Adding Clarity to Your FMEA
Before commencing with the FMEA meetings, it is essential to visibly show the nature and scope of the analysis. This article discusses different ways FMEA scope can be made visible, and why this is a necessary step.
“The soul cannot think without a picture” – Aristotle
Definition of “scope” and “visible”
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,” and “visible” as “able to be perceived or noticed easily.”
Why is it important to make the FMEA scope visible?
As discussed in the previous article, determining the scope of the FMEA is an extremely 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.
If you haven’t read the article “Determining the Scope of the FMEA”, you can access it with this link.
Making the scope visible ensures that the FMEA team agrees on the precise extent of the FMEA, including interfaces. Elements of the diagram can map to corresponding elements of the FMEA to help ensure that nothing is missed.
An interface is the point or surface where two parts or subsystems meet, and it can take various forms. There are four primary types of interfaces:
- Physical connection (e.g., brackets, bolts, clamps and various types of connectors).
- Material exchange (e.g., pneumatic fluids, hydraulic fluids or any other fluid or material exchange).
- Energy transfer (e.g., heat transfer, friction or motion transfer such as chain links or gears).
- Data exchange (e.g., computer inputs or outputs, wiring harnesses, electrical signals or any other types of information exchange).
Since interfaces can contain up to fifty percent or more of the total failure modes, it is essential that any FMEA carefully consider the interfaces between subsystems and components in addition to the content of the subsystems and components themselves.
The following sections provide a brief introduction to four types of visual depictions that are commonly used to demonstrate the scope of an FMEA. More detailed information, including examples for each type, can be found in Chapter 5 of Effective FMEAs.
FMEA Block Diagram
An FMEA Block diagram (or Boundary diagram) is a visual depiction of the entire system or design to clearly show the boundaries of the FMEA (i.e., what is included and not included), the interfaces between the items and other information that can help to depict the scope of the analysis.
An FMEA Block diagram is recommended as part of the preparation for every System or Design FMEA.
An example of an FMEA Block diagram for a hand brake subsystem of a bicycle is shown next.
In the case of a System FMEA, the FMEA Block Diagram should visually show the interfaces between the various subsystems, as well as between the system and its users. For a Subsystem FMEA, the FMEA Block Diagram should visually show the interfaces between the various components.
Important interfaces from the FMEA Block Diagram can be brought in to the FMEA Function column as interface functions. This will provide trace-ability to ensure that no important interfaces are missed.
FMEA Interface Matrix
An FMEA interface matrix is a chart with the subsystems and/or components (depending on the scope of the FMEA) on both the vertical and horizontal axes. The chart shows which interfaces must be considered in the analysis and the type of interface.
Used for System and Subsystem FMEAs, the FMEA interface matrix is supplemental to the FMEA Block diagram and is done when the FMEA team wants to ensure that all of the various types of interfaces are included in the analysis, missing none. When it is used, it is a good idea to assign character designations for each interface and map them to the corresponding items or functions in the FMEA, to be sure that all desired interfaces are addressed within the scope of the FMEA.
A Parameter Diagram (or P-Diagram) takes the inputs from a system/customer and relates those inputs to desired outputs of a design that the engineer is creating, while also considering non-controllable outside influences. It is a useful tool in brainstorming and documenting input signals, noise factors, control factors, error states and the ideal response of the system.
A P-Diagram is most useful when the item under analysis is a complex system with many system interactions, operating conditions and design parameters, and the team will benefit from seeing these elements visually.
Process Flow Diagram
A Process Flow Diagram (PFD) is a graphical representation of all of the process operations that result in the manufactured or assembled product, and are within the scope of the Process FMEA project. This is essentially the process hierarchy, including manufacturing and assembly operations, shipping, incoming parts, transporting of materials, storage, conveyors, tool maintenance and labeling, and any other steps of the operations that are within the scope of the Process FMEA.
A PFD is done as part of the preparation for all Process FMEAs. Some practitioners use a Process Flow Diagram Worksheet (or PFD Worksheet) which includes a more detailed description for each process step, and other information, such as the significant product and process characteristics.
There are a number of other optional techniques that FMEA teams can use to make the scope of the analysis visible, such as correlation matrix and functional analysis.
FMEA Tip for Beginners
For System and Design FMEAs, a properly done FMEA Block diagram is recommended, with a visible representation of the different types of interfaces. The other diagrams (Interface Matrix and Parameter Diagram) are optional and depend on specific selection criteria.
For Process FMEAs, a properly done Process Flow Diagram is recommended, visually showing the specific manufacturing and assembly operations that will be analyzed.
FMEA Tip for Experienced Practitioners
When using P-Diagrams, certain portions of the P-Diagram map to corresponding elements of an FMEA. For example, the “ideal response” of the P-Diagram can provide input to the primary functions of the corresponding System/Design FMEA; the “error states” can provide input to the failure modes of the FMEA, and “control factors” can provide input to key product characteristics of the FMEA.
The following is a rough draft of a fictitious FMEA Block diagram for an all-terrain bicycle. At least four interfaces are missing. Can you identify three of them?
The following interfaces were omitted from the Hand Brake Subsystem FMEA Block diagram. There may be other missing interfaces.
- The Rider interfaces with the Sprocket/Pedal subsystem, both physically and with energy transfer.
- The Suspension subsystem connects to the Front Wheel subsystem (through the front forks) with both physical and energy transfer interfaces.
- The Front Wheel subsystem physically connects to the Frame (through the front forks).
- The Frame is physically supported in an upright position by the ground, usually through a kick-stand.
FMEA Q & A
The important thing is not to stop questioning. – Albert Einstein
I will be leading some FMEA work for a new product we are developing. The product is primarily comprised of purchased components for which we are not design responsible. The individual suppliers will be held responsible for the DFMEAs of their respective components, and I am thinking that the FMEAs I will be facilitating internally will be primarily “interface FMEAs” to ensure that component A marries up to component B, etc.
Now for the challenges: In a perfect world, the suppliers themselves would all be involved, but I can guarantee you they won’t all be. Suppliers are scattered across the globe. The factories that will ultimately make the product are also scattered (Europe, Asia, USA), which will make the PFMEA work a challenge. Any suggestions on how to manage the supplier FMEAs?
I agree with you that suppliers should do Design FMEAs for the designs they are responsible for, and Process FMEAs for the manufacturing processes they are responsible for. I also agree with you that your company should perform the system/subsystem FMEAs, including interfaces. I typically like to differentiate critical parts from the rest of the bill of materials. For critical parts, I require suppliers to submit FMEAs to the higher-level company, and review and approve them according to the FMEA quality objectives that are discussed in my book. I also like to involve critical suppliers in the interface discussions on a need-to-know basis.
That’s the best approach, in my opinion.
Identifying ground rules and assumptions are an important part of effective FMEA preparation. By discussing and agreeing on the primary assumptions before beginning FMEA meetings, the team will avoid one of the pitfalls of FMEAs. Learn why, and what to do, in the next article.