A historical trend trigger is the definition of an event along with a list of data to be recorded when that event is triggered.  An event is triggered when a set of variables meet some prescribed conditions.  In an aluminum smelting plant, for instance, a trigger could be defined to capture data during an anode effect.  The trigger could watch for when the pot resistance gets too high, and when it does record a set of data including the pot resistance, volts, and line amps.  Once this trigger is configured in the historical trend system, all anode effect events would be captured to individual historical trend files on disk for later review.  

Once a trigger has been activated, the historical trend trigger system monitors each of the trigger conditions and continuously evaluates each of them to determine when they have all been met. During this time the trigger is Waiting for trigger event detection.  If this occurs, and all trigger conditions are met, then data collection begins and the trend system begins to write data to the file.  This will continue until the trigger conditions are no longer all met.  At this point the data file is closed and left on the disk for later review.

Several options are available to enhance data collection:

• A pre-trigger time period may be configured so that when a trigger event is detected the trend system will actually go backwards in time to retrieve the data leading up to the event and save this in the historical trend file before the data for the event itself.  In many cases this information is crucial for determining the cause of a given event.

• A post-trigger time period may be configured so that once the trigger conditions are no longer satisfied the trend system will continue to record data for a period of time and append it to the historical trend file after the data for the event itself.  In many cases this information is useful for determining how the control system reacts after a given event.

• A maximum trend time period may be specified to keep file sizes small and manageable.  This value limits the maximum amount of time of historical data that can be stored in a single file; if the event lasts longer than this amount of time then the data recorded for that event will span multiple files.  This option is useful for continuously recording data (i.e. the event is defined as always triggered) and generating files of finite size.

Triggers can be created, modified, activated, and deactivated using the TriggerMgr [LINK] screen.

Historical trigger files are stored on the host as ASCII text files.  Following is an example file:

[Trigger]
Name=TrackTime
Description=Record the drift constants for the time tracking algorithms.
TagVar=PidCom.rtDrift.filtDrift
PreTriggerTrendTime=30
PostTriggerTrendTime=45
MaxTrendTime=1440
SaveDate=127592326792807993
 
NumTriggerVars=2
TriggerVar0=/TrendGsm/PidCom.rtDrift.bTrack != 0
TriggerVar1=/TrendGsm/PidCom.pcDrift.bTrack != 0
 
NumTrendVars=4
TrendVar0=/TrendGsm/PidCom.rtDrift.filtDrift   PidCom.rtDrift.filtDrift
TrendVar1=/TrendGsm/PidCom.rtDrift.instDrift   PidCom.rtDrift.instDrift
TrendVar2=/TrendGsm/PidCom.pcDrift.filtDrift   PidCom.pcDrift.filtDrift
TrendVar3=/TrendGsm/PidCom.pcDrift.instDrift   PidCom.pcDrift.instDrift

NumScalarVars=2
ScalarVar0=PidCom.rtDrift.filtDrift   PidCom.rtDrift.filtDrift
ScalarVar1=PidCom.rtDrift.instDrift   PidCom.rtDrift.instDrift

The trend manager process is responsible for initializing the trending subsystem, creating the trend global shared memory, configuring the various trend sources, and processing requests for dynamic trend variables.  In addition, TrendMgr monitors the active trends, periodically writing trend data from the memory buffer to the disk for long-term storage and disabling dynamic variables after a specified period of inactivity.  The trending subsystem is configured via an ini file, which is read by the TrendMgr process on initialization.  This file defines each of the various trend sources such as the global common trending process TrendGsm.  

The trend manager process is initialized by a text file passed to it as a command line parameter.  This file is used to configure the internals of the trending subsystem itself.  It consists of several sections described below:

[General]
This section specifies the general parameters for the trending subsystem.

• MaxTrendSrc=2
  Specifies the maximum number of trend sources in the system. The minimum value is 2, which will support both the internal test trend source and the TrendGsm global shared memory data collection trend source. This is sufficient for most systems.

• MaxTrendVar=512
  Specifies the maximum number of trended variables in the system. This number must be larger than the total of the number of static trends, dynamic trends required by historical triggers, dynamic trends required to support various TrendX clients, and additional trending slots required as 'maneuvering room' for adding and deleting various dynamic trends during operation.  Since most of these values aren't known up front, it is recommended that this number be chosen to sufficiently cover the worst case scenario.

• TrendComSizeMB=30
  Specifies the maximum size of the trend global common in megabytes. The trending system requires that the entire trending global common be locked in memory, so this number specifies the amount of available physical RAM that will be allotted to the trending subsystem.  If this number is too small given the maximum number of trended variables specified above, the TrendMgr process will not start but will provide suggestions (via the console LogMsg) for settings that provide adequate space.

• TempDir=\locNtRt\sys\Temp\
  Specifies a temporary directory for the trending system. This directory is used to contain trended data that has been paged to disk, as well as the trending common image for persisting trend data between system shutdown and restart.

• TriggerDefDir==\locNtRt\sys\Trigger\Def\
  Specifies the storage directory for trigger definitions. This is not required if the historical trend subsystem is not installed.

• TriggerTrendDir==\locNtRt\sys\Trigger\Trend\
  Specifies the storage directory for historical trend files. This is not required if the historical trend subsystem is not installed.

• PersistTrends=No
  Specifies whether or not to persist trended data between system shutdown and restart.

[TrendSrcList]

This section specifies the various trend sources configured for a given system.  Each trend source is specified on a single line in this section; this line contains a white space-delimited list of parameters defining the trend source.  Most systems will only have a single entry for the global common trending system, TrendGsm.

The parameters in order are:

• SourceName
  Specifies the name of the trend source.  This name is used to fully qualify a trended variable.

• AllowTemp
  Specifies whether or not the trend source allows temporary (dynamic) variables to be added at runtime.

An example configuration entry for the TrendGsm source is provided below:

#SourceName       #AllowTemp

TrendGsm          1

This hard real-time process samples variables from global common at frequencies up to 50 Hz (20 ms per sample) and buffers their values into memory. Static trend variables are defined through an ini file, which specifies each global variable’s fully qualified name, sampling period, and the number of samples to be stored both in memory and to disk.  Alternatively, dynamic trend variables may be requested at any time during system operation and the TrendGsm will begin buffering the appropriate data. 

The TrendGsm process is initialized by a text file passed to it as a command line parameter. Typically, this file is the same as that used to initialize the trend manager process and containing additional sections for the TrendGsm process. The initialization file parameters are described below:

[TrendGsmVars]

This section specifies the list of statically trended variables for the TrendGsm process. Each variable listed in this section will be trended at all times as long as the TrendGsm process is active. Each statically trended variable is specified on a single line in this section; this line contains a white space-delimited list of parameters defining the trended variable.

The parameters in order are:

• VariableName
  Specifies the data dictionary name of the variable to be trended.

• SamplePeriod(ms)
  Specifies the sampling period of the variable in milliseconds. This number cannot be smaller than the rep rate of the TrendGsm process as specified in the sysProcs.ini file.

• MemPeriod(s)
  Specifies the size of the circular buffer (in seconds-worth of data) that will be stored in memory before the data is paged off to disk. This number must be greater than zero. If DiskPeriod is zero, this number dictates how far back into the past live data will be stored before it is destroyed.

• DiskPeriod(s)
  Specifies the size of the circular buffer (in seconds-worth of data) that will be stored on disk. If this number is zero, no data will be stored on disk. Otherwise this number must be greater than the MemPeriod and dictates how far back into the past live data will be stored before it is destroyed. 

The trend server process accepts TCP/IP connections from remote clients and handles their requests for trended data.  Trended data is requested by source and variable name at a given sampling rate and between a starting and ending time.  The TrendSrv process searches for the requested variable on the list of currently trended variables, returning the desired data if found.  If the variable is not currently being trended, TrendSrv passes a request for dynamic trend to the specified trend source and returns no data; subsequent client requests for this variable will thereafter return whatever data is available.

• Operates as a TCP/IP server process

• Server services requests to port 2250

• Runs at standard or real time 2000 priority

• Does not run at a Hard Real-Time priority

• Receives and processes connection request from client

• Receives requests for set of trend data

• Saves request information associated with a channel for use as defaults for following data requests

• Responds to requests with requested trend data

• Waits in loop for further data requests