Automotive

CAM0500244-01
Method: FTA
Maturity

Creator
Name: Jean-Marc Astruc
Department: BU ES Q
30.11.2010
eSign List ID: 1116849

draft
valid

Process Owner

Change Reason

Name: Hans-Leo Ross

Department: QPF
30.11.2010
eSign List ID: 1116849

Objective

Subject:

This method description provides an overview of the Fault Tree Analysis (FTA) method and
subjects to analyzed.

Goal:

FTA is a deductive failure analysis which is often applied (but not restricted) to reliability prediction
and safety analysis of the systems. The method is based on the identification and evaluation of
conditions and factors which cause or contribute to the occurrence of one particular undesirable
event. This event is usually denominated as an undesired top-level event or top event. A further
goal of the method could be the analysis and determination of cutsets, which is the basis for the
design of safety mechanism.

The FTA could be further on used, to analyse the paths of real occurred failures of the
system, to localize the causes of the system failures. The different cut sets are showing
the paths with the highest probability for the occurrence of the failures.

Scope
This method description is applicable to Conti Automotive. It can be complemented with local or application-specific
working instructions.
This regulation is mandatory for:
Continental Automotive and its majority
interests as well as minority interests with
management control by Continental Automotive.
Division
Business Unit
Automotive Function
Region
Country
Site
Plant
Other

For internal use only

Continental AG

Page 1 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01

Table of Content
Method: FTA .................................................................................................................................................................1
1 Method...................................................................................................................................................................3
1.1
Preparation of a Fault Tree Analysis ............................................................................................................3
1.2
Fault Tree Construction ................................................................................................................................4
1.3
Qualitative Evaluation of Fault Tree..............................................................................................................4
1.4
Quantitative Evaluation of Fault Tree ...........................................................................................................5
1.5
Use of FTA Outcomes ..................................................................................................................................5
1.6
Archiving of the FTA Documents ..................................................................................................................5
2 Metrics and Performance Indicators......................................................................................................................6
2.1
Graphic Symbols...........................................................................................................................................6
2.2
General Hints on FTA Usage........................................................................................................................8
3 Further Definitions .................................................................................................................................................9
3.1
Acronyms ......................................................................................................................................................9
3.2
Definitions .....................................................................................................................................................9
3.3
Example of Fault Tree Diagram ..................................................................................................................10
3.4
Example of Primary Events Dictionary .......................................................................................................12
3.5
Example of Qualitative Evaluation ..............................................................................................................12
4 References ..........................................................................................................................................................14
4.1
Mandatory ...................................................................................................................................................14
4.2
Other ...........................................................................................................................................................14
5 Document History ................................................................................................................................................14
6 Responsible Persons...........................................................................................................................................14
6.1
Process Owner ...........................................................................................................................................14
6.2
Process Manager........................................................................................................................................14
6.3
Process Team .............................................................................................................................................14

For internal use only

Continental AG

Page 2 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01
1

Method

The top events usually come out of Hazard & Risk Analysis or higher-level analysis (such as FMEA, FTA, ETA etc.)
previously carried out at vehicle level by the car manufacturers. In some cases, they can be directly derived from
the experience.
Ideally, the development of the fault tree should start early in the concept phase, so that results could affect the
design of the function, system or component. FTA could be considered as complementary method of a FMEA. For
ASIL C & ASIL D, deductive analysis such as FTA is mandatory in addition to FMEAs. The FTA could be used to
develop the function net of a VDA-FMEA. The higher order cutsets should be resulting in the connection of the
function net.
FTA can also be carried out retrospectively on existing or reused systems in order to check / confirm their
compliance with given safety requirements or objectives.
Responsibility for FTA shall be planned as part of the Project (Safety) Plan.
Whatever the context is, the steps described below should be completed.

1.1

Preparation of a Fault Tree Analysis

State precisely the undesired top-level event in order to bound the scope of the analysis to the system under
consideration.
For example, the scope of top event "vehicle runaway" is basically broader than "vehicle runaway due to
EMS". Moreover, wording "vehicle runaway" needs to be defined as far as possible in measurable terms and
for given operating conditions, if any.
Define the goal of the FTA in order to focus on the type of data to be collected for analysis.
Definition of goal may include showing that a system design complies with qualitative and/or quantitative
safety objectives or requirements.
However, a relevant knowledge of the system is required before starting a FTA that encompasses functional
structure and physical structure of the system, interactions and interfaces with other systems, mission profiles
and operating modes, etc.
Define hierarchical level and depth of the FTA.
It consists in defining the level of detail as criteria for the identification of the primary events. This level of detail
should allow clear discrimination of responsibility related to the causes leading to the undesired top-level
event.
FTA could be performed on any level of abstraction; the hierarchical level shall be aligned with the structure
net of the corresponding FMEA. As a consequence the interface and boundary definition within the
development should be taken into account.
It should be agreed, if the fault tree is based on functional failure or on technical failure (e.g. physical
damages, random hardware fault). Furthermore it should be agreed if failure modes (malfunction), erroneous
behavior or faults should be considered within the analysis. Any mixture could lead to different results at
interfaces.
This may take into account features such as system interfaces, system components sources, hardware and
software split, work sharing between partners or with customers (incl. calibration, sub-systems manufacturing
and mounting), etc.

For internal use only

Continental AG

Page 3 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01
1.2

Fault Tree Construction

Develop the upper and intermediate levels of the fault tree.
It consists in determining the intermediate failures and combinations of failures which are minimum,
immediate, necessary and sufficient to cause the top event to occur and interconnecting them by the
appropriate graphic logic symbols.
Then, each level is expanded to the next lower level. For each event, the following questions should be
answered:

Are there any single failures, which will cause the event under consideration to be true?

Are there any common cause failures, which will cause the event under consideration to be true?

Are there any multiple failure combinations which will cause this event to be true?

When considering fail-safe properties of a system the following structure should be sought whenever possible
in order to identify which measures are taken at system design level in order to preclude or reduce effects of
faults and failures:
event
G17

failure(s)
or fault(s)
G18

protection
mechanism (or
measure)
inoperative
G19

Extend the branches of the fault tree down to the primary events.

It consists in developing each event down through successively more detailed levels of the
system design until the root causes are established or until further development is thought
no more necessary.
1.3

Qualitative Evaluation of Fault Tree

Determine qualitative importance of primary events.
It consists in ranking the cutsets in ascending order based on the number of primary events in each cutset. It
allows to see the relative importance of the various primary events with respect to top event occurrence based
on how many times the primary event appears in the cutsets and in what combination with other primary
events.
st
Specific attention should be paid to existence of 1 order cutsets (i.e. single-point failures or dependent failure
leading directly to the top event)
Moreover, rough estimation assuming the same probability for all primary events shows that the probability of
th
th
occurrence of N order cutsets is greater than for N+1 order cutsets. It comes out that cutsets with 5 or more
primary events have very low relative influence on the probability of occurrence of the top event.
This type of evaluation works well with hardware random faults, hardware / software development errors, and
a combination of the two in the same tree.
Determine common cause vulnerability.
It consists in examining each cutset to determine potential lack of independence between the primary events
in each cutset.
Moreover, cutsets having similar primary events are more likely to be susceptible to common cause failures
than cutsets having dissimilar primary events.

For internal use only

Continental AG

Page 4 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01
1.4

Quantitative Evaluation of Fault Tree

Quantitative evaluation is usually restricted to complement qualitative evaluation of the most critical applications. It
is carried out on a case by case basis depending on customer's demands. It consists in calculating the probability
of occurrence of the top event (or any intermediate event) from the probability of occurrence of each primary event.
The probability of primary events is usually based on data such as failure rate, exposure time, and failure detection
coverage by monitors, etc. ISO 26262 does not consider any quantification of systematic fault.
Caution:

1.5

Cutsets containing primary events related to software or hardware development errors (i.e.
systematic errors) must only be evaluated by qualitative approach. Quantitative evaluation cannot be
performed because the current methods for estimating the post-verification probabilities of errors do
not provide results that are commensurate with safety objectives usually assigned to critical
applications.
Fault trees containing primary events related to both hardware random faults and hardware or
software development errors require performing quantitative analysis only on primary events related
to hardware random faults.

Use of FTA Outcomes

The outcomes of a FTA can be used as a basis in order to:

Discriminate the responsibilities related to the causes leading to a given hazardous top event,

Supporting the allocation and design of safety mechanism

Adequate budgeting of average from reliability targets (e.g. PMHF) for sub-elements.

Supports design improvement, especially for higher order cutsets and establishing of barriers for sufficient
independence or freedom of interference.

Evidence about potential cause of depending failure or potential common cause effects and cascades

Establish coverage of the failures leading to this event by the system built-in protection mechanisms,

Identifying the optimized position in the architecture for design improvement.

Define relevant test cases that aim at showing that the actual system reacts as intended in failure
conditions.

Show compliance with safety (only PMHF) or other key-characteristic objectives assigned to the system.

Arguing sufficient effectiveness of safety mechanism, especially if different operating modes are
considered. (Event Tree Analysis (ETA) would be considered as a deductive analysis.)
Assess the impact of design changes on safety or other key-characteristic.

1.6

Archiving of the FTA Documents

The data resulting from the FTA should be documented and recorded in the corresponding project folder. All the
FTA documents (electronic or paper versions) must be archived for the same period of time as all other R&D
documents of the corresponding project unless a stronger demand of the customer exists.

For internal use only

Continental AG

Page 5 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01

2
2.1

Metrics and Performance Indicators

Graphic Symbols

The Fault Tree Diagram is based on graphic symbols, which provide a straightforward and hierarchical
representation of the relationships between the events that can lead to the top event. A definition of the most
common graphic symbols is provided in the table below:
Caution: Symbols in tools could be different.
Name
Basic event

Illustration

Definition
Primary event which is internal to the system under
analysis. It requires no further development.
Here :
- "comp-B1" is the name of the basic event
- "component #B1 fails" is a comment attached to
the basic event (see example in Appendix A)

component
#B1 fails
comp-B1

Undeveloped
event

Primary event which is not developed further

because:
- it has a negligible impact on the top event, or
- it would jeopardize understandability without
adding significant value for the purpose of the
study, or
- details necessary for further development are not
(yet) available.
Software-related primary events usually take the
form of undeveloped events.

SW design
error
comp-A/01

OR-gate

with or without description box :

Boolean logic gate - output event of this gate occurs

if any one or more of the input events are true.

component
#A fails
G11

AND-gate

G7

with or without description box :

loss of
Function
'B'
G4

For internal use only

Continental AG

Boolean logic gate - output event of this gate occurs

when all the input events are true.

G14

Page 6 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01

Configuration
event

Pseudo-event which describes a configuration or

operating condition that is true or false.
Configuration events can be used to include or
exclude parts of a fault tree.

specific
operating
conditions
cond-01

Subtree
transfer

Transfer-in :

Transfer-out :
{2}

incorrect
operation of
Function 'C'
{2}

Indicates transfer of information between subtrees:

- transfer-in: event is developed in another subtree
(e.g. {2}),
- transfer-out: top of the corresponding subtree.

incorrect
operation of
Function 'C'
G5

Identical
transfer

Top of subtree :

Replication :

{1}
component
#A fails

Indicates transfer of information between subtrees:

It enables multiple replications of a given subtree
and can be used to designate a common cause
event.

{1}

component
#A fails
G11

More sophisticated graphic symbols may be used whenever necessary1 such as:
Exclusive-OR gate: type of logical disjunction on two operands that results in a output of true if exactly one of
the operands has a value of true
NOT gate: Output event is an inverse of the input event. NOT gate associated with AND gate becomes NAND
while associated with OR gate it becomes a NOR gate.
'M out of N' gate: Output of this gate occurs if at least M of the N input events are true

The basic rule is "keep it simple for understandability purpose".

For internal use only

Continental AG

Page 7 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01
2.2

General Hints on FTA Usage

Starting with the top event, this top-down process consists in systematically determining all foreseeable singlecauses or multiple-causes that could lead to it. The analysis proceeds down through successively more detailed
(lower) levels of the system design until primary events (root causes) are identified. The resulting Fault Tree
Diagram is then evaluated.

Criteria for the decision to use FTA are (not limited to):

Demand from the customer for using the FTA method,

Specific safety requirements from the customer (e.g. no runaway),

Identification of particular hazard(s) or undesired event(s) related to innovative function of systems,

High potential for FTA reuse from similar existing systems.

Identification of cause and effect or failure cascades in system architecture

For internal use only

Continental AG

Page 8 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01
3

Further Definitions

3.1

Acronyms

EMS
ETA
PMHF

Engine Management System

Event Tree Analysis
Probabilistic Metric for random Hardware Failures

ETC

Electronic Throttle Control

FTA

Fault Tree Analysis

FMEA

Failure Mode and Effects Analysis

H&RA

Hazard & Risk Analysis

3.2

Definitions

Common cause event:

Event, which provokes a failure and causes at the same time the associated protection
mechanism(s) to be inoperative.
Cutset:

Set of primary events, which (may) cause the top event to happen when occurring together.

st

Cutset consisting of a unique primary event.

nd

Cutset consisting of two primary events.

th

N order cutset:

Cutset consisting of N primary events.

Minimal cutset:

Smallest cutset in which all primary events must occur for the top event to occur. Usually, from
st
safety viewpoint, it is not recommended to keep 1 order cutset(s) as minimal cutset: it means
that single-point failure(s) exists that leads directly to the undesired top-level event.

1 order cutset:
2 order cutset:

Hazard Analysis and Risk Analysis:

Comprehensive examination that aims at identifying and classifying hazardous events related
to system functions according to their severity.
Primary event:
Event which has not to be further developed for the purpose of the analysis, i.e. it represents a
root cause which does not need to be broken down to a finer level of detail. A primary event
may be internal or external to the system under analysis and can be attributed to hardware
random faults and hardware or software development errors.
More generally, primary events can be attributed to system, sub-system or component
failures, human mistakes, environmental adverse conditions, inadequate processes or
procedures, etc.
Undesired top-level event (or top event):
Starting point and focus of the entire FTA. Top events are generally related to the inability of a
system to meet performance, economical, safety requirements or other key characteristics.
Qualitative evaluation:
The qualitative evaluation produces cutsets, which are used to determine the qualitative
importance of primary events in the occurrence of the top event and to evaluate vulnerability to
common cause events.
Quantitative evaluation:
FTA evaluation is mainly qualitative. It may also be complemented by quantitative evaluation depending on specific
conditions. The purpose of quantitative evaluation is to estimate the probability of occurrence of the top event or a
selected set of intermediate events. For that, probabilistic data are required. Reliability and availability prediction
techniques, actual test or field use data may be used to establish the quantitative value.

For internal use only

Continental AG

Page 9 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01

The following Fault Tree is intended to be used as an example. It has been drawn using the software tool ARALIA
WORKSHOP - SIMTREE. Symbols in the tool FaultTree+ are different.

3.3

Example of Fault Tree Diagram

undesired
top-level
event
G00

ORed events
no operation of
Function 'A' on
demand

loss of
Function
'B'

incorrect
operation of
Function 'C'

G9

G4

{2}

event developed
in subtree {2}

specific
operating
conditions

component
#B1 fails

component
#B2 fails

'B' backup
fails

comp-B1

comp-B2

G3

ANDed events

cond-01

{1}

component
#A fails

component
#B3 fails

component
#A fails

comp-B3

{1}

subtree {1}
replication

G11

SW design
error

G14

HW design
error

single-point root causes

(only when specific
conditions are met)

comp-A/01
comp-A/02
HW random
fault
comp-A/03

HW
monitoring
inoperative
comp-A/04

For internal use only

Continental AG

fail-safe
structure

H/W and S/W

safety-related
items

Page 10 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01

{2}

Top of subtree {2}

development

incorrect
operation of
Function 'C'
G5

G7

protection
mechanism #D
inoperative

fail-safe
structure

G6
component
#C fails

other
causes

G2

comp-C

part #x
fails

part #z
fails

part-x

part-z

G13

no timely
detection by
#D

potential common
cause failure

prot-D/01
erroneous
control by
operator

incorrect
system
reaction after
detection

G16

human and
process issues

G8

For internal use only

Continental AG

part #y
fails

part #z
fails

other
causes

part-y

part-z

prot-D/02

human
error

inadequate
procedure

human-D

proc-D

Page 11 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01

3.4

Example of Primary Events Dictionary

A dictionary of this type can be built from results computed by the tool. While the "Remarks" column can be used to
define more precisely each primary event, the last column is intended to bound the scope of analysis under
CONTINENTAL Automotive responsibility.
ID
human-D
comp-A/01
comp-A/02
comp-A/03
comp-A/04
comp-B1
comp-B2
comp-B3
comp-C

Primary events
human error
SW design error
HW design error
HW random fault
HW monitoring inoperative
component #B1 fails
component #B2 fails
component #B3 fails
other causes

Remarks

Responsibility

ID
part-x
part-y
part-z
proc-D
prot-D/01
prot-D/02

Primary events
part #x fails
part #y fails
part #z fails
inadequate procedure
no timely detection by #D
other causes

Remarks

Responsibility

3.5

Example of Qualitative Evaluation

Twice the tool has computed the following cutsets. The first column lists the cutsets when cond-01 is true and the
last column when it is false:
Presence of specific operating conditions Absence of specific operating conditions
st
1 order cutsets : comp-A/01 SW design error
comp-A/02 HW design error
nd
2 order cutsets : comp-A/03 HW random fault
comp-A/04 HW monitoring inoperative
prot-D/01
no timely detection by #D
prot-D/01
no timely detection by #D
comp-C
other causes
comp-C
other causes
prot-D/01
no timely detection by #D
prot-D/01
no timely detection by #D
part-x
part #x fails
part-x
part #x fails
prot-D/01
no timely detection by #D
prot-D/01
no timely detection by #D
part-z
part #z fails
part-z
part #z fails
human-D
human error
human-D
human error
part-z
part #z fails
part-z
part #z fails
part-z
part #z fails
part-z
part #z fails
proc-D
inadequate procedure
proc-D
inadequate procedure

For internal use only

Continental AG

Page 12 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01
rd

3 order cutsets : comp-B1

comp-B2
comp-B3

human-D
comp-C
part-y
comp-C
part-y
proc-D
prot-D/02
human-D
comp-C
prot-D/02
comp-C
proc-D
human-D
part-x
part-y
part-x
part-y
proc-D
prot-D/02
human-D
part-x
prot-D/02
part-x
proc-D
th

4 order cutsets :

For internal use only

Continental AG

component #B1 fails

component #B2 fails
component #B3 fails

human error
other causes
part #y fails
other causes
part #y fails
inadequate procedure
other causes
human error
other causes
other causes
other causes
inadequate procedure
human error
part #x fails
part #y fails
part #x fails
part #y fails
inadequate procedure
other causes
human error
part #x fails
other causes
part #x fails
inadequate procedure

comp-B1
comp-B2
comp-B3
comp-A/01
comp-B1
comp-B2
comp-A/02
comp-B1
comp-B2
human-D
comp-C
part-y
comp-C
part-y
proc-D
prot-D/02
human-D
comp-C
prot-D/02
comp-C
proc-D
human-D
part-x
part-y
part-x
part-y
proc-D
prot-D/02
human-D
part-x
prot-D/02
part-x
proc-D
comp-A/03
comp-A/04
comp-B1
comp-B2

component #B1 fails

component #B2 fails
component #B3 fails
SW design error
component #B1 fails
component #B2 fails
HW design error
component #B1 fails
component #B2 fails
human error
other causes
part #y fails
other causes
part #y fails
inadequate procedure
other causes
human error
other causes
other causes
other causes
inadequate procedure
human error
part #x fails
part #y fails
part #x fails
part #y fails
inadequate procedure
other causes
human error
part #x fails
other causes
part #x fails
inadequate procedure
HW random fault
HW monitoring inoperative
component #B1 fails
component #B2 fails

Page 13 of 14
Template: CAP0103001-F02-02

Automotive
CAM0500244-01
4

References

4.1

Mandatory

/1/ CAPM
4.2

Other

CAP0500131 FSM-Guideline

CAP0500032 FMEA

CAM0500176 Quantified Safety Analysis

ISO 26262

Document History

Rev. #
01

Conti Automotive Process Management

Change Description
First version

Process
Owner

Date

Hans-Leo
Ross

30.11.2010

(dd.mm.yyyy)

02
03

6
6.1

Responsible Persons
Process Owner

Hans-Leo Ross

6.2

Process Manager

Jean-Marc Astruc supported by Safety Manager in BUs.

6.3

Process Team

The members of the Process Team have reviewed the method and their feedback has been considered.
The Process Owner keeps records about the Review.
Name
Department
Location
Dieter Strohmeier
Quality ES
Regensburg
Paolo Pedri
Quality Automotive
Auburn Hills
Dieter Knoedler
BU SEN
Frankfurt
Uwe Kley
BU HBS CHTBK
Frankfurt
Thomas Hmmrich, Jrg Steinmetz, Karl-Heinz Henne,
BU TR
Nrnberg
Wolfgang Spengler
Peter Lascych
BU HEV
Nrnberg
Masao Chiba
R&D EBS
Nakaze, Japan
Dr. Harald Luetteke, Sandro Syguda
BU C&S, S&T
Frankfurt
Thomas Gbel
BU EBS
Frankfurt
Christian Brand
BU B&S
Regensburg
Dieter Brasin
C&S PSAD
Regensburg
Tom Eibergen
C&S S&T
Auburn Hills
Habel Stephan
BU CHS
Nrnberg
Dr. Eva Schwarze, H.-A. Schneider
BU HBS EPB
Frankfurt

For internal use only

Continental AG

Page 14 of 14
Template: CAP0103001-F02-02