Defines the common AVTPDU header fields for IEEE 1722 datagrams in the Raw Data Stream module.
Context
In the AUTOSAR Adaptive Platform, the module Raw Data Stream (RDS) provides mechanisms for the efficient exchange of unstructured data streams and standardized streaming protocols. The class ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields serves within this module as a fundamental representation of the common header fields of Audio/Video Transport Protocol Data Units (AVTPDUs) according to IEEE 1722, as specified in SWS RawDataStream §1 “IEEE 1722 Datagram”.
The structure encapsulates the essential protocol fields defined for AVTPDU datagrams in the IEEE 1722 standard. This includes the attribute version of type std::uint8_t ([SWS_RDS_90232]), which represents the protocol version of the AVTP standard. Furthermore, the data field avtpStreamDataSubtype of type std::uint16_t ([SWS_RDS_90230]) accommodates the subtype of the AVTP streaming payload in order to identify the specific format of the transported data streams. In addition, the element headerSpecific stores protocol- and format-specific control bits and flags of the AVTPDU header as std::uint8_t ([SWS_RDS_90231]).
All payload data fields of the class are declared under the access modifier protected. From this arises the interpretation that ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields is presumably designed primarily as a fundamental base class for specialized IEEE 1722 datagram classes within the RDS module, rather than being instantiated directly by users as an independent value object. Question Q-674fc96343869829 (open)
Lifecycle
The lifecycle of ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields aligns with its role as a fundamental header structure. Instantiation occurs in conjunction with a concrete specialization that inherits from this base class. The assignment and initialization of the protected attributes version ([SWS_RDS_90232]), avtpStreamDataSubtype ([SWS_RDS_90230]), and headerSpecific ([SWS_RDS_90231]) is usually performed in the constructor of the derived class.
For the destruction of instances, the specification explicitly provides a virtual destructor: ~IEEE1722DatagramAVTPDUCommonHeaderFields() noexcept ([SWS_RDS_90233]). The presence of this virtual destructor ensures that derived datagram objects can be safely destroyed polymorphically via pointers or references to the base class without undefined behavior or resource leaks occurring. The specifier noexcept contractually guarantees that no exceptions can be thrown during the destruction process.
Regarding ownership and memory management, the class is subject to the general conventions for data transfer objects in the RDS module: Instances are typically either kept on the stack of a processing function or managed by higher-level data buffers and stream handlers. With regard to concurrency, the data structure does not offer any internal synchronization mechanisms. Interpretation: Concurrent access by multiple threads to the same instance therefore presumably requires external synchronization by the calling application or the surrounding runtime system. Question (open)
Usage Path
The typical usage path is divided into the creation, population, and evaluation of datagrams within streaming connections. Because the fields are protected, developers access the base fields via specialized subclasses.
When sending an IEEE 1722 data stream, the application or an internal pipeline of the RDS module instantiates a derived datagram class. Subsequently, the common AVTPDU header fields are populated: The field version ([SWS_RDS_90232]) is set to the respective supported protocol version level. The field avtpStreamDataSubtype ([SWS_RDS_90230]) is provided with the identification value of the specific payload type to enable the receiver to decode the data stream. Finally, the derived implementation configures the field headerSpecific ([SWS_RDS_90231]) with the required control bits according to the IEEE 1722 specification.
When receiving network packets via the Raw Data Stream, the reverse sequence takes place: Incoming raw data is deserialized and transferred to the corresponding attributes of the derived datagram class. Higher-level components can then check the header information via polymorphic interfaces or typed access methods of the subclass. After successful processing and forwarding of the AVTPDU payload to the target sink, the datagram is released, with the virtual destructor ([SWS_RDS_90233]) ensuring the clean release of all resources. Interpretation: Serialized transmission over the network presumably occurs via downstream serializers of the RDS stack that arrange the header in the byte stream conformant to IEEE 1722. Question Q-7f31ac02b5e4facf (open)
Error Scenarios
Error scenarios when working with ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields result primarily from erroneous values in the header fields or improper lifecycle management.
At the data element level, invalid values can lead to protocol violations. For example, if a version value not supported by the peer is passed for version ([SWS_RDS_90232]), this can lead to the discarding of the entire AVTPDU by the communication partner. Likewise, an incorrectly set field avtpStreamDataSubtype ([SWS_RDS_90230]) leads to the receiver being unable to correctly assign the data stream to the appropriate decoder. An inconsistent assignment of headerSpecific ([SWS_RDS_90231]) can in turn result in misinterpretations regarding synchronization flags or data lengths.
At the C++ level, the virtual destructor ~IEEE1722DatagramAVTPDUCommonHeaderFields() noexcept ([SWS_RDS_90233]) precludes exceptions during the destruction process. If a derived class executes custom error handling logic during resource release, it must be ensured that no exceptions are thrown there either, in order to prevent immediate program termination via std::terminate.
This guide is based on the AUTOSAR Adaptive R25-11 specification and was generated automatically.
gemini-3.8-flash-low· 2026-10-13 · German original