class ara::rds::IEEE1722DatagramAAF

In the Raw Data Stream module, the class is used for the structured representation of audio datagrams according to the IEEE 1722 AVTP Audio Format AUTOSAR_AP_SWS_RawDataStream p. 1. It encapsulates protocol-specific header data such as format, channel count, and bit depth in protected attributes, which are typically initialized and evaluated by derived data stream classes. A virtual destructor ensures that specialized datagram objects can be released polymorphically and exception-safely via base class pointers [SWS_RDS_90273]. Since no internal synchronization exists, concurrent accesses must be coordinated by the consuming streaming architecture.

more ›

Context

The class ara::rds::IEEE1722DatagramAAF provides the data representation of an IEEE 1722 datagram for the AVTP Audio Format (AAF) in the Raw Data Stream (rds) module of the AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_RawDataStream p. 1. The IEEE 1722 (Audio Video Transport Protocol, AVTP) standard serves for the time-synchronized transmission of time-critical audio and video data streams over Ethernet networks in automotive environments. The header file ara/rds/raw_data_stream_IEEE1722.h declares the structure within the namespace ara::rds.

The class is responsible for encapsulating the protocol-specific control and metadata fields of an AAF data frame. This includes the mandatory format field format [SWS_RDS_90262] as well as specifications of the number of data streams per frame via streams_per_frame [SWS_RDS_90263] and sp [SWS_RDS_90269], respectively. For flexible mapping of different audio formats and AES3 specifications, the class comprises optional attributes for sampling rates and frame rates such as nsr [SWS_RDS_90268] and nfr [SWS_RDS_90265], event identifiers evt [SWS_RDS_90264], channel information channels_per_frame [SWS_RDS_90267], bit depths bit_depth [SWS_RDS_90266], and AES3 data type and reference fields aes3_data_type_h [SWS_RDS_90270], aes3_data_type_l [SWS_RDS_90271], and aes3_dt_ref [SWS_RDS_90272].

Since all data fields are defined in the protected area (protected) and no public access methods are declared, the class is presumably intended primarily as an inheritance base for concrete, module-internally specialized datagram types and drivers. Question Q-f24c82b5fa9fbaaa (open) Interaction partners are the processing components of the RDS subsystem, which receive raw data streams from the network, parse them, or prepare them for transmission.

Lifecycle

Objects of ara::rds::IEEE1722DatagramAAF are typically created at runtime within the streaming pipeline as soon as a new audio data frame is received via Ethernet or assembled for transmission. Management and allocation are the responsibility of the higher-level data stream management of the RDS module or of a specialized derived class.

For controlled destruction, the class declares a virtual destructor ~IEEE1722DatagramAAF() noexcept [SWS_RDS_90273]. The virtual declaration ensures that derived classes are cleaned up completely and without errors when released via base class pointers, without leading to resource leaks. The noexcept specification guarantees that no exceptions are thrown during object destruction, which is essential particularly during stack unwinding in error scenarios.

With regard to concurrency, ara::rds::IEEE1722DatagramAAF does not provide internal synchronization of its own. Since audio streaming processing is often executed on separate real-time threads, concurrent read and write accesses must be coordinated by external synchronization mechanisms of the calling architecture.

Usage Path

The class is typically used via a specialized derived class that makes the protected attributes accessible for payload processing. A representative usage path comprises four consecutive phases:

1. Instantiation: The consuming component or audio driver instantiates a specialized datagram object, thereby creating the base class IEEE1722DatagramAAF.
2. Header initialization: The protected attributes are populated according to the specification of the data stream. The format format [SWS_RDS_90262] is defined, and attributes such as channels_per_frame [SWS_RDS_90267] and bit_depth [SWS_RDS_90266] are populated with values as ara::core::Optional. If an AES3 format is present, aes3_data_type_h [SWS_RDS_90270], aes3_data_type_l [SWS_RDS_90271], and aes3_dt_ref [SWS_RDS_90272] are also initialized.
3. Audio payload processing: The audio data stream is transmitted or decoded taking into account the configured header parameters.
4. Object destruction: After completion of the streaming process or after processing the packet, the object is released polymorphically via the virtual destructor ~IEEE1722DatagramAAF() [SWS_RDS_90273].

Sequence diagram: Typical sequence of instantiation, population of protected protocol fields, and destruction. Sources: [SWS_RDS_90262], [SWS_RDS_90266], [SWS_RDS_90273].

Error Scenarios

In the context of error handling and interface safety, two aspects in particular are decisive:

On the one hand, the encapsulation of optional header fields in ara::core::Optional (for example, in evt [SWS_RDS_90264], nfr [SWS_RDS_90265], or sp [SWS_RDS_90269]) requires an explicit check for presence prior to read access. Direct access to unset optional values leads to programming errors or runtime errors. Consuming software modules must therefore always check whether the respective field is validly set for the current data stream before evaluation.

On the other hand, specifying the destructor as noexcept ensures that no exceptions can escape during cleanup [SWS_RDS_90273]. If errors occur during the release of internal or derived resources, they must be caught locally within the destructor to prevent termination of the process by the C++ runtime environment.