Alerts and Alarms - An Overview

The devices supported by the Questra IDM Application Suite are continually being monitored to assess their operational status. Generally speaking, when something is "wrong" with a device (it may be low on water, running too hot or too cold, or otherwise be malfunctioning), an alarm is raised and the users responsible for servicing that device are alerted that the device needs attention.

For every problematic condition that a device may experience, the administrators will have defined an alarm. Think of an alarm as a definition or description of a problematic condition. Some alarms can also describe conditions in which something fails to happen, such as when a device fails to send its readings to the Enterprise at its scheduled time. The table below describes the various default alarms.

NOTE: The term asset as used in an alarm name means the same thing as device.

Each defined alarm describes one particular condition, and (generally speaking for the sake of this discussion) each is associated with one or more alerts. An alert is an instruction that describes what the Enterprise will do when the alert's associated alarm is raised. There are several types of alerts, but the one that pertains to users most frequently is the type Email alert, which instructs the Enterprise to email alert notifications to the owners of the group to which the device belongs (that is, to the users responsible for servicing the device). (Another type of alert might pertain to notifications from a CRM system.)

An alarm event is an individual instance of an alarm condition detected on a device. For example, if a property of a device, such as its temperature, is detected as being outside of normal parameters, an alarm event is generated. In fact, when a device is malfunctioning, there may be multiple alarm events generated because several properties may be outside of normal parameters at the same time. For each alarm event that is generated, the Enterprise generates an alert request.

Consider the following example: Assume that the Enterprise has a rule for evaluating a motor temperature against a threshold and that a "Motor Over Temperature" alarm has been defined. This alarm is associated with an alert of the type Email alert. When a motor temperature reading is received by the Enterprise, it is evaluated by the motor temperature rule. If the motor temperature exceeds the threshold, the rule triggers the "Motor Over Temperature" alarm and a "Motor Over Temperature" alarm event is generated. In turn, an alert request of type Email alert is generated and its processing is begun.

The system manages alert requests from their generation to their completion. At any given time, an alert request will be in a certain state. In the user interface, you will see references to the states of alert requests, so it is important that you understand them. The following figure illustrates the states through which an alert request may pass in its processing, and the table defines these states.

When you receive an emailed alert notification for a device you service, you will need to sign into the system, acknowledge the alert, take the necessary action to clear the alarm condition on the device, and finally close the alert. If you are unable to acknowledge the alert within a reasonable timeframe (as defined by your administrator), the alert will be escalated to the owners of the parent group to which your group of devices belong.

NOTE: As you use the system, you will see references to alerts and alarms on screen and in reports. Technically speaking, these are alert requests and alarm events, as described above. We've shortened these terms in the user interface for simplicity.