Historian Tags

Not counted towards your tag license limit.

The Historian Tag is used to write data that is to be logged to storage. (The Logger tag controls only how often the Historian tag writes.)

Every VTScada application will have a default instance of an Historian tag named "SystemHistorian" for tag I/O values and one named SystemAlarmHistorian, used by Alarm databases. In many cases, these will be the only Historian tags that you use in an application. The information will be written to a VTScada proprietary database format unless otherwise configured.

Do not use the same Historian to record both process values (tag I/O data) and alarm information.

The Historian tag's configuration panels provide access to only some of the available options. With a combination of Historian tags and related application properties, you can also configure the following:

  • Save data to a proprietary database such as Oracle, Microsoft SQL Server, MySQL. PostgreSQL , or SQLite instead of the VTScada database.
  • Ensure that a redundant backup exists by writing to separate storage locations on two or more servers.
  • Configure load sharing between servers.

The status of the Historian's connection to its data store can be viewed using the Historian Status Widget widget.

Historian properties Datastore tab

Choose how and where data will be stored. Use only letters and numbers for the Storage Name.

Historian datastore options

Represent system downtime as missing data

Do not select this option in Historians used by Alarm Databases.

If selected, then system downtime will be represented as a gap in the data. If not selected, then the last recorded value will be taken as if it were in effect for the duration of the time that VTScada was not logging.

Options for system downtime

Enable Client Data Storage

Intended only for Alarm Historians. Do not enable client data storage otherwise unless you have a clear understanding of the costs and benefits. On a system with many clients, this feature can add a significant load to network communications.

This feature is intended for use only with Alarm Historians, allowing isolated clients to modify the alarm system database and obtain alarm data from local storage. When enabled, Client Data Storage increases availability of the alarm system, especially in the event of a client becoming isolated from the network. Alarm historians tend to be relatively small (averaging one or fewer alarm or events per minute) when compared to the SystemHistorian, which may be logging thousands of records per second. It is entirely possible to use alarm Historians without this feature, but those clients will not be able to generate alarms and events when isolated from a server. They will also have to obtain alarm history from the server, which may require significant data transfer.

You are strongly advised to avoid using this feature with Historians that are logging I/O data.
If you insist upon doing so, ensure that drivers are configured with the Hold option set, to prevent isolated clients from logging invalids and thereby causing HDV gaps.

When enabled on any Historian tag, that tag will synchronize and store its history files on all VTScada hosts, regardless of their presence in the server list. This generates extra synchronization and update traffic between all hosts and should only be used in the recommended circumstances such as alarm Historians, to allow alarm data to be available locally on all hosts.

Diagnostic Tracing

When enabled, diagnostic information such as error messages will be recorded to a file within the application's Data\TraceFiles folder structure. This option is enabled by default and should remain enabled in most circumstances.

Storage Name

Advanced Use Only. Enables a user-specified name to be used, rather than the tag's Unique ID. This provides control over the folder name that will be used in the data store.

If configuring an ODBC-based database, the use of this field is recommended, as the tag's Unique ID may not remain unique after being modified to a form that can be used by the ODBC driver.

Storage Type

Advanced Use Only. May be either "ODBC" or "ODBCSingleTable" if configuring an ODBC-based database. Defaults to the native VTScada storage system if blank and therefore need not be set unless using ODBC.

  • If set to ODBC, each tag's data will be stored in a table named for that tag's unique identifier.
  • If set to ODBCSingleTable, there will be one table per schema (analogs, digitals, drivers...) holding the data for all tags that match that schema.

If using an Oracle database as a target for historian data, the database must have a "tablespace" named "Users", which is not present in a new Oracle DB. This is used as the default tablespace for the user created by a historian tag, and is where all the historian tables are stored.
All tables are created with the "owner" (or schema) named after the tag name. So, given a historian tag of "SystemHistorian", then all tables are created with the owner SYSTEMHISTORIAN and have a name such as "SYSTEMHISTORIAN.FRIENDLYTAGNAMELOOKUP".

Storage Location

Advanced Use Only. If using the VTScada data store, you may use this field to specify the path to a storage location other than the default. (C:\VTScada\AppName\Data)

When using paths outside of VTScada install folder, ensure that VTScada will have read/write access to the new location. VTScada has no control over file permissions outside its installation folder.

If using an ODBC-based database, this should be set to either the configured DSN (Data Source Name) of the database as follows:


Or, you may use a connection string, in the form:


While it is possible to set the storage type and location using application properties, you are advised to use the tag configuration fields described here instead.

Historian Data Storage - More about storage options. How to configure logging to both the VTScada data store and a third-party database.

Query a 3rd-Party DBMS - Table structure

Historian properties Storage Limiting Settings tab

Historians used by Alarm Databases should not use storage limiting.

Choose whether to limit the data saved. If the data is to be limited, you can also choose whether to limit it by date, or by a maximum number of records.

Storage limiting tab

By default, no limit is set on the amount of data to be stored.

If you choose to delete data older than a given number of days, you will have the option of setting how many days that will be. The default is 365.

Default settings for storage limiting

If you have chosen to delete data, the only guarantee is that records newer than the limit are kept.
Older records will be swept eventually and it is pointless to focus on the value of the Sweep Interval.

The sweep interval sets the size of data blocks. It can be no less than one hour and no greater than 356 days. The default comes from the application property HistorianDataAgeSweepIntervalDivisor. (A more technical explanation is provided with the description of that property.)

Sweeping is done based on when data was recorded, which may differ from the data timestamp, especially in the case of manually entered data. Data blocks are removed when all recorded timestamps within that block are older than the set date. Changes to the HistorianDataAgeSweepIntervalDivisor do not cause older blocks to be broken into smaller chunks. Older values will be swept eventually, and it is pointless to focus on the value of the sweep interval.


Historian storage limiting options

Historian Status Widget - Displays information for all Historians, rather than being linked to a specific instance as widgets are.