Whether it is a human or a computer in charge of a vehicle, reaction times are critical. At just 50 kilometers per hour – a typical speed for traffic in built-up areas – a hazard 13 meters in front of the car will be reached in less than a second. At this speed, a vehicle will travel more than 4 meters in the time it takes to blink.
A human driver has a reaction time of between 300 and 600 milliseconds (approximately half a second) between sensing danger and taking avoiding action. This is the best-case scenario, when the driver is awake, alert, and looking in the right direction. If concentration was to lapse, due to distraction, intoxication, or fatigue, then reaction time would be considerably slower. Such lapses play a major role in many of the approximately 1.3 million traffic accident fatalities that happen each year worldwide.
What is clear is that when we use computing to assist, or replace the reactions of a driver, then we must do much better than merely matching the human’s capability. We need to be tens of thousands of times better.
The need for accurate, fast, automotive real-time control is one of the primary differences between the hidden computing in our cars, and the familiar computing in our mobile phones or laptops. It is not sufficient that the reaction is fast; it must happen within a pre-determined time, every time – a characteristic that is known as deterministic real-time control. Of course, some automotive real-time applications such as antilock braking, airbag and motor controllers have been with us for many years. Now, with the adoption of advanced driver assistance systems (ADAS) and features such as automatic emergency braking, collision avoidance, and blind spot detection, the number and sophistication of real-time workloads is on the rise.
This rise coincides with the emergence of a new kind of zonal architecture in vehicle electronics, in which the functions of more than 100 individual electronic control units (ECUs) per car are being consolidated onto a smaller number of more powerful modules. Automakers are exploring the best place to run these automotive real-time workloads, and two integration options are proving to be popular.
Consolidation of real-time workloads in zonal controllers
The first option is that the real-time functions can be handled by zonal controllers. These ECUs are a new kind of module that serve many of the input and output sensors and actuators in one geographical area of a vehicle. For example, a single zonal controller may support the front lights, mirror adjustments, door locks, electric windows, seat controls and so on, which are located close to each other in the same front corner of the vehicle.
The zonal controller is, first of all, a networking platform, as it transfers automotive bus systems (e.g., CAN, LIN, FlexRay) to high-speed Ethernet data packages. This allows designers to simplify the wiring harness, which then reduces cost and weight. The rapid move to electric vehicles provides a window of opportunity for the shift to zonal architectures and the first generation of zonal controller is already becoming standard in many production vehicles.
As the multiple real-time functions are consolidated into zonal controllers, the requirement for processor performance increases, as does the sophistication of the operating system and software. The industry is increasingly turning to microcontrollers (MCUs) based on Arm Cortex-R52 to enable this software integration vision. Several automotive chip manufacturers have already incorporated this processor into their designs for high-performance microcontrollers for zonal platforms, and automotive software providers have established solutions that integrate with Armv8-R, the Arm architecture used in this processor family.
The safety island
The second location where Arm sees the consolidation of real-time workloads is in high-performance modules such as ADAS, cockpit domain controllers or central compute units. These larger computing nodes are based on heterogeneous compute designs where a cluster of Arm Cortex-A cores resides next to a real-time “safety island” that manages boot up and error management and supports safety critical functions.
In these complex high-performance SoC designs, the Cortex-R52 is established as a popular processor for the safety island, selected by almost all of Arm’s industry leading automotive silicon partners for the real-time compute in their designs.
Real-time is really critical
In the high-performance compute area, consolidation of workloads is already established. Now the automotive industry is embracing the urgency for consolidation in the real-time compute.
Vehicle architects value flexibility on where to run the real-time workloads. As the Cortex-R52 is used in both system-on-chip (SoC) and MCU-based designs, the same software architecture can be reused in all design variants. Thus, an investment in Cortex-R52-based frameworks maximizes the opportunity for software reuse and portability.
You can learn more about Cortex-R52 here. And if you’re attending Embedded World in Nuremberg, Germany, this year, please come by our booth for a chat. We are located in Hall 4, Stand 4-140. Additionally, my Arm colleague Girish Shirasat is giving a virtual keynote (“Automotive Technologies: Cloud-Native Mixed Critical Automotive System Development”) from 8:30-9 p.m., Tuesday June 21, followed by an in-person version of the presentation the following day at 4 p.m.