Alarm Disablement, Inhibition, and Suppression
You can turn alarms “off” or ignore them without actually removing the alarm configuration. You can either disable an alarm, inhibit it, or suppress it.
Alarm disablement and inhibition are controlled by the alarm provider. Suppression is controlled by the alarm consumer. For more information on providers and consumers, see Alarm Providers and Consumers.
Disablement.
You disable an alarm at the alarm provider by setting a flag that marks it as disabled. No matter what alarm conditions occur, the item is never put into an alarmed state. For information on dotfields you can use to disable an alarm.
You can disable or enable all of a tag’s alarms at one time. Also, for an alarm that has sub-states, you can disable each sub-state individually.
Inhibition.
You inhibit an alarm by:
Adding an “inhibitor” tag to the alarm configuration in WindowMaker. The inhibitor tag is used at run time to mark the alarm as inhibited.
Setting the inhibitor tag to True or False at run time. When the inhibitor tag is False, the alarm is handled normally. When the inhibitor tag is True, the item cannot alarm.
Each alarm sub-state can be inhibited by a different tag, and you can leave some sub-states with no inhibitor tag assigned.
Assigning a tag as an inhibitor tag for an alarm increases its cross-reference use count.
Suppression.
Suppression causes an alarm consumer to ignore certain alarms. If an alarm matches the exclusion criteria, it is not visible. That is, it is not shown on a display, printed, or logged at that particular alarm consumer.
The actual alarm generation is completely unaffected by suppression. Alarm records can still be logged into alarm history.
If an alarm becomes disabled or actively inhibited while the item is in an alarmed state, the item is forced to a different (valid) state. What that state should be depends upon which states are available and whether they have also been disabled. This activity is handled by the alarm provider according to the type of alarm, limit values, and so on.
An alarm that is disabled or actively inhibited is not waiting for an acknowledgment. If the alarm has sub-states, it can only be waiting for an acknowledgment on sub-states that are still available.
Terminal Services Alarm Support
By using the Distributed Alarm system with Terminal Services for InTouch, alarm clients running on different terminal sessions can select what alarm data to show and how to present it.
Alarm Providers identify themselves by a name that uniquely identifies their application, and the instance of their application. This information is made available to the Distributed Alarm system when the Alarm Provider or the Alarm Consumer registers with the Distributed Alarm system.
The node on which an Alarm Provider is running is identified by a name that uniquely identifies the computer node in the system. This information is made available to the Distributed Alarm system when an instance of it starts up on the computer node.
When an alarm event is logged, the node and complete Alarm Provider name identify the source of the alarm.
When an alarm is acknowledged in a Terminal Services environment, the Operator Node that gets recorded will be the name of the client machine that the respective operator established the Terminal Services session from. If the node name can’t be retrieved, the node’s IP address will be used instead.
A terminal server client session cannot be an InTouch alarm provider.
Distributed Alarm System Data Storage
There are several forms of data storage used in the Distributed Alarm system:
Internal alarm memory (buffer)
Most information about current and recent alarms is held in memory on various computer nodes. InTouch uses two memory locations: one for summary alarms (current) and one for historical alarms and events. This model is also used in the Distributed Alarm system.
The memory for summary alarms grows as needed to accommodate all current alarms up to the limit of available memory. The memory for historical alarms can grow only to a pre-determined limit. After the historical memory reaches this limit, the oldest alarm records are discarded as new ones are added. In a multi-node environment, the alarm memory on the various nodes constitute a single collective of alarm memory.
Alarm database
The Alarm DB Logger creates a database, keeping track of when an alarm occurs, makes a sub-state transition, is acknowledged, and when it returns to normal. Essentially, these records constitute a history of alarms in the system.
Because it is based on the use of queries, the Distributed Alarm system supports using one computer node to log alarms for several other nodes.
Also Read:-