Fault Tree Analysis worthwhile exercise for small systems?

[McLeod]

In the reference listed below, the author makes a statement about Fault Tree Analysis (FTA) while discussing the use of cutsets:

If you are analyzing a small system for which the fault tree only takes up two or three pages, you have either not developed the fault tree correctly, or you shouldn't be wasting your time with this methodology. (p. 9)

I was wondering if other practicing engineers using FTA have found this to be true. We currently only use Failure Mode and Effects Analysis (FMEA) as our risk assessment tool. I've seen opportunities to apply FTA as well, but I'm not sure if the products are complex enough to warrant that approach, given the author's statement. We make a variety of mechanical and electromechanical devices for the medical field, some involving software, but none approaching the complexity of, say, an automobile or a launch vehicle.

Still, two or three pages of gates and events seems to me to be plenty complex enough to apply the method. Is the author biased towards super-complex systems because of his background in the aerospace industry perhaps? Is anyone finding it useful for analyzing small(er)-scale systems?

Ref:
Long, R.A. Beauty and the Beast - Use and abuse of the fault tree as a tool.

http://www.fault-tree.net/papers/long-beauty-and-beast.pdf

 

I am the author of the cited paper and McLeod has a very valid question. My point about a fault tree needing to be more than two or three pages long, is not based on ultra-complex systems. Rather, you will rarely get a one or two page fault tree if the fault tree is properly used to analyze a system (as opposed to simply documenting what you already know about the system). I have used fault tree analysis for relatively simple systems such as a safe & arming device which had three or four relays, two or three switches, and a power source. Even such a relatively small system can take a number of pages and requires a cutset analysis to properly determine whether there are are combinations (or worse, single-point failures)where you thought you had redundancy. There are sytems in which FMEA can potentially miss single point failures. This can occur if a single component is used to tie two supposedly redundant systems together. Even more likely to be missed in FMEA is if the same component is used for several different functions thought to be independent (that together may trigger the top undesired event).

You also do not have to have failure rate data in order to get great value early in a design for finding weaknesses and design flaws.

I would not be surprised if McLeod does have systems that could benefit from fault tree analysis. And, the fault tree is most useful in analyzing protions of a system rather than trying to analyze a huge system for every conceivable problem rolled into one gigantic fault tree. I would caution against using it to document the entire system. Rather I would suggest using for specific problems or for analyzing the design against specific potentially catastrophic scenarios that you are worried about.

At the risk of being accused of promoting my website, I have several other tutorials and papers on the subject. Here is a direct link to a paper I recommend:

http://www.fault-tree.net/papers/long-variants-cutsets-2003issc.pdf

Don't let the fancy title fool you. The title was supposed to be tongue in cheek (and I have been told the paper is a very entertaining read)

The website itself is

http://www.fault-tree.net

 

[McLeod]

Allen! I'm so glad to see that fault-tree.net is back up! We've found the references incredibly useful and entertaining.

Thanks for the response. Since I posted that message we've completed two analyses, and they did indeed take more than two or three pages before they were done. We've also been able to demonstrate to the rest of the organization how FTA can be applied to our systems.

I've got one other question on a related topic. In researching these risk analysis tools, we've come to realize that what we've been calling FMEAs are actually more like Preliminary Hazard Analyses, i.e. top-down hazard inventories. The guidance documents are all pretty explicit about the method being bottom-up, or at least lower-level to higher-level. Unfortunately, there's a good bit of resistance to applying the tool as it was intended because some of our senior management regard the bottom-up approach as too time-consuming and wasteful. (Actually, they feel the same way about FTA.) What advice would you give managers who hold that perspective?

 

[IRstuff]

We've been tasked with FMEA and FMECA requirements in previous contracts. However, the biggest issue has not been whether FMEA or fault tree is better or worse, but, rather, it's been about how much money do you want to, or have available to, spend on the task. A typical electronic system with 15 boards and hundreds of components can take you thousands of hours to identify relevant faults and their effects.

It would seem to me that this distinction between fault tree and FMEA is very artificial. You cannot determine the "effects" part of FMEA without doing a de facto fault tree. The whole point of FMEA is to find the end effect of a failure. Without a formal or informal fault tree, the analysis cannot be performed.

TTFN