ENGINEERING NOTE / ALARMS

Every alarm should ask for an action.

An alarm flood buries the cause of an upset. Priorities, delays and suppression each fix a different part of the problem, and none changes the process.

Low Kah Yi · 21 October 2026 · Independent synthetic example

Count what the operator has to read.#

In the Lab's alarm exercise, one cooling water pump trips at 60 seconds. Nothing else fails. Within the next minute the operator's list holds 7 alarms, and over ten minutes the as-found alarm system presents 41. Alarm management guidance treats more than about 10 in ten minutes for one operator as an alarm flood. Only one of those alarms names the cause.

The rest are its consequences: cooling water flow low, return temperature high, cooler outlet high, then levels and temperatures further along the process. Each one is true. None of them asks the operator to do anything that the pump alarm has not already asked for.

The first alarm sinks.#

The list shows the newest alarm first, so every consequence pushes the cause further down. One minute into the upset, the pump alarm is 7 of 7. Some alarms make it worse by chattering: a level that hovers around its limit raises and clears the same alarm several times in a few seconds, and each return looks like news.

Three fixes for three different problems.#

The exercise lets you switch on three common alarm design changes, one at a time: on-delays and a deadband, priorities, and suppression of consequential alarms. Each removes a different kind of alarm that asks for no action.

On-delays and deadbands stop the chattering and bring the count down to 12, but the cause is still at the bottom of the list. Priorities sort the pump alarm to the top without removing anything. Suppression hides alarms while the alarm that explains them is active: 13 presentations disappear, and the pump alarm stands alone. Pressure alarms are deliberately left visible, because rising pressure needs a response of its own.

Only the three together bring the upset below the flood benchmark. Each fixes the problem it was designed for, and no more.

None of them changes the process.#

Every row in the table ends the same way: the safety system shuts the unit down at 262 seconds. Alarm design changes what the operator sees, not what the plant does. Someone still has to start the standby pump, and in this model that has to happen within about three minutes of the pump trip.

What the better design buys is time. With the cause at the top of a short list, those three minutes go into acting instead of reading.

Try it: play the shift once with the as-found alarm system and once with the improved one. Then open the design view and switch the changes on one by one.

Take the questions into an alarm review.#

For each alarm, ask what action it asks for, how long the operator has to take it, and what happens if nobody does. An alarm with no answer to the first question is information, and belongs somewhere other than the alarm list. Then ask which alarms are consequences of another, and whether suppressing them is written down with its reason. Ask which ones chatter, and what delay or deadband the measurement noise justifies.

Alarm management standards such as ISA-18.2 and EEMUA 191 organize these questions into a lifecycle of philosophy, rationalization, monitoring and review. This note describes general practice. The exercise uses one fault, thirteen invented tags and an operator who never tires; it leaves out shelving, multiple faults and the human factors of a real shift. Its assumptions and checks are on the model code page and in the verification notebook.