Emerson Exchange 365

• Not Answered

PHV Discrepancy with values overtime

Hello,

We have temperature reading for a freezer at our factory. This signal is recorded and stored in the historian server.

Our system is Delta V 11.3.1 build 4326.

Maintenance keeps a printed trend (paper record) for every month by our procedures.

There was a human mistake changing the title dates and other department requested to re-print July 2018 readings.

However, when we pulled out this temperature chart, the data that is in the printed paper does not match with what we are able to get from PHV today.

The events for this signal match what we have in PHV, there was a point in time where a download in the controller was performed and the temperature status changed to bad, this behaivor generated a spike in the trend that I think is normal while the CM is initialized after a download. At this point in time the events and alarms generated match the PHV signal.

I went back in time to verify the printed trends in paper and compare them with PHV values today, there is no descrepancy whatsoever. The only time where is different is for July 2018.

These are some things I’ve checked in Delta V:

- Opening the signal with different PHV templates: Does not matter what settings are modified in PHV, the temperature signal is always the same.

- In the control module, Sampling rate is set to 30 seconds and the deviation (compression) is set to 2 with max value of 18 hours.

- There is no Audit trail change in the history collection parameters from 2015 until now, at least I can't see any change. Are these parameters recorded by default in the Audit Trail database?

- Changing compression and plotting method in PHV does not make any difference in the graph.

I think the compression in PHV should affect the graph only if the compression parameters (sampling time, deviation value, time to force new datapoint) in the control module are quicker than values plotted in history view. Is this statement correct?

I've tried everything that came to mind to see if was able to replicate the paper signal, no success. Is there any KBA that can help to troubleshoot this problem?.

Is there any know bug for PHV that can cause this issue?.

Appreciate any suggestion you may have.

Also, this is my first post and I learned a lot from you!

Thanks!

gennarogiura

• 7 Jan 2020 4:27 PM
• Cancel

4 Replies

• Andre Dicaire

  

  • 7 Jan 2020 5:13 PM

  The first thing I would ask is whether the recorded chart was based on history data, or was this being recorded in real time.
  
  Let me explain. When PHV is open and displaying a chart, if first draws the chart lines based on History server data. As the Chart remains opened, it uses local real time data instead of history data. If the CHART was opened in PHV in preparation for recording a print screen the data in the PHV chart could look different than the History data. In your case, the history server is collecting a value every 30 seconds, assuming deviation is seen. A PHV chart by default will poll data every 5 seconds and plot this without compression. The update rate could also be set to 1 second on the CHART.
  
  If the module was downloaded and the temperature value spiked for a scan or two, the PHV Chart might record this anomaly, but the history server could easily "miss" this.
  
  You can easily observe this by opening a Chart and setting the update rate to 1 second. Then observe a historized value that is collecting at a slower sample rate, but is moving. (create a test module with a reference signal from a Signal Generator to see the effects of aliasing). When you refresh the chart, it will replace the runtime data with the stored history data and the trend line will "change".
  
  When collecting history, it is important to sample the data as a function of the process time constant. A temperature is typically slow moving, but you should still sample fast enough to capture possible process movement. A spike caused by a Download is not a process movement, and should not really matter. (Except that you do want to resolve the paper record to the electronic one.)
  
  If the paper record was created from a runtime collection of data, your SOP should be to refresh the trend from the History server prior to capturing the image to the printer. That way future views of the data will align.
  
  I'm not aware of any issue where history data is modified. There are no tools provided with DeltaV to manipulate the data in the DVCH data sets. If you were to view the raw data using the DeltaV Reporter and list the data values for the time in question, either the data is there, or it is completely missing. There is no way to extract a portion of a data set or modify them. If the data is showing up in a PHV CHART and in a DV Report, then the records are complete and I would suspect the paper copy was from a real time data capture.

  Andre Dicaire

  • Cancel
• gennarogiura

  

  • 7 Jan 2020 6:27 PM

  In reply to Andre Dicaire:

  Hello Andre, Thank you for your quick repply.
  
  The paper version was printed one month after data was collected. The chart is from July and the paper record was printed in August.
  
  Is clear to say the chart was printed from the Historian server.
  
  Off course you are right about sampling in function of the time constant. In this case is a very slow temperature. Don't think this is an issue here, however I proposed lowering this sampling time and deviation.
  
  One thing I forgot to write is that, I've used the Excel Add-in to extract the raw points and off course those points match with what we have retrievied from the historian to PHV.
  
  Would you mind confirming that changes in history collection compression parameters are stored in the Audit Trail database?.
  
  Maybe the guy who printed the paper trends changed something in PHV which caused not to update the values correctly.
  
  Don't think we have a problem with Delta V, the problem is that I'm not able to replicate the signal. And also at that time, the data loggers were down, so i don't have a way to prove there wasn't any problem with the equipment.
  
  Again, thank you very much!

  • Cancel
• Andre Dicaire

  

  • 7 Jan 2020 8:17 PM

  In reply to gennarogiura:

  The changes to History collection are part of the module configuration, but I don't know if/how they are stored in the VCAT database. History parameters form part of the data of a module when exported, so I expect this is in VCAT.
  
  I cannot think of how the data can be manipulated such that two sessions of PHV would retrieve different data for the same time span from the same History server. As long as the archives are available, the chart should always show the same data for the same time span and parameters.
  
  Is it possible the CHART is for a different time span? is the year correct on the paper copy? Hmm.

  Andre Dicaire

  • Cancel
• gennarogiura

  

  • 7 Jan 2020 11:05 PM

  In reply to Andre Dicaire:

  I went back almost two years in time, maybe there was a mistake when the guy printed the trend, but the month/year at the bottom of the chart depends on the signal. The user cannot change it. That month/year is correct. Jul 2018.
  
  I even believed in some kind of data manipulation (not in Delta V) but is not the case, there was no benefit of doing so...
  
  Also, at the same time this guy printed two signals, the one with the problem and another temperature from other freezer. There is no discrepancy with the second one.
  
  I've contacted Emerson directly through Guardian Support, maybe they can have a different suggestion.
  
  If we find a solution will reply back in this thread.
  
  Thanks!

  • Cancel