Emerson Exchange 365

ALM_FLOOD_SUP_32 configuration questions

We are deploying the alarm flood suppression modules and have some questions about the functionality in 13.3.

1.) What is the purpose of the "module bad" alarm and does the default priority of "critical" have any meaning? We are leaning toward rationalizing it out of existence (or at least enabled-ness) unless we can figure out an operator action. I could not find "bad mask" in the module.

2.) When ALM_FLOOD_SUP_32 is tripped, it suppresses all the configured alarms, but does not (?) change the shelving time out setting in the module - correct? So if the detected flood condition persists for longer than the shelving timeout (in our configuration they would all be at the same value) all 32 or 96 alarms will become unsuppressed? So the question is, can we create logic to extend the suppression timeout if the flood condition persists, as it would for an extended outage?

Regards,

John

• Alarm Flood Suppression

John Rezabek

• 14 Jun 2016 4:28 PM
• Cancel

2 Replies

• Kim Van Camp

  

  • 15 Jun 2016 6:39 PM

  1) The MODBAD_ALM alarm alerts someone there is an issue with the module's execution, likely meaning the intended alarm flood detection/suppression is not operative. It's of course your call concerning the a consequent of inaction and expected operator action. Should you decide to leave it enabled you could reduce it to a log priority or redirect it to someone other than the operator though area assignment. The mask I think you are looking for is MERROR_MASK.
  
  2) You are correct. The ALM_FLOOD_SUP_32 module does not manipulate the suppression timer of the individual alarms. In V13.3 and higher we introduced a new native alarm suppression bit for out-of-service (OOS) suppression. In the v13.3 implementation of ALM_FLOOD_SUP_32 this new OOS bit (not OPSUP), plus another new V13 field suppression reason (SUPRSN) are manipulated, such that there is no interference with operator shelving.
  
  More details... OOS operates independent of the operator suppression (OPSUP) bit, and both of them have the same effect which is to suppress the alarm. If either is true, the alarm is suppressed. What is different about them is the suppression timeout (SUPTMR) affects only OPSUP. Their field security is also independent so that operators could be allowed to shelve alarms but not take them out of service. So if the suppression timer times out or the operator manually un-shelves the alarm making OPSUP false, it will still be suppressed as long as OOS is true. Also in V13.3 there is a new native alarm suppression reason field (SUPRSN) which can be set be either logic or a user performing the suppression. An associated name set allows you to define the reason selections. The pre-v13 versions of the module uses OPSUP. In a pre-V13 system one could construct additional logic in the module to manipulate the suppression time (SUPRSN) and or the countdown timer (SUPTMR). The ALM_FLOOD_SUP_32 module also has its own configurable suppression timeout, with three timeout options; to un-suppress all, re-suppress all, or re-suppress the active alarms and un-suppress the inactive ones. So this module suppression feature might factor into any logic changes you would want to make.

  • Cancel
• John Rezabek

  

  • 15 Jun 2016 7:42 PM

  In reply to Kim Van Camp:

  That's excellent and I'm glad I waited for 13.3 to deploy the flood suppression. If I have "zero" for the flood suppression timeout, then suppression (OOS bit) is removed when the logic ceases to be true (by virtue of voting or required conditions no longer being true). When that happens, the options are the same as the timeout options? Is there a clever way to leave OOS enabled until the alarm condition clears, then remove it?
  
  In light of that, our operations manager will probably elect to simply un- suppress the flood en masse even though it creates another (hopefully minor) flood. I think I saw some "delays" so we could perhaps make a little space between the end of flood suppression and the onslaught of alarms . . .
  
  Or maybe another timer that fires the "un-suppress" action block after a period of time, or after another condition is met.
  
  The "remain OOS until not in alarm" might be a good one for the wish list. Since you must be monitoring the actual alarm state of each alarm in the module, it might be conceivable to fire it (the un-suppress action block) again as each alarm changed state?

  • Cancel