Alarm Notification Pipelines
Alarm Notification Pipelines are logic diagrams that control how alarm notifications are sent out, including who they are sent to and when. They can be used to achieve many advanced alarming scenarios, such as delays, escalation, and parallel delivery. Pipelines provide an easy to use a drag and drop mechanism for creating complex notification scenarios.
Creating Pipelines
Before you create a pipeline in the Designer, you need to configure at least one alarm notification profile and at least one roster in the Gateway. Then in the Designer, you create the Pipelines under the Global node of the Project Browser. Alarm Pipelines, unlike other types of resources such as windows and Transaction Groups, are global resources, and are not part of a project. A defined pipeline runs in the Gateway, and you can see the same pipelines available to edit regardless of the project that is currently open. If you already have a Remote Gateway configured to support alarm notifications, you can expand the already significant power of alarm pipelines by also exposing alarm pipelines that are configured on the Remote Ignition Gateway system.
When you create a new pipeline, or select one to edit, the Designer Switches to the Pipeline Workspace. The workspace is basically a blank canvas, on which you arrange and connect together various Pipeline Blocks. Each pipeline block has an input, and potentially has outputs. Using the mouse, you can draw connectors between the output of one block into the input of another. The START block, which you will see when you first create the pipeline, cannot be deleted and is the only fixed part of the workspace. It represents the entry point for alarm events into the pipeline, and is treated like an output block.
Multiple outputs can be connected to a single input. Also, it is perfectly acceptable to write the output of a downstream block back to the input of an earlier block, creating a loop. Of course, some care should be taken when doing this, as it can easily result in unexpected behavior, like sending out emails indefinitely for one event!
Understanding Pipelines and Events
Understanding how events flow through pipelines is crucial to leveraging them fully. Alarms are configured on individual Tags, and each alarm can specify a target pipeline for active and clear conditions. When the condition for that alarm is met a new alarm event is generated and sent to the entry point of the associated pipeline. The alarm event then moves through the different logical elements of the pipeline until it finally reaches a pipeline endpoint, or until the alarm matches the pipeline's dropout condition, upon which it then exits the pipeline. There can be multiple alarm events in a pipeline at any given point in time and you can view the current status of the pipeline from the Alarm Pipelines status screen in the Ignition Gateway. It is possible to forward events from one pipeline to another, making it possible to create multipurpose and reusable pipelines.
Each alarm event progresses sequentially through the blocks of a pipeline. However, multiple alarm events can exist in parallel in the pipeline, and new events may enter the pipeline at any time. Some block settings may result in alarm events being held up, such as consolidated notification, but one alarm event cannot affect other events in the pipeline. In this particular case, when multiple events will be collected together for notification, the events that don't drop out of the pipeline after notification are individually forwarded to the output of the block.
At every transition, and occasionally inside of the block execution as well, the dropout conditions will be evaluated. If the event no longer meets the conditions, it will drop out of the pipeline. It is crucial to understand how this works in order to understand pipeline execution. For example, a common scenario is to place a Delay block directly in front of a Notification block. If the delay is 5 minutes, and "Clear" is one of the pipeline drop out conditions, it effectively means that only events that stay active for longer than 5 minutes will actually result in notifications. If acknowledge is one of the dropout conditions, it would mean that operators (or anyone viewing alarm status) would have 5 minutes to acknowledge them, and only then would notifications be sent.
Event Instances and Runtime Properties
As mentioned, a new "alarm event" is generated each time an alarm transitions to active. This event consists of core data, but also has arbitrary properties available on it. The alarm configuration properties are available, as well as associated data, but in addition there are "runtime properties", that only exist while the alarm event is in memory, and are only used by pipelines. These properties can be accessed by several block types, and runtime properties can be created and updated with the "Set Property" block type.
During an alarm event's lifetime, its properties may be updated at any time. When an alarm goes to clear, for example, the system sets information about that state on the alarm event. In the pipeline, if a block accessed the "state" property, it would see a different value than if it had checked just moments earlier.
It may be possible for a specific alarm event to exist multiple times in a pipeline. This is especially true when using the Splitter block, which takes events and forwards them concurrently to multiple outputs. When this occurs, the alarm event is "branched" and a new "event instance" is created. Each event instance will start with identical properties, but future modifications of properties will only affect the particular instance. All instances of an event will properly reflect properties set later by the system, such as acknowledgement or clear state.
Pipeline Lifecycle
Given the potentially long running nature of pipelines, it's important to understand how they operate when you edit them. Each pipeline normally has only one instance running at a time, which handles all of the events that go into it. When you edit a pipeline and save, however, a new instance is instantiated. The old instance is "retired", but continues to run until all of the existing events are done. The new instance only receives events generated after the time that it was created, it does not take over the previous instance's events.
Pipeline Blocks
Pipeline Blocks are the building blocks of the Alarm Pipelines. Each block, depending on the type, will perform some action for the pipeline, such as sending a notification, setting a property, or evaluating an Expression. Refer to the Pipeline Blocks section for descriptions of the different pipeline blocks that you can use to build your pipeline.
Pipeline Properties
Pipelines have only a few property settings, but they are important.
To Display and Modify the Properties
Click on the gray area of the Pipeline workspace anywhere there isn't a block.
In the lower-left corner of the Designer, the Pipeline Properties are displayed. They are as follows:
- Dropout Conditions
- These dictate when alarms fall out of the pipeline. There are three possible conditions: Acknowledged, Cleared, and Shelved. If any of the selected conditions become true for an event in a pipeline, it will "drop out" entirely, no matter where it is at. No further action will be taken for that event.
- Pipeline Enabled
- Indicates whether or not the pipeline is allowed to receive events.
Commonly Used Properties
The following screenshot shows how you can access the two commonly used sets of properties in the Expression Block: the Main and State properties.
The Main properties are information about the alarm that are independent of whether the alarm is currently active, clear, or acknowledged. They are:
- Display Path
- Display Path or Source
- Name
- Priority
- Source Path
The State properties are information about the alarm that change while the alarm is changing, and some of them even change each time the alarm goes from active to clear to ack (acknowledged).
- Ack Time
- Ack'ed By
- Ack'ed By (Name)
- Acked?
- Active Time
- Active?
- Clear Time
- Clear?
- Current State
- Event State
- Event Time
- Event Value
- Is Shelved?
Alarm events are made up of many different properties. Refer to the Alarm Event Properties Reference section for information on alarm properties and how they are used.