Automotive open source virtualization: AGL virtualization architecture
July 26, 2018
Story
The AGL Software Defined Car Architecture white paper edited by the AGL EG-VIRT and published by Linux Foundation details the AGL virtualized architecture.
This blog is part three in a three part series. Read part two here. Read part one here.
The AGL Software Defined Car Architecture white paper edited by the AGL EG-VIRT and published by Linux Foundation details the AGL virtualized architecture, built upon heterogeneous execution environments that support mixed criticality and communicate through communication buses. Figure 1 shows an overview of this architecture, which is described in detail in the next sections.
[Figure 1 | AGL virtualized software defined connected vehicle architecture (via AGL Software Defined Car Architecture white paper)]
AGL virtualized architecture
More in particular, the AGL virtualized software connected vehicle architecture is composed by Execution Environments (EEs), communication buses and the Virtualization Platform.
The latter is the most important module, because it enables a safe and secure execution of multiple applications, virtual machines, or operating systems consolidating them in a single hardware/software platform. It can be implemented using technologies like hypervisors, system partitioners, containers, etc.
EEs on the other hand, are software silos built in some cases with the help of specific CPU hardware extensions, where the different automotive functions are executed. Not all the EEs have the same performance, safety and security requirements. For this reason, two types of EEs have been identified: Critical and Non Critical (CEEs and NCEEs). EEs can be implemented in several ways, following the openness target of the architecture design mentioned above, e.g., bare metal application, virtual machine, container, unikernels or a full fledged operating system like AGL itself.
Following the characteristics of the EEs, the communication buses can be critical or non critical as well. To guarantee isolation, data safety and privacy the critical bus is restricted to sharing information between CEEs only. Critical functions can therefore decide to share here information that in no way has to be shared with NCEEs. Conversely, the non critical communication bus creates a bridge between critical and non critical EEs. This bus targets performance and security more than safety (which is more important for the critical communication bus).
Next steps and conclusions
With the recent publication of the AGL Software Defined Car Architecture white paper, AGL defined an open, modular and mixed critical virtualized architecture for software defined connected vehicles, and claimed its role of virtualization technology integrator aiming to provide a flexible virtualization platform to OEMs and Tier-1 companies. From the technical point of view, this means that all the developments that aim to enhance openness, modularity and portability of its platform (e.g., development of new interoperable APIs, portable drivers, test bench, image building tools for different virtualization solutions, etc.) are of interest for AGL.
In this context, AGL and in particular its EG-VIRT group, has identified future challenges and activities for the implementation of this architecture. First, the AGL support for virtualization solutions needs to be enhanced. Second, Input Output (IO) virtualization has been identified as an important challenge to be addressed, particularly for devices like GPUs. Last but not least, the design and implementation of an open source communication bus between critical and non critical automotive functions will be the principal objective of EG-VIRT. This part is in fact seen as an enabler of virtualized automotive functions portability, interoperability, performance, security and safety.
More information on the next EG-VIRT activities can be found at https://wiki.automotivelinux.org/eg-virt.
