The Banner Was Empty and the Plant Was Not Quiet

The night operator took over a console at 22:00 and the alarm banner was empty. It stayed empty. Around 02:10 a supervisor called from the field asking why nobody had responded to a compressor trip that had been sitting there since before midnight.

The console was fine. The alarm server was fine. The trip alarm was active, unacknowledged, and priority 1. The day-shift technician had spent the afternoon chasing a level transmitter, had typed LT- into the banner search box, and had gone home. The filter persisted through a logout, through a shift handover, and through four hours of a quiet-looking screen that was in fact filtered down to eleven instruments in one tank farm.

Nobody misconfigured anything. The banner did precisely what it was told. It just never told anyone what it was doing.

Filtering is a view. Suppression is a decision.

These get blurred constantly, usually in the same sentence, and ISA-18.2 (published internationally as IEC 62682) separates them for a reason. Suppression in the standard's vocabulary is an umbrella over states that change whether an alarm is annunciated at all — shelved (operator-initiated, temporary, with a timeout), suppressed by design (logic-driven, e.g. suppress the low-flow alarm while the pump is stopped), and out of service (maintenance-initiated, authorized, and tracked). Each of those needs an authority model, an audit trail, and an expiry. Each of them is a change to the alarm system.

Filtering is none of that. It changes what one person is looking at on one screen right now. It needs no approval and no audit trail — but it does need to be impossible to miss, because it is the one that changes silently.

The practical rule I use: if the operator's action changes what anyone else sees, it is suppression and it goes through the suppression machinery. If it only changes their own display, it is a filter, and the requirement shifts entirely to visibility.

If your alarm source is an OPC UA server, this distinction is already modelled for you. Part 9 (Alarms and Conditions) carries ActiveState, AckedState, ShelvingState, SuppressedState and OutOfServiceState as separate substates on AlarmConditionType. If the server populates them, surface them — a banner that collapses all of that into one "Alarm/No Alarm" column is throwing away information the protocol went to real trouble to give you.

The default view is the only view that matters

Everything else is a control the operator has to think about. The default is what they get at 02:10 without thinking, so design that one and let the rest be convenience.

What I ship as the default, unless the site has a reason to differ:

Every active unacknowledged alarm in the operator's assigned area, priority 1 and 2, newest first.
Active acknowledged alarms whose condition is still true, below those, visually distinct — acknowledged is not resolved.
Safety and environmental alarms regardless of area assignment. A toxic gas detector two units over is not somebody else's problem.
A persistent hidden-alarm count, always rendered, even when it reads zero.

Note what is not in there: returned-to-normal alarms. Under ISA-18.2's state model, RTN-unacknowledged is a real state and it belongs in the alarm summary, but a cleared condition should never push an active unsafe one down the banner. I have seen a banner where the top three rows were all things that had already fixed themselves.

Six to eight rows is about the ceiling for a banner strip. Past that you are building a summary page and calling it a banner, and the operator has to scroll during the exact minute they can least afford to.

The hidden count is the entire safety argument

If a filter is active and the banner does not say so loudly, the filter is a hazard. That is the whole of it. Everything else in this article is detail.

Make the indicator a first-class element of the banner, not a dropdown value in a corner, and make it answer four things at a glance:

How many active alarms are outside the current view.
Whether any of them is priority 1. This gets its own colour treatment; a count of 14 hidden and a count of 14 hidden, 2 critical are different emergencies.
What kind of filter is applied — area, priority, state, or text.
How to clear it, in one click, with the button visible rather than in a menu.

Text like AREA FILTER: TANK FARM — 14 active alarms hidden (2 critical) [Show all] is ugly and long and I would still take it over a subtle tint on the header bar. ISA-101.01 pushes hard on consistent, unambiguous state indication for exactly this class of problem; a filter is a mode, and unindicated modes are how operators get surprised.

Persistent filters across sessions: fine on a dedicated area console where the area assignment is the console's identity. Not fine on a shared control room or engineering station. If you support persistence at all, tie it to the workstation configuration rather than the user session, and reset on logout regardless.

Priority is a lie until you normalize it

A banner that sorts by priority is only as good as the priority numbers feeding it, and on a plant assembled from vendor skids those numbers mean nothing consistent. The compressor package sends every alarm it has at priority 1 because the OEM's commissioning engineer thought his skid was the important one. The water treatment skid uses 1–999 with low numbers as urgent. A third box only ever emits priority 0.

Normalize at the gateway or the alarm server, before the banner ever sees it, and keep the vendor's original value in a detail field so field service can still talk to it.

The check that tells you whether your priority assignment is real: count the distribution. EEMUA 191's often-quoted split is roughly 5% high, 15% medium, 80% low. If 60% of your configured alarms are priority 1, you do not have a priority scheme, you have a formality — and a priority filter over that data will hide as arbitrarily as a text filter.

Rates are the other half. ISA-18.2 characterizes an alarm flood as more than 10 alarms per 10 minutes per operator position; EEMUA 191 puts a manageable long-run average nearer one per 10 minutes. Pull those numbers off your own historian for a month before designing filters. If steady-state is already at flood rate, filtering is a bandage over an alarm rationalization problem, and no banner design will fix it.

Communication loss: pick one lead alarm and mean it

A comms failure fails in two directions at once. Alarms derived from stale values keep evaluating against the last good number and flood the banner, or they stop evaluating and the banner goes quiet on a unit that is actually in trouble.

What the underlying protocol gives you varies more than people assume:

DNP3 (IEEE 1815) carries per-point flags in the object octet — ONLINE, RESTART, COMM_LOST, REMOTE_FORCED, LOCAL_FORCED, CHATTER_FILTER. If your driver discards these and hands the master a bare value, you have thrown away the quality information the outstation already computed.
OPC UA gives you a real StatusCode per value — Bad_NoCommunication, Uncertain_LastUsableValue, and friends. Alarm logic should branch on the severity bits, not just on the numeric value.
Modbus gives you nothing. There is no quality concept in the spec, so the gateway has to synthesize one from response timeouts and exception codes, and every downstream quality decision depends on a timeout you chose. Write that timeout down somewhere an operator can find it.

Then decide, per device, what happens to dependent alarms while quality is bad:

One lead alarm per PLC, RTU, gateway, or skid, carrying the count of affected points: GATEWAY-3 COMMUNICATION LOST — 412 points.
Inhibit derived process alarms that cannot be evaluated. Not filter — inhibit, through the suppressed-by-design path, with the state visible in the alarm summary.
Leave hardwired and independently-powered safety alarms alone. They are still valid and they are exactly what you want visible when the network is gone.
Resist per-tag bad-quality alarms. 412 of them is not diagnostics, it is a denial of service against your own operator.

The operator should never have to decode PLC03_DI_1247 during a trip. Seven columns is roughly the budget before the row stops being scannable:

Column	What it earns its width for
Time in	When the condition went active — not when the message rendered
Priority	Post-normalization value, colour-coded consistently across every screen
Area / unit	Whether it is theirs
Equipment	The thing in the field: pump, tank, drive, skid, tool
Condition	The abnormal state in words — "discharge pressure high", not the tag path
State	Active / acked / RTN-unacked / shelved / suppressed / out of service
Action hint	One short instruction, or a link to the response procedure

The engineering tag path still matters — put it in the detail pane, where maintenance will look for it and the operator won't have to.

Test it with a flood, not with one simulated alarm

Single-alarm testing proves the banner can render a row. It proves nothing about the failure modes that actually bite. Force these during commissioning, with operators watching:

Inject 60 alarms in 90 seconds from one unit. Does the top of the banner still show the most urgent one, or does the newest-first sort bury it?
Drop a gateway carrying several hundred points. Count how many rows appear.
Set an area filter, then trip something critical in a different area. This is the compressor scenario above. If the operator cannot tell from the banner alone, the design has failed and everything else is decoration.
Leave a text filter active, log out, log back in as another user. Whatever happens here is what will happen at 22:00 on a Tuesday.
Acknowledge an alarm whose condition is still true. Confirm it does not vanish.
Return-to-normal on an unacknowledged alarm — the RTN-unacked state trips up more alarm servers than any other transition.
Restart the alarm server with alarms active. Check whether the banner repopulates with correct original timestamps or restamps everything to the restart time.

Record it. Screen capture with a clock in frame costs nothing and settles the "the banner didn't show it" argument six months later, in either direction.

Mistakes I keep running into

Text search used as the everyday filter. It is a troubleshooting tool. It matches on strings that have nothing to do with plant structure, and it is the filter most likely to be left on, because it looks like a search box rather than a mode.

A filter indicator that only appears when filtered. Sounds sensible, works badly — operators learn to read the presence of a widget, not its absence. Render the count always, showing zero when nothing is hidden.

Trusting vendor priority. Covered above; it is worth repeating because it is invisible until an alarm you needed sorts below one you didn't.

Hiding that shelving exists. Operators don't need every shelved alarm in the banner. They absolutely need to know the shelf is not empty, and where to look at it. A shelf with no expiry and no visible count is a suppression that outlives the person who created it.

If you inherit an existing banner and want one test to run first, run number 3. Filter to a quiet area, trip something serious elsewhere, and watch whether an operator who wasn't told what you did notices. Everything else on this list is refinement; that one tells you whether the banner is safe.