Search
Close this search box.

Why virtualization of a single function?

Why virtualization of a single function?

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.

Virtualization For A Single Function

Virtualization technology is gaining acceptance in the automotive industry. It makes the development process of software systems more efficient, reduces development and BOM costs, and shortens time-to-market. The use of open standards enhances the advantages of virtualization as fully virtualized guest operating systems can be flexibly deployed and reused across all hardware. Only then the potential of virtualization technology can be fully exploited.

While in the last decade, virtualization has been mainly used to address convergence (see the emergence of powerful domain controllers, integrating several functionalities), lately OEMs and Tier1 have recognized that virtualization can be used to address the other problems, independently from the convergence, i.e. virtualization can be used also in the case of one single functionality: the 1 VM case.

How It Works

Virtualization based on open standards enables the operating systems to use virtual drivers that are standardized and therefore independent of the hypervisor as well as the underlying hardware. These virtual drivers are responsible for the communication between the respective guest operating system and the hardware, e.g. display controller, GPU, sound device, etc.

Usually, one of the operating systems runs on the IVI and serves as the physical device manager. The device manager contains physical drivers that are provided by the silicon vendor for the actual hardware or that are developed or customized by the customer. In addition, there is a customization layer in the device manager that provides the physical drivers via a standardized interface. The other operating systems running on the IVI use these virtual drivers. They access physical devices through the standardized interface provided by the adaptation layer in the physical device manager. Since the virtual drivers rely only on standardized interfaces for hardware access, they are completely independent of hardware-specific device drivers.

Benefits Of VIRTIO

The decoupling between software and hardware enables OEMs and Tier-1 suppliers to create maximum flexibility as it

  • allows easy updates/upgrades
  • reduces dependencies on SoC-specific BSP releases
  • allows easier software reuse across different hardware, hardware families (e.g., multiple vehicle lines), and across hardware generations

 Especially for the deployment of Android, standards-based virtualization

  • reduces time to deploy new releases (e.g., using AAOSP Android & not waiting for the SoC vendor to adapt it)
  • allows integration of minor updates directly from the source (e.g., AAOSP)
  • decreases certification effort as virtual Android is CTS tested by Google

Hypervisor Use For More Security

As the IVI forms a gateway for unwanted access from outside the implementation a hypervisor is one of the best reasons to achieve more security on an IVI system.

The hypervisor runs directly on the SoC application cores (at the highest privilege level) and creates one or several virtual machines (VMs). This way, it allows customers to build highly compartmentalized systems that can be tailored to specific requirements. The hypervisor follows the multi-kernel architecture of the ARMv8 architecture and takes advantage of the hardware virtualization of the SOC using this architecture. The safety properties strongly rely on a systems supervisor component. TÜV SÜD has confirmed that the hypervisor complies with ISO 26262:2018 ASIL-B.

Customers can assign the VM to physical cores and temporal behavior can grant access rights to the VM to devices. Even if there is only one VM this approach seals off any outside influence (ISO 26262 calls it “freedom from interference”). The partitioning approach of the COQOS Hypervisor SDK acts as a firewall protecting against external offenses.

The implementation of virtualization also increases security because the virtual driver avoids direct access of the operating system to the real drivers. Moreover, the automotive virtual platform COOQOS Hypervisor SDK contains a type-1 hypervisor that has been designed as a low-complexity embedded hypervisor especially fitting to automotive applications. Reducing hardware driver attack surface and the lean code (10.000 lines of code) are also reasons why virtualization is one the most effective approach to protect against malicious attacks from the outside.