ISO 26262 ASIL Decomposition: Part 9 of ISO26262 defines a scheme for dividing a requirement with a specific ASIL level into two requirements with lower ASIL levels.

In the following blog post I will address the question when the ASIL decomposition can be applied in practice and what are the advantages. At the same time, however, some practice is critically questioned in the projects regarding the ASIL decomposition.

A very important prerequisite for the meaningful application of ASIL decomposition is freedom of interference. You can find more on this topic in the blog post ISO26262: Freedom from Interference – What is that?

ISO 26262 ASIL decomposition statements in the norm

ISO 26262 specifies the following in part 9, chapter 5.2:

ASIL decomposition is a method of ASIL tailoring during the concept and development phases. During the safety requirements allocation process, benefit can be obtained from architectural decisions including the existence of sufficient independent architectural elements. This offers the oppertunity

• To implement safety requirements redundantly by these independent architectural elements, and
• To assign a potentially lower ASIL to (some of) these decomposed safety requirements.

If the architectural elements are not sufficiently independent, then the redundant requirements and the architectural elements inherit the initial ASIL.

Opportunities arising from ASIL decomposition

The technical advantage lies in the chance to make the architecture of the system more safe by adding redundancy. However, this only applies if common cause errors are prevented and freedom of interference is ensured.

An economic advantage results from the reduction of development costs. Experience shows that significant cost savings can be realized. Especially, if the ASIL decomposition is performed so that the majority of the software is classified as QM or ASIL A/B instead of ASIL C or D. The advantage increases further when the part of the software that is subject to frequent changes becomes QM or ASIL A/B software too.

Good safety architectures are characterized by the fact that only a small part of the software, which is not frequently modified, is to be developed according to high ASIL levels.

Mistakes that can be made with ASIL decomposition

The most common error results from the fact that an ASIL decomposition is performed isolated for individual requirements without considering the software architecture.

In this case there is no improvement of the architecture. Likewise no cost advantage can be realized, since in the end all requirements often have to be developed according to the highest ASIL level.

A further disadvantage, which often arises here, is that with such an approach, the development team is no longer able to keep track of the safety process and then often the acceptance of the ISO26262 methods is no longer guaranteed. This is a very serious disadvantage because there are many other negative consequences.

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.