Modul ara::rds — Raw Data Streams

Das adaptive Cluster Raw Data Stream (RDS) dient dem latenz- und durchsatzoptimierten Transfer unstrukturierter Datenströme sowie zeitkritischer Sensor- und Multimediadaten unter Umgehung serviceorientierter Serialisierungs-Overheads AUTOSAR_AP_EXP_SWArchitecture S. 74. Es stellt C++-APIs für IP-basierte Punkt-zu-Punkt-Byteströme (TCP/UDP) sowie für Layer-2-Streaming gemäß dem AVTP-Standard IEEE 1722 bereit [SWS_RDS_10482], [SWS_RDS_90312]. Beide Kommunikationsformen arbeiten strikt über statische Factory-Methoden und melden Fehler ressourcenschonend über das plattformweite Result-Konstrukt [SWS_RDS_12367].

mehr ›

Das funktionale Cluster Raw Data Stream (RDS) stellt hochperformante Schnittstellen zur Übertragung unformatierter Byteströme und zeitkritischer Sensordaten für die AUTOSAR Adaptive Platform bereit AUTOSAR_AP_EXP_SWArchitecture S. 73. Durch die direkte Abstraktion von POSIX-Netzwerk-Sockets sowie Layer-2-Ethernet-Schnittstellen umgeht RDS die aufwendige Serialisierung der standardmäßigen serviceorientierten Kommunikation (ara::com) AUTOSAR_AP_EXP_SWArchitecture S. 74.

Für IP-basierte Byteströme über TCP oder UDP nutzen Anwendungen die Klassen RawDataStreamClient und RawDataStreamServer, welche über statische Create-Methoden an modellierte Ports gebunden werden [SWS_RDS_10482], [SWS_RDS_11312]. Nach Verbindungsaufbau via Connect bzw. WaitForConnection werden Datenmengen ohne unnötige Speicherkopien mittels std::unique_ptr<ara::core::Byte[]> über ReadData und WriteData ausgetauscht [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11301].

Sequenzdiagramm: Verbindungsaufbau, Datenaustausch und Terminierung bei IP-basierten Raw Data Streams. Quellen: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322]

Für deterministische Echtzeitdatenströme von Kameras oder Audioquellen implementiert RDS Klassen nach IEEE 1722 (AVTP) wie IEEE1722RawDataStreamProducer und IEEE1722RawDataStreamConsumer [SWS_RDS_90312], [SWS_RDS_90323]. Spezifische Subtyp-Klassen wie RVF (Video), AAF (Audio) und CRF (Taktreferenz) kapseln hierbei standardkonforme Frame-Header und Nutzdaten [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295].

Fehler werden plattformkonform ohne C++-Exceptions über ara::core::Result und die Fehlerdomäne RdsErrorDomain mit spezifischen Fehlercodes (RdsErrc) signalisiert [SWS_RDS_11298], [SWS_RDS_12367]. Im AUTOSAR-Manifest wird die Schnittstellendefinition über RawDataStreamClientMapping und RawDataStreamServerMapping nahtlos an Ethernet-Endpunkte gebunden AUTOSAR_AP_TPS_ManifestSpecification S. 851.

mehr ›

Architektonische Einordnung und Systemgrenzen

Das funktionale Cluster Raw Data Stream (RDS) der AUTOSAR Adaptive Platform stellt standardisierte Programmierschnittstellen (APIs) für den hochperformanten Transfer unstrukturierter oder echtzeitkritischer Datenströme bereit AUTOSAR_AP_EXP_SWArchitecture S. 73. Im Gegensatz zur stark typisierten, serviceorientierten Kommunikation über ServiceInterfaces (wie SOME/IP oder DDS) umgeht RDS den Serialisierungs- und Protokoll-Overhead von ara::com vollständig AUTOSAR_AP_EXP_SWArchitecture S. 74. Dies ermöglicht die echtzeitfähige und durchsatzoptimierte Anbindung breitbandiger Sensorik wie Videokameras, Radar-, LiDAR-Sensoren oder Audiosystemen direkt an Adaptive Applications AUTOSAR_AP_EXP_SWArchitecture S. 61.

Architektonisch teilt sich das Modul in zwei fundamentale Kommunikationssäulen auf: Zum einen die IP-basierte Bytestrom-Übertragung über Transportprotokolle wie TCP oder UDP unter Kapselung von POSIX-Sockets und optionaler TLS-/IPsec-Absicherung AUTOSAR_SWS_CommunicationManagement S. 58. Zum anderen bietet das Modul ein spezialisiertes Subsystem für das Layer-2-Streaming nach IEEE 1722 (Audio Video Transport Protocol, AVTP) über Ethernet- und Time-Sensitive Networking (TSN)-Netzwerke AUTOSAR_AP_EXP_SWArchitecture S. 74. Beide Kommunikationsformen abstrahieren systemspezifische Netzwerk- und Pufferstrukturen hinter einheitlichen C++-Klassen im Namensraum ara::rds AUTOSAR_AP_SWS_RawDataStream S. 39.

Instanziierung und Verbindungsmanagement

Die Erzeugung von Kommunikationsendpunkten erfolgt bei RDS strikt über statische Factory-Methoden, die an modellierte Port-Instanzen gebunden sind [SWS_RDS_10482]. Für IP-basierte Byteströme kapseln die Klassen ara::rds::RawDataStreamClient und ara::rds::RawDataStreamServer die Rollen von Initiator und Listener AUTOSAR_AP_EXP_SWArchitecture S. 73. Die Factory RawDataStreamClient::Create instanziiert einen Client-Endpunkt für einen im Manifest definierten Port thread-sicher über einen ara::core::InstanceSpecifier [SWS_RDS_10482]. Analog erzeugt RawDataStreamServer::Create die zugehörige Server-Endpunktinstanz [SWS_RDS_11312]. Beide Klassen verbieten Kopierkonstruktoren und Kopierzuweisungen, unterstützen jedoch explizit Move-Semantiken für einen eindeutigen Ressourcenbesitz [SWS_RDS_11303], [SWS_RDS_11305], [SWS_RDS_11316], [SWS_RDS_11314].

Nach erfolgreicher Initialisierung wartet der Server über WaitForConnection blockierend oder mit einem spezifizierten Timeout auf eingehende Verbindungen [SWS_RDS_11318], [SWS_RDS_11319]. Der Client etabliert seinerseits die Verbindung aktiv mittels Connect, wahlweise unbeschränkt oder innerhalb einer Zeitspanne in Millisekunden [SWS_RDS_10484], [SWS_RDS_11307]. Das Beenden einer aktiven Sitzung geschieht entweder deterministisch durch den Aufruf von Shutdown [SWS_RDS_10485], [SWS_RDS_11320] oder implizit im Rahmen des Destruktor-Aufrufs, welcher eine noch offene Verbindung automatisch schließt und freigibt [SWS_RDS_10483], [SWS_RDS_11313].

Sequenzdiagramm: Verbindungsaufbau, bidirektionaler Datenaustausch und Terminierung zwischen RawDataStreamClient und RawDataStreamServer. Quellen: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322], [SWS_RDS_11324], AUTOSAR_AP_SWS_RawDataStream S. 10, AUTOSAR_AP_EXP_SWArchitecture S. 204, AUTOSAR_AP_EXP_SWArchitecture S. 222

Zustandsdiagramm: Lebenszyklus einer Raw-Data-Stream-Verbindung. Quellen: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10485], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11318], [SWS_RDS_11320]

Unstrukturierter IP-Datenaustausch über Sockets

Der Datentransfer für IP-Verbindungen ist bidirektional ausgelegt und erfolgt über synchron abwickelbare Operationen mit optionaler Timeout-Überwachung [SWS_RDS_10486], [SWS_RDS_11309]. Auf der Empfängerseite liefert die Operation ReadData eine Datenstruktur des Typs ara::rds::ReadDataResult zurück [SWS_RDS_10486], [SWS_RDS_11322]. Diese Struktur kapselt die gelesenen Binärdaten in Form eines Smart-Pointers data (std::unique_ptr<ara::core::Byte[]>) und gibt über das Feld numberOfBytes die tatsächliche Anzahl der empfangenen Bytes an [SWS_RDS_11301], [SWS_RDS_11302]. Durch diese Übergabe des Pufferbesitzes werden unnötige Speicherkopien vermieden.

Für das Senden von Binärdaten übergeben Anwendungen den Bytepuffer ebenfalls mittels Move-Semantik über einen std::unique_ptr<ara::core::Byte[]> und spezifizieren die Maximallänge maxLength in WriteData [SWS_RDS_10487], [SWS_RDS_11324]. Bei latenzkritischen oder blockierungsgefährdeten Netzwerkpfaden stehen überladene Varianten von ReadData und WriteData mit expliziter Timeout-Angabe in Millisekunden zur Verfügung [SWS_RDS_11310], [SWS_RDS_11323], [SWS_RDS_11325]. Damit können ausbleibende Gegenstellen oder stockende Netzwerkpuffer deterministisch abgefangen werden AUTOSAR_AP_EXP_InterfacesGuidelines S. 41.

Echtzeitnahes Streaming mit IEEE 1722 (AVTP)

Für deterministische, isochrone Multimedia- und Sensorströme stellt RDS spezialisierte Template-Klassen für Konsumenten und Produzenten nach IEEE 1722 bereit [SWS_RDS_90312], [SWS_RDS_90323]. Die Klasse ara::rds::IEEE1722RawDataStreamConsumer<T> agiert als Datensenke und wird über Create instanziiert [SWS_RDS_90312]. Mittels Connect bindet sie sich an den zugeordneten Stream (unter Filterung von Multicast-MAC, VLAN und Stream-ID) AUTOSAR_AP_EXP_SWArchitecture S. 203, um anschließend über ReadData bis zu maxNumberOfDatagrams strukturierte Datagramme als std::vector<T> auszulesen [SWS_RDS_90319], [SWS_RDS_90321]. Analog übernimmt ara::rds::IEEE1722RawDataStreamProducer<T> die Erzeugung und das Absenden von AVTP-Frames über WriteData(std::vector<T>) [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90332].

Die Datagramm-Typen bilden eine standardisierte objektorientierte Vererbungshierarchie AUTOSAR_AP_SWS_RawDataStream S. 39. Basis aller Frames ist IEEE1722Datagram mit Nutzdatenfeld data und Längenangabe stream_data_length [SWS_RDS_90226], [SWS_RDS_90227], [SWS_RDS_90228]. Davon abgeleitet kapselt IEEE1722DatagramAVTPDUCommonHeaderFields allgemeine Header-Informationen wie avtpStreamDataSubtype, headerSpecific und Protokoll-version [SWS_RDS_90230], [SWS_RDS_90231], [SWS_RDS_90232], gefolgt von IEEE1722DatagramAVTPDUCommonStreamHeaderFields mit Zeitstempeln (avtp_timestamp), Stream-Identifikation (unique_id, mac_address) und Paketfolgenummern (sequenceNum) [SWS_RDS_90235], [SWS_RDS_90237], [SWS_RDS_90240].

Auf dieser gemeinsamen Basis setzen konkrete Subtyp-Spezialisierungen auf: IEEE1722DatagramRVF für Rohvideodaten mit Pixelparametern, Bildwiederholrate und Zeileninformationen (pixel_format, pixel_depth, frame_rate, colorspace, total_lines) [SWS_RDS_90276], [SWS_RDS_90278], [SWS_RDS_90285], [SWS_RDS_90286], [SWS_RDS_90287]; IEEE1722DatagramAAF für Audioformate wie PCM oder AES3 (channels_per_frame, bit_depth, aes3_data_type_h) [SWS_RDS_90262], [SWS_RDS_90266], [SWS_RDS_90267], [SWS_RDS_90270]; IEEE1722DatagramCRF zur Taktsynchronisation und Taktübertragung über TSN (base_frequency, timestamp_interval, pull) [SWS_RDS_90295], [SWS_RDS_90297], [SWS_RDS_90302], [SWS_RDS_90303]; sowie IEEE1722Datagram61883_IIDC für industrielle Kameratransporte [SWS_RDS_90245], [SWS_RDS_90260] und IEEE1722DatagramNTSCF für nicht-zeitkritische Steuerformate [SWS_RDS_90306], [SWS_RDS_90310].

Sequenzdiagramm: Interaktionszyklus für IEEE 1722 Audio/Video Streaming (Producer und Consumer). Quellen: [SWS_RDS_90312], [SWS_RDS_90319], [SWS_RDS_90320], [SWS_RDS_90321], [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90331], [SWS_RDS_90332], AUTOSAR_AP_EXP_SWArchitecture S. 203, AUTOSAR_AP_EXP_SWArchitecture S. 221

Klassendiagramm: Vererbungshierarchie der IEEE 1722 Datagramme im Subsystem ara::rds. Quellen: [SWS_RDS_90226], [SWS_RDS_90230], [SWS_RDS_90235], [SWS_RDS_90245], [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295], [SWS_RDS_90306], AUTOSAR_AP_SWS_RawDataStream S. 39

Metamodellierung und Manifest-Deployment

Im AUTOSAR-Manifest-Metamodell wird die Trennung von Anwendungsentwurf und plattformspezifischem Deployment gewahrt AUTOSAR_AP_TPS_ManifestSpecification S. 254. Das abstrakte Basiselement AbstractRawDataStreamInterface spezialisiert PortInterface und verzweigt in die konkreten Schnittstellen RawDataStreamClientInterface und RawDataStreamServerInterface AUTOSAR_AP_TPS_ManifestSpecification S. 254. Auf der Deployment-Ebene verknüpft ein EthernetRawDataStreamClientMapping bzw. EthernetRawDataStreamServerMapping die Software-Ports mit physischen Kommunikationsendpunkten wie ApApplicationEndpoint, IP-Adressen und Portnummern AUTOSAR_AP_TPS_ManifestSpecification S. 851, TPS_ManifestSpecification S. 850.

Das Manifest gestattet flexible Integrationsszenarien für die Systemtopologie: Sowohl voll formalisierte AUTOSAR-Modelle, bei denen Client und Server innerhalb desselben ARXML-Designs verknüpft sind AUTOSAR_TPS_ManifestSpecification S. 656, als auch asymmetrische Konfigurationen. In diesen asymmetrischen Szenarien ist entweder nur der Client oder nur der Server im Modell modelliert, während die jeweilige Gegenstelle über statische Credentials wie remoteServerConfig oder remoteClientConfig angebunden wird AUTOSAR_TPS_ManifestSpecification S. 660, AUTOSAR_TPS_ManifestSpecification S. 661. Für AVTP-Ströme bindet das EthernetMacRawDataStreamMapping Ports und Prozesse direkt an MAC-Endpunkte und VLAN-Priorisierungen an AUTOSAR_AP_TPS_ManifestSpecification S. 854, korrespondierend zu den System-Template-Definitionen IEEE1722TpConnection, IEEE1722TpAvConnection, IEEE1722TpAafConnection und IEEE1722TpRvfConnection AUTOSAR_CP_TPS_SystemTemplate S. 705, AUTOSAR_CP_TPS_SystemTemplate S. 708, AUTOSAR_CP_TPS_SystemTemplate S. 716.

Kontextdiagramm: AUTOSAR Metamodell-Beziehungen zwischen Port-Interface, Mapping und Transport-Deployment. Quellen: [SWS_RDS_10482], [SWS_RDS_11312], AUTOSAR_AP_TPS_ManifestSpecification S. 254, AUTOSAR_AP_TPS_ManifestSpecification S. 851, TPS_ManifestSpecification S. 850

Verhalten im Fehlerfall

Die Fehlerbehandlung in RDS folgt dem fehlerauswertenden Ansatz der AUTOSAR Adaptive Platform über ara::core::Result und ara::core::ErrorCode [SWS_RDS_10484], [SWS_RDS_11299]. Alle potenziell fehlschlagenden API-Methoden – darunter Create, Connect, WaitForConnection, ReadData und WriteData – sind als noexcept deklariert und melden Fehlercodes über den Rückgabetyp ara::core::Result zurück [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_11318]. Die modulspezifischen Fehlerzustände werden in der Enumeration ara::rds::RdsErrc verwaltet [SWS_RDS_12367], welche über den Typ-Alias ara::rds::RdsErrorDomain::Errc referenziert werden kann [SWS_RDS_11326].

Das Modul definiert hierfür die Fehlerdomäne RdsErrorDomain, deren Instanz über GetRdsErrorDomain() abgerufen wird [SWS_RDS_11298]. Die Standardkonstruktion von RdsErrorDomain ist explizit gelöscht [SWS_RDS_11294]. Fehlerbeschreibungen und der Domänenname lassen sich über die virtuellen Methoden Message(CodeType) und Name() auslesen [SWS_RDS_11295], [SWS_RDS_11296]. Die Fabrikfunktion MakeErrorCode gestattet die Erzeugung typisierter Fehlerobjekte aus einem RdsErrc-Code und Zusatzdaten [SWS_RDS_11299]. Für Umgebungen, in denen C++-Ausnahmen aktiviert sind, stellt das Modul die Ausnahme ara::rds::RdsException bereit [SWS_RDS_11292], [SWS_RDS_11327], welche über RdsErrorDomain::ThrowAsException ausgelöst werden kann [SWS_RDS_11297].

Weiterführende Detailbelege

Die Architektur und die Schnittstellen von RDS sind in den zentralen Spezifikationsdokumenten von AUTOSAR verankert. Die funktionale Definition der C++-Schnittstellen für IP-basierte Streams und Fehlermechanismen stützt sich auf AUTOSAR_AP_SWS_RawDataStream [SWS_RDS_10482], [SWS_RDS_11312], [SWS_RDS_12367]. Die Architekturmodelle, Klassenentwürfe und Sequenzszenarien für IEEE-1722-Streaming sind in AUTOSAR_AP_EXP_SWArchitecture dokumentiert AUTOSAR_AP_EXP_SWArchitecture S. 74, AUTOSAR_AP_EXP_SWArchitecture S. 203, AUTOSAR_AP_EXP_SWArchitecture S. 221. Die formale Modellierung der Schnittstellen und des Deployments erfolgt über AUTOSAR_AP_TPS_ManifestSpecification AUTOSAR_AP_TPS_ManifestSpecification S. 254, AUTOSAR_AP_TPS_ManifestSpecification S. 851 sowie die zugrundeliegenden Systemvorlagen für Ethernet-Transportverbindungen in AUTOSAR_CP_TPS_SystemTemplate AUTOSAR_CP_TPS_SystemTemplate S. 705.