The short answer
Alarm Shelving
Shelving lets an operator remove an alarm from the active display for a limited time, after which it returns automatically, so that a chattering or currently irrelevant alarm does not bury the ones that matter. It is an operator action, distinct from suppression by design, which is automatic logic, and from out of service, which is a maintenance state with a procedure. A philosophy sets the maximum shelve duration, commonly a shift, which priorities may be shelved by which roles, which alarms may never be shelved, and how the shelved list is displayed and reviewed. Every shelve is recorded with the user, the time, and the reason, the shelved count is reported, and an alarm that is shelved repeatedly is a candidate for rationalization, not for a longer shelf.
Key points
- Shelving is temporary, operator-initiated, and time-limited; it is not a fix for a bad alarm.
- The philosophy sets the maximum duration, who can shelve which priority, and what can never be shelved.
- Automatic unshelving at the time limit is what makes shelving safe; without it, shelving is deletion.
- The shelved list is visible on every operator station and reviewed at every shift change.
- Every shelve is logged with the user and reason; repeated shelving of one alarm goes to rationalization.
- Platforms without native shelving can implement it with a timer and a tag, with the same rules.
What shelving is for
An alarm that is technically valid can still be useless at the moment: a low flow alarm on a pump that a crew is working on, a level alarm chattering because a float is being replaced, a communication alarm on a site whose radio is known to be down until Tuesday. Left on the display, it takes attention from every alarm that arrives after it and trains the operator to ignore the list. Shelving removes it for a while, with the promise that it will come back on its own. The concept comes from the alarm management standard and is built into most modern platforms; its value lies in the rules around it.
Shelving, suppression, out of service
| Shelving | Suppression by design | Out of service | |
|---|---|---|---|
| Initiated by | Operator | Logic, from plant state | Maintenance or engineering, by procedure |
| Duration | Time-limited, automatic return | As long as the state lasts | Until returned to service by procedure |
| Reason | Nuisance right now | Alarm meaningless in this state | Equipment or instrument under maintenance |
| Approval | Role-based, by priority | Designed and documented in rationalization | Permit or work order, with a record |
| Display | Shelved list | Suppressed list | Out of service list |
| Review | Each shift | Periodic audit of the logic | Return to service checklist |
The rules
- Maximum duration: commonly one shift, eight to twelve hours; some philosophies allow shorter defaults with a supervisor extension. The alarm unshelves itself at the limit, whatever its state.
- Who may shelve what: operators may shelve low and medium priority alarms; high priority alarms need a supervisor; the highest priority and any safety-related alarm cannot be shelved by anyone.
- Reason required: a short text or a pick list. A shelve with no reason is not allowed by the platform configuration.
- Visible: the shelved list on every operator station, with the time remaining, and a count on the overview.
- Reviewed: at shift handover, every shelved alarm is discussed and either unshelved or re-shelved by the incoming shift with its own record.
- Limited repetition: an alarm shelved more than a set number of times in a month is reported for rationalization.
When an alarm is shelved
The alarm leaves the active display and stops annunciating. Its condition is still evaluated, its state is still journaled, and on most platforms a change of state while shelved is recorded so that the history is complete. When the shelf expires or the operator unshelves it, the alarm reappears in whatever state it is in at that moment: if the condition is still true, it appears as an unacknowledged alarm and annunciates. The operator who shelved it may be off shift by then, which is why the shelved list is reviewed at handover.
Implementation
Platforms with native shelving provide the button, the timer, the list, the role checks, and the journal entries, and the configuration is a matter of setting the durations and the permissions from the philosophy. Platforms without it can approximate it: a shelve tag per alarm set by a supervisor-level button, a timer that clears the tag, display logic that hides the alarm while the tag is set, a display that lists every set tag with its remaining time, and an event log entry when the tag is set and cleared. The rules are the same; what is lost is the standard reporting, which has to be built by hand.
Frequently asked questions
- Why limit how long an alarm can be shelved?
- Because an alarm shelved indefinitely is an alarm that has been deleted without anyone deciding to delete it. The time limit forces the alarm back in front of an operator, who decides again whether it is still a nuisance. If the underlying problem takes days, the alarm goes out of service by procedure, with a record and a return checklist, which is a different thing.
- Should the highest priority alarms be shelvable?
- No. The highest priority is reserved for alarms with severe consequences and short response times, and an operator should never have the option of hiding one. If such an alarm is chattering, that is an urgent maintenance problem, and the maintenance procedure with its out-of-service record is the tool.
- What should happen to a shelved alarm at shift change?
- It is on the handover list. The incoming operator sees it, hears why it was shelved, and either unshelves it or re-shelves it under their own name with the reason. Nothing shelved by a departing operator should silently continue into the next shift.
- How is a shelved alarm different from an acknowledged one?
- An acknowledged alarm stays on the display in the acknowledged state and is visible as an active problem; a shelved alarm is removed from the display for a time. Acknowledgment says the operator has seen it; shelving says the operator does not want to see it for a while.
Related topics
- Alarm SuppressionSuppressing alarms by design: state-based logic that removes alarms that mean nothing in the current state, parent-child logic that stops a flood at its source, out-of-service suppression for maintenance, the rules that keep it safe, and how to test it.
- ISA-18.2 Alarm ManagementThe lifecycle standard for alarm systems, the rate targets that define a workable system, and why alarm rationalization is the step nobody wants to fund.
- The Alarm PhilosophyThe document that decides what is allowed to be an alarm: the definition, the criteria, the priorities and their meaning, the performance targets, the handling rules, and who owns it. Under ISA-18.2 it comes first.
- Alarm RationalizationThe meeting where every alarm earns its place: who attends, what is decided for each alarm, how to document it in a master alarm database, and how to run it at a utility that cannot spare a week.
- Alarm ServersThe part of SCADA that turns a condition into an alarm and manages its life: where detection happens, the alarm state machine, priority, deadband and delays, acknowledgment across clients, the journal, notification, redundancy, timestamps, and flood behavior.
- Alarm FloodsWhat an alarm flood is, why it happens at exactly the wrong moment, the ISA-18.2 rate targets, and the design measures that keep a power failure or a communication loss from burying the one alarm that matters.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.