[Last month I mentioned that the next article would be on the subject of the application of models in the FMEA process. I am postponing that important topic, in order to do more research. Stay tuned . . .]
This month, I want to discuss one of the most common problems that FMEA teams face: getting confused about the difference between failure modes, effects and causes.
“Things are not always as they seem; the first appearance deceives many.” Phaedrus
Let’s begin with definitions
People at all levels of FMEA experience sometimes get confused about the difference between failure modes, effects and causes. A little careful attention to this subject, to the definitions given in this article, and a bit of practice, will avoid any such confusion.
A failure mode is the manner in which the item or operation potentially fails to meet or deliver the intended function and associated requirements. 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.
An effect is the consequence of the failure on the system or end user. Depending on the ground rules for the analysis, the team may define a single description of the effect on the top-level system and/or end user, or three levels of effects:
- Local effect: The consequence of the failure on the item or adjacent items
- Next-higher level effect: The consequence of the failure on the next-higher level assembly
- End effect: The consequence of the failure on the top-level system and/or end user
For Process FMEAs, the team should consider the effect of the failure at the manufacturing or assembly level, as well as at the system or end user.
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. In most applications, particularly at the component level, the cause is taken to the level of failure mechanism. By definition, if a cause occurs, the corresponding failure mode occurs.
An example to illustrate this potential confusion
Excerpting from Effective FMEAs, chapter 3:
Take the example of “leak.” In many cases “leak” is a failure mode, but not always.
Question: Can “leak” be a failure mode? Answer: “Yes.”
Example: If one function of a storage vessel or tank includes the need to contain fluid to some standard of performance, a “leak” can be a failure mode, which is the manner in which the storage vessel does not perform the containment function.
Question: Can “leak” be an effect? Answer: “Yes.”
Example: If one function of a vehicle body structure is to provide a safe “crumple zone” during accidents to a given standard of performance, a failure mode can be the structure compresses too quickly, which can result in breach of the vehicle fuel tank integrity and a “leak” of fuel. Thus, “leak” becomes part of the effect description.
Question: Can “leak” be a cause? Answer: “Yes.”
Example: If one function of a camera flash circuit is to provide the electrical signal for the flash bulb to a given standard of performance, a failure mode can be missing electrical signal and the cause can be capacitor malfunction or “leak.” Note that this is not a root cause, as the question still exists why the capacitor leaks. The FMEA team may do an FMEA on the capacitor, or further analyze the cause of the capacitor leakage, in order to arrive at root cause.
Failure Mode and Cause progression from system to subsystem to component
Take a look at this chart to help understand how the difference between cause, effect and failure mode depends on the level of analysis on the system hierarchy.
Tip
Whenever an individual or team gets confused about whether a particular word or phrase is a failure mode, effect or cause, I always go back to the item and the corresponding function (and associated requirements). I want to make sure everyone knows where we are on the system hierarchy, and which function we are addressing. This often clears up the the confusion. I then continue carefully to describe the failure mode as the manner in which the item potentially fails to meet or deliver the intended function and associated requirements. Now we have the correct description of the failure mode; same for effect and cause(s).
Summary
A given word or phrase does not itself imply whether it is a failure mode, or an effect, or a cause. Determining whether something is a failure mode, effect or cause depends on the context in the scenario, and where you are on the system hierarchy. There is no substitute for studying and learning the FMEA fundamentals, including a working knowledge of definitions.
Next Article
With “automation” being increasingly applied to engineering processes, I want to take up the subject of using generic lists of failure modes, causes, and failure mechanisms as an aid in conducting FMEAs. Is this a good idea or not, and under what circumstances can it be helpful?
Leave a Reply