<<< Back to Index
This Month's Article >>>

FMEA Corner 
This Month's Theme is FMEA Effects
Next month's theme will be causes

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.

 

 

 
ef·fect [ih-fekt, noun]
In an FMEA, an "effect" is the consequence of the failure on the system 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. There can be more than one effect for each failure mode. However, in most applications the FMEA team will use the most serious of the end effects for the analysis.


!FMEA Tip of the Month

Identifying effects may include local, next level and end effect, or it may include only the end effect. If the standard being used by the team only requires end effect, it is still a good idea to include the verbiage in the end effect column tracing the local and next level effects to the end effect. This will be helpful when the team decides on corrective actions for high severity issues, and shows due care in the analysis. However done, the team should always arrive at the end effect of the failure mode on the user or system. End user effects should reflect what the user might notice or experience. They should clearly state if the effect of a failure mode could potentially affect safety or non-compliance to regulations, when applicable. For Process FMEAs, the effects can manifest at the next operation, subsequent operations, the dealer or distributor, as well as the end customer.

Xfmea users can choose "Grouped Effects and Causes" when setting up the project properties for the FMEA project. This will allow the entry of multiple effects, with the software choosing the highest severity for the analysis. See screenshots directly below.

*Beginner’s Problem

In an FMEA, which of the following is true about an "effect"? (Select all that apply) [Show/Hide Answers]

1. An "effect" is the specific reason for the failure.

2. An "effect" is the potential consequence or impact of the failure to the system or end user.

3. An "effect" is the manner in which an item does not accomplish its intended functions.

4. For Process FMEAs, an "effect" can manifest at the manufacturing/assembly area, as well as with the end-user.

**Intermediate Problem

[The intermediate problem repeats the same scenario from last month. This month, readers will be asked to continue the analysis by the identification of an effect.]

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:

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.

Last month, we focused on one possible function, and one possible failure mode for the identified function. This month we’ll focus on an effect 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 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 effect for the function and failure mode that were identified last month: "Function: 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. Failure Mode: Door latch pin bends under maximum stress loading."

Try to trace the effect from the local (cargo door) all the way to the end effect on the aircraft system. [Show/Hide Answer]

?Something I’ve always wanted to know about FMEAs
"A prudent question is one-half of wisdom." Francis Bacon

A HotWire reader 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.

Carl,

Can you please help me in understanding System FMEA with respect to the following questions?

I understand that for new product programs or new application of existing design, we perform System FMEA before the design gets frozen. However, this is not best followed for Continuous Improvement changes or small design changes. In those cases, sometimes Design FMEA gets addressed, but essentially may not address system issues. Here consideration is that, those changes may affect system functionality. Example is coolant composition change, flow pressure change for pump, filter element change, etc. Is there any objective evaluation criteria when to do System FMEA? How should this issue be addressed when evaluating small design changes, for System FMEA may require more resources and may not be feasible?

Consider the following proposed changes:

Above scenarios are for making my query clear. Here my real concern is shall I perform System FMEA with all these changes proposed, as there may be some impact on other functional systems of vehicle? Or do you suggest some objective evaluation, so that it should give me some rating or decision on performing of System FMEA for each design change proposed. There should not be any confusion when to perform Design FMEA or System FMEA. What are your recommendations to handle these kinds of situations?

Carl: There are two ways that changes to product programs can be managed. Both will be explained below.

The first way to manage system changes is by updating the System FMEA and performing or updating any needed Design FMEAs. For new product programs, a System FMEA should be done as soon as system concept is determined, and completed (as you note) before system design freeze. The System FMEA can be subsequently updated when there are changes to the system configuration, as you describe in your question above. The System FMEA update should assess how changes to system configuration or components impact the system itself, as well as the interfaces between subsystems and/or components, and recommend actions to reduce risk due to the changes. The update to the System FMEA is not a new System FMEA, but merely a review of the current System FMEA to make needed adjustments. Your question on when to update a System FMEA can be answered as follows: when there are changes to the system configuration or componentry that impact the operation of the system itself, or impact the interfaces between subsystem and/or components within the system, it is a good idea to update the System FMEA. What sometimes seem to be minor changes to components or interfaces can cause significant system problems. In addition to the System FMEA update, individual Design FMEAs can be done (or updated) on the subsystems or components that have been changed. Not all changes justify a Design FMEA. Preliminary risk assessment can help identify which changes require Design FMEAs, and is fully covered in chapter 4 of my book, and in ReliaSoft’s FMEA training.

The second way to manage system changes is through the use of Change Point Analysis and Design Review Based on Failure Mode (DRBFM). This presupposes that there is a properly done System FMEA to begin with. Here’s an excerpt from the book, which references an excellent presentation by Lisa Allen at the 2008 Applied Reliability Symposium.

A DRBFM project always builds from the success of a Good Design. Once the Good Design is established, the next step in a DRBFM project is called “Change Point Analysis.” It begins with the baseline design and focuses on the specific changes to the design. It is the initial step in Good Discussion. The main idea is to begin with a robust design and to fully understand and document all of the change points to the baseline design. Change points can include changes in design, manufacturing, supplier, supplier design or process, usage environment, interfaces, specifications, performance requirements, or any other changes.

Both Change Point Analysis and DRBFM are fully covered in chapter 13 of my book.

Best of luck to you, and thanks for the questions.

Carl


About the Author

Carl S. CarlsonCarl 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.

Effective FMEAsMaterial 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.

 
ReliaSoft