Alarms
An alarm is a record that warns the operator when a tag's value meets a defined condition. This page explains how an alarm is raised, which states it goes through and whom it reaches. The definition steps are on the Alarm Definitions page; using the alarm screen is described on the Interface Tour and Alarm History pages.
Alarm Definition
Every alarm definition is bound to a tag. A tag can have more than one alarm definition. A definition consists of these parts:
- Compare Operator and Compare Value: the condition itself, for example "value > 80".
- Bit Number: if filled in, the condition is applied only to this bit of the tag value; if the bit is 1 the value is taken as 1, if it is 0 the value is taken as 0.
- Active Tolerance, Passive Tolerance and Delay Time: settings that keep the alarm from being raised and cleared needlessly.
- Type (the alarm type).
The condition is evaluated again each time the tag's value changes. Alarms are not evaluated for text (String) tags.
Alarm Types
The alarm Type is one of three values: ERROR, WARNING or ALARM. The type does not change how the alarm is evaluated:
- In the active alarm table and in alarm history, rows are shown in different colors depending on the type and state.
- The subject of the email notification is "2Win Scada Uyarı" for the WARNING type and "2Win Scada Hata" for the other types (the subject is always in Turkish).
Tolerance
Two tolerances keep the alarm from being raised and cleared over and over when the value fluctuates around the threshold. The alarm is raised when the value passes the threshold by the Active Tolerance and cleared when it comes back by the Passive Tolerance. Between the two limits the alarm keeps its previous state.
| Operator | Alarm is raised | Alarm is cleared |
|---|---|---|
| Greater than (>) | value > threshold + active tolerance | value ≤ threshold − passive tolerance |
| Greater than or equal (>=) | value ≥ threshold + active tolerance | value < threshold − passive tolerance |
| Less than (<) | value < threshold − active tolerance | value ≥ threshold + passive tolerance |
| Less than or equal (<=) | value ≤ threshold − active tolerance | value > threshold + passive tolerance |
| Equal (=), Not equal (!=) | When the condition is met | When the condition is not met; tolerances are not used |
| Not Changed | The difference from the previous value is ≤ active tolerance; it is checked again about every 10 seconds even if the value does not change at all. It is not evaluated until the first real value is read (see Delay). | Difference > passive tolerance |
Example: a "greater than" alarm with threshold 80, active tolerance 2 and passive tolerance 5 is raised when the value goes above 82 and cleared when the value drops to 75 or below.
Delay
If Delay Time is greater than zero, no decision is made for the alarm as soon as the tag's value changes. The system waits for the delay time and, at the end of it, raises or clears the alarm according to the latest state of the condition. This way, fluctuations shorter than the delay do not produce alarms. The delay applies both to raising and to clearing the alarm; only Not Changed alarms are cleared without waiting when the condition goes away.
For a Not Changed alarm, the delay is counted from the first real value read after the service starts, the device is reloaded, or the alarm definition is updated and moved to another tag. If no value has ever been read from the tag, the alarm is not raised. When the connection is lost, the last value stays frozen, so the alarm is still raised at the end of the delay.
Lifecycle
Taking the state of the condition and the operator's acknowledgement together, an alarm is in one of four states:
| State | Condition | Acknowledgement | In the active alarm table |
|---|---|---|---|
| New | Met | None | Visible; sound plays |
| Acknowledged | Met | Given | Visible |
| Awaiting reset | Gone | None | Visible; sound plays |
| Closed | Gone | Given | Not visible |
Transitions:
- The condition is met (after the delay, if any): the alarm becomes New.
- The operator acknowledges the alarm: it becomes Acknowledged. When the condition later goes away, the alarm becomes Closed.
- The condition goes away before the alarm is acknowledged: the alarm becomes Awaiting reset. It stays in the table so that the operator does not miss it. It becomes Closed with an acknowledgement.
- If the condition is met again, the alarm becomes New again and needs a new acknowledgement.
Operator Actions
These actions are available in the active alarm window:
| Action | Effect |
|---|---|
| Ack (toolbar) | Acknowledges all alarms in the list. A single alarm is acknowledged with the Ack switch in its row; the user who acknowledged it appears in the Ack By column of the table. An acknowledgement closes an alarm awaiting reset directly. |
| Lock | Applies one lock state to all selected alarms: if at least one selected alarm is unlocked, all selected alarms are locked; if all selected alarms are already locked, they are all unlocked (see Lock). If no alarm is selected, the message There is no item selected! is shown. A selected alarm stays selected when it is updated; an alarm that drops out of the list is removed from the selection. |
| Mute Sound | Turns the alarm sound off or on in this browser (see Sound). |
Acknowledge and lock require the UserAdministrator, Operate, Editor or AlarmManagement role. A user can act only on the alarms they can see; which alarms are visible is described on the Process Groups and Access page.
During a Connection Outage
When the live data connection to the server drops, the alarm list is not emptied and the alarm count does not drop to 0. From 2.10.1, the last known alarms stay on screen, but they are not current:
- The note Alarm list not current appears in the toolbar of the active alarm window. The alarm count in the top bar appears faded; the same note is shown when you hover over it.
- Widgets bound to the alarm summary system tags (for example, the active alarm count) are also calculated from the last known alarms.
- While there is no connection, alarms cannot be acknowledged or locked. The Ack and Lock actions only show the warning Alarm not acknowledged: no SCADA connection. or Alarm lock not changed: no SCADA connection.; the alarm does not appear acknowledged or locked.
When the connection is restored, the list is replaced in one step by the current active alarm list the server sends, and the note disappears. Alarms raised during the outage are added to the list; alarms that closed during the outage drop out of the list.
If the outage is caused by a restart of the server service, the server evaluates the alarms again when its startup finishes. If the startup takes longer than 15 seconds after the screen reconnects, the alarms kept on the screen can drop out of the list; the list and the alarm count can be empty or 0 until the startup finishes. When the startup finishes, the active alarms come back; the alarms of a device that has not been read yet at that moment come back when the device is read.
Lock
The Lock action checks the Ignored field in the definition of the selected alarms. If at least one selected alarm is unlocked, all selected alarms are locked; alarms that are already locked stay locked. If all selected alarms are locked, the same action clears the field on all of them. The lock is stored with the alarm definition: it is kept when the server service restarts and applies to all users. The Ignored column of the alarm definition table shows the lock state; the field is not edited in the definition dialog.
A lock silences the alarm only in the interface:
- A locked alarm is still listed in the active alarm table, but it is not colored.
- It is not counted in the alarm count on the top bar, and the alarm sound does not play.
A lock does not stop the alarm from being evaluated. A locked alarm is still raised and cleared, written to alarm history, and its defined notifications are sent. Use it to keep a known situation, such as a faulty sensor, from disturbing the operator all the time; remove the lock when the problem is fixed.
Sound
The alarm sound plays in the user's browser. The sound plays while there is at least one unlocked alarm in one of these states:
- a New or Awaiting reset alarm,
- an alarm acknowledged by another user.
Alarms the user acknowledged themselves do not trigger the sound. The sound is turned off with two settings:
- Mute Sound: the button in the active alarm window. The choice applies only to that browser and is kept when the page is refreshed.
- Alarm Sound Enabled: the setting in the user definition. If it is not checked, the user hears no alarm sound in any browser.
TIP
Browsers can block sound until the user interacts with the page. On a computer used as a monitoring screen, click the page once after signing in.
Alarm History
The times an alarm is raised and cleared are written to the archive database together with the tag value at that moment (see Archiving). History is queried on the Alarm History screen. Locked alarms are written to history as well.
Notifications
Email or SMS notification for an alarm is set up with a separate definition (see Notifications). The notification rule looks at whether the alarm is active:
- The notification's own Delay Time [s] is the time to wait after the alarm is raised.
- Repeat Count and Max Sent Count limit the number of messages for frequently repeating alarms.
- The notification goes to the users selected in the notification definition. Acknowledgement, lock and process group scope do not affect whether the notification is sent.
The state of sent notifications is monitored on the Notification History screen.
Who Sees Alarms
Live alarms are delivered according to the user's process group scope. Alarms whose tag belongs to no process group or tag group belong to the Genel process group and are delivered to users who can see Genel; if no role is assigned to Genel, everyone sees them. Users with the Editor role and SystemAdmin receive the alarms of all process groups, including Genel. Details: Process Groups and Access.