SCADA alarm management is the work of making sure every alarm an operator sees is real, relevant and has a defined response. It sounds obvious, yet most legacy water and process SCADA systems alarm on far too much. The UK's best-known lesson is the Texaco Milford Haven refinery, where the HSE notes that operators faced a barrage of alarms for five hours before the incident.
Water control rooms rarely face explosions, but they do face the same human problem. When a storm hits and every pumping station on the network reports at once, the operator who can see the three alarms that matter prevents the spill. The one buried under four hundred others does not.
What the guidance says
HSE's alarm management page sets out principles that every SCADA engineer should know, and points to EEMUA Publication 191, Alarm systems: a guide to design, management and procurement, as the main UK reference. Its key principles include:
- Alarms should direct attention to plant conditions that need timely assessment or action.
- Each alarm should alert, inform and guide the operator's response.
- Every alarm should be useful and relevant to the operator, with a defined response.
- Alarm levels should give enough time to respond before conditions escalate.
- The system should be designed around human capabilities and limitations.
In the process industries, ANSI/ISA-18.2-2016 covers the full alarm lifecycle, from identification and rationalisation through implementation, maintenance and change management, with a documented alarm philosophy at its centre. EEMUA 191 and ISA-18.2 work well together: one gives practical guidance, the other a lifecycle structure.
Step 1: write an alarm philosophy
The alarm philosophy is a short document that defines what counts as an alarm on your system, how priorities are assigned, how alarms are shown, who can change them and how performance is measured. For a water company it should sit alongside the engineering standard, and every new project should follow it.
Step 2: measure before you change anything
Export a few weeks of alarm and event logs and find the worst offenders. On most systems a small number of tags generate a large share of alarms: a chattering level switch, a communications alarm that clears itself, a standby pump that reports as failed whenever it is not running. Fixing the top twenty usually changes how the control room feels within days.
Step 3: rationalise alarm by alarm
| Problem | Typical cause | Fix |
|---|---|---|
| Chattering alarm | No deadband or delay | Add hysteresis and on/off delays |
| Standing alarm | Equipment out of service | Shelving with expiry, or state-based suppression |
| Duplicate alarms | Same fault seen by several tags | Keep the root alarm, demote the rest |
| Alarm flood after trip | Every downstream device alarms | First-out logic and suppression groups |
| Everything high priority | No agreed priority rules | Priority from consequence and response time |
Rationalisation is a team exercise. Sit an operator, a process engineer and a controls engineer together, go through the alarm list and record a decision and reason for each alarm. The output is a master alarm database that the SCADA configuration must match.
Shelving, suppression and out-of-service
Operators need a safe way to silence alarms from equipment they already know about, such as a pump isolated for maintenance. Give them shelving with an automatic expiry, record who shelved what and why, and show shelved alarms on a separate list that supervisors review each shift. State-based suppression is more powerful: when a process unit is offline, the PLC tells SCADA which of its alarms are meaningless. Both need rules in the philosophy, or they become a way to hide real problems.
Priorities from consequence, not habit
Set priority from two things: how bad the consequence is if nobody acts, and how long the operator has to act. A high-high wet well level at a station that spills within minutes is top priority. A run-hours reminder is not an alarm at all. Writing this matrix down once saves hours of argument in every later project.
Step 4: design the HMI to support it
Priorities only help if the screens show them clearly. High-performance HMI practice uses muted grey graphics so that colour is reserved for abnormal conditions. The video below gives a short introduction.
What is High-Performance HMI?
RealPars
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeStep 5: keep it managed
Alarm systems decay. New projects add alarms, temporary changes become permanent, and shelved alarms are forgotten. Review alarm rates monthly, require change control for any alarm setting, and check that every new package follows the philosophy before it is accepted. HSE's information sheet Better alarm handling draws on the Milford Haven lessons and is a good short read for the whole team.
Doing it during an upgrade
The cheapest time to fix alarms is during a PLC or SCADA upgrade, because tags are being rebuilt anyway. Our treatment works upgrade guide shows where alarm rationalisation fits in the project, and pumping station alarms are covered in our pumping station control article.
Next step
Send us an export of your alarm and event log and the current alarm list. We will return an analysis of the worst offenders and a proposed rationalisation scope through our automation engineering service, or you can contact us to discuss it.
