About the Historian module
The Tag Historian module provides several tools to manage, collect, and store time-series data. It offers a robust solution for storing tag values and their corresponding timestamps in SQL or third-party time-series databases. Data Logging is essential for many industrial processes, collecting and storing data in the context of its time frame. Typically, users utilize this data to create trend charts, perform data analytics, monitor performance, ensure regulatory compliance, manage operations, and control processes.
This module provides an out-of-the-box solution for archiving historical data without programming requirements. It provides users with flexibility in terms of storage options and advanced features. While you can include additional custom data logging procedures in your project using Scripts (.NET programming) and Datasets (SQL storage), the Historian module's standard configuration tools can fulfill most typical data logging requirements.
It leads to improved efficiency, increased productivity, and reduced downtime, resulting in a more profitable and sustainable industrial operation.
On this page:
Purpose and Key Concepts
The Historian module ensures that essential process data is securely stored and easily accessible for analysis and decision-making. Organizations can monitor equipment performance, optimize processes, track trends, and improve efficiency by collecting and storing time-series data.
To understand how to configure and execute the Historian module is essential to understand the following concepts:
Target Database
Target Database, in the context of the Historian Module, defines the debase where variables will be archived, or read to be used in charts and calculation. The Target Database can be any SQL Database (SqlLite, Microsoft SQL, ProgressDB and others, or, using the TagProvider Extensibility, it can also use third-party products designed to store long-term time related values, known as time-series databases or Historian tools (Canary, InfluxDB, OSIsoft PI).
The Historian Module allow allows to use the Script Module, to processes requests for archiving and retrieving data, as if it was a virtual database. The configuration of the Target Database for the Historian Module is performed at the Project Explorer, under the section Historian → TargetDB
Historian Table
The Historian table is a logical organization that groups Tags for historical archiving. Each HistorianTable has a definition of which Target Database the group of Tags will be archived. You can also configure other standard settings that apply to all tags in that group in the HistorianTable, such as when to save new data or how long to keep the data. The HistorianTable is a logical grouping to expedite and simplify the configuration, not necessarily corresponding to a table in the Target Database; different targets have their archiving structures. The configuration of the Historian Tables is in the Project Explorer, section Historian → Tables.
Historian Tag
The variables grouped in a HistorianTable are typically Tags defined in this platform. However, you can also include dynamic references to external data using the TagProvider functionality. Therefore, across the documentation, the generic term Historical Item refers to any value contained in a HistorianTable to be archived, whether an internal Tag or an external data reference.
How the Historian module works
In this section we present the summary on the execution of the Historian Module, including:
- The Archiving Process
- Events to start the archiving
For a detailed Historian execution explanation, check Arching process.
Archiving process
The module Historian process to archive data is composed of 3 steps:
Step 1. An Event starts the request to archive the value of a group of variables.
There are two types of events (Trigger or TagChange). The events that start the archiving are configured in the Historian Tables section, and the variables that are archived in response to that event are configured in the Historian Tags section.
Step 2. The Historian archives the values in the Target database.
The Target Database can be a SQL Database or a third package, like Canary, InfluxDB, configured to act as a historian.
Step 3. If Store and Forward are enabled, the data synchronization is executed.
With this option, if the Target Database is unavailable, the data is stored in a local database and sent to the target when it becomes available.
Events to start the Archiving
Trigger
The Trigger can be a Tag Value, a Tag Property, or any object from the runtime namespace (e.g., server.minute will save data every minute). When a value change in the object is detected, the archive request event is generated. Only Tags of server domains or objects residing in server-side namespaces can be used as Triggers since the Historian process runs on the Server computer. The Trigger is configured in the Historian Table. All tags and objects connected to that HistorianTable will be requested to be archived, regardless of having or not a new value.
Tag Change
The Tag Change is a checkbox on the TableHistorian configuration. When enabling the Tag Change checkbox, the Historian process will verify all tags connected to that Historian Table. When the tag has a new value, the archive request event is generated. The request to archive will be generated only for the Tag with a new value. But, according to the Historian Target Database, only the tag or all tags in the group with be archived. Further information on that is included in the next section of this page.
Configuring the Historian module
Configuration workflow
The typical configuration workflow for the Historian Module has the following sequence:
| Historian module configuration workflow | ||
|---|---|---|
| Action | Where | Comments |
| Define the default TagHistorian SQL Database | Historian → TargetDB | By default, TagHistorian maps to a SQLite database named the same as the Project Name. Modify it as needed. |
| If using Canary, modify the default target to the the Canary Historian | Historian → TargetDB | If using Canary, a connection with the local embedded Canary Historian is already included in new project. Just use that connection, or modify it willing to connect an external Canary System instead. |
| If necessary, add other Target Databases | Historian → TargetDB | If archiving or retrieving data from other Historian tools is necessary, such as InfluxDB or OSIsoft PI, add the connection in the Tag Providers, making sure to setup the "Historian Provider" checkbox. |
| Create and Edit HistorianTables | Historian → Tables | Add or modify HistorianTables, organizing how the Tags will be grouped for archiving and the Target Databases. |
| Add Tags to the HistorianTables | Historian → Tags | Connect Tags to the Historian tables. Either by typing, browsing, pasting or any of the available import methods. |
Default Target Database
By default, when a new project is created, the TagHistorian is defined to use the built-in embedded SQLite database, as defined in the Datasets module.
The Historian Target Database can be selected among the following options:
| Historian Database options | |
|---|---|
| Target Database | Description |
| SQL Database | Any SQL style database, defined in the object TagHistorian on Datasets → DBs. |
| Canary Historian | Embedded CabaryLabs engine included in the framework, or connection with external Canary systems. |
| TagProvider Historian (InfluxDB, OSIsoft PI) | Using TagProvider, connect with third-party products that can act as native, fully integrated historian repositories.In addition to current interfaces, additional products can be easily added using the driver toolkit. |
The SQLite database may be used for databases up to around 10GB. If the amount of tags and the save interval is expected to create more than that, it is recommended to use another SQL database for the Tag Historian or the Canary Historian, or any of the available TagProvider Historian target.
To define another SQL Database to the TagHistorian connection, refer to the Dataset module configuration.
To define other Tag Provider Historian targets, refer to the Tag Provider configuration.
Configuring Historian Tables
By default, there is one HistorianTable created using Dataset-TagHistorian SQL as the Target Database, and if Canary Historian is enabled, another HistorianTable using Canary target.
The settings on the HistorianTable provide rules for saving the tags connected with HistorianTable. You can set a trigger that determine when tags will be saved — a time deadband that defines the minimum interval between saves, and a lifetime value that determines how long the saved tag values will be retained. According to the target database selected, some options may not be available.
It is a good practice to store only the data that is necessary, and with the time frequency that your process requires. Using features as headbands, OnTagChange or Trigger events, you organize your storage to save what is needed, without overload the system or slowing the data recovery.
HistorianTable configuration fields
New HistorianTables can be create with the NEW button, on Tags → Historian, or editing the table on Tags → HistorianTables.
To modify History Tables, on Tags → Historian, select the Table in the ComboBox and Config button, or editing the datagrid on Tags → HistorianTables.
Either using the Dialog view or datagrid view, the HistorianTable has the following configuration fields:
HistorianTable configuration properties | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Field | Description | ||||||||||||
Target | Defines the Historian Target Database. By default, SQL or Canary, or other TagProvider Historian connections. Historian Target Database According to the Target Database selected in this field, some other fields on the configuration may be disabled | ||||||||||||
Table Name | Name of the HistorianTable object. For SQL databases, this name is also the table name inside the SQL DB. For other databases, this name is used as a logical grouping name.. | ||||||||||||
Auto Create | When checked, Historian module will check if this table is already created in your SQL DB. If not, a new one will be created. | ||||||||||||
Save on Change | When checked, whenever your Tags value has changed, the event to archive the tag is generated. | ||||||||||||
Trigger | Here you can define the event that triggers the archiving of all the tags in the HistorianTable group to the database. The trigger can be any tag, or any object or property from the objects namespaces. For example When you click on "…" elypses button, a window will appear listing your Tags, Objects and Properties, allowing to select which one will act as a Trigger. | ||||||||||||
TimeDeadband | Enter the minimum logging interval. You must define in this format HH:MM:SS:MS (Hours, minutes, seconds, milliseconds). If left with zeros, this setting is not used. This is how long the system must wait after storing one value of a tag, before storing a new value. This field is used in conjunction with SaveOnChange option to avoid creating too many records in the database. For example Consider that you have a 5 seconds Deadband, the Deadband count will start when your Tag value changes. When Deadband count starts, any changes in Tag value in this range will not be saved on your DB if the time dead-end has not elapsed yet.. Your Tag’s value will only be saved in DB after TimeDeadband ends.
| ||||||||||||
Life Time | Here you can set in days how long the records will be stay on the Target Database. Every day, if the Historian Modules find data on the HistorianTables older than the lifetime, that data is automatically deleted. If its the value is 0 or blank, no automatic data deletion is executed. Data is no longer automatically deleted. | ||||||||||||
Save Quality | When checked, a column in your SQL DB store the Quality property of the Tag argon with the value. The quality level defines how much reliable is the Tag value and it follows the OPC standard specification. | ||||||||||||
Normalized | When checked, uses the Normalize table schema for SQL database, or the Standard schema otherwise. For more information on SQL database schemes refer to Archiving Process. | ||||||||||||
Value Columns Type | Select the Type for Value Columns used to store the tag values in the SQL database. This field can be edited ONLY when first creating the HistorianTable Options:
| ||||||||||||
GetSamples Method | Name of a method defined on Script → Class to allow customization when retrieving data from this tables. | ||||||||||||
Description | Description for this HistorianTable object. | ||||||||||||
Adding Tags for Data Logging
After configuring the HistorianTables, or just keeping the predefined ones, the next step is to list the tags to be archived in connection with those HistorianTables.
- Go to Tags → Historian.
- Type or select tags in the TagName column, or copy and paste tags from Tags → Objects.
Configure any required additional fields.
- Only the TagName and TableName fields are mandatory.
HistorianItem Configuration Properties | |
|---|---|
Field / Column | Description |
TagName | Enter a tag name or click "..." to select the tag for historian archiving. |
DeadBand | When using the SaveOnChange option in the HistorianTable, the DeadBand is how much the value must change (in Units) in order to the system store the value. |
Deviation | This value can override the Time Deadband logging interval. If the tag changes more than the Deviation value, the event to archive the tag is generated, even the deadband specified in TimeDeadBand has not elapsed yet. |
RateOfChange | This value can overrides the Time Deadband logging interval. If the Rate of Change of that is higher than this value, the event to archive the tag is generated, even the deadband specified in TimeDeadBand has not elapsed yet. The Rate of Change of a tag, is the difference on consecutive value changes, divided by the time in seconds between the changes. |
HistorianTable | Select the HistoranTable that this tag will be connected with. |
Working with the Historian
Runtime execution
When the Project runs, the Module Historian runs in an isolated process on the Server Computer.
The main procedures executed by the module include:
Check if a request to archive from a HistorianTable was generated (by the Trigger or OnTagChange events).
Archive the Data as needed.
Synchronize with remote archives if store and forward or redundancy is enabled.
Reply to requests from Displays and Scripts on querying the archived data.
Those procedures as described in detail in the Archiving Process page.
On this page, we have covered the essentials of the Historian module, which provides a comprehensive solution for managing time-related data in industrial equipment and systems. To further enhance your understanding and optimize the use of this module, we recommend exploring the following sections:
Module integration
You can learn how to seamlessly integrate the Historian module with other platform modules, such as the Security, Scripts, Displays, or Alarm module, to create a robust, cohesive, and efficient system tailored to your needs.
You can easily use the information from the historian archives in other modules, like creating TrendChart plots, or using in calculation scripts.
The page Integration with Other Modules presents information on that integration.
Advanced features and options
Dive deeper into the Historian module's advanced features and options, such as data compression, data aggregation, and custom data queries. Discover how these features can help you unlock the full potential of your data analysis and process optimization.
Troubleshooting and common issues
You'll be able to familiarize yourself with common problems that may arise when using the Historian module and learn effective troubleshooting techniques to resolve these problems quickly and efficiently.
Diagnostics information about the historian module execution is located in the Historian troubleshooting page.
Best practices and recommendations
Benefit from the knowledge of experts and experienced users by following our curated list of best practices and recommendations. These guidelines will help you ensure the successful implementation of the Historian module and maximize its impact on your industrial operations.
Please take a look at Historian's best practices and recommendations.
By exploring these sections, you will gain a deeper understanding of the Historian module's capabilities and learn how to leverage its full potential to improve your industrial processes, increase efficiency, and drive sustainable growth.
Historian module highlights
Connectivity is the software platform key feature.
Data integration
The platform streamlines data integration from multiple sources, such as field devices, ERP systems, MES, and databases, enabling centralized collection and storage. Utilizing various communication protocols like OPC UA, Modbus, MQTT, and RESTful APIs, ensures compatibility with diverse systems. Users can configure real-time data collection to be scheduled or event-driven, defining acquisition intervals or trigger conditions as needed. This integrated approach enhances analytical capabilities across the system without needing separate historians at each layer.
Data management
A secure, reliable, and scalable data storage infrastructure handles large data volumes generated by industrial equipment and systems. This infrastructure supports popular databases like Microsoft SQL Server, Oracle, and MySQL, ensuring data integrity and security. Data management features include data redundancy, version control, and automatic backups to protect against data loss.
Data analysis
Built-in analytics tools empower users to perform in-depth data analysis. Various visualization options, such as charts, graphs, and dashboards, provide intuitive data representation. Trend analysis functions enable users to monitor process performance over time and identify irregularities. Additionally, statistical tools like standard deviation, moving average, and linear regression are available for further data evaluation.
The Historian Runtime objects
The Historian namespace exposes properties and methods of the .NET objects used by the Tag Historian Module execution.
This section describes only some commonly used properties.
Examples of Historian Module properties | ||
|---|---|---|
Property | Type | Description |
| Boolean | Flag indicating if the Module Historian has started. |
| String | Message OK or error when initiating the Module. |
| Boolean | When enabled, temporary binary files are created on the server computer in order to optimize the performance of the TrendChart object requesting large amounts of data. |
Examples of Tag Runtime Properties on Historian | ||
|---|---|---|
Property | Type | Description |
| Boolean | Flag indicating if Tag is confirmed in a Historian Table. |
| String | HistorianTable related to this tag. Usage: |
| Object | Entry point to access the Historian Item settings connect with this tag. |
See Namespaces Reference for the complete list of properties and available methods.
In this section...