Hazard Effects Tree
- Hazard Effects Tree
- a diagram that is a kind of event tree
(i.e., a forward-search decision tree) that shows the ways that a
hazard can cause
accidents
As illustrated in the preceding figure, Hazard Effects Tree is part of the following inheritance hierarchy:
- Type: Concrete
- Superclass: Diagram
- Subclasses:
The typical responsibilities of a Hazard Effects Tree are to:
- Document the possible sequences of potentially hazardous events
(i.e., the success or failure of safeguards and other components) that may follow an initial hazard.
- Document the possible resulting effects
(e.g., accidents, near misses, protection of valuable assets) that may result
from each sequence of such potentially hazardous events.
- Determine the various accident scenarios that may result from a single hazard.
- Determine the safeguards, the failure of which most contribute to the probability of an accident.
- Estimate the probability of various success/failure event sequences that may or may not lead to an accident.
The typical contents of a Hazard Effects Tree are:
- A series of boxes labeled with safeguards and other
devices that can either succeed or fail.
- An event tree with the following components:
- The root labeled with an initial hazard being
analyzed
- Branches labeled with alternative potentially hazardous
events (e.g., safeguard works, safeguard fails), the
associated probability (if practical), and lined up under
the associated boxes
- Leafs labeled with resulting effects (e.g., accidents,
near accidents, protection of valuable assets)
The typical stakeholders of a Hazard Effects Tree are:
- Producer:
- Evaluators:
- Approvers:
- Maintainers:
- Users:
-
Safety
Team, which uses hazard effects trees to perform
hazard analyses.
-
Requirements Team, which uses hazard effects trees to
identify and analyze safety-related requirements.
-
Architecture Team, which uses hazard effects trees to
identify safeguards and the safety ramifications of
architecture components.
A Hazard Effects Tree typically can be started if the following preconditions hold:
- The
initiation phase is started.
- The
safety
team is adequately staffed and trained in
safety risk analysis.
- Most of the architecture and design (including
safeguards) of the system must be complete.
- The safety engineers performing the hazard analysis must
either fully understand the architecture and design or else
have significant access to subject matter experts who
do.
A Hazard Effects Tree typically has the following inputs:
- Work Products:
- Stakeholders:
Guidelines
- Simplify large hazard effects trees by pruning impossible
branches (i.e., those whose associated functional or
operational relationships are illogical or meaningless).
- Label the safeguards (i.e., safety protection systems or
devices) above the conditions in order to simplify the
identification of the branch event labels.
- Line up the potentially hazardous events left to right in
such a manner as to minimize the complexity of the resulting
event tree (i.e., so that all potential sub-branches can be
subsumed into a single branch with the single common result).
Considerable rearrangement may be required to identify the
optimal ordering.
- Hazard effects trees typically ignore the potential
failure of computer hardware and software, which could happen
anywhere along the tree and greatly increase the tree’s
complexity.
- It is often impractical to label branch segments with
their probabilities. There are typically huge unknowns
associated with these numbers, especially with regard to the
probability of software failures. Also, assumptions of
independence that allows one to multiply probabilities may
not be justified due to common cause failures. Thus,
quantitative hazard effect trees may imply more precision and
accuracy than they justify.
A Hazard Effects Tree is typically constrained by the following conventions:
The hazard effects tree for the initiating event “passenger near open door of moving subway” for a
inter-terminal subway system for an airport:
