Indefinite parent alarm suppression

When you configure the following fields on the Main tab of the almsuppression Row Edit dialog box as indicated, the system considers alarm suppression to be "indefinite", and suppression will not expire:

• Parent Alarm/Control: 0

• Parent Return to Normal: A non-zero value

So long as the parent remains in the alarm state, the system continues to suppress the child. A point comes out of a suppressed condition when either the parent returns to normal, or the child enters a state that is either not suppressed or not subject to alarm suppression.

The system ceases to generate telemetered alarms for points in a suppressed state. This method of handling alarm suppression can have a potentially undesirable consequence: if the child point is in an unsuppressed alarm state (for example, HiHi), and then enters a suppressed alarm state (for example, Lo), the HiHi alarm remains on the child even though the point is no longer in the HiHi state. This situation arises because the system ceases to generate further alarms to remove the pre-existing HiHi alarm from the Alarm Summary window while the point is suppressed.

Optional functionality controlled by a registry variable enables the system to generate stateless alarms for child points in indefinite alarm suppression.

When generated, the stateless alarm message will look similar to the following:

Suppressed Alarm: Entering Indefinite Suppression. Further alarms suppressed.

The new default behavior is as follows, unless turned off by a registry variable:

• Suppression does not change existing alarms when a parent point enters the suppression-triggering state.

• If a flashing alarm exists when a child is entering a suppressed state again after being previously suppressed, a stateless alarm replaces the existing alarm.

• If a non-flashing alarm exists when a child is entering a suppressed state again after being previously suppressed, the system removes the alarm.

• If no alarms currently exist on a child entering a suppressed state again after being previously suppressed, the system will not generate any further alarms.

When either the parent or child comes out of suppression, the system generates a new alarm on the child if:

• It needs to replace a stateless alarm with an alarm indicating the current state (the stateless alarm implies there was an alarm flashing).

• The child is in a different state than when suppression began, and, had suppression not been active, the Controller would have been notified of the state change. However, no such notification was sent.

If the Controller wishes to understand why they have a flashing stateless alarm, they should refer to events logged for the relevant point.

Note: This functionality does not currently apply to points configured for Timed Parent Alarm Suppression.

The process of enabling Indefinite Parent Alarm Suppression is as follows:

1. Alter the new the key-value pair in the RealTime_AlmSuppressRTN.json file (see Enable the generation of stateless alarms).

2. If desired, extend indefinite RTN Alarm functionality to non-baseline tables (see Extend the generation of stateless alarms to non-baseline tables).

3. If required, change the krunching routine (see Change the krunching routine).

   Note: If large replication deadbands are configured on either the parent or child point, they could prevent the replication of the current point(s) value to the non-owning system. If this occurs, the system would not generate a RTN alarm on the non-owning system.