FTA, ETA, and BNs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

FTA, ETA, and BNs

gchesterton
Looking for additional ammunition against FTA and ETA. I'd appreciate some additional examples such as the derailment example of Chapter 11 to highlight the benefits of BNs and how to translate from an event tree to a BN.
One thing mentioned on p.355 is that "the semantics of the event tree break down." I'm curious what was meant by this. Perhaps it's the problem often encountered when facilitating a hazard assessment with a group of domain experts: that the group often starts arguing about what is a hazard, what is a cause, what is a condition, etc. An event tree forces them to pick one point in a temporal sequence of events. They get so wrapped up in which step in the chain to label the hazard (for the obligatory hazard log table) that they can't focus on the job at hand -- to provide their best conditional probability estimates. That flaw, among others, seems to plague FTA.
Reply | Threaded
Open this post in threaded view
|

Re: FTA, ETA, and BNs

Martin Neil
I don't have any additional examples to hand; well not in a suitable form for our  model library, but once we get around to revising the book for a new edition we will add some more.

The issue with ETA, FTA etc is similar to that encountered when people try and use/do risk registers and heat maps etc. These methods assume, at best, a linear organising principle with a "risk" at the centre, rather than a network of events, where what is labelled risk depends on your perspective on the network. So inevitably risk people argue about "what the risk is" rather than about whether the overall model makes some kind of sense. This often descends into a power game where some manager resorts to diktat in order to focus minds on "their personal risk" rather than the system's risk.

 "Semantic beak down" is simply that  in an event tree there is one root node, "the hazard", and all events are conditioned on it, as a tree, when in reality what we really want is a graph, to represent the network, and, of course, a graph does not need a single root node but can support many. Under these conditions a graph has a wider semantic bandwidth and can support modelling other variables that interact with the consequences of the hazard and indeed many hazards that may interact in some way. This seems trivial but is liberating.

Likewise, the use of the graph should mean that we don't get hung up on what constitutes a hazard for the hazard log (or should convince us just to bin the damn thing).

Unfortunately some communities of practice seem to be locked into using old methods of analysis embedded in out of date standards, adopted by users who value ritual over substance and oversold by consultants who give customers what they ask for rather than what they need.

Best,

Martin