How many Design FMEAs do you have?

[ga2qa23]

In a product design project, you always want to do a System FMEA at the beginning. Then as the design matures, you're supposed to complete Design FMEA(s) for the subassemblies and even possibly the lower-level components. How many DFMEAs do you typically do? How far down do you go? I personally choose to have a Design FMEA for each subassembly, and only do Design FMEAs for lower-level components if they're super important AND I have control over design/manufacture of that critical component.

And for those of you with hardware/software combination products, do have a System FMEA, then a Design FMEA for hardware, and a separate Design FMEA for software?

 

[Tidge]

I regularly work in medical devices. For me, FMEA are subordinate to a Hazard Analysis.

I prefer to have one DFMEA for discretely recognizable assemblies... the upper limit of a DFMEA is basically "what could go in a box to a customer". This is motivated (partially) because when we assign efforts on design changes, we find it valuable to draw meaningful boundaries around the change.... assigning resources, understanding impacted requirements, regression testing, etc.

We do construct a separate (subordinate) document for software, as for medical devices the requirements of the consensus (development) standard 62304 can be represented most cleanly in a document separate from hardware considerations.

 

[Stoic]

How far down do you go?

My favorite quote on this comes from D. H. Stamatis in Failure Mode and Effect Analysis (2003):

Contrary to what some specialists may think, the FMEA is not always looking for the subatomic and/or molecular root cause, but rather a functional root cause. The distinction is quite great and we all must be cognizant that all 'root causes' are definitional root causes rather than true root causes.

You only need to go as far down as is useful from an engineering perspective. The only real engineering benefit of FMEA is the identification of insufficiently mitigated risks that you wouldn't have identified without FMEA. Sure, providing a full road map of the design team's thought process on risks and mitigations has regulatory and business benefit, but only because of the first benefit. (No, I don't consider risk-driven sample size determination to be an engineering benefit. When your risk matrix says a harm is only OK at an occurrence of 1E-5, it doesn't matter whether your confidence and reliability criteria are 90/90 or 99/99. But I digress...)

If treating a circuit board module as a black box of functions and associated failure modes achieves your goal, there's no need to break the FMEA down into ICs, capacitors, resistors, etc. (Just make sure that you identify all of its functions, lest you miss some failure modes...)

 

[Miner]

There is another benefit to FMEAs beyond the engineering benefit. A well-executed FMEA shows due diligence if you are ever involved in a product liability case. This will help protect you from claims of negligence.

 

[Stoic]

There is another benefit to FMEAs beyond the engineering benefit. A well-executed FMEA shows due diligence if you are ever involved in a product liability case. This will help protect you from claims of negligence.

Sure, that's part of the "regulatory and business benefit" that I noted.