The short answer
Alarm Suppression
Suppression by design uses logic to keep an alarm off the display when the plant state makes it meaningless: a low flow alarm while the pump is stopped, a low pressure alarm on a station that is out of service, every alarm from a site whose communication link is down except the communication alarm itself. It is designed during rationalization, documented per alarm, implemented in the controller or the SCADA, listed on a display so that suppressed alarms are visible as suppressed, and tested so that an alarm returns when the suppressing state ends. Out-of-service suppression for maintenance is a separate mechanism with a permit, a record, and a return-to-service check. Suppression that is undocumented, untested, or stuck is how a real alarm disappears, and every philosophy has rules against it.
Key points
- Suppress an alarm only when the plant state makes it meaningless, and say so in the rationalization record.
- Parent-child and first-out logic stop a flood at its source: one communication alarm, not fifty.
- A suppressed alarm is still evaluated, still journaled, and listed as suppressed on a display.
- Suppression logic is tested like an interlock: does the alarm return when the state ends.
- Out of service is a procedure, not a checkbox: permit, record, return-to-service check.
- A suppression that never releases is a deleted alarm; audit the suppressed list for the ones that have been there for months.
State-based alarming
Most nuisance alarms are valid alarms in the wrong state. A pump that is stopped has no flow, and a low flow alarm on it is not information. A lift station taken out of service for a rebuild has low level, no pumps available, and no communication, and every one of those alarms is expected. State-based alarming makes the alarm condition include the state: low flow and pump running for a delay; low pressure and station in service; the alarm is suppressed, automatically, while the state says it should be. The logic belongs in the rationalization record for each alarm, with the state it depends on, and it is implemented where the alarm is detected, which is usually the controller.
| Alarm | Suppressed when | Why |
|---|---|---|
| Low flow, low discharge pressure on a pump | Pump stopped, and for a delay after start | No flow is expected |
| Fail to start | Pump not in AUTO, or no start commanded | Only meaningful for a commanded start |
| Low level in a wet well | Station in a pump-down or cleaning mode | Operator is draining it on purpose |
| Analyzer alarms | Sample flow lost, analyzer in calibration | The value is not a measurement |
| All alarms at a remote site except communication | Communication to the site lost | They are consequences of the one alarm |
| Drive fault alarms | Drive control power off for maintenance | Expected |
| Process alarms in a treatment train | Train shut down or in a defined off state | Expected while off; alarms return on startup with a delay |
Floods: parent and child, first out
A single event can produce dozens of alarms: a lost radio link brings bad quality on every tag from the site, a tripped feeder breaker stops every pump in a station, a plant shutdown takes every process value out of range. The operator needs the one alarm that says what happened and not the fifty that say what followed. Parent-child suppression ties each consequential alarm to the causal one: while the communication alarm is active, the site alarms are suppressed; while the feeder alarm is active, the pump fail alarms are. First-out logic in a trip sequence records which alarm came first and presents that one with the rest grouped under it. Both are designed from the flood analysis, which looks at the alarm journal for the events that produced the largest bursts.
Out of service
A transmitter being calibrated, a pump being rebuilt, a site being rewired: the alarms from that equipment will be nonsense for days, and shelving is too short. Out of service is the state for that. It is entered by an authorized person under a work order or permit, recorded with the equipment, the alarms affected, the person, and the expected return, listed on a display, and reviewed on a schedule. Returning to service is a checklist: the equipment is back, the alarms are re-enabled, and someone confirms that each alarm is in the state it should be. A piece of equipment forgotten in out of service is the most common way a plant runs for a year without an alarm it thought it had.
Rules
- Documented: every suppression in the rationalization record, with the state, the logic, and the reason.
- Visible: a suppressed alarm list on the operator stations, with the reason for each, and a count on the overview.
- Still evaluated: the condition continues to be evaluated and journaled while suppressed, so the history is complete and the return is immediate.
- Returns: when the suppressing state ends, the alarm is active if its condition is true. A delay after the state change avoids a flood on startup; it is a designed delay, not an afterthought.
- Tested: at commissioning and after any change, each suppression is forced on and off and the alarm behavior confirmed, the same way an interlock is tested.
- Audited: the suppressed list is reviewed periodically for alarms suppressed longer than their state should last; a stuck state bit suppresses forever.
- Never for the highest priority: safety-related and highest priority alarms are not suppressed by design except by parent-child logic that is itself reviewed.
Designing the logic
- 1
Start from the journal
Find the alarms that occur most, the floods, and the standing alarms. Each is a candidate for a state condition or a parent-child relationship.
- 2
Name the state
For each candidate, the plant state in which the alarm is meaningless: pump stopped, site out of service, communication lost, train shut down. If no such state exists, the alarm needs a different fix.
- 3
Write the condition
The alarm condition including the state and the delays, in the form that will be coded. Low flow alarm = flow below limit AND pump running AND run time greater than 30 seconds.
- 4
Decide where it lives
In the controller where the alarm is detected there; in the SCADA for server-evaluated alarms and for parent-child logic across sites.
- 5
Record it
In the rationalization record for the alarm, with the reason and the date.
- 6
Implement and test
Code it, then force each state and confirm the alarm suppresses and returns, with the delay.
- 7
Review
After a month, look at the journal again: the alarm rate should have fallen, and nothing should have been missed.
Frequently asked questions
- Is suppression the same as raising the alarm limit?
- No. Raising a limit changes when the alarm occurs; suppression changes whether it is shown in a given state. An alarm that chatters because its limit is set at a normal operating value needs a new limit or a deadband from rationalization, not suppression.
- Where should the suppression logic live?
- With the alarm detection, which is usually the controller: the state bits are there, the logic runs every scan, and the alarm bit sent to the SCADA already includes the state. Parent-child suppression across sites, such as communication loss, lives in the SCADA because that is where the parent alarm is known.
- How do I keep a suppressed alarm from being forgotten?
- List it. A display of every suppressed alarm with its reason and its duration, a count on the overview, and a periodic review of anything suppressed longer than expected. Out-of-service entries carry an expected return date and are reviewed against it.
- Can the operator suppress an alarm?
- The operator shelves, for a limited time. Suppression by design is engineering, decided in rationalization and changed through the change process. Out of service is a maintenance action under a permit. Keeping the three separate is what keeps each one safe.
Related topics
- 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.
- 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.
- 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.
- 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 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.
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.