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. Virtualization may be the answer.
Read along or jump ahead to the section that interests you the most:
- The Rise of Automotive Virtualization
- Why Use an Automotive Hypervisor?
- Compliance Concerns With Automotive Hypervisors
- How the Xen Project Hypervisor Achieves Compliance
- ➡️ Start Your Free Helix QAC Trial
The Rise of Automotive Virtualization
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 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 and compliance constraints. Using a hypervisor can help you address these concerns.
Why 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 , 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.
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.
Compliance Concerns With Automotive Hypervisors
The automotive embedded software must comply with ISO 26262. 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
The first step in 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 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:
How the Xen Project Hypervisor Achieves Compliance
What Is Xen Project?
The is an open source hypervisor that allows multiple operating systems to run on hardware simultaneously.
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 makes it easier.
The 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++.