The short answer
Alarm Problems
Alarm problems occur at every layer from detection to notification: an alarm never raises because the condition is not detected, the bit is not mapped, the limit is wrong, the tag is bad quality, or the alarm is disabled, suppressed, or out of service; it raises silently because the client sound, the alarm display filter, or the notification service is misconfigured; it sticks because it is latched and needs a reset, the deadband keeps the condition true, or the value is stale; it chatters because it has no deadband or delay; it floods because nothing suppresses the consequences of one event; acknowledgments fail to propagate because the redundant pair does not synchronize them; the journal stops because the database is full; and notifications fail because of the modem, the gateway, the contact list, or the escalation logic. The end-to-end test, forcing the condition in the field and following it to the display, the journal, and the phone, is how each alarm is proven and how most of these are found.
Key points
- An alarm has a chain: condition, detection, mapping, evaluation, display, sound, journal, notification. Any link can fail silently.
- Never raised: detection, mapping, limit, quality, or a suppression, shelve, or out-of-service state that stuck.
- Raised but unheard: client sound, display filter, notification service, contact list.
- Stuck, chattering, and flooding are configuration: latching, deadband, delay, and suppression logic.
- Acknowledgment and journal failures are server problems: redundancy synchronization and database space.
- Prove every critical alarm end to end on a schedule; the test finds what the design review missed.
The chain
An alarm starts as a condition in the process, is detected by a controller or a server evaluation, is mapped from a bit or a limit to an alarm record, is evaluated through its deadband and delays, appears on the alarm display with its priority and color, sounds at the client, is written to the journal, and is sent to whoever is on call. Each step is configured separately, often by different people at different times, and any one of them can be wrong without the others noticing. That is why alarm problems are found by walking the chain, and why the proof of an alarm is a test that exercises every link.
By symptom
| Symptom | Causes | Checks |
|---|---|---|
| Alarm never raised | Condition not detected in the controller; alarm bit not mapped to a SCADA alarm; limit set outside the range the value reaches; tag bad quality suppressing the alarm; alarm disabled, suppressed by a stuck state, shelved, or out of service; server-evaluated alarm on a tag polled too slowly to catch a brief condition | Controller bit while the condition is forced; alarm configuration for the tag; the suppressed, shelved, and out-of-service lists; the tag quality; the poll rate |
| Raised, nobody heard it | Client sound off or muted; alarm display filtered to another area or priority; notification service stopped; contact on the roster wrong; escalation waiting on an acknowledgment that never came | Test sound on the client; display filter settings; notification service status and log; the roster |
| Stuck active | Latched alarm awaiting reset; deadband holding the condition true; stale value keeping the condition; a state-based suppression that ended with the condition still true | The alarm type; the live value against the limit and deadband; the tag timestamp |
| Chattering | No deadband; no on or off delay; a noisy signal at the limit; a discrete input bouncing | The alarm configuration; a trend of the value at the limit |
| Flooding | One event producing many alarms with no parent-child suppression; a plant state change without state-based alarming; a communication loss without suppression of the site alarms | The journal for the event; the suppression design |
| Acknowledgment does not propagate | Redundant pair not synchronizing acknowledgments; clients connected to different servers; a client with a stale alarm list | Which server each client is on; the redundancy configuration |
| Journal stopped | Database full or unreachable; journal service stopped; retention job failed | Database size and status; service status |
| Notification never arrives | Modem or gateway failure; carrier or account problem; wrong number or address; escalation logic waiting; the alarm below the notification priority threshold | The notification log; a test notification; the roster and the priority filter |
| Wrong priority or color | Priority assigned wrongly; display color mapping different on one client; a priority changed without rationalization | The alarm record; the display configuration |
The end-to-end test
- 1
Choose the alarm
Critical alarms on a schedule, every alarm at commissioning and after any change to its chain.
- 2
Force the condition at the source
Trip the float, simulate the transmitter, open the contact, or force the input at the controller with a record that it was forced.
- 3
Watch the controller
The alarm bit sets after the configured delay. If it does not, the detection logic is the problem.
- 4
Watch the display
The alarm appears on the alarm list and on the process display with the right priority, color, and text, and the client sounds.
- 5
Check the journal
The entry with the right timestamp, tag, priority, and value.
- 6
Check the notification
The on-call phone receives it within the configured time; the escalation proceeds if it is not acknowledged.
- 7
Clear and confirm
Remove the condition; the alarm returns to normal after the off delay; the display, the journal, and the notification reflect it.
- 8
Record
The test, the date, the result, and any correction, in the alarm record.
Using the reports
The alarm performance reports from the alarm server, the rate, the most frequent, the standing, the chattering, the shelved and suppressed counts, are the routine way to find alarm problems before an incident does. A chattering alarm on the report is a missing deadband; a standing alarm is a stuck condition or a broken instrument; a frequent alarm is a bad limit or a real recurring problem; a growing suppressed list is a state bit that never released. A weekly look at the report, and a fix for the top few items, keeps the system healthy with very little effort.
Frequently asked questions
- The alarm bit is on in the controller but nothing shows on the SCADA. Why?
- The bit is not mapped to an alarm, the alarm is disabled or in a suppressed, shelved, or out-of-service state, the tag is bad quality, or the display is filtered. Look at the alarm configuration for the tag first, then the three lists, then the tag quality, then the display filter on that client.
- The notification went to the wrong person.
- The roster or the escalation schedule is stale, or the alarm is assigned to the wrong group. Rosters change with staff and shifts, and a roster that nobody owns is wrong within months. Assign an owner, review it monthly, and send a test notification to each person on it.
- An alarm cleared on its own with nobody acting. Is that a fault?
- It is normal for a momentary alarm whose condition cleared, and the returned-to-normal-unacknowledged state exists so that the operator sees it happened. If the condition should not have cleared without action, the alarm belongs latched, and if it cleared because the value went bad quality, the bad-quality handling is wrong.
- How often should critical alarms be tested?
- At least annually, and after any change to their chain; some utilities test the highest priority alarms quarterly. The test takes minutes per alarm and is the only proof that the chain still works. Record every test.
Related topics
- Alarms Not AnnunciatingThe condition is real and nothing happened on the screen or the phone: where an alarm can be lost between the controller and the operator, from the alarm bit and the tag quality to the alarm server, the display filter, the shelved and suppressed lists, the audible, and the notifier.
- 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 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 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.
- 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 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.
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.