AUTOSAR Time Synchronization Explained: Time Master, SoK, gPTP (IEEE 802.1AS), EthTSyn & StbM – A Complete End-to-End Deep Dive

Executive Summary

Modern automotive systems are no longer collections of isolated electronic control units. Today’s vehicles are complex, networked platforms – from ADAS cameras capturing 60 fps video to radar sensors firing microsecond pulses, from electric powertrain controllers switching at 20 kHz to V2X communication modules exchanging safety messages with surrounding traffic. All of these systems must agree on one thing above all else: what time it is, right now, down to the nanosecond.

This is not a trivial requirement. Distributed clocks drift. Networks introduce variable latency. Hardware timestamps have jitter. Without a disciplined, standards-based approach to time synchronization, sensor fusion fails, safety-critical events are logged with wrong timestamps, and deterministic control loops fall apart.

AUTOSAR – the Automotive Open System Architecture – addresses this through a layered, standards-compliant time synchronization stack. At its core sit three major components: IEEE 802.1AS (gPTP) for Ethernet-based time distribution, EthTSyn as the AUTOSAR service layer wrapping gPTP, and StbM (Synchronized Time Base Manager) as the central time authority exposed to all software components across the vehicle.

This PiEmbSysTech Insight article is your single, definitive reference. We cover every layer – from physical oscillator behavior to application-level time consumption APIs – with architectural explanations, tables, configuration parameters, practical examples, and implementation guidance. Whether you are a software architect designing a new E/E architecture, an embedded engineer integrating EthTSyn into an ECU, or a test engineer validating time sync behavior, this article delivers everything you need.

1. Why Time Synchronization Matters in Modern Vehicles

1.1 The Scale of the Problem

A luxury vehicle produced today can contain well over 100 electronic control units communicating across multiple bus systems including CAN, LIN, FlexRay, and increasingly Ethernet. Each ECU carries its own oscillator – typically a crystal running between 8 MHz and 80 MHz – and each oscillator drifts independently due to manufacturing tolerances, temperature changes, supply voltage variations, and aging.

The typical accuracy of an automotive crystal oscillator without correction is in the range of ±20 to ±100 parts per million (ppm). Over a single second, a 100 ppm drift means the local clock could be 100 microseconds ahead of or behind a reference. Over a minute, that accumulates to 6 milliseconds. In a vehicle traveling at 120 km/h, 6 milliseconds corresponds to a position error of 20 centimeters – far exceeding the tolerance for lane-change decisions in ADAS applications.

1.2 Use Cases Requiring Precise Time

Domain	Use Case	Required Accuracy	AUTOSAR Impact
ADAS / AV	Camera-LiDAR-Radar sensor fusion	< 1 µs	StbM Global Time consumed by fusion ECU
ADAS / AV	Time-stamped object tracks	< 10 µs	EthTSyn sync across perception ECUs
Powertrain	Multi-ECU injection timing	< 100 µs	StbM Local Time Base for engine domain
Body	Diagnostic event logging (DET/DEM)	< 1 ms	StbM Offset Time Base
V2X	Cooperative awareness messages	< 1 µs (UTC)	GPS-disciplined GrandMaster + StbM
OTA Update	Signed update manifests	< 1 s (UTC)	StbM UTC offset tracking
Chassis	ESC / brake actuator coordination	< 500 µs	CAN-based time sync + StbM
Infotainment	Audio-video synchronization	< 125 µs	gPTP + EthTSyn

1.3 The Cost of Incorrect Time

Time synchronization failures do not always cause immediate, visible faults. More insidiously, they cause subtle degradations that are difficult to diagnose in the field:

• A camera ECU and a radar ECU with 3 ms clock skew may fuse an object at a position that does not correspond to any physical obstacle, leading to false-positive emergency braking events.
• A battery management system logging cell temperature anomalies with unsynchronized timestamps may produce event sequences that misrepresent the root cause, leading to incorrect warranty claims.
• A gateway ECU bridging CAN and Ethernet may reorder or corrupt protocol data units when its local time drifts out of range, causing spurious CRC failures.
• V2X messages transmitted with incorrect UTC timestamps violate ETSI ITS protocol specifications and may be rejected by receiving nodes, eliminating the safety benefit of cooperative awareness.

2. Fundamentals of Distributed Time Synchronization

2.1 Clock Models and Oscillator Behavior

Every digital system is driven by an oscillator. In automotive ECUs, the most common type is a quartz crystal oscillator, which exploits the piezoelectric resonance of a thin quartz wafer to produce a stable frequency reference. The nominal frequency is set during manufacturing, but the actual frequency varies with:

Temperature: The most significant factor. Most AT-cut quartz crystals have a characteristic turnover temperature near 25°C, and frequency changes by several ppm as temperature moves away from this point.

Supply voltage: Voltage regulators have finite rejection ratios; small voltage changes alter crystal loading and thus resonant frequency.

Aging: Crystal frequency drifts predictably over time as mechanical stress in the wafer relaxes, typically on the order of 0.5 to 5 ppm per year for automotive-grade parts.

Mechanical shock and vibration: Particularly relevant in automotive environments where road excitation is continuous.

For time synchronization purposes, the key parameters are: initial frequency offset (how far the oscillator is from nominal at startup), frequency stability (how consistently it runs at a given temperature), and phase noise (short-term jitter in the oscillation).

2.2 Time, Frequency, and Phase Concepts

To understand gPTP and StbM, three related but distinct concepts must be precisely defined:

Time: An absolute or relative position on the timeline, expressed as nanoseconds from an epoch. AUTOSAR represents time as a 64-bit nanosecond counter internally.

Frequency: The rate at which a clock advances. If a clock runs at 100.001 MHz instead of 100 MHz, it runs 10 ppm fast. Its time will accumulate 10 ns per millisecond of error relative to a 100 MHz reference.

Phase: The instantaneous offset between two clocks at the same nominal frequency. Two clocks can agree perfectly on frequency but be 500 ns apart in phase – this is phase offset.

Time synchronization involves correcting both phase offset (where is the clock right now relative to the master) and frequency offset (how fast is the local clock running relative to the master). The process of continuously correcting frequency is called rate correction or slewing, and is essential for maintaining long-term synchronization.

2.3 IEEE 1588 PTP vs IEEE 802.1AS gPTP

IEEE 1588-2008 (Precision Time Protocol, PTP) is the original standard for sub-microsecond time synchronization over packet networks. IEEE 802.1AS-2011 (and the 2020 revision) is a profile of PTP specifically tailored for time-sensitive networking (TSN) and Audio Video Bridging (AVB) applications, and is the protocol mandated by the AUTOSAR EthTSyn specification.

Feature	IEEE 1588 PTP	IEEE 802.1AS (gPTP)
Network scope	Heterogeneous, multi-hop	Ethernet-only, point-to-point links
Delay measurement	E2E or P2P	P2P (peer delay) only
Bridge requirement	Transparent clocks optional	All bridges must be gPTP-aware
Typical accuracy	Sub-microsecond	Sub-100 nanosecond
AUTOSAR use	Not directly	Yes, via EthTSyn module
TSN integration	Limited	Native (part of TSN standard set)
Multi-domain	Yes (domain number field)	Yes (802.1AS-2020, multiple instances)

Key differences include that 802.1AS operates only over full-duplex point-to-point links, uses the peer delay mechanism exclusively, requires all bridges to be time-aware, defines automotive-specific message rates and timeouts, and supports multiple domains simultaneously on a single device – aligning directly with AUTOSAR’s multi-domain time base concept.

3. IEEE 802.1AS – Generalized Precision Time Protocol (gPTP) Explained

3.1 Protocol Overview

gPTP is a Layer 2 Ethernet protocol. It uses multicast MAC addressing and does not rely on IP, making it latency-deterministic and topology-independent from a Layer 3 perspective. All gPTP messages are carried in standard Ethernet frames with EtherType 0x88F7.

The fundamental goal of gPTP is to establish a common time reference across all nodes in a network segment. One node is designated as the GrandMaster – the ultimate source of time. All other nodes are either slave nodes that synchronize directly to the GrandMaster, or transparent clocks in larger networks that correct for forwarding delay as messages pass through.

3.2 gPTP Message Types

Message Type	Direction	Purpose	Multicast MAC
Sync	Master → Slave	Carry master timestamp t1 (or trigger Follow_Up)	01:80:C2:00:00:0E
Follow_Up	Master → Slave	Carry precise t1 (when two-step mode used)	01:80:C2:00:00:0E
Pdelay_Req	Any → Peer	Initiate peer delay measurement	01:80:C2:00:00:0E
Pdelay_Resp	Peer → Requester	Return t3 and t2 timestamps for delay calc	01:80:C2:00:00:0E
Pdelay_Resp_Follow_Up	Peer → Requester	Two-step correction for precise t3	01:80:C2:00:00:0E
Announce	Master → All	Advertise clock quality for BMCA election	01:80:C2:00:00:0E
Signaling	Any → Any	Negotiate message intervals	01:80:C2:00:00:0E

3.3 The Two-Step Sync Mechanism

The most accurate gPTP implementations use two-step synchronization. The reason two steps are needed relates to hardware timestamp capture latency: the precise moment at which the Sync frame actually leaves the physical medium (the egress timestamp t1) cannot be embedded in the Sync frame itself, because the timestamp is only available after the frame has been transmitted.

The two-step mechanism:

1. The master sends a Sync frame at time t1 (as measured by the master’s hardware timestamp unit). The Sync frame contains a less-precise software timestamp or zeros.
2. Immediately after transmitting the Sync frame, the master reads the hardware egress timestamp t1 and embeds it in a Follow_Up frame, which is sent to all slaves.
3. The slave receives the Sync frame at time t2 (slave’s local hardware ingress timestamp).
4. The slave receives the Follow_Up and extracts the precise t1.
5. The slave computes the offset: offset = t2 − t1 − path_delay.
6. The slave applies this offset to correct its local clock, either through a step correction (phase jump) or gradual slewing (frequency adjustment).

3.4 Peer Delay Measurement

gPTP mandates peer delay measurement, measuring the propagation delay on each individual link segment. This is more accurate in switched environments and allows each bridge to compensate for its own forwarding delay independently.

The peer delay calculation:

Peer Delay = ((t4 − t1) − (t3 − t2)) / 2

Where: t1 = timestamp when Pdelay_Req is sent by requester, t2 = timestamp when Pdelay_Req is received by responder, t3 = timestamp when Pdelay_Resp is sent by responder, t4 = timestamp when Pdelay_Resp is received by requester. This formula assumes symmetrical propagation delay — valid for point-to-point full-duplex Ethernet links.

3.5 Rate Ratio and Frequency Correction

gPTP includes a neighbor rate ratio mechanism that allows each node to continuously estimate the relative frequency difference between itself and its upstream master. The rate ratio is computed by comparing the interval between successive Sync frames as measured by the master versus the slave:

rateRatio = (t2_n − t2_(n−1)) / (t1_n − t1_(n−1))

A rateRatio of 1.000010 means the local clock is running 10 ppm fast relative to the master. The AUTOSAR EthTSyn module uses this rate ratio to adjust the local time base, ensuring that the rate of local time advance matches the master’s rate. This is called frequency compensation or clock rate adjustment.

3.6 gPTP Domains

A gPTP domain is an independent synchronization scope. Different domains can carry different time scales (e.g., vehicle network time vs. UTC vs. GPS time) and can have different GrandMasters. IEEE 802.1AS-2020 supports multiple domain instances per physical interface, enabling a single ECU to participate in multiple time domains simultaneously — a capability that directly enables the AUTOSAR multi-domain time base architecture.

4. AUTOSAR Time Synchronization Architecture Overview

4.1 Layered Architecture

AUTOSAR’s time synchronization architecture follows the classic layered BSW design principle. The layers from hardware to application are:

1. Physical layer: Crystal oscillator + optional GPS/GNSS receiver.
2. Hardware timestamping: Ethernet MAC with hardware timestamp registers; GPT (General Purpose Timer) for other domains.
3. Eth driver (EthDrv): Raw Ethernet frame receive/transmit; exposes hardware timestamps to upper layers.
4. EthTSyn: Implements gPTP message processing; master/slave logic; peer delay; rate ratio computation.
5. StbM: Central time base registry; manages multiple time bases; provides customer-facing API.
6. RTE: Mediates time access between BSW and SWC.
7. SWC: Application code consuming or producing time references.

4.2 AUTOSAR Time Base Types

Time Base Type	Description	Source	Typical Use Case
Synchronized Global Time Base (SGTB)	Directly tracks the GrandMaster’s time; highest accuracy; distributed network-wide	EthTSyn / gPTP	ADAS sensor fusion, V2X, cross-domain event correlation
Offset Time Base	Derived from a Global or Synchronized Time Base by adding a fixed or slowly varying offset	StbM internal calculation	Domain-local time, UTC offset, application-specific epochs
Pure Local Time Base	Free-running local oscillator; no synchronization; used when external time reference is unavailable	GPT hardware timer	Standalone ECUs, pre-sync fallback, internal scheduling

Each time base is identified by a unique TimeBaseId within StbM. Consumers query StbM with their required TimeBaseId and receive a time value along with a status bitmask indicating synchronization quality.

4.3 Multiple Domain Architecture

A modern vehicle E/E architecture may contain multiple distinct time synchronization domains. A zonal architecture might have:

• Domain 0: Vehicle network global time, disciplined by a GPS GrandMaster in the central gateway.
• Domain 1: ADAS domain time, maintained by the ADAS domain controller, disciplined by Domain 0.
• Domain 2: Powertrain domain time, maintained by the powertrain gateway, synchronized to Domain 0 through a domain bridge.
• Domain 3: Infotainment / HMI domain, synchronized for audio-video bridging.

StbM manages all of these time bases simultaneously. Each EthTSyn instance is configured to produce updates for a specific StbM time base. An ECU acting as a domain bridge runs both a gPTP slave (receiving from Domain 0) and a gPTP master (distributing to Domain 1), with StbM providing the time relay between them.

5. Time Master and Time Slave: Roles, Election, and Hierarchy

5.1 Role Definitions

GrandMaster: The single authoritative time source for a domain. All other nodes ultimately derive their time from the GrandMaster. In automotive systems, the GrandMaster is typically the central gateway, a domain controller with GPS/GNSS input, or a dedicated time server ECU. An AUTOSAR ECU acting as GrandMaster has EthTSyn configured as a master on all its Ethernet ports, and StbM configured to use a local GPS-disciplined time base or the highest-quality oscillator.

Time-Aware Bridge (Transparent Clock): A switch or gateway that forwards gPTP messages while correcting for its own forwarding delay in the correctionField of Sync and Follow_Up messages. Automotive Ethernet switches (e.g., from NXP, Marvell, Renesas) implement this in hardware. The bridge does not maintain its own synchronized time base; it only corrects delay.

Slave (Endpoint): An ECU that receives gPTP Sync messages and adjusts its local time to match the GrandMaster. In AUTOSAR, most endpoint ECUs are pure slaves. The EthTSyn module on the slave ECU processes incoming Sync and Follow_Up messages, computes the time offset, and updates the corresponding StbM time base.

5.2 Best Master Clock Algorithm (BMCA)

The BMCA determines which node takes the GrandMaster role. The algorithm is deterministic and compares candidate nodes based on their Announce message content, using the following priority fields in order:

1. Priority1: Statically configured administrative priority (lower value = higher priority). Range 0–255.
2. Clock Class: Indicates the quality and traceability of the clock source. Class 6 = primary reference traceable to UTC (GPS); Class 7 = holdover after GPS lock; Class 135 = application-specific master; Class 248 = default.
3. Clock Accuracy: Quantifies how closely the clock tracks the ideal clock. 0x20 = within 25 ns; 0x21 = within 100 ns; 0x22 = within 250 ns, etc.
4. Offset Scaled Log Variance: Statistical measure of oscillator stability (Allan deviation).
5. Priority2: Secondary administrative priority for tie-breaking.
6. Clock Identity: EUI-64 identifier, used as final tie-breaker to ensure unique and deterministic selection.

5.3 Static vs. Dynamic Master Configuration in AUTOSAR

Static Configuration: The EthTSyn master/slave role is fixed at compile time in the configuration. One ECU is always the master; all others are always slaves. BMCA may still run for redundancy detection, but the configured role does not change. This is the most common approach in series production automotive systems where the E/E architecture is fixed.

Dynamic BMCA: EthTSyn runs the full BMCA and can dynamically transition between master and slave roles based on clock quality. This is used in systems requiring hot-standby redundancy – for example, when a primary GrandMaster ECU fails, a secondary ECU with lower Priority1 but the same GPS reference can take over automatically.

5.4 Cascaded Masters and Bridged Domains

In large E/E architectures, it is common to have a hierarchy of time masters. The central gateway acts as the GrandMaster for the backbone Ethernet network. Zone controllers act as masters for their respective zone networks, but are slaves to the backbone. This creates a cascade: GPS → Central GW GrandMaster → Zone Controller Master/Slave → ECU Slave.

AUTOSAR supports this through the Master-Slave Bridge concept in EthTSyn. The zone controller runs two EthTSyn instances: one configured as a slave on the backbone port and one configured as a master on the zone port. StbM ties these together: the synchronized time base updated by the slave instance is used as the source for the master instance’s outgoing Sync messages.

6. Synchronized Time Base Manager (StbM) – Architecture and API

6.1 StbM Purpose and Position

StbM is the central hub of the AUTOSAR time synchronization stack. It sits above all transport-specific modules (EthTSyn, TimeSyncXcp, FrTSyn, CanTSyn) and provides a unified, transport-independent API to all BSW modules and application software components. Think of StbM as the operating system of time – it manages multiple time domains, tracks synchronization state, handles rate correction, and exposes a clean API.

6.2 StbM Time Base Internal State

Field	Type	Description
TimeBase Value	uint64 (nanoseconds)	Current time value in nanoseconds from epoch
Status Bitmask	uint8	Bit 0: SYNC_TO_GLOBAL; Bit 1: TIMEOUT; Bit 2: TIME_LEAP; Bit 3: SYNC_TO_SUB_DOMAIN; …
Rate Correction	float / fixed-point	Current frequency correction factor (ppm)
RateDeviation	int32 (ppb)	Measured frequency deviation from master
User Data	StbM_UserDataType	Optional application-defined data transported alongside time
SyncLoss Timeout	uint32 (ms)	Time after last sync until TIMEOUT bit is set
TimeLeap Future Threshold	uint32 (ns)	Jump forward threshold to set TIME_LEAP
TimeLeap Past Threshold	uint32 (ns)	Jump backward threshold to set TIME_LEAP

6.3 StbM API Reference

StbM_GetCurrentTime(): The primary consumer API. Takes a TimeBaseId and returns the current time as a StbM_TimeStampType (nanosecond resolution) along with the status bitmask and optional user data. All SWCs that need the current time call this function.

StbM_GetCurrentTimeExtended(): Extended variant returning additional quality information including rate deviation and time base chain information.

StbM_SetGlobalTime(): Called by EthTSyn (or other sync modules) to update the synchronized time base with a new time value from the master. Also accepts rate correction and user data. This is the write path into StbM.

StbM_UpdateGlobalTime(): Incremental update for rate correction only, without a full time step — used between sync cycles to improve interpolation accuracy.

StbM_GetTimeBaseStatus(): Returns only the status bitmask without the full time value, for lightweight polling of synchronization health.

StbM_GetRateDeviation(): Returns the current rate deviation (frequency offset) in parts per billion (ppb) relative to the master. Useful for diagnostics and oscillator characterization.

StbM_StartTimer(): Sets a timer on a time base, triggering a callback (StbM_TimerCallbackType) when the time base reaches a specified absolute time. Used for time-triggered actions synchronized across ECUs.

StbM_BusSetGlobalTime(): Alternative entry for bus-specific sync modules that operate on raw time values without going through the full EthTSyn processing path.

6.4 Status Bitmask Interpretation

Bit	Symbol	Meaning When Set
0	STBM_SYNC_TO_GLOBAL_MASTER	Time base is actively synchronized to the GrandMaster (most recent sync within SyncLossTimeout)
1	STBM_TIMEOUT	Sync messages not received within SyncLossTimeout; time base is coasting on local oscillator
2	STBM_TIME_LEAP_FUTURE	A forward time jump exceeding LeapFutureThreshold was detected
3	STBM_TIME_LEAP_PAST	A backward time jump exceeding LeapPastThreshold was detected
4	STBM_SYNC_TO_SUB_DOMAIN_MASTER	Synchronized to a sub-domain master rather than the ultimate GrandMaster
5	STBM_GLOBAL_TIME_BASE	This time base is a global time base (as opposed to an offset time base)
6–7	Reserved	Reserved for future use

6.5 Rate Correction Mechanism

StbM implements a software-based rate correction to compensate for oscillator frequency deviation. When EthTSyn reports a rate ratio (neighbor rate ratio from gPTP), StbM stores this as a rate correction factor. Every time StbM_GetCurrentTime() is called, StbM computes the corrected time as:

correctedTime = baseTime + (hardwareTimerDelta × rateRatio)

The rate correction is applied continuously without requiring a phase jump, ensuring smooth, jitter-free time delivery to consumers even between sync updates.

7. EthTSyn – Ethernet Time Synchronization Module Deep Dive

7.1 EthTSyn Position and Responsibilities

EthTSyn is the AUTOSAR module that implements the gPTP (IEEE 802.1AS) protocol for Ethernet-based time synchronization. It is a Service Layer module in the AUTOSAR Classic BSW stack, sitting between the Ethernet Interface (EthIf) and StbM. EthTSyn handles all gPTP protocol logic: message construction, timestamp processing, peer delay measurement, BMCA, and rate ratio computation.

7.2 EthTSyn Internal Architecture

EthTSyn is organized around the concept of ports. Each physical Ethernet port managed by EthTSyn is represented as an EthTSyn port configuration. A port can be configured as:

• Master Port: Sends Sync and Follow_Up messages; responds to Pdelay_Req with Pdelay_Resp; sends Announce messages.
• Slave Port: Receives Sync and Follow_Up; sends Pdelay_Req; processes Pdelay_Resp to measure peer delay; does not send Announce or Sync.
• Passive Port: Participates in peer delay measurement only; does not send or process Sync. Used on ports that should not carry master traffic.

EthTSyn’s main task function is typically called from a periodic BSW task at 1 ms or less. Each call processes any pending received messages from the Ethernet receive buffer, updates timers (Sync interval, Pdelay interval, Announce interval, timeout watchdogs), and triggers any due transmissions.

7.3 Hardware Timestamping Interface

The accuracy of gPTP depends entirely on the quality of hardware timestamping. EthTSyn interfaces with the Ethernet driver through EthIf_GetTxTimeStamp() and EthIf_GetRxTimeStamp() (or their driver-specific equivalents). These functions return hardware timestamps captured by the Ethernet MAC’s timestamp unit at the moment of frame transmission or reception.

Modern automotive Ethernet MACs provide timestamp accuracy of ±8 ns or better. The timestamp is typically captured at the Start of Frame Delimiter (SFD) crossing at the physical layer interface — the earliest possible point, minimizing the impact of protocol stack processing latency.

When hardware timestamps are not available, EthTSyn falls back to software timestamps captured by calling Os_GetCounterValue() at the moment of Eth_Transmit() or upon the Eth receive callback. Software timestamps have accuracy in the range of 1–50 µs depending on interrupt latency and task scheduling, and are not suitable for production ADAS systems.

7.4 EthTSyn Master Processing Flow

When an EthTSyn master port is active and the Sync interval timer expires:

1. EthTSyn allocates a Sync PDU and populates the PTP header with the sequenceId, domainNumber, sourcePortIdentity, and logMessageInterval.
2. For two-step mode, EthTSyn sets the twoStepFlag in the Sync header.
3. EthTSyn calls EthIf_Transmit() to send the Sync frame. The hardware captures the egress timestamp t1.
4. EthTSyn retrieves t1 via EthIf_GetTxTimeStamp() (typically in the next EthTSyn_MainFunction() call or via callback).
5. EthTSyn builds a Follow_Up PDU containing t1 in the preciseOriginTimestamp field and any accumulated correctionField value, then transmits it.
6. EthTSyn increments the sequenceId for the next Sync cycle.

7.5 EthTSyn Slave Processing Flow

When an EthTSyn slave port receives a gPTP frame, EthIf invokes EthTSyn_RxIndication(). Processing by message type:

1. On Sync reception: EthTSyn records the hardware ingress timestamp t2 and the sequenceId. If oneStep mode, the originTimestamp is extracted directly and offset computation begins. If twoStep, EthTSyn stores t2 and waits for the matching Follow_Up.
2. On Follow_Up reception: EthTSyn matches the sequenceId to the pending Sync, extracts t1 (preciseOriginTimestamp + correctionField), computes the raw offset: rawOffset = t2 − t1 − peerDelay.
3. EthTSyn applies the neighborRateRatio correction: correctedOffset = rawOffset / cumulativeRateRatio.
4. EthTSyn calls StbM_SetGlobalTime() with the new synchronized time value = masterTime + peerDelay + rateAdjustedOffset.
5. StbM updates its internal time base and status flags accordingly.
6. EthTSyn stores the rate ratio for use in subsequent interpolation.

7.6 Pdelay Measurement in EthTSyn

EthTSyn initiates peer delay measurement independently on each port at the configured Pdelay_Req interval (typically every 1 second). The peer delay is computed as:

peerDelay = ((t4 − t1) − neighborRateRatio × (t3 − t2)) / 2

EthTSyn maintains a running filter on peer delay measurements to reject outliers. The AUTOSAR specification recommends a minimum of the last N measurements (N configurable, typical value 8) using an IIR low-pass filter to smooth the result. If the measured peer delay exceeds the configured EthTSyn_PdelayLatencyThreshold, EthTSyn considers the link anomalous and may stop forwarding sync information.

8. Synchronized Offset Time Bases and SoK

8.1 What is SoK (Synchronized over K)?

SoK is an AUTOSAR concept and abbreviation appearing in the StbM and EthTSyn specifications. It stands for Synchronized over K, where K represents the number of cascaded synchronization hops between the local ECU’s time base and the GrandMaster.

In a simple two-node network (GrandMaster directly connected to a slave ECU), K = 1. In a cascaded architecture (GrandMaster → Zone Controller → End ECU), the end ECU’s time base has K = 2. Each additional hop introduces additional synchronization error. The cumulative error budget for a K-hop chain is approximately K times the single-hop error. For a well-designed automotive Ethernet network with hardware timestamping, single-hop error is typically under 100 ns, so a K = 3 chain achieves roughly 300 ns accuracy — still within requirements for most ADAS applications.

8.2 Offset Time Bases in AUTOSAR

An offset time base tracks another time base (called the parent or base time base) with an additional fixed or slowly varying offset. Common use cases:

• UTC Offset: The synchronized vehicle network time may track GPS time, which has a fixed offset from UTC (currently 18 leap seconds as of 2024). A UTC offset time base provides wall-clock time to applications needing it.
• Domain-local epoch: A powertrain time base might start from zero at engine start, tracking a global time base with an offset equal to the vehicle network time at engine start.
• Application-specific alignment: A data recorder application may align its timestamps to a specific calibration event.

8.3 SoK in StbM

When StbM manages multiple time bases forming a hierarchy (global → domain → offset), the SoK value is tracked through the chain. The StbM_GetCurrentTimeExtended() function returns the SoK value as part of the extended status, allowing the application to assess the number of synchronization hops and estimate the accumulated error. In AUTOSAR Adaptive (where StbM is replaced by the ara::tsync API), SoK becomes more explicit through the TimeBaseStatusType.

9. TimeMaster Selection, BMCA, and Fault Tolerance

9.1 BMCA Decision Tree

When node A receives an Announce message from node B and compares it against its own clock data set, the winner is determined by sequentially comparing:

1. If Priority1(A) < Priority1(B) → A is better (A claims master).
2. Else if ClockClass(A) < ClockClass(B) → A is better.
3. Else if ClockAccuracy(A) < ClockAccuracy(B) → A is better.
4. Else if OffsetScaledLogVariance(A) < OffsetScaledLogVariance(B) → A is better.
5. Else if Priority2(A) < Priority2(B) → A is better.
6. Else ClockIdentity(A) vs ClockIdentity(B): numerically lower EUI-64 wins.

The outcome determines whether A should be in master state (it wins) or slave state (B wins). This is evaluated for each port independently, enabling the same ECU to be a master on some ports and a slave on others – the basis for bridging functionality.

9.2 Announce Timeout and Network Failure Detection

EthTSyn implements an Announce Receipt Timeout watchdog. If no Announce message is received from the current master for a configurable number of Announce intervals (EthTSyn_AnnounceReceiptTimeout, default 3 intervals = 3 seconds), the slave ECU considers the master unreachable and may transition to master state.

This timeout event also propagates to StbM: the time base associated with the failed master path has its STBM_TIMEOUT bit set, and StbM may trigger a DEM event for the synchronization loss. Applications monitoring the status bitmask detect this condition and can implement graceful degradation – for example, switching from sensor fusion (requiring sub-microsecond sync) to dead-reckoning (tolerating millisecond-level drift).

9.3 Hot-Standby Redundancy

For safety-critical vehicle systems, a single-point-of-failure GrandMaster is unacceptable. AUTOSAR supports hot-standby redundancy through the following architecture:

• Two ECUs are configured with identical Priority1 values but different Priority2 values (Primary: Priority2=128, Secondary: Priority2=129).
• Both ECUs receive GPS time independently from separate GNSS receivers on separate antenna circuits.
• Under normal operation, the Primary ECU wins BMCA and acts as GrandMaster.
• If the Primary ECU fails or loses GPS lock (causing ClockClass to degrade from 6 to 7 or 52), the Secondary ECU wins BMCA and seamlessly takes over as GrandMaster within one to three Announce intervals.
• The switchover is transparent to slave ECUs – they simply start receiving Sync messages from a different source MAC address, and EthTSyn updates the remoteClockIdentity accordingly.

10. StbM Configuration Reference

10.1 Key AUTOSAR Configuration Parameters

Parameter	Container	Type	Description	Typical Value
StbMSynchronizedTimeBaseId	StbMSynchronizedTimeBase	uint8 (0–255)	Unique identifier for this time base	0 (global), 1 (domain A), etc.
StbMSyncLossTimeout	StbMSynchronizedTimeBase	float (s)	Duration after last sync before TIMEOUT flag is set	0.1 to 1.0 s
StbMTimeleapFutureThreshold	StbMSynchronizedTimeBase	uint32 (ns)	Forward jump threshold for TIME_LEAP_FUTURE flag	10000000 (10 ms)
StbMTimeleapPastThreshold	StbMSynchronizedTimeBase	uint32 (ns)	Backward jump threshold for TIME_LEAP_PAST flag	1000000 (1 ms)
StbMLocalTimeHardware	StbMLocalTimeHardware	enum	Hardware timer providing the free-running local time base	GPT channel or Eth SWT timer
StbMAllowMasterRateCorrection	StbMSynchronizedTimeBase	boolean	Allow frequency correction from EthTSyn	true
StbMCorrectionRateThreshold	StbMSynchronizedTimeBase	uint32 (ppb)	Maximum rate correction; beyond this triggers error	1000000 (1000 ppm)
StbMTimeBaseUpdateCounter	StbMSynchronizedTimeBase	uint8	Number of MainFunction calls between time base updates	1

10.2 Multi-TimeBase Configuration Example

A typical gateway ECU configuration managing three time bases:

TimeBase 0: Global Vehicle Time (synchronized to GrandMaster via EthTSyn on backbone port). SyncLossTimeout=100ms. TimeleapFutureThreshold=10ms.

TimeBase 1: UTC Offset Time Base (parent=TimeBase 0, offset=current TAI-UTC = 18 s leap seconds + UTC epoch). Used for V2X and OTA.

TimeBase 2: Powertrain Domain Time (synchronized via EthTSyn slave on powertrain Ethernet port). SyncLossTimeout=50ms.

11. EthTSyn Configuration Reference

11.1 Key Configuration Parameters

Parameter	Container	Description	Typical Value
EthTSynPortRole	EthTSynPort	Master / Slave / Passive — role of this Ethernet port	Slave (for most ECUs)
EthTSynSyncInterval	EthTSynPort (master)	Interval between Sync messages (log base 2 seconds)	−3 (125 ms) or −1 (500 ms)
EthTSynPdelayReqInterval	EthTSynPort	Interval between Pdelay_Req messages	0 (1 s)
EthTSynAnnounceInterval	EthTSynPort (master)	Interval between Announce messages	0 (1 s)
EthTSynAnnounceReceiptTimeout	EthTSynPort (slave)	Number of announce intervals before timeout	3
EthTSynSyncReceiptTimeout	EthTSynPort (slave)	Number of sync intervals before timeout	3
EthTSynPdelayLatencyThreshold	EthTSynPort	Maximum acceptable peer delay	100000 (100 µs)
EthTSynHardwareTimestampSupport	EthTSynGeneral	Enable hardware timestamp capture via EthIf layer	true
EthTSynTimeBaseId	EthTSynPort	StbM TimeBaseId that this port updates or sources from	0
EthTSynFollowUpDataIDList	EthTSynPort	CRC data ID list for Follow_Up message authentication (ICV)	AUTOSAR-specified list
EthTSynDomain	EthTSynPort	gPTP domain number for this port instance	0
EthTSynPdelayResponseAllowed	EthTSynPort	Consecutive Pdelay failures before link flagged as asymmetric	3

11.2 EthTSyn Master Configuration Example

A gateway ECU acting as GrandMaster on a 100BASE-T1 backbone network:

EthTSynPort_0: Role=Master, SyncInterval=−3 (125 ms), AnnounceInterval=0 (1 s), Domain=0, TimeBaseId=0, HardwareTimestamp=true.

EthTSynPort_1: Role=Slave, Domain=0, TimeBaseId=0 (updates StbM TimeBase 0 from upstream GPS source).

If the GrandMaster ECU is the ultimate time source (no upstream master), EthTSynPort_1 may not exist, and StbM TimeBase 0 is fed directly from the GPS driver via StbM_SetGlobalTime().

12. Integration with AUTOSAR OS and RTE

12.1 OS Task Scheduling

EthTSyn and StbM both require periodic execution via their respective MainFunction calls. Recommended periods:

Function	Recommended Period	Rationale
EthTSyn_MainFunction()	1 ms	Ensures prompt processing of received gPTP frames and timely Pdelay/Sync transmission
StbM_MainFunction()	1 ms	Keeps internal time interpolation accurate; updates timeout watchdogs
StbM_GetCurrentTime() (SWC call)	Application-defined	No restriction; StbM is reentrant for reading; write (SetGlobalTime) is non-reentrant

12.2 RTE Port Interface for SWC Time Consumption

The recommended pattern for SWC time consumption:

1. SWC declares a RequiredInterface to StbM using the StbM service port.
2. RTE generates a wrapper that resolves to StbM_GetCurrentTime() at runtime.
3. SWC calls Rte_Call_StbMService_GetCurrentTime(&timeStamp, &userDataPtr, &statusPtr).
4. SWC checks statusPtr for STBM_SYNC_TO_GLOBAL_MASTER and STBM_TIMEOUT before using the time value.

Safety rule: Never consume a time value from a time base whose status bitmask has STBM_TIMEOUT set in a safety-relevant function. The value is valid only as long as the SYNC_TO_GLOBAL_MASTER bit is asserted.

13. Diagnostics, Error Handling, and Runtime Monitoring

13.1 DEM Events for Time Synchronization

DEM Event	Trigger Condition	Example DTC	Healing Condition
ETHTSYN_E_SYNC_LOSS	No Sync received for SyncReceiptTimeout intervals	0x902100	3 consecutive Sync received successfully
ETHTSYN_E_ANNOUNCE_LOSS	No Announce received for AnnounceReceiptTimeout intervals	0x902101	1 Announce received
ETHTSYN_E_PDELAY_ASYM_FAULT	Pdelay exceeds latency threshold for N consecutive measurements	0x902102	Pdelay within threshold for 3 measurements
STBM_E_SYNC_LOSS	StbM SyncLossTimeout expired — time base coasting	0x902200	Time base updated by EthTSyn within timeout
STBM_E_TIMELEAP	TIME_LEAP_FUTURE or TIME_LEAP_PAST flag set in StbM	0x902201	3 consecutive updates without leap

13.2 Det Error Reporting

Development Error Tracer (DET) errors in EthTSyn and StbM catch programming errors during integration testing:

• ETHTSYN_E_UNINIT: Called before EthTSyn_Init() was executed.
• ETHTSYN_E_INVALID_CONTROLLER_IDX: Invalid Ethernet controller index passed.
• STBM_E_PARAM_POINTER: NULL pointer passed where a valid pointer is required.
• STBM_E_INVALID_TIMEID: TimeBaseId not within the configured range.

14. Testing and Validation Strategies

14.1 Unit Testing

Unit tests for EthTSyn and StbM should cover the following scenarios:

• Correct offset computation for known t1, t2, peer delay inputs – verify against hand-calculated values.
• Rate ratio application: inject a synthetic rate ratio of 1.000100 (100 ppm fast) and verify that StbM_GetCurrentTime() returns values advancing at the corrected rate.
• Timeout handling: do not call SetGlobalTime() for SyncLossTimeout + epsilon and verify STBM_TIMEOUT bit is set.
• Time leap detection: inject a SetGlobalTime() with a value 100 ms ahead of current and verify STBM_TIME_LEAP_FUTURE is set.
• BMCA correctness: inject Announce messages with varying priority fields and verify EthTSyn transitions to the correct master/slave state.

14.2 Hardware-in-the-Loop (HiL) Testing

Recommended test scenarios with real Ethernet hardware:

1. Synchronization convergence time: From power-on to STBM_SYNC_TO_GLOBAL_MASTER set. Target: < 2 seconds.
2. Steady-state accuracy: Measure the difference between the GrandMaster’s time and the slave’s StbM time over 10 minutes. Target: < 1 µs (sub-100 ns for ADAS).
3. Master failure and recovery: Pull power from GrandMaster ECU; verify slave transitions to TIMEOUT within SyncLossTimeout; restore power; verify re-synchronization within 3 Announce intervals.
4. Network cable unplug / replug: Verify peer delay remeasurement and resynchronization after link restoration.
5. Temperature sweep: Test synchronization accuracy at −40°C and +125°C to characterize oscillator drift under worst-case automotive conditions.

14.3 Network Analysis with Wireshark

gPTP traffic is visible in Wireshark with the PTP dissector enabled (EtherType 0x88F7). Key measurements to capture:

• Sync interval: Verify actual interval matches configured EthTSynSyncInterval.
• Follow_Up latency: Time between Sync and Follow_Up frames should be < 1 ms.
• Pdelay_Req/Resp turnaround: Should be < 100 µs for a direct link with hardware timestamping.
• Announce interval and content: Verify Priority1, ClockClass, ClockAccuracy fields.
• correctionField accumulation: For multi-hop chains, verify transparent clocks are correctly adding forwarding delay.

15. Common Pitfalls and Best Practices

15.1 Most Frequent Mistakes

Pitfall	Root Cause	Solution
Software timestamps used in production	Hardware timestamp not enabled in Eth driver config or HW not supported	Always verify EthTSynHardwareTimestampSupport=true and validate with network analyzer
SyncLossTimeout too short	Busy network or high-latency switch causes occasional sync gaps	Set SyncLossTimeout >= 3 × SyncInterval + max jitter margin
PeerDelay filter not long enough	Noisy measurements cause inaccurate delay estimate and offset jitter	Use N=8 or N=16 filter samples; verify with long-term capture
BMCA priority not configured on all ECUs	Default Priority1=128 for all nodes; undefined master election result	Set explicit Priority1 values reflecting the intended time hierarchy
Time base ID mismatch between EthTSyn and StbM	EthTSyn updates TimeBaseId=1 but SWC reads TimeBaseId=0	Cross-check all TimeBaseId references in integration configuration
Asymmetric Ethernet cable or connector delay	Mismatched cables introduce differential delay between TX and RX paths	Use matched-length cables; calibrate asymmetry and apply EthTSyn correction
Not checking StbM status before using time	SWC uses time value even when TIMEOUT bit is set (time coasting)	Always check STBM_SYNC_TO_GLOBAL_MASTER flag before safety-critical time use

15.2 Best Practices Summary

1. Always use hardware timestamping in production – software timestamps degrade accuracy by 2–3 orders of magnitude.
2. Design the time synchronization hierarchy before specifying EthTSyn configurations – know which ECU is GrandMaster, which are slaves, and which are bridges.
3. Use DEM events and StbM status flags in safety monitors – never silently ignore synchronization loss in safety-relevant functions.
4. Test synchronization accuracy at automotive temperature extremes – thermal drift is the primary long-term error source.
5. Document time base IDs centrally in the E/E architecture specification – mismatches are one of the most common integration bugs.
6. Validate gPTP behavior with a network analyzer on every new hardware platform – oscillator and MAC behavior varies significantly.

16. Real-World Use Cases Across Vehicle Domains

16.1 ADAS Perception Fusion ECU

A Level 3 autonomous driving perception stack integrates inputs from 6 cameras, 5 radars, and 2 LiDARs. Each sensor has its own local timestamp. The fusion algorithm requires all sensor inputs to be aligned to a common timeline with accuracy better than 500 µs to correctly compute object positions and velocities.

Architecture: All sensor ECUs are connected to a 100BASE-T1 Ethernet star through a TSN-capable managed switch. The central ADAS domain controller runs gPTP GrandMaster. All sensor ECUs run EthTSyn slave. The switch implements transparent clock functionality with hardware timestamp correction.

StbM configuration: All sensor ECUs expose StbM TimeBase 0 (domain global time). The fusion algorithm calls StbM_GetCurrentTime(0, …) to get the current time and uses it to correct sensor timestamps to the common timeline. If any sensor ECU’s TimeBase 0 has STBM_TIMEOUT set, the fusion algorithm excludes that sensor’s data from the fusion set and triggers a diagnostic event.

16.2 V2X Gateway with GPS GrandMaster

A V2X communication unit requires UTC-traceable time accuracy better than 1 µs for ETSI ITS Cooperative Awareness Message (CAM) generation. A dedicated GNSS receiver provides GPS time with < 100 ns accuracy. The V2X gateway acts as GrandMaster for the vehicle network, distributing GPS-disciplined time to all ECUs.

The GPS driver calls StbM_SetGlobalTime() every PPS (1 pulse per second) from the GNSS receiver, providing an absolute UTC-traceable time step with low jitter. EthTSyn on the gateway’s backbone port then distributes this time to all connected ECUs. StbM TimeBase 1 is configured as a UTC offset time base (parent=TimeBase 0, offset=current leap seconds).

16.3 Electric Powertrain Multi-ECU Control

An electric axle drive system uses three ECUs: inverter controller, battery management system, and thermal management controller. These must coordinate current commands and thermal derating decisions with timing accuracy better than 500 µs.

The powertrain domain controller is connected to the backbone Ethernet and runs an EthTSyn slave that synchronizes its StbM TimeBase 0 to the vehicle global time. It then acts as CanTSyn master on the CAN bus, distributing time to the three powertrain ECUs. Each powertrain ECU’s StbM TimeBase 0 is updated by CanTSyn, achieving an end-to-end accuracy of approximately 200 µs from GPS GrandMaster to CAN slave.

17. Future Trends: TSN, 5G V2X, and AUTOSAR Adaptive

17.1 Time-Sensitive Networking (TSN)

TSN is a set of IEEE 802.1 standards that collectively enable deterministic, low-latency Ethernet communication. gPTP (IEEE 802.1AS) is the time synchronization component of TSN, but TSN also includes traffic shaping (802.1Qbv – Time-Aware Shaper), frame preemption (802.1Qbu), and reliability (802.1CB – Frame Replication). All of these mechanisms depend on a synchronized time base to operate correctly.

As automotive architectures migrate to TSN-capable switched Ethernet backbones (common in vehicles from 2025 onward), the accuracy requirements on gPTP become even more stringent. 802.1Qbv time gates require synchronization accuracy better than ±500 ns across all nodes in a TSN network. This demands careful hardware selection, validated asymmetry correction, and comprehensive HiL testing.

17.2 AUTOSAR Adaptive and ara::tsync

AUTOSAR Adaptive Platform replaces the Classic BSW with a POSIX-based middleware. The time synchronization service is provided by the ara::tsync Functional Cluster, which offers:

• A C++ API for time base consumption: ara::tsync::SynchronizedTimeBaseConsumer.
• Support for multiple time domains with individual quality indicators.
• Integration with the adaptive platform’s Service-Oriented Architecture (SOME/IP) for time base distribution.
• Full compatibility with Classic Platform time bases through cross-platform bridges.

The underlying protocol remains gPTP (IEEE 802.1AS), ensuring interoperability between Classic and Adaptive nodes on the same Ethernet network. EthTSyn in Classic BSW and ara::tsync in Adaptive can share the same gPTP GrandMaster and produce synchronized time bases that SWCs on both platforms can consume.

17.3 Towards Nanosecond Accuracy

The industry is actively pushing toward sub-100 ns and eventually sub-10 ns synchronization accuracy for future autonomous driving applications. Emerging technologies enabling this include:

• White Rabbit Protocol extensions to gPTP: Originally developed at CERN, providing sub-nanosecond accuracy through DMTD (Dual Mixer Time Difference) circuits.
• GNSS-disciplined hardware oscillators (GPS-disciplined OCXO): Oven-controlled crystal oscillators steered by GPS PPS with Allan deviation in the 10⁻¹² range.
• Hardware-assisted asymmetry compensation: Emerging Ethernet PHY chips that measure the TX/RX propagation asymmetry directly in hardware and report it to gPTP stacks.
• Deterministic Ethernet switching with cut-through forwarding: Reducing switch latency from microseconds to nanoseconds, dramatically reducing bridging delay contributions to synchronization error.

Conclusion

AUTOSAR time synchronization is a discipline that spans physics, hardware design, protocol engineering, software architecture, and safety validation. From the humble quartz crystal that drives every ECU’s clock to the nanosecond-accurate gPTP messages flowing through automotive Ethernet switches, every component in the stack contributes to – or detracts from – the final accuracy delivered to application software.

This PiEmbSysTech Insight deep dive has covered the complete end-to-end picture: the physics of clock drift, the mechanics of IEEE 802.1AS gPTP, the architecture of EthTSyn and its hardware timestamping interface, the StbM time base management API, the BMCA master election algorithm, SoK and offset time bases, configuration parameters, diagnostics, testing strategies, and real-world automotive use cases.

The key takeaways for practitioners: always use hardware timestamps in production, design the time hierarchy before writing configuration, monitor StbM status flags in safety-critical paths, and validate your synchronization accuracy with real measurement equipment at automotive temperature extremes. Do not treat time synchronization as an afterthought in the E/E architecture design – it is foundational infrastructure on which every distributed, time-sensitive function in the vehicle depends.

As vehicles become more software-defined and autonomous, the demands on time synchronization will only intensify. Engineers who understand this stack deeply – from gPTP frame structure to StbM rate correction algorithms – will be indispensable contributors to the safe and reliable vehicles of tomorrow.