Alarms

The Alarms configuration page defines the alarm conditions monitored by the runtime. Each alarm evaluates a Condition expression continuously. When the condition evaluates to true, the alarm becomes active and is displayed in the Alarm Viewer and in any Alarm Banner objects on runtime pages.

Alarms support severity levels, asset grouping, user group restrictions, an On Delay and an Off Delay against short or chattering conditions, suppression by design through Parent Alarms or a Suppress When expression, and automated actions that execute when the alarm activates.

Operators can acknowledge active alarms, shelve alarms for a limited time and review historic alarm records in the Alarm Viewer.

Alarm Settings

Each Alarms row represents one alarm definition.

Create a new alarm with the Add button in the toolbar. The Add dialog contains all alarm settings with default values already filled in. Enter at least the Condition and press Create. The ... button next to the Condition field opens the Condition editor, and the ... button next to the Actions field opens the Edit Actions dialog.

The alarm row shows Enable, Condition, Severity, Asset, Alarm Groups, and Message directly and these values can be edited in place. Press the Settings icon on an alarm row to open the Alarm Settings dialog, which contains all settings of the alarm, including the Actions field. The Timing section of the dialog holds the On Delay (s) and Off Delay (s) settings. The Suppression section of the dialog holds the Parent Alarms, Suppress When and Release Delay (s) settings and, in the Alarm Settings dialog, the Child Alarms list. Press Save to apply the changes.

Severity Levels

Severity controls visual prioritization in the Alarm Viewer and Alarm Banner. The following levels are supported, in increasing priority order: Low, Medium, High, Critical.

Message Tokens

The Message field supports variable tokens that are resolved to their live values at the moment the alarm activates. A token is written as {VariableName}, using the full variable name. If the token matches a variable in the project, it is replaced with that variable's current value, shown with the Format of the variable when the variable has one. If no matching variable is found, the token is left as-is in the displayed message.

Tokens may reference nested names and support alphanumeric characters, underscores, hyphens, brackets, and the hash sign in each segment.

Action Tokens

Action strings support a set of fixed tokens that refer to alarm metadata, as well as variable tokens in {VariableName} format using the full variable name. Fixed tokens are resolved first, then variable tokens are substituted.

Actions

Alarm actions execute once when the alarm transitions from inactive to active. They do not fire again while the alarm remains active.

Press Add Action in the Edit Actions dialog to add an action. Each action has a type and input fields for that type. Actions execute in the order shown and can be moved up and down or deleted. Press Save to apply the action list.

On Delay and Off Delay

On Delay (s) and Off Delay (s) in the Timing section of the Alarm Settings dialog filter short changes of the Condition (time delays, ISA-18.2). On Delay prevents an alarm from a Condition that is true for only a moment, for example a contact that bounces or a value that briefly crosses its limit. Off Delay prevents a series of repeated alarms from a Condition that changes back and forth around its limit (a chattering alarm).

On Delay (s) is the number of seconds the Condition must be true without interruption before the alarm becomes active. When the Condition becomes false within this time, no alarm is raised: the alarm does not appear in Active Alarms or the Alarm Banner, no historic alarm record is written and no actions are executed. The On Time of the alarm is the moment the delay ended. 0 raises the alarm immediately.

Off Delay (s) is the number of seconds the Condition must be false without interruption before an active alarm returns to normal. When the Condition becomes true again within this time, the alarm stays active as the same occurrence, with its original On Time and acknowledgement state, and no new alarm is raised. The Off Time of the alarm is the moment the delay ended. 0 returns the alarm to normal immediately.

Example with On Delay (s) 3 and Off Delay (s) 0:

The alarm engine checks a running delay every 0.5 seconds, so an alarm becomes active or returns to normal up to 0.5 seconds after its delay ended. The On Time and Off Time record the end of the delay.

A running delay restarts in these cases: the Condition of the alarm is changed, the alarm is disabled, a variable in the Condition has no Good or Warning status (see Notes), the application restarts, or the standby server takes over. Changing other settings of the alarm, such as the Message or the delays themselves, keeps a running delay, and the new delay values apply to it.

On Delay decides when the alarm becomes active. Suppression and shelving apply to the alarm once it is active, and Release Delay (s) is a separate delay that applies when a suppression cause clears.

Through the configuration API and MCP, the Alarms entity carries these settings as onDelaySeconds and offDelaySeconds, whole seconds from 0 to 3600. On a UDT alarm member, On Delay (s) and Off Delay (s) are set in the Timing group of the member's detail drawer, as a number or a parameter token such as {OnDelay}. An empty field is 0. The definition owns both settings, so every push writes them to the materialized alarms.

Suppression

The Suppression section of the Alarm Settings dialog silences an alarm by design while its cause is known (alarm cascading and state-based suppression, ISA-18.2). A suppressed alarm is evaluated and logged as usual, but it is not annunciated: it is absent from Active Alarms, from the Alarm Banner and from the alarm counters, and it is listed in the Suppressed Alarms view of the Alarm Viewer with the kind Parent alarm or Condition and its cause. Alarm actions still execute when a suppressed alarm goes active. Alarm shelving, the operator-side counterpart with a limited duration, is described in the Alarm Viewer article.

Parent Alarms folds this alarm under one or more other alarms. While any of its parent alarms is active, this alarm is suppressed, and the parent row in Active Alarms shows an N suppressed button that unfolds the suppressed alarms in place. With several parents active, the alarm is folded under the parent that went active first, which is the likely root cause; between parents with the same On Time, the order of the Parent Alarms list decides. A parent that goes active later leaves the alarm where it is. When the parent it is folded under returns to normal while another parent is still active, the alarm stays suppressed and moves under that parent. An alarm that goes active while a parent is active is suppressed at once. An alarm that was already active shortly before its parent, within the Cascade Window (s) setting on the Parameters page, is folded in as well because it is a consequence detected before its cause; an alarm that went active earlier than that stays annunciated. A parent alarm may itself have parents, so a whole tree of consequences folds under the top cause. An alarm cannot be its own parent, and a loop is refused on Save. Deleting an alarm removes it from the Parent Alarms of its child alarms; their other parents remain.

Suppress When is an expression in the Condition syntax, for example Pump1_Mode == 0 to silence a pump alarm while the pump is switched off. While the expression is true, the alarm is suppressed. An empty field never suppresses.

Suppress When can also follow the alarm counters that the alarm engine publishes per asset, alarm group and UDT instance, for example SYSTEM.AlarmCount_Severity1_WTP/Intake > 0 to suppress an alarm while a Critical alarm with Asset WTP/Intake is annunciated. A counter covers the alarms with exactly that Asset, so a condition for a node and the nodes below it adds their counters, for example SYSTEM.AlarmCount_Severity1_WTP + SYSTEM.AlarmCount_Severity1_WTP/Intake > 0. A counter exists once an alarm with that severity and that Asset, alarm group or UDT instance has been loaded; the Navigator article lists the counter variables. Shelved and suppressed alarms are not counted, so Save refuses a Suppress When that reads a counter the alarm itself is part of: the counter of its own severity for its own Asset, alarm group or UDT instance, the SYSTEM.TotalAlarms totals and SYSTEM.TotalSuppressedAlarms. Such a counter drops as soon as the alarm is suppressed, which would release the alarm again. Use the counter of another severity or another node instead.

Release Delay (s) applies when the cause clears, that is once no parent alarm is active and Suppress When is false. The alarm then waits the entered number of seconds. When a cause returns within the delay, the alarm stays suppressed. When the delay has passed and the alarm is still active, it appears in Active Alarms unacknowledged with its real On Time; when it returned to normal in the meantime, it is closed without an acknowledgement. The Suppressed Alarms view shows releasing at with the end of a running delay. 0 annunciates immediately.

Through the configuration API and MCP, the Alarms entity carries these settings as parentAlarmIds, suppressWhen and releaseDelaySeconds. parentAlarmIds holds the Ids of the parent alarms as a comma-separated list in list order, for example 12,15; an empty value removes all parents. On create and update, parentAlarmConditions names the parent alarms by their Condition instead, one Condition per line: it is used when parentAlarmIds is empty, it is resolved to the Ids on Save, and a read returns it empty. A Git export stores the parent alarms by Condition, so an import links them to the Ids of the alarms in the target project. Export and Import on the Alarms page work the same way: the CSV or JSON file carries the parent alarms by Condition, and Import links them to the Ids of the alarms in the target project, also when a parent alarm is created by the same file. Import refuses the whole file when a parent Condition does not exist, when an alarm names itself as parent, or when the parent alarms form a loop. A file that names the parent alarms by Id is accepted when those Ids exist in the project. On a UDT alarm member, Suppress When, Release Delay (s) and Parent Alarms are set in the Suppression group of the member's detail drawer; they are tokenized like Condition, so every materialized alarm receives them from the definition. A member names its parent alarms by condition and the push links them per instance, the alarms of the same instance first. When a member leaves Parent Alarms empty, the parent alarms of its materialized alarms are set on this page.

Notes

The Condition field supports any expression that evaluates to a boolean result. Use standard comparison operators (==, !=, >, <, >=, <=) with variables referenced by their full variable name, for example Pump1_Speed > 1480.

Actions are executed once when the alarm transitions from inactive to active. They do not fire again while the alarm remains active.

The Alarm Groups field restricts which user groups can view and acknowledge this alarm. Users not in the listed groups will not see the alarm in the Alarm Viewer or Alarm Banner.

The Suppression settings suppress an alarm by design. Shelving, the operator action that silences an alarm for a limited time with a reason, is done in the Alarm Viewer and requires the Alarm Shelve Right.

A variable name that contains a slash, such as the counter of a nested asset node, is read as one name in Condition and Suppress When when a variable with that name exists. Otherwise the slash divides, so Tank1_Level/2 > 40 compares half the level.

A condition is evaluated only while every variable it references has the Good or Warning status. While a referenced variable is Unknown, ConnectionLost, FormatError, Timeout or Disabled, the alarm is suspended: it keeps its current state, active or inactive, and no actions run. A running On Delay or Off Delay stops and starts again with the first Good or Warning value. The System Log Viewer reports the suspension once per variable and reports it again when the variable delivers a value. Suppress When follows the same rule: while a variable it references has no Good or Warning status, it keeps its last result, so the outage neither suppresses nor releases the alarm. Build a communication alarm on the Channel State variable of the device to be notified of the outage itself. See the Variable Status article.