See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/335396971

ISO 26262 ASIL-Oriented Hardware Design Framework for Safety-Critical

Automotive Systems

Conference Paper · November 2019

DOI: 10.1109/ICCVE45908.2019.8965235

CITATIONS READS

8 11,937

2 authors:

Yung-Yuan Chen Kuen-Long Lu

National Taipei University Foxtron
73 PUBLICATIONS 384 CITATIONS 27 PUBLICATIONS 132 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Kuen-Long Lu on 24 November 2019.

The user has requested enhancement of the downloaded file.

 ISO 26262 ASIL-Oriented Hardware Design
Framework for Safety-Critical Automotive Systems
Kuen-Long Lu and Yung-Yuan Chen
Department of Electrical Engineering, National Taipei University
SanXia, New Taipei City, Taiwan, R.O.C
s810476101@webmail.ntpu.edu.tw
chenyy@mail.ntpu.edu.tw
Abstract—In this paper, we base on the fault tree analysis
(FTA) to propose an Automotive Safety Integrity Level (ASIL)-
oriented hardware design framework for safety-critical
automotive systems, where ASIL plays a key component in the
ISO 26262 safety standard to measure risk of a specific system
component. There are two contributions in this framework:
FTA-based weak-point analysis and ASIL-oriented fault-
tolerant design methodologies. The former can rapidly identify
the weak-points for safety through the fault tree analysis, and
the latter can effectively introduce the safety mechanisms in the
hardware design to fulfill the requirements of target ASIL. We
use the autonomous emergency braking (AEB) system to
demonstrate the effectiveness of the proposed design framework.
Keywords—Fault tree analysis; Safety-critical system; Safety
mechanism; ISO 26262; Automotive safety integrity level.
I. INTRODUCTION
Safety-critical automotive systems like autonomous
driving systems, advanced driver assistant systems,
autonomous emergency braking systems, and driver-by-wire
systems require stringent dependability while the systems are
in operation. Therefore, safety and reliability issues must be
addressed in the development of safety-critical systems. When
the vehicle control functions are implemented by electronic
control systems, functional safety issues become so critical
that such systems must be developed with strict safety
requirements. Furthermore, safety issues must be considered
with the highest priority during the whole lifecycle of a safety-
critical system. To carry out such safety-oriented system
development, the functional safety standard, ISO-26262, was
established [1].
ISO-26262 was first published in 2011 for needs specific
to the application sector of electrical and/or electronic (E/E)
systems within road vehicles. The primary purpose of this
standard is to conduct a safety life cycle for the electronic
systems. ISO-26262 has been accepted world-wide as the
technical “state-of-the-art” for safety-critical automotive
systems [2]. In ISO-26262, a safety life cycle includes the
concept phase, product development phase, and the
production and operation planning phase. During the safety
life cycle, considered issues cover initialization of the product
concept, specification establishment, product design and pre-
production test. All these issues put emphasis on functional
safety consideration. At the product development phase, V-
model [3] is adopted as the primary design, verification and
validation flow. This phase is further divided into three
different levels: system level, hardware level and software
level. For these levels, functional safety requirements are
verified and validated through failure mode and effect analysis
(FMEA), fault tree analysis (FTA) and safety-related metrics.
978-1-7281-0142-2/19/$31.00 ©2019 IEEE
ISO-26262 standard adopts the ASILs (Automotive
Safety Integrity Levels) to measure if the target system has
achieved the demanded level of safety or not. There are four
ASILs identified by the standard - from A to D where the
ASIL A defines the lowest and ASIL D defines the highest
safety level. More strict requirements need to be fulfilled if the
higher ASIL is specified.
In this study, we base on the ISO-26262 functional safety
standard to propose an ASIL-oriented hardware design
framework for safety-critical automotive systems. The
effectiveness of the proposed design framework is
demonstrated by taking an autonomous emergency braking
(AEB) system as the case study. The AEB system integrates
the brake-by-wire system proposed in [4] with automotive
radar sensors and speed sensor to implement a front-vehicle
collision avoidance system.
This paper is organized as follows: related work is
discussed in the next section. Then in Section III, we introduce
the proposed ASIL-oriented hardware design framework
including fault tree construction, weak-point analysis and
fault-tolerant design. Case study demonstration is also
presented in Section III. Conclusions appear in Section IV.
II. RELATED WORK
In this section, related works which focus on the PMHF
(Probabilistic Metric for random Hardware Failures, one of
hardware metrics for measuring if demanded ASIL is
achieved or not) calculation, FTA and fault-tolerant design for
safety-critical automotive systems are discussed. In [5], an
accurate and well-explained practical guide to the specific
techniques appropriate for PMHF calculation using FTA was
proposed. This paper presented a structured and systematic
quantitative FTA while showing various techniques for
calculating the PMHF considering both single point faults and
dual point latent faults.
In [6], the author performed the quantitative assessments
for ISO-26262 hardware architecture metrics by means of
fault tree analysis. A custom coverage gate was firstly
proposed to represent the diagnostic coverage related to a
safety mechanism. The advantage of introducing coverage
gate is to reduce the complexity of fault tree construction
The author of [7] presented generalized formulas for the
calculation of PMHF in non-redundant and redundant
subsystems using observable parameters, such as the failure
rate of a mission function and a safety mechanism, the
diagnostic coverages of the primary and secondary safety
mechanisms and the diagnostic periods of the secondary
safety mechanisms to expand the scope of the application
according to ISO 26262.
A mixed model based on FTA and Markov chain was
proposed in [8] to evaluate random hardware failures of the
whole-redundancy system in ISO 26262. The mixed model exemplify how each step to be performed and the safety
presented in this study tried to solve the problem of calculating mechanisms compliant to be attained.
the PMHF in the whole-redundancy system, whose fault tree
only contains several dynamic logic gates. A. Case Study: an autonomous emergency braking system
All above studies have well applied fault tree analysis
and formulations to calculate the PMHF for automotive
systems with or without fault-tolerant design. However, the
previous approaches do not address how to effectively
conduct the fault-tolerant design to achieve the required ASIL.
Therefore, in this paper we attempt to propose an ISO-26262-
compliant design framework which well utilizes the results of
fault tree analysis to enhance the efficiency of fault-tolerant
design for automotive hardware systems.
III. ASIL-ORIENTED HARDWARE DESIGN FRAMEWORK
Fig. 2. Functional block diagram of AEB system
In this work, we propose an ASIL-oriented hardware
design framework shown in Fig. 1. Fig. 2 shows the functional block diagram of the AEB
system. The primary function of the AEB system is to warn
drivers about emergent situations and autonomously brake the
vehicles to avoid serious collisions if drivers do not react to
the warning massage.
For implementing the warning and autonomous braking
function, radar will continuously monitor the distance
between the subject vehicle and the front vehicle, and provide
the distance information to the central AEB control node.
Fig. 1. ASIL-oriented Hardware Design Framework Once AEB control node is aware that the current distance falls
The goal of this framework is to assist the designer in into the dangerous range and the collision could happen under
creating the system-level hardware architecture to meet the the relative vehicle speed, the AEB control node will firstly
ASIL requirement. The proposed framework consists of four send a warning message (a sound or a flash light) to warn the
steps: driver. If the driver does not react to the warning message and
the situation becomes more severe, then the AEB control node
1) Step 1 – fault tree construction: construct the fault tree will inform the electronic brake units to actively perform the
manually according to the system hardware architecture. vehicle braking in accordance with appropriate braking forces
2) Step 2 – fault tree based weak-point analysis: specify to avoid the serious collision.
the failure rates for each hardware component of the Fig. 3 shows the hardware architecture of the AEB
analyzed system and acquire PMHF through the system. The CAN bus is adopted as in-vehicle communication
quantitative FTA to check if the target value can be backbone. According to designer’s requirements, other
reached. If the demanded ASIL cannot be achieved, advanced in-vehicle communication protocols like FlexRay or
then the quantitative disparity between current system automotive Ethernet can also be employed.
failure probability and the PMHF target value is
calculated. Moreover, the fault tree analysis will list all
MCSs (Minimal Cut Sets). In the meantime, the MCSs,
which cause PMHF target value not fulfilled, are
identified as weak-points in the system hardware
architecture. We rank all identified weak-point
components according to their quantitative disparity
with PMHF target value. Illustration of this step can be
found in Section III sub-section C.
3) Step 3 – ASIL-oriented fault-tolerant design: based
on the analysis results derived in Step 2, this step then
applies the safety mechanisms (SMs) to the identified
weak-point components to reduce their failure
probability. For weak-point components with higher
Fig. 3. Hardware architecture of AEB system
rank, SMs that are more powerful are applied. The
applied safety mechanisms with expected diagnostic The barking function of the AEB system is implemented
coverages can refer to ISO-26262 Part 5 Annex D. with fail-operational consideration. Once any one among four
Detailed explanation and illustration of this step can be EBD nodes (whether the Brake ECU or the EBM, Electrical
found in Section III sub-section D. Brake Module) is diagnosed as failed, the AEB MCU will stop
4) Repeat step 1-3 until the system PMHF conforms to the to send braking force to the failed EBD node. To keep braking
demanded ASIL. efficiency remained, braking forces are redistributed to the
remaining three working EBD nodes, i.e. these three working
To demonstrate the effectiveness of the proposed EBD nodes will take more braking force burden than previous
framework, we employ a safety-critical AEB system to four working EBD nodes situation. Therefore, the AEB
system can tolerate one failed EBD node with the degraded
braking performance.
B. Fault Tree Construction
Fig. 4 illustrates the fault tree constructed from the
hardware architecture as shown in Fig. 3. The K-out-of-N
gate reflects the fail-operational design concept. 2/4 (2-out-
of-4) gate for four EBD nodes means that the failure of one
EBD node will not lead to AEB system failure.
Fig. 4. Constructed fault tree of AEB system
C. FT-based Weak-point Analysis
Fault tree analysis (FTA) is a well-known and widely
applied analysis methodology. FTA has been proven to be
very effective on system reliability and safety analysis. In
ISO-26262, the FTA is recommended for analyzing the safety
of system, HW and SW. In this study, FTA is adopted
quantitatively and qualitatively for evaluating the failure
probability of the system, listing MCSs and calculating the
failure probability for each MCS.
C.1 Quantitative Fault Tree Analysis
TABLE I. COMPONENT FAILURE RATE
TABLE II. MCS AND FAILURE PROBABILITY
Before performing quantitative FTA, the component
failure rates shall be provided. The component failure rates
only for the purpose of demonstration are listed in Table I. In
real case, component failure rates can be estimated by
application of industry reliability data books and/or estimated
by procedural (enhanced data books incorporating physics of
failure elements) such as SN-29500, IEC-62380/61709 and
HDBK-217F, etc. Then, the MCSs and their failure
probabilities are listed in Table II.
For the MCSs {Brake ECUi, Brake ECUj}, {EBMi,
EBMj} and {EBMi, Brake ECUj}, i and j are both from 1 to 4
representing 4 EBD nodes, respectively, where i ≠ j.
The F(t) in (1) represents the failure probability at the
mission time t.
𝐹 𝑡 1 𝑒 (1)
where λ represents the component failure rate. In this
case study, mission time is specified to 5000 hours.
F(t) calculation is according to the following three cases
for MCS:
a. SPF (Single Point Fault): 1 component in the MCS;
b. DPF (Dual Point Fault): 2 components in the MCS;
c. MPF (Multiple Point Fault): ≥ 3 components in the
MCS.
For SPF, F(t) of MCS is directly equal to the component
failure probability; for DPF and MPF, the F(t) of MCS is
calculated by multiplying all component failure probabilities
included in this MCS. F(t) of whole system is calculated by
summation of failure probabilities of all MCSs. In this case
study, the system F(t) is 2.8703E-03.
In ISO-26262, system hardware can be declared to fulfill
the requirements for target ASIL only when the
corresponding target values of hardware architecture metrics
are achieved. The hardware architecture metrics include
Single Point Fault Metric (SPFM), Latent Fault Metric (LFM)
and Probabilistic Metric for random Hardware Failures
(PMHF) [1]. In this study, only the PMFH is adopted as target
to be achieved. However, SPFM and LFM can also be applied
to the proposed design framework. Table III gives the target
values of PMHF for different ASILs.
TABLE III. TARGET VALUES OF PMHF FOR DIFFERENT ASILS
In this case study, we assume that ASIL D is the target to
be achieved, i.e. the PMHF target value is 10-8h-1, and the
target failure probability of whole system is 4.99999E-05.
Apparently, there is a non-negligible gap between the
PMHF target value for ASIL D and current PMHF of AEB
system (nearly 60 times larger than the PMHF target value).
Thus, we need to improve the PMHF by introducing the
effective safety mechanisms in the hardware design.
C.2 Gap Quantification and Weak-point Classification
In this study, the “Gap” is defined as follows:
 Gap(Sys): quantitative disparity between whole system
and target failure probabilities
 𝐺𝑎𝑝 𝑆𝑦𝑠 𝐹𝑃 /𝐹𝑃 , where FPsys means
failure probability of whole system and FPTarget
means target value of failure probability with
required target ASIL.
  Gap(Sys) ≥ 1: PMHF for target ASIL is not achieved.
 Gap(Sys) < 1: PMHF for target ASIL is achieved.
 Gap(MCS): quantitative disparity between MCS and target
failure probabilities
 𝐺𝑎𝑝 𝑀𝐶𝑆 𝐹𝑃 /𝐹𝑃 , where 𝐹𝑃
means failure probability of kth MCS.
 Gap(MCSk) ≥ 1: 𝐹𝑃 must be reduced to be lower
than FPTarget, otherwise the target ASIL will never be
achieved. We call such MCS as must-be-protected
(MBP) weak-point.
 Gap(MCSk) < 1: 𝐹𝑃 is reduced on demand.
Details are described as follows:
 When Gap(Sys) > 1 and all Gap(MCS) < 1, all
MCSs will be ranked according to their
Gap(MCS). MCS with greater Gap(MCS) will
have higher ranking. Safety mechanism will be
introduced to the component(s) in the MCS with
highest ranking so that the 𝐹𝑃 can be
reduced. Such MCS is called protected-on-
demand (POD) weak-point.
Table IV shows the weak-point analysis results.
TABLE IV. weak-point analysis results for AEB system
D. ASIL-oriented fault-tolerant hardware design
Through the FT-based weak-point analysis, we have
identified the weak-points in the system and quantified the gap
to target failure probability. According to the Table IV results,
we propose an ASIL-oriented fault-tolerant hardware design
methodology to assist the designer in choosing the appropriate
safety mechanisms for identified weak-points. Fig. 5 depicts
the flow chart of the design methodology:
Fig. 5. ASIL-oriented fault-tolerant hardware design methodology
First of all, the existence of MBP weak-points should be
checked. All the MBP weak-points need to be protected by
safety mechanisms until we can assure that no more MBP
weak-point exists. If we apply SMs to a MBP weak-point
which is DPF/MPF, there will be more than one component in
this MBP weak-point, thus the primary contributor to failure
probability shall be identified. For the case that MBP weak-
point which is DPF or MPF and constituted by hardware
redundancy, the failure probability could be primarily
contributed by common cause failure. Thus, the mitigation
measures are adopted to lower the occurring probability of
common cause failure.
If Gap(Sys) is still greater than or equal to 1 after all the
MBP weak-points are resolved, then the POD weak-points are
the next targets to be addressed. The POD weak-point with
highest Gap(MCS) will be selected. There are three cases of
applying SM protection:
(a). Components in the POD weak-points have been
protected by SMs but the DCs are only at medium
level. In this case, current SMs are replaced by others
with high-level DCs.
(b). There is only one component in the POD weak-point,
i.e. SPF. In this case, this single component will be
directly protected with SM.
(c). For this case, one or more components in the POD
weak-point will be protected by SMs.
To avoid the situation that the designers do not specify a
reasonable target ASIL and component failure rates so that the
number of design iterations become very large or even infinite,
the number of iterations needs to be specified an upper bound.
When the number of iterations reaches the upper bound and
the Gap(Sys) is still greater than or equal to 1, the fault-tolerant
design shall be abandoned and a FT-based weak-point
analysis report is generated with all the fault-tolerance-
induced hardware blocks. Designers can base on the provided
information to determine if the target ASIL or the component
failure rates should be revised. Otherwise, we should consider
the redesign of hardware architecture.
In the following sub-sections, we will illustrate the
effectiveness of the proposed design methodology through the
AEB system case study.
D.1 Iteration 1: apply SM to MBP weak-point
TABLE V. SAFETY MECHANISM ADOPTION FOR EACH MBP WEAK-POINT
The selection of applied safety mechanisms is according
to ISO 26262 Part 5 Annex D [1]. In this Annex, Tables D.2-
14 suggests practical safety mechanisms with expected DCs
for various types of components such as processors, sensors
and communication buses, etc. Based on these tables, we can
apply appropriate safety mechanisms to those components
included in the MBP weak-points as shown in Table V.
Fig. 6 shows the revised hardware architecture and Fig.
7 illustrates the corresponding fault tree according to Table V.
Fig. 6. Revised hardware architecture of AEB system
Fig. 7. Revised fault tree of AEB system
D.2 Iteration 2: Apply CCF mitigation to MBP weak-point
In this design iteration, the Common Cause Failure (CCF)
should be addressed because the hardware redundancy is
adopted. To quantify the failure probability of CCF, the failure
rate of CCF must be acquired in advance. IEC-61508 provides
a feasible methodology for this end [9-10]. In IEC-61508 Part
6 Annex D, a β factor is proposed to represent the percentage
of CCF among whole failure rate of certain hardware
component and its redundancy. The β factor can be acquired
by answering about 40 Yes/No questions. These questions are
used to check if the designers use suitable measures to prevent
CCF from several aspects such as degree of physical
separation, design diversity and environmental control, etc. If
more questions are answered “Yes”, then the occurring
probability of CCF, i.e. β factor will become lower. The β
factor is ranged from 0.5 % to 10%. The β factor is then used
to calculate the failure rate of CCF, λC, by the following
equation (2).
𝜆 𝜆 𝛽 (2)
Table VI shows the updated MCS and their failure
probabilities with CCF consideration. In table VI, MCSs with
suffix “CCF” and β factor represent that the failure probability,
𝐹𝑃 _ is calculated by following equations:
𝐹𝑃 _ 𝐹𝑃 _ _ _
𝐹𝑃 _ _ _ 𝐹𝑃 (3)
𝑤ℎ𝑒𝑟𝑒 𝐹𝑃 _ _ _ 𝐹𝑃 _ _ _
1 𝑒
𝐹𝑃 1 𝑒
We note that the β values used in table IV are only for the
purpose of illustration. Presentation of CCF in fault tree can
also be found in [11].
TABLE VI. MCS FAILURE PROBABILITY WITH CCF CONSIDERATION
The failure probability of current AEB system is
9.19174E-05. The Gap(Sys) is 1.83839 which is still greater
than 1. It means that the target PMHF for ASIL D still cannot
be achieved. Thus, FT-based weak-point analysis is
performed again to identify the weak-point so that the fault-
tolerant design can be employed to further improve the system
failure probability. Table VII shows the analysis results.
TABLE VII. WEAK-POINT ANALYSIS RESULTS (ITERATION 2)
According to Table VII, radars are the only one MBP
weak-point left. Due to the high β factor, the Gap(MCS) for
MCS {Radar 1, Radar 2}CCF,β=10% is not effectively reduced as
expected. Through this case study, we want to demonstrate
that the hardware redundancy could still fail to provide
sufficient failure probability reduction if the CCF is not well
addressed. To reduce β factor, the CCF mitigation measures
shall be adopted. ISO-26262 Part 11 provides effective
measures for CCF mitigation. Typical measures are external
watchdog, physical separation and design diversity, etc. We
assume that the β factor for radars is reduced to 0.5% after
applying the CCF mitigation measures. Fig. 8 depicts the
revised fault tree. For space saving, only the changed part is
shown.

Fig. 8. Revised fault tree of AEB system (only Radar Sub-sys part is shown)
D.3 Iteration 3: Apply safety mechanism to POD weak-point
The fault-tolerant design now enters the third iteration.
After applying CCF mitigation measures to radars, Gap(MCS)
for MCS{Radar 1, Radar 2}CCF,β=0.5% has been reduced to
7.33620E-02. Consequently, all MCSs are identified as POD
weak-points. However, Gap(Sys)=1.66268 which is still
greater than 1. Thus weak-point analysis for current AEB
system is performed and the results are shown in Table VIII.
TABLE VIII. WEAK-POINT ANALYSIS RESULTS (ITERATION 3)
In table VIII, we identify the MCS {EBMi, EBMj} as the
highest rank. Therefore, we apply appropriate SMs to protect
EBMs. Fig. 9 depicts the revised fault tree. Again, for space
saving, only the changed part is displayed.
Fig. 9. Revised fault tree of AEB system (only EBD node part is shown)
D.4 Iteration 4: target ASIL has been achieved
Performing quantitative FTA for current AEB system
under the fourth design iteration, the analysis results indicate
that the failure probability of whole system is 3.59763E-05
and the Gap(Sys) = 7.19544E-01 which is lower than 1.
Consequently, the PMHF for target ASIL has been achieved.
The final fault tree is shown in Fig. 10.
IV. CONCLUSION AND FUTURE WORK
In this study, an ASIL-oriented hardware design
framework for safety-critical automotive system is proposed.
With the case study, we have illustrated how to accomplish a
hardware design for the AEB system which complies to the
requirements of ISO-26262 functional safety standard.
Through the proposed FT-based weak-point analysis and
ASIL-oriented fault-tolerant design methodologies, we have
shown that how to effectively apply safety mechanisms to the
system design so that the demanded ASIL can be achieved.
View publication stats
In this paper, only the PMHF is adopted as the target
metric. Our future goal is to improve the proposed framework
to conform to all the three hardware architecture metrics,
SPFM, LFM and PMHF. This will increase the complexity of
fault-tolerant HW design substantially. Therefore, the
challenge of next work will be how to propose a fault-tolerant
design framework to fulfill the target values of all hardware
architecture metrics and keep the number of design iterations
low enough to make the approach feasible and effective.
Besides, the proposed methodologies are very suitable to be
implemented in an EDA tool. That is another future work.
Fig. 10. Revised fault tree of AEB system (final version)
ACKNOWLEDGMENT
The authors acknowledge the support of MOST
academic research project under Contract Number 108-2221-
E-305 -004 -MY2.
REFERENCES
[1] ISO/DIS 26262, “ISO-26262 Road Vehicles -- Functional safety”,
International Organization for Standardization, 2018.
[2] Fabio Marchiò et al., “Automotive electronics: Application &
technology megatrends”, 44th ESSDERC, Page(s): 23 - 29, 2014.
[3] John O. Clark et al., “System of Systems Engineering and Family of
Systems Engineering From a Standards, V-Model, and Dual-V Model
Perspective”, 3rd IEEE Systems Conference, Page(s): 381 - 387, 2009.
[4] J.S. Cheon et al., “Brake By Wire Functional Safety Concept Design
for ISO/DIS 26262”, 2011 SAE World Congress, 2011-01-2357, 2011.
[5] N. Das, and W. Taylor, "Quantified fault tree techniques for calculating
hardware fault metrics according to ISO 26262," in IEEE Symp.
Product Compliance Eng. (ISPCE), pp. 1–8, 2016.
[6] Abraham Cherfi, “Toward an Efficient Generation of ISO 26262
Automotive Safety Analyses”, Ecole Doctorale Polytechnique,
Laboratoire PRiSM, UVSQ, July 2015
[7] Atsushi Sakurai, "Generalized formula for the calculation of a
probabilistic metric for random hardware failures in redundant
subsystems", ISPCE 2017, pp. 1-5, 2017.
[8] Tong Wang, Xi Chen, Zhikai Cai, Junnan Mi, Xiaomin Lian, "A mixed
model to evaluate random hardware failures of whole-redundancy
system in ISO 26262 based on fault tree analysis and Markov chain",
Proceedings of the Institution of Mechanical Engineers, Part D:
Journal of Automobile Engineering, vol. 233, pp. 890, 2019
[9] IEC 61508: Functional safety of electrical/electronic/ programmable
electronic safety-related systems, International Electro-technical
Commission IEC, 2010
[10] Stein Hauge et al., “Common Cause Failures in Safety Instrumented
Systems”, Report of SINTEF Technology and Society, May 2015
[11] Vrbanic, I. et al., “Presentation of common cause failures in fault tree
structure of Krsko PSA : an historical overview”. NENE 2003