Tutorial: Alarm on a Tag

Configure alarms that operators will actually act on: a multi-level analogue set, a latched digital fault, and a notification path for critical alarms.

You will need: tags with live data. Time: ~25 minutes.

---

Step 1 — Decide what deserves an alarm

Before touching the interface, answer four questions for each candidate:

1. Is it actionable? If nobody does anything differently, it is an event, not an alarm.
2. What priority, honestly? Reserve critical for safety and production-stopping conditions.
3. What delay and deadband? Nearly every chattering alarm is a missing one of these.
4. What does the message tell the operator to do?

An alarm that fails question 1 makes every other alarm slightly less effective. This step is the work; the configuration is data entry.

---

Step 2 — Enable alarming on the tag

Select the tag, open the Alarms tab, and enable alarming. This is the per-tag master switch — definitions are not evaluated until it is on.

---

Step 3 — Build a multi-level analogue set

For Reactor/Temperature, engineering range 0–200 °C:

Name	Mode	Setpoint	Priority	Deadband	On delay	Latch
LoLo	below	20	critical	1%	2000 ms	no
Lo	below	40	high	1%	2000 ms	no
Hi	above	160	high	1%	2000 ms	no
HiHi	above	180	critical	1%	1000 ms	yes

Set deadband mode to percent and fill in eng low/high so the percentage resolves. In a UDT this means one definition works across instruments with different ranges.

Messages should tell the operator what to do:

HiHi:  "Reactor temperature critical — reduce feed rate and check cooling water"
Hi:    "Reactor temperature high — verify cooling water flow"

Not "Temperature > 180". The operator can see the number.

---

Step 4 — Add a digital fault alarm

For Motor1/Fault:

Field	Value
Mode	on_boolean
Bool target	true
Priority	high
Latch	yes
Require ack	yes
Message	"Motor 1 faulted — reset at the local panel before restarting"

Latching matters here. A fault that self-clears in 200 ms is annunciated and gone before anyone looks. Latched, it stays until someone acknowledges it — which is the point of recording that it happened.

---

Step 5 — Alarm on the instrument, not just the process

A temperature reading 20 °C because the sensor is dead looks perfectly normal to an above alarm.

Add a bad_quality alarm on the same tag:

Field	Value
Name	SensorFault
Mode	bad_quality
Priority	high
Message	"Reactor temperature transmitter fault — check TT-101"

By default, numeric alarms do not evaluate while quality is bad — you should not raise a process alarm from a value you do not trust. This alarm covers the gap that leaves.

---

Step 6 — Tune out chatter

Run it for a shift, then look at the journal.

Symptom	Fix
Raises and clears repeatedly around the setpoint	Increase deadband
Raises on brief spikes that self-correct	Increase on delay
Clears during a momentary dip on the way down	Increase off delay
Many alarms from one physical event	Alarm the cause, suppress-by-design the consequences

Deadband and delay solve different problems — noise around a threshold versus short excursions. Chattering alarms usually need both.

---

Step 7 — Route critical alarms to a notification service

Build a pipeline:

Alarm node → Python → REST API (egress)

Alarm node

Setting	Value
Operation	subscribe
Events	raised
Priorities	critical
Include tag meta	on

Python node

def transform(payload, message):
    return {
        "text": f"[{payload['priority'].upper()}] {payload['tag_path']}: {payload['message']}",
        "value": payload.get("value"),
        "ts": payload.get("timestamp"),
    }

REST API node (egress) posting to your webhook.

Because the pipeline's egress calls are covered by store-and-forward, a notification service that is briefly down does not lose the alert.

→ Alarm node

---

Step 8 — Put alarms on the screen

Component	Purpose
Alarm Bell	Annunciator with an unacknowledged count
Alarm Event	The live active-alarm list
Alarm Performance	ISA-18.2 metrics and bad actors
Alarm Journal	History, for handover and investigation

---

Step 9 — Review after a week

Open the alarm metrics and look at:

Metric	Healthy
Average rate	~1–2 per operator per 10 minutes
Bad actors	Few, and shrinking
Priority distribution	Roughly 5/15/80 critical/high/rest
Standing alarms	Few

The bad-actor list is the highest-value screen in the alarm system. In most plants ten alarms produce most of the volume, and each is usually one missing deadband or on-delay away from silence.

→ Alarm metrics

---

Checklist

• Every alarm is actionable
• Priorities are meaningful, critical is rare
• Messages say what to do
• Deadbands and delays are set on analogue alarms
• Latching is on where the occurrence matters more than the duration
• A bad_quality alarm covers instrument failure
• Critical alarms reach someone outside the control room
• The rate is one an operator can actually absorb

Next

→ Log data to SQL · Operating alarms