What is FMEA?

A Brief Overview

Should an FMEA result in design or manufacturing improvements? Should it ensure that tests discover the right problems? What are the objectives of FMEAs? Whether you are new to FMEA or an experienced practitioner, there is always something to learn. This is the first in a series of articles on FMEA that should expand the knowledge of every reader.

“Successful engineering is all about understanding how things break or fail.” ~ Henry Petroski

What is an FMEA?

Failure Mode and Effects Analysis (FMEA) is a method designed to:

Identify and fully understand potential failure modes and their causes, and the effects of failure on the system or end users, for a given product or process.
Assess the risk associated with the identified failure modes, effects and causes, and prioritize issues for corrective action.
Identify and carry out corrective actions to address the most serious concerns.

An FMEA is an engineering analysis done by a cross-functional team of subject matter experts that thoroughly analyzes product designs or manufacturing processes, early in the product development process. Its objective is finding and correcting weaknesses before the product gets into the hands of the customer.

An FMEA should be the guide to the development of a complete set of actions that will reduce risk associated with the system, subsystem, and component or manufacturing/assembly process to an acceptable level.

Performing an FMEA just to fill a checkbox in the Product Development Process and then filing it away, never to be seen again, is a waste of time and adds no value. If not for use as guidance through the development process, why waste the time and resources to do it in the first place? If effectively used throughout the product life cycle, it can result in significant improvements to reliability, safety, quality, delivery, and cost.

What is the primary objective of FMEA?

The primary objective of an FMEA is to improve the design. For System FMEAs, the objective is to improve the design of the system. For Design FMEAs, the objective is to improve the design of the subsystem or component. For Process FMEAs, the objective is to improve the design of the manufacturing process.

There are many other objectives for doing FMEAs, such as:

• identify and prevent safety hazards
• minimize loss of product performance or performance degradation
• improve test and verification plans (in the case of System or Design FMEAs)
• improve Process Control Plans (in the case of Process FMEAs)
• consider changes to the product design or manufacturing process
• identify significant product or process characteristics
• develop Preventive Maintenance plans for in-service machinery and equipment
• develop online diagnostic techniques

What are the different types of FMEA?

The three most common types of FMEAs are:

System FMEA is the highest-level analysis of an entire system, made up of various subsystems. The focus is on system-related deficiencies, including system safety, system integration, interfaces or interactions between subsystems or with other systems, interactions with the surrounding environment, human interaction, service, and other issues that could cause the overall system not to work as intended. In System FMEAs, the focus is on functions and relationships that are unique to the system as a whole (i.e., do not exist at lower levels). Included are failure modes associated with interfaces and interactions, in addition to considering single-point failures (where a single component failure can result in complete failure of the entire system). Some practitioners separate out human interaction and service into their own respective FMEAs.

Design FMEA focuses on product design, typically at the subsystem or component level. The focus is on design-related deficiencies, with emphasis on improving the design and ensuring product operation is safe and reliable during the useful life of the equipment. The scope of the Design FMEA includes the subsystem or component itself, as well as the interfaces between adjacent components. Design FMEA usually assumes the product will be manufactured according to specifications.

Process FMEA focuses on the manufacturing or assembly process, emphasizing how the manufacturing process can be improved to ensure that a product is built to design requirements in a safe manner, with minimal downtime, scrap and rework. The scope of a Process FMEA can include manufacturing and assembly operations, shipping, incoming parts, transporting of materials, storage, conveyors, tool maintenance, and labeling. Process FMEAs most often assume the design is sound.

Failure Mode Effects and Criticality Analysis (FMECA) is similar to FMEA, with the added step of a more formal Criticality Analysis.

Other types of FMEA include Concept FMEA, Maintenance FMEA, Software FMEA, Hazard Analysis, Human Factors FMEA, Service FMEA, Business-process FMEA, and others.

Each of the types of FMEA are described in detail with examples in the book Effective FMEAs.

Why do FMEAs?

There are a number of business reasons to implement an effective FMEA Process. When done well, FMEA is a proven tool to reduce life cycle warranty costs. When done well, FMEAs will reduce the number of “oops” during product development. It is far less expensive to prevent problems early in product development than fix problems after launch. FMEAs can identify and address safety issues before a potential catastrophe.

FMEA Success Factors

There are six broad success factors that are critical to uniformity of success in the application of FMEA in any company. The six success factors are listed here, and will be elaborated on in future articles.

1. Understanding the fundamentals and procedures of FMEAs, including the concepts and definitions.
2. Selecting the right FMEA projects
3. Preparation steps for each FMEA project
4. Applying lessons learned and quality objectives
5. Providing excellent facilitation
6. Implementing an effective company-wide FMEA process.

Implementing these FMEA success factors will help ensure FMEAs achieve safe, reliable and economical products and processes.

Example FMEA

The entire set of articles in the Effective FMEA Series will explain each step in the FMEA process, including the theory, examples, and application tips. However, I would be remiss to not include an example of an FMEA in the “What is FMEA?” article. Please click on the link to open up an excerpt from a simple FMEA on a pencil. I chose a pencil, because most everybody has experience using a pencil and should be able to relate to the potential failures.

[click to enlarge]

The pencil Design FMEA is a fictitious FMEA that is used for training purposes. It is an excerpt, and not meant to follow any particular FMEA standard. It has a few built-in errors that can be discovered by the more experienced FMEA users. When you have had a chance to review the FMEA, please send me an email at carl.carlson@effetivefmeas.com with any questions or observations about this FMEA. Remember, questions are one of the primary mechanisms for learning, and there are no wrong questions.

FMEA Applications

FMEA procedure has a multitude of applications, spanning across a wide variety of industries and supporting product design and development, manufacturing operations and field operations.

In addition to the most common FMEA applications, such as System, Design and Process FMEAs, the FMEA procedure can apply to software, hazard analysis, maintenance, human factors, service, and even business processes.

All of these applications will be covered in future articles in this series, and are explained in detail, with examples, in the book, Effective FMEAs.

When is an FMEA complete?

Students ask me when an FMEA is complete. Let me first answer when an FMEA is NOT complete. An FMEA is not complete when each column is filled with words. It is not even complete when the recommended actions have been implemented. An FMEA is complete when the risk associated with the item being analyzed is reduced to an acceptable level.

Some companies go beyond the completion of the FMEA from a risk reduction standpoint, and update the FMEA on an ongoing basis, in order to retain post-launch information in the form of a “living FMEA.” The topic of “living FMEA” will be the subject of a future article.

Application Tips

1. As with any quality or reliability tool, FMEA has specific selection criteria. There are guidelines for when to do FMEAs. FMEAs take time and cost money. They should be done when a certain level of risk can be effectively addressed by the FMEA procedure. FMEA selection criteria is covered in a future article and is the subject of chapter 4 of the book.

2. FMEAs have specific quality objectives, based on the most common mistakes in FMEA applications. By learning and applying the FMEA quality objectives, FMEAs can be more effective. The FMEA team should review the quality objectives as needed to ensure they are met before the FMEA is considered complete. FMEA quality objectives are covered in a future article and is the subject of chapter 9 of the book.

In the next article, we’ll explore the underlying philosophy for effective FMEAs and how to use key focus areas to help ensure success in your FMEA applications.

Carl Carlson says

August 26, 2017 at 10:43 AM

Hi Gary. Thanks for the follow-up questions and comments. They are very thoughtful and open up some very good discussion. I’ll reply below.

You say, “It doesn’t seem as important whether an item is repairable or not, COTS or not. It makes sense to establish purpose and focus on that.”
My reply: I agree, with this additional comment. Whether the system is repairable or not can be described as part of the verbiage for one of the functions in the corresponding System FMEA.

You say, “It seems that Design FMECA’s can serve at least two purposes. 1. To determine the effect of failure and how to handle it (may not be necessary to understand cause). This purpose may serve to evaluate and/or establish the design (e.g. technology, configuration, redundancy) to minimize the severity and/or occurrence of failure. 2. To determine the proximate cause (designer responsible specification) of failure to reduce the occurrence of failure. This purpose may serve to evaluate and/or optimize the design for robustness.”
My reply: Regarding your first point, I agree with the concept of your statement. When the FMEA reveals high severity, the FMEA team should try to reduce severity where possible, and this usually requires a design change. However, I always advise FMEA teams to get to root cause for all high-risk issues. The objective for high-risk issues is to reduce severity (if possible) and to get occurrence as low as possible. And reducing occurrence requires understanding root cause, and failure mechanism. Regarding your second point, I agree that one of the objectives for reducing occurrence is to improve the design robustness of the product. And, as you point out, this requires understanding root cause.

You say, “Whether or not an item is repairable and/or COTS would have an effect on the level of proximate cause. Example: for a COTS light bulb it may be necessary to specify a brightness range, spectrum range, maximum wattage, operating hours. The light bulb manufacturer may have a deeper level of proximate cause, for example: filament material, attachment method, sealing method, etc.”
My reply: You are correct. However, this brings up the subject of failure mode and cause progression from system to subsystem to component. In the fictitious bicycle example in my book, the hand brake subsystem may have a failure mode “insufficient friction delivered by hand brake between brake pads and wheel rim”, with one of the causes “cable breaks.” That is not a root cause. A Design FMEA on the brake cable will take up “cable breaks” as on of the failure modes, and drill it down to root cause, such as “”corrosion of cable wiring due to wrong material selected” or “fatigue cracks in cable wiring due to inadequate cable thickness.” I do not usually recommend the system FMEA take every cause to root cause, but rather for high-risk causes, the team can generate the lower level FMEA (or sometimes done by supplier) to get to root cause. This avoids very long system FMEAs. I always advise getting to root cause and failure mechanism to all high-risk issues.

You say, “The pencil example is great for understanding a manufacturer’s FMECA. As a user of a COTS pencil, if the purpose is recording information on the space shuttle, the pencil FMECA example may be too deep. There may not be a need to go into cause, and there may be more serious effects that preclude a pencil’s use in the application.”
My reply: I agree with you. When doing FMEAs on complex systems, I use “preliminary risk assessment” (chapter 4 of my book) to identify where it makes sense to perform lower level FMEAs. And as you point out in your example, it may not make sense to do a pencil FMEA on a complex system that happens to use a pencil.

Great discussion! Please feel free to discuss further or ask any follow-up questions.

Thanks.

Carl

Comments

Gary Bolla says
August 24, 2017 at 5:48 AM
Hi Carl,
Thank you for your previous response. After reviewing a little more material, I think I have a better understanding of FMECA and would like to get your thoughts.
It doesn’t seem as important whether an item is repairable or not, COTS or not. It makes sense to establish purpose and focus on that.
It seems that Design FMECA’s can serve at least two purposes.
1. To determine the effect of failure and how to handle it (may not be necessary to understand cause). This purpose may serve to evaluate and/or establish the design (e.g. technology, configuration, redundancy) to minimize the severity and/or occurrence of failure.
2. To determine the proximate cause (designer responsible specification) of failure to reduce the occurrence of failure. This purpose may serve to evaluate and/or optimize the design for robustness.
Whether or not an item is repairable and/or COTS would have an effect on the level of proximate cause. Example: for a COTS light bulb it may be necessary to specify a brightness range, spectrum range, maximum wattage, operating hours. The light bulb manufacturer may have a deeper level of proximate cause, for example: filament material, attachment method, sealing method, etc.
The pencil example is great for understanding a manufacturer’s FMECA. As a user of a COTS pencil, if the purpose is recording information on the space shuttle, the pencil FMECA example may be too deep. There may not be a need to go into cause, and there may be more serious effects that preclude a pencil’s use in the application.
Regards,
Gary
- Carl Carlson says
  August 26, 2017 at 10:43 AM
  Hi Gary. Thanks for the follow-up questions and comments. They are very thoughtful and open up some very good discussion. I’ll reply below.
  You say, “It doesn’t seem as important whether an item is repairable or not, COTS or not. It makes sense to establish purpose and focus on that.”
  My reply: I agree, with this additional comment. Whether the system is repairable or not can be described as part of the verbiage for one of the functions in the corresponding System FMEA.
  You say, “It seems that Design FMECA’s can serve at least two purposes. 1. To determine the effect of failure and how to handle it (may not be necessary to understand cause). This purpose may serve to evaluate and/or establish the design (e.g. technology, configuration, redundancy) to minimize the severity and/or occurrence of failure. 2. To determine the proximate cause (designer responsible specification) of failure to reduce the occurrence of failure. This purpose may serve to evaluate and/or optimize the design for robustness.”
  My reply: Regarding your first point, I agree with the concept of your statement. When the FMEA reveals high severity, the FMEA team should try to reduce severity where possible, and this usually requires a design change. However, I always advise FMEA teams to get to root cause for all high-risk issues. The objective for high-risk issues is to reduce severity (if possible) and to get occurrence as low as possible. And reducing occurrence requires understanding root cause, and failure mechanism. Regarding your second point, I agree that one of the objectives for reducing occurrence is to improve the design robustness of the product. And, as you point out, this requires understanding root cause.
  You say, “Whether or not an item is repairable and/or COTS would have an effect on the level of proximate cause. Example: for a COTS light bulb it may be necessary to specify a brightness range, spectrum range, maximum wattage, operating hours. The light bulb manufacturer may have a deeper level of proximate cause, for example: filament material, attachment method, sealing method, etc.”
  My reply: You are correct. However, this brings up the subject of failure mode and cause progression from system to subsystem to component. In the fictitious bicycle example in my book, the hand brake subsystem may have a failure mode “insufficient friction delivered by hand brake between brake pads and wheel rim”, with one of the causes “cable breaks.” That is not a root cause. A Design FMEA on the brake cable will take up “cable breaks” as on of the failure modes, and drill it down to root cause, such as “”corrosion of cable wiring due to wrong material selected” or “fatigue cracks in cable wiring due to inadequate cable thickness.” I do not usually recommend the system FMEA take every cause to root cause, but rather for high-risk causes, the team can generate the lower level FMEA (or sometimes done by supplier) to get to root cause. This avoids very long system FMEAs. I always advise getting to root cause and failure mechanism to all high-risk issues.
  You say, “The pencil example is great for understanding a manufacturer’s FMECA. As a user of a COTS pencil, if the purpose is recording information on the space shuttle, the pencil FMECA example may be too deep. There may not be a need to go into cause, and there may be more serious effects that preclude a pencil’s use in the application.”
  My reply: I agree with you. When doing FMEAs on complex systems, I use “preliminary risk assessment” (chapter 4 of my book) to identify where it makes sense to perform lower level FMEAs. And as you point out in your example, it may not make sense to do a pencil FMEA on a complex system that happens to use a pencil.
  Great discussion! Please feel free to discuss further or ask any follow-up questions.
  Thanks.
  Carl
Theyab says
December 16, 2020 at 2:34 PM
Can FMEA calculate the overall system reliability?
- Carl Carlson says
  December 17, 2020 at 4:46 AM
  Hello Theyab,
  FMEA is not the right tool to calculate system reliability. A better tool is System Reliability Modeling (SRM). When done well, SRM creates a model that can be used to estimate reliability. Of course, SRM is only as good as the inputs and corresponding assumptions.
  To answer your question about the use of FMEA to calculate system reliability, there are two ways that some people attempt to estimate reliability using FMEA.
  Some people use the occurrence scale in FMEA to estimate reliability. In some occurrence scales the ratings are associated with failure rates, and that information is used as input to reliability calculations. The problem is the occurrence scale in FMEA is subjective, not objective. It is meant to prioritize risk, not to calculate reliability. I do not advise using the FMEA occurrence scale as input to a reliability calculation. I cover the proper use of FMEA occurrence scale in chapter 3 and 6 of my book, Effective FMEAs.
  The other way that some people use to calculate reliability from FMEA is when a quantitative Criticality Assessment (CA) is done, in addition to the FMEA, which results in FMECA. I don’t have time in this reply to describe the proper application of quantitative CA, but suffice to say there are limitations and assumptions that do not lend to the use of this tool to calculate overall system reliability. I cover the application of quantitative and qualitative CA in chapter 12 of my book.
  Hope that helps.
  Carl