Virtualised ECUs with Renesas R-Car: new challenges and opportunities
Future-proof and (semi-) autonomous driving: a reallocation of tasks
Modern embedded processors now provide sufficient performance for most traditional applications inside the car. However, new functions – including image processing and natural-looking human-machine interfaces (HMI) – have increasingly challenging requirements. With HMIs, even simpler systems, such as a warning tone generator, make technically complex demands on simple ECUs. An example is a signal sent to an ECU for audio amplification, so that the HMI can make passengers aware of a source of danger and its location. Image and speech recognition algorithms use neural networks and deep learning, which was still in the supercomputer domain until recently. The requirement for new solutions is not even being driven by the need for more computing power – instead, it is the sheer size of the databases shared by the various ECUs. Networks like CAN were never designed for the shared usage of camera or microphone data and this can prove too much for microcontrollers that only have integrated memory. Extended diagnostic functions also impose increasing memory and communication tasks on ECUs whose initial function was relatively simple.
Looked at from another perspective, it is becoming more difficult to achieve semiconductor cost reductions through technological advances alone. Although semiconductor makers, like Renesas with its R-Car product, provide highly scalable system-on-chip (SoC) families, certain minimum costs for a single ECU cannot really be reduced any further. After all, they do still need a package that includes connectors, power supply and a circuit board. We need a different way of thinking if we are to continue getting more functionality for the same price.
The return of the central server ECU idea
One approach to a solution is to develop standardised, high-performance hardware on which a variety of controllers can run entirely as software – in other words, to use virtualised ECUs. This has two main advantages. First, it enables a more cost-effective architecture as whole devices – and their wiring – can be eliminated. Second, this type of system is much easier to extend with new functions. This is already starting to be implemented today with centralised body controllers that integrate various functions in one ECU, including optional ones.
Taking this approach to its logical conclusion, a single ECU could have software from different suppliers running on it and handle a variety of tasks. A prominent example of this type of convergence is the infotainment system that includes a traditional instrument cluster. The input and output units can still be arranged separately, like screens, but are only powered by a single ECU (Fig. 1).
This integration generates several new questions. For example: will traditional suppliers be able to change their business model to encompass a purely software-based solution? Who will be responsible for the integrated product? And how can these virtual devices be isolated from each other to comply with safety and security requirements?
Robust encapsulation of virtualised ECUs
The approach that Renesas uses in its R-Car product is to implement extensive support for hardware virtualisation that goes far beyond what is used today for ordinary PCs used as virtual machines.
PC virtualisation works mainly by virtualising the memory used by the various applications. In other words, a program accesses a memory address, but that is then translated into a physical address using special hardware. This translation unit is controlled by an operating system (or hypervisor) that knows exactly which access rights the relevant program has.
But in a highly-integrated SoC like the R-Car, there is a lot more hardware that can access the RAM independently. For example, a video input could manipulate the entire program’s RAM if there are no protection mechanisms in place. Video decoders and audio DSPs can do similar things too. And if a malware program fraudulently obtained the rights to manipulate output addresses, it could export all the secrets in the RAM to an HDMI interface.
The R-Car provides a solution to this problem with a multi-level memory protection concept. It includes global access rights for the relevant hardware accelerators, and each of these modules can be moved into a virtual address space. Once there, they are controlled by a system MMU, which translates memory requests into physical addresses in the same way as the CPU MMU. The same access rights apply as for the CPU-based software and the system MMU is controlled entirely by the secure operating system (Fig. 2). Combined with the comprehensive secure boot concept, it is practically impossible to manipulate the operating system later on.
However, providing memory protection alone would be insufficient, as the various encapsulated programs still need access to the hardware accelerators in the R-Car. For example, both the infotainment application and the instrument cluster will need to display 3D graphics on their respective screens. But as the powerful 3D GPU is the largest component on the SoC by a wide margin, it is not possible to simply double its size or provide half a GPU to each application. The first would be too expensive and the second ineffective, especially if the two applications do not have the same performance requirements. And what would happen if a third application needed the GPU?
Pure software virtualisation is an option but would use up too much graphics performance. And you can never have enough of that. In addition, this option does not include real memory protection. This is why Renesas worked with Imagination Technologies to develop and implement a new GPU hardware virtualisation concept. This provides the various programs with up to eight virtual GPUs. They are entirely hardware-managed once the central operating system has defined the resource distribution and prioritisation.
This approach has a whole string of benefits. First, it barely causes any reduction in performance compared to a non-virtualised system. Second, each process can be aborted independently, without affecting the others. This independence enables guaranteed performance allocation, so that an instrument cluster will always be able to display its content under all circumstances. It would even be able to do this if, for example, the infotainment system’s web browser froze and had to be restarted. Third, the GPU can also detect and stop malicious or faulty software after a certain delay – this could include so-called shader bombs that can use 100% of the GPU’s capacity. And finally, each virtualised software program uses its own graphics driver that is not dependent on a particular operating system (Fig. 3). Every supplier of virtualised control device software can choose the appropriate operating system for their application, such as open-source Linux for the infotainment system and an ISO26262-certified OS for the security-critical applications.
In this type of system, hardware resource management and security feature configuration is carried out by the hypervisor, a sort of simple operating system with the highest level of access rights. There are various types on the market, each with its own advantages. Renesas supports its partners by helping them port their hypervisors to the R-Car, enabling customers to choose their preferred solution.
Rules of the game are clear from the outset
Along with the 3D graphics, a virtual control device will also need broad-based access to individual physical input and output units. However, this could mean that several applications could conflict with each other. This is why the ECU architect needs to distribute the resources across the virtualised devices. It helps if the chosen SoC can provide several units or independent data paths for the same task. Each R-Car includes enough standard interfaces like UARTs or USB, so that static resource allocation is the most convenient method. Conversely, other accelerators – such as video decoders should be used in a time multiplex to offer the maximum level of flexibility. Video outputs provide independent display layers that can be allocated to each virtualised device and then combined centrally into a single image (Fig. 4).
All this needs to be agreed between the subsystem suppliers from the outset. In addition, it is important that the provider of the hardware driver also supports this concept. For example, although different video display layers can isolate their data paths from each other, there can only be one centralised driver that sets up the video output. In the case of the R-Car, Renesas delivers the device drivers required to support this distribution.
As different subsystems are now combined in one ECU, the integration tests are also transferred to the ECU. Tasks that carmakers carry out when vehicle development is finished are now managed by the ECU architect. It will be interesting to see how the industry deals with this challenge going forward – and without making development cycles even longer. In future, SoC makers will need to be more involved in this process from the outset. Simply adopting products destined for consumers will not work – they will not comply with the automotive industry’s high development standards in terms of security and safety.
The reward: future-proof solutions
Companies that master these challenges will benefit from a completely new level of freedom. With integrated cockpits, HMI designers can move information from the infotainment screen to the central driver display if the situation requires it. That enables the computing-intensive navigation function to be generated on common hardware and temporarily display a route map in the driver’s line of vision. This approach reduces hardware – because separate systems would need double the amount – and eliminates the need for wiring between the two. Processing power reserves only need to be allocated once and will be distributed more evenly depending on the application. As a result, virtual controller devices running on central, powerful servers provide the benefit of significant potential cost savings.
With its R-Car, Renesas offers customers a concept that is highly scalable within one product generation, while also remaining compatible with the next generation. That enables customers to recoup their – initially high – investment in virtualised control devices very quickly. The reward for this investment in central server ECUs is a cost-effective performance reserve to handle future extensions to functionality that are currently still unplanned. These could then be sent to the customer as an over-the-air update.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
