Software Decomposition for Safety Applications
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current functional safety standards in software are rigid, requiring costly and time-consuming design and validation processes, especially when non-safety related applications need upgrades, as they necessitate recertification of both safety and non-safety related applications.
Innovation Solution
A software decomposition process that separates safety-related and non-safety related applications using distinct logical units and modules, allowing safety-related applications to be validated only to Quality Management levels, while non-safety related applications can be integrated and upgraded without re-certifying the safety components, utilizing a Memory Management Unit and dual-core architecture to ensure separation and monitoring.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If functional safety standards are implemented using standard functional architecture patterns, then safety goals are achieved, but flexibility to maintain or upgrade functionality is reduced and costs increase
Solution Approach 1:
The patent segments the software into a safety-related software component and a non-safety-related software component. The safety-related component implements safety goals according to functional safety standards, while the non-safety-related component handles general application functionality. This segmentation allows independent development, validation, and upgrading of each component without affecting the other, thereby maintaining safety integrity while enabling system flexibility and adaptability.
2Reliability
If functional safety standards require certified validation for all applications, then safety reliability is ensured, but time and labor costs increase significantly
Solution Approach 1:
The patent divides the software system into safety-related and non-safety-related components. Only the safety-related component undergoes certified validation according to functional safety standards, while the non-safety-related component uses standard validation processes. This segmentation eliminates the need for time-consuming recertification of the entire system when upgrading non-safety functionality, significantly reducing validation time and labor costs while maintaining safety reliability.
3Ease of operation
If safety software and non-safety related application are integrated, then system functionality is unified, but upgrades require recertification of both applications
Solution Approach 1:
The patent segments the integrated system into a safety-related software component and a non-safety-related software component that can communicate through defined interfaces. This architectural segmentation maintains system functionality and integration while allowing independent upgrading of the non-safety component without triggering recertification requirements for the safety component, thus easing the manufacturing and maintenance process.
Solution Approach 2:
The patent introduces an intermediary interface layer between the safety-related and non-safety-related software components. This intermediary enables communication and integration between the two components while maintaining clear boundaries that allow independent validation and upgrading. The interface acts as a mediator that preserves system unity without coupling the validation requirements of both components.
Data Source
AI summary
A process for decomposing safety software involves the steps of providing a first software module associated with a first logical unit, providing a second software module associated with a second logical unit, instructing the first software module to implement a first safety goal based on a quality management level, and instructing the second software module to implement a second safety goal based on a safety integrity level, where the second software module uses at least one input and at least one output of the second logical unit to determine if the second safety goal is satisfied. Consequently, the second software module uses a result of the first software module to determine if the first safety goal has been completed, and the second software module uses at least one algorithm to verify an operational status of the first logical unit.