Figure 11.8: Scenario: Send IP Stream

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-2.0-Sequenzdiagramm mit kombinierten Fragmenten (loop) und architektonischen Partitionen/Swimlanes (Client, Server).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Communication Management (ara::com).
• Technischer Zweck: Spezifikation des Lebenszyklus und Interaktionsmusters für Raw Data Streams (IP-basierter Rohdatenstrom) zwischen zwei Adaptive Applications. Das Diagramm demonstriert die Kapselung transportprotokollspezifischer Verbindungsphasen (hier exemplarisch TCP) hinter standardisierten ara::com-Abstraktionsschnittstellen für Streaming-Szenarien (z. B. Kamera-/Sensordaten, Video-Streams oder Bulk-Transfers).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • Client: Adaptive Application: Anwendungsinstanz auf Client-Seite (Initiator von Verbindungsaufbau, Schreibzugriffen und Verbindungsabbau).
  • :RawDataStreamClient: Plattformseitige ara::com-Laufzeitinstanz zur Handhabung der clientseitigen Socket-/Stream-Kommunikation.
  • :RawDataStreamServer: Plattformseitige ara::com-Laufzeitinstanz zur Verwaltung des serverseitigen Listener- und Empfangs-Sockets.
  • Server: Adaptive Application: Anwendungsinstanz auf Server-Seite (Empfänger des Datenstroms).
• Anwendungsschnittstellen (APIs):
  • Create(): Synchrone/konstruktive Instanziierung der Stream-Endpunkte.
  • WaitForConnection(): Blockierendes bzw. synchronisierendes Warten der Server-Applikation auf einen eingehenden Verbindungsaufbau.
  • Connect(): Clientseitige Verbindungsanforderung an den konfigurierten Remote-Endpunkt.
  • WriteData(): Übergabe von Nutzdatenpuffern an den Ausgangsstrom.
  • ReadData(): Abruf empfangener Byte-Puffer aus dem Eingangsstrom.
  • Shutdown(): Geordnete Terminierung der Stream-Sitzung.
• Protokollebene & Stereotypen:
  • Stereotyp «aapInformative»: Kennzeichnet die plattforminternen, rein informativen Netzwerk-Frames unterhalb der ara::com-API-Ebene (OS-Netzwerkstack / TCP-IP).
  • Netzwerkmeldungen: SYN(), SYN-ACK(), ACK(), data(), FIN().

3. Dynamisches Verhalten & Sequenzablauf

Der Kommunikationsablauf gliedert sich in drei aufeinanderfolgende Phasen:

1. Verbindungsaufbau (Connection Establishment):
   • Server initialisiert :RawDataStreamServer via Create() und blockiert/wartet über WaitForConnection().
   • Client instanziiert :RawDataStreamClient via Create() und ruft Connect() auf.
   • Transportpfad («aapInformative»): Das Subsystem führt den standardkonformen TCP-3-Way-Handshake aus:
     1. Client → Server: SYN()
     2. Server → Client: SYN-ACK()
     3. Client → Server: ACK()
   • Nach erfolgreichem Handshake kehren sowohl WaitForConnection() auf Serverseite als auch Connect() auf Clientseite erfolgreich zur jeweiligen Applikation zurück.
2. Datenübertragungsphase (loop Write Data):
   • Wiederholte Datenübermittlung innerhalb des Loop-Fragments:
     • Client ruft WriteData() auf.
     • Transportebene übermittelt Nutzdatenpayload (data(), «aapInformative»).
     • Server ruft ReadData() auf und übernimmt die empfangenen Bytes in den Applikationsspeicher.
   • Ausführung erfolgt entkoppelt über Sende-/Empfangspuffer der Plattform bzw. des Betriebssystems.
3. Verbindungsabbau (Connection Teardown):
   • Client initiiert die Schließung via Shutdown().
   • Transportpfad («aapInformative»): Standardisierter 4-Way-Teardown (TCP FIN/ACK-Handshake):
     1. Client → Server: FIN()
     2. Server → Client: ACK()
     3. Server → Client: FIN()
     4. Client → Server: ACK()
   • Beide Stream-Objekte (:RawDataStreamClient, :RawDataStreamServer) werden zerstört (terminierende Lebenslinien mit X).

4. Normative Relevanz & Entwickler-Hinweise

• Protokolltransparenz vs. Konfiguration: Die Applikationslogik verwendet identische APIs (Create, WriteData, ReadData), unabhängig davon, ob im Deployment-Manifest TCP oder UDP konfiguriert ist.
  • TCP (wie dargestellt): Verbindungsaufbau (SYN/ACK) und geordneter Shutdown (FIN/ACK) sind zwingend; Byte-Stream-Semantik erfordert applikatives Framing/Message-Delimiting, da TCP keine Nachrichtengrenzen wahrt.
  • UDP (laut Notiz): Verbindungsaufbau und Shutdown entfallen auf Netzwerkebene; die Aufrufe von Connect() bzw. WaitForConnection() degenerieren zu lokalen Socket-/Bind-Operationen ohne Netzwerkverkehr.
• Blockier- & Threading-Modell: WaitForConnection() und ReadData() sind in Echtzeitanwendungen zwingend gegen Deadlocks und Thread-Starvation abzusichern (z. B. durch asynchrone Futures (ara::core::Future), Timeouts oder Polling-Mechanismen gemäß POSIX/ARA-Spezifikation).
• Buffer-Management: Für Hochdurchsatz-Streams (z. B. Video) müssen Zero-Copy-Strategien oder Ringpuffer-Allokatoren genutzt werden, um Kontextwechsel und Kopiervorgänge zwischen Kernel- und User-Space über WriteData()/ReadData() zu minimieren.