Author: Steve McAslan, Technical Director at NXP Semiconductors.
It's clear, even to the average vehicle owner, that the automotive landscape is changing. Beyond gasoline and diesel, there are also electrification options. These include hybrids, fully battery-powered, and hydrogen-powered. But they are not the only changes. The vehicle's underlying electrical and electronic (E/E) architecture is also changing. This entails significant changes to the design of the vehicle's electronics and to the driver and passenger experience inside.
Microprocessors have been slowly incorporated into the automobile since the 70s, when original equipment manufacturers began to integrate electronic fuel injection (EFI) systems and on-board diagnostics. Year after year they have contributed to the safety, efficiency and comfort of the car, with one or more of them integrated into each of the increasingly numerous electronic control units (ECUs). This has resulted in a flat architecture from a network standpoint and little scope to deliver feature upgrades after the vehicle is built. Everything needed to implement a function, from sensing to actuation, is connected to a single ECU. ECUs are normally connected via a bus, such as CAN, to central control, programming and diagnostic systems. Once implanted, the software is only updated if a problem is detected and only after considerable effort, testing and a vehicle recall.
The influence of the smartphone in the automotive industry
However, a generation of smartphone users is influencing expectations around the product experience. Consumers no longer expect to buy a finished product; they buy platforms that can be modified and configured according to their needs, requirements and lifestyle. Today's rigid approach to vehicle design does not fit this mould. This has forced the automotive industry to rethink its approach to vehicle electronics and the software that implements most of its functionality.
There are currently two schools of thought on E/E architecture, which reduce the number of ECUs, simplify wiring and networking, and allow for over-the-air (OTA) updates. They also provide the necessary structure so that functions, such as heated seats, can be purchased as a smartphone app long after the vehicle has been configured and delivered to its original owner.
One of them is domain architectures that follow the current naming convention of the different domains of the vehicle, such as the drivetrain, chassis, brakes and bodywork, to name a few (Figure 1). A function that was previously implemented on a single ECU is deployed along with many other domain functions on a single ECU with a powerful multi-core processor (Figure 2).
The other approach is zonal architecture. Here the location of the ECU is more relevant, with a small number of hardware boxes situated around the vehicle closer to the installed sensors and actuators. Again, the ECUs contain powerful multi-core processors with high-speed redundant networks suitable for real-time control that exchange data with other zone controllers. At the center is a high performance computer (HPC) and a telematics gateway that provides Internet connectivity.
While domain architectures offer what might be considered an easy step toward greater integration, zonal architectures turn the software development approach on its head. This is because functions such as headlight and turn signal control are spread across the zonal ECUs instead of being dedicated to a single box. Instead, the functions are implemented as virtual ECUs on powerful multicore processors.
In both domain and zonal architectures, this also means that software compliant with the different automotive safety integrity levels (ISO 26262 ASIL) must run in parallel on the same processor without affecting each other in case of failure. This is known in the automobile industry as "freedom from interference." Therefore, regardless of the architecture used, it is clear that software is at the center of the definition of vehicle capabilities and a central aspect of this is virtualization.
Figure 2: On a domain controller, each vehicle function is implemented in a virtual ECU, with operating systems sharing processing performance under the watchful eye of a hypervisor.
Brief foray into virtualization
Virtualization has been critical to the success of Cloud Computing, as it allows multiple operating system (OS) installations to run on a single server, thus sharing its performance among many users. Bare metal virtualization runs on the lowest level of server hardware, without any installed guest operating system knowing that it is virtualized, sharing hardware resources, or that other operating systems are running alongside it. In its purest form, the virtualization platform, known as a hypervisor, basically catches OS calls and translates them to the virtualized system, such as disk and memory accesses. The same goes for hardware interfaces, such as Ethernet connectivity.
As you might expect, virtualization has unavoidable overhead in managing these hardware accesses. To combat this, developers can take the alternate approach of paravirtualization. In this case, the accesses to the hardware resources are implemented in software similar to how they would be done if there was only one operating system. Although this provides a performance boost over virtualization, the benefit varies with the workload and requires OSs to be modified accordingly. This level of variation is not acceptable for the real-time world of automotive control.
Real-time processors for virtualized operating systems
Processors dedicated to automotive applications must face these challenges, as is the case with a new generation of real-time processors from NXP. For example, a development engineer often expects general purpose I/O (GPIO) pins to be configured and controlled through a series of large registers, with each bit dedicated to setting the address, the use of pull-ups, provide output control, and provide status of inputs. Each of these registers is assigned a unique address in memory. Because of this, typical memory protection mechanisms cannot allocate individual bits of a register to a specific instance of the OS. Therefore, it is the responsibility of the hypervisor to manage this in software.
The S32Z and S32E provide a smart alternative that waives this requirement, allowing core-to-pin virtualization support for arbitrary combinations of GPIO pins per guest OS. Support is provided through additional hardware that assigns, at boot time, the required GPIO pins to a specific client OS or system partition. Since this is implemented in hardware, the performance losses typically associated with virtualization disappear. Since each operating system only sees its own arbitrary number of GPIOs, thanks to partitioning at the hardware level, there is almost no need for paravirtualization.
ASIL certification is also made simpler by this hardware-level virtualization support. Any hardware failure only affects the related operating system and its application, and a single virtual machine can choose to reset or reboot itself with no impact on other operating systems or device hardware configurations. Runaway processes do not affect other parts of the system. Another advantage is the resulting quality of service guarantees for bandwidth and performance.
Adaptation to the needs of the vehicle defined by software
Core-to-core access to GPIO resources is just one aspect of the S32E and S32Z family of real-time processors that meet the demands of software-defined vehicles. The 24 FlexCAN FD network interfaces can be tagged with an identifier that allows them to be assigned to specific guest operating systems as well, again minimizing software overhead. But this is not all. CAN networks can be especially interrupt-intensive, resulting in many context switches that make it difficult to meet real-time requirements in the rest of your application code.
To manage this, the CAN peripherals are part of a dedicated communication auto-acceleration block with two dedicated Arm Cortex-M33 lockstep cores and 768 KB of SRAM (Figure 3). The new CAN-XL standard is also supported by the Connectivity/Interface block. CAN-XL offers data rates of up to 20 Mbit/s and a larger data field of 2048 bytes. It remains interoperable with CAN-FD networks, but also supports the channelization of higher layer protocols such as Internet Protocol (IP), something that will be used more and more as Automotive Ethernet is deployed as a backbone.
It also includes automotive Ethernet, with two 10/100/1000Mbit interfaces and an Ethernet switch built into an Ethernet acceleration block. In the future, processes that control vehicle functions will issue commands via Ethernet to software processes that implement the control or provide sensor data. However, that function may be running on the same processor hardware, but on a different virtual ECU. To do this, the Ethernet switch can also pass data between virtual ECUs of the processor. This means that you can create software functions that communicate over Ethernet without needing to know if the partner software is on the same processor or on a different zone controller somewhere else on the network.
Figure 3: A small sample of the available automotive connectivity, sometimes with acceleration support, offered by the S32E and S32Z.
Software-defined vehicle software development
The way of developing automotive software is also changing. The most significant break with tradition occurs at vehicle OEMs. Here the overview is essential, as it ensures that the necessary functions are well defined and that the chosen processor hardware offers the necessary performance to meet the expectations of today and those of future drivers throughout the life of the vehicle ( Figure 4).
Figure 4: In a zoned architecture, functions are distributed in virtual ECUs throughout the vehicle, as in this case, where the front and rear braking system and ESC related to the braking system are centrally deployed.
Tier 2 suppliers will also play an important role here, thanks to their deep understanding of the various aspects of the vehicle and how they have been implemented historically. Further down the chain, tier 3/XNUMX automotive suppliers are more likely to see fewer changes, apart from moving to software development for a virtual ECU, rather than hardware. They will receive access to an operating system and peripherals with little information about what else is running on the same hardware. In fact, those decisions may not even have been made. Such is the flexibility of the software-defined approach.
What is essential is that the chosen processors offer great performance for today and headroom for the future, along with the ability to support secure OTA updates. The S32E and S32Z provide eight Arm Cortex-R52 cores running at up to 1 GHz, built on a 16nm process and with a roadmap to 5nm. They can be flexibly configured as individual kernels or in blocks to accommodate the security demands of the functions running on them. To meet the demands of Advanced Driver Assistance Systems (ADAS) and autonomous driving functions, there is also a 25 GFLOPS DSP/Machine Learning processor.
A Hardware Security Engine (HSE), certified to ISO 21434, provides secure cryptographic accelerators for secure communication and digitally signed software updates that are shared using a public key infrastructure (PKI).
The future of the car is software
Seen from the outside, the cars remain mechanical marvels, from their design and shape to their seats and engines. But everything else, from movement to the benefits they offer to their occupants, will be defined by the software, linked to the electronics, hidden from view. Automotive has always been a unique market, requiring more than just the fastest processors the semiconductor industry can offer, but demanding products that also meet extensive reliability and safety requirements. A new class of real-time processors is needed as the software-defined vehicle drives system architectures that are based on approaches typically associated with cloud computing, such as virtualization. Devices like the S32E and S32Z family, which support granular core-to-pin hardware mapping to support virtualized ECUs, will become a staple of newly deployed automotive I/O architectures. This will allow OEMs to consolidate hardware and offer smartphone-as-a-service features, apps and OTA updates, without losing the reliability and security that their brands are built on.
