Software component qualification (ISO26262-8, clause 12) is an activity widely used with the intent of reusing existing software for Safety. This article is covered as 2 parts and will cover the following topics:
- What’s the big picture view for component qualification? Why is it performed?
- A simple jigsaw puzzle analogy to understand the activity
- The Thumb Rule for Component Qualification
- Different perspectives of the qualification activity
- The broad steps that need to be carried out for SW component qualification
- Challenges in qualification and possible solutions
This is Part-1 of the article and will cover topics 1-4 above. Part 2 of this article will cover topics 5 and 6.
What’s the big picture view for component qualification? Why is it performed?
When it comes to developing the software of a safety-critical system as ASIL, there are mainly 3 approaches.
- Developing the entire software of that system according to the highest ASIL level of that system
- Developing only some parts of the software at the highest level and the rest of the software at lower ASIL or QM levels and ensuring freedom from interference for the higher ASIL level SW from lower ASIL level/QM SW, typically by placing them in different memory partitions
- “Qualifying” some of the existing SW to reuse it for Safety, which also gives the advantage that the qualified SW can co-exist with ASIL SW
Figure 1: Three Approaches to SW Safety
This third approach is what we call as SW component qualification.
It is an activity that allows existing COTS (Commercial off-the-shelf) software and legacy software to be repurposed for use in safety-critical systems. Often, these components were not originally designed for safety applications but were running sturdily without issues in several production systems. Hence, it becomes beneficial to reuse them for safety, to save development time and costs.
Examples of software components suitable for qualification include:
- Communication stacks, such as CAN stacks that have been reliable in other systems but were not developed with functional safety in mind.
- Math libraries or CRC libraries that have served Math and CRC needs in existing systems but were not used before in safety-critical contexts.
- Operating systems (RTOS) and hardware drivers that were developed for standard use but now must fulfil safety goals in ASIL applications.
Analogy of a Jigsaw Puzzle
The simple jigsaw puzzle analogy could help to understand the process of Software component qualification.
Consider the analogy of a jigsaw puzzle composed of numerous pieces, each of which must be correctly aligned to complete the entire image. In this scenario, one piece is missing and needs to be fitted into a specific spot to finish the puzzle. To address this, it is possible to borrow a corresponding piece from another identical puzzle.
Initially, the borrowed puzzle piece appears to closely resemble the shape of the empty space, suggesting that it may fit seamlessly. However, upon further inspection, it becomes evident that the piece does not fit perfectly due to subtle differences—it may be slightly oversized in one area, or the notches and tabs do not align correctly. This highlights the need for adjustments. To achieve the correct fit, small modifications, such as shaving or sanding the edges of the piece, must be made gradually until it integrates seamlessly into the puzzle.
This Jigsaw puzzle represents an ASIL System with safety requirements. The borrowing of the puzzle piece represents the reuse of an existing software component, and the refinements of the puzzle piece represents the software component qualification process.
The Thumb Rule for Component Qualification
A basic thumb rule to consider the reuse of an existing SW for Safety is that the requirements that the reused SW implements and the technical requirements that are allocated to it by the system are aligned to a larger extend. For e.g., if your system needs a specific CRC 32-bit algorithm for its E2E implementation and you want to reuse an existing CRC library, then ideally, this library needs to provide the exact algorithm needed by that system. The intent here is that the code can be reused as-is without having to update it to fulfil the requirements for the system. That being said, it is not mentioned in the ISO26262 that a SW component considered for reuse should not be modified. Minimal re-engineering activities can be performed if there are deviations in the requirements. However, performing major re-engineering as part of component qualification goes against the benefits of reuse.
Different perspectives of the qualification activity
Before delving deeper into the topic of how to perform software component qualification, let’s understand it even better, taking different perspectives.
The Gap Analysis Perspective (Process point of view)
Figure 2: SW component qualification as a gap analysis
Component qualification can be looked at as a Gap Analysis activity. The Safety Engineer looks at the existing artefacts that are available for the SW component and identifies the gap that needs to be filled to gain confidence to use the component in an ASIL context.
The as-is state of an existing component may vary from one component to another. In some cases, the SW component code and test specifications might exist but other work products such as design documents and reviews are not available. In some other cases, only the code and its static analysis reports are present. In some other “best” cases, all the V-model artefacts from SW requirements to Qualification testing have been developed at QM standards for the SW component.
To address the gap, the safety engineer needs to understand what SW process has been followed to develop the reused SW and what SW work products are available and evaluate how much the gap is between this process and the software development process of the ASIL system. A crude example is, if your reused SW does not have a requirements document but as per ASIL process, a software requirement specification is needed, then the “gap” that needs to be filled is to create a requirements document for the reused SW.
The Risk Mitigation Perspective (Risk analysis point of view)
Figure 3: SW component qualification as a risk mitigation activity
To gain confidence to reuse the existing component in an ASIL system, it must be ensured that the risks introduced by the component to the ASIL system in which it is proposed to be used, need to be sufficiently mitigated. From that perspective, component qualification can also be looked at as a Risk analysis and mitigation activity, where all the risks that are introduced by the SW components are identified in a systematic way and appropriate measures are taken to mitigate the risks that will affect safety.
In Part-2 of this article, we will write about how the gap analysis and risk analysis perspective converge when we perform the qualification activity, and what challenges one might face when doing so.