Alarm rationalization is a subtraction problem

If you want to understand how an alarm system is really doing, watch the alarm list during a real upset rather than watching the operator. When alarms start arriving faster than anyone can read them, the system has stopped helping and turned into noise, and every alarm after the first few is just competing for attention the operator doesn’t have to spare.

That’s the problem this work exists to fix, and it’s worth being honest about the kind of problem it is. It’s a subtraction problem. The hard part isn’t deciding which alarms to add. It’s getting people to agree on which ones to take away.

Every alarm is a promise to the operator

This isn’t just a nice way of putting it, it’s close to the official definition. The standards for alarm systems define an alarm as a signal that tells the operator about a condition they need to respond to, and respond to in time (ANSI/ISA-18.2 and IEC 62682, with EEMUA Publication 191 saying much the same in plainer words). So every alarm is really a promise: if this goes off, there’s a specific thing for you to do, and there’s time to do it. When either half of that promise isn’t true, the alarm shouldn’t be sitting there at the priority it has.

That gives you a simple test to run on every alarm. Is there a clear action the operator is meant to take, or is the honest answer just “keep an eye on it”, in which case it isn’t really an alarm? Is there actually time to do something before the problem arrives, because if not it needs to be handled automatically rather than by a person? And is it telling the operator something new, or is it one of three alarms that always come in together? Most plants that are drowning in alarms fail the first and third of those far more often than the second.

Priority is a budget

Priority only means something if the high-priority alarms are genuinely rare, which is why the standards recommend deliberately keeping them to a small share of the total (EEMUA 191; ANSI/ISA-18.2). The moment a third of the list is marked “high”, the label has stopped meaning anything and the operator is back to sorting them out by gut feel. It helps to think of priority as a fixed budget, because a control room can only carry so many high-priority alarms before the whole idea of priority breaks down.

Tie each alarm to a consequence

The instrument can tell the operator that a level is high. What they actually need to know is why that matters here, whether it’s heading towards an overfill, the loss of a safeguard, or a step on the way to a trip. Rationalization that stops at the instrument just produces tidy paperwork and busy screens. Rationalization that ties each alarm back to what could go wrong, and to what the operator should do about it, produces a system that’s quieter and that people trust.

Fewer, clearer, more credible alarms isn’t a slogan. It’s the only state in which an operator can really use the system on their worst day.

Watch the upset, not the average

The average number of alarms over ten minutes is a useful figure, and the standards set target rates and treat a sustained high rate as a flood (EEMUA 191; ANSI/ISA-18.2). But the number I care about most is what happens during an upset. A system that’s quiet on a normal day and then buries the operator the moment something goes wrong has been tuned for the day you don’t need it and left to fail on the day you do.

Taking an alarm away feels uncomfortable, because it feels like giving up a bit of safety. Done properly it’s the opposite. What you’re really doing is making sure the alarms that are left are the ones the operator can still trust on their worst day.

References

ANSI/ISA-18.2 and IEC 62682, Management of Alarm Systems for the Process Industries, for the alarm lifecycle, the definition of an alarm, rationalisation, priority and performance metrics.
EEMUA Publication 191 (4th edition, 2024), Alarm Systems: A Guide to Design, Management and Procurement.