Operating Alarms
This page is for the people who use the alarm system: acknowledging, managing nuisance alarms and reading the record afterwards.
Acknowledging
Acknowledgement means "I have seen this and I am dealing with it." It does not clear the condition.
Acknowledging — one alarm or a selection — requires Acknowledge alarms.
What happens depends on the current state:
| From | Acknowledging moves it to |
|---|---|
UNACK (condition still active) | ACK — stays in the active list |
RTNUN (condition already cleared) | NORM — leaves the active list |
Every acknowledgement is journalled with who and when.
If operators routinely acknowledge everything at once, the alarm system is generating more than they can read. That is a rationalisation problem, not an operator problem — see metrics.
Suppression
Three kinds, deliberately distinct, so the reason an alarm is silent is always recorded.
| Kind | Duration | Released by | Use for |
|---|---|---|---|
| Shelve | Timed | Expiry, automatically | A known nuisance during this shift |
| Suppress by design | Indefinite | An operator restoring it | An alarm meaningless in the current mode |
| Out of service | Indefinite | An operator restoring it | Equipment deliberately down for maintenance |
Shelving, suppressing, taking out of service and restoring all require Acknowledge alarms.
Which to use
Shelve when the alarm is real but you cannot act on it right now. It comes back on its own, which is exactly why it is the safe default — a shelved alarm cannot be forgotten.
Suppress by design when the alarm genuinely does not apply: a low-flow alarm on a line that is deliberately idle. This is an engineering decision and should be reviewed.
Out of service when the equipment is down for maintenance. It says "this is expected", not "this is noise", to the next shift.
An alarm suppressed indefinitely is an alarm nobody will look at again. Track suppressed alarms as open work, review them at shift handover, and treat a long-suppressed alarm as a configuration defect.
The active list
The Alarm Event widget, or the alarm screen (needs View alarms).
Shows every alarm currently in UNACK, ACK or RTNUN, with priority, tag, message, timestamps
and suppression state. Suppressed alarms are marked, not hidden — you can always see what is
silent.
Sort by priority then by time. The oldest unacknowledged critical alarm is usually the one that matters.
The journal
The Alarm Journal widget, or the alarm screen's history tab (needs View alarms).
Every lifecycle event, permanently:
| Field | Meaning |
|---|---|
| Timestamp | When it happened |
| Tag path / alarm name | What |
| Event | raised, ack, rtn, clear, shelve, suppress, oos, restore |
| Priority | Severity at the time |
| Value | The value that triggered it |
| Actor | Who acknowledged, shelved or restored |
| Message | The operator-facing text |
The journal answers the questions that come up after an incident: what happened, in what order, who saw it, and how long it took to be acknowledged.
Alarm metrics
The Alarm Performance widget (needs View alarms).
The ISA-18.2 performance indicators:
| Metric | Healthy target | What it tells you |
|---|---|---|
| Average alarm rate | ~1–2 per operator per 10 min | Whether the load is manageable |
| Peak rate | Bounded | Whether floods occur |
| Alarm flood periods | Rare | A single event annunciating dozens of alarms |
| Bad actors (top by count) | Few, and shrinking | The 10 alarms causing most of the load |
| Priority distribution | Roughly 5/15/80 critical/high/rest | Whether priorities are meaningful |
| Standing alarms | Few | Alarms active for hours or days |
The bad-actor list is the highest-value screen in the whole alarm system. In most plants, ten alarms produce most of the volume — and each is usually one missing deadband or on-delay away from being quiet.
Alarm floods
When one physical event annunciates dozens of alarms, operators cannot triage.
| Cause | Remedy |
|---|---|
| Communication loss to a PLC | One bad_quality alarm on the connection instead of one per tag |
| A trip cascading through interlocks | Suppress-by-design on the downstream consequences |
| A shared root cause | Alarm the cause, not each symptom |
| Start-up and shutdown transitions | Mode-based suppression during the transition |
The measure of a good alarm system is not how much it detects — it is how well an operator can act during the worst ten minutes of the year.
Shift handover
A workable handover screen:
- Active unacknowledged — highest priority first
- Suppressed and out of service — with who and when
- Shelved, with expiry times — what is coming back and when
- Bad actors this shift — what has been noisy
- Standing alarms — anything active longer than a shift
Runtime access
LiveView operators see alarms through the alarm widgets, subject to the project's access policy and their runtime roles — the same active list, journal and metrics an engineer sees in the Platform.
Acknowledgement from LiveView is attributed to the runtime user, and appears in the journal under their identity.