Not counted towards your tag license limit.
The Alarm Database tag type is used to link alarms and events to Historian tags. They are also used to preselect the columns that will be shown when viewing the alarms from a particular database in the Alarm Page.
Every VTScada installation comes with two Alarm Database tags: System Alarm DB and System Event DB. The term "System Event" refers to the VTScada event-level actions that will be recorded using the System Event DB tag. This includes operator actions such as signing in and changing output tag settings. It also includes events such as report generation using a Report tag.
Alarms are associated with their closest Alarm Database ancestor in your tag hierarchy. Any alarm that does not have a specific Alarm Database tag as an ancestor will be associated with the System Alarm DB. This includes user-defined alarms that are given priority 0 - Event. Only VTScada events are logged with the System Event DB tag.
If configuring an I/O and Calculations tag (advanced alarm mode) or an Alarm tag, you are free to select any Alarm Database for that tag's alarms.
Version 12.0.18 introduced a change in alarm database behavior: In earlier versions, all operational events related to tags were stored in the System Event DB. From 12.0.18 onward, operational events related to tags are stored in the parent alarm database, if one exists. Otherwise, they continue to be stored in System Event DB. For those using custom Alarm Database tags, this simplifies filtering.
Alarm Database tags are treated as containers, similar to the Context type and include all options for site display configuration.
Depending on the size and complexity of your application, there can be benefits from creating extra Alarm Databases. Do so if any of the following apply but avoid creating extra databases if they are not needed.
- Security across realms.
Realm filtering can be applied so that an operator can be restricted to see only the alarms from a single alarm database (or set of databases). All other databases could be hidden from this operator.
Note that it is not a requirement that you create multiple alarm databases to use realm filtering. - Management of alarms.
If operators in different roles or locations are required to look after a certain subset of alarms, those alarms could be kept in a separate database so that no filtering is required in the alarm list beyond the selection of which database's alarms to show. - Efficiency.
It can be slow to filter alarm history if there are millions of alarm records in a database. If the alarms are distributed between multiple databases then each will be smaller, thus making it faster to filter alarm history. - Management of large, widely distributed systems.
If two or more plants are part of the same application, and those plants are separated by a slow network link, then you can improve local performance by setting up an Historian-AlarmDatabase pair for each plant, where each plant will be use local server(s) for its primary server.
(We do not recommend creating additional Historians except in large or widely-distributed systems.)
Switching Databases
There is no restriction on moving an alarm from one database to another, but in rare circumstances the alarm may be temporarily orphaned on the old database. This could result in duplicate alarms on the alarm page and may result in an alarm activation not being logged in the new db. The orphaned alarms will be purged automatically within a few minutes of application start, as controlled by the property, AlarmDatabasePurgeDelay. See: Orphaned Alarms
To move an alarm to a new database, move the tag to become a child of the new Alarm Database tag or change its configuration to link to the new database. A decommission event will be registered for the old database, and a commission event will be registered for the new.
Every Alarm Database tag will have its own child Notebook tag, which will be created automatically. All notes created for an alarm are stored in the notebook associated with the matching alarm database.
Realm Filtering, Global Tag & Area Filtering
Historian and Logger Configuration
Alarm Database 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 yellow to indicate that you have applied an override. (Orange in the case of user-defined types. Refer to Configuration Field Colors)
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.
Alarm Database properties Settings tab
Use the Column Format selector to choose how alarms in this database should be displayed on the Alarm Page. Your options are as follows:
| Column Format | Displayed columns |
|---|---|
| Alarms | Time - Priority - State - Event - Area - Name - Description - Value - Setpoint - Units - Operator - Notes |
| Events | Time - Area - Name - Description - Workstation - Device - Operator - Notes |
| Legacy 1 | Event - Priority - Time - Area - Name - Description - Operator |
| Legacy 2 | Time - Name - Description |
| Legacy 3 | Time - Ack - State - Event - Priority - Area - Name - Description - Operator |
| Legacy 4 | Time - State - Event - Priority - Area - Name - Description - Operator |
| Legacy 5 | Ack - State - Event - Priority - Area - Name - Description - Operator |
| Legacy 6 | Time - Event - Priority - Area - Name - Description - Operator |
| Legacy 7 | Time - Name - Description - Ack |
| Locks |
Relevant only to the Alarm List Widget / Locks List Widget. Displays currently active Control Locks and provides a means for authorized operators to release those locks. Described in Locks List Widget |
| Popups | Priority - Ack - Name - Description |
As an advanced configuration option, you can create your own column formats by writing XML templates. See: Customize Columns in Alarm Displays
Alarm Database properties Historian tab
Historian
Do not use the same Historian for both alarm history and tag data.
An Historian tag must be selected in order for this alarm database to save alarm history. Historian configuration and advanced logging options are described in the discussion of the Historian Tags. By default, the System Alarm Historian is selected.
There are consequences if you change the selected Historian tag after you have begun collecting data. If you switch to a new Historian (perhaps for organizational or load sharing purposes), the data collected for this tag by the previous Historian will become inaccessible.
Alarm Database properties Site Display tab
There are two ways to prevent a site's location pin from being shown on a map: Leave the Latitude and Longitude values empty, or deselect the Show option for the map icon. If the site has latitude and longitude values, but the icon is not displayed, then the indicator beacon will pulse while the cursor is held over the site's coordinates on the map, even though the pin is not displayed.
Latitude and Longitude
Holds location coordinates for this tag, thereby allowing it to be represented on a Site Map page if the map icon is shown.
Custom Details Page
If a custom details page has been created for this context tag, then that page should be selected here. If there is no custom details page, then operators will see the standard Site Details page upon clicking the pin for this tag in a Site Map.
Map Icon
You might choose to define a location for this site, but not display it on a map.
If a custom map icon widget has been defined, you can select it here. That icon will then be used instead of the standard icon when this tag is represented on a Site Map page. If there is no custom map icon, then the standard widget will be used. A custom map icon is any tag-widget that can be linked to this tag type.
This tag will be included in the list of a Sites page. What will happen when an operator clicks on this tag in that list depends on the Site List display choice, and on whether any of this tag's children are I/O tags. Note that the following applies only to the list section of the Sites page, not to the map.
- Display as Site: A click will open the Site Details page as a pop-up.
- Display as Folder: A click will leave focus on the Sites page, but the list will now show the child tags of this site.
- Exclude from Site List: This tag should not be shown in the list section of the Sites page.
- Only Display Child Tags: This tag is used to group other sites. Those sites should be displayed, but this one should not be displayed. Operators will not need to navigate through this site to reach the child sites.
- Automatic: If this tag contains child sites, folder display will be used. Otherwise, site display will be used.
Map Zoom Level
If Automatic is chosen (the default) then when a map is opened, showing only this site, it will zoom to level 15, which shows only the immediate surroundings. You may select any value between 18 (the closest possible level) and 2 (showing the entire globe).
Default zoom level.
Alarm DatabaseTag Widgets
The following widgets are available to display information about your application’s CalAmp diagnostic driver tags:
