Figure 7.4: IEEE1722 subtype class inheritance hierarchy.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (Spezialisierungs- und Vererbungshierarchie).
• Architektur-Einordnung: Spezifikation der AUTOSAR Adaptive Platform (AP) im Funktionscluster Raw Data Stream (ara::rds), spezifiziert im Dokument AUTOSAR_AP_SWS_RawDataStream (Releases R24-11, R25-11).
• Technischer Zweck: Das Diagramm modelliert die objektorientierte C++-Klassenstruktur zur Kapselung von Ethernet-Datagrammen gemäß dem IEEE 1722-Standard (Audio Video Transport Protocol / AVTP). Es bildet die Basis für den echtzeitfähigen, latenzarmen Datenaustausch von Multimedia-, Video- (ADAS/Sensoren) und Steuerungsinformationen über Time-Sensitive Networking (TSN) / AVB, ohne den Overhead des vollständigen ara::com-Service-Stacks zu durchlaufen.

2. Komponenten, Entitäten & Schnittstellen

Alle Entitäten sind Klassen im C++-Namespace ara::rds, deklariert in der Header-Datei #include "ara/rds/raw_data_stream_IEEE1722.h". Das Diagramm definiert eine dreistufige Spezialisierungshierarchie über reine Vererbungsbeziehungen (Generalization, rot indiziert):

1. Wurzelklasse:
   • ara::rds::IEEE1722Datagram: Abstrakte Basisklasse für alle IEEE 1722-konformen Datagramme im Raw Data Stream.
2. Gemeinsame AVTPDU-Basisschicht:
   • ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields (spezialisiert IEEE1722Datagram): Kapselt die allgemeinen AVTPDU-Header-Felder (u. a. subtype, version, Stream-Data-Subtyp-Definitionen wie avtpStreamDataSubtype gemäß [SWS_RDS_90230]).
3. Subtyp-Ebene 1 (Direkte Subklassen von IEEE1722DatagramAVTPDUCommonHeaderFields):
   • ara::rds::IEEE1722DatagramCRF: Kapselt das Clock Reference Format (CRF) zur Verteilung von Takt-, Frequenz- und Phasenreferenzen über Ethernet.
   • ara::rds::IEEE1722DatagramNTSCF: Kapselt das Non-Time-Synchronous Control Format (NTSCF) für asynchrone Steuerbefehle ohne zwingenden AVTP-Präsentationszeitstempel.
   • ara::rds::IEEE1722DatagramAVTPDUCommonStreamHeaderFields: Abstrakte Zwischenklasse für alle kontinuierlichen, zeitkritischen Datenströme; erweitert die Basis-Header um stream-spezifische Kontrollfelder (Stream-ID, Sequence-Number, AVTP-Timestamp).
4. Subtyp-Ebene 2 (Spezialisierungen von IEEE1722DatagramAVTPDUCommonStreamHeaderFields):
   • ara::rds::IEEE1722Datagram61883_IIDC: Datenformate nach IEC 61883 / IIDC (Audio/Video-Legacy-Formate).
   • ara::rds::IEEE1722DatagramAAF: AVTP Audio Format (Übertragung von PCM- oder AES3-Audiodaten).
   • ara::rds::IEEE1722DatagramTSCF: Time-Synchronous Control Format (zeitkritische, zyklische Regelungs- und Steuerungsnachrichten, z. B. CAN/LIN/FlexRay-over-Ethernet Tunneling).
   • ara::rds::IEEE1722DatagramRVF: Raw Video Format (unkomprimierte oder pixelbasierte Video-Rohdatenströme, z. B. für Kamerasysteme im autonomen Fahren).

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Als statisches Klassendiagramm enthält die Abbildung keinen zeitlichen Ablauf. Für das Zusammenspiel zur Laufzeit gilt:

• Demultiplexing & Parsing: Bei Frame-Empfang auf einem ara::rds-Endpunkt wertet der Stack das IEEE 1722-Subtype-Feld aus und projiziert den PDU-Speicher auf die entsprechende spezialisierte Klasse (z. B. IEEE1722DatagramRVF oder IEEE1722DatagramTSCF).
• Synchrones Zero-Copy / In-Place Handling: Die Instanzen operieren typischerweise als Wrapper/Views auf contiguous Buffers (ara::core::Span), um Kopieroperationen bei hochratigen Streams (z. B. Video) zu vermeiden.
• Fehlerpfade & API-Signalisierung: Der Datenaustausch erfolgt über Adaptive-Platform-Mechanismen (ara::core::Result), Ausnahmen und Det/Dem-Fehlerpfade existieren im AP-Kontext nicht; Protokoll- und Frame-Fehler (z. B. ungültige Subtypes, falsche Sequence Numbers) werden über typspezifische Fehlercodes im Result-Typ an die Applikation zurückgemeldet.

4. Normative Relevanz & Entwickler-Hinweise

• Zugriffsmodifikatoren & Datenkapselung ([SWS_RDS_90230]): Header-Felder wie std::uint16_t avtpStreamDataSubtype sind innerhalb von IEEE1722DatagramAVTPDUCommonHeaderFields mit protected-Sichtbarkeit deklariert. Ein direkter schreibender Zugriff auf Feldebene durch Applikationscode ist verboten; der Zugriff erfolgt kontrolliert über Zugriffsmethoden der konkreten Subklassen.
• Typsicherheit im Protokoll-Stack: Die Zweiteilung zwischen Nicht-Stream-Typen (CRF, NTSCF) und Stream-Typen (AVTPDUCommonStreamHeaderFields und dessen Ableitungen) erzwingt auf C++-Typsystemebene, dass Stream-spezifische Header-Felder (wie z. B. 64-Bit-Stream-ID oder 32-Bit-AVTP-Timestamp) für Formate wie CRF oder NTSCF semantisch nicht aufgerufen werden können.
• Entwickler-Vertrag für High-Throughput-Applikationen:
  • Applikationen, die Rohvideo (RVF) oder Sensorsteuerungsströme (TSCF) verarbeiten, müssen gegen die konkreten Blattklassen programmieren.
  • Wegen hoher Latenzanforderungen sollten Instanzen dieser Klassen per Referenz oder Move-Semantik übergeben werden, um Allokationen im Fast-Path zu verhindern.