The History feature
- Last UpdatedDec 17, 2024
- 5 minute read
Any attribute that exists at run time and is not already historized can be configured with a history Feature.

A history Feature can be added to a template or an instance attribute. If added to a template attribute, the existence of the history Feature is automatically locked in derived objects.
You can configure Writeable and Calculated attributes of the following data types with a history Feature:
-
Float, Double (stored as a Float)
-
Integer
-
Boolean
-
String stored as Unicode, 512 character limit
-
Custom Enumeration stored as an Integer
-
ElapsedTime stored as seconds
You can configure the following attributes for a history Feature:
|
History Feature Attributes |
Description |
|---|---|
|
Description |
The attribute containing the description string, if any, associated with the attribute being configured. Enter the attribute manually, or use the browse button to open the Galaxy Browser to find a specific attribute. Example: For the description associated with Attribute001 that has been added to object Reactor31, you would enter or browse to "Reactor31.Attribute001.description". The description also can be a simple string without reference to an attribute. |
|
Force storage period |
The Historian normally stores values by exception. The force storage period is designed for situations where data is expected to change very infrequently, compared to the engine scan rate, for examples, setpoints and values which only toggle in abnormal cases. The force storage period sets a length of time, in milliseconds, after which the value must be historized, even if the value has not changed, or has not changed more the the Value deadband. Setting the value to 0 disables the parameter. Example: A setting of 3600000 (60 seconds/minute x 60 minutes/hour x 1000) will force the value to be stored once per hour (if the value remains unchanged), as measured from the time the object was last put onscan. The force storage period should be long relative to the AppEngine scan cycle. If the force storage period is shorter than the scan cycle, forced storage will occur at every scan period, as the value change is not recorded until the scan takes place. When the storage period is set to a value greater than the scan period and there is no change in value, or if the change in value is less than the Value deadband, the forced storage period artificially updates the timestamp on the previous (unchanged) value, and allows the Historian to store that value again with the artificial timestamp. In most cases, that is, in cases where a change in value occurs, values are associated with the timestamp from the source system (e.g., PLC), and that time is applied to the historized values. On the other hand, if a value is historized because of the force storage period, the value is instead stored with the system time of the engine scan when the force storage period was exceeded. Factors such as communications latency, clock differences, and detailed engine timing can result in force storage values being historized out of order or overlapping with those values historized due to value changes. It is also possible that the timeout for the forced storage period may coincide exactly with the timestamp of an actual exception update from the instrumentation. If this occurs, both values are stored with the associated timestamp. To avoid this, disable (set to 0) the force storage period in cases where the value normally updates frequently. In cases where the value rarely changes, set the force storage period to a much longer time period, for example, to a value between 1 and 48 hours (3600000 to 172800000 ms). |
|
Value deadband |
The threshold value, measured in engineering units, that the absolute value of the difference between the new and last-stored values must differ before storing the new value to history. The value deadband is intended to filter out low-level noise in the signal so that only significant changes are historized. When a value deadband is set, value changes that are within the value deadband will not be historized. Therefore, you should only specify a value deadband when the reduction of processing and storage overhead is more important than completeness of the data. If you choose to set a value deadband, the value should be set to as small a value as possible. The value should be based on how large (or small) the changes in value that are expected. A value of zero (0) is valid and means that any level of change results in the new value being stored. A change in Quality always causes a new record to be stored, regardless of whether the Value has changed. When combined with the Force storage period, new values are compared with the last historized value, regardless of whether the the previous value was historized because it exceeded the value deadband or exceeded the force storage period. |
|
Trend high |
The default top of a trend scale. This value must be greater than or equal to the low value for the trend. If this value is changed at run time, the maximum engineering unit change is not reflected in the HIstorian until you redeploy the object. This attribute applies only to numeric data types. |
|
Trend low |
The default bottom of a trend scale. This value must be less than or equal to the high value for the trend. If this value is changed at run time, the minimum engineering unit change is not reflected in the HIstorian until you redeploy the object. This attribute only applies to numeric data types. |
|
Enable swinging door |
Enable and provide a valid swinging door rate deadband and the force storage period becomes the deadband override period. Boolean or string data types cannot be configured with a swinging door deadband. |
|
Rate deadband |
Available only if swinging door is enabled. The percentage rate of change deadband based on the change in the slope of incoming data values to the HIstorian. Example: A swinging door rate deadband of 10 percent means that data is saved to the HIstorian if the percentage change in slope of consecutive data values exceeds 10 percent. Default is 0.0, which indicates a swinging door rate deadband is not applied. Any percentage greater than 0.0 can be assigned to the rate deadband. |
|
Interpolation type |
The method used by the Historian to interpolate analog historical data. The interpolation type determines which analog value is selected during a Historian ata retrieval cycle. Select an Interpolation type: System Default: The HIstorian system-wide interpolation setting is used. The system-wide setting must be either stairstep or linear interpolated. Stairstep: The last known value is returned with the given cycle time. If no valid value can be found, a NULL is returned to the HIstorian. Linear: HIstorian calculates a new value at the given cycle time by interpolating between the last known value prior to the cycle time and the first value after the cycle time. |
|
Rollover value |
A non-negative numeric value that represents a tag’s reset limit when the Historian operates in counter retrieval mode. In counter retrieval mode the Historian uses a tag's rollover value to calculate and return the delta change between consecutive retrieval cycles. The default value is 0.0. Boolean and string data types cannot be configured with a rollover value. |