Moving from Domains to Zones: The Auto Architecture Revolution

What you’ll learn:

The shift from conventional electrical and electronic (E/E) architecture within the vehicle to the domain and zonal architectures.
How software is taking precedence over hardware in defining the vehicle and its key components.
How automotive manufacturers are now moving from domain to zonal architectures.
Challenges with—and a solution to—the zonal approach implementation.

The wiring harness in many vehicles now weighs more than any other component, except the engine—whether it’s an internal combustion engine (ICE) or battery-powered electric motor. Reducing this unsustainable burden demands an entirely new approach to interconnection architectures, and it can’t be realized using high-speed serial buses and networking technologies alone.

To fully address the issue requires a fundamental shift in how hardware and software functions are partitioned across newly configurable platforms.

Dividing into Domains—and the Need for a Zonal Approach

Due to the increasing complexity of the conventional vehicle architecture caused by the addition of more and more electronic control units (ECUs), an alternative approach was introduced to add structure and hierarchy. The approach was to divide the vehicle into “domains,” or areas with common functionality—such as the chassis, powertrain, body & comfort and infotainment, and ADAS—and connect them to a centrally located service-oriented gateway via a dedicated domain controller (Fig. 1).

1. The domain architecture approach divides the car into areas with common functionality and, via a dedicated domain controller, connects them to a centrally located service-oriented gateway.

However, the downside to this approach is that many (if not all) of the domains physically span the entire vehicle. Therefore, instead of organizing the domains by function, a zonal approach organizes by the location where all of the functions—lighting, suspension, indicators, image sensors, and braking—are controlled by the zonal controller (Fig. 2). However, this approach needs modularity and flexibility.

2. The zonal architecture approach organizes by location, where the zonal controller controls all functions.

Modularity means that there’s a high degree of commonality between system elements, such as ECUs, that will have the same hardware despite being used for different tasks. The operation of these devices will be defined by the software that’s embedded within them.

Flexibility refers to the ability of the vehicle’s systems to be tweaked and reconfigured over time. Combining software-defined ECUs with the ability to deliver over-the-air (OTA) updates to firmware provides this flexibility and allows automakers to easily support the vehicles. This can include addressing software defects (“bugs”) as well as adding new features or enhancing existing ones.

Challenges in Zonal-Approach Implementation

While the automotive industry has relied on CAN networking for decades, it’s becoming apparent that it’s unable to cope with the demands of vehicles today. This is especially the case for the “backbones” that connect the zonal gateways, which will be based on Ethernet. However, the hierarchical nature of the zones will introduce more “hops” within the network, potentially causing latency and jitter issues.

Many of the systems in a modern vehicle have time dependencies, which is especially critical in safety-related systems, such as ADAS. While a delay in opening a window or changing a radio station would be an inconvenience, a delay to a message from a camera that has detected an obstruction resulting in brakes being applied late is potentially catastrophic.

This highlights a weakness of traditional Ethernet in that data packets are only propagated when the backbone is free of other traffic, and there’s no hierarchy of relative importance. Simply put, traditional Ethernet would see a data packet for changing a radio station as equally important as one to apply the brakes.

In-vehicle networking will be based on IEEE 802.1AS-2020, the IEEE-approved standard for timing and synchronization in time-sensitive networking (TSN) applications. Often called “deterministic Ethernet,” this standard includes several features for ensuring that data is managed to strict time criteria based on the importance of the data, including ensuring that time-sensitive traffic is propagated via the shortest path.

This high-speed Ethernet will form the backbone of the zonal architecture and connect zone controllers with one another as well as with the central computing resources. However, things will become more complex within each zone due to multiple types of edge networks being implemented, connecting the zone controller to various edge ECUs. While Ethernet may be used in some cases, a significant amount of CAN infrastructure will exist in both CAN (FD) and CAN XL formats.

Several areas should be considered for this multi-protocol approach to work effectively. In particular, the designer must consider how data is moved onto and from the Ethernet backbone to and from the in-zone network. This is further complicated by the fact that CAN traffic is typically periodic and broadcast, compared to Ethernet, which is usually event-based and point-to-point.

As in-vehicle networking (IVN) becomes more important and powerful, the complexity will rise, with networks incorporating multiple elements, including switches and gateways. While this complexity is necessary to build a resilient network, some simplification must be achieved so that the components (and therefore the complete network) are configured.

Software-defined networking (SDN) can be used to simplify how network components are configured by standardizing the interface so that the configuration is hardware- and vendor-agnostic. Because this also can be achieved OTA, optimized network configuration may become part of manufacturer updates as well as being managed at a fleet level if necessary.

Functionality moves from domain controllers to zonal controllers and the central processor within a zonal architecture. Thus, applications are mapped over more processing and network hardware, with individual hardware sharing multiple data streams and functions. The increased workload can be a source of latencies and jitter that are highly undesirable in time-sensitive applications.

As a result, hardware performance and throughput are key considerations when planning a zonal architecture. Often the central controller will incorporate sophisticated task-scheduling algorithms running on multicore processors to minimize any delays, while the network will be based on high-performance technologies such as time-sensitive Ethernet.

The final consideration is safety and security, which increase in importance as vehicles become more connected and more autonomous. This multi-faceted area is concerned with functional safety that detects and addresses failures in critical components, ensuring fail-safe operation as well as making sure the entire zonal architecture isn’t vulnerable to malicious external attack.

The Zonal Solution

A zonal architecture could be implemented in almost an infinite number of ways to cover the key functions of connectivity, network control, real-time I/O, and application/service management. Within NXP’s proposed solution, there are three categories of zonal gateway: the zonal aggregator, the zonal controller, and the zonal processor (Fig. 3).

3. Within NXP’s proposed zonal solution, there are three categories of zonal gateway: the zonal aggregator, the zonal controller, and the zonal processor.

The zonal aggregator has the sole role of traffic management, aggregating different data types with varying criticality, safety, and security requirements. But the dissolving of functions while maintaining the data execution pipeline of “sense-think-act” requires enabling both: accessing and exiting of the data highway, and, finally, the reconversion of Ethernet packets into CAN or LIN bus signals without impacting the criticality, safety, or security requirements of each bit of information.

In addition to traffic management, the zonal controller adds real-time processing and takes care of advanced network processing. Here, the sensors, actuators, and, to some extent, functions, are locally connected to zonal controllers. These also can be considered mini gateways because this is where a CAN or LIN meets Ethernet. The zonal controllers are then connected through a high-speed Ethernet network backbone to the center, the brain, of the car.

Finally, the zonal processor is involved in the same aspects of the network, but it adds capability for application processing and advanced gateway services.

On this front, NXP offers integrated solutions specifically designed to implement an Ethernet TSN switch (SJA1112/1110) and multicore processors from the S32 platform that can scale across the three zonal-gateway categories (zonal aggregator, zonal controller, and zonal processor) as well as functionally safe power-management devices.

Summary

The automotive industry is undergoing unprecedented change with technology-laden vehicles that enable connected, electrified self-driving. To fully implement this future, hundreds of ECUs and sensing devices will be added to almost every car, necessitating a fundamental rethink of the vehicle architecture—not least, to reduce the size and weight of the wiring harness.

While early initiatives have organized the vehicle into domains, the zonal approach is rapidly gathering pace as the preferred approach due to its capacity, flexibility, and ability to constrain costs.