From Wikipedia, the free encyclopedia - View original article
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 military systems. An FMEA is often the first step of a system reliability study. It involves reviewing as many components, assemblies, and subsystems as possible to identify 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 worksheets. An FMEA is mainly a qualitative analysis.
A few different types of FMEA analysis exist, like
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 "Process" (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 manufacturing 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 determine 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) analysis, however the failure probability can only be estimated 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).
The FME(C)A is a design tool used to systematically analyze postulated component failures and identify the resultant effects on system operations. The analysis is sometimes characterized as consisting of two sub-analyses, the first being the failure modes and effects analysis (FMEA), and the second, the criticality analysis (CA). Successful development of an FMEA requires that the analyst include all significant 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 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 decision process if the analysis is performed after the hardware 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 development effort; 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.
Remark: For more complete scenario modelling another type of Reliability analysis may be considered, for example 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 maintenance 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 basic events). Interface hazard analysis, Human error analysis and others may be added for completion in scenario modelling.
The analysis may be performed at the functional level until the design has matured sufficiently to identify specific hardware that will perform the functions; then the analysis should be extended to the hardware level. When performing the hardware level FMECA, interfacing hardware 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 attention 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 damage 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 directly 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 failures. When both steps are done, the total process is called a FMECA.
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 excluded from the analysis and the rationale for the exclusions. 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:
Major benefits derived from a properly implemented FMECA effort are as follows:
From the above list, early identifications of SFPS, input to the troubleshooting procedure and locating of performance monitoring / fault detection devices are probably the most important benefits of the FMECA. In addition, the FMECA procedures are straightforward and allow orderly evaluation of the design.
The following covers some basic FMEA terminology.
Procedures for conducting FMECA were described in US Armed Forces Military Procedures document MIL-P-1629 (1949); revised in 1980 as MIL-STD-1629A). By the early 1960s, contractors for the U.S. National Aeronautics and Space Administration (NASA) were using variations of FMECA or FMEA under a variety of names. NASA programs using FMEA variants included Apollo, Viking, Voyager, Magellan, Galileo, and Skylab. The civil aviation industry was an early adopter of FMEA, with the Society for Automotive Engineers (SAE) publishing ARP926 in 1967. 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. A 1973 U.S. Environmental Protection Agency report described the application of FMEA to wastewater treatment plants. FMEA as application for HACCP on the Apollo Space Program moved into the food industry in general.
The automotive industry began to use FMEA by the mid 1970s. The Ford Motor Company introduced FMEA to the automotive industry for safety and regulatory consideration 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. It is now in its fourth edition. The SAE first published related standard J1739 in 1994. This standard is also now in its fourth edition.
Although initially developed by the military, FMEA methodology is now extensively used in a variety of industries including semiconductor processing, food service, plastics, software, and healthcare. 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. The standard Failure Modes and Effects Analysis (FMEA) and Failure Modes, Effects and Criticality Analysis (FMECA) procedures however, do not identify the product failure mechanisms and models, which limits their applicability to provide a meaningful input to critical procedures such as virtual qualification, root cause analysis, accelerated test programs,and to remaining life assessment. To overcome the shortcomings of FMEA and FMECA a Failure Modes, Mechanisms and Effect Analysis (FMMEA) has often been used.
Design Failure Mode and Effects Analysis (DFMEA) is the application of the FMEA method specifically to product design. It is a paper-and-pencil analysis method used in engineering to document and explore ways that a product design might fail in real-world use. A DFMEA documents the key functions of a design, the primary potential failure modes relative to each function and the potential causes of each failure mode. The DFMEA method allows the design team to document what they know and suspect about a product's failure modes prior to completing the design, and then use this information to design out or mitigate the causes of failure.
Ideally, the DFMEA is begun at the earliest stages of concept development, and can then be used to help winnow down competing designs and to help generate new, more robust concepts.
The method attempts to quantify the likely severity and frequency of occurrence of each potential cause, as well as the ability of the design to detect each failure cause by using an ordinal scale (typically 1 - 10, where one is "best" and ten is "worst"). Those failure modes and causes with the highest scores should then be addressed through product redesign.
DFMEA is fundamentally a team effort, and therefore should only be performed with a cross-functional team that includes members of the design team as well as manufacturing/assembly, quality/validation and stress analysis team members.
First, the known functions of a system or component are written down. These are usually drawn from the product requirements, bill of materials (BOM) and prior experience of the engineering team. Next, for each function, a list is made of ways in which the product might fail to meet the functional requirement; these are known as the failure modes. For instance, the main functions of a pencil sharpener are to sharpen pencils to a fine point and to catch the tailings from sharpening. The failure modes may include not sharpening at all, frequently breaking the graphite and not catching the tailings.
Once failure modes are identified, the product design is reviewed and potential causes of the failure modes are identified.
The team then ranks the severity of the failure mode, using a 1 to 10 scale, where a "1" indicates that there is no discernible effect and a "10" indicates that the failure mode may impact safe operation or violate government regulations. Next, the frequency of occurrence of the failure mode is ranked using a scale from "1," remote likelihood of failure, to "10," persistent failures. Each cause of failure is then evaluated for the ability of the design controls to detect and prevent the failure mode.
Finally, a Risk Priority Number (RPN) is calculated by multiplying the severity, occurrence and detection rankings together.
With RPNs calculated, the next action by the design team depends on the stage of development. In the concept development stage, the RPNs may be used to compare various designs and select the best among them, or as an input to sensitivity analysis when combining features of the best concepts. Later in the development process, the RPNs should be used by the developers as a guide to focus development effort in order to make the product safer and more robust. After production launch, the RPNs should be used to select design features for continuous improvement activities.
The primary tool of DFMEA is the DFMEA matrix, which provides a structure for documenting the relevant information, including revision dates, team members and product data. The AIAG Potential Failure Mode Effects Analysis manual provides examples. The matrix may be created using pen and paper, electronic spreadsheets, or specialized software package .
DFMEA suffers from the same limitations discussed in Failure mode and effects analysis.
|FMEA Ref.||Item||Potential failure mode||Potential cause(s) / mechanism||Mission Phase||Local effects of failure||Next higher level effect||System Level End Effect||(P) Probability (estimate)||(S) Severity||Detection (Indications to Operator, Maintainer)||(D) Detection Dormancy Period||Risk Level P*S (+D)||Actions for further Investigation / evidence||Mitigation / Requirements|
|1.1.1||Brake Manifold Ref. Designator 2b, channel A, O-ring||Internal Leakage from Channel A to B||a) O-ring Compression Set (Creep) failure b) surface damage during assembly||Landing||Decreased pressure to main brake hose||No Left Wheel Braking||Severely Reduced Aircraft deceleration on ground and side drift. Partial loss of runway position control. Risk of collision||(C) Moderate||(VI) Catastrophic (this is the worst case)||(1) Flight Computer and Maintenance Computer will indicate "Left Main Brake, Pressure Low"||Built-In Test interval is 1 minute||Unacceptable||Check Dormancy Period and probability of failure||Require redundant independent brake hydraulic channels and/or Require redundant sealing and Classify O-ring as Critical Part Class 1|
It is necessary to look at the cause of a failure mode and the likelihood of occurrence. This can be done by analysis, calculations / FEM, looking at similar items or processes 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 errors in handling, Manufacturing induced faults, Fatigue, Creep, Abrasive wear, erroneous algorithms, excessive voltage or improper operating conditions or use (depending on the used ground rules). A failure mode is given an Probability Ranking.
|A||Extremely Unlikely (Virtually impossible or No known occurrences on similar products or processes, with many running hours)|
|B||Remote (relatively few failures)|
|C||Occasional (occasional failures)|
|D||Reasonably Possible (repeated failures)|
|E||Frequent (failure is almost inevitable)|
Determine the Severity for the worst case scenario adverse end effect (state). It is convenient to write these effects down in terms of what the user might see or experience in terms of functional failures. Examples of these end effects are: full loss of function x, degraded performance, functions in reversed mode, too late functioning, erratic functioning, etc. Each end effect is given a Severity number (S) from, say, I (no effect) to VI (catastrophic), 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 classification is given. Other classifications are possible. See also hazard analysis.
|I||No relevant effect on reliability or safety|
|II||Very minor, no damage, no injuries, only results in a maintenance action (only noticed by discriminating customers)|
|III||Minor, low damage, light injuries (affects very little of the system, noticed by average customer)|
|IV||Moderate, moderate damage, injuries possible (most customers are annoyed, mostly financial damage)|
|V||Critical (causes a loss of primary function; Loss of all safety Margins, 1 failure away from a catastrophe, severe damage, severe injuries, max 1 possible death )|
|VI||Catastrophic (product becomes inoperative; the failure may result in complete unsafe operation and possible multiple deaths)|
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 specially important for multiple failure scenarios. This may involve dormant failure modes (e.g. No direct system effect, while a redundant system / item automatic takes over or when the failure only is problematic during specific 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.
|1||Certain - fault will be caught on test|
|6||Fault is undetected by Operators or Maintainers|
DORMANCY or LATENCY PERIOD The average time that a failure mode may be undetected may be entered if known. For example:
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:
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 involves 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 accounted 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 effect 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 concern. 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 provided.
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 scenarios (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. 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.
|Probability / Severity -->||I||II||III||IV||V||VI|
The FMEA should be updated whenever:
While FMEA identifies important hazards in a system, its results may not be comprehensive and the approach has limitations. In a healthcare context, FMEA has been found to have limited validity compared to another prospective hazard analysis method (Structured What If Technique, SWIFT) and retrospective approaches, with particular challenges around scoping and organisational boundaries.
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 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 particular failure modes up to the upper level subsystem or system.
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 than a more serious failure mode. The reason for this is that the rankings are ordinal scale numbers, and multiplication 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.