The 2 sides of ISO26262

As part of this blog post, we will cover the 2 facets of ISO 26262 and how these 2 facets go hand-in-hand in making a system safe. We consider these 2 facets to be like the sides of a coin. When a system is considered safe, it means that both these aspects are present in it. Let us deep dive a bit to understand what those are by using a very simple example.

The first aspect of the ISO 26262 standard is the addressing of failure modes. As the ASIL increases, more and more failure modes need to be addressed as part of our system. The standard calls this the increasing diagnostic coverage. Let us take the example of the communication function and try to understand what we mean by this.

Given below is the list of failure modes that are possible for a communication function.

1. Message delayed

2. Message corruption

3. Message-out-of-order

4. Transmitter not available

5. Masquerading

To start with, you might want to have a technical solution in which we have a software component that detects the missing of the communication peer as the first step for an ASIL-A system. As we go further up the stream towards ASIL-B, the SW component now should have safety mechanisms to detect message-out-of-order & message corruption failure modes. This basically means that there is an increase in the diagnostic coverage of the system. How to understand the diagnostic coverage that is offered by a technical solution aka safety mechanism? Annex-D in Part-5 (Hardware-level) of the ISO 26262 standard provides a good starting point for understanding the failure modes of various functions, what is the diagnostic coverage one achieves when the address specific failure modes & the possible ways to address those failure modes are provided in this annexure.

The other aspect of the standard is the process compliance aspect. Even the best technical solution is of not much use when the process that is followed in implementing the technical solution is awful. An implementation that is full of bugs or an incomplete implementation is not going to take us any closer to our intended ‘Safe’ system. It is like having the best intention and not following it up with concrete actions!

Before we go any further explaining what this ‘process compliance’ aspect means, it is imperative that we take a small detour here to understand the concept of ‘Process’ here. When defined in the simplest way, a process is to be considered as the set of steps one needs to take to achieve the expected result. A more apt definition would be that process is the series of incremental steps that one needs to take one closer to the expected ‘perfect’ result. As the process becomes better and better, the deviation from the expected output decreases. (Is there something called a ‘Perfect process’ that leads to a ‘Perfect Result’ every time? I am not really sure about that!)

To continue with our previous example of communication function, let us assume that you are moving from a QM compliance to ASIL-A compliance. Let us take the activity of defining the requirements. If you are complying with a QM process, you would create a proper requirements document that explains how the communication safety mechanism should work. The requirements might be in an informal notation. The requirements might not be reviewed by a peer group or by the implementors of the solution, leaving some gaps in the requirements.

When we move to an ASIL-A solution, the process might dictate that not only that the requirements be defined but as well-reviewed with peers and the implementation teams. This process enhancement greatly reduces the chances of having some incorrect or incomplete requirements being taken up for implementation. When we move to an ASIL-B solution, the process might dictate that we not only review the requirements but review it using a pre-defined requirement review checklist. A checklist helps in consolidating the perspectives of various reviewers and helps in improving the quality of the review even further. This, in turn, improves the quality of the requirements that get delivered to the implementation team.

When these process improvements are applied throughout the development cycle starting from requirements elicitation to system integration & delivery, the product that gets delivered will be much closer to the expected technical solution.

Thus, technical solutions improving the diagnostic coverage work in tandem with process enhancements that bring the expected output from the technical solutions. Even though this is an overly simplified way of explaining ISO 26262, an understanding of this framework will help us in navigating this complex standard.