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.
Dealing with Daylight Savings Time:
VTScada records all data using UTC timestamps. In UTC, time advances at the rate of one second per second (barring leap-seconds) and if you were to plot your data against UTC time, you would see an uninterrupted line, assuming that your system is up and running, logging data.
Complications arise in places where daylight savings time (DST) is used. When DST starts in the spring, clocks jump forward from 2:00:00am to 3:00:00am. As far as UTC is concerned, data continues to be logged at the same rate, but if viewed on a graph that shows the local time, there will be a gap or a straight line showing no data for that hour. This is not a problem with VTScada. The gap exists because no time passed when the clock jumped forward, and therefore there is no data for that hour. Nothing can be shown.
Also, that day is 23 hours long, not 24, which may affect your reports. Again, this is not a problem with VTScada. According to your local clock, the DST-transition day had only 23 hours, therefore a daily report can include only 23 hours worth of data.
In the autumn, when daylight savings time ends, you can expect the same in reverse. It will appear that an hour's worth of data is over-written during the transition as the local clocks repeat that hour. That day is 25 hours long.
Rest assured that VTScada is faithfully and steadily recording your data, regardless of what your local clocks are doing.
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
Historian tags have been designed to provide dependable, efficient service with minimal configuration. Refer to Historian Tags for configuration options.
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)
