|
|
This Month's Theme is FMEA Causes
Next month's theme will be controls
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. To find out something you have always wanted to know about FMEAs, submit your question to Carl.Carlson@EffectiveFMEAs.com.
cause [kôz, noun]
In an FMEA, a "cause" is the specific reason for the failure, preferably found by asking "why" until the root cause is determined.
For Design FMEAs, the cause is the design deficiency that results in the failure mode. For Process FMEAs, the cause is the manufacturing or
assembly deficiency (or source of variation) that results in the failure mode.
There can be many causes for each failure mode, and the team should identify as many causes as are needed to document their concerns. Causes should be described in sufficient detail to establish the underlying mechanisms of the cause.
FMEA Tip of the Month
It is impossible to overstress the importance of fully analyzing and understanding the cause. A half-analyzed cause has little value, as the cause is the heart and soul of the FMEA. Take the example of a projector lamp shattering. If the FMEA team simply describes the cause as "over pressure" and does not ask why the over pressure occurs, the root cause of "wrong gas" is not established. The team will end up trying to solve "over pressure," and may miss recommending the correct gas specification. The problem will not be solved. It is often useful to use the phrase "due to" to help get the root cause. For example, in the case of the projector lamp shattering, a possible cause could be "over pressure due to wrong gas."
Many practitioners use repeated questioning of the FMEA team to ensure that the basic "why" is determined as the cause of a failure mode. This technique, called the Five Whys, can be very helpful, especially when the root cause is not forthcoming. The Five Whys is a technique developed by Taiichi Ohno, originator of the Toyota Production System. It means that by asking "why" five times, the team will be able to discover the progression of cause-and-effect relationships behind a problem and the root cause that is below the surface.
Beginner’s Problem
In an FMEA, which of the following is true about a "cause"? (Select all that apply) [Show/Hide Answers]
1. A "cause" is the specific reason for the failure.
(True)
2. A "cause" is the potential consequence or impact of the failure to the system or end user.
(False. The potential consequence or impact of the failure to the system or end user describes an "effect.")
3. There is always one cause for every failure mode.
(False. There may be many causes for each failure mode.)
4. If a cause occurs, the corresponding failure mode occurs.
(True)
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.)
Intermediate Problem
[The intermediate problem repeats the same scenario from previous months. This month, readers will be asked to continue the analysis by the identification of a cause.]
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:
- Airline cargo handler uses extra force to close rear door, bending door pin. Door does not securely close.
- The door vent flap does not trigger the electronic alarm, and the pilot is not notified the cargo door failed to lock securely.
- 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.
- 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.
In previous months, we focused on one possible function, one possible failure mode for the identified function and one possible effect for the identified failure. The answer for the function of the door latch-pin was something similar 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;" for the failure mode, it was something similar to "door latch pin bends under maximum stress loading," and for the effect of the failure it was something similar to "bent latch pin allows the door to appear to be closed when it is not fully secure, thus failing to abort airplane takeoff, potentially creating a pressure differential between inside and outside air, with the possibility of catastrophic cargo door blowout during flight."
This month we'll focus on a cause for the failure of 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 controls and recommended actions.
Problem: Use the door latch-pin failure of the DC-10 cargo door latching subsystem as an example to identify one possible cause for the identified failure mode "Door latch pin bends under maximum stress loading." [Show/Hide Answer]
Answer: For the cause, your answer should be something like "Door latch pin bends under extreme loads due to inadequate pin diameter" or "Specification of pin material has inadequate hardness."
Advanced Problem
Scenario: A Process FMEA is being performed on an optical prism, which is part of a precision laser system. The prism glass surfaces must be very smooth in order to accurately reflect and redirect light for laser applications. When the Process FMEA was nearing completion, the FMEA facilitator asked the FMEA team if there were any concerns that had not been brought forward or addressed. One of the team members said there was a concern. However, in their entire prism manufacturing history, there had never been a workable solution to this problem; therefore, it would be a waste of time to bring it up in the FMEA. The facilitator asked about the concern, and the team member said it had to do with gas bubbles in the prism glass. He said that no one understands why these bubbles occur, and they will occur from time to time in the manufacturing process. The entire team concurred that this problem will occur at a moderate frequency and when it does, the prism surface cannot be smoothed properly and the laser system performance will be degraded. However, since it has no solution, putting it in the FMEA would only waste the time of the FMEA team and management. The FMEA facilitator considered different options, including leaving the gas bubble concern out of the Process FMEA, or entering it without a cause. There may be other options the facilitator should consider.
Problem: In your opinion, what should the FMEA facilitator do and why? Write down your answer and compare to the following. [Show/Hide Answer]
Answer: There are times when the cause of a problem is not immediately available to the FMEA team. When this happens, the FMEA facilitator should recognize this fact, and avoid the temptation to skip over the problem or enter ineffective solutions in the FMEA. This takes excellent facilitation skills and willingness to face difficult choices.
Summarizing the problem, the FMEA team believed gas bubbles would occur with moderate frequency; and when they did occur, the performance of the laser system would be degraded. Leaving this concern out of the Process FMEA is not a good option. It is always best to factually, and without emotion, include the concerns of the FMEA team, along with recommendations for addressing the most serious concerns. However, in this case, the FMEA team did not know the reason for the problem. The FMEA facilitator and team can do the following: The gas bubble concern can be entered as a failure mode. The cause of failure can be temporarily noted as "unknown." The team can use the Recommended Actions column to brainstorm actions to identify the cause of the problem. If the team does not know what to do, the FMEA facilitator should encourage the team to identify specific steps to analyze the cause of the problem. Possibly new laboratory equipment is needed to analyze the nature of the gas bubbles. Possibly a review of academic research literature into the gas bubble problem would be helpful. Possibly one or two new FMEA team members need to be added, who have skills and experience with the problem. The FMEA team should enter the steps that are needed to get to the root cause of the problem, and bring the gas bubble problem and the recommended steps to the attention of management in order to obtain support for root cause analysis. Once the root cause is identified, the cause of the problem should be entered in the FMEA and new recommendations should be added to the FMEA to reduce the risk associated with the problem to an acceptable level.
Something
I’ve always wanted to know about FMEAs
"A prudent question is one-half of wisdom." Francis Bacon
A HotWire reader from China submitted the following questions to Carl Carlson. To submit your own question about any aspect of FMEA theory or application, e-mail Carl at Carl.Carlson@EffectiveFMEAs.com.
Hi Carl,
1. How do "boundary diagrams" and "interface matrices" link to DFMEA? Could you please share experience regarding how using "boundary diagrams" and "interface matrices" help to improve FMEA process, and identify important functions? [See Answer]
2. How can you define a system level function? The DFMEA team tends to drill down functions to subsystem and component functions when we conduct system level DFMEA. It would be endless and low efficiency, and should be handled by subsystem/component DFMEA. So could you please share some of your experience regarding how to define system level functions, subsystem functions and component functions? [See Answer]
Carl: I appreciate these very insightful and application-based questions. My answers are below.
An FMEA boundary diagram (also called an "FMEA block diagram") is an essential input to new FMEA projects. It is a visual depiction of the entire system or design to show clearly the boundaries of the FMEA analysis (what is included and not included), the interfaces between the items, and other information that can help to depict the scope of the FMEA. The functions of the FMEA must be within the scope of the diagram, and include all of the interfaces that are identified.
An FMEA Interface Matrix, on the other hand, is an optional input to System or Subsystem FMEAs. It is a chart with the subsystems and/or components (depending on the scope of the FMEA) on both the vertical and horizontal axes, and clearly shows which interfaces must be considered in the analysis and the type of interface. It is done when the FMEA team wants to ensure that all of the various types of interfaces are included in the analysis, missing none. The functions of the FMEA must include all of the identified interfaces.
Staying within the boundaries of the analysis is important in order to avoid overly long FMEAs. This takes good preparation (FMEA block diagrams, etc.) and good facilitation. This concept can be demonstrated using excerpts from fictitious FMEAs on an All-Terrain Bicycle: System FMEA on entire bicycle, a subsystem Design FMEA on the handbrake subsystem and a component design FMEA on the brake cable.
Illustration from the book Effective FMEAs, by Carl S. Carlson, published by John Wiley & Sons, © 2012
The facilitator must keep the team focused on both the scope and the level of the analysis. The team can drill down by doing lower levels of analyses. Notice the functions have increasing detail as you move to lower levels of analysis.
The following definition of System FMEA will help to clarify the appropriate functions at the system level.
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 a 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.
Hope that answers your questions. Feel free to ask any follow up questions at any time.
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 35 years of experience in reliability testing, engineering and management positions, and is currently supporting clients from a wide variety of industries, including clients of HBM Prenscia. Previously, 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.
Selected material for
FMEA Corner articles 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.
Carl Carlson can be reached at carl.carlson@effectivefmeas.com.
