DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-0e9c3a9628a20d2a 828 × 625 px 1 Release(s)

Figure 11.10: Scenario: Receive IP Stream

SHA-256 Inhalts-Fingerabdruck: 0e9c3a9628a20d2a4b4a6199edd97433fc1c6339aa95c1a194f1255067c2ec1f
Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

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.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Client Server | Client: Adaptive | Application | :RawDataStreamClient | loop Read Data | :RawDataStreamServer | Server: Adaptive | Application |               |     |  |      |  |  |  |   |   |    |         |  |       |  |   |  |     |     |  |  |  |  |  |  |  |     |  |  |       |  |  |  |            |        |  |      |  |  |  |   |   |    |        |   |  |         |  |   |  |        |  |   |  |  |    |  |   |       |  |  |     |  |  |  | FIN() | «aapInformative» | Shutdown() | FIN() | «aapInformative» | ACK() | «aapInformative» | ACK() | «aapInformative» | SYN-ACK() | «aapInformative» | data() | «aapInformative» | ReadData() | ACK() | «aapInformative» | WaitForConnection() | Create() | Connect() | SYN() | «aapInformative» | WriteData() | Create()

Begleitender Spezifikationstext:

FIN() «aapInformative» Shutdown() FIN() «aapInformative» ACK() «aapInformative» ACK() «aapInformative» SYN-ACK() «aapInformative» data() «aapInformative» ReadData() ACK() «aapInformative» WaitForConnection() Create() Connect() SYN() «aapInformative» WriteData() Create() Figure 11.10: Scenario: Receive IP Stream Figure 11.10 shows the scenario for Receive Raw Data Stream that makes use of an IP-based protocol (i.e., TCP or UDP). The Client Adaptive Application needs to connect to a Server using Connect(). If TCP is configured as a protocol, the underlying TCP connection will be established with the Server. Afterwards, the Server Adaptive Application transmits data by calling WriteData(). The Client Adaptive Application may receive the data transmitted by the Server by calling ReadData() . The segmentation of data is handled internally. Please note that Client and Server are both able to receive and transmit via the same stream for some types of protocol configurations (e.g., TCP). If the stream is no longer needed, the Client Adaptive Application may shutdown the connection using Shutdown(). 11.2.2 Time Synchronization This section shows interactions for Time Synchronization Master (see Section 11.2.2.1) and Time Synchronization Slave (see Section 11.2.2.2). 224 of 269 Document ID 982: AUTOSAR_AP_EXP_SWArchitecture

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 224 11.10 Figure 11.10: Scenario: Receive IP Stream