504 h0002 (gs 0002) - design fmea

Design FMEA
(Potential Failure Mode and Effect Analysis
in Design)
DPS Global Standard
504H0002, issue 6
Content Approved: 2015-03-26
New Format Implemented: 2016-01-
15
Strategic Owner:
Jeff Herrin
Content owner:
Global Engineering (PTL Team) / Author: Doug McCoy
Approved by:
Jeff Herrin
504H00002, Issue 6, Approved: 2015-03-26 Available to: Unrestricted 1/31
Danfoss Power Solutions Global Standard
504H0002
Potential
Failure Mode and Effect Analysis
in Design
(Design FMEA)

Content Page:
Scope and Introduction 3
Implementation 3
Team Effort 6
Design- and process FMEA 7
Development of a design FMEA 7
Content of the FMEA form
- Headings 8
- Function and Failure Modes 10
- Effects of Failure 11
- Severity of Failure 12
- Causes 14
- Occurrence 15
- Severity Occurrence Number (SON) 16
- Classification 17
- Design Verification 17
- Detection 18
- RPN, Risk Priority Number 18
- Recommended Actions 19
Follow-up 20
Change history 22
Terms and Definitions 23
Block Diagrams 24
Boundary Diagram 25
P-diagram (Parameter diagram) 26
DFMEA Form 27

Scope
This standard introduces thetopicpotentialFailureModeand Effect Analysis (FMEA) and gives a
general guidance in theapplicationofthetechnique.
An FMEA can bedescribed as a systemized group of activitiesintended to:
1) recognize and evaluate thepotentialfailureof a product or a process and its effects,
2) identifyactions which could eliminateor reduce thechance of thepotentialfailureoccurring,
and
3) document the process. It is complementary to thedesign process ofdefining positivelywhat a
design must do to satisfy the customer.
This standard presents thedesign FMEA which normallyfollows a system FMEA and itself is
followed bya process FMEA. System and process FMEA each have theirown standards
(504H0005 and 504H0006). The interactionbetween the threeis illustrated in thefigure on page
6.
Introduction
A design FMEA is an analyticaltechniqueutilized primarilyby a Design Responsible Engineer and
his / her teamas a means to assure that,to theextent possible, potentialfailuremodes and their
associated causes/mechanisms have been considered and addressed. End items, along with every
related system, subassembly and component,should beevaluated. In its most rigorous form, an
FMEA is a summary of an engineer’s and theteam’s thoughts(including an analysis ofitems that
couldgo wrong based on experience and past concerns) as a component,subsystem or system is
designed. Thissystematic approach parallels, formalizes and documents themental disciplines
that an engineer normallygoes through in any process.
The designFMEA supports thedesign process in reducing therisk offailures by:
 Aiding in theobjectiveevaluationof design requirements and design alternatives.
 Aiding in theinitialdesign for manufacturing and assembly requirements.
 Increasing theprobabilitythat potentialfailuremodesand theireffects on systems and
component operationhave been considered in the design/development process.
 Providing additionalinformationto aidin theplanning of thorough andefficient design
test and development programs.
 Developing a list of potentialfailuremodes ranked according to theireffects on the
“customer”, thus establishing aprioritysystem for design improvements as well as
development and validationtesting / analysis.
 Providing an open issue format for recommending and tracking risk-reducing actions.
 Providing future reference to aidin analyzing fieldconcerns, evaluating designchanges
and developing advanced designs.

FMEAImplementation
Because of a company’s commitment to continuallyimprove its productswhenever possible, the
need for using theFMEA as a disciplined technique to identifyand help to eliminate potential
concern is as important as ever. Case studies ofmajor complaintshave shown that a fully
implemented FMEA programcouldhave prevented many complaints.
Although responsibilityforthe“preparation” ofthe FMEA must, of necessity, beassigned to an
individual,FMEA input shouldbe a teameffort. A team ofknowledgeableindividualsshould be
assembled; e.g., engineers with expertise in Design, Manufacturing, Assembly, Service, Quality
and Reliability.
One of themost important factors for thesuccessful implementationofan FMEA program is
timeliness. It is meant to be a “before-the-event” action,not an “after-the-fact” exercise.
To achievethegreatest value, theFMEA must be donebefore a design or process failure mode
has been unknowingly designed into theproduct.
Up front time spent in doinga comprehensiveFMEA well, when productor processchanges
can be most easily and inexpensively implemented, will alleviate late change crises.
An FMEA can reduce oreliminate the chance of implementinga correctivechange which
could create an even larger concern.
Properlyapplied, it is an interactive processwhich is never ending.
There are three basic cases for which FMEAs are generated, each with a different scope or focus.
Case 1: New designs, new technology,ornew process. The scopeof the FMEA is the complete
design, technologyorprocess.
Case 2: Modificationsto existing design or process (hopefullythereis an FMEA for the existing
design or process). Thescope of theFMEA should focus on themodificationto designor
process, possibleinteractions due to themodification,and fieldhistory.
Case 3: Use of existing design in a new environment, locationor application. Thescope of the
FMEA is theimpact of thenew environment or locationonthe existing design.
The need for taking effective preventive/corrective actions, with appropriatefollow-up onthose
actions cannot be overemphasized.
Actions shouldbe communicated to all affected activities. A thoroughlythought-out andwell-
developed FMEA will beof limited value without positiveand effective preventive/corrective
actions.
The Responsible Engineer is in chargeof ensuring that all recommended actionshave been
implemented and adequatelyaddressed. TheFMEA is a living document and shouldalways
reflect thelatest relevant actions including those occurring after thestart of production.

The Responsible Engineer has several means of assuring that recommended actions are
implemented.
Theyshould include, but are not limited to the following,
a. Reviewing designs, processes and drawings to ensure that recommended actionshave been
implemented.
b. Confirming theincorporationof changesto design-, assembly- or manufacturing
documentation.
c. Reviewing design and process FMEAs, special FMEA applicationsandcontrol plans.
The figure beneath illustrates thedifference and the connectionof System FMEA, Design FMEA
and Process FMEA.
Thepreferred applicationmethodduring theProductDevelopment Program(PDP)isflow-down,
where thecustomerrequirements cascadedownfrom one FMEAlevel to thenext. FMEA is used
during theearlyconcept phase,aswellas thedetailed phase,to assess theriskof not delivering a
product to thecustomerwith theintended functions. It is also auseful means to document the
decision-making process,to identifypotentialKey Characteristics andSafetyCharacteristics(see
504H0004), andto identifyelementsofan analysisanda test plan. Theflow-up methodis
commonlyused with theEngineering Changeprocess. It is used to evaluatechangesto existing or
new applicationsforexisting systems,products,options,partsorprocesses,as well as astructured
problem-solving tool. ForEngineering ChangesthelocalEngineering Managermaydecide
whetheraSystemFMEA is needed orif theSeveritycanbe determined bytheDFMEAteam.

TheSeverityrating shouldreflect theseverityofthehighest knownFMEAlevelFailureEffect (i.e.
theFailureeffect in theProcess FMEAshouldbethesame words as theFailureEffect oftheSystem
FMEA).
Customer Defined
The definitionof“CUSTOMER” for a Design FMEA is not only the“END USER”, but also the
design Responsible Engineers /teams of the product or higherlevelassemblies, and/or the
manufacturing process responsible engineers in activitiessuch as Manufacturing, Assembly, and
Service.
Theidentificationofanendcustomer presentsa challengeforproductswithoutasingle,
designated using system. Thepotentialtypesoftypicalapplicationsmust be identified anda
SystemFMEA shouldbeperformed foreach onehaving different failuremodesandfailureeffect
severities.
When fully implemented,the FMEA disciplinerequires a Design FMEA for all new parts, changed
parts, and carryover parts in new applicationsorenvironments. An engineer from theresponsible
design activityinitiatesit,which for a proprietarydesignmay be thesupplier.
Teameffort
During theinitialDesign FMEA process, theResponsible Engineer is expected to directlyand
activelyinvolve representatives from allaffected areas. These areas shouldinclude, but are not
limited to,assembly, manufacturing, materials, quality,service and suppliers, as well as the
design area responsible for thenext assembly. The FMEA should bea catalyst to simulate the
interchange ofideas between thefunctions affected and thus promotea teamapproach.In
addition,for any (internal/external) supplier designed items, theresponsible design engineer
should be consulted.
TheFMEA shouldbeperformed byacross-functionalandmulti-disciplinedteamconsisting offour
to seven individualsasidentified inthefollowing table. Theteammembership willvarydepending
on theleveloftheFMEA, thetypeofproduct orsystembeing analyzed,andthetechnicalareas
involved. Assemblyand machining engineersshouldbeconsidered forteammembership whenthe
product orpart requires new manufacturing processes.
FMEA LEVEL
Role
System Design
(Vehicle) FMEA
Product Design
FMEA
Sub-Assembly Design
FMEA
Part Design
FMEA
Facilitator X X X X
ResponsibleProjectEngineer X X X X
Technical Experts(1 minimum required):
X X X X
Independent Design Engineer Optional X X X

ApplicationsEngineer X X Optional Optional
Assembly Engineer Optional Optional Optional Optional
Machining Engineer Optional Optional Optional Optional
Under no circumstances shouldthe FMEA, either partiallyortotally,bedoneby a single individual
or as a separatesmaller team with theexpectationthat theTeam will subsequently review the
FMEA for discrepancies. This review rarely occurs at a sufficient level of scrutiny, and it eliminates
an opportunityfor theTeam to use its potentialsynergyto identifynew issues or to reach a better
decision thantheycouldindividually.
Facilitatorexpertisehas significant impact on FMEA integrity.
Highlyskilled facilitatorsshouldbeinvolved in FMEAs of System, criticaland complex assemblies
or components. Facilitatorsin training shouldlead less critical or complexassembly or component
FMEAs.
Design FMEAand its Process counterpart
The Design FMEA is a living document and shouldbe initiated beforeor at design concept
finalization,be continuallyupdated as changes occur or additionalinformationisobtained
throughout thephasesof product development,and be fundamentally completed beforethe
productiondrawings are released for tooling.
Considering that manufacturing /assembly needs have been incorporated,theDesign FMEA
addresses thedesign intent and assumes thedesign will be manufactured and assembled to this
intent. Potentialfailure modes and/or causes or mechanisms which can occur during the
manufacturing or assembly process might beidentified in theDesign FMEA, but their
identification,effect and control are covered bythe Process FMEA.
The Design FMEA does not relyon process controls to overcome potentialweaknesses in the
design, but it does taketechnical/physicallimitsof a manufacturing and assembly process into
consideration, e.g.:
 Necessary mould drafts.
 Limited surface finish.
 Assembling space and access for tooling.
 Limited harden-abilityofsteels.
 Tolerances, process capability,processperformance.
The designFMEA can also takeinto considerationthe technical/physicallimitsofproduct
maintenance (service) and recycling, for example:
 Toolaccess
 Diagnosticcapability

 Materialclassification symbols (for recycling)
Developmentofa Design FMEA
Theprocess must bepreventionoriented.Theemphasismust beon preventive(analytical)design
controlsratherthandetective(test)designcontrols.Thereisno requirement forboth preventative
and detectioncontrolsifproperRPN's(Risk PriorityNumbers)can beachieved.
An FMEA shouldbedonein advanceof planned changesinorderto identifypotentialrisks.
TheDesignResponsibleEngineerhasat his or herdisposalanumber ofdocumentsthat willbe
useful in preparing theDesignpotentialFMEA.Theprocessbeginsbydeveloping alisting ofwhat
thedesignis expected to do,andwhat it isexpected not to do,i.e.thedesignintent.Customer
wants and needs, as maybedetermined fromsources as Customer Involvement,Product
Requirements Documents, known product requirementsand/ormanufacturing and assembly
requirements shouldbeincorporated.Thebetterthedefinitionofthedesired characteristics,the
easier it is to identifypotentialfailuremodesforcorrectiveaction.
A Design FMEA shouldbegin with a blockdiagramfor the system, subsystem, and/or component
being analyzed. An example blockdiagramis shown in AppendixB. The blockdiagramcan also
indicatetheflow of information, energy, force, fluid,etc.
The object is to understand thedeliverables(input) to theblock,the process (function) performed
in the block,and thedeliverables(output)from the block.
The diagramillustrates theprimary relationship betweenthe items covered in the analysis and
establishesa logicalorderto theanalysis. Copies of thediagramused in theFMEA preparation
shouldaccompany theFMEA.
As preliminary work and as a means to understand theproduct functions and thepossiblefailure
modes a Boundarydiagram and a P-diagram may beestablished as in AppendicesC and D.
In order to facilitatedocumentationoftheanalysis of the potentialfailuresand their
consequences, a form has been designed and is shown in AppendixE.
A templatefor this form is availableon the Danfoss Intranet ▶ DPS Segment ▶ Global Quality
Templates.
The templatewilluse English headings. TheDFMEA document may be done in thelocal
language. Theresponsible design team may berequested to translate it into English based on
customer or otherplant site needs.
Applicationoftheform is described below; pointsare numbered according to thenumbers on the
form shown in Appendix E.
Allproblemsarenot equallyimportant. It isimportant during aflow-downFMEAto identifythe
areas ofhighest riskusing customer statementsor theSeverityOccurrenceNumber - SON and to
prioritizeefforts,including additionalanalysis,testing,andanext levelFMEA. TheRisk Priority
Number (RPN) is commonlyused during a flow-up FMEA forexisting productsto identifyareasof

highest risk. SONis typicallyused fornew productsandpartssince detectionisoftenrated asa 10
dueto missing, incompleteornon-applicableanalysisandtesting,whereasRPN is typicallyused for
existing productssincesome detectionisusuallycompleteandapplicable.
When entering information in the FMEA form tryto limit theamount of words, but still, and that
is very important, make sure you are adequatelyspecific, so that persons not in theinitialFMEA
team can still understand the meaning.
The FMEA is said to be a living document, but it will often bekept alive by persons not involved in
thefirst issue.
Contentofthe form
1. FMEA number
Enter the FMEA document number, which may beused for tracking.
2. System, subsystemor componentname and number
Indicatetheappropriatelevelof analysis and enter thename and number of system,
subsystem, or component being analyzed.
The FMEA team members must decideon what constitutes a system, subsystem or
component for theirspecific activities.
The actualboundaries that dividea system, subsystem and component are arbitraryand
must be set bytheFMEA team.
Some descriptionsare provided belowand an example can beseen on thefigure on
page6.
SystemFMEA scope
A system can be considered to be made up of various subsystems. These
subsystems often have been designed bydifferent teams. Some typicalsystem
FMEA's might,for a car, cover the following systems: Chassis system, power train
system, interior system etc. Thus thefocus of the system FMEA is to ensure that
allinterfaces and interactions are covered among thevarious subsystems that
make up thesystem, as well as interfaces to othervehicle systems and to the
customer.
Subsystem FMEA scope
A subsystem FMEA is generally a sub-set of a larger system.
For example on a car thefront suspension subsystem is a sub-set of thechassis
system. Thus the focus of thesubsystem FMEA is to ensure that allinterfaces
and interactions are covered among thevarious components that make up the
subsystem.
Component FMEA scope
A component FMEA is generallyan FMEA focused on the sub-set of a subsystem.

For example a strut is a component of thefront suspension (which is a subsystem
of thechassis system).
The component will normally consist of several parts, which each has a number
of lines in theFMEA form.
3. Design responsibility
Enter OEM, department and division as appropriate.Also include thesupplier name if
known.
4. Preparedby
Enter the name, telephonenumber, company of engineer responsible for preparing the
FMEA.
5. Key date
Enter initialFMEA due date,which should not exceed the scheduled productiondesign
release date.
6. FMEA date
Enter the datetheoriginalFMEA was compiled,and thelatest revision date.
7. Core team
List the names of theresponsible individualsand departments which have the authorityto
identifyand/or perform tasks. (It is recommended that allteam members’ names,
departments, telephonenumbers, addresses, etc. be included on a distributionlist.)
8. Item
Enter the name and number of the itembeing analyzed.
9. Function
Enter, as concisely as possible thefunction of theitem being analyzed to meet thedesign
intent. Include information regarding the environment in which thissystem operates(e.g.
define temperature, pressure, humidityranges). If theitemhas more thanone function
with different potentialmodesof failure, list all thefunctions separately.
Brainstorming on thebasis offunction diagram,boundary diagram,part prints or actual
hardware, can be useful.
10. Potential Failure Mode
Potentialfailure modeis defined as themanner in which a component, subsystem, or
system couldpotentiallyfailto meet thedesign intent. The potentialfailuremode may
also be thecause ofa potentialfailure modein a higherlevelsubsystem, or system, or be
theeffect of a failure mode in a lower level component.
See theinteraction figure on page6.
List each potentialfailuremode for theparticularitem and item function. The assumption
is made that thefailure could occur, but may not necessarily occur. A recommended
starting point is a review of past things-gone-wrong, concerns reports, and group

“brainstorming”, as well as theP-diagram (appendixD).
Potentialfailure modes that couldonlyoccur under certain operating conditions(i.e. hot,
cold,dry, dusty, etc.) and under certain usage conditions (i.e. aboveaverage mileage,
rough terrain, not specified use, etc.) shouldbe considered.
Thereare two approachesto identifyingfailuremodes,functional(sometimesinNOR
referred to as technical)andhardware(sometimesinNORreferred to as physical).
Thefunctionalapproach shallbeused at thesystemandproduct levelsoftheFMEA.
Thehardwareapproach ispreferred at thepart level.
Eitherapproachisallowed at the sub-assemblylevel.
Functionalfailuremodescan bedescribed interms ofthe“Anti-Function”which couldbeas
mentioned beneath:
 Over achievefunction
 Underachievefunction
 Non function
 Intermittent function
 Degrading function
For example,thefunctionofabulbmay be“providelight at 5±0.2 candelafor50 hours.”
Thefailuremodesfor a light bulbmight theninclude:no light;dimlight;erraticblinking
light;gradualdimmingoflight;andlighttoo bright.
Hardwarefailuremodesshouldbedefinedinthephysicalmannerwhich thepart mayfailto
meet or delivertheintended function.

Typicalhardware failure modes couldbe, but are not limited to:
Cracked Sticking
Deformed Short circuited (electrical)
Loosened Oxidized
Leaking Fractured
Drift No support (structural)
No signal Intermittent signal
Inadequate signal Inadequate support (structural)
Harsh engagement Does not transmit torque
Disengages too fast Slips(does not holdfulltorque)
EMC / RFI
Note: Potentialfailure modes shouldbe described in “physical"or technicalterms, not
as a symptomnoticeablebythecustomer, as thiswill be covered as effect of
failure.
If you have a hardtime thinking of a failure mode - just use "no function" or "antifunction".
And then try to be more specific byidentifying as many causes as possible.
List all failure modes before proceeding to theidentificationoffailure effects.
11. Failure number
For easy identificationandrecognitionof failure modes, causes and verification, each
row / line shouldbe identified byits own current number.
12. Potential effects of failure
PotentialEffects of Failure are defined as theeffects of thefailure mode on thefunction
as perceived by thecustomer.
Describe theeffects offailure in terms of what thecustomer might noticeor experience,
remembering that thecustomer may be an internal customer as well as the ultimateend
user.
Stateclearlyif the function could impact safety or non-compliance to regulations.
The effects shouldalways be stated in terms of the specificsystem, subsystem or
component being analyzed.
Remember that thehierarchicalrelationship exists between thecomponent, subsystem,
and system levels.
For example, a part couldfracture, which may cause theassembly to vibrate, resulting in
an intermittent system operation. The intermittent system operationcouldcause
performance to degrade,and ultimatelyleadto customer dissatisfaction.The intent is to
forecast thefailure effects to theTeam’s levelof knowledge.
Typicalfailure effects couldbe, but are not limited to:
Noise Rough
Erratic operation Inoperative
Poor appearance Unpleasant handling

Unstable Operationimpaired
Intermittent operationLeaks
Thermal event Regulatorynon-compliance
13. Severity (S)
Severity is an assessment ofthe seriousness of theeffect (listed in the previous column) of
thepotentialfailuremode to the next component, subsystem, system, or customer if it
occurs. Severity appliesto theeffect only. A reductionin SeverityRanking index can be
effected through a design changethat makes thefailure modedisappear.
Severity shouldbe estimated on a “1” to “10” scale.
Assign allseverities before proceeding to theidentificationofpotentialcauses.
Suggested evaluation criteria:
High severity rankings can sometimes bereduced by making designrevisions that
compensate or reduce theresultant severity of failure. For example, "run flat tires" can
reduce the severity of sudden tire blow-out,and "seat belts" can reduce the severity of a
vehiclecrash.
The different divisions such as Hydrostatics,Work Function, and Controls or theirBusiness
Units might have extra guidelines, which give a more specific explanationof thecriteria of
therankings. Examples couldbe used as illustrations.
The guidelinescannot be contradictoryto the tablebelow.
Effect Criteria: Severity of Effect Ranking
Hazardous
without
warning
Very high severity ranking when a potentialfailuremodeaffects
safe operationand/or involves non-compliance with government
regulationwithout warning. Requires abnormal operator/ user
response.
Requires emergency actions.
10
Hazardous
with
warning
Very high severity ranking when a potentialfailuremodeaffects
safe operationand/or involves non-compliance with government
regulationwith warning. Such as audibleor visual alarms.
9
Very High Item inoperable,with loss of primaryfunctions. Noticeableto all
operators/ users.
8
High Item operable,but reduced level of performance. Customer
dissatisfied.
7
Moderate Item operable,but at reduced level of performance or life for a
primary function or loss of a non-primary function. Noticeableby
skilled operators/ users. Normal responses required from operator.
Customer experiences discomfort.
6
Low Item operable,but works at reduced level of performance.
Customer experiences some dissatisfaction.
5

Very Low Product works at reduced level of performance for a non-primary
function. Noticeableto askilled operator/ user.
Defects noticed bymost customers (> 75 %).
4

Effect Criteria: Severity of Effect Ranking
Minor Fit &Finish items do not conform. Product works at reduced level
of performance or life for a non-primary function. Defect
noticeablebyaverage customer. (50%).
3
Very Minor Defect noticeablebydiscriminating customer. (<25%)
No response required from operator/ user.
2
None No effect 1
You couldalso lookat it this way:
If theeffect of thefailure modegenerally willresult in a complaint from the customer, your
ranking should bein thearea from 5 - 10.
If it won't result in a complaint,you are in the area 1 - 4.
You may consider drawing lesser attentionto severities from 1 - 2, meaning that when you
have established thislow ranking, you cancel further work in this line, at least for the time
being.
If theeffect of a failure mode is rated 9 or 10, special effort should be madeto identifyas
many potentialroot causes as possible.
If we have a severity ranking of 8 - 10 and low rankings (1 - 2) for occurrence and detection,
you stillshouldconsider whetherthefailure modeor thefailure cause could appearduring
manufacturing, and if so pass it on to process FMEA bywriting process FMEA in the
recommended actions column.
A severity rating of 9 or 10 will normally callfor a design changethat makes thefailure
mode disappear. If a design change seems impossible(thefailure mode is an integralpart
of thedesign), specialinitiatives must be taken.
According to 504H0004, a severity rating of 9 or 10 for a function and its corresponding
failure mode requires that thecontributing characteristic(s)be labeled as a ‘Safety
Characteristic(s)’.
Special initiatives for the severity rating of 9 or 10:
The preferred way to address a nine or ten-point severity rating is to changethedesign. If
no immediatedesign changes are possible, thedesign FMEA team must ensure that these
ratings are specifiallydiscussed and approved during thedesign review process.
One solution couldbe a totalredesignof the product.
Another solutioncould bea remedial provision at the system level (e.g. redundancy or
failsafe). This remedialmeasure must be strongly pointed out in thetechnicalinformation
papers accompanying theproduct,as a warning. Documentatione.g. in a Product

Specifikationneeds to ensure that SeverityRankings of 9 and 10 flow up into future S-
FMEAs.
In some cases it might be necessary to put a warning labelon the product or maybeon the
equipment where theproduct is utilized.
Finally, if a rating of 9 or 10 in severity cannot be eliminated or reduced, it must be
accompanied byrelativelylow rankings of Occurrence and Detection(described in later
sections), resulting in an acceptableRPN (also described in a later section). These failure
modes must also benoted and passed along to theprocess FMEA to ensure that the
productionprocess is sufficiently safeguarded.
D.H. Stamatisin his book"FailureMode Effect Analysis" page35, points to a set of rules:
Assessment rating Failure situation Action taken
S O D
1 1 1 Ideal situation (goal) No action (N/A)
1 1 10 Assured mastery N/A
10 1 1 Failure does not reach user N/A
10 1 10 Failure reaches user Yes
1 10 1 Frequent fails, detectable, costly Yes
1 10 10 Frequent fails, reaches the user Yes
10 10 1 Frequent fails with major impact Yes
10 10 10 Trouble! Yes, Yes, Yes, Yes
14. Potential Causes/Mechanisms of Failure
Potentialcause of failure is defined as an indicationof a design weakness, the
consequence of which is the failure mode.
List, to theextent possible,every conceivablefailure cause and/or failure mechanism for
each failure mode.The cause/mechanism shouldbe listed as conciselyand completelyas
possibleso that remedial efforts can be aimed at pertinent causes.
Typicalfailure causes may include, but are not limited to:
Incorrect material specified
Inadequate design life assumption
Over-stressing
Insufficient lubricationcapability
Inadequate maintenance instructions
Improper maintenance instructions
Poor environment protection
Incorrect algorithm
Improper tolerancespecified

Improper frictionmaterial specified
Improper surface finish specification
Typicalfailure mechanisms may include, but are not limited to:
Yield Creep
Fatigue Wear
Materialinstability Corrosion
Electro migration Chemical oxidation
15. Occurrence(O)
Occurrence is thelikelihoodthat aspecificcause/mechanism (listed in the previous
column) will occur during thedesign life.
Preventing or controlling one or more of thecauses/mechanisms of thefailure mode
through a designchange or design process change is theonly way a reduction in the
occurrence ranking can be effected. Design process change couldbe through Design
Review, Design Guide or Design Checklist. Controlling couldbe through extended
calculationsand tests, or specialwork to improve theEngineering organisation’s
fundamental knowledgeof thecause of failure.
Estimatethe likelihood ofoccurrence ofpotential failure cause/ mechanism on a “1” to
“10” scale. In determining thisestimate questions such as thefollowing shouldbe
considered:
 What is theservice history/fieldexperience with similar componentsor subsystems?
 Is component carryover or similar to a previous level component or subsystem?
 How significant are changes from a previous level component or subsystem?
 Is component radicallydifferent from a previous level component or subsystem?
 Is thecomponent completelynew?
 Has thecomponent applicationchanged?
 What are theenvironmental changes?
 Has an engineering analysis been used to estimate theexpected comparable
occurrence rate for the application?
 Have preventive controlsbeen put in place?
A consistent occurrence ranking system, as seen in thetablenext page, shouldbe used to
ensure continuity.
Occurrence(O) Suggested Evaluation Criteria
The column “Possible failure rates” fits for a process FMEA, but is difficult to use in the
context ofengineering causes of failure modes.

Instead use thearea of “Occurrence likelihood”andamong thefour columns find theone
that best fits with theappropriatesituation.
Hereafter you have maximum threefigures to choosefrom, which you must do to thebest
of your ability.

Probability
of Failure
Possible
Failure
Rates
Rating
Criteria: Occurrence Likelihood
Calculation
and Analysis
Design Margin
Design
Experience
Lab and Field
Test Results
Deviation
Very High,
Failure is
almost
inevitable
>1 in 2 10 Not possible Unknown Similar designs
in similar
applications
frequently show
problems
Typically not
approved
1 in 3 9
High,
Repeated
failures
1 in 8 8 Possible, with
low correlation
to test results
Small, not well
established or
understood
Similar designs
in similar
applications
sometimes
have problems
1 in 20 7
Moderate,
Occasional
failures
generally
acceptable
correlation to
test results
Small, somewhat
established and
understood
Some problems
detected in first
round of
testing, but
easy to
overcome with
help of analysis
Typically
approved for
small
differences,
<33% of
tolerance range
1 in 400 5
1 in 2000 4
Low,
Relatively
few failures
high level of
correlation to
test results
Large, somewhat
established and
understood
Proven design
which typically
passes first
round of testing,
similar designs
in similar
applications do
not have
problems
Typically
approved for
larger
differences, up
to 100% of
tolerance range
1 in 150.000 2
Remote 1 in 1.500.000 1 Common, with
high level of
correlation to
test results
Large, well
established and
understood
Design Margin couldalso be interpreted as DesignExperience which makes it clear that
theexperience ofthe design teamis themain influence for theoccurrence.
The column Lab and Field Test Results means, that whatever testing we have done at the
time we do theDFMEA, theywill addto our knowledgeand thereforeinfluence the risk
that we design a failure mode into the product.
In such cases we may givethe same ranking to Occurrence and Detection.
16. Severity OccurrenceNumber (SON)
The severity rating can be multiplied with theoccurrence rating to form theSON rating.
SON can be useful in the early designphases, where detectionis not yet specified.
In thisway theSON value is an earlyindicatorof therelative levels of risk in a design.

If a function and its corresponding failure mode obtainsa severity value of 5 or greater and
an occurrence value of 4 or greater, 504H0004 requires that that thecharacteristic(s)
affecting that function be labeled as a ‘KeyCharacteristic(s)’. This shouldthen be stated
on thedrawing or on similar relevant documents through thedesignationofa pentagon
with a ‘K’ inside it. It is possibleto reduce theamount of “K” through further analysis
utilizing the“loss function” as described in 504H0004.
A function and its failure modecan, however, beformed of several connected dimensions
on a drawing or drawings. In such cases it must be very carefully considered
which of thedimensions shall have thesymbolK.
17. Classification
This column can be used to the choiceofthe team. It may beused to classify any special
product characteristics (e.g., Keyor Safety)for components, subsystems, or systems that
may require additionalprocesscontrols. Theclassificationcan originatefrom customer
demands or from theS and O values as described in 504H0004.
Any item deemed to require special process controls shouldbe identified on theDesign
FMEA form with the appropriatecharacterorsymbol in theClassification column and
shouldbe addressed in the recommended actions column.
Each item identified as above in theDesign FMEA shouldhave thespecial process controls
identified in theProcess FMEA.
It might also be used as an explanationof a high score for a failure modethat will never
reach a customer and thus shouldhave a low score. But being a failure modethat is
discovered latein the productionprocess and thereforeis expensive to correct means it is
given a high score. That couldbe marked with an E for economy in theclassification
column.
18. Current Design Verification
List the prevention, detection,designvalidation/verification(DV),or otheractivities that
have been completed andthat will assure the design adequacyfor thefailure modeand/or
cause/mechanism under consideration.
Current verifications (e.g. roadtesting, design reviews, fail-safe (pressure relief valve),
mathematicalstudies, rig or labtesting, feasibilityreviews, prototypetest,fieldtesting)
are those that havebeen or are being used with thesame or similar designs.
The teamshould always be focused on improving designverifications; for example,
creating new system tests in thelab, or creating new system modeling algorithms,etc.
There are three typesof Design Verifications/Features to consider; thosethat:
(1) prevent the cause/mechanism or failure mode/effect from occurring, or reduce their
rate of occurrence,
(2) detect thecause/mechanism and leadto corrective actions,
(3) detect thefailure mode.

The preferred approach is to first use type(1) verifications if possible; second, use thetype
(2) verifications; and third,use the type(3) verifications.
The initialoccurrence rankings will be affected by thetype(1) verifications provided they
are integrated as part of thedesign intent.
The initialdetectionrankings will bebased upon thetype(2) or type(3) current
verifications, provided theprototypesandmodels used are representative of design
intent.
You can distinguish between preventive and detectivecontrols byusing eitherthe
prevention or detectionpart of thedesign verification column.
Once the designverifications have been identified and ranked, review all verifications to
determine if any of thepreceding occurrence ratings need to be revised.
19. Detection (D)
Detectionis an assessment of theabilityoftheproposed type(2)current design
verifications, listed in column 18, to detect a potentialcause/mechanism (design
weakness), or abilityoftheproposed type(3)current designcontrols to detect the
subsequent failure mode, beforethecomponent, subsystem, or system is released for
production.In order to achievea lower ranking, generally theplanned design verifications
(e.g., preventative, validation,and/or verification activities)have to be improved.
In theearly stageof a project thedetectiondiscussion willresult in parts of theAnalysis
Plan (=Prevention) and theTest Plan (=Detection) perPDP.
Detection, Suggested Evaluation Criteria:
Detection Likelihood of Detection by Design Verification Ranking
Absolute uncertainty Design Verification will not and/or cannot detect a potential
cause/mechanism and subsequent failure mode; or there is no
Design verification.
10
Very remote Very remote chance the Design Verification will detect a
potential cause/mechanism and subsequent failure mode.
9
Remote Remote chance the Design verification will detect a potential
cause/mechanism and subsequent failure mode.
8
Very Low Very low chance the Design verification will detect a potential
7
Low Low chance the Design verification will detect a potential
6
Moderate Moderate chance the Design verification will detect a potential
5
Moderately high Moderately high chance the Design verification will detect a
potential cause/mechanism and subsequent failure mode.
4
High High chance the Design verification will detect a potential
3
Very high Very high chance the Design verification will detect a potential 2

Almost certain Design verification will almost certainly detect a potential
1
Remember - theDetectionranking can also influence theOccurrence rating.
See section 21 for explanation.
20. Risk Priority Number(RPN)
The Risk PriorityNumber is themultiplicationoftheSeverity(S), Occurrence (O),and
Detection(D)ranking
RPN = (S) x (O) x (D)
The Risk PriorityNumber is a measure of design risk. Thisvalue may beused to roughly
rank order theconcerns in thedesign (e.g., in Pareto fashion). TheRPN will be between
“1” and “1000”. In employing theDFMEA as a continuous improvement tool,for higher
RPNs, theteam shouldundertake efforts to reduce thiscalculated risk through corrective
action(s). In general practice, regardless of theresult ofthe RPN, specialattentionshould
be given when Severity is high - meaning 9 or 10.
21. Recommended Action(s)
When failure modes have been rank ordered byRPN, corrective action shouldbe first
directed at thehighest ranked concerns and criticalitems. This means ranking
A: Severity9 or 10
B: High Severityand Occurrence rating (“K”, see 504H0004)
C: RPN above100
The intent of any recommended actionis to reduce any one or all of theoccurrence,
severity, and /or detectionrankings. In general practicewhen theseverity is a 9 or 10,
specialattentionmust be given to ensure that therisk is addressed through existing
design controls for preventive / corrective action(s)regardless of theRPN. In allcases
where the effect ofan identified potentialfailuremodecouldbe a hazard to theend user,
preventive corrective actionsshould beconsidered to avoidthefailure mode by
eliminating,mitigating,or controlling thecause(s). In a situation where theteam has been
unable to reduce an RPN below 100 on a severity 9 or 10 failure mode, approvalmust be
specificallygranted in the design review process.
An increase in design validation/verificationactionswill result in a reductionin the
detectionranking. A reductionin theoccurrence ranking can be effected only by
removing or controlling one or more of thecauses/mechanisms of the failure mode
through a designrevision or improved fundamental knowledge.
In some cases a reduction in theDetectionrating can also improve theOccurrence rating
as new knowledgefrom calculationsor testing can give thedesigner a more firm ground
for his / her considerations.

Only a design revision can bring about a reductionin theseverity ranking. Actions such as
thefollowing shouldbe considered, but are not limited to:
 Design of experiments (particularlywhen multipleor interactivecauses are present).
 Revised Test Plan.
 Revised Design, geometryand/or tolerances.
 Revised MaterialSpecification.
The primaryobjectiveof recommended actions is to reduce risks and increase customer
satisfactionby improving thedesign.
If no actions are recommended for a specific cause, thiscouldbe indicated byentering a
“NONE” in thecolumn.
On page35 in his book,Stamatispointsat a number of corrective actions and their
influence on S, O and D.
Corrective actions S O D
Redesign the product Y Y Y
Improve current control N N Y
Change material parts Y N Y
Change the application Y Y Y
Change the field environment Y Y Y
Improve reliability program Y N Y
Improve employee training N N Y
Implement FMEA program Y Y Y
Implement SPC program N N N
Improve quality plan N N N
(Y= Yes, N= No)
This column could also be used for theremark "Process FMEA" which means that aFailure
Modehas been identified which originatesfrom the product designbut which can also
appearin theproductionprocess.
22. Responsibility (for the recommended action)
Enter the organizationandindividual responsible for recommended actionand thetarget
completiondate.
23. ActionsTaken
After an actionhas been implemented, enter a brief descriptionof theactual actionand
effective date.

24. Resulting RPN
After the corrective actionhas been identified,estimateand record theresulting Severity,
Occurrence, and Detectionrankings. Calculate and record theresulting RPN. If no actions
are taken, leave the “Resulting RPN” and related ranking columns blank.
All resulting RPN(s) shouldbe reviewed and if further actionis considered necessary,
repeat steps 20 through 23.
If it is considered appropriate,therankings can beestimated before thecorrective action
has been implemented and the resulting RPN calculated.
The purposeis to estimate if therecommended actionwill give a satisfactorylow score.
Follow-Up
The Design Responsible Engineer is responsible for assuring that allactions recommended have
been implemented or adequatelyaddressed.
The FMEA is a living document and shouldalways reflect the latest design level, as well as the
latest relevant actions, including those occurring after start of production.
The designresponsible engineer has several means of assuring that concerns are identified and
recommended actions are implemented. Theyinclude, but are not limited to:
 Assuring designrequirements are achieved.
 Review of engineering drawings and specifications.
 Confirmation of incorporationto assembly/manufacturing documentation.
 Review of Process FMEAs and Control Plans.
References: PotentialFailure modeand Effects Analysis (FMEA)
Reference manual, February 1995 by Chrysler, Ford and General Motors
Fourth editionof2008. (Technicalequivalent of SAE J 1739)
D.H. Stamatis"Failure Mode Effect Analysis" Second edition.
ASQ QualityPress.

CHANGE HISTORY
Date Issue
No.
Description of Change
2004-03-24 A OriginalRelease Date
2004-08-18 B GS-0003 integrated into GS-0002.
Same severity ranking to be used in D-, S- and P-FMEA.
Exploitationoffacilitatorexpertise.
Actions to be taken if severity rating = 9 or 10.
Critical and keySON to be specified on drawings.
Corrective actionsrecommended by D.H. Stamatis
2005-07-07 C Severity ranking: Customer complaint added. "Theteam should
agree ..." has been taken awayas it can cause confusion (the same
goes for Occurrence and Detection)
Occurrence Criteria: Design margin/design experience and
laband field test results.
Illustrations to Classification.
Resulting RPN: Estimating corrective actions.
2009-08-10 D Allows for designs with severity 10 failure modes as long as
occurrence and detectionare relativelylow.
Updated forchanges to GS-0004 concerning Key and Safety
characteristics and howtheyare determined.
Softens thelanguage ofrequired actions when RPN > 100 in
accordance with AIAG’s 4th Editionof FMEA standard.
2014-08-14 Minor
Change
Changed Administrator from Christine Holst to Crystal Burns
2015-03-26 E Changed references from PDLP to PDP and from QFD to Customer
Involvement.
2016-01-15 6
To ensure a uniformed and consistent format for Danfoss Power
SolutionsGlobalStandards,we are adopting theuse of the Danfoss
GlobalStandardsTemplateas well as theterminologyand
numbering system currently used in theDanfoss Standards
Repository.

Appendix A
FMEA Terms and Definitions
Boundary Diagram – A graphical representation of the system, product, sub-system, sub-assembly, or product that
shows what is being analyzed (e.g. parts list and/or layout), what its interfaces are (e.g. other parts, sub-systems,
products), and what itsinputs and outputs are. See Appendix C for an example.
Brainstorming – A method of shared idea-generation or problem solving in which all team members spontaneously
contribute ideas.
Characteristic – A measurable parameter or dimension of a product distinguished by its numerical value and
measurable units.
Customer – Customers exist at all levels of the FMEA. The end user of a system is called the end customer.
Design Intent – What a given system, product, sub-assembly, sub-system, or part is expected to do or not to do.
Design Margin - The additional performance capability above the requirements to compensate for uncertainties.
Detection – A past-oriented design control strategy that attempts to identify unacceptable output or results after the
system, product, sub-assembly, sub-system, or part is produced.
Facilitator – A person with no vested interest in the design being analyzed who is knowledgeable about the FMEA
process and is able to guide the Core Team.
Failure Mode – The manner in which a system, product, sub-system, sub-assembly, or part could potentially fail to
meet or deliver the intended function, including complete function failure, partial failure, intermittent failure, failure
over time, or over-performance of a function. The failure mode may also be the cause of a potential failure mode in a
higher FMEA level.
Function – What a system, product, sub-system, sub-assembly, or part is intended to do.
Functional Block Diagram – A graphical representation of the functional relationships within a system, product, sub-
system, or sub-assembly. Each block represents one element, along with its inputs, outputs, and transfer function.
See Appendix B for an example.
Occurrence Ranking – A numerical value corresponding to the likelihood of a design error.
P-Diagram – A diagram that shows the inputs, control factors, error states, ideal functions, and noise factors for a
system, product, sub-assembly, or sub-system. Noise factors are categorized as: piece-to-piece variation;
deterioration or degradation over time; other systems; customer usage or duty cycle; and the environment. See
Appendix C for an Example.
Part Level FMEA – An FMEA that focuses on a sub-set of a product, sub-system, or sub-assembly that is comprised
of a single piece of hardware or software. A level of detail where a design is considered not to be further subdivided
into separate components. May also be referred to as a component level FMEA.
Product Level FMEA – An FMEA that focuses on the product, such as a pump, motor, or valve, that is sold by Danfoss
power Solutions for use in a system.
Recommended Action – Any action intended to mitigate risk by reducing the severity, occurrence, detection, or all
three ratings.
Risk Priority Number (RPN) – The multiplied product of the severity, occurrence, and detection ratings.
Severity Occurrence Number (S.O.N.) – A measure of design risk that is the multiplied product of the severity and
occurrence rankings.
Severity Ranking – A numerical value corresponding to the seriousness of the effect of a potential failure mode on
the upper levels of the FMEA.
Sub-Assembly Level FMEA – An FMEA that focuses on a group of parts from a product that fulfills a specific sub-set
of product functions.

Sub-System Level FMEA – See Sub-Assembly level FMEA.
SystemLevel FMEA – An FMEA that focuses on a combination of connected elements that fulfills a specific set of
functions, typically for a vehicle.
Appendix B
Example of a Block Diagram for a Flashlight.
2
3
4 1 4
4
5 5
Components Attachingmethod
A.Housing 1.Slip fit
B. Batteries (2C-cell) 2.Rivets
C.On/OffSwitch 3.Thread
D. BulbAssembly 4.Snap fit
E. Plate 5. Compressive fit
F.Spring
FunctionalBlockDiagram Example – Mechanical Displacement Control
Switch
ON / OFF
C
Housing
A
Batteries
B
Spring
F
Plate
E
Bulb
assembly
D

Appendix C
Boundary Diagram Example - Hydromodule
Input
Shaft
Rotation ()
+
-


x
x Q Q 
x
Input
Shaft
Rotation ()
+
-


x

x
x Q Q 
x

Appendix D
P-Diagram Example - Hydromodule
Causes (Noise Factors)
1. Piece toPiece Variation
a. Kits
b. Control
c. Loop flushing
d. Yokeseal
e. Assembly process
f. Torqueon fasteners
g. Sweetpoint location
h. Yokerunning faceflatness
i. Speed sensor
2. OtherSystems
a. Control Valve
b. System 1
c. System 3
d. Housing
e. Cooler Circuit
f. TransHarness
g. Ring
h. Sun
i. Housing
j. Engine
3. CustomerUsage/Duty Cycle
a. Overload
b. Aftermarket changes
c. Poor servicepractices
d. Poor oil quality
e. Infrequent oilchanges
f. Heavy sustained transport
g. Extremeduty cyclein high heat
h. Trash in/blocked oil cooler
i. Heavy sustained tillage
4. Deterioration/degradation
over time
a. Self generated debris
b. Bearing wear
c. Yokeseal wear
d. Cam follower wear
e. Kit wear
f. Synch joint wear
5. Environment
a. Contamination
b. Air
c. High ambient temperatures
d. High oil temperatures
Inputs
a. Control chargepressure/flow
b. Lubepressure/flow
c. Loop chargepressure/flow
d. FUshaft torque/speed
e. Mount load/position
f. VUcontrol pressure/flow
HYDROMODULE
Ideal Functions
a. Supply transmission torque/speed ratio
independent of load andproportional
to hydraulic signal pressure(transmit
power)
b. Meet noiserequirements
c. Meet efficiency requirements
d. Providehydraulicsupply/return
connections
e. Support gears
f. Provideiso mount connections
g. Trap isolator/mount inevent ofisolator
failure
h. Routelubeoilto gearsand bearings
i. Provideanglesensor interface
Design Verification
a. Hydro Specification
b. GPM program deliverables
c. Part and Assy Drawings
d. HPP-82, HPP-85, HPP-117, HPP-122,
HPP-123, HPP-125, HPP-124,HPP-132,
HPP-133, HPP-134, HPP-135, HPP-137
Failure Modes
a. Does not Supply transmission
torque/speed ratio independent of
load and proportional to hydraulic
signal pressure(transmit power)
b. Failsnoiserequirements
c. Failsefficiency requirements
d. Does not providehydraulic
supply/return connections
e. Does not support gears
f. Does not provideiso mount
connections
g. Does not trap isolator/mount in event
of isolator failure
h. Does not routelubeoil to gearsand
bearings
i. Does not provideanglesensor
interface
Ifyou donot wantto make the full P-diagram, at least list all functionsforthe product,the sub-assemblies,
and foreach part ofthe product.
Foreach functionofthe part, list all possible failure modes, bearing in mind the total amountof functions.

This is the least preparation youcando, andit is a must.
Appendix E
Of
Prepared by
4
Prevention Detection
8 9 10 11 12 13 14 15 16 17 18 18 19 20 21 22 23 24 24 24 24
Severity
Occurrence
Detection
RPN=SxOxD
RPN=SxOxD
Recom-
mended
Actions
Responsible
person
Completion
date
Actions
taken
SON=SxO
Classific.
Design
Verification
Detection-D
Potential
Effect(s) of
Failure/
Customer
Perception
Severity-S
Potential
Cause (s)
of Failure
Occurrence-O
Item/
Part
name Part Function
Potential
Failure
Mode
Technical/
Physical
FailureNo.
FMEA date
6
Page
Revision date
6
Key date
5
Name
2
Design FMEA No.
1
Description
2
Core Team
7
Design responsible
3

504 h0002 (gs 0002) - design fmea

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 504 h0002 (gs 0002) - design fmea

Similar to 504 h0002 (gs 0002) - design fmea (20)

Recently uploaded

Recently uploaded (20)

504 h0002 (gs 0002) - design fmea