Page History

Purpose and Key Concepts

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

[The Defintions flowing the concept should be VERY CONCISE and Objectice'the. should NOT have any marking spring, configuration informaiton, minimum is the best.  The examples with you this chart, and likely in all MODULES, they typically say much more than they should be saying here''.  This second is to name sure the NAMING COVENTIONS, KEY CONCEPT,    essentially MAKING WE WILL TALK USING THE SAME LANGUAGE, when in the following section will will lexapling what it does, and how it does. But even before I give summary on that is does and how it does, I need to make WE ARE SPEAKING THE SAME LANGAUGE, and to speak the same language some KEYWORDS must have the SAME MEANING, to both parts the communication.

TargetDB

The TargetBD defines the database where variables will be archived or read to be used in charts and calculations. The Target Database can be any SQL Database 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.

HistorianTable

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 apply to all tags in that group in the Historian Table, such as when to save new data or how long to keep the data.

HistorianTag

The HistorianTag refers to any value contained in 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 include dynamic references to external data using the TagProvider functionality. 

Understanding the Historian module

Write notes:  Typically most of the Modules when they go the Undesting they go right away a more technical deep understand. 

In my my opinion: the Understand Section should typically and a development in 3 state.

The very first one here in the same page, in this exactly logaiotn, is a very, vary simple explanation on how it does what it does. 

The number 3 step in a child page, which many module will, (like this one have(, but not necessarily all need to have, which a DEEP detail on the Inner working. With the cldeartate in the statement, that page (child), is ADVANECED details of the working and of the implantation 

the in middle, we have the setp2, which be ieither is here, in exactly same page, after the item 1, or the y bra in the child page ad this part of the Destalchidl page.

I believe if keep too much struct rules in this, will some sin the some with modules with forced test that will create. I udnertnad that to have the  number 1 simple explanation HERE, and the number 3 advanced detail inner working in the Child page, that but the Perla template, The detail of in between must addressed, the delve of the detail, the languid, and even location where it will located, then that context is understood to be necessary, the contact of the middle layer is develop.

===================

Anchor
ArchivingProcess ArchivingProcess

Archiving 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:

Default TargetDB

When creating a new solution, the TagHistorian is set 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 Canary Historian, or any available ExternalTags Historian targets.

The SQLite database is suitable for databases 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 use another SQL database for the Tag Historian, the Canary Historian, or any of the available ExternalTags 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.

To configure a different SQL Database for the TagHistorian connection, please refer to the Dataset module configuration.

For other ExternalTags Historian targets, please refer to the ExternalTags configuration to define and configure their use.

Configuring HistorianTables

The Historian module creates a default HistorianTable using Dataset-TagHistorian SQL as the Target Database, with an additional HistorianTable being created if the Canary Historian is enabled. This setup offers a range of flexible options to choose from when selecting and configuring the target database for your solution's specific needs.

The HistorianTable settings allow you to define rules for saving the tags connected with it. You can set triggers such as a time deadband, specifying the minimum interval between saves, and a lifetime value, determining how long saved tag values will be retained. Note that certain options may be unavailable depending on the target database selected, so it's important to carefully consider your options.

Storing only the necessary data at the required frequency is a good practice to follow. You can use features such as deadbands, OnTagChange or Trigger events to organize your storage and save only what's required without overloading the system or slowing down data recovery.

HistorianTable configuration fields

New HistorianTables can be create with the NEW button, on  Historian → Historian Tags, or editing the table on Historian → Historian Tables.

To modify History Tables, on Historian  → Historian Tags, select the Table in the ComboBox and Config button, or editing the datagrid on Historian → Historian Tables.

Either using the Dialog view or datagrid view, the HistorianTable has the following configuration fields:

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 Historian → Historian Tags.

• Type or select tags in the TagName column, or copy and paste tags from Unified Namespace → Tags.

• Configure any required additional fields.

• Only the TagName and TableName fields are mandatory.

Working with the Historian module

Runtime execution

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

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 information, see the Displaying TrendCharts.

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.

Troubleshooting and Best Practices

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.

In this section: