Wikipedia describes Event tree analysis (ETA) as “a forward, bottom up, logical modeling technique for both success and failure that explores responses through a single initiating event and lays a path for assessing probabilities of the outcomes and overall system analysis”. However, like many techniques, its benefits rely on it being used properly.
Ten tips for its application are shown below:
- List the barriers which are designed to protect against the initiating event of concern in the same order as the one in which they would be called upon to act as an incident progressed, e.g. fire alarm before sprinkler system. This is because their order of occurrence may affect the outcome (in this case, whether building occupants would have a chance to leave the building before being sprayed with water).
- Every time you introduce an extra barrier within your event tree analysis you potentially at least double the size of your tree with up to 2n possible outcomes if there are n barriers and two branches for each. Therefore, if possible, define the scope of your analysis such that you consider no more than 6-8 barriers, particularly if you will not be using software for your analysis!
- Within an Event Tree, when listing the barriers, phrase all of the questions in terms of the ability of those barriers to act effectively, e.g. “Is the fire alarm activated?”, and then draw the tree such that the branch indicating a positive response is always upwards. This will ensure that the preferred scenarios tend to be clustered together towards the top of the Outcomes column while the least desirable scenarios are grouped near the bottom of the column.
- Remember that barriers can include administrative and personnel activities (e.g. human actions) as well as engineered safety systems (e.g. alarms, interlocks, automatic valves). It may also be necessary to consider physical phenomena such as the presence of ignition sources or weather conditions where these may affect the outcome.
- Although most branch points have two outcomes (depending on whether or not the barrier operates successfully or not), it is perfectly acceptable to have only one outcome (where operation or otherwise has no impact on a particular branch of the event tree). Similarly, there may be cases where it is appropriate to consider more than two outcomes, for example where the outcome depends on the number of components which operate correctly on demand at that stage in the sequence of events.
- The relative probabilities of the different outcomes are dependent on the number of barriers that need to fail for each outcome to occur – as a first approximation, the more barriers that need to fail for an outcome to occur, the lower the probability of the outcome.
- The initiating event can be assigned a frequency (i.e. with units 1/time), or probability (dimensionless quantities with values in the range 0-1). However, the values assigned to the branch splits should always be probabilities.
- Don’t forget that the probabilities associated with any branch point should always add up to 1 – this is because the branches emanating from any branch point should represent all possible outcomes.
- Event trees use conditional probabilities, i.e. the probability of success or failure at each barrier is conditional on the success or failure at each barrier that preceded it. Therefore, for example, it may be appropriate to assign a higher value to the probability of a bund alarm not working if the high level alarm in the associated tank (which is the same design and which is maintained by the same maintenance crew) has already failed. Common cause failures can therefore be represented very effectively within an event tree.
- When quantifying an event tree, a useful check is to sum the frequencies of all of the different outcomes. This sum should equal the frequency of the initiating event since the event tree should have identified all the possible outcomes resulting from the occurrence of that initiating event.
