Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

FMEA 2

Status
Not open for further replies.

TheInquisitor

Mechanical
Jun 9, 2005
5
0
0
GB
I am currently conducting an fmea on a system and am a bit confused on the design verification column. If there are calculations and existing test procedures that have been carried out at the design stage. Does this necessarily mean that you have to fill in the recommended action columns?
 
Replies continue below

Recommended for you

So can I be clear on this. Once you have calculated the risk and have tests on prototypes to back up your design calculations, Then leaving the recommended actions is ok
 
The question has been raised what if a part is not made to drawing. This will give a potential failure. Surely this is not the responsibilty of the designer how far do I need to go with this. Even if we look at every dimension on the drawing we still can not stop the part being manufactured wrong to drg. This is giving me a headache!!!!!
 
That is where one must differentiate between DFMEA (design) and PFMEA (process). DFMEA must assume parts are made correctly.

DFMEA must account for parts being made incorrectly only as far as the part's design not being fully specified (i.e. omissions in a drawing).
 
Is this FMEA for a new design?

If so, my recollection is that there are supposed to be corrective measures taken to reduce the criticality and effect of the failure modes you've identified

TTFN
 
That was my experience as well. We had to account for any forseeable failure at each station of the system. If it could be designed out...great. If not, what precautions must be taken. Inquisitor, it is a headache. The size of the headache increases exponentially with the number of people in on the FMEA.[smile]
 
Patience! Especially for the facilitator. I recently went through a gruelling DFMEA, and uncovered a lot of potential failures. I'm currently involved in a PFMEA... and the facilitator much rathers to "speed up the pace." Lots of detail being left out, in my opinion. "Machine malfunction" can be broken down into many categories. It should not be a stand alone Failure Mode, in my opinion. Just too broad. Inquisitor, save the recommendations section for the higher RPNs first... then revisit and assess the leftovers again. Consider it an infinitesimal iteration.... never reaching target, but getting smaller.

ChemE, M.E. EIT
"The only constant in life is change." -Bruce Lee
 
When working up a PFMEA I like to use a 5M approach. All your failure modes can be categorized under either of Man, Machine, Material, Method or Measurement.

I fully agree with aspearin1, "machine malfunction" is NOT a single mode. Every instance where a machine designer / builder will place a sensor is a 'corrective action' preventing a failure mode. Every hard stop, every safety feature, every poke-a-yoke are there to head off potential failure.

A lot of these items are built in under a 'common sense' umbrella, but should be given consideration on the PFMEA. Otherwise, down the road, some hot-shot newbie will come along and "improve" an operation by removing or defeating a feature that has no apparent function and doesn't appear to be a corrective action as per the PFMEA.

So many products outlive the original launch team and the PFMEA is one of the living documents that should be there to guide future tinkerers.

regards,

Hydroformer
 
Recommended Actions on an FMEA should be assigned for the highest risk identified in your analysis. Once you complete the analysis, rank order the FMEA by RPN, primary, and the Severity, secondary. Begin assigning Recommended Actions to the top RPN’s. Additionally, as you are completing the FMEA, you might assign Recommended Actions for the obvious high risk. Recommended Action is not required for every line in the FMEA. Be sure the Recommended Action is actionable and executable.
 
I disagree with Hydroformer on using the 5M approach to identify Failure Modes in a PFMEA. The 5M approach will work with causes as you do root cause analysis. It does not apply to the Failure Mode. The Failure Modes are derived from the function.
 
Aspearin1. Be careful applying “Machine Malfunction” as a Failure Mode. It isn’t a Failure Mode, it is a Cause of Failure, and a vague one at that. Look a little deeper for the cause of the malfunction. In addition, you are no longer in PFMEA, you are now doing a machinery FMEA.
 
Hi TheInquisitor,

If you are only "a bit confused" then you're doing better than most. ISO 9000 has new definitions now for design verification vs. design validation:

Subclause 4.4.7, Design Verification, states that design verification must be carried out at appropriate stages of design and must ensure that "design stage output meets the design stage input requirements."
Subclause 4.4.8, Design Validation, is new and is in addition to "design verification." Design validation must ensure that the product conforms to defined user needs or requirements. This is in addition to design verification which must ensure that design stage output meets design stage input requirements. Design validation follows successful design verification and is normally performed on the final product.

The design stage output typically would be drawings, specifications, ie. paperwork. Does the paperwork invoke, enforce, or implement the original design input requirements? In otherwords (according to this old designer's brain) are the drawing details and calculations checked, maybe independently checked, and properly signed off and documented and archived? That would be design verifcation.

Design validation then would be testing or demonstration of the final product (hardware) to assure that it meets the originally intended performance, appearance, dimensions, reliability, etc.
 
This thread is a classic example of why everybody needs to have appropriate standards for how their organization will handle all aspects of Failure Mode and Effects Analysis. It is meant to be a living and breathing document that will likely never be "completed". It should be drilled down to as much detail as possible and necessary for a given situation. No two situations are the same. The purpose in the Risk Priority Number is to identify which items need to be worked on. You should not have to revisit items with high risk or severity if the RPN is low. A low RPN by definition means the risk and severity have been addressed somewhere. Since the FMEA is very subjective, specific rules should used to rate risk, severity, detection etc. That is the only way to insure an effective process in implementing RPN corrective actions for the appropriate hugh risk items.

As for the 5M's, they are used in cause and effect analysis as a tool for root cause identification. What causes could cause a specific effect?
 
Status
Not open for further replies.
Back
Top