Automotive Virtualization: How Automotive Hypervisor Enables Innovation and Compliance
Connected vehicles are here to stay. And that brings plenty of opportunities to innovate — as well as challenges in compliance. Automotive virtualization may be the answer.
Read along or jump ahead to the section that interests you the most:
➡️ automotive hypervisor is easy with Helix QAC
Back to topThe Rise of Automotive Virtualization and the Automotive Hypervisor
Vehicles used to have standalone systems for each function. Vehicle control. Telematics. Diagnostics.
Today, there are more integrated systems handling multiple functions. This includes advanced driver assistance systems (ADAS) and infotainment. And virtualization technology can provide a solution to some of the system design challenges.
As vehicles components are virtualized, it creates opportunities for development teams. They can reduce complexity and speed up development times, for instance. This can be a competitive advantage.
But virtualization also brings security concerns and compliance constraints. Using a hypervisor can help you address these concerns.
Back to topWhy Use an Automotive Hypervisor?
Hypervisors provide a layer between the operating system and the hardware.
Type 1 vs. Type 2 Hypervisors
Type 1 hypervisors are the most popular. They’re deployed on top of system hardware. They’re also known as bare metal hypervisors. The Xen Project, for instance, develops an open source type 1 hypervisor.
Type 2 hypervisors run on top of a host operating system. They’re also known as hosted hypervisors.
How Hypervisors Protect Embedded Systems
An operating system running on a hypervisor doesn’t have access to real hardware resources. And because hypervisors virtualize software environments, they can be isolated from each other.
This is key for components with different ASIL levels. They can be kept separate, so they don’t need to be recertified for ISO 26262 with every system change.
That’s why embedded hypervisors are important for compliance, particularly in the automotive industry. Plus, using hypervisors can protect safety-critical applications from hackers, too.
Back to topCompliance Concerns With Automotive Hypervisors
The automotive industry is heavily regulated, with strict safety requirements. It’s critical that every component of a vehicle is safe. Failure isn’t an option. Systems must be designed to prevent failure. And that’s why all automotive embedded software must comply with ISO 26262.
The first step in ISO 26262 compliance is identifying the system’s automotive safety integrity level (ASIL). This is important for determining the risk each piece of software poses to the vehicle. And the ASIL level determines what you need to do to ensure safety.
The next step is in Part 6 of ISO 26262, which addresses software development. This section includes several compliance tables that lay out what you’ll need to do to comply (in relation to your ASIL level).
A compliant automotive hypervisor will need to comply with the design methods in Table 8: Design Principles for Software Unit Design and Implementation.
Here are the methods outlined in Table 8:
- 1a. One entry and exit point in subprograms and functions.
- 1b. No dynamic objects or variables, or else online test during their creation.
- 1c. Initialization of variables.
- 1d. No multiple use of variable names.
- 1e. Avoid global variables or else justify their usage.
- 1f. Limited use of pointers.
- 1g. No implicit type conversions.
- 1h. No hidden data flow or control flow.
- 1i. No unconditional jumps.
- 1j. No recursions.
Using MISRA coding rules will help you comply with design methods in Table 8 of ISO 26262.
Here’s an example of how an ISO 26262 method from Table 8 maps to MISRA coding rules.
ISO 26262 Table 8 1a. relates to:
MISRA Rule 14.4:
Do not use the goto statement
MISRA Rule 14.7:
A function shall have a single point of exit at the end of the function
📕 Related Resource: More on ISO 26262 compliance >>
Back to topHow the Xen Project Hypervisor Achieves Compliance
What Is Xen Project?
The Xen Project is an open source hypervisor that allows multiple operating systems to run on hardware simultaneously.
Who Contributes?
Many development teams contribute to the Xen Project. Contributors include Alibaba/Aliyun, AWS, AMD, Arm, Bitdefender, Cavium, Citrix, EPAM, Intel, Huawei, Oracle, Qualcomm, Suse, and XILINX.
Why Coding Standards Are Important for Functional Safety
Open source is great for innovation, but that makes it difficult to be compliant. Embedded hypervisors need to meet security requirements and achieve safety certifications.
Using a coding standard is key for safety and security.
By checking open source code against a standard, such as MISRA, you can ensure it’s safe, secure, and reliable. And applying MISRA to an open source hypervisor helps to make it suitable for use in safety-critical, embedded applications.
How to Apply Coding Standards
Applying and enforcing coding standards can be difficult. Using a static analyzer makes it easier.
The Xen Project uses Helix QAC to apply MISRA rules. This ensures the Xen hypervisor is MISRA-compliant. And that is critical for demonstrating ISO 26262 compliance — which automotive vendors require.
So, Helix QAC makes it possible for automotive vendors to use the Xen Project hypervisor.
See why Helix QAC is the best static code analysis tool for MISRA C and C++. Register for a free trial.
Back to top