RPN Synthesis Using FEA
RPN Synthesis Using FEA
RPN Synthesis Using FEA
or reduced by understanding the failure mechanism. Ideally this probability shall be lowered to impossible to occur by eliminating the (root) causes. It is therefore important 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 analyze postulated component failures and identify the resultant eects on system operations. The analysis is sometimes characterized as consisting of two sub-analyses, the
rst being the failure modes and eects analysis (FMEA),
and the second, the criticality analysis (CA).[3] Successful development of an FMEA requires that the analyst
include all signicant failure modes for each contributing element or part in the system. FMEAs can be performed 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 dependent on the eectiveness and timeliness with which
design problems are identied. Timeliness is probably
the most important consideration. In the extreme case,
the FMECA would be of little value to the design decision process if the analysis is performed after the hardware is built. While the FMECA identies all part failure
modes, its primary benet is the early identication of
all critical and catastrophic subsystem or system failure
modes so they can be eliminated or minimized through
design modication at the earliest point in the development eort; therefore, the FMECA should be performed
at the system level as soon as preliminary design information is available and extended to the lower levels as the
detail design progresses.
A successful FMEA activity helps identify potential failure modes based on experience with similar products and
processesor based on common physics of failure logic.
It is widely used in development and manufacturing industries in various phases of the product life cycle. Effects analysis refers to studying the consequences of those Remark: For more complete scenario modelling another
failures on dierent system levels.
type of Reliability analysis may be considered, for examFunctional analyses are needed as an input to deter- ple fault tree analysis (FTA); a deductive (backward logic)
mine correct failure modes, at all system levels, both for failure analysis that may handle multiple failures within
functional FMEA or Piece-Part (hardware) FMEA. An the item and/or external to the item including mainteFMEA is used to structure Mitigation for Risk reduction nance and logistics. It starts at higher functional / system
based on either failure (mode) eect severity reduction or level. An FTA may use the basic failure mode FMEA
based on lowering the probability of failure or both. The records or an eect summary as one of its inputs (the baFMEA is in principle a full inductive (forward logic) anal- sic events). Interface hazard analysis, Human error analysis, however the failure probability can only be estimated ysis and others may be added for completion in scenario
1
modelling.
1.1
Functional analysis
BASIC TERMS
1. It provides a documented method for selecting a design with a high probability of successful operation
and safety.
2. A documented uniform method of assessing potential failure mechanisms, failure modes and their impact on system operation, resulting in a list of failure
modes ranked according to the seriousness of their
system impact and likelihood of occurrence.
The analysis may be performed at the functional level until the design has matured suciently to identify specic
hardware that will perform the functions; then the analysis should be extended to the hardware level. When performing the hardware level FMECA, interfacing hard3. Early identication of single failure points (SFPS)
ware is considered to be operating within specication.
and system interface problems, which may be critiIn addition, each part failure postulated is considered to
cal to mission success and/or safety. They also probe the only failure in the system (i.e., it is a single failure
vide a method of verifying that switching between
analysis). In addition to the FMEAs done on systems to
redundant elements is not jeopardized by postulated
evaluate the impact lower level failures have on system
single failures.
operation, several other FMEAs are done. Special atten4. An eective method for evaluating the eect of protion is paid to interfaces between systems and in fact at all
posed changes to the design and/or operational profunctional interfaces. The purpose of these FMEAs is to
cedures on mission success and safety.
assure that irreversible physical and/or functional damage is not propagated across the interface as a result of
5. A basis for in-ight troubleshooting procedures
failures in one of the interfacing units. These analyses
and for locating performance monitoring and faultare done to the piece part level for the circuits that didetection devices.
rectly interface with the other units. The FMEA can be
accomplished without a CA, but a CA requires that the
6. Criteria for early planning of tests.
FMEA has previously identied system level critical failures. When both steps are done, the total process is called From the above list, early identications of SFPS, input
a FMECA.
to the troubleshooting procedure and locating of performance monitoring / fault detection devices are probably
the most important benets of the FMECA. In addition,
1.2 Ground rules
the FMECA procedures are straightforward and allow orderly evaluation of the design.
The ground rules of each FMEA include a set of project
selected procedures; the assumptions on which the analysis is based; the hardware that has been included and
2 Basic terms
excluded from the analysis and the rationale for the exclusions. The ground rules also describe the indenture level
[5]
of the analysis, the basic hardware status, and the criteria The following covers some basic FMEA terminology.
for system and mission success. Every eort should be
made to dene all ground rules before the FMEA begins; Failure The loss of a function under stated conditions.
however, the ground rules may be expanded and claried
as the analysis proceeds. A typical set of ground rules Failure mode The specic manner or way by which a
failure occurs in terms of failure of the item (being
(assumptions) follows:[4]
a part or (sub) system) function under investigation;
it may generally describe the way the failure occurs.
1. Only one failure mode exists at a time.
It shall at least clearly describe a (end) failure state of
the item (or function in case of a Functional FMEA)
2. All inputs (including software commands) to the
under consideration. It is the result of the failure
item being analyzed are present and at nominal valmechanism (cause of the failure mode). For examues.
ple; a fully fractured axle, a deformed axle or a fully
open or fully closed electrical contact are each a sep3. All consumables are present in sucient quantities.
arate failure mode.
4. Nominal power is available
Failure cause and/or mechanism Defects in requirements, design, process, quality control, handling or
part application, which are the underlying cause or
1.3 Benets
sequence of causes that initiate a process (mechanism) that leads to a failure mode over a certain time.
Major benets derived from a properly implemented
A failure mode may have more causes. For examFMECA eort are as follows:
ple; fatigue or corrosion of a structural beam or
3
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 application of corrosion protection layer (paint)" and /or
"(abnormal) vibration input from another (possibly
failed) system.
History
4.5 Indication
4.2
Severity (S)
Determine the Severity for the worst-case scenario ad Normal. An indication that is evident to an operator
verse end eect (state). It is convenient to write these
when the system or equipment is operating normally.
eects down in terms of what the user might see or ex Abnormal. An indication that is evident to an operperience in terms of functional failures. Examples of
ator when the system has malfunctioned or failed.
these end eects are: full loss of function x, degraded
performance, functions in reversed mode, too late func Incorrect. An erroneous indication to an operator
tioning, erratic functioning, etc. Each end eect is given
due to the malfunction or failure of an indicator (i.e.,
a Severity number (S) from, say, I (no eect) to VI (catasinstruments, sensing devices, visual or audible warntrophic), based on cost and/or loss of life or quality of life.
ing devices, etc.).
These numbers prioritize the failure modes (together with
probability and detectability). Below a typical classication is given. Other classications are possible. See also PERFORM DETECTION COVERAGE ANALYSIS
FOR TEST PROCESSES AND MONITORING (From
hazard analysis.
ARP4761 Standard):
4.3
Detection (D)
The means or method by which a failure is detected, isolated by operator and/or maintainer and the time it may
take. This is important for maintainability control (Availability of the system) and it is especially important for
multiple failure scenarios. This may involve dormant failure modes (e.g. No direct system eect, while a redundant system / item automatic takes over or when the failure only is problematic during specic mission or system states) or latent failures (e.g. deterioration failure
mechanisms, like a metal growing crack, but not a critical 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 maintenance crew by some diagnostic action or automatic built
in system test. A dormancy and/or latency period may be
entered.
4.4
5
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.[25] The
higher the Risk level, the more justication 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 nal decisionmaking.
After this step the FMEA has become like a
FMECA.
Timing
8 Limitations
While FMEA identies important hazards in a system, its
results may not be comprehensive and the approach has
limitations.[26][27][28] In the healthcare context, FMEA
and other risk assessment methods, including SWIFT
(Structured What If Technique) and retrospective approaches, have been found to have limited validity when
used in isolation. Challenges around scoping and organisational boundaries appear to be a major factor in this
lack of validity.[26]
If used as a top-down tool, FMEA may only identify major failure modes in a system. Fault tree analysis (FTA)
is better suited for top-down analysis. When used as
6 Uses
a bottom-up tool FMEA can augment or complement
FTA and identify many more causes and failure modes
Development of system requirements that minimize resulting in top-level symptoms. It is not able to discover
the likelihood of failures.
complex failure modes involving multiple failures within
Development of designs and test systems to ensure a subsystem, or to report expected failure intervals of parthat the failures have been eliminated or the risk is ticular failure modes up to the upper level subsystem or
system.
reduced to acceptable level.
Additionally, the multiplication of the severity, occurrence and detection rankings may result in rank reversals,
where a less serious failure mode receives a higher RPN
To help with design choices (trade-o analysis).
than a more serious failure mode.[29] The reason for this
is that the rankings are ordinal scale numbers, and multiplication
is not dened for ordinal numbers. The ordinal
Advantages
rankings only say that one ranking is better or worse than
another, but not by how much. For instance, a ranking
Improve the quality, reliability and safety of a prodof 2 may not be twice as severe as a ranking of 1,
uct/process
or an 8 may not be twice as severe as a 4, but multiplication treats them as though they are. See Level of
Improve company image and competitiveness
measurement for further discussion. Various solutions to
Increase user satisfaction
this problems have been proposed, e.g., the use of fuzzy
logic as an alternative to classic RPN model. [30] [31]
Reduce system development time and cost
Besides, two shortcomings are (1) complexity of the
Collect information to reduce future failures, cap- FMEA worksheet ; (2) intricacy of its use. Entries in
ture engineering knowledge
a FMEA worksheet are voluminous. The FMEA worksheet is hard to produce, hard to understand and read, as
Reduce the potential for warranty concerns
well as hard to maintain. The use of neural network techEarly identication and elimination of potential fail- niques to cluster and visualise failure modes were sugure modes
gested, recently.[32][33]
11
Types
Functional: before design solutions are provided
(or only on high level) functions can be evaluated on
potential functional failure eects. General Mitigations (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 functional failures, specially to dierent concept solutions in more detail. It may be used in trade-o
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
(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 eect Severity, failure Prevention (Mitigation), Failure Detection and Diagnostics may be fully analyzed in this
FMEA.
Process: analysis of manufacturing and assembly
processes. Both quality and reliability may be affected from process faults. The input for this FMEA
is amongst others a work process / task Breakdown.
10
See also
11
References
REFERENCES
[3] 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.
[5] Langford, J. W. (1995). Logistics: Principles and Applications. McGraw Hill. p. 488.
12
12
12.1
Failure mode and eects analysis Source: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis?oldid=758275192 Contributors: AxelBoldt, Rmhermen, SimonP, Michael Hardy, Rp, Liftarn, Ronz, CatherineMunro, Aimaz, PeterBrooks, Zarius, Greenrd,
Lupo, Davidcannon, Tom harrison, Everyking, Duncharris, Brockert, Quarl, Ukexpat, Rich Farmbrough, Gejigeji~enwiki, El C, Adambro,
Remuel, Prainog, Vortexrealm, Cohesion, HasharBot~enwiki, Spangineer, Marasmusine, David Haslam, JeUK, Plrk, Prashanthns, Jivecat, Yamamoto Ichiro, Wragge, FlaBot, Rsavoie, RexNL, Knoma Tsujmai, Chris Capoccia, Sasuke Sarutobi, Darren.bowles, Epipelagic,
Boogachamp, Bondegezou, Daleh, Bill, Attilios, SmackBot, LaurensvanLieshout, DanielPeneld, David n m bond, Jpvinall, Chris the
speller, Bluebot, Darth Panda, Emurphy42, KaiserbBot, Cybercobra, Marc T Smith, JanCeuleers, Derek R Bullamore, NickPenguin,
RJBurkhart, DP2.5, Thopper, Peterlewis, Fig wright, Petter73, RichardF, Hu12, Twas Now, Dan1679, ChrisCork, Eastlaw, CmdrObot,
Cydebot, Fnlayson, Jayen466, Kozuch, Thijs!bot, Miller17CU94, QuiteUnusual, JAnDbot, Harryzilber, Davewho2, Ncsupimaster, Vicsar,
Jvanhorn, Kevinmon, JSSX, Mmoitzh, Pswift, Anaxial, RJBurkhart3, J.delanoy, Rlsheehan, Dfunk58, HALIGHT, Juliancolton, Taykins,
Inwind, VolkovBot, Philip Trueman, Kevconaghan, Allantonkin, SueHay, Wittym, HansMair, Ahhboo, Bdm87, Wtubeguru, Jt310897,
Heat fan1, Billinghurst, AlleborgoBot, Finnrind, Jmuenzing, SieBot, PeterFV, CWDURAND, Jsc83, Mongbei, Yintan, Flyer22 Reborn, Jojalozzo, Pac72, Ctxppc, Onopearls, Zwiadowca21, Linforest, ClueBot, TerribleTadpole, PipepBot, Philip Sutton, Compellingelegance, Ashchori, LizardJr8, Trivialist, LyallDNZ, Excirial, Jdvernier, Vinodh.vinodh, SchreiberBike, Qwfp, DumZiBoT, Spitre, Gnowor,
Rich Baldwin, DragonFury, Gerhardvalentin, WikHead, Addbot, NielsJurgen~enwiki, QAassistant, Olufowa, Ashton1983, 9000store,
Mm0therway, Foamfollower, Tide rolls, Quantumobserver, Syona~enwiki, Yobot, Niklo sv, AnomieBOT, RandomAct, Citation bot, JohnnyB256, LilHelpa, MilesSmith1776, Capricorn42, J, Kobraton, RibotBOT, SassoBot, Imveracious, Broeze, FrescoBot, Plain Jane 2009,
Lexas, Alexdfromald, Thequality, Pavanpatidar, Redrose64, JIK1975, I dream of horses, Modalla, Er.yogesh3486, Trappist the monk,
SchreyP, Fiducial, Watdenfoo, EmausBot, WikitanvirBot, Wikipelli, Dcirovic, DonToto, J to2000, Quondum, Mburdis, Tolly4bolly, Kerlevenez, Robin48gx, Bsaguy, ClueBot NG, Pawankashyap123, Abhi.analyst, ConconJondor, Hassanahmed2, O.Koslowski, Helpful Pixie
Bot, BG19bot, Kjwilson76, Maradi.mallikarjun, Marcocapelle, M2OS, Omerpeksen, BattyBot, New Light Taiwan, Khazar2, FMEA Expert, Whagen2, Rich9874, Jonahugh, Me, Myself, and I are Here, Fantomian, OliJWalker, Marianne.jyrgenson, MarciaRieferJohnston,
Strug, IrfanSha, Michaelsopa, Javegeorge, Uwnib, Tourhaan, Monkbot, Eldrichr, Innoresmentor, Riskdoctor, Tkaimeng, Chevvin, InternetArchiveBot, Rtrust, Hifatih, MikeBucala, Sprinkledonut and Anonymous: 330
12.2
Images
12.3
Content license