The Evolution to Central Computing and Zonal Architecture

Introduction#

The automotive industry is undergoing a profound transformation in electrical and electronic (E/E) architecture. Traditional distributed ECU architectures, where each function is controlled by a dedicated electronic control unit, are reaching their limits. As vehicles become more connected, autonomous, and electrified, the need for higher computing power, reduced wiring complexity, and flexible software updates drives the evolution towards central computing and zonal control architectures.

This guide examines the underlying logic of this shift, focusing on cross-domain fusion, in-vehicle Ethernet topology design, and the adaptation challenges for AUTOSAR Classic Platform (CP) and Adaptive Platform (AP) software stacks. By understanding these elements, automotive architects can navigate the complexities of modern E/E architecture design.

From Distributed ECUs to Domain Controllers#

The first step in this evolution was the introduction of domain controllers, which consolidate functions within a specific domain such as powertrain, chassis, infotainment, or advanced driver-assistance systems (ADAS). Domain controllers reduce the number of ECUs and simplify inter-ECU communication by centralizing processing for related functions. However, as cross-domain features like autonomous driving and intelligent cockpit emerge, domain controllers alone are insufficient.

Domain controllers still operate in silos, limiting data sharing and resource utilization. For instance, ADAS requires sensor fusion from cameras, radar, and lidar, while the cockpit needs to display that information seamlessly. This demands a more integrated approach, leading to central computing and zonal architectures.

Central Computing and Zonal Control: The Next Step#

Central computing architecture replaces multiple domain controllers with a few high-performance central computers. These central computers handle all major processing tasks, from ADAS to infotainment, using powerful system-on-chips (SoCs). Zonal control complements this by grouping ECUs and sensors into physical zones based on location in the vehicle, rather than function. Each zone has a zonal gateway that manages I/O and communication for devices in that area, reducing wiring harness complexity and enabling scalable growth.

The key benefits include reduced weight and cost, improved software update efficiency, and enhanced cross-domain fusion. For example, a central computer can process data from all zones, enabling features like intelligent cockpit that integrates ADAS alerts with infotainment displays. This architecture also supports over-the-air updates and service-oriented communication, essential for future software-defined vehicles.

Cross-Domain Fusion: Computing Demands and Challenges#

Cross-domain fusion, such as merging ADAS and cockpit domains, introduces significant computing demands. ADAS requires real-time processing of high-resolution sensor data, often exceeding 100 TOPS, while the cockpit needs high-definition graphics and natural user interfaces. Combining these on a single SoC requires heterogeneous computing with CPUs, GPUs, NPUs, and FPGAs, along with hypervisor-based virtualization to isolate safety-critical and non-critical functions.

Challenges include thermal management, power consumption, and functional safety. For instance, ADAS functions must meet ASIL-D requirements, while infotainment can be QM. Hypervisors like QNX Hypervisor or COQOS enable mixed-criticality integration, but they add complexity in resource partitioning and real-time guarantees. Architects must carefully balance performance, safety, and cost.

In-Vehicle Ethernet Topology Design#

Central computing and zonal architectures rely on high-speed in-vehicle Ethernet as the backbone. A typical topology uses a multi-gigabit Ethernet ring or star with zonal gateways connected to the central computer. Each zonal gateway aggregates data from sensors and actuators via Ethernet, CAN, LIN, or FlexRay, and forwards it to the central computer over 10Gbps or higher links.

Design considerations include latency, bandwidth, and redundancy. For ADAS, end-to-end latency must be under 10ms, requiring time-sensitive networking (TSN) standards like IEEE 802.1Qbv for scheduled traffic. Redundancy can be achieved with ring topologies and rapid spanning tree protocol (RSTP) or proprietary solutions. Additionally, power over Ethernet (PoE) can simplify wiring for sensors like cameras and lidar.

AUTOSAR CP/AP Software Stack Adaptation#

AUTOSAR Classic Platform (CP) is designed for deeply embedded, real-time ECUs, while Adaptive Platform (AP) targets high-performance computing with POSIX-based operating systems. In central computing architectures, both must coexist. CP handles safety-critical, hard real-time functions like braking or steering, while AP manages dynamic, service-oriented applications like ADAS perception or infotainment.

Adaptation challenges include communication between CP and AP, often via SOME/IP or DDS over Ethernet. CP's static configuration contrasts with AP's dynamic service discovery, requiring gateways or middleware. Also, AP's use of C++14 and POSIX demands more powerful hardware, while CP remains on microcontrollers. Architects must define clear interfaces and partitioning to ensure safety and security, leveraging standards like ISO 26262 and ISO 21434.

Conclusion#

The evolution from distributed ECUs to central computing and zonal architectures is driven by the need for greater computing power, reduced complexity, and cross-domain fusion. By understanding the roles of domain controllers, the benefits of zonal control, and the challenges in Ethernet topology and AUTOSAR adaptation, automotive architects can design robust E/E architectures for the software-defined vehicle era. Embracing these changes will be crucial for delivering safe, efficient, and innovative vehicles.