This Month's Theme is Decomposing System Functions to Lower Levels
Next month's theme will be "essential FMEA facilitation skills"
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.
de·com·pose [dee-kuhm-pohz, verb]
The Merriam-Webster Dictionary defines decompose as "to separate into constituent parts or elements..."
What are system functions?
System functions describe what the overall system is intended to do, including the standard of performance. This can include system safety, system integration, interfaces or interactions between subsystems or with other systems, interactions with the surrounding environment, human interaction, service and other high-level functional descriptions. There can be many system functions, although a System FMEA usually focuses on the primary functions.
Using the fictional all-terrain bicycle example, two system functions might be:
The bicycle must provide safe and reliable transportation, including safe stopping distances and safe operation under all customer usage conditions as defined in the All-Terrain technical specifications.
The bicycle must provide comfortable transportation throughout the life of the bicycle, under all operating conditions defined in the All-Terrain technical specifications.
[Note that it is up to the FMEA team to decide how to describe system and lower-level functions. In this fictional example, the first system function described above is safety related and broadly described. The FMEA team may choose to break this system function into separate system functions that are more narrowly described, such as breaking out the safe stopping function into its own unique function.]
What are lower-level functions?
Lower-level functions relate to subsystems and components. They describe what the subsystem or component is intended to do, including the standard of performance.
In a bicycle hand brake subsystem, one example of a subsystem function is:
Provide the correct level of friction between brake pad assembly and wheel rim to safely stop bicycle in the required distance, under all operating conditions.
In a bicycle brake cable, one example of a component function might be:
The brake cable provides adjustable and calibrated movement between the brake lever and brake caliper, under specified conditions of use and operating environment.
What is meant by decomposing system functions to lower levels?
Referencing the definition of decompose, "to separate into constituent parts or elements," decomposing system functions to lower levels means separating each high-level system function into constituent lower-level elements.
Using the examples above, the system function...
provides safe and reliable transportation, including safe stopping distances and safe operation under all customer usage conditions
... decomposes to the hand brake subsystem as:
provides the correct level of friction between brake pad assembly and wheel rim to safely stop bicycle in the required distance, under all operating conditions
... and further decomposes to the brake cable as:
provides adjustable and calibrated movement between the brake lever and brake caliper, under specified conditions of use and operating environment
Each functional decomposition becomes more detailed and relevant to the function of the lower level.
What is the value of decomposing system functions in an FMEA?
Many companies and FMEA practitioners find that decomposing system functions to lower levels provides a greater understanding of the overall system functionality and generates a meaningful input to the system and lower-level FMEAs. Therefore, decomposing system functions to lower levels can be part of the preparation for the system and lower-level FMEAs, along with FMEA Block Diagram, P-Diagram and information gathering.
Note that FMEA Block Diagrams and P-Diagrams apply to the item being analyzed. Whereas, decomposing system functions to lower levels are input to the set of FMEAs, from system to lower levels.
Are there limitations to the application of functional decomposition?
There are limitations that practitioners need to be aware of when applying functional decomposition.
There are times when the system FMEA is done before the lower levels are sufficiently defined. In this case, the team may not be able to decompose the high-level functions down to the lowest level. For example, if the bicycle design team has not yet decided whether to use conventional brake pads or use newer disc brakes, the decomposition to the pad or disc level may not be appropriate.
Also, there are times when the FMEA team may selectively choose which lower-level items require FMEAs. Decomposing system functions to all lower-level functions will require more work than is needed. For example, if the bicycle design team chooses to do a System FMEA, a Front Wheel Subsystem FMEA, a Wheel Spoke Design FMEA, a Hand Brake Subsystem FMEA and a Brake Pad Design FMEA, decomposing system functions to all lower-level subsystems and components would result in many functional descriptions that would not get used in the resulting FMEAs.
What does a visual display of functional decomposition look like?
Using the fictional all-terrain bicycle example, a functional decomposition chart might look like this.
[Note that this chart represents only one system function, one function for the hand brake subsystem and one function for the brake cable. A complete functional decomposition would include all of the functions that the FMEA team believes to be relevant to the FMEA analyses.]
Attaching a functional decomposition chart in Xfmea
Users can create a functional decomposition worksheet and attach it to the Xfmea system hierarchy. To do this, right-click the item in the system hierarchy where you want to attach the functional decomposition document. Choose Attachments to open the Attachments window.
FMEA Tip of the Month
Functional descriptions should include the standard of performance, or requirement. This is sometimes forgotten or omitted by FMEA practitioners. When doing functional decomposition, remember to include the standard of performance or requirement as part of the functional description. Alternatively, the team may choose to make this a separate column in the FMEA, where the requirement(s) are associated with the corresponding FMEA function in their own column.
I’ve always wanted to know about FMEAs
The important thing is not to stop questioning. - Albert Einstein
A 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).
As a Process FMEA lead, I sit in the room and record many ideas from the FMEA team. However, it is unlikely that all of these ideas will be fully implemented. How should I deal with the unlikely suggested actions?
Carl: The process FMEA team members may suggest many potential improvements to the current manufacturing process. As you know, any changes to the current process, whether the changes are to improve the process or improve the detection system, will be entered into the Recommended Actions column of the PFMEA. However, suggested changes by a member of the FMEA team do not automatically get entered into the final PFMEA. FMEA is a consensus activity and suggestions by a team member must be discussed by the FMEA team and a consensus arrived at before entering into the final PFMEA. It is during this discussion and consensus building that the FMEA team should weed out any suggestions that do not make sense or are not supported by the team. This takes good facilitation skills. If you have my book, please refer to chapter 10, "How to Facilitate Successful FMEA Projects."
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 email@example.com.