Alarms and Events Window Popup Wonderware Intouch :-https://youtu.be/fHKgPYI8agA
Alarms and Events Wonderware Intouch
Identify the different alarm types and events and add alarm functionality to applications
This section explains and defines the different types alarms and events and how to add alarm functionality to applications.
InTouch has two types of notifications to inform operators of process activity: Alarms and Events.
Alarms represent warnings of process conditions that could cause problems, and require an operator response.
A typical alarm is triggered when a process value exceeds a user-defined limit, such as an analog value exceeding a hi-limit threshold. This triggers an unacknowledged alarm state that can be used to notify the operator of a problem. Once the operator acknowledges the alarm, the system returns to an acknowledged state.
InTouch can be configured to require an alarm to be acknowledged even if the condition causing the alarm has passed. This ensures that an operator is aware of events that caused a temporary alarm state but have returned to normal.
Events represent normal system status messages, and do not require an operator response. A typical event is triggered when a certain system condition takes place, such as an operator logging into InTouch. If configured to do so, InTouch can log an event to the alarm database and print it out to a printer.
Any tag can be configured to do event monitoring while you are defining it in the Tagname Dictionary. When you define a tag to do event monitoring, an event message is logged to the alarm system each time the tag value changes. The event message logs how the value changed, whether the operator, I/O, scripts or the system initiated the change.
Alarm Concepts
There are a number of terms and concepts that apply to alarms generally, regardless of the particular system in which they are used, or how they are implemented.
Alarms: In general, an Alarm is a specific type of a condition – in particular, an alarm is an abnormal condition.
The intention of an alarm is to signal that something has gone wrong, or that a particular stage of processing has been reached. For example, an alarm might indicate that a boiler has exceeded a safe temperature limit.
Priority: A level of priority is associated with an alarm to indicate how severe the situation or condition is.
In the case of a boiler temperature limit, it might be very severe, requiring immediate attention to save life and property. By contrast, in other (less dire) situations the severity might be minimal.
The severity of an alarm usually depends upon the circumstances – the factory application, the nature of the equipment, safety, availability of backup systems, potential costs of damage or downtime and so on.
Sub-states: An alarm condition may also have sub-conditions, in which case it is called a multi-state alarm.
For example, an analog alarm typically has several limits, with High and Low bounding the normal operating range, and HiHi and LoLo marking the extreme departures from normal.
The boiler temperature level mentioned above could be in the alarmed condition for any one of these sub-states. It could also transition between any two sub-states while continuing to remain in the overall alarmed condition.
Events: An event is defined as a detectable occurrence, which may or may not be associated with an alarm.
A transition into or out of an alarmed state constitutes one kind of event. An event might also mark an operator action, a change to the system configuration or some kind of system error.
It is important to make a distinction between an alarm condition and an event. A condition may persist for minutes, hours, days or weeks. An event is momentary; it takes place and is immediately over. An alarm is a condition; an alarm notification is an event.
Acknowledgment: One major purpose of an alarm is to alert someone about the condition.
The person or system should then acknowledge the alarm, indicating that is has been seen.
Acknowledgment is separate from the issue of taking corrective action, which might not happen right away. It is also separate from the issue of whether the alarm condition returns to normal – which it might do on its own, even without any external intervention.
Acknowledgment merely indicates that someone has noticed the occurrence of the alarm. A high or medium priority alarm usually requires acknowledgment, while a very low priority alarm might not.
Although the condition that generated the alarm may go away (for example, a temperature rises too high and then becomes lower again), the alarm itself is not considered “handled” until it is acknowledged.
Groups: Alarms may be organized into groups to facilitate tracking and management. These groups might represent different areas of a factory, pieces of equipment, operator responsibility or a specific functionality. Groups may also be organized into a hierarchy of parent groups and sub-groups.
Areas: Factories are generally organized into areas, representing physical location, operator responsibility, phases of a process, types of equipment and so on. Like groups, areas can be hierarchical – divided into main areas and sub-areas.
However, areas should be mentioned separately from groups, because some factories make a distinction between the two.
Note: The Distributed Alarm System provides no explicit support for Areas. However, alarm Groups may be used to divide alarms into collections that correspond to Areas.
Alarm Types
InTouch classifies alarms into several general categories based on their characteristics. These categories are known as Class and Type.
The Distributed Alarm System categorizes all alarms into five general Conditions: Discrete, Deviation, Rate-of-Change, SPC and Value.
The table below summarizes the alarm condition for both systems.
Alarm Condition Distributed Class Distributed Type
Discrete DSC DSC
Deviation – Major DEV MAJDEV
Deviation – Minor DEV MINDEV
Rate-of-Change ROC ROC
SPC SPC SPC
Value – LoLo VALUE LOLO
Value – Low VALUE LO
Value – High VALUE HI
Value – HiHi VALUE HIHI
Each alarm can be associated with an InTouch tag. Depending upon a tag type, you can define one or more of the alarm classes or types for it.
Alarm conditions are defined within the Tagname Dictionary.
Event Types
InTouch also classifies events into general categories based on their characteristics. These categories are known as Event Types.
The table below summarizes the classification of events.
Event Condition
ACK Alarm was acknowledged.
ALM Alarm has occurred.
EVT An alarm event occurred.
RTN Tagname returned from an alarm state to a normal state.
SYS A system event occurred.
USER $Operator changed.
I/O The tagname value was poked from a DDE client.
LGC A QuickScript modified the tagname value.
OPR The operator modified the tag value using the Value Input.
The first six events listed are configured automatically when event logging is enabled. The remaining three must be defined by users for each tagname in the Tagname Dictionary.
Tagname Alarm Configuration
In Touch supports alarm definition and configuration for each tag that is defined in the Tagname Dictionary. By default, all tags have their alarms disabled.
The basic concept is that any tag can be configured as alarmable, specifying the type of alarm and user-selected limits. For such a tag, when the tag value changes, the alarm logic is invoked.
This alarm logic is an InTouch subroutine that checks the type of alarm, compares the new value to the indicated limits, and determines whether the tag is in an alarmed condition. Any transitions of state are then reported to the Distributed Alarm System.
There are two basic alarm types (or classes) defined in InTouch. These are subdivided into several additional alarm sub-types.
Discrete: A discrete alarm corresponds to a discrete tag. You can configure whether the alarmed state corresponds to the TRUE state or the FALSE state of the discrete tag, and the associated priority of the alarm.
The configuration dialog for a discrete tag is as follows.
The configuration dialog for an analog tag is as follows.
Analog: An analog alarm corresponds to either an integer or real (floating point) tag. Within the analog type there are several alarm classes.
Value: The current value is compared to one or more limits. If the value exceeds the limit, the alarmed state is declared. You can individually configure values and priorities for the “LoLo” limit, “Lo” limit, “Hi” limit and “HiHi'” limit and indicate whether or not each limit is to be used. The Value Deadband establishes how much the value must change before it is taken out of alarm.
Deviation: The current value is compared to a target value, and then the absolute value of the difference is compared to one or more limits, expressed as a percent of the range of the tagname value – that is, the total difference between its configured maximum and minimum allowable values. You can individually configure values and priorities for the “Minor Deviation” limit and the “Major Deviation” limit, and indicate whether or not each limit is to be used.
Values may also be configured for a “Deviation Deadband,” also expressed as a percent of the tag’s range. This controls the percentage the tag value that must drop before it is taken out of alarm.
Rate-of-Change: The current value and the previous value are used in this computation, along with the current time and the time of the previous update. If the absolute value of the rate of change exceeds the limit, the alarmed state is declared. You can configure the value and priority for the ROC limit, and whether or not the limit is to be used.
The limit is expressed as a percent of the range of the tag value, which can be per-second, per-minute, or per-hour.
Alarm Priorities
Each alarm configured in InTouch has a priority value associated with it. This value represents the severity of the alarm and can range from 1 to 999 with 1 being the most severe.
By creating alarm ranges using these priorities and assigning alarms to each, you can easily filter out critical alarms from non-critical ones. You can also create animation links, acknowledgment scripts, and filtered viewing and printing all based on the priority range.
For example, if a process plant has determined that they need four levels of severity, they could establish ranges as shown below.
Alarm Severity Priority Range
Critical 1 – 249
Major 250 – 499
Minor 500 – 749
Informational 750 – 999
As the plant engineers create InTouch tags and alarm conditions, each alarm will be assigned to one of these severity levels by choosing a priority number within that range. When the ranges are configured, the plant operators may now easily display and print only certain severity levels.
Alarm Groups
Each InTouch alarm is assigned to a logical Alarm Group. Each Alarm Group is user- definable, must have a unique name, and can be arranged into a hierarchy up to 32 levels deep. The groups provide a way of categorizing alarms based on an organization, plant layout, or any other metric. Alarm Groups are useful for filtering alarm displays, Alarm Printers, and acknowledgment scripts.
Every tag is associated with an Alarm Group. If you do not associate an Alarm Group name to a tag, InTouch automatically associates it with the root group, $System by default. Any Alarm Group may have both tags and other Alarm Group names associated with it.
Alarm Groups are organized into a hierarchical tree structure with the root group, $System, at the top of the tree. All defined Alarm Groups automatically become descendants of the root group.
This tree may have up to 32 levels. Each Alarm Group may have a maximum of 32 subgroups. Each subgroup may have a maximum of 32 subgroups, and so on, until the maximum of 32 levels is reached.
This illustration displays only Alarm Groups, not the tagnames within each group. This tree concept is analogous to the Windows Explorer directory structure, where a directory may contain other sub-directories which are analogous to groups, and file names which are analogous to tagnames.
Alarm Group names are limited to 31 characters and must begin with an alpha character A- Z or a-z. At the same time, the Group name cannot have any spaces in the string. For example, a valid name is “AlarmGroup#1-23” whereas a sample of an invalid name is “Alarm Group # 1 – 23”.
The Distributed Alarm System also uses these groups as the basis for its Alarm Group Lists.
Note: While Alarm Groups do not count as tags with InTouch licensing, they do count as tags in the database. Therefore, the total number of Alarm Groups plus actual tagnames cannot exceed 61,402. Also, groups cannot be created if WindowViewer is running.
Warning: Large numbers of alarm groups (hundreds or thousands) can cause performance problems. For more information, refer to the Alarm Deployment Guide.
Creating an Alarm Group
Click Special / Alarm Groups on the WindowMaker main menu. The Alarm Groups dialog box appears:
The Modify and Delete buttons are not available until an Alarm Group is defined. The $System Alarm Group cannot be modified or deleted.
Note: While defining tagnames in the Tagname Dictionary, you can create Alarm Groups and associate them with any tags.
Click Add.
The Add Alarm Group dialog box appears:
In the Group Name box, enter the name for the new Alarm Group. Since this is the first Alarm Group you have created, it is automatically assigned to the $System Parent Group.
After you have created an Alarm Group, it can be used as a Parent Group.
Click OK.
The Alarm Groups dialog box reappears:
Select the first Alarm Group you created, then click Add to create a second group. The Alarm Group that was selected is now the Parent Group of the new alarm group.
In the Comment box, enter any comment for the new Alarm Group.
Click OK.
The Alarm Groups dialog box reappears displaying your Alarm Group hierarchy:
Click Close.
Modifying an Alarm Group
Select Special / Alarm Groups.
The Alarm Group dialog box appears:
Note: You can also modify Alarm Groups while defining tags in the Tagname Dictionary.
Select the Alarm Group to modify in the list and then click Modify.
The Modify Alarm Group dialog box appears:
Click Parent Group to change the parent group for the Alarm Group.
The Alarm Groups dialog box appears:
Select $System as the new parent group. Click Close.
The Modify Alarm Group dialog box appears, displaying the new parent group:
Make any changes (if any) to the Comment.
Click OK.
The new Alarm Group hierarchy is displayed:
Click Close.
Deleting an Alarm Group
Select Special / Alarm Groups.
The Alarm Group dialog box appears.
Select the Alarm Group in the list to delete.
Click Delete.
Click Yes to confirm the intended deletion.
Note: You can also delete Alarm Groups while defining tags in the Tagname Dictionary. Alarm Groups can be deleted regardless of any tagnames in use in the group to be deleted. Any tags in the deleted group will migrate to the parent Alarm Group.
Alarm Acknowledgment Models
When an item goes from a Normal state to an Alarmed state, a new instance of its alarm is generated. If the alarm is a multi- state alarm, any change to a new sub-state while still remaining alarmed is treated as a transition of the same alarm instance.
The lifetime of an alarm instance stops when the alarm returns to Normal – a subsequent transition to the alarmed state generates a new alarm instance.
The InTouch Distributed Alarm system tracks each instance of an alarm – when it first enters the alarmed state, when it makes a sub-state transition, when it returns to Normal, whether it is waiting for an Acknowledgment, and when it is Acknowledged.
Alarms as conditions: Acknowledgment is for the instance of the alarm. An alarm instance begins waiting for an ACK when it first enters the alarmed state. If it is ACKed and subsequently transitions to a new alarmed sub- state (for example from “Hi” to HiHi”), it begins waiting for another ACK. when the ACK is received, it is accepted and applies to all transitions of the alarm that have occurred so far. The alarm is considered ACKed when the most recent instance has been ACKed.
Alarms as events: Acknowledgment is for the instance of the alarm, and must be for the most recent transition to an alarmed state or sub -state. An alarm instance begins waiting for an ACK when it first enters the alarmed state. If it is ACKed and subsequently transitions to a new alarmed sub-state, it begins waiting for another ACK. Each subsequent transition is assigned a sequence number, and the ACK must have attached to it the sequence number of the transition to which it is responding. The ACK is accepted only if it is for the most recent transition.
A rejected ACK may be logged for diagnostic purposes, but is not otherwise tracked in the system. If it is accepted, it applies to all transactions of the alarm that have occurred so far. The alarm is considered ACKed when the most recent instance has been ACKed. The event-oriented model ensures that if an alarm is changing between different states, the ACK corresponds to up-to-date information. In systems with small latency times, this may look just like condition-oriented alarms – but in other environments, such as the Internet, the features of this model may become important.
Expanded Summary Alarms: Acknowledgment is for each transition of the alarm. The initial entry to the alarmed state must be ACKed, and the return to normal must also be separately ACKed. Any transition to a new alarm sub-state is treated as a new occurrence that must be ACKed, and whose RTN must also be ACKed. Sub -state transitions are treated as belonging to a “RTN group,” starting with the first entry into an alarmed state when the item was previously normal. If the item returns to normal and subsequently enters the alarmed state again, a new RTN group is created. Each transition must be acknowledged individually and explicitly; and the alarm is considered acknowledged only when the item has returned to normal and all transitions in all pending RTN groups have been acknowledged.
Note: Here the term summary means “awaiting acknowledgment.” This alarm model may also be known as ring-back alarms.
To summarize, for condition-oriented alarms, an acknowledgment counts against all entries into the alarmed state up to the time of the acknowledgment. For event-oriented alarms (as in OPC) an acknowledgment is accepted only if it refers to the most recent activation event.
For Expanded Summary alarms, all events – to active, inactive, and different sub-states – must be acknowledged before the overall alarm is considered acknowledged.
Expanded Summary Alarms
When an alarm occurs it generates a record in the alarm display object showing that an alarm condition has occurred with the date and time stamp of the alarm. This record does not leave the display until an operator has acknowledged the alarm and a return-to-normal state (RTN) has occurred. If the return-to-normal state occurs before the alarm is acknowledged, then two records are displayed in the alarm object.
For example, if a boiler’s temperature exceeds the hi-limit state, thus triggering an alarm, but returns to the normal temperature range before an operator acknowledges the alarm state, a record will be generated showing the alarm state and an additional record will be generated showing that the alarm state was not acknowledged.
An acknowledgment is only for a particular transition, whether to an alarmed state, to a sub-state, or a return to normal. Each transition from the normal state marks the beginning of a new RTN group. All transitions in an RTN group must be acknowledged individually before the overall RTN group is considered acknowledged.
Using Expanded Summary Alarms
When you define a tagname and select Expanded Summary as its ACK Model it requires an operator to acknowledge that an alarm occurred even if the state triggering the alarm has returned-to-normal.
Acknowledging an alarm state will change the color of the alarm entry but does not change the displayed time stamp. Alarms will only clear from the display when they are acknowledged and the alarm has returned to a normal state.
Note: When you define a tag with the Expanded Summary ACK model, the RTN Implies Ack option in the Alarm Properties dialog box does not apply to the tag.
Alarm Visibility Controls
It may sometimes be necessary or desirable for you to turn some alarms off without actually removing the alarm configurations for an item.
InTouch supports three basic types of alarm visibility control: disablement, inhibition, and suppression. These are described in terms of a three-stage alarm model.
Alarm stimulus: The value or status of an alarmable item is tracked.
Alarm state: The alarmable item is compared against limits and conditions, to determine if it is in an alarmed state. State transitions are tracked and reported.
Alarm annunciation: Reports and updates of the alarm state are displayed and/or logged via one or more alarm clients.
With the model shown in the previous figure in mind, the following visibility controls are handled at the Alarm Provider.
Alarm Disablement: An alarm can be disabled by setting a flag that marks it as disabled. No other change to the alarm configuration is involved.
While an alarm is disabled, any checking may or may not- continue regarding conditions that would put the item into an alarmed state. But while the disablement is in effect those conditions cannot put the item into the alarmed state.
Essentially, the item is in a forced normal state. Disablement breaks the connection between the alarm stimulus and the alarm state.
Since the alarm cannot go into the alarmed state, while an alarm is disabled, no entries are made to the alarm history for that alarm.
Alarm Inhibition: An alarm can be inhibited by identifying a tag that marks it as inhibited. This tag is called an inhibitor tag. No other change to the alarm configuration is involved.
While the inhibitor tag is FALSE (or zero), the alarm is handled normally; but while the inhibitor tag is TRUE (or non-zero), the item cannot alarm.
In essence, it is treated the same as if the alarm were disabled. The alarm is then actively inhibited.
Alarm inhibition is a two-stage process.
Assignment of the inhibitor tag.
A change of the state of the inhibitor tag from FALSE to TRUE or vice-versa.
As with disablement, inhibition breaks the connection between the alarm stimulus and the alarm state.
Alarm Suppression: With the alarm model in mind, we have the ability to break the connection between the alarm state and the alarm annunciation. The alarm still occurs and is stored/logged, but is not visible in the Alarm Display.
To Configure Alarm Inhibition
Open the Tagname Dictionary (Special / Tagname Dictionary).
Select an existing tag.
Click OK.
Select the Details & Alarms option.
Click the Ellipsis button in the Alarm Inhibitor column of one of the Alarm Value rows (LoLo, Low, High, HiHi).
The alarm inhibition can be based upon any non-Message tag. In this example, a Memory Discrete tag-type is used. When the tag value becomes true, it will trigger the inhibition.
Select the tag, and click OK.
The Tagname Dictionary appears with the new inhibition tag filled in:
Click Save, then click Close.
Disabling Alarms
The Alarms view of the Tagname Dictionary may be used to access a tag’s .alarm enabled dot field. This dot field can disable alarming for an individual tag, or for an alarm group.
Note: Disabling the alarms for an Alarm Group disables ALL alarms in that group.
Note: Additional dot fields are available for alarm configuration. For a complete list of dot fields refer to the InTouch Reference Guide.
Configuring the Alarm System
You can configure various parameters for the alarm system such as whether to enable events, whether alarms require an acknowledgment when they return to normal, and so on.
The configuration dialog box behaves like any standard Windows property sheet in that no settings are recorded until you click OK. If you click Cancel, all input is ignored and the dialog box closes.
Alarm/Event General Properties
Select Special / Configure / Alarms from the main WindowViewer menu. The Alarm Properties dialog box appears:
Configuration Options:
Alarm Buffer Size: The number of in-memory alarm events you want WindowViewer to maintain.
This number represents the maximum number of alarms that the node can store for summary or historical queries.
Note: Only in-memory alarm events can be displayed in alarm display objects. If alarms are not being used, this value may be set to 1 to conserve memory.
If you set this value too high, it can slow down the performance of your system. For the Distributed Alarm System, the default value of 500 is recommended.
RTN implies ACK: Automatically acknowledges alarmed tags that return to the “normal” state (RTN). Do not select this option if you want the operator to acknowledge an alarm after it returns to normal. (RTN Implies ACK does not apply to tags with Expanded Summary ACK model.)
Events Enabled: Turn on event logging of all data changes that are initiated by the operator, I/O, QuickScripts, or the system. (Only tagnames with Log Events selected will be affected.)
Alarm Enable Retentive: State of the .AlarmEnabled variable to be retained when WindowViewer is closed and restarted. Retain ACK Comment as Alarm Comment: Custom comments are to override the alarm comments. Otherwise, alarm comments from the Tagname Dictionary will be used.
Also Read:-