Failure mode and effect analysis ( FMEA ) - also " failure mode ", plural, in many publications - is one of the first > highly structured, systematic techniques for failure analysis. It was developed by reliability engineers in the late 1950s to study the problems that might arise from military system malfunctions. An FMEA is often the first step of a system reliability study. This involves reviewing as many components, assemblies, and subsystems as possible to identify failure modes, and their causes and consequences. For each component, the failure mode and the resulting effect on the rest of the system are recorded in a particular FMEA worksheet. There are many variations of such worksheets. An FMEA can be a qualitative analysis, but can be put on a quantitative basis when the mathematical failure rate model is combined with a database of statistical failure mode ratios.
Several different types of FMEA analysis exist, such as:
- Functional
- Design
- Process
Sometimes FMEA is extended to FMECA (failure mode, effect, and criticality analysis) to show that criticality analysis is also performed.
FMEA is an inductive reasoning (advanced logic) one point of failure analysis and is a core task in engineering reliability, safety engineering and quality engineering.
Successful FMEA activity helps identify potential failure modes based on experience with similar products and processes - or physics based on common logic failure. It is widely used in the development and manufacturing industry in various phases of the product life cycle. Securities Analysis refers to studying the consequences of failures at different system levels.
Functional analysis is required as input to determine the correct failure mode, at all levels of the system, whether for functional FMEA or Parts-Piece (hardware) FMEA. An FMEA is used to create a Mitigation for Risk reduction structure based on a reduction in the severity of the effect (mode) or based on a decrease in the probability of failure or both. FMEA in principle is a full inductive analysis (advanced logic), but the probability of failure can only be estimated or reduced by understanding the failure mechanism . Therefore, FMEA may include information about the cause of failure (deductive analysis) to reduce the likelihood of occurrence by eliminating the identifiable cause (root) .
Video Failure mode and effects analysis
Introduction
The FME (C) A is a design tool used to systematically analyze the failures of postulated components and identify the resulting effects on system operation. This analysis is sometimes characterized as consisting of two sub-analyzes, the first being the failure mode and effect analysis (FMEA), and the second, the criticality analysis (CA). The successful development of FMEA requires that the analysts include all significant failure modes for each element or part that contributes to the system. FMEA can be performed in systems, subsystems, assemblies, sub-assemblies, or parts levels. FMECA should be a living document during the development of hardware design. This should be scheduled and completed along with the design. If completed on time, FMECA can help guide the design decisions. The use of FMECA as a design tool and in the decision-making process depends on the effectiveness and timeliness with the design issues identified. Timeliness is probably the most important consideration. In extreme cases, FMECA will be of little value to the design decision process if the analysis is done after the hardware is built. While FMECA identifies all parts of the failure mode, the main benefit is the early identification of all critical and catastrophic subsystems or modes of system failure that can be eliminated or minimized through design modifications at the earliest point in the development effort; therefore, FMECA should be done at the system level as soon as the initial design information is available and extended to a lower level when detailed design takes place.
Note: For a more complete scenario modeling, other types of Reliability analyzes may be considered, eg fault tree analysis (FTA); deductive failure analysis (reverse logic) that may handle some failure in items and/or external to items including maintenance and logistics. It starts at a higher functional/system level. FTAs can use the base failure mode of the FMEA record or the effect summary as one of its inputs (basic events). Interference hazard analysis, human error analysis and others can be added for completion in scenario modeling.
Functional analysis
The analysis can be done at a functional level until the design has been mature enough to identify the specific hardware that will perform the function; then the analysis should be extended to the hardware level. When performing hardware level FMECA, the interfacing hardware is considered to operate in the specification. In addition, any postulated section failures are considered the only failures in the system (that is, it is a single failure analysis). In addition to the FMEA conducted on the system to evaluate the impact of lower level failures on system operation, some other FMEA are performed. Particular attention is paid to interface between systems and in fact across all functional interfaces. The purpose of the FMEA is to ensure that irreversible physical and/or functional damage is not propagated throughout the interface as a result of failure in one of the interfacing units. This analysis is performed for parts of pieces for circuits that directly interact with other units. FMEA can be completed without CA, but CA requires FMEA to previously identify system-level critical failure. When both steps are done, the total process is called FMECA.
Basic rules
The basic rules of each FMEA include a set of selected project procedures; assumptions on which the analysis is based; hardware that has been entered and excluded from the analysis and reason for the exclusion. The basic rules also describe the level of indenture from analysis, basic hardware status, and criteria for system and mission success. Every effort should be made to determine all ground rules before FMEA begins; However, the ground rules can be extended and clarified as a result of the analysis. A set of basic rules (assumptions) follows:
- Only one failure mode exists at a time.
- All inputs (including software commands) to the item being analyzed are present and at face value.
- All consumables are present in sufficient quantities.
- Nominal quantity available
Benefits
The key benefits derived from the correctly implemented FMECA efforts are as follows:
- This provides a documented method for selecting designs with high probability of successful operation and security.
- The documented uniform method for assessing potential failure mechanisms, failure modes and their impact on system operation, generates a list of failure modes that are sorted based on the seriousness of their system impact and the likelihood of occurrence.
- Identify the start of a single failure problem (SFPS) and system interface issues, which may be critical to the success and/or safety of the mission. They also provide a method to verify that switching between redundant elements is not threatened by postulated single failures.
- An effective method for evaluating the effect of proposed changes to the design and/or operational procedures on the success and safety of the mission.
- The basis for in-flight troubleshooting procedures and for finding performance monitoring and error-detection devices.
- Criteria for initial test planning.
From the above list, initial identification of SFPS, input to troubleshooting procedures and find performance monitoring/error detection devices may be the most important benefit of FMECA. In addition, the FMECA procedure is very easy and allows regular design evaluation.
Maps Failure mode and effects analysis
History
The procedures for organizing FMECA are described in the Military Military Procedure document of the US Army MIL-P-1629 (1949); revised in 1980 as MIL-STD-1629A. In the early 1960s, contractors for the US National Aeronautics and Space Administration (NASA) used variations of FMECA or FMEA under various names. The NASA program uses FMEA variants including 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 the ARP926 in 1967. After two revisions, the ARP926 has been replaced by the ARP4761, which is now widely used in civil aviation.
During the 1970s, the use of FMEA and related techniques spread to other industries. In 1971 NASA prepared a report for the US Geological Survey which recommended the use of FMEA in the offshore oil exploration assessment. The 1973 Environmental Protection Agency report illustrates the application of FMEA to wastewater treatment plants. FMEA as an application for HACCP on the Apollo Space Program moved into the food industry in general.
The automotive industry began using FMEA in the mid-1970s. Ford Motor Company introduced FMEA to the automotive industry for safety and regulatory considerations after Pinto affairs. Ford applied the same approach to the process (PFMEA) to consider the potential process causing failure before launching production. In 1993 the Automotive Industry Action Group (AIAG) first published FMEA standards for the automotive industry. Now in its fourth edition. SAE first published J1739 related standards in 1994. This standard is also now in its fourth edition.
Although originally developed by the military, the FMEA methodology is now widely used in a variety of industries including semiconductor processing, food service, plastics, software, and health care. Toyota has taken a step further with the Design Review approach Based on the Failure Mode approach (DRBFM). This method is now supported by the American Society for Quality which provides detailed guidance on the application of this method. Mode Failure Mode and Effect Analysis (FMEA) and Failure Mode, Effect and Critical Analysis (FMECA) procedures identify the failure mechanisms of the product, but may not model them without special software. This limits its application to provide meaningful input to important procedures such as virtual qualifications, root problem analysis, accelerated testing programs, and for the assessment of remaining lives. To address the shortcomings of FMEA and FMECA, Failure Modes, Mechanisms and Effect Analysis (FMMEA) are often used.
Basic requirements
The following covers some basic FMEA terminology.
- Failure
- Loss of function under specified conditions.
- Failure Mode
- The specific way or manner in which failure occurs in the event of an item failure (being part or (sub) of the system) function being investigated; may generally illustrate the way failure occurred. At least it should clearly describe a state of failure (final) of the item (or function in the Functional FMEA case) being considered. This is the result of a failure mechanism (the cause of failure mode). For example; completely cracked axles, defective axles or fully open or completely closed electrical contacts are each separate failure modes of DFMEA, they are not a PFMEA failure mode. Here you check your process, so step x-insert drill process, failure mode will insert the wrong bits of drill, the effect of this hole is too big or the hole is too small.
- Cause of failure and/or mechanism
- Defects in requirements, design, process, quality control, handling or part application, which is the cause or sequence of causes causing the process (mechanism) leading to failure mode for a certain time. Failure mode may have more causes. For example; "Fatigue or corrosion of the structural beam" or "fretting corrosion in electrical contact" is a failure mechanism and in itself (probably) not a failure mode. The associated failure mode (end state) is "full structural beam fracture" or "open electrical contact". The initial cause may be "improper application of the corrosion protection layer (paint)" and/or "(abnormal) vibration input from another system (may fail)".
- Failure effect
- A direct consequence of failure of operations, functionality or functionality, or the status of some items.
- Indenture Level (material billing or functional breakdown)
- Identifier for system level and thus item complexity. Complexity increases as the level is closer to one.
- Local effects
- The failure effect as it applies to the item being analyzed.
- The next higher level effect
- Effect of failure as it applies to the next higher indenture level.
- End effect
- Effect of failure at the highest level of the indenture or total system.
- Detect
- Mode of failure detection by installed manager, operator or detection system, including estimated dormancy period (if applicable)
- Probability
- Possible failures occur.
- Risk Priority Number (RPN)
- Severity (of events) * Probability (of events occurring) * Detection (The probability that the event will not be detected before the user realizes it)
- Severity
- Consequences of failure mode. Severity considers the worst potential consequences of failure, determined by the extent of injury, property damage, system damage and/or lost time to correct failure.
- Description/mitigation/action
- Additional info, including proposed mitigation or action to reduce risk or justify the level of risk or scenario.
Sample worksheet FMEA
Probability (P)
It is important to see the cause of failure mode and the possibility of occurrence. This can be done by analysis, calculation/FEM, viewing similar items or processes and failure modes that have been documented for them in the past. The cause of failure is seen as a design flaw. All potential causes for failure mode should be identified and documented. This should be in technical terms. Examples of the causes are: Human error in handling, Manufacturing induced error, Fatigue, Creep, Abrasive wear, incorrect algorithm, excessive stress or improper operation condition or usage (depending on the basic rules used). Failure mode is given Possible Rank .
Severity (S)
Determine Severity for worst case adverse effects scenario (state). It's easier to write this effect in terms of what users might see or experience in terms of functional failure. Examples of this final effect are: loss of function x, degraded performance, function in reversed mode, overdue function, erratic function, etc. Each final effect is numbered Severity (S) from, say, I (no effect) to V (catastrophic), based on cost and/or loss of life or quality of life. These numbers prioritize failure modes (along with probability and detection ability). Under the typical classification is given. Another classification is possible. See also hazard analysis.
Detection (D)
Means or methods that detect failure, isolated by the operator and/or manager and the time required. This is important for maintenance control (System availability) and is very important for some failure scenarios. This may involve the mode of sleep failure (eg No direct system effect, while the redundancy system/auto item takes over or when failure is only problematic during a specific mission or system) or latent failure (eg damage failure < i> mechanism , like cracks that grow from metal, but not critical length). It should be explained how the mode or cause of failure can be found by the operator under normal system operation or if it can be found by the maintenance crew by some built-in diagnostic or test system. Dormancy and/or latency periods can be entered.
Dormancy or Latency Period
The average time that a failure mode may not be detected can be entered if known. As an example:
- Seconds, automatically detected by maintenance computer
- 8 hours, detected by turn-around check
- 2 months, detected by the scheduled maintenance block X
- 2 years, detected by task check x
Indication
If undetected failures allow the system to remain in a safe state of employment, a second failure situation should be explored to determine whether or not the indication will be proven for all operator and what corrective action might be or should they take.
Indications to operators should be explained as follows:
- Normal. Clear indications for operators when the system or equipment is operating normally.
- Not normal. Clear indications for operators when the system has functioned or failed.
- Wrong. Incorrect indications for operators due to malfunctions or indicator failures (ie, instruments, sensing devices, visual or audible warning devices, etc.).
PERFORMANCE PERFORMAN DETECTION PERFORM ANALYSIS FOR TEST PROCESS AND MONITORING (From ARP4761 Standard):
This type of analysis is useful for determining how effective various testing processes are in latent and dormant error detection. The method used to achieve this involves checking against the prevailing failure mode to determine whether or not their effects are detected, and to determine the percentage of failure rates applicable to the failure modes detected. The likelihood that the detection way itself may be latent failure should be taken into account in coverage analysis as a limiting factor (ie, coverage can not be more reliable than the availability of detection means). The inclusion of detection scopes in FMEA may cause any individual failure to be a single category of securities to now become a separate effects category due to the possibility of detection coverage. Another way to include detection coverage is for FTAs ​​to conservatively assume that there are no loopholes in coverage because latent failures in detection methods affect the detection of all failures defined for the category of failure effects of concern. FMEA may be revised if necessary for cases where this conservative assumption does not allow the peak event probability requirements to be met.
After these three basic steps, the Risk level can be given.
Level of risk (P * S) and (D)
Risk is a combination of Possible Edge Effect And Severity where the probability and severity include the effect on undetectable ( dormancy time ). This may affect the probability of the final effect of failure or the worst case effect, Severity. Appropriate calculations may not be easy in all cases, such as where multiple possible scenarios (with some occurrences) and detection/dormancy ability play an important role (such as for redundant systems). In this case, Tree Error Analysis and/or Events Tree may be needed to determine the appropriate probability and level of risk.
Initial Risk Levels can be selected based on the Risk Matrix as shown below, by Mil. Std. 882. The higher the level of Risk, the more justification and mitigation needed to provide evidence and lower the risk to an acceptable level. High risk must be shown to higher level management, which is responsible for final decision making.
- After this step FMEA has become like FMECA.
Time
FMEA must be updated at any time:
- The new cycle starts (new product/process)
- Changes made under operating conditions
- Changes made in design
- New regulations are instituted
- Customer feedback indicates a problem
Using
- Development of system requirements that minimize the possibility of failure.
- Development of design and testing systems to ensure that failure has been eliminated or risk reduced to acceptable levels.
- Development and evaluation of diagnostic systems
- To help with design options (trade-off analysis).
Advantages
- Catalysts for teamwork and inter-functional ideas exchange
- Collect information to reduce future failures, capture technical knowledge
- Initial identification and elimination of potential failure modes
- Emphasize problem prevention
- Improve your corporate image and competitiveness
- Upgrade production
- Improve product/process quality, reliability, and security
- Improve user satisfaction
- Maximize profits
- Minimize final changes and related costs
- Reduce impact on corporate profit margin
- Reduce system development time and cost
- Reduce the likelihood of the same type of failure in the future
- Reduce potential warranty issues
Limitations
Although FMEA identifies important hazards in a system, the results may not be comprehensive and the approach has limitations. In the context of health care, 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. The challenges surrounding scoping and organizational boundaries seem to be a major factor in the lack of validity.
If used as a top-down tool, FMEA can only identify major failure modes within a system. Fault tree analysis (FTA) is more suitable for "top-down" analysis. When used as a "bottom-up" tool, FMEA can supplement or complement the FTA and identify more causes and failure modes that produce upper-level symptoms. It can not find complex failure modes that involve multiple failures in the subsystem, or report expected failure intervals from certain failure modes down to the top subsystem or system level.
In addition, propagation of severity, occurrence and detection rates can result in a rank reversal, in which less serious failure modes receive a higher RPN than a more serious failure mode. The reason for this is that the rank is an ordinal scale number, and the multiplication is not defined for the serial number. The ordinal rating only says that one rank is better or worse than the other, but not how much. For example, the "2" rating may not be twice as heavy as the ratings "1," or "8" can not be twice as heavy as "4", but multiplication treats them as if they are. See Rate measurement for further discussion. Various solutions to this problem have been proposed, for example, the use of fuzzy logic as an alternative to the classic RPN model.
The FMEA process can be a challenge for participants who have not completed many PFMEAS, often confuse MODE FAILURES with EFFECTS and CAUSES. To clarify, the FMEA Process shows how the process can go wrong. Using the Detailed Process Map will help the person who filled in the worksheet to correctly list the steps of the process being reviewed. The FAILURE MODE then just how that step can go wrong. Example, Process Step 1. Take the right hand part. Can they take the wrong part? (some manufacturing centers have left and right hand part etc). MODE FAILURE puts the left hand side, EFFECTS can damage CNC machines and discarded parts, or holes drilled in the wrong location. Cause, keep inventory of similar parts at work. Why is it important to do PFMEA in connection with the process? When a process is examined or if we ask what could go wrong with the process of unknown problem unfold, solve the problem before it occurs and solve the root cause problem or at least 2 Y deep at 5 Y. Here the manufacturing engineer may be able to poke the tool yoke to prevent the left hand part in the fixture when running the right hand part or the touch program probe off in CNC programming - all before ever making mistakes the first time. If PFMEA is set where FAILURE MODE relates to the feature on the printout, for example FAILURE MODE drills a hole too large - no further understanding of what caused the problem was obtained. Many PFMEAs have been checked and show that little or no value is obtained when reviewing features of print as a FAILURE MODE - little understanding of the cause is obtained. New PFMEA practitioners often try to connect PFMEA FAILURE MODE with FEATURE, many authors have listed this as trying to check in quality rather than a process step list determining how it can go wrong and build quality through root evaluation of the problem.
In addition, there are two flaws
- the complexity of the FMEA worksheet;
- the complexity of its use. The entry in the FMEA worksheet is bold.
The FMEA worksheet is difficult to produce, hard to understand and read, and difficult to maintain. The use of neural network techniques to classify and visualize failure modes is recommended, recently.
Type
- Functional : before a design solution is provided (or only at a high level) its functionality can be evaluated on the potential effects of functional failure. General Mitigation ("design for" requirements ") may be proposed to limit the consequences of functional failure or limit the likelihood of occurrence in these early developments. It is based on the functional details of a system. This type can also be used for evaluation of the Software.
- Design/Hardware Concepts : system or subsystem analysis in the early design concept stage to analyze the failure mechanisms and lower level functional failures, especially for different concept solutions in more detail. This can be used in trade-off studies.
- Design/Hardware Details : product analysis before production. This is the most detailed (in miles 1629 called the Piece-Part or Hardware FMEA) FMEA and is used to identify possible hardware (or other) failure modes to the lowest part level. This should be based on hardware damage (eg BoM = Bill of Material). Failure Effects of Severity, Prevention of failure (Mitigation), Failure Detection and Diagnostics can be fully analyzed in this FMEA.
- Process : analysis of manufacturing and assembly processes. Quality and reliability can be affected from process errors. The inputs for FMEA include work process/task details.
See also
References
Source of the article : Wikipedia
0 Comments