1 Reply Latest reply on Feb 7, 2019 5:07 PM by TimCarmichael

    AFAttribute class recorded timestamp and updatetimestamp

    ManishMehndiratta

      Hi All,

       

      We are trying to integrate Pi archive data using the AFAttribute search with our reporting system, and are able to retrieve data arriving in PI archive.

       

      One of the use cases (or scenarios) we wish to cover is late arriving data. For example; if the hardware goes does, the the value for the data arrive late to the system, how is it treated?

      Does it have two timestamps, aka value.timestamp and value.updatetimestamp OR does it always have one timestamp regardless if the actual value was recorded an hour or so back from a SCADA system?

       

      We are using AFAttribute class and need help is making sure we can detect gaps and cover them up.

       

      AFAttribute Class

       

      Search Overview

       

      Regards,

      Manish Mehndiratta

        • Re: AFAttribute class recorded timestamp and updatetimestamp
          TimCarmichael

          I'm sure others will give a more detailed response, but I believe the answer is: a single timestamp of when the value was generated.

          If the data is coming from a node with buffering enabled, there could be multiple reasons for the data to be 'late' arriving such as:

          the buffered node lost communication with the data archive, the primary buffer on the buffered node became corrupt or data is being generated faster than it can be sent.

           

          In previous environments, I've seen each of these scenarios occur.

           

          If you want to determine the time delay between data generation and data receipt, find a 'busy' tag from the source site and create a new tag to record the time difference between the event timestamp and the value being received into the data archive snapshot system.