This blog is part two in a three part series. Read part one here.
The AGL Software Defined Car Architecture white paper defines how the AGL target platform for software defined vehicles can be implemented by using virtualization techniques, presented in the document along with their automotive benefits, challenges, use cases and requirements.
From the beginning, this work objective was to provide an architecture for a virtualization platform that can be used, extended or customized by Tier-1 or OEM companies to reduce time to market.
However, the automotive market has important certification requirements that challenge AGL and its development process. Existing efforts in this direction are ongoing from the Open Source Automation Development Lab (OSADL) and XEN communities. Thanks to its virtualization approach, described here below, AGL is able to leverage these and any possible future activities in this direction.
[Figure 1 | AGL virtualization approach integrated in the AGL architecture (via AGL Software Defined Car Architecture white paper)]
The AGL approach towards virtualization
The key targets that drove the design of the AGL virtualized software connected car architecture are:
- Modularity: hypervisors, virtual machines, automotive functions, etc. are considered interchangeable modules and can be changed at compile-time or at run-time. Tier-1s and OEMs are able to combine them together and to differentiate themselves from the competition.
- Openness: The AGL virtualization architecture supports multiple hypervisors, CPU architectures, software licenses and deployments (it can be executed as a host or as a guest system).
- Support for mixed-criticality: The objective of this architecture is to consolidate applications with different levels of criticality. Heterogeneous requirements are considered in terms of safety, real time responsiveness, etc.
These three targets uniquely position the AGL platform among existing automotive virtualized solutions and open source projects.
The AGL role in the open source automotive virtualization community
As a matter of fact, different automotive virtualization solutions already exist and there are already several open source communities working on virtualization. Notable examples are XEN and KVM, but there are also L4Re, ACRN, Jailhouse and ATF. What is then the role of AGL?
Selecting one of them has several disadvantages: First and foremost, it would break the openness target which drove the solution design from the beginning. Second, this would impose a virtualization solution to Tier-1 and OEMs, and consequently this would make them struggle to find ways to differentiate their products. Also the development of a new virtualization solution would not pay: for not leveraging the code, huge experience and expertise of these communities, as well as for the important challenges of developing a new virtualization solutions which performs better than the existing.
This is why, AGL will not develop a new hypervisor but will leverage on existing open source solutions (and on the experience and experise of the respective communities) considering them as modules of its architecture. As a result, the AGL (and more in particular the Virtualization Expert Group) role is the one of virtualization technology integrator, aiming at supporting different virtualization technologies and to make them interoperable and interchangeable. 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.