Create Alarms

All alarms are configured within tags. For some, it is part of the tag's configuration. For example, the I/O and Calculations tag, as well as several legacy types. For most other tag types, or to create an expression that considers several factors to trigger an alarm, you must create an Alarm tag.

Analog Status tags - alarms tab

High alarm within an
I/O tag in analog mode

Alarm tag - Trigger tab

Built-in alarm configuration is always the easiest to configure and in most cases all that you would need. The separate Alarm tag provides the most control over all aspects of alarm configuration.


There are three main parts to alarm configuration:

Alarm Identification

The tag's name, area and description are all important when configuring alarms. Names because that uniquely identifies the source of the alarm. Area because that is often used to sort and filter alarm lists. Also, Rosters for the VTScada Alarm Notification system are keyed to area. And description, because (when available) this is how alarms are reported to operators.

Alarm Trigger

An alarm on an analog tag is triggered by defining a high or low setpoint. When the value reaches or passes the setpoint, the alarm triggers and is said to be in an active state. An alarm on a digital tag is triggered by a given state, activating when the equipment enters that state, whether On or Off, Running or Stopped.

The setpoint can be predefined in the alarm, but it is always possible to configure operator or automatic control over the setpoint.

You might need to avoid nuisance alarms. Use either or both of:

  • Deadband - allows you to specify a range, within which the alarm will remain active if the triggering value retreats from the setpoint.
    The purpose of this feature is to prevent system noise from repeatedly triggering alarms or cluttering the record with repeating events. For example, a high alarm with a setpoint of 80 and a deadband of 2 will trigger when the value reaches 80, and remain in the active state so long as the value is above 78. Without the deadband, if the value hovered above and below 80, then each time it crossed the setpoint a new "active" or "normalized" record would be recorded.
  • Delay - allows you to ignore a brief spike in value.
    If you set an "on" delay, measured in seconds, the value must remain at or beyond the setpoint for that length of time before an alarm is triggered.
    An "off" delay is the reverse, used to prevent the alarm from returning to the normal state if the trigger briefly drops below the high setpoint or rises above the low setpoint.
    For alarms built into other tags, the only available delay is "On". Create a separate Alarm tag if you need an "Off" delay.

Alarm Priority and Action

For alarms built into tags, setting the priority is the step that creates the alarm. While the priority is set to "None", the alarm does not exist.

This tag has a High Alarm. It does not have a High High alarm.

Some developers, working under the idea of "just in case we need it later" have set alarm priorities but also selected the "disabled" option in the advanced mode. It is far easier on system resources to simply leave the priority as None until the alarm is needed.

Stand-alone Alarm tags do not have a "None" priority. They exist when you create them.

There are five priorities defined by five Alarm Priority Tags, which are included in every VTScada application. These control how the alarm looks and sounds (the "actions"). Using the advanced mode of a built-in alarm, or the Actions tab of an Alarm tag, you can override the some of the default actions from the priority and can add others such as enabling pop-ups or rearming.

Alarm tag - Actions tab

Features here include:

  • The ability to disable an alarm.
  • The ability to set a rule that will suppress the alarm.
  • A rearm time. When enabled, the alarm will return to the unacknowledged state after a given length of time if the triggering condition remains active.
  • Trip – For digital triggers only.
  • The name of a .WAV file may be provided in the sound field if you would like a customized alarm sound such as phasers firing or a warning of a warp core breach. (The file should be located in the application folder.)

Level alarms versus trip alarms:

"Level" alarms

Alarms that become active when a setpoint value is reached, and return to a non-active state if the value being monitored is no longer past the designated setpoint.

For example, if the alarm’s high level setpoint is 100 inches, the alarm will activate when the tank reaches that level. If the level then drops below 100 (plus optional deadband), the alarm will return to a normal state. (Although, it must still be acknowledged).

"Trip" alarms

Trip alarms do not have an active or inactive state. Something occurs to trip the alarm and that is all the information that matters.

If you shelve a trip alarm, then the act of unshelving it is taken to be equivalent to acknowledging it, whether you manually unshelve the trip alarm, or allow the shelving time to expire.

They are usually added to digital tags, especially those that read fault status from the PLC. Trip alarms do sound and must be acknowledged. They are alarms.

The term "active" can be confusing. The thing to remember is that it refers to the cause of the alarm, not to the alarm itself, even though you are likely to hear people use the term "active alarm". By that, they mean an alarm whose cause has not returned to a normal operating condition.

There may be situations where the state of the system is not relevant after the alarm starts. All that you care about is that something rang the alarm. This is when you would configure the alarm as a trip alarm. A trip alarm is just as much an alarm as any other, but it will never be included in the list of "active alarms". A classic example is a burglar alarm where the alarm is triggered when the door opens. Nobody cares whether the burglar had the good manners to close the door after entering. The burglar alarm is not in the "active" list but it is still very "current" and there are lots of flashing lights and sirens.

Trip alarms are triggered only by digital I/O (or the equivalent). But there is no requirement that every alarm triggered by a digital value must be configured as a trip alarm.