Reuse Secenarios in ISO 26262 part 1 demonstrated the diversity of reuse scenarios. Now I want to concentrate on concrete measures, which are used to make the reuse of software successfully.

Case 1: Software meets the ISO 26262, new system has same level of ASIL:

If an existing software already meets the ISO26262 and the software is unchanged in a new system with same ASIL, then ISO26262-8 chapter 12 “Qualification of software components” mainly defines, the tasks to be performed. The artifacts from the previous development need to be tested. Are they valid and complete so that they can be used in the new system? Ideally, the result of this test, that all artifacts without modification can be applied. However, it will be also necessary to prove that the software is also working in the new environment. Therefore ISO26262, part 6 “integration and testing” is applicable as well.

The self-destruction of the Ariane 5 shortly after the start at the 04.06.1996, is an example that although come from another industry, but it shows that fatal things can happen if errors remain undetected in the new system. The Ariane example shows two points. Firstly integration tests are required, to proof that the old software works correctly also in the new environment. Secondly an impact analysis should also always be done, to be sure that all possible scenarios which could cause problems are detected and measures are taken.
Concerning the Ariane disaster, the cause of the crash was a memory overflow when converting the horizontal speed of 64-bit floating point number in 16-bit value. This conversion came to an overflow of the 16-bit value because the new missile had much higher horizontal velocity values than its predecessor. The software was not designed for such a case.
For the case that the existing software was developed after ISO 26262, the ASIL stays equal, but the software is modified, you may only partially apply part 8 “qualification of software components”. For the portion of the software remains unchanged, you can of course use artefacts from the previous development. However, an impact analysis will be necessary, which verifies the impact of the changes. Depending on the complexity of the changes, the result can be that large parts of the existing artefacts to fulfil the ISO26262 must be adapted. If the software changes contains also new parts, the documentation has to reflect this parts as well. As in the above case, integration tests will be certainly necessary here too.

Case 2: Software meets the ISO 26262, new system has higher levels of ASIL:

For the case that a development according to ISO 26262 has taken place in an old system, but the software is now integrated into an electronic control unit, which must meet a higher ASIL more points (compared to case 1) need to be considered. In this case, an analysis of ISO 26262 is necessary to identify artifacts which are additionally needed and which need to be adapted due to the higher ASIL level.
Depending on old and new ASIL level it may be necessary, that reviews carried out as a walkthrough (sufficient for ASIL A), now needed to be repeated as an inspection (required for ASIL B, C and D).
Another example is the necessary structural coverage of the source code. For ASIL B and C the branch coverage is sufficient. For ASIL D an MC/DC is required.
In addition, the points from the first case are also here to take into account.

Case 3: Software was developed prior to the first release of ISO 26262:

This case is very simple. For such a software the ISO26262 does not apply and nothing needs to be done!
However, it is clear that the case is becoming rarer and rarer as the standard is for years already applicable (First release in 2011). The intension of this arrangement was that it should be avoid at the introduction of the standard that the existing systems at that time had to be subsequently adapted to the ISO26262.

Case 4: COTS Software:

For commercial off-the-shelf (COTS) software that is used in the automotive industry it is conceivable, that the so-called “proven-in-use argument” (ISO26262, part 8) may apply. It is often almost impossible to create the necessary artifacts of ISO 26262 for such software. One reason is that there is usually no access to the source code.
In this case the proven-in-use argument can be a very useful way to meet the requirements of the standard.
However, the requirements in the standard are quite challenging:

• Relevance of the available field data needs to be proven, i.e. a detailed analysis must be performed
• If changes to the software are made in the period of observation, then it must be demonstrated that these changes have no effect on the relevance of the data
• Methods for systematic integration must be applied
• A justification for the calculation of the observation period must be provided (service period)

Conclusion:

The second part of the blog has shown that for the various reuse scenarios unique measures are defined, which are to be met.
In conclusion, it can be determined that you can only benefit from a reuse from an economic perspective, if both a professional configuration management is available, as well as a very high degree of test automation.

Related HEICON Blog posts

• Reuse scenarios in ISO 26262 (part 1)
• Good safety development process – What is it?
• Functional Safety – What is it?

Are you ready for a functional safety workshop, to identify improvement potentials in your development process? Send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.