Marvin Rausand - Risk Assessment

Figure 2.3Two different choices of hazardous events, (a) early in the event sequence and (b) late in the event sequence.

Hazards are primary causes of initiating events, but specific events or conditions often need to be in place in addition for an initiating event to occur. The same applies for events later in the accident scenario. These events and conditions are called enabling events and conditions.

An event or a condition that on its own or in combination with other events or conditions can trigger an initiating event or enable an accident scenario to develop further toward an accident.

Enabling events and conditions are events and conditions that contribute to instigate the initiating event and to drive the accident scenario forward toward harm of an asset. Sometimes, it may be difficult to distinguish clearly between events that are in the accident scenario sequence and enabling events, but as a general rule, all events that are not on the “main path” toward the accident scenario end event are enabling events. It may seem unnecessary to distinguish between these two, but for the purpose of managing risk it may be quite important. If an initiating event or another event occurs that is defined as being part of the accident scenario, this means that the situation has moved one step closer to becoming an accident. Enabling events (and conditions) only change the probability that an event in the sequence occurs. In an earlier example, “Gas leak from flange A” was used as an initiating event. An enabling event could be “impact on flange” and an enabling condition could be “corrosion” because both increase the probability of failure of the flange.

Table 2.4lists some hazards, enabling events and conditions, and initiating events to help clarify the concepts and illustrate the differences between them.

Table 2.4Hazards, enabling events and conditions, and initiating events.

Reason (1997) distinguishes between active failures and latent conditions . Active failures are events that trigger unwanted events. Examples of active failures are errors and violations by field operators, pilots, and control room operators. 3These are the people in the operation – what Reason calls the sharp end of the system. Latent conditions do not trigger an accident immediately, but they lie dormant in the system and may contribute to a future accident. Examples of latent conditions are poor design, maintenance failures, poor and impossible procedures, and so on. Latent conditions can increase the probability of active failures.

There are clear similarities in the way that Reason uses these terms and our way of using enabling events and conditions.

Failures and malfunctions of technical items may be relevant as both hazards and enabling events. A failure is defined as follows:

The termination of the ability of an item to perform as required.

A failure is always linked to an item function and occurs when the item is no longer able to perform the function according to the specified performance criteria. Failure is an event that takes place at a certain time . Item failures can be recorded, and we can estimate the frequency of failures in a certain population of similar items. This frequency is called the failure rate of the item.

The occurrence of some failures can be observed immediately when they occur, and these failures are called evident failures. For other failures, it is not possible to observe the failure without testing the item. These failures are called hidden failures . Hidden failures are a particular problem for many safety systems, such as fire or gas detection systems, and airbag systems in cars.

After a failure, the item enters a failed state or a fault and remains in this state for a shorter or longer time. Many failures require a repair action to be brought back to a functioning state. Some items – especially software items – may spend a negligible time in failed state.

A fault of a technical item is defined as follows:

A state of an item, where the item is not able to perform as required.

Many faults are caused by a preceding failure, but there is also another important category of faults – systematic faults . A systematic fault is caused by a human error or a misjudgment made in an earlier stage of the item's life cycle, such as specification, design, manufacture, installation, or maintenance. A systematic fault remains in – or is related to – an item until the fault is detected as part of an inspection or test, or when the systematic fault generates an item failure. Systematic faults are important causes of safety system failures and include faults, such as, software bugs, calibration errors of detectors, erroneously installed detectors, too low capacity of fire‐fighting systems, and so forth.

If we compare a human being and a technical item, the terms “death” and “failure” are similar terms. In most cases, we can record the time of death of a person, and we can calculate the frequency of deaths in a certain population. When a person dies, she enters the state of being dead, and remains in this state. As for technical items, it is not possible to calculate any frequency of being dead. The main difference between the terms is that technical components often can be repaired and continue to function, whereas a dead person cannot.

Consider a pump that is installed to supply water to a process. To function as required, the pump must supply water between 60 and 65 l/min. If the output from the pump deviates from this interval, the required function is terminated and a failure occurs. The failure will often occur due to a gradual degradation, as shown in Figure 2.4.

Figure 2.4Failure and fault of a degrading item.