class ara::rds::IEEE1722DatagramCRF

In the rds module, the class serves as a representation for Clock Reference Format datagrams according to the IEEE 1722 standard AUTOSAR_AP_SWS_RawDataStream p. 1. It encapsulates protocol-specific header and clock information in protected, optional data fields and provides a virtual destructor for polymorphic memory deallocation [SWS_RDS_90304]. Applications use derived structures to configure clock data and must verify the validity of the contained optional values prior to access. This ensures flexible and error-free handling of heterogeneous data streams.

more ›

Context

Within the Raw Data Stream (rds) functional cluster of the AUTOSAR Adaptive Platform, the class ara::rds::IEEE1722DatagramCRF represents a datagram for the Clock Reference Format (CRF) according to the IEEE 1722 standard AUTOSAR_AP_SWS_RawDataStream p. 1. The structure is defined in the header file ara/rds/raw_data_stream_IEEE1722.h [SWS_RDS_90304]. The class serves to encapsulate and provide protocol-specific metadata and synchronization attributes required for transmitting clock references over Ethernet connections.

All data fields of the class are declared with the access modifier protected and use the wrapper ara::core::Optional. These include the IEEE 1722 header fields unique_id [SWS_RDS_90294], base_frequency [SWS_RDS_90295], tu [SWS_RDS_90296], pull [SWS_RDS_90297], sequenceNum [SWS_RDS_90298], mac_address [SWS_RDS_90299], type [SWS_RDS_90300], mr [SWS_RDS_90301], fs [SWS_RDS_90302], and timestamp_interval [SWS_RDS_90303]. Because direct access to these members is protected, the class is likely to function primarily as an inheritance base for concrete, application-specific CRF datagram implementations or serialization drivers within the data stream. Question Q-0f9ddee032bd505f (open)

Lifecycle

Destruction of instances takes place via the virtual destructor ~IEEE1722DatagramCRF() noexcept [SWS_RDS_90304]. Due to its declaration as virtual, proper release of all resources is guaranteed even when objects of derived classes are managed and destroyed via a pointer to the base class. The specification as noexcept ensures that the destruction process is guaranteed to proceed without exceptions.

In the absence of an independent public constructor in the payload, creation and initialization of instances presumably occur via derived classes or module-specific factory mechanisms. Question (open) With regard to concurrency, instances of the class are not intrinsically thread-safe; because the attributes consist of simple optional scalar values, concurrent read and write access must be coordinated by higher-level synchronization mechanisms of the application.

Usage Path

A typical use case comprises the creation, configuration, and processing of a CRF datagram in the data stream, followed by its release.

Sequence diagram: Typical processing flow and lifecycle of an IEEE1722DatagramCRF object. Sources: [SWS_RDS_90304], AUTOSAR_AP_SWS_RawDataStream p. 1

First, the application instantiates a concrete variant of the CRF datagram class. The parameters relevant to the clock reference are then populated. For example, the MAC address mac_address [SWS_RDS_90299], the sampling frequency via fs [SWS_RDS_90302] or base_frequency [SWS_RDS_90295], and the timestamp interval timestamp_interval [SWS_RDS_90303] can be set. Because all fields are optional, header entries that are not required or are incomplete can be left in the ara::core::nullopt state. After configuration, the datagram is passed to the Raw Data Stream channel. As soon as processing is complete, the instance is safely destructed via ~IEEE1722DatagramCRF() [SWS_RDS_90304].

Error Scenarios

The virtual destructor ~IEEE1722DatagramCRF() is declared as noexcept [SWS_RDS_90304], preventing C++ exceptions from escaping during cleanup and avoiding program termination during stack unwinding.

When using the data fields, the primary risk lies in erroneously reading unset values. Prior to accessing values such as unique_id [SWS_RDS_90294], sequenceNum [SWS_RDS_90298], or tu [SWS_RDS_90296], the application must always check whether the respective ara::core::Optional actually contains a value (e.g., via has_value()). Direct dereferencing access to an empty optional represents a precondition violation and leads to undefined behavior or errors.