Search
Close this search box.

Virtualizing a Single IVI Function

Virtualizing a Single IVI Function

Why use a hypervisor for a single function? Isn’t it the technical approach to consolidate multiple functions? The answer is yes and no. Virtualization is first and foremost a technology used to separate software applications from the underlying hardware. This enables the convergence of systems to save BOM costs. However, virtualization is also useful in contexts beyond the consolidation of functions onto a single hardware unit. Virtualization of a single function makes updates and upgrades of software components much easier and increases the system’s security. Therefore, virtualizing a single function is a very efficient approach for in-vehicle devices, such as dedicated embedded infotainment systems. Several carmakers are already preparing the deployment of the COQOS Hypervisor SDK to virtualize a standalone IVI system to reap the benefits mentioned above.

By deploying virtualization for a single function, carmakers update and upgrade the IVI operating systems to prolong the life of the infotainment system beyond the life cycle of the hardware.
Hardware manufacturers usually only support their SoCs for a limited period of time. This makes it difficult or even impossible to update the software and services in vehicles in the field if the software runs natively on the SoC. However, a virtualized operating system accesses a set of “virtual” drivers, which access the physical drivers through an interface layer. Since the virtual drivers rely only on standardized interfaces for hardware access, they are entirely independent of hardware-specific device drivers.

Carmakers deploy virtualization for single functions to use the same IVI releases across different hardware models and across multiple vehicle generations.
Every IVI system needs to be adapted to the physical drivers on systems without virtualization. By introducing virtualization, i.e., virtual drivers that only rely on interfaces for hardware access and are entirely independent of hardware-specific device drivers, OEMs and tier-1s eliminate the software dependency dictated by the underlying hardware. This way, they achieve a “build once, deploy many” strategy, saving development time and cost and reducing risk.

If the manufacturers agree on the same open virtualization standard, they will be free to choose the hardware of different providers and can reuse hardware in an unlimited number of models.
With the increasing complexity of the functionalities in the car, the variety of hardware manufacturers whose devices have to interact smoothly in the vehicle also grows. The fully virtualized function can be flexibly deployed and reused across all hardware. Manufacturers can obtain the virtualization layer from any company working with the common standard or even develop or adapt the adaptation layer themselves.

The standardized virtualized drivers of a single function can run an operating system on any virtual platform based on the same virtualization standard.
These drivers are responsible for the communication between the guest operating system and the hardware, e.g., display controller, GPU, sound device, etc. Therefore, virtualization based on open standards, such as VIRITIO gives flexibility and independence even from the virtual platform implementing the virtualization.

Virtualization of a single function helps to easily upgrade existing Android or Linux-based IVI systems with virtualization to add a new IVI.
The number and versions of each operating system are limited as they require support by the silicon manufacturer in each case. But software vendors release new versions of their operating systems independently of the adaption of the SoC vendors. Integrating a virtualization layer makes the operating system free from the BSP releases of the hardware vendor.

The virtualized single function shows nearly the same performance as a native system because the open standard-based virtualization VIRTIO avoids costly memory copy operations.
Some dedicated software needs to be executed to perform hypervisor functions like context switching or routing of interrupts when adding virtualization. Instead of transferring memory contents, which would be slow and place an excessive load on the system’s general-purpose compute cores, VIRTIO transfers references to the actual data via virtual queues. Therefore, the virtualized operating system provides high performance with only minimal performance overhead.

A virtualization layer between the hardware and the operating system of an IVI increases security thanks to virtual drivers.
On native systems, drivers have access to the kernel of the operating system (OS). This way, a driver can hack a guest OS. In contrast to this, OSes running in a virtual machine use virtual drivers. The virtual drivers have a limited command set and access to the operating system. They access physical devices only through the standardized interface provided by the virtualization layer. This is how virtual drivers protect the operating system against attacks from the outside.

Virtualization of a single function seals off a system against attacks from the outside, as the hypervisor provides an additional defense layer and can increase the system’s overall security.
Virtualization automatically generates isolation, as the hypervisor creates virtual machines (VM). The applications run on the operating system integrated into the main VM. A second VM  provides connectivity to the outside world, e.g., the internet. A network firewall in this VM can protect against malicious attacks. This is one way how virtualization can isolate mission-critical system applications for better security when IVI systems are connected to the internet and have access to potentially malicious or faulty third-party applications.

Over-the-air (OTA) software updates and system supervisors are a must in all new vehicle systems. Adding a virtualization layer to a single function increases the security of these applications.
The core technology of virtualization is the hypervisor, which creates virtual machines (VM). The main VM runs the IVI system including apps, and potentially the app store. A second VM contains the update agent and firewall and is directly connected outside of the car. This small VM transfers update packages to the VM running the IVI system by VIRITO-net. The separation of the OTA function from the IVI function into separate virtual machines provides isolation and therefore protects the OTA function from potential attacks from the IVI function.