In this video we're going to be exploring how to set up our event frame generation
analyses. To demonstrate event frames we're going to be using
the asset based PI example kit for oil and gas well downtime tracking.
In this example kit you can see that we have two different sites within West Texas:
Clear Fork and Odessa and in each of those we have several wells. If we look at the attributes on the
wells, we have quite a few involving the casing pressure, casing temperature, the gas gravity,
as well as a status message that signifies whether the well is running or if there is some other kind
of downtime event that is happening with it. This status message is based off of an enumeration
set which I'll show you later and in that set we see the following options. There is down,
there's draw down testing, faulted installation, offline and running. I would like to set up an
event frame that will capture whenever the status message is not running and it'll tell
me exactly what the status message is as well as some metrics on the well itself.
You can think of event frames as the way that the PI system captures unique events,
which could be process excursions, could also be routine events, such as scheduled shifts and
all those are captured over a time range using a type of freeze frame that will capture attribute
values, PI tag values and can also perform analyses over the specified time period as
of AF 2017 R2. Let's take a look at an event frame that's already set up and see how we can
improve upon it. This event frame is called downtime tracking, I can look on the right
and see that it's an event frame generation analysis. It's using an event frame template
called well downtime and there is a start trigger specified below that shows that when the status
message is not equal to running and when the status message is not equal to point created,
we're going to create an event frame. We do not necessarily need end triggers in this
particular case this event frame will end any time that this start trigger is no longer true.
On the far right you can see that there is no severity that is set that is something that
will improve upon. What I want to do is set up another event framed generation analysis
but this time we'll have multiple start triggers and we'll specify an end trigger.
In the next video we'll go over the behavior of child events and how multiple start triggers work,
but for this video we're just going to be practicing how to set up an event
frame generation analysis and show you what some of those look like in a brief
search. Let's start building out our event frame generation analysis, I'll right click,
new and I'll call this downtime severity. I'll switch it to event frame generation analysis and
you'll see that it requires me to set up an event frame template. These are housed in the library
and you're able to set this up in the library tab itself, or we can manually create an event frame
and create an event frame template directly from the manual event frame. I'll show you the manual
event frame as this will aid us in building out our syntax, but again if you are advanced and
you know how to create an event frame template you can feel free to do this on the library tab.
To create a manual event frame I'll go to the event frames tab and from the event frames tab
I can right click new event frame and if you're starting from scratch you'll only have none as
an option here, so I will keep this as none and we can go and give this a referenced element,
this will help us build out our syntax and I'm going to browse one of my well elements. Since all
of my wells are based off of the same template, I'll just choose any of my wells and I'll hit OK.
When I go into the attributes tab, we're going to be referencing different attributes that we would
like to capture in our event frames. So that way when we go back to the time period of the event
frame we'll have a few metrics to go on we'll know what was happening with a piece of equipment and
this is really the beauty of capturing event frames. I'll go into my settings, I'll choose
attribute and when I click that drop-down you'll see the type of syntax that I'm referring to.
In order to reference the element of the event frame it's generated for we need this dot slash
elements open bracket period close bracket and then put a bar to the attribute name that we're
referencing. You can type this in manually but if you include a referenced element the way
that I just showed you, then this is populated automatically with all of the attributes that
belong to the referenced element. For this event frame I'm going to be taking the casing pressure
and temperature as well as the status message. If I look below I'll see the value retrieval methods
and the by time range field it shows end time, that means at the end time of my event frame I'm
going to be capturing the casing pressure value. We're able to name these attributes whatever
we'd like, I'd like to keep it consistent and keep the original attribute name. And I'll go
through the same process to get my casing temperature as well as the status message.
Be careful if you are going to be copying and pasting from the field below as if you if you
change anything you will likely break whatever connection you had to the attribute at hand. When
I grab the status message I would like to know the status message that happened at the start of
my event frame. So if I go to the by time range, I'll change this from end time to start time. Also
keep in mind that we'll want to make sure that our value types match what our input value types
are. As the status message is an enumeration set I want to make sure that I choose the right value
type and the right enumeration set. These were set to double I'll just make sure that this stays
consistent. If I go back on the general tab of the event frame that I manually generated, I can give
this a name. This particular referenced element was on well 29, I'd like to call this downtime
severity and let's say for instance that my status message attribute had a value of faulted for this
particular event frame, again this is just a manually created one this hasn't necessarily
happened in our system we could make this happen but what we were trying to do is just build out
a template for what we're going to be using for the rest of our event frame generation analyses.
And at the end of this I probably would like to append the start time and that's because
we would like to make sure that all of our event frames are uniquely named and easily searchable,
so by appending the start time you make it a bit easier to find and keep track of if
you're looking at the names of these event frames. At this point I can right click
and if I'm happy with how I've set this up I can convert this to an event frame
template. This shows my substitutions, in this particular case it doesn't change anything,
so I'll just go ahead and I can hit OK. If I look the library, in my event frame templates,
this will by default just append template to whatever name I gave my individual event
frame. We can call this downtime severity and I just like to have referenced this name that
I gave it so that way we can help define a naming pattern for the rest of these.
So again I'm going to call this template downtime severity. Τhis naming pattern allows
us to uniquely name our event frames and have it automatically generate names based off of a few
substitution parameters which are defined on the right. We can pass plain text as well as these
substitution parameters, to combine to give us our naming pattern. In the description field I
put an initial idea of what we'd like to do for our substitution parameters, we can see that well
29 was our reference element if I do % element % that will give us our well 29 or our well 30
or well 31 depending on which element the event frame was generated for. Put a space and next we
can see that I have downtime severity. I'm going to keep the template name as downtime severity,
so if I pass percent template percent, that will put in downtime severity.
New for AF 2017 R2 is the ability to add attribute values into our naming pattern. In this particular
case faulted was read from the status message. I can see that I have a substitution parameter
here called % @ attribute % what I'll need to do here is I'll need to change out the attribute
for the attribute name that is on my event frame template. You will need to reference an attribute
that exists on your event frame template, so make sure that if you do have an attribute value that
you would like to put in the naming pattern that you place it on your event frame template itself.
Now when the event frame opens the status message that it was at the start time will be appended.
Last but not least I'll add a start time. You're able to change the time date format
that is presented here but I'll leave the defaults. Again you could also place plain
text here. So you could put at any point in time any type of plain text they would like
to be put into every single event frame name from this event frame template,
so that is also an option as well. If we take a look at our attribute templates you'll see the
attributes that we put initially on our manually created event frame. We're also allowed to add
more attributes here if we would like them to appear on the end product of the event frames
created from the event frame generation analysis. And this time I don't need to
add any more attributes and I can go back to creating my event frame generation analysis.
For my event frame template I will use my downtime severity and here I'd like to use multiple start
triggers, one for each of my different down times. If we'd like to look at our enumeration set we can
either do this in the library itself or we can look on the attribute and look at the drop down
menu. I'll take a look at the enumeration set in the library and for my well status these are the
possible options that come into the enumeration set. For ease I'm going to take a quick screenshot
of this and I'll use these to create my start triggers. Probably my least important start
trigger is going to be the installation phase. As this is likely a fairly well scheduled system,
I'm going to name my start triggers as well. We have the option of keeping the start trigger
name in any event frame itself, so correct naming of the start triggers will actually
be helpful. For this severity I'll just put it as information. A note on severities these
increase from none up to critical so this is the set order that we have for these severities.
The next one that I have is the draw down testing. Since this is testing I'll assume that this is
also fairly scheduled, but I will increase the severity to warning. I'll proceed with putting
in the rest of my start triggers and for down and offline I'll put these as the same severity.
For my highest severity I'll have faulted; we'll
give this an end trigger; when the well status is equal to running then we'll know
that everything is working properly and we'll want to close out of any open event frames.
In the next video, I'll show you how to add an output expression onto your event frame
generation analysis, which will then allow you to capture different analytics that you run over
the course of an event frame . Afterwards we'll get back to creating the rest of the
event frame and checking out how it looks in our event frames tab in PI System Explorer.