Emerson Exchange 365

• Not Answered

rate of change Alarm

In a project, there is a requirement to configure rate of change alarm for Pressure as below:

 

1. Alarm setpoint = 10bar (should be configurable)
2. The rate of change variable should be calculated on a time averaged absolute basis over 10 minutes. Changes (either +10 or -10) of greater than 10bar over a 10 minute period should cause the alarm to be activated.

The time averaging period should be configurable.

 

I have tried using PCSD composit C_AI_RATE52 (PCSD Composite for Rate Alarming for Analogue Input). However not able to understand how exactly calculating the ROC parameter. Has anyone used this composite for such application?

What is the formula/calculation used to determine ROC? Which parameter is to be used to configure time averaging period?

• DeltaV #DCS
• configuration

Nandkumar chandra

• 3 May 2021 8:22 PM
• Cancel

8 Replies

• vmvmhatre

  

  • 5 May 2021 9:46 PM

  PCSD rate alarming composite have functionality to calculate ROC of a Process variable based on specified TIME_UNITS to RTLM block and generate RATE_ALM based on MAX_RATE_UP and MAX_RATE_DWN limit parameters.
  In your case, logic to calculate running average needs to be designed. Next this average signal will be input to PCSD rate alarming composite with MAX_RATE_UP = 10 bar and MAX_RATE_DWN = -10 bar.
  
  To calculate running average (with average period configurable) following design can be used:
  First finalize maximum value of time average period to decide array elements required to store data. If 10 min is maximum average period then assuming 1 sec as scan rate of module, you need 600 array elements to store data. So you need 5 array parameters (each array parameter with 127 rows and 1 column).
  Then use CALC/ACT block to manipulate these array elements. Use only required array elements based on average period configured.
  On every scan, move array element value to next row and add current PV in first array element (this will move out oldest array element).
  Calculate average of data as SUM of used array elements/array element used count.

  • Cancel
• Nandkumar chandra

  

  • 6 May 2021 7:46 AM

  In reply to vmvmhatre:

  Thanks for reply in details. Just have some further query as below:
  If I specified 1 second TIME_UNITS to RTLM block. In this case , dose this composite output calculate rate of change per 1 second? and Can I use this output to store in Arrays directly to calculate 600 samples averaging for 10 min time?
  Customer asked 10min time as configurable however array size depends on this so how it is possible to change array size in line with configurable time value dynamically?

  • Cancel
• Andre Dicaire

  

  • 6 May 2021 2:30 PM

  In reply to Nandkumar chandra:

  The Array parameter is not adjustable at run time. However, your CALC expression can manage the number of elements used. So if you have 5 arrays of 127 elements each, you can set a max value based on the number of elements needed and only iterate to that number of elements. One way would be to divide total number by 5 (i.e if you need 300 elements, 300/5= 60. ) now you would use only the first 60 elements in each array.

  Andre Dicaire

  • Cancel
• jhCoxx

  

  • 6 May 2021 3:00 PM

  In reply to vmvmhatre:

  Great description of how to calculate the running average. What's the actual calculate that further done with that to get the ROC to compare with the MAX_RATE_UP and MAX_RATE_DWN parameters? Inquiring minds never really figured that out...

  • Cancel
• DBacker

  

  • 11 May 2021 7:06 PM

  In reply to Andre Dicaire:

  One comment from the peanut gallery.
  
  Depending on how you choose to load these 5 arrays with data, and how you choose to access the data in these arrays, you might hit the "runaway process" trigger and your module will be forced to fail, and stop executing. The only way to restart the module is to re-download it (where again it will fail).
  
  If your array manipulation is already working, then don't worry about it. If the module does fail, you need to do about 25 or 50 array elements per module execution and create an integer type MODULE level parameter that tracks the last position in the array so you know where to resume.

  • Cancel
• SBPosey

  

  • 11 May 2021 8:34 PM

  In reply to DBacker:

  Moving 600 values is rather expensive for processing. I would recommend using the arrays as circular buffers and just keep track of the indices for the next value. We've done this to create a 300-element deadtime block.

  • Cancel
• Andre Dicaire

  

  • 11 May 2021 9:56 PM

  In reply to SBPosey:

  BOL states that a While loop is limited to 2000 iterations. If you nest them, it will be less. I think what that means if is you have a nested loop that say does 10 iterations and you have that in another loop that does 10 iterations, you have 100 total iterations. If you jump to a label or have an IF statement, these are each counted as an additional iteration. The limit of 2000 is per Calc Block.
  
  If we have 5 Arrays each with 120 values, and we want to sum them up, we could loop through each array to add the values using 5 While loops, with 600 iterations. well below 2000.
  
  Another approach is to maintain a running sum. Each scan you add a new value to the sum. Once you've read x number of values, you start subtracting the oldest value when you add a new value. In reality, you will be storing the new value in place of the oldest value, once you've used it. This way, you keep a running total divided by number of values for the average. In each scan of the CALC block, you read new value, Read oldest value, adjust Total= Total + New Value - Old Value, and store New value in old value location. Update the average and done. No while loops.
  
  The trick is the circular buffer referenced by SBPosey. The pointer indicates the location of the newest value, and the next value is the oldest value. Gets a bit trickier managing this point across 5 arrays. I'm thinking you would use a pointer value from 1 to 600. Use 5 IF statements to direct the logic to act on the various Arrays (IF Index < 121 Then Use Array one, else If Index is < 241 use Array two, else If Index is < 361, if Index < 481 else )
  Within each IF statement, you adjust the index from 1 to 120. You read this value and place it in "OldValue" internal parameter. Then Store the "NewValue" in the same location. At the end of the If statements, you adjust the new sum and calculate average. Make sure you store the Index value to an external parameter for use next scan. Internal variables in an expression do not transfer to the redundant partner. On a switchover, you would lose the index value.
  
  Initialization is an other consideration. You can keep track of how many you've read up until you reach the buffer size. Divide the sum by number of values stored, which becomes the buffer size once fill. This allows you to set the quality status on the calculated sum, based on having a sufficient number of values to make the average valid.
  
  Wrap this all up in a composite/embedded block and expose the Size of the buffer, number of registers used (equals Size once initialized), Sum and Average.
  
  with a circular buffer, you can get your average without using While Loops at all.

  Andre Dicaire

  • Cancel
• vmvmhatre

  

  • 12 May 2021 1:30 PM

  In reply to Nandkumar chandra:

  Hope information by experts in this thread will help to write code for average calculation.
  
  Answer to your earlier query regarding RTLM block:
  PCSD RATE composite uses RTLM block to get ROC value. RTLM block is not used for its primary functionality to limit rate of change of output per specified limits. So, I would suggest not to use (not wire) INCREASE_MAX and DECREASE_MAX parameters of RTLM block, these parameters can be set to values 99999 and -99999 respectively.
  Regarding TIME_UNITS parameter, this parameter have configurable time unit (seconds, minutes, hours, or days) but no value can be specified with this TIME_UNITS parameter. RTLM block algorithm calculates roc value in seconds and displays value in ROC parameter as per specified time unit in TIME_UNITS parameter.
  As input to RTLM block is calculated running average signal, TIMECONST parameter configuration may not required. You can decide this while tuning if ROC is getting triggered due to noisy signal.
  Also, this RTLM/ROC output parameter can be used as input to ALM block for separate ROC_HI and ROC_LO alarm detection. Also with ALM block, you can utilize hysteresis feature if required. From your initial information, ROC alarm setpoint 10 bar/Minutes and -10 bar/Minutes can be ALM block HI_LIM and LO_LIM setpoints. If separate alarms are not required, single alarm can be generated.

  • Cancel