DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-dd5addc263c4d6fa 406 × 360 px 1 Release(s)

Figure 11.10: Scenario: Receive IEEE1722 Stream

SHA-256 Inhalts-Fingerabdruck: dd5addc263c4d6fa6c76e28f1a92d8e6d7f167beb1a74df5d725bfd9dc878434

Im Versions-Explorer öffnen

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

  • Klassifikation: UML 2.x Sequenzdiagramm (Interaktionsdiagramm mit kombiniertem Fragment loop).
  • Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Teilsystem Kommunikation (ara::com / Raw Data Stream API).
  • Technischer Zweck: Spezifikation des Lebenszyklus und Interaktionsmusters beim Empfang von unstrukturierten bzw. echtzeitnahen Streaming-Daten über das IEEE 1722 AVTP (Audio Video Transport Protocol) durch eine Adaptive Application (Consumer-Rolle).

2. Komponenten, Entitäten & Schnittstellen

  • Akteure / Lebenslinien:
    • :Adaptive Application: Nutzerprozess im User Space der Adaptive Platform, agiert als Datensenke (Consumer).
    • :IEEE1722RawDataStreamConsumer: Funktionale Entität / Proxy-Klasse des Kommunikations-Stacks zur Kapselung des IEEE 1722 Stream-Endpunkts (AVTP-Empfänger).
  • Schnittstellen & Methoden:
    • Create(): Konstruktion/Instanziierung der Consumer-Instanz (Lifecycle-Beginn).
    • Connect(): Bindung des Sockets bzw. Registrierung auf den spezifischen IEEE 1722 Stream (Stream-ID, Multicast-MAC/VLAN-Filterung).
    • ReadData(): Polling- oder blockierender Abruf von empfangenen AVTP-Payloads/Frames aus dem Stack-Puffer.
    • Shutdown(): Terminierung der Stream-Verbindung, Freigabe von Netzwerk- und Puffer-Ressourcen.
  • Beziehungen: 1:1-Assoziation zwischen der anfordernden Applikationsinstanz und dem zugewiesenen Stream-Consumer-Objekt über dessen Lebensdauer hinweg.

3. Dynamisches Verhalten & Sequenzablauf

  1. Instanziierung: Die :Adaptive Application erzeugt das :IEEE1722RawDataStreamConsumer-Objekt via Create() (gekennzeichnet durch die direkte Erzeugungsnachricht auf den Objektkopf).
  2. Verbindungsaufbau: Synchroner Methodenaufruf Connect() initiiert das Subskribieren/Binden an den IEEE 1722 AVTP-Datenstrom auf Netzwerkebene.
  3. Datenempfang (loop Read Data):
    • Das kombinierte Fragment loop definiert die wiederholte Ausführung von ReadData().
    • Die Applikation ruft zyklisch oder ereignisgetrieben ReadData() auf, um eintreffende Datenpakete (z. B. Audio/Video, Sensor-Rohdaten wie Kamera/Radar) sequenziell aus dem Empfangspuffer auszulesen.
  4. Verbindungsabbau & Zerstörung:
    • Nach Abschluss des Datenstroms ruft die Applikation Shutdown() auf.
    • Der Consumer-Endpunkt wird geschlossen, die Ressourcen werden freigegeben und die Lebenslinie des :IEEE1722RawDataStreamConsumer endet explizit mit dem UML-Terminierungszeichen (X).

4. Normative Relevanz & Entwickler-Hinweise

  • Protokoll-Charakteristik: Im Gegensatz zu IPC/SOME/IP-basierten RPC- oder Event-Mechanismen verzichtet der Raw Data Stream auf Serialisierungs-Overhead. Daten werden direkt im IEEE 1722 AVTP-Format verarbeitet (z. B. Ethernet Layer 2 / AVB).
  • API-Vertrag (ara::com):
    • Connect() und ReadData() arbeiten nach dem ara::core::Result-Muster (Fehlerbehandlung ohne C++ Exceptions).
    • ReadData() erfordert applikationsseitiges Puffer-Management (Bereitstellung von Speichervektoren bzw. Entgegennahme von Zero-Copy-Puffern/Spans zur Vermeidung von Latenzen).
  • Ressourcen & Determinismus:
    • Der Aufruf von Shutdown() ist zwingend vor Zerstörung des Kontextes erforderlich, um Socket-Desktriptoren und Kernel-/Stack-Puffer deterministisch freizugeben.
    • Die Ausführungsschleife (loop) unterliegt Echtzeitanforderungen; ein Überlaufen des Empfangspuffers bei zu seltener Abholung (ReadData()) führt zu Frame-Loss auf AVTP-Ebene.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

:Adaptive Application | :IEEE1722RawDataStreamConsumer | loop Read Data | Shutdown() | Create() | Connect() | ReadData()

Begleitender Spezifikationstext:

Explanation of Adaptive Platform Software Architecture AUTOSAR AP R24-11 Figure 11.9 shows the scenario for Send 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 Client Adaptive Application may transmit data to the Server by calling WriteData(). The Server Adaptive Application may receive the data transmitted by the Client 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.1.2 Receive Raw Data Stream 11.2.1.2.1 Scenario: Receive IEEE1722 Stream :Adaptive Application :IEEE1722RawDataStreamConsumer loop Read Data Shutdown() Create() Connect() ReadData() Figure 11.10: Scenario: Receive IEEE1722 Stream Figure 11.10 shows the scenario for Receive Raw Data Stream that makes use of the IEEE1722 protocol. The Adaptive Application needs to connect to an IEEE1722 stream using Connect(). Afterwards, the Adaptive Application may receive any number of datagrams by calling ReadData(). If the stream is no longer needed, the Adaptive Application may shutdown the connection using Shutdown().

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_EXP_SWArchitecture S. 203 11.10 Figure 11.10: Scenario: Receive IEEE1722 Stream