Figure 11.8: Scenario: Send IEEE1722 Stream

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsszenario mit Objekterzeugung, Methodenaufrufen und kombiniertem Interaktionsfragment loop).
• Technischer Zweck: Spezifikation des Lebenszyklus und der Interaktionssequenz beim Senden unformatierter Datenströme (Raw Data Stream) über das Protokoll IEEE 1722 (Audio Video Transport Protocol / AVTP) innerhalb der AUTOSAR Adaptive Platform (ara::com / Raw Data Stream API).
• Funktionale Einordnung: Dient dem deterministischen, echtzeitnahen Streaming von AVB/TSN-Sensordaten (z. B. Video-, Audio- oder Radar-Streams) direkt aus einer Adaptive Application unter Umgehung des Service-Oriented-Communication-Overheads (SOME/IP), realisiert als spezialisierter Stream-Producer auf Plattformebene.

2. Komponenten, Entitäten & Schnittstellen

• :Adaptive Application: Aktiver Prozess / Client-Instanz der Anwendungsdomäne, agiert als Initiator und Datenquelle des Datenstroms.
• :IEEE1722RawDataStreamProducer: Plattform- bzw. Middleware-Entität (Endpunkt-Abstraktion der Raw Data Stream API), zuständig für die Kapselung, Header-Generierung (AVTP-Header, Stream-ID, Sequence-Numbering) und das Absenden der IEEE 1722-Frames über Ethernet/TSN-Sockets.
• Schnittstellen / Methoden:
  • Create(): Instanziierung / Allokation des Producer-Objekts (parametrisiert über Konfiguration/Manifest wie Stream-ID, VLAN, Traffic-Klasse).
  • Connect(): Synchrone/asynchrone Bindung an das Netzwerkinterface bzw. Reservierung der TSN/AVB-Stream-Ressourcen.
  • WriteData(): Übergabe des Daten-Payloads (Datagrams/Frames) an den Protokoll-Stack zur Übertragung.
  • Shutdown(): Terminierung der Verbindung, Freigabe zugewiesener Descriptor- und Puffer-Ressourcen sowie Schließen des Socket-/TSN-Endpunkts.

3. Dynamisches Verhalten & Sequenzablauf

1. Instanziierung: Die Adaptive Application erzeugt via Create() eine Instanz von :IEEE1722RawDataStreamProducer.
2. Verbindungsaufbau: Aufruf von Connect(), um den Producer an das konfigurierte Netzwerkziel und die IEEE 1722 Stream-ID zu binden.
3. Datenübertragung (loop Write Data):
   • Wiederholter, zyklischer Aufruf von WriteData() innerhalb des Interaktionsfragments loop.
   • Payload wird serialisiert, in AVTP-Datagramme gepackt und versendet.
4. Terminierung: Nach Abschluss der Datenübertragung ruft die Applikation Shutdown() auf.
5. Objektzerstörung: Freigabe und Zerstörung des Producers (gekennzeichnet durch das Abbruch-/Lebensdauer-Ende-Kreuz X auf der Rettungsleine des :IEEE1722RawDataStreamProducer).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag: Connect() muss zwingend vor dem ersten WriteData() erfolgreich ausgeführt worden sein. Ein Schreibversuch ohne aktiven Verbindungsstatus führt zu einem standardisierten Fehlercode (z. B. ara::core::ErrorCode).
• Pufferung & Blocking-Semantik: WriteData() erfordert je nach Treiberkonfiguration entweder Zero-Copy-Pufferung (ara::core::Span<const uint8_t>) oder blockiert bei vollen Network-Socket-/TSN-Queue-Puffern. Entwickler müssen Pufferüberläufe und Timeouts bei hohen Datenraten (z. B. Rohkamera-Streams) über korrekte Socket-QoS/PBN-Konfigurationen absichern.
• Ressourcenfreigabe: Shutdown() ist vor der Deallokation des Application-Contexts zwingend erforderlich, um Leakage von File Descriptors, TSN-Bandbreitenreservierungen (Stream Reservation Protocol / IEEE 802.1Qat) und Socket-Handles im zugrunde liegenden POSIX-Betriebssystem zu verhindern.