Alarming
Alarms are always configured on a tag, excluding Vision Client tags. Every time a tag with a configured alarm receives an updated value, the configured alarm will examine the new value. If the new value on the tag meets some criteria, as defined by the alarms mode settings, then the alarm generates a new alarm event.
Alarms are monitored by the Gateway, and are considered Gateway-scoped. However, some module features and functions can be used to monitor the live status of alarm events.
Alarm Events​
Each alarm event contains several attributes that store metadata about the source tag at the time the alarm event was created. Alarm events are effectively a "snapshot" of several parameters when the alarm went active. Tags can have multiple alarms configured on them, meaning that it's possible for multiple alarm events to be created from a single value change on a tag.
Alarm Events and Their States​
The state of an alarm event is determined by two conditions, Active and Acknowledged.
Active Condition​
Determines if the alarm is active, or "live".
All alarm events start with an Active condition, and then move to a Cleared condition. Alarm events never transition from Cleared to Active. Instead, a new alarm event would be created should the value on a tag meet the setpoint criteria.
- Active - The alarm event is still active. Meaning, the value on the source tag still meets the setpoint configured on the alarm. If the alarm is used to signal that there's a problem, then the active condition means the problem is still active.
- Cleared - The alarm event is no longer active. The value on the source tag no longer meets the setpoint configured on the alarm.
Acknowledged Condition​
Alarms feature an Acknowledgement functionality. Acknowledgement is simply a flag that can be marked on an alarm event. Commonly the acknowledged condition is used as a way for users to signal to other users that an alarm is being handled.
Imagine a scenario where multiple operators are monitoring any alarm events that occur. Acknowledgement allows an operator to "claim" an alarm, signaling to the others that the event is being handled by someone.
Alarm event acknowledgement is generally handled by either the Vision or Perspective Alarm Status Table components, or the system.alarm.acknowledge function.
- Unacknowledged (Unacked) - The alarm event has not yet been flagged as "acknowledged".
- Acknowledged (Acked) - The alarm event has been flagged as "acknowledged".
Alarm Event States​
The two conditions above are combined form the state of an event. The four possible states are:
- Active and Unacknowledged
- Active and Acknowledged
- Cleared and Unacknowledged
- Cleared and Acknowledged
Alarm Count Tags​
Ignition provides a set of System Tags to view information about the Ignition server which includes four tags that count the number of alarms in each state. A quick way to see if any alarms are currently active and get an alarm count is to add Label components bound to these tags.
To view these tags, open the System Tag Provider in the Tag Browser of the Designer, and navigate to the Gateway > Alarming folder. These System Tags can easily be used to visualize all alarms in the system.
Alarm Shelving​
Shelving an alarm tells the alarm system that it should ignore the alarm, preventing new alarm events from being created. Shelving always has a duration associated it. At the end of the shelving period, the alarm will evaluate it's source tag, potentially creating a new alarm event. Shelving is useful to temporarily ignore an alarm for a period of time, such as maintenance periods.
Shelved alarms will not generate alarm notifications. In addition, shelving an alarm will hide all alarm events for that alarm from the Vision and Perspective Alarm Status Table components.
Alarms in Transaction Groups​
OPC items in Transaction groups can also have alarms configured on them, similar to tags. This functionality exists mostly for legacy reasons, and offers no real benefit over configuring alarms on a tag instead.
Configuring Alarms​
Alarm configuration in Ignition is flexible and highly customizable to your needs. You can configure alarms with one alarm on a tag or multiple alarms on a tag. You can add alarms in UDTs so every instance of that tag will automatically have alarms configured when a new instance of your tag is created. You can use the alarm settings to create alarms that equal or don't equal a setpoint, above or below a setpoint, between setpoints, outside setpoints, dynamic setpoints, out of range, bad quality, etc. Alarms can be configured for any alarm condition imaginable.
More information about configuring alarms can be found in Alarming Properties and Configuring Alarms pages.
The image below shows an alarm configured on an OPC tag. You can see that an alarm has quite a few properties including alarm mode settings where you can set specific alarm attribute values.
Monitoring Alarm Status​
Alarms can be monitored from Vision and Perspective using their respective Alarm Status Table components. In addition, the system.alarm.queryStatus function can be used to retrieve realtime alarm status.
Viewing Alarm History​
The Alarm Journal stores historical information about alarms in a database. It stores basic data about alarms that have occurred, such as their source and timestamp, associated data on an alarm, and the values of an alarm's properties at the time the event occurred. It captures all status changes for each alarm to an external SQL database of your choosing. To begin viewing alarm history, all you need to do is create an Alarm Journal Profile on the Gateway webpage.
Like the Alarm Status Table, both Vision and Perspective have components that can be used to view entries in an Alarm Journal.
Filtering Alarms​
The Perspective and Vision Alarm Journal Table and Alarm Status Table components, along with Alarm Journals on the Gateway, all contain filter properties to further determine which alarms appear or are logged. By default, all alarms within the system are included, but in many cases it can be desirable to only show a subset of alarms. Strings can be entered in these fields, including wildcards, and you can enter multiple comma-delimited values to filter by. The filtering properties for components can also be bound so the paths are dynamically created.
Display Path​
The default value for an alarm's Display Path is the tag path that leads to the name of the alarm. For example, if there is an alarm named High Alarm on a Ramp3 tag within a Ramp folder, the Display Path would be Ramp/Ramp3/High Alarm. However, the Display Path can be customized when configuring the alarm by entering the desired path into the Tag Editor > Alarms > Display Path field. This is generally utilized to display messages describing the issue the alarm is tracking.
To filter entries on the table by the Display Path, simply set a value on the Display Path Filter property. The * wildcard can be used in the Display Path string.
Source Path​
The Source Path is also a path to the alarm, but it uses a different syntax and includes the Tag Provider the alarm is located in. If the name of the Tag Provider is Sample_Tags, then the source path using the same tag as the Display Path Filtering example would resolve to prov:Sample_Tags:/tag:Ramp/Ramp3:/alm:High Alarm. Unlike the Display Path, the Source Path on an alarm can never be overridden.
To filter entries on the table by Source Path, simply set a value on the Source Filter property. The * wildcard can be used in the Source Filter. See the Source Path Filter Examples table below for more use cases.
Source Path Filter Examples​
Since the Source Path is made up of the alarm name, the tag path to the host tag, and the Tag Provider the tag resides in, the Source Filter property can be used to filter on tag folders and Tag Providers. For example, you may want the table to only show alarms that contain a certain term or folder path. The table below demonstrates some filters as well as some hypothetical results.
| Example Filter | Result |
|---|---|
prov:tagProvider:/tag:Inputs/PS_1:/alm:MyAlarm | Retrieve alarm information from the alarm at precisely the specified path: prov:tagProvider:/tag:Inputs/PS_1:/alm:MyAlarm |
*PS_1:/alm:MyAlarm | Retrieves alarm information from any path that ends with PS_1:/alm:MyAlarm. The following paths would be returned: prov:tagProvider:/tag:Inputs/PS_1:/alm:MyAlarm prov:tagProvider:/tag:anotherFolder/different_Path/PS_1:/alm:MyAlarm |
prov:tagProvider:/tag:PS_* | Retrieves alarm information from any source path starting with prov:tagProvider:/tag:PS_, such as: prov:tagProvider:/tag:PS_1:/alm:MyAlarm1 prov:tagProvider:/tag:PS_2/Tag2:/alm:MyAlarm2 |
*MyAlarm* | Retrieves any alarm information that has MyAlarm somewhere in the path. |
Alarm Notifications​
Alarms can also generate notifications that are delivered to users allowing Ignition to immediately communicate events and problems to your users. Alarm Notification Pipelines control how and when notifications are sent to users. You can select the delivery channel for how alarms are sent: Email, SMS, or Voice. The notification system has access to Ignition's Authentication Profiles so users can easily be added to notification On-Call Rosters. Schedules can be created allowing users to receive notifications only when on-schedule, so there is no need to worry about notifying a supervisor or manager when they are not on-site, or if it's in the middle of the night. Pipelines coupled with on-call rosters and schedules allow you to build your own custom alarm notification process.
On-Call Rosters​
The On-Call Roster is a collection of users that are notified when an alarm occurs. When an alarm is triggered, a notification is sent to a designated On-Call Roster where it evaluates the users schedules, and only notifies those users that have an active schedule.
Roster Management from the Vision Client Window
Alarm Notification Pipelines​
The Alarm Notification Pipeline feature is an innovative tool that lets you easily create routes for your alarms. By designing your own alarm notification routing, you have control of what happens when an alarm goes active, when an alarm is sent out, and who receives the alarm notification.
The alarm notification pipeline has a simple drag-and-drop interface so you can build various types of alarm logic. Alarm notification pipelines can be very simple to very complex. In this simple notification pipeline, when an alarm is triggered, the people listed in the On-call Roster are notified via Email. If no one acknowledges the alarm in 20 seconds, the alarm notification is routed back to the same users listed in the On-Call Roster.
In this more complex alarm notification pipeline, if an operator doesn't respond to the alarm after three attempts, the pipeline jumps it to another pipeline (possibly an escalation pipeline).
To learn more about building your own pipelines, go to Alarm Notification Pipelines.