Hazard Cause Tree

Definition

Hazard Cause Tree

a diagram that is a kind of fault tree (i.e., a backwards-search decision tree) that shows the ways that that hazardous events can lead to a hazard

Objectives

The typical objectives of a hazard cause tree are to document:

• Sequences of potentially hazardous events (i.e., the success or failure of safeguards and other components) and resulting intermediate conditions that may cause a given hazard.

Benefits

The typical benefits of a hazard cause tree are to enable safety engineers to:

• Determine the various potentially hazardous events that might cause the hazard to occur.
• Determine the safeguards that might prevent the hazardous events or mitigate their effect.
• Estimate the probability of various hazardous events that may result in the hazard.

Contents

The typical contents of a hazard cause tree are:

• An fault tree with the following components:
  • The root labeled with the hazard being analyzed
  • Branches labeled with intermediate conditions
  • Leafs of potentially hazardous events (e.g., safeguard works, safeguard fails), optionally with their associated probability (if practical)

Stakeholders

The typical stakeholders of a hazard cause tree are:

• Producer:
  • Safety Team
• Evaluators:
  • Safety Evaluation Team
• Approvers:
  • Project Management Team
  • Customer Representative
• Maintainers:
  • Safety Team
• Users:
  • Safety Team, which uses hazard cause trees to perform hazard analyses.
  • Requirements Team, which uses hazard cause trees to identify and analyze safety-related requirements.
  • Architecture Team, which uses hazard cause trees to identify safeguards and the safety ramifications of architecture components.

Phases

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Completed
• Construction: Completed or Maintained
• Delivery: Completed or Maintained
• Usage: Completed or Maintained
• Retirement: Archived

Preconditions

A hazard cause 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.

Inputs

A hazard cause tree typically has the following inputs:

• Work Products:
  • System Requirements Specification
  • System Architecture Document
• Stakeholders:
  • Requirements Engineers
  • Architects
  • Safety Domain Experts

Guidelines

• Individual hazard cause trees can become very large and complex.
• Real applications can have a great number of hazards, resulting in the production of a great number of hazard cause trees.
• Carefully label the conditions and the hazardous events.
• 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 cause trees may imply more precision and accuracy than they justify.
• Traditional fault trees use a complicated notation that is not intuitively obvious (e.g., the different symbols for and and or. Where practical, use whiteboards and simple notations to initially derive the hazard cause trees.

Conventions

A hazard cause tree is typically constrained by the following conventions:

• Content and Format Standard
• Evaluation Checklist

Examples

The following diagram is a hazard cause tree for the hazard ‘passenger near open door on moving subway’ for a inter-terminal subway system for an airport.