Alarm Rationalization: Making the Real Alarms Visible

Open the alarm console on a typical front end. Several hundred active alarms, some of them years old, a red banner that never clears, and an operator who acknowledges by the page because that is the only way to keep up. Nobody ignores that console out of laziness. It earned its reputation by crying wolf hundreds of times a day, so the alarm that signals a failing chiller arrives looking like the noise it is buried in. When everything alarms, nothing does.

Where the noise comes from

Almost none of the load was designed. It accumulated. Controllers ship with alarming enabled at factory limits nobody revisits after startup, so points alarm at thresholds that have nothing to do with how the equipment actually runs. A sensor fails, reads zero or full scale, and alarms continuously until the alarm becomes furniture. A value sitting near its threshold crosses it dozens of times an hour because no deadband or time delay was ever configured. And on most systems every alarm arrives at the same priority, so a failed supply fan and a space temperature one degree out of range present as the same kind of event.

• Factory-default limits, never tuned to the equipment they watch.
• Dead or drifting sensors alarming continuously for months.
• Chatter from missing deadbands and time delays.
• One priority for everything, so severity carries no information.
• Alarms bound to equipment that was removed two renovations ago.

The triage pass

Start with data, not opinions. Export the alarm history for the last sixty or ninety days and sort by source and frequency. The distribution is always lopsided: a small number of points generates most of the volume, and that short list is where the work goes first.

• Kill the duplicates and the dead. One condition should raise one alarm. Delete alarms on points whose equipment no longer exists, and fix or formally decommission failed sensors instead of letting them alarm forever.
• Add deadbands and delays. Alarm above the limit, return to normal below the limit minus a deadband, and require the condition to persist before it reports. Suppress alarms during equipment start and stop, where transients are normal.
• Assign priorities by consequence. Three or four levels are enough, each defined by the response it demands: act now, act this shift, act this week, or log only. If two alarms demand the same response, they share a priority.
• Route by audience. Life safety and critical equipment to the person on call, maintenance items to the work queue, informational events to the log and nowhere else. The console is for alarms that need an operator.

What day one should look like

After the pass, the console should be quiet enough that an arriving alarm is an event. A handful of standing alarms at most, each one known, owned, and tied to work in progress. Every alarm on the screen passes the same test: an operator can say what it means, what to do about it, and how urgent it is. Anything that fails the test is either noise to retire or a training gap to close.

The pass only holds if the discipline does. Every new alarm gets its deadband, delay, priority, and routing decided at creation, not defaulted. A monthly look at the ten noisiest points catches regressions while they are cheap. And nuisance alarms get repaired or retired, never acknowledged into the background, because the console's entire value is that when it speaks, someone believes it.