TABLE OF CONTENTS

FOREWORD ....................................................................................................................................................... 4
ACKNOWLEDGEMENTS ...................................................................................................................................... 5
TABLE OF CONTENTS .......................................................................................................................................... 8
1 INTRODUCTION .............................................................................................................................................. 15
·,
1.1 PURPOSE ANO DESCRIPTION .....................................................................................................................................15
1.2 0BJECTIVES ANO LIMITS OF FMEA ............................................................................................................................ 16
1.3 INTEGRATION OF FMEA IN THE COMPANY ..................................................................................................................17
1.3.1 Potentia/ Considerations of the FMEA ....................................................................................................... 17
1.3.2 Senior Management Commitment............................................................................................................. 18
1.3.3 Know-How Protection of the Design FMEA/Process FMEA ........................................................................ 18
1.3.4 Agreements between Customers and Suppliers ......................................................................................... 18
1.3.5 Transition Strategy ..................................................................................................................................... 19
1.3.6 Foundation and Family FMEAs ................................................................................................................... 19
1.4 FMEA FOR PROOUCTS ANO PROCESSES ...................................................................................................................... 20
1.4.1 Design FMEA .............................................................................................................................................. 21
1.4.2 Process FMEA ............................................................................................................................................. 21
1.4.3 Collaboration between FMEAs ................................................................................................................... 22
1.5 PROJECT PLANNING ................................................................................................................................................ 23
1.5.1 FMEA lnTent ............................................................................................................................................... 23
1.5.2 FMEA Timing ............................................................................................................................... ...............23
1.5.3 FMEA Team ................................................................................................................................................ 25
1.5.4 FMEA Tasks ................................................................................................................................................ 28
1.5.5 FMEA Tools ................................................................................................................................................ 28
1.6 FMEA METHODOLOGY.......................................................................................................................................28

2 EXECUTION OF THE DESIGN FMEA .................................................................................................................. 31

2.1 DESIGN FMEA 1ST STEP: PLANNING ANO PREPARATION ............................................................................................... 31
2.1.1 Purpose ...................................................................................................................................................... 31
2.1.2 DFMEA Project ldentification and Boundaries ........................................................................................... 31
2.1.3 DFMEA Project Plan ................................................................................................................................... 32
2.1.4 Jdentification of the Baseline DFMEA......................................................................................................... 32
2.1.5 DFMEA Header ........................................................................................................................................... 33
2.1.6 Basis for Structure Analysis ........................................................................................................................ 33
2.2 DESIGN FMEA 2NO STEP: STRUCTURE ANALYSIS ......................................................................................................... 34
2.2.1 Purpose ...................................................................................................................................................... 34
2.2.2 System Structure ........................................................................................................................................34
2.2.3 Define the Customer .................................................................................................................................. 34
2.2.4 Visualize System Structure ......................................................................................................................... 35
2.2.5 Col/aboration between Customer and Supplier ......................................................................................... 40
2.2..6 Basis for Function Analysis ......................................................................................................................... 40
2.3 DESIGN FMEA 3RO STEP: FUNCTION ANALYSIS ........................................................................................................... 40
2.3.1 Purpose ............................................................................................................................... ....................... 40
2.3.2 Function ............................................................................................................................... ......................41
2.3.3 Requirements ............................................................................................................................... ..............41
2.3.4 Parameter Diagram (P-Diagram) ............................................................................................................... 42
2.3.5 Function Analysis .......................................................................................................................................45

-8-
 produce products which conform to design intent. Process-related
failures are different than the failures analyzed in the Design
FMEA.
The Process FMEA analyzes processes by considering the
potential failure modes which may result from process variation, to
establish priority of actions for prevention, and as needed,
improve controls. The overall purpose is to analyze processes and
take action prior to production start, to avoid unwanted defects
related to manufacturing and assembly and �he consequences of
those defects.

1.4.3 Collaboration between FMEAs

There are opportunities for collaboration between both Design and
Process FMEAs in the same company and outside of the
company. To help communicate effects and severities, a joined
and agreed to severity evaluation can be reviewed between
organizations (different companies in the supply chain starting
with Tier 1, Tier 2, Tier 3, etc.) as shown in Figure 1.4-1.

Goal: Risk to End User reduced

Failure Effects and

Severity
Customer
(as possible / as needed)

l
Tier n

Technical risk analysis and

Tier (n + 1)
proposed product or process
changes
(as possible / as needed)
Goal: Collaboration between Customer and Supplier

Figure 1.4-1 FMEA Collaboration

- 22 -
 A functional requirement is a criterion by which the intended
performance of the function is judged or measured (e.g., material
stiffness).
A non-functional requirement is a limitation on the freedom for
design decision (e.g., temperature range).
Requirements may be derived from various sources, externa! and
interna!, these could be:
Legal requirements:
• Environmentally friendly product design, suitable for recycling,
safe in the event of potential misuse by the operator, non­
flammable, etc.
lndustry Norms and Standards:
• ISO 9001, VDA Volume 6 Part 3, Process audit, SAE J1739,
ISO 26262 Functional Safety.
Customer Requirements:
• Explicit (i.e., in customer specification) and implicit (i.e.
freedom from prohibited materials)- under all specified
conditions
Interna! Requirements:
• Product Specific (i.e., Requirements Speciftcations,
manufacturability, suitability for testing, compatibility with
other existing products, reusability, cleanliness, generation,
entry and spreading of particles)
Product Characteristics:
• A distinguishing feature (or quantifiable attribute) of a product
such as a journal diameter or surface ftnish.

2.3.4 Parameter Diagram (P-Diagram)

Parameters are considered to be attributes of the behavior of a
function. A Parameter (P) Diagram is a graphical representation of
the environment in which an item exists. A P-Oiagram includes
factors which influence the transfer function between inputs and
outputs, focusing on design decisions necessary to optimize
output.
A P-Diagram is used to characterize the behavior of a system or
component in the context of a single function. P-Oiagrams are not
required for all functions. Teams should focus on a few key
functions affected by new conditions and those with history of
robustness issues in previous applications. More than one P­
Diagram may be needed in arder to illustrate the function(s) of the
system or component that are of concern to the FMEA Team.

- 42-
 The complete functional description forms the basis for
subsequent failure analysis and risk mitigation.
A P-Diagram focuses on achievement of function. lt clearly
identifies ali influences on that function including what can be
controlled (Control Factors), and what cannot reasonably be
controlled (Noise Factors).
The P-Diagram, completed for specific Ideal Functions, assists in
the identification of:
• Factors, levels, responses and signals necessary for system
optimization
• Functions which are input� to the DFMEA
• Control and Noise factors which could affect functional
performance
• Unintended system outputs (Diverted Outputs)
lnformation gained through developing a P-Diagram provides
input to the test plan.
Referring to Figure 2.3-2 below, the output (grey area) of the ltem/
System Element often deviates/varies from the desired behavior
(straight line). The control factors act on the design to achieve as
close as practica! to the desired behavior.

Ideal/Actual vs. OESIRED/REQUIRED Functional Definition

(Linear Response Example)
Customer and/or other systems determine
to level of acceptable (Desired/Required)
functional performance of a commodity

Input "X"
Convert
X to Y I
I
I
I

I
I
I
Y= output I

X= input

Figure 2.3-2 Example of system behavior

-43 -
 A Parameter Diagram consists of dynamic inputs (including
signals), factors that could affect system performance (control and
noise), sources of variation, and outputs (intended outputs and
unintended/diverted outputs ).
The following is an example of a Parameter Diagram which is
used to assess the influences on a function of a product including:
Input (What you want to put in to get the desired result) is a
description of the sources required for fulfilling the system
functionality.
Function (What you want to happen) is described in a Parameter
Diagram with an active verb followed by a measurable noun in the
present tense and associated with requirements.
Functional Requirements (What you need to make the function
happen) are related to the performance of a function
Control Factors (What you can do to make it happen) which can
be adjusted to make the design more insensitive to noise (more
robust) are identified. One type of Control Factor is a Signa!
Factor. Signal Factors are adjustment factors, set directly or
indirectly by a user of a system, that proportionally change the
system response (e.g., brake pedal movement changes stopping
distance). Only dynamic systems utilize signal factors. Systems
without signal factors are called static systems.
Non-Functional Requirements (What you need beside the
functional requirements) which limit the design option.
lntended Output (What you want from the system) are ideal,
intended functional outputs whose magnitude may (dynamic
system) or may not (static system) be linearly proportional to a
signal factor (e.g., low beam activation for a headlamp, stopping
distance as a function of brake pedal movement).
Unintended Output (What you don't want from the system) are
malfunctioning behaviors or unintended system outputs that divert
system performance from the ideal intended function. For
example, energy associated with a brake system is ideally
transformed into friction. Heat, noise and vibration are examples
of brake energy diverted outputs. Diverted Outputs may be losses
to thermal radiation, vibration, electrical resistance, flow
restriction, etc.
Noise Factors (What interferes with achieving the desired output)
are parameters which represent potentially significant sources of
variation for the system response and cannot be controlled or are
not practica! to control from the perspective of the engineer.
Noises are described in physical units.
N9ise factors are categorized as follows:
• Piece to Piece Variation
(in a component and interference between components)

-44

Noise Factors
Noise 1 Noise 2
Piece to Piece Variation Change Over Time
e.g., variation In clearance
between rotor and holding
clamps
Input
Energy:
e.g., Voltage, Current
Function
Convert elec!Jical energy
lnto mechan lcal energy
acc. to parameterization
Requirement
Generate motor
characterlstlc curve acc.
to spec 6790-1323
Figure 2.3-3 Example of Parameter Diagram with Electrical Motor
• Change Over Time
(aging over life time, e.g., mileage, aging, wear)
• Customer Usage
(use out of desired specifications)
• Externa! Environment
(conditions during customer usage, e.g., road type, weather)
• System lnteractions
(interference from other systems)
Noise 3 Noise4 Noise 5
Customer Usage Externa!
e.g.• holding clamps e.g .. excessive use or Environment System lnteractions
become permanently window lift system by child e.g., electromagnelic
e.g.. humidity,
magneti:zed, carbon playing inlerference fro¡n ECU
temperature, dust. extemal
brushes wear vibralion, shock, ...
Window Lifter Motor lntended Output
Energy:
�f8:t Enqy e.g., angle dependent
-- - M,w electrlcal energy on
-----·-
IE-vY - ---- ► solenold
rbr-=�
. • Unintended
·-;;;-�- output
Functional Control Factors Non Functional Unintended Output
Requirements Natural scientific factors Requirements energy !osses,
which control the function, Requirements which limit e.g .• thermal energy,...
Move wlndow glass up
e.g., magnetic field the design options, NVH, EMC
and down with a defined
velocity strength, permeability, ... e.g., geometric interface to
customer system.
requirements regarding
weight, material, size, ...
2.3.5 Function Analysis
The interactions of the functions of severa! System elements are
to be demonstrated, for example as a function tree/network, or
using the DFMEA form sheet. The focus of the analysis cascades
from OEM to Tier 1 supplier to Tier N supplier.
The purpose of creating a function tree/network or function
analysis on the DFMEA form sheet is to incorporate the technical
dependency between the functions. Therefore, it subsequently
supports the visualization of the failure dependencies. When there
is a functional relationship between hierarchically linked functions,
-45-
 then there is a potential relationship between the associated
failures. Otherwise, if there is no functional relationship between
hierarchically linked functions, there will also be no potential
relationship between the associated failures.
For the preparation of the function tree/network, the functions that
are involved need to be examined. Sub-functions enable the
performance of an overall function. AII sub-functions are linked
logically with each other in the function structure (Boolean AND­
relationships).
A function structure becomes more detailed from top down. The
lower level function describes how the higher level function is to
be fulfilled. For the logical linking of a function structure, it is
helpful to ask:
• "How is the higher level function enabled by lower level
functions?" (Top-Down) and
• "Why is the lower level function needed?" (Bottom-Up).

Brush Card Base Bocty

Window Lifter Motor
Functlon:
Convert electrical energy into /
mechanical energy ■ce. to
paremetarizetion
Functlonal Requlrements:
Move window glau up and
Function:
B,ush card body tran11 ports torc8'
/ between sprlng and motor body 10 hold
lh& brush sprlng syslem In x , y , 1 posltlon
/ ( support commutatlng contact poi ni)
Cornmutatlon Systam / C..rbon Brush
Functlon: FunctJon:
¡ Commutatlon system tren,ports the ~ Carbon bru11h transports electrical
/1 eleclrlcal curren! betw"n coll palrs ol \
current betw11■n carbon 11trended wire
th• electro magnetlc converter and commutator surface
\
Brush Card Ben Body
FunctJon: ...
/
Carbon Brush
,, Electromagnetic convartar 1 Functlon: ...
Functlon:
Electro-magnatic converter transforma II

◄_yJ:fol•t•1liil•t•il
_,."', . ........,.�
down with a deflned velocity the electrlc field into angla-dependen! Brush Card Bue Bocty
Functlon: .••

�
Figure 2.3-4 Example of Function Analysis Structure Tree

-46
 The function structure can be created in the Function Analysis
section:

FUNCTION ANALYSIS (STEP 3)

1. Next Higher Level 2. Focus Element

3. Next Lower Level Function and
Function and Function and
Requirement or Characteristic
Requirement Requirement

Commutation system
Convert electrical Brush card body transports forces
transports the electrical
energy into between spring and motor body to hold
current between coil
mechanical energy the brush spring system in x, y, z
pairs of the
according to position (support commutating contact
electromagnetic
parameterization point)
converter

Figure 2.3-5 Example of Function Analysis Form Sheet

The column header numbering (1, 2, 3) and color coding are
included to help show alignment between the Structure Analysis
and associated content of the Function Analysis (see figure 2.3-5).
In this section you work from left to right answering the question:
"How is the higher level function enabled by lower level
funttions?"
1. Next Higher Level Function and Requirement:
The function in scope of the Analysis.
2. Focus Element Function and Requirement:
The function of the associated System Element (item in focus)
identified in the Structure Analysis.
3. Next Lower Level Function and Requirement or Characteristic:
The function of the associated Component Element identified
in the Structure Analysis.

2.3.6 Collaboration between Engineering Teams (Systems,

Safety, and Components)
Engineering teams within the company need to collaborate to
make sure information is consistent for a project or customer
program especially when multiple DFMEA teams are
simultaneously conducting the technical risk analysis. For
example, a systems group might be developing the design
architecture (structure) and this information would be helpful to the
DFMEA to avoid duplication of work. A safety team may be
working with the customer to understand the safety goals and
hazards. This information would be helpful to the DFMEA to
ensure consistent severity ratings for failure effects.

-47 -
4 SUPPLEMENTAL FMEA FOR MONITORING AND
SYSTEM RESPONSE (FMEA-MSR)
In a Supplemental FMEA for Monitoring and System Response,
potential Failure Causes which might occur under customer
operating conditions are analyzed with respect to their technical
effects on the system, vehicle, people, and regulatory compliance.
The method considers whether or not Failure Causes or Failure
Modes are detected by the system, or Failure Effects are detected
by the driver. Customer operation is to be understood as end-user
operation or in-service operation and maintenance operations.
FMEA-MSR includes the followiñg elements of risk:
a) Severity of harm, regulatory noncompliance, loss or
degraded functionality, and unacceptable quality;
represented by (S)
b) Estimated frequency of a Failure Cause· in the context of
an operational situation; represented by (F)
c) Technical possibilities to avoid or limit the Failure Effect via
diagnostic detection and automated response, combined
with human possibilities to avoid or limit the Failure Effect
via sensory perception and physical reaction; represented
by (M }
The combination of F and M is an estímate of the probability of
occurrence of the Failure Effect due to the Fault (Failure Cause)
and resulting malfunctioning behavior (Failure Mode).
NOTE: The overall probability of a Failure Effect to occur may be
higher, because different Failure Causes may lead to the
same Failure Effect.
FMEA-MSR adds value by assessing risk reduction as a result of
monitoring and response. FMEA-MSR evaluates the current state
of risk of failure and derives the necessity for additional monitoring
by comparison with the conditions for acceptable residual risk.
The analysis can be part of a Design FMEA in which the aspects
of Development are supplemented by aspects of Customer
Operation. However, it is usually only applied when diagnostic
detection is necessary to maintain safety or compliance.
Detection in DFMEA is not the same as Monitoring in
Supplemental FMEA-MSR. In DFMEA, Detection controls
document the ability of testing to demonstrate the fulfillment of
requirements in development and validation. For monitoring that is
already part of the system design, validation is intended to
demonstrate that diagnostic monitoring and system response
works as intended. Conversely, Monitoring in FMEA-MSR
assesses the effectiveness of fault detection performance in
customer operation, assuming that specifications are fulfilled. The

- 125 -
 Monitoring rating also comprehends the safe performance and
reliability of system reactions to monitored faults. lt contributes to
the assessment of the fulfíllment of Safety Goals and may be used
for deriving the Safety Concept.
Supplemental FMEA-MSR addresses risks that in DFMEA would
otherwise be assessed as High, by considering more factors
which accurately reflect lower assessed risk according to the
diagnostic functions of the vehicle operating system. These
additional factors contribute to an improved depiction of risk of
failure (including risk of harm, risk of noncompliance, and risk of
not fulfilling specifications).
FMEA-MSR contributes to the provision of evidence of the ability
of the diagnostic, logical, and actuation mechanisms to achieve
and maintain a safe or compliant state (in particular, appropriate
failure mitigation ability within the maximum fault handling time
interval and within the fault tolerant time interval).
FMEA-MSR evaluates the current state of risk of failure under end
user conditions (not just risk of harm to persons). The detection of
faults/failures during customer operation can be used to avoid the
original failure effect by switching to a degraded operational state
(including disabling the vehicle), informing the driver and/or writing
a diagnostic trouble code (DTC) into the control unit for service
purposes. In terms of FMEA, the result of RELIABLE diagnostic
detection and response is to eliminate (prevent) the original effect,
and replace it with a new, less severe effect.
FMEA-MSR is useful in deciding whether the system design fulfills
the performance requirements with respect to safety and
compliance. The results may include items such as:
• additional sensor(s) may be needed for monitoring purposes
• redundancy in processing may be needed
• plausibility checks may reveal sensor malfunctions

4.1 FMEA-MSR 1 st Step: Planning and Preparation

4.1.1 Purpose
The main objectives of Planning and Preparation in FMEA-MSR
are:
• Project identification
• Project plan (lnTent, Timing, Team, Tasks, Tools (5T))
• Analysis boundaries: What is included and excluded from the
analysis
• ldentification of baseline FMEA
• Basis for the Structure Analysis step

- 126 -
4.1.2 FMEA-MSR Project ldentification and Boundaries
FMEA-MSR project identification includes a clear understanding of
what needs to be evaluated. This involves a decision-making
process to define the FMEA-MSRs that are needed for a customer
program. What to exclude can be just as important as what to
include in the analysis.
The following may assist the team in defining FMEA-MSR
projects, as applicable:
• Hazard Analysis and Risk Assessment
• Legal Requirements
• Technical Requirements
• Customer wants/needs/expectation (externa! and interna!
customers)
• Requirements specification
• Diagrams (Block/Boundary/System)
• Schematics, Drawings, and/or 30 Models
• Bill of Materials (BOM), Risk Assessment
• Previous FMEA for similar products
Answers to these questions and others defined by the company
help create the list of FMEA-MSR projects needed. The FMEA­
MSR project list assures consistent direction, commitment and
focus.

Below are sorne basic questions that help identify FMEA-MSR

boundaries:
(1) After completing a DFMEA on an
Electrical/Electronic/Programmable Electronic System, are
there effects that may be harmful to persons or involve
regulatory noncompliance?
(2) Did the DFMEA indicate that ali of the causes which lead
to harm or noncompliance can be detected by direct
sensing, and/or plausibility algorithms?
(3) Did the DFMEA indicate that the intended system
response to any and all of the detected causes is to switch
to a degraded operational state (including disabling the
vehicle), inform the driver and/or write a Diagnostic Trouble
Code (DTC) into the control unit for service purposes?
FMEA for Monitoring and System Response may be used to
examine systems which have integrated fault monitoring and
response mechanisms during operation. Typically, these are more
complex systems composed of sensors, actuators and logical
processing units. The diagnosis and monitoring in such systems
may be achieved through hardware and/or software.
- 127 -
 Systems that may be considered in a Supplemental FMEA for
Monitoring and System Response consist in general of at least a
sensor, a control unit, and an actuator or a subset of them and are
called mechatronic systems. Systems in-scope may also consist
of mechanical hardware components (e.g., pneumatics and
hydraulics ).

Data Data
Voltage Voltage
Current Current
Sensor Electronic Control Unit Actuator

Figure 4.1-1 Generic block diagram of an Electrical / Electronic / Programmable

Electronic System

The scope of a Supplemental FMEA for Monitoring and System

Response may be established in consultation between customer
and supplier. Applicable scoping criteria may include, but are not
limited to:
1. System Safety relevance
2. ISO Standards, i.e., Safety Goals according to ISO 26262
3. Documentation requirements from legislative bodies, e.g.
UN/ECE Regulations, FMVSS/CMVSS, NHTSA, and On
Board Diagnostic Requirements (OBD) Compliance.

4.1.3 FMEA-MSR Project Plan

A plan for the execution of the FMEA-MSR should be developed
once the FMEA-MSR project is known.
lt is recommended that the 5T method (lntent, Timing, Team,
Tasks, Tool) be used as described in section 1.5 of this handbook.
The plan for the FMEA-MSR helps the company be proactive in
starting the FMEA-MSR early. The FMEA-MSR activities (7-step
process) should be incorporated into the overall design project
plan.

- 128 -
4.2 FMEA-MSR 2nd Step: Structure Analysis
4.2.1 Purpose
The main objectives of Structure Analysis in FMEA-MSR are:
• Visualization of the analysis scope
• Structure tree or equivalent: block diagram, boundary
diagram, digital model, physical parts
• ldentification of design interfaces, interactions
• Collaboration between customer and supplier engineering
teams (interface responsibilities)
• Basis for the Function Analysis step
Depending on the scope of analysis, the structure may consist of
hardware elements and software elements. Complex structures
may be split into severa! structures (work packages) or different
layers of block diagrams and analyzed separately for
organizational reasons or to ensure sufficient clarity.
The scope of the FMEA-MSR is limitad to the elements of the
system for which the baseline DFMEA showed that there are
causes of failure which can result in hazardous or noncompliant
effects. The scope may be expanded to include signals received
by t�e control unit.
In order to visualiza a system structure, two methods are
commonly used:
• Block (Boundary) Diagrams
• Structure Trees
For more details, refer to Section 2.2 Design FMEA

4.2.2 Structure Trees

In a Supplemental FMEA for Monitoring and System Response,
the root element of a structure tree can be at vehicle level, i.e. for
OEMs which analyze the overall system (see Figure 4.2-1) or at
the system level, i.e. for suppliers which analyze a subsystem or
component (see Figure 4.2-2).

<
Root element at vehicle level
Connector ECU Window Ufter
Electronic Control Unit
Window Lift System
Window Lifter Interface within the ECU Window
Lifter

Figure 4.2-1 Example of a structure tree of a window lift system for investigating
erroneous signals, monitoring, and system response

- 129 -
 The sensor element and the control unit may also be part of one
component (smart sensor). Diagnostics and monitoring in such
systems may be realized by hardware and/or software elements.
,-----------------------------------------,
.---- ---, ----
1 Root element at system level 1
Elements of Smart Sensor 1
Data Processing Unit '
Connector (Output)
of Smart Sensor
'
' OEM, :
Connector (Input)
; Suppliers;
Manofacturerl 1 L- -- - - _1
'-----------------------------------------�

r Root elemental vehicle leve!

:
�-----�
Elements of Actuator
Data Processing Unit
Vehicle
of Actuator
1 Connector (Input)
1 '-------------' 1
Manufacturer 2
L-----------------------------------------1

Figure 4.2-2 Example of a structure tree of a smart sensor with an interna! sensing
element and output to an interface

In case there is no sensor within the scope of analysis, an

Interface Element is used to describe the data/current/voltage
received by the ECU. One function of any ECU is to receive
signals via a connector. These signals can be missing or
erroneous. With no monitoring, you get erroneous output.
In case there is no actuator within the scope of analysis, an
Interface Element is used to describe the data/current/voltage sent
by the ECU. Another function of any ECU is to send signals, i.e.
vía a connector. These signals can also be missing or erroneous.
lt can also be "no output" or "failure information."
The causes of erroneous signals may be within a component
which is outside the scope of responsibility of the engineer or
organization. These erroneous signals may have an effect on the
performance of a component which is within the scope of
responsibility of the engineer or organization. lt is therefore
necessary to include such causes in the FMEA-MSR analysis.
NOTE: Ensure that the structure is consistent with the Safety
Concept (as applicable).

1------------STRUCTURE ANALYSIS (STEP...---------------1

2)
3. Next Lower Level or
1. Next Higher Level
Characteristic Type
Window Lift S stem Connector ECU Window Lifter

Figure 4.2-3 Example of Structure Analysis in the FMEA-MSR Form Sheet

- 130 -
4.3 FMEA-MSR 3rd Step: Function Analysis
4.3.1 Purpose
The main objectives of Function Analysis in FMEA-MSR are:
• Visualization of functions and relationships between functions
• Function tree/ function net, or equivalent parameter diagram
(P-diagram)
• Cascade of customer (externa! and interna!) functions with
associated requirements
• Association of requirements or characteristics to functions
• Collaboration between engineering teams (systems, safety,
and components)
• Basis far the Failure Analysis step
In a Supplemental FMEA far Monitoring and System Response,
monitoring for failure detection and failure responses are
considered as functions. Hardware and software functions may
include monitoring of system states.
Functions for monitoring and detection of faults/failures may
consist of, far example: out of range detections, cyclic redundancy
checks, plausibility checks and sequence counter checks.
Functions far failure reactions may consist of, far example,
provision of default values, switching to a limp home mode,
switching off the corresponding function and/or display of a
warning.
Such functions are modeled for those structural elements that are
carriers of these functions, i.e., control units or components with
computational abilities like smart sensors.
Additionatly, sensor signals can be considered which are received
by control units. Therefore, functions of signals may be described
as well.
Finally, functions of actuators can be added, which describe the
way the actuator or vehicle reacts on demand.
Performance requirements are assumed to be the maintenance of
a safe or compliant state. Fulfillment of requirements is assessed
through the risk assessment.
In case sensors and/or actuators are not within the scope of
analysis, functions are assigned to the corresponding interface
elements (consistent with the Safety Concept-as applicable).

- 131 -
 Connector ECU Window Lifter
Funct/on:

<
Transmit signal from Hall effect sensor to ECU
Electronic Control Unit Window Lifter Transmit signal from electric motor to ECU
Window Lift System
Function: Transmit power supply
Function:
Provide signal to stop and reverse
Provide anti-pinch protection
window lifter motor in case of pinch Interface within the ECU Window Lifter
for comfort closing mode
situation Functlon:
Transmit status signals of ECU components

Figure 4.3-1 Example of a Structure Tree with functions

�-----------FUNCTION ANALYSIS (STEP 3)

. Next Lower Level Functlon
1. Next Higher Level Function
and Requlrernent or
and Requirement
Characteristic

Provide signal to stop and

Provide anti-pinch protection for Transmit signal from Hall
reverse window lifter motor in
comfort closing mode effect sensor to ECU
case of pinch situation

Figure 4.3-2 Example of Function Analysis in FMEA-MSR Form Sheet

4.4 FMEA-MSR 4th Step: Failure Analysis

4.4.1 Purpose
The purpose of Failure Analysis in FMEA-MSR is to describe the

'
chain of events which lead up to the end effect, in the context of a
relevant scenario.
The main objectives of Failure Analysis in FMEA-MSR are:
• Establishment of the failure chain
• Potential Failure Cause, Monitoring, System Response,
Reduced Failure Effect
• ldentification of product Failure Causes using a parameter
diagram or failure network
• Collaboration between customer and supplier (Failure Effects)
• Basis for the documentation of failures in the FMEA form
sheet and the Risk Analysis step

4.4.2 Failure Scenario

A Failure Scenario is comprised of a description of relevant
operating conditions in which a fault results in malfunctioning
behavior and possible sequences of events (system states) that
lead to an end system state (Failure Effect). lt starts from defined
Failure Causes and leads to the Failure Effects. (See Figure 4.4-
1)

- 132 -
 Mitigated System
1

<{
Failure Effect Response
w
� Can the
failure be
detected in
customer
operation?
<{
w
�
LL
C)

Figure 4.4-1 Theoretical failure chain model DFMEA and FMEA-MSR

The focus of the analysis is a component with diagnostic

capabilities, e.g., an ECU.
lf the component is not capable of detecting the fault/failure, the
Failure Mode will occur which leads to the end effect with a
corresponding degree of Severity.
However, if the component can detect the failure, this leads to a
system response with a Failure Effect with a lower Severity
comparad to the original Failure Effect. Details are described in
the following scenarios (1) to (3).

0
Fault occurs Failure Effect occurs No hazardous event
(S = 1...9)
Malfunctioning Behavior (Failure Mode)
t

Figure 4.4-2 Failure Scenario (1) - Non-Hazardous

Failure Scenario (1) describes the malfunctioning behavior from

the occurrence of the fault to the Failure Effect, which in this
example is not hazardous but may reach a non-compliant end
system state.

- 133 -
4.5.6 Current Monitoring Controls
Ali controls that are planned or already implemented and lead to a
detection of the Failure Cause, the Failure Mode or the Failure
Effect by the system or by the driver are entered into the "Current
Monitoring Controls" column. In addition, the fault reaction after
detection should be described, i.e. provision of default values, (if
not already sufficiently described by the Failure Effect).
Monitoring evaluates the potential that the Failure Cause, the
Failure Mode or the Failure Effect can be detected early enough
so that the initial Failure Effect can be mitigated befere a hazard
occurs or a noncompliant state is reached. The result is an end
state effect with a lower severity.

4.5. 7 Monitoring (M)

The Monitoring rating (M) is a measure of the ability of detecting a
fault/failure during customer operation and applying the fault
reaction in order to maintain a safe or compliant state.
The Monitoring Rating relates to the combined ability of ali
sensors, logic, and human sensory perception to detect the
fault/failure; and react by modifying the vehicle behavior by means
of mechanical actuation and physical reaction (controllability). In
order to maintain a safe or compliant state of operation, the
sequence of fault detection and reaction need to take place before
the hazardous or noncompliant effect occurs. The resulting rating
describes the ability to maintain a safe or compliant state of
operation.
Monitoring is a relative rating within the scope of the individual
FMEA and is determined without regard fer severity or frequency.
Monitoring should be estimated using the criteria in Table MSR3.
This table may be augmented with examples of common
monitoring. The FMEA project team should agree on an
evaluation criteria and rating system which is consistent, even if
modified fer individual product analysis.
The assumption is that Monitoring is implemented and tested as­
designed. The effectiveness of Monitoring depends on the design
of the sensor hardware, sensor redundancy, and diagnostic
algorithms that are implemented. Plausibility metrics alone are not
considered to be effective. Refer to Table MSR3.
lmplementation of monitoring and the verification of effectiveness
should be part of the development process and therefore may be
analyzed in the corresponding DFMEA of the product. (see NOTE
fer Failure Causes in Section 4.4.1 ).
The effectiveness of diagnostic monitoring and response, the fault
monitoring response time, and the Fault Tolerant Time lnterval
need to be determined prior to rating. Determination of the

- 141 -
 Supplement of FMEA-MSR Risk Analysis:

w
LL
-.t
0. -ro
-
_,s

-
LL
(.)
w as en
o LL e:- o
o o:: o�"6>�
-
� :.::;

LL MostSevere -en "C en a. a.

Rationale for
Current Current C)
e: - a, <
�e?
Failure Effect

' �!
��
t¡
Diagnostic System o::
(>' en
"C
Frequency o afterSystem
�-=
Monitoring Response :t::
:::, oe Response � o,.._
� ·e ·-
LL� en
Q)
CD>LLa, (])
.:!::'.

enCD .gE
ü:
.
The Supplement shows detailed definition of Rationale for Frequency, Current Diagnostic
Monitoring and System Response, Most Severe Failure Effect after System Response, Severity
(S) of FE after MSR, Severity (S) of Original FE from Failure Analysis (Step 4), and MSR AP.
MSR AP introduced with Action Priority high, medium, and low.
Possible views in form sheet are described.
Collaboration between customer and supplier explained.
Reason for change:

(t The FMEA-MSR is a supplement to DFMEA and takes aspects of road vehicle safety in
account.

6th Step: Optimization

Definition of optimization detailed.

w
ºª -G:' --
�=z,:
Most lL Action
Severe Taken :E

f
MSR
Diagnosti
e
System Failure - (¡ Responsible Target with
Completion � � ...
(/)

Preventive Respon Effect Person's Completion Status Pointer i::, a: (1)

ej
Monitorin Date u, E
Action se after Name Date to a,
g Action -� � :E o:::
System > Eviden u..
a,
Response (/) ce

Status of different action defined.

New assessment of action effectiveness defined;
Continua! improvement described
Remarks column added to document interna! comments, notes, and filter column for
manipulation of data.
Possible views in form sheet are described.

- 233
 Collaboration between FMEA team, management, customer and supplier explained.
Reason for change:
The information helps the user with visual management; each piece of information is included
and correct. lmportant is the "Pointer to Evidence" for follow-up reasons.

- 234
G References and Suggested Readings

• IATF 16949: 2016 Quality management systems

Particular requirements for the application of ISO 9001
for automotive production and relevant service part
organizations
• ISO 9001 Quality management systems - Requirements
• ISO 26262 Road vehicles - Functional safety
• SAEº J1739 Potential Failure Mode and Effects Analysis in
Design (Oesign FMEA), Potential Failure Mode and Effects
Analysis in Manufacturing.and Assembly Processes (Process
FMEA)
• VDA Volume 2 Quality Assurance of Supplies
• VDA Maturity Level Assurance for New Parts
• AIAG APQP Advanced Production and Quality Planning
• AIAG PPAP Production Part Approval Process

- 235 -
 H Glossary
Cyber-Physical Systems: a mechanism that is controlled or monitored by computer-based
algorithms, tightly integrated with the Internet and its users
Diagnostic coverage: per ISO 26262-1:2018, the percentage of the failure rate of a hardware
element, or percentage of the failure rate of a failure mode of a hardware element that is
detected or controlled by the implemented safety mechanism, the diagnostic figures are
determined by the hardware functional safety analysis
Failure Chain: A failure chain consists of a Failure Effect, a Failure Mode, and a Failure Cause.
Failure Network: A failure network is the connection of one or more failure chains that can
represent failures at multiple levels such that a Failure Cause at one level is a Failure Mode at
the next lower level.
Focus Element: The subject of the analysis. In a hierarchically described system, a focus
element has a next higher level element and at least one next lower element. A focus element
may be a System Element (item), a function of a system element, or a failure to provide a
function as specified.
Hybrid Failure Chain: A hybrid failure chain consists of a Failure Cause or Failure Mode,
intended Monitoring Controls, and a mitigated failure effect.
Mechatronics: technology combining electronics and mechanical engineering
Operational situation: per ISO 26262-1 :2018, a scenario that can occur during a vehicle's life
(e.g. driving at high speed; parking on a slope; maintenance)
Primary Vehicle Function: a function that is essential to fulfil the basic purpose of a vehicle,
e.g. steering, braking, propulsion, and visibility
Residual Risk: The risk(s) remaining after the deployment of safety measures. See ISO26262-
1:2018.
Secondary Vehicle Function: a function that enhances or enables a primary vehicle function
as well as the user experience, e.g. safety, comfort, convenience, interface, diagnostic, and
serviceability
Service life: the intended design life of the item (FMEA-MSR:the intended design life of the
vehicle)
Structure Tree: A graphical depiction of the hierarchical links between system elements and its
dependencies.
System Element: elements of a system that are represented in the structure tree
System response: the system's reaction to a detected fault, usually in the form of degrading or
disabling of a function and/or warning the operator and setting a fault code
Useful life: the operating interval in which a function is correctly provided, and the failure rate is
within acceptable tolerance
Zero Mileage / Zero km / Zero Hours: vehicle has not left the assembly plant

- 236-