Historian and Logger Configuration

VTScada uses its own storage system for saving data. It includes all the tools you need to extract data when and how you wish.

The task of collecting and saving data is managed by Historian tags. There are at least two in every application (SystemHistorian and SystemAlarmHistorian) and you can add more if required.

By default, information is written to a proprietary storage format, located in the Data folder of your application. You can choose to store your data in a 3rd party database such as Oracle®, PostgreSQL®, SQLite®, MS SQL Server® or MySQL®, but this is not a common configuration. Note that VTScada will use its own data storage system within these databases, therefore you should plan to query and retrieve your data using the VTScada tools, regardless of how and where it is stored.

When the connection to an Historian is built into a tag, that tag's values are written with every change. The use of a deadband on analog-value source tags is recommended to avoid logging system noise, and in fact is present by default in the tags, I/O and Calculations & Analog Status. See: Optimize Your Configuration for related steps that you should take to avoid problems when logging data.

If using tag types that do not have a built-in connection to the Historian, you must add a Logger tag (Logger Tags) to serve as a go-between, passing data from the collection tag to an Historian.

Historian tags have been designed to provide dependable, efficient service with minimal configuration. Options include:

  • Data Limiting - you can configure the Historian tag to save data from only the last X days or N records.
  • Alternate storage locations. You can direct the data to be saved to a location of your choosing. For optimum performance, this should never involve sending data across a network to another machine.
  • Alternate storage formats. Instead of using the VTScada database system, you may use any of the following databases to store data: Oracle, MS SQL Server, MySQL or SQLite.

Two additional configuration options for your Historians are done using the Edit Server Lists panel of the Application Configuration dialog:

  • Redundant storage locations. In a multi-server application, you can (and should) configure backup servers. Data will be copied automatically, and backup servers can take control when the primary is offline.
  • Load distribution between multiple Historian tags. By adding more Historian tags, each running on a separate server and saving to separate databases, you can ensure that the data logging requirements of extremely large systems does not exceed any one server's I/O capacity.

System Historian versus System Alarm Historian

Both are Historian tags and both write data to long-term storage. In general, it is best to keep process I/O data separate from the alarm history for the following reasons:

  • Retrieval speed.
    If alarm data were mixed with process I/O data, it would take longer to retrieve. The stored history of alarms and events tends to be very small compared to I/O process history.
  • Local storage.
    For applications that run on multiple workstations, every workstation will have its own copy of the alarm database so that alarm information remains available in the event that the workstation becomes separated from the rest of the network.
    This is not a good idea for your stored process I/O data. Therefore, the System Alarm Historian is configured to maintain a local copy of its database on all workstations, while the System Historian is not.
    (Caution: do not confuse this concept with that of backup Historians. Client / Server Configuration)