The short answer
Alarm Servers
The alarm server evaluates alarm conditions, or receives them already evaluated from the controller, and manages each alarm through its states: normal, unacknowledged, acknowledged, returned to normal but unacknowledged, shelved, suppressed by design, and out of service. It applies priority, deadband, and on and off delays, propagates acknowledgment to every client, writes every transition to a journal with a timestamp, and hands alarms to the notification system. In a redundant pair the alarm states and acknowledgments are synchronized, timestamps come from the source where the controller supports it, and under a flood the server buffers rather than drops. It also produces the measures an alarm philosophy calls for: alarm rate, standing alarms, chattering alarms, and the most frequent alarms.
Key points
- Detect in the controller where possible; the server manages the alarm, the controller decides that the condition exists.
- The alarm state machine has more than on and off; shelved, suppressed, and out of service are states with rules.
- Deadband and delay belong to every analog alarm; without them the alarm chatters.
- An acknowledgment on one client is an acknowledgment everywhere, and it is journaled with the user.
- Timestamps from the source are better than timestamps from the server; sequence of events depends on it.
- The alarm server produces the alarm rate and the bad actor list; if it cannot, the philosophy cannot be measured.
Where the alarm is detected
An alarm condition can be evaluated in the controller, which compares the value with the limit and sets a bit, or in the SCADA server, which compares the value it polled with a limit configured on the tag. Detection in the controller is preferred for anything that matters: the controller sees every scan, not every poll, it keeps working when the SCADA is down, and the same bit that raises the alarm can drive interlocks. Detection in the server is acceptable for advisory alarms and for legacy devices that expose only values, and it is where analog limits on historian-only tags usually live. Either way, the server manages the alarm from the moment the condition is true, and the philosophy records where each alarm is detected.
The state machine
| State | Meaning | Leaves by |
|---|---|---|
| Normal | Condition false, no unacknowledged history | Condition becomes true |
| Unacknowledged alarm | Condition true, operator has not acknowledged | Acknowledgment, or condition clears |
| Acknowledged alarm | Condition true, acknowledged; still displayed as active | Condition clears |
| Returned to normal, unacknowledged | Condition cleared before acknowledgment; shown so the operator knows it happened | Acknowledgment |
| Shelved | Operator has temporarily removed it from the display, with a time limit | Timer expires or operator unshelves |
| Suppressed by design | Logic has determined the alarm is not meaningful in the current state | Logic condition ends |
| Out of service | Removed for maintenance by an authorized person, with a record | Returned to service by procedure |
Latched alarms stay in the acknowledged state until reset even after the condition clears, which fits alarms whose cause must be investigated. Momentary alarms clear when the condition does. A platform that supports only on, off, and acknowledged can approximate the rest with logic and tags, but the reporting and the operator view suffer.
Priority, deadband, delays
- Priority is assigned per alarm from the philosophy, by consequence and time to respond, and the server displays, sorts, and colors by it. Three or four levels; the philosophy says which.
- Deadband on analog alarms: the alarm sets at the limit and clears only after the value has moved back by the deadband, so a value hovering at the limit does not chatter.
- On delay: the condition must persist for a time before the alarm is raised, which filters transients. Off delay: the condition must be clear for a time before the alarm clears, which stops rapid cycling.
- Time-based deadband and delay values are part of the alarm record and the rationalization, not a tuning knob left to whoever is bothered by the noise.
Acknowledgment and the journal
An acknowledgment means an operator has seen the alarm and taken responsibility. It happens on one client and must appear on every client, including the standby server clients, immediately. The journal records every transition: raised, acknowledged, cleared, shelved, unshelved, suppressed, out of service, returned, with the timestamp, the value, the priority, the user, and the client station. The journal is the record used for incident investigation and for the alarm performance reports, and it is kept in a database that is backed up and that does not fill the disk when a flood produces a hundred thousand entries in an hour.
Timestamps and sequence
The time on an alarm entry can be when the controller detected the condition or when the server noticed the bit. On a polled system those differ by up to a poll interval, and on a radio-polled site by minutes. Protocols that carry source timestamps, DNP3 and OPC UA among them, let the server record when the event actually happened, which is what a sequence of events analysis after a trip needs. Where the protocol does not, the server timestamp is what there is, and the philosophy notes the uncertainty. All of it depends on synchronized clocks.
Redundancy and floods
In a redundant pair, both servers must have the same alarm states, and an acknowledgment on the active server must reach the standby before a failover, or operators see alarms come back unacknowledged after a switch. Products handle this differently; the failover test checks it explicitly. Under a flood, the server receives events faster than it can journal or display them; it must buffer and catch up, keep the priority sorting working, and never silently drop. The alarm display design and the flood suppression logic reduce the flood, but the server has to survive one.
What the server should report
| Measure | Target from the philosophy | Use |
|---|---|---|
| Average alarm rate per operator | A handful per hour; about one per ten minutes is the common target | Whether the system is manageable |
| Peak rate and flood periods | Rarely more than ten in ten minutes | Flood identification and suppression design |
| Standing alarms | Few, and each explained | Alarms that have become wallpaper |
| Chattering and fleeting alarms | None | Deadband and delay fixes |
| Most frequent alarms | A short list that changes as it is worked | The bad actor list for rationalization |
| Shelved, suppressed, out of service counts | Small, reviewed each shift | Alarms not being seen |
| Priority distribution | Mostly low, some medium, few high | Whether priorities mean anything |
Frequently asked questions
- Should analog alarm limits be in the controller or on the SCADA tag?
- In the controller, as a rule, with the limits as setpoints that the SCADA can display and, with the right role, change. The controller then alarms every scan and can interlock on the same condition. Limits on the SCADA tag are acceptable for advisory alarms and for data that only the SCADA sees.
- Why does an alarm come back unacknowledged after a server failover?
- The acknowledgment did not reach the standby before the switch, or the platform does not synchronize acknowledgments at all. Check the product documentation and the failover test. Where synchronization is not available, a short journal review after any failover is the workaround, and the finding goes on the upgrade list.
- What is the difference between a shelved and a suppressed alarm?
- Shelving is an operator action, temporary, with a timer, for an alarm that is a nuisance right now. Suppression by design is logic, automatic, based on plant state, for an alarm that is meaningless in that state. Both keep the alarm off the display; both are listed and reviewed; neither is a permanent fix for a bad alarm.
- How long should the alarm journal be kept?
- Long enough for incident investigation and performance trending, and as long as any regulatory requirement says. A year online and longer in archive is common. The journal is small compared with the historian and there is little reason to discard it early.
Related topics
- 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 PriorityHow to assign alarm priorities that operators trust: a consequence-and-time matrix, three or four levels, the target distribution from ISA-18.2 and EEMUA 191, and the mistakes that make every alarm high.
- 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.
- Alarm Notification and CalloutGetting the alarm to the person on call when no one is watching the screen: notification paths, escalation, acknowledgment from the field, which alarms qualify, and the failure modes that leave a station in high level with nobody paged.
- Alarm ShelvingThe operator tool for temporarily silencing a nuisance alarm: what shelving is and is not, the rules a philosophy sets, who may shelve what and for how long, automatic unshelving, the shelved list, the record, and how to implement it on any platform.
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.