Why is the reuse of software, hardware, or complete electronic control units a central theme? Two essential aspects are to be considered: the development costs can be reduced significantly, i.e. reuse of components is very attractive in economic terms.
But also for security reasons, the reuse of components can offer significant benefits. A control unit, which is used already for years in the field and shows no safety relevant failure can be used with significantly reduced risk in comparison to a new development.
To be able use these benefits really, you must be aware of the various reuse scenarios. In a second step, you must identify the features of the discussed reuse scenario and take appropriate action.
The blog is divided into two parts. The first part is about diversity of possible reuse scenarios, as well as the appropriate requirements resulting from the ISO 26262. The measures to be taken for selected reuse scenarios will be discussed in the second part of the blog.
The diversity of possible scenarios is indicated by the following graphic. Not all paths occur equally often. Just like not all of the possibilities that occur in practice, are represented in this graph:

The first level in the graph shows the definition of what is to be reused. Software, hardware, or the complete ECU can be selected. The second level focuses on the functional safety requirements for the item to be reused. The third level defines whether the system will be reused unchanged or whether adjustments are necessary.

Requirements arising from ISO 26262:

In part 8 of the standard (supporting processes), two chapters deal with specific forms of reuse systems, SW or HW.
Part 8 chapter 12: ‘Qualification of Software Components’ defines the procedure for the reuse of software components that have already been developed to ISO 26262. For such elements the evidence on the suitability for reuse is to be provided. Qualified software components reuse avoids the development of software components with the same or similar functions.
Part 8 chapter 14: defines the approach for the use of the ‘ proven-in-use argument “. This is about the use of components that are already in the field, and for which sufficient data about failures in the field are available. If the conditions defined in the standard are met, then the “proven-in-use argument” can be applied as an alternative method to the fulfilment of the ISO 26262.
The following two criteria needed to be considered, as soon as a “proven-in-use argument” is prepared:
1) the relevance of the data from the field during the observation period
2) the changes to the product, since the beginning of the observation period

The “proven-in-use argument” shows systematic and random errors of the ECUs. It does not focus on failures which will arise due to the age of the ECUs.
In addition to the above described reuse scenarios, there are lots of scenarios where points from different parts of the standard are used. These are integration strategies, including impact analysis, verification strategies, etc.

Conclusion:

There are many facets in the reuse of safety-related software, hardware or systems. To recognize this is the first step to a successful reuse strategy.
In the second step, you must identify the relevant, project specific points of the ISO 26262.
With these two steps, the conditions are created to make the reuse of software, hardware or systems a safety and economic success.

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.