Alarm Management for HMI Engineers
You can draw the calmest, most standard-compliant operator screen in the world and it will still fail if the alarm system underneath it is broken. Colour discipline on the screen and alarm discipline in the logic are the same project seen from two ends — and most plants only ever do the first half.
This guide is the alarm half. It is written for the person who builds the HMI, not for the process safety department: what alarm management actually asks of you, which decisions must be made before you draw anything, and exactly how alarm priority should appear on the screen.
1. The failure mode: nobody designed the alarms
Alarms are the one part of a control system that almost never gets designed. Symbols get reviewed. Screen layouts get reviewed. Alarms get added — one at a time, over years, by whoever was on site that week, usually in response to an incident nobody wants to repeat.
The result is predictable and remarkably consistent across industries:
- Alarm floods. A single upset trips one alarm, which trips twelve consequential alarms, which the operator cannot read fast enough to act on any of them.
- Standing alarms. Alarms that have been active for weeks because the condition is real but nobody can fix it. They occupy the summary list permanently, and the operator learns to scroll past.
- Chattering alarms. A signal sitting on its threshold generates hundreds of transitions an hour. Every one of them is noise.
- Alarms that are not alarms. "Pump 3 started." Nothing is wrong; there is nothing to do. It is an event, logged as an alarm, competing for the same attention.
The common measure of health is the alarm rate per operator. The widely cited EEMUA 191 benchmark treats roughly 150 alarms per operator per day (about six an hour) as the boundary of what is manageable in steady operation, with the "very likely acceptable" target closer to one alarm every ten minutes and a hard limit of about ten alarms in the ten minutes after an upset. Most brownfield plants that measure themselves for the first time find rates several times higher.
Treat those numbers as a thermometer, not a target to design toward. If your rate is 2,000 a day, the problem is not that you need to delete 1,850 alarms — it is that nobody has ever decided what an alarm is for on this plant.
2. The one rule that fixes most of it
ISA-18.2 defines an alarm as an audible or visible means of indicating an equipment malfunction, process deviation, or abnormal condition requiring a response. The last three words carry the whole standard.
So the test for every candidate alarm is a single question, and it is not a technical one:
What is the operator supposed to do about it, and how long do they have?
If there is no answer — no action, or an action nobody could take in time, or an action that happens automatically anyway — then it is not an alarm. It may be a log entry, a trend, a maintenance work order, or a status indication on the screen. All of those are useful. None of them should make a noise or occupy the alarm banner.
Applying only this rule, without any tooling, typically removes a large fraction of a legacy alarm list. It is also the rule that makes the HMI design tractable: what survives is small enough to represent honestly on a screen.
3. The ISA-18.2 lifecycle, in the order you actually meet it
ISA-18.2 (also published as IEC 62682) frames alarm management as a lifecycle rather than a document. As an HMI engineer you will meet the stages in roughly this order:
| Stage | What it produces | Your stake in it |
|---|---|---|
| Philosophy | The plant's written rules: what an alarm is, how many priorities exist, what each colour means, response expectations | Your colour and symbol conventions must match it, or the screen contradicts the paperwork |
| Identification | Candidate alarms from HAZOP, P&IDs, incidents, operator requests | None yet — but this is where the list grows uncontrolled |
| Rationalisation | For each alarm: cause, consequence, corrective action, time to respond, priority, setpoint | This is the input to your design. No rationalisation, no defensible priorities |
| Detailed design | Deadbands, on/off delays, suppression rules, priority-to-colour mapping, display design | Half of this is yours |
| Implementation | PLC/DCS configuration, HMI objects, training | Yours |
| Operation & maintenance | Shelving, out-of-service handling, testing | The screen must show these states honestly |
| Monitoring & assessment | Rate metrics, bad-actor lists, flood analysis | Feeds the next revision |
| Management of change & audit | Controlled changes, periodic review | Keeps the screen and the logic from drifting apart |
You do not need to own the lifecycle. You do need to refuse to guess the parts of it that were skipped: if nobody can tell you the priority of an alarm and what the operator does about it, that is a finding, not a detail to fill in yourself.
4. Allocating priority without arguing about it
Priority is not importance and it is not severity. It is urgency of operator response, derived from two things: how bad the consequence is if nothing is done, and how long the operator has before that consequence arrives.
A consequence/time matrix keeps the discussion objective. A typical four-level allocation:
| Priority | Consequence if unaddressed | Time to respond | Typical share of the list |
|---|---|---|---|
| P1 · Critical | Safety, environment, or major equipment loss | Minutes | ~5 % |
| P2 · High | Production loss, quality loss, trip risk | Tens of minutes | ~15 % |
| P3 · Medium | Degraded operation, rising cost | Hours | ~80 % |
| P4 · Low | No consequence; awareness only | No deadline | Use sparingly |
The distribution matters as much as the definitions. If a third of your alarms are P1, the priority scheme carries no information — the operator cannot triage a list where everything is critical. Roughly 5 / 15 / 80 is the shape most alarm philosophies aim for, and it is worth checking your list against it before you design a single display.
P4 deserves suspicion. In practice most "information alarms" are events that belong in a log or a status field on the screen. If it never requires a response, question whether it should be in the alarm system at all.
5. Showing priority on the screen
Now the HMI part. The calm ISA-101 palette exists precisely so that alarm colour has somewhere to land. The canonical mapping:
Three rules govern how these appear:
Colour is never the only cue
Around one man in twelve has some form of colour vision deficiency, and red/green confusion is the most common form. Every alarm indication must carry a second, non-colour cue: the priority number in the badge (P1, P2), a distinct shape, a position, or text. A red circle and an orange circle that differ only in hue are, for a meaningful share of your operators, the same circle.
The alarm rides on the equipment, not next to it
An operator scanning a mimic should be able to answer "what is wrong and where" in one fixation. That means the alarm badge sits on the pump, the valve, the motor — a small filled disc in a consistent corner of the symbol, carrying the priority text. The equipment keeps showing its own state (running, stopped, no feedback) underneath; the badge is additive.
This is why the nine standard motor states include "running + P1 alarm" and "running + P2 alarm" as distinct states rather than replacing the running colour: the operator needs both facts at once.
Blink means unacknowledged, and nothing else
Blinking is the most expensive attention signal you have, and it is exhausting. Reserve it for a single meaning: a new alarm that nobody has acknowledged yet. Once acknowledged, the badge goes solid and stays until the condition clears. A screen where things blink permanently has taught its operators to ignore blinking.
6. The three displays an alarm system needs
- The banner. Always visible, on every screen, showing the highest-priority unacknowledged alarms — typically the most recent one or two lines. It answers "is something wrong right now?" without navigation.
- The summary. A sortable, filterable list of active alarms with priority, tag, description, time, and acknowledgement state. Default sort should be priority first, then time — not time alone, which buries a P1 under a flood of P3s.
- The mimic badge. On the process graphic, as described above. This is what converts "LSHH-104 high high" into "that tank, over there".
A fourth view — the alarm history/analysis page — is for engineering rather than operation, but it is where your rate metrics and bad-actor lists come from, so do not omit it.
7. Shelving, suppression and out-of-service — show them
Every real plant needs a way to temporarily silence an alarm: a known-broken transmitter, a unit down for maintenance, a nuisance alarm awaiting a fix. ISA-18.2 distinguishes these mechanisms, and the important HMI consequence is the same for all of them:
A suppressed alarm must be visibly suppressed. Never let the screen imply that a silent alarm is a healthy one.
Practically: a shelved tag keeps a muted marker on the mimic, appears in a dedicated "shelved" filter on the summary, and carries an expiry. Shelving without expiry becomes permanent suppression, which is how plants end up with instruments that have been "temporarily" disabled for three years.
8. Killing chatter before it reaches the screen
Most alarm noise is fixable in the logic, and it is cheaper there than in the HMI:
- Deadband. The alarm clears at a value meaningfully inside the threshold, not at the threshold itself. A few percent of range removes most oscillation chatter.
- On-delay. The condition must persist for a defined time before the alarm is raised. Transients that resolve themselves in two seconds never needed an operator.
- Off-delay. Prevents flicker on the way out.
- State-based suppression. A low-flow alarm on a stopped pump is not information; it is noise. Suppress alarms that are meaningless in the current equipment state — and make that logic explicit and documented, not a hidden hack.
- First-out / cause-and-effect grouping. When one root event necessarily produces ten consequential alarms, present the root cause and collapse the rest.
These are the highest-leverage changes available. Deadband and on-delay alone routinely cut a plant's alarm rate by more than half, and they cost nothing but review time.
9. What to measure
You cannot argue about alarm quality without numbers. The minimum set:
- Average alarms per operator per hour and per day — the headline health number.
- Peak rate in a ten-minute window — detects floods that averages hide.
- Top ten bad actors — in most plants a handful of tags generate a large share of all alarms. Fixing ten of them changes the day-to-day experience more than any redesign.
- Standing alarm count and age — alarms active longer than a shift.
- Priority distribution — compare against the 5 / 15 / 80 shape.
- Shelved alarm count and expiry compliance.
10. A checklist you can apply this week
- Export the alarm list. Count it. Compute the per-operator daily rate.
- For each alarm, fill three columns: consequence, operator action, time to respond. Anything with a blank action column is a candidate for deletion or demotion.
- Rank the top ten bad actors by count and fix them with deadband, on-delay or state-based suppression.
- Check the priority distribution. If P1 exceeds ~10 %, re-rationalise.
- Confirm every priority has a distinct colour and a distinct non-colour cue on the screen.
- Confirm blinking means exactly one thing on your HMI.
- Confirm suppressed and shelved alarms are visible as such.
- Put a banner on every screen if there is not one already.
Draw the alarm states, don't improvise them. The P1/P2 badges, the alarm and state markers and the calm ISA-101 palette are built into the Symbol Builder — mark the body of the equipment and export the nine standard states, badges included, as a ready-to-import set.
Open the Symbol Builder → Get the ISA-101 cheat sheet →Frequently asked
Is ISA-18.2 the same as IEC 62682?
Effectively yes — IEC 62682 is the international adoption of ANSI/ISA-18.2, so a plant certifying against either is working from the same lifecycle. EEMUA 191 is a separate, older and more prescriptive guide that is widely used for its performance benchmarks.
How many priorities should we have?
Three or four. Three (critical / high / low) is enough for most plants and is easier to allocate consistently. More than four and the boundaries stop being defensible, which pushes everything toward the top.
Should alarms be audible?
Yes for P1 and usually P2, distinct per priority, and silenceable independently of acknowledgement. An audible signal that cannot be silenced without acknowledging teaches operators to acknowledge blindly.
Where does this leave the HMI designer if the plant has no alarm philosophy?
Write the two pages that matter: the priority definitions with their response times, and the colour/shape mapping. Get it signed. It is not a full philosophy document, but it makes your screen defensible and it is usually the seed the plant needed.