Properly handle Event Frame edits on Event Frames that are generated by the PI Analysis Service

What is very bad about the current behaviour is that it is not just one event frame that does not get closed, but that the analysis is stopped afterwards and no new event frames are created at all anymore as soon as this happened once. To correct the problem, you have to identify the stopped analysis, and manually restart it in PI System Explorer. As discussed with Techsupport, it currently is not possible to detect and correct this error otherwise (e.g. via a Powershell script etc.)

The current behavior assumes that PI Analysis Service is the "owner" of the event frame that it creates, therefore we assume that other users do not write to an event frame that doesn't belong to them. Similarly, for a PI Point, we assume the interface that is writing to a PI Point to be the "owner" of that data stream. We assume that two users, e.g. two interfaces, would not write to the same PI Point (data stream). Earlier in this discussion, it's mentioned that a custom application is being used to write to event frames. Can you describe what you're writing, the criteria that would lead you to start writing, and how often this is done?

We use event frames to mark alarms (generated by event frame generation analyses), and a custom developed web application that allows our users to comment and acknowledge the alarms. Each alarm can be acknowledged only once, and commented multiple times. The time that an event frame is checked out is generally short (1-3 seconds), but that is enough to make this problem happen multiple times per month typically, with the amount of acknowledgments and comments that we currently have. If the PI Analysis service is the "owner" of the event frame, then it should be possible to comment on and acknowledge the event frame via the analysis service, but this cannot be done, we therefore check out the event frame from our application and check it in afterwards again. I can understand that a collision can always happen in this scenario (this is actually the exact reason for a check-in/check-out mechanism), but what is very unfortunate is that the event frame generation analysis breaks when such a collision happens. It stops working and never ever starts on its own afterwards.

A follow-up question would be: how does PI Vision handle the case where a user enters a reason, or acknowledges an event frame? I guess the event frame will be checked out for a short period of time by PI Vision, and the very same situation could happen here as well: an analysis could try to enter the event frame end time exactly during this short period of time where PI Vision has checked out the event frame to store the reason/acknowledgement. In that case, too, the analysis would fail and stay broken indefinitely.

So that means that an event frame should never be annotated nor acknowledged while it is not yet closed (because, as you mention, PI Analysis Service is the owner of the open event frame until it closes). This is creating problems for us, because we use event frames e.g. for alarms, and we therefore are not allowed to store a comment to an alarm on the event frame itself while it is not yet closed. However, this functionality is available in various clients independent of the state of the event frame. It might be the best then if you could disable annotating and acknowledging event frames in PI Vision and other tools for all event frames with no end time, otherwise the risk exists that we run into this problem.