Figure 11.11: Scenario: Receive IP Stream

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm) mit Interaktionsrahmen (loop), Lifelines und informativen Transportprotokoll-Interaktionen.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Communication Management (ara::com).
• Technischer Zweck: Spezifikation des Interaktionsmusters für das Empfangen unstrukturierter Datenströme (Raw Data Stream) über IP-basierte Transportprotokolle (L4: TCP/UDP). Das Diagramm illustriert die Kapselung von POSIX/Socket- bzw. OS-Netzwerk-Interaktionen durch die standardisierten AP-Stream-APIs (RawDataStreamClient und RawDataStreamServer) unter beispielhafter Darstellung eines verbindungsorientierten Transports (TCP).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Rollen

• Client: Adaptive Application (AA): Konsumierende Applikationsinstanz im Client-Ausführungskontext, die den Verbindungsaufbau initiiert und Daten über die API liest.
• :RawDataStreamClient: Plattform- bzw. Middleware-Entität (ara::com), die den clientseitigen Stream-Endpunkt, Socket-Zustände und Datenpufferung abstrahiert.
• Server: Adaptive Application (AA): Produzierende Applikationsinstanz im Server-Ausführungskontext, die Verbindungsanfragen entgegennimmt und Nutzdaten schreibt.
• :RawDataStreamServer: Middleware-Gegenstelle (ara::com) auf Server-Seite zur Verwaltung von Listener-Sockets, eingehenden Verbindungen und L4-Segmentierung.

Stereotypen & Notationen

• «aapInformative»: Kennzeichnet AUTOSAR Adaptive Platform Informative Messages. Die markierten Nachrichten (SYN(), SYN-ACK(), ACK(), data(), FIN()) repräsentieren den physischen bzw. netzwerkseitigen Protokollfluss (OS-/TCP-Stack-Ebene) und sind keine direkten C++-API-Aufrufe der Applikation.
• Interaktionsrahmen (loop Read Data): Repräsentiert das zyklische oder ereignisgesteuerte Polling/Lesen von Streaming-Datenblöcken.
• Lebensdauer-Ende (X): Zerstörung/Freigabe der jeweiligen Stream-Instanzen nach Ausführung der Shutdown-Sequenz.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Initialisierung & Verbindungsaufbau (Connection Setup)

1. Server-Bereitstellung:
   • Server: Adaptive Application instanziiert :RawDataStreamServer via Create().
   • Server ruft blockierend oder asynchron WaitForConnection() auf dem Stream-Server-Objekt auf (entspricht funktional bind()/listen()/accept()).
2. Client-Verbindungsanforderung:
   • Client: Adaptive Application instanziiert :RawDataStreamClient via Create().
   • Client initiiert die Verbindung mittels Connect().
3. L4-Handshake (TCP 3-Way Handshake via «aapInformative»):
   • :RawDataStreamClient → :RawDataStreamServer: SYN()
   • :RawDataStreamServer → :RawDataStreamClient: SYN-ACK()
   • :RawDataStreamClient → :RawDataStreamServer: ACK()
4. Verbindungsbestätigung:
   • Nach erfolgreichem Handshake kehrt WaitForConnection() zur Server-AA zurück.

Phase 2: Datenübertragung (loop Read Data)

1. Senden: Server: Adaptive Application übergibt Nutzdatenpuffer via WriteData() an :RawDataStreamServer.
2. Netzwerktransfer («aapInformative»): L4-Payload wird über IP als data() an :RawDataStreamClient übertragen. Segmentierung und Reassemblierung erfolgen plattformintern.
3. Empfang: Client: Adaptive Application ruft ReadData() auf. Die Middleware liefert den empfangenen Bytestrom zurück (gestrichelte Rückgabe an Client-AA).

Phase 3: Verbindungsabbau (Connection Teardown)

1. Trigger: Client: Adaptive Application initiiert die Beendigung via Shutdown().
2. TCP Graceful Teardown (4-Way Handshake via «aapInformative»):
   • :RawDataStreamClient → :RawDataStreamServer: FIN()
   • :RawDataStreamServer → :RawDataStreamClient: ACK()
   • :RawDataStreamServer → :RawDataStreamClient: FIN()
   • :RawDataStreamClient → :RawDataStreamServer: ACK()
3. Instanzterminierung: Beide Endpunkte beenden ihre Session und schließen die Lifelines (X).

4. Normative Relevanz & Entwickler-Hinweise

• Abstraktion von Socket-APIs: Applikationsentwickler interagieren ausschließlich mit den typisierten C++-Methoden (Connect(), WaitForConnection(), ReadData(), WriteData(), Shutdown()). Direkte Zugriffe auf BSD-/POSIX-Sockets sind unzulässig und brechen die Portabilität nach AP-Sicherheits- und Plattformvorgaben.
• Protokollvarianz (TCP vs. UDP):
  • TCP (dargestellt): Verbindungsorientiert. Verbindungsaufbau (Connect() / WaitForConnection()) und -abbau (Shutdown()) erfordern L4-Handshakes.
  • UDP (gemäß Diagramm-Notes): Verbindungslos. SYN/ACK- sowie FIN/ACK-Phasen entfallen auf Netzwerkebene; die API-Zustandsmaschine bleibt für die Applikation homogen gekapselt, arbeitet intern jedoch datagrammbasiert ohne Zustandsgarantie.
• Bidirektionalität: Obwohl als Unicast-Stream vom Server zum Client dargestellt, unterstützen Protokollkonfigurationen wie TCP vollduplexen Datenaustausch (ReadData() und WriteData() sind auf beiden Peers nutzbar).
• Segmentierung & MTU-Handling: Die Fragmentierung/Reassemblierung größerer Datenblöcke wird vollständig innerhalb der Kommunikationsmiddleware und des OS-Netzwerk-Stacks abgewickelt. Applikationen müssen jedoch Pufferüberläufe und unvollständige Chunks über Rückgabewerte bzw. Streamsizes von ReadData() defensiv auswerten.
• Ressourcen-Lifecycle: Der Aufruf von Shutdown() ist obligatorisch, um Socket-Deskriptoren, Pufferbereiche und ephemeral Ports deterministisch freizugeben und Zombie-Verbindungen im OS-Netzwerk-Stack zu vermeiden.