//php echo do_shortcode(‘[responsivevoice_button voice=”US English Male” buttontext=”Listen to Post”]’) ?>
Over the years, the automotive industry has produced many iconic designs, from the Jaguar E-Type to Sir Alec Issigonis’s Mini. These vehicles are not only lauded for their appearance but their mechanics, from engine to handling. But the automotive industry is changing. How transport integrates into our lives has changed, with sharing becoming more important than ownership. Additionally, today’s consumers grew up with computers and smartphones—devices customizable to users’ needs. As a result, the balance of power in automotive is moving from the mechanical to the software engineers.
Electronics in automotive is not a recent trend. Electric vehicles were around in the 19th century, and the first car radio was introduced in the 1920s. But today’s reliance on programmable electronics can be traced back to the introduction of electronic-fuel–injection systems, such as the Bosch Motronic built around the 8051 microcontroller (MCU). Since then, the quantity of electronic control units (ECUs) in vehicles has grown apace, with today’s high-end vehicles using between 100 and 150 ECUs. These support features from engine management and traction control to keyless entry and electric seat adjustment.
From function-per-box to boxes of functions
The move from mechanical to electronic follows a well-worn path. The vehicle function is analyzed and then implemented using the electronic and electrical capabilities of the day. Thus, the cranked window lifter is replaced with a motor and electronic drive system and linked to a control switch.
Over time, such systems were networked via solutions like Local Interconnect Network (LIN) or Controller Area Network (CAN), primarily to aid diagnostics and sometimes ECU programming. As a result, the electrical/electronic (E/E) architecture has grown around functional domains (drivetrain, body, chassis, braking, etc.), but data exchange for supporting functionality was limited.
For example, a rain sensor provides data to the windscreen-wiper ECU, or light-level sensors inform the lighting ECU when the vehicle enters a tunnel or when it gets dark outside. That raw sensor information would never have been shared with other ECUs.
As a result, a complex structure of boxes hanging on disparate networks is defined for an automotive platform (Figure 1), staying the same for up to a decade. Feature differentiation involves removing boxes, but due to interdependencies, certain features can be offered only in conjunction with others, limiting consumer choice. Finally, adding OEM features post-purchase, such as acquiring a car second-hand, is simply impossible.
Moving to domain and zonal architectures
Tesla has shown that post-purchase upgrades are possible and often desired. But to implement them, the OEM threw the traditional approach to E/E architectures out the window. Currently, there are two competing approaches to this move to software-defined vehicles.
The domain architecture (Figure 2) splits the vehicle into its functional domains, placing a large, powerful ECU, a domain controller, in charge. Some actuators and sensors are then connected to these domain controllers via dedicated ECUs, perhaps in cases when critical real-time performance is required. The domain controllers are linked to a gateway that provides connectivity, linking the vehicle to cloud services.
By comparison, the zonal architecture deploys hardware where it is needed. A zonal module at the front of the driver’s side may handle headlights, a camera, suspension and braking for that zone of the vehicle. As a result, the concept of domains is removed from the hardware perspective.
The modules are linked via high-speed Ethernet, using the new standards for implementing low latency and synchronization. Data from sensors are fused and delivered to several functions, regardless of where they originated. A powerful, high-performance computer coordinates the entire electronic system at the vehicle’s center. Like in the domain approach, a gateway offers connectivity to the cloud. The core difference is that the domains exist purely in software, spread across all computing hardware.
Changing demands on automotive processors
The demands on semiconductor vendors supplying the automotive industry have always been intense. These range from longevity of supply and high quality to device survival under some of the most extreme electrical pulses. As a result, automotive MCUs have typically been a generation or two behind those offered for commercial applications, perhaps except for the powerful system-on-chips (SoCs) used in telematics systems in which functional safety is not an issue. Multicore devices can support up to ASIL-D applications, but the older process nodes used limit the processor’s operating frequency.
Furthermore, how software is developed is not conducive to firmware updates. AUTOSAR is well established, providing a bare-metal OS platform for automotive code. But the code ends up inextricably linked to the hardware and is challenging to port to a new processor, let alone redeploy. Changing a small section of code and rolling out an update is, quite simply, not simple.
Therefore, there is a growing demand amongst OEMs and their tier suppliers for a new generation of processing platforms that offer the power and performance of today’s smartphone SoCs but conform to the safety demands of automotive (Figure 3).
Core to achieving this is the use of virtualization. Long established in the server markets, virtualization is a software layer that allows multiple OSes to execute on a single, multicore processor. None of the OSes are aware of each other, and each believes it has complete control of the underlying hardware. If one OS fails, it has no impact on the other OSes running on the same machine. In the automotive context, virtualization would support a mixture of standard and safety-critical code to execute on a single SoC without the risk of them impacting each other.
This approach does not come for free. Virtualization adds overhead that impacts performance, although the impact is small. However, different resources are impacted in different ways. Memory accesses are usually partitioned in hardware through the memory management unit (MMU), so there is little overhead.
But access to peripherals is more complex. The hypervisor manages Ethernet access, sharing a single connection among the installed OSes. For embedded systems, the same is true for access to general-purpose input/output (GPIO) pins. Because pins are assigned at the bit level rather than the register level, there is no way to offload this to the MMU, so the hypervisor must jump in for every access.
A new generation of processors
To retain real-time performance when accessing hardware interfaces with virtualized software, a new generation of SoCs manufactured on advanced technology nodes are needed that are optimized for automotive needs. This has been the focus of NXP, with its S32E and S32Z families of real-time processors (Figure 4). Built at 16 nm, with a path to 5 nm in place, these SoCs offer eight Arm Cortex-R53 processors, designed for advanced real-time embedded systems, operating at up to 1 GHz. Designed for domain and zonal controllers, these devices can support up to ASIL-D applications, with the cores configurable for individual use or flexible lockstep operation.
The trend toward virtualization is also recognized, with various hardware features supporting automotive applications and freedom from interference between OSes executing on the same hardware. GPIO control is one aspect, with support for “core to pin” virtualization. While pins are still configurable in registers, pins can be individually assigned to cores in hardware before each OS is booted. At runtime, the pins appear as a dedicated resource. Should the associated OS fail, it can reboot without impacting the GPIOs used by other OSes or needing to have its GPIOs reassigned.
CAN will remain a key networking technology in future cars and is known for generating lots of interrupts during communication exchanges. These are challenging to accommodate when the processor is busy with other real-time control tasks. The S32E and S32Z offer 24 CAN/CAN FD interfaces via a Flexible Low Latency Communication Engine (FlexLLCE) (Figure 5), a module that also features two lockstep Cortex-M33s and 768 kB of dedicated SRAM. In addition to offloading the demands of communication, the interfaces can be assigned to OSes in hardware.
As the automotive software environment changes, software functions are expected to become independent of the hardware—transferable from one domain or zonal controller to another. This may result in a function assuming its counterpart will be available via Ethernet, even though the counterpart is implemented on the same SoC. Thanks to the Ethernet subsystem, which includes two MACs and a switch, such communication can be automatically routed on-chip directly.
New demands, new requirements, new hardware
The automotive industry has realized that software flexibility must be more than installing an app or updating the map on the telematics system. Consumers, who have grown up with customizable everything, want the same from their cars. The fact that this can be done is not in doubt. The question is how and what processing hardware to use. Like in the past, the semiconductor industry is responding, using their experience from consumer and commercial applications and combining it with the automotive industry’s safety requirements. Real-time processors offer the necessary refinements required for low-latency control and freedom from interference to support OEMs with their software-defined–vehicle goals.
