By ATN Editorial Team
A zonal E/E architecture is a vehicle electrical and electronic architecture in which controllers are grouped by their physical position in the vehicle rather than by the function they perform, so each zone controller handles local power distribution and the sensor and actuator connections for its corner of the car and passes data to a small number of central computers over a high-speed backbone. A zone ECU is the controller that does that job inside one zone, and the two terms are not interchangeable: the architecture is the topology, and the zone ECU is one box within it. Conflating them is one of the most common errors in trade coverage of software-defined vehicles, and the distinction is practical: the architecture decision turns on harness mass, material cost and assembly as much as on compute, while a zone ECU is specified around I/O count, power distribution, networking and functional safety.
The vocabulary reached a wider audience on 31 August 2026, when Nissan and Honda agreed to standardise the core ECUs of their next-generation software-defined vehicles, along with the in-vehicle operating system, key middleware and vehicle control software. The release defines its terms only in a footnote: high-performance main ECUs that use SoCs, and zone ECUs that oversee each area of the vehicle. It is planned for both companies’ vehicles from fiscal year 2029 onward.
What is a zonal E/E architecture?
A zonal architecture organises a vehicle’s electronics by physical position, and the rule is as literal as it sounds. A device is generally connected to the zone controller serving the area it sits in, regardless of what it does, so a door lock, a seat motor and a corner radar in the same part of the vehicle can share a controller because they share a location rather than a purpose. Locality is the primary organising principle in a zonal architecture rather than an absolute one, and bandwidth, latency, safety and packaging all produce exceptions.
The zone controller is a hub more than a decision maker. As onsemi puts it, instead of separate ECUs for central locking, lighting or climate control, the central compute unit makes the decisions while zone controllers carry them out.
What is a zone ECU, and how does it differ from a domain controller?
A zone ECU is the controller connecting the actuators and sensors in its physical zone to a central compute ECU. NXP’s definition adds a useful qualifier: depending on how applications are distributed, a zone ECU can also have a significant role in strategy within its zone, so it is not always a simple concentrator.
In practice a zone ECU does three jobs: it can distribute electrical power locally, using smart high-side switches and electronic fuses rather than relying solely on a conventional central fuse box; it provides the physical I/O for the sensors and actuators in its zone across CAN, LIN and low-speed Ethernet; and it acts as a gateway between those local buses and the vehicle backbone.
A domain controller groups by function, so powertrain, chassis, body and infotainment each get their own. A zone ECU groups by geography. The consequence is in the wiring: a domain architecture is organised primarily around function rather than location, which can leave long harness runs between distributed components and their domain controller, whereas in a zonal architecture the wire follows the shortest path to the corner.
These are stages rather than rivals. Distributed came first, each feature arriving as its own ECU and its own wiring, producing what onsemi calls an ever more complex web of 100 to 150 ECUs in a single vehicle. Grouping them into functional domains cut the controller count but left the wiring problem largely intact. Only the zonal stage abandons function as the organising principle for the harness.
Why zonal architecture is a wiring harness decision
Zonal designs are usually explained as a computing story. They are more accurately a manufacturing story: the numbers that justify a programme are mass, material cost and assembly labour. Zone count is itself a design variable rather than a convention, with NXP’s reference material built around four corner zones and academic modelling examining anything from two to ten.
LEONI estimates that the weight of a comprehensively optimised zone architecture could be reduced by 20 to 30 per cent against today’s customer-specific harnesses, and expects the approach to push automation in harness production to well over 50 per cent, because smaller, more standardised sub-harnesses are easier to build by machine and quicker to install. The qualifier “comprehensively optimised” carries weight there.
Independent modelling supports the direction, with a caveat. A 2024 study in Sensors compared zonal architectures of two, four, six, eight and ten zones against a five-domain architecture, scaling ECU count from 20 to 120, and found a six-zone architecture cut total harness length by 45.5 to 55.1 per cent, an eight-zone architecture by up to 61 per cent. These are simulated and theoretically derived figures for an abstracted medium-sized vehicle rather than production measurements, so they indicate scaling behaviour rather than supplying a number for a business case.
The same study contains the trade-off an engineer needs and a supplier deck tends to leave out. More zones is not monotonically better. In simulation, average end-to-end delay for the highest-priority command-and-control traffic held at 23.14 microseconds for architectures of two, four and six zones, then rose by about 76 per cent to 40.74 microseconds at eight and ten zones. The study attributes the rise to traffic traversing a larger number of zone controllers, and the mechanism behind that is ordinary switched-network behaviour: each additional hop adds store-and-forward frame processing and queuing delay. Zone count is therefore a trade-off between wiring efficiency and network latency, and the right answer depends on which time-sensitive functions the architecture has to carry.
Two enabling technologies make the arithmetic work. The first is automotive Ethernet at the edge. 10BASE-T1S, standardised as IEEE 802.3cg-2019, runs 10 Mbit/s over a single unshielded twisted pair in a multidrop topology, supporting at least eight nodes on a bus of up to 25 metres and using physical layer collision avoidance, or PLCA, to give controlled access to the shared medium with bounded latency. Eight nodes is the standard’s floor rather than its ceiling, so low-bandwidth devices such as door locks and turn signals can share one pair instead of each taking a point-to-point run, while higher-bandwidth links use 100BASE-T1 or 1000BASE-T1. The second enabler is moving power distribution into the zone controller itself. onsemi describes smart high-side switches giving channel-level voltage and current monitoring, supporting functional-safety designs that target ASIL B or ASIL D depending on the device and the system around it, and offering fail-safe and fail-operational modes. The practical difference from a thermal fuse is that the switch need not simply open and stay open: onsemi’s own example is a device that reduces power, isolates the fault or enters a safe fallback state rather than shutting a critical load down. Suppliers expect zonal power distribution and 48 V nets to converge, though adoption across shipped vehicles is not published.
Where the compute sits, and the redundancy problem zonal creates
Concentrating vehicle behaviour in one or two high-performance computers is what makes the rest of the software-defined vehicle possible. Volkswagen Group China’s China Electronic Architecture, in series production since January 2026 on the VW ID. UNYX 07, cuts electronic control units by around 30 per cent against previous vehicle generations. Volkswagen calls it the Group’s first zonal electronic architecture and claims to be first to deploy one at scale across multiple platforms, which this piece has not independently established. The CEA is fully over-the-air updateable and spans all powertrain types, and because the functional software sits centrally rather than in each component, hardware can be reused across programmes while the feature set changes after build. Volkswagen reports 18 months from concept to production, development cycles shortened by up to 30 per cent and development costs for new models cut by up to 50 per cent in selected key projects.
The layer that makes this work is the middleware. AUTOSAR’s Adaptive Platform follows a service-oriented architecture in which a service may sit on the local ECU running the application or on a remote one, and in AUTOSAR’s own words the application code is the same in both cases, because the communication infrastructure provides transparent communication. That is the abstraction zonal design exploits: once software stops caring which box it runs in, consolidating the boxes becomes an economic decision rather than a functional one.
The constraint is the SoC. A high-performance computer has to run mixed-criticality workloads, from infotainment to ASIL-rated vehicle control, so the SoC decision fixes the architecture around it and is taken very early: the Nissan and Honda architecture, announced in August 2026, is planned for application from fiscal year 2029 onward.
Concentration also creates the safety problem. In a distributed vehicle, a failed body control module took out one function; in a zonal vehicle, a failed zone controller can take out everything electrically downstream of it. Fail-operational behaviour, meaning the ability to keep delivering a function after a defined fault rather than simply failing safe, therefore has to be designed at architecture level rather than bought in a component. It matters most for functions with no simple mechanical fallback, such as steer-by-wire and some brake-by-wire implementations, which need enough redundancy in power, communication and computing to meet their safety targets after a defined fault. No single device provides that: zone-level power distribution is one part of a fault-tolerance strategy spanning independent supply paths, redundant networking and the compute itself. Allegro MicroSystems lists thermal and power management at zone level among the integration challenges, which matters because zone controllers can end up in thermally awkward locations.
Why production vehicles rarely run a pure zonal architecture
The clean diagram of simple zone controllers and one central brain is better understood as an architectural target than as a description of most production vehicles.
onsemi is unusually direct about why. Not all edge modules can be completely stripped of intelligence, because some components, advanced lighting among them, still need local processing for performance, safety or proprietary reasons, and tier ones deliver those modules with embedded software because they hold the knowledge of how to control them. The result is split responsibility, with the carmaker owning central compute software and the tier one owning module software, and onsemi concludes that a pure, software-only central brain is a goal but that compromises are often necessary.
LEONI expects the same gradualism on the hardware side, describing the change as a smooth transition rather than a disruptive one. Its phase two, the zonal approach 1.0, is explicitly a multi-domain architecture combined with a few high-performance computers, gaining momentum from 2025, while phase three, aligning functional zones with the OEM’s own production modules, is expected to matter from the end of this decade. What ships in the meantime is a hybrid, which is why apparently contradictory claims about who has a zonal architecture can both be true.
That is also why the Nissan and Honda agreement matters more than a routine collaboration announcement. Neither company has said so and the commercial outcome is unsettled, but the potential implication for suppliers is significant: if common ECU specifications translate into shared sourcing volumes, the economics of developing a zone controller change, because volume decides whether one is worth designing for a single programme or building as a platform part.
Frequently Asked Questions
A zonal E/E architecture groups vehicle controllers by physical location rather than by function. Each zone controller handles power distribution and sensor and actuator I/O for its area of the vehicle and communicates with one or more central computers over a high-speed backbone.
A zone ECU is the controller that serves one physical zone of the vehicle. It distributes power locally using smart switches and electronic fuses, provides the I/O for the sensors and actuators in that zone, and acts as a gateway between local buses such as CAN and LIN and the vehicle’s Ethernet backbone.
A domain controller groups functions, such as powertrain or body, regardless of where the components sit. A zone ECU groups components by location, regardless of what they do. Many production vehicles run both, which is why the terms are often used interchangeably and should not be.
LEONI estimates a 20 to 30 per cent reduction in harness weight for a comprehensively optimised zone architecture compared with current customer-specific harnesses. A separate quantity, harness length, was modelled in Sensors in 2024, which found reductions of 45.5 to 55.1 per cent for a six-zone architecture against a five-domain architecture depending on ECU count. Length and weight are not interchangeable, and the Sensors figures are simulation rather than measurement, so the two numbers should not be read as confirming each other.
Not strictly, but automotive Ethernet is the main enabler of the topology in practice, particularly for the higher-bandwidth backbone between the zone controllers and central compute, where 100BASE-T1 and 1000BASE-T1 are used. At the edge, 10BASE-T1S, standardised as IEEE 802.3cg-2019, lets at least eight devices share a single unshielded twisted pair over a bus of up to 25 metres. CAN and LIN continue to serve low-speed devices, depending on the architecture.
No. A software-defined vehicle is a software and lifecycle concept, and it depends on abstraction layers such as AUTOSAR’s Adaptive Platform, in which application code is unchanged whether a service runs on the local ECU or a remote one. A zonal architecture is the physical I/O and power topology that makes running that software on centralised compute economic. A vehicle can be zonal without being meaningfully software-defined, and an OEM can centralise software without rewiring the car.
For more software-defined vehicle news, click here.
Further Reading From The ATN Vehicle Architecture Library
- Nissan And Honda To Standardise Zone ECUs And SDV Software (Sep 2026)
- Volkswagen China Starts Production Of New CEA Zonal Architecture (Jan 2026)
- Stellantis STLA One Modular Vehicle Architecture Launches 2027 (May 2026)
- NXP And Rimac Technology Co-Develop Centralized Vehicle Architecture For SDVs (Jun 2025)
- TTTech Auto Introduces MotionWise Communication Middleware (Dec 2025)
- Snapdragon SoCs Underpin Volkswagen’s Future Software-Defined Vehicle Platform (Jan 2026)
- Brake-By-Wire Explained: How EMB And EHB Architectures Are Reshaping Chassis (May 2026)
- Who Owns Automotive Cybersecurity In A Software-Defined Industry? (May 2026)
