PFMA & FMEA - what are these anyway? 3

[KM]

The general topic of my question is flow control equipment at dams. I'm trying to get a hang of what various dam safety documents call "risk informed decision making." I see acronyms like PFMA (Potential Failure Mode Analysis) and FMEA (Failure Mode Effect Analysis) tossed around.

I get the general concept: It's the identification if a number of failure modes for a particular piece of machinery, the assignment of probability (P) to these failure modes, determining the degree of damage each one would cause (D), and then multiply P x D to get R which is the risk of each of the i failure modes.

It's the application of the concept that is getting me. It seems to range from either a very global overview of things that one could do on a table napkin to such gory, gory, detail it would be worthy of a PhD thesis.

So I'm trying to write a SOW for getting some dam gates inspected by a Consultant for various deficiencies. I want to try and prioritize on a bang-for-buck basis a number of improvements to them, and this "risk informed decision making" approach sounds like it might be the way to go....but:

If it involves the table-napkin level of risk analysis, I can do it myself.

If it involves the PhD level of risk analysis, I can't afford it.

How do I describe a Goldilocks-level failure mode analysis? (not too hot, not too cold, but "just right")

 

[dgallup]

We do these for automotive components. There is a design FMEA for every single component as well as each sub assembly on up to the complete part we deliver to our customer. They integrate multiple components and do their FMEA. Then their assembly is integrated into the complete vehicle and the OEM does their level FMEA. There are also process FMEA's that look at all the ways a process could make and pass a non-conforming part.

So I think you would be doing the top level FMEA then asking the equipment manufactures for their FMEA's and they would ask their supplier's for their FMEA's.

You might also want to take a look into the DFR (Design for Reliability) methodology. I find it a little more useful at the concept stage.

----------------------------------------

The Help for this program was created in Windows Help format, which depends on a feature that isn't included in this version of Windows.

 

[drawoh]

KM,

I am getting into this stuff too. I found this on Wikipedia. Google is your friend.

Failure mode and effects analysis

--
JHG

 

[GregLocock]

FMEA can be a powerful tool, or it can be the most soul grinding makework around. If you are doing a system FMEA, put your engineer's hat on (assuming you ever take it off) and list the sort of failures that you really expect to have to work hard to prevent. If your FMEA doesn't catch those failures, then you have done it wrong.

The weighted score is largely useless, certainly you can't say you'll take special actions for 7.1s and leave the 6.9s to fend for themselves. The weighting /process/ is useful.

Incidentally FMEAs don't need to be complete, that is by all means list loads of stuff in the left hand side, but as you work across don't bother filling in the other columns for the obvious ones where no control action is possible or necessary (planet earth struck by moon sized asteroid, and, operator's tea gets cold respectively). If the PM insists that all FMEAs should have an entry in every box then tell him to get a clerk to fill in the rest.




Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[KENAT]

Definitely keep it relatively simple - only complicate it if you really have to.

I saw it used fairly well in aerospace.

I see it used poorly at my current employer making precision metrology equipment.

Back in Aerospace where it really mattered due to safety we did FMECA and kept it relatively simple.

Here they do DFMEA and manage to make it ridiculously complex - I'm not sure of the distinction between some of the columns on the spread sheet - and it manages to be the marginally useful soul destroying task Greg mentions.

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[tygerdawg]

I think Greg & I have similar thoughts on the procedure.
After many years, I've come to the conclusion that D/P -FMEAs are a formalized & proceduralized method of capturing common sense for gigantic organizations that don't seem to have any common sense. It makes one "think it through" and consider all the worst-case scenarios, then suggest abatements. Then it provides a framework for sorting out the most critical things to work on first (the ranking) in a more or less quantitative way. In theory, it is not a one-shot deal, but is meant to be a regularly-reviewed paperwork mechanism to force continuous improvement. Also in theory it is not a bad thing.

Not every process or design needs it: some are small/simple enough. Sometimes he responsible folks are smart enough or just wired to look at the negative worst case scenarios and to figure it out. But like I said: "common sense."

Unfortunately all too often I've seen it as some manager's response to a quality engineering requirement to just get the paperwork done by some imaginary schedule date. The phrase was "soul grinding makework"...quite right. It never gets reviewed again until the next-required cycle dictated by the quality management system. There are just too many fires out on the shop floor to be concerned with something as mundane as continuous improvement paperwork.

As far as YOUR implementation, you have much flexibility in how you define criticality, etc. This is a method I've used before to capture & act upon "the big, important, obvious" stuff (think Pareto diagram). Fully anticipating another review & evaluation to start capturing the small stuff.

TygerDawg
Blue Technik LLC
Virtuoso Robotics Engineering

http://www.bluetechnik.com