|
|
|
FMEA: An Overview
Introduction
Customers are placing increased demands on
companies for high quality, reliable products. The increasing
capabilities and functionality of many products are making it more
difficult for manufacturers to maintain the quality and reliability.
Traditionally, reliability has been achieved through extensive
testing and use of techniques such as probabilistic reliability
modeling. These are techniques done in the late stages of
development. The challenge is to design in quality and reliability
early in the development cycle.
Failure Modes and Effects Analysis (FMEA) is
methodology for analyzing potential reliability problems early in
the development cycle where it is easier to take actions to overcome
these issues, thereby enhancing reliability through design. FMEA is
used to identify potential failure modes, determine their effect on
the operation of the product, and identify actions to mitigate the
failures. A crucial step is anticipating what might go wrong with a
product. While anticipating every failure mode is not possible, the
development team should formulate as extensive a list of potential
failure modes as possible.
The early and consistent use of FMEAs in the
design process allows the engineer to design out failures and
produce reliable, safe, and customer pleasing products. FMEAs also
capture historical information for use in future product
improvement.
Types of FMEA's
There are several types of FMEAs, some are used
much more often than others. FMEAs should always be done whenever
failures would mean potential harm or injury to the user of the end
item being designed. The types of FMEA are:
- System - focuses on global system functions
- Design - focuses on components and subsystems
- Process - focuses on manufacturing and assembly
processes
- Service - focuses on service functions
- Software - focuses on software functions
FMEA Usage
Historically, engineers have done a good job of
evaluating the functions and the form of products and processes in
the design phase. They have not always done so well at designing in
reliability and quality. Often the engineer uses safety factors as a
way of making sure that the design will work and protected the user
against product or process failure. As described in a recent
article:
"A large safety factor does not necessarily
translate into a reliable product. Instead, it often leads to an
overdesigned product with reliability problems."
Failure Analysis Beats Murphy's Law
Mechanical Engineering , September 1993
FMEA's provide the engineer with a tool that can
assist in providing reliable, safe, and customer pleasing products
and processes. Since FMEA help the engineer identify potential
product or process failures, they can use it to:
- Develop product or process requirements that
minimize the likelihood of those failures.
- Evaluate the requirements obtained from the
customer or other participants in the design process to ensure
that those requirements do not introduce potential failures.
- Identify design characteristics that contribute
to failures and design them out of the system or at least minimize
the resulting effects.
- Develop methods and procedures to develop and
test the product/process to ensure that the failures have been
successfully eliminated.
- Track and manage potential risks in the design.
Tracking the risks contributes to the development of corporate
memory and the success of future products as well.
- Ensure that any failures that could occur will
not injure or seriously impact the customer of the
product/process.
Benefits of FMEA
FMEA is designed to assist the engineer improve
the quality and reliability of design. Properly used the FMEA
provides the engineer several benefits. Among others, these benefits
include:
- Improve product/process reliability and quality
- Increase customer satisfaction
- Early identification and elimination of
potential product/process failure modes
- Prioritize product/process deficiencies
- Capture engineering/organization knowledge
- Emphasizes problem prevention
- Documents risk and actions taken to reduce risk
- Provide focus for improved testing and
development
- Minimizes late changes and associated cost
- Catalyst for teamwork and idea exchange between
functions
FMEA Timing
The FMEA is a living document. Throughout the
product development cycle change and updates are made to the product
and process. These changes can and often do introduce new failure
modes. It is therefore important to review and/or update the FMEA
when:
- A new product or process is being initiated (at
the beginning of the cycle).
- Changes are made to the operating conditions
the product or process is expected to function in.
- A change is made to either the product or
process design. The product and process are inter-related. When
the product design is changed the process is impacted and
vice-versa.
- New regulations are instituted.
- Customer feedback indicates problems in the
product or process.
FMEA Procedure
The process for conducting an FMEA is
straightforward. The basic steps are outlined below.
- Describe the product/process and its function.
An understanding of the product or process under consideration is
important to have clearly articulated. This understanding
simplifies the process of analysis by helping the engineer
identify those product/process uses that fall within the intended
function and which ones fall outside. It is important to consider
both intentional and unintentional uses since product failure
often ends in litigation, which can be costly and time consuming.
- Create a Block Diagram of the product or
process. A block diagram of the product/process should be
developed. This diagram shows major components or process steps as
blocks connected together by lines that indicate how the
components or steps are related. The diagram shows the logical
relationships of components and establishes a structure around
which the FMEA can be developed. Establish a Coding System to
identify system elements. The block diagram should always be
included with the FMEA form.
Complete the header on the FMEA Form worksheet: Product/System,
Subsys./Assy., Component, Design Lead, Prepared By, Date, Revision
(letter or number), and Revision Date. Modify these headings as
needed.
- Use the diagram prepared above to begin listing
items or functions. If items are components, list them in a
logical manner under their subsystem/assembly based on the block
diagram.
- Identify Failure Modes. A failure mode is
defined as the manner in which a component, subsystem, system,
process, etc. could potentially fail to meet the design intent.
Examples of potential failure modes include:
- Corrosion
- Hydrogen embrittlement
- Electrical Short or Open
- Torque Fatigue
- Deformation
- Cracking
- A failure mode in one component can serve as
the cause of a failure mode in another component. Each failure
should be listed in technical terms. Failure modes should be
listed for function of each component or process step. At this
point the failure mode should be identified whether or not the
failure is likely to occur. Looking at similar products or
processes and the failures that have been documented for them is
an excellent starting point.
Describe the effects of those failure modes. For each failure mode
identified the engineer should determine what the ultimate effect
will be. A failure effect is defined as the result of a failure
mode on the function of the product/process as perceived by the
customer. They should be described in terms of what the customer
might see or experience should the identified failure mode occur.
Keep in mind the internal as well as the external customer.
Examples of failure effects include:
- Injury to the user
- Inoperability of the product or process
- Improper appearance of the product or process
- Odors
- Degraded performance
- Noise
Establish a numerical ranking for the severity
of the effect. A common industry standard scale uses 1 to
represent no effect and 10 to indicate very severe with failure
affecting system operation and safety without warning. The intent
of the ranking is to help the analyst determine whether a failure
would be a minor nuisance or a catastrophic occurrence to the
customer. This enables the engineer to prioritize the failures and
address the real big issues first.
- Identify the causes for each failure mode. A
failure cause is defined as a design weakness that may result in a
failure. The potential causes for each failure mode should be
identified and documented. The causes should be listed in
technical terms and not in terms of symptoms. Examples of
potential causes include:
- Improper torque applied
- Improper operating conditions
- Contamination
- Erroneous algorithms
- Improper alignment
- Excessive loading
- Excessive voltage
- Enter the Probability factor. A numerical
weight should be assigned to each cause that indicates how likely
that cause is (probability of the cause occurring). A common
industry standard scale uses 1 to represent not likely and 10 to
indicate inevitable.
- Identify Current Controls (design or process).
Current Controls (design or process) are the mechanisms that
prevent the cause of the failure mode from occurring or which
detect the failure before it reaches the Customer. The engineer
should now identify testing, analysis, monitoring, and other
techniques that can or have been used on the same or similar
products/processes to detect failures. Each of these controls
should be assessed to determine how well it is expected to
identify or detect failure modes. After a new product or process
has been in use previously undetected or unidentified failure
modes may appear. The FMEA should then be updated and plans made
to address those failures to eliminate them from the
product/process.
- Determine the likelihood of Detection.
Detection is an assessment of the likelihood that the Current
Controls (design and process) will detect the Cause of the Failure
Mode or the Failure Mode itself, thus preventing it from reaching
the Customer. Based on the Current Controls, consider the
likelihood of Detection using the following table for guidance.
- Review Risk Priority Numbers (RPN). The Risk
Priority Number is a mathematical product of the numerical
Severity, Probability, and Detection ratings:
RPN = (Severity) x (Probability) x (Detection)
The RPN is used to prioritize items than require additional
quality planning or action.
- Determine Recommended Action(s) to address
potential failures that have a high RPN. These actions could
include specific inspection, testing or quality procedures;
selection of different components or materials; de-rating;
limiting environmental stresses or operating range; redesign of
the item to avoid the failure mode; monitoring mechanisms;
performing preventative maintenance; and inclusion of back-up
systems or redundancy.
- Assign Responsibility and a Target Completion
Date for these actions. This makes responsibility clear-cut and
facilitates tracking.
- Indicate Actions Taken. After these actions
have been taken, re-assess the severity, probability and detection
and review the revised RPN's. Are any further actions required?
- Update the FMEA as the design or process
changes, the assessment changes or new information becomes known.
|
