In
this video I will demonstrate how to
set up an event frame generation
analysis. An event frame allows
you to essentially bookmark important
events in your process, and to
collect information about them for
analysis, like tracking these downtime
events that have been periodically occurring for
this particular piece of equipment. An
event frame generation analysis is used to
trigger event frames by specifying the start and
end conditions for a specific event.
In this example we would want an
event to be triggered when the status
goes from this running state to a
downtime, and we would want the
event frame to end when it switches from the
downtime state back to this
running state. The type of information
that will be captured during
this specific event time
period is specified with an event frame
template. The event frame
template contains the attributes that will
be captured. And in order to set up an event
frame generation analysis to create event
frames, an event frame template is first
needed.
Let's set up the event frame generation
analysis to create event
frames for downtime events for all these different
pieces of equipment
in this manufacturing
group's AF database in PI system
Explorer. Event frames
generation analysis can be set up
for individual elements
using this analyses
tab. If you don't see
this analyses tab you probably aren't using
the latest version of the PI Server,
which includes AF 2.6, or the client
tool. However, these pieces of
equipment were built off of a
template, so I can set up the event frames generation
analysis on the template and only have to do
it once. Let's take a look at the templates
under the library tab.
Under templates, element templates,
right here is the equipment
element template that those pieces of equipment
are based off of. In order
to set up the analysis I'll use the
analysis templates tab, and
the process for setting up this type of
analysis, either with the analysis
templates, or the analyses
tab for elements is basically
the same. We'll go ahead and create a new
analysis template. The first thing that we're going
to start off with is, over here on the right-hand
side, giving the analysis a name and
relevant description.
As I mentioned, we're going to be tracking
the equipment downtime, and I'm going
to give it a full description. That way
anybody who looks at this analysis
will understand what it's being
used for. Similarly
I'm going to go ahead and create
a new category, since I don't have a relevant category
for this.
Categories are used for
organizational purposes and to make things easier
to search for. Use categories that are
meaningful to you. The next selection we need to make is to
choose the event frames generation under the
analysis tab. Since we're working off of a
template, we'll need to
choose an example element to
work with, since at a template level the
attributes don't have defined values the way they do for a given
element. An example element is already
selected, but if I wanted to change it I could click
on this and choose another piece of
equipment. This is basically pulling a list of all the elements that are
based off of the equipment template. The next
thing to do is to pick the event frame
template. An event frame template has to be
set up beforehand. The template that we're going to
be using is this downtime template. Now that I've
selected the downtime template I'm actually going to take
a quick look under the event frames template
at this downtime template, so we can see what
we'll be capturing.
So I'm going to navigate to attribute
templates. Here we can see that
for the downtime event we'll be
capturing the time length, the reason for the
downtime, and what was the average
production rate of the parent line for the equipment piece, so we
can have an understanding of how individual pieces'
of equipment downtimes affect the line as
a whole. One thing to point out on
this template is, as we look at
these attributes, there's this particular
syntax that is being used right
here. It's the dot backslash
elements, open square bracket, close square
bracket. This particular syntax
was used in order to have relative
references; that way in the
event frames generation analysis,
we can apply this to each piece of
equipment. Let's navigate back.
I'm navigating
back to the analysis that we were
looking at, and the main
component of setting up
the analysis is to determine the start and
end of an event.
Because they test start in
end conditions, the expressions that are
entered here must be able to be evaluated as
true or false. Let's start off
with the start trigger and talk about what
that means. What condition must
be true for there to be a downtime
event. Essentially that status
would have to equal downtime, or you could
conversely report that that status,
that value, was not running.
To start typing this condition I'm first going
to call the status attribute. There's
a particular syntax for
expressions, and attributes have to be
enclosed with single quotes. So
if I hit a single quote, IntelliSense
is going to pick up all of the
attributes that this template
has, and we can see that the status
attribute is indeed picked up, and if I
start typing I can just select the
status. If you want to look for different
attributes, you can always use
this attributes tab down here.
When developing
expressions you're combining attributes
with functions and the functions that are available are
shown over here on the right. The
functions are grouped by different categories. I'm
selecting the operators, and this
provides the definition and an example
for each of the functions. If I wanted
to add any of the functions I can
also use this insert button right here
versus typing it in this box. We
want to represent when the status does not
equal running. Another important syntax rule is that strings have to be
enclosed in double quotes.
Once you have your start expression
typed in here, a good thing
to do is to hit evaluate,
which will see whether or not this
particular condition is true or
false at the current time for this example
element. It will also let you know if there is
any problems with your expression, if there is
an error. So I hit
evaluate; if I look
here I can see that in this case
the value is true, so this
particular element must be actually going through a
downtime right now. If the
status was equal to running this
value here would be false. If I scroll
down there's also an end trigger, but
you'll notice that it says that this is
optional. Why is this
optional? If no end trigger is
specified the event frame will end when
the start condition is false.
What that means is this event
frame will end when the status
equals running, because that will mean the status
not equal running statement will be
false. You only need to
use an end trigger therefore if the start and
end conditions would be different. In our case
we won't enter an end trigger.
There are some additional options down
below, such as the start trigger true. This
start trigger parameter is designed in case
you have a spike in the input
data that would maybe potentially start an
unwanted event frame. This would make sense
if the attributes that are incorporated
in the trigger might be monitoring
something like a temperature or pressure that might
receive a spike, and it's important to
ensure that it's not a temporary condition
but that that value is indeed in some sort
of threshold that should receive an
event. If we're interested in generating a child root
cause event frame we can check this box here, which I'll
go ahead and do. What this will do is it
will essentially take a specific time range, in
this case I'll pick 30 minutes before the
event, and it will capture information as a root
cause. This can be particularly
important if something that triggered the
downtime actually was occurring before and
we wanted to capture information for
analysis there. The final
configuration choice to make is on
scheduling. There's event triggered, and there's
periodic. With event triggered
if there is a change to any of the
inputs, in this case the only attribute
in our expression is the status, this
expression will be evaluated
and if it is indeed true, and event frame
will be triggered. Periodic
is for clock-based
scheduling, which you'll notice it says trigger at
regular intervals. When the periodic choice would
make sense is if you're trying
to track events that are, say, operator
shifts, and these are periodic; they occur, say
every eight hours and you're just trying
to make comparisons between those different
operator shift, and you have events set up to capture
different shifts. At this point we're ready to
go ahead and check in this analysis.
Since I set up the analysis
at a template level
the analyses should be started
automatically. I can confirm that this analysis
was applied to all of the equipment
pieces by navigating back under
elements. So I'll take a look at this
piece of equipment and under the
analyses tab
I see that there's the equipment
downtime event frame generation analysis that I just
set up, and if I navigate and
look at other pieces of equipment
I see that they
all have the
analyses applied and
started. I want to look at
are we generating event frames, and in
order to do that I'm going to navigate
to the event frames
tab. I can simply do a
right click and do a new
search, and this brings up the event
frame search menu. I know that
downtime was in the name of my
event frame so I'm going to do the
wild card asterisk, downtime,
asterisk, and do a
search. Somebody told me that
they heard BP988 went through
a downtime starting about 20 minutes
ago, so let me take a look.
Okay, I can see that I
have eight event frames that have been
generated and there was indeed a downtime for
BP988, which in fact
lasted eleven minutes and
started about 20 minutes ago
right here. Something
that I also can see is
BP988 wasn't the only downtime event
we had. These pieces of equipment went
through downtimes too, and in fact
these ones down here are still
active.
Now I can look at the
different downtimes for each, and this one was
for BP988. If I look at
attributes I can see that the
reason why we were down for those
eleven minutes is because something was
assembled incorrectly. Fortunately
it looks like our impact on the line
average production we only fell a little
bit below the target of
forty. I wonder if the same thing happened for
other downtimes. Oh wow; it looks like in this
downtime we didn't produce anything for
that line. In this case it was easy
to see the event frames in action
because we are actively having
downtimes. One thing that you may be interested in when setting
event frames is backfilling your
data to see what did the events look like
last week. And that's something that we'll show in the next video.