Why an alarm list stops being read
No plant’s alarm list is built in one sitting. It starts with a reasonable core during commissioning, then grows after every fault, one “let’s see this one too” at a time. Five years later the picture is usually the same: every analogue tag has four thresholds, every motor has both a “not running” and a “no feedback” alarm, and not one priority has been revisited since day one.
You find out how that list behaves the moment something breaks. A feed pump stops; pressure drops, the flow alarm comes in, the low level alarm comes in, the downstream tank reports high level, the dryer temperature drifts. One root cause, twenty lines. This is an alarm flood, and the only thing an operator can do with it is silence the list — and an operator who has learned to silence will silence the real alarm too. At that point the alarm system has stopped working while still looking healthy on screen.
The method below is the shared backbone of ISA-18.2 (Management of Alarm Systems for the Process Industries) and the EEMUA 191 guide. The sequence is the same for a new system and for cleaning up a ten-year-old SCADA.
Step 1: Apply the definition — no action means it is not an alarm
Both standards start from one sentence: an alarm is the annunciation of a condition that requires an operator response. That gives a one-question filter:
When this annunciation arrives, what will the operator do?
If the answer is “nothing”, “just for information” or “maintenance will look at it in the morning”, it is not an alarm — it is an event. Events go to the log, show up on trends and get counted in reports, but they never appear in front of an operator with sound and colour. This filter alone usually removes a substantial part of an unreviewed list.
For every alarm that survives, record five fields. This is what ISA-18.2 calls the master alarm database — the alarm list’s single source of truth:
| Field | What goes in it | Why it is needed |
|---|---|---|
| Cause | The physical condition that triggers the alarm | Makes a second alarm on the same cause visible |
| Consequence | What happens if nobody responds | Priority is derived from this, not guessed |
| Operator action | A concrete, one-line intervention | If no action can be written, the alarm goes |
| Response time | Order of seconds or minutes | Input for delay and priority settings |
| Priority | Consequence severity × response urgency | A matrix output, not a personal preference |
Any alarm whose “operator action” line you cannot fill in leaves the list. If deleting feels too aggressive, demote it to event level: the record survives, the screen gets cleaner.
Step 2: Derive priority from a matrix, then measure the distribution
Priority is not whatever the engineer who wrote the alarm felt that day. Consequence severity (personnel safety, environment, equipment damage, production loss) is crossed with required response time in a matrix, and priority is read off from there.
Then look at the distribution. Common practice, and the target both guides point at for three priorities, sits around these values:
| Priority | Target share | Symptom when it is broken |
|---|---|---|
| High / critical | ~5% | If everything is critical, nothing is |
| Medium | ~15% | A bulge here means the matrix was skipped |
| Low | ~80% | A small low share keeps operators permanently running |
What you usually find on site is the inverse: more than half the alarms are “high”. Producing the distribution is half a day of querying and shows in one chart how much rationalisation the system needs.
Step 3: Suppress noise at the source
Some alarms that survive rationalisation still arrive far too often. The fix is not switching them off but separating measurement noise from the alarm logic.
Deadband. Without a hysteresis band around the threshold, a signal sitting near it will come and go hundreds of times. Commonly published starting values are a percentage of measurement span: around 5% for flow, 5% for level, 2% for pressure, 1% for temperature. Treat those as starting points; the real value comes from the signal’s own noise amplitude — put the band above the peak-to-peak noise.
On/off delay. Short excursions do not need to reach the operator. An on-delay raises the alarm only when the condition persists; an off-delay stops it from vanishing the instant the condition clears. The criterion for choosing the time is the response time field in the master alarm database: any delay below the operator’s intervention window is safe. Depending on the natural time constant of the process, a few seconds to about a minute is typical.
Chattering alarms. The common definition is an alarm that transitions three or more times within one minute. Detecting them takes a query grouping the alarm log by tag and counting transitions per minute. The handful of tags at the top of that list usually produce a surprising share of the total load, and that is where deadband and delays get applied first.
Stale alarms. An alarm active for more than 24 hours sits on screen as a permanent red line and hides new alarms. The common target is single digits on any given day. Something permanent is not an alarm but an operating condition — if a tag is out of service, take its alarm out of service too.
Step 4: Handle derived alarms in logic — first-out and state-based suppression
Once the noise is gone, the real problem is the chain of alarms one fault triggers.
First-out logic. Within a fault group, the first alarm to arrive is latched and flagged as the initiating cause; later alarms in the group go to the log but raise no annunciation. The classic application is a machine trip: if the stop chain has ten conditions, what the operator needs is which one opened first. Build the logic on the PLC side, within a single scan; leave it to SCADA and communication latency will scramble the ordering.
State-based suppression. Whether an alarm is valid depends on the state of the process. A “no flow” alarm on a stopped pump carries no information, and neither does a “low temperature” alarm on a furnace still warming up. Hold equipment state (stopped / starting / normal running / cleaning / maintenance) in a state machine and record which states each alarm is valid in.
The one real risk here is suppression left switched on. Two safeguards are mandatory: the reason for every suppression sits on a list the operator can see, and every manual suppression carries a timeout. Open-ended shelving becomes permanent blindness.
Step 5: Measure the rate and compare it against the targets
Nobody can tell whether an alarm system is improving if it is not measured. The metrics below are the commonly published EEMUA 191 and ISA-18.2 targets, calculated per operator console rather than per plant:
| Metric | Common target | Unacceptable |
|---|---|---|
| Alarms per operator per hour | ~6 | Above 12 |
| Alarms per operator per day | ~150 | Above 300 |
| Alarms per 10 minutes | 1–2 | Above 10 (flood threshold) |
| Share of time spent in flood | Below 1% | Continuous flood |
| Share of the 10 most frequent alarms | Below 5% | A single tag above 5% |
| Stale alarms (>24 h) | Single digits | Double digits and rising |
The SCADA alarm log is enough to produce these numbers; no separate product is required. Streaming alarm records to a database and pulling a weekly report is the practical way to get measurement in place — the job of the data acquisition and analytics layer, while the alarm logic itself is built on the industrial automation side, in the PLC and HMI layers.
What you can do tomorrow
Rationalising an entire alarm list in one week stops the work altogether. A small, measurable start:
- Pull the last 30 days of the alarm log. Group by tag and sort.
- Take the 20 most frequent alarms. That list usually explains most of the total load.
- Ask the one question of each: what does the operator do? Demote the ones with no answer to event level.
- Apply deadband and delays to what remains, and confirm the chattering tags with counts.
- A week later, measure alarms per hour again and put the two numbers side by side.
Those five steps are a few days of work for a shift engineer and normally clear a visible portion of the alarm load. The real gain: once an operator sees the list is useful, they go back to reading it.