The wiring harness is among the heaviest and most expensive things in a car, and a hundred scattered controllers is what makes it that way. Zonal architecture, a high-speed backbone and centralised compute exist to attack that — and the consequence is that the vehicle becomes a software platform whose functions are deployed, updated and sold after it leaves the factory.
One controller per function, added over decades. Every new feature added a box, a connector and more harness. Simple individually, unmanageable collectively, and the wiring became a dominant cost and weight problem.
Functions grouped by domain — powertrain, chassis, body, infotainment, ADAS — behind a controller each. Fewer boxes, but the harness still radiates from the centre to every sensor and actuator.
Controllers placed by physical location rather than by function. A zone controller aggregates whatever is near it and connects to central compute over a high-speed backbone. The harness shortens dramatically, which is the entire commercial argument.
Application software runs on a small number of high-performance computers, decoupled from the hardware it drives. This is what makes a vehicle software-defined: function is no longer welded to the box that implements it.
Ethernet supplies bandwidth. Determinism has to be added on top of it.
| Layer | What it provides | Why it is needed |
|---|---|---|
| 100BASE-T1 / 1000BASE-T1 | Ethernet over a single twisted pair | Automotive weight, cost and connector constraints |
| Multi-gigabit automotive Ethernet | Backbone capacity between zones and compute | Sensor data volumes that CAN cannot carry |
| 802.1AS — generalised PTP | A common time base across every node | Fusion, logging and control all assume shared time |
| 802.1Qbv — scheduled traffic | Guaranteed transmission windows | Control traffic must not queue behind a video stream |
| 802.1Qbu — frame preemption | Interrupting a long frame for an urgent one | Latency bounds on a shared link |
| CAN and CAN FD | Retained for low-rate, cost-sensitive nodes | Ethernet everywhere is neither necessary nor affordable |
Time synchronisation is the foundation. Without a common clock, scheduled traffic cannot be scheduled and fused sensor data cannot be aligned.
| Classic | Adaptive | |
|---|---|---|
| Runs on | Deeply embedded microcontrollers | High-performance processors under POSIX |
| Configuration | Static, fixed at build | Dynamic, services discovered at runtime |
| Communication | Signal-oriented, on CAN and similar | Service-oriented, SOME/IP or DDS over Ethernet |
| Suits | Hard real-time control, safety functions | Perception, infotainment, updatable applications |
| Updated | Rarely, and carefully | Expected to be, repeatedly, over the air |
A real vehicle runs both. The interesting engineering is at the boundary, where a service-oriented request has to become a deterministic signal.
Camera, radar, LiDAR and inertial aligned in time and space before any estimator runs. Surround view, parking and driver assistance functions build on that alignment.
IN-CABINInfrared fatigue and distraction detection, tuned for precision because a system that cries wolf is switched off. Occupant classification and child presence.
INFOTAINMENTDisplay and audio subsystems, connectivity, and the isolation that lets an infotainment domain share hardware with functions that must not fail.
NETWORKINGAutomotive Ethernet, IEEE 1588 and gPTP distribution, and bridging to the CAN and legacy diagnostic protocols that are not going away.
TELEMATICSCellular and GNSS, vehicle-network data, store-and-forward through coverage gaps, and the electrical robustness a vehicle demands.
SAFETYISO 26262 hazard analysis, ASIL decomposition, FMEDA and diagnostic coverage, with a safety manual stating the assumptions of use.
A vehicle whose functions are implemented in software running on centralised compute rather than welded to dedicated controllers, so capability can be deployed, updated and extended after the vehicle leaves the factory.
Principally the wiring harness. It is among the heaviest and most expensive components in a vehicle, and it is that way because a hundred function-specific controllers each need their own runs. Placing controllers by physical zone and connecting them over a high-speed backbone shortens the harness dramatically.
Ethernet supplies bandwidth but not determinism. Time-sensitive networking adds a common time base with generalised PTP, scheduled transmission windows and frame preemption, so control traffic is not queued behind a video stream.
Classic targets deeply embedded microcontrollers with static configuration and signal-oriented communication, suited to hard real-time control. Adaptive runs on high-performance processors under POSIX with dynamic service discovery, suited to perception, infotainment and updatable applications. Real vehicles run both, and the interesting engineering is at the boundary.
Yes. UNECE R156 requires a software update management system and R155 a cybersecurity management system for type approval in the regions that adopt them. Update capability moved from a product feature to a homologation requirement.
Quiescent current. A vehicle must start reliably after weeks unattended, which strictly bounds what may remain awake — usually a far harder constraint on remote features than the architecture itself.
Timing before estimator.
INDUSTRYSector constraints.
PRODUCTMixed-generation vehicle networks.
PRODUCTAutomotive Ethernet timing variant.
TECHNOLOGYISO 26262 and the safety case.
SOLUTIONTelematics, ADAS and in-cab sensing.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.