Niagara Browser Access Guide

Niagara Release 2.3
Revised: August 15, 2002
Niagara Browser Access Guide
Chapter 4 Alarms and Alerts
About Alarms

4–2
About Alarms
The term alarm is widely-used to refer to any unusual occurrence that requires system users to be notified. Once users receive an alarm notification, they may acknowledge it, which validates to the system that it was received.
All system users can view unacknowledged alarms (notifications still pending user acknowledgment. Depending on your security rights, you may also be able to acknowledge alarms. All alarm notifications and subsequent acknowledgments including the user) are archived in the SQL application database for the system.
In a Niagara system, there are actually two classes of such alarms, namely:
•
Events (Alarms)
—Transitions of an object from normal to “off-normal”, and back. Events include application alarms (alarm low, fault condition, etc) as well as system alarms (for example, device down).
•
Alerts
—An alert means some predefined limit has been reached by a binary or multi-state object. This limit is either some amount of elapsed active-time
(runtime) or some amount of COS (changes of state).
In general, alerts are used as reminders for scheduling maintenance on equipment, whereas events (alarms) typically indicate problems that require immediate attention.
E
VENTS
(A
LARMS
)
Typically, most alarms occur from within the various applications upon reaching some predefined limits, which triggers an alarm condition. Alarm conditions mayor may not) result in user notifications, that is “alarms.”
For example, an analog input (AI) object representing a space temperature value may have an alarm high limit of 79.5 F. Upon reaching this value, the object will have an in alarm status, and have a red status color. If so configured, the AI object may also send an alarm notification through the station’s notification subsystem. Consider that alarm detection and alarm notification are separate things. There maybe objects in your system that are configured with alarm limits (or states) but not event enabled This means you may observe them in an alarm or fault condition, but you will not receive alarms from the system about them. In addition, objects maybe configured such that they are event-enabled for transitions into alarm (“to-offnormal”), but not return-from-alarm (“to-normal”). Other objects maybe configured as event-enabled (send notifications) for all alarm transitions. In this case, these objects will require user acknowledgement upon each alarm transition (to or from) any alarm and fault conditions.
When you receive an alarm, you will see information about when it occurred and why is was issued. Specifically, you will seethe current value, from state and to state If the event represents a transition into an alarm condition, you may also see some additional alarm text (depending on configuration).

Download 3.76 Mb.

Share with your friends: