Zonal architecture
An E/E architecture that organizes vehicle electronics by physical zone, with zone controllers aggregating local I/O and central computers running the logic.
A zonal architecture organizes a vehicle’s electronics by physical location rather than by function. Zone controllers — typically two to six, placed front/rear or by corner — aggregate local sensors, actuators and power distribution, while the actual application logic runs on one or more central computers.
This contrasts with the domain architecture, where electronics are grouped by function (powertrain, body, infotainment) regardless of where components sit in the car. The main gains are wiring and scalability: because devices connect to the nearest zone controller instead of a function-specific ECU across the car, the wiring harness gets shorter, lighter and cheaper to assemble, and software becomes largely independent of vehicle topology. The cost is complexity elsewhere — zonal designs depend on high-bandwidth automotive Ethernet backbones, time-sensitive networking, and rigorous separation of safety-critical and non-critical traffic on shared infrastructure.
Inside a zone controller
A zone controller does three jobs at once. First, it is an I/O concentrator: door modules, seat motors, lights, local sensors and switches connect to it over short runs of CAN, CAN FD, LIN or low-speed Ethernet, and the controller translates between those edge networks and the vehicle’s Ethernet backbone. Second, it is a power distributor: instead of routing every load back to central fuse boxes, the zone controller feeds nearby consumers directly, increasingly through solid-state switches (“e-fuses”) that software can monitor, reset and use for selective wake and sleep of parts of the car. Third, it can host local logic — time-critical control loops or simple body functions that do not justify a round trip to the central computer.
Combining these roles is what makes the box economical. A zone controller replaces sections of the fuse box, several gateways and a handful of small body ECUs in one location, which is why zonal designs are usually justified on part count and harness savings rather than on computing power.
The network that makes zones possible
Zonal designs stand on automotive Ethernet. Single-pair standards — 100BASE-T1 and 1000BASE-T1 for the backbone, with multi-gigabit links where camera and sensor data demand it — connect zone controllers to central compute, while 10BASE-T1S offers an Ethernet alternative to CAN at the edge. Interoperability specifications for these physical layers are maintained by the OPEN Alliance, an industry group whose members include most major OEMs.
Ethernet alone does not guarantee that a brake signal arrives on time when the same cable carries video streams. That is the role of time-sensitive networking (TSN), a family of IEEE 802.1 standards providing bounded latency, time synchronization and traffic shaping so that deterministic control traffic and best-effort data can share one physical network. Configuring TSN correctly across all zones is one of the genuinely new engineering disciplines a zonal design imposes: the network schedule itself becomes safety-relevant.
Legacy buses do not disappear. CAN, CAN FD and LIN remain the pragmatic choice for simple sensors and actuators, terminating at the nearest zone controller instead of crossing the vehicle.
What zones buy: the harness case
The wiring harness is among the heaviest and most expensive single components in a car, containing kilometers of wire, and it is one of the last major assemblies still built largely by hand. Function-oriented architectures make this worse: a body ECU behind the dashboard needs wires to every door, light and motor it controls, wherever they sit. In a zonal layout each device connects over the shortest possible path, so total wire length, connector count and weight all drop, and the harness can be split into per-zone sections that are simpler to manufacture, easier to automate and easier to install on the assembly line.
The second gain is scalability. Because the backbone and zone interfaces are stable, adding a sensor or feature to a new model variant means wiring it to the nearest zone rather than redesigning function-specific harness runs. Application software running on the central computer addresses abstracted I/O and does not care which zone a device hangs on — a precondition for reusing one software platform across vehicles of different sizes and body styles, and thus for the software-defined vehicle generally.
The hard parts
Zonal architectures concentrate risk as well as wiring. A zone controller that distributes power and I/O for a quarter of the car must meet safety requirements while staying cheap enough to deploy four or six times per vehicle. Power distribution becomes a software problem: safety-relevant loads need redundant supply paths, and the failure behavior of e-fuses must be understood as thoroughly as that of the melting fuses they replace. Mixed-criticality networking, as noted above, makes network configuration part of the safety case.
Migration is the other obstacle. OEMs carry long-running supplier contracts, validated legacy ECUs and organizational structures shaped around functional domains. Most therefore introduce zonal elements stepwise on new platforms rather than switching an existing vehicle line, and hybrid layouts — zone controllers coexisting with domain controllers and legacy ECUs — are the norm in the transition. The umbrella E/E architecture entry covers this evolution path.
Who has shipped it
Tesla is widely credited with the first high-volume move in this direction, placing body controllers by location (front, left, right) from the Model 3 onward and integrating power distribution into them. Rivian drew attention with the redesigned electrical architecture of its refreshed platform, which cut the number of ECUs substantially by consolidating into zonal controllers. Several Chinese OEMs have brought zonal designs to market quickly on new EV platforms, and most established manufacturers have announced zonal or zonal-hybrid architectures for platform generations arriving in the second half of the decade. As of 2026, zonal is the stated destination across the industry; fully zonal production vehicles remain the exception rather than the rule.
Recent coverage
Related: Central compute / HPC · Domain controller · E/E architecture