Figure 9.26: Interfaces for raw data streams

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm mit Schnittstellen- und Port-Spezifikation (AUTOSAR Adaptive Platform UML-Profil).
• Funktionale Einordnung: Verortet im Functional Cluster Raw Data Stream der AUTOSAR Adaptive Platform.
• Technischer Zweck: Spezifikation standardisierter Schnittstellen zur Übertragung unmodellierter, roher Byteströme (Raw Data Streams) zwischen einer Adaptive Application und der Plattform. Die Schnittstelle dient als performante Abstraktion für volumetrische Daten (z. B. Video-, Audio-, Radar- oder Sensor-Rohdaten), bei denen die Serialisierung und der Overhead serviceorientierter Protokolle (SOME/IP) vermieden werden müssen.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • Adaptive Application: Anwendungsprozess im User-Space, agiert je nach Use-Case als Stream-Consumer, Stream-Producer oder Gateway.
  • «aapFunctionalCluster» Raw Data Stream: Plattform-Dienst/Cluster, der die systemnahe Streaming-Infrastruktur kapselt (z. B. über POSIX-Sockets, Shared-Memory oder Unix Domain Sockets).
• Schnittstellen & Stereotypen:
  • «aapAPI,aapPortInterface» RawDataStreamClient: Client-Endpunkt für ausgehende Verbindungen.
    • + Connect(): Baut aktive Verbindung zum Ziel-Endpunkt auf.
    • + ReadData(): Liest Byteströme aus dem Puffer/Kanal.
    • + WriteData(): Schreibt Rohdaten in den Kanal.
    • + Shutdown(): Führt geordneten Verbindungsabbau durch.
  • «aapAPI,aapPortInterface» RawDataStreamServer: Server-Endpunkt zur Entgegennahme eingehender Verbindungen.
    • + WaitForConnection(): Wartet auf eingehende Verbindungsanfragen (Passiv-Listen/Accept).
    • + ReadData(): Liest eingehende Nutzlast.
    • + WriteData(): Sendet Daten an den verbundenen Client.
    • + Shutdown(): Beendet die Verbindung bzw. schließt den Server-Socket.
• Beziehungen:
  • Interface Realization: Der Functional Cluster Raw Data Stream implementiert und exponiert beide Schnittstellen über Realisierungsbeziehungen.
  • Dependency («use», «aapRequiredPort»): Die Adaptive Application bindet die Schnittstellen über explizit mit «use» und «aapRequiredPort» modellierte Abhängigkeiten an, um Stream-Sitzungen zu steuern.

3. Dynamisches Verhalten & Sequenzablauf

1. Verbindungsinitialisierung:
   • Server-Pfad: Initialisierung der Server-Instanz → Aufruf von WaitForConnection(). Blockiert synchron oder operiert asynchron (Rückgabe via ara::core::Future), bis ein Client anklopft.
   • Client-Pfad: Initialisierung der Client-Instanz → Aufruf von Connect(). Initiiert den Handshake zum konfigurierten Endpunkt (IP/Port oder IPC-Socket).
2. Datentransfer-Phase (Vollduplex / Halbduplex):
   • Senden: Aufruf von WriteData() mit Datenzeiger und Längenangabe. Pufferung erfolgt im underlying Transportpuffer des OS-Kernels/Treibers.
   • Empfang: Aufruf von ReadData(). Übergabe von Ziel-Puffern; Rückgabe der tatsächlich gelesenen Byteanzahl oder eines ara::core::Result<void> bzw. Fehlercodes (z. B. Puffer-Überlauf, EOF).
3. Terminierung:
   • Initiator ruft Shutdown() auf → Flush verbleibender Daten → TCP-FIN/RST oder Schließen des IPC-File-Descriptors → Gegenstelle detektiert EOF in ReadData() und beendet die Sitzung ebenfalls mit Shutdown().

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Fehlermodell: Die Methoden folgen dem C++14/C++17-Paradigma der Adaptive Platform. Rückgabewerte und asynchrone Ergebnisse sind typischerweise über ara::core::Result<T> bzw. ara::core::Future<T> gekapselt (keine C++ Exceptions).
• Abgrenzung zu Service Interfaces: Im Gegensatz zu modellierten Service Interfaces (Events, Methods, Fields) existiert kein typisiertes IDL-Schema (keine Serialisierung via SOME/IP Transformer). Entwickler sind selbst für Framing, Synchronisationsmuster (z. B. Paket-Header, Magic Bytes) und Endianness zuständig.
• Laufzeit- & Speichereffizienz:
  • Zur Vermeidung von Cache-Trashing und CPU-Kopieraufwand unterstützen typische Stack-Implementierungen Zero-Copy-Puffer (z. B. Memory-Mapped IO, POSIX Shared Memory).
  • Bei Echtzeit-Streaming müssen Entwickler ReadData()- und WriteData()-Threads deterministisch priorisieren, um Pufferüberläufe im Kernel-Space (Socket-Drop) zu verhindern.
• ARXML-Manifestierung: Die Schnittstellen müssen im Service Instance Manifest und Execution Manifest korrekt auf Netzwerk-Endpunkte (IP-Adressen, Ports, Transport-Layer-Protokoll TCP/UDP) gemappt und den Prozess-Berechtigungen (POSIX Capabilities / Access Control) zugewiesen werden.