SCADA Alarm Rationalisation Software: When Operators Get Thousands of Alarms a Shift and Miss the Real One

The alarm summary page nobody reads

Walk into a utility control room at shift change and look at the alarm summary. There are 60 or 70 entries standing, and the incoming operator scrolls past every one of them without reading, because they were standing yesterday too. Half are comms failures on remote sites that have been unreachable since a storm in autumn. A dozen are low level analogue alarms on a pump station where somebody set a deadband too tight in 2014. Three are from a unit that was decommissioned and never removed from the configuration. Somewhere in the historian, buried in that noise, is the pressure alarm that mattered forty minutes ago and got acknowledged in a batch of nine keystrokes.

ISA 18.2 defines an alarm flood as more than 10 alarms in 10 minutes for a single operator. EEMUA 191, the guideline most control rooms benchmark against, puts the manageable steady state at roughly one alarm per operator every ten minutes. Sit with your own alarm and event log for one week and calculate your actual rate. Most operations that have never measured come out at ten to fifty times the benchmark, and every one of them believed their alarm system was basically fine because the operators had learned to work around it.

The reason this matters beyond ergonomics: alarm floods have been named as contributing factors in serious process incidents, and after an event the first question from an investigator is what the operator was shown and when. If the answer is a screen with 400 unresolved entries, the alarm system becomes the story.

Problem one: the rationalisation lives in a workbook, the system lives in the DCS

Almost everyone has done a rationalisation workshop. A team sits in a room for three weeks with the tag list, and for each alarm they agree the cause, the consequence of no operator action, the operator action itself, the time available to respond, and from those a priority. That work is real and expensive. It comes out as a spreadsheet.

Then it dies. The spreadsheet is a snapshot. The control system keeps changing through capital projects, vendor upgrades and one engineer typing a new setpoint at 2am during a trip. Six months later nobody can say which live alarms match the rationalised record, and the only way to find out is to export the configuration and diff it by hand. In practice nobody does, so the master document quietly becomes historical fiction and the next rationalisation starts from zero.

What a build fixes is the loop, not the workshop. The master alarm database becomes the authority, every rationalisation decision is a versioned record with the person who made it and the date, and a scheduled comparison pulls live configuration from each control system and reports what has drifted. Drift is reported as a difference against an approved record, not as a list of alarms, which is what makes it actionable at a change board.

Problem two: the nuisance is measurable and nobody is measuring it

Bad actors follow a brutal distribution. In most control systems a very small number of tags generate the overwhelming majority of alarm activations, and they are almost always the same ones month over month. You do not need machine learning to find them, you need a metrics engine reading the alarm and event history and computing a handful of things properly.

• Alarm rate per operator per ten minutes, and the flood periods where it exceeded the threshold, with the ability to click into what happened.
• Chattering alarms, meaning tags that activate and clear repeatedly inside a short window, which is a deadband or filter problem with a known fix.
• Fleeting alarms that return to normal before an operator could have acted, which are noise by definition.
• Stale alarms standing beyond 24 hours, which are usually a field defect, a decommissioned asset or a suppression somebody forgot.
• Priority distribution against the shape EEMUA 191 suggests, roughly 80 percent low, 15 percent high and 5 percent emergency, versus the flat priority landscape most systems actually carry.
• Operator response time by priority, which is the number that tells you whether high priority still means anything in your control room.

Publishing those six numbers monthly, per console, changes behaviour before a single configuration edit is made. It also gives the control room manager something to take to a capital committee that is not a feeling.

Problem three: the write back is the dangerous part

Reading alarm history is safe. Changing alarm configuration on a live control system is not, and any developer who treats it casually should be removed from the project. Your DCS or SCADA vendor's change control exists for a reason, warranty terms often depend on it, and a deadband change on the wrong tag suppresses something that was doing its job.

The design that works is a one way street with a human gate. The platform proposes a change set derived from the master alarm database, routes it through your management of change workflow with the approvals your procedure requires, generates the configuration artifact in the vendor's own import format, and then verifies after the engineer applies it that the live value matches what was approved. The system never writes directly. It prepares, records and verifies. That is also exactly the evidence trail an auditor or an incident investigator asks for, so the conservative design is the compliant one.

Where PAS, DynAMo and TiPS actually stand

Hexagon PAS PlantState Suite is the most capable product in this category and nobody should pretend otherwise. It carries a master alarm database, management of change and multi vendor configuration reading across a very wide list of control systems, and for a large refinery or chemical site with the budget it is a defensible purchase. Two things push utilities away from it: commercial structure, since pricing scales with tag counts that get uncomfortable across a distribution SCADA estate, and weight, since it assumes a process plant organisational model with dedicated alarm management staff you may not have.

Honeywell DynAMo Alarm Suite is genuinely good and genuinely native inside Experion. If your estate is Honeywell end to end, buy it, and stop reading. Its value drops sharply as soon as half your alarms come from an OSI, Survalent, GE or Schneider system, because you then need a second answer for those and the consolidated view you actually wanted never appears.

TiPS has been doing this longer than most and the analytics are sound. It is narrower than PAS on the change management and configuration authority side, and the interface shows its age in a control room where operators and engineers now expect to self serve a report rather than request one.

None of the three is wrong. The gap they share for a utility or pipeline is the mixed estate with a proprietary schema per vendor and a rationalisation record that has to tie back to your own asset hierarchy, your own substation or station naming, and your own operating procedures rather than a generic plant model.

What this costs and how long it takes

From what Digital Heroes has delivered across industrial and utility projects, the shape is consistent. A first release with alarm and event ingestion from your primary control system, normalisation, the metrics engine and a master alarm database with the rationalisation record runs $60,000 to $140,000 and ships in 12 to 16 weeks. That is enough to publish real numbers per console and start killing bad actors. The full programme platform adding management of change, drift detection against live configuration, the shelving and suppression register with expiry enforcement, and conformance reporting against the ISA 18.2 lifecycle runs $180,000 to $450,000 across 6 to 12 months.

What drives cost up here: the number of distinct control system vendors, because each one is a separate extraction path with its own schema and its own export quirks. Historian volume, if you want years of history rather than a rolling window. Console and operator modelling, because alarm rate per operator requires knowing which points belonged to which console on which shift, and that mapping is rarely documented. Sites with no reliable network back to the control centre, which turn collection into a store and forward problem.

What holds cost down: starting read only. You can get most of the operational benefit from measurement and rationalisation records alone, and defer everything that touches live configuration to a second phase once the control room trusts the numbers.

When buying beats building

Buy if you are a single vendor site with a mature vendor relationship. The integrated product will always read the configuration more faithfully than an outside team can, and you will spend less.

Buy if you have no one who will own the master alarm database. Software does not rationalise alarms, people do, and a platform with nobody accountable for the record becomes another dashboard. If you cannot name the engineer whose job includes this, fix that before you spend anything.

Build when your estate is genuinely mixed, which describes most electric, water and gas utilities and most pipeline operators. Build when per tag commercial models make a packaged suite absurd at your point count. Build when the rationalisation record has to live inside your own asset hierarchy because your operating procedures, switching orders and maintenance records already do. And build when you need conformance evidence shaped to how your regulator or insurer asks for it rather than how a vendor reports it.

How to choose a developer for alarm management work

Ask how they will get alarm and event data out of each of your systems, by name. The answer should be specific: an OPC alarms and events or OPC UA subscription here, a sequence of events file export there, a direct historian read somewhere else. Vague talk of connectors means they have not looked at your estate.

Ask them to define a chattering alarm and tell you how they would compute it. If they cannot describe a repeat activation count inside a time window per tag, they will hand you an alarm list rather than an analysis.

Ask what they will never do to a live control system. The correct answer includes generating change artifacts and verifying them after application, and excludes writing directly to the DCS. A developer who volunteers that boundary understands the environment.

Ask who owns the code and the infrastructure, and put it in the contract before kickoff. At Digital Heroes the client owns the repository from the first commit. Your next step is cheap and tells you almost everything: export one month of alarm and event history from your busiest console and count activations per tag. The top twenty will be roughly the same twenty a year from now unless someone acts on them, and that list is the business case.