About Events

You can use the Historian Server event subsystem to detect events and associate actions when they are detected. At a basic level, anything that can be determined by examining stored data can be used as an event. The event subsystem can be configured to periodically check to see if an event occurred. This is called event detection.

Event Subsystem

The event subsystem performs the following basic functions:

• Detects when events occur by comparing sets of criteria against historical data in the database

• Optionally logs event records to a dedicated SQL server table (EventHistory)

• Optionally triggers a configured action each time an event occurs

The event subsystem does not support Daylight Savings Time changes. The replication subsystem, however, does handle Daylight Savings Time changes, and you can use replication to generate data summaries according to a schedule.
The event subsystem is not designed to transfer data to and from the database continually and should not be used in this manner. The only exception is for summary actions; the event subsystem can continually process data aggregates so that they are available for reporting purposes.

The event subsystem is not a real-time system; rather, it operates on historical data. For real- time alarming, use an application such as InTouch or Application Server. The event subsystem is intended to initiate actions based upon historical event detection. An alarm system presupposes an immediate message response is propagated for all configured alarms at the time the respective conditions are met. In this sense, the historian event subsystem is not an alarm system. The event subsystem queues up detected events and processes them accordingly based upon preconfigured priorities.
 
The following table describes the components of the event subsystem:

Component	Description
Configuration Editor	Part of the ArchestrA System Management Console. Used to set up event definitions and possible actions.
Runtime database	Stores event definition information and all data generated by the event subsystem, such as records of event detections, data summaries, and data snapshots
Event System Service (aahEventSvc.exe)	Internal process that coordinates the event detection and action functions. This process runs as a Windows service. Using the System Management Console, you can configure the event service to automatically start and stop at the same time as Historian Server. The event service is responsible for: l Reading event definition information from the Runtime database l Creating event detectors and actions, including allocating the necessary processing threads and establishing database connections l Initiating the event detection cycle
SQL variables	Available for use in event queries

 
You use the System Management Console to configure the event subsystem.

You can obtain a number of distinct operational benefits from properly using the features of the event subsystem. Key benefits are:

• Unlike real-time alarming, the event subsystem determines events from stored historical data and is not dependent on real-time detection. No events are missed unless the machine is severely overloaded for a long period of time.
• The event subsystem is SQL-based, thus providing a means of managing database- related tasks within the system. You can use custom SQL queries as detectors, as well as create custom SQL-based actions.
• A number of preconfigured detectors and actions are available.
• Detections may be made by external sources. (A COM mechanism is available for invoking the detector in the event subsystem.)
• Time-based detection (based on the system clock time) allows you to schedule certain tasks, such as data aggregations (summaries).
• The event subsystem is designed to manage overload situations. If the system is currently busy due to some other processing for a period of time, the event subsystem will catch up at a later time during off-peak periods. If the overall Historian Server is continuously overloaded, the event subsystem degrades in functionality gracefully.
• You can select which actions have priority and can assign certain actions (preferably only a few) never to be compromised, even under overload conditions.
• System tags are available to monitor event subsystem conditions.

Latency in Event Configuration

The detection of an event may occur significantly later than the actual time that the event occurred, depending on the value you specify for the time interval. The time between when an event actually occurred in history and when it was detected is called latency. Latency is important when you want to quickly trigger an action after an event occurs.
For example, if you created an event that detects when an instrument is starting to send non- normal values, you would want an action to notify you to check the instrument as soon as possible. You would create an event tag for this with a short time interval (scan rate) so that the event system would frequently check to see if this event has occurred.
Other events (for example, when an operator ended a shift) are not as critical and latency is not as important.
Use caution in assigning time intervals to event tags. Too many event tags assigned to the same time interval may result in detector overruns. While this should not have a negative impact on actual detection of events, it may add to increased latency. Also, assigning short time intervals will result in higher CPU loading and may lead to degraded performance.