Autom

motive Hard
dwaree Deveelopm
ment A
According too
ISO O 262
262
Seo-Hyunn Jeon*, Jin-Hee Cho*, Y
Yangjae Jung
g*, Sachoun Park*, Tae-M
Man Han*
*Automotive
* Convergence Platform Research Team, E
ETRI, 161 Gaajeong-Dong, Yuseong-Gu, Daejeon, 305 5-700, KOREAA
[email protected], chojh
[email protected],, [email protected], [email protected]
kr, [email protected],

Abstract— This paper brieflyy explains ISO O 26262, thee new orien
nted and safetty-oriented annalyses, and 10.Guideline.
1 The
autoomotive stand dard for functional safety. The
T standard is for development process of item leevel starts fromm part 3 to 7, and
elecctrical/electron
nic systems moounted on seriees of passengerr cars. he other partss are supportiing process. The developm
all th ment
In the
t standard, Automotive Safety Integriity Level (ASIIL) is proceess generally follows V-stytyle process model
m and cann be
ur levels accorrding to the reequired safety level.
classsified into fou
Eacch of the AS SIL has its ow wn process and
a steps forr item
depiccted as Figuree 1. [1]
development. Thiis paper focu uses on the iteem developmeent at
hardware level, eespecially for ASIL C and d D. The hard dware
development proccedure includees the calculation of single point
mettric and latentt fault metric. Furthermore,, we present ooverall
calcculation steps oof controlling random
r hardw
ware failure.

Keyywords— ISO 26262, system m, hardware, deevelopment, sinngle

poin
nt fault metricc, latent fault metric,
m diagnosstic coverage

I. INTRRODUCTION
There
T is an uupcoming staandard for au utomotive inddustry;
ISO
O 26262 Roaad vehicles – Functional safety, and it is
plannning to be ppublished in 2011. The au utomotive inddustry
sho
ould be well pprepared to addapt this new standard intoo their
product developm ment process since automo otive manufaccturers
willl require theiir suppliers too provide only products w whose
devvelopment proocesses complies this stand dard. It is beecause
the company’s competitiveneess will be measured m by their Figure
F 1. Overviiew of ISO 26262
2
pability of cconducting the
cap t standardiized developpment
process. The scoope of ISO 26262 includes all safety reelated Ass in Figure 1,1 functional safety concep pt of the itemm is
elecctrical/electronnic (E/E) systtems for autom
motive applicaation. deriv
ved in the co oncept phase,, and productt developmennt at
ISO
I 26262 iss derived froom IEC 6150 08, but adaptted to systeem level will be
b started. In tthe product deevelopment phhase,
autoomotive induustry. The big differen nce between two the system design is speciified and eaach developm ment
stan
ndards is thatt ISO 26262 considers co ontrollability while proceesses at harrdware and software lev vels are initiiated
IECC 61508 doees not. Conttrollability is ability to avoid indiv
vidually.
hazzardous event, the action takken by a driveer. Considerinng this, Allthough the ISSO 26262 stanndard lists alll the requirem
ments
ISO
O 26262 classiifies Automotive Safety Integrity Level ((ASIL) to be complied, it is difficullt to catch th he steps of each
e
into
o four diffeerent levels, depending on its sevverity, vities’ what to do and wherre to start. Fo
activ or this reason, this
probbability of exxposure, and controllability.
c . After determ
mining paper explains how to develoop a product to achieve the
ASIIL, the producct is developed in the proceess according to the functtional safety according
a to tthe standard, especially forr the
metthod and meaasure of the coorresponding ASIL. As a rresult, produ uct development at hardwar are level.
the main purposee of implemennting this stan ndard is keepinng all Thhis paper intro
oduces the stepps at hardwarre developmennt by
the records of saafety-related activities
a from
m the developpment deriv
ving metrics of a hardwarre element with w respect too its
process to ensuree functional saafety. failurre modes. This analysis is inevitable steep when claim ming
ISO
I 26262 is composedd of 10 parrts: 1.Vocabuulary, comp pliance of AS SIL C and D. The result of o these steps will
2.M
Management of functionnal safety, 3.Concept pphase, furth
her perform as an evidence oof compliancee.
4.Prroduct develoopment: system m level, 5.Pro
oduct developpment: Thhe scope of th his analysis iis limited to random
r hardw
ware
harddware level,, 6.Product developmentt: software level, failurre and the parts
p consideered in the analysis are the
7.Prroduction andd operation, 8.Supporting
8 processes,
p 9.A
ASIL- electtrical and electronic parts.. For electrom mechanical parts,
p

ISBN 978-89-5519-155-4 588 Feb. 13~16, 2011 ICACT2011

only the electrical failure modes and failure rate are Random hardware failure normally occurs arbitrarily in a
considered. hardware element, however, its failure rate can be predicted
The derivation steps of hardware architectural metrics will with reasonable accuracy. The random hardware failure data
be mainly discussed in Section II. Section II-A explains can be obtained from several sources. (see list of II-C, 1) )
general process of hardware development. Section II-B To calculate the hardware architectural metrics, the failure
describes classification of the failure modes of hardware mode needs to be defined. Each faults occurring in a safety-
elements. Section II-C derives hardware architectural metrics related hardware element can be classified as in figure 3 and
according to the classification and gives steps how to calculate. are defined in the standard as follows: ([2], [3])
The conclusion is given in III, and a brief example of x Safe fault: fault whose occurrence will not significantly
calculating the metrics and deriving ASIL is given in IV. increase the probability of violation of a safety goal
x Multiple point fault: one fault of several independent
II. HARDWARE DEVELOPMENT ACCORDING TO ISO 26262 faults that in combination, leads to a multiple point
failure (either perceived, detected or latent)
A. Hardware development process
- Perceived: This fault is deduced by the driver
The hardware development process according to ISO 26262 without detection by a safety mechanism within a
starts from planning the hardware development. The plan prescribed time.
includes specifying the methods and measures to be used - Detected: This fault is detected by a safety
during hardware design. Next, hardware safety requirement is mechanism to prevent the fault from being latent
specified. This will be derived from several sources such as within a prescribed time.
technical safety concept, software safety requirements and - Latent: This fault is neither detected by a safety
system design specification, from previous activities. (Not mechanism nor perceived by the driver.
mentioned in this paper) Hardware safety requirement x Single point fault: fault in an element which is not
specification should be consistent to these documents. And, covered by a safety mechanism and where the fault
hardware is designed according to the hardware safety leads directly to the violation of a safety goal
requirements specification. In the hardware design process, x Residual fault: portion of a fault which by itself leads to
hardware architectural metric with respect to random the violation of a safety goal, occurring in a hardware
hardware failures needs to be evaluated and verified for ASIL element, where that portion of the fault is not covered
C and D. The steps deriving hardware architectural metrics are by existing safety mechanisms
explained in the section II-C. Finally, the hardware elements
are integrated and tested. Overall steps of hardware Failure mode
of a HW
development are depicted in Figure 2. [2] element

4.7 System Design Not safety

Safety relate
relate HW
element HW element
Scope of ISO 26262-5

5.5 Initiation of product

development at hardware level Multiple
Single/residu
Safe fault Safe fault point
fault(MPF) al point fault

5.6 Specification of hardware

safety requirements

Detected Perceived
Latent MPF
5.7 7.5 Production and MPF MPF
Hardware design
operation

Figure 3. Failure modes classification of a hardware element

5.8 Hardware architectural
metrics
Qualification of
C. Hardware architectural metric calculation
5.9 Evaluation of violation of the safety 8.13 hardware components
goal due to random HW fa ilures To obtain objective evidence for the hardware design that it
has achieved the safety goal, the hardware architectural metric
Hardware integration and Item integration and
needs to be calculated for ASIL C and D according to the
5.10 4.8
testing testing following procedure.
---------------------------------------------------------------------
Figure 2. Hardware development procedure 1) Estimate failure rate of single point fault and latent
multiple fault.
Each of the number appeared in the left box and the name 2) Estimate diagnostic coverage of safety mechanism.
in the right box in the figure 2 shows the corresponding 3) Calculate “single point faults metric” and “latent
number and the name of clauses in the ISO 26262. faults metrics.”
4) Compare the metrics with target values.
B. Failure mode classification of a hardware element
---------------------------------------------------------------------

ISBN 978-89-5519-155-4 589 Feb. 13~16, 2011 ICACT2011

 The detailed explanation for the procedure is given as the first, and the outputs difference leads to a failure message.
follows: This technique can achieve high diagnostic coverage.
1) Estimate failure rate of single point fault and latent TABLE 2. DIAGNOSTIC TECHNIQUE/MEASURE AND THEIR COVERAGE FOR
multiple fault. VARIABLE MEMORY
The failure rate of a hardware part can be estimated either Diagnostic technique/measure Maximum
from following sources. diagnostic
x Using a recognised industry sources (i.e., IEC 62380, coverage
IEC 61709, MIL HDBK 217 F notice 2, RAC HDBK considered
217 Plus, NPRD95, EN50129 Annex C, EN 62061 achievable
Annex D, RAC FMD97, MIL HDBK 338, etc.); RAM test "checkerboard" or "march" Low
x Using statistics based on field returns or tests; or One bit redundancy Low
x Using expert judgement based on engineering approach. Detection of RAM data failures with error- High
detection-correction codes (EDC)
2) Estimate diagnostic coverage of safety mechanism. Block replication High
Diagnostic coverage can be calculated using Annex D of [2]
which tables of every element or part used in the hardware 3) Calculate “single point faults metric” and “latent
architecture are given with their achievable diagnostic faults metrics.”
coverage. When all the failure rates estimated, ęSingle point faults
Table 1 shows an example of the components consisting metric” and “latent faults metrics are calculated as following
hardware architecture and their faults or failures that needs to equations.
be analysed to derive diagnostic coverage. For relays to Single point faults metric:
achieve 99% of diagnostic coverage, 2 factors need to be
detected: i) does not energize or de-energize, ii) individual σ ሺȜ ାȜ ሻ σ ሺȜ ାȜ ሻ
contacts welded. This table is only part of the quotation of the ൌ ͳ െ ౏౎ σ౏ౌూ ౎ూ ൌ ౏౎ σ౉ౌూ ౏ (1)
౏౎ Ȝ ౏౎ Ȝ
standard, therefore, for further examples of hardware Latent fault metric:
components, see Annex D of [2],[4],[5].
σ౏౎ሺȜ౉ౌూై ሻ σ ሺȜ౉ౌూౌీ ାȜ౏ ሻ
ൌͳെσ ൌ σ ౏౎ (2)
TABLE 1. EXAMPLE OF REQUIRED FAULTS OR FAILURES TO DERIVE ౏౎ሺȜିȜ౏ౌూ ିȜ౎ూ ሻ ౏౎ሺȜିȜ౏ౌూ ିȜ౎ూ ሻ
DIAGNOSTIC COVERAGE where,
Components Recommendations for diagnostic coverage x Safety related HW elements: σୗୖ
Low Medium High x Failure rate associated to hardware element single point
(60 %) (90 %) (99 %) faults: Ȝୗ୔୊
Relays Does not Does not Does not energize x Failure rate associated to hardware element residual
energize energize or de-energize faults: Ȝୖ୊
or de- or de- Individual contacts x Failure rate associated to hardware element multiple
energize energize welded point faults: Ȝ୑୔୊
Welded Individual
x Failure rate associated to hardware element perceived or
contacts contacts
welded detected multiple point faults: Ȝ୑୔୊୔ୈ
Invariable Stuck-at d.c. fault All faults which x Failure rate associated to hardware element latent
memory for data model for affect data in the multiple point faults: Ȝ୑୔୊୐
range and data and memory x Failure rate associated to hardware element safe faults:
addresses addresses Ȝୗ with Ȝ ൌ Ȝୗ୔୊ ൅ Ȝୖ୊ ൅ Ȝ୑୔୊ ൅ Ȝୗ and Ȝ୑୔୊ ൌ
Variable Stuck-at d.c. fault d.c. fault model for Ȝ୑୔୊୔ୈ ൅ Ȝ୑୔୊୐ .
memory for data model for data and addresses
range and data and Dynamic cross-over 4) Compare the metrics with target values.
addresses addresses for memory cells Numerical target values for “single point faults metric” and
No, wrong or “latent faults metrics” are given in table 3. Appropriate target
multiple addressing
values wrt. their ASILs are chosen for the hardware
architectural metric of the product. Finally, by comparing the
Techniques to derive the diagnostic coverage and the result of calculated metrics with the target values, the product
maximum achievable diagnostic coverage for the selected can be claimed compliance with the standard.
component are given in table 2. This is the example of a
variable memory range from table 1. Block replication in table TABLE 3. TARGET VALUES FOR SINGLE POINT FAULTS METRIC AND
2, for instance, aims to detect all bit failures of the memory by LATENT FAULTS METRIC
duplicating the address space in two memories. The ASIL B ASIL C ASIL D
mechanism is: the first memory is operated in the normal
Single point faults metric > 90 % > 97 % > 99 %
manner, the second memory stores the same information
inversely and it is inverted again when accessed in parallel to Latent faults metric > 60 % > 80 % > 90 %

ISBN 978-89-5519-155-4 590 Feb. 13~16, 2011 ICACT2011

 III. CONCLUSION Now, applying (1) for single point faults metric, we
The hardware development process according to ISO 26262 calculate:
is explained in this paper. The process consists of planning,
σ౏౎ሺ஛౏ౌూ ା஛౎ూ ሻ ହǤଶଷସ
hardware safety requirement specification, hardware design, ൌͳെ σ౏౎ ஛
ൌ ͳ െ 
ଵ଴଼
and integration and testing. The calculation of hardware ൌ ͻͷǤʹΨ (3)
architectural metrics during hardware design process for ASIL Applying (2) for latent fault metric, we calculate:
C and D is explained in detail by 4 steps. Evaluation of
hardware architectural metrics with respect to random σୗୖሺȜ୑୔୊୐ ሻ ͲǤ͸
hardware failures and final claiming evidence are included in ൌͳെ ൌͳെ
the steps. By obtaining hardware architectural metrics, the σୗୖሺȜ െ Ȝୗ୔୊ െ Ȝୖ୊ ሻ ሺͳͲͺ െ ͷǤʹ͵Ͷሻ
architectural detailed design can have ASIL dependent ൌ ͻͻǤͶʹΨ (4)
pass/fail criteria and can be objectively assessable. 4) Compare the metrics with target values.
Developing an item in compliance with ISO 26262 is not a The result of this hardware is complying ASIL B because
simple task, but automotive companies should implement the the single point faults metric satisfies > 90% of ASIL B but
standard in advance to their development process because this not enough for > 97% of ASIL C. Latent faults metric satisfies
will show the evidence of organizational capability of in all cases but the result of the hardware is conservative and
performing functional safety in near future. becomes ASIL B.
IV.EXAMPLES This example shows that in order to receive higher ASIL
the hardware component with lower failure rate or safety
The example of calculation of single point fault metric and mechanism with higher diagnostic coverage is needed. If
latent fault metric are given in table 4 and 5, respectively. [2] hardware does not meet the target value, rationale for how will
Recall the 4 steps. the safety goal be achieved should be stated in the safety case.
1) Estimate failure rate of single point fault and latent
multiple fault. TABLE 4. SINGLE POINT FAULTS METRIC EXAMPLE

The first step is to fill the failure rate (F) of the second C F SR FM FD V SM FC RF/SPF
column of the table 4 and 5. This failure rate is normally R1 2 SR Open 90% X none 90% 0.18
provided with the component (C). And check in the “SR” Closed 10%
column, whether the component is safety related or not. This C1 2 SR Open 20% SM1
selection is made by the hardware developer. Closed 80% X 99% 0.016
Also, fill in the failure mode (FM) and failure rate I1 4 SR Open 70% X SM1 99% 0.028
Closed 20% X 99% 0.008
distribution (FD). Failure mode can be derived using FMEA.
Drift 5% X 99% 0.002
[6] The summation of failure rate distribution of each 0.5
component should be 100%. Drift 2 5%
2) Estimate diagnostic coverage of safety mechanism. L1 10 NSR Open 90%
Closed 10%
If the failure mode of the component has potential to violate ȝC 100 SR All 50% X SM3 90% 5
the safety goal in the absence of safety mechanism or due to All 50%
independent failure of another component, check “V” or “VI” Total 118 5.234
column.
And, describe in the “SM” or “L” column, the safety
mechanism that prevents the failure mode from violating the TABLE 5. LATENT FAULTS METRIC EXAMPLE
safety goal or being latent. Continuously, fill out the
diagnostic coverage of the safety mechanism in “FC” and C F SR FM FD VI L FCL LMPF
“FCL” column of table 4 and 5. R1 2 SR Open 90% X SM1 100% 0
Residual or single point fault failure rate (RF/SPF) can be Closed 10% X 0% 0.2
C1 2 SR Open 20% X SM1 0% 0.4
calculated by multiplying F*FD*(1-FC). Latent multiple
Closed 80% X 100% 0
point fault failure rate (LMPF) can be calculated by
I1 4 SR Open 70% X SM1 100% 0
multiplying F*FD*(1-FCL). Closed 20% X 100% 0
3) Calculate “single point faults metric” and “latent Drift 5% X 100% 0
faults metrics.” 0.5
Drift 2 5%
x Total failure rate: 118
L1 10 NSR Open 90%
- Total safety related failure rate: 108 Closed 10%
- Total not safety relate failure rate: 10 ȝC 100 SR All 50% X SM3 100% 0
x Total residual or single point fault failure rate : 5.234 All 50%
x Total latent multiple point faults failure rate: 0.6 Total 118 0.6

ISBN 978-89-5519-155-4 591 Feb. 13~16, 2011 ICACT2011

 Table indices: mechanism allowing preventing the failure mode from
being latent.
x C (Component name): list of components. x FCL (Failure mode coverage wrt. latent failures):
x F (Failure rate): input failure rate of the component.
diagnostic coverage of the selected safety mechanism
x SR (Safety Related): state whether the component is
x LMPF (Latent multiple point fault failure rate):
safety-related (SR) or not (SNR). calculate the latent multiple point fault failure rate by
x FM (Failure mode): Describe failure mode of each
ࡸࡹࡼࡲ ൌ ࡲ ൈ ࡲࡰሺͳ െ ࡲ࡯ࡸሻ.
component.
x FD (Failure rate distribution): for each of the failure
mode, derive failure rate distribution. The sum of each ACKNOWLEDGMENT
distribution will be 100%. This work was supported by the fund of Development of
x V (Potential to violate the safety goal in absence of
Integrated Control SW Platform for Automotive Electronics
safety mechanism): check whether the absence of safety project (MKE).
mechanism can cause the violation of the safety goal.
x SM (Does the safety mechanism prevent the failure REFERENCES
mode from violating the safety goal?): if checked (X), [1] R. Hamann, J. Sauler, S. Kriso, W. Grote and J. Moessinger,
write the safety mechanism. “Application of ISO 26262 in Distributed Development ISO 26262 in
x FC (Failure mode coverage): diagnostic coverage of the Reality,” SAE World Congress & Exhibition, Apr. 2009.
selected safety mechanism [2] ISO 26262 Road vehicles – Functional safety – Part 5: Product
development: hardware level
x RF/SPF (Residual or single point fault failure rate): [3] ISO 26262 Road vehicles – Functional safety – Part 10: Guideline
calculate the residual or single point fault failure rate by [4] IEC 61508 Functional safety of electrical/electronic/programmable
ࡾࡲȀࡿࡼࡲ ൌ ࡲ ൈ ࡲࡰሺͳ െ ࡲ࡯ሻ. electronic safety-related systems-Part 1: General requirements
x VI (Independent failure): check if the failure mode may [5] IEC 61508 Functional safety of electrical/electronic/programmable
electronic safety-related systems-Part 7: Overview of techniques and
lead to violation of safety goal in combination with an measures
independent failure of another component. [6] Potential Failure Mode & Effects Analysis, Chrysler LLC, Ford Motor
x L (Does the safety mechanism prevent the failure mode Company, General Motors Corporation, Jun. 2008
from being latent?): if VI is checked, write the safety

ISBN 978-89-5519-155-4 592 Feb. 13~16, 2011 ICACT2011