Alarm Rationalization Worksheet

Most alarm systems I open up were never designed. They grew. Somebody added an alarm every time something went wrong and nobody ever took one away. Now the operator gets 400 alarms an hour, 30 of them in the first 10 seconds of any trip, and the one that actually mattered scrolled off the screen before anybody read it. That is an alarm flood, and it is how a good operator misses the alarm that would have saved the batch, the pump, or the shift. This worksheet is the tool I use to fix that, one tag at a time. It pairs with the Strule blog post on alarm rationalization for food and beverage, but the method is cross-sector — it works the same on a digester skid, a boiler house, a packaging line, or a water plant.

Why floods happen, and what "good" looks like The root cause is almost always the same: alarms were configured as notifications instead of as calls to action. If a point of information does not require the operator to do something, it is not an alarm — it is a log entry, a trend, or a status color on the screen. The goal of rationalization is that every alarm is actionable, prioritized, and gives the operator enough time to act before the consequence lands. That is it. Three tests. If an alarm fails any one of them, you fix it or you delete it. Two industry references frame this, and it is worth defining both because people throw the numbers around without them: EEMUA-191 — the Engineering Equipment and Materials Users' Association Publication 191, "Alarm Systems: A Guide to Design, Management and Procurement." It is where the widely quoted performance targets come from: a target of roughly one alarm every 10 minutes per operator in steady state, and no more than about 10 alarms in the 10 minutes after a major upset. Treat those as benchmarks to measure against, not a spec to hit on paper.