Appearance
Alarms and Alarm Rules
Last updated
An alarm rule watches one tag and raises an alarm when the tag's value meets a condition — for example spindle temperature greater than 60, or tank level outside 10–90. Scada.Ink records every alarm in the alarm history, shows active alarms to operators, and (with Alarm Pipelines licensed) can send email, SMS, voice calls and webhooks when an alarm fires.
This article covers the page layout and alarm rules. The rest of the alarm topic is split up:
- Alarm states, acknowledging and shelving — what happens after an alarm fires
- Alarm pipelines — notification and escalation steps
- Email, SMS and voice delivery — SMTP and the Scada.Ink Cloud relay
- Notification settings and on-call schedules — the master switch, quiet hours, acknowledgement comments, SMS reply acknowledgement and who is on call
- Alarm history and CSV export
- ISA 18.2 alarm metrics
- Alarm troubleshooting
The Alarms page
Open Alarms in the sidebar (/alarms). The page is titled Alarms — "Alarm rules, active alarms, and alarm history" — and has these tabs, in this order:
| Tab | What it shows | Needs |
|---|---|---|
| Active Alarms | Alarms that are currently active, with filters, a live Duration column, Acknowledge (one or many) and Shelve (the default tab) | — |
| Alarm Rules | Every rule, with edit, enable/disable and delete, and each device's offline threshold | — |
| Pipelines | Notification pipelines and the recent pipeline activity log | Alarm Pipelines license feature |
| History | Every alarm occurrence, searchable, with Export CSV | — |
| ISA 18.2 Metrics | Alarm-system performance (rate, floods, chattering, bad actors) | ISA 18.2 Alarm Metrics license feature |
| Notifications | Notification settings, on-call schedules, the SMS delivery log and received replies | — (changing settings needs an admin; schedules an editor) |
Create an alarm rule
Before you start, the tag must be subscribed on its device (see Tags). The rule form only lists a device's subscribed tags, so a tag you have not subscribed to cannot be alarmed. Expression tags are listed under the device Expression Tags at the end of the device list.
- Go to Alarms → Alarm Rules.
- Click New Rule. The Create Alarm Rule form opens above the list.
- Enter a Name, pick the Device, then the Tag.
- Choose a Condition and enter the Threshold (one value, or Low and High for a range).
- Pick a Severity, and optionally a Message.
- Set Debounce (ms), and optionally On-delay (s), Off-delay (s) and Deadband — see "Timing: on-delay, off-delay, deadband and debounce" below.
- Optionally fill in Notify — email addresses, a user group and/or an on-call schedule to tell as soon as the alarm activates.
- Click Create Rule. The button is disabled until Name, Tag and a usable threshold are set.
The rule is enabled as soon as it is saved and is evaluated from the next tag change. Notify sends one message when the alarm activates; for delays, escalation, SMS steps or webhooks, attach the rule to a pipeline from the Pipelines tab (see Alarm pipelines).
Rule fields
| Field | What it does | Default | Allowed values / notes |
|---|---|---|---|
| Name (required) | The rule name shown in lists, history and notifications | empty | Any text. Placeholder "e.g. High Temperature" |
| Device (required) | Narrows the tag list to one device | none | Any configured device. Not stored — the rule stores the tag |
| Tag (required) | The tag the rule watches | none | The chosen device's subscribed tags, by display name. Disabled until a device is chosen |
| Condition (required) | How the value is compared with the threshold | Greater than | See the conditions table |
| Threshold (required) | The limit | empty | A number. Low and High for range conditions, with Low no greater than High. Create Rule stays disabled until the threshold is filled in |
| Severity | Priority of the alarm | Warning | Info, Warning, Critical |
| Message (optional) | Text shown on the active alarm and in notifications | empty | Blank gives <name>: value <n> triggered <condition> condition, e.g. High Temperature: value 63.2 triggered gt condition |
| Debounce (ms) | Minimum time between two firings of this rule | 5000 | Milliseconds. See below — it is not an on-delay |
| On-delay (s) | The condition must hold this long before the alarm activates | 0 (at once) | 0 to 86400 seconds; decimals allowed |
| Off-delay (s) | The condition must stay clear this long before the alarm clears | 0 (at once) | 0 to 86400 seconds |
| Deadband | Once active, the value must come back past the limit by this much before it counts as clear | 0 (none) | A number of 0 or more, in the tag's units (the rate's units for Rate of change) |
| Notify: Email addresses | Emailed when the alarm activates | empty | Comma-separated addresses |
| Notify: User group | Its active members are emailed (and texted, with the SMS box) | None | Any notification group |
| Notify: On-call schedule | Whoever is on call is emailed (and texted, with the SMS box) | None | Any on-call schedule |
| Also text the group and on-call person | Sends an SMS to the group's and on-call person's mobile numbers too | off | Needs SMS & Voice Alerts. Typed email addresses are never texted |
For Rate of change, the form also shows Rate (per second or per minute, and Rising or falling, Rising only or Falling only) and Measured over (seconds) (default 60, 1 to 86400).
Notify: per-alarm recipients
The Notify fields send one message the moment the alarm activates (after any on-delay), in addition to whatever pipelines the rule has:
- Email goes to the typed addresses, the group's members and the person on call, as one message, through SMTP or the relay like a pipeline's Send Email. Subject
Alarm: <rule> [SEVERITY]. - With Also text the group and on-call person, their mobile numbers get
Alarm: <rule> [SEVERITY] <message> (<tagPath>=<value>)through the SMS queue. - Anyone a pipeline assigned to the rule already reaches at once — a Send Email or Send SMS step before the pipeline's first Delay, that the alarm's severity lets through — is left off, so nobody gets the same alarm twice.
- It is held back by the notification master switch and quiet hours, like any page (see Notification settings), and doesn't run for a shelved alarm.
- What was sent shows in Alarm rule notifications on the Notifications tab.
Conditions
| Condition | Alarm is active while | Example |
|---|---|---|
| Greater than | value > Threshold | Spindle temp > 60 |
| Less than | value < Threshold | Air pressure < 5.5 |
| Equal to | value = Threshold (exact match) | E-stop input = 1 |
| Not equal to | value ≠ Threshold | Mode ≠ 2 |
| Between (inclusive) | Low ≤ value ≤ High | Speed between 0 and 50 while it should be running |
| Outside range | value < Low or value > High | Ambient temp outside 15–35 |
| Rate of change | the value's change per second (or per minute), measured over the window, is above Threshold — rising, falling or either way | Tank level falling faster than 2 per minute |
| Trend toward a limit, Deviation from normal, Change interval | judged against the tag's own history — see Trend alarms | Mold temperature heading for 90 within ten minutes; a part counter ticking every 45 s instead of every 30 s |
Equal to and Not equal to compare floating-point numbers exactly. A value of 59.99999 is not equal to 60. Use them for integers and digital signals, and ranges for analog values.
Rate of change
The rate is the change from the value at the start of the window to the latest value, divided by the window. Values arrive only when they change, so the value at the window's start is the last one received at or before it: a level that sat at 10 for five minutes and jumped to 20 a second ago changed by 10 over a 60-second window, not over five minutes. Until a whole window of values has been seen, the rate is measured over what there is. While the value stands still, the rate falls back to 0 as the window moves past the last change, so the alarm clears without a new value. Threshold must be above 0; Deadband lowers the rate it must drop below to clear.
Timing: on-delay, off-delay, deadband and debounce
- On-delay — the condition has to hold for the whole delay before the alarm activates. If it drops out partway, the delay starts over next time. "Above 60 for 30 seconds" is Greater than
60with On-delay30. The alarm activates when the delay ends even if the tag sends no new value in the meantime. - Off-delay — once active, the condition has to stay clear for the whole delay before the alarm clears. If it comes back partway, the alarm stays active and the delay starts over.
- Deadband — once active, the limit moves back by the deadband: a Greater than
60alarm with deadband2stays active until the value is58or lower; Less than moves up; a range has to come back inside by the deadband. Equal to with a deadband stays active while the value is within the deadband of the threshold. Not equal to ignores it. - Debounce (ms) — only stops the same rule from activating again within that many milliseconds of its last activation. It is not a delay: the first activation is immediate (after any on-delay). If the condition comes back inside the window, the alarm activates as soon as the window has passed, if the condition still holds.
Editing a rule starts its delays over. Delays are kept in memory, so an API restart also starts them over.
To stop an alarm chattering on a noisy analog signal, give it a Deadband and an Off-delay of a few seconds; a deadband on the tag subscription (in the device's Live Data tab) also stops small changes being reported at all.
What values can be alarmed
- Rules are evaluated when the tag engine reports a changed value (after scaling and deadband), and once a second while an on- or off-delay is running or for a Rate of change rule.
- Values must be numeric.
true/falsebecome 1/0, so a boolean tag works with Equal to 1. Any other non-numeric value (a string tag such asAUTO) is ignored — string tags cannot be alarmed. - Bad-quality readings are not treated specially: the rule sees only the value.
Alarming on the system itself
The appliance publishes its own health as ordinary tags under _STATUS/, so a faulting ladder task, a failed workflow run, a failed script run or a device that stopped talking can all be alarmed with a normal rule and a normal pipeline:
| To alarm on | Device | Tag | Condition |
|---|---|---|---|
| A device offline | that device | _STATUS/Connected | Equal to 0 |
| A ladder task faulted | Local Tags | _STATUS/Ladder/<task name>/Faulted | Equal to 1 |
| A workflow's last run failed | Local Tags | _STATUS/Workflow/<workflow name>/Failed | Equal to 1 |
| A script's last run failed | Local Tags | _STATUS/Script/<script name>/Failed | Equal to 1 |
Scada.Ink also raises some alarms on its own — device offline and ladder task faults — but those have no rule behind them, so they run no pipeline and reach nobody who isn't looking at a screen. A rule on the tag above is what sends the email or text. The full list of status tags is in System Status Tags.
Manage rules
Each row in All Rules shows the device → tag, the condition and threshold, and a severity badge.
- Pencil (Edit rule) opens Edit Alarm Rule; click Save Changes.
- Enabled / Disabled toggles the rule immediately. A disabled rule is not evaluated.
- Trash (Delete rule) asks you to confirm, then deletes the rule. If the rule is in alarm, that alarm clears. Its pipeline assignments and shelves are removed. Its past occurrences stay in History, but without the rule name.
Who can do what
| Action | Minimum role |
|---|---|
| View rules, active alarms, history, metrics | Any signed-in user |
| Create, edit, enable/disable, delete rules | Editor |
| Acknowledge, shelve, unshelve | Operator |
Roles are set under Users.
Example: spindle over-temperature
A machining center's Spindle Temp tag should be below 60 °C, and anything above 70 °C needs maintenance now.
- Rule 1: Name
Spindle Temp High, Condition Greater than, Threshold60, Severity Warning, MessageSpindle temperature above 60 °C — check coolant. - Rule 2: Name
Spindle Temp High-High, Greater than70, Severity Critical. - On the device's Live Data tab, give the tag an absolute deadband of
0.5so a reading hovering at 60.0 does not fire and clear every poll. - Attach Rule 2 to a pipeline that texts the maintenance lead (Alarm pipelines).
API
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /api/alarms/rules | List rules |
| POST | /api/alarms/rules | Create a rule (name, tagSubscriptionId, condition, threshold, severity, message, debounceMs, onDelayMs, offDelayMs, deadband, notifyEmail, notifyGroupId, notifyScheduleId, notifySms) |
| PUT | /api/alarms/rules/:id | Update a rule |
| DELETE | /api/alarms/rules/:id | Delete a rule |
| GET | /api/alarms/active | Active, unshelved alarms, including device-offline and ladder task fault alarms |
A create without a name, tag or condition returns name, tagSubscriptionId, and condition are required; an unknown tag returns Tag subscription not found. A missing or non-numeric threshold returns threshold.value must be a number for condition "gt" (or threshold.low and threshold.high must be numbers… for a range). A Rate of change rule takes threshold as { "value": 2, "per": "min", "windowS": 60, "direction": "fall" } (per is s or min, direction rise, fall or either); a rate of 0 or less returns threshold.value must be a positive rate for condition "roc". onDelayMs and offDelayMs are whole milliseconds from 0 to 86400000.