DOKK Library

The Automotive Grade Linux Software Defined Connected Car Architecture

Authors The Linux Foundation

License CC-BY-4.0

        The Automotive Grade Linux
   Software Defined Connected Car

                                  20th June 2018

© 2018 The Linux Foundation

The paper is licensed for use using Creative Commons Attribution 4.0 International (CC BY 4.0)
                             The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                               The AGL Software Defined Connected Car Architecture

Table of contents

Introduction                                                                                                      2

Virtualization in automotive                                                                                      3

Automotive virtualization requirements and functions                                                              5

AGL Virtualization Approach                                                                                       7

   4.1 Business model considerations                                                                              9

   4.2 Interactions with proprietary solutions                                                                  10

AGL Virtualization architecture                                                                                 11

Automotive virtualization solutions                                                                             12

   6.1 Hypervisors                                                                                              13

       Xen Project - GPL license                                                                                13

       Kernel-based Virtual Machine (KVM) - GPL license                                                         13

       L4Re Micro-Hypervisor – GPL license                                                                      14

       ACRN - BSD license                                                                                       14

   6.2 System Partitioners                                                                                      14

       Jailhouse - GPL license                                                                                  14

       Arm Trusted Firmware (ATF) – BSD license                                                                 15

   6.3 Containers                                                                                               15

   6.4 Commercial solutions                                                                                     15

Conclusion                                                                                                      17

Contributors                                                                                                    17

                              The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                The AGL Software Defined Connected Car Architecture

1.       Introduction
With the increasing momentum of electric, connected and self driving cars, the automotive
industry is today experiencing a total revolution; consequently it is looking for new solutions to
maintain the rapid pace of innovation that the market is demanding while keeping engineering
costs under control. The implementation of the software defined vehicle, an autonomous
connected automobile whose functions can be customized at run-time, demands an innovative
software architecture that can easily scale and drastically reduce software time to market. Open
source is certainly a way to create a fast-innovating ecosystem and to shorten software time to
market. Automotive Grade Linux (AGL), a collaborative project of The Linux Foundation, aspires
to do this by building a de-facto industry standard Linux-based open software platform for
automotive applications. However, the complexity of a software defined vehicle and extreme
level of configurability requires a system architecture which is flexible, scalable and configurable
at run-time. Virtualization is the technology capable of offering this in a secure and efficient way,
thanks to its ability to host the isolated execution of different environments concurrently in a
single hardware system. For this reason, virtualization is seen as the main software defined
vehicle enabler providing the key differentiating factor for Tier-1 and OEM software products.

With this document the AGL Virtualization Expert Group (EG-VIRT), a team of virtualization
professionals active in the AGL community, presents the AGL virtualized software defined
vehicle architecture. The objectives of this white paper are:

     ●   Disseminate automotive virtualization​ inside and outside AGL
     ●   Identify virtualization use cases, requirements and solutions ​for AGL
     ●   Define the ​AGL virtualized software defined vehicle architecture

EG-VIRT desires to build, connect and combine together open source virtualization solutions
around AGL to provide a modular virtualization infrastructure which boosts the creation of
innovative advanced driver-assistance systems (ADAS), in-vehicle Infotainment (IVI) and
telematics products. In the following pages, the AGL virtualization infrastructure vision is
described along with its most important building blocks.

This white paper is organized as follows:

     ●   Section 2 outlines virtualization benefits and challenges in automotive
     ●   Section 3 presents its use cases and requirements
     ●   Section 4 details the AGL approach towards virtualization
     ●   Section 5 shows the AGL Virtualization architecture along with with business models
     ●   Section 6 lists the most interesting virtualization solutions for the AGL community
     ●   Section 7 concludes the document.

                              The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                The AGL Software Defined Connected Car Architecture

 What is virtualization?

 Virtualization is a technique used to create multiple virtual execution environments by means
 of resource abstraction or partitioning. These virtual execution environments are then used to
 consolidate multiple applications on the same hardware in ​server, ​desktop and ​embedded
 In ​server and desktop environments the most common virtualization techniques are
 hypervisors and containers. Hypervisors rely on CPU hardware capabilities (e.g., AMD SVM,
 Arm Virtualization Extensions or Intel VMX) to create the abstraction of a virtual machine (VM)
 for the execution of kernel operating systems and applications. This results in minimal
 overhead and excellent isolation performance. In a server environment hypervisors are used
 in multi-tenant solutions to isolate workloads belonging to different customers. Containers are
 a software only mechanism to create execution environments. When running on a Linux host,
 all containers run on a single Linux kernel instance but in different namespaces for their
 storage, network, etc.. Containers enable high workload density and provide good deployment
 time performance, but being a software-only technology they do not provide the same level of
 isolation provided by hypervisors.
 Embedded environments are, on the other hand, very different from servers and desktops due
 to requirements for power consumption and memory constraints. Therefore, embedded
 systems use size optimized hypervisors and system partitioners for most solutions. The
 former are small footprint hypervisors which minimize the number of their components to be
 more certification-friendly and to provide a smaller attack surface (higher security). System
 partitioners, on the other hand, limit their functionality to the partition of the system resources
 only, aiming at an even smaller footprint and at very low overhead (virtual environments are
 hardware partitions of the system, and therefore run directly on the hardware). More
 information about Hypervisors, system partitioners and containers can be found in Section 6
 of this document. In addition, automotive, aviation, and other embedded systems have
 functional safety certification requirements that must be met before being deployed.
 Virtualization can help device manufacturers meet these function safety requirements by
 isolating the certified components into their own execution environment.

2.     Virtualization in automotive
With hundreds of sensors, actuators, and Electronic Control Units (ECUs) that need to
communicate together while ensuring the highest performance, safety and security, today’s
automobiles are approaching the limits of their complexity. In the future the automotive industry
will provide always connected vehicles running advanced self-driving functions and an
increasing number of cutting edge applications. In this environment the in-vehicle hardware and
software components grow exponentially with the number of applications, causing an explosion
of the vehicle’s architectural complexity. Moreover, increased connectivity and applications lead
to a larger attack surface that needs to be protected and defended.

To address the market requests and provide self-driving always connected vehicles, the
automotive industry needs a hardware and software architecture that guarantees isolation,
simplified systems management, high performance, open standards, interoperability, and

                             The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                               The AGL Software Defined Connected Car Architecture

flexibility. This brings a set of challenges that the automotive industry can achieve by using
virtualization techniques as shown in the table below.

                      Challenge                                       Benefit of virtualization

 1   Software Defined Autonomous Car. ​New                Abstraction. Virtualization abstracts the
     automotive systems functions and services            software from the underlying hardware,
     need to adapt much quicker to new                    thus enabling the concept of Software
     requirements users, manufacturers and                Defined Car. Moreover, it reduces costs
     legal authorities. Time to market is required        and time to market through portability and
     to be much shorter, and functions and                support for legacy solutions.
     services life cycle needs to be similar to the
     one of smart mobile applications.                    Flexibility and Interoperability. ​Updates
                                                          can be automated and performed remotely.
                                                          Solutions based on different licenses,
                                                          security levels and operating systems can
                                                          be combined together.

 2   Costs. ​Each time a new function is added,           Consolidation. ​The number of ECUs and
     additional sensors, cables and ECUs are              wiring complexity can be reduced by
     added to the vehicle. This increases space,          replacing them with virtualized instances in
     weight, and power consumption as well as             a single ECU.
     having an impact on vehicle cost (hardware,
     wire harness, maintenance, deployment,               Flexible architecture. Deployment and
     etc).                                                maintenance can be automated and
                                                          performed remotely resulting in simplified
                                                          maintenance.      However,       software
                                                          integration complexity depends on the
                                                          type/number of shared resources between
                                                          virtual machines. Care should be taken
                                                          when deciding which resources are shared
                                                          between virtual machines.

 3   Security.     ​Third    party    applications,       Isolation. ​Virtualized systems separate
     advanced self driving and infotainment               execution environments (CPU, memory,
     features as well as multiple (also remote)           IO) to implement a multilevel security
     connectivity endpoints increase the security         concept. Isolation guarantees that an
     risk and the attack surface. In addition, more       application security flaw does not affect
     complex architectures result in a larger             other applications running in the system.
     attack surface.                                      Finally, vulnerability lifespan can be
                                                          reduced with remote updates.

                              The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                The AGL Software Defined Connected Car Architecture

 4   Mixed criticality. Vehicles are embedding             Certification. ​Virtualization techniques can
     different functions with heterogeneous                have a very limited code footprint which
     levels of safety. Some of them require                eases certification. Concurrent execution of
     Automotive Safety Integrity Level (ASIL)              systems with different certification levels is
     certification.                                        possible;      however,        the    chosen
                                                           virtualization solution (as well as the
                                                           underlying hardware platform) must comply
                                                           with the most stringent certification level
                                                           requested in the system.

Table 1: Virtualization challenge benefits table

Table 1 shows how virtualization addresses automotive challenges with a number of benefits
that can be easily found in today’s virtualization solutions. For this reason ​virtualization ​can be
seen as ​the software defined connected car enabler​.

3.     Automotive virtualization requirements and
In the introduction of this document we defined virtualization, a technology which enables the
hosting of different execution environments concurrently in a single hardware system. In this
section, the workloads - hereinafter referred to as ​automotive functions - that can populate
these execution environments and the requirements to create them will be discussed in more

Virtualization provides the best performance in terms of security, isolation and overhead when
supported directly by the hardware platform. Table 2 shows the hardware system requirements
needed to enable virtualization.

               Electronic Control Unit (ECU) requirements to enable virtualization

         ●   Hardware virtualization support for CPU, Cache, Memory and interrupts to
             create execution environments (Arm Virtualization Extensions, Intel VT-x and
             AMD SVM, IOMMU, etc.)
         ●   Multicore processor with possibility to allocate one or multiple cores to each
             execution environment
         ●   Trusted Computing Module to isolate safety-security critical applications and
             assets (Arm TrustZone, Intel Trusted Execution Technology, etc.)
         ●   Optionally, ​IO virtualization ​support for GPU and connectivity sharing
Table 2: System hardware requirements to enable virtualization

                              The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                The AGL Software Defined Connected Car Architecture

In fact, an ECU equipped with the hardware components listed in Table 2 can run multiple
execution environments hosting different automotive functions concurrently, securely and with a
good level of performance. Examples of such functions are:

   ●   Instrument Cluster ​displays critical information (speed, signalling, etc.) and needs to be
       isolated from the rest of the system due to reuse of legacy software or regulations.
   ●   IVI systems drive the central console with multimedia/radio functions, Heating,
       Ventilation and Air Conditioning (HVAC), navigation, rear-view camera, and in many
       cases, third-party applications. Isolation is used as a security measure against possible
       vulnerabilities brought by applications installed after market. IVI systems may share
       display, input, and audio interfaces with the Instrument Cluster.
   ●   Telematics ​performs collection of telemetry data from vehicle, may also serve as OEM
       cloud connectivity gateway, and can support installation of edge services.
   ●   Safety critical functions ​include ADAS functions such as parking/lane assistant,
       autonomous driving, digital mirror, etc. These are typically implemented on top of
       AUTOSAR compliant operating systems.

Thanks to the abstraction and isolation created by virtualization, it is possible to concurrently run
heterogeneous types of virtualized automotive functions (e.g., different licenses, operating
systems, legacy solutions, etc.). Moreover, virtualized automotive functions define a set of
characteristics that the virtualization solution must address. Table 3 shows these requirements
in detail.

                    ​Automotive functions requirements for virtualized ECUs

   Computing             ●   Static resource partitioning and flexible on-demand resource
                             allocation (CPU, RAM, GPU and IO).
                         ●   Memory/IO bus bandwidth allocation and rebalancing.

   Peripherals           ●   GPU and displays shall be shared between execution
   sharing                   environments supporting both fixed (each one talks to its own
                             display or to a specified area on a single display) and flexible
                             configurations (shape, z-order, position and assignment of
                             surfaces from different execution environments may change at run
                         ●   Inputs shall be routed to one or multiple execution environments
                             depending on current mode, display configuration (for
                             touchscreens), active application (for jog dials & buttons), etc.
                         ●   Audio shall be shared between execution environments. Sound
                             complex mixing policies for multiple audio streams and routing of
                             dynamic source/sink devices (BT profiles, USB speakers/
                             microphones, etc.) shall be supported.
                         ●   Network shall be shared between execution environments. Virtual
                             networks with different security characteristics shall be supported

                             The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                               The AGL Software Defined Connected Car Architecture

                            (e.g., traffic filtering and security mechanisms).
                        ●   Storage shall support static or shared allocation, together with
                            routing of dynamic storage devices (USB mass storage).

     Security           ●   Root of Trust and Secure boot shall be supported for all execution
                        ●   Trusted Computing (discrete TPM, Arm TrustZone or similar) shall
                            be available and configurable for all execution environments.
                        ●   Hardware isolation shall be supported (cache, interrupts, IOMMUs,
                            firewalls, etc.).

     Performance        ●   Virtualization performance overhead shall be minimal: 1-2% on
     and Power              CPU/memory benchmarks, up to 5% on GPU benchmarks.
     consumption        ●   Predictability shall be guaranteed. Minimal performance
                            requirements shall be met in any condition (unexpected events,
                            system overload, etc.).
                        ●   Execution environments fast boot: Less than 2 seconds for safety
                            critical applications, less than 5 seconds for Instrument Cluster,
                            and 10 seconds for IVI. Hibernate and Suspend to RAM shall be
                        ●   Execution environments startup order shall be predictable.
                        ●   Advanced power management shall be implemented with flexible
                            policies for each execution environment.

     Safety             ●   System monitoring shall be supported to attest and verify that the
                            system is correctly running.
                        ●   Restart shall be possible for each execution environment in case
                            of failure.
                        ●   Redundancy shall be supported for the highest level of fault
                            tolerance with fallback solutions available to react in case of
                        ●   Real time support shall be guaranteed together with predictive
                            reaction time.
Table 3: Virtualization solution requirements to execute multiple automotive functions in
a single multicore platform

4.      AGL Virtualization Approach
AGL is building a Linux-based, open software platform to serve as the de-facto industry
standard for automotive applications. The AGL virtualization approach follows the same
philosophy and aims to provide a virtualization platform that can be used as it is or extended to
consolidate different automotive functions in a single hardware platform.

We recognize virtualization as the next differentiating factor for automotive software, and we see
such software as a set of interchangeable modules that need to be deployed together,

                              The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                The AGL Software Defined Connected Car Architecture

communicate, interact. Any automotive player can combine such modules to provide a unique
and customized solutions. AGL does not develop new hypervisors, but leverages on existing
open source solutions considering them as modules of its architecture.

For this reason the key pillars of the AGL virtualization approach are:

   ●   Modularity​: hypervisors, virtual machines, AGL Profiles and automotive functions are
       seen by the AGL architecture as interchangeable modules that can be plugged in at
       compilation time (and where possible at runtime). The combination of the modules
       makes the difference. We can instantiate different modules. Modules can communicate
       with each other. To achieve modularity, interoperability will be required, especially
       between open and proprietary components.
   ●   Openness​: There is no restriction in the way the AGL virtualization platform can be
       used, deployed and extended. The AGL virtualization architecture supports multiple
       hypervisors, CPU architectures, software licenses and can be executed as a host and
   ●   Mixed Criticality​: Applications with different level of criticality are targeted to coexist and
       run in a virtualized manner. As a consequence, AGL virtualization approach targets to
       consolidate applications different certification requirements.

The virtualization approach presented in this document and implemented as AGL virtualization
platform is fully compliant with the current AGL plans and implementations, as well as it is
orthogonal to the AGL application framework.

In fact, today the AGL application framework already supports applications isolation based on
namespaces, cgroups and SMACK which relies on files/processes security attributes that are
checked by the linux kernel each time an action processes and that work well combined with
secure boot techniques. However, when multiple applications with different security and safety
requirements (infotainment, instrument cluster, telematics, etc.) need to be executed in the
system, the management of these security attributes becomes complex and there is a need of
an additional level of isolation to properly isolate these applications from each other.

This is where the AGL virtualization platform comes into the picture, helping to enhance system
security and to isolate different applications coming from the AGL community but also from third
party developers.

                              The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                The AGL Software Defined Connected Car Architecture

       Illustration 1: AGL virtualization approach integrated in the AGL architecture

4.1 Business model considerations
Regulations on automotive products require compliance with safety standards such as ISO
26262 (“Road Vehicles - Functional Safety”). ISO 26262 defines four Automotive Safety Integrity
Levels (ASIL): ASIL A (the least restrictive), ASIL B, ASIL C and ASIL D (the most restrictive).
The entire system, its hardware and its software from the virtualization solution up to the
applications, needs to be certified to be integrated in production vehicles.

Among the automotive functions presented in Section 3, IVI typically requires ASIL A or no
certification, Instrument Cluster and Telematics typically require ASIL B and more advanced
functions such as ADAS and digital mirrors require ASIL C or D.

ISO 26262 suggestions a classic systems engineering approach to software development and
provides regulations and recommendations throughout the product development process from
conceptual development through decommissioning. Automotive device makers must document
and follow their ISO 26262 certified development process. This process provides checkpoints to
ensure correctness of design through comprehensive verification and validation. During the
development process artifacts are created at every stage to document product design and
verification, track change history of work items, show full traceability of testing based on product
requirements, provide proof of process control and report process compliance as needed to
certification authorities.

However, open source development projects including Automotive Grade Linux prioritize the
value of working software (i.e., “code first approach”) over that of comprehensive
documentation. This raises the question: ”Can a safety-certifiable software element be
developed using open source development practices?” There are many ways to answer this

                              The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                The AGL Software Defined Connected Car Architecture

question but the short answer is no. This is not possible without making changes to the current
AGL software development practice which is arguably what allows AGL to innovate quickly.

An argument can be made that taking an open source software element through safety
certification after development is possible. A relatively small (<10K SLOC) software element
could be snapshot (forked) and taken through an effort to reverse engineer requirements and
validate the testing effort for certification. The result of such an effort would be a certified open
source software element that would have to be managed as a new (forked) product. From this
point, all changes going forward would have to be managed with the same rigor required for a
safety certifiable software element. In process, this is equivalent to managing a commercial
software element. The following questions would then arise:

   ●   Who covers the costs of the required artifacts during design, development and testing?
   ●   Who is the gatekeeper for changes after safety certification?
   ●   Who covers the cost of long term support?
   ●   Will the product be monetized? If so, what are the licensing terms?
   ●   Who bears for the liability of the solution?

The answers to these questions could be addressed by an open source community/project with
lots of coordination. Existing effort in this direction are today ongoing in the OSADL community.

Instead of focusing on a new business model and changing the rigor of the AGL open source
project we will focus on detailing a comprehensive list of properties for the virtualization solution.
It is expected that both open source and proprietary (closed source) software solutions will meet
the requirements outlined in this white paper.


 Open Source Automation Development Lab (OSADL) is an open source community which
 hosts the Realtime and the Safety Critical Linux projects. The former is an initiative which
 aims to develop a realtime version of the linux kernel, while the latter targets to create
 procedures and documents that will lead to a facilitated safety certification Linux-based
 More information can be found at

4.2 Interactions with proprietary solutions
In the short term, it is likely that several proprietary virtualization solutions will meet the
requirements to support AGL specified use-cases. These proprietary solutions will typically have
certification data packages that have been evaluated to assess compliance with the ISO 26262
standard. In the safety case, the virtualization solution is considered a safety element out of
context (SEooC). A SEooC is a safety-related element which is not developed for a specific
item. This means it is not developed in the context of a particular ECU or system. A SEooC
certification data package will provide assumptions of use which must be considered when

                               The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                 The AGL Software Defined Connected Car Architecture

composing the system/ECU. In the case where AGL is used as a software element that is
integrated with a previously certified virtualization solution, the integrator must ensure that the
assumptions of use are followed during the system composition process.

5.        AGL Virtualization architecture
The AGL virtualization architecture is composed by multiple modules that enable the execution
of concurrent applications with different level of criticality (safety and security wise) on a single
multicore hardware.

         Illustration 2: AGL virtualized software defined connected vehicle architecture

The components of such architecture are:

     ●    Execution Environments (EEs)​: these are silos that run concurrently on the system
          and enable the execution of different applications. Different types of EE are supported:
          certified, non certified, trusted, non trusted, open source, proprietary. Some of them are
          classified as Critical Execution Environments (CEEs), because their applications have an
          impact of the safety and security of the system. The others are considered Non Critical
          Execution Environments (NCEEs). They could be implemented as binary applications,
          combination of a set of libraries with the related application, or full featured operating
          systems, etc.
     ●    Communication buses​: Consolidated EEs (and their applications) need to interact and
          communicate with each other. Two types of communication bus are supported by the
              ○ Critical communication bus: it is restricted to Critical Execution Environments
                   (CEEs) only. The communication here has to address important requirements of
                   safety and security.
              ○ Non critical communication bus: it is open to all the EEs available in the system.
                   It has to address high performance and security requirements.

                               The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                 The AGL Software Defined Connected Car Architecture

     ●   Virtualization Platform​: This module leverages on system software and hardware
         functions to create the silos for the execution of different EEs. Depending on the type
         and the combination of the functions used to build this module, the virtualization platform
         can be implemented using technologies like hypervisors, system partitioners, containers,
         etc. EEs can communicate with the Virtualization Platform (EE configuration, power
         management, etc) through specific channels.

Multiple implementations of the above components already exist both open source and
commercial solutions. The role of AGL EG-VIRT is to act as technology integrator among these
different components, enabling the coexistence of multiple virtualized environments together
through different virtualization platforms. For this reason component communication (both
horizontal among EEs, and vertical between the EEs and the Virtualization Platform) is one of
the next work items for AGL and EG-VIRT. An open source implementation of the
communication buses is of pivotal importance for the portability, interoperability, performance,
security and safety of the system. This represents in fact one of the most interesting original
contributions that EG-VIRT is planning in its near future activities.

6.       Automotive virtualization solutions
The virtualization platform functionality can be implemented using different technologies which
come with different trade-offs. Some of them are feature-rich and hard to certify, others have a
more limited set of functions and for this reason can be more easily certified.

The different virtualization technologies available with both open source and proprietary
solutions are hypervisors, system partitioners and containers. Illustration 3 highlights the
architecture of each of them, considering as host kernel an operating systems which runs
directly on top of the hardware and as guest kernel an operating systems which runs on top of
an abstraction layer.

Hypervisors, system partitioners and containers can be combined together to address different
requirements and to extend the set of features the system provides to its EEs.

                      Illustration 3: Virtualization solutions architectures
In the next sections, different open source and proprietary virtualization solutions are detailed.

                             The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                               The AGL Software Defined Connected Car Architecture

6.1 Hypervisors
Hypervisors (Illustration 3B) create a virtual hardware abstraction for automotive functions,
operating systems and applications to use, leveraging on specific hardware features to create
and isolate different execution environments. When run directly on top of the hardware, a
hypervisor is defined as Type-1 or bare-metal, while it is considered a Type-2 solution when it is
executed on top of an additional software layer. Both Arm and Intel processors are equipped
with virtualization extensions and implement directly in hardware memory, timer, and interrupt
virtualization. Different operating systems can run unmodified on top of the same hypervisor.

Hypervisors can provide advanced features such as guest to guest communication
mechanisms, emulation of devices not present on the system, ability of over commit system
resources (memory, CPUs), device sharing and a full set of functions and performance
optimization which leverage on the system awareness of being virtualized (para-virtualization).
Hypervisors can also provide the capability of statically allocating system resources to virtual

Xen Project - GPL license
Xen is a versatile, general-purpose Type-1 hypervisor with mature community governance. It is
developed as a Linux Foundation project and continues improving in response to use in public
clouds, enterprise servers, middleboxes, desktops, vehicles and embedded devices. Xen can
partition or pool plural resources while optionally virtualizing —securely sharing— singular
hardware resources like coprocessors. Xen provides stable interfaces as applications and
platforms evolve. For environments with real-time constraints, it can be configured as a
partitioning hypervisor, eliminating scheduler overhead, reducing interrupt latency and
delegating I/O and memory isolation to hardware with an IOMMU. Xen also provides static CPU
assignment and multiple real-time schedulers (including an ARINC 653 scheduler) to further
isolate resources and provide real-time guarantees. Xen is available in OpenEmbedded
meta-virtualization, and its integration in AGL is planned in future EG-VIRT activities. The Xen
community is currently working on implementing a hypervisor configuration compliant with ISO
26262          ASIL-B         requirements.        For        more        information,       see​.

Kernel-based Virtual Machine (KVM) - GPL license
KVM is a Type-2 hypervisor included in the Linux kernel and implemented as a kernel module. It
exploits CPU Virtualization Extensions to execute guest’s instructions directly on the host
processor(s) and to provide virtual machines (VMs) with isolated execution environments. KVM
borrows from the Linux kernel functions such as memory management and CPU scheduling and
relies on external user space components to execute virtual machines. In fact, KVM doesn’t
offer itself machine or device models abstractions (bios, devices, etc.), but uses Quick Emulator
(QEMU) for emulating guest hardware devices and instantiating guests. In the KVM paradigm
guests are seen by the host as normal POSIX (Portable Operating System Interface for Unix)
processes, with QEMU residing in the host userspace and utilizing KVM to take advantage of
the hardware virtualization extensions. QEMU and KVM are able to run unmodified guests and

                             The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                               The AGL Software Defined Connected Car Architecture

support direct device assignment and static CPU allocation. KVM is today already supported in
AGL for specific platforms and can be used by enabling the agl-egvirt feature at building time.
More information can be found at ​​.

L4Re Micro-Hypervisor – GPL license
L4Re is a light-weight, capability-based, real-time, open source operating system with support
for virtualization (Type-1 hypervisor). Based on a microkernel architecture, the system is built
from user-level components. The kernel is minimized by only providing essential functionality
that foremost ensures spatial and temporal isolation among the components it executes, such
as address spaces and inter-process communication. The user-level infrastructure provides a
POSIX-like environment for running small and trustworthy applications on the L4Re kernel itself,
so-called micro-apps, facilitating the construction of systems with small and application-specific
trusted computing bases. Both hardware-assisted virtualization as well as paravirtualization
employ functionality by the kernel to provide virtual machines on the system. So-called virtual
machine monitors provide the necessary virtual platform for VMs to run. Those also offer a rich
set of VirtIO functions to provide connectivity for VMs. L4Re supports the Arm, x86 and MIPS
multi-core architectures in both 32-bit and 64-bit modes. Besides the open source version a
commercial variant is also available. For more information, see ​​.

ACRN - BSD license
The open source project ACRN defines a Type-1 hypervisor stack for running multiple software
subsystems or domains. As a reference embedded hypervisor implementation, it is flexible and
lightweight, and featured with real-time and safety-criticality capability. The ACRN hypervisor is
composed of two primary components: the hypervisor and its device model. Like Xen, ACRN
has a privileged service OS that has I/O device model, and the VM manager managing and
controlling guest VM. It's geared towards IoT and embedded devices, especially for Automotive.
For more information, see ​​.

6.2 System Partitioners
Such solutions do not create virtual hardware abstraction, but simply partition the system in
different execution environments that can be used to run different automotive functions. System
partitioners, shown in Illustration 3C, do not provide advanced virtualization features (e.g., over
commitment, device emulation, etc.) and extensively leverage on hardware technologies to limit
their footprint in terms of memory and lines of code. As a result, device sharing capabilities are
very limited if not directly supported by the hardware. System partitioners can be used to host
bare metal applications, operating systems or security workloads directly on the hardware
without the need of any abstraction layer (as it is the case of hypervisors).

Jailhouse - GPL license
Jailhouse is a static partitioning hypervisor based on Linux. It runs as bare-metal on the system,
i.e. it takes full control over the hardware and needs no external support. Its management
interface is based on Linux infrastructure, so one should boot Linux first, then enable Jailhouse,
configure it and finally split off parts of the system's resources and assign them to additional

                             The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                               The AGL Software Defined Connected Car Architecture

cells (Guest OS). The host system is called root cell, which initially controls the complete system
resources; when a new cell is created, based on the configuration root cell relinquishes control
over some of its CPU, devices and memory to the new cell. As the cells run in isolation,
hardware support is required to restrict device accesses to the owner of the partition managing
the device. This also makes the Jailhouse a secured option for automotive applications.
Jailhouse focuses on two main things: being small and simple, and allowing cells to execute
with nearly-zero latency. It supports real-time code run, including bare-metal applications and
RTOSes. To know more, visit ​​.

Arm Trusted Firmware (ATF) – BSD license
Arm Trusted Firmware (ATF) is a secure software reference implementation based on Arm
TrustZone, a set of security extensions which partitions the system in two execution
environments, one only allocated to security and safety workloads (secure world), and the other
for the rest (non secure world). It provides support for secure boot, trusted computing functions
via the open source project Open Portable Trusted Execution Environment (OPTEE) and power
management. More information can be found at :

6.3 Containers
Containers (depicted in Illustration 3D) create abstraction starting from the layers above the
Linux kernel. Containers can not run full fledged operating systems but can be used to host
Linux applications. No hardware isolation/security enforcement is guaranteed for Containers
based EEs, and for this reason their use in AGL is not considered for safety and real time
workloads. ​Using Containers within non-safety critical EEs is considered a good solution for
application isolation.

6.4 Commercial solutions
Here below are listed commercial solutions developed by AGL members and part of the AGL

COQOS Hypervisor SDK

COQOS Hypervisor SDK is a next generation hypervisor, specially tailored to the needs of
automotive applications. High efficiency and absolute functional reliability are achieved by a
lean kernel and support for hardware virtualization. The system is flexible, economical, and
functionally reliable due to the minimal trusted code-base. On top of the hypervisor, the SDK
provides modular features corresponding to the needs of the customer.


                             The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                               The AGL Software Defined Connected Car Architecture

Crucible is a Xen-based separation & security hypervisor that provides hardware partitioning,
workload isolation, real-time processing, data confidentiality, secure boot, and runtime integrity.
Crucible enables security and isolation throughout the software stack, and supports multiple
concurrent guest environments (Linux / Android, VxWorks, baremetal, etc). In addition to secure
configuration & positive control of Intel and ARM-based systems, Crucible provides anti-reverse
engineering protections and system accreditation / certification artifacts (​​).

Green Hills Integrity® Multivisor™

INTEGRITY Multivisor is the virtualization service for the safety and security certified
INTEGRITY RTOS. Since 2003, INTEGRITY Multivisor has been the industry’s only safe and
secure certified architecture for simultaneously running one or more guest operating systems
alongside life and mission-critical functions on a wide range of multicore SoC’s. INTEGRITY
Multivisor, with its advanced ASIL D qualified MULTI IDE, enable rapid, optimized and cost
effective complex system design without compromising safety, security or performance.


Based on Open Source Xen hypervisor, Nautilus provides a solution accelerator that helps
realize a converged digital cockpit for the modern day connected vehicle. It is highly
configurable, supports multiple guest operating systems including AGL & Android and can be
ported to automotive platforms from Intel, Renesas, Texas Instruments, Qualcomm, NXP,
Mediatek & other commercially available Automotive SOC's. GlobalLogic also provides custom
development services in the automotive domain around Nautilus (see more at ​Nautilus​).


PikeOS is an RTOS including a hypervisor based separation microkernel designed for the
highest levels of safety and security. PikeOS technology has been certified on a wide range of
projects using various certification standards including DO-178B/C, IEC 61508, EN 50128, IEC
62304 and ISO 26262. It combines a modular, flexible and future proof architecture with a large
variety of certification standards. With this full European solution customers benefit in terms of
reduction of cost, risk and full system certification lead times. (​​).


VOSYSmonitor is an automotive system partitioner based on the Arm TrustZone security
extensions. It configures two physical partitions (hardware-isolated) in the system and runs a
safety critical certified critical operating system (e.g., an RTOS) together with a non critical
operating system (AGL, Linux, Android, etc.). VOSYSmonitor is certified ISO 26262 ASIL-C and
provides a high level of customization, as it can run any type of operating system in both system
partitions. (​​).

                               The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                                 The AGL Software Defined Connected Car Architecture

7.     Conclusion
This white paper is the result of the Automotive Grade Linux Virtualization Expert Group
(EG-VIRT) activity, which aims to pave the way for open source virtualization in production cars.
AGL considers virtualization as part of its architecture that is particularly important to enable
multiple AGL profiles (IVI, Telematics, ADAS, etc.) and to implement the concept of software
defined vehicle.

In this document, automotive virtualization has been presented with its benefits, challenges,
requirements and use cases to foster the use of this technology on all next generation
automotive vehicle architectures. Moreover, business model considerations have been
presented, highlighting existing gaps between open source projects and functional safety
certification. The Linux Foundation is working to fill these gaps and EG-VIRT will rely on the
results of this work to build a certified and open source virtualization infrastructure. In addition, a
non-exhaustive list of virtualization solution has been presented, detailing the trade-offs of each
solution and suggesting the integration of multiple solutions to cover a wider range of

Finally, the most important contribution of this white paper is the definition of the AGL virtualized
software defined vehicle architecture, which has been presented together with its components.
This new architecture will serve as input for the future activities of AGL (e.g., Reference
Hardware System Architecture, AGL Application and Security Frameworks, etc.) and of
EG-VIRT. More in particular, in this document the role of EG-VIRT has been defined as
virtualization technology integrator, identifying as key next contribution the development of a
communication bus reference implementation for the interaction between Execution
Environments and the Virtualization Platform. An open source implementation of this component
is seen by EG-VIRT as an enabler of automotive virtualization portability, interoperability,
performance, security and safety.

Future EG-VIRT activities will focus on this communication, on extending the AGL support for
virtualization (both as a guest and as a host), as well as on IO devices virtualization (e.g., GPU).

8.     Contributors
Michele Paolino - Virtual Open Systems
Walt Miner - The Linux Foundation
Daniel Bernal - Arm
Artem Mygaiev - EPAM
Tiejun Chen - VMware
Rich Persaud - OpenXT
Tero Antero Salminen - OpenSynergy
Adam Lackorzynski - Kernkonzept
Ciwan Gouma - SYSGO
Praveen Kumar - Sasaken
Alexander Damisch - Kevix

                            The Linux Foundation Automotive Grade Linux (AGL) Virtualization Expert Group (EG-VIRT)
                                                              The AGL Software Defined Connected Car Architecture

Jonathan Kline - Star Lab
Denys Balatsko - GlobalLogic
Dan Mender - Green Hills Software
Toni Hoang - Daimler

License for use: Creative Commons Attribution 4.0 International (see