A nanosecond is thirty centimetres: automotive time synchronisation has become a safety function

Light travels about thirty centimetres in a nanosecond. For most of the history of the in-vehicle network, that number was trivia. A radar sensor measured range against its own local oscillator, ran its own signal processing, and published a tidy list of objects onto the bus. Whatever the network believed the time to be had no bearing on where the vehicle thought the lorry ahead of it was.

That has quietly stopped being true. As radar migrates from self-contained smart sensor to satellite front end streaming raw data to a central computer, and as several radars are operated coherently as one large virtual aperture, the vehicle's shared notion of time stops being housekeeping metadata and becomes part of the measurement chain. The clock has become a sensor. Most production time synchronisation budgets were written before anyone assumed it would be.

The sensor that stopped being a sensor

The direction was on full display at CES 2026. On 5 January, Texas Instruments introduced the AWR2188, a single-chip 4D imaging radar transceiver with eight transmitters and eight receivers, detecting beyond 350 metres and explicitly supporting satellite architectures in which the transceiver hands raw point cloud data upstream rather than compressing it into an object list at the edge. Alongside it came the TDA5 compute family, scaling from 10 to 1,200 TOPS to ingest more than ten cameras plus multiple radar and lidar streams at once, and a 10BASE-T1S PHY intended to push Ethernet out to cheap edge nodes.

Push that logic further and you arrive at distributed aperture radar. Angular resolution follows aperture, and aperture follows physical separation, so operating several ordinary radars coherently as one instrument buys the resolution of a very large antenna without building one. NXP and Zendar have been developing exactly this, and NXP reports azimuth resolution of 0.5 degrees or better from coherently fused standard sensors, against the 2 to 4 degrees typical of a conventional radar.

The catch is what coherence demands. As NXP engineers Don Pannell and Rajeev Roy laid out at IEEE Ethernet and IP at Automotive Technology Days in November 2022, coherent radars must share the same notion of time of day to start their chirp sequences together. Their conclusion was blunt: timing inaccuracy is directly related to the error in the estimated distance to the target, and relative frequency drift between the units makes a stationary object appear to move. The clock is not supporting the measurement. It is inside it.

The budget was written for loudspeakers

Here is where the gap opens. The gPTP accuracy budget the industry inherited comes from Audio Video Bridging: IEEE 802.1AS was specified to hold any two nodes within 500 nanoseconds of each other across seven hops on 100 Mb/s links, with single-hop accuracy of about 71 nanoseconds, assuming local oscillators of 100 parts per million with up to 1 ppm per second of drift. It was a good budget, set so that loudspeakers in a car stayed in phase.

Convert it. Five hundred nanoseconds of relative clock error corresponds to roughly 150 metres of apparent path length. For a coherent radar pair that is not a tolerance, it is the entire measurement. Coherent operation needs the sub-nanosecond region, three orders of magnitude tighter than the inherited budget.

The network alone does not close that gap. Pannell and Roy's analysis shows what tuning buys: dropping the downstream pDelay interval to 125 ms gives roughly five times lower worst-case dynamic time error, halving the sync interval to 62.5 ms reaches ten times, and tightening local crystal drift to 0.5 ppm per second reaches about fifteen. Fifteen is hard-won engineering. It is not a thousand. Coherence needs the network budget, better oscillators and clock recovery working together, which is why the same presentation points at IEEE 1722's Clock Reference Format driving a tunable local PLL. Accurate time is a system architecture decision, not a configuration parameter.

Time as a single point of failure

Accuracy is only half of it. Availability is where the architecture looks most exposed. A gPTP domain has a grandmaster, and everything downstream slaves to it. Standardised redundancy for that role arrived remarkably recently: IEEE 802.1ASdm-2024, "Hot Standby and Clock Drift Error Reduction", is the first IEEE standard to define hot standby for gPTP, running primary and secondary grandmasters in coexisting time domains with a selection function between them. Anything designed earlier used proprietary redundancy or none.

The arithmetic of losing time is unforgiving. A 100 ppm oscillator accumulates 100 microseconds of error per second of free running, roughly six milliseconds after a minute without a sync message. A University of Waterloo simulation held nodes within about 100 nanoseconds of each other in normal operation, then showed a single switch declining to forward sync messages leaving the ECU behind it ticking on its own drift, invisibly wrong. Work published at IFIP Networking 2026 by researchers at the University of Hamburg puts numbers on the adversarial case: gPTP lacks integrity protection, and injected per-message offsets of five microseconds accumulated to over 100 microseconds of divergence within one second, at which point more than 80 percent of credit-based-shaper flows missed their deadlines even with a 10 percent tolerance.

What the recall record already shows

None of this is hypothetical, even if the specific failure has not yet produced a headline recall. On 23 March 2026, NHTSA acknowledged campaign 26V165, covering 254,640 Ford and Lincoln vehicles whose Image Processing Module A could experience multiple unexpected resets, taking the rearview camera image, pre-collision assist, lane-keeping assist and blind-spot monitoring with it. Trade reporting on the filing indicates the module misbehaved most readily when tracking many moving objects at once. The remedy was a software update.

That is not a clock defect and should not be described as one. It is something more instructive: a real-time property that held comfortably in the average case and failed in the tail, precisely when the scene was busiest and the function mattered most. Timing failures look like this. They surface in the worst five seconds of a driver's month, not in bench validation.

What to watch

The useful question for anyone specifying a next-generation platform is whether the time base is treated as plumbing or as a function with its own safety requirement.

Watch whether requirement specifications separate time domains by purpose, with microsecond-class accuracy for control and logging and a far tighter budget for coherent sensing, rather than one global figure for the whole vehicle. Watch whether the grandmaster attracts an explicit ASIL allocation, and whether platforms define what perception should do when time is lost: degrade to single-sensor operation, invalidate fused output, or carry on unaware. Watch for IEEE 802.1ASdm hot standby in 2027 and 2028 platform requirements and switch silicon roadmaps, the clearest signal that OEMs have recognised the grandmaster as a single point of failure. Watch how synchronisation is validated, because mean offset on a bench at room temperature says little about worst-case dynamic time error across the thermal range under peak load. And watch integrity, since AUTOSAR has been extending secure global time synchronisation while the protocol underneath still ships unauthenticated in most designs. Note too that every cheap multidrop node pushed out to the vehicle edge joins the same time domain, and each is another place a timestamp can be captured badly.

The industry has spent a decade arguing about how much compute the software-defined vehicle needs and how many gigabits its backbone should carry. The measure that has quietly become just as load-bearing is how well, and how reliably, all of it agrees on what time it is. So, a question for whoever writes the next platform specification: should the vehicle's time base be specified, rated and validated as a safety function in its own right, or is treating it as network infrastructure still good enough?

---

This piece first appeared in ASG's Hello, Auto! newsletter on LinkedIn.