The inquiry into the accident at Three Mile Island in 1979 recorded that more than a hundred alarms sounded in the control room in its first minutes and that the operators had no means of telling the important ones from the rest (Kemeny, 1979). Fifteen years later the investigation of the explosion at the Texaco refinery in Milford Haven reported that in the last eleven minutes before the explosion the two operators were presented with 275 alarms (HSE, 1997). In both cases the alarm system worked as designed. Each alarm was genuine. Together they were useless.

The response has been substantial. Research commissioned by the British safety regulator surveyed alarm practice in the chemical and power industries (Bransby and Jenkinson, 1998) and led to the EEMUA 191 guide, now in its third edition (EEMUA, 2013). The ISA-18.2 standard followed in the United States (ISA, 2016) and was taken up internationally as IEC 62682 (IEC, 2014). Books, vendor tools and consultancies have grown around them (Hollifield and Habibi, 2011; Rothenberg, 2009).

Even so, a survey of the research field as late as 2016 listed alarm flooding among its open problems (Wang et al., 2016), and a review the following year reached a similar view (Goel et al., 2017). This perspective asks why. Its argument is that the guidance, sound as it is, addresses flooding indirectly, and that the features of plants and organisations that generate floods are left largely untouched by it.

The documents share a core. An alarm is an indication to the operator of an abnormal condition that requires a timely response. If no response is required, the event is not an alarm and belongs in a log. From that definition follows rationalisation: each configured alarm is examined, justified by a consequence and an operator action, given a priority and a setpoint, and recorded in a master alarm database. ISA-18.2 places this within a lifecycle that starts with an alarm philosophy and runs through identification, rationalisation, design, implementation, operation, maintenance, monitoring, management of change and audit (ISA, 2016). Figure 1 sets the main documents beside the accidents that prompted them.

The guidance also sets performance targets. EEMUA 191 suggests that a long-term average of fewer than one alarm in ten minutes is very likely to be acceptable to an operator, and that after a major plant upset fewer than ten alarms should appear in the first ten minutes (EEMUA, 2013). ISA-18.2 treats ten or more alarms in ten minutes at one operator position as the usual threshold of a flood. These numbers are reference points for assessment. They are not derived from a model of the operator, and the guides say as much.

Five reasons are proposed here. They are drawn from the logic of the guidance and from the human factors and reliability literature, and are summarised in Table 1.

The most direct objection is that the guidance works where it is applied and that persisting floods only show incomplete adoption. There is truth in this. The standards do provide for advanced alarming, the practitioner texts describe how to carry it out, and a document cannot be blamed for work not done. But the objection concedes the point at issue. If the part of the guidance that deals with floods is the part most often left undone, the reasons for that, cost, upkeep and ownership, are the real explanation and deserve to be addressed as such.

A second objection is that floods are unavoidable in a tightly coupled plant and that the proper response lies elsewhere: in automatic protection that does not rely on the operator, and in training. Automatic protection is indeed the right defence for the fastest events. Yet the operator remains responsible for diagnosis and recovery, and the theory of situation awareness holds that perception of the relevant elements comes before comprehension and projection (Endsley, 1995). An interface that defeats perception at the critical moment undermines everything built on it. The human factors literature on alarm design has said so consistently (Stanton, 1994).

A third objection is that better displays and analytics will make the problem disappear. They may help, but they share the dependence on engineering effort and maintenance described above, and they add a layer whose own failure modes have to be understood.

If the argument is right, three changes of emphasis follow. First, the flood should be a design case. For each operator position, a short list of credible upsets, such as loss of a utility, trip of a major machine or failure of a control system component, should be defined, and the alarm sequence each produces should be predicted, counted and reviewed, in the way that relief loads are reviewed for the same scenarios. Dynamic simulators used for operator training make this practicable.

Second, measurement should lead with the peaks. A site report that opens with the number of floods, their duration and their peak rate, and gives the average afterwards, directs effort differently from one that does the reverse. Third, the asymmetry of cost should be countered deliberately, by giving the alarm system an accountable owner and something like a budget, so that an addition during an upset scenario has to be traded against what is already there. None of this contradicts the existing standards. It asks that their least practised parts be treated as the centre of the subject.

Alarm flooding has outlasted decades of guidance because the guidance was built around the individual alarm and the ordinary day, while the flood belongs to the plant as a whole and to its worst minutes. The remedies exist but are costly to engineer and to maintain, the common metrics do not reward them, and no one clearly owns the result. Treating the upset as a design case, reporting peaks before averages and fixing accountability would align practice with what the accident reports have been saying since 1979.

To be declared by the author(s) before publication.

To be declared by the author(s) before publication.