Event Tree Analysis
Event Tree Analysis (ETA) is an inductive, forward-logic reliability engineering method that graphically maps all possible outcomes (success or failure consequences) stemming from a single initiating event, such as a component failure or accident, accounting for the functioning or failure of safety barriers and subsequent system events.
In ServiceGrid (CMMS) and shop-floor maintenance, ETA is used during risk-based asset reliability assessments to simulate 'what-if' scenarios, such as 'What if Pump A fails?', to quantify the likelihood of downstream consequences like total production loss versus minimal downtime. This guides the design of preventive maintenance tasks and safety instrumented systems. Steps include identifying the initiating event, determining safety functions/barriers, constructing the tree showing success/failure branches, classifying outcomes, estimating branch probabilities, and quantifying final consequences.
- Omitting critical safety barriers: Failing to model all relevant engineered safeguards (e.g., emergency stops, interlocks), leading to inaccurate risk quantification and underestimated failure consequences.
- Neglecting human error factors: Ignoring the probability of operator response failures or maintenance mistakes during an event sequence, which often causes cascading breakdowns not predicted by the model.
- Static vs. dynamic mismatch: Applying static binary logic to complex systems requiring dynamic event tree methods (e.g., time-dependent failures, standby systems), resulting in flawed reliability data for critical assets like smart power grids.
How does ETA differ from Fault Tree Analysis (FTA)?
FTA is deductive (top-down: from system failure to causes), while ETA is inductive (bottom-up: from initiating event to consequences); they are often combined to link failure probabilities with consequences for full risk communication.
What logic governs ETA branching?
ETA typically uses binary logic where a node splits into two branches: the event occurred (or component failed) vs. the event did not occur (or component succeeded), though advanced tools support multi-state logic.
Can ETA handle success states?
Yes, modern reliability software (e.g., Isograph Reliability Workbench) explicitly handles success logic, allowing full minimal cut set analysis and distinguishing between primary success and secondary failure paths.
How is probability calculated in ETA?
Probabilities are assigned to each branch based on failure rates, repair rates, or dormant failure data; the final consequence probability is the product of all branch probabilities along that path.
Is ETA qualitative or quantitative?
Primarily qualitative for scenario identification, but it becomes quantitative when branch probabilities are estimated to calculate the likelihood of specific accident scenarios or reliability outcomes.