Alarm

Introduction

The Alarm module provides core functionality for lifecycle managment of alarms within the Baja framework. Alarms are used to indicate that some value is not within an appropriate or expected range. Alarms may be routed from the system to a variety of external sources, be it email, a printer or a console application.

Object Model

All alarms in the Baja Framework are generated by objects implementing the BIAlarmSource interface. Those alarms (BAlarmRecord) are then routed to the BAlarmService. The service for storing and routing of alarms. Alarms are then routed to one or more recipients (BAlarmRecipient) via their BAlarmClass.

Alarm Sources

While BIAlarmSource is an interface, most alarm sources are instances of javax.baja.control.alarm.BAlarmSourceExt, the alarm point extension. The alarm extension determines when it's parent point is in an alarmable condition, and uses the AlarmSupport class to take care of routing and issuing alarms to the alarm service. The alarm source updates the alarm when the parent point goes back to its normal condition as well as notifies the point that an acknowledgement has been received.

Objects implementing BIAlarmSource that have a status (BStatus) should use the following rules when setting the status bits.

Generate Offnormal alarm: set the BStatus.ALARM and BStatus.UNACKED_ALARM bits.
Generate Fault alarm: set the BStatus.ALARM, BStatus.UNACKED_ALARM and BStatus.FAULT bits.
AckAlarm methods is called: if the alarm is the last one generated clear the BStatus.UNACKED_ALARM bit.
Generate Normal alarm: clear the BStatus.ALARM and BStatus.FAULT bits.

Note that BStatus.UNACKED_ALARM should only be set if the BAlarmClass.ackRequired bit is set for that transition in the AlarmSource's AlarmClass. This can easily be ontained if using the AlarmSupport class by calling BAlarmSupport.ackRequired(BSourceState state).

Alarm Service

The BAlarmService coordinates routing of alarms within the framework. It routes alarms from their source to the appropriate recipients, and alarm acknowledgements from the recipients back to the source. The alarm service routes individual alarms via their alarm class. All alarm classes available to the system are maintained as slots on BAlarmService. The BAlarmService also maintains the Alarm Database. It is acessed though the getAlarmDb() method.

Alarm Class

The alarm classes, as stated above, are maintained as slots on the alarm service and serve to route alarms with similar sets ot properties along common routes - they serve as channels for like data. BAlarmClass manages the persistence of the alarms as needed via the alarm database. The AlarmClass manages the priority of an alarm and also which alarm require acknowledgement. Each alarm class can be linked to one or more alarm recipients.

Alarm Recipients

Alarm recipients are linked to an alarm class (from the alarm topic on the alarm class to the routeAlarm action on BAlarmRecipient.) Recipients may be configured to receive alarms only at certain times of day, certain days of the week, and receiving alarms of only certain transitions (eg. toOffnormal, toFault, toNormal, toAlert).

Three subclasses of BAlarmRecipient are worth noting: BConsoleRecipient, BStationRecipient and BEmailRecipient.

BConsoleRecipient

This recipient manages the transfer of alarms between the alarm history and the alarm console, i.e. it gets open alarms from the alarm history for the console and updates the history when they are acknowledged.

BStationRecipient

This recipient manages the transfer of alarms between the alarm service and a remote Niagara station.

BEmailRecipient

The email recipient is part of the email package. It allows alarms to be sent to users via email.

Lifecycle

Each alarm is a single BAlarmRecord that changes throughout its lifecycle. An alarm has four general states that it may be in:

New Alarm
Acknowledged Alarm
Normal Alarm
Acknowledged Normal Alarm

All alarms start as New Alarms and end as Acknowledged Normal Alarms. They may be acknowledged then go back to normal or go back to normal then be acknowledged.

An Alert is an alarm that does not have a normal state and thus its lifecycle consists of New Alarm and Acknowledged Alarm.

Alarm Routing Overview

New Alarms

BIAlarmSource generates an offnormalAlarm (or faultAlarm).
It is sent to the BAlarmService
BAlarmService routes it to its BAlarmClass.
The BAlarmClass sets the alarm's priority, ackRequired bit, and optional data.
It is then routed to any number of BAlarmRecipients.

The normal alarm is sent along this same path.

Alarm Acks

When a BAlarmRecipient acknowledges an alarm, the acknowledgement is sent to the BAlarmService
The BAlarmService routes back to the BIAlarmSource (if an ack is required).
The Alarm Acknowledgement is then routed to AlarmRecipients along the same path as a New Alarm.

Usage

Setup

The most basic piece needed is a control point. Then add an alarm extension from the alarm module palette. There are several types of extensions depending upon the type of point selected. The AlarmExtension are disabled by default. You must enabled toOffnormal or toFault alamrs and configure and enable the alarm algorithms.

An Alarm Service is also required. Depending on your needs, it may require some of the following slots:

Any desired BAlarmClasses should be added.
A BConsoleRecipient should be added if an alarm console is required.

Link any of the slots as needed. The alarm recipients must be linked to an alarm class in order to receive alarms from that alarm class.

To generate an alarm, go to a point with an alarm extension and put it an alarm condition.

Console Recipient / Alarm Console

To view all of the outstanding alarms in the system, double click on the console recipient on the alarm service. The alarm console manages alarms on a per point basis. Each row in the alarm console is the most recent alarm from a point. To view all the current alarms from that point, double click the row. To acknowledge an alarm, select the desired alarm and hit the ack button. An alarm is cleared from the alarm console when the alarm is acknowledged AND the point is in its normal state. To view more information about an unacknowledged alarm, right click and select View Details.

Station Recipient

A BStationRecipient allows sending alarms to remote Niagara stations. A remote station is selected from the stations you have configured in your Niagara Network. This recipient require that the remote station be properly configured in the Niagara Network.

Line Printer Recipient

A BLinePrinterRecipient allows printing of alarms on a Line Printer. This recipient is only availible on Win32 Platforms. It supports both local and remote printers.