The Zonal Architecture Transition: How Automotive OEMs Are Rebuilding Systems Engineering From the Ground Up
The conventional vehicle electrical architecture — 70 to 150 discrete ECUs, each owning a bounded function, each sourced from a Tier-1 supplier with a bespoke requirements specification — was a systems engineering solution to a 1990s integration problem. It worked. It scaled. It produced the modern car. It is now one of the primary obstacles to the software-defined vehicle.
The shift to zonal architectures replaces that distributed model with a small number of zone controllers (typically four to six, each handling a vehicle region), one or two central compute platforms running the vehicle’s software stack, and high-bandwidth Ethernet backbones replacing the CAN and LIN networks that once connected everything. The functional advantages are real: lower wiring harness mass, software updates that propagate to the entire vehicle, faster feature iteration, and the ability to separate software lifecycles from hardware ones.
The systems engineering challenge is that the requirements infrastructure sitting underneath modern vehicle programs was not built for this topology. Every requirement specification, every interface control document, every DFMEA, every traceability matrix — they were authored against a distributed architecture. Migrating a vehicle platform means migrating all of that too, and that work is harder, slower, and more consequential than most program plans currently account for.
What a Distributed Requirements Hierarchy Actually Looks Like
To understand why the transition is difficult, it helps to be specific about what engineers are dealing with.
A typical body and convenience domain on a mid-size passenger vehicle will have somewhere between 800 and 1,500 system-level requirements decomposed from OEM specifications down to ECU-level requirements documents. Those ECU-level documents contain functional requirements, timing requirements, interface requirements (which signals arrive on which bus, at which cycle time, with which DBC encoding), diagnostic requirements (UDS services, DTCs, freeze frame formats), and hardware interface requirements (connector pinout, voltage thresholds, load specifications).
The vast majority of those requirements — particularly the interface and hardware requirements — are not abstract functional statements. They are descriptions of how a specific ECU accomplishes a specific function in a specific wiring topology. The requirement “Body Control Module shall respond to door handle capacitive touch signal within 30ms” contains embedded architectural assumptions: that there is a Body Control Module, that it receives a discrete signal from a sensor, and that 30ms is the right latency given the processing and communication overhead of that topology.
In a zonal architecture, there is no Body Control Module. The door handle sensor connects to a zone controller. The zone controller runs software that may or may not have been written by the same supplier. The latency budget is different because the communication path is different. The requirement is not just reallocated — it is structurally invalid.
How the OEMs Are Approaching This
BMW: Platform-Led, Model-Specific Migration
BMW’s E3 electrical architecture, which underpins current production vehicles, uses a domain-based structure that is one step removed from fully distributed but still heavily supplier-modular. The Neue Klasse platform, entering production in 2025-2026, moves to a more genuinely zonal model.
BMW’s approach to requirements migration has been to treat the Neue Klasse as a clean-sheet system architecture, with legacy platform requirements serving as a reference library rather than a migration target. System architects define vehicle-level and zone-level requirements from function-first principles, then cross-reference the legacy requirement set to identify coverage gaps and conflicts. The explicit goal is to avoid importing architectural assumptions from E3 into Neue Klasse requirements documents.
The practical challenge this creates is one of tribal knowledge. Requirements in legacy systems carry context that engineers understand intuitively but that is not written down. When those requirements are not carried forward, that context can be lost unless it is actively extracted. BMW has invested in what they internally call “function archaeology” — dedicated engineering time to reconstruct the intent behind legacy requirements before those requirements are retired.
Volkswagen: Group-Wide Standardization Attempting to Absorb Complexity
Volkswagen’s approach is structurally more ambitious and correspondingly more fragile. The E3 (not to be confused with BMW’s designation — VW uses it to mean a third-generation electrical architecture) effort spanning MEB, PPE, and SSP platforms attempts to define common zone controller interfaces that apply across brands including Audi, SEAT, Škoda, and Porsche.
This means the requirements migration problem is multiplied by the number of brand variants while also having to converge on a common interface layer. A requirement that exists in different forms for Golf, Tiguan, and Audi A4 must ultimately be traceable to a single zone interface specification, or variant management becomes uncontrollable.
The CARIAD software subsidiary was created in part to hold this integration layer. The dysfunction that became publicly visible in 2022-2024 — program delays, executive departures, the eventual restructuring — was partly a software delivery problem but was equally a systems engineering ownership problem. When OEM system architects, CARIAD software teams, and Tier-1 hardware suppliers all have partial ownership of requirements that cross their boundaries, traceability breaks down and integration failures become difficult to attribute.
VW’s revised approach post-restructuring has moved toward clearer architectural authority, with zone controller hardware and operating environments owned by VW/CARIAD and application-layer requirements negotiated with suppliers on that foundation.
Stellantis: STLA Architecture and the Multi-Brand Constraint
Stellantis faces a version of VW’s problem with less organizational infrastructure to support it. The STLA platform family (STLA Small, Medium, Large, Frame) is intended to serve Jeep, Ram, Dodge, Chrysler, Fiat, Alfa Romeo, Peugeot, Citroën, Opel, and Vauxhall. The electrical architecture targets four zone controllers and a central compute platform.
Requirements governance across that brand portfolio requires managing what engineers sometimes call “requirement dialects” — functional intents that are nominally the same but specified differently across brand engineering teams, often with incompatible interface assumptions. Jeep off-road feature requirements and Fiat urban mobility requirements may both trace to a zone controller capability, but they were written by separate organizations using separate tools with different verification conventions.
Stellantis has leaned heavily on the SmartCockpit and SmartCar compute platform architecture as integration anchors — defining zone interface requirements at the platform level and requiring brand teams to express their functional requirements in terms of those interfaces. This is architecturally sound but organizationally demanding, and implementation consistency across brands remains uneven as of 2026.
Toyota: Incremental Platform Evolution With Arene as the Integration Layer
Toyota’s approach is the most conservative and, arguably, the most executable in the near term. The Arene vehicle OS and the e-TNGA and updated platform families represent an incremental migration rather than a clean-sheet transition. Toyota is preserving significant elements of distributed ECU architecture while introducing zone controllers as an integration layer, rather than replacing the distributed model entirely.
This means Toyota’s requirements transition problem is different in character. Rather than a wholesale migration, they are managing requirements for a hybrid architecture in which some functions remain in domain ECUs and some have migrated to zone controllers. The traceability challenge is managing the handoff boundaries — ensuring that requirements allocated to legacy ECUs and requirements allocated to zone controllers maintain consistent coverage with no gaps and no contradictions.
The Arene OS strategy also has implications for requirements structure: Toyota is investing in defining requirements at the service interface level (following AUTOSAR Adaptive service-oriented architecture conventions) rather than at the signal level. This is a meaningful architectural shift in requirements methodology, not just in vehicle topology.
What Happens to the ECU-Level Requirements
The specific question of ECU-level requirement fate is worth addressing directly because it tends to be underspecified in program plans.
The typical disposition of an existing ECU-level requirement during a zonal architecture migration falls into one of four categories:
Functional reallocation: The requirement expresses a genuine function (e.g., “driver door shall unlock when valid passive entry credential is detected within 1.5 meters”) and can be rewritten at the zone controller service level with a revised but architecturally neutral interface.
Hardware requirement retirement: The requirement specifies hardware behavior that no longer exists (e.g., “BCM shall tolerate reverse battery protection to -14V DC”). If the zone controller handles protection differently, this requirement is retired and replaced, not migrated.
Interface requirement transformation: Signal-level interface requirements (CAN message IDs, cycle times, DBC entries) must be rewritten as service interface requirements in the new architecture. This is not migration — it is reauthoring.
Latency and timing budget recalculation: Many timing requirements embed assumptions about ECU processing capability and CAN bus arbitration. Moving to Ethernet-based zonal architectures changes the latency budget entirely. These requirements cannot be carried forward unchanged without verification that the new values are correct.
The mistake programs make is treating migration as a copy-and-allocate operation. It is closer to a validation exercise: for each legacy requirement, determine whether the underlying intent is captured correctly in the new architecture’s requirement set.
Supplier Ecosystem Implications
The supplier ecosystem is experiencing this transition as a simultaneous compression of scope and expansion of responsibility.
Traditional Tier-1 suppliers owned a bounded deliverable: a specific ECU with a defined requirements specification. That model is being replaced by one in which zone controllers are OEM-architected (or OEM-subsidiary-architected), and suppliers are asked to either deliver hardware to an OEM-defined interface specification or contribute software components to an OEM-defined software stack.
This is a requirements ownership problem. In the old model, Continental, Bosch, or ZF received a specification and produced a requirements-conformant deliverable. In the new model, the deliverable boundary is blurry: who owns the requirements for a software function running on OEM hardware that interacts with a sensor module from a different supplier through an OEM-defined service interface?
Several major Tier-1s have responded by building systems integration capabilities they previously did not need. Bosch’s cross-domain compute (CDC) architecture and Continental’s SDV platform efforts are partly technical responses and partly positioning moves — attempts to remain in the requirements ownership position rather than being pushed into component supply.
Smaller Tier-2 suppliers face a starker version of the problem. Their ECU deliverables may simply not have an equivalent in the new architecture. Requirements that once drove dedicated ECUs are being absorbed into zone controller software. This is accelerating consolidation in the Tier-2 supply base.
The Requirements Tooling Gap
One of the underappreciated bottlenecks in this transition is the mismatch between what existing requirements management tools were designed to do and what the transition actually requires.
The majority of automotive requirements management infrastructure runs on IBM DOORS or DOORS Next, with some programs on Jama Connect or Polarion. These tools are built around document-centric hierarchies: a parent requirement, child requirements, traceability links to tests and design artifacts. They work well when the system architecture is stable and the requirement hierarchy mirrors the module decomposition.
They work poorly when the architecture is in flux, when requirements need to be dynamically reallocated across a topology that is changing, and when engineers need to identify which requirements embed architectural assumptions versus which express architectural-neutral function intent.
The architectural transition to zonal systems is precisely the scenario where graph-based traceability models outperform document-based ones. When a zone controller requirement touches 40 legacy ECU requirements across three domains, you need to traverse that graph quickly, identify coverage gaps, and understand the impact of a change — not navigate nested folders in a document hierarchy.
Tools like Flow Engineering, which model requirements and system architecture as a connected graph with AI-assisted analysis, are better suited to the transition scenario: identifying orphaned requirements when a source ECU is deprecated, surfacing requirements that embed topology assumptions, and tracing coverage across a changing allocation model. The limitation is that these platforms require teams to rethink how they structure requirements, which is itself a change management challenge on top of an already demanding architectural transition.
Honest Assessment
The automotive OEM community is managing this transition with varying degrees of rigor, but all of them are grappling with the same fundamental problem: systems engineering methodology was built for stable architectures, and the zonal transition is an architecture in motion.
The OEMs that will execute best are the ones that treat requirements migration as a validation and reauthoring exercise rather than a copy-and-reallocate one — and that invest in the architectural authority structures to make clear who owns requirements at each layer of the new topology. The supplier ecosystem is under structural pressure that will not relieve until the new architecture stabilizes, which is still several program generations away.
The tooling will eventually catch up. The harder problem is organizational: software-defined vehicles require systems engineering organizations that think in services and architectures, not in ECU specifications and DBC files. That transition is slower and less visible than the architectural one, and it is where most programs will encounter the most friction.