POST 5 · ISA 18.2 SERIES

Keeping It Alive – Advanced Alarming, Nuisance Alarms, and Change Control

An Automated NSW Smart Solutions Guide

Publish Date: 08/27/26

A rationalized, well-designed system still degrades if nobody’s watching it. Here’s how to keep it working.

Every alarm system starts clean. Rationalization is done, priorities are balanced, setpoints are tuned. Then equipment ages, sensors drift, and someone changes a setpoint during a call at 2 a.m. and never documents it. A year later, the same system that started at an 80/15/5 priority split looks like the mess it was built to replace. This post covers the tools for keeping a system healthy long after commissioning: advanced alarming for problems basic design can’t solve, the metrics for catching nuisance alarms early, and the change control process that keeps the system from drifting in the first place.

Advanced Alarming: When Basic Design Isn’t Enough

Deadbands and delays solve noisy signals. They don’t solve alarms that are only relevant in certain operating conditions. A chiller alarm that makes sense when the system is running is meaningless during a scheduled shutdown. Basic design has no concept of context. Advanced alarming techniques add that context back in.

State-based alarming is especially relevant in building automation, where a single air handler might legitimately operate under half a dozen modes in a normal week. The rule of thumb: if an alarm is technically correct but operationally wrong a meaningful fraction of the time, that’s a sign it needs state-based logic, not a wider deadband.

Nuisance Alarms: Measuring the Problem

Nuisance alarms are the clearest sign a system is drifting from its rationalized state. ISA-18.2 gives specific, measurable definitions instead of leaving it to judgment, which means you can actually track this over time instead of relying on operator complaints.

 

Fixing Each Type

• Chattering: widen the deadband, add or extend a delay, or re-rationalize whether the setpoint is placed correctly relative to normal process variation.
• Fleeting: check whether the condition is genuinely momentary and safe to ignore, in which case it may not qualify as an alarm at all, or whether it’s an early warning of a real problem being caught too late.
• Stale: determine why it’s not being addressed. Sometimes it’s an operator workflow gap, sometimes it’s an alarm that no longer applies and was never removed from service.

None of these fixes should happen informally. Which brings up the last piece: how changes get made without quietly undoing all the rationalization work.

Management of Change (MOC)

MOC is the least glamorous part of the standard and the one most consistently skipped in building automation. Setpoints get adjusted during a service call, a priority gets bumped up because someone missed an alarm once, and none of it gets recorded. Six months later nobody can explain why the system looks the way it does, and the next rationalization effort starts from scratch instead of building on documented history.

This doesn’t need to be heavyweight. Even a simple change request form tied to the master alarm database closes most of the gap. The point isn’t bureaucracy; it’s making sure the system a year from now still reflects a decision someone made on purpose, not an accumulation of quick fixes.

Audit and Benchmarking

Periodic audits close the loop. On a regular schedule, typically annually, compare the live system’s performance against the targets set in the alarm philosophy: priority distribution, alarm rate, standing alarm count, chattering and fleeting counts. Where the system has drifted, that’s the trigger for the next rationalization pass, not a full redo, just a targeted review of the alarms that have moved furthest from their original intent.

That’s the full lifecycle: a philosophy that sets the rules, rationalization that applies them, design and HMI that make them usable, and advanced alarming, monitoring, and MOC that keep the system from decaying. None of these stages works in isolation. A great HMI on top of an unrationalized alarm list is still noise. A strict MOC process protecting a philosophy nobody ever wrote is protecting nothing. The standard exists because these pieces were always meant to work together, and most systems in the field today are proof of what happens when they don’t.

Is Your System Still On Track?

If you are concerned your system’s tight control requirements have degraded or if you are working to bring an existing system into spec, contact us. We will help you get there.

www.automatednsw.com | support@automatednsw.com