The short answer
Alarms in the Controller
An alarm condition belongs in the controller because the controller is the one place that sees the process every scan, keeps running when the SCADA server or the network is down, and can act on the condition with an interlock or a shutdown at the same time it reports it. The SCADA system annunciates, prioritizes, records, and notifies, but the decision that a level is high or a pump has failed to start is made once, in logic, with a setpoint, a deadband, and a delay that are documented and adjustable. A standard alarm block applied to every analog and every discrete condition makes the behavior uniform and the list auditable, and packing the alarm bits into words gives SCADA a compact, reliable picture that survives a communication loss with a single bad-quality indication rather than a flood of stale alarms.
Key points
- The controller decides the alarm state; SCADA annunciates it. One source of truth, and it works when the server does not.
- Every analog alarm has a setpoint, a deadband, and an on delay; every discrete alarm has a condition and a delay.
- Use one standard alarm block for the whole program so behavior and documentation are uniform.
- Fail-to-start, fail-to-stop, and rate-of-change alarms catch equipment problems that limit alarms miss.
- Pack alarm bits into words for SCADA, keep the controller alarm list matched to the alarm philosophy, and make setpoints adjustable from the screen with limits.
Why the controller
- It sees the value every scan, not every poll; a short excursion is caught.
- It keeps working when the SCADA server, the network, or the radio is down, and can drive a local horn, a dialer, or a shutdown.
- The same condition drives the interlock and the alarm, so they can never disagree.
- Setpoints and delays live in one place and are backed up with the program.
- SCADA receives a state, not a value to evaluate, so every client and every historian sees the same alarm at the same time.
A standard analog alarm block
| Input | Purpose | Typical value |
|---|---|---|
| PV | The engineering unit value being watched | The scaled tag |
| HH, H, L, LL setpoints | The four limits | From the alarm philosophy; adjustable within limits |
| Deadband | Hysteresis so the alarm does not chatter at the limit | 1 to 2 percent of span, or a process-based value |
| On delay | How long the condition must persist before alarming | 2 to 30 seconds for most process alarms |
| Off delay | How long it must clear before returning to normal | Often zero; used where the value oscillates |
| Enable | Suppress by design during a known state, such as a pump starting | From the sequence logic |
| Bad quality | Force the value alarms off and raise a separate instrument alarm | From signal validation |
| Output | Meaning |
|---|---|
| HH, H, L, LL active | The condition is true after delay and deadband |
| Any alarm | Combined bit for interlocks and the screen |
| Instrument fault | Bad quality, out of range, or open loop, separate from process alarms |
Discrete and equipment alarms
- Fail to start
- The run command is on and the run feedback is off after a delay long enough for the starter, typically 5 to 10 seconds. Latch it; it needs a person.
- Fail to stop
- The run command is off and the feedback stays on; a welded contactor or a wrong feedback wire. Latch it.
- Unexpected running
- Feedback on with no command; a hand switch, a bypass, or a wiring fault.
- Discrepancy
- A valve commanded open with the closed limit still made after the travel time.
- Communication loss
- A watchdog word from a remote site or a device stops changing; alarm after a delay and set the data bad.
- Rate of change
- A level rising faster than any pump combination can explain, or dropping faster than a single pump should pump; catches a burst main or a stuck valve before a limit does.
- Stale value
- An analog that has not changed by more than its noise for a period; a frozen transmitter or a held gateway value.
- Runtime and starts
- Starts per hour above the motor rating, or runtime without a stop beyond what the process should need.
Delays and deadbands
A delay filters transients: a level that wobbles past the high setpoint for one scan during a pump start is not an alarm. A deadband stops the alarm from setting and clearing repeatedly as the value hovers at the limit: the alarm sets at the setpoint and clears only when the value has moved back through the setpoint by the deadband. Both are values in the block, both are documented in the alarm list, and both come from the process, not from a habit. A chlorine residual alarm might need a two-minute delay and a deadband of a tenth of a milligram per liter; a wet well high alarm needs a few seconds and a few inches.
// Analog high alarm with deadband and on delay (structured text)
IF PV >= H_SP THEN
HighCond := TRUE;
ELSIF PV < (H_SP - Deadband) THEN
HighCond := FALSE;
END_IF;
HighTimer(IN := HighCond AND Enable AND NOT BadQuality, PT := OnDelay);
HighAlarm := HighTimer.Q;Packing for SCADA
Alarm bits are packed into 16-bit or 32-bit words in a contiguous block, with the bit positions fixed in the alarm list, so that SCADA reads the whole alarm state of a site in one or two registers per poll. The SCADA alarm server maps each bit to an alarm with its priority and message. A communication loss then produces one bad-quality condition on the block rather than a flood of individual stale alarms, and adding an alarm is a bit assignment and a list entry rather than a new poll. Setpoints are exposed in a separate block of registers that SCADA can write, with the controller clamping each to a documented range.
Keeping the list
- One alarm list, in the engineering library, with tag, condition, setpoint, deadband, delay, priority, consequence, and operator action.
- The controller block parameters are set from the list, and the SCADA alarm configuration is generated from or checked against it.
- Setpoint changes from the screen are logged with who and when; the list is updated when a change is made permanent.
- Alarm counts per shift and standing alarms are reviewed; an alarm nobody acts on is removed or re-rationalized.
Frequently asked questions
- Should the alarm latch in the controller or in SCADA?
- Process alarms follow the condition and are acknowledged in SCADA. Equipment alarms that need a person, such as fail to start, seal failure, or a discrepancy, latch in the controller and are reset from the screen or the panel after the cause is fixed, so that the equipment does not restart on its own.
- How do I stop the alarm flood when communications are lost?
- Package the site alarms in words and have SCADA treat the block quality as one condition: a communication alarm for the site, with the individual alarms held or marked stale rather than tripped. The controller keeps its own alarm state and the flood never happens.
- Can operators change setpoints?
- Within limits set by engineering and enforced by the controller, with the change logged. A high level setpoint can be moved within the range the wet well allows; it cannot be set above the overflow. The limits are in the alarm list.
- What about alarms for conditions the controller cannot see, like a server disk filling?
- Those are system alarms and belong in SCADA or the network monitor. The controller owns process and equipment alarms; SCADA owns its own health.
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.
- How to Add an AlarmFrom a request to a working alarm: define it against the philosophy, build the condition in the PLC with deadband and delays, configure the SCADA alarm with priority and message, test it end to end, and record it in the master alarm database.
- Signal ValidationCatching a failed analog input in logic before it runs a pump on a dead transmitter: range checks, module status bits, frozen-value detection, rate checks, and what the program does with a bad value.
- 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.
- Interlocks and PermissivesA permissive lets you start. An interlock stops you. Confusing the two produces equipment that either will not run or will not protect itself.
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.