I learned about the Failure Modes and Effects Analysis (FMEA) process for designs some decades ago. I was Supervisor of an Embedded System development group. There seemed to be a lot of evidence that an FMEA on a design was a really good way to identify issues (problems) early in the design process. And we had a lot of downstream problems that caused re-design and schedule delay.
I got a lot of resistance from members of the new product development team:
- This FMEA thing will take too many engineering hours,
- Our job is to make things work not to worry about how they might fail,
- We do not have failure modes for our functional blocks,
- And many more, etc.
I did find a training course which we scheduled in-house for our group. This course described using Guide Words for functional failure modes. That only addressed one of the objections, but we tried some FMEAs on our designs with Guide Words. The Guide Word issue did cause some debate and these FMEAs took more time than we wanted but I believe some of the issues identified prevented more time consumption (re-design and re-schedule) later in the project. Resistance to FMEA was reduced.
I read about Failure Modes, Effects and Criticality Analysis (FMECA) sometime later. FMECA added risk priority numbers (RPN) to the DFMEA process. These RPN numbers were added to show which FMECA lines were the most important. I read that this was important to help project management make a judgement about what problems were critical based on risk. And what problems were not worth fixing. I could see how this was useful when there were too many problems to handle. But, should we add more time to the FMEA for this?
Our group reviewed the addition of extra columns to our spreadsheet but concluded that spending time to choose a number between 1 and 10 for three variables just did not add value for our level of complexity. We determined priority simply by choosing one of three categories: A. Do Not Care, B. Useful to Fix, or C. Must Fix. That was all we needed. RPN numbers just did not look useful for us.
More recently I read an excellent book on FMEA called Failure Modes and Effects Analysis, FMEA Handbook. This was written by a team from the Automotive Industry Action Group (AIAG) and the Verband der Automobilindustrie (VDA). I found the clarity and completeness to be very helpful. This book used the term Design FMEA (DFMEA). And it was clear that in the context of a product as complicated as an automobile, the top down design approach with a top down DFMEA might benefit from RPN numbers with many interactive subsystems from different design teams.
Were we wrong to ignore RPN numbers? No, we used the essential parts of DFMEA that covered the level of complexity for our design. Our focus was on finding design problems in a system with only three levels of architecture design hierarchy. We did not need RPN numbers. We did not need to trace through many layers of architecture tracking failure modes at each level. With tough deadlines, we could not waste any valuable engineering time without a good return on time spent. Even in one project which required functional safety certification, the essential parts of a DFMEA were sufficient to find problems and document our work for the Certification Body.
At exida, we discovered that even a good DFMEA is missing some important information needed for FMEDA work. So, we recommend adding some important detail during the DFMEA when the design context is clear. At exida this expanded DFMEA is was named Design Deviation and Mitigation Analysis (DDMA). It includes all the essential DFMEA information plus . When used with an expert failure knowledge base we call it DexDMA (Design expert Deviation and Mitigation Analysis).
For many applications, a DDMA can replace the DFMEA and can gather the information needed for an FMEDA. We have found this approach to provide good design verification (find problems), good documentation, and a good use of scarce engineering resources. To read more about DFMEA versus DDMA, get the exida White Paper - The Essential DFMEA Process – Maximum value / Optimal Cost.
Related Items
Tagged as: william goble RPN FMEA DFMEA