AVEVA™ PI System™ Feedback Portal

Welcome to our 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 Event Frames (EF)
Created by Kenneth Barber
Created on Aug 20, 2022

RELATED IDEAS

The "True for" time of event frame generation analyses should not consider the extrapolation after the snapshot event

PI assumes that the value of a PI Point from its snapshot event up to now is equal to the snapshot value. This extrapolation is not necessarily a good representation of what the interpolation will look like when new data arrives. The extrapolation can cause event frames to generate prematurely, and by the time the user compares the trigger data to the event frame, new data will have arrived, which turns the extrapolation into interpolation, and it will look like the event frames should not have generated. This problem gets worse the more any of the following conditions hold true: • event frame generation analysis has a short "True for" time • trigger signal is noisy or has occasional random spikes and dips • trigger signal's timestamp represents the time that the signal was generated and it takes long time for the signal to reach the PI Data Archive (could be due to infrequent scanning or delays in signal transmission) Since the extrapolation does not represent real data, it should not count towards the "True for" time of event frame generation analyses.
  • ADMIN RESPONSE
    Aug 20, 2022
    The current data access behavior is inherent to OSIsoft's data access technology for more than 30 years. For a historical PI Point where the data comes from typically a control system in real time, the assumption has always been that if you query for the "current" value, the system returns the Snapshot. (Side note - "*" doesn't mean "now" in the PI System, but rather the Snapshot.) The rationale being if you query for the current value and there isn't a value at this exact time and the data is coming from a real time data source, then the Snapshot value is the closest approximation since it's the last value the PI System knows about. This also means practically we extrapolate from the Snapshot and return it as the current value. If we didn't extrapolate then we would have to return nothing. With the introduction of Future PI Points back in 2015, we have had to add (not change) to this behavior. For example, if you ask for "current" value for a Future PI Point and the first value is in the future, we would return an error if you request the current value. Now if we change the extrapolation behavior for historical PI Points, it would affect backwards compatibility for all our existing software and also all 3rd party software. Therefore we cannot treat this likely. In your specific scenario, if you configure your analysis to be event-triggered and you are able to use the triggering PI Point in your "True For", you would not experience an extrapolation behavior as this is only evaluated when you get a new event. I understand it may not be possible to only have 1 trigger and use that for the evaluation of "True For", but it a viable workaround.
  • Attach files
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    Since notifications are based on event frames, this can lead to lots of false-alarm notifications. However, the problem lies with the event frame generation, not the notifications.
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    If this is implemented, OSIsoft must be careful to distinguish between extrapolation and exception & compression kicking in.
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    Stephen, my analyses are event-triggered. When a spike is encountered and is the snapshot, the "True for" time starts ticking. If the time runs out before a new event is saved to the PI Point, the event frame is generated and a notification is sent. When the new events are finally saved to the PI Points, some of them are within the "True for" time and cause the spike to drop, so when you look back at the spike, it was not worthy of a notification. If I remember correctly, the event frames were set to generate if the PI Point stayed above a certain value for 1 to 2 minutes, but there would also be 1 to 2 minutes of extrapolation because of lag and because the data goes through 2 PI Interfaces (the one for the data source and then PI To PI) before it reaches the final PI Data Archive. My workaround was to increase the "True for" time. Just to be clear, I'm not opposing your reason for declining the suggestion. I'm just saying that the suggestion was based on a scenario that already used your workaround.
  • Guest
    Reply
    |     Aug 20, 2022
    Kenneth, I want to provide some details on how analyses work when configured for event-trigger. By its very name, event-trigger only evaluates when there are new events. Therefore, in a simplified configuration where you analysis has Input1 -> Output1, and you configure a Time True for Input1, the evaluation for Time True only occurs when there are new events for Input1. So as an example, if you set your Time True to 2 minutes based on Input1, but the data rate for Input1 is every 5 minutes, then it's possible that your Input1 remain true for 5 minutes before the event frame is created. I explained this behavior in PI Square not too long ago and this is also in our documentation. In your description, looks like you have slow arriving data but the software doesn't know that the data is slow arriving. All it know is that the True For time has been exceeded, the Start Trigger condition is still valid, therefore it would create the event frame and if a notification is configured to be sent, we send best possible information and that is to gather the "current" value and include that in the email. Having said that, it is still not making sense based on your description. You're saying that the True For time has been exceeded and then later on an event arrives that nullifies the True For. The only way this can happen is if you have out-of-order data and you're using the PI Point with possible out-of-order data for your Time True. If this is the case, please contact tech support to verify and to assess how we can make the system more reliable for your needs.
  • Guest
    Reply
    |     Aug 20, 2022
    Let me add an example to clarify. Let's say you have Input1->Output1 as your start trigger and a True For = 5 minutes. Event-triggered. At 12:00 you get a spike with Input1 and that start the timer going for True For. Input1 gets another value at 12:02 leading to an evaluation of the True For and since the spike is still there, the timer keeps going. Input1 gets another value at 12:07 leading to an evaluation of the True For and since the spike is still there AND we have exceeded the True For setting, the event frame is created. Note the only evaluations are done at 12:00, 12:02 and 12:07. There are no other evaluations since there are no events to trigger the evaluation. Now if at a later time, you find that you have a value at 12:04 that would've nullified the True For, it came in out of order, meaning it came into the system after the 12:07 event, yet with an earlier timestamp.
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    Stephen, by what you're describing, my understanding of how and when event frames are created is wrong, meaning that my reasoning of why we got so many seemingly false alarm notifications is also wrong. It's not really an issue at the moment, and increasing the "True for" time is a sufficient solution. Thanks for your explanation.