Should my dynamic alarming logic suppress or disable alarms?

In a DeltaV system an alarm can be inhibited using either the Enable (ENAB) or Suppression (OPSUP) field. And in the case of standard alarms, such as the HI_ALM, there is a third method of inhibiting an alarm called conditional enabling. So the question arises which one is best?

Let’s begin with a few definitions. The ISA-18.2 alarm standard defines an alarm as an audible and/or visible means of indicating to the operator an equipment malfunction, process deviation, or abnormal condition requiring a response. The standard defines suppression as any mechanism to prevent the indication of the alarm to the operator when the base alarm condition is present. These two definitions both point to a key consideration, the presence (or not) of an abnormal condition.

So generally speaking, if the reason your logic is inhibiting an alarm is because there is (at that moment) nothing abnormal to bring to the operator’s attention, using the enable field is a good choice. An example application would be to inhibit low-energy alarms when the process is in a de-energized state. A word of caution though; a disabled alarm is permanently and immediately removed from the system so be sure that is what you really want.

The suppression field is a good choice when the purpose of your logic is to prevent the operator from receiving duplicate and consequential alarms when an abnormal condition (requiring operator action) is present. An example application is flood suppression logic, to suppress multiple expected alarms resulting from say a compressor trip, and in their place raise a single common alarm with the appropriate expected post-trip operator action. Note that the calculation of a suppressed alarm’s active/inactive condition continues to function (Hint: use OPCWATCHIT to monitor the alarm’s CUALM field), which can be useful in logic or be used to flag active suppressed alarms in process graphics.

Conditional enabling for standard alarms affects the calculation of the active/inactive condition of an otherwise enabled (ENAB true) alarm. An example application would be to inhibit the generation of new active alarms while still expecting the operator to acknowledge the alarm if it was active (and not acknowledged) at the moment the conditional enabling signal became false. Note that a conditional enable delay can be specified. So for example a pump’s on state (the conditional enabling signal) may need to persist for a specified number of seconds before allowing the positive calculation of an active downstream LO_ALM pressure alarm.