Emerson Exchange 365

• Not Answered

Flood Suppression field test - success! . . . and some unforeseen features (?)

We have begun deploying alarm flood suppression using the new module templates provided in 13.3 We recently had a short planned outage where one of the module's trip logic was invoked and about 90 alarms were automatically suppressed. We were all present to witness this and it made a significant difference in the level of distraction on the board. One or two additional alarms were uncovered that were candidates for suppression.

Upon starting back up, we anticipated the point at which the suppression logic would cease to be true. We had selected the option "Active Suppressed" which would unsuppress only "inactive" alarms when the flood clears (assume this means when the logic is false) or the suppression "timeout" has expired. When the votes to invoke suppression were no longer sufficient, all alarms became unsuppressed (both ACT and INACT state). But there was no flood - there was no additional noise or "flood" of alarms. Points in alarm on graphics did now light up with the color corresponding to their priority, but they behaved as if they were in the "active acknowledged" state - they made no noise.

Could it be that an OOS alarm doesn't have an "ACT" or "INACT" alarm state, so (therefore) the logic just removed suppression from all alarms?

1.) Is this the expected behavior? We think we like it - there's no self-inflicted "flood" when suppression is removed - but we thought the active alarms would have remained "suppressed" (OOS in 13.3). We can see in the event journal, somewhere around thirty of the previously suppressed (OOS) alarms were still "in alarm", but came back in the ACT/ACK state.

In the event journal, we can see some of the alarms took up to 5 seconds after the flood modules became false, before they registered as ACT/ACK. Since the "remove suppression" logic looks like a one-shot or one-scan action in the flood suppression module, why doesn't DeltaV have issues writing to a parameter that's in a module executing much less frequently?

• flood suppression
• alarm management

John Rezabek

• 29 Jun 2016 9:08 PM
• Cancel

2 Replies

• Kim Van Camp

  

  • 30 Jun 2016 2:32 PM

  John,
  
  Pleased to hear the module is working to suppress alarm floods. Now on to your questions and observations...
  
  When an alarm is suppressed, by either being out-of-service (OOS) or operator suppressed (aka shelved via OPSUP) the calculation of the alarm’s active/inactive condition continues to function. One way to observe this is with the latest version of the Alarm Help window in V13 which displays the suppression trigger (OOS or OPSUP), suppression reason and active/inactive condition. Alarm Help is available without a license on the ProPlus. Another way is with the new out-of-box DeltaV display dynamos that have an icon (bell on a black background) indicating a suppressed active alarm.
  
  Your observations don’t align with the expected behavior for the selected timeout option of ‘Active Suppressed’. Would you be open to a WebEx to look at it together… providing an updated post to this blog afterwards so others know what happened?
  
  Expected behavior:
  
  1) When the dynamic alarming module (ALM_FLOOD_SUP) is in an ARMED state and it detects the necessary conditions to take action the module goes to a TRIPPED state. Alarms in the suppression group are suppressed and a timer (SUP_TIMEOUT\TIME_DURATION) starts counting down. You can observe the state change and timer countdown on the module’s faceplate. The default time duration is 30 minutes/1800 seconds.
  
  2) When the necessary conditions to take action are removed or the timer reaches zero, whichever happens first, the module takes one of three actions according to the selected TIMEOUT_OPT; where the choices are Active Suppressed, None Suppressed or All Suppressed. The expected behavior for Active Suppressed is that inactive alarms are unsuppressed and the active alarms are suppressed.
  
  3) The module will transition out of the tripped state to the ARMED state when the condition block AUTO_RESET becomes true for the block’s specified TIME_DURATION, which is 10 minutes by default. The default expression in the AUTO_RESET block evaluates as true when the necessary conditions to trip the module have been removed. When the module returns to the ARMED state every alarm suppressed by the module is unsuppressed, and the COMMON_ALM raised by the module becomes inactive.
  
  4) In addition to AUTO_RESET there are two other ways to rearm the module. By either using the RESET button on the detail display or by disabling/re-enabling the module through use of the Supervisor and Operator buttons on the faceplate.
  
  The behavior you described seems to suggest the module is unexpectedly transitioning from the tripped/timed-out state to a re-armed state, or that the TIME_OUT option is None Suppressed.
  
  I’ll have to check into your last question about module execution timing.

  • Cancel
• Andre Dicaire

  

  • 4 Jul 2016 11:06 PM

  Can you confirm scan rate of the modules that took up to 5 seconds to register their change of state to ACT/ACK? Also, are these alarms in function blocks assigned to FF devices or are these alarms associated with Controller Function blocks?
  
  I would expect that if the modules have a 5 second execution rate, this would be normal. The change of state of the alarm actually happens when the module executes, and the time stamp is set accordingly.
  
  Although you can have several hundred modules in a controller ( no set limit actually) only one module is ever executing at a time. You read and write to parameter memory locations and values hold until they are changed. When you write to the OPSUP or OOS, you don't actually write the state of the alarm to ACT/ACK. The alarm state will change as a function of the current alarm trigger, and go to ACT/ACK or INACT/ACK, when the module executes.

  Andre Dicaire

  • Cancel