FMEA - Failure Mode and Effects Analysis

1. Failure mode and effects analysis
Failure Mode and Effects Analysis (FMEA) was one
of the first systematic techniques for failure analysis. It
was developed by reliability engineers in the 1950s to
study problems that might arise from malfunctions of mil-
itary systems. An FMEA is often the first step of a sys-
tem reliability study. It involves reviewing as many com-
ponents, assemblies, and subsystems as possible to iden-
tify failure modes, and their causes and effects. For each
component, the failure modes and their resulting effects
on the rest of the system are recorded in a specific FMEA
worksheet. There are numerous variations of such work-
sheets. An FMEA is mainly a qualitative analysis.[1]
A few different types of FMEA analyses exist, such as
• Functional,
• Design, and
• Process FMEA.
Sometimes FMEA is extended to FMECA to indicate
that criticality analysis is performed too.
FMEA is an inductive reasoning (forward logic) single
point of failure analysis and is a core task in reliability
engineering, safety engineering and quality engineering.
Quality engineering is specially concerned with the “Pro-
cess” (Manufacturing and Assembly) type of FMEA.
A successful FMEA activity helps to identify potential
failure modes based on experience with similar products
and processes - or based on common physics of failure
logic. It is widely used in development and manufactur-
ing industries in various phases of the product life cycle.
Effects analysis refers to studying the consequences of
those failures on different system levels.
Functional analyses are needed as an input to deter-
mine correct failure modes, at all system levels, both for
functional FMEA or Piece-Part (hardware) FMEA. An
FMEA is used to structure Mitigation for Risk reduction
based on either failure (mode) effect severity reduction or
based on lowering the probability of failure or both. The
FMEA is in principle a full inductive (forward logic) anal-
ysis, however the failure probability can only be estimated
or reduced by understanding the failure mechanism. Ide-
ally this probability shall be lowered to “impossible to oc-
cur” by eliminating the (root) causes. It is therefore im-
portant to include in the FMEA an appropriate depth of
information on the causes of failure (deductive analysis).
1 Introduction
The FME(C)A is a design tool used to systematically ana-
lyze postulated component failures and identify the resul-
tant effects on system operations. The analysis is some-
times characterized as consisting of two sub-analyses, the
first being the failure modes and effects analysis (FMEA),
and the second, the criticality analysis (CA).[2]
Success-
ful development of an FMEA requires that the analyst
include all significant failure modes for each contribut-
ing element or part in the system. FMEAs can be per-
formed at the system, subsystem, assembly, subassembly
or part level. The FMECA should be a living document
during development of a hardware design. It should be
scheduled and completed concurrently with the design.
If completed in a timely manner, the FMECA can help
guide design decisions. The usefulness of the FMECA as
a design tool and in the decision-making process is de-
pendent on the effectiveness and timeliness with which
design problems are identified. Timeliness is probably
the most important consideration. In the extreme case,
the FMECA would be of little value to the design deci-
sion process if the analysis is performed after the hard-
ware is built. While the FMECA identifies all part failure
modes, its primary benefit is the early identification of
all critical and catastrophic subsystem or system failure
modes so they can be eliminated or minimized through
design modification at the earliest point in the develop-
ment effort; therefore, the FMECA should be performed
at the system level as soon as preliminary design infor-
mation is available and extended to the lower levels as the
detail design progresses.
Remark: For more complete scenario modelling another
type of Reliability analysis may be considered, for exam-
ple fault tree analysis(FTA); a deductive (backward logic)
failure analysis that may handle multiple failures within
the item and/or external to the item including mainte-
nance and logistics. It starts at higher functional / system
level. An FTA may use the basic failure mode FMEA
records or an effect summary as one of its inputs (the ba-
sic events). Interface hazard analysis, Human error anal-
ysis and others may be added for completion in scenario
modelling.
1.1 Functional analysis
The analysis may be performed at the functional level un-
til the design has matured sufficiently to identify specific
hardware that will perform the functions; then the analy-
1

2. 2 2 BASIC TERMS
sis should be extended to the hardware level. When per-
forming the hardware level FMECA, interfacing hard-
ware is considered to be operating within specification.
In addition, each part failure postulated is considered to
be the only failure in the system (i.e., it is a single failure
analysis). In addition to the FMEAs done on systems to
evaluate the impact lower level failures have on system
operation, several other FMEAs are done. Special atten-
tion is paid to interfaces between systems and in fact at all
functional interfaces. The purpose of these FMEAs is to
assure that irreversible physical and/or functional dam-
age is not propagated across the interface as a result of
failures in one of the interfacing units. These analyses
are done to the piece part level for the circuits that di-
rectly interface with the other units. The FMEA can be
accomplished without a CA, but a CA requires that the
FMEA has previously identified system level critical fail-
ures. When both steps are done, the total process is called
a FMECA.
1.2 Ground rules
The ground rules of each FMEA include a set of project
selected procedures; the assumptions on which the anal-
ysis is based; the hardware that has been included and
excluded from the analysis and the rationale for the exclu-
sions. The ground rules also describe the indenture level
of the analysis, the basic hardware status, and the criteria
for system and mission success. Every effort should be
made to define all ground rules before the FMEA begins;
however, the ground rules may be expanded and clarified
as the analysis proceeds. A typical set of ground rules
(assumptions) follows:[3]
1. Only one failure mode exists at a time.
2. All inputs (including software commands) to the
item being analyzed are present and at nominal val-
ues.
3. All consumables are present in sufficient quantities.
4. Nominal power is available
1.3 Benefits
Major benefits derived from a properly implemented
FMECA effort are as follows:
1. It provides a documented method for selecting a de-
sign with a high probability of successful operation
and safety.
2. A documented uniform method of assessing poten-
tial failure mechanisms, failure modes and their im-
pact on system operation, resulting in a list of failure
modes ranked according to the seriousness of their
system impact and likelihood of occurrence.
3. Early identification of single failure points (SFPS)
and system interface problems, which may be criti-
cal to mission success and/or safety. They also pro-
vide a method of verifying that switching between
redundant elements is not jeopardized by postulated
single failures.
4. An effective method for evaluating the effect of pro-
posed changes to the design and/or operational pro-
cedures on mission success and safety.
5. A basis for in-flight troubleshooting procedures
and for locating performance monitoring and fault-
detection devices.
6. Criteria for early planning of tests.
From the above list, early identifications of SFPS, input
to the troubleshooting procedure and locating of perfor-
mance monitoring / fault detection devices are probably
the most important benefits of the FMECA. In addition,
the FMECA procedures are straightforward and allow or-
derly evaluation of the design.
2 Basic terms
The following covers some basic FMEA terminology.[4]
Failure The loss of a function under stated conditions.
Failure mode The specific manner or way by which a
failure occurs in terms of failure of the item (being
a part or (sub) system) function under investigation;
it may generally describe the way the failure occurs.
It shall at least clearly describe a (end) failure state of
the item (or function in case of a Functional FMEA)
under consideration. It is the result of the failure
mechanism (cause of the failure mode). For exam-
ple; a fully fractured axle, a deformed axle or a fully
open or fully closed electrical contact are each a sep-
arate failure mode.
Failure cause and/or mechanism Defects in require-
ments, design, process, quality control, handling or
part application, which are the underlying cause or
sequence of causes that initiate a process (mecha-
nism) that leads to a failure mode over a certain time.
A failure mode may have more causes. For exam-
ple; “fatigue or corrosion of a structural beam” or
“fretting corrosion in an electrical contact” is a failure
mechanism and in itself (likely) not a failure mode.
The related failure mode (end state) is a “full fracture
of structural beam” or “an open electrical contact”.
The initial cause might have been “Improper appli-
cation of corrosion protection layer (paint)" and /or
"(abnormal) vibration input from another (possibly
failed) system”.

3. 3
Failure effect Immediate consequences of a failure on
operation, function or functionality, or status of
some item.
Indenture levels (bill of material or functional breakdown)
An identifier for system level and thereby item com-
plexity. Complexity increases as levels are closer to
one.
Local effect The failure effect as it applies to the item
under analysis.
Next higher level effect The failure effect as it applies at
the next higher indenture level.
End effect The failure effect at the highest indenture
level or total system.
Detection The means of detection of the failure mode
by maintainer, operator or built in detection system,
including estimated dormancy period (if applicable)
Risk Priority Number (RPN) Cost (of the event) *
Probability (of the event occurring) * Detection
(Probability that the event would not be detected be-
fore the user was aware of it)
Severity The consequences of a failure mode. Severity
considers the worst potential consequence of a fail-
ure, determined by the degree of injury, property
damage, system damage and/or time lost to repair
the failure.
Remarks / mitigation / actions Additional info, in-
cluding the proposed mitigation or actions used to
lower a risk or justify a risk level or scenario.
3 History
Procedures for conducting FMECA were described in US
Armed Forces Military Procedures document MIL-P-
1629[5]
(1949); revised in 1980 as MIL-STD-1629A).[6]
By the early 1960s, contractors for the U.S. National
Aeronautics and Space Administration (NASA) were us-
ing variations of FMECA or FMEA under a variety of
names.[7][8]
NASA programs using FMEA variants in-
cluded Apollo, Viking, Voyager, Magellan, Galileo, and
Skylab.[9][10][11]
The civil aviation industry was an early
adopter of FMEA, with the Society for Automotive En-
gineers (SAE) publishing ARP926 in 1967.[12]
After
two revisions, ARP926 has been replaced by ARP4761,
which is now broadly used in civil aviation.
During the 1970s, use of FMEA and related techniques
spread to other industries. In 1971 NASA prepared
a report for the U.S. Geological Survey recommending
the use of FMEA in assessment of offshore petroleum
exploration.[13]
A 1973 U.S. Environmental Protection
Agency report described the application of FMEA to
wastewater treatment plants.[14]
FMEA as application for
HACCP on the Apollo Space Program moved into the
food industry in general.[15]
The automotive industry began to use FMEA by the mid
1970s.[16]
The Ford Motor Company introduced FMEA
to the automotive industry for safety and regulatory con-
sideration after the Pinto affair. Ford applied the same
approach to processes (PFMEA) to consider potential
process induced failures prior to launching production.
In 1993 the Automotive Industry Action Group (AIAG)
first published an FMEA standard for the automotive
industry.[17]
It is now in its fourth edition.[18]
The SAE
first published related standard J1739 in 1994.[19]
This
standard is also now in its fourth edition.[20]
Although initially developed by the military, FMEA
methodology is now extensively used in a variety of indus-
tries including semiconductor processing, food service,
plastics, software, and healthcare.[21][22]
Toyota has taken
this one step further with its Design Review Based on
Failure Mode (DRBFM) approach. The method is now
supported by the American Society for Quality which
provides detailed guides on applying the method.[23]
The
standard Failure Modes and Effects Analysis (FMEA)
and Failure Modes, Effects and Criticality Analysis
(FMECA) procedures however, do not identify the prod-
uct failure mechanisms and models, which limits their ap-
plicability to provide a meaningful input to critical proce-
dures such as virtual qualification, root cause analysis, ac-
celerated test programs, and to remaining life assessment.
To overcome the shortcomings of FMEA and FMECA a
Failure Modes, Mechanisms and Effect Analysis (FM-
MEA) has often been used.
4 Example worksheet (ARP4761) -
Design (Hardware) FMEA
4.1 Probability (P)
It is necessary to look at the cause of a failure mode and
the likelihood of occurrence. This can be done by anal-
ysis, calculations / FEM, looking at similar items or pro-
cesses and the failure modes that have been documented
for them in the past. A failure cause is looked upon as
a design weakness. All the potential causes for a failure
mode should be identified and documented. This should
be in technical terms. Examples of causes are: Human er-
rors in handling, Manufacturing induced faults, Fatigue,
Creep, Abrasive wear, erroneous algorithms, excessive
voltage or improper operating conditions or use (depend-
ing on the used ground rules). A failure mode is given a
Probability Ranking.

4. 4 4 EXAMPLE WORKSHEET (ARP4761) - DESIGN (HARDWARE) FMEA
4.2 Severity (S)
Determine the Severity for the worst-case scenario ad-
verse end effect (state). It is convenient to write these
effects down in terms of what the user might see or ex-
perience in terms of functional failures. Examples of
these end effects are: full loss of function x, degraded
performance, functions in reversed mode, too late func-
tioning, erratic functioning, etc. Each end effect is given
a Severity number (S) from, say, I (no effect) to VI (catas-
trophic), based on cost and/or loss of life or quality of life.
These numbers prioritize the failure modes (together with
probability and detectability). Below a typical classifica-
tion is given. Other classifications are possible. See also
hazard analysis.
4.3 Detection (D)
The means or method by which a failure is detected, iso-
lated by operator and/or maintainer and the time it may
take. This is important for maintainability control (Avail-
ability of the system) and it is specially important for mul-
tiple failure scenarios. This may involve dormant fail-
ure modes (e.g. No direct system effect, while a redun-
dant system / item automatic takes over or when the fail-
ure only is problematic during specific mission or sys-
tem states) or latent failures (e.g. deterioration failure
mechanisms, like a metal growing crack, but not a criti-
cal length). It should be made clear how the failure mode
or cause can be discovered by an operator under normal
system operation or if it can be discovered by the mainte-
nance crew by some diagnostic action or automatic built
in system test. A dormancy and/or latency period may be
entered.
DORMANCY or LATENCY PERIOD The average time
that a failure mode may be undetected may be entered if
known. For example:
• During aircraft C Block inspection, preventive or
predictive maintenance, X months or X flight hours
• During aircraft B Block inspection, preventive or
predictive maintenance, X months or X flight hours
• During Turn-Around Inspection before or after
flight (e.g. 8 hours average)
• During in-built system functional test, X minutes
• Continuously monitored, X seconds
INDICATION
If the undetected failure allows the system to remain in a
safe / working state, a second failure situation should be
explored to determine whether or not an indication will
be evident to all operators and what corrective action they
may or should take.
Indications to the operator should be described as follows:
• Normal. An indication that is evident to an operator
when the system or equipment is operating normally.
• Abnormal. An indication that is evident to an oper-
ator when the system has malfunctioned or failed.
• Incorrect. An erroneous indication to an operator
due to the malfunction or failure of an indicator (i.e.,
instruments, sensing devices, visual or audible warn-
ing devices, etc.).
PERFORM DETECTION COVERAGE ANALYSIS
FOR TEST PROCESSES AND MONITORING (From
ARP4761 Standard):
This type of analysis is useful to determine how effective
various test processes are at the detection of latent and
dormant faults. The method used to accomplish this in-
volves an examination of the applicable failure modes to
determine whether or not their effects are detected, and
to determine the percentage of failure rate applicable to
the failure modes which are detected. The possibility that
the detection means may itself fail latent should be ac-
counted for in the coverage analysis as a limiting factor
(i.e., coverage cannot be more reliable than the detection
means availability). Inclusion of the detection coverage in
the FMEA can lead to each individual failure that would
have been one effect category now being a separate ef-
fect category due to the detection coverage possibilities.
Another way to include detection coverage is for the FTA
to conservatively assume that no holes in coverage due to
latent failure in the detection method affect detection of
all failures assigned to the failure effect category of con-
cern. The FMEA can be revised is necessary for those
cases where this conservative assumption does not allow
the top event probability requirements to be met.
After these three basic steps the Risk level may be pro-
vided.
4.4 Risk level (P*S) and (D)
Risk is the combination of End Effect Probability
And Severity. Where probability and severity includes
the effect on non-detectability (dormancy time). This
may influence the end effect probability of failure or the
worst case effect Severity. The exact calculation may not
be easy in all cases, such as those where multiple scenar-
ios (with multiple events) are possible and detectability /
dormancy plays a crucial role (as for redundant systems).
In that case Fault Tree Analysis and/or Event Trees may
be needed to determine exact probability and risk levels.
Preliminary Risk levels can be selected based on a Risk
Matrix like shown below, based on Mil. Std. 882.[24]
The
higher the Risk level, the more justification and mitigation
is needed to provide evidence and lower the risk to an
acceptable level. High risk should be indicated to higher
level management, who are responsible for final decision-
making.

5. 5
• After this step the FMEA has become like a
FMECA.
5 Timing
The FMEA should be updated whenever:
• A new cycle begins (new product/process)
• Changes are made to the operating conditions
• A change is made in the design
• New regulations are instituted
• Customer feedback indicates a problem
6 Uses
• Development of system requirements that minimize
the likelihood of failures.
• Development of designs and test systems to ensure
that the failures have been eliminated or the risk is
reduced to acceptable level.
• Development and evaluation of diagnostic systems
• To help with design choices (trade-off analysis).
7 Advantages
• Improve the quality, reliability and safety of a prod-
uct/process
• Improve company image and competitiveness
• Increase user satisfaction
• Reduce system development time and cost
• Collect information to reduce future failures, cap-
ture engineering knowledge
• Reduce the potential for warranty concerns
• Early identification and elimination of potential fail-
ure modes
• Emphasize problem prevention
• Minimize late changes and associated cost
• Catalyst for teamwork and idea exchange between
functions
• Reduce the possibility of same kind of failure in fu-
ture
• Reduce impact on company profit margin
• Improve production yield
8 Limitations
While FMEA identifies important hazards in a system, its
results may not be comprehensive and the approach has
limitations.[25][26][27]
In the healthcare context, FMEA
and other risk assessment methods, including SWIFT
(Structured What If Technique) and retrospective ap-
proaches, have been found to have limited validity when
used in isolation. Challenges around scoping and organ-
isational boundaries appear to be a major factor in this
lack of validity.[25]
If used as a top-down tool, FMEA may only identify ma-
jor failure modes in a system. Fault tree analysis (FTA)
is better suited for “top-down” analysis. When used as
a “bottom-up” tool FMEA can augment or complement
FTA and identify many more causes and failure modes
resulting in top-level symptoms. It is not able to discover
complex failure modes involving multiple failures within
a subsystem, or to report expected failure intervals of par-
ticular failure modes up to the upper level subsystem or
system.
Additionally, the multiplication of the severity, occur-
rence and detection rankings may result in rank reversals,
where a less serious failure mode receives a higher RPN
than a more serious failure mode.[28]
The reason for this
is that the rankings are ordinal scale numbers, and multi-
plication is not defined for ordinal numbers. The ordinal
rankings only say that one ranking is better or worse than
another, but not by how much. For instance, a ranking of
“2” may not be twice as severe as a ranking of “1,” or an
“8” may not be twice as severe as a “4,” but multiplication
treats them as though they are. See Level of measurement
for further discussion.
9 Types
• Functional: before design solutions are provided
(or only on high level) functions can be evaluated on
potential functional failure effects. General Mitiga-
tions (“design to” requirements) can be proposed to
limit consequence of functional failures or limit the
probability of occurrence in this early development.
It is based on a functional breakdown of a system.
This type may also be used for Software evaluation.
• Concept Design / Hardware: analysis of systems
or subsystems in the early design concept stages to
analyse the failure mechanisms and lower level func-
tional failures, specially to different concept solu-
tions in more detail. It may be used in trade-off
studies.
• Detailed Design / Hardware: analysis of products
prior to production. These are the most detailed
(in mil 1629 called Piece-Part or Hardware FMEA)
FMEAs and used to identify any possible hardware

6. 6 11 REFERENCES
(or other) failure mode up to the lowest part level.
It should be based on hardware breakdown (e.g. the
BoM = Bill of Material). Any Failure effect Sever-
ity, failure Prevention (Mitigation), Failure Detec-
tion and Diagnostics may be fully analysed in this
FMEA.
• Process: analysis of manufacturing and assembly
processes. Both quality and reliability may be af-
fected from process faults. The input for this FMEA
is amongst others a work process / task Breakdown.
10 See also
11 References
[1] System Reliability Theory: Models, Statistical Methods,
and Applications, Marvin Rausand & Arnljot Hoylan, Wi-
ley Series in probability and statistics - second edition
2004, page 88
[2] Project Reliability Group (July 1990). Koch, John E., ed.
Jet Propulsion Laboratory Reliability Analysis Handbook
(pdf). Pasadena, California: Jet Propulsion Laboratory.
JPL-D-5703. Retrieved 2013-08-25.
[3] Goddard Space Flight Center (GSFC) (1996-08-10).
Performing a Failure Mode and Effects Analysis (pdf).
Goddard Space Flight Center. 431-REF-000370. Re-
trieved 2013-08-25.
[4] Langford, J. W. (1995). Logistics: Principles and Appli-
cations. McGraw Hill. p. 488.
[5] United States Department of Defense (9 November 1949).
MIL-P-1629 - Procedures for performing a failure mode
effect and critical analysis. Department of Defense (US).
MIL-P-1629.
[6] United States Department of Defense (24 November
1980). MIL-STD-1629A - Procedures for performing a
failure mode effect and criticality analysis. Department
of Defense (USA). MIL-STD-1629A.
[7] Neal, R.A. (1962). Modes of Failure Analysis Summary
for the Nerva B-2 Reactor (PDF). Westinghouse Electric
Corporation Astronuclear Laboratory. WANL–TNR–
042. Retrieved 2010-03-13.
[8] Dill, Robert; et al. (1963). State of the Art Reliability
Estimate of Saturn V Propulsion Systems (PDF). General
Electric Company. RM 63TMP–22. Retrieved 2010-03-
13.
[9] Procedure for Failure Mode, Effects and Criticality Analy-
sis (FMECA) (PDF). National Aeronautics and Space Ad-
ministration. 1966. RA–006–013–1A. Retrieved 2010-
03-13.
[10] Failure Modes, Effects, and Criticality Analysis (FMECA)
(PDF). National Aeronautics and Space Administration
JPL. PD–AD–1307. Retrieved 2010-03-13.
[11] Experimenters’ Reference Based Upon Skylab Experiment
Management (PDF). National Aeronautics and Space Ad-
ministration George C. Marshall Space Flight Center.
1974. M–GA–75–1. Retrieved 2011-08-16.
[12] Design Analysis Procedure For Failure Modes, Effects and
Criticality Analysis (FMECA). Society for Automotive En-
gineers. 1967. ARP926.
[13] Dyer, Morris K.; Dewey G. Little, Earl G. Hoard, Al-
fred C. Taylor, Rayford Campbell (1972). Applicability
of NASA Contract Quality Management and Failure Mode
Effect Analysis Procedures to the USFS Outer Continen-
tal Shelf Oil and Gas Lease Management Program (PDF).
National Aeronautics and Space Administration George
C. Marshall Space Flight Center. TM X–2567. Retrieved
2011-08-16.
[14] Mallory, Charles W.; Robert Waller (1973). Application
of Selected Industrial Engineering Techniques to Wastewa-
ter Treatment Plants (PDF). United States Environmental
Protection Agency. pp. 107–110. EPA R2–73–176. Re-
trieved 2012-11-10.
[15] Sperber, William H.; Stier, Richard F. (December 2009
– January 2010). “Happy 50th Birthday to HACCP: Ret-
rospective and Prospective”. FoodSafety magazine: 42,
44–46.
[16] Matsumoto, K.; T. Matsumoto; Y. Goto (1975).
“Reliability Analysis of Catalytic Converter as an Auto-
motive Emission Control System”. SAE Technical Paper
750178. doi:10.4271/750178. Retrieved 2012-11-10.
[17] AIAG (1993). Potential Failure Mode and Effect Analysis.
Automotive Industry Action Group.
[18] AIAG (2008). Potential Failure Mode and Effect Analysis
(FMEA), 4th Edition. Automotive Industry Action Group.
ISBN 9781605341361.
[19] SAE (1994). Potential Failure Mode and Effects Analy-
sis in Design (Design FMEA), Potential Failure Mode and
Effects Analysis in Manufacturing and Assembly Processes
(Process FMEA), and Potential Failure Mode and Effects
Analysis for Machinery (Machinery FMEA). SAE Interna-
tional.
[20] SAE (2008). Potential Failure Mode and Effects Analysis
in Design (Design FMEA) and Potential Failure Mode and
Effects Analysis in Manufacturing and Assembly Processes
(Process FMEA) and Effects Analysis for Machinery (Ma-
chinery FMEA). SAE International.
[21] Quality Associates International’s History of FMEA
[22] Fadlovich, Erik (December 31, 2007). “Performing Fail-
ure Mode and Effect Analysis”. Embedded Technology.
[23] “Failure Mode Effects Analysis (FMEA)". ASQ. Re-
trieved 2012-02-15.
[24] http://www.everyspec.com/MIL-STD/
MIL-STD-0800-0899/MIL-STD-882E_41682/

7. 7
[25] Potts H.W.W., Anderson J.E., Colligan L., Leach P.,
Davis S., Berman J. (2014). “Assessing the validity of
prospective hazard analysis methods: A comparison of
two techniques”. BMC Health Services Research (14).
doi:10.1186/1472-6963-14-41.
[26] Franklin BD, Shebl NA, Barber N: “Failure mode and ef-
fects analysis: too little for too much?" BMJ Qual Saf
2012, 21: 607–611
[27] Shebl NA, Franklin BD, Barber N: “Is failure mode and
effect analysis reliable?" J Patient Saf 2009, 5: 86–94
[28] Kmenta, Steven; Ishii, Koshuke (2004). “Scenario-
Based Failure Modes and Effects Analysis Using Ex-
pected Cost”. Journal of Mechanical Design 126 (6):
1027. doi:10.1115/1.1799614.

8. 8 12 TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES
12 Text and image sources, contributors, and licenses
12.1 Text
• Failure mode and effects analysis Source: http://en.wikipedia.org/wiki/Failure%20mode%20and%20effects%20analysis?oldid=
622852673 Contributors: AxelBoldt, Rmhermen, SimonP, Michael Hardy, Rp, Liftarn, Ronz, CatherineMunro, Aimaz, PeterBrooks,
Zarius, Greenrd, Lupo, Tom harrison, Everyking, Duncharris, Brockert, Quarl, Ukexpat, Rich Farmbrough, Gejigeji, El C, Adambro, Re-
muel, Prainog, Vortexrealm, Cohesion, HasharBot, Spangineer, Marasmusine, David Haslam, Plrk, Prashanthns, Jivecat, Yamamoto Ichiro,
Wragge, FlaBot, Rsavoie, RexNL, Knoma Tsujmai, Chris Capoccia, Darren.bowles, Epipelagic, Boogachamp, Bondegezou, Daleh, Bill, At-
tilios, SmackBot, LaurensvanLieshout, DanielPenfield, David n m bond, Chris the speller, Bluebot, Darth Panda, Emurphy42, KaiserbBot,
Cybercobra, Marc T Smith, Derek R Bullamore, NickPenguin, RJBurkhart, DP2.5, Thopper, Peterlewis, Fig wright, Petter73, RichardF,
Hu12, Twas Now, AbsolutDan, ChrisCork, Eastlaw, CmdrObot, Cydebot, Fnlayson, Jayen466, Kozuch, Thijs!bot, Miller17CU94, Quite-
Unusual, JAnDbot, Harryzilber, Davewho2, Ncsupimaster, Vicsar, Kevinmon, JSSX, Mmoitzh, Pswift, Anaxial, RJBurkhart3, J.delanoy,
Rlsheehan, Dfunk58, HALIGHT, Juliancolton, Taffykins, Inwind, VolkovBot, Philip Trueman, Kevconaghan, Allantonkin, SueHay, Wit-
tym, HansMair, Ahhboo, Bdm87, Wtubeguru, Jt310897, Heat fan1, Billinghurst, AlleborgoBot, Finnrind, Jmuenzing, SieBot, PeterFV,
CWDURAND, Jsc83, Mongbei, Yintan, Flyer22, Jojalozzo, Pac72, Ctxppc, Onopearls, Zwiadowca21, Linforest, ClueBot, Terrible-
Tadpole, PipepBot, Philip Sutton, Compellingelegance, Ashchori, LizardJr8, Trivialist, LyallDNZ, Excirial, Jdvernier, Vinodh.vinodh,
SchreiberBike, Qwfp, DumZiBoT, Spitfire, Gnowor, Rich Baldwin, DragonFury, Gerhardvalentin, WikHead, Addbot, NielsJurgen, QAas-
sistant, Olufowa, Ashton1983, 9000store, Mm0therway, Foamfollower, Tide rolls, Quantumobserver, Syona, Yobot, Niklo sv, Rando-
mAct, Citation bot, JohnnyB256, LilHelpa, MilesSmith1776, Capricorn42, Jü, Kobraton, RibotBOT, SassoBot, Imveracious, Broeze,
FrescoBot, Plain Jane 2009, Lexas, Alexdfromald, Thequality, Pavanpatidar, Redrose64, Modalla, Er.yogesh3486, SchreyP, Fiducial,
Watdenfoo, EmausBot, WikitanvirBot, Wikipelli, DonToto, J to2000, Mburdis, Tolly4bolly, Kerlevenez, Robin48gx, Bsaguy, ClueBot
NG, Pawankashyap123, Abhi.analyst, ConconJondor, O.Koslowski, Helpful Pixie Bot, BG19bot, Kjwilson76, Maradi.mallikarjun, M2OS,
Omerpeksen, BattyBot, New Light Taiwan, Khazar2, FMEA Expert, Whagen2, Jonahugh, Fantomian, OliJWalker, Marianne.jyrgenson,
IrfanSha, Michaelsopa, Javegeorge, Uwnib, Tourhaan, Monkbot, Riskdoctor and Anonymous: 292
12.2 Images
• File:Commons-logo.svg Source: http://upload.wikimedia.org/wikipedia/en/4/4a/Commons-logo.svg License: ? Contributors: ? Original
artist: ?
• File:Folder_Hexagonal_Icon.svg Source: http://upload.wikimedia.org/wikipedia/en/4/48/Folder_Hexagonal_Icon.svg License: Cc-by-
sa-3.0 Contributors: ? Original artist: ?
12.3 Content license
• Creative Commons Attribution-Share Alike 3.0