Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

November 21, 2007 | Ken Reed

Fault with Fault Trees

Many of us have had experience working with fault trrees.  We have worked throught the painstaking process of determining how a particular material failure will get us to a specific observed failure.  It is an excellent tool to structure your thinking when you need to see exactly what could possibley have caused the failure we are investigating.

Too often, we seem to focus only on the material failures.  The fault tree will have items such as “Relief Valve Fails”, Vessel Wall Fatigue Failure”, “Overpressure”, “Power Supply Fails.”  This is very comfortable, because it is only a piece of “stuff” that failed, and I can easily lay the blame for the failure on an inanimate object.  The fault tree will use the basic event (or equivalent) symbol, signifying that we need look no deeper than this event.

The more realistic investigator may add in a set of events that include “Human Error” into the mix.  More often than not, however, these events are catagorized as Incomplete Events, or those that we just don’t have enough information to further develop.  It is easier to just leave these events on our fault trees as incomplete, and we just accept that the human error is just going to occur.  After all, I can’t replace the human like I can a part.  And parts don’t get their feelings hurt or complain about the result!

Yet, deep down we know (and studies have proven over and over again) that these “human errors” are at the root of over 90% of equipment failures.  Therefore, although our fault trees may eventually get you to the point of discovering what part or condition contributed to the final failure, we still never seem to get to the bottom of 90% of our failures.

It is important that, when conducting a fault tree analysis, we include and run down the human errors that lead to the failure conditions.  The failure conditions that we discover should be considered Causal Factors (“Relief Valve did not lift”), and then a proper root cause analysis can be conducted on the reasons why the relief valve did not lift.  Use Equifactor® to help populate your fault trees.  Then take the results of your fault tree, plug them into your SnapCharT®, and finish your investigation.  Using the rest of the TapRooT® system to assist in your equipment troubleshooting process, you will get much further beyond where the fault tree drops you.

Categories
Root Cause Analysis
-->
Show Comments

Leave a Reply

Your email address will not be published. Required fields are marked *