Why Every Alarm Ends Up High Priority, and How to Rank Them by Response Time Instead

Pull the alarm summary on almost any brownfield SCADA and count by priority. You will usually find half the list sitting at High or Critical. EEMUA 191 suggests a three-level scheme should land near 80% low, 15% medium, 5% high; ISA-18.2 (and its international twin IEC 62682) call that a rationalization outcome, not a color you pick in the tag editor. When everything is red, red stops meaning anything, and during the shift that actually matters the operator is scrolling past forty High alarms to find the one that explains the trip.

Priority is not decoration. It answers one question: how fast does the operator need to move, and what happens if they do not?

The two axes that actually matter

Rank on consequence and available response time. Everything else is secondary.

• Consequence — safety, environmental, quality, production, equipment damage, regulatory exposure. This is the how bad.
• Available response time — the window between the alarm going active and the consequence becoming unacceptable. This is the how soon.

Frequency is a rationalization input, not a priority axis. A relief valve that lifts once every three years is rare and still Critical. Demoting a serious alarm because it seldom fires is how the one alarm nobody has seen in years shows up as Low the day it matters.

Keep it to three or four levels

Most control rooms do not need ten priorities. I stick to three or four operational levels — anything more is impossible to train consistently and the distinction between "priority 6" and "priority 7" never survives a night shift handover.

Priority	Typical meaning	Operator expectation
Critical	Immediate safety, environmental, or major asset risk	Stop normal work and respond now
High	Prompt action needed to prevent trip, loss, or quality issue	Act within defined minutes
Medium	Abnormal condition requiring attention but not immediate shutdown risk	Handle during normal monitoring
Low	Advisory condition or maintenance follow-up	Review without distracting from active operation

The names can match the site standard. What matters is that each level carries a response expectation in minutes, not just a sound and a color. If you cannot state the expectation, you have not defined the level.

No action, no alarm

An alarm with no operator action is not improved by making it high priority. Before you touch the priority column, write the expected action in plain words:

• Check standby pump status and start if auto start failed.
• Reduce feed rate before high-high level trip.
• Call maintenance because the redundant instrument has failed.
• Confirm product hold procedure if temperature excursion exceeds limit.

If the only action is "be aware," it belongs in an event log, a status indication, or a report — not the alarm banner. If the action is purely maintenance and can wait for planned work, keep it out of the process alarm stream where it competes with things that need a response now.

Response time is not alarm delay

These two get confused constantly. Response time is the window you have after the alarm goes active before the consequence is unacceptable. Alarm delay (on-delay, off-delay, deadband) is logic you add before the alarm annunciates to stop nuisance chatter. One sizes the priority; the other keeps the signal clean. They pull in opposite directions on the timeline.

For example:

• A compressor lube oil low pressure alarm may have seconds before equipment damage.
• A chilled water temperature high alarm may have minutes before product quality risk.
• A cabinet temperature warning may have hours before a hardware problem.

Commissioning should confirm that the response time written in the rationalization sheet is realistic. If the process trips in 12 seconds but the HMI alarm appears after a 30-second delay, the priority matrix is not the main problem. The alarm design is wrong.

Priority drags behavior with it — check what

Many platforms bolt behavior onto priority or alarm class, and half of it is invisible until it fires at 3am. Walk through each of these on the live system during commissioning, not on the spec sheet:

• Banner color and flashing behavior.
• Audible tone and repeat behavior.
• Whether the alarm appears on overview screens.
• Notification, SMS, email, or escalation rules.
• Shelving permission and maximum shelve time.
• Historian or event retention period.
• Required operator note on acknowledgement or return to normal.

A high-priority alarm that pages supervisors every time an instrument chatters will quickly be bypassed. A critical alarm that can be shelved for a full shift may violate the site philosophy.

Test the matrix against real upsets, not the spreadsheet

A priority list that looks balanced in Excel can still bury the operator when a real upset hits. Sit down with operations, maintenance, and process engineering and walk several scenarios through the actual HMI:

1. Normal startup with permissives not yet made.
2. Utility loss affecting many units at once.
3. Communication loss to one remote PLC or package skid.
4. Instrument failure on a value used by several alarms.
5. A process upset where one primary alarm creates many secondary alarms.
6. Planned maintenance with bypasses or out-of-service equipment.

During each scenario, ask whether the highest priority items are truly the first things an operator should notice. If low-value alarms appear above the alarm that explains the problem, adjust priority, suppression, shelving, or alarm logic.

Don't use priority to hide a bad signal

Priority is not a filter, and demoting a chattering alarm to Low is not a fix — it just hides a broken signal, a wrong limit, a missing delay, or a repeated state transition where you will forget about it. Fix the alarm, then rank it. Presentation load belongs to other tools:

• Area filters show only alarms relevant to the operator station.
• Suppression prevents consequential alarms during known states.
• Shelving lets an operator temporarily manage a known nuisance within rules.
• Standing alarm review handles active alarms that remain after acknowledgement.

If the site uses priority as the only way to manage alarm load, the matrix will slowly become meaningless.

Common failure modes

Too many high-priority alarms

When everything is high, nothing is. Pull the count by priority and by area and hold it against the EEMUA 191 target — roughly 5% high in a three-level scheme. If a single operator station shows thirty Critical alarms, the ranking has failed regardless of how careful the matrix looked on paper. High and Critical should be a small, defendable set you can list from memory.

Priority copied from vendor equipment

Vendor severity does not always match site consequence. A package skid warning may stop a bottleneck line, or it may be only a local maintenance advisory. Map vendor alarms into the site matrix instead of copying them directly.

Priority based on who complains

A noisy alarm may get promoted because it is visible, while a quiet but serious abnormal condition remains medium. Use consequence and response time, not complaint volume.

Matrix ignores bad quality

If a process value is bad quality, dependent alarms may be invalid. Decide whether communication loss or bad-quality status has its own priority and how it affects related process alarms.

No evidence after changes

Priority changes should be recorded with date, reason, reviewer, and affected displays or notification rules. Without a change note, the next outage review becomes guesswork.

Commissioning evidence to keep

Keep enough evidence that another engineer can understand why priorities were accepted:

• The approved priority matrix and definitions.
• Alarm list with priority, consequence, response time, and expected action.
• Scenario test notes and screenshots of the alarm banner.
• Any notification or escalation tests.
• Exceptions that still need process engineering or operations approval.

None of this is worth much if the matrix only lives in the spreadsheet. The one place to check whether it worked is the alarm banner during the next real upset: if the top item is the one that explains the problem, the ranking is doing its job. If it isn't, you have your next commissioning task.