What is a hazard?


The definitional problem

Across a range of safety standards there exist multiple, overlapping and inconsistent definitions of what constitutes a ‘hazard’. Definitional ‘parts’, extracted from various standards include:

  1. “event”,
  2. “system state”,
  3. “or set of conditions”,
  4. “physical situation”,
  5. “must occur in combination with…”,
  6. “source of harm”,
  7. “real or potential source”,
  8. “condition”,
  9. “…together with other conditions in the environment”
  10. “may (alt. inevitably) lead to an accident”, or
  11. “cause injury, illness or death”

Interestingly, all these definitions share a common trait they are ‘phenotypical’ in nature, that is concerned with defining observable characteristics of a hazard. As I  noted in a previous post it may not actually be useful to try to come up with a singular pheontype definition of what a hazard is. A far more useful question is what do we use the concept of hazard for? In safety engineering we normally start with an overall safety goal for a system, an example would be a quantitative maximum allowable accident rate. A safety goal is just that a goal of the system, as a goal it is inherently stated in high level terms such that we can’t go off and straight away build a solution system that meets the goal.

The response of systems engineers to such a challenge is to decompose this top level goal into a series of lower level objectives which can be shown to satisfiy the top level goal. These objectives can be further decomposed (along with further justification) until we arrive at a set of requirements that can be allocated to the actual hardware, software, procedural and personnel components making up the system solution. The resulting decomposition is not unique as the systems analyst can always choose different intermediate requirements.

From the systems engineering perspective a hazard is therefore simply an intermediate requirement that links an safety goal (accident rate) to the set of leaf or derived requirements (e.g. design constraints) that will, if implemented, satisfice the safety goal of the system. Note that a justification that these requirements will satisfy the top level goal is an essential element of the argument. This, the purpose that a hazard serves can be considered it’s genotype. Logically to control an accident we can look to eliminate or control the potential causes or if the accident eventuates reduce the severity of it’s consequences.

Importantly, by the time we get to establishing safety requirements we have already made a value judgement that it’s worthwhile to engage in activity with some risk attached to it, this may be considered to be the fundamental source of risk. As an example, if we choose to fly at low level there exists an inherent (and inescapable) risk of wire strike. Likewise if we choose to generate power using nuclear reactors there exists an inherent risk of releasing radiation into the environment.

The relation between hazard genotype and phenotype can be expressed more concisely as:

  • genotype (cause(s), consequence(s)) + problem domain (source) + analysis introduced variation  → phenotype (the actual hazard description)

Perhaps the earliest example of hazard as intermediate requirement is the source/mechanism/outcome model first proposed by Clements. In Clement’s model a hazard description contains three elements that express a threat; a source — an activity and/or a condition that serves as the root, a mechanism — a means by which the source can bring about the harm and  an outcome — the harm itself that might be suffered (Clements 1984). This model of causation provides us with a link between the accident (outcome) and the causation (the source and mechanism). Justification for this intermediate requirement is usually provided in the form of references to the safety analysis used to identify hazards, the more formal the analysis (Fault Tree, THERP or FMECA, versus hazard workshop) the greater the justification.

By describing the hazard in these terms we also satisfy the systems engineering principles that requirements should have an associated rationale and should state needs, rather than solutions. The objective being to describe the possible causation of an accident sufficiently completely to allow the identification of an effective set of mitigating design requirements. The concept of a hazard phenotype and genotype also explains why the definition of hazards is such a moveable feast across domains of application.

Further Reading

Clements, P. (1984), System Safety Scrapbook – Sheet 84-3, Sverdrup Technology Inc.