Hypervisor separates software worlds in the dashboard
The car is rapidly becoming a part of the internet of things and is increasingly being influenced by consumer electronics. While a modern vehicle’s electric/electronic (EE) architecture is already complex, this level of complexity is driven further by more worlds that all meet in the cockpit domain: Advanced driver assistance systems (ADAS), in-vehicle infotainment, telematics, cloud-based services, and apps mean more functions that the driver must handle. Each function needs an interface which offers choices, parameters and control options. As a result different software systems either share the same display at times or they use different displays in different situations.
Having a closer look the different software systems are even based on different operating systems (OSs). Some of these OSs are very rich and tailored towards handling large amounts of data like, for instance, GENIVI-compliant Linux systems. Other software demands severe real-time capabilities with minimal latency and maximum reliability. Many of these safety-critical systems are AUTOSAR-based. Now, with the advent of Android in the car, a whole new dimension of apps and dynamic innovation is added yet. This “collision of worlds” is brought about by the best of intentions, but the differing requirements of each world need to be addressed and solved, Fig.1.
Fig.1: Conflicting requirements in the passenger car interior domain
Higher interior integration avoids ECU proliferation
A look back at the evolution of cockpit electronics points a way out that has worked before: The answer lies in higher integration. This successful strategy has led to the current partitioning of the interior domain. The head unit is the result of the previous step up the integration ladder.
- Functions, directly related to driving, which interface in the cluster instrument are controlled by a dedicated ECU tailored to the specific needs of this category.
- Infotainment and related functions are summarized in the head unit.
To date the head unit serves to take all the functions which are not immediately relevant to driving. However, the differentiation between what is relevant for driving and what isn’t has begun to dissolve. With the number of external functions in the vehicle increasing, this type of static architecture with two ECUs is difficult to uphold. It would have to be expanded by another dedicated ECU, e.g., for the Android world. Considering the growing capabilities of multi-core CPUs, higher integration is becoming a more economic option that offers several added benefits. Continental demonstrated the benefits of a highly integrated system interior domain architecture at this year’s CES in Las Vegas. It integrates AUTOSAR, GENIVI-compliant Linux and Android OSs in a single hardware.
Safe system architecture
Instead of having several dedicated ECUs the showcased integration solution is based on a multi-core CPU. At the moment up to four cores are being used but in the future even a many-core CPU could be an option. The computing power and infrastructure of the hardware is controlled by the SYSGO PikeOS hypervisor, Fig.2. It divides the CPU into several virtual machines with different OSs. The big benefit of this architecture lies in the fact that it allows to use mature, unmodified guest OSs and automotive-certified OSs and applications on a single hardware without mutual interference. Even if one OS should fail, the other OSs on the other virtual machines will continue to run unaffected.
Fig.2: Domain integration with hypervisor architecture
However, dividing the virtual machines in a trusted and an untrusted zone does not only ensure reliability, it is also a perfect way of handling the dynamics of consumer electronics: Frequent updates and the installation of new Android apps, for instance, are perfectly permissible in the untrusted zone, while they are not in the trusted zone.
Splendid “Isolationism”
As the automotive industry is regulated by stringent safety standards, it is of paramount importance to certify safety relevant OSs and applications and to re-use them. This applies to the hypervisor software as well: SYSGO PikeOS hypervisor architectures, for instance, have already been successfully certified for mission critical avionics (e.g. in the Airbus) and rail use. In contrast it would be a rather futile effort to try and certify something as rich as Linux to an ASIL-B standard. While certifying around half a million lines of code in the case of Linux would indeed be a Herculean task of unending frustration, the hypervisor’s few thousand lines of code are a real asset.
The hypervisor strictly separates the virtual machines and their OSs from the hardware In/Outs, Fig.3. Any request of a virtual machine for hardware access has to be approved by the hypervisor. This equally applies to trusted automotive OSs and to partially trusted OSs. If several virtual machines share hardware, they have to ask permission to do so at the shared services. Even if the request is granted, it will be the hypervisor which then accesses the source OS and provide the requested data – not the virtual machine itself. This architecture elegantly avoids problems like data races, which could result from Linux storing data on a memory while other virtual machines accesses it. Untrusted external requests have to pass through the firewall of the security policy if they request data. Only after approval can an untrusted OS/application request data via the shared services.
Fig.3: Secure In/Outs, shared services and a firewall make it possible to run trusted and untrusted systems on one hardware
The clearly defined security policy of the firewall works both ways, though. It does provide security but is also provides an opportunity for the big Android developer community to come up with innovative automotive apps. While it would be wise to open this door to a certain extent only, the security policy is an element of making the architecture future-proof as the rules of security can be redefined if needed.
Holistic HMI based on hypervisor technology
Handling heterogeneous software worlds safely and securely is one main factor for higher integration in the cockpit. The driver is another. After all, it’s the person behind the wheel who has to handle the multitude of systems and information sources on top of controlling the car. There’s no doubt: Being “Always on” provides more valuable information, better driver support, e.g. by dynamic navigation, plus additional services to increase the comfort of driving. To make this new level of connectivity usable, the human machine interface (HMI) needs to adapt to the growing number of functions and services. One key modification is to look at the HMI as one consistent and comprehensive system instead of a set of individual displays.
Within such a holistic HMI, any information or message to the driver can be shown on any of two or three displays in the cockpit: Cluster instrument, Head-up display (HUD) and central information display (CID). The difference to current HMI strategies lies in the flexibility. If a driver is navigating through dense urban traffic, the information he needs is strongly filtered to bring the load down to an absolute minimum which is displayed in the HUD, where the driver can perceive it while her or his eyes stay on the road.
If, however, the same driver is going down a motorway with little traffic, there is no reason why the number of an incoming call should not be depicted in the HUD or cluster instrument. However, if the driver starts a maneuver such as a lane change and the lane change assist functions detects a vehicle coming up from behind at high speed, the available display space plus other communication channels need to be freed immediately for this highly safety-relevant information. This requires a holistic control architecture.
This kind of flexible HMI makes the best possible use of the available communication channels that connect a driver with the car, Fig.4. Depending on the traffic situation, the HMI is constantly adapted to the driver workload and condition.
Fig.4: A holistic HMI makes flexible use of the available displays to tailor the amount and selection of information to the driver’s needs. For higher resolution click here.
This cannot be done with a static HMI that allocates one display to one function. The list of potential problems with a static HMI architecture includes such details as the question where a particular image should be rendered if it is to be shown on different displays in different situations. Another major benefit of a holistic HMI is a consistent look and feel of all functions and systems. It is a lot easier for a driver to control a multitude of functions, if the principles of making an entry and confirming a choice are always the same.
Outlook
With the prospect of automated driving there is yet another rationale for a holistic HMI based on higher domain integration: It makes a big difference whether a driver immediately controls all vehicle functions or whether that driver is responsible for monitoring an ADAS function which controls longitudinal and lateral dynamics. The role change between these two types of workload also changes the scope of information a driver needs for the instantaneous task. Again, this evolution of driving puts new challenges to the HMI. Assuming that a car is capable of highly or fully automated driving, for instance, the HMI should support the driver in two phases in particular:
- One is the transition between actively driving and just monitoring during a phase of automated driving. It will be highly beneficial if a driver intuitively grasps what is expected of her or of him to do when a phase of automated driving comes to an end and the driver needs to take over the immediate control of the vehicle again.
- Two is the phase of automated driving itself. While the vehicle navigates automatically, the available displays could be used to show any relevant contents, as long as the holistic system architecture ensures that entertainment or office contents gets overridden immediately, if the driver’s attention is required.
Higher integration in the vehicle interior domain can help to avoid a costly ECU proliferation. At the same time an interior integration “box” with shared hardware opens up highly beneficial possibilities for changing from a static HMI to a future proof holistic HMI which offers optimum driver support in all driving situations.
About the author:
Torsten Posch is Head of Software Technology Centre, Interior Electronics Solutions at Continental AG.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
