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.