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

Enable alarming for this tag, at the top of the tag's Alarms tab, is the master switch: the engine only evaluates a tag's alarms when it is on, and alarms can be added only once it is.

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

The Condition picker on the alarm form offers these modes:

Condition (mode)	Active when
Above setpoint (above)	value >= setpoint
Below setpoint (below)	value <= setpoint
Equal to (equal)	value == setpoint (± deadband)
Not equal to (not_equal)	value != setpoint (± deadband)
Inside range (between)	setpoint <= value <= setpoint_high
Outside range (outside)	value < setpoint or value > setpoint_high
Boolean state (on_boolean)	value == bool_target
Bad quality (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 on the form	Meaning
Name	Unique per tag — Hi, HiHi, Fault. Appears in the annunciator and journal.
Condition	One of the modes above.
Priority	Low · Medium · High · Critical.
Setpoint / Range low	Primary threshold, or the low end of a range.
Range high	High end, for Inside range / Outside range.
Active when value is TRUE	For Boolean state: on raises the alarm on true, off on false.
Deadband	Hysteresis — see below.
On-delay (s)	The condition must hold this long before raising. Stored in milliseconds.
Off-delay (s)	It must clear this long before returning to normal.
Message (optional)	Operator-facing text. Write what to do.
Requires acknowledgement	The alarm must be acknowledged, not just cleared. On by default.
Latch (stays in alarm until acknowledged)	Stays active until acknowledged, even after the condition clears. Requires acknowledgement.
Evaluate 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. Until the form exposes the mode, set the deadband mode and span in a bulk import document.

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 Requires acknowledgement — 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
Evaluate on bad quality off (default)	The alarm does not evaluate; the value is not trusted
Evaluate 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.

Changed in 1.0.8 Instances now get exactly the alarm the type defines. A type alarm with Enabled or Requires acknowledgement switched off used to arrive on its instances switched on, and a sync never carried a change to the alarm's deadband, deadband mode, span or Evaluate on bad quality to instances that already existed. Both are fixed; re-sync a type to bring older instances in line. → Alarms in a type

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