4 Replies Latest reply on Jun 24, 2013 11:27 AM by RJKSolutions

    Should an event frame have PI Point attributes?

    Rick Davin

      In another thread (http://vcampus.osisoft.com/discussion_hall/development_with_osisoft_sdks/f/28/p/4190/22305.aspx#22305) I claimed that it is highly discouraged for an event frame's attributes to be something other than a null data reference.  Certainly that statement has some small exceptions: formulas to quickly calculate something.  But I thought having PI Points or other historical items on an event frame are discouraged.  I thought for sure this was written down somewhere and tried to find something to back up my claim.  I can't find it in writing anywhere but perhaps I am looking in the wrong places.

       

      To me, if you have something historical, it doesn't belong on an event frame.  Rather it should be on an element.  I think of a single PI Value as a value for some point in time.  Likewise I think of attribute values on an event frame as being a value for some vector or segment in time.  If you do have a PI Point on an event frame, is it possible to get values outside the StartTime-EndTime of the frame?

       

      I didn't think there was technically anything stopping someone from having a PI Point on an event frame.  But is it a good or recommended design?

        • Re: Should an event frame have PI Point attributes?
          cnelson

          Hi Rick,

           

          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

          1 of 1 people found this helpful
            • Re: Should an event frame have PI Point attributes?
              Rick Davin

              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.

                • Re: Should an event frame have PI Point attributes?
                  Roger Palmen

                  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.

                    • Re: Should an event frame have PI Point attributes?

                      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.