E/E architecture

E/E (electrical/electronic) architecture is the overall design of a vehicle’s electronics: which computers exist, how they communicate, how power is distributed, and where software runs. It is the skeleton every vehicle function hangs on, and one of the longest-lived engineering decisions an OEM makes — a given architecture typically underpins a model generation for close to a decade.

The industry describes an evolution in stages: distributed architectures with up to 150 single-function ECUs on CAN networks; domain architectures that consolidate by function; and zonal architectures that consolidate by location around central compute, connected by automotive Ethernet. Architecture choices determine what is possible in software — update capability, feature velocity, cybersecurity boundaries, wiring cost and even vehicle assembly sequence all trace back to the E/E design — which is why architecture announcements from OEMs are treated as strategic news rather than component news.

What an E/E architecture consists of

An E/E architecture spans four tightly coupled layers. The compute layer defines how many electronic control units (ECUs) the vehicle carries and how capable each one is, from small microcontrollers driving a single door module to multi-core systems-on-chip running full operating systems. The network layer defines how they communicate: legacy buses such as CAN, CAN FD, LIN and FlexRay at the edge, and increasingly automotive Ethernet as the backbone. The power layer distributes energy from the battery to every electrical load, traditionally through central fuse boxes and dedicated wiring, increasingly through software-controlled solid-state switches. The software layer determines where functions actually execute, how they communicate and how they are updated — which is where an electronics decision becomes a product-strategy decision.

These layers move together. A carmaker cannot centralize software without a network fast enough to carry sensor data to the compute, and cannot shorten the wiring harness without rethinking power distribution. This coupling is why E/E overhauls arrive with new vehicle platforms rather than as mid-cycle changes.

The evolution: distributed, domain, zonal

In the distributed model that dominated through the 2010s, each function shipped as its own ECU, usually developed and delivered by a supplier as a closed unit. Feature growth pushed ECU counts in premium vehicles past 100, with some programs above 150. The result was an integration burden: every new feature that touched several ECUs meant coordinating several suppliers, and the OEM often had limited visibility into the software it was selling.

Domain architectures were the first consolidation step, merging the ECUs of one functional area — driver assistance, cockpit, body and comfort, powertrain — into a powerful domain controller. Zonal architectures go further by reorganizing around physical location: zone controllers aggregate local inputs, outputs and power, while application logic moves to one or a few central computers. Most vehicles in production today sit between these stages, running hybrid layouts that mix legacy ECUs, domain controllers and early zonal elements.

Why the industry is centralizing

Three pressures drive the shift. The first is the wiring harness, one of the heaviest and most expensive components in a vehicle, containing kilometers of wire and assembled largely by hand. Distributed and domain architectures route wires by function across the whole car; location-based designs shorten them substantially, cutting weight, cost and assembly complexity.

The second is software. Integrating code spread across dozens of supplier-owned black boxes is slow and fragile, and it makes substantial over-the-air updates impractical. Consolidated compute lets the OEM own the software platform, decouple hardware and software lifecycles, and reuse one software stack across models — the foundation of the software-defined vehicle.

The third is capability. Functions such as automated driving fuse data from many sensors at once and need computing power no single-function ECU can offer. Centralized compute concentrates that power where the data converges.

The engineering trade-offs

Centralization moves complexity rather than removing it. Shared Ethernet backbones must carry safety-critical control traffic next to infotainment streams, which requires deterministic networking and careful bandwidth budgeting. Consolidated computers must host mixed-criticality software — brake-related logic beside navigation — with proven freedom from interference, typically through hypervisors and safety-rated partitions under ISO 26262. Removing dozens of fuse boxes and dedicated power lines demands intelligent, software-controlled power distribution with its own failure modes to manage.

The organizational cost is at least as large. Centralized architectures shift integration responsibility from suppliers to the OEM, and the difficulty of building that capability has been demonstrated publicly — Volkswagen’s widely reported struggles with its CARIAD software unit delayed several vehicle programs. An E/E architecture decision is therefore also a decision about what kind of engineering organization the carmaker must become.

Where the industry stands in 2026

No production vehicle is a single computer on wheels, and none is likely to be: even the most centralized designs keep zone controllers, smart actuators and dedicated safety microcontrollers. Tesla is widely credited with pushing location-based controllers into high volume first, and several Chinese OEMs have moved quickly toward centralized compute on new platforms. Most established OEMs are transitioning in steps, introducing zonal and central-compute elements with new vehicle platforms while carrying legacy and domain-based designs in parallel across their lineups. The direction of travel — fewer, more powerful computers connected by Ethernet — is no longer contested; the pace and the migration path are where strategies differ.

How the neighboring entries fit together

This page is the umbrella. The zonal architecture entry covers zones, zone controllers and the in-vehicle network in depth; the domain controller entry covers the functional-consolidation generation and why it is being superseded; the central compute entry covers high-performance computers, the SoC platforms behind them and the consolidation of software onto them.