Alarm Management

The alarm system detects abnormal values, records them, and reports them to the operator.

It works in two layers: an alarm group sets the behaviour shared by everything inside it — scan period, priority, colours, the scripts to run, printer settings — while the alarm definitions in that group describe the individual conditions. Each group belongs to a project.

Where it is managed

Screen	What it does
Alarm Groups	Defines the group and the behaviour shared across it
Analog Alarms	Threshold alarms on numeric variables
Digital Alarms	State alarms on boolean variables
Custom Alarms	Conditions written as an expression

Alarms that have fired are followed at runtime: the Alarm Monitor shows the current state, Alarm History the past records.

Alarm Types

Every alarm definition is one of three types:

Type	Watches	Fires when
Analog	A numeric variable	The value crosses a threshold (High-High / High / Low / Low-Low)
Digital	One or two boolean variables	The evaluated result becomes true (AND/OR and inversion supported)
Custom	Anything	The expression you write returns a truthy value

Common Fields

All three types carry these; the type-specific fields are covered on their own pages.

Field	Type	Description
name	String (≤100)	Alarm name — unique within the project
dsc	String (≤255)	Description
groupId	String	The alarm group it belongs to
delay	Integer (ms, ≥0)	How long the condition must hold before firing (debounce)
isActive	Boolean	Whether this definition is active
part	String (≤100)	Equipment / line code — used in reporting and filtering
onTimeVariableId	String	Variable the firing time is taken from (optional)
offTimeVariableId	String	Variable the clearing time is taken from (optional)

Taking the timestamp from the field

onTimeVariableId and offTimeVariableId decide where the alarm’s timestamp comes from. Left empty, the alarm is stamped with the moment the system noticed the condition.

Given a variable, the system reads that variable’s last value as epoch milliseconds and uses it as the alarm’s time. The stamp then reflects what the field reported rather than what the SCADA observed.

The reason is the scan period: if the alarm group evaluates once a second, the moment the system sees can be up to a second later than the event itself. A PLC that stamps the event with its own clock is far more precise. Where the order of a fault matters — which protection tripped first, which signal arrived first — that difference decides the answer.

The one-hour limit

A value more than an hour away from the time the system observed is ignored, a warning is written to the log, and the alarm is recorded with its own observed time.

The check keeps a device with an unset clock, or a stamp field scaled wrongly, from corrupting the alarm history. If a field timestamp is being ignored unexpectedly, look first at the device’s clock and at the unit of the value — it must be milliseconds, not seconds.

Lifecycle

An alarm’s actual state has two values:

ON (fired)  →  OFF (cleared)

Acknowledging, commenting and forcing off are not part of that state — they are operator records kept in separate fields:

Field / action	Description
acknowledgeTime / acknowledgedBy	Filled when an operator acknowledges; the alarm may still be ON
commentTime / comment / commentedBy	Filled when an operator adds a comment
forceOff action	Pulls the alarm to OFF even though the condition still holds
offTime	Filled when the condition clears on its own

The distinction shows in the colours: an alarm that is “ON and unacknowledged” is displayed differently from one that is “ON and acknowledged”. The colour mapping is defined on the group → Alarm Groups.

Managing alarms from a script

Alarms can also be queried and managed from a script — listing, querying by date range, acknowledging, commenting, enabling a group. Method inventory and examples: Alarm API →