Alarms

QUBIQ implements tag alarming to ISA-18.2 / IEC-62682: the standard that exists because badly designed alarm systems have caused industrial accidents.

An alarm is attached to a tag. One tag can carry many alarms — Hi, HiHi, Lo, LoLo, Fault — each with its own condition, priority and message.

The lifecycle

An alarm that cleared on its own still waits for a human — that is the Cleared state.

State	Meaning
NORM	Condition not met, nothing outstanding
UNACK	Condition met, awaiting acknowledgement
ACK	Condition still met, operator has acknowledged
RTNUN	Condition cleared, but was never acknowledged

RTNUN is the state that matters most and the one operators find least intuitive. A transient excursion that self-corrected still has to be seen — otherwise a repeating fault disappears before anyone notices it happened.

Priorities

Priority	Use for
critical	Safety, environmental release, production stop
high	Requires prompt operator action
medium	Requires action this shift
low	Informational; action when convenient

Reserve critical. An alarm system where everything is critical is an alarm system operators learn to ignore, which is precisely the failure mode ISA-18.2 exists to prevent.

Events

Every transition is journalled:

Event	Meaning
raised	The alarm annunciated
ack	An operator acknowledged
rtn	The condition returned to normal
clear	The cycle fully closed (→ NORM)
shelve	Temporarily shelved by an operator
suppress	Suppressed indefinitely by design or logic
oos	Taken out of service for maintenance
restore	Suppression released, back in service

Suppression: three distinct kinds

Being able to silence an alarm is necessary. Being unable to tell why it is silent is dangerous — so QUBIQ records the reason as part of the state.

Kind	Duration	Who	Use for
Shelve	Temporary, auto-released on expiry	Operator	A known nuisance during a shift
Suppress by design	Indefinite	Engineering	An alarm that is meaningless in the current mode
Out of service	Indefinite	Maintenance	Equipment deliberately down

A shelved alarm returns on its own. That is the whole point: it cannot be forgotten.

→ Operating alarms

Where alarms appear

Surface	Component
Annunciator	Alarm Bell
Active list, and per-tag indicator	Alarm Event
History	Alarm Journal
Metrics / KPIs	Alarm Performance
Pipelines	The Alarm node, subscribing to lifecycle events

The alarm widgets read the alarm system directly — no binding required — and respect the viewer's alarm permissions.

Notification

To send alarms somewhere — email, SMS, a webhook, a paging system — use a pipeline:

Alarm node (raised, priority: critical)
  → Python (format the message)
  → REST API (egress → your notification service)

The Alarm node filters by event type, priority and tag, and can attach the tag's static metadata to each event.

→ Pipeline nodes

Permissions

Action	Permission
See active alarms and the journal	View alarms
Acknowledge, shelve, suppress, restore	Acknowledge alarms
Create/edit/delete alarm definitions and storage settings	Manage alarms

Acknowledgement is deliberately separate from configuration: an operator acknowledges; an engineer defines.

Design principles

Before adding an alarm, answer four questions:

1. Is it actionable? If nobody does anything differently, it is an event, not an alarm.
2. What is the priority, honestly? Everything critical means nothing is.
3. What delay and deadband? Nearly every chattering alarm is a missing on-delay or deadband.
4. What does the message tell the operator to do? Put the response in the message text.

A well-rationalised plant produces a handful of alarms per operator per hour. A poorly rationalised one produces hundreds — and the operator stops reading them long before the one that mattered.

In this section

Page	Contents
Configuring alarms	Modes, setpoints, deadband, delays, latching
Operating alarms	Acknowledging, shelving, the journal, metrics