Skip to main content

The Mumbo-Jumbo called ASIL Decomposition!



ASIL Decomposition – What is it anyway!

Let us start with the ISO 26262 definition for ASIL Decomposition: “Apportioning of redundant safety requirements to elements, with sufficient independence, conducing to the same safety goal, with the objective of reducing the ASIL of the redundant safety requirements that are allocated to the corresponding elements.”

If you feel completely lost or confused as though you read a statement in a language that you have never heard of, then you are not alone! ASIL decomposition is considered as one of the advanced topics in the safety domain and many feel intimidated to venture into this topic. The idea behind this blog is to demystify the decomposition concept and to present you with some pointers on how to use decomposition.

If we have to breakdown the definition into ‘plain’ English, it would look something like this: ASIL decomposition is a method by which the requirements could be broken down into redundant requirements that are then allocated to independent elements and possibly with lower ASILs (With certain terms & conditions, of course!). The standard provides us with permissible schemas in which a higher ASIL could be decomposed into lower ASILs. The acceptable schemas are given in the table below.

Original ASIL

Permitted ASIL Decomposition Schemas

D

C(D) + A(D)

B(D) + B(D)

D(D) + QM(D)

C

B(C) + A(C)

C(C) + QM(C)

 

B

A(B) + A(B)

B(B) + QM(B)

 

A

A(A) + QM(A)

 

 


Apart from the use case of lowering the ASIL between redundant requirements, there is one another use case in which ASIL decomposition could be utilized. It is when we want to decompose between an intended safety function and its associated safety mechanism. This blog will concentrate mainly on this use case of ASIL decomposition as this is the one that we have utilized extensively in our software safety development. Also, this aspect is often overlooked and not covered in many articles & our idea is to throw more light on this hidden item of the standard.

Simon Sinek comes calling

As Simon Sinek says, we should always ‘Start with Why’. If you try to find answers to the fundamental question of “Why should one do an ASIL decomposition?” the answer is not so straight forward. A rather simplistic answer would be that the methods/processes that needs to be followed is for the decomposed ASIL. This inevitably leads to savings in terms of cost, time or tools. For example, ASIL-D development necessitates that the requirements be captured in semi-formal notations. This could mean that an organization might have to purchase a tool for this requirement capture (if they don’t have one already). However, if you decompose your system into B (D) + B (D), then you could get away with creating requirements in an informal notation.

Typical scenarios where ASIL decomposition is applied:

Having understood the ‘Why’, let us look at the ‘Where’ aspects of ASIL decomposition. Given below are some of the typical development scenarios in which ASIL decomposition could be utilized to reduce the complexity of the system. All of the below examples are cases where decomposition is applied between intended safety function and its associated safety mechanism. In other words, they lead to a QM(X) + X(X) where X refers to any of ASIL A/B/C/D.

  1. When we have a legacy code that is not developed per ASIL standards (And qualifying it is also not an easy task).
  2. When we have a 3rd party component that is not ASIL (Qualification is almost ruled out for these type of components).
  3. When the SW complexity of a component is so high that developing it per ASIL standards is prohibitively expensive (Ex: CAN stack).
  4. When the SW development is closely coupled with a SW tool. In this particular case, even the SW tool will have to be developed per the ASIL standard or will have to go through the tool qualification process (Ex: HMI software).
  5. When we have a system where ASIL functions are spread across multiple microcontrollers (Ex: Dual micro solutions seen in high end instrument clusters). In such a scenario, it is advantageous to do an ASIL decomposition & restrict the ASIL to one of the micros.

For the sake of completeness of the scenarios for ASIL decomposition, let us also look at the use cases where redundancy is being introduced into the system.

  1. For a headlight system that is required at ASIL-B, it could be decomposed into 2 redundant headlights (Right & Left ones) at A (B) each. This helps in improving the availability of the headlight when one of them fails during operation.
  2. A MCAL software that is developed at ASIL-B level could be used for developing ASIL-D requirements. In this case, redundant inputs are taken through a peripheral (Say ADC) using different ports and are processed using different algorithms. The results are then compared (At ASIL-D level) to ensure that the MCAL is working fine.

Constraints/Limitations of ASIL decomposition

Like any design approach, ASIL decomposition has its own fair share of constraints or limitations that one should be aware of. Given below are the most pressing issues that one encounters when performing ASIL decomposition.

  1. The hardware metrics and probability of safety goal violation targets remain at the original ASIL. For example, let us assume that we decompose an ASIL-D requirement into B (D) + B (D) and allocate this to different systems. In this scenario, both the decomposed systems will have to achieve the ASIL-D metrics (Unless otherwise specified by the OEM). What this means from an implementation standpoint is that the diagnostic coverage that needs to be achieved still remains high. This in turn means that the technical complexity of the solution might not be reduced because of the decomposition.
  2. The integration activities and confirmation measures will continue to be at the original ASIL level. This means that the methods that need to be followed still remain stringent at the original ASIL and no benefits are accrued in this aspect.
  3. Demonstrating independence between the 2 decomposed elements might become complex depending on where the decomposition is being applied. If it is applied at the system/ECU level (Like the point #5 above), the parameters that need to be considered might include the HW connectors, the power supply, the layout of the printed circuit board, the clock source etc. Analyzing all these factors and concluding that there is no dependence will become a mini-project in itself!

Is ASIL decomposition a panacea for all safety design?

As we have seen above, there are various scenarios and advantages of applying ASIL decomposition. Be it legacy software or complex systems, decomposition does yield some handy solutions for these problems. However, what one should not forget is the flip-side of decomposition. Like every engineering decision that we make while designing an ECU, a cost-benefit or Decision Analysis and Resolution (DAR) or other equivalent analysis methods will have to be performed to really understand the overall gain/loss of decomposition. Only after such careful analysis is performed should be make a decision on decomposition. Without this analysis, one might end up losing much more than what they gain!

Parting thoughts (Pun intended!)

If your head is still spinning with all the mumble-jumble of ASIL decomposition, just drop us a note in LinkedIn or at our blog and we will definitely get back to you.


Labels: