Overview
This document describes how to configure a solution to generate alarms using the Scripts Module, instead of doing the configuration at the AlarmsItems session. The methods presents here allows to Activate, Normalize, and Acknowledge alarm items directly from your customization scripts, bypassing the AlarmsItems configuration table, but still using the AlarmGroup properties, AlarmViewer Online table, and saving to AlarmHistory
On this page:
Configuration
Script Methods
Those methods are on the Alarm.Group namespace. Example: Alarm.Group.Warning.ActivateCustomAlarmsAsync(...
AlarmCustomInfo Settings
The key parameter of the AlarmCustomInfo is the ItemName.
The ItemName is defined by user, it cannot start with "ID", as those are reserved to the alarms created by Alarm Engine, based on the AlarmsItems table.
We recommend to keep similar standard, having two letters that related to the data source, then a sequential number.
ItemName Property
The ItemName must unique to each alarm, as repetitive ItemName will be understood as the same alarm (if already activated, you can't active it again.
The ItemName is the key used in the methods do normalize or acknowledge the tag from script.
Except by the ItemName and Condition, all the other fields are optional, but we strongly recommend to use then consistency with the configuration of the alarms in the AlarmItems table, and the columns you intend to visualize in the AlarmViewer graphical component.
Alarm Initial Condition
If the alarm is created with Condition Changed, ChangedUp, or ChangedDown, as they represent an EVENT, not a STATE, they are generated with its status in NORMALIZED, meaning they only stay on the alarm online page if the group required acknowledgement, otherwise they go directly to the AlarmHistory.
The alarms created with Condition Hi, HiHi, Lo, .. and all the conditions that reflect an STATE, are generated with the status ACTIVE. They will stay in the alarm online page until you call the script method to normalize them (using the ItemName to define which alarm to normalize).
Alarm Acknowledgement
When the alarm is presented in the AlarmViewer graphical components, it can be acknowledged directly from the commands available on that User Interface. Otherwise you can use teh custom acknowledge method to do it directly .
The alarms stay in the AlarmOnline view when they have Acknowledment pending, even if they are normalized, if the AlarmGroup requires ack.
The alarms that in Normalized state, and don't require ACK (or have been acknowledged) will present only on the AlarmHistorian (assuming the AlarmGroup is set to log those events in the AlarmHistorian database).
Execution
The alarms show in the AlarmViewer online, and are stored to the AlarmHistorian, in the same way the alarms created on AlarmItems would behave.
There are though some restrictions on the use of those custom alarms:
- In hot-standby scenarios the Alarm Online not updated with the custom alarms, on the switch. A custom script is necessary to enable it.
- The internal counters Alarm.TotalCount and other counters, as the Tag Alarm properties, will not update base on those messages.
Essentially, the custom alarm are intended to be used only in local Online Alarms table, and Acknowledgement and Logging if the group is enabled to those actions.
Example
Solution Example
In this section: