Figure 9.30: Interfaces for raw data streams using IP based protocols

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Profilierung).
• Architektonischer Kontext: AUTOSAR Adaptive Platform (Release R24-11), Spezifikation AUTOSAR_AP_EXP_SWArchitecture, Kapitel Communication Management / Raw Data Stream.
• Technischer Zweck: Modellierung der standardisierten C++-API-Abstraktion für unstrukturierte bzw. nicht-serialisierte Byte-Datenströme (Raw Data Streams) über IP-basierte Transportprotokolle (TCP/UDP). Dient als performante Alternative zur modellierten, stark typisierten Service-Oriented Architecture (ara::com mit SOME/IP oder DDS) für bandbreitenintensive Nutzlasten wie Video-/Kameraströme, Radar-Rohdaten oder Diagnose-Tunnel.

2. Komponenten, Entitäten & Schnittstellen

Komponenten & Funktionscluster

• Adaptive Application (Komponente): Endanwender- oder Plattformprozess im User Space, der als Datensenke/Datenquelle agiert.
• «aapFunctionalCluster» Raw Data Stream (Komponente): Standardisierter AUTOSAR Adaptive Funktionscluster, der die zugrundeliegenden POSIX-Netzwerk-Sockets kapselt, Lifecycle- und Pufferverwaltung übernimmt und die Port-Interfaces implementiert.

Port-Interfaces & Operationen

Beide Schnittstellen tragen die Stereotypen «aapAPI,aapPortInterface»:

• RawDataStreamClient:
  • + Create() (statisch / factory method, unterstrichen): Instanziiert den Client-Kanal anhand von Port-Prototypen / Service-Deployment-Konfigurationen.
  • + Connect(): Baut aktiv die IP-Verbindung zum Server-Endpunkt auf (Drei-Wege-Handshake bei TCP bzw. Endpunkt-Bindung bei UDP).
  • + ReadData(): Liest Rohdatenblöcke aus dem internen Empfangspuffer.
  • + WriteData(): Übergibt Datenblöcke an den IP-Socket zur Übertragung.
  • + Shutdown(): Initiiert den geordneten Verbindungsabbau und Ressourcen-Freigabe.
• RawDataStreamServer:
  • + Create() (statisch / factory method, unterstrichen): Instanziiert den Listener-Endpunkt.
  • + WaitForConnection(): Blockierender bzw. synchronisierender Zustandswächter (Accept-Semantik), wartet auf eingehende Client-Verbindungsanfragen.
  • + ReadData(): Liest ankommende Nutzdaten.
  • + WriteData(): Sendet Daten über die aktive Session zurück.
  • + Shutdown(): Beendet den Server-Socket und schließt aktive Client-Verbindungen.

Beziehungen & Abhängigkeiten

• Realization (--▷): Der Cluster Raw Data Stream realisiert beide Schnittstellenverträge (RawDataStreamClient und RawDataStreamServer).
• Usage / Dependency (..> «use» «aapRequiredPort»): Die Adaptive Application bindet die Schnittstellen über Required Ports ein, wodurch die Abhängigkeit zur konkreten Plattformimplementierung entkoppelt wird.

3. Dynamisches Verhalten & Sequenzablauf

Client-Lebenszyklus

1. Initialisierung: Aufruf der statischen Factory-Methode Create() mit Port-Konfiguration (PortPrototypeMapping). Rückgabe eines Handle/Instanzobjekts (gemäß Adaptive-Mustern typischerweise ara::core::Result<...>).
2. Verbindungsaufbau: Connect() initiiert den Socket-Verbindungsaufbau zum Server.
3. Nutzdatenphase:
   • Bidirektionaler Datenaustausch via WriteData() (Übergabe von ara::core::Span<const Byte> o. ä.) und ReadData().
   • Je nach Realisierung blockierend oder event-basiert über asynchrone Futures (ara::core::Future).
4. Terminierung: Aufruf von Shutdown() führt zu FIN/RST-Paketen auf Socket-Ebene und entbindet Systemressourcen.

Server-Lebenszyklus

1. Initialisierung & Bind: Aufruf von Create(), Socket wird an IP-Adresse/Port gebunden (bind(), listen()).
2. Client-Handling: Aufruf von WaitForConnection(). Suspendiert den rufenden Thread bzw. liefert ein Future, bis eine Client-Verbindung akzeptiert wurde.
3. Nutzdatenphase: Symmetrische Nutzung von ReadData() und WriteData() auf dem aktiven Stream.
4. Terminierung: Shutdown() schließt den Listening-Socket und terminierende Sessions.

4. Normative Relevanz & Entwickler-Hinweise

• Bypass von Serialisierung: Im Gegensatz zu ara::com erfolgt keine SOME/IP-Serialisierung, Signal-Transformation oder Deserialisierung. Applikationsentwickler sind selbst für Endianness, Framing, Pufferbegrenzungen und Integrität (z. B. Checksums) verantwortlich.
• Port-basiertes Deployment (AUTOSAR-Metamodell):
  • Zugriff erfolgt strikt über Ports (RPortPrototype mit Bindung an RawDataStreamClient oder RawDataStreamServer).
  • IP-Parameter (IP-Adressen, TCP/UDP-Ports, Puffergrößen, QoS/VLAN) werden im Execution Manifest und Service Instance Manifest modelliert, nicht hardcodiert.
• Echtzeit & Scheduling: WaitForConnection() und I/O-Aufrufe müssen bezüglich der OS-Scheduling-Policies (POSIX FIFO/RR) analysiert werden, um Priority Inversion oder Blockaden im Haupt-Execution-Thread zu vermeiden (Dedizierte Worker-Threads oder Non-blocking/Asynchrone I/O-Muster verwenden).
• Fehlerbehandlung: Methoden nutzen das AUTOSAR-Standardfehlermodell (ara::core::Result und ara::core::ErrorCode), statt C++ Exceptions. Netzwerkunterbrechungen erfordern deterministische Reconnect-Logik im Applikationscode.