ASIL Decomposition

www.embeddeduncharted.com Madhusudhanan Ravi ASIL (ISO 26262) Decomposition Madhusudhanan Ravi www.embeddeduncharted.com

www.embeddeduncharted.com Madhusudhanan Ravi ASIL 2

www.embeddeduncharted.com Madhusudhanan Ravi “ 3 ASIL refers to Automotive Safety Integrity Level. It is a risk classification system defined by the ISO 26262 standard for the functional safety of road vehicles. ASIL

www.embeddeduncharted.com Madhusudhanan Ravi 4 Automotive Safety Integrity Level • The Automotive Safety Integrity Level ( ASIL ) expresses the criticality associated with a function of the system . • It defines the safety requirements that must be fulfilled by the design and development of the system to provide a sufficient margin of safety for the users (driver, passengers, road traffic participants, etc . ) . Risk Potential QM A B C D

www.embeddeduncharted.com Madhusudhanan Ravi 5 ASIL Basics • The ASIL is calculated for a function and not calculated for a physical system component . • THE ASIL associated with a function is then inherited by the software and hardware elements that realize the function . • It could happen that a hardware component or a software element realizes several functions with different ASILs (e . g . microcontroller ) • In this case, the ASIL associated with the hardware or software component is inherited from the function with the highest ASIL HARA Component Function ASIL X ASIL X ASIL X ASIL Y ASIL Y max ( ASIL X , ASIL Y )

www.embeddeduncharted.com Madhusudhanan Ravi 6 Lowering the ASIL • Under certain circumstances, the ASIL can be lowered through the technique of ASIL Decomposition . • The concept is applicable for Safety Integrity Levels of other domains too . • Advantageous in terms of Development and Production costs . • There are strict underlying concepts and rules that must be respected . ASIL Cost, Effort

www.embeddeduncharted.com Madhusudhanan Ravi ASIL Decomposition 7

www.embeddeduncharted.com Madhusudhanan Ravi “ 8 ASIL Decomposition ◉ An element implemented to address a given safety goal, with a given ASIL may be decomposed into two independent elements , with possibly lower ASIL

www.embeddeduncharted.com Madhusudhanan Ravi 9 Valid Combinations – Simple Decomposition ASIL D QM (D) ASIL D(D) ASIL B(D) ASIL B(D) ASIL A(D) ASIL C(D) ASIL D ASIL D ASIL D ASIL C QM (C) ASIL C(C) ASIL A(C) ASIL B(C) ASIL C ASIL C ASIL B QM (B) ASIL B(B) ASIL A(B) ASIL A(B) ASIL B ASIL B ASIL A QM (A) ASIL A(A) ASIL A

www.embeddeduncharted.com Madhusudhanan Ravi 10 Valid Combinations – Multilevel Decomposition ASIL Value ASIL Decomposition Combinations D C(D) + A(D) B(D) + B(D) D(D) + QM(D) D(D) C(D) + A(D) B(D) + B(D) D(D) + QM(D) C B(C) + A(C) C(C) + QM(C) C(D) B(D) + A(D) C(D) + QM(D) C(C) B(C) + A(C) C(C) + QM(C) B A(B) + A(B) B(B) + QM(B) B(D) A(D) + A(D) B(D) + QM(D) B(C) A(C) + A(C) B(C) + QM(C) B(B) A(B) + A(B) B(B) + QM(B) A A(A) + QM(A) A(D) A(D) + QM(D) A(C) A(C) + QM(C) A(B) A(B) + QM(B) A(A) A(A) + QM(A)

www.embeddeduncharted.com Madhusudhanan Ravi 11 • An element implemented to address a given safety goal, with a given ASIL may be decomposed into two independent elements , with possibly lower ASIL  Each must address the same safety goal  Each must take on the same safe state • ASIL Decomposition can be used in the following phases: • Functional Safety Concept development • System Design • Hardware Design • Software Design ASIL Decomposition Basics ASIL D ASIL C(D) ASIL A(D) ASIL Decomposition Inherited Safety Goal and Safe State ASIL decomposition is a qualitative concept , more addressing systematic issues (architecture) than random errors (hardware reliability); contributing to a robust and fault tolerant architecture.

www.embeddeduncharted.com Madhusudhanan Ravi 12 Redundancy through Decomposition Element M Element N Safety Goal  Functional Redundancy • ASIL Decomposition introduces functional redundancy . • Two independent architectural elements work toward the same (redundant) safety goal .  Heterogeneous Redundancy • These independent architectural elements are nearly always diverse . Heterogeneous redundancy through architectural design elements . • This is not the homogeneous hardware redundancy . Note : An element can be either a HW or SW Component Remember that (in general) there is actually very little redundancy in automotive systems. Costs !

www.embeddeduncharted.com Madhusudhanan Ravi ASIL Decomposition Example - Motor Control Function 13

www.embeddeduncharted.com Madhusudhanan Ravi 14 Function Description Description : • Consider a function F which , upon input from a combination of sensors S1 , S2 , ... Sn issues an activation command to actuator M (“Motor ”) • Sensors S1, S2 till Sn measure different values. They are independent and non - redundant . HARA (Hazard Analysis Risk Assessment) Output : • ASIL Level Determined : ASIL D • Safety Goal : “Avoid the undesired activation of M ” ( w here “undesired” means “as a result of an incorrect combination of sensors S1, S2, ... Sn ” ). • Safe State : “M” Deactivated S1 S2 Sn : : : MCU driver PWM cmd signal M U V W Brushless 3 - phase DC Motor ASIL D

www.embeddeduncharted.com Madhusudhanan Ravi 15 ASIL Allocation • Assumption : In this scenario we assume that each of these sensors, if faulty, could by itself cause the safety goal to be violated. • Therefore according to the ASIL theory in the standard, each sensors shall inherit the same ASIL level D, allocated to the function F S1 S2 Sn MCU driver PWM cmd signal M U V W Motor ASIL D ASIL D ASIL D ASIL D ASIL D ASIL D ASIL D

www.embeddeduncharted.com Madhusudhanan Ravi 16 Initial Analysis • Using the specific knowledge of the technology, analysis must be performed to reason which elements of the architecture are capable of violating safety goals. • In this example, we know from the theory of motor control, that the three phases need signals that are precisely defined in time, • Therefore some of the components (e.g. the driver and its associated command channel), in case of failure couldn’t possibly produce the precise signals necessary to erroneously activate “M”. • And therefore they are incapable by themselves of violating the safety goal. driver PWM cmd signal M U V W

www.embeddeduncharted.com Madhusudhanan Ravi 17 Lowering ASIL • As a result of this analysis, we are justified in lowering the ASIL of the driver, motor, and command channel to QM. Note : This depends entirely on the technology; if the motor were based on continuous technology, it would not have been possible to lower the ASIL to QM S1 S2 Sn MCU driver PWM cmd signal M U V W Motor ASIL D ASIL D ASIL D ASIL D QM QM QM

www.embeddeduncharted.com Madhusudhanan Ravi “ 18 ◉ Lessons Learnt: Sometimes through examining the technology and its potential for safety goal violation, we can influence ASIL allocation. A project might even change its technologies after such analyses .

www.embeddeduncharted.com Madhusudhanan Ravi 19 Exploiting the HARA results – System Design • As we begin to perform system design, we shall look to improve the Safety architecture by considering the results of HARA . • Currently the architecture considers only “erroneous sensor inputs”, regardless of the operational scenario . • Typically the HARA shall distinguish the operational scenarios related to the risks (such as speed of the vehicle) . • Assuming that the HARA yielded the result that the “undesired activation of M” is dangerous only at a speed greater than threshold , this information could be exploited to introduce a safety mechanism in our architecture . Initial Architecture New Architecture Safety Mechanism HARA Risk analysis information (ex: operational scenario)  Another example : consider undesired deployment of an airbag – its effect depends on the velocity of the vehicle.  Typical Operational Scenarios : • Driver - side door open • Temperature of the engine greater than a threshold.

www.embeddeduncharted.com Madhusudhanan Ravi 20 Introducing a Safety Mechanism We now introduce a Safety mechanism : “The function M must not be activated when vehicle speed is greater than a specified threshold ” . – This is effectively introducing a kind of “AND” gate to lower the probability of M being erroneously activated. – The undesired activation of M can only occur now if F fails and V >threshold . SHW S1 S2 Sn MCU driver PWM cmd signal M U V W Motor ASIL D(D) QM QM QM Application SW ASIL D(D) V Speed Sensor SSW – SW introduced for the safety mechanism SHW – HW introduced for the safety mechanism

www.embeddeduncharted.com Madhusudhanan Ravi “ 21 ◉ Lessons Learnt : By careful examination of the Hazard and Risk Analysis and sufficiently detailed analysis of operational scenarios, we can discover possibilities for the introduction of safety mechanisms in the architecture.

www.embeddeduncharted.com Madhusudhanan Ravi 22 Safety Mechanism ASIL? By introducing the safety mechanism we have changed the architecture now, - Introduced a new speed sensor “v”. - Introduced new software. But have we changed the ASIL allocation ? No. The mere addition of the safety mechanism by itself does not change the ASIL allocation. SHW S1 S2 Sn MCU ASIL D(D) Application SW ASIL D(D) V The complete system hardware and software including the Safety components are at ASIL D level High Cost !

www.embeddeduncharted.com Madhusudhanan Ravi 23 SW ASIL Decomposition? Observation: Analyzing the new architecture we can observe, • ASIL D for the complete system software to be too high and • Introducing HW redundancy is not cost optimal. Decision: • Apply ASIL Decomposition at the software level. SHW S1 S2 Sn MCU driver PWM cmd signal M U V W Motor ASIL D(D) QM QM QM V ASIL D(D) QM QM Any software function potentially leading to the violation of the safety goal (operating system, safety mechanism, etc.) Application software and firmware that has no capability of violating the safety goal Independence

www.embeddeduncharted.com Madhusudhanan Ravi 24 Independence Is this Decomposition acceptable ? Ans: The proposed software - level ASIL decomposition is acceptable only if the criteria of independence are satisfied. • This includes not only examining the software but also the hardware. • There are multiple issues to be considered • What about sharing of software resources like the underlying operating system ? • Sharing of firmware ? • What about sharing of hardware resources like memory, ALU, etc . ? What about the hardware metrics? • Hardware metrics are not affected, so they are still ASIL D ! MCU ASIL D(D) QM

www.embeddeduncharted.com Madhusudhanan Ravi “ 25 Lessons Learnt : Software level ASIL decomposition involves a careful analysis of both software and hardware independence. Hardware metrics are not affected by ASIL decomposition at the software level.

www.embeddeduncharted.com Madhusudhanan Ravi 26 HW Level Decomposition • The analysis of software level decomposition reveals that there are too many issues, and hence we shall perform a HW - level decomposition. S1 S2 Sn MCU driver PWM cmd signal M U V W Motor QM QM QM QM QM Application software, firmware, operating system Safety Element SHW ASIL D(D) V ASIL D(D) Independence Functions related to the safety goal The Safety Element disables the driver if V > threshold

www.embeddeduncharted.com Madhusudhanan Ravi 27 The Safety Element - HW What exactly is the Safety Element in terms of hardware? • This doesn’t have to be a full microprocessor • It might be a programmable gate array , essentially just a state machine, programmed only one time, with no operating system • They cost only one - tenth of a full micro, and are very reliable, with their own clock and power supply, easy to manage There is no embedded logic (i.e. no software) • Only ISO 26262 part 5 is applicable. Part 6 is not required.

www.embeddeduncharted.com Madhusudhanan Ravi “ 28 Lessons Learnt : Hardware level ASIL decomposition involves deep knowledge of the characteristics of the available hardware, so that independence, functionality, and costs are all correctly balanced

www.embeddeduncharted.com Madhusudhanan Ravi 29 ASIL Decomposition – Architecture evolution Initial Architecture Safety Mechanism addition Architecture after ASIL Decomposition

www.embeddeduncharted.com Madhusudhanan Ravi Alternate Decompositions 30

www.embeddeduncharted.com Madhusudhanan Ravi 31 Alternate Decomposition The HW level decomposition presented here can be favorable when  There are many non - critical functions that can be confined to the main MCU, and  A limited number of safety critical functions sharing the same safe state (driver deactivation). What other possibilities exist for decomposing the original ASIL (D) over the two elements ? • There are two more decomposition possible : 1. ASIL B (assigned to μP) + ASIL B (assigned to safety element) 2. ASIL C (assigned to μP) + ASIL A (assigned to safety element) ASIL D QM (D) ASIL D(D) ASIL B(D) ASIL B(D) ASIL A(D) ASIL C(D) ASIL D ASIL D ASIL D

www.embeddeduncharted.com Madhusudhanan Ravi 32 Alternative 1: ASIL B(D) + ASIL B(D)  The first alternative decomposition represents having two essentially equivalent processors with redundant functionality. • This is a prohibitively expensive solution already from the hardware side (a processor is much more costly than e.g. a simple sensor ) • Furthermore , the software would have to be developed with “diversity” techniques that are also known to be prohibitively expensive ASIL B(D) ASIL B(D) ASIL D High Cost !

www.embeddeduncharted.com Madhusudhanan Ravi 33 Alternative 2 : ASIL C(D) + ASIL A(D)  This alternative represents an asymmetric layout once again • Main MCU : The software assigned to the main microprocessor implements the overall functions of the Controller. • Safety Element : The safety element is simple, inexpensive, and reliable. ASIL A(D) ASIL C(D) ASIL D

www.embeddeduncharted.com Madhusudhanan Ravi 34 Alternative 2 : ASIL C(D) + ASIL A(D) Why not the reverse? Why not a “ASIL A - main MCU” and a “ASIL C - safety element” – which would usually be the intuitive choice ? - The Safety element may be too simple to be able to handle more complex safety functions. - In some cases the safety element could be a legacy element from previous designs and it has a prescribed use.

www.embeddeduncharted.com Madhusudhanan Ravi “ 35 Lessons Learnt : The “obvious” decomposition may not always be possible due to project - specific constraints such as legacy components. Case - by - case analysis is essential .

www.embeddeduncharted.com Madhusudhanan Ravi Ten ASIL Misconceptions 36

www.embeddeduncharted.com Madhusudhanan Ravi 37 ASIL Misconceptions 10 . The ASIL deals with hardware development only - ASIL has an impact on hardware, software, and supporting processes 9 . A hardware element can be designed as ASIL X for any system - A hardware element can be designed to satisfy up to ASIL X safety requirements in a given system 8 . ASIL decomposition is a form of hardware redundancy - Yes and no : ASIL decomposition implies functional redundancy but also with diversity, independence and freedom from interference 7 . ASIL decomposition is used to reduce the HW metrics targets - NO ! after the ASIL decomposition the same targets of initial safety goal (before decomposition) apply to the decomposed HW/SW elements 6 . ASIL decomposition is primarily about random failures - This was true with IEC 61508 , but doesn’t apply with ISO 26262 . In reality, it is more about dealing with systematic(e . g . architectural) issues

www.embeddeduncharted.com Madhusudhanan Ravi 38 ASIL Misconceptions 5 . ASIL decomposition is required by the 26262 standard - In reality, it is not a required step . It can be seen as an opportunity to allocate homogeneously functions with different safety criticality during the SW partitioning onto the HW elements . 4 . Software level ASIL decomposition is simpler and cheaper than hardware level decomposition - In reality, software level decomposition is often more difficult and more expensive than hardware level decomposition, due to heavy requirements for diversity and independence . 3 . ASIL decomposition is the only way to lower the ASIL of an element - In reality, the ASIL of an element may also sometimes be directly lowered by an informed and careful analysis of the technologies and the architecture involved . 2 . ASIL decomposition is always possible - In reality, the implementation of multiple functions with many different ASILS (as in a modern microcontroller) might make it essentially impossible to effect an ASIL decomposition in certain cases . 1 . ASIL decomposition is always desirable ! - In reality, there is always a cost - benefit trade - off, and often after careful analysis an ASIL decomposition may reveal itself as undesirable .

www.embeddeduncharted.com Madhusudhanan Ravi www.embeddeduncharted.com