Every month in FMEA Corner, join Carl Carlson, a noted expert in the field of FMEAs and facilitation, as he addresses a different FMEA theme (based on his book Effective FMEAs) and also answers your questions.
fail·ure mode [fāl-yuhr mōd, noun]
In an FMEA, a "failure mode" is the manner in which an item or operation potentially fails to meet or deliver the intended function and associated requirements. Depending on the definition of failure established by the analysis team, failure modes may include the failure to perform the function within defined limits, inadequate or poor performance of the function, intermittent performance of the function and/or performing an unintended or undesired function. There may be many failure modes for each function.
The term "failure mode" combines two words that both have unique meanings. The Concise Oxford English Dictionary defines the word "failure" as the act of ceasing to function or the state of not functioning. "Mode" is defined as "a way in which something occurs." Combining these two words emphasizes that the failure mode is what presents itself (i.e. the manner in which the item does not meet the intended function or requirements).
FMEA Tip of the Month
Identifying failure modes for inclusion in an FMEA is not an academic listing of every conceivable failure mode (such as a failure brought about by the unlikely event of a meteor striking the item) but rather a list of potential failure modes of concern to at least one of the FMEA team members. Most companies are limited in their time, budget and skilled resources. Therefore, provided the FMEA team has the correct membership and is led by a skilled facilitator, it is good practice to limit FMEA entries to areas of genuine concern to one or more of the team members.
In an FMEA, which of the following is true about a "failure mode"? [Show/Hide Answers]
1. A "failure mode" is the specific reason for the failure.
(False. A "failure mode" is the manner in which the item or assembly could fail to meet the intended function and its requirements.)
2. A "failure mode" is the manner in which the item or assembly could fail to meet the intended function and its requirements.
3. In an FMEA, there can be only one failure mode for each function.
(False. There can be many failure modes for each function.)
4. The failure mode description in an FMEA must include the consequence or impact on the end user.
(False. An effect must include the consequence or impact on the end user, not a failure mode.)
October Beginner's Solution
In an FMEA, which of the following is true about a "function"? (Select all that apply)
1. A "function" is what the item is intended to do, and can be listed
with or without respect to any standard of performance. (False. A
function description needs to include the standard of performance. It
is the function statement including the standard of performance that
allows the FMEA team to determine the failure modes.)
2. A "function" is what the item is intended to do, usually to a given standard of performance. (True)
3. There is always one function for each item in an FMEA. (False. There can be many functions for an item.)
4. The function description in an FMEA must include the consequence or impact on the end user. (False. An effect must include the consequence or impact on the end user, not a function.)
Scenario: On June 12, 1972 an American Airlines DC-10 aircraft lost its aft cargo door soon after taking off from Detroit. We'll use this incident to practice identifying the elements of an FMEA. Here is the background to the FMEA problem.
McDonnell Douglas learned from cabin pressure testing that an improperly closed cargo door could burst open due to loss of cabin pressure, potentially resulting in the floor of the passenger compartment crashing down into the cargo compartment. The temporary solution was to put a vent flap in the door that would close by the same linkage that shut the cargo door, which would keep the airliner from holding pressure unless the cargo door was safely latched, thereby alerting the pilot to the problem. However, a bit of excessive force by a baggage handler shutting the door could make the vent flap close even though the cargo door was not fully latched.
The DC-10 with the cargo door vent flap was put back in service. On a brief layover before the Flight 96 leg to Detroit, a cargo handler had trouble shutting the rear cargo door, but managed to get it shut with a little extra force. Since the door-latch signaled "closed," the warning light in the cockpit did not show a problem. However, the force the cargo handler used to shut the door bent a metal linkage on the inside of the door, preventing it from closing properly. The air pressure during ascent generated too much force on the bent door linkage. It sheared off the pins, releasing the door. The cabin near the door collapsed and jammed the control cables to the tail. The rest is tragic history.
The probable failure sequence of the DC-10 cargo door is:
1. Airline cargo handler
uses extra force to close rear door, bending door pin. Door does not securely
2. The door vent flap does not trigger the electronic alarm, and the pilot is not notified the cargo door failed to lock securely.
3. The air pressure outside the cargo door drops during ascent, until pressure on the door from the inside causes the door-latch pin to shear. The cargo door blows out.
4. High-pressure air inside the cabin collapses the floor, resulting in hydraulic lines and cables becoming non-functional.
We’ll use the door latch-pin failure on DC cargo door latching subsystem as an example to practice identifying functions, failure modes, effects, causes and controls, based on the cargo door latch-pin failure history. This month we’ll focus on one possible function and failure mode for the door latch-pin of the DC-10 cargo door. We’ll continue this exercise in the next several months as we focus on the proper identification of failure effects, causes and controls.
Problem: Use the door latch-pin failure of the DC-10 cargo door latching subsystem as an example to identify one possible function of the door latch-pin of the cargo door and one possible failure mode for the identified function. [Show/Hide Answer]
Answer: Your answer for the function of the door latch-pin should be something like "To fully secure the cargo door in the closed position during all operating loads and environmental conditions without allowing the door to close unless fully latched." Your answer for the failure mode should be something like "Door latch pin bends under maximum stress loading."
Something I've always wanted to know about FMEAs
HotWire reader Tom Crenna from Arthrex, Inc. submitted the following question to Carl Carlson. To submit your own question about any aspect of FMEA theory or application, e-mail Carl at Carl.Carlson@ReliaSoft.com.
We have an electro-surgical medical device system consisting of the following:
1. Should the user and patient be part of this system? [See Answer]
2. How would we perform an Application or System FMEA on this? [See Answer]
3. Is an Application and System FMEA the same thing? [See Answer]
Carl: Hi Tom. Those are excellent questions.
Let me begin my answer with the definition and scope of a "System FMEA":
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 FMEA, the focus is on functions and relationships that are unique to the system as a whole (i.e., do not exist at lower levels). The System level FMEA includes 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.
As you can see from this description, the scope is not set in stone. It is up to the FMEA team (and supporting management) to determine the exact scope of individual FMEAs. For a situation like the one you described, there are two approaches that practitioners use. One approach is to do two different FMEAs: a System FMEA that includes just the device system itself and not the interactions/interfaces with users and patients, and a separate Human Factors (or Application) FMEA that covers only the interactions/interfaces between the system and the users and patients. The second approach is to do a more comprehensive System FMEA, which includes within its scope the interactions/interfaces with users and patients in addition to the device system. International standards or company policy may dictate which approach you are required to use, so it is important to familiarize yourself with appropriate standards and policy. Regardless of which approach you use, be sure to make the scope visible through the use of a properly done FMEA Block Diagram. This will show clearly the scope of your FMEA, including interfaces with humans.
A thorough answer to this question will go beyond the scope of this forum. In Effective FMEAs, I dedicate three entire chapters to the preparation, procedure and implementation of all different types of FMEAs, including System FMEA. Having said that, let me provide a few tips to get you started.
Let's assume you know how to prepare and conduct an FMEA and want to know what is different about a System FMEA (including the interactions with users and patients). One of the first considerations is whether to include the interfaces with humans in the system hierarchy (as you have done), or to include the human interfaces as interface functions in the list of primary functions at the system level. I typically use the latter, but it can be done either way. The most important thing is to include system interactions with humans somewhere, so they do not get missed in your FMEAs.
If you include the interface between user(s)/patient and the bipolar ESU system in the system hierarchy, then it should be so described in the system hierarchy as "user-to-system interface" and "patient-to-system interface," rather than merely "User(s)" and "Patient." If you include the user(s)/patient interface to system as interface functions, make sure they are properly described functions as covered in October's HotWire FMEA Corner, including the standard of performance for each function. It is also important to do an FMEA Block Diagram that clearly shows the scope of your FMEA, and shows the four types of interfaces (physical connection, material exchange, energy transfer and/or data exchange).
One other point is to include in your System FMEA the interfaces between the various subsystems, as these can generate more than 50% of the failure modes. You will have to review your risk ranking scales to be sure they apply well to System FMEAs, Application FMEAs (if you do them separately) and Design FMEAs (typically done at the subsystem or component level).
I think we covered this above. Many medical device companies separate System FMEA (scope: the device system) and Application (or Human Factors) FMEA (scope: interfaces between device system and humans). As I have said above, you can do these separately, or combine them into one more comprehensive System FMEA. The key is to show clearly the scope of your FMEA, and to include all of the subsystem-to-subsystem interfaces, as well as the interfaces between users/patients and the device system.
About the Author
Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines. He has 30 years of experience in reliability testing, engineering and management positions, and is currently supporting clients of ReliaSoft Corporation with reliability and FMEA training and consulting. Previous to ReliaSoft, he worked at General Motors, most recently senior manager for the Advanced Reliability Group. His responsibilities included FMEAs for North American operations, developing and implementing advanced reliability methods and managing teams of reliability engineers. Previous to General Motors, he worked as a Research and Development Engineer for Litton Systems, Inertial Navigation Division. Mr. Carlson co-chaired the cross-industry team that developed the commercial FMEA standard (SAE J1739, 2002 version), participated in the development of SAE JA 1000/1 Reliability Program Standard Implementation Guide, served for five years as Vice Chair for the SAE's G-11 Reliability Division and was a four-year member of the Reliability and Maintainability Symposium (RAMS) Advisory Board. He holds a B.S. in Mechanical Engineering from the University of Michigan and completed the 2-course Reliability Engineering sequence from the University of Maryland's Masters in Reliability Engineering program. He is a Senior Member of ASQ and a Certified Reliability Engineer.
Material for the FMEA tips, problems and solutions is excerpted from the book Effective FMEAs, published by John Wiley & Sons, ©2012. Information about the book Effective FMEAs, along with useful FMEA aids, links and checklists can be found on www.effectivefmeas.com.