module ara::rds — Raw Data Streams

The Raw Data Stream (RDS) adaptive cluster serves the latency- and throughput-optimized transfer of unstructured data streams as well as time-critical sensor and multimedia data while bypassing service-oriented serialization overheads AUTOSAR_AP_EXP_SWArchitecture p. 74. It provides C++ APIs for IP-based point-to-point byte streams (TCP/UDP) as well as for Layer 2 streaming according to the AVTP standard IEEE 1722 [SWS_RDS_10482], [SWS_RDS_90312]. Both forms of communication operate strictly via static factory methods and report errors in a resource-efficient manner via the platform-wide Result construct [SWS_RDS_12367].

more ›

The Raw Data Stream (RDS) functional cluster provides high-performance interfaces for transmitting unformatted byte streams and time-critical sensor data for the AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_SWArchitecture p. 73. By directly abstracting POSIX network sockets as well as Layer 2 Ethernet interfaces, RDS bypasses the computationally expensive serialization of standard service-oriented communication (ara::com) AUTOSAR_AP_EXP_SWArchitecture p. 74.

For IP-based byte streams via TCP or UDP, applications use the classes RawDataStreamClient and RawDataStreamServer, which are bound to modeled ports via static Create methods [SWS_RDS_10482], [SWS_RDS_11312]. After establishing a connection via Connect or WaitForConnection, data volumes are exchanged without unnecessary memory copies using std::unique_ptr<ara::core::Byte[]> via ReadData and WriteData [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11301].

Sequence diagram: Connection establishment, data exchange, and termination for IP-based raw data streams. Sources: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322]

For deterministic real-time data streams from cameras or audio sources, RDS implements classes according to IEEE 1722 (AVTP) such as IEEE1722RawDataStreamProducer and IEEE1722RawDataStreamConsumer [SWS_RDS_90312], [SWS_RDS_90323]. Specific subtype classes such as RVF (video), AAF (audio), and CRF (clock reference) encapsulate standard-compliant frame headers and payload data [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295].

Errors are signaled in a platform-compliant manner without C++ exceptions via ara::core::Result and the error domain RdsErrorDomain with specific error codes (RdsErrc) [SWS_RDS_11298], [SWS_RDS_12367]. In the AUTOSAR manifest, the interface definition is seamlessly bound to Ethernet endpoints via RawDataStreamClientMapping and RawDataStreamServerMapping AUTOSAR_AP_TPS_ManifestSpecification p. 851.

more ›

Architectural Classification and System Boundaries

The Raw Data Stream (RDS) functional cluster of the AUTOSAR Adaptive Platform provides standardized application programming interfaces (APIs) for the high-performance transfer of unstructured or real-time critical data streams AUTOSAR_AP_EXP_SWArchitecture p. 73. In contrast to strongly typed, service-oriented communication via ServiceInterfaces (such as SOME/IP or DDS), RDS completely bypasses the serialization and protocol overhead of ara::com AUTOSAR_AP_EXP_SWArchitecture p. 74. This enables the real-time-capable and throughput-optimized connection of broadband sensors such as video cameras, radar, LiDAR sensors, or audio systems directly to Adaptive Applications AUTOSAR_AP_EXP_SWArchitecture p. 61.

Architecturally, the module is divided into two fundamental communication pillars: First, IP-based byte stream transmission via transport protocols such as TCP or UDP, encapsulating POSIX sockets and optional TLS/IPsec protection AUTOSAR_SWS_CommunicationManagement p. 58. Second, the module offers a specialized subsystem for Layer 2 streaming according to IEEE 1722 (Audio Video Transport Protocol, AVTP) over Ethernet and Time-Sensitive Networking (TSN) networks AUTOSAR_AP_EXP_SWArchitecture p. 74. Both communication forms abstract system-specific network and buffer structures behind uniform C++ classes in the namespace ara::rds AUTOSAR_AP_SWS_RawDataStream p. 39.

Instantiation and Connection Management

In RDS, communication endpoints are created strictly via static factory methods bound to modeled port instances [SWS_RDS_10482]. For IP-based byte streams, the classes ara::rds::RawDataStreamClient and ara::rds::RawDataStreamServer encapsulate the roles of initiator and listener AUTOSAR_AP_EXP_SWArchitecture p. 73. The factory RawDataStreamClient::Create instantiates a client endpoint for a port defined in the manifest in a thread-safe manner via a ara::core::InstanceSpecifier [SWS_RDS_10482]. Similarly, RawDataStreamServer::Create creates the associated server endpoint instance [SWS_RDS_11312]. Both classes forbid copy constructors and copy assignment operators, but explicitly support move semantics for unambiguous resource ownership [SWS_RDS_11303], [SWS_RDS_11305], [SWS_RDS_11316], [SWS_RDS_11314].

After successful initialization, the server waits for incoming connections via WaitForConnection in a blocking manner or with a specified timeout [SWS_RDS_11318], [SWS_RDS_11319]. The client, for its part, actively establishes the connection using Connect, optionally without limitation or within a time span in milliseconds [SWS_RDS_10484], [SWS_RDS_11307]. Terminating an active session occurs either deterministically by calling Shutdown [SWS_RDS_10485], [SWS_RDS_11320] or implicitly during the destructor call, which automatically closes and releases a connection that is still open [SWS_RDS_10483], [SWS_RDS_11313].

Sequence diagram: Connection establishment, bidirectional data exchange, and termination between RawDataStreamClient and RawDataStreamServer. Sources: [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 p. 10, AUTOSAR_AP_EXP_SWArchitecture p. 204, AUTOSAR_AP_EXP_SWArchitecture p. 222

State diagram: Lifecycle of a Raw Data Stream connection. Sources: [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10485], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11318], [SWS_RDS_11320]

Unstructured IP Data Exchange via Sockets

Data transfer for IP connections is designed to be bidirectional and takes place via operations that can be processed synchronously with optional timeout monitoring [SWS_RDS_10486], [SWS_RDS_11309]. On the receiver side, the operation ReadData returns a data structure of type ara::rds::ReadDataResult [SWS_RDS_10486], [SWS_RDS_11322]. This structure encapsulates the read binary data in the form of a smart pointer data (std::unique_ptr<ara::core::Byte[]>) and indicates the actual number of received bytes via the field numberOfBytes [SWS_RDS_11301], [SWS_RDS_11302]. This transfer of buffer ownership avoids unnecessary memory copies.

For transmitting binary data, applications likewise pass the byte buffer using move semantics via a std::unique_ptr<ara::core::Byte[]> and specify the maximum length maxLength in WriteData [SWS_RDS_10487], [SWS_RDS_11324]. For latency-critical network paths or those at risk of blocking, overloaded variants of ReadData and WriteData with an explicit timeout specification in milliseconds are available [SWS_RDS_11310], [SWS_RDS_11323], [SWS_RDS_11325]. This allows non-responsive peers or stalled network buffers to be handled deterministically AUTOSAR_AP_EXP_InterfacesGuidelines p. 41.

Near-Real-Time Streaming with IEEE 1722 (AVTP)

For deterministic, isochronous multimedia and sensor streams, RDS provides specialized template classes for consumers and producers according to IEEE 1722 [SWS_RDS_90312], [SWS_RDS_90323]. The class ara::rds::IEEE1722RawDataStreamConsumer<T> acts as a data sink and is instantiated via Create [SWS_RDS_90312]. Using Connect, it binds to the assigned stream (filtering multicast MAC, VLAN, and stream ID) AUTOSAR_AP_EXP_SWArchitecture p. 203 in order to subsequently read up to maxNumberOfDatagrams structured datagrams as std::vector<T> via ReadData [SWS_RDS_90319], [SWS_RDS_90321]. Analogously, ara::rds::IEEE1722RawDataStreamProducer<T> handles the creation and sending of AVTP frames via WriteData(std::vector<T>) [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90332].

The datagram types form a standardized object-oriented inheritance hierarchy AUTOSAR_AP_SWS_RawDataStream p. 39. The base of all frames is IEEE1722Datagram with payload data field data and length specification stream_data_length [SWS_RDS_90226], [SWS_RDS_90227], [SWS_RDS_90228]. Derived from this, IEEE1722DatagramAVTPDUCommonHeaderFields encapsulates general header information such as avtpStreamDataSubtype, headerSpecific, and protocol version [SWS_RDS_90230], [SWS_RDS_90231], [SWS_RDS_90232], followed by IEEE1722DatagramAVTPDUCommonStreamHeaderFields with timestamps (avtp_timestamp), stream identification (unique_id, mac_address), and packet sequence numbers (sequenceNum) [SWS_RDS_90235], [SWS_RDS_90237], [SWS_RDS_90240].

Concrete subtype specializations build upon this common base: IEEE1722DatagramRVF for raw video data with pixel parameters, frame rate, and line information (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 for audio formats such as PCM or AES3 (channels_per_frame, bit_depth, aes3_data_type_h) [SWS_RDS_90262], [SWS_RDS_90266], [SWS_RDS_90267], [SWS_RDS_90270]; IEEE1722DatagramCRF for clock synchronization and clock transmission over TSN (base_frequency, timestamp_interval, pull) [SWS_RDS_90295], [SWS_RDS_90297], [SWS_RDS_90302], [SWS_RDS_90303]; as well as IEEE1722Datagram61883_IIDC for industrial camera transport [SWS_RDS_90245], [SWS_RDS_90260] and IEEE1722DatagramNTSCF for non-time-critical control formats [SWS_RDS_90306], [SWS_RDS_90310].

Sequence diagram: Interaction cycle for IEEE 1722 audio/video streaming (producer and consumer). Sources: [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 p. 203, AUTOSAR_AP_EXP_SWArchitecture p. 221

Class diagram: Inheritance hierarchy of the IEEE 1722 datagrams in the ara::rds subsystem. Sources: [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 p. 39

Metamodeling and Manifest Deployment

In the AUTOSAR manifest metamodel, the separation between application design and platform-specific deployment is maintained AUTOSAR_AP_TPS_ManifestSpecification p. 254. The abstract base element AbstractRawDataStreamInterface specializes PortInterface and branches into the concrete interfaces RawDataStreamClientInterface and RawDataStreamServerInterface AUTOSAR_AP_TPS_ManifestSpecification p. 254. At the deployment level, a EthernetRawDataStreamClientMapping or EthernetRawDataStreamServerMapping links the software ports to physical communication endpoints such as ApApplicationEndpoint, IP addresses, and port numbers AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850.

The manifest permits flexible integration scenarios for the system topology: both fully formalized AUTOSAR models, where client and server are connected within the same ARXML design AUTOSAR_TPS_ManifestSpecification p. 656, and asymmetrical configurations. In these asymmetrical scenarios, either only the client or only the server is modeled in the design, while the respective peer is connected via static credentials such as remoteServerConfig or remoteClientConfig AUTOSAR_TPS_ManifestSpecification p. 660, AUTOSAR_TPS_ManifestSpecification p. 661. For AVTP streams, the EthernetMacRawDataStreamMapping directly binds ports and processes to MAC endpoints and VLAN prioritizations AUTOSAR_AP_TPS_ManifestSpecification p. 854, corresponding to the system template definitions IEEE1722TpConnection, IEEE1722TpAvConnection, IEEE1722TpAafConnection, and IEEE1722TpRvfConnection AUTOSAR_CP_TPS_SystemTemplate p. 705, AUTOSAR_CP_TPS_SystemTemplate p. 708, AUTOSAR_CP_TPS_SystemTemplate p. 716.

Context diagram: AUTOSAR metamodel relationships between port interface, mapping, and transport deployment. Sources: [SWS_RDS_10482], [SWS_RDS_11312], AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850

Behavior in the event of an error

Error handling in RDS follows the error-evaluating approach of the AUTOSAR Adaptive Platform via ara::core::Result and ara::core::ErrorCode [SWS_RDS_10484], [SWS_RDS_11299]. All potentially failing API methods—including Create, Connect, WaitForConnection, ReadData, and WriteData—are declared as noexcept and return error codes via the return type ara::core::Result [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_11318]. The module-specific error states are managed in the enumeration ara::rds::RdsErrc [SWS_RDS_12367], which can be referenced via the type alias ara::rds::RdsErrorDomain::Errc [SWS_RDS_11326].

For this purpose, the module defines the error domain RdsErrorDomain, whose instance is retrieved via GetRdsErrorDomain() [SWS_RDS_11298]. The default construction of RdsErrorDomain is explicitly deleted [SWS_RDS_11294]. Error descriptions and the domain name can be read via the virtual methods Message(CodeType) and Name() [SWS_RDS_11295], [SWS_RDS_11296]. The factory function MakeErrorCode allows typed error objects to be created from a RdsErrc code and supplementary data [SWS_RDS_11299]. For environments where C++ exceptions are enabled, the module provides the exception ara::rds::RdsException [SWS_RDS_11292], [SWS_RDS_11327], which can be thrown via RdsErrorDomain::ThrowAsException [SWS_RDS_11297].

Further detailed evidence

The architecture and interfaces of RDS are anchored in the central specification documents of AUTOSAR. The functional definition of the C++ interfaces for IP-based streams and error mechanisms relies on AUTOSAR_AP_SWS_RawDataStream [SWS_RDS_10482], [SWS_RDS_11312], [SWS_RDS_12367]. The architectural models, class designs, and sequence scenarios for IEEE 1722 streaming are documented in AUTOSAR_AP_EXP_SWArchitecture AUTOSAR_AP_EXP_SWArchitecture p. 74, AUTOSAR_AP_EXP_SWArchitecture p. 203, AUTOSAR_AP_EXP_SWArchitecture p. 221. The formal modeling of the interfaces and the deployment takes place via AUTOSAR_AP_TPS_ManifestSpecification AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851 as well as the underlying system templates for Ethernet transport connections in AUTOSAR_CP_TPS_SystemTemplate AUTOSAR_CP_TPS_SystemTemplate p. 705.