The short answer
Alarm Notification and Callout
Alarm notification sends selected alarms to people who are not at the SCADA screen, by voice call, text message, app, or radio, following an on-call schedule with escalation if no one acknowledges. It should be driven by a separate notification rule set rather than by priority alone, tested on a schedule, and monitored for its own health, because a silent notification server is indistinguishable from a quiet night.
Key points
- Notification is its own rule set: which alarms, to whom, by what path, with what escalation.
- Voice and text through a dialer or a notification service; email is not a notification path for urgent alarms.
- Escalate on no acknowledgment. The schedule is data, and operators must be able to change it.
- Monitor the notifier. A heartbeat test every shift is the minimum.
- Two independent paths for the critical sites: the notifier and an autodialer at the site.
Why utilities depend on it
Most water and wastewater systems are not staffed around the clock. The plant may have an operator on the day shift and nobody at night; the lift stations and tanks never have anyone. The alarm system works only if the alarm gets to a person who can act, which means the notification layer is not an accessory to the alarm system at a utility. It is the alarm system for most hours of the week.
That makes the notification path a piece of critical infrastructure with its own design questions: what gets sent, to whom, how, how it is confirmed, what happens when nobody answers, and how the utility knows the whole chain still works.
What gets sent
Not every alarm should page anyone. The temptation is to tie notification to priority, so every high alarm calls out, and that is a reasonable start. But the two are not the same. A high-priority alarm at a staffed plant during the day needs no call; a medium alarm at a remote site at 3 a.m. may. The notification rule set is a separate set of decisions recorded during rationalization: for each alarm, whether it notifies, under what conditions, and to which group.
| Rule | Example | Note |
|---|---|---|
| By priority and time | High alarms always notify; medium alarms notify only when the plant is unstaffed | Requires a staffed or unstaffed state the operators set, or a schedule |
| By site | Every alarm from an unstaffed remote site notifies the collection system on-call group | Simple and common; relies on the alarms at those sites being rationalized so the group is not flooded |
| By class | Regulatory and safety alarms notify a supervisor in addition to the operator | Supports permit obligations and reporting timelines |
| By consequence type | Alarms that can lead to an overflow notify with a shorter escalation interval | Matches the response time computed for the high-level float |
| Never | Low priority and maintenance notifications go to a morning report | Keeps the on-call phone quiet enough that a call means something |
Paths
- Voice call
- A dialer or a notification service calls the phone, reads the alarm, and takes an acknowledgment by keypress. It wakes people up, which is the point. It works on any phone.
- Text message
- Fast and cheap, with the alarm text visible later. Delivery is not guaranteed and a sleeping person may not hear it. Good as the first attempt with voice as the escalation, or in parallel.
- Mobile application
- Push notification with acknowledgment, often with a view of the alarm summary and trends. Depends on a data connection and on the application being installed and permitted to interrupt.
- Useful for reports and low-priority information. Not a notification path for anything urgent, because nobody is woken by email and delivery timing is uncontrolled.
- Radio and pager
- Still in use where cellular coverage is poor. Paging networks have shrunk; check coverage before relying on one.
- Site autodialer
- A dialer at the remote site, on its own line or cellular modem, triggered by hardwired inputs such as the high-level float and power failure. Independent of SCADA, so it is the second path when the SCADA radio or the server is what failed.
Escalation and acknowledgment
A notification that no one acknowledges must go somewhere else. The usual structure is a call list per group: primary on-call, then secondary, then a supervisor, with a set interval between attempts. Acknowledgment from the field, by keypress on a voice call, by reply to a text, or in the application, stops the escalation and is logged. Acknowledging the notification is not the same as acknowledging the alarm in SCADA, and the two should be kept distinct: the operator acknowledged that they know, and the alarm remains until the condition clears.
Escalation intervals come from the response time of the consequence. An overflow with ten minutes of storage cannot wait five minutes per call attempt through three people. For those alarms the notifier calls the primary and secondary together, or the interval is short and the list is long.
Monitoring the notifier
A notification server that has quietly stopped looks exactly like a quiet night. The failure is discovered when a station overflows and nobody was called. The notifier therefore needs to be watched as carefully as any other critical system.
- A heartbeat test: a scheduled test notification every shift or every day that an operator must acknowledge, with an alarm if it is not delivered or not acknowledged.
- Health of the notifier itself as a SCADA alarm: service running, modem or service connection up, license valid, queue empty.
- A watchdog between SCADA and the notifier, in both directions, so a stalled link is alarmed by whichever side is still alive.
- Redundancy for the critical sites: a site autodialer on independent power and an independent line, tested on the same schedule as the high-level float.
- A log of every notification and its outcome, reviewed after every callout and monthly for patterns.
Configuration mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Every alarm notifies | The on-call phone rings all night; operators turn it off or ignore it | Rationalize; notify by rule, not by default |
| Notification tied only to priority | Alarms that need a call at night do not get one; alarms that do not need a call do | Separate notification rules with a staffed-state condition |
| Single path through the SCADA server | A server, network, or radio failure silences every site at once | Autodialers at critical sites; notifier health alarms |
| Escalation to voicemail | The call is counted as delivered when voicemail picks up | Require a keypress acknowledgment; configure the dialer to treat voicemail as no answer |
| Schedule maintained by one person | Wrong person called on any week that person is away | Operator-editable schedule shown on the HMI |
| No test | Notifier failure discovered by an incident | Daily heartbeat with acknowledgment |
Frequently asked questions
- Should the notifier be part of the SCADA platform or a separate product?
- Either works. Built-in notification is convenient and reads the alarm database directly. A separate product is easier to make independent of the SCADA server, and some are built for this with their own hardware and lines. The independence argument favors separate for the critical path, but a built-in notifier with a well-tested site autodialer as the second path is a common and reasonable design.
- How many people should be on the escalation list?
- At least three: primary, secondary, and a supervisor, so that one missed call and one unavailable person still leave someone. For alarms with very short response times, call the first two at once.
- Can operators acknowledge alarms from their phone?
- Most applications allow it. Whether they should depends on the alarm class. Acknowledging the notification is always appropriate; acknowledging the SCADA alarm remotely is appropriate if the operator has enough information on the phone to make the decision the acknowledgment implies. Regulatory and safety alarms often require acknowledgment at the console.
- What about cellular coverage at the on-call person's home?
- Check it, for every person on the list. A voice call to a landline is still the most reliable path for someone who lives outside coverage, and the notifier should allow a different path per person.
Related topics
- 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 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.
- 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.
- Lift Station High LevelThe alarm that stands between a lift station and an overflow: where the high-level float goes, what it must do on its own, how much response time the well provides, and how to diagnose a high level that should not be happening.
- SCADA RedundancyWhat redundant SCADA servers protect against and what they do not, how failover works for tags, alarms, history, and clients, the network and controller layers beneath it, and why an untested failover is not redundancy.
- 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.
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.