1 Reply Latest reply on Oct 3, 2017 10:09 PM by tramachandran

    Using the AF SDK, what's the best way to get "realtime" PIPoint and/or AFPoint values?


      I would like to get something close to real-time data from a PI system.

      I would like this to be flexible and able to work with both the AF and PI (Archive) databases.


      I'm new to the PI system and the AF SDK, but I suspect that there are two basic ways to approach this.


      1.) Polling

      • Request current values at regular intervals.
      • Cache to increase interval at expense of delay.
      • Problem is unnecessary traffic

      2.) Subscription/Events

      • Asynchronous updates
      • Raising events
      • Minimizes traffic



      I would like the second option if possible, something like a subscription model. From what I'm seeing, should I use a DataPipe (either PI or AF) coupled with an IObserver then?

      If a DataPipe is the way to go, then should I use snapshots, time-series, or archive events? I'm assuming Archive events to get any recently archived value, otherwise I'll persist my locally available last archived value?

      Another hangup I have is that I'm not interested in any attributes except the current value. How do I optimize for this for both a PIDataPipe and AFDataPipe?



      Also, it sounds like an AFDataCache might be another way to go, vs an AFDataPipe. What are the advantages of one vs the other? Is there a similar mechanism to the DataCache for the PI (Archive) database?


      A little cross-referencing here to a similar question: Real Time Extract from OSI PI

        • Re: Using the AF SDK, what's the best way to get "realtime" PIPoint and/or AFPoint values?

          Let me try to answer your questions, I'm sure others will chip in.

          First up, could you elaborate on what you are trying to accomplish with "close to real time data". Is it a custom application for data extraction, is there a particular language you are using, what is the nature of the data, what is the scope of this project? These answers might help us provide you with a more specific solution.


          Yes, the approaches mentioned by you are both valid and have the characteristics as pointed out by you.

          DataPipe: they are used to subscribe for data change events. The options you have are PIDataPipe and AFDataPipe.


          There are two ways to get the data change events:

          a) direct GetUpdateEvents method to get events;

          b) through IObserver of AFDataPipeEvent. Trigger retrieval of new events that occurred on the PIPoint objects monitored by the data pipe. The new events will be sent to the IObserver objects registered with the data pipe.

          Note: The IObserver pattern provides performance improvement over direct GetUpdateEvents method for high throughput scenario. Application will have to implement the IObserver and register the IObserver with the data pipe via the Subscribe(IObserver< AFDataPipeEvent> ) method.


          The data pipe types you are referring to are AFDataPipeType Enumeration.

          Snapshot = The datapipe will generate snapshot or current value data change events.

          Archive = The datapipe will generate archive data change events.

          TimeSeries = The datapipe will generate change events for a PI timeseries

          Note: The PIDataPipe class uses this enumeration to define the type of data change events that are generated. TimeSeries datapipe is only supported against PI Data Archive 3.4.395 or later.The AFDataPipe and AFDataCache will retrieve data for AFAttributes backed by a PIPoint using a TimeSeries where it is supported and Snapshot otherwise.

          Also refer to subscribing future data.


          Both PIDataPipe and AFDataPipe return AFDataPipeEvent objects, which used to represent changes to the PIPoint and AFAttribute objects delivered by data pipes, so I am not sure if this can be optimized for just values.



          AFDataCache manages a collection of AFAttributes via cache enabled AFData objects and will can automatically monitor for new data changes.

          It will generate and return the corresponding list of cached enabled AFData. Be default, AFDataCache uses AFDataPipe to populate the run time events in the cache. As a result, AFAttributes monitored by the AFDataCache must support AFDataPipe.


          Characteristics(advantages?) as mentioned in the documentation:

          AFDataCache will trim the cached events based on both event count and timespan. Trimming is done when the application calls the UpdateData Overload method to update the cache. Just like AFDataPipe, AFDataCache does not poll the data automatically in the background. This allows an application to have complete control over when and which thread will be used, making synchronization across threads simpler.

          Single event data access queries made with the cache enabled AFData are much faster. For data access queries not supporting data cache or if the requested range exceeds the amount on data in cache, the data cache will make the normal data access query so no functionality is lost. Hence, AFDataCache is ideal for high performance applications working with streaming data while maintaining the functionality of the Rich Data Access through AFData.


          There seems to be no equivalent mechanism for the PI Data Archive but I would assume that the response would be very quick for PI Point objects.


          The PI Square post in your question also mentions PI Web API, which is another developer technology. It can use channels, which is a way to receive continuous updates about a stream or stream set. Rather than using a typical HTTP request, channels are accessed using the Web Socket protocol. There are numerous Web Socket client libraries in several languages available for use with channels.


          Since you mentioned you are new to PI System and AF SDK, the following is a link to Developing Applications with PI AF SDK from our learning channel.


          Here are other PI Square posts that may be of interest to you.



          5 of 5 people found this helpful