DFMEA (Design Failure Mode Effects Analysis) is a risk analysis methodology. Sometimes referred to as FMEA (Failure Mode Effects Analysis) without the D because risk analysis in product development may also include PFMEA and UFMEA activities known as Process and User FMEA respectively. The FMEA methodology uses a specific template for performing and documenting risk analysis activities. The template has been around for a long time, but despite its popularity and longevity, completed FMEAs are seldom read. The activity of performing the analysis is common, but review of the documented analysis is infrequent. A completed FMEA may be read once or twice after its completion by the team who created it,
and they too will skim read, referring more frequently just to the verification test planning. This shouldn’t be the case. The fact that a completed DFMEA is tedious to read is not an inherent characteristic of the FMEA methodology, and it’s often not due to the reader’s lack of FMEA literacy. It is most often due to the fact that the FMEA is poorly written, full of obscure logic and understood only by the collective team who authored the document.
A DFMEA is intended to be a living document, but if no one can follow the author’s logic, it will be kept quietly tucked away in a design history folder making only occasional appearances for audits. It’s then quite typical that neither the auditor or auditee can fully read it either, but assuming there’s not a failure investigation going on, they will be satisfied it exists before tucking it back into the files. Before considering how to improve a DFMEA’s readability, I should clarify that the FMEA method seems to be tolerant of an author’s ability to logically document their thought process. In other words, even a poorly written DFMEA can still assist in developing a thorough and effective verification test plan. I suspect this is why the template has been around so long without significant change, and this is why when the document is read, the primary focus is on testing. In other words, the FMEA activity, practiced with use of the template is often effective despite the fact that it contains esoteric logic. This shouldn’t justify a poorly written document, because there are many additional benefits gained when the document’s logic is accessible. As the FMEA is intended to be a living document, its readability is necessary to fulfill its intention.
If a DFMEA is highly readable, it will have a more active life and provide more assurance of risk mitigation. Being readable makes the DFMEA accessible. When accessible to a wider audience, the DFMEA will perform a critical function pertaining to the design’s risk management. When it’s readable, experts from other projects will be able to contribute their expertise. Readability and accessibility, also known as transparency, may make the difference of catching an unusual failure mode outside of the team’s area of expertise. It’s also likely that the product’s engineering ownership will transfer during its life cycle, so an easy to read DFMEA will be the new engineer’s primary access to the design’s history and key attributes. These are a few reasons for putting in the effort to ensure the readability of the DFMEA document. It is worth the effort. As a final comment to encourage the effort required, consider that a failure analysis report, containing forensic evidence as to why something broke, is often fascinating to a diverse technical audience. Such reports can even form the basis of TV shows and documentaries. Risk analysis should aspire to the same level of readability and interest.
Increasing an FMEA’s readability is about ensuring a consistent cadence from line to line, Function to Recommended Action, left to right. The logic has to be consistent and obvious to a person not having an intimate knowledge of the design’s intricacies. Each step, left to right needs to move forward from function to evaluation with consistent logical strides from one box to the next. A similar logic and stride have to be applied to each line almost like meter in poetry. To do this, it’s important to first identify if the failure mode belongs on a U, D or P FMEA. It’s acceptable for a DFMEA to carry line items that may eventually move to a P or U FMEA, but the difference between these lines of analysis needs to be clear because the cadence and logic will change on these lines. This is because the modes of failure and the detection controls are different in these three FMEAs.
A DFMEA’s key purpose is to detect failure modes during development, before the product exists. In this way, the design is iterated during development to safe guard against the predetermined failure modes. This iteration occurs before the design is released to production. A key purpose of the PFMEA is to ensure the manufacturing processes identified to produce the design are fully capable to meet the required design specifications. The team performing the PFMEA may not have expertise on the design’s function or knowledge concerning the effects and severity of the design’s potential failure, but they do have expertise in ensuring the design’s specifications can be met consistently during fabrication. A failure on a PFMEA is a dimension or specification out of tolerance, and the Control-Detection column in a PFMEA documents how such a failed item can be discovered before the product leaves the factory.
In reading a DFMEA, the first logical step observed by the reader is between Function and Failure Mode. A frequent clumsy pair of entries, which may be acceptable in a PFMEA , is to list the Failure Mode as the direct opposite of the Function. Stating the Function as “A” and Failure Mode as “not A” is tedious for the reader and arguably not a mode of failure. Modes of failure for a design should be more abstract and similar to what could happen to any design, such as: yield, fracture, fatigue, brinelling, wear, and corrosion to name a few. Stating the Failure Mode as a direct opposite of the Function is not a mistake that negates the analysis, but the DFMEA’s readability suffers. Not only is it tedious, but the missing mode will probably end up in the Cause column or Effects column, because eventually something will document the mode. This hinders the left to right reasoning with a jumpy cadence; one step containing an obvious opposite and another box containing compound information. This will likely re-occur inconsistently from line to line. Conversely, when the Failure Mode column contains a mode of failure, the Cause-Occurrence column can concentrate directly and succinctly on the mode. For example, a failure mode of yielding implies overloading, so the Cause-Occurrence column will contain information regarding how overloading might occur. This flow forces a step wise analysis separating loads related to yielding from loads related to fracture or fatigue which can be equally evaluated on another line.
Continuing with this example of a yielding mode of failure, the Control-Detection column will document what design specifications directly address application loads and overloads. These specifications likely will address fracture and fatigue as well. This information reads left to right and informs another engineer, outside of the risk analysis team, of the design’s function and the design features and specifications to safe guard against that failure mode. Recommended Actions will typically focus on verification testing or simulation to provide evidence of the design’s robustness. I didn’t mention the Effects of Failure column as it is typically short and simple. Even when exaggerated, it shouldn’t have a negative effect on readability. Although a jest, a little exaggeration may make things more interesting or give the reader reason to doubt.
When the DFMEA document is clearly laid out, its meaning is easily understood and accessed. An outside engineer or expert might recognize an omission. In some cases, the outsider may have unique expertise such as corrosion, tribology, or marine welding. A weakness regarding an obscure or overlooked failure mode could end up becoming a well read failure report or television documentary, so making the analysis accessible may make a difference in preventing this failure. Exaggeration aside, aiming for readability is a best practice. A poorly written DFMEA may not be in error, but it will be read less which is unfortunate. A DFMEA is made to be a living document and in order for it to be read, other people are going to have to interpret its meaning. As authors, let’s make that simple.
