Tutorial · vehicle E/E architecture
Zonal architecture, built up one step at a time
Zonal architecture reorganises a vehicle's electronics by where things are instead of what they do. Below, a conventional vehicle is converted into a zonal one in six steps. After that, the trade-offs are weighed honestly, and the same idea is compared against a real truck that was divided by subsystem, not by zone: the Kenworth T280 fuel-cell truck, Big Red.
01 — Tutorial
From one-ECU-per-function to zones
Step 1 of 6
Start: one ECU per function
Drawn as a teaching model. Fourteen ECUs and four zones keep the picture readable; production vehicles have many more functions, and zone counts vary by platform. The mechanism is what the figure shows accurately.
02 — Trade-offs
What zonal buys, and what it costs
Zonal architecture does not remove complexity — it moves it. Copper and connectors come out of the vehicle; software, networking and safety analysis move into the centre. Every "con" below has a known mitigation, and every mitigation has its own price.
Pros
Cons
Weighted fit
Each architecture's 0–2 fit per factor is my engineering judgement, shown in the row labels so it can be argued with. The weights are yours.
03 — Applied
Big Red as built, next to Big Red as a zonal design
The truck in the FCEV case study was not zonal. It was divided by subsystem: a supervisory controller in the cab, each subsystem's ECU near its hardware, six CAN buses and 12 V / 24 V fuse and relay maps running between them. Below is that layout next to how the same chassis would look if it had been organised by location instead.
Both layouts are schematic — component placement is for a box-body Class 6 truck, not the build drawing, and the as-built wire routes are simplified. The length figure is measured from the lines in this figure, so it compares the two drawings to each other; it is not a harness estimate for the real truck.
| On Big Red | As built · by subsystem | Zonal redesign |
|---|---|---|
| How the system is divided | by function — fuel cell, hydrogen, battery, eAxle, brakes, thermal | by position on the chassis — cab, mid-frame, rear axle |
| Supplier ECUs (fuel cell, eAxle, ABS, BMS, HVAC) | integrated as delivered | kept as smart nodes on zone-local CAN — replacing them needs their software |
| Supervisory logic | RCM112 supervisory controller | moves to central compute |
| 12 V / 24 V fuse and relay maps | hand-authored, relay boxes | eFuse channels in each zone, with current diagnostics |
| Parasitic draw and wake / sleep | solved per ECU, with a dedicated wake CAN | zones switch loads off centrally |
| Network load | over 85% on a shared segment, 60% after gateway re-segmentation | Ethernet between zones; CAN runs stay short |
| HV contactors, precharge, lock-out energy isolation | hard-wired | still hard-wired — not moved into software |
| Single point of failure | supervisory controller | central compute — needs a degraded mode |
| Software updates | six ECUs flashed individually | one coordinated release |
| Cost and schedule for a few prototype trucks | low | new zone hardware and software |
By subsystem was the right call for Big Red. Supplier ECUs were fixed, the program built a handful of trucks, and schedule was the constraint.
Zonal would have paid off at fleet volume. It removes the fuse-and-relay wiring between subsystems, makes wake / sleep a zone-level job and turns six separate flashes into one release — at the cost of new zone hardware, a central compute unit that needs a degraded mode, and owning more of the software. High-voltage isolation stays hard-wired either way.
Scope: the as-built column is the truck I worked on, which was divided by subsystem. The zonal column is design analysis — it was never built.