Automotive: the next frontier for virtualization

I have been predicting for years that there is a need for virtualization in cars. Guess what, it’s about to happen!

There are two main drivers (excuse the pun): On the one hand, features are mushrooming in cars just as in consumer electronics. And in cars, traditionally each new feature has resulted in yet another microcontroller (or four). The barrier of 100 ECUs (as micros are called in cars) has been broken years ago. Besides the problems of increasing complexity of this distributed computing system, there are very solid reasons why this approach doesn’t scale any more: cars are a very hostile environment for electronics. It must be packaged up to be heat resistant, dust resistant, vibration resistant, water proof, grease proof, acid proof, the lot. This leads to expensive and bulky packaging, which is creating space and weight problems.

On the other hand, there is an increasing need for integration of very dissimilar systems. Classical automotive (control and convenience) functionality is subject to standards set by the automotive industry. But much of the infotainment functionality uses parts from the consumer-electronics space (eg wifi, Bluetooth, Linux, Windows). These are made to standards (or not) that are out of control of the auto industry. And as such it can be hard to predict how such parts interact with automotive subsystems.

An obvious way of getting around the issue of mushrooming functionality is to consolidate on fewer processors. This requires a protected multitasking operating system to isolate functions. However, while classical automotive functionality runs on automotive OSes, such as AUTOSAR, entertainment functionality expects more powerful OS platforms. The automotive industry has reconised this, as is obvious in GENIVI, which is a Linux-based OS. But two different OSes on the same processors only works if they run in separate virtual machines (VMs). Even if they run on different cores of a multicore processor, multiple cores aren’t isolated from each other unless there’s a hypervisor underneath.

Note that this consolidation is not only needed to save parts/space/weight. Increasingly tight integration of functionalities is inevitable. For example, infotainment is becoming tightly integrated with more classical automotive functions, such as navigation and driver assistance. (Example: information on road conditions, obtained from ad-hoc networks formed with other cars, may be used to change driving behaviour, say to stabilise the car when there is a chance of roads being slippery).

However, such integration cannot lead to misbehaviour of consumer-electronics parts spreading to other functionality. If some infotainment component crashes (or worse, catches a virus) you want to be damn sure this doesn’t spread to other functions.

There are other interesting aspects. Automotive components are expected to be ready and operational very quickly when the ignition key is activated. For example, nodes in the automotive CAN and MOST networks have a requirement to start up within 50 ms. GENIVI, being a Linux OS, cannot boot up anywhere near that quickly, yet it must be able to talk to the CAN/MOST bus and is subject to its requirements. The way out is either have the CAN/MOST controller driver on a separate processor (and chip), or, much cheaper, have it in a different virtual machine on the same chip.

All this is nothing compared to having to run GENIVI and AUTOSAR on the same processor, because of integration fo functionalities (eg. the instrument cluster, driven by AUTOSAR, is to display date that comes from the infotainment world). You’re really stuck there without virtualization.

Don’t believe me? Just wait, you’ll see it happening quite soon.