class ara::tsync::ConsumerTimeBaseValidationNotification

The interface ara::tsync::ConsumerTimeBaseValidationNotification informs consumer applications about newly available measurement data blocks of a time base. Via the callback methods SetSlaveTimingData [SWS_TS_00420] and SetPdelayInitiatorData [SWS_TS_00422], the system passes detailed timing and validation data for the Time Slave and the pDelay initiator. Application developers derive from the class, implement the data processing, and must ensure that no exceptions are thrown, since all methods are specified as noexcept and exception-safe. In addition, classification as non_threadsafe requires application-side synchronization during concurrent accesses.

more ›

Context

The class ara::tsync::ConsumerTimeBaseValidationNotification represents a callback interface in module tsync of the AUTOSAR Adaptive Platform. Its purpose is to inform a consumer application as soon as new recorded data blocks are available for a monitored time base.

Essentially three components participate in this interaction:

• Time base of module tsync: Continuously acquires time and synchronization measurements in the communication network.
• Interface ConsumerTimeBaseValidationNotification: Defines the transfer points for recorded measurement data blocks via the methods SetSlaveTimingData [SWS_TS_00420] and SetPdelayInitiatorData [SWS_TS_00422].
• Consumer application: Implements the callback methods, takes over the provided measurement values, and performs the functional validation of the time base.

Through this structure, application-specific validation logic is cleanly decoupled from the platform-internal recording of time data.

Lifecycle

As an abstract interface class with pure virtual methods, ara::tsync::ConsumerTimeBaseValidationNotification cannot be instantiated directly. A consumer application derives a concrete class and implements the required methods.

Creation and ownership are entirely the responsibility of the consumer application. The application presumably creates the callback object during its initialization phase and links it to the corresponding time base of the tsync service. Question Q-a423ce4cbd4eeaaa (open)

For destruction, the class provides a virtual destructor: virtual ~ConsumerTimeBaseValidationNotification() noexcept = default; [SWS_TS_01300]. Declaring it as a virtual destructor ensures that instances of derived classes can be released via base class pointers in a type-safe manner and without resource leaks.

Regarding concurrency, the notification methods SetSlaveTimingData [SWS_TS_00420] and SetPdelayInitiatorData [SWS_TS_00422] are specified as non_threadsafe. As invocation by the platform service is likely to occur in the context of a background thread, the application-side implementation is responsible for protecting accesses to shared application resources itself. Question Q-1b857df043504eec (open)

Usage Path

The typical sequence for using the validation notification comprises the following steps:

1. Implementation: The consumer application implements a class derived from ara::tsync::ConsumerTimeBaseValidationNotification.
2. Reception of time slave measurement data: As soon as a new measurement data block has been recorded for the time slave of the time base, the time service invokes the method SetSlaveTimingData [SWS_TS_00420] and passes the detailed validation data via the parameter measurementData of type TimeSlaveMeasurementType.
3. Reception of pDelay initiator measurement data: If new measurement data is available for the pDelay initiator, SetPdelayInitiatorData [SWS_TS_00422] is invoked with the detailed timing data in PdelayInitiatorMeasurementType.
4. Processing: The consumer application evaluates the transmitted data blocks to detect synchronization errors or runtime deviations.
5. Object release: When monitoring is terminated, the instance is destroyed via the virtual destructor [SWS_TS_01300].

Sequence diagram: Transmission of recorded measurement data blocks for time slave and pDelay initiator to the consumer implementation. Sources: [SWS_TS_00420], [SWS_TS_00422].

Error Scenarios

The interface methods are designed for maximum robustness and deterministic invocations:

• Exception safety: All member functions – SetSlaveTimingData [SWS_TS_00420], SetPdelayInitiatorData [SWS_TS_00422], and the destructor [SWS_TS_01300] – are declared with noexcept and specified as exception-safe (exception safe). The overriding methods in the consumer application must not propagate exceptions to the outside, as this leads to immediate program termination.
• Lack of feedback channels: Since the callback methods have the return type void, processing errors within the application logic cannot be reported back to the tsync module. The application must handle and log any error states internally on its own.
• Concurrency risks: Due to the property non_threadsafe ([SWS_TS_00420], [SWS_TS_00422]), it must be prevented that multiple data blocks are processed in parallel without application-side locking. Interpretation: The callback object must also remain valid for the entire duration of its registration with the time base in order to prevent fatal accesses to already released memory. Question Q-934e451f6a0099c1 (open)