When the Controller Area Network (CAN) was first introduced to the automotive industry, it revolutionized vehicle design by dramatically cutting down heavy, complex wire harnesses. Today, we are standing at a very similar turning point with the shift toward Zonal Control Units (ZCUs).
Just like CAN did decades ago, Zonal Architecture solves the nightmare of messy cable harnesses. By reducing wiring, it not only lowers vehicle weight but also unlocks Robot-Ready Modular Manufacturing—allowing automated robots to assemble vehicles much more efficiently. More importantly, ZCU is a core prerequisite for the Software-Defined Vehicle (SDV) era, decoupling hardware from software.
Driven by these massive benefits, the industry is moving rapidly toward ZCU implementation. So, what does this mean for Tier-1 suppliers? How should they prepare for this architecture shift?
Zonal Architecture Transition: The Motivation and Real-world Hurdles
Automotive Electrical/Electronic (E/E) architectures are evolving from domain-based systems to zonal architectures. In domain architectures, Electronic Control Units (ECUs) are grouped by function, which requires massive point-to-point wiring. Today’s premium luxury vehicles can contain over 100 ECUs, resulting in copper wire harnesses that span up to 5 km and weigh over 50 kg. This heavy weight directly reduces the driving range of Battery Electric Vehicles (BEVs).
To solve these weight and packaging problems while enabling Software-Defined Vehicles (SDVs), the industry is moving toward Zonal Architecture. Zonal architecture groups the vehicle’s electronics by their physical location (zones) using Zone Control Units (ZCUs) connected to a central High-Performance Computer (HPC). In theory, this can cut wiring harness weight by up to 85% and significantly lower manufacturing costs.
However, except for a few tech-native automakers like Tesla or Rivian, most legacy OEMs cannot switch to a pure zonal architecture overnight. They are instead taking a gradual, step-by-step approach. Major technical barriers include communication delays between different networks, safety isolation risks under virtualization, the extreme complexity of migrating legacy software, and the unproven reliability of smart power distribution.
1. Mixed-Criticality System Integration & Hardware Virtualization Isolation Barriers
In older distributed architectures, safety-critical systems like braking (ASIL-D), steering (ASIL-D), and rear lights (ASIL-B) ran on separate physical ECUs with dedicated microcontrollers. In a zonal architecture, these different “virtual ECUs” (vECUs) are consolidated onto a single, high-performance multicore ZCU.
To prevent lower-priority software bugs (e.g., body diagnostics) from crashing safety-critical systems, developers must prove “Freedom from Interference” under ISO 26262. Standard software-based hypervisors add translation overhead and memory jitter, which are unacceptable for real-time control. Furthermore, conducting system-level worst-case analyses (FMEA/HARA) is extremely difficult because a single failure in a ZCU can impact multiple unrelated vehicle domains.
Tesla & Rivian’s Approach
- Tesla: Tesla bypassed commercial hypervisor packages entirely. They write their proprietary bare-metal operating system and schedule tasks using highly optimized, deterministic software algorithms developed in-house. By maintaining full control of the silicon scheduling, they run safety-critical body and powertrain commands with near-zero software translation overhead.
- Rivian: Instead of using commercial real-time operating systems (RTOS) or hypervisors to partition legacy code, Rivian built its own real-time operating system called Safe ARTUS. Safe ARTUS enables clean, native software partitioning directly on their in-house designed zonal controllers (East, West, South) without the overhead and debugging “obfuscation” of standard automotive software stacks.
Stakeholder Tasks & Solutions
- Traditional Tier-1 Suppliers (Infrastructure Integrators):
- Static Partitioning Hypervisors: Adopt lightweight, static-partitioning hypervisors that allocate dedicated memory and CPU cores to specific software at boot time, eliminating dynamic virtualization overhead.
- Error Isolation Middleware: Design virtual runtime environments that allow individual virtual machines to safely perform a warm reset without affecting other running operating systems.
- MCU Makers:
- Hardware Virtualization Extensions: Design microcontrollers with hardware-assisted virtualization (such as ARM Cortex-R52 or Renesas RH850/U2B) to eliminate software-level address translation delays.
- Core-to-Pin Isolation: Implement hardware register-level partitioning, enabling specific physical GPIO pins and network resources (like CAN controllers) to be assigned directly to specific CPU cores.
- OEMs (Automakers):
- System-Level Fail-Operational Design: Create fail-safe strategies that can instantly shift critical software tasks to another healthy ZCU or central computer if a ZCU fails.
- Virtual Integration Testing: Lead vehicle-level virtual integration testing to verify that mixed-criticality systems do not interfere with each other.
2. Real-Time Networking (TSN) & Heterogeneous Protocol Conversion Latency
In domain systems, sensors connect directly to their domain controllers. Zonal architectures, however, physically separate sensing from actuation. A wheel speed sensor’s signal goes to the nearest ZCU, traverses an Ethernet backbone to the central HPC, which calculates a command and sends it to a different ZCU to actuate the brakes.
This requires Time-Sensitive Networking (TSN) standards (like IEEE 802.1Qbv and IEEE 802.1AS) to guarantee low, predictable network latency. However, configuring TSN is highly sensitive; a single wrong parameter can ruin real-time performance. Furthermore, converting legacy CAN FD or LIN signals into Ethernet packets at the ZCU adds protocol translation delays that are difficult to predict.
Tesla & Rivian’s Approach
- Tesla: Tesla minimizes network translation latency by utilizing highly optimized, custom point-to-point topologies. In the Cybertruck, they deployed custom serial buses and an Ethernet-based backbone directly optimized for ultra-low latency. For safety-critical functions like steer-by-wire, Tesla relies on highly redundant, direct-drive motor paths, completely bypassing traditional multi-tier CAN-to-Ethernet translation bottlenecks.
- Rivian: Rivian’s Gen 2 platform consolidates functions into just 7 ECUs connected via high-speed Ethernet. Rather than retaining legacy CAN/LIN networks from Tier-1 suppliers at the edge, Rivian connects sensors and actuators directly to their three in-house designed zonal controllers. The ZCUs process raw edge data and stream it natively over high-speed Ethernet to the central computing platform, eliminating translation delays.