The transition from numerous ECUs to zones will occur over several years from roughly 2025 to 2030. Each OEM will use its own architecture.

Long before the smartphone, the number of interconnected electronics and electrical equipment on automobiles, especially high-end vehicles, led pundits to describe a car as a computer on wheels or a digital car. More recently, with IoT terminology attached to any wired or wireless electronic product connected to the Internet or cloud, cars have now become the IoT on wheels. To continue the progress from yesterday’s interconnected vehicle to today’s vehicle into the future, the electrical/electronics (E/E) architecture must evolve to address increasing complexity, speed of getting to production, ongoing updates during the life of the vehicle, and network/vehicle-wide security, all while offsetting computing cost increases by reducing system integration costs.

Evolving vehicle networks
Today, automotive experts are proud to cite the presence of 60 to 100 traditional electronic control units (ECUs) on an average vehicle, each with a computing core — microcontroller (MCU) — to provide the various features and functions that car buyers want. This number should shrink as the vehicle architecture changes from distributed to zonal designs with Central Computer Systems (CCS). With all the legacy hardware and software that currently provides the desired functions and proven reliability, the transition will not occur without intermediate steps. Besides timing considerations, safety and security must be paramount to obtain the full benefits of the transition.

From roughly 2025 to 2030, the computing could be based on using two or more Central Computer Systems with several zone controllers that aggregate functions from previous ECUs. Figure 1 shows Infineon’s vision of how this could occur. In addition to the various zone modules, power distribution systems (PDS) will also be a critical element of new vehicles.

In today’s vehicle architecture, an ECU typically controls an entire domain such as a powertrain or chassis. It’s cumbersome to control and difficult to update the software because the ECU has no direct connection to the outside world. In the new zonal approach, the geographic arrangement aggregates hardware and software independent of the domain, which means fewer, easily software-updateable ECUs. Several CCSs perform high-level processing. One CCS could address cockpit domain control (CDC) and networking functions — typical body electronics systems. A second CCS would handle advanced driver assistance systems (ADAS) including image processing.

The transition process
In the 1990s, OEM efforts to develop a standard approach to vehicle network communications led to SAE J1850 with unique versions for Chrysler, Ford, and GM. Other OEMs are also taking their own unique paths for zonal architectures.

In this approach, the central computers do the high-level processing with actions carried out by the zone control units (ZCUs). These ZCUs interface with satellite sensors and actuator modules at the edge of the vehicle’s platform. The ZCU middleware enables a future with flexible software-defined vehicle (SDV) features, constantly updated by the OEMs.

Another variation of this architecture for the 2028-30 timeframe is the layered approach. This architecture consists of:

• an upper, high-performance central computing layer consisting of modules for real-time control and for Adaptive AUTOSAR (AA) or POSIX;
• a layer with as many as 5 to 10 zones that are ASIL D capable and include chassis, body, and safety ECUs;
• the lowest layer that has intelligent edge devices including a mix of smart sensors and small ECUs, PDS elements, and other miscellaneous legacy hardware.

Issues in developing/adapting a new architecture
OEMs are initially pulling body systems into zones. In this transition phase, the powertrain in battery electric vehicles (BEVs) could be among the last to have a zone. Some possible implementations mix body and safety domains into a zone. Others doing zone controllers try to avoid ASIL A and ASIL B overlap because if they co-exist, then both require ASIL-B qualification and work products. That means higher costs and greater system complexity.

Another system aspect is how OEMs deal with wake-up considerations. Today, many inputs can wake-up a car: door handles, remote keyless entry (RKE), the liftgate, smartphones, and more. Since these wake-up inputs can go into different ECUs, coordinating and managing the wake-up at the vehicle level is challenging. When to wake-up and how to wake-up a vehicle will become much more decentralized and software dependent in future vehicles.

One of the design goals of these new architectures will be over-the-air (OTA) updatability, to provide unprecedented flexibility in new features, updates, and services. OTA introduces greater security risks and offers solutions to resolve them. The new ISO21434: Road vehicles — Cybersecurity engineering, outlines processes and methods to support security in these new automotive architectures.

Coexisting vehicle architectures
Because the complete ramifications of any new architecture are not fully understood at this point, OEMs could react quite differently based on their design considerations and strategies. ZCUs tend to be body applications, but at some OEMs, they could be body and safety or safety and powertrain applications, or even vehicle motion, chassis, and propulsion in one. Those are different implementations that could be put into zones. The zone concept itself is the common theme with the CCS on top and legacy systems below that do not have to significantly change. For example, in the legacy portion, a fuel pump does not need to change very much because its function is not changing — innovation is not required. It is probably not going to be incorporated into a zone controller because the electronics could even be embedded in the fuel pump itself and it just needs network connectivity.

Automotive electronics advancements
New E/E architectures will ultimately change the way engineers design and implement vehicle electronics. These changes, however, will take several years to implement because they will not replace legacy ECUs all at once. While existing vehicle models will not be redesigned to fit a new or transitional architecture, the need to have OTA updateable software and software-based services could accelerate the timing.