Overview
The Historian module implements data storage based on classical table systems. Although an SQLite database is integrated into FrameworkX, the module is also compatible with various other types of databases.
In order to streamline the table creation process across different database types, it is feasible to define generic characteristics. These characteristics will subsequently be employed for table creation in the selected database, designated as ArchiveLocation. This procedure can also be independently conducted directly within the Database Management System (DBMS) in use. The introduction of this abstraction layer enables users to customize settings such as table name, data type, data lifespan, and so forth. This not only facilitates the automatic creation of the table but also provides numerous advantages from the perspective of potential database architectural migrations.HistorianTables organize HistorianTags for logical grouping and management. A table defines the storage parameters for a specific set of tags. This includes how and when tags are saved, storage locations, and triggers for data storage (such as time intervals or value changes). HistorianTables allow customization of data retention periods. They are used to structure historical process data for retrieval and analysis, supporting applications such as process optimization, troubleshooting, and reporting.
Configuring HistorianTables
You can create as many HistorianTables as you need to organize your archives better and optimize for disk space and performance. To create a new HistorianTable, follow the steps below:
- Access Historian / HistorianTables.
- Click on the Plus icon.
- Fill in the fields and set the HistorianTable settings. The following section on this page describes each option available.
- Click OK.
Info | ||
---|---|---|
| ||
Specific options may be unavailable depending on the selected database or property chosen. For example, you can't define a trigger if you check the Normalized option for the new Historian Table. Therefore, it's essential to consider your options carefully. |
The new table will show up on the Datagrid list. You can edit the HistorianTable by selecting and changing the desired property if you need to. Alternatively, you can choose the HistorianTable and click the Pencil icon.
It's a good practice to store
Understanding Historian Tables
Historian Tables encompass the organization of tags read from Historian archives, arranging them systematically into Logical tables. These tables play a defining role by specifying the Target Archive database and settings, dictating when and how a specific group of tags is archived.
Definition
Historian Tables constitute a structured organization of tags from Historian archives, logically arranged into tables with defined settings for archiving within a specified Target Archive database.
Purpose
Provide user convenience with a configuration interface that encompasses all databases supported by the software.
Function
Automate the process of creating Historian tables in the database and define how and when groups of tags and properties will have their values recorded.
Operation
In operation, Historian Tables define the criteria for archiving, including the Target Archive database and specific settings, establishing a comprehensive framework for the storage and retrieval of tagged data.
Application
Historian Tables find application in the structured organization and storage of tagged data within the Historian system.
Usage
To use Historian Tables, users configure settings within the Historian system, specifying the Target Archive database and defining criteria for when and how the associated group of tags should be archived.
Historian Tables Configuration
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 like Deadbands, On Tag Change, or Trigger events to achieve this. These features help you organize your storage and save only what's required only save important data without overloading the system or slowing down data recovery.
HistorianTable Properties
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:
HistorianTable configuration propertiesWhen configuring a HistorianTable, you need to specify some properties defining when and how data will be archived. The following table describes each of the properties available.
Field | Description |
---|
ArchiveLocation | Defines the |
Archive Location used. By default, |
According to the Target option, some other fields on the configuration may be disabled
Table Namethe TagHistorian based on SQLite is used. For more information, access the Historian Storage Locations. | |
TableName | Name of the HistorianTable object. For |
other databases, this name is used as a logical grouping name |
. |
Auto Create
AutoCreate | If you select this option, the |
Historian module will |
verify if this table |
has already been created in your SQL |
database. If the table does not exist, it will create a new one |
. |
Save on Change
SaveOnChange | If you check this option, an action |
event to archive |
Tag data is generated whenever the Tags value changes. |
Trigger |
The Trigger option enables you to choose an event that, when it happens, will trigger the archiving of all Tags associated with the |
current HistorianTable in the database. |
You can |
use any tag, |
object, or property from the |
object's namespaces as a trigger. Click the Elllipses button (...) to access all options available. |
TimeDeadband |
Specify the minimum logging interval |
using HH:MM:SS:MS (Hours, minutes, seconds, milliseconds) |
format. This parameter determines the duration the system must wait after storing one tag value |
before storing a new |
one. It prevents excessive record creation in the database, especially if you're using the SaveOnChange option. If set as zero, this setting is inactive. As an example, consider you set a five-second deadband. After a Tag is archived, the counter begins. If the counter doesn't reach five seconds, no Tag information will be saved, independent of how big its value changes. The table below exemplifies the example.
|
|
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.
LifeTime | Set the duration in days for retaining records on the Storage Location. The system automatically deletes data older than the specified lifetime. If you set the value to 0 or leave it blank, the system will not perform automatic data deletion, ensuring the data remains untouched. |
SaveQuality | When checked, a column in your SQL DB |
stores the Quality property of the Tag argon with the value. The quality level defines how |
reliable |
the Tag |
is, and it follows the OPC standard specification. By checking this option, only points with real data will be displayed when you access a graph. Check more about this option in the section on this page. | |
Normalized | When checked, the system uses the Normalize table schema for SQL |
databases or the Standard schema otherwise. For more information on SQL database schemes, refer to the Archiving Process. |
ValueColumnsType | Select the |
type of value to be stored in the value columns, which defines the Tags' value type in the SQL database. |
You can change this property only when creating the HistorianTable. |
- Float (4 bytes) - Default option
- Double (8 bytes)
GetSamples Method
Name of a method defined on Script → Class to allow customization when retrieving data from this tables.
Description
| |
Description | Description for this HistorianTable object. |
Save Quality
In certain instances, the graph may exhibit lines and values even in timestamps where there is no data present. For instance, when you access a graph that you know lacks data and you see a continuous line connecting the endpoints of existing data points, despite the absence of data in between, you can infer that you are leading with unreal information. If you click on such areas, the value shown can lead you to misleading cursor values, as no data exists for those specific moments.
To address this issue, you can remove the line connecting the points of the graph where there is no data. This can be achieved by enabling the SaveQuality property in your HistorianTable, as depicted in the image below. If the SaveQuality option is not available in any column, you can enable it by right-clicking on the top of any column name and select SaveQuality.
You can also configure this option when creating the HistorianTable by checking the SaveQuality option, as shown in the image below.
The image below demonstrates a graph without lines in areas where no data exists, offering a clearer representation.
In this section...
Page Tree | ||||
---|---|---|---|---|
|