Supervisor Isolation for Safety-Critical Apps on Linux Kernels
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for executing safety-critical applications on non-safety-qualified operating systems, such as Linux-based kernels, face challenges in achieving compliance with safety integrity levels like ISO 26262, and there is a lack of effective solutions to prevent interference and fault-propagation between software components of different criticality levels in mixed-criticality systems.
Innovation Solution
A method and system that utilize a supervisor component to monitor and control transitions of control flow between safety-critical and other software applications, prohibiting access to resources and capturing states during context switches to prevent interference, ensuring freedom from fault-propagation, without requiring redundant resource duplication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a safety-critical application is executed on a non-safety-qualified operating system kernel, then the application can run on widely available platforms, but the system cannot comply with safety integrity level requirements
Solution Approach 1:
The system segments the execution environment into multiple isolated domains (first execution environment for safety-critical applications, second execution environment for the supervisor component). This segmentation allows the safety-critical application to run on a non-safety-qualified kernel while the supervisor enforces safety boundaries, thus achieving both platform compatibility and safety compliance simultaneously.
Solution Approach 2:
The supervisor component acts as an intermediary between the non-safety-qualified kernel and the safety-critical application. It monitors control flow transitions, manages resource access, and enforces safety constraints, thereby bridging the gap between the incompatible kernel and safety requirements without requiring the kernel itself to be safety-qualified.
2Reliability
If the entire operating system kernel is monitored or qualified for safety, then safety integrity can be ensured, but the complexity and cost of qualification becomes practically infeasible for large kernels
Solution Approach 1:
The safety-critical functionality is extracted from the general-purpose kernel by creating a separate first execution environment for safety-critical applications. The supervisor component in the second execution environment provides targeted safety monitoring only for these critical applications, rather than requiring the entire kernel to be safety-qualified. This extraction reduces qualification complexity while maintaining safety integrity for critical functions.
Solution Approach 2:
Safety monitoring and supervision are applied locally only to the first execution environment where safety-critical applications run, rather than uniformly across the entire kernel. The supervisor component selectively monitors control flow transitions and resource access specific to safety-critical applications, providing localized safety assurance without the overhead of qualifying the entire kernel.
3Reliability
If redundant resource duplication is used to prevent interference, then fault-propagation can be prevented, but the system resource consumption and complexity increases
Solution Approach 1:
The supervisor component serves as an intermediary that prevents fault-propagation without requiring redundant resource duplication. It monitors control flow transitions between the safety-critical application and other software, and controls access to shared resources, thereby isolating faults through active supervision rather than through resource duplication.
Solution Approach 2:
The supervisor component continuously monitors control flow transitions and provides feedback control over resource access. When detecting transitions from safety-critical applications to other software, the supervisor prohibits or captures resource states, and when transitions return, it verifies state compliance. This feedback mechanism prevents fault-propagation dynamically without requiring static resource duplication.
Data Source
Figure 1
Figure 2~3
Figure 4
AI summary
A method of executing a safety-critical application on a hardware platform (100) is proposed. The method includes executing, in a first execution environment (120), the safety-critical application (130); executing, in a second execution environment (140), a supervisor component (150) for the safety-critical application; detecting, by the supervisor component (150), at least a transition of a control flow between the safety-critical application (130) and other software (125, 125a, 125b) running in the first execution environment (120). The method further includes in response to detecting that the control flow is transitioning from the safety-critical application (130) to the other software (125, 125a, 125b), prohibiting, by the supervisor component (150), at least one mode of access to at least one resource (114) and/or capturing a state of at least one resource, whereas, in response to detecting that the control flow is transitioning from the other software (125, 125a, 125b) back to the safety-critical application (130), allowing access to the at least one resource (114) again and/or verifying the state.