XEN and the future of automotive: how open source hypervisor becomes a competitor to commercial automotive solutions
This is a story in two parts - a new round of automotive development. In the first, Alex Agizim, CTO Automotive & Embedded Systems in EPAM , will talk about virtualization in a car computer. And also how and why the open source hypervisor XEN can become a full-fledged competitor to commercial solutions for the automotive industry.
Immediately I must warn you - I will not throw at the reader pieces of code and engineering subtleties. Here we will talk about global things that we think will change the automotive industry in the next 2-4 years. Just as 12 years ago, mobile phones changed forever with the advent of Android and Apple iOS.
')
In EPAM Automotive, we are engaged in two large blocks: virtualization and a cloud platform for deploying services directly to the car. This story is about the first.
If you follow the automotive theme, you probably noticed how actively Google is developing the theme of info-info with its Android Auto OS. Since the end of last year, the company has entered into several strategic partnerships with automakers to integrate Android Auto OS into the car.
But manufacturers still have concerns. The main reason is safety. In today's and future cars, the Infotainment Cluster and the Instrumental Cluster, which contains “vital” instruments and indicators, become one and use the same resources. Physical arrows and indicators replaced painted. However, the driver must see true readings of speed, fuel level, state of the braking system, engine no matter what. It is unacceptable if, somewhere along the way, the screens suddenly freeze and require a reboot. And from the experience of Android smartphones, we know that this is quite possible.
Car manufacturers solve this problem in the forehead: put two or more computers. For example, the first deals with the drawing and maintenance of the entire dashboard. In the second, Android Auto OS runs and shows navigation, music, applications, etc.
This option has several drawbacks. First, several computers are more expensive than one. Secondly, implementation becomes more complicated: it is necessary to ensure the exchange of information between the Android part and the insturmental cluster, consistency and many other aspects.
Another option is to use virtualization with the help of the hypervisor, following the example of the cloud. The power and capabilities of modern microprocessors in car computers is quite enough. At least two screens are connected to the computer. One - for Android - infotainment. The other is for dashboard maintenance. Two operating systems run in isolated virtual machines. Even if Android “gets tired” and falls, only the virtual machine in which it runs will reboot.
With this consolidation, we can work on one computer and make integration much easier. But there are nuances here.
In the data center, the hypervisor only does what cuts the processor, memory, and storage between different virtual machines. It also ensures that the “virtuals” do not climb into each other’s space. At the same time, they all have the same set of services that they receive from the server platform.
In the same car computer, in addition to the CPU, RAM and storage, there are different coprocessors for specific tasks. For example, the same GPU, which is needed and Android, and the dashboard. Hence, the task of the hypervisor is to enable both operating systems to use coprocessors. In addition, make sure that Android does not plug the coprocessor into some kind of illegal team or software error.
This is a requirement of functional safety - the Instrumental Cluster should work without regard for possible Android dances. Therefore, the hypervisor must be sufficiently advanced and have special mechanisms by which complete isolation is provided.
Hardware this insulation already provide modern processors. We take on the software part. Namely, we modify the open source XEN Hypervisor so that it can work in the car, taking into account all the nuances of the environment. In it, we have provided the following blocks.
First, the computer has a lot of peripherals, buttons, touchscreen networks, etc ... Virtualization of peripherals is already supported by a set of drivers.
Secondly, we virtualize GPU and coprocessors. If one of the virtual machines does something with any of the coprocessors in the system, this will not affect the work of the other virtual machine.
Third, TEE Support virtualization is implemented - the trusted execution environment. This is a special, hardware-protected zone in the processor that deals with the execution of various security procedures. But since there are more than one operating system, requests from them to TEE are also separated.
Below you can see the status of the component and if you are interested to see the code.
Any operating system manages power and performance and can put the computer into low power mode according to current tasks and load. Car Android may also want to do the same: if there are no current tasks, it decides to send the processor to power save mode. But the OS that deals with the devices must continue to work. We solve this conflict with a special extension of the hypervisor. It monitors the state of the entire system and controls the power and performance.
The next moment is realtime. The system should work with a guaranteed schedule. We also deal with this as part of the XEN Real-Time Scheduler.
The last in turn, but the first in importance for the future auto industry unit. Car manufacturers today realize that a virtualization approach will help them to actually create significantly more flexible and powerful systems for servicing digital cockpit. This requires a automotive-grade hypervisor.
There are 3-4 commercial automotive-grade hypervisors on the market. But all commercial products have disadvantages:
All these problems are solved by an open source hypervisor. Initial free. There is access to the source, you can make any changes. To do this, you can organize your team or contact the service companies. Full freedom is preserved, because when the supplier changes, the source remains with the manufacturer.
On the way to the open source remains the last, but the key barrier. An open hypervisor for a car must be functional safety compliant. Until recently, everyone believed that making it impossible. Now there is progress.
The last time we are actively working with XEN Hypervisor open source community. The challenge is to adapt the development process so that XEN can be certified for safety.
At the end of March, a summit was held in Cambridge, where all interested people gathered. First, all the main companies that are engaged in the development of XEN: Citrix, ARM, Xilinx, Renesas, EPAM. Secondly, companies that are engaged in certification. Thirdly, companies that provide tools to automatically analyze the system and identify problem areas.
As a result of the summit, we developed a plan according to which it is perfectly possible to make functional safety compliant open-source hypervisor. By the end of this year, we plan to obtain a specific set of necessary artifacts, so that when XEN is integrated into car computers, they can be certified for safety.
XEN becomes a full-fledged competitor to commercial solutions in the automotive industry and takes away from them the last argument about the lack of safety certification.
From the last - in the middle of July passed the Xen Developer Summit . Function Safety was one of the main themes. We presented an approach to the solution of Functional Safety (under the link PDF).
Probably, this question arose in some from the very beginning.
The XEN project has existed since 2003 and, compared to other open-source solutions, has a very wide deployment in data centers. He has already become quite mature. Since 2012, XEN has native support for ARM architecture. And the processors of this particular architecture are mainly used in the automotive industry.
In addition, we did a lot of work, analyzed different solutions and achieved very good performance indicators. For example, if the performance of the operating system that runs on a processor without virtualization is X, then on a virtual machine it is 0.96-0.97X. And in commercial hypervisors, performance drops by up to 30%. The difference in order looks convincing.
Therefore, XEN seems to us a suitable basic solution. Therefore EPAM will drive this project. There are already several European automakers who are evaluating a solution based on XEN for future cars with digital cockpit, Android inside and other things that I mentioned above.
Parallel to this big story, we are developing our own connected vehicle Aos platform. Its main idea is that, on the one hand, we give connected services developers the opportunity to deploy them directly to a car computer, and on the other hand, we isolate them from critical functions, ensuring security. I will tell about it in the following part.
Immediately I must warn you - I will not throw at the reader pieces of code and engineering subtleties. Here we will talk about global things that we think will change the automotive industry in the next 2-4 years. Just as 12 years ago, mobile phones changed forever with the advent of Android and Apple iOS.
')
In EPAM Automotive, we are engaged in two large blocks: virtualization and a cloud platform for deploying services directly to the car. This story is about the first.
Two approaches
If you follow the automotive theme, you probably noticed how actively Google is developing the theme of info-info with its Android Auto OS. Since the end of last year, the company has entered into several strategic partnerships with automakers to integrate Android Auto OS into the car.
But manufacturers still have concerns. The main reason is safety. In today's and future cars, the Infotainment Cluster and the Instrumental Cluster, which contains “vital” instruments and indicators, become one and use the same resources. Physical arrows and indicators replaced painted. However, the driver must see true readings of speed, fuel level, state of the braking system, engine no matter what. It is unacceptable if, somewhere along the way, the screens suddenly freeze and require a reboot. And from the experience of Android smartphones, we know that this is quite possible.
Car manufacturers solve this problem in the forehead: put two or more computers. For example, the first deals with the drawing and maintenance of the entire dashboard. In the second, Android Auto OS runs and shows navigation, music, applications, etc.
This option has several drawbacks. First, several computers are more expensive than one. Secondly, implementation becomes more complicated: it is necessary to ensure the exchange of information between the Android part and the insturmental cluster, consistency and many other aspects.
Another option is to use virtualization with the help of the hypervisor, following the example of the cloud. The power and capabilities of modern microprocessors in car computers is quite enough. At least two screens are connected to the computer. One - for Android - infotainment. The other is for dashboard maintenance. Two operating systems run in isolated virtual machines. Even if Android “gets tired” and falls, only the virtual machine in which it runs will reboot.
With this consolidation, we can work on one computer and make integration much easier. But there are nuances here.
Automotive hypervisor
In the data center, the hypervisor only does what cuts the processor, memory, and storage between different virtual machines. It also ensures that the “virtuals” do not climb into each other’s space. At the same time, they all have the same set of services that they receive from the server platform.
In the same car computer, in addition to the CPU, RAM and storage, there are different coprocessors for specific tasks. For example, the same GPU, which is needed and Android, and the dashboard. Hence, the task of the hypervisor is to enable both operating systems to use coprocessors. In addition, make sure that Android does not plug the coprocessor into some kind of illegal team or software error.
This is a requirement of functional safety - the Instrumental Cluster should work without regard for possible Android dances. Therefore, the hypervisor must be sufficiently advanced and have special mechanisms by which complete isolation is provided.
Hardware this insulation already provide modern processors. We take on the software part. Namely, we modify the open source XEN Hypervisor so that it can work in the car, taking into account all the nuances of the environment. In it, we have provided the following blocks.
1. Complete isolation of the virtual machines on which the info-equipment and dashboard work
First, the computer has a lot of peripherals, buttons, touchscreen networks, etc ... Virtualization of peripherals is already supported by a set of drivers.
Secondly, we virtualize GPU and coprocessors. If one of the virtual machines does something with any of the coprocessors in the system, this will not affect the work of the other virtual machine.
Third, TEE Support virtualization is implemented - the trusted execution environment. This is a special, hardware-protected zone in the processor that deals with the execution of various security procedures. But since there are more than one operating system, requests from them to TEE are also separated.
Below you can see the status of the component and if you are interested to see the code.
2. Power and Performance
Any operating system manages power and performance and can put the computer into low power mode according to current tasks and load. Car Android may also want to do the same: if there are no current tasks, it decides to send the processor to power save mode. But the OS that deals with the devices must continue to work. We solve this conflict with a special extension of the hypervisor. It monitors the state of the entire system and controls the power and performance.
The next moment is realtime. The system should work with a guaranteed schedule. We also deal with this as part of the XEN Real-Time Scheduler.
3. Functional safety
The last in turn, but the first in importance for the future auto industry unit. Car manufacturers today realize that a virtualization approach will help them to actually create significantly more flexible and powerful systems for servicing digital cockpit. This requires a automotive-grade hypervisor.
There are 3-4 commercial automotive-grade hypervisors on the market. But all commercial products have disadvantages:
- high cost of the license;
- the inability to easily change anything in the software according to their needs
- manufacturer for such breaks check and terms;
- vendor lock.
All these problems are solved by an open source hypervisor. Initial free. There is access to the source, you can make any changes. To do this, you can organize your team or contact the service companies. Full freedom is preserved, because when the supplier changes, the source remains with the manufacturer.
What is left to solve
On the way to the open source remains the last, but the key barrier. An open hypervisor for a car must be functional safety compliant. Until recently, everyone believed that making it impossible. Now there is progress.
The last time we are actively working with XEN Hypervisor open source community. The challenge is to adapt the development process so that XEN can be certified for safety.
At the end of March, a summit was held in Cambridge, where all interested people gathered. First, all the main companies that are engaged in the development of XEN: Citrix, ARM, Xilinx, Renesas, EPAM. Secondly, companies that are engaged in certification. Thirdly, companies that provide tools to automatically analyze the system and identify problem areas.
As a result of the summit, we developed a plan according to which it is perfectly possible to make functional safety compliant open-source hypervisor. By the end of this year, we plan to obtain a specific set of necessary artifacts, so that when XEN is integrated into car computers, they can be certified for safety.
XEN becomes a full-fledged competitor to commercial solutions in the automotive industry and takes away from them the last argument about the lack of safety certification.
From the last - in the middle of July passed the Xen Developer Summit . Function Safety was one of the main themes. We presented an approach to the solution of Functional Safety (under the link PDF).
Why XEN?
Probably, this question arose in some from the very beginning.
The XEN project has existed since 2003 and, compared to other open-source solutions, has a very wide deployment in data centers. He has already become quite mature. Since 2012, XEN has native support for ARM architecture. And the processors of this particular architecture are mainly used in the automotive industry.
In addition, we did a lot of work, analyzed different solutions and achieved very good performance indicators. For example, if the performance of the operating system that runs on a processor without virtualization is X, then on a virtual machine it is 0.96-0.97X. And in commercial hypervisors, performance drops by up to 30%. The difference in order looks convincing.
Therefore, XEN seems to us a suitable basic solution. Therefore EPAM will drive this project. There are already several European automakers who are evaluating a solution based on XEN for future cars with digital cockpit, Android inside and other things that I mentioned above.
Parallel to this big story, we are developing our own connected vehicle Aos platform. Its main idea is that, on the one hand, we give connected services developers the opportunity to deploy them directly to a car computer, and on the other hand, we isolate them from critical functions, ensuring security. I will tell about it in the following part.
Source: https://habr.com/ru/post/460507/
All Articles