Hypervisor Driver Isolation for Reliable Autonomous Driving
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing autonomous driving systems face challenges in leveraging the open-source resources of the Linux ecosystem while achieving high levels of reliability, as the Linux system inherently cannot achieve such reliability, leading to potential system crashes due to malfunctioning device drivers.
Innovation Solution
A driving system architecture is developed using a hypervisor based on a microkernel system, such as sel4 or QNX, with a Linux virtual machine and a device driver module deployed on the hypervisor, allowing the driving module to access peripherals without being part of the virtual machine, thereby isolating failures to prevent system-wide crashes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If Linux system is used as the operating system for autonomous driving modules, then open-source resources and ecosystem compatibility are improved, but system reliability deteriorates due to potential driver malfunctions causing system crashes
Solution Approach 1:
The system is segmented into multiple virtual machines with different functions (autonomous driving module, sensor processing module, infotainment module, etc.), each running on its own isolated virtual machine. This segmentation allows Linux to be used in non-critical modules while maintaining reliability in critical modules through the hypervisor layer.
Solution Approach 2:
A hypervisor based on microkernel system (sel4 or QNX) is introduced as an intermediary layer between the hardware and the Linux-based virtual machines. This intermediary provides isolation and protection, ensuring that even if Linux drivers malfunction, the entire system doesn't crash - only the affected virtual machine is impacted.
2Ease of operation
If device driver module is deployed inside the virtual machine, then ease of operation and driver management are improved, but system stability deteriorates because a malfunctioning driver can crash the entire system
Solution Approach 1:
The device driver module is extracted from the Linux virtual machine and deployed directly on the hypervisor layer. This extraction maintains the benefits of centralized driver management while removing the risk that driver malfunctions will crash the entire system - only the specific virtual machine attempting to use the driver is affected.
Solution Approach 2:
The hypervisor serves as an intermediary between the device driver module and the virtual machines. This intermediary architecture allows drivers to be managed centrally while providing isolation - when a driver malfunctions, the hypervisor contains the error and prevents it from crashing the entire system.
3Reliability
If commercial microkernel operating systems are used, then system reliability is improved, but access to open-source Linux ecosystem resources deteriorates
Solution Approach 1:
The hypervisor layer provides universal support for multiple operating systems and ecosystems. It can simultaneously support Linux-based virtual machines for accessing open-source resources while also supporting safety-critical applications requiring microkernel reliability, making the system multi-functional and adaptable to different requirements.
Solution Approach 2:
The system segments different functional requirements into separate virtual machines - Linux-based VMs can access open-source ecosystem resources while other VMs can use certified safety-critical OSes, allowing both open-source access and high reliability to coexist in different segments of the system.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The present application relates to a driving system and a method for constructing the same, a vehicle, and a storage medium. The system includes: a hypervisor deployed on a processor; a virtual machine deployed on the hypervisor; a driving module deployed on the virtual machine; and a device driver module deployed on the hypervisor, where the driving module accesses peripherals via the device driver module.