Instrumentation & Control

Alarm management — why an operator with 400 alarms has none

What an alarm is actually for, why a flood during an upset removes the help exactly when it is needed, what a standing alarm costs, and why adding an alarm is a design decision rather than a configuration change.

IntermediateOil & GasPetrochemicalPharmaceutical

Standards referencedEEMUA 191IEC 62682IEC 61511

An alarm is a message to a person: something needs your attention, and here is roughly how urgently. Everything that goes wrong with alarm systems follows from forgetting that there is a person at the other end with finite attention.

What makes something an alarm

The test is narrow, and most systems fail it.

The flood

The failure that matters is not a bad alarm. It is hundreds of them arriving at once.

The widely used benchmarks come from EEMUA 191 and IEC 62682: roughly one alarm every ten minutes in steady operation is manageable, and more than ten in ten minutes is generally considered unmanageable. Many real plants sit far above the second figure as their normal state.

Standing alarms and the habit they teach

A standing alarm has been active for days, weeks or years. Everyone knows about it. Everyone ignores it.

The causes are usually mundane: an instrument out of service and never repaired, a limit set for a design case the plant no longer runs, a spare pump alarming because it is spare.

Priority means something specific

Priority exists for one moment: three alarms arrive together and the operator must choose what to look at first.

It should therefore follow consequence severity and time available — how bad the outcome, and how soon. Both are process judgements, and neither can be read off the instrument.

A plant control room with two operators seated at a curved console of flat screens showing process graphics, and a large wall-mounted overview display of a schematic behind them.
Two people, and however many alarms the system chooses to send them. Attention is the fixed quantity in this room, and every alarm added takes a share of it.

Suppression, shelving and inhibits

There are legitimate reasons to silence an alarm, and each has a proper mechanism.

Designed suppression is built in advance: alarms from a shut-down unit are suppressed while it is shut down, because a stopped pump alarming on low flow tells nobody anything. This is engineered, documented and automatic.

Shelving lets an operator set an alarm aside temporarily, with the system bringing it back after a defined period. The return is the point.

Inhibiting removes it, and needs the discipline of any other override.

Rationalisation

Rationalisation reviews every configured alarm and asks the three questions above. It is unglamorous and it is the only thing that genuinely works.

Typical outcomes: a large proportion deleted or downgraded to events because they have no operator action; limits moved to where they give usable warning rather than announcing an accomplished fact; priorities reassigned on consequence; standing alarms resolved at source rather than tolerated.

A wall-mounted alarm annunciator panel in a plant control room, a grid of backlit rectangular windows with roughly a third illuminated in amber and red and the rest dark, accept and reset pushbuttons below the grid.
A third of this panel is lit, and everyone who works here knows which ones are always lit. That is how a standing alarm stops being information and becomes part of the wallpaper.

Where this connects

Alarms are one layer of protection, and a weak one, because they depend on a person noticing and acting correctly under pressure. The layer that acts without a person is the safety instrumented system, and an alarm is never a substitute for one.

An alarm system in poor condition also shows up in incident investigation, usually phrased as operator error — when the real finding is that the operator was given three hundred alarms and expected to find the one that mattered.

What to take away

  • An alarm needs a defined action and the time to take it. Without both, it is information in the wrong place.
  • A flood removes help when it is most needed by hiding the cause among its own consequences.
  • Standing alarms teach operators to ignore the list, and hide new alarms in the clutter.
  • Priority answers “what first”, from consequence and time available. If everything is high, priority has been abolished.
  • Suppression is designed, shelving returns, inhibits need a register.
  • Rationalisation is the only thing that works, and most of it is deletion.
  • Adding an alarm spends operator attention. Lists become unusable one reasonable addition at a time.

Check your understanding

7 questions. Nothing is recorded — this is just for you.

1What is the defining test of whether something should be an alarm?
2During a trip, several hundred alarms arrive in a few minutes. What has been lost?
3What is a standing alarm?
4Why is alarm priority assigned from consequence and response time rather than from how the loop is configured?
5An operator inhibits a nuisance alarm during a shift. What must follow?
6Why is adding one more alarm rarely free?
7How does alarm rationalisation differ from simply reducing alarm limits?

#instrumentation#alarms#dcs#operator#human-factors#eemua