Alarms

The VTScada alarm system does much more than just notify operators when a pump has stopped running, or a well level is low. The system also stores a record of every operational and security event that occurs in the system. To differentiate between the two, the word alarm refers to situations that require an operator's action to prevent damage to life or property. The word event refers to a record of something that did not require an operator's attention.

VTScada has an optional Alarm Notification System that can be configured to contact designated remote operators by voice, pager, SMS text, or email if alarms are left unacknowledged for a defined period of time.

Important Alarm Terms

Active / Active Alarm

The trigger for the alarm has reached or is past the setpoint. For digitals, the tag's value is in the state that triggers the alarm.

Normal / Normalize

After triggering an alarm, the tag's value returns to a normal operating condition. The alarm remains "Current" and must still be acknowledged.

Inactive

There is no such thing as an "Inactive" alarm. The opposite of "Active" is "Normal".
That said, alarms can be shelved by operators or disabled by developers.

Current

Any alarm that is either Active or Unacknowledged.
(But not Shelved or Disabled.)

Trip / Trip Alarm

Seldom used and applies only to alarms triggered by a digital tag's state. Removes consideration of Active or Normalized. A Trip alarm is not included in the list of Active alarms, but it is Current and must be Acknowledged. (Remember, there is no such thing as an "inactive" alarm.)

Shelved

Used by busy operators to hide (temporarily) unacknowledged alarms that are less urgent while dealing with more important tasks.

Disabled

Used by developers to "switch off" an alarm trigger (and any current alarms from that trigger) rather than delete it entirely.

Suppressed

Alarm suppression is applied and removed automatically via a configured expression or tag reference. For example, if a "Low Flow" alarm is configured to detect a low flow rate, but the alarm is meaningless if the pump isn't running, then this alarm should be suppressed when the "Pump Running" tag is FALSE."

Alarm Databases(Alarm Database Tags) and Tag Hierarchies

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