What is the significance of a software safety analysis? For us to understand the motivation behind performing a software safety analysis, we have to first step back and look at the entire ISO 26262 safety lifecycle.
In Part 4 and Part 5, clauses 4.7 and 5.7 respectively, the ISO 26262 standard requires engineers to perform safety analyses in order to verify that the design formulated from the requirements specification stage have been implemented.
At the system level, the safety analyses are aimed at uncovering potential design gaps known as single-point and dual-point latent faults. At the hardware level, quantitative safety analyses such as FMEDA or quantitative fault trees are also required to estimate the product’s robustness against random hardware faults. In the same vein, Part 6, clause 7, requires software engineers to execute software safety analyses at the architectural level to uncover potential design gaps within the software design.
So assurances against faults at the system and hardware levels are necessary, but not sufficient. Rigorous verification of software architectural design is also a cornerstone for safe design. Verifying the product design at different stages as prescribed by the standard significantly reduces the chances of an unwanted surprise out in the field or in the later phases of development, thereby saving considerable time and money.
Software safety analysis can be done in various ways. We often attack the problem using the following three best-practices for software safety analysis:
Software failure mode coverage analysis
- The goal is to prove robustness against commonly known faults & issues that occur in software.
- The list of common global failure modes is generated from past experience, discussion with experts and reviews of technical literature.
Dependent failure analysis/Freedom from Interference analysis
- This is applicable only for software designs that must support multiple ASILs, for example due to a decomposition or coexistence.
- The goal of the analysis is to prove that the higher ASIL software component functionalities are not hindered by the lower ASIL software components or QM software components.
- The goal is to systematically step through inputs to the SW software and, and provide evidence of mitigation measures to protect against single-point or dual-point latent faults created by the failure modes of these inputs.
- Software FMEA should be performed at a low enough level that it does not become a repetitive version of the system FMEA; yet at a high enough level to preserve its usefulness to identify potential systematic faults at the architectural level. Generally, the ideal level for software FMEA is a level lower than ‘software as a black-box’ where the internal software signals between high-level software modules are available.