Virtualized vs. Non-virtualized: Integrating Critical Driver Information Applications into the Automotive Infotainment System



When it comes to integrating more of the vehicle’s critical driver information applications into the infotainment system, what are the considerations when deciding to switch the infotainment system from a design using multiple SoCs to a design relying on platform virtualization for hosting mixed-criticality applications all running on a single SoC?

Virtualization technology has been supported in embedded processing for quite some time. However, at present, there are very few infotainment system designs in the market that rely on platform virtualization to integrate different types of applications in the vehicle onto a single applications processor. This article discusses the benefits of using virtualization to achieve protective separation for different operating system environments running on the same processor. It also reviews the key tradeoffs that automotive manufacturers must consider and decide before moving their infotainment system designs to rely on platform virtualization for integration of both critical and non-critical applications into the same system.

Figure 1: When integrating critical applications into a new IVI system design, one area to explore is the question of whether to use virtualization or physically separate SoCs.

Figure 1: When integrating critical applications into a new IVI system design, one area to explore is the question of whether to use virtualization or physically separate SoCs.

Even though virtualization technology has been advancing for some time now with the recent generations of embedded multicore processor architectures, there is still a lag in its use to integrate critical and non-critical applications onto a single applications processor in the latest in-vehicle infotainment (IVI) systems being designed and introduced to the market. Certainly there are many cost savings to be achieved by integrating more of the vehicle’s analysis and information display functions onto a single SoC that would naturally be a good fit within the IVI system. Some examples of these natural targets for integration are driver information applications such as: rear-view camera video, cluster display with telltale indicators, cluster information display, head-up display, and informational advanced driver assistance system (ADAS) features with audio, visual, or physical feedback to the driver.

When integrating any of a vehicle’s critical applications into the IVI system, it is important to protect each application’s reliability and isolate it from the rest of the IVI system applications—even if it is using the same processing resources and some of the same physical interfaces on the infotainment processor.

One way to achieve this is through the use of virtualization. Separation of different types of applications using platform virtualization can be accomplished by using hypervisor software, ideally running on a processor architecture that supports hardware-assisted virtualization (to ensure minimal overhead for context switching and guest memory protection), to host a separate virtual machine (VM) environment for the infotainment guest operating system (OS) and for each of the other guest operating systems used for different critical applications that need to be hosted. Each guest OS then runs in a protected VM environment with separation being achieved for each of the applications running in the separate VMs. Separation in this context means ensuring that the applications running in one VM cannot adversely impact an application in any other VM. An example of an infotainment system software architecture based on virtualization is shown in Figure 2.

Figure 2.  Infotainment System Software Architecture Example using Platform Virtualization to Integrate Mixed-Criticality Applications onto a Single Infotainment Processor.

Figure 2. Infotainment System Software Architecture Example using Platform Virtualization to Integrate Mixed-Criticality Applications onto a Single Infotainment Processor.

A good hypervisor is designed to be able to provide complete separation for each VM and ensure that one VM’s resources (memory, peripherals, etc.) cannot be accessed by any other VM, unless a protocol for sharing has been specifically designed and enabled via the hypervisor. The hypervisor should also be able to handle a prioritization scheme among the VMs and be able to switch quickly to a VM with a higher priority assignment than the VM that is currently running. A hypervisor can also track and control the amount of time that is given to each VM to run on the available processor cores to ensure that none of the VMs are completely starved of run time.

However, there are a few tradeoffs to be made when considering whether to use virtualization or physically separate SoCs when integrating critical applications into a new IVI system design. These are some of the tradeoffs that need to be considered when weighing a design with the infotainment applications and other critical applications being run on either a virtualized platform hosted on a single SoC or a non-virtualized (multi-SoC) platform:

Cost

This tradeoff is about the cost of development of virtualization software and integration of mixed criticality applications onto a single SoC compared to the inherent hardware costs of a larger system design with physically separate SoCs for each set of applications. Automotive manufacturers and their Tier1 suppliers must hurdle some up-front development costs in designing IVI systems that use virtualization technology and then finally bring production-ready systems with virtualization to market. It may take some time for the cost benefits of a reduction in the number of SoCs in the system to overcome the initial cost of development of a design based on a single SoC with virtualization support.

Time to Maturity

Another tradeoff is the maturation time for a robust IVI system based on virtualization when compared to more immediate time-to-market demands for a new system design. It may take some additional development and test time to prove the robustness of IVI systems that rely on virtualization to integrate a variety of mixed criticality applications together onto a single SoC. Therefore, automotive manufacturers may stick with multi-SoC based designs in order to integrate additional functions into the IVI system if they haven’t had the full amount of time required to prove the robustness of the other option.

Performance

The third area of concern is the performance of system applications running on a virtualized platform compared to the performance when running on physically separate processors. Performance should not be a problem for applications running on the virtualized platform if the processing power available on the infotainment processor is enough to handle the load requirements of the infotainment applications and the other critical vehicle applications. In addition, there should be some small processing margin to spare for the overhead of management and VM switching being handled by the hypervisor.

Protection

The last tradeoff area to consider is protection for critical applications running on the virtualized platform as compared to the protection of natural separation when designing with physically separate SoCs. A properly designed hypervisor can robustly protect the resources and run-time of the different VMs that are hosting various applications. However, care must be taken to protect each application’s resources from other processing subsystems and peripherals on the same SoC that may not be controlled by the hypervisor running on the main processor. In this case, in order to protect critical applications from being compromised it is important to design using a processor with hardware security support. For example, the automotive applications processors in the Texas Instruments “Jacinto 6” (DRA7xx) family of devices have built-in support for security firewalls that can be set for various peripherals and memory regions. These hardware-based security firewalls can help protect critical application resources from being compromised by software running on another processor or by a peripheral on the same SoC.

Conclusion

For the present time, most automotive manufacturers have opted to handle integration of critical applications into the IVI system using designs mainly with physically separate processors when application reliability and separation of resources need to be guaranteed. However, in the near future, many automotive manufacturers will have had the opportunity to develop very robust platform virtualization for their IVI system products and more systems will enter the market that regularly host mixed-criticality applications using virtualization on a single SoC. The cost-benefits of hosting multiple applications on a single SoC may soon outweigh other factors that have caused a lag in willingness to design IVI systems that rely on virtualization technology.

_____________________________________________________________________________________________________________________

JBergsagelJonathan Bergsagel is a software architect for the Automotive Processor business unit at Texas Instruments. He has been developing software and system solutions for mobile and automotive products at TI for over 10 years. His current pursuits include enabling new automotive infotainment feature combinations and optimizing infotainment system performance using TI multicore automotive processors. He holds a Master of Science in Electrical Engineering from Southern Methodist University.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis