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.
Optimize Your Configuration - Avoid problems when logging data
Log, Note, and Report - Advanced options.
Alarm Data Logging - Details related to the alarm system.
Historian properties ID tab
The ID tab of every tag includes the same common elements: Name, Area, Description, and Help ID.
Name:
Uniquely identifies each tag in the application. If the tag is a child of another, the parent names will be displayed in a separate area before the name field.
You may right-click on the tag's name to add or remove a conditional start expression.
Area
The area field is used to group similar tags together. By defining an area, you make it possible to:
- Filter for particular tag groups when searching in the tag browser
- Link dial-out alarm rosters to Alarm tags having a particular area
- Limit the number of tags loaded upon startup.
- Filter the alarm display to show only certain areas.
- Filter tag selection by area when building reports
When working with Parent-Child tag structures, the area property of all child tags will automatically match the configured area of a parent. Naturally, you can change any tag's area as required. In the case of a child tag, the field background will turn orange to indicate that you have applied an override.
To use the area field effectively, you might consider setting the same Area for each I/O driver and its related I/O tags to group all the tags representing the equipment processes installed at each I/O device. You might also consider naming the Area property for the physical location of the tag (i.e. a station or name of a landmark near the location of the I/O device). For serial port or Roster tags, you might configure the Area property according to the purpose of each tag, such as System or Communications.
You may define as many areas as you wish and you may leave the area blank for some tags (note that for Modem tags that are to be used with the Alarm Notification System, it is actually required that the area field be left blank).
To define a new area, type the name in the field. It will immediately be added. To use an existing area, use the drop-down list feature. Re-typing an existing area name is not recommended since a typo or misspelling will result in a second area being created.
There is no tool to remove an area name from VTScada since such a tool is unnecessary. An area definition will exist as long as any tag uses it and will stop existing when no tag uses it (following the next re-start).
Description
Tag names tend to be brief. The description field provides a way to give each tag a human-friendly note describing its purpose. While not mandatory, the description is highly recommended.
Tag descriptions are displayed in the tag browser, in the list of tags to be selected for a report and also on-screen when the operator holds the pointer over the tag’s widget. For installations that use the Alarm Notification System, the description will be spoken when identifying the tag that caused the alarm.
The description field will store up to 65,500 characters, but this will exceed the practical limits of what can be displayed on-screen.
This note is relevant only to those with a multilingual user interface:
When editing any textual parameter (description, area, engineering units...) always work in the phrase editor. Any changes made directly to the textual parameter will result in a new phrase being created rather than the existing phrase being changed.
In a unilingual application this makes no difference, but in a multilingual application it is regarded as poor practice.
Help Search Key
Used only by those who have created their own CHM-format context sensitive help files to accompany their application.
Historian properties Datastore tab
Choose how and where data will be stored. Use only ASCII characters for these fields and only letters and numbers for the Storage Name.
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.
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:
DSN=MyDSNName
Or, you may use a connection string, in the form:
Driver=ServerBrand;Server=ServerName;Database=DBName;Uid=user;Pwd=pwd
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.
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.
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 Status Widget - Displays information for all Historians, rather than being linked to a specific instance as widgets are.
