Re: [SystemSafety] Functional hazard analysis, does it work?

From: DREW Rae < >
Date: Wed, 20 Jan 2016 12:20:07 +1000


Matthew,

My opinion/experience only - I don't have any strong evidence for this. There are three broad areas risk assessment can mess up. There's the non-deterministic bit equivalent to external validity for research - are there things that are outside the bounds of your analysis or that are missed through the modelling and abstraction process? There's the internal completeness question discussed by Peter, which is in theory determinstic if and only if you can create a complete causal model of your system for the properties of interest, and keep it accurate. Then there's the question of whether you understand the identified risks well enough to mitigate them, and to ensure that the mitigations are reliable.

FHA is reasonable at the first and last ones - the imaginative anticipation side of things - for things that can naturally be described as a set of functions. NB - anything _can_ be described by functions, but the more you "force it to fit", the harder it is to extrapolate what might happen. For the good-fit systems, hazards are the same type of thing as the functions, they're just unintended and dangerous. A good example is hazard analysis of software control components within a larger system. It's fairly straightforward for people familiar with the larger system to consider what the software is supposed to do (the functions) and project what else it could conceivably do. Functions interacting with other functions is less of a problem than you might think, because once you're in the space of thinking about what the system _could_ do, instead of what it is meant to do, interaction is just a potential cause of the dangerous behavior, not a brand new dangerous behavior.

Systems for which FHA is a bad fit are those where the hazards are intuitively a different type of thing than the functions. "Chemical plant" is an easy one to see the difficulty, but for similar reasons database software is also a bad fit.

When it comes to internal completeness, FHA/FFA is awful. In particular, the output is very hard to review. For that reason I've always taught that it should be used as a tool to support design, not as a way to validate design. I'm sure we've all got opinions about the best type of risk assessment to apply to a completed design, but FHA/FFA ain't it. It works best "quick and dirty" to create quick turn around and better designs, followed by something more rigorous to "verify" the design against the safety requirements.

That's where modes create problems though. Considering diffferent modes of operation blows out the size and time of the FFA, so that it lags behind the design. Worst example I've seen, they applied FFA to the _requirements document_, finishing two years after the design was finalised.

My safety podcast: disastercast.co.uk
My mobile (from October 6th): 0450 161 361

On 19 January 2016 at 12:20, Matthew Squair <mattsquair_at_xxxxxx

> Thx Andy,
>
> Though I'm not a Dr, that's the wife. :))
>
> Matthew Squair
>
> MIEAust, CPEng
> Mob: +61 488770655
> Email; Mattsquair_at_xxxxxx > Web: http://criticaluncertainties.com
>
> On 19 Jan 2016, at 12:25 PM, andy <loeblas_at_xxxxxx >
> Dr. Squire;
>
> I have had these same kinds of questions in the past. I have studied the
> relationship between probabilistic and non-probabilistic risk assessment
> mostly as a result of a project I worked on for the U.S. Nuclear Regulatory
> Commission regarding digital systems reliability versus non-digital systems
> for safety critical power reactor control. I have also studied the
> statistical work executed by the London folks on common cause failure and
> defense in depth. I believe probabilistic risk assessment is a
> bureaucratic, reductionist, and none to complete analysis of risk
> assessment focused on a “guns and guards” mentality dominant in the USA. I
> have written, 3 or 4 years ago, white papers on my conclusions and readings
> and done some graphic representations of the NRC regulations on common
> cause failure. I have studied Nancy Leveson’s systems approach and taken
> her week long course, also 3 or 4 years ago, and I have developed a
> favorable disposition towards her conclusions. My white papers were
> written to keep my own thinking organized and I can look for any of the
> products I developed for this purpose as well as share my bibliographies
> with you, although some of the documents from the city college folks in
> England were given to me as a professional courteousy and these references
> might be listed but not available for re-distribution according to my
> agreement.
>
>
>
> Let me know if any of this would be useful to you. It will take me a week
> or two to relocate the digital versions of this stuff.
>
>
>
> andy
>
>
>
>
>
>
>
> *From:* systemsafety-bounces_at_xxxxxx > mailto:systemsafety-bounces_at_xxxxxx > <systemsafety-bounces_at_xxxxxx > Squair
> *Sent:* Monday, January 18, 2016 7:43 PM
> *To:* systemsafety_at_xxxxxx > *Subject:* [SystemSafety] Functional hazard analysis, does it work?
>
>
>
> A question to the list.
>
>
>
> Does the process of functional hazard analysis 'work' in terms of
> identifying all functional hazards that we are, or should be, interested
> in?
>
>
>
> The way the FHA process is defined in the various standards seems IMO to
> be very reductionist in nature, fine for identifying the specific
> consequences of a single functional failure mode, but what about functional
> interactions, multiple functional failures, the interaction of modes with
> functions and so on.
>
>
>
> The background to this is that the project I'm working with is about to
> commit to a significant campaign of 'FHA'-ing. So we're engaged in a little
> bit of professional navel gazing about the efficacy of the technique before
> we commit to the campaign.
>
>
>
> --
>
> *Matthew Squair*
>
>
>
>
>
> BEng (Mech) MSysEng
>
> MIEAust CPEng
>
>
>
> Mob: +61 488770655
>
> Email: MattSquair_at_xxxxxx >
> Website: www.criticaluncertainties.com <http://criticaluncertainties.com/>
>
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed Jan 20 2016 - 03:20:37 CET

This archive was generated by hypermail 2.3.0 : Mon Feb 18 2019 - 11:17:07 CET