Overview

Alarm notification pipelines are the bridge between alarms becoming active or clear (broadly called an alarm event) to messages being sent out to users. Pipelines are a graphical mechanism for building up logic, providing an easy to use drag and drop mechanism for creating complex notification scenarios. Using pipelines, it is possible to accomplish many tasks, such as alarm escalation, notification consolidation, conditional dispatch, and more.

Pipelines are created in the Ignition designer 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 will run in the gateway, and you will see the same pipelines available to edit regardless of the project that is currently open.

When you create a new pipeline, or select one to edit, the designer switches to the pipeline workspace. The workspace is basically blank canvas, upon 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 starting block 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 many emails for one event!

Blocks are described individually in the next section, but here is a brief overview:

•	Notification - Delivers a notification through the selected Notification Profile.

•	Delay - Blocks the alarm event for the specified amount of time

•	Expression - Evaluates an expression that results in either "true" or "false", and forwards the event to that output.

•	Splitter - Forwards a single event concurrently to multiple other blocks.

•	Switch - Evaluates a non-boolean expression, and forwards to an output based on the result.

•	Set Property - Evaluates an expression, and sets the result as a runtime property on the alarm event.

Pipelines themselves have very few settings, but they are important. They can be seen/modified by clicking on the pipeline workspace anywhere there isn't a block.

•	Enabled - Whether or not the pipeline is allowed to receive events.

•

Dropout Conditions - These dictate when alarms fall out of the pipeline. There are three possible conditions: Cleared, Acknowledged, 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 take for that event.

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.

As mentioned, a new "alarm event" is generated each time an alarm transition 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.

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.