6 Replies Latest reply on May 21, 2014 12:29 PM by Roger Palmen

    Trending future data in up coming Coresight 2014

    aldorexbraam

      Hi, 

       

      I was approached by one of our clients who wanted to do trending of future data in coresight... i told him that AFAIK there currently was no provisioning for that. 

       

      It made me wonder what would be the provisioning for such functionality in Coresight 2014.

       

      Especially since what i saw from the 'Delorean' beta you need a second pi tag that holds the future data. ( or build your own data reference that makes the switch )

       

       

        • Re: Trending future data in up coming Coresight 2014
          Roger Palmen

          If you review this file (part of the CTP for PI Server 2014), it describes how future data is handled in CoreSight: vcampus.osisoft.com/.../Guide-to-Future-Data-in-PI-Visualization-Products.pdf

           

          And yes, it is supported in production versions of CoreSight and is used e.g. in combination with AF to retrieve future data.

            • Re: Trending future data in up coming Coresight 2014
              tlebay

              PI Coresight has always allowed a user to request future data by scrolling into the future, so as Roger correctly states we support future data tags with the current production versions of PI Coresight.

               

              As far as the upcoming release of PI Coresight 2014  we do not have any features that will detract from or enhance the current capability.

               

              We are planning to enhance the support of future data in the release following PI Coresight 2014.  Some likely enhancements include: visually indicate "current time" on a trend, set a display to automatically update and scroll through time without the need to set the end time to NOW.

                • Re: Trending future data in up coming Coresight 2014
                  aldorexbraam

                  Ok clear and thanks for the spec Roger, really appreciated

                   

                  For your information: I found out that the problem for me is in the way to define that an attribute is time series data coming from a relational table.

                   

                  in AF 2.5 and greater you can do this with setting the behavior rule to 'Table provided time series data'

                   

                  ==> Trending those in Coresight is no-brainer...

                   

                  in AF 2.4 and lower you do not have this option and instead i use the 'interpolate' clause in the table reference, this works fine in AF explorer and the AF SDK...but when i trend on data the trend is messed up (see embedded picture)

                   

                  Conclusion : trending of future data in Coresight (using relational data) works fine for AF 2.5 and greater.

                   

                  2364.futuredata.jpg

                    • Re: Trending future data in up coming Coresight 2014
                      Roger Palmen

                      Hi Aldo, did not look at the poster...just noticed it was you!

                       

                      Yes, the interpolate clause performs interpolation on the value, and not on the time. And that is simply not supported in the v2.4 Table Lookup.

                       

                      EDIT: removed my rubbish

                       

                      Let's do some guesswork why: The client (CoreSight in this case) calls AFData.InterPolatedValuesAtTimes or the PlotValues method (.NET4 methods). This is then translated into a call to the data reference. Since the v2.4 table lookup does not support time, the attribute is setup supplying the time into the where clause. I presume that the V2.4 table lookup does not support the InterPolatedValuesAtTimes or the PlotValues calls, so the AFSDK will probably do subsequent calls to InterpolatedValueAtTime? Well, this does not explain why future dates are not handled properly by the v2.4 DR. Definitely not effective, but that's not the point.

                       

                      Anyone around to comment why this does NOT work?

                       

                      So best recommendation is to build a custom DR to call a custom proxy Webservice to get the data from the external source. Gives more control over your architecture too.

                       

                      Greetings, Roger