This Month's Theme is What is Unique About a System FMEA?
Next month's theme will be "using mode of operation in FMEA applications"
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.
u·nique [yoo-nēk, adjective]
The Oxford English Dictionary defines "unique" as "being only one of a kind; unlike anything else."
sys·tem [sis-təm, noun]
The Oxford English Dictionary defines "system" as "a set of things working together as parts of a mechanism or an interconnecting network; a complex whole."
What is a System FMEA?
A System FMEA is the highest-level analysis of an entire system that is 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 interactions
- Other issues that could cause the overall system not to work as intended
In other words, with a System FMEA, the focus is on the functions and relationships that are unique to the system as a whole (i.e., those that do not exist at lower levels). The System 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 interactions and services into their own respective FMEAs.
What is unique about a System FMEA?
In my experience, 50% or more of system problems occur at the interfaces between subsystems or components, or as a result of integration with adjacent systems. Understanding and addressing interfaces and integration is essential to achieving safe and reliable systems. A System FMEA is uniquely capable of making interfaces and integration issues visible, and addressing them through the FMEA procedure.
When to do a System FMEA?
New product programs usually begin with a System FMEA. If existing designs are changed, the System FMEA may need to be updated in order to ensure the changes are safe, reliable and cost-effective.
How does Xfmea support System FMEAs?
In Xfmea it is easy to create a system hierarchy that shows the entire system. This helps to ensure that all aspects of the system are considered with the appropriate FMEA projects. Once the system configuration is entered into Xfmea in the System Hierarchy, the FMEA defined for the top-level item is the typically the System FMEA.
In addition, the FMEA Block Diagram tool in Xfmea can support the System FMEA by visually displaying the scope of the project, including interfaces, and ensuring that the interfaces are entered into the System FMEA as functions. In the FMEA Block Diagram, identify the interfaces that you wish to bring into System FMEA.
In the Connections area, choose Diagram > Blocks > Create Functions to add the selected connections to the FMEA. Then, in the System FMEA, add any necessary verbiage to develop the function descriptions.
The scope of the System FMEA should be determined at the outset of the FMEA project. For example, the System FMEA team may consider including human interactions, services or software. These areas can either be included within the scope of the System FMEA project or addressed with their own FMEAs.
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. (All questions and responses will be kept anonymous).
I have questions about the following points.
1. DFMEA captures the risk level and the reliability estimation at design phase since it is capturing design characteristics of failure.
2. In the same way, Process FMEA captures the process related failures.
My question is can we link DFMEA and PFMEA together and come up with a reliability prediction and the risk level of product through FMEA?
Carl: Although an FMEA can provide selected information that is sometimes used in a reliability prediction model, an FMEA is not intended to predict reliability. It is intended to analyze and improve designs or manufacturing processes, identify risks and recommend actions that will reduce risks to acceptable levels.
From the design side, some people leverage the occurrence ratings for causes associated with failure modes, and use reliability system modeling to develop a reliability prediction based on the product design. This assumes that the occurrence ratings are objective and can be used outside of the FMEA. However, according to FMEA standards, "The occurrence ranking number has a relative meaning rather than an absolute value." It was designed to be used within an FMEA, as part of the risk assessment to prioritize remedial actions.
Similarly, from the process side, the occurrence rating has a relative meaning rather than an absolute value. Although assumptions can be made that would allow reliability calculations, that is not the intended use of occurrence ratings.
I prefer to use system reliability modeling to predict reliability.
Regarding using FMEA to understand the risk level of the product, this can definitely be done and is one of the objectives of FMEA. Proper use of the risk rankings for severity, occurrence and detection can provide a useful insight into product risk.
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.