Alarm Floods Don't Start with the DCS — They Start at the Shift Handover Table

What alarm management standards actually measure

ISA-18.2 and EEMUA 191 provide a rigorous framework for alarm system design: priority distribution, nuisance alarm thresholds, suppression policies, and response time benchmarks. They are designed primarily around the alarm system itself — what should alarm, at what threshold, and with what priority.

What they measure less well is the human context in which alarms are received. An alarm that a departing operator has been managing for the last three hours — knows the cause, knows it is not escalating, knows the expected resolution timeline — is a very different cognitive object than the same alarm received fresh at the start of a shift with no history. The alarm management standard sees both as identical. The incoming operator does not.

The context gap that drives suppression

An incoming operator at the start of a shift inherits the current alarm state with variable amounts of context. On a good handover, each standing alarm has been explained: what triggered it, what is being done about it, and whether the incoming team needs to take any action. On a typical handover, the outgoing operator says 'there are a few alarms running, nothing serious' and the incoming operator acknowledges.

In that second scenario, the incoming operator has two choices when an alarm activates in the first 30 minutes: investigate fully, which requires time and plant knowledge they are still reconstructing, or acknowledge and continue. For a standing alarm that has been running for hours, acknowledgment feels safe. The outgoing team knew about it and didn't escalate. The incoming team assumes continuity.

The assumption is often correct. The times it is not are the cases that appear in incident reports.

How bad handovers create alarm debt

When outgoing operators don't transfer alarm context, incoming operators inherit debt: a set of active or standing alarms they don't understand, each requiring a choice between investigation and acknowledgment. Under time pressure, in the first hour of a shift, acknowledgment wins repeatedly.

This creates a suppression pattern: the first hour of a shift shows a spike in alarm acknowledgments without corresponding investigations or process changes. Alarm management systems record this as normal operator activity. The underlying cause — a handover that failed to transfer context — is not visible in the alarm data.

The pattern compounds if the alarm suppression is not logged with a reason code. An alarm acknowledged three times in the first hour of three consecutive shifts, each time without investigation, is a signal that exists in the data but is practically invisible without someone specifically looking for it.

What post-incident investigations find

The Chemical Safety Board's investigation records and EEMUA's near-miss analysis both document a consistent pattern in alarm-related incidents: the alarm that mattered was present and acknowledged before the incident, often multiple times, by operators who lacked the context to recognise its significance.

The contributing factor is not operator error in the narrow sense — acknowledging an alarm is the correct action when you believe it is a known, managed condition. The contributing factor is a handover that didn't communicate that the condition was not, in fact, managed — that the alarm was standing not because it was under control, but because the outgoing team had been deferring investigation.

In retrospect the pattern is clear. In the moment, with an inherited alarm state and no documented history, the incoming operator had no way to distinguish 'managed standing alarm' from 'deferred problem that is about to escalate'.

What a better handover changes

The intervention is not complex: make alarm status a required structured field in every shift handover, not an optional verbal addendum. Each standing or active alarm at handover time should be documented with: the alarm identifier, the current cause or suspected cause, any actions taken during the shift, and the incoming team's required action (monitor, investigate by a specific time, escalate immediately).

When incoming operators receive this, the choice between investigation and acknowledgment is no longer made in an information vacuum. An alarm documented as 'standing for 4 hours, cause confirmed as instrument drift on TE-301, maintenance work order raised for 0800' can be safely acknowledged with context. An alarm documented as 'cause unknown, has been present since 1400, investigation was started but not completed' requires a different response — one that the incoming operator can now make correctly because they have the information they need.

Building alarm context into the handover workflow

For plants running a digital handover system, the most direct improvement is integrating the DCS alarm summary into the handover generation step. Rather than asking the outgoing operator to recall which alarms are standing, the handover tool surfaces the current alarm list automatically — pulling standing alarms, their duration, and any acknowledgment history from the DCS — and prompts the operator to add context for each.

This takes the cognitive burden off an operator at the end of a shift and places it on the system, which does not forget that Alarm HH-421 has been standing since 14:07 and was acknowledged four times without a reason code. The outgoing operator's job becomes verification and annotation, not recall. The incoming operator receives a complete, current alarm picture as part of the structured handover rather than as a verbal footnote.

The return on investment from reducing alarm-driven incidents compounds across every shift.