Dient der Repräsentation von IEEE-1722-Audio-Datagrammen mit geschützten Kopfdatenfeldern und virtuellem Destruktor.
Kontext
Die Klasse ara::rds::IEEE1722DatagramAAF stellt im Modul Raw Data Stream (rds) der AUTOSAR Adaptive Platform die datentechnische Abbildung eines IEEE-1722-Datagramms für das AVTP Audio Format (AAF) bereit AUTOSAR_AP_SWS_RawDataStream S. 1. Der Standard IEEE 1722 (Audio Video Transport Protocol, AVTP) dient der zeitsynchronen Übertragung zeitkritischer Audio- und Videodatenströme über Ethernet-Netzwerke in Automobilumgebungen. Die Header-Datei ara/rds/raw_data_stream_IEEE1722.h deklariert die Struktur innerhalb des Namensraums ara::rds.
Verantwortlich ist die Klasse für die Kapselung der protokollspezifischen Steuer- und Metadatenfelder eines AAF-Datenrahmens. Hierzu zählt das obligatorische Formatfeld format [SWS_RDS_90262] sowie Angaben zur Anzahl der Datenströme pro Rahmen über streams_per_frame [SWS_RDS_90263] beziehungsweise sp [SWS_RDS_90269]. Zur flexiblen Abbildung unterschiedlicher Audioformate und AES3-Spezifikationen umfasst die Klasse optionale Attribute für Abtastraten und Frame-Raten wie nsr [SWS_RDS_90268] und nfr [SWS_RDS_90265], Ereigniskennungen evt [SWS_RDS_90264], Kanalinformationen channels_per_frame [SWS_RDS_90267], Bittiefen bit_depth [SWS_RDS_90266] sowie AES3-Datentyp- und Referenzfelder aes3_data_type_h [SWS_RDS_90270], aes3_data_type_l [SWS_RDS_90271] und aes3_dt_ref [SWS_RDS_90272].
Da sämtliche Datenfelder im geschützten Bereich (protected) definiert sind und keine öffentlichen Zugriffsmethoden deklariert werden, dürfte die Klasse primär als Vererbungsbasis für konkrete, modulintern spezialisierte Datagrammtypen und Treiber dienen. Frage Q-f24c82b5fa9fbaaa (offen) Interaktionspartner sind die verarbeitenden Komponenten des RDS-Subsystems, welche Rohdatenströme aus dem Netzwerk empfangen, parsen oder für den Versand vorbereiten.
Lebenszyklus
Objekte von ara::rds::IEEE1722DatagramAAF werden zur Laufzeit typischerweise im Zuge der Streaming-Pipeline erzeugt, sobald ein neuer Audio-Datenrahmen über Ethernet empfangen oder zur Übertragung zusammengestellt wird. Die Verwaltung und Allokation obliegt der übergeordneten Datenstromverwaltung des RDS-Moduls oder einer spezialisierten abgeleiteten Klasse.
Für die kontrollierte Zerstörung deklariert die Klasse einen virtuellen Destruktor ~IEEE1722DatagramAAF() noexcept [SWS_RDS_90273]. Die virtuelle Deklaration stellt sicher, dass abgeleitete Klassen bei der Freigabe über Basisklassenzeiger vollständig und fehlerfrei bereinigt werden, ohne dass es zu Ressourcenlecks kommt. Durch die noexcept-Spezifikation wird garantiert, dass bei der Objektauflösung keine Ausnahmen ausgelöst werden, was insbesondere bei der Rückabwicklung im Fehlerfall (Stack Unwinding) unerlässlich ist.
Hinsichtlich der Nebenläufigkeit bietet ara::rds::IEEE1722DatagramAAF keine eigene interne Synchronisation. Da Audio-Streaming-Verarbeitungen häufig auf separaten Echtzeit-Threads ausgeführt werden, müssen gleichzeitige Lese- und Schreibzugriffe durch externe Synchronisationsmechanismen der aufrufenden Architektur koordiniert werden.
Nutzungspfad
Der typische Einsatz der Klasse erfolgt über eine spezialisierte Ableitung, welche die geschützten Attribute für die Nutzdatenverarbeitung zugänglich macht. Ein repräsentativer Nutzungspfad umfasst vier aufeinanderfolgende Phasen:
- Instanziierung: Die anwendende Komponente oder der Audio-Treiber instanziiert ein spezialisiertes Datagramm-Objekt, wodurch die Basisklasse
IEEE1722DatagramAAF erzeugt wird.
- Header-Initialisierung: Die geschützten Attribute werden gemäß der Spezifikation des Datenstroms belegt. Das Format
format [SWS_RDS_90262] wird festgelegt, und Attribute wie channels_per_frame [SWS_RDS_90267] sowie bit_depth [SWS_RDS_90266] werden als ara::core::Optional mit Werten belegt. Sofern ein AES3-Format vorliegt, werden auch aes3_data_type_h [SWS_RDS_90270], aes3_data_type_l [SWS_RDS_90271] und aes3_dt_ref [SWS_RDS_90272] initialisiert.
- Verarbeitung der Audio-Payload: Der Audiodatenstrom wird unter Berücksichtigung der konfigurierten Header-Parameter übertragen oder dekodiert.
- Objektzerstörung: Nach Abschluss des Streaming-Vorgangs oder nach Verarbeitung des Pakets wird das Objekt polymorph über den virtuellen Destruktor
~IEEE1722DatagramAAF() freigegeben [SWS_RDS_90273].
Sequenzdiagramm: Typische Abfolge von Instanziierung, Belegung der geschützten Protokollfelder und Zerstörung. Quellen: [SWS_RDS_90262], [SWS_RDS_90266], [SWS_RDS_90273].
Fehlerszenarien
Im Rahmen der Fehlerbehandlung und Schnittstellensicherheit sind insbesondere zwei Aspekte maßgeblich:
Zum einen erfordert die Kapselung optionaler Headerfelder in ara::core::Optional (beispielsweise bei evt [SWS_RDS_90264], nfr [SWS_RDS_90265] oder sp [SWS_RDS_90269]) eine explizite Prüfung des Vorhandenseins vor dem lesenden Zugriff. Ein direkter Zugriff auf nicht gesetzte optionale Werte führt zu Programmierfehlern oder Laufzeitfehlern. Konsumierende Softwaremodule müssen daher vor der Auswertung stets prüfen, ob das jeweilige Feld für den aktuellen Datenstrom gültig gesetzt ist.
Zum anderen stellt die Spezifikation des Destruktors als noexcept sicher, dass während der Bereinigung keine Ausnahmen entweichen können [SWS_RDS_90273]. Sollten bei der Freigabe interner oder abgeleiteter Ressourcen Fehler auftreten, müssen diese zwingend lokal innerhalb des Destruktors abgefangen werden, um eine Terminierung des Prozesses durch die C++-Laufzeitumgebung zu verhindern.
Dieser Leitfaden wurde durch eine KI auf Basis der Spezifikationsunterlagen zu AUTOSAR Adaptive R25-11 generiert.
gemini-3.8-flash-medium· 2026-10-13