See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/260136605
ASIL Decomposition: The Good, the Bad and the Ugly
Conference Paper · March 2013
DOI: 10.4271/2013-01-0195
CITATION READS
1 6,797
2 authors, including:
Rami Debouk
General Motors Company
52 PUBLICATIONS 895 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
ISO 26262 View project
Cybersecurity View project
All content following this page was uploaded by Rami Debouk on 25 October 2017.
The user has requested enhancement of the downloaded file.
ASIL Decomposition:
The Good, the Bad, and the Ugly
Joseph D’Ambrosio and Rami Debouk
General Motors Company
Overview
• Background
• ASIL Decomposition in ISO 26262
• Example of ASIL Decomposition
• Observations on Applying/Interpreting ASIL Decomposition
• Recommendations
Background
System-level requirements allocation / decomposition is a well-
know task in the discipline of systems engineering
Direct Allocation Decomposition
Requirement Requirement R
R1 R2
Component
Comp 1 Comp 2
Background
Safety-critical system design
Safety-critical system design may benefit from redundant
requirements allocation
S Decompose system-level requirement into multiple
Requirement R
redundant sub-requirements allocated to different
components
S Each sub-requirement (component) directly supports
achieving the system-level requirement R1 R2
S There has to be some means to assure independence in
the implementation of the redundant requirements
Comp 1 Comp 2
S If one component fails then other components still satisfy
the system-level requirement, hence improving the
integrity of the system
Background
Assessment of Requirements Redundancy
R Not Achieved
A challenge arises on how to assess the value of
redundant requirements
S A fault tree analysis may be used to assess
effectiveness of redundant requirements against
random hardware failures Comp 1 Comp 2
Failed Failed
S An algebra is required to assess redundant
requirements against systematic failures
S The concept of ASIL Decomposition is defined in
ISO 26262
ASIL Decomposition
in ISO 26262
S Requirements decomposition with respect to ASIL tailoring is
defined in Part 9 of ISO 26262
S Decomposes a given safety requirement into a set of redundant
safety requirements to which an ASIL is tailored, given the
original ASIL
S ASIL Decomposition is intended for systematic aspects, not
random HW failures
S Need to prove independence of elements to which the
requirements are allocated
ASIL Decomposition Rules
(Source ISO 26262, Part 9)
ASIL before Decomposition ASIL after Decomposition
ASIL C(D) Requirement + ASIL A(D) Requirement or
ASIL D Requirement ASIL B(D) Requirement + ASIL B(D) Requirement or
ASIL D(D) Requirement + QM(D) Requirement
ASIL B(C) Requirement + ASIL A(C) Requirement or
ASIL C Requirement
ASIL C(C) Requirement + QM(C) Requirement
ASIL A(B) Requirement + ASIL A(B) Requirement or
ASIL B Requirement
ASIL B(B) Requirement + QM(B) Requirement
ASIL A Requirement ASIL A(A) Requirement + QM(A) Requirement
Example of ASIL Decomposition
(Illustrative Only)
ASIL C: The feature
shall be deactivated for
vehicle speed > 15km/h
Driver
Controller Actuator
Request
Vehicle
Speed
Example of ASIL Decomposition
(Illustrative Only)
ASIL C: The feature
shall be deactivated for
vehicle speed > 15km/h
Driver Actuator
Controller Actuator
Request Switch
Vehicle Vehicle
Speed Speed
Example of ASIL Decomposition
(Illustrative Only)
ASIL C: The feature
shall be deactivated for
vehicle speed > 15km/h
ASIL A(C): Controller shall ASIL B(C): Actuator switch
not send an activation shall open when vehicle speed
command for vehicle speeds > > 15km/h
15km/h
Driver Actuator
Controller Actuator
Request Switch
Vehicle Vehicle
Speed Speed
Observations on Applying/Interpreting
ASIL Decomposition
S Concept and Applicability
S Overlapping Requirements
S Benefits of Requirements Decomposition
S Top down vs. Bottom up Approach
S Safety Element out of Context
Concept and Applicability
S Concept used in allowing the exploration of options in designing
an architecture
S decomposing requirements and allocating them to architecture elements
S does not deal with hardware reliability and trying to achieve a
quantitative target
S Caution in using the terminology of ASIL lowering/reduction
Overlapping Requirements
S ASIL Decomposition is applied to requirements and not the
elements building up the architecture to which requirements
are allocated
S A suitable partitioning of safety requirements into redundant
safety requirements can be used on a combination of
independent elements
S The decomposed and “parent” requirements are all one and the
same
Benefits of Requirements
Decomposition
S Requirements decomposition can be used to lower the ASIL
of the safety requirements assigned to a specific element, by
benefiting from the existing redundant elements in an
architecture
S Implementing safety mechanisms for random hardware
failures will be enough to meet the requirements of the
standard for several elements of the design
S Such a technique is one explanation for the decomposition rule
of ASIL X to ASIL X(X) and QM(X)
Top down vs. Bottom up
Approach
S ASIL Decomposition is easily interpreted as a top down approach
S However, designers may need to construct systems bottom up from
existing design elements
S Having some knowledge about the component elements and their
associated ASILs and factoring that into meeting a target system level
ASIL constitutes a bottom up approach for ASIL Decomposition
S Still, the top-down ASIL requirement decomposition needs to be
confirmed
Top down vs. Bottom up
Approach
ASIL A ASIL B
Bottom Driver Actuator Actuator
Controller
Up Request Switch
Vehicle Vehicle
Speed ASIL C Speed
Top down vs. Bottom up
Approach
ASIL A ASIL B Random HW
Failure Target
Bottom
?
Driver Actuator Values
Controller Actuator
Up Request Switch ASIL D 10-8
ASIL C 10-7
ASIL B 10-7
Vehicle Vehicle
Speed ASIL C Speed
Top down vs. Bottom up
Approach
ASIL A ASIL B Random HW
Failure Target
Bottom
?
Driver Actuator Values
Controller Actuator
Up Request Switch ASIL D 10-8
ASIL C 10-7
ASIL B 10-7
Vehicle Vehicle
Speed ASIL C Speed
1: The feature shall be
deactivated for vehicle speed >
ASIL A(C)2 ASIL B(C)3 15km/h
Top Driver Actuator
2: Controller shall not send an
Controller Actuator activation command for vehicle
Down Request Switch
speeds > 15km/h;
3: Actuator switch shall open
when vehicle speed > 15km/h
Vehicle Vehicle
Speed ASIL C1 Speed
Safety Element out of Context
(SEooC)
S A SEooC is a safety-related element which is not developed
for a specific system in the context of a particular vehicle
S Assumptions are made at the component level and
requirements are developed that can meet a given safety
integrity level
S Can be seen as a bottom up application of an ASIL
Decomposition concept
Example of SEooC
Random HW
ASIL A ASIL B
Failure Target
Actuator
Values
Driver Controller Actuator
Request Switch ASIL D 10-8
ASIL C 10-7
ASIL B 10-7
Vehicle
Speed
ASIL C
S Speed Sensor #1 S Speed Sensor #2
S ASIL C development process S ASIL C development process
S ASIL C HW Metrics S ASIL C HW Metrics
S 99.99 FIT for random hardware failures S 1 FIT for random hardware failures
S 500 ms fault detection time S 20 ms fault detection time
Recommendations
S ASIL Decomposition per ISO 26262 is a method not intended to
justify reduced ASIL assignments to hardware elements for
random hardware failures, but instead focuses on functions and
requirements in the context of systematic failures
S ASIL Decomposition is to be used only when requirements are
being refined and allocated to different independent components
Recommendations
S If a design utilizes ASIL decomposition, it is critical for the
final safety case that the top-down ASIL requirement
decomposition be confirmed
S Design teams need to explicitly consider the (expected) top-
down requirements decomposition even when the system is
being designed bottom up, where design elements have pre-
assigned ASILs
View publication stats
