Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction to Historian Module

The Historian module enables the storage of tag values and their corresponding timestamps in SQL databases or third-party time-series databases. This module is designed to streamline the collection and storage of data in its time context. 

The Historian module provides an out-of-the-box solution for archiving historical data without programming requirements. Although it is possible to include custom data logging procedures in your solution using Scripts (.NET programming) and Datasets (SQL storage), the standard configuration tools of the Historian module can fulfill most typical data logging needs. 

On this page:

Table of Contents
maxLevel3


Purpose and Key Concepts

Configuration of the Historian module is accomplished through the following sections: Target Database, Historian Table, and Historian Tag.

TargetDB

Archive Location

The Archive Location defines in which database The TargetBD defines the database where variables will be archived or read to be used in charts and calculations. The Target Database You can be use any SQL Database or, using the TagProvider Extensibility, it can also use . If you want to integrate third-party products designed to store long-term time-related values, known as time-series databases or Historian tools, you need to use the Tag Provider.

HistorianTable

Historian Tables

Historian Tables group The HistorianTable is a logical organization that groups Tags for historical archiving. Each Historian Table has a definition of which Target Database the group of Tags will be archived. You can also configure other standard settings that Using the Historian Table, you can define the Tags to archive to each Target Database. Moreover, you can configure additional standard settings to apply to all tags in that group in the Historian Tableone particular group, such as when to save new data or how long to keep the data on the database.

HistorianTag

The HistorianTag A Historian Tag refers to any value contained in internal or external Tag whose values are archived into a Historian Table to be archived, whether an internal Tag or an external data reference. These variables are typically Tags defined in this platform, but you can also . In addition to Tags from the platform, you can include dynamic references to external data using the TagProvider functionalityTag Provider function. 


Understanding the Historian

Functionality

Module

Historian permite salvar valores do processo em time-series data e também permite que esses dados sejam recuperados para ser usados em telas e Alarmes. 

AnchorArchivingProcess

The Historian Module provides an out-of-the-box solution for archiving historical data without programming requirements. Although it is possible to include custom data logging procedures in your solution using Scripts (.NET programming) and Datasets (SQL storage), the standard configuration tools of the Historian Module can fulfill most typical data logging needs. 

You can use the data archived through your application's Historian Module in Alarms and Displays.

Feature Highlights

  • Embedded Canary Historian includes 500 free Canary Historian Tags with any license – Edge to Unlimited.
  • The Historian Module works with the industry's major players (OSISoftPI, InfluxDB, and more).
  • Store and Forward function ensures your data will not be lost if the database is unavailable. 
  • Universal Time and Daylight Saving
ArchivingProcessArchiving Process Overview

The Historian module has a three-step archiving process:

  1. An event triggers the request to archive a group of values. There are two types of events (Trigger or TagChange), which are configured in a Historian Table.

  2. The Historian archives the values in the Target database. The Target Database can be a SQL Database or a TagProvider that is configured to act as a historian.

  3. If Store and Forward is enabled, the data synchronization is executed. This option stores data in a local database if the Target Database is not available, and sends it to the target when it becomes available.

The archiving process considers two types of archiving events:

  • Trigger: The Trigger can be a Tag Value, Tag Property, or any object from the runtime namespace (e.g., server.minute). When a value change is detected in the object, the archive request event is generated. Only Tags of domain Server 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 HistorianTable. 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 check-box on the TableHistorian configuration. Enabling this checkbox allows the Historian process to verify all tags connected to that HistorianTable. When the tag has a new value, the archive request event is generated. The request to archive will be generated only for the Tag that has a new value. However, according to the Historian Target Database, only the tag or all tags in the group will be archived. Further information on this is included in the next section of this page.

For a more detailed Historian execution explanation, check Archiving process.

Configuring the Historian module

Configuration Workflow 

The typical configuration workflow for the Historian Module has the following sequence:

Historian module configuration workflow
ActionWhere Comments

Define the default TagHistorian  SQL Database

Historian → TargetDBsArchive Location

By default, TagHistorian maps to a SQLite database named and located equal as the Solution itslefitself, followed by the proper FileExtension. You're able to change it as needed. 

If using Canary, modify the default target to the  the Canary Historian

Historian → TargetDBsArchive Location

If using Canary, a connection with the local embedded Canary Historian is already included in new solution. Just use that connection, or modify it willing to connect an external Canary System instead.

If necessary, add other Target Databases

Historian → TargetDBsArchive Location

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 mark  "Set as Historian Server" checkbox when creating the provider.

Create and Edit HistorianTables

Historian → Historian Tables

Add or modify HistorianTables, organizing how the Tags will be grouped for archiving and the Target Databases. Learn more at Historian Tables.

Add Tags to the HistorianTables

Historian → Historian Tags

Connect Tags to the Historian tables. Either by typing, browsing, pasting or any of the available import methods. Learn more at Historian Tags.

Default

TargetDB

Archive Location

When

creating

you create a new solution with the platform, the

TagHistorian is set

default database (Tag Historian) uses, by default

to use

, the embedded SQLite database provided in the Datasets

module. The Historian Target Database can be chosen from a range of options, including selecting another SQL database for the Tag Historian, the

Module. However, you can change the default option at any moment. 

The platform lets you choose from various Historian options, including SQL databases, Canary Historian, or any available

ExternalTags Historian targets

External Tags Historian. The table below describes the options available.

Historian

Database

options

Option

Target Database 

Description 

SQL Database

Any

You can use any SQL-style database

,

defined in the object

TagHistorian

 Tag Historian available on Datasets → DBs.

Canary Historian

Embedded CanaryLabs engine included in the framework, or connection

The platform includes an embedded Canary Labs Historian, and you can also use it with external Canary systems. Read more information on the Canary Labs page.

ExternalTags

External Tags Historian (InfluxDB, OSIsoft PI)

The

ExternalTags

External Tags feature allows

for seamless integration

you to seamlessly integrate with third-party products, which can act as native and fully integrated historian repositories. This feature

provides not only

enables you to use current interfaces

but also allows for

or additional products

to

, which can be

easily

incorporated using the driver toolkit.

When to use the SQLite database

The SQLite database is suitable for databases with a size limit of up to

around

10GB

in size. If the number of tags and the save interval are expected to exceed this limit, it is recommended to

. It is recommended to use another option if the stored data exceeds this limit. You can use another SQL database for the Tag Historian, the Canary Historian, or any

of the

available

ExternalTags

External Tags Historian targets.

It is advisable to select an alternative database option in cases where a solution is expected to create more tags or require frequent saving intervals that exceed the capabilities of the embedded SQLite database.

Despite the limited size, no other restrictions prevent you from using SQLite in a production application.

Refer to the Dataset Module configuration to

To

configure a different SQL Database for the

TagHistorian connection, please refer to the Dataset module configuration

Tag Historian connection.

For other

ExternalTags

External Tags Historian targets, please refer to the

ExternalTag

 External Tags configuration to define and configure their use.


 

Working with the Historian

module

Module

Runtime Execution

You can control the Historian module execution while running your solution. You can RunPause, or Stop the Historian module directly from the platform. Access Runtime → Runtime Diagnostics to find the three buttons that you can use to control the module.

Image Added


When the Solution 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:

Monitoring Historian

It allows monitor and managing historical data storage. This functionality provides a clear view of the data and facilitates the analysis and optimization of system performance. For a comprehensive understanding, see the Monitoring HistorianTables. (Go to Historian → Historian Tables)

Displaying TrendCharts

Is that all data is achieve, with NO addition configuration, can be really used by Displays and scripts

ON Displays, when you configure a TREND chart with a TAG, no configuration is required for the tech to use the archive, the Platform uses its built cross-referenced to know that the TAG

int ehcarft, has Historian arquivid, and queries it automatcily. 

The configuration the trend char tis on THIS LINKD

Monitoring Historian

When the solution is in runtime, the Historian Monitor menu provides a way to monitor real-time information related to the Historian Module operation.  

You can read more information an see a list of properties on the Historian Monitor page.

Intra-Module interaction

Displaying TrendCharts

 It is possible to display Trend Charts to analyze and compare It allows the visualization of trend charts for analysis and comparison of historical and real-time data. This functionality makes it easy to identify patterns and trends in system performance. For detailed more information, see the Displaying TrendChartsthe Displaying Trend Charts or Examples page.

Unified Namespace Module

The Historian Module creates a time-series archive of tag values, by storing them and their corresponding timestamps in SQL or third-party time-series databases.

Querying Data on Scripts

It enables the querying and retrieving of data from variables and historical tables through scripts. This functionality empowers the creation of custom logic and solution-specific analysis. For a comprehensive understanding, refer to the Querying Data on Scripts.

Wrong link, note to myself: find and fix!


External System Interaction

Trough the Datasets Module, the Historian module can integrate with external databases to create a time-series archive. The following is a list of possible databases you can connect:

  • SQL Server
  • PostgreSQL
  • Excel

Read more information on the Dataset DBs page and its sub-pages.


Advanced Historian Topics

Archiving Process

The Archiving Process is the process of receiving new data from Tags and storing it in databases defined by the Archive Location. You can define different configurations to trigger storing actions based on your needs and database restrictions. Access the Archiving Process for further information about the process and configurations available.

Historian Runtime Attributes

The Historian Namespace exposes properties and methods from the .NET objects used by the Historian Module execution. You can use these properties and methods on your Displays or to create Scripts and Alarms. The Historian Runtime Attributes page lists all options available.


Troubleshooting and Best Practices

Table of Contents
maxLevel4
minLevel3
include#

Troubleshooting and Common #Issues

The Historian module may encounter some issues in its operation. Here are some common issues and their solutions:

#Data not being archived

Check the Historian Table configuration, Trigger or TagChange settings, and Target Database. Ensure the settings are correctly set up, and the database connection is valid.

#Incomplete data

Ensure that the Historian module is started (IsStarted flag) and the archiving process is functioning correctly. Check for any error messages in the OpenStatusMessage string.

#Slow data retrieval

Enable the caching feature (EnableCache) to optimize performance when requesting large amounts of data.

#Store and Forward not working

Verify if the Store and Forward feature is enabled and configured correctly. Check the local database and target database connections.

#Database connection error

Check the database connection settings and ensure that the database is reachable.

Best Practices and #Recommendations

To ensure the smooth operation of the Historian module, follow these best practices:

#Use descriptive names for Historian objects

Use clear and descriptive names for Historian Tables, tags, and other related objects.

#Optimize data retrieval

Optimize data retrieval by enabling caching when working with large datasets.

#Ensure data integrity with Store and Forward

Use Store and Forward to ensure data integrity in case of temporary database connection issues.

#Plan your data storage strategy

Determine how much data you want to store and for how long you want to store it. It is important to plan your data storage strategy in advance so that you can optimize the historian module for your specific requirements.

#Document yours historians configurations

Document your historian module configuration to make it easier to manage and maintain. This includes documenting data sources, data types, sampling rates, storage options, and performance optimizations.

#Use security best practices

Protect the historian module from unauthorized access by implementing security best practices such as user authentication, access control, and data encryption.

Historian Runtime Attributes

The Historian namespace exposes properties and methods of the .NET objects used by the Tag Historian Module execution.

For general information on namespace and object concepts, go to the section Objects and Namespaces.

This section describes only some commonly used properties. See Namespaces Reference for the complete list of properties and available methods.

Examples of Historian properties 

Property

Type

Description

To access the property on CodeBehind

IsStarted

Boolean

This is a Boolean flag that indicates whether the Module Historian has started

.

If the flag is set to "true," it means that the Module Historian is up and running, actively archiving data according to the configured Historian Tables. If the flag is set to "false," the Module Historian has not yet started, and no data archiving is taking place.

Historian.IsStarted

OpenStatusMessage

String

This is a string that displays a message indicating the success or failure when initiating the Module Historian. If the Module Historian starts successfully, the message will typically show "OK" or a similar confirmation. If there is an error during the initiation process, the message will display an error description to help diagnose and troubleshoot the issue.

Historian.OpenStatusMessage

EnableCache

Boolean

This is a Boolean flag that, when enabled, allows the creation of temporary binary files on the server computer to optimize the performance of the TrendChart object when requesting large amounts of data. With caching enabled, the system can quickly retrieve the necessary data for the TrendChart object without causing significant delays or performance issues. By setting this flag to "true," users can benefit from improved performance and responsiveness when working with large datasets in the TrendChart object.

Historian.EnableCache


In this section:

Page Tree
root@self
spacesV10

...