ASIL (ISO 26262) Decomposition

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

ASIL
2
ASIL
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.
3
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
4
ASIL Basics
• The ASIL is calculated for a function and not calculated for
a physical system component. HARA
• THE ASIL associated with a function is then inherited by

the software and hardware elements that realize the
function. ASIL X
• It could happen that a hardware component or a software Component Function

ASIL X ASIL X
element realizes several functions with different ASILs
(e.g. microcontroller)
ASIL Y
ASIL Y
• In this case, the ASIL associated with the hardware or max (ASIL X, ASIL Y)
software component is inherited from the function with the

highest ASIL
5
Lowering the ASIL
• Under certain circumstances, the ASIL can be lowered

ASIL
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.
Cost, Effort
• There are strict underlying concepts and rules that must
be respected.
6
ASIL Decomposition
7
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
8
Valid Combinations – Simple Decomposition
ASIL D ASIL D ASIL D

ASIL D
ASIL C(D) ASIL A(D) ASIL B(D) ASIL B(D) ASIL D(D) QM (D)
ASIL C ASIL C
ASIL C
ASIL B(C) ASIL A(C) ASIL C(C) QM (C)
ASIL B ASIL B
ASIL B
ASIL A(B) ASIL A(B) ASIL B(B) QM (B)
ASIL A
ASIL A
ASIL A(A) QM (A)
9
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)
10
ASIL Decomposition Basics
• An element implemented to address a given safety goal, with a
ASIL D
given ASIL may be decomposed into two independent
elements, with possibly lower ASIL
 Each must address the same safety goal
ASIL
 Each must take on the same safe state Decomposition
• ASIL Decomposition can be used in the following phases:

• Functional Safety Concept development ASIL C(D) ASIL A(D)
• System Design
Inherited Safety Goal
• Hardware Design and Safe State
• Software Design
ASIL decomposition is a qualitative concept, more addressing systematic issues (architecture)

than random errors (hardware reliability); contributing to a robust and fault tolerant architecture.
11
Redundancy through Decomposition
 Functional Redundancy
• ASIL Decomposition introduces functional redundancy. Safety
Goal
• Two independent architectural elements work toward the same
(redundant) safety goal.
 Heterogeneous Redundancy Element M Element N

• These independent architectural elements are nearly always diverse.
Note : An element can be
Heterogeneous redundancy through architectural design elements. either a HW or SW Component
• This is not the homogeneous hardware redundancy.
Remember that (in general) there is actually very little redundancy in automotive systems. Costs !
12
ASIL Decomposition Example -
Motor Control Function
13
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” (where “undesired” means “as a result of an incorrect combination
of sensors S1, S2, … Sn” ).
• Safe State : “M” Deactivated
S1 MCU
U
S2 PWM cmd signal
ASIL D V
: M
W
: driver
: Brushless
Sn 3-phase DC Motor
14
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
ASIL D
ASIL D
MCU ASIL D
ASIL D S1
U
PWM cmd signal
V
ASIL D S2 M
ASIL D W
driver
ASIL D Sn Motor
15
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.
U
PWM cmd signal
V
M
W
driver
16
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
ASIL D
QM
MCU QM
ASIL D S1
U
PWM cmd signal
V
ASIL D S2 M
QM W
driver
ASIL D Sn Motor
17
◉ 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.
18
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.
Risk analysis information
(ex: operational scenario)  Another example : consider undesired
HARA deployment of an airbag – its effect depends
on the velocity of the vehicle.
New
Architecture  Typical Operational Scenarios :
Initial • Driver-side door open
Architecture Safety • Temperature of the engine greater than
Mechanism a threshold.
19
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.
ASIL D(D)
ASIL D(D)
QM
MCU QM
S1
U
PWM cmd signal
V
S2 M
QM W
driver
Sn Motor
V
SHW Application SW
SSW – SW introduced for the safety mechanism
SHW – HW introduced for the safety mechanism
Speed Sensor
20
◉ 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.
21
Safety Mechanism ASIL?
By introducing the safety mechanism we have changed the ASIL D(D)
architecture now, ASIL D(D)
MCU
- Introduced a new speed sensor “v”. S1
- Introduced new software.
S2
But have we changed the ASIL allocation ? Sn

No. The mere addition of the safety mechanism by itself does
not change the ASIL allocation.
V
SHW Application SW
The complete system hardware and software

High Cost ! including the Safety components are at ASIL D level
22
SW ASIL Decomposition?
Observation: Analyzing the new architecture we can observe, Decision:
• ASIL D for the complete system software to be too high and • Apply ASIL Decomposition at the software level.
• Introducing HW redundancy is not cost optimal.
Application software and firmware that has no capability

QM of violating the safety goal
QM
MCU
QM
S1
QM
U
S2 PWM cmd signal
V
M
QM W
Sn driver
Motor
Independence
V
SHW
ASIL D(D) ASIL D(D) Any software function potentially leading to the violation of
the safety goal (operating system, safety mechanism, etc.)
23
Independence
Is this Decomposition acceptable ?
Ans: The proposed software-level ASIL decomposition is acceptable only if the QM

criteria of independence are satisfied.
MCU
• 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!

ASIL D(D)
24
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.
25
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.
Application software,
firmware, operating system
QM
QM QM
MCU
QM
S1
U
PWM cmd signal
V
S2 M
QM W
driver
Sn Motor
Independence
V
SHW The Safety Element disables the
ASIL D(D) Safety Element driver if V > threshold
Functions related
ASIL D(D) to the safety goal
26
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.
27
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
28
ASIL Decomposition – Architecture evolution
Initial Architecture
Safety Mechanism addition
Architecture after ASIL

Decomposition
29
Alternate Decompositions
30
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 ASIL D ASIL D

ASIL D
ASIL C(D) ASIL A(D) ASIL B(D) ASIL B(D) ASIL D(D) QM (D)
31
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
High Cost !
ASIL D
ASIL B(D) ASIL B(D)
32
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 ASIL D
implements the overall functions of the Controller.
• Safety Element : The safety element is simple, inexpensive, and reliable. ASIL C(D) ASIL A(D)
33
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.
34
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.
35
Ten ASIL Misconceptions
36
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 IEC61508, but doesn’t apply with ISO 26262. In reality, it is more about dealing with
systematic(e.g. architectural) issues
37
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.
38
www.embeddeduncharted.com

ASIL (ISO 26262) Decomposition

Uploaded by

Copyright:

Available Formats

ASIL (ISO 26262) Decomposition

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ASIL (ISO 26262) Decomposition

Uploaded by

Copyright:

Available Formats

ASIL (ISO 26262) Decomposition

Madhusudhanan Ravi www.embeddeduncharted.com

ASIL refers to Automotive Safety Integrity Level. It is a

• The Automotive Safety Integrity Level

• It defines the safety requirements that

• THE ASIL associated with a function is then inherited by

• It could happen that a hardware component or a software Component Function

software component is inherited from the function with the

• Under certain circumstances, the ASIL can be lowered

• The concept is applicable for Safety Integrity Levels of

• Advantageous in terms of Development and Production

◉ An element implemented to address a given safety goal, with

ASIL D ASIL D ASIL D

D C(D) + A(D) B(D) + B(D) D(D) + QM(D)

• ASIL Decomposition can be used in the following phases:

ASIL decomposition is a qualitative concept, more addressing systematic issues (architecture)

 Heterogeneous Redundancy Element M Element N

HARA (Hazard Analysis Risk Assessment) Output :

But have we changed the ASIL allocation ? Sn

The complete system hardware and software

Application software and firmware that has no capability

Ans: The proposed software-level ASIL decomposition is acceptable only if the QM

• There are multiple issues to be considered

What about the hardware metrics?

• Hardware metrics are not affected, so they are still ASIL D!

There is no embedded logic (i.e. no software)

Safety Mechanism addition

Architecture after ASIL

ASIL D ASIL D ASIL D

ASIL B(D) ASIL B(D)

Why not the reverse?

9. A hardware element can be designed as ASIL X for any system

8. ASIL decomposition is a form of hardware redundancy

7. ASIL decomposition is used to reduce the HW metrics targets

6. ASIL decomposition is primarily about random failures

3. ASIL decomposition is the only way to lower the ASIL of an element

2. ASIL decomposition is always possible

1. ASIL decomposition is always desirable !

Madhusudhanan Ravi www.embeddeduncharted.com

You might also like