Properly handle Event Frame edits on Event Frames that are generated by the PI Analysis Service
Users manipulate open event frames that are generated by the PI Analysis Service. The manipulation can be:
1) Write to an attribute on the EF
2) Write an annotation
3) Acknolwedge the EF
When these manipulations are being performed the Event Frame is checked out to the user performing the changes. From time to time, it happens that a closing event is received and the PI Analysis Service fails to close the Event Frame as it is checked out to another user. This causes the analysis to stop and the event frame remains opens.
A possible solutions could be:
Retry to close the Event Frame multiple times (configure a timeout or retry count limit)
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.
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.
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?
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.)