Configuring Tag Historian
Setup Tags to Log
Logging data is easy with Tag Historian. Once you have a database connection, just set the tags to store history. Ignition creates the tables, logs the data, and maintains the database. To learn how to log history for your tags, go to Set up Tags to Log.
You must first install the Tag Historian module so that the standard Tag Historian features are added to Ignition and the Historian Providers show up in the Historian Configuration section of the Gateway.
Tag Configuration and Historical Value Generation
The first step to storing historical data is to configure tags to report values. This is done from the History page in the Tag Editor in the Designer. The properties include a historical scan class, that will be used to check for new values. Once values surpass the specified deadband, they are reported to the history system, which then places them in the proper store and forward engine.
Add History to Tags in a UDT
Setting up UDTs to log history data works on the same principle as creating UDTs. You dramatically reduce the amount of work when setting up UDTs to log history data so that all instances of that UDT will log data without having to edit each individual instance. To learn how to set the UDT to log history, refer to Add History to Tags in UDT.
Historian Providers
The settings for the Tag Historian providers are in the Gateway under Tags > History. Historian providers are automatically created and removed according to the configured database connections. By default, they are created with a one month partition size, and will not delete old data.
You can configure the Database Tag History Provider in the Configure section of the Gateway by going to Tags > History. A History Provider is created automatically for each database connection, and will be removed if the connection is removed. Although enabled by default, the providers won't interact with the database unless data is logged to them.
Historical Tag Provider Properties
Below are the properties available on the Historical Tag Provider.
Main |
|
|
Data Connection |
Name of the Data Connection for the Tag History Provider. |
|
Enabled |
If the check box is selected (enabled), the provider is turned on and accepts tag history data. If disabled, the database is not shown in the list of history providers when configuring tag history from the Designer. Also, any data logged to the provider, will error out and be quarantined by the store and forward engine, if possible. |
Data Partitioning |
|
|
Enable Partitioning |
To improve query performance, Tag Historian can partition the data based on time. Partitions will only be queried if the query time range includes their data, thereby avoiding partitions that aren't applicable and reducing database processing. On the other hand, the system must execute a query per partition. It is therefore best to avoid both very large partitions, and partitions that are too small and fragment the data too much. When choosing a partition size, it is also useful to examine the most common time span of queries. |
|
Partition Length and Units |
The size of each partition, the default is one month. Many systems whose primary goal is to show only recent data might use smaller values, such as a week, or even a day. |
|
Enabled Pre-processed Partitions |
Pre-processed partitions will use more space in the database, but can improve query speed by summarizing data, reducing the amount that must be loaded. |
|
Pre-processed Window Size (seconds) |
When pre-processing is turned on, the data will be summarized into blocks of this size. |
Data Pruning |
|
|
Enable Data Pruning |
Partitions with data older than a specific age are deleted. The check box is not selected/enabled by default. Important: Data pruning works by deleting old partitions. Therefore, data will only be removed when a partition has no data younger than the prune age. |
|
Prune Age and Units |
The maximum age of data. As mentioned, the data is deleted by the partition, and could therefore surpass this threshold by quite a bit before all of the data in the partition is old enough to be dropped. |
Advanced |
|
|
Enable Stale Data Detection |
If enabled, tracks scan class executions to determine the difference between unchanging values, and values that are flat due to the system not running. |
|
Stale Detection Multiplier |
The multiplier for scan class rate used to determine when values are stale. If scan class execution is not recorded within this amount of time, values will be considered bad on query. |
Table Partitioning
Ignition has the ability to automatically break up data into different tables of fixed duration. This can help make data maintenance easier, by preventing tables from becoming too large. Tables can easily be deleted in order to prune old data, and the database is able to better optimize access to frequently retrieved rows. The built-in partitioning feature can be used with any database.
It is important to note the difference between this feature and any partitioning options that the database might provide. Most modern databases offer their own faculties for defining "partitions", offering similar and greater benefits. While Ignition cannot use these features directly, advanced users may choose to apply these features on top of what Ignition currently offers.
Data Compression
As mentioned above, Ignition does not perform any binary compression on the data. That is, values are stored directly in standard database tables. However, to reduce the number of values stored, Ignition offers two different algorithms for pre-compressing the data (trimming unnecessary values). The two modes correspond to the value mode property of the tag. The value mode (Discrete or Analog) dictates the type of value that the tag represents, affects how the deadband is applied to values, and how interpolation is performed when querying.
-
Discrete
The value uses a simple deadband and is only stored when a new value is + /- the deadband value away from the previously stored value. -
Analog
The deadband is used to form a corridor along the trajectory of the value. A new value is only stored when it falls outside the previous corridor. When this occurs, the trajectory is recalculated and a new corridor is formed.
Typically, Discrete is used for boolean or integers that represent state, and Analog is used for floats or integers that change more often (which is why you want to perform compression).
You choose and set the Value Mode on the History section of the Tag Editor window.
While advanced users can change the table according to their database to be more efficient (for example, using a compressed engine), Ignition does not perform binary compression or encrypt the data in any way. See Value Mode, in History Properties for more information about the difference between Discrete and Analog values.
Store and Forward
The Store and Forward system provides a reliable way for Ignition to store historical data to the database. The Store and Forward system is not exclusively part of Tag History, but systems such as the Tag Historian and Transaction Groups use this to prevent data loss and store data efficiently using a record cache.
It is important to configure your Store and Forward system when using tag history. For more information, see the following sections:
In This Section ...