Configuring Alarms

Alarms are configured on a tag. First enable alarming for the tag, then add one or more alarm definitions to it.

Enable alarming on the tag

The tag's Alarm enabled flag is the master switch: the engine only evaluates a tag's alarms when it is on.

Reading the flag needs View alarms; changing it needs Manage alarms.

Turning it off silences every alarm on that tag at once — useful during commissioning, and visible as a configuration change rather than as a suppression.

Alarm modes

Mode	Active when
above	value >= setpoint
below	value <= setpoint
equal	value == setpoint (± deadband)
not_equal	value != setpoint (± deadband)
between	setpoint <= value <= setpoint_high
outside	value < setpoint or value > setpoint_high
on_boolean	value == bool_target
bad_quality	The tag's quality is not Good

bad_quality deserves special mention: it is how you alarm on the instrument rather than on the process. A temperature that reads 20 °C because the sensor is dead looks normal to an above alarm.

Configuration fields

Field	Meaning
Name	Unique per tag — Hi, HiHi, Fault. Appears in the annunciator and journal.
Mode	One of the above.
Setpoint	Primary threshold, or the range low.
Setpoint high	Range high, for between / outside.
Bool target	The value that raises an on_boolean alarm.
Priority	low · medium · high · critical.
Message	Operator-facing text. Write what to do.
Deadband	Hysteresis — see below.
On delay (s)	The condition must hold this long before raising. Entered in seconds, stored in milliseconds.
Off delay (s)	It must clear this long before returning to normal.
Require ack	The alarm must be acknowledged, not just cleared.
Latch	Stays active until acknowledged, even after the condition clears. Requires Require ack.
Eval on bad quality	Evaluate numeric/boolean modes even when quality is bad.
Enabled	Per-definition enable, independent of the tag's master switch.

An alarm definition also has a deadband mode — absolute (engineering units) or percent (of a span, eng low to eng high) — that the form does not show. Those three can be set only through a bulk import document.

Deadband — stopping chatter

A value sitting exactly on a setpoint will raise and clear repeatedly, producing dozens of journal entries a minute and training the operator to ignore the banner.

Deadband creates hysteresis: the alarm raises at the setpoint and does not clear until the value has moved back past the setpoint by the deadband.

Setpoint 80 °C, deadband 2 °C, mode above

  raises  at  80.0
  clears  at  78.0        (not at 79.9)

Mode	Deadband is
absolute	A value in engineering units
percent	A percentage of eng_high - eng_low, resolved once when the runtime is built

Percentage deadbands are the right default in a UDT: one definition covers instruments with different ranges.

Check the deadband of an alarm made on the form

An alarm added on a tag's Alarms tab, or on a UDT member's, is created in percent mode with an eng low and eng high of 0, and the form offers no way to change either. A percentage of a zero span is zero, so the Deadband typed into the form does not take effect on such an alarm. Set the deadband mode and span in a bulk import document instead.

Rule of thumb: 1–2% of span. Start there and only tighten if it demonstrably hides something.

Delays — ignoring transients

Delay	Effect
On delay	The condition must hold continuously for this long before the alarm raises
Off delay	It must be clear continuously for this long before returning to normal

On delay filters momentary spikes — a motor's inrush current, a pressure transient on a valve stroke, a communication blip. Off delay stops an alarm from clearing during a brief dip on its way back down.

Motor overcurrent
  mode      above
  setpoint  15 A
  on delay  3 s          ignores start-up inrush
  off delay 1 s          does not clear on a momentary dip

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

Latching

A latched alarm stays active once raised until an operator acknowledges — even if the condition has cleared.

Use it where the occurrence matters more than the duration: a safety trip, a brief overpressure, a momentary interlock. Without latching, a 200 ms fault is annunciated and gone before anyone looks.

Latching requires Require ack — a latch nobody has to clear is a latch that stays on forever.

Quality handling

By default, a numeric or boolean alarm does not evaluate while the tag's quality is bad — you should not raise a process alarm from a value you do not trust.

Setting	Behaviour
Eval on bad quality off (default)	The alarm does not evaluate; the value is not trusted
Eval on bad quality on	The alarm evaluates regardless

The complementary move is a separate bad_quality alarm on the same tag, so a failed instrument raises an instrument alarm rather than being silent or raising a misleading process alarm.

Tank1/Level
  alarm "HiHi"       above 95 %,    critical
  alarm "Hi"         above 85 %,    high
  alarm "SensorFault" bad_quality,  high, "Level transmitter fault — check LT-101"

Worked examples

Multi-level analogue

Reactor/Temperature   (eng 0–200 °C, deadband mode percent)

  LoLo   below  20   critical  deadband 1%  on-delay 2000
  Lo     below  40   high      deadband 1%  on-delay 2000
  Hi     above 160   high      deadband 1%  on-delay 2000
  HiHi   above 180   critical  deadband 1%  on-delay 1000  latch  require-ack

Digital fault

Motor1/Fault
  mode        on_boolean   target true
  priority    high
  latch       yes          require-ack yes
  message     "Motor 1 faulted — reset at the local panel before restarting"
  on delay    0

Range alarm

Line1/pH
  mode           outside
  setpoint       6.5      setpoint_high 7.5
  priority       medium
  deadband       0.1      absolute
  on delay       5000

Alarms in UDTs

Define alarms on UDT members and every instance is alarmed identically. A percentage deadband and a parameterised message ("Motor {Device} overcurrent") make one definition fit the whole plant.

An instance that genuinely needs different setpoints uses an override, which is recorded and revertible — not a silent divergence.

Permissions

Reading alarm definitions needs View alarms. Creating, editing and deleting them — and changing alarm storage settings — needs Manage alarms.

Rationalisation checklist

For every alarm:

• An operator does something specific in response
• The priority reflects the real consequence, not the loudest stakeholder
• The message says what to do, not just what happened
• Deadband and on-delay are set for analogue values
• Latch is on where the occurrence matters more than the duration
• A bad_quality alarm covers instrument failure
• The expected alarm rate keeps the operator's load manageable

Next

→ Operating alarms