$IDLE_TIME is the Blue Devils Playground

Overall Equipment Effectiveness (OEE) is a hot topic these days, and again shows the interactions going on between levels 0, 1, 2 and level 3 of the S95 model.  Folks are exploiting the features and functions of DCS platforms to provide intelligence towards the calculation of OEE.  Bob Engel of Informetric Systems Inc, has got an excellent white paper on calculating portions of OEE by using their InfoBatch product to mine data from DCS batch historians, like the one in DeltaV.  Batch analysis and batch to batch comparisons are the key outputs.

There is a missing component from batch historians, and that’s information between batches.  One of the three components of an OEE calculation is Availability, and being able to account for a Unit’s time not making batches can be as important as recipe run time.

One of the new features in Version 10 of DeltaV was Dynamic Unit Allocation.  This had been a long awaited feature (I’ve wanted something like this since my PROVOX days working on resins projects for Monsanto).  In grossly over-simplified terms, Dynamic Unit Allocation is the programmatic selection of what units a recipe should run on.

As part of Dynamic Unit Allocation, Emerson developed the concept of the Unit Selection Policy.  You configure your Selection Policies to provide the logic to the batch engine for determining which unit or units to use while the recipe is running.  They provide a couple of default selection policies, one of which is the DEFAULT_LEAST_RECENTLY_USED:

So how does DeltaV know which unit is least recently used?  Ah ha, they’ve added a new, default unit parameter named $IDLE_TIME.  So if I have a choice of three dryer units to transfer to, and I want the one that hasn’t been used in the longest time, I can use the DEFAULT_LEAST_RECENTLY_USED policy, which in turn will somehow look at the $IDLE_TIME parameter of each dryer and pick the one with the largest value.

So this got me thinking, how could I exploit (I’m famous for this, right?) this $IDLE_TIME parameter for use in OEE calculations?  How can it help me know what I don’t know – the time between batches on a unit?

My first crash and burn was to try and create an external reference parameter in a module that pointed to $IDLE_TIME of a particular unit.  You can’t do, because you can’t see it when you browse, and you get an error when you try and just type the path in – SF_100/$IDLE_TIME.CV

A little voice in my head suggested I build up a dynamic reference string, but I’ve seen so many good configurations go bad with the over-utilization of dynamic referencing, I dismissed it.  But since I had the expression editor open anyway, I thought I’d just try typing in the path (remember, can’t browse) to the parameter – success!

At this point, there are endless possibilities on how to use it.  I decided I’d push a message to the Event Chronicle (which can then feed into the Batch Historian) the first time my unit wasn’t idle, and report how long it had been idle just prior to its use:

If your batch cycle times are measured in minutes or hours, perhaps you’d want to report a daily idle time per unit.  If your cycle times are measured in days, a weekly or monthly report would be more appropriate.

Now, go be more effective.

DeltaV in HD

In version 10.3 of DeltaV, Emerson included support for wide screen monitors. To protect customer’s investment in their 4:3 format displays, a migration utility is included in 10.3. This utility allows the user decide how best to make use of the extra real estate on the glass when using a 4:3 graphic on a 16:10 monitor.

16:10? Wait a minute, Bruce – you mean 16:9, right? No, for some reason the computer world decided that wide screen for PC’s should be different than wide screen for TV’s. I’m sure it was a very good reason (like most reasons you get from IT folks). So what you’re looking at is a 1680 x 1050 format. Now if you’re starting a brand new project on a brand new system, you can use the new 1680x1050 template to create all your displays.

Back to your 4:3 displays. When you run the utility, you have to specify whether to right, left, or center justify the 4:3 inside the 16:10. But to utilize the remaining space, you need to adjust the layout file. Layout files were introduced the same time quad head monitors were. Books Online is somewhat sparse in detailing how to modify the layout files, so here are some tips and tricks from Scott Thompson:

• Layout files can be created for specific workstation names just like the Usersettings.grf files. Save the layout file with the name [workstation]_Picture.layout and it will only be applied to the matching workstation name. The workstation name restrictions are the same, so no dashes are allowed and use underscores with care as they tend to prevent customized user settings files from loading. You also won’t want to start a workstation name with a number even though DeltaV will allow it in DeltaV Explorer.
• If you have any errors in your layout file the entire file will be skipped. If what you get isn’t even close to what you expected there is probably an error and the default layout file was used instead.
  
  
• A custom layout file overrides settings that are common between the layout file and the user settings file. Since the layout file specifies initial graphics, toolbars and alarm banners the ones that load are those in the layout file, regardless of what is in the user settings file.
  
  
• In a multi-monitor system the layout file can be used to change what monitor is used for what purpose. For example, in a quad-head system monitors are numbered 1 through 4 by the operating system. The default layout makes monitor 2 the primary display (behaves the same as a single monitor system) and monitor 3 the secondary display (behaves like the second monitor on a dual-head system). Monitors 1 and 4 are defined as “user” monitors and are pre-defined for alarm list and alarm filter graphics by default. To rearrange the monitor usage without changing cabling (some furniture makes it difficult to get to after everything is installed) you can change the [MonitorAllocation] section (commented out initially).
  
  
• To add an additional picture to the layout definition you must make three changes. First, change the value of “Count.” This is the total number of pictures that are defined in the layout file. Don’t forget to decrease the value if you remove a picture. Second, add a “Picture#=” line that has the relative path to the graphic and graphic name without the extension. The base path is assumed to be the Pic folder of the workstation. Third, add a section that has the relative path and graphic name inside square brackets. This section will have entries for the screen, picture type, upper left corner position (X & Y coordinates), height and width.
  
  
• Easy trip-up prevention tip – if you change the picture name in the “Picture#=” line, don’t forget to change the name farther down in the file where the name is in square brackets.
  
  
• Picture height and width values don’t have to match the actual graphic that will be displayed. The graphic will stretch/shrink to fit the defined space reserved by the height and width numbers unless that functionality has been disabled for the graphic. This will require some testing to make sure all the displays you have defined or that may be switched to will appear correctly in the reserved area.
• Picture widths may not be what you expect. On a test system at 1920x1080 resolution, the alarm banner and toolbar widths needed to be set to 1914 instead of 1920 to display without extending onto the other display. Test often and try making minimal changes between tests.

PMBR

With batch event and LOG EVENT information going into the DeltaV version 10.3 Event Chronicle, you can start putting together simple views or what I’ve affectionately termed as Poor Man’s Batch Reporting (PMBR).

Process History View just doesn’t have the horsepower for the types of queries required. And that’s OK, because the Event Chronicle is a SQL database. So what I’ve done is link the alarms and events table into Access. This was easy because the ODBC data source is already setup for you in DeltaV:

Then I created two queries – one to get unique Batch ID’s and one to get the batch events. The Find Unique BatchIDs query looks like this in SQL:


SELECT Right(Events1!Attribute,Len(Events1!Attribute)-InStr(1,Events1!Attribute," ")) AS BatchID
FROM Events1
GROUP BY Right(Events1!Attribute,Len(Events1!Attribute)-InStr(1,Events1!Attribute," ")), Events1.Attribute
HAVING (((First(Events1.Attribute)) Like "@*") AND ((Count(Events1.Attribute))>1));

Executing this gives:

The Batch Events query required a parameter (well it did for me, anyway, but I am no SQL guru – I’m sure someone out there can do a better job), its SQL looks like this:

PARAMETERS BatchID Text ( 255 );
SELECT Events1.Date_Time, Events1.State, Events1.Desc1, Events1.Desc2
FROM Events1
WHERE (((Events1.Attribute) Like "*" & [BatchID])) OR (((Events1.Desc1) Like "*" & [BatchID]))
ORDER BY Events1.Date_Time;

When I run the query, I get prompted for the BatchID:

And the results look like this:

The pressure drop data was captured with the LOG EVENT function in the FERM_PTEST phase.

So here's a way to generate some simple batch reports without dealing with those pesky EVT files. Head over to my website - I'll be consolidating the 3 posts about batch events/reports into a whitepaper.