QNX Advanced Virtualization Frameworks Architecture

The QNX Advanced Virtualization Frameworks allow you to build systems that share resources such as graphics, audio, and input devices among multiple OSs, while separating the management of critical services and non-critical services to mitigate the effects of faults.

As illustrated below, the virtualization frameworks augment the QNX Hypervisor by allowing you to implement the front ends of resource sharing in guest OSs and the back ends in the host. This design protects the hardware from any vulnerabilities of guest OSs, and lets you run multiple OSs on a single ECU, which saves hardware costs. The host manages the critical services (i.e., the instrument cluster) while both the host and the guest manage the non-critical services (i.e., infotainment).

Architecture diagram showing multiple displays managed by hypervisor host and guest, and specific graphical elements supported by each

Figure 1. QNX Advanced Virtualization Frameworks architecture

Although this release focuses on Cockpit Domain Controllers (CDC) with multiple displays, the virtualization frameworks also apply to other markets such as medical and industrial control. The default design for the CDC example places the instrument cluster in the host and renders the cluster on the dashboard display. This design offers higher efficiency (e.g., less CPU usage per frame drawn) than placing it in a guest. Because an instrument cluster is designed to be passive, with little to no attack surface, the risk of running it in the host is minimized. The infotainment apps run in an Android guest and other infotainment functions run in the QNX host but are rendered on the head unit along with the apps.

The QNX Advanced Virtualization Frameworks design is flexible. Where required, an application such as an instrument cluster display may also be run within a separate guest.

CAUTION:

If you want to build a safety-certified product, you must acquire the QNX Hypervisor for Safety (instead of the non-certified QNX Hypervisor). Many of the virtualization frameworks have variants designed for safety certification. Please contact your QNX Sales team for details on these variants. Be sure to use the proper variant that is designed for your safety requirements; for example, a non-safety variant may run correctly in a safety system but it may not support your required safety case.

Supported guests

The default use case targeted by this release is a QNX Hypervisor that hosts one Android guest. To see which Android OS versions are supported and which QNX Hypervisor version this release is based on, see the QNX Advanced Virtualization Frameworks Release Notes.

The QNX Hypervisor supports other guest types, namely Linux and QNX Neutrino. These too can be adapted to implement the front ends of resource sharing and thereby provide infotainment and instrument cluster functions. Linux guests can involve customized development because they are not being standardized for device sharing in the same way as Android. Please contact your QNX Sales team for options when working with Linux and QNX Neutrino guests.

Note: Throughout this document, when we refer to simply a “guest” or “guest OS”, an Android guest OS is implied unless explictly stated otherwise.