Newest-First Alarm Summaries Hide the Critical Alarm During a Flood

More than 200 alarms arrived in the three minutes before the trip. One of them was a compressor critical, and the operator never saw it. The summary was sorted newest-first, and a chattering level switch reclaimed the top of the list about once a second. The critical alarm turned up during the investigation, after somebody dug through the event history.

The alarm summary did not delete anything. The alarm server held every state exactly as the ISA-18.2 state model says it should, the filter hid some of them, and the sort ordered what was left. What reached the operator's eye was the output of that last stage. Knowing which stage lost it comes first.

Newest-first breaks first during a flood

ISA-18.2 (adopted unchanged as IEC 62682) defines an alarm flood as a period where the rate exceeds 10 alarms per 10 minutes per operator. The steady-operation target EEMUA 191 is usually quoted for is 1 alarm per 10 minutes per operator. A flood is ten times the target or worse. In that window, newest-first sorting turns the alarm summary into a log scrolling past the screen — the list moves faster than a person reads.

A chattering alarm on top of that is worse. ISA-18.2 defines chattering as an alarm that repeatedly transitions between the alarm state and the normal state in a short period. Under newest-first, one of those permanently owns the top few rows. Low priority, best seat in the house.

Primary sort	Good use	Risk
Unacknowledged first, then priority	Response during abnormal conditions	Acknowledged critical alarms move down.
Priority, then active time	One operator owning one area	New low-priority alarms are less visible.
Newest first	Commissioning and event review	Chattering alarms own the top.
Area, then priority	Large plants with area ownership	Cross-area events missed if area data is wrong.
First-out sequence	Trip and shutdown analysis	Not sufficient as a live summary on its own.

The default I use on the main operating summary is the first row: unacknowledged first, then priority, then oldest active first within a priority. Alarms nobody has looked at rise; alarms somebody has looked at sink but do not disappear. Newest-first stays on the commissioning display and in the event history.

Let operators change the sort if they want. Just put a reset-to-site-default button on the same screen, and write the default down. "What was it sorted by at the time?" comes up in every incident review.

State has to survive the row moving

The ISA-18.2 state model has states beyond normal, unacknowledged, and acknowledged that the operator must be able to tell apart: returned-to-normal but unacknowledged, shelved, suppressed by design, and out-of-service. Flatten those four in the summary and you have caused half of the failure modes further down.

• Returned to normal but unacknowledged — the process recovered, nobody confirmed it. Delete the row here and the transient abnormal condition vanishes without trace. The alarm that appeared and cleared in twenty seconds is often the most valuable one in the analysis.
• Shelved — an operator took it down temporarily. ISA-18.2 treats shelving as temporary and assumes a list the operator can review. Without an automatic un-shelve time, shelving is a quiet disable.
• Suppressed by design — logic suppressed it. State conditions release it, not the operator.
• Out of service — removal for maintenance. This one needs authorization and a record attached.

Keep row styling simple. Strongest treatment for active unacknowledged; still clearly visible but calmer for active acknowledged; a distinct style for returned-but-unacknowledged. Shelved, suppressed, disabled, and out-of-service rows keep a visible marker.

Do not carry meaning in color alone — ISA-101 says the same thing. Plant monitors are uncalibrated, night lighting differs from day, and colour vision deficiency runs at roughly 1 in 20 men. Colour plus a text state column clears all three.

Changing the sort column must not change what a row means. That one is not negotiable.

A filter has to display what it hid

Filters themselves are fine. A utility operator does not need packaging alarms in view all day. The problem is a filter that works silently.

Permanently at the top of the summary:

• the active area, equipment, priority, and state filters;
• the count of alarms currently visible;
• the count of active alarms outside the filter — conspicuous when it is not zero;
• separate counts for shelved, suppressed, disabled, and out-of-service;
• one click back to the site default filter.

I have seen the hidden count implemented as a tooltip, and once inside a detail popup. That is the same as not having it. It belongs in the header as a number.

Filters that persist across login sessions should not be the default behaviour. Night shift filters the summary to one skid, day shift inherits the view, and that has caused real incidents. If it must persist, clear it at logout or announce it loudly on the next login.

The list jumping right after acknowledgement

Acknowledgement gets clicked fast when things are going badly. If the sort key changes at that moment and the row moves, the next click lands on the wrong alarm. Unacknowledged-first sorting brings this on structurally — acknowledging a row is exactly what makes it jump down the list.

The fix is not to abandon the sort but to delay the resort. Freeze the order while the pointer is over the list, or for about two seconds after the last click. The implementation differs per platform; the behavioural requirement does not.

What to test:

• Does the row move immediately after acknowledgement?
• With several rows selected, does the selection stay on the intended alarms?
• Does the system require an operator note at selected priorities?
• Is mass acknowledgement restricted by role or alarm class?
• Does a server-side acknowledgement failure show on the screen? (Some implementations quietly look like success.)
• Are returned-but-unacknowledged alarms still visible while acknowledgement work is under way?

Live summary and event history are different screens

The live summary shows the load still outstanding. The event history is for reconstructing afterwards why it happened. Different purposes, so different row lifetimes.

Leave every historical event in the main summary and operators learn to ignore the whole list. Hide returned-but-unacknowledged alarms and the transient disappears again. Link the two screens; do not merge their contents.

These default columns are enough for most systems.

Column	Notes
Time in	Source time where available. Make the timezone explicit if sites span zones.
Area / unit	Must match how operating responsibility is actually divided.
Equipment or tag	Readable equipment name alongside the raw tag name, not instead of it.
Alarm message	Include the condition and limit where it helps.
Priority	Same terms as the alarm philosophy.
State	Active, acknowledged, returned, shelved, suppressed, out-of-service.
Duration	The only practical way to find standing alarms.
Action link	Faceplate, procedure, trend.

The duration column is underrated. Sort descending on it once a shift and the alarms that have been standing for days fall out immediately. ISA-18.2 calls those stale alarms, with 24 hours as the usual threshold. A long list there is not an alarm summary design problem — it is an alarm configuration problem.

A quiet FAT proves nothing

The alarm summary works fine when it is quiet. It breaks when it is noisy, so test it noisy. A simulator or forced alarms will do.

1. Raise one critical alarm while 100 low-priority alarms are active.
2. Keep a high-priority alarm active while a chattering alarm repeats.
3. Apply an area filter, then raise a critical alarm in a different area. Watch the hidden count.
4. Create a returned-but-unacknowledged alarm, then acknowledge a different row.
5. Shelve or suppress several alarms, then change the main summary filter.
6. Restart a redundant server or the alarm service while alarms are active.
7. Open the summary on the slowest workstation on site during a flood.

Keep screenshots or a short screen recording. The evidence should show the default sort, visible count, hidden count, state indication, and acknowledgement behaviour.

Results converge on a short list of failures.

Failure	What it looks like	Fix direction
Chatter owns the top	Newest-first keeps pushing nuisance alarms up	Change the sort and fix the chattering source
Active alarms hidden	Filtered view with no hidden count	Put the hidden active count in the header
Cleared alarms vanish instantly	Operator never sees the transient	Keep returned-but-unacknowledged until acknowledged
Row changes under the cursor	Resort fires on acknowledgement	Delay the resort
Shelved alarms forgotten	Gone entirely from the main summary	Show the count and a review link
Event journal used as live summary	Thousands of rows, mixed states	Split the two screens

What goes in the project file

Default sort order, default filters, state indication definitions, hidden count behaviour, acknowledgement and mass acknowledgement rules, shelving/suppression/out-of-service visibility, and the flood test result. One page covers it.

With that page you can separate "the HMI hid the alarm" from "the operator was looking at a configured filtered view" during an incident review. Those are different problems with different fixes. Without it, both get blamed on the HMI.