Skip to Main Content
AVEVA™ PI System™ Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Status Declined
Categories Data Archive
Created by Kenneth Barber
Created on Aug 20, 2022

Option to turn off interpolation for a PI Point

Currently, PI will always interpolate to determine a value for a PI Point between archived events. The Step attribute determines the interpolation method. "On" means "step interpolation" and "off" means "linear interpolation". This works well for most PI Points, which store samples of signals that are continuous over time. However, interpolation does not make sense for data that is discrete over time, which includes: • Aggregated data (e.g. totals, counts, minimums, maximums), possibly calculated using the PI Analysis Service • Data that applies to a time range as a whole and not to each instant within it (e.g. monthly costs, daily quotas, weekly targets) • Events in PI that correspond to events in real life (e.g. record an event each time a defective product is detected, track the mass of material per dump of a loader or per load of a haul truck) • A lot of stuff coming from PI Manual Logger Currently, for this type of data, the user must be careful to use only the values at stored events and not interpolated values. This is prone to error. Please add an option to turn off interpolation for a PI Point. Replace the Step attribute with an Interpolation attribute whose options are Off, Step, and Linear. If any PI client program requests the value, of a PI Point that has Interpolation = Off, at a timestamp that does not correspond to a stored event, no value should be returned.
  • ADMIN RESPONSE
    Aug 20, 2022
    Hi, What you're describing is already available. For example, when you configure an AF attribute for a PI Point Data Reference, you have the flexibility to determine which data retrieval mode you want. You can retrieve via interpolation, Exact, At-or-Before, Exact time, etc. In addition, we have to be very careful when dealing with the default data retrieval methods as it can change behavior of existing (older) clients. We also do not necessarily want to require customers to upgrade clients the same time as when they upgrade the server. As such, we can get into a situation where a mixture of older/newer server/client can have different default behaviors and we want to avoid that.
  • Attach files
  • Kenneth Barber
    Reply
    |
    Aug 20, 2022
    Related: https://feedback.osisoft.com/forums/320517-pi-vision/suggestions/40829407-option-to-turn-off-interpolation-on-trends https://feedback.osisoft.com/forums/555148-pi-server/suggestions/40829017-have-an-option-to-use-step-interpolation-to-the-pr
  • Kenneth Barber
    Reply
    |
    Aug 20, 2022
    Hi Stephen, I was thinking of a setting at the level of the PI Point and not the AF attribute (not everyone uses PI AF), but thank you for telling me that this already exists for AF attributes. I didn't know that. Requiring a client upgrade for this suggestion alone is perhaps not worth it, but perhaps more ideas will come along that will also require a client upgrade, and all of those ideas can be implemented together and require only a single client upgrade. I've been reading some of the declined suggestions. Some of them are pretty good; they're just not appropriate for now.
  • Guest
    Reply
    |
    Aug 20, 2022
    Kenneth, While forcing a client upgrade is not ideal, what's even more concerning is a mixture of old/new server/client producing inconsistent results. If you can imagine a large corporation with multiple servers/clients (maybe thousands of clients) it quickly becomes unmanageable if we change previous default behavior. Having said that, I appreciate that fact that if we ever do a step change, we can consider changing previous default behavior but would have to ensure we prevent old/new server/client mixed interactions.