|
|
This Month's Theme is Determining the Scope of the FMEA
Next month's theme will be making the scope visible
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.
Questions and answers are a great way to learn about FMEAs, for both experienced and less experienced FMEA practitioners. Please feel free to ask any question about any aspect of FMEAs. Send your questions to Carl.Carlson@EffectiveFMEAs.com, and your contact information will be kept anonymous. All questions will be answered, even if they are not featured in the FMEA Corner.
scope [skohp, noun]
The Oxford English Dictionary defines "scope" as "the extent of the area or subject matter that something deals with or to which it is relevant."
Why is it important to determine the scope of an FMEA project?
"Begin with the end in mind" – Stephen Covey
Determining the scope of an analysis is an important step because clearly defined boundaries establish the issues that are to be considered and the approach that the team will take during the analysis.
The scope needs to define the major elements of the FMEA project such as the subsystems or components that will be analyzed, interfaces between lower level subsystems or components, interfaces with environment and/or humans, and other elements.
The other reason why scope needs to be well defined is to avoid "scope creep."
What is "scope creep"?
Many FMEA projects suffer the effects of "scope creep," in which the project begins without agreed upon boundaries and then expands as the meetings go on. If this happens, the team must go back and redo the early work to take into account the larger scope and the project becomes "endless."
The FMEA scope typically includes . . .
For System FMEAs, the scope typically includes system-related deficiencies, 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.
For Design FMEAs, the scope typically includes design-related deficiencies, with emphasis on improving the design and ensuring product operation is safe and reliable during the useful life of the item. For subsystem Design FMEAs, the scope includes the subsystem itself, as well as the interfaces between adjacent components.
For Process FMEAs, the scope typically includes manufacturing- or assembly-related deficiencies, as identified in manufacturing and assembly operations, shipping, incoming parts, transporting of materials, storage, conveyors, tool maintenance, and labeling.
For each type of FMEA, the exact scope will need to be determined by the FMEA team.
FMEA Tip of the Month
Tip 1: In defining the scope of any FMEA project, it is essential to include the interfaces between adjacent subsystems or components. This is important because empirical data show that at least fifty percent of problems occur at the interfaces between subsystems or components.
Tip 2: One of the most effective techniques to define the scope of an FMEA project is to "make it visible." Design FMEAs use FMEA block diagrams. Process FMEAs use process flow diagrams. Making the scope visible will be the theme of next month’s FMEA Corner.
Beginner’s Problem
You are part of a team of engineers that is redesigning an all-terrain bicycle. You’ve been asked to lead the System FMEA. Describe some of the ingredients that you might include within the scope of your System FMEA. [Show/Hide Answers]
The following are possible ingredients of a System FMEA for an all-terrain bicycle. These can be converted into primary functions, and each one should be properly described, including standard of performance. The final scope of the System FMEA needs to be determined by the System FMEA team.
- Overall system-related functions for the bicycle (what the bicycle is intended to do)
- System safety functions (the overall safety of the bicycle and rider)
- Integration of subsystems (how the various subsystems should perform together)
- Interfaces between subsystems (physical connections, material exchange, energy transfer, data exchange)
- Interfaces or interactions with other systems (example might be a GPS system)
- Interactions with the surrounding environment (such as pavement, weather)
- Human interaction (such as rider, mechanic)
- Service (maintenance throughout the life of the bicycle)
- Single-point failures (where failure of a single component results in complete failure of the entire system)
- Other issues that could cause the overall system not to work as intended
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.)
Something
I’ve always wanted to know about FMEAs
The important thing is not to stop questioning. — Albert Einstein
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@EffectiveFMEAs.com.
In the DFMEA detection criteria (ref pg43, or pg149, your text), it ranks degradation testing as most effective (lowest Detection rating), followed by test-to-failure, and finally by pass/fail testing as least effective as a detection method. While I would agree that pass/fail testing is the least effective detection of the three, I would have put true test-to-failure testing as a more effective detection method than degradation testing. The thought being that in taking something all the way to failure you know without doubt what that failure mode is, and how long it took to get there. I suppose that degradation testing perhaps has the advantage of requiring less test time than complete test-to-failure. I’d be interested in your thoughts.
Carl: I’ll begin my answer with a quote from an engineering statistics handbook written by the National Institute of Standards and Technology:
"When failure can be related directly to a change over time in a measurable product parameter, it opens up the possibility of measuring degradation over time and using that data to extrapolate when failure will occur. That allows fitting acceleration models and life distribution models without actually waiting for failures to occur."
Test-to-failure is a very useful technique to understand the nature of failure and to be able to estimate the life of a product in service. However, as you point out, the time to achieve failure can drive up testing costs. Properly done accelerated testing mitigates this cost and improves results.
The relative ranking that placed degradation testing ahead of test-to-failure testing was from the SAE and AIAG guidelines. Their rationale for degradation testing being slightly better assumes that the test developer knows the failure distribution (including where failure occurs) and can model the progression to failure. In this case, a degradation test can have an advantage over test-to-failure.
Best Regards,
Carl
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.
