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.

Add a new idea Subscribe
Status Declined
Product AVEVA™ PI Server
Categories Data Archive
Created by Kenneth Barber
Created on Aug 20, 2022

RELATED IDEAS

2 timestamps for future data tags

Currently, if you want to store predictions for 1 day, 2 days, 3 days, etc. into the future, you must create a different PI tag for each distance into the future. Future data tags should support 2 timestamps: the timestamp that the predicted value applies to and the timestamp of when the prediction was made. The additional continuous time dimension will make it much easier to analyze the change in accuracy of prediction as the distance into the future changes.
  • ADMIN RESPONSE
    Aug 20, 2022
    We are declining this item as we don't feel it's the right fit with our overall product strategy. Thank you for your feedback, and please continue sharing your thoughts on how we can better serve you.
  • Attach files
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    I realize that not every future event is a prediction. For example, it could be a goal. But even goals are set at specific times. I also don't expect PI to support an arbitrary number of continuous dimensions (e.g. resistance predictions as predicted current, predicted voltage, and distance into the future change over time). That might be a time to use fancier tools.
  • Guest
    Reply
    |     Aug 20, 2022
    Fully support this, this would be benficial for our energy usage initiatives and using PI as a potential solution for a replacement energy portfolio manager.
  • Guest
    Reply
    |     Aug 20, 2022
    Perhaps a different thread but, I would like to see all tags support 2 timestamps (occurrence time and logged time).
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    Angela Hill brings up an interesting case, but her case is different from the case in my suggestion in more ways than you might expect. In the case in my suggestion, at any particular time for a particular type of value (e.g. power output), you can make predictions to multiple times in the future. Similarly, any particular time in the future can have multiple predictions against it for a particular type of value (e.g. it can have the "1 day later" prediction from yesterday and the "2 days later" prediction from the day before yesterday). There is a many-to-many relationship between the 2 types of timestamps even within a single type of value (e.g. power output), so we have no choice but to represent each value of 1 of the types of timestamps as a new tag. Angela's case is a bit different. Each occurrence of a particular type of event is logged only once (I'm assuming), so for that type of event, there is only 1 logged time for each occurrence time, but multiple occurrences of the same type of event can share the same logged time. That is, there is a 1-to-many relationship between the occurrence time and the logged time for a particular type of event. In such cases, for each type of event, you can have 1 tag that captures the value and 1 tag that captures the logged time, where both tags use the occurrence time as the timestamp. You can then create an element template called "Logged Event" that has 1 attribute for each of the 2 tags that I just mentioned. Then, instead of representing each type of event as a different attribute in an element, you would instead create 1 element, based on the Logged Event template, for each type of event, and each of these elements would be child elements to the element that the event applies to. I think that situations like the one above support the idea that it wouldn't hurt for OSIsoft to talk about the theoretical side of PI, design patterns, and different approaches to problems in PI. Solutions like the one that I described are not immediately obvious and customers may be doing things suboptimally and not even realize it. https://feedback.osisoft.com/forums/602086-osisoft-learning/suggestions/31689928-make-more-videos-about-the-theoretical-side-of-pi