I don't share the requirement. If a data reference is based on a PIPoint or other attributes, then the events are usually determined by the events based upon GetInputs(). The gnarly thing about event frames is that usually GetInputs() would return null, and then its up to the developer to fetch all the required data and determine the events. Add in some RDA, and it gets more gnarly.
I've written simple data references in 2 hours or so. I wrote one with event frames and it took several weeks.
Bringing this thread back to life. Currently the customer uses OLEDB Enterprise as a remote AF table in AF and runs a few queries to determine statistics. Kudos for creativity using out-of-box solutions, but this is like a circular reference in architecture.
I really can't imagine this client is the only one that needs to know simple statistics on EventFrames?
But setting that aside, somehow i don't yet see why an EF custom DR would be more of less difficult than any other (if you keep functionality down). Almost finding some time to fire up the compiler and find out....
Can you enumerate what statistics you want/need?
AF Product Manager
For this specific case (a German energy company, using PI in this case to capture (100K+ downtimes / year) on wind turbines (>2000 of them):
- How many downtimes do i have? Count of active EventFrames, filtered on EventFrame Template
- How much downtime did i have this month? Sum / Avg / Min / Max duration of EventFrames for a given period (thus truncating events if they exceed the period).
- How much energy loss occured due to downtime? Sum / Avg / Min / Max of an EventFrame attribute for EventFrames for a given period.
Where each can have some filtering on EventFrame template, catagory, etc. All should work on EventFrames where the Element is either the primary referenced element.
Because these can be quite data-intensive, i could imagine supporting this from abacus only is one way to go (especially for the statistics over time)
Key ones are #1 & #2.
The latter example is a bit tricky, as when the EventFrame extends over the requested period, the energy loss cannot be calculated accurately by just taking the sum. To solve that, one should use additional logic on the trigger for generating the EventFrame to ensure an EventFrame is split every day / week / month / shift or whatever time period you need to report on. But as that is some kind of pre-slicing of data, this is a bit of a grey area. But nevertheless, having some capability to combine natural and periodic triggers would be nice.
Hi Rick (and others),
Now the customer requested a DR to be built for this, i'm checking for any pitfalls to implement a DR that will do some simple rollups on EventFrames. Filtering on EventFrame template. Counting eventframes for the given time period, or sum/min/max/avg of an EventFrame attribute. I just want to implement GetValue, and leave GetValues & RDA calls to the base implementations. The performance impact of the related inefficiency is manageable (or at least not less manageable than the current solution).
GetInputs i would use only to resolve any attributes used in the configuration, and use getValues to make a call to AFElement.GetEventFrames().
PS: This is a nice candidate for Abacus to persist the data in a PI Point, and to hide the attribute for browsing using the features from the next release! That way the business logic stays in AF, but performance impact can be managed.
1 of 1 people found this helpful
I share the same challenge and believe it should be a feature within AF, will also raise an enhancement request to possibly have it included in the next versions.
It should really be an analytic feature which would provide so many possibilities to leverage the data created by event frames in elements. I'm surprised that OSI-Soft haven't capitalized on this yet.
Can't agree more! We have all the components to build OEE in AF, yet the most logical way to implement using EventFrames is just not available...
Stephen Kwan, this is a similar use case to my issue: Some AF Calculations working, some aren't. Where do I troubleshoot this?
What I am really after in a condition based maintenance application is the ability to sum up the durations or other attributes of event frames. The things I want to know are: "Tell me how long this motor has run in an overcurrent condition since the last time I maintained it or replaced it," "Is the time it is spending above rated current getting worse? Staying the same? Getting better?" "I need to notify someone to do maintenance or change the asset at X run hours where the motor has run over current." Etc.
So, really, I am having to do extra calculations and then intermediate calculations on those calculations on information (EF durations) that is in the PI System somewhere. I can take the EF's and query them in OLEDB Enterprise and get a sum of the durations, but I may be querying a year or more worth of data, and then I have to build another mechanism outside of PI to notify if a time threshold is exceeded.
I would want to do the same with downtime as Roger is stating. I think the idea is we want to be able to do some rollups on the event frames themselves to understand what they are telling us. Event Frames may be the single most powerful thing you guys have done in the last 5 years, and now that we are starting to use them more, we are finding more use cases.
Jim, Thanks for sharing your thoughts.
I think many people will discover use cases that are hard to imagine today and we'll see unique uses cases as OSIsoft builds additional features and components around Event Frames. Soon you'll hear about the ability to acknowledge/annotate an Event Frame, put severity labels on an Event Frame and improvements around visualizing Event Frames. Our next release of the BA Integrator will support Event Frame Views! For now, I think this could help provide the statistics you require you require in a simpler fashion. Maybe one day, asRoger Palmen suggested, we'll be able to persist the values in PI Points, or bring in the BA Integrator summary data back into the AF world. I played around with my own EF DR once that sent summary values to PI on the closing of the EF; however, I didn't like the manageability of this due to having to recalculate EF, changing end times, or dealing with late data.
Yes, this would be. Extremely useful, almost the identical use case:
- Total downtime within a period, either dynamic time range or written to a PI point
- Number of events
One slight enhancement is to include filtering of events based on a value. We use this for OEE style calculations and partitioning downtime into different buckets.
We have solved the Problem using a custom DR, Rhys had a post earlier which shows the concept. We basically have an attribute with the custom DR which is called by Analytics.
What I would really like is to have the functionality exposed via Analytics.