The VTScada Historian

VTScada uses its own storage system for saving data. The task of collecting and saving data is managed by Historian tags. Every application starts with two Historian tags (SystemHistorian and SystemAlarmHistorian) and data is stored locally by default. You may choose to configure additional Historians, redundant Historians, choose an alternative storage location, or extend your historian storage.

Information is written to a proprietary storage format and located, by default, in the Data folder of your application. You can choose to store your data in a 3rd party database, but note that VTScada will use its own data storage system within these databases, therefore you should plan to query and retrieve your data using VTScada's tools, regardless of how and where it is stored. If you want to store data in a 3rd party database, it is a Best Practice to keep your default SystemHistorian and SystemAlarmHistorian configured to store locally and add additional Historian tags that log redundantly. (for example, ODBCSystemHistorian and ODBCAlarmHistorian). Local storage is where logging is best optimized for speed and efficiency.

Why does VTScada use a proprietary format for logging data?
VTScada's Historian stores data very quickly, very efficiently and has a unique way of managing redundancy. That alone is why we use our own proprietary format for logging. But there is another great reason:
The VTScada Historian is incredibly resistant to tampering.
You can't access or extract logged data from the Historian without the application that logged it. Attempts to access a secured application or to change values or even to modify tags leave forensic traces.
Logged values can be deleted and lost forever (which is why backups and redundancy are very important) but a bad actor would find themselves hard-pressed to make any alterations that are undetectable.

Historians and Logger tags

Out-of-the-box, logging is enabled on all I/O tags. Data is logged to SystemHistorian. Logging is also enabled on Alarm tags and Alarms that are configured in the I/O & Calculations tag. Alarms and events from these tags are stored in SystemAlarmDB and that is linked to SystemAlarmHistorian. This is the starting position of a new standard application, but it is completely customizable.

Disable logging of I/O tags that don't need to be logged to save storage space.
Reduce the frequency of logging or increase deadbands within tolerance to save storage space and cut noise.
Alarm tags will auto-link to Alarm Databases that are closer in their tag hierarchy (sibling, or parent).
You can create new Alarms and Event Databases.
You can create new Historian tags and change linked I/O and Alarms. (I/O and Alarms should never share the same Historian tag!)

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 a Historian.

See Historian Tags for a detailed look at Historian tag configuration.

Some 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)