Emerson Exchange 365

• Not Answered

PHV reporting false alarms

Hi all,

Any idea on below for PHV reporting alarm when alarm limits was not reach?

It is pulling vacuum at 375 SP and logic have a transition to see if PV is below hi limit SP of 375 (which was obviously reached) based on trends.

However, the moment alarms are enabled at the end before reaching vacuum, this alarm shows up.

Appreciate your help. Thank you!

Glxy0923

• 28 Apr 2020 6:22 AM
• Cancel

3 Replies

• Marcelo Sottano

  

  • 28 Apr 2020 1:20 PM

  Hello, have you enable de Conditional Alarming for this Alarm, if you do, ther could be a delay configured, so that why the alarm appears a little bit after the alarm condition accomplish.

  • Cancel
• James Beall

  

  • 28 Apr 2020 1:29 PM

  And, one must be careful when using "compressed" historian data to diagnose time series problems. What is the collection rate in historian for the PV? What is the historian compression limit (EU's)? If the collection rate is slow or the compression to high, the historical data may not show the correct picture. Also, the plot method (step, line, line with points) and change the trend appearance. One quick way to see if the collection time or compression might be an issue is to right click on the variable (PV) of interest in the PHV legend and choose the plot method "line with points". This shows each data point that was actually saved in the historian. Also, as Marcelo Sottano mentions, check any conditional alarm settings for this alarm that might delay the activation of the alarm.

  • Cancel
• Andre Dicaire

  

  • 28 Apr 2020 3:18 PM

  In reply to James Beall:

  Tying all this together, it is clear that the PV was in the alarm region at 750 mmHg and dropped gradually toward 350 mmHg, but there was no active alarm until we see the PV cross the High Alarm threshold at 375 mmHg. The alarm goes active at 371 mmHg, and then clears shortly after at 368 mmHg as the PV continues to drop.
  
  Marcelo points out that the alarm must have a conditional alarm configured, which is why there was no alarm while PV was 750 mmHg.
  
  Here's what happens. The Conditional alarm is supplementary logic applied to the alarm trigger, in this case HI_ACT parameter. There is also a Hysteresis on the Alarm. So once HI_ACT is set, the alarm trigger does not clear until the PV pass through the Hysteresis region. In this case, the Alarm cleared at 368 mmHg. Assuming Hysteresis was 5 mmHg, that means 371 is still in the Hysteresis region and the conditional Enable was enabled in the region, and shortly after when it past the hysteresis value, the alarm cleared.
  
  As James explained, the Continuous historian samples at a collection rate that is often slower than the module execution time. If compression is incorrectly set, that will further skew the stored data and the result could be an aliased signal. The other factor is that Continuous History data is timestamped at the History server. DeltaV sends data by exception from the controller, and that Exception Flag is set when the Control Module executes. The Communication layer checks this flag and if set, sends the value to its destination. There is always a slight lag between when the module executes, and when the value is sent, received and timestamp. The result is a slight skew of the history curve verses Alarm Events which mark Time in the controller. Add to that any discrepancy in the Time setting of the controller and Workstation and there is typically a time slip on stored data. I believe this is in the order of 50 ms or so.
  
  If history is stored at say 5 seconds, then a module can record an even up to 5 seconds before the PV is actually sent. However, if the process time constant is like 20 seconds, the value recorded will accurately reflect the process behavior, even at 5 seconds. If collection and compression are properly set, the value stored will be within the accuracy ratings of the transmitter. Oversampling and disabling compression does not give you more accurate data since the sensing element and transmitter will have a stated accuracy. More data does not equate to better data.
  
  In this case, the PV is a slow moving variable that tracks almost linearly on a downward slop. A straight line can be defined with two points. More points do not make it straighter. the Chart is correctly showing an interpolated line so I don't anticipate the PV value is much different than the value recorded in the Alarm. But I would expect that it is not the same. The line will be skewed slightly to the right by the communication lag and server time stamp. However, if the server time is slightly ahead of the controller time, the result could be skewed to the left. Point is, as long as the server and controller are reasonably in time sync, the stored value will be within the transmitter accuracy.
  
  The issue is that the Alarm Enable logic is enabling this alarm too soon. Change the logic to enable when PV is below the Hysteresis region and you will not see this transient alarm occur.

  Andre Dicaire

  • Cancel