next up previous contents
Next: 3. Notification type and Up: Alert/Notification Requirements Previous: 1. Introduction   Contents

Subsections

2. Notification Triggering Requirements

This section will discuss the requirements for the rules which will define whether a notification will be sent.

2.1 Data used within the triggering rules shall be available in the Status Server

The rules used to define the notifications will be based on data which is currently in the Status Server. The notification system will not be required to source data outside of the Status Server. If external data is considered necessary to be part of a notification rule, it must first be pushed to the Status Server. For example, if Allen-Bradley PLC information is used within a notification rule, it must first be made available to the Status Server. The notification system will not communicate directly with the PLC device.

2.2 A simple and well described syntax must be available to define notification rules

One of the goals of the notification system is to make it easy for individuals, who wish to receive notifications, to define and adjust the rules which trigger the notifications themselves.

A likely mechanism for defining the rules is a C-style regular expression syntax. For example, here is a simple rule which might trigger if there is a potential problem with the vacuum system for MegaPrime.


((/i/megacam/fipvar/cryoErrors/vacuumCritical == ``TRUE'') ||
 (/i/megacam/fipvar/cryoErrors/vacuumOutOfRange == ``TRUE'') ||
 (/i/megacam/fipvar/cryoErrors/vacuumTooHigh == ``TRUE'') ||
 (/i/megacam/fipvar/cryoErrors/vacuumTooLow == ``TRUE''));

I would anticipate that many triggering rules will be more complex than this example.

2.3 It must be possible to specify a time-based rule conditions

It must be possible to define rules which will be triggered only after a parameter or set of parameters is at the same value for a given duration of time. For example, there are cases where a subsystem will be turned on and some settling will occur before a parameter becomes stable. Hopefully this can be illustrated more clearly with a picture. Figure 1 shows the case where some time may be required for a parameter to settle within its operating threshold. In this example, the notification rule could be set up to only trigger after the on switch has been in the ``ON'' state for at least 15 minutes.

Figure 1: Parameter Settling Example
\begin{figure}
\centering\epsfig {file=settling.eps}\end{figure}

2.4 It must be possible to trigger rules on both valid and invalid data

The data in the Status Server is usually valid if the supplying client is actively providing information. However, if the client were to go away, or if the data goes stale (lifetime exceeded), the data will be considered ``EXPIRED''. An example of this is the datalogger. The datalogger updates the Status Server every 10 seconds. If a new set of updates is not received within 20 seconds, the data will go expired. It must be possible to specify rules which trigger on data changing between a valid and invalid state and vice-versa.

2.5 It must be possible to suppress repeat notifications for a period of time

If a rule is triggered, it must be possible to suppress a repeat notification based on the same rule for a predefined period of time. For example, if a notification is generate on the following rule.


(/i/megacam/fipvar/cryoErrors/vacuumOutOfRange == ``TRUE'');

It may be possible that the vacuum system is right on the threshold of going out of range. If the ``vacuumOutOfRange'' variable begins to oscillate between ``TRUE'' and ``FALSE'', it must be possible to suppress multiple notifications each time the variable changes to a ``TRUE'' for a predefined period of time.


next up previous contents
Next: 3. Notification type and Up: Alert/Notification Requirements Previous: 1. Introduction   Contents
Tom Vermeulen
2004-04-30