Emerson Exchange 365

• Not Answered

Configuration of ALM_FLOOD_SUP module in DeltaV

Hi,

I am trying to configure the advanced alarming module ALM_FLOOD_SUP for alarm masking following a compressor trip and have a few questions -

1. Once the unmasking logic is triggered following AUTO_RESET and the chosen TIMEOUT_OPT is None Suppressed, is it possible to delay the actual unmasking of the alarm to the operator by a specified period of time configured on an alarm by alarm basis (e.g. using the HI_AUTO_UNMASK/TIME_DURATION parameter for a particular High alarm) ? Or does the unmasking to the operator happen instantly after AUTO_RESET?

2. Can the SUP_TIMEOUT parameter be configured to start counting down once the AUTO_RESET condition block is satisfied before unmasking all alarms? The aim is to have this timer to be longer than the individually configured unmasking timers above.

3. What is the logic that would be needed in the DYN_PRIORITY action block if the alarm priority state required is Mask?

Any other configuration tips would be appreciated, thank you.

• alarm masking
• ALM_FLOOD_SUP configuration
• advanced alarming

yashdongre

• 10 Aug 2016 8:15 AM
• Cancel

6 Replies

• Kim Van Camp

  

  • 10 Aug 2016 2:00 PM

  In the DeltaV V13 edition of the ALM_FLOOD_SUP module, the suppression bit that is used is OOS (Out of Service) where in prior DeltaV versions the suppression bit used is OPSUP (Operator Shelving). OPSUP is automatically cleared by the configurable timers available for each alarm in the alarm properties dialog, independent of the ALM_FLOOD_SUP module. OOS has no unsuppression timer so it must be manually or programmatically cleared. In DeltaV V13, OOS and OPSUP are both available, plus there is another new bit SUPRSN to set a reason for suppression using a name set.
  
  There are actually two timers at work in the module. The first one is the TIME_DURATION parameter on the function block SUP_TIMEOUT. When the module is armed and the trigger conditions are present the alarms are suppressed and this timer starts counting down. When either the conditions necessary to trigger the module are no longer satisfied or this timer reaches the end, the module will take one of three actions per the TIMEOUT_OPT. I see that you chose the action None Suppressed, and thus all alarms would be unsuppressed (OPSUP cleared or OOS cleared per your system version).
  
  The second timer is specified by the TIME_DURATION parameter of the function block AUTO_RESET. The block is intended to automate the rearming of the ALM_FLOOD_SUP module. The default logic in the block is a simple check that the conditions necessary to trigger the module are no longer present. The idea here is to prevent an immediate retriggering of the module.
  
  Getting to your questions.
  
  1) The TIME_OUT option (action taken) is related to the SUP_TIMEOUT/TIME_DURATION, not to AUTO_RESET. If the module is using the bit OPSUP, then individual alarms can each have a different maximum suppression duration. When the AUTO_RESET logic is satisfied for the AUTO_RESET/TIME_DURATION every alarm will be unsuppressed as part of rearming the module.
  
  2) The design intent for the two blocks SUP_TIMEOUT and AUTO_RESET are different and both have their own timer. I’d suggest experimenting with the two timers and perhaps also with the TIMEOUT_OPT choices to attain the desired behavior. Given you've selected the option 'None suppressed' all alarms will be unsuppressed when the first timer times out so it's a moot point how long it will be after that until the module is re-armed by the AUTO_RESET block.
  
  3) The function block DYN_PRIORITY default logic can reprioritize alarms, when the module is triggered and when it is rearmed. The function block uses the PRIORITIES parameter, which is an array where each row corresponds to one of the alarms and each column corresponds to one of the index values of the PRIORITY_STATE named set. The default name set is Alarm_Group_Mode where 0 is Disabled, 1 is Normal and 2 is Tripped. The DYN_PRIORITY logic will set an alarms priority according to the array. If the cell in the array is 0, the alarm is left at its current priority. If the cell contains a non-zero value the alarm is set to that priority; e.g. 7 = Advisory. By default the ALM_FLOOD_SUP module does not change any alarm priorities when the module is tripped or rearmed (normal) because the array contains all zeros by default.
  
  There is a whitepaper available that provides information on the technical workings of this module, and also of the First-out module FO_ALM_SUP. See the website www2.emersonprocess.com/.../index.aspx The downloadable zip file at the bottom of this webpage includes the whitepaper.

  • Cancel
• yashdongre

  

  • 11 Aug 2016 7:56 AM

  In reply to Kim Van Camp:

  Thanks a lot for the helpful and detailed response and the resources! I am working with DeltaV v12. I have a couple of questions following on from what you said -
  
  1. You mentioned that if OPSUP is used it is possible for individual alarms to have different maximum suppression timers. Would this timer be configured in the Alarm On-Delay parameter or the previously mentioned AUTO_UNMASK/TIME_DURATION parameter? I want to check whether configuring this suppression timer will affect the alarm annunciation during normal operation or whether the timer is independent.
  
  2. If I use the AUTO_RESET/TIME_DURATION to configure a timer along with some conditions to be satisfied in the AUTO_RESET block, is it possible for alarms to be unsuppressed before that timer runs out provided the voting and required conditions are no longer satisfied?
  
  Thanks in advance.

  • Cancel
• Kim Van Camp

  

  • 11 Aug 2016 2:27 PM

  In reply to yashdongre:

  Q1: Using DeltaV Explorer select one of the control modules (E.g. LIC101) that contains one of the alarms you are working with in the ALM_FLOOD_SUP module. Right-click on one of the alarms to open its context menu, then select Properties. The Alarm Suppression Timeout is on the advanced tab. Beginning with V13, the field was relabeled "Alarm Shelving Timeout" to clarify that that it only applies to Operator Suppression (OPSUP) and not to Out-Of-Service. The shelving (suppression in v12) timeout of the alarm is completely independent of the logic in the ALM_FLOOD_SUP module.
  
  Q2: Yes, alarms can be unsuppressed before the AUTO_RESET/TIME_DURATION timer runs out. And from what you have told me the module is already set up to do that. See 2-4 below.
  
  The action you said you selected is 'None suppressed' so I would expect the module to work as follows:
  1. When process conditions indicate a compressor trip (or whatever it is you are wanting to detect), the individual alarms that you specified related to the compressor are suppressed and a new "Compressor Trip" common alarm is raised.
  2. if process conditions indicating the compressor trip clear, the selected action is immediately taken, skipping past step 4.
  3. If process conditions indicating the compressor trip persist, the timer on the faceplate (SUP_TIMEOUT/TIME_DURATION) will eventually reach zero, causing the selected action to be taken. Think of this as the time you've allotted for the operator to deal with the compressor trip, say for example 60 minutes.
  4. You selected the action of "None Suppressed" so all alarms will be unsuppressed. (Note: The other 2 choices are to keep all the alarms suppressed or to only keep suppressed the alarms that are still in an active condition.)
  
  At this point the module has done it work and all that remains is to reset/rearm it to be ready for the next compressor trip. Rearming the module includes unsuppressing all alarms, which is needed if one of the other two actions was selected. In your case it is a moot point since all alarms were unsuppressed in step 4.
  
  5. The operator can manually reset/rearm the module.
  6. The operator can do nothing and eventually the module will rearm itself when the conditional logic in the AUTO_RESET block is true for the RESET/TIME_DURATION. The default logic only checks that process conditions no longer indicate a compressor trip.

  • Cancel
• Kim Van Camp

  

  • 11 Aug 2016 2:40 PM

  In reply to Kim Van Camp:

  A correction and a suggestion. The correction... in 2, I meant to say "skipping past step 3" The suggestion... if my latest post did not meet your needs, I suggest we reset the conversation by you describing your desired alarm flood suppression behavior. Then we can decide how (or even if) the ALM_FLOOD_SUP module can do what you want.

  • Cancel
• yashdongre

  

  • 11 Aug 2016 4:03 PM

  In reply to Kim Van Camp:

  Kim, thanks a lot for your help here in clarifying my doubts, it has helped immensely. I will give it a try and get back to you in case the advice does not meet my needs.
  
  Thanks again,
  
  Yash

  • Cancel
• yashdongre

  

  • 1 Sep 2016 3:01 PM

  In reply to Kim Van Camp:

  Hi Kim,
  
  After reviewing your suggestion, I believe using Unmask Inactive for TIMEOUT_OPT is the more appropriate option . I am using DeltaV v12. I just wanted to clarify how inactive alarms would be unmasked in this option.
  
  Is it possible to check for inactive alarms periodically and unmask them, or does the unmasking of inactive alarms just occur once (following the loss of the required or voting conditions or the elapsing of the SUP_TIMEOUT/TIME_DURATION timer)? I understand that the active alarms would unmask following the elapsing of the AUTO_RESET/TIME_DURATION timer.
  
  Thanks,
  
  Yash

  • Cancel