Alarm rationalization is a subtraction problem
Operators do not need more information in an upset. They need less, sequenced better. Rationalization is mostly about what you are willing to remove.
Walk into a control room during a real upset and watch the alarm list, not the operator. If the screen is filling faster than a person can read, the alarm system has stopped being a tool and become noise. Every alarm after the first few is competing for attention that the operator does not have to give.
That is the problem alarm rationalization exists to solve, and it is worth being honest about what it is: a subtraction problem. The hard part is not deciding which alarms to add. It is agreeing on which ones to take away.
Every alarm is a promise
An alarm is a promise to the operator: if this activates, there is a specific thing for you to do, and there is time to do it. If either half of that promise is false, the alarm should not exist at its current priority.
That gives a simple test for every alarm on the list:
- Is there a defined operator response? If the answer is “monitor it,” it is not an alarm.
- Is there enough time to act before the consequence? If not, it needs an automated function, not a human one.
- Is it unique? If three alarms always come together, two of them are telling the operator something they already know.
Most over-alarmed plants fail the first and third tests far more than the second.
Priority is a budget, not a label
Priority only means something if high-priority alarms are genuinely rare. The moment a third of the list is “high,” the word has lost its meaning and the operator is back to triaging by instinct. I treat priority as a fixed budget: there are only so many high-priority alarms a console can carry before the category stops working.
Rationalize against the consequence, not the instrument
The instrument tells you a level is high. The operator needs to know why that matters here — overfill, loss of a safeguard, a step toward a trip. Rationalization that stays at the instrument produces tidy registers and busy screens. Rationalization that ties each alarm to a consequence and a response produces a quieter, more credible system.
Fewer, clearer, more credible alarms is not a slogan. It is the only state in which an operator can actually use the system on their worst day.
The measure that matters
Average alarm rate per ten minutes is a useful number, but the one I care about most is the alarm rate during upsets. A system that is calm in steady state and floods the moment something goes wrong has optimised for the day you do not need it and failed the day you do.
Subtraction is uncomfortable because removing an alarm feels like accepting risk. Done properly, it is the opposite: it is making sure the alarms that remain are the ones an operator will still trust when it counts.