Topic 1.1.2 – Event Tag Definitions
About Event Tags
An event tag is a name for an event definition in the system. For example, if you wanted to detect an event when a tank temperature reaches 100 degrees, you can define an event tag and name it TankAt100. Event tags differ from all of the other tag types in Historian Server (analog, discrete, and string). Analog, discrete, and string tag types are the definitions of variables to be stored..
When you define an event tag, you must specify:
- Name, description, and other general configuration information
- Event criteria, which describes the conditions that must exist for the event to occur and how often the event subsystem will check to see if the event has occurred
- Whether or not to log the event detection
- Whether or not to enable or disable event detection
- Optional action that is triggered when the event is detected
Each event tag has an associated event detector. An event detector is a mechanism for determining when the set of event criteria for an event tag has been satisfied. When you configure an event detector, you must first configure its type and then configure the parameters associated with that detector type. You can choose from the following types of event detectors:
- SQL-Based Detectors
- Schedule Detectors
- External Detectors
SQL-Based Detectors
Analog specific value, discrete specific value, and generic SQL detectors operate on data stored in the database. The detection criteria for each of these detectors is an SQL statement that is executed against the Historian Server. Generic SQL detectors can query against both the historian and Microsoft SQL Server.
For SQL-based detectors, you must specify a time interval that indicates how often the detector will execute. The time interval is very important in that it affects both the response rate of any event actions and the overall performance of the system.
Generic SQL Detectors
A generic SQL detector detects an event based on criteria that are specified in an SQL statement. You can use preconfigured SQL templates that are stored in the database as the basis for your script, or you can create your own script from scratch.
To use a preconfigured SQL template, simply select it from a list of available templates when defining the event tag.
Specific Value Detectors
Two specific value detectors are available:
- Analog specific value detector
- Discrete specific value detector
These detectors can be used to detect if a historical tag value matches the state defined by the detector criteria. For the criteria, historical values are compared to a target value that you specify. If a value matches the criteria, then an event is logged into the EventHistory table, and any associated actions will be triggered.
|
Edge Detection Option |
Results |
|
None |
Returns all rows that successfully meet the criteria. No edge detection is implemented as the specified resolution. |
|
Leading |
Returns only rows that are the first to successfully meet the criteria (return true) after a row did not successfully meet the criteria (returned false) |
|
Trailing |
Returns only rows that are the first to fail the criteria (return false) after a row successfully met the criteria (returned true) |
|
Both |
Returns all rows satisfying both the leading and trailing conditions |
Schedule Detectors
The schedule detector is a time-based detector. A schedule detector detects whether the system clock is equal to or greater than a specific date and/or time.
External Detectors
For an external detector, event detection is triggered from an external source by the ActiveEvent ActiveX control that is provided as part of Historian Server
An event may or may not be associated with an event action. Event action is triggered after the event detector determines that the event has occurred. The event subsystem is not intended to run external processes. There is only a very limited ability to run external program files or to call methods from COM interfaces within the given system or network.
Historian Server is shipped with the following preconfigured event actions:
|
Action |
Description |
|
None |
Does not perform any action as a result of event detection. There are times when you may want to simply store when events happened. |
|
Generic SQL |
Executes an action that is outlined in a SQL statement. For example, an SQL action can update the database (such as turning off storage for tags), or copy data to a separate table or database. You can use preconfigured SQL templates that are stored in the database as the basis for your script, or you can create your own script entirely from scratch. |
|
Snapshot |
Logs into dedicated SQL Server tables the data values for selected analog, discrete, or string tags that have the same timestamp as the detected event. Quality is also logged. Value snapshots are stored in tables according to the tag type, either AnalogSnapshot, DiscreteSnapshot, or StringSnapshot. A snapshot action requires an expensive SQL join between the extension tables and the snapshot tag table. The process of performing the join and logging the retrieved results to the snapshot tables can be very slow. This is because most of the tables used for event snapshots are normal SQL Server tables, subject to the data processing limitations of Microsoft SQL Server. Thus, the higher the number of snapshots that are being taken by the event system, the higher the transaction load on the Microsoft SQL Server. |
|
|
Sends a preconfigured Microsoft Exchange email message. Although email actions are useful for sending non-critical messages triggered by event detection, these types of actions are not to be used for alarm-type functionality. |
|
Action |
Description |
|
Deadband |
Changes the time and/or value storage deadband for one or more tags that are using delta storage. (Value deadbands only apply to analog tags.) Deadband change actions are useful for increasing data storage based on an event occur- ring. For example, an event detector has detected that a boiler has tripped, you might want to start saving the values of certain tags at a higher rate to help you determine the cause of the trip. |
|
Summary |
A set of aggregation calculations to be performed on a set of tags between a start time and an end time with a defined resolution. When you configure a sum- mary action, you must define the type of aggregation you want to perform (called a summary operation) and the analog tags that you want to be summarized. The event subsystem performs average, minimum, maximum, and sum calculations on the basis of a specific event being detected. Note: Summary actions using the event subsystem are retained for backward compatibility. We recommend that you use the more robust and flexible replica- tion subsystem to perform data summaries. Data summaries are useful for: Extremely long-term data storage. Because summarized data takes up less space than full resolution data, even a moderately sized system can store daily summary information for many years. Production reporting. For many reporting purposes, aggregate data is more important than raw data. For example, the total mass produced in a day is often more relevant than the actual rate of production during the day. Integration with business systems. The full resolution, high-performance Historian Server history and real-time data tables are best accessed with tools that can take advantage of the Historian Server time domain extensions. However, not all client tools support these SQL extensions. The summary tables reduce the volumes of data to manageable quantities that can be used by any normal SQL client application. |
Event Action Priorities
The event subsystem contains three different queues for event actions.
- Critical queue – Contains any actions for event tags that have been assigned a critical priority.
- Normal queue – Contains any actions for event tags that have been assigned a normal priority.
- Delayed Action queue – Contains any actions for event tags that have been assigned a post-detector delay.