Sei sulla pagina 1di 52

Edition 08.

1998
Work group booklet 14
K1/EQS Viehmann*
K3/QSG Lnder
K5/QSG Kaczynski
UC/WAY Gatter**
ZQF Eilers
* moderation
** at times
We are also very grateful for the work of those employees who have contributed to this booklet
with their ideas and their constructive criticism.
1998 Robert Bosch GmbH
H14 (43-08/98)
Contents
1 Introduction 6
FMEA Objectives .......................................................................................................... 6
FMEA History................................................................................................................ 6
Possibilities of and limits to the FMEA......................................................................... 6
FMEA-types - methodological differences.................................................................... 7
2 Description of Method 8
Deadlines for doing the FMEA...................................................................................... 8
FMEA-Team.................................................................................................................. 9
FMEA-sequence plan................................................................................................... 10
Systematic Preparations ............................................................................................... 10
Special Characteristics................................................................................................. 11
FMEA-Documents ....................................................................................................... 11
Updating....................................................................................................................... 11
3 System FMEA 13
Structuring.................................................................................................................... 14
Functional Analysis ..................................................................................................... 14
Risk evaluation............................................................................................................. 16
Optimizing ................................................................................................................... 19
4 Design FMEA 20
Structuring.................................................................................................................... 21
Functional analysis....................................................................................................... 22
Failure analysis ............................................................................................................ 22
Risk evaluation............................................................................................................. 23
Optimizing ................................................................................................................... 25
5 Process FMEA 27
Structuring.................................................................................................................... 28
Functional analysis....................................................................................................... 29
Failure analysis ............................................................................................................ 29
Risk assessment............................................................................................................ 30
Optimizing ................................................................................................................... 33
6 Cooperation with customers 34
FMEA presentation for customers............................................................................... 34
System or interface FMEA in cooperation with the customer..................................... 34
7 Cooperation with suppliers 35
8 Further FMEA-applications 36
Interface FMEA........................................................................................................... 36
Logistics FMEA........................................................................................................... 36
FMEA for software...................................................................................................... 37
FMEA for control units................................................................................................ 37
9 Selection/Prioritizing for FMEA 38
Selection according to application criteria .................................................................. 38
Selection with QFD...................................................................................................... 38
Further possibilities for selection................................................................................. 38
4 Contents

10 Relation to other methods 39
FMEA and Quality Function Deployment (QFD) ....................................................... 39
FMEA and value analysis ............................................................................................ 39
FMEA and Team Oriented Problem Solving (TOPS) ................................................. 40
FMEA and review procedures ..................................................................................... 40
11 Computer assistance 41
IQ FMEA..................................................................................................................... 41
Sibylle for windows ..................................................................................................... 41
12 Bibliography 42
13 Appendix 43
Appendix 1: Forms....................................................................................................... 43
Appendix 2: Short description ..................................................................................... 46
Appendix 3: Questions on the columns of the form.................................................... 48
Index 49
Foreword 5

H14 (43-08/98)
Foreword
In this booklet, the Failure Mode and Effects Analysis (FMEA) is described as method for risk
evaluation. The method used at Bosch is oriented on the successful procedures of the
automobile industry. The objective of this manual is a methodological description
(introduction) of a RB-uniform FMEA procedure. The already existing training material Basic
Seminar for System-, Construction-and Process-FMEA2. Edition (2/95) has been integrated in
its contents. QSP0305 FMEA and the existing FMEA procedures in the division have also
been taken into consideration.
In this booklet, some of the terms specifically used at RB have been substituted by more
common terms. The expert is already familiar with these terms; those who have just started to
get into this subject should be aware of the fact that within the period of change, they will still
find outdated terms like failure effect, severity, scope and RZ in the existing documents.
With the publication of this booklet, there is also a change of software. The programs used so
far are no longer up-to-date and are not further developed. With the now available IQ-FMEA
program, we have the possibility to efficiently support the FMEA. You will find more
information in chapter Computer assistance.
The efficiency of the FMEA is dependent on its timely implementation, on the cooperation of
competent employees and the concentration on relevant aspects.
The FMEA-documentation and its contents are together with other documents, for example
drawings, production- and inspection notes a know-how which is worth protecting and should
only be handed on under defined circumstances (see chapter Cooperation with customers).
The FMEA is organizationally tied up in existing design and production planning sequences. It
is also successfully used in new areas of employment, for example in the SW-development or
logistics-planning.
Please use the FMEA in view of the fact that systematic analyses in regard to potential failures
and their documentation help to prevent failure causes with means of the FMEA. In the long
run, the early and thus preventive usage of FMEA helps securing the success of the
organization.
6 Introduction

1 |ntroduct|on
FHEA 0bject|ves
The Failure Mode and Effects Analysis (FMEA) is an analytical method of the preventive
quality assurance. It serves to find the potential failure of a product/process, to recognize and
evaluate its importance and to identify appropriate actions to prevent the potential failure or to
discover it in time. The systematic analysis and removal of weak points leads to the
minimization of risks, to the reduction of failure costs and to an improved reliability.
FHEA h|story
In the mid-1960s, this method was developed within the Apollo-project in the USA. It has first
been used by the aerospace industry and the nuclear technology and later by the automobile
industry and also in other sections. Today, FMEA is an important part of the Bosch-quality
system.
Poss|b|||t|es of and ||m|ts to the FHEA
A FMEA is a good means to analyze risks caused by individual failures. The individual risks
are weight against each other to recognize priorities. A FMEA does not provide a statement on
the total failure risk. For the analysis of failure combinations, the fault-tree analysis is more
appropriate.
The advantages of a FMEA prove that the effort to prevent failures from the beginning of the
development process of a product are justified because the very much higher resulting costs are
eliminated later. Advantages are, e.g.:
Prevention of failures in design and development
Less subsequent product changes and thus reduction of costs
Prevention of repeated failures through systematic consideration of expert/failure
knowledge on the product or process.
An argument which is often used against FMEA is its high expenditure. The following topics
play an important role:
Complexity of the product
Level of analysis/type of FMEA
methodological experience of moderator/team
Quality of preparations
Terms of reference/scope of analysis
Especially the two last topics offer big saving potentials. Important things to note with a
systematic preparation are described in chapter 2.
The scope of analyses can be reduced in co-ordination with the client and the team. Approaches
for savings are:
Priority system and selection of analyses (compare chapter 9)
a decision analysis that shows the critical component groups
the use of existing products/processes with similar FMEA
the use of a Basis-FMEA with parts / products / processes which are repeatedly
analyzed
Introduction 7

H14 (43-08/98)
Whereas the expenditure of a FMEA can be easily determined, the savings can often not be
directly measured. The implementation of a FMEA is necessary when products are newly
developed, when there are changes on the product or procedures, products with safety
regulations or customer requirements (see [QSP0305]). Besides all that, the FMEA
implementation shows the following positive aspects, for example.:
all project participants are ready for team work at an early stage
better understanding of the system for all participants
early detection of problem areas
consequent taking of actions up to implementation
The biggest benefit is gained when the FMEA is made at an early stage simultaneous to the
development and planning of the production. It is important that the results can be used in the
product development process and so unnecessary recurrences are avoided.
FHEA-types - methodo|og|ca| d|fferences
There are different types of FMEA depending on the time, the depth and the object of the
analysis. Basically, all FMEA types are identical in their procedure; the useage of the same
form proves this.
System FMEA
The system FMEA analyzes the correct functional interrelation of the system components and
their connections. The goal is to avoid defects in system selection and layout and field risks.
The system requirements are the basis for the analysis.
The system development department is responsible for the system FMEA .
Design FMEA
The design FMEA analyzes the design and layout of products/components according to the
specification to avoid design errors and process defects influenced by the design.
The product/component design department is responsible for the design FMEA.
Process FMEA
The process FMEA analyzes process planning and performance for products/components
according to the drawing specifications to avoid planning errors and manufacturing defects.
The product planning department is responsible for the process FMEA.
8 Description of Method

2 0escr|pt|on of Hethod
0ead||nes for do|ng the FHEA
As soon as possible, a FMEA is prepared in a team. The knowledge and experience of experts
from all affected areas are taken into consideration. The FMEA analyzes the state of a project
and is to be continually updated as changes occur.
System FMEA
For base projects, the system FMEA is implemented after the drafting of system concepts or the
proposing of. For specific individual projects, the system FMEA is done after the description of
the function scope including project sheet, if possible before the component design accounts are
issued and before the design FMEA for new concepts is made.
Design FMEA
First draft is done before the start of B-sample manufacturing and testing. Corrective actions
should be completed before product release.
Process-FMEA
First draft is concurrent with preparations of the production sequence plan and the planning of
operational supplies, to the release of the product. Corrective actions should be completed
before the start of production.
System development
Component development
Concept Design Testing
Production Engineering Department
Planning Procurement
Pre-Series
Series
System FMEA
First draft Completion of corrective actions further updating
Design FMEA
First draft Completion of corrective actions further updating
Process FMEA
First draft Completion of corrective
actions
further
updating
u
Proposal for special
characteristics, QB1
u
Definition of special
characteristics, QB2
u
Realization of special
characteristics e.g. Cpk, QB3
System
development
order
Component
development order
Start of
B(C)-sample
production/
testing
Planning order./
product pre-release
Product release Start of series
(product -
delivery-
release)
Fig.1: Chronological integration of the FMEA (example)
Description of Method 9

H14 (43-08/98)
FHEA-Team
To improve efficiency, the FMEA is performed by a team of experts from all responsible and
affected areas.
Team work should lead to
parallel instead of serial work at an early stage
the benefit of a greater potential of knowledge and experience
an open way of dealing with existing information
increased creativity
quicker harmonized decisions
consensus building and improved acceptance of results
the promotion of cooperation within different departments.
For an efficient FMEA implementation, core teams are created (approx. 3 to 5 members). If
necessary, additional experts are included.
System FMEA Design FMEA Process FMEA
Core team
System development
(responsible)
Application
Moderator
Design
(responsible)
Testing
Plant (production
engineering department or
quality assurance)
Moderator
Production engineering
department
(responsible)
Quality assurance
Manufacturing operations
department
Moderator
Supplemental
members
Component
development
Sales
Department
Purchase department
Application/
System development
Endurance testings
Departments
Sales department
Plant
Purchase department
Development (design and/or
testings)
Departments
Purchase department
Table 1: FMEA team members (example)
10 Description of Method

FHEA-sequence p|an
The following table shows the individual criteria and sub-criteria which are important for a
FMEA.
0. Preparation and Planning
determine problem, problem definition and objective
team, sequential planning of action
materials for team
functional description
1. System structuring
numbering
component or working operations
2. Functional analysis
functions/characteristics
3. Failure analysis
potential types of failures
failure effects and failure causes
4. Risk assessment
failure prevention and failure detection
significance of failure effect (S)
occurance probability (O)
detection probability (D)
risk priority number RPN = S x O x D
5. Optimizing / Quality improvement
chose priority order of risks (analyze S, O, D and RPN)
determination of actions for improvement with R: and I:
introduction of actions for improvement
assess improvements (O,D)
Table 2: FMEA-sequence plan
8ystemat|c Preparat|ons
Before beginning with a FMEA, you have to do the following:
define scope (type of FMEA)
define objective
select team members
determine need for training, if necessary organize training
prepare tables and diagrams
plan topics which have to be dealt with
estimate expense
do organizational preparations
A systematic preparation of the FMEA can reduce the expenditure of the actual FMEA, i.e. the
time spend on team work. Involved in the preparations are the moderator of the FMEA, if
necessary also the FMEA-coordinator, the representative of the FMEA team (the expert) and
sometimes the client. The representative of the team is an important contact person for
producing departments (production area, plant) and thus an important contact person for the
moderator and he/she advises him with his expert knowledge.
When planning and preparing a FMEA, scope and objectives have to be clearly defined. At this
stage, you have to decide which parts of a system or a process have to be analyzed. If several
FMEA are planned, set the priorities according to urgency and required time which has to be
spend.
Description of Method 11

H14 (43-08/98)
The employees needed for a FMEA are to be exempt from their usual work, i.e. they should be
available during team work. Precondition for the cooperation in a FMEA team is the knowledge
of the FMEA method. If no training of this method takes place, there are unnecessary
methodological discussions when working in a team.
After the definition of the topics which have to be dealt with, the moderator estimates the
expense and coordinates this with the client.
Before the actual team work starts, all necessary documents have to be prepared. At the
beginning of the FMEA team-work, the team is supported by a functional description with the
help of drawings and sample parts. Is the product a successor product, the already existing data
(failure data, change applications, improvement proposals, field failures) can be additionally
used to support the team.
Important influence factors for the quality of FMEA are:
time of the FMEA/start in time
composition of team
ability of employees of working in a team
knowledge of the FMEA-method
in a process-FMEA : knowledge on the possibility of translating the measures
through MA into action in the production
willingness to hand on information
8pec|a| 6haracter|st|cs
When determining and dealing with special characteristics (critical/significant/ R/D/ SPC) you
have to take note of the following:
special characteristics which result from customer requirements have to be merked in
the FMEA.
The special characteristics (critical/significant/ R/D/ SPC) are deduced from the
FMEA and the marking is done according to the stipulations of the division.
FHEA-0ocuments
The following documents are recommended for the publication of the FMEA as provided on
the FMEA- cover sheet:
cover sheet with general information and a summary
description of product which is to be analyzed (drawings, sketches,...)
list of used documents (used rating chart)
FMEA-forms
evaluation (time schedule, FMEA-summary,...)
Updat|ng
FMEA updating includes entering product and process changes and changed operating
conditions; information on manufacturing, zero-mileage and field experiences are entered and
the measures are reviewed. A redistribution follows the revision.
The associate responsible for updating of the FMEA (see cover sheet) must be informed by the
associate responsible for introducing quality improvement measures when these are introduced.
The effectiveness of these measures must be checked and the ratings reviewed, if necessary.
The old ratings are put in brackets - [ ] or < > -. The new and valid ratings do not have any
brackets.
12 Description of Method

The updating of the FMEA has to be guaranteed in documenting the development and
production of a product. When updating, especially the latest actions have to be taken into
consideration. It is recommended to update the FMEA every six months to every year.
System-FMEA 13

H14 (43-08/98)
3 8ystem FHEA
The system FMEA analyzes the correct functional interrelation of the system components and
their connections. The goal is to avoid defects in system selection and layout and field risks.
The system requirements are the basis for the analysis. The system development department is
responsible for the system FMEA.
<ggf. Vertraulichkeitshinweis>
System-FMEA Page:
Department:
Quality Assurance Product:
Number:
FMEA-Number:
Date:
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN Actions
R:/I:
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
This document is the exclusive property of Robert Bosch GmbH. Without their consent it may not be reproduced or given to third parties.
Fig. 2: The FMEA-form
Preparations
The following documents should be prepared for the first team meeting:
(also see chapter 2 - systematic preparations)
system-requirements, e.g. system target specification, machine list and block
diagram with detailed functional description.
field failure statistics and failure rates of comparable products
failure lists
prepared structuring and functional analysis
Base data
The base data are entered in the form (see following table).
Field System FMEA contents Notes
RB-Logo Additional customer-logo with joint
FMEA
FMEA type System FMEA
Product The system or sub-system which is analyzed in the FMEA
Article number The identity number of the analyzed system or the project
number (as far as it exists)

Confidence note if necessary note on how to treat the FMEA Here, a conficence note can be
entered
Page Page number of the FMEA-forms Is generated automatically through
SW
Department The department responsible for the realization of the FMEA
FMEA-NR. Numbering according to BOSCH-standard N12A or N10 another numbering can be
determined
Date Date of the corresponding FMEA-edition
Footnote Includes copyright and if necessary an explanation to the
appreviations used in the FMEA
Is generated automatically through
SW
Tabelle 3: Base data
14 System-FMEA

The following description of the system FMEA procedure is oriented on the FMEA-sequence
plan (see page 10) and on the FMEA-form.
8tructur|ng
A successful possibility to structure the system FMEA is the component/function-matrix of the
system. The SW IQ-FMEA offers more possibilities for system structuring (e.g. system tree,
functions- or failure grid.
No. Component
or Process

(1) (2)
Column (1) No.
The numbering of the component is taken, e.g., from the block diagram or the machine list and
supplemented through a number for the failure cause, e.g. 010.01 or 01.001.
Column (2) Component or Process
In column 2, the system components, component groups to be analyzed are entered according to
block diagram/machine list or component/function-matrix. Software-modules/-functions can
also be analyzed.
Funct|ona| Ana|ys|s
No. Component
or Process
Function
(3)
Column (3) Function/ Purpose
The system FMEA lists all functions of the system components on the basis of the system
requirements in view of operating conditions, starting from a black-box analysis.
The scope of the FMEA is determined within a functional analysis.
The more exact the description of the functions and characteristics is, the more exact the
potential failure types can be derived. The functions should be described with a noun, verb.
System-FMEA 15

H14 (43-08/98)
Failure analysis
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes

(4) (5) (6) (7)
Column (4) Failure mode
In the failure mode column, it is described why a required function or characteristic could not
have been fulfilled.
The system FMEA analyzes all potential malfunctions and functional deficits that are inferable
from the functions of the system components and from their connections.
Column (5) Failure consequence
A failure consequence is a short and precise description of a causal chain from failure mode to
effect on the highest system level (e.g. vehicle) or the environment or the customer (external
and internal). This description should be done in different steps - direct, next, end.
Column (6) Special characteristics
The special characteristics are identified according to the stipulations of the division (see also
chapter special characterlistics, page 11).
Column (7) Failure causes
In this column, those failure causes are to be listed that might lead to the analyzed failure mode
(= potential failure causes). The actual cause has to be described in such a way that any
necessary measures for improvement can be directly introduced.
The system FMEA looks at failures of functional groups or components and their connections;
for the design as well as for the field.
All operating conditions (lifetime, temperature, time acceleration factors etc.) and operating
conditions (e.g. complete load, partial load, ABS breaking, partial breaking,...) have to be
analyzed.
Failure causes during the system development phase and system testing phase are to be looked
for in the selection, co-ordination, design and development.
16 System-FMEA

R|sk eva|uat|on
For the risk evaluation, the already introduced actions are listed in the columns failure
prevention and detection.
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection

(8) (9)
Column (8) Failure prevention
Failure prevention is a preventive action taken during the system design phase to prevent failure
causes to occur or to complicate their occurrence.
In a system FMEA (field and interpretation), the introduced actions are to be analyzed that
minimize the risk of system interpretation failures, prevent or limit the failure consequences.
Column (9) Failure detection
In a system FMEA , everything from failure detection during system development to system-
release (design failures) is analyzed and failure detection through the system even in the field
(field failure) are analyzed.
Actions for failure detection during the design are e.g. the system testings, testings in the
vehicle, simulations and endurance testings.
Actions for failure detection in the field are e.g. internal diagnosis (together with appropriate
substitutional functions), warning lamp/display, symptoms (noises etc.)
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN
(10) (11) (12) (13)
Column (10) Relevance of failure consequence (S)
In column 10, the significance of the end- or. distant effect of the failure type on the system
and/or the customer is evaluated. The evaluation criteria are covered by the VDA-Evaluation
tables (see VDA vol. 4.2) or QS 9000 evaluation tables. The product-specific adaptation of the
rating charts can be of importance for the individual divisions.
System-FMEA 17

H14 (43-08/98)
System FMEA:
S - Severity of failure consequence Rating
Extremely serious failure, which affects safety and/or violates legal
requirements, without previous warning.
10
Extremely serious failure, which possibly affects safety and/or violates
legal requirements with previous warning or leads to breaking down.
9
Serious failure, failure of primary functions, e.g. vehicle not in running order. 8
Serious failure, reliability of vehicle very restricted, immediate servicing
required.
7
Moderately serious failure, failure of important operational and comfort
systems; immediate servicing not required.
6
Moderately serious failure, limited functioning of important operational and
comfort systems.
5
Moderately serious failure, little reliability restriction of operational and
comfort systems; detectable by any driver
4
The failure is insignificant. The customer is only slightly bothered, and will
probably only notice slight interference;can be noticed by the average driver.
3
It is unlikely that the failure could have a noticeable effect on the behavior of
the vehicle; only noticeable by experts or experienced drivers.
2
No effect 1
Table 4: Evaluation criteria for the importance of the failure consequence (B)
in system FMEA
Column (11) Occurrence probability (O)
The rating O says how probable it is that the failure type occurs at the customers/users
because of a certain failure cause. Actions which have been introduced to avoid the failure
cause are analyzed and are assumed to be efficient.
System FMEA
O - occurance probability
Possible
failure rate*

ppm*
Rating points
Very high It is almost certain that the type/cause of failure will
occure very often.
1/10
1/20
100.000
50.000
10
9
High The type/cause of failure occurs repeatedly. Problematic, not
perfect system.
1/50
1/100
20.000
10.000
8
7
Moderate The type/cause of failure occurs occationally. Advanced
system.
1/200
1/1.000
1/2.000
5.000
1.000
500
6
5
4
Low The probability that the type/cause of failure occurs is low.
Proven system design.
1/15.000
1/150.000
67
6,7
3
2
Unlikely. The occurence of the type/cause of failure is unlikely. <1/1.500.000 <0,67 1
*pro LD (LD = product lifetime)
Table 5: Rating chart for probability of occurrence (O) in system FMEA
The failure rates (e.g. - rates, ppm) in the rating chart are based on the number of failures that
are expected to occur within the required lifetime of a product. The dependencies of operating
time (h), road performance (km), cycle numbers are to be taken into account. Plant, 0-mileage
and field experiences are to be considered.
18 System-FMEA

Column (12) Detection probability (D)
In the system FMEA, there are different D ratings for the detection probability of system
design and field failures.
With design failures, D assesses the actions taken for inspection and detection of the system
development phase, e.g. simulation, functional testings, vehicle inspection, endurance testing,
customer-initial sample testing according to system target specification and test plan.
With field failures, D assesses the detection measures, displays and symptoms that are perfect
for detecting field failures in time, e.g. system-immanent tests (e.g. self-diagnosis), service,
diagnosis, driver, warning lamps, changed functions.
System FMEA :
D detection probability

Evaluation criteria design Rating
Unlikely It is impossible or unlikely that a type and/or cause of failure is
detected through test and analysis measures in the development phase.
10
Very low The probability is very low that the type and/or cause of failure is
detected through test and analysis measures in the development phase.
9
8
Low The probability that the type and/or cause of failure is detected through
test and analysis measures in the development phase is low.
7
6
Moderate The probability that the type and/or cause of failure is detected
through test and analysis measures in the development phase is moderate.
5
4
High The probability that the type and/or cause of failure is detected through
test and analysis measures in the development phase is high.
3
2
Very high It is certain that the the type and/or cause of failure is detected
through test and analysis measures in the development phase.
1
Evaluation criteria field Rating
It is impossible or improbable that the failure is detected at all or on time. 10
The failure can be detected through, e.g.:
- reading of the fault memory during service work, substitue measures of the
system do not exist
- changed secondary function or another symptom (e.g. noise, noticeable
smell)

9
8
7
Diagnosis and substitute functions of system are active, warning lights at
vehivle have to be turned on (e.g. emission)
6
Clearly noticeable impairement of secondary function (e.g. very loud noise)
or slowly increasing impairement of function
5
Diagnosis and substitute function of system are active, light does not have to
be turn on.
4
3
2
The failure is definitely detected and ist effect is definitely prevented. 1
Table 6: Rating criteria for probability detection (D) in system FMEA
Column (13) Risk priority number
The risk priority number is the product of S, O and D. It is the standard for the ranking of
existing risks.
RPN = S x O x D
System-FMEA 19

H14 (43-08/98)
0pt|m|z|ng
The RPN and the individual ratings S, O and D clearly show the system risks. If there is a high
RPN or high individual ratings, improvements are required.
If B 9, actions that reduce the importance of the failure consequence should
possibly be taken. Usually, these are system changes. If this is not possible, A has to
be reduced to such a degree that only a small and warrantable risk remains.
Other limiting values for S, O, D, and RPZ are set by the team in such a way that the
different quality objectives for the product have to be met at the start of production.
In some areas, the following is valid:
Dependend on the degree of FMEA specification (system, subsystem, component),
the limit for introducing quality improvements should have a RPN between 60 and
300.
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN Actions
R:/I:
(14)
Column (14) Actions R:/I:
After the actions have been written down in the FMEA-form, they have to be completed by the
responsible person (R) and the deadline (I).
The ratings for the planned improvement are entered in the round brackets ().
If there are extreme concept changes, all 5 steps of the system FMEA are retaken for all
concerned sections from system structuring to optimizing.
The final assessment is done after the action has been taken and after testing its effectiveness.
If a type of failure does not exist any longer because of the proposed action, the assessment
numbers S, O, D, PRZ are to be put equal zero. If a failure cause does not exist any longer
because of an action, the assessment number for O and RPN are to be put equal to zero.
Alternatively, the cancelled failure type/cause can be documented.
20 Design FMEA

4 0es|gn FHEA
The design-FMEA analyzes the design and layout of products/components according to the
specification to avoid design errors and process defects influenced by the design.
The product/component design department is responsible for the design FMEA.
<ggf. Vertraulichkeitshinweis>
Design-FMEA Page:
Department:
Quality Assurance Product:
Number:
FMEA-Number:
Date:
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN Actions
R:/I:
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
This document is the exclusive property of Robert Bosch GmbH. Without their consent it may not be reproduced or given to third parties.
Fig. 3: The FMEA-form
Preparations
The following documents should be available at the first team meeting (see also chapter 2 -
systematic preparations):
Target specification
Development drafts
Parts lists
prepared FMEA structure
In addition, the following documents are also very helpful:
System FMEA
Functional description
Test sheet, sample
Technical customer documents
Endurance test results
0-mileage and field failure statistics of comparable products
Failure lists
Uncleared-topics-list
Failure rates of comparable products
Design FMEA 21

H14 (43-08/98)
Base data
The base data are entered in the form (see following table).
Field Design FMEA contents Notes
RB-Logo
FMEA type Design FMEA
Product The product analyzed in the FMEA
Article number The identity number of the analyzed product
Confidence note if necessary note on how to treat the FMEA Here, a conficence note can be
entered
Page Page number of the FMEA-forms Is generated automatically through
SW
Department The department responsible for the realization of the FMEA
FMEA-NR. Numbering according to BOSCH-standard N12A or N10 Another numbering can be
determined
Date Date of the corresponding FMEA-edition
Footnote Includes copyright and if necessary an explanation to the
appreviations used in the FMEA
Is generated automatically through
SW
Table 7: Base dates in design FMEA
The following description of the design FMEA procedure is oriented on the FMEA-sequence
plan (see page 10) and on the column structure of the Bosch FMEA form.
8tructur|ng
The structuring of the design FMEA can be derived from the component-function-matrix.
No. Component
or Process

(1) (2)
Column (1) No.
The number serves the clear identification of the analyzed failure cause. In the design FMEA, it
consists of, e.g., the position numbers of the parts lists and of a serial number for the failure
cause.
Column (2) Component or Process
In column 2, the component groups (component parts which are to be analyzed are entered
according to parts list.
22 Design FMEA

Funct|ona| ana|ys|s
No. Component
or Process
Function
(3)
Column (3) Function
The design FMEA lists all important functions and operating conditions of components; on the
basis of the component target specification and the design characteristics. The total product life
cycle up to the recycling of the product is to be analyzed.
The scope of the FMEA is determined within the functional analysis.
The more exact the description of the functions and characteristics is, the more exact the
potential failure types can be derived. The functions should be described with a noun, verb.
Fa||ure ana|ys|s
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes

(4) (5) (6) (7)
Column (4) Failure mode
In the failure mode column, it is described why a required function or a characteristic could not
have been fulfilled.
The design FMEA analyzes all potential malfunctions and functional deficits that are inferable
from the component functions and which are described as physical expression. The design
which meets the requirements of production is also to be analyzed; however, the process FMEA
is not anticipated.
Column (5) Failure consequence
A failure consequence is a short and precise description of a causal chain from failure mode to
the effect on the highest system level (e.g. vehicle) or the environment or the customer (external
and internal). This description should be done in different steps - direct, next, end. The failure
consequence can be derived from the system FMEA.
Column (6) Special characteristics
The special characteristics are identified according to the stipulations of the division (see also
chapter 2 - special characteristics).
Column (7) Failure causes
In this column, the failure causes are to be listed that might lead to the failure mode under
consideration (= potential failure causes). The actual cause has to be described in such a way
that any necessary measures for improvement can be directly introduced.
The design FMEA looks at failures which result from the design, selection or system as well as
production and assembly failures which can be constructively influenced.
All operating conditions (lifetime, temperature, time acceleration factors etc.) have to be
considered.
Design FMEA 23

H14 (43-08/98)
R|sk eva|uat|on
For the risk evaluation, the already introduced actions are listed in the columns failure
prevention and detection.
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN
(8) (9)
Column (8) Failure prevention
Failure prevention is a preventive action taken during the design phase to prevent failure causes
to occur or to complicate their occurrence.
Preventive actions are derived from theoretical knowledge and practical experience. DoE
(Design of Experiments) prevents failures for the designs and processes (robust design/robust
process).
Column (9) Failure detection
Defect detection within the design FMEA are inspections and testings in the development and
other detection possibilities up to the product release.
To keep the testing expense as small as possible, actions which prevent failures have to be
taken. Testings have to be done to provide security for the design. Through a specific planning
of experiments, the expense for the testings is minimized.
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN
(10) (11) (12) (13)
Column (10) Relevance of failure consequence (S)
In column 10, the end or distant effect of the failure mode on the system and/or the customer
are evaluated. The evaluation criteria are covered by the VDA-rating charts or QS 9000 rating
charts (see [VDA4/2(96)], [CFG9000(95)]. It is better to make new rating charts for none K-
areas.
24 Design FMEA

Design FMEA:
S - Importance of failure consequence

Rating
Extremely serious failure, which affects safety and/or violates legal
requirements, without previous warning.
10
Extremely serious failure, which possibly affects safety and/or violates
legal requirements with previous warning or leads to breaking down.
9
Serious failure, failure of primary functions, e.g. vehicle not in running order. 8
Serious failure, reliability of vehicle very restricted, immediate servicing
required.
7
Moderately serious failure, failure of important operational and comfort
systems; immediate servicing not required.
6
Moderately serious failure, limited functioning of important operational and
comfort systems.
5
Moderately serious failure, little reliability restriction of operational and
comfort systems; detectable by any driver
4
The failure is insignificant. The customer is only slightly bothered, and will
probably only notice slight interference;can be noticed by the average driver.
3
It is unlikely that the failure could have a noticeable effect on the behavior of
the vehicle; only noticeable by experts or experienced drivers.
2
No effect 1
Table 8: Evaluation criteria for the importance of the failure consequence (S)
in design FMEA
Column (11) Occurrence probability (O)
The rating O says how probable it is that the failure type occurs at the customers/users
without previous detection - because of a certain failure cause. Actions which have been
introduced to avoid the failure cause are analyzed and are assumes to be efficient.
The failure rates (e.g. - rates, ppm) in the rating chart are based on the number of failures that
are expected to occur within the required lifetime of a product. The dependencies of operating
time (h), road performance (km), cycle numbers are to be taken into account. Plant, 0-mileage
and field experiences are to be considered.
Design FMEA
O - occurance probability
Possible
failure rate*

ppm*
Rating points
Very high It is almost certain that the type/cause of failure will
occure very often.
1/10
1/20
100.000
50.000
10
9
High The type/cause of failure occurs repeatedly. Problematic, not a
perfect design.
1/50
1/100
20.000
10.000
8
7
Moderate The type/cause of failure occurs occationally. Advanced
design.
1/200
1/1.000
1/2.000
5.000
1.000
500
6
5
4
Low The probability that the type/cause of failure occurs is low.
Proven design.
1/15.000
1/150.000
67
6,7
3
2
Unlikely. The occurence of the type/cause of failure is unlikely. <1/1.500.000 <0,67 1
*pro LD (LD = product lifetime)
Table 9: Rating chart for probability of occurrence (O) in design FMEA
Design FMEA 25

H14 (43-08/98)
Column (12) Detection probability (D)
In the design FMEA, E assesses the test and detection measurements of the development
phase, e.g. functional testings,
endurance testings, vehicle testings, customer-initial sample testings according to target
specification and test plan.
Actions within the design FMEA that make the detection of the failures possible only after the
product release should be rated with E=9 or 10.
Design FMEA:
D detection probability

Evaluation criteria design Rating
Unlikely It is impossible or unlikely that a type and/or cause of failure is
detected through test and analysis measures in the development phase.
10
Very low The probability is very low that the type and/or cause of failure is
detected through test and analysis measures in the development phase.
9
8
Low The probability that the type and/or cause of failure is detected through
test and analysis measures in the development phase is low.
7
6
Moderate The probability that the type and/or cause of failure is detected
through test and analysis measures in the development phase is moderate.
5
4
High The probability that the type and/or cause of failure is detected through
test and analysis measures in the development phase is high.
3
2
Very high It is certain that the the type and/or cause of failure is detected
through test and analysis measures in the development phase.
1
Table 10: Rating criteria for probability detection (D) in design FMEA
Column (13) Risk priority number
The risk priority number is the product of S, O and D. This number shows the risk connected to
the failure cause and allows a rating of the failure causes.
0pt|m|z|ng
The RPN and the individual ratings S, O, and D clearly show the system risks. If there is a high
RPN or high individual ratings, improvements are required.
If S 9, actions that reduce the meaning of the failure consequence should possibly
be taken. Usually, these are system changes. If this is not possible, O has to be
reduced to such a degree that only a small and warrantable risk remains.
For high O-ratings, actions have to be taken that guarantee the set quality objective
for the product at the beginning of the production. That means that normally O=2 to 3
should be reached. If there is safety relevance, the objective should be O=1.
To make sure that the quality objectives will be met, action for detection have to be
taken.
In some areas, the following is valid:
If RPN exceeds a limit which is to be set (e.g. 125), actions for quality improvement
have to be taken.
If RPN are close to the set limit (e.g. between 50 and 125) actions for continuos
improvement have to be taken to reach the quality objective at the production-start.
26 Design FMEA

No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN Actions
R:/I:
(14)
Column (14) Actions R:/I:
After the actions have been written down in the FMEA-form, they have to be completed by the
responsible person (R) and the deadline (I).
The ratings for the planned improvement are entered in the round brackets ().
If there are extreme concept changes, all steps of the FMEA are retaken for all concerned
sections from system structuring to optimizing.
The final assessment is done after the action has been taken and after testing its effectiveness.
If a type of failure does not exist any longer because of the proposed action, the assessment
numbers S, O, D, PRZ are to be put equal zero. If a failure cause does not exist any longer
because of an action, the assessment number for O and RPN are to be put equal to zero.
Alternatively, the cancelled failure type/cause can be documented.
If an action is taken (e.g. change of the design draft or change of the production procedure), it
has to be examined which new risks arise. If actions are found which lead to the canceling of a
failure type/cause, the new actual state is to be analyzed. The old and new actual state have to
be weight up.
Process FMEA 27

H14 (43-08/98)
5 Process FHEA
Definition: The process FMEA analyzes process planning and performance for products/com-
ponents according to the drawing specifications to avoid planning errors and manufacturing
defects.
<ggf. Vertraulichkeitshinweis>
System-FMEA Page:
Department:
Quality Assurance Product:
Number:
FMEA-Number:
Date:
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN Actions
R:/I:
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
This document is the exclusive property of Robert Bosch GmbH. Without their consent it may not be reproduced or given to third parties..
Fig. 4: The FMEA-form
Preparation
The following documents should be available at the first team meeting (see also chapter 2
Systematic preparations, Page 10):
Design FMEA
Parts lists
Production sequence plans
Production drafts
Functional description
Sample
Technical customer documents
0-mileage and field failure statistics of comparable products
Failure lists
Failure rates of comparable products
Machine and process capability data
prepared FMEA structure
28 Process FMEA

Base data
The base data are entered in the form (see following table).
Field Process FMEA contents Notes
RB-Logo Additional customer-logo with joint
FMEA
FMEA type Process FMEA
Product The product under consideration in the FMEA
Article number The identity number of the product under consideration
Confidence note if necessary note on how to treat the FMEA Here, a conficence note can be
entered
Page Page number of the FMEA-forms Is generated automatically through
SW
Department The department responsible for the realization of the FMEA
FMEA-NR. Numbering according to BOSCH-standard N12A or N10 Another numbering can be
determined
Date Date of the corresponding FMEA-edition
Footnote Includes copyright and if necessary an explanation to the
appreviations used in the FMEA
Is generated automatically through
SW
Table 11: Base dates in process FMEA
The following description of the design FMEA procedure is oriented on the FMEA-sequence
plan (see page 10) and on the column structure of the Bosch FMEA form.
8tructur|ng
The structuring of the process FMEA results from the process sequence plan or the product
quality assurance plan (PQP).
No. Component
or Process
(1) (2)
Column (1) No.
The number serves the clear identification of the failure cause and the assignment of the
individual process in the FMEA to the product quality assurance plan (PQP). In the process
FMEA, the first part of the number is the operation number of the sequence plan and the second
part is, e.g. a serial number for the failure cause.
Column (2) Component/Process
In column 2, the working operations/steps which have to be analyzed are entered in the working
plan.
Process FMEA 29

H14 (43-08/98)
Funct|ona| ana|ys|s
No. Component
or Process
Function
(3)
Column (3) Function
The process FMEA lists all important process functions (working plan) and parts characteristics
(drawing).
The size of the FMEA is determined within the functional analysis.
The more detailed the description of the functions and characteristics is, the more accurate the
potential failure types can be derived. The functions should be described with substantive, verb
and the criteria for compliance (target values, tolerances, ...).
Fa||ure ana|ys|s
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
(4) (5) (6) (7)
Column (4) Failure mode
The process FMEA analyzes all potential process failures that can be deducted from the
required process functions and parts characteristics and that can be described as deviation.
Column (5) Failure consequence
A failure consequence is a short and precise description of a causal chain from failure mode to
effect on the highest system level (e.g. vehicle) or the environment or the customer (external
and internal). This description should be done in different steps - direct, next, end. It can be
deducted from the design or system FMEA .
Column (6) Special characteristics
The special characteristics are identified according to the stipulations of the division (see also
chapter 2.5).
Column (7) Failure causes
In this column, the failure causes are to be listed that might lead to the analyzed failure mode
(= potential failure causes). The actual cause has to be described in such a way that any
necessary measures for improvement can be directly introduced.
Basically, all process-oriented failure causes are to be listed here. The term process includes all
process sections, from supplying the material to transport, the actual production, cleaning,
assembly, packaging, storing to the delivery to the customer.
The commitment of the product to a certain design should no longer be questioned.
30 Process FMEA

R|sk assessment
For the risk evaluation, the already introduced actions are listed in the columns failure
prevention and detection.
It is important to note that double-evaluations should be avoided. Double evaluations exist
when the efficiency of a preventive or detective action are presupposed in an evaluation at
some other place. Examples for a non-permissible argumentation: a) The detection is very
good, i.e. D=1, the failure does not reach the customer, he/she does not notice the failure;
therefore S=1, b) The detection is very good, i.e. D1, therefore the occurrence probability is
O=1.
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
(8) (9)
Column (8) Failure prevention
Failure prevention is a preventive action taken during production preparations to prevent failure
causes to occur or to complicate their occurrence.
SPC is an action within the process FMEA to prevent failures (process capability)
DoE (Design of Experiments) prevents failures of design and processes (robust design/robust
process).
Column (9) Failure detection
Actions which lead to the detection of failures make an early detection of the failure in the
process possible and prevent products with failures to get to the customer. Processes in control
prevent failures and are thus preferred to inspections.
Only established or obligatory testings and detections within the process (e.g. next working
operation not possible) should be taken into consideration.
In the process FMEA, it is distinguished between random and systematic failures. The SPC-
sampling inspection is a detective action for systematic but not for random failures (sampling
inspection). Random failures can be detected with a 100% inspection; or if a working operation
at some later time can not be realized (e.g. .....)
Process FMEA 31

H14 (43-08/98)
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN
(10) (11) (12) (13)
Column (10) Relevance of failure consequence (S)
In column 10, the end or distant effect of the failure mode on the system and/or the customer
are evaluated. The evaluation criteria are covered by the VDA-rating charts or QS 9000 rating
charts (see [VDA4/2(96)],[CFG9000(95)]). It is better to make new rating charts for none K-
areas.
Process FMEA:
S - Importance of failure consequence

Rating
Extremely serious failure, which affects safety and/or violates legal
requirements, without previous warning.
10
Extremely serious failure, which possibly affects safety and/or violates
legal requirements with previous warning or leads to breaking down.
9
Serious failure, failure of primary functions, e.g. vehicle not in running order. 8
Serious failure, reliability of vehicle very restricted, immediate servicing
required.
7
Moderately serious failure, failure of important operational and comfort
systems; immediate servicing not required.
6
Moderately serious failure, limited functioning of important operational and
comfort systems.
5
Moderately serious failure, little reliability restriction of operational and
comfort systems; detectable by any driver
4
The failure is insignificant. The customer is only slightly bothered, and will
probably only notice slight interference;can be noticed by the average driver.
3
It is unlikely that the failure could have a noticeable effect on the behavior of
the vehicle; only noticeable by experts or experienced drivers.
2
No effect 1
Table 12:Evaluation criteria for the importance of the failure consequence (S)
in process FMEA
Column (11) Occurrence probability (O)
The rating O reflects the probability with which the failure type occurs as a consequence of a
certain failure cause - without previous detection. Actions which have been introduced to avoid
the failure cause are analyzed and are assumed to be efficient.
32 Process FMEA

Process FMEA
O - occurance probability
Possible
failure rate*

ppm*
Cpk
Rating points
Very high It is almost certain that the type/cause of
failure will occure very often.
1/10

1/20
100.000

50.000
- *

- *
10

9
High The type/cause of failure occurs repeatedly.
Problematic, not a perfect design.
1/50

1/100
20.000

10.000
- *

- *
8

7
Moderate The type/cause of failure occurs occationally.
Advanced design.
1/200

1/1000

1/2000
5.000

1.000

500
0,94

1,10

1,17
6

5

4
Low The probability that the type/cause of failure occurs
is low. Proven design.
1/15000

1/150.000
67

6,7
1,33

1,50
3

2
Unlikely. The occurence of the type/cause of failure is
unlikely.
< 1/1500000 < 0,67 >
1,67
1
*data not sensible
Table 13: Rating chart for probability of occurrence (O) in process FMEA
The failure rates (e.g. - rates, ppm) in the rating chart are based on the number of failures that
are expected to occur within the required lifetime of a product. The dependencies of operating
time (h), road performance (km), cycle numbers are to be taken into account. Plant, 0-mileage
and field experiences are to be considered.
Column (12) Detection probability (D)
In the process FMEA, D assesses the test and detection measurements of the production and
assembly. The rating is oriented on verbal criteria or on the portion of non-detected parts in
relation to the portion of nonconforming items in the lot.
Actions within the process FMEA that make the detection of the failures possible only after the
product release should be rated with D=10.
Process FMEA:
E detection probability
Certainty of
the testing
processes

Rating
Unlikely
The failure is not detected or cannot be detected.
10
Very low
The probability that the failure is detected is very low.
90% 9
Low
The probability of detecting the failure is low.
98% 8
7
Moderate
The probability of detecting the failure is moderate..
99,70% 6
5
4
High
The probability of detecting the failure is high.
99,90% 3
2
Very high
The probability of detecting the failure is certain.
99,99% 1
Table 14: Rating criteria for probability detection (D) in process FMEA
Process FMEA 33

H14 (43-08/98)
Column (13) Risk priority number
The risk priority number is the product of S, O and D. This number shows the risk connected to
the failure cause and allows a rating of the failure causes.
0pt|m|z|ng
The RPN and the individual evaluations B, A and E show the risks. If there are high RPN or
high individual ratings, improvement measures are necessary.
The objective for safety relevance is O = 1. If this is not possible, you have to make
sure with suitable detection measurements that no nonconforming products get to the
customer.
If there is a high probability of failures to occur, actions have to be taken which
ensure the reaching of the quality objective. In general, this means that processes in
control coincide with C
pk
> 1,33 - 1,67 or A = 1 or 2.
In some areas, the following is valid:
If RPZ exceed a limit which is to be set (e.g. 125), actions for quality improvement
have to be taken.
If RPZ are close to the set limit (e.g. between 50 and 125) actions for continuos
improvement have to be taken to reach the quality objective at the production-start.
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN Actions
R:/I:
(14)
Column (14) Actions R:/I:
After the actions have been written down in the FMEA-form, they have to be completed by the
responsible person (R) and the deadline (I).
The ratings for the planned improvement are entered in the round brackets ().
If there are extreme concept changes, all steps of the FMEA are retaken for all concerned
sections from system structuring to optimizing.
The final assessment is done after the action has been taken and after the testing of its
effectiveness.
If a type of failure does not exist any longer because of the proposed action, the assessment
numbers S, O, D, RPN are to be put equal zero. If a failure cause does not exist any longer
because of an action, the assessment number for O and RPN are to be put equal to zero.
Alternatively, the cancelled failure type/cause can be documented.
34 Cooperation with customer

6 Cooperation with customers
Customer contacts for FMEA are regulated by the K/VKK directive Submittal of FMEAs to
customers, dated 1/26/1995. Cooperation with customers takes place when the customer
whishes so on sight or after the FMEA is handed over or after a cooperaqtive preparation of a
system or interface FMEA.
FMEA presentation for customers
The FMEA presentation is usually performed and organized by the sales department together
with other responsible departments.
On the first presentation of a FMEA, the RB-FMEA-method and the used rating charts should
be explained.
The FMEA with regard to its contents should be presented by an employee of the responsible
department. System and design FMEA are usually done by the development department,
process FMEA by the plant. The FMEA resume (enclosure...) can be handed over to the
customer, if requested.
Details should be regulated specific to the division.
System or interface FMEA in cooperation with the customer
A system or interface FMEA in cooperation with the customer investigates the functionally
correct interaction of the input and output functions on the interface between RB and customer
components of a system. This can be software or hardware components.
This can be conducted by FMEA moderators of RB or by the customer. The FMEA in
cooperation with the customer should be well prepared and structured by RB. First, rating
charts have to be determined which are accepted by both parties.
Working on a system or interface FMEA in cooperation with the customer has to be approved
of by the responsible division.
Cooperation with supplier 35

H14 (43-08/98)
7 6ooperat|on w|th supp||ers
Basis for the cooperation with the supplier is the guideline for suppliers. To guarantee the
quality of fabricating parts, Bosch demands of its suppliers, among others, that they make a and
present FMEA (supplier FMEA).
Procedure with (sub-) system or design FMEA
After the draft has been made by the supplier, the Bosch development department wants to
inspect the (sub-)system of design FMEA through RN-MA (development and purchase
department) and wants to discuss the draft with the supplier.
Process FMEA procedure
After the production process has been planned by the supplier, the Bosch purchase department
wants to inspect the process FMEA through RB-MA (production, quality assurance, purchase
department) and wants to discuss the production process with the supplier.
Representation of a FMEA-request
Product, component, drafts and article numbers
RB-specification, target specification or lists of functionally important measures
and characteristics.
Notes on the significance of failure consequences and their rating, specific to the
application of products.
Date of FMEA and discussion
Form for FMEA-summary
Criteria for FMEA discussion at supplier
Submittal of FMEA-summary
The FMEA of the supplier is comparable to the RB-FMEA-methodics
Assessment of the significance (S), occurrence probability (O) and detection
probability (D)
Introduction of actions with responsible persons and deadline
Scope of FMEA
36 Further FMEA-applications

8 Further FHEA-app||cat|ons
|nterface FHEA
The interfaces between different systems, subsystems or components are analyzed in this type
of FMEA. The interface FMEA can be part of a system or design FMEA and is methodically a
system or design FMEA. It is done if required. The system development or product/component
development department is responsible for the internal interface FMEA. Initiation and
preparation of the external (with customer) interface FMEA by the RB system development or
product/component department is preferred. The FMEA is done by RB in cooperation with the
customer.
Log|st|cs FHEA
The methodology of the logistics FMEA is comparable to that of the process FMEA. The
logistics FMEA analyzes the logistical flow of products from receiving at Bosch until delivery
to the customer.
Logistics errors comprise a large portion of the customer complaints statistics. It is advisable to
analyze and evaluate these customer complaints with logistics FMEA.
Logistics procedure of a product
from packing at the end of the production line (usually end of process FMEA of the
assembly) to the delivery to the customer
from delivery of parts or materials to the receiving goods department at Bosch to the
delivery to the production line.
For the evaluation and assessment of the significance, the occurrence probability and the
detection probability, the rating charts of a process FMEA are used for the logistics FMEA as
well.
For the evaluation of the significance, the occurrence probability and the detection probability,
the rating charts of the process FMEA are used.
FMEA for software 37

H14 (43-08/98)
FHEA for software
Basic is the functional approach of the system FMEA . Analyzed can be, e.g.:
the functional requirements and effects of their non-fulfillment
Failures on interfaces
Failures of individual software parts
The following premises are valid for the use of FMEA for software
For reasons of efficiency, this method is only used in the early development phases
before coding
Documents are required that are described on an abstract level (e.g. HW and SW
block diagram or SW architecture model).
Failures which occur during coding are not individually analyzed.
Procedure and form are adopted without a change
In some cases, the rating charts have to be adapted.
With a FMEA for software, a risk evaluation concerning quality characteristics reliability and
safety is made. This method can be used in various software improvement/refinement levels.
So, in a top-down procedure, results of a higher level of the FMEA can be used again for the
level which is momentarily analyzed.
Software can also be seen as part of the system of a system FMEA
FHEA for contro| un|ts
System FMEA
Within the system FMEA of the whole system, the control units are regarded as black box. In
some cases, the main actions or in the system FMEA for electronic the component-level are
inspected.
Function, redundancies and their functional failures and effects on the whole system are
analyzed. In case of analyzing SW-functions, their intersections to the outside are analyzed. For
a detailed analysis, other test techniques have proved to be good in the software development,
e.g. reviews.
Apart from the system FMEA there are also failure simulations.
Design FMEA mechanic proportion
The procedure of the mechanic proportion corresponds to the known design FMEA.
Design FMEA electronic proportion
If the design of the electronic proportion is analyzed with FMEA, it has been succesful to build
the wiring plan corresponding to the functional groups and to treat the functional groups like
components.
In the electronic development, procedures like design-rules, tolerance analyses, checklists and
design-reviews have been also succesful.
38 Selection / prioritizing for FMEA

9 8e|ect|on|Pr|or|t|z|ng for FHEA
To reach a possibly high effectiveness, i.e. to recognize and prevent failure possibilities as far
as possible, a high level of specification is necessary for the functional analysis/system
structuring. To keep up effectiveness and efficiency during implementation, the use of selection
and tightening approaches is useful.
8e|ect|on accord|ng to app||cat|on cr|ter|a
A possibility for prioritizing /selection are application criteria. The more criteria listed above
apply to a component/process, the more important is a FMEA:
Customer requirements (FMEA)
Potential risk
Changed conditions for product usage
High depreciation in value when failure occurs
Basic new development of a product
Essential change
Parts important for functioning
Change of parts with correlation
Use of new materials, procedures
Recycling of problematic parts
Critical objective
Production transfer (new production line)
8e|ect|on w|th 0F0
Quality Function Deployment (QFD) is a method for quality planning and communication.
Above everything else, it serves a better and consistent planning of the individual quality
characteristics, from customer and development to production.
If a QFD is done for a product, it can be used for selection. Important and difficult
characteristics should have priority.
Further poss|b|||t|es for se|ect|on
Critical paths for critical failures of a system, component or process result from a system,
functional and failure analysis according to the top-down principle (functional and fault tree
analysis). The critical failures which are part of subsystems, components, characteristics or sub-
processes should have priority.
Relation to other methods 39

H14 (43-08/98)
10 Re|at|on to other methods
FHEA and 0ua||ty Funct|on 0ep|oyment (0F0)
Chronologically, the QFD method (Quality Function Deployment) comes before the application
of a FMEA. QFD aims at converting customer demands on a product into technical
characteristics necessary for development and production.
Core of QFD is the House of Quality. In this document, the customer requirements are put
opposite to the technical characteristics. And opposing requirements on the product are listed
(e.g. small case seize, loss of power). Also possible in the House of Quality is the comparison
to products of competitors. The level of meeting the individual characteristics results in a
product profile.
QFD should be used in the market analysis phases and conceptional phases. Apart from the
development and sales departments, the product planning and marketing department should also
be involved when applying this method.
QFD can lead to aspects important for following FMEA projects.
FHEA and va|ue ana|ys|s
The time of applying the value analysis (value engineering) mainly corresponds with the time
of starting the FMEA: from finishing the concept to the production-start. Both methods are
based on a systematic functional analysis but differ in their goals:
FMEA failure prevention
Value analysis minimizing costs
However, minimizing costs should not have a negative impact on quality. The actions of a
FMEA to prevent failures have an influence on the costs but do not always reduce costs.
Preventing potential failures often includes investments in advance.
To prevent unnecessary work, the use of both methods has to be coordinated.
40 Relation to other mathods

FHEA and Team 0r|ented Prob|em 8o|v|ng (T0P8)
Whereas the FMEA methodically looks into the future and analyzes the occurrence of
potential failures, the TOPS method (Team Oriented Problem Solving) analyzes real problems
whose cause is unknown. For such an analysis, it is necessary to look back into the past to
find out the reasons for the problems.
TOPS is based on a problem analysis just like Kepner-Tregoe. It was further developed in the
automobile industry (compare Ford 8D=eight disciplines). With the systematic procedure of
TOPS, the problem is described, potential causes are found out, the actual cause is identified
and certain actions are taken.
FMEA and TOPS complement one another:
To find out the reasons for a problem, a finished FMEA can be of help.
The basis for creating a new FMEA are the findings of problems with similar
products.
FHEA and rev|ew procedures
Review procedures are mainly used for software development, but they can also be used in
other areas (e.g. layout review ).
Just like a FMEA, reviews are done according to a fixed order of sequence.
Other than that, FMEA and review have the following in common:
Main objective is the early failure detection and thus the prevention of failures in the
course of the system development.
Interdisciplinary team work with moderator
The result of the working group is dependent on the competence (system knowledge
and experience) and creativity of the team members.
The following are the differences of review procedures and FMEA:
Time
Reviews can already take place during concept finding/selection. The making of a
FMEA makes sense if a system concept is at hand.
Analyzed characteristics
With a review, different quality characteristics like, e.g. usability or completeness (of
demands) are tested, dependent on the selected technique.
Sequence
Different review procedures are used dependent on the test object, the objective and
the planned test expense. The FMEA is done according to a defined sequential plan of
events whose main elements are risk analysis and risk evaluation.
Computer assistance 41

H14 (43-08/98)
11 6omputer ass|stance
|0 FHEA
IQ FMEA has been on the market since 1992 and is being continually developed further in
cooperation with users.
The five FMEA steps are supported by IQ FMEA through several editors who visualize the data
and guarantee an optimal access. IQ FMEA supports the Bosch form, and also the forms
according to VDA and QS-9000. It is possible to switch between the different forms.
Databases can be installed and administered in several languages. The language of the program
interface can be dynamically switched; at the moment, German, English, French and Spanish.
IQ-FMEA can export complete databases as SGML, forms can be stored in HTML-format.
Other export possibilities are (RTF, CSV, TXT, WMF, MPX).
Prerequisites:
Sibylle for Windows requires an IBM-compatible PC (Processor 486 or higher).
Hard-Disk with 10 MB space
VGA (800 x 600 or more)
12 MB memory for Win 3.x, 16 MB for Win 95, 24 MB for Win NT
MS-DOS Version 5.0 or higher (only for Win 3.x)
MS-Windows 3.1 or MS-Windows for Workgroups or Win 95 or NT
IQ-FMEA is available via the Intranet (at ZQF). Via the exchange-distribution list IQ-FMEA
User, information on IQ-FMEA are distributed. The news-group bosch.fmea.iqfmea is
available for exchanging information.
The seminar TQ012 offers information on the making of a FMEA with IQ-FMEA.
8|by||e for w|ndows
Sibylle for Windows is a program to prepare RB-standard documents for FMEA.
The RB-self-development can be received from your contact person or from the FTP-server in
Frankfurt.
Sibylle is a transitional solution until IQ-FMEA is introduced and it substitutes the MS-DOS
variant of the program.
Prerequisites:
Sibylle for Windows requires an IBM-compatible PC (Processor 486 or higher, at
least 4 MB memory). To print the FMEA, a postscript printer is recommended,
other printers are also possible.
For a graphical operating system, Microsoft Windows is required, at least Version
3.1. The typeface Courier New has to be installed as True Type Face (TTF).
Compatibility:
Sybille for Windows has command of the storage format of the MS-DOS variant.
So, FMEA between both programs can be exchanged.
42 Bibliography

12 |b||ography
References:
[CFG9000 (95)] Chrysler, Ford, General Motors (QS9000): Potential Failure Mode and
Effects Analysis (FMEA). 2. Auflage 1995, Carwin Continuous Ltd.
[K/VKK (95)] RB: K/VKK-Vertriebshinweis - FMEA-bergabe an Kunden. Stand:
26.1.1995.
[QFDa] RB: QFD - Quality Function Deployment - Mit besseren Produkten
schneller am Markt. (RB interne Unterlage - kann bei ZQF angefordert
werden).
[SWFMEA (96)] RB: Leitfaden fr die Durchfhrung von FMEA fr Software. Ausgabe 1.2
(15.2.1996) (RB interne Unterlage - kann bei ZQF angefordert werden).
[TOPS (89)] RB: T.O.P.S. / 8 D - Leitfaden zur Problemlsung in der Projektgruppe.
Ausgabe 8903/E5 (RB interne Unterlage - kann bei ZQF angefordert
werden)
[VDA4/2 (96)] VDA: Sicherung der Qualitt vor Serieneinsatz - Band IV/2 - System-
FMEA. 1. Auflage 1996, VDA.
Intranet:
[WWWzqf] ZQF: Web-Seite der Zentralabteilung Qualittssicherung (ZQ) -
Zentralstelle Qualittsfrderung (ZQF) - Methoden der Qualittstechnik -
FMEA - Software fr FMEA (Einstieg:
http://www.intranet.bosch.de/zq/zqf/index.htm).
Other literature:
[Mas (88)] Masing (Hrsg.), Handbuch der Qualittssicherung, 2. Auflage, Mnchen
1988
[MIL1629A (84)] Military Standard: MIL 1629A - Procedures for Performing a Failure Mode,
Effects and Critically Analysis. Notice 2, November 1984.
[IEC812 (85)] IEC: Publication 812 - Analysis techniques for system reliability -
Procedures for failure mode and effects analysis (FMEA). CEI 1985.
[BS5760 (91)] BSI: BS5760 - Reliability of systems, equipment and components - Part 5 -
Guide to failure modes, effects and criticality analysis (FMEA and
FMECA). Britisch Standard, 1991.
[DIN25448 (90)] DIN 25448 - Ausfalleffektanalyse (Fehler-Mglichkeits- und -Einflu-
Analyse). Mai 1990, DIN.
[DIN25424/1 (81)]DIN 25424 Teil 1 - Fehlerbaumanalyse - Methode und Bildzeichen.
September 1981, DIN.
[DIN25424/2 (81)]DIN 25424 Teil 2 - Fehlerbaumanalyse - Handrechenverfahren zur
Auswertung eines Fehlerbaums. April 19990, DIN.
[DIN25419 (85)] DIN 25419 - Ereignisablaufanalyse - Verfahren, graphische Symbole und
Auswertung. November 1985, DIN.
[QFDb] RB: QFD - Quality Function Deployment - Mit besseren Produkten
schneller am Markt - Information fr Fach- und Fhrungskrfte. (RB interne
Unterlage - kann bei ZQF angefordert werden).
Appendix 43

H14 (43-08/98)
13 Append|x
Append|x 1: Forms
- Cover sheet
- Form English
44 Appendix

Appendix 45

H14 (43-08/98)
46 Appendix

Append|x 2: 8hort descr|pt|on
What does FMEA stand for?
FMEA is short for Failure Mode and Effects Analysis.
What are the objectives of FMEA?
FMEA is a method to qualitatively assess the failure of individual components in systems,
products or processes. Objective of the FMEA is a systematic safety and reliability analysis.
Before the FMEA was introduced, it was only experiences of the past which were used when a
new product was developed, i.e. failures which had occurred during or after the production
were considered. The FMEA aims at the detection of potential failures before the production-
start, i.e. during planning, development and design.
Potential failures are prevented by an early detection of weak points and the introduction of
appropriate actions. Thus, the safety and reliability of the products is improved.
When is the FMEA used?
The FMEA is used for
New developments
Changes on the product or procedure
Products with requirements concerning the safety technique
New usage conditions for existing products
Processes and services
Characteristics of the FMEA
The following characteristics are typical for the FMEA method:
systematic procedure with working plan and form
functional oriented approach
interdisciplinary work group team work leads to creativity
preventive usage
The three FMEA types
Depending on the task or the unit, it is distinguished between system, process and design
FMEA.
The system FMEA analyzes the correct functional interrelation of the system components and
their connections. The goal is to avoid defects in system selection and layout and field risks.
The system requirements are the basis for the analysis. The system development department is
responsible for the system FMEA. Note: The system FMEA can also be used in software
development.
The design FMEA analyzes the design and layout of products/components according to the
specification to avoid design failures and process failures influenced by the design.
The process FMEA analyzes the process planning and performance for products/components
according to the drawing specifications to avoid planning errors and manufacturing defects.
Note: General processes like, e.g. services can also be analyzed with a process FMEA
Appendix 47

H14 (43-08/98)
What is done in the FMEA?
The individual steps in the FMEA are described in the FMEA-sequence plan (here shown as
excerpt):
0. Preparation and Planning
determine problem, problem definition and objective
team, sequential planning of action
materials for team
functional description
1. System structuring
numbering
component or working operations
2. Functional analysis
functions/characteristics
3. Failure analysis
potential types of failures
failure effects and failure causes
4. Risk assessment
failure prevention and failure detection
significance of failure effect (S)
occurance probability (O)
detection probability (D)
risk priority number RPN = S x O x D
5. Optimizing / Quality improvement
chose priority order of risks (analyze S, O, D and RPN)
determination of actions for improvement with R: and I:
introduction of actions for improvement
assess improvements (O,D)
When finishing a FMEA, it is important to give the members a feedback, to distribute the
documentation and, if necessary, to present the findings. For current products, actualizing the
FMEA on a regular basis is important.
Expense and prerequisites of a FMEA
A FMEA only fulfils its purpose if the requirements for completeness and correctness are
generally met.
The correctness of the analysis is, e.g. guaranteed by a systematic procedure, clear evaluation
criteria, critical assessments (worst case) and an extensive exchange of information within the
work team.
The completeness is reached by the analysis of all components or processes in order to
recognize all possible failure modes. To shorten the FMEA, individual components can be left
out if they are uncritical despite worst-case inspection.
A frequent argument against a FMEA is its expense. Whereas the expense can be easily
determined if the books are well kept, the savings cannot be exactly represented because
failures which were not made and prevented changes can hardly be calculated.
The advantages of the FMEA, e.g.
Prevention of failures in design and development
Reduction of costs for later product changes
systematic recording of expert knowledge to
prevent repeated failures shows that the prevention of failures at the beginning of the life of a
product can prevent higher costs at a later point in time.
48 Appendix

Append|x 3: 0uest|ons on the co|umns of the form
<ggf. Vertraulichkeitshinweis>
... -FMEA Page:
Department:
Quality Assurance Product:
Number:
FMEA-Number:
Date:
No. Component
or Process
Function Failure
modes
Failure
effects
C Failure
causes
Failure
prevention
Failure
detection
S O D RPN Actions
R:/I:
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
This document is the exclusive property of Robert Bosch GmbH. Without their consent it may not be reproduced or given to third parties.
Fig 4: The FMEA-form
Structuring
(2) Which components/processes are to be analyzed?
Functional analysis
(3) Which functions have to be fulfilled?
Failure analysis
(4) How could the function be negatively affected?
(5) Which are the consequences of the failure mode?
(7) Which failure causes are possible?
Risk assessment
(8a) Which actions are introduced to reduce consequences? (BM)
(10) How important is the consequence?
(8b) Which actions are introduced to prevent failures? (VM)
(11) How probable is the occurrence of the failure?
(9) Which actions to detect failures are taken?
(12) How probable is the detection of the failure?
(13) RPN = S x O x D (RPN)
Optimizing
(10 to 13) Where a high risks? (via S, O, D, RPN)
(14) Which actions are taken to reduce the risk?
(14) Who is responsible?
(14) Which deadline is planned?
Appendix 49

H14 (43-08/98)
|ndex
8D 40
Analyses 6
Base data 21, 28
Design FMEA 7, 8, 20, 21, 22, 23, 24, 25,
27, 28, 34, 35, 36, 37, 46
Detection probability 18, 36, 47
DoE 23
Failure analysis 29, 47
FMEA
Chronological integration of the FMEA
8
Functional analysis 47
Interface FMEA 34, 36
IQ-FMEA 14, 41
Kepner-Tregoe 40
Logistics-FMEA 36
Preparation 10, 20, 27, 34, 36, 47
Prioritizing 38
Process FMEA 7, 8, 11, 22, 27, 28, 29, 30,
31, 32, 34, 35, 36, 46
QFD 38, 39, 42
Rating charts 36
Relevance of failure consequence 16, 17,
23, 24, 31
Review 40
Risk evaluation 16, 23, 30, 40
Risk evalution 47
RPN 10, 18, 19, 23, 25, 26, 31, 33, 47, 49
Selection 38
Sequence plan 10, 14, 21, 28
Sibylle 41
Significance of failure consequence 47
Software
FMEA for software 37
Special characteristics 11, 15, 22, 29
Structuring 14, 21, 26, 28, 33, 34
System FMEA 7, 8, 13, 14, 15, 16, 18, 19,
20, 29, 37
Team work 9, 11, 46
TOPS 40
Updating 11
Value analysis 39
Robert Bosch GmbH
Zentralstelle
Qualittsfrderung (ZQF)
Responsible: Eilers
Telephone (07 11) 8 11-4 47 88
Telefax (07 11) 8 11-4 51 55
Edition 08.1998
Robert Bosch GmbH
Zentralstelle
Qualittsfrderung (ZQF)
Postfach 30 02 20
D-70442 Stuttgart
Telefon (07 11) 8 11-4 47 88
Telefax (07 11) 8 11-4 51 55
Stand 08.1998

Potrebbero piacerti anche