[SystemSafety] FMEA draft international standard

[Peter Bernard Ladkin]

On 2014-07-16 12:10 , Andrew Rae wrote:
> What bugs me most is that one reason the standards process has got like this is proliferation of
> useless standards.

They may be useless to engineers, but, as I just mentioned to Matthew, engineers aren't necessarily
the most important audience.

> FMEA is a broad-brush name for a family of techniques. What is the benefit of locking the practice
> of those techniques into a standard?

Yes, I find it a problem that the name "FMEA" is used nowadays for all varieties of qualitative risk
analysis. If you have a more thorough or reliable way to perform qualititative risk analysis, it
gets far more attention if you say it's a "demonstrable improvement to FMEA/FMECA".

I think I can suggest what the technical benefits may be of describing general practice in a standard.

First, if you don't know how to do one, but your regulator or customer says they need to see one,
some kind of general recipe, where you can tick the task-boxes, is very helpful to manage the
process. It doesn't ensure anyone does a brilliant technical job, but it does help management and
auditors to ensure that nothing has been missed out. So a process description is helpful.

Second, to say who does what, and how. Take Step 1: identifying failure modes. The standard should
say: form a team. And it should indicate who should be on such a team. And it should indicate how
you determine when the task has been completed, and how you measure success.

For example, to perform a HAZOP on a process-industry plant you hire an *independent* chairman, that
is, no one who works for the designer, builder or operator or any of their subcontractors. Such
chairmen will bring with them an equally independent secretary who records minutes of all
deliberations. Such phenomena aren't special to HAZOP. They could apply to any FMEA. Actually, to
any RCA also (but it's not in the RCA standard).

> You can't tell if FMEA has been performed well by auditing it against a standard, so it is useless
> for quality control or contract management, if not downright counter-productive. Use of a standard
> implies that someone is spending time checking that it meets the standard instead of meets its
> actual objectives. 

What if the standard says "7.5.25.39: There must be a written document demonstrating that the
<qualitative risk analysis> meets its <actual objectives>"? Then the two tasks are, by definition,
the same, no?

> If the standard is intended instead to teach people how to do FMEA properly, then
> the standardisation process is not the way to go about it.

The IEC FMEA standard is most definitely not intended to teach people how to do FMEA.

> Worse, the name "FMEA" is often used to cover functional failure analysis type activities that have
> different purposes to bottom-up component FMEA. Whichever direction the standard jumps (covering
> both, or restricting to one) it is going to contribute to confused people applying techniques at the
> wrong stage in the lifecycle for them to do any good. 

Yes, that has been a standing problem. It is hard to see how to achieve clarity on it. People wanted
FMEA included in the RCA standard as an RCA technique. People wanted RCA included in the FMEA
standard as an FMEA technique. The requests don't go away. They always reappear at the comments stage.

> We'll get people performing FMEA in a
> particular way at a particular time because "it's in the contract, and the contract calls up the
> standard" instead of "because I think it will help make a safer system".

That has indeed happened with IEC 61508. The net result has been, according to people who were
present both before and after 1997, that civil systems are built nowadays with more attention to all
aspects of functional safety than they were then. If that happens in the small with specific
techniques such as FMEA, then I would deem it a Good Thing.

For example, the following one-sentence standard would be a good substitute for the current FMEA draft:

"To perform an FMEA, (a) engage a qualified engineering-risk analyst with an established track
record of successful analysis, preferably one independent of your company; (b) form a team,
including in the team the risk analyst as chairman, as well as domain specialists familiar with each
of the engineering aspects and artifacts in the system to be assessed; (c) provide the team all
resources to complete an FMEA and prepare a document giving their analysis; (d) the team shall
self-assess when they are finished."

That's what we do. It would help not continually to have to explain this to clients, along with the
rationale. Actually, it would also help our clients not to have to explain this to *their* clients.

> Standards processes seldom have an easy way for people outside the immediate process to say "You're
> whole approach to this is wrong". They're much more suited to complaining about how specific bits
> are expressed, on the assumption that the overall framework makes sense.

Yes. That is my main concern specifically with the IEC comments process. There is no way of pointing
out major incoherence, such as in
http://www.rvs.uni-bielefeld.de/publications/WhitePapers/RVS61508Problems.pdf and
http://www.rvs.uni-bielefeld.de/publications/WhitePapers/rvsIEC61508CaseStudy.pdf , inside the IEC
comments process.

PBL

Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de