Tuesday, September 6, 2016

Easy Formula Management

One of the features in DeltaV version 13 is an easier way to manage recipe formulas.  When there are dozens of formulas with hundreds of parameters for a given recipe, viewing and editing the values wasn't all that easy prior to V13.  We now have the ability to copy, edit and paste formula values with Excel.

First, let’s take a look at a recipe I have in my demo system appropriately named DEMO_WITH_TRAINS along with its 4 configured formulas:

I can right-click on the recipe and select Edit Formulas:

The interface in DeltaV Explorer looks like this:

From here, I can change any of the values just by typing into the fields (remember the values contained within the <> are default formula values).  But instead of 10 parameters and only 4 formulas, I could have a lot more, making this a less than ideal interface.

So now with V13, I can select everything and copy it, including parameter names and descriptions to the clipboard:

Open up Excel and paste the data in (I added the green highlight):

You can make any required changes to any of the formula values.  What you can’t do is add a recipe parameter (that’s pretty straight forward, right?) or add a new formula (maybe not so obvious – I’ll come back to that in a minute).  You could create a master formula Excel file and use a different worksheet for each recipe.

When you’re ready to bring the changes back into DeltaV, highlight the data cells (some or all of the green highlighted data), hit CTRL-C, then go back to the formula dialog in DeltaV Explorer, select the EXACT same size range of cells, right click and select Paste (or CTRL-V).  If you don’t make the destination range the exact same size as the source range, you’ll get this type of error message:

If you need to add a new formula, right click on the recipe object and select New Formula:

Fill in the new formula dialog box as necessary:

Now editing the formula values will include your new formula:

There is one final step you have to do in order for the new formula to show up in DeltaV Operate – back in the DeltaV Explorer view, right click on the new formula and select Properties:

You need to check the “Operator can load” box which will then cause a Yes to appear in the “Release to production” column in the Explorer view.

Wednesday, August 24, 2016

Not To Alarm You, But Here's How to Generate An Audit Report

Alarm Management is a big focus of DeltaV version 13, helping our customers become compliant with ISA 18.2, which provides a roadmap for compliance across all stages of alarms, from identification to implementation and management of change.

One of the tools we’ve included in V13 is an Alarm Audit Reporting tool, allowing you to compare alarms as they are currently set online in the controllers to how those alarms are configured in the DeltaV database.

Accessing the tool first requires you to launch the System Alarm Management application from the DeltaV Explorer toolbar:

I’ll have to come back to the System Alarm Management application in a future post.  For now, once the app appears, click on the left most toolbar button or File, then Manage Alarm Reports…

The Alarm Reports interface looks like this:

So let’s create a differences report for the entire system – click on the green + button.  I’ll give the report a name, accept the default location and select Difference Report before I hit OK:

The next dialog box allows you to select the types of alarms to include and some filtering.  I’ll pick only Enabled Alarms, Process Alarms and All Functional Classifications:

The next dialog is where you get to add specific locations to the report.  You can specify areas, nodes, logic solvers, units, or even specific modules.  The All check box allows you to pick all of any of the above categories (except modules).  Since this is a system-wide differences report, I’ll check the All box for Areas:

Finally, you’ll get to the Schedule Task dialog – you’ll see it’s not yet scheduled, but using the drop down under Schedule Task, you can select the desired frequency – Once, Daily, Weekly, or Monthly.  Now you don’t have to schedule a report – you can leave it as Not Scheduled and you’ll be able to run it on demand from the Manage Alarm Reports view.  For this example, I’m going to leave the report as Not Scheduled:

Now here’s an important safety tip – if you hit cancel on any of these dialog boxes, it’s going to take you all the way back to the Manage Alarm Reports view L - just be careful. 

After hitting OK from above, your report will show up in the first row of the Manage Alarm Reports view.  I’ll go ahead and select it to show you how the other toolbar buttons highlight.  You can also get some of the choices by right clicking on the report:

Select Run from the menu, and wait until the Last Result column shows Completed:

Now use the View report button on the toolbar or the right click selection to see the results:

So out of 84 process alarms, I’ve got one difference between the controller and the database – my high alarm on LIC101 is configured for 90, but the online value is 95.

Both an XML and HTM file are generated when you run a report, so it’s highly portable.  And you don’t have to be inside the Alarm Report application to generate reports.  There’s a command line executable in the DeltaV/bin directory named SAMAlarmReports.exe – there’s a full explanation of how to use the executable in the help file associated with Alarm reports.

So a great use example would be to automatically generate a differences report as part of your plant’s shift turnover procedure – using, of course, DeltaV Logbooks.  Another use would be to generate a runtime report for a specific unit or units at the beginning or end of a batch.

Wednesday, July 20, 2016

Restore Point Modification With DVS 2.3.1

One of the cool features in DeltaV Virtual Studio (DVS) is the ability to provide disaster recovery capabilities using Virtual Machine (VM) Replication.  VM Replication creates and constantly updates a replica image of a running virtual machine in a separate cluster or replication server.

By locating the two clusters in different locations, a disaster in one location can be mitigated by starting up the replica image in the second location.

Now in addition to disaster recovery, virtual machine corruption can also be addressed with replication.  By default, VM Replication within DVS provides two restore points, allowing recovery from an image that is up to two hours old.  Here’s the procedure to increase the number of recovery points and select the required recovery point if a corruption occurs.

A couple of important points before I go on – increasing the number of recovery points increases the disk space requirements for the replica image.  Also, adjusting the number of recovery points has to be done in Hyper-V, not DVS.  In next year’s release of DVS, version 3.3, you’ll be able to modify the number of restore points from directly within DVS.

From the DeltaV Virtual Studio domain controller desktop, access the Hyper-V manager:

While the recovery points are associated with a replica image, managing the recovery points is done from the primary virtual machine.  You can see how many recovery points (snapshots) are available by selecting the replication location and the replica virtual machine.  Be sure to select the Replication tab at the bottom of the dialog box:

To change the number of recovery points, select the host and then the primary virtual machine that requires recovery point modification, then right click on the virtual machine and select Settings…

On the Settings dialog box, scroll down the left hand pane, click to expand the Replication section, then select Recovery Points:

The Recovery Points screen will show the current number of recovery points and the estimated storage requirement.  Either by using the up and down arrows or by simple typing in the field, change the number of recovery points.  The estimated hard drive space will change:

Once you click OK, Hyper-V will begin keeping more restore points, once an hour, until the newly entered number is achieved.  Checking the replica again will show all the configured snapshots:

If a corruption is ever detected in a primary virtual machine, use the Hyper-V manager to start the replica image and pick a recovery point.  DO NOT USE DeltaV Virtual Studio to start the replica – this will automatically use the most recent snapshot and will discard all the other snapshots.

Thursday, July 7, 2016

Using Fault Detection to Help Increase Process Understanding

We released our Batch Analytics (BA) application with version 12 of DeltaV and provided some additional enhancements as part of version 13.  BA uses Multivariate Analysis and Dynamic Time Warping to detect process faults, the reasons for those faults, and predicts endpoint quality, all in real time.  So instead of having to wait until the batch completes to find out there was a problem, fault and quality issues can be examined while the batch is still running.  This allows operations and engineering personnel to make better decisions that could correct a quality issue, dump a bad batch early, or schedule maintenance for when a unit is not in use.

Another important benefit is the education of inexperienced personnel to gain process understanding.  One of the features of the fault detection screen within BA is to prioritize parameters that are contributing to a fault:

The small green band at the bottom of the screen is the normalized range of the two fault parameters, T2 and Q.  A fault in this range (0 to 1) is statistically insignificant.  The larger the fault peak (the large blue T2 peak is around 55), the more statistically significant the fault is.  By selecting the user-friendly parameter names on the left, response plots of actual versus modeled are displayed:

The black lines above are the actual parameter response, while the dashed and dotted blue lines are the expected, modeled response.  For instance, you can see that M1 Level didn’t increase as much as the model thought it should have and the Salt Bin Level didn’t drop as much as the model predicted it should have.

But you don’t have to have a fault to monitor actual versus modeled trajectories.  Here’s a fault detection screen from a normal batch:

You’ll notice that while some of the peaks exceed the normalized 0 to 1 range, the largest fault is less than 2.5, compared to the 55 on the previous example.  My point is you can still see the parameters on the left hand side and can plot out their actual versus modeled response:

Notice that the mixer and salt bin levels followed the predicted, modeled response.  This can provide a great tool for training operations personnel to understand what “normal” is to be better prepared for process upsets and faults.