Shelving vs. Suppression: Quieting SCADA Alarms Without Hiding Real Risk

The worst alarm-system failure I have seen was not a flood. It was a single high-temperature alarm on a dryer that nobody saw for three shifts because someone had "disabled" it during a bearing swap and there was no display that listed disabled alarms anywhere in the control room. The banner was clean. The event was ugly.

That is the real danger with shelving and suppression. Everyone talks about them as tools for killing nuisance alarms, and they are — but the failure mode is not too many alarms, it's an important alarm quietly removed with no owner, no reason, no expiry, and no place an operator can look to find out it's gone.

These are four different things, and ISA-18.2 says so

Most sites use "shelve," "suppress," "disable," and "bypass" interchangeably in conversation, then wire them up inconsistently in the HMI. ANSI/ISA-18.2-2016 (and IEC 62682, which mirrors it) actually defines these as distinct alarm states with different transitions and different authorization. Pin the words down before you configure anything.

Shelved — temporary, operator-initiated, and it should auto-return. This is the tool for a chattering level switch or a device being worked on this shift. Per the standard's intent, a shelf carries a time limit and re-annunciates when it expires. If your system lets an operator shelve something forever with two clicks, you've built the dryer story.

Suppressed by design — hidden automatically because the process state makes the alarm meaningless. Low-flow on a pump that is commanded stopped. This lives in the logic, not in an operator's hands. It's engineered, tested, and documented, or it isn't suppression-by-design — it's just a bug you decided to like.

Out-of-service — deliberately removed until someone puts it back, with no automatic return. This one is dangerous precisely because it has no expiry, so it needs the tightest authorization of the alarm states. Use it for a transmitter that's been pulled, not for "this thing is annoying today."

Interlock bypass — not an alarm state at all. A bypass changes protection or permissive logic. It belongs to the safety/MOC process, needs field confirmation, and must be indicated separately from anything on the alarm page. If your bypass switch lives inside the alarm shelving control, move it.

The hidden-alarm display is not optional

Hidden is not the same as invisible. There needs to be a standing view — not buried in an engineering menu — that lists everything currently shelved, suppressed, out-of-service, or bypassed. This is the single cheapest thing you can build to avoid the failure above.

For each entry, show:

Tag / equipment name and the alarm description
Which hidden state it's in
Reason or comment, and the user who applied it
Start time and expiry/review time
Current value and quality
Whether the underlying condition is active right now — a shelved alarm that is currently true is the one you care about

The trap is a control room that shows only active alarms plus event history. It looks tidy while a dozen alarm functions are offline. If a supervisor can't answer "what alarms are hidden and why" from one screen, that screen doesn't exist yet.

Put a clock on operator shelving

Operator shelves should expire. Full stop. I'd wire the presets to something like 30 min, 2 h, 8 h, and end-of-shift, require a comment for anything past 2 h, and forbid indefinite shelving outright unless it's escalated. For a high-consequence alarm — anything ISA-18.2 would classify high or urgent priority — cut the max short or require supervisor sign-off. For a low-priority diagnostic, a long shelf is fine.

Whatever you pick, the software enforces it:

Auto-return the alarm to service on expiry, and log the return
Annunciate or list shelves that are about to expire (a few minutes' warning beats a silent snap-back)
Log the shelve, unshelve, and expiry events with user and timestamp

The point isn't a specific number. It's that the limit is a deliberate decision, not "whatever the operator felt like."

Suppress on state, not on annoyance

State-based suppression earns its keep when an alarm genuinely has no meaning in an operating state. Drive it off the equipment state model you already have:

Stopped / starting / running / stopping
Manual / auto / remote / local
Production / cleaning / maintenance / standby
In service / isolated / out of service
Comms healthy / failed

A pump commanded stopped doesn't need a run-feedback-fail alarm. A CIP skid in cleaning mode wants a different alarm set than the same skid in production. Fine — document the condition and test it.

What I push back on is the suppression rule that exists only to shorten the list. If an alarm is useless in every normal state, the alarm is wrong — fix the setpoint or delete it, don't paper over it with suppression logic that someone will have to reverse-engineer in three years.

Bad quality is where suppression turns dangerous

Here's the one that bites people. State-based suppression reads the process state from the PLC. When the PLC, remote I/O rack, radio link, or protocol gateway drops, the HMI is now suppressing alarms based on a stale state it thinks is current. The pump "looks stopped," so low-flow stays suppressed, while in reality you have no idea what the pump is doing.

So decide the fail direction explicitly:

Surface bad quality on the HMI — don't let a stale value render as a healthy green
Alarm on loss of comms to any device whose state drives suppression
Make suppression fail toward showing the alarm when the driving quality is bad, unless you have a specific reason not to
Actually test PLC restart, server restart, and a yanked network cable — this is where "it worked in the demo" quietly fails

On remote sites, one comms alarm often stands in for dozens of field alarms you can no longer see. Make that relationship obvious to the operator, because their mental model is "no alarms = all good."

What to test at FAT/SAT

Don't just prove the alarm activates. Prove the whole lifecycle around it, and do it before the last startup day — alarm state behavior is miserable to debug while the plant is trying to run.

Alarm appears with correct priority, message, area, equipment
Operator can shelve only if permitted; duration options match the standard
Required comments are enforced
Shelved alarm shows on the hidden-alarm display, and an active-shelved condition is visible somewhere
Expiry returns the alarm to service and logs it
Suppression tracks the intended equipment state — and fails safe when quality goes bad
Disable and bypass actions are logged with user and time
Event history can answer "who changed this state, when, and why"

The rule I'd leave on the wall: every alarm that isn't annunciating should still be explainable from the HMI, without anyone opening controller code or digging through old emails. A clean banner is only worth something if it's honest.