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.
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.
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.
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
