Alarm management

The alarm process begins with the source of a condition that triggers an alarm. After creating the alarm, the system routes it to a recipient whose job it is to manage each alarm using the alarm console.

This simple process provides highly specific and flexible alarming life cycle management.

1. Alarm creation

   Alarms are generated by components using an alarm extension. The alarm extensions create the alarm whenever specified values are outside of normal range. Alarms are then handled by the alarm service.

2. Alarm routing

   In addition to allowing you to specify the routing destinations (including archiving destinations, the alarm service provides notification and acknowledgment properties:

   • Notification

     Alarms are routed to one or more recipients based on the class of the alarm. This includes notification by email, at the alarm console, on a lineprinter, or at one or more remote stations.

   • Acknowledgment

     Alarms may require a response from those who are notified. If a required acknowledgment is not received within an optionally-specified time, alarms can be escalated and re-routed to other designated alarm recipients.

3. Alarm management

   Typically open alarms, (alarms not yet acknowledged and/or acknowledged but not yet transitioned back to normal) are managed using the alarm console. Open alarms can be stored in records that are managed by the local alarm database management interface, as they are often updated (through alarm transitions, acknowledgement, adding notes, etc.) and viewed (via alarm console).

   In Niagara 4.11 and later, there is added support for the Alarm Archive feature in the Alarm Service. The Orion Archive Alarm Provider added to the Alarm Service provides the mechanism to archive cleared and closed alarms. This is useful for customers who need to store a large number of alarms for historical and regulatory purposes. For more details, see “alarm-OrionArchiveAlarmProvider” in the “Components” section of the Niagara Rdbms Driver Guide.