1 of 1 people found this helpful
Great topic. One main value Event Frames brings to the PI System is the ability to "Bookmark" your real time data. Now, you are right, the majority of real-time data is "physical" in nature and is stored in a PI Tag. This "physical" stream is then put into its "physical" container through AF which relates a lot of these real-time signals together into the physical equipment that this stream is coming from. The last step is to "Bookmark" those important events and reference the real-time data and encode how to return that real-time data.
What this means is that within an Event Frame/Event Frame Template, you can use PI Point Data References, but we encourage these PI Point Data References to reference the Event Frames Referenced Elements Attributes that has the official mapping to the PI Tag. We don't encourage direct references to PI Tags from the Event Frame, although you could do this, we encourage that you leverage how the Event relates to the Physical Equipment and then how that Physical Equipment maps to the PI Tag.
I do want to hear the communities thoughts here, but I did want to give some insight into the design of these features within Event Frames.
Cheers - Chris
Thanks for the reply, Chris. I've got to admit that I was a little embarrassed posting such a rookie question, but your answer put my mind at ease (including using the positive 'encourage' over the negative 'discourage').
In our use cases, we avoid defining PI Points, or other attributes with historical values, on the event frame. This doesn't mean we only have static values, i.e. attributes with null data references. We do prudently use some data references on what I would call scalar values (same value for entire duration of the event frame). Something simple like a formula to sum or calculate a rate. Maybe the occasional table lookup (without a time column) against a small table. But our intent is to keep the data on the event frame to the minimum necessary, i.e. how it relates to or even helps define that event. If need be, we can always relate back to a (usually primary) referenced element.
It would be nice to hear from others on their use cases.
I'm the type that if I make a claim, I like to provide support behind it such as some benchmarking results or a link. If I ever make the claim in the future, I now have this link to reference. Thanks.
Not using EventFrames (yet), so can't add any usecases.
I don't think this was a rookie question. There are a million of possibilities in the AFSDK, and it's good to revisit the concept of EventFrames to re-confirm why one would not want to define a PI Point DR on an EventFrame. A good understanding of the concept is imho the core of any good design, and this will help.
I am sat on the fence here because there are use cases where you would want to have direct PI tag references from an event frame.
An event frame gives the time context on your assets and it is perfectly reasonable that you have archived data that either describes that time context over its duration, or calculated/performance data during that time context - especially if the time context is repeatable. For example, take shift monitoring/patterns. They are repeatable, they give time context to your physical assets, and you would report on performance (or other data) during that time (shift). I wouldn't really model a shift within an Element Template since the primary context of a shift is time so I would template them as an Event Frame. When that shift is on duty an instance of the EF Template is instantiated and the physical assets under that shift's responsibility are referenced. There are numerous KPIs (calculated & stored in PI tags) that are relevant to the shift so would be directly referenced in the EF. You would want to see how some of the performance data trends over the shift duration for shift handovers, shift reviews or other post event analysis. Especially if things are ramping up towards the shift handover. Although you could derive the same data from the physical assets (e.g. alarm rates) & correlate with the EF for the time period, it seems more efficient to directly access that information from the EF itself. Especially when we get native OSIsoft client tool support for visualisation.