module ara::tsync — Time Synchronization

The functional cluster Time Synchronization provides consistent and network-wide synchronized time bases to the AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Via standardized interfaces, adaptive applications query atomic time states or, acting as active time masters, feed new time and rate corrections into the overall system. At the same time, registered notifier callbacks continuously monitor state changes and time leaps of the underlying clocks ([SWS_TS_01009]). Advanced mechanisms for validating measurement data and freshness values secure temporal integrity against transmission errors and tampering.

more ›

The functional cluster Time Synchronization (tsync) provides consistent and network-wide synchronized time bases on the AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_TimeSynchronization p. 16). As a daemon-based background service, it abstracts hardware- and bus-specific synchronization mechanisms (such as IEEE 802.1AS gPTP) and supplies core clusters such as Log and Trace, the Intrusion Detection System Manager (IdsM), and update services via standardized interfaces (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Context diagram: Embedding of the daemon-based Time Synchronization cluster in the AUTOSAR Adaptive Platform and its interface relationships with consuming clusters and applications. Sources: AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

For read access, applications use the interface SynchronizedTimeBaseConsumer ([SWS_TS_01001]). The method GetTimeWithStatus() returns an atomic snapshot of type SynchronizedTimeBaseStatus, from which the global time, the local steady creation time, the synchronization status, and received UserData can be retrieved ([SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176]). To avoid polling, applications register via notifier callbacks for status changes and time leaps ([SWS_TS_01010], [SWS_TS_01014]).

Sequence diagram: Sequence of a synchronous time query via the consumer interface and retrieval of atomic snapshot properties. Sources: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Time-providing applications control system behavior via SynchronizedTimeBaseProvider: SetTime() initiates immediate bus transmissions, whereas UpdateTime() initially adjusts the clock locally ([SWS_TS_01101], [SWS_TS_01107], [SWS_TS_01108]). Accompanying mechanisms such as Time Validation ([SWS_TS_00420], [SWS_TS_00421]) and native Freshness Value Management (FVM) protect against drift and replay errors ([SWS_TS_14198]). In the event of an error, TsyncErrc codes (e.g. kDaemonConnectionLost) signal connection drops, while an absence of synchronization messages is indicated as kTimeOut in the status object ([SWS_TS_00901], [SWS_TS_01050]).

more ›

The functional cluster Time Synchronization (tsync) provides coordinated, network-wide synchronized time bases on the AUTOSAR Adaptive Platform and decouples using processes from hardware- and bus-specific time synchronization protocols (AUTOSAR_AP_SWS_TimeSynchronization p. 16). The system forms the information-technological foundation for distributed systems in which consistent event sequences, reproducible trace logs, and deterministic computation cycles must be guaranteed across ECU boundaries (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Context diagram: Embedding of the daemon-based Time Synchronization cluster in the AUTOSAR Adaptive Platform and its interface relationships with consuming clusters and applications. Sources: AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

System Boundaries and Role of the Daemon-Based Time Synchronization Cluster

The functional architecture of Time Synchronization is designed as a daemon-based cluster (daemon-based), which operates in the background as a central platform service (AUTOSAR_AP_SWS_TimeSynchronization p. 16). This daemon interacts directly with the interfaces of the underlying operating system and processes network-based time synchronization data such as gPTP (IEEE 802.1AS) or classic bus time synchronizations (AUTOSAR_FO_PRS_TimeSyncProtocol p. 68). Toward the application context, the cluster completely encapsulates the mathematical drift and offset compensation of the hardware clocks.

Numerous core functional clusters of the Adaptive Platform access tsync via standardized service interfaces (AUTOSAR_AP_EXP_SWArchitecture p. 83). For instance, Log and Trace relies on the synchronized time base to provide system-wide log and DLT events with reliable global timestamps (AUTOSAR_AP_EXP_SWArchitecture p. 59; AUTOSAR_AP_SWS_LogAndTrace p. 15). Security-relevant modules such as the Intrusion Detection System Manager (IdsM) and update services (UCM and Vehicle UCM) also strictly rely on the C++ interface of SynchronizedTimeBaseConsumer in order to control forensically reliable reports and consistent update transactions across ECU boundaries (AUTOSAR_AP_EXP_SWArchitecture p. 125; AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 16; AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement p. 11).

Consuming Interfaces and Stateful Time Queries

For read access to a synchronized time base, applications use the interface class SynchronizedTimeBaseConsumer ([SWS_TS_01001]). The class implements move semantics ([SWS_TS_01003], [SWS_TS_01004]), but explicitly excludes any copying ([SWS_TS_01005], [SWS_TS_01006]). At runtime, GetRateDeviation() allows direct reading of the clock's current frequency deviation ([SWS_TS_01008]).

The central element of every synchronous query is the operation GetTimeWithStatus() ([SWS_TS_01009]). Instead of returning isolated raw time values, the method generates a self-consistent snapshot of type SynchronizedTimeBaseStatus (EXP_SWArchitecture p. 81). This snapshot freezes the exact creation point in time in global time ([SWS_TS_01055]) as well as in local monotonic time via GetCreationLocalTime() ([SWS_TS_14176]). Points in time are represented in the standardized C++ chrono type Timestamp with nanosecond resolution based on std::int64_t ([SWS_TS_01251], [SWS_TS_01261], [SWS_TS_01262]).

In addition to time, the communication and synchronization state via GetSynchronizationStatus() ([SWS_TS_01053]), any time jump that may have occurred via GetLeapJump() ([SWS_TS_01054]), and application-specific user data via GetUserData() ([SWS_TS_01056]) can be determined from the snapshot. A default constructor for the status object does not exist ([SWS_TS_01061]), whereas move and copy constructors ensure its thread-safe handover to calling application routines ([SWS_TS_01057], [SWS_TS_01058]).

Sequence diagram: Sequence of a synchronous time query via the consumer interface and retrieval of atomic snapshot properties. Sources: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Event-Driven Notifications and Synchronization Monitoring

To avoid polling loops, SynchronizedTimeBaseConsumer provides an event-driven observer pattern via notifier callbacks (AUTOSAR_AP_EXP_SWArchitecture p. 226). Applications register with type-safe callbacks for specific state changes ([SWS_TS_14221], [SWS_TS_14222]). With each re-registration, the new notifier overwrites the previously registered handler ([SWS_TS_01010]).

For aggregated state changes, RegisterStatusChangeNotifier() is available ([SWS_TS_01010]), supplemented by UnregisterStatusChangeNotifier() ([SWS_TS_01011]). If an application primarily reacts to changes in synchronization status (e.g. loss of the grandmaster connection), RegisterSynchronizationStateChangeNotifier() ([SWS_TS_01012]) is used. Time jumps into the future (kTimeLeapFuture) or past (kTimeLeapPast) that exceed a configured threshold are reported via RegisterTimeLeapNotifier() ([SWS_TS_01014], [SWS_TS_01051]).

For mechatronic high-precision applications, RegisterTimePrecisionMeasurementNotifier() is also available ([SWS_TS_01018]). The callback passes a structure TimePrecisionMeasurement containing exact second and nanosecond values directly before (locSeconds, locNanoSeconds) and after synchronization (glbSeconds, glbNanoSeconds), the calculated path delay pathDelay, and the bitmask timeBaseStatus ([SWS_TS_01401], [SWS_TS_01403], [SWS_TS_01406], [SWS_TS_01408]). The Time Synchronization cluster performs no queue management (queuing) here; buffering must be implemented within the application callback if required ([SWS_TS_01018]).

Sequence diagram: Registration and asynchronous notification flow upon synchronization changes and time jumps. Sources: [SWS_TS_01010], [SWS_TS_01012], [SWS_TS_01014], AUTOSAR_AP_EXP_SWArchitecture p. 226

State diagram: Lifecycle of the synchronization status of a time base according to SWS_TS_01050. Sources: [SWS_TS_01050], AUTOSAR_SWS_TimeSync p. 25

Provision of Time Bases and Frequency Adjustment by Providers

If an Adaptive Application acts as an active time provider (time master) — for example by connecting to a GNSS receiver or an external reference clock —, it uses the class SynchronizedTimeBaseProvider ([SWS_TS_01101]). The interface allows the explicit setting of new time values via two different semantics: SetTime() and UpdateTime() (EXP_SWArchitecture p. 80).

Calling SetTime() not only resets the internal clock value, but forces immediate transmission of the updated synchronization messages on the vehicle bus ([SWS_TS_01107]). In contrast, UpdateTime() initially updates the clock time exclusively locally; transmission on the bus takes place with a delay in the regular subsequent cycle of the time transmission protocol ([SWS_TS_01108]). Both methods accept structured UserData in addition to the timestamp in order to distribute additional synchronization-accompanying information across the network ([SWS_TS_01112], [SWS_TS_01113]).

For the fine adjustment of quartz oscillators and the avoidance of abrupt phase jumps, SetRateCorrection() enables the application of a relative frequency correction factor ([SWS_TS_01110]). In addition, GetRateDeviation() provides the currently present clock deviation ([SWS_TS_01111]), while GetCurrentTime() reads the absolute time value of the clock independently of the current synchronization status ([SWS_TS_01109]).

Integrity Protection via Time Validation and Freshness Value Management

In safety-critical and highly automated driving environments, merely adopting time values is not sufficient; the correctness and tamper resistance of timestamps must be continuously validated (AUTOSAR_AP_SWS_TimeSynchronization p. 38). For this purpose, tsync offers callback interfaces for Time Validation: Consumers register via RegisterTimeValidationNotification() ([SWS_TS_01016]), providers analogously via the provider-specific method ([SWS_TS_01114]).

The validation interfaces ConsumerTimeBaseValidationNotification and ProviderTimeBaseValidationNotification pass detailed measurement data records to specialized monitoring applications ([SWS_TS_01300], [SWS_TS_01301]). At the master station, SetMasterTimingData() provides the egress timestamp (syncEgressTimestamp) and the sequence number (sequenceId) of the sent sync frames ([SWS_TS_00421], [SWS_TS_14141], [SWS_TS_14142]). At slave level, SetSlaveTimingData() passes the corresponding ingress timestamps (syncIngressTimestamp), the received correction field (correctionField), and the measured path delay (pDelay) ([SWS_TS_00420], [SWS_TS_14152], [SWS_TS_14153], [SWS_TS_14155]). For peer-to-peer delay measurements, SetPdelayInitiatorData() and SetPdelayResponderData() completely provide the ingress and egress points in time of the request and response packets ([SWS_TS_00422], [SWS_TS_00423], [SWS_TS_14160], [SWS_TS_14170]).

To protect against replay attacks and to secure transmitted time messages, the platform integrates Freshness Value Management (FVM) via native interfaces in namespace apext::tsync ([SWS_TS_14198], EXP_SWArchitecture p. 83). During startup, Initialize() initializes the responsible FVM plugin ([SWS_TS_14200]). Prior to transmission, the stack calls GetTxFreshness() to retrieve fresh counter values ([SWS_TS_14199]), whereas during reception GetRxFreshness() is used for verification and authentication ([SWS_TS_14198]). Data is transported via the standardized FVContainer ([SWS_TS_14195], [SWS_TS_14196]).

Sequence diagram: Validation flow of timing measurement data between master, slave, and external validator application. Sources: [SWS_TS_00420], [SWS_TS_00421], AUTOSAR_AP_SWS_TimeSynchronization p. 38

Configuration, Process Binding, and Manifest Modeling

The allocation and functional binding of the cluster is performed declaratively in the AUTOSAR model manifests (AUTOSAR_AP_TPS_ManifestSpecification p. 590). In the machine manifest, the platform daemon is instantiated via the metamodel element TimeSyncModuleInstantiation on a concrete Machine, where it manages the physical and virtual TimeBaseResource objects (AUTOSAR_AP_TPS_ManifestSpecification p. 590).

At the application level, processes declare their demand for time bases via port prototypes (RPortPrototype for consumers and PPortPrototype for providers) (AUTOSAR_AP_TPS_ManifestSpecification p. 599). The metamodel construct TimeSyncPortPrototypeToTimeBaseMapping links these ports on a process-individual basis to the time bases defined on the machine (TPS_ManifestSpecification p. 599; AUTOSAR_AP_TPS_ManifestSpecification p. 600). At runtime, instantiation in code is performed via the type-safe ara::core::InstanceSpecifier, whereby the stack binds the correct configured time base ([SWS_TS_01001], [SWS_TS_01101]).

Behavior in the event of an error

Error situations in the Time Synchronization cluster are signaled via the standardized error model of the Adaptive Platform (ara::core::Result and ara::core::ErrorCode) ([SWS_TS_00910]). For regular time base operations, the enumeration TsyncErrc defines the error codes ([SWS_TS_00901]). For example, if interprocess communication with the platform daemon breaks down, error code kDaemonConnectionLost is returned ([SWS_TS_00901]).

Via the global error domain TsyncErrorDomain, error codes can be inspected ([SWS_TS_00905], [SWS_TS_00906], [SWS_TS_00907]) or, when C++ exceptions are enabled, thrown via ThrowAsException() as TsyncException ([SWS_TS_00903], [SWS_TS_00908], [SWS_TS_00909]). For Freshness Value Management, an independent error domain TsyncFvmErrorDomain exists with the enumeration TsyncFvmErrc ([SWS_TS_14201], [SWS_TS_14202]). If initialization fails, Initialize() returns error kFVInitializeFailed ([SWS_TS_14200]), whereas if counters for authentication checks are unavailable, kFVNotAvailable is reported ([SWS_TS_14202]).

At the functional level, the cluster does not necessarily signal the loss of time messages via synchronous API errors, but marks the time base in the status object with the communication status kTimeOut ([SWS_TS_01050]) or sets the corresponding bit in timeBaseStatus ([SWS_TS_01403]). Interpretation: The application is therefore likely to always have an obligation to actively check the validity status of the snapshot according to GetTimeWithStatus() before measurement values are used for safety-critical control loops. Question Q-0cd9bb48452ae3db (open)

Further detailed evidence

The core requirements and specification points of module tsync can be assigned to the following focal areas:

• Runtime interfaces for consumers and providers: The lifecycle and retrieval operations are based on [SWS_TS_01001] through [SWS_TS_01019] as well as the provider functions [SWS_TS_01101] through [SWS_TS_01115] (EXP_SWArchitecture p. 80, EXP_SWArchitecture p. 81).
• Status structures and time representation: Definition of SynchronizedTimeBaseStatus, SynchronizationStatus, and LeapJump according to [SWS_TS_01050] through [SWS_TS_01062] as well as standard chrono types according to [SWS_TS_01251] through [SWS_TS_01265].
• Time Validation and measurement data acquisition: Definition of measurement structures and notification callbacks according to [SWS_TS_00420] through [SWS_TS_00423] as well as [SWS_TS_14140] through [SWS_TS_14174] (AUTOSAR_AP_SWS_TimeSynchronization p. 38).
• Security extension FVM: Authentication and freshness checking via interfaces [SWS_TS_14195] through [SWS_TS_14213] (AUTOSAR_AP_EXP_SWArchitecture p. 83).
• Manifest modeling: Declarative configuration and assignment of processes and port prototypes to time bases according to AUTOSAR_AP_TPS_ManifestSpecification p. 590 and AUTOSAR_AP_TPS_ManifestSpecification p. 599.