Automation Software: Pick OPC to be more Futureproof

by Oliver Yu

When scoping out automation projects, we commonly run into the tension of cost versus extensibility.

A system that is "futureproof" is one that can withstand changes to requirements or specifications that are determined at some later time. As with a lot of decisions in life, choosing a short-term gain often comes at the expense of the long-term.

So is the case when deciding to go with OPC at a greater initial cost. OPC stands for "OLE for Process Control" where "OLE" is Microsoft terminology that stands for Object Linking Embedding. (I guess that would make OPC short for "Object Linking Embedding for Process Control.")

As discussed here and here, OPC is the standard for communications between automation systems. OPC is maintained by the OPC Foundation… an industry consortium and is essentially what makes vendor agnosticism possible.

Vendor Agnosticism

Not having to believe in or commit to or be beholden to a single vendor.

For example, suppose you want to go with a Rockwell system. Rockwell has an embedded historian called, "FactoryTalk." Under the hood, FactoryTalk is OSIsoft PI. Side-by-side, they share the same folder structure, the same commands, the same services.

So the logical thing to do when setting up a corporate PI system is to buy a PItoPI interface and call it a day, right?

Not so fast.

Suppose the facility has a Building Automation System (BAS) and while out-of-scope for this project, the data from the BAS is expected to go into this corporate PI system. What happens then?

One option is to find that specific BAS vendor and see if OSIsoft sells a PI interface for this BAS vendor.

A second option is to see if this BAS vendor sells an OPC server for their data and if so purchase the OPC server and purchase the OPCtoPI interface and connect the two via OPC.

What happens if another control system enters the picture (suppose a Finesse/DeltaV system was purchased and commissioned)? The same questions have to get asked again (and re-answered).

Futureproofing in this case means choosing OPC and running every new system through this standard of communication, even at a greater cost to the initial system. In short-term, there is a larger budget to justify; in the long-term you eliminate future work (Design Reviews, meetings, revisiting past decisions…)

KEPServerEX OPC Connectivity Suite

by Oliver Yu

I just plunked down some dough for Kepware's KEPServerEX OPC Connectivity Suite. Actually, it was a part of a project for a client, but nonetheless, Kepware makes one of the best OPC servers in the business.

Read this intro to OPC.

So if you've got "Islands of Automation," that is, a diverse ecosystem of PLC and DCS vendors as a part of your operations, getting these systems to talk to PI with OPC is the best way to go.

Most operations aren't intelligently designed from Day 1. Operations tend to evolve. People come and go. Corporations make mid-course corrections to their strategy and even the best automation systems evolve into silos of automation.

OPC breaks down these silos and enables communications, and none better than Kepware's KEPServerEX.

Each modern PLC vendor writes an OPC Server for their PLC. In the diagram to the left, those are the blue computers at the bottom.

The OPC Server allows OPC clients to connect and get data. This is where the KEPServerEX OPC Connectivity Suite comes in. One part of the server is an OPC Client (the yellow puzzle piece in the diagram).

And the other part of the KEPServer is the OPC Server. In a sense, this makes the KEPServerEX the "One-stop-shopping" for OPC data.

So from here, you get to send the data to wherever you want to go.

Biotech/pharma companies typically choose OSIsoft's PI System. And to connect there, you just need the PI OPC Interface, which is an OPC client.

You could've connected PI directly to the OPC Server of the PLCs, and a lot of people do. But if you want a separation of duties between your systems, Kepware OPC is where I've seen a lot of people meet success.

But here's the really cool part. Kepware has impeccable technical support. They're a small company so you're not getting routed around the globe for your tech support calls... you're usually talking to the same guy to follow your issue to solution.

Evaluating their systems is worth your while if you're looking to upgrade your automation.

Download Demo

Disclosure: I have no business relationship with Kepware and receive nothing if you buy their products.  Also, I didn't get paid anything to write this post.

5 Things About Connecting To DeltaV OPC Server

by Oliver Yu

Configuring an OPC client to talk to DeltaV's OPC Server is a chore. And surprisingly, there's not a lot of Google-ready goodies on the matter.

To rectify that situation, here's a list of the Top 5 things you need to know about OPC.DeltaV.1

5. OPC Remote - required client software

OPC Remote refers to the software you need to install on the OPC Client to be able to talk to DeltaV OPC.  I found this strange because when I was the PI OPC Interface to a KEPServerEX, OSI provided all the software for the OPC client and Kepware provided all the software for the OPC server.

Whatever the case, you need to execute OPCRemote.exe on each machine you designate as an OPC client. This package contains the requirements and diagnostic tools like OPC WatchIt.

4. OPC WatchIt! - diagnostic tool

This Windows application is a single form that let's you connect to the DeltaV OPC Server.  It's installed on the DeltaV Application Station and you ought to run it there to see if the OPC Server is up.

If it's working on the App Station, but not on the client machine, you know that you have a connectivity problem.  If it's working on the client machine, you know you're close to getting data flowing.

3. FrsOpcDv

The DeltaV OPC Server does NOT run as it's own Windows Service.

 As in, if you type services.msc and go hunting through that list, you won't find anything that resembles the OPC server.   But if you type taskmgr and look through the programs that are running, you'll see FrsOpcDv.exe.  That, right there, is the DeltaV OPC Server.

This means that when you're setting up DCOM settings that you need to visit this entry in DCOM Config.

2. Local User Account is Your Only Option

There's only one way to connect to DeltaV OPC Server and that's with a local user account.  The one that's pre-configured is called, "DeltaVAdmin."  This account has to exist on the DeltaV App Station as well as the PROPLUS for the data to get sent.

What's crazier is that DeltaV is hard-coded to block anonymous access, which means your OPC client must be running as DeltaVAdmin (or equivalent).  If you're connecting DeltaV to a PI-OPC Interface, make sure the interface is running as "DeltaVAdmin".  This is basically your only option to getting it to work: you cannot use the local SYSTEM account.

1. DeltaVAdmin Needs DCOM Permissions

It follows that you need to create a local user on your OPC client called DeltaVAdmin.  It also follows that you need to grant this local DeltaVAdmin user Local and Remote authorities:

• Local Access
• Remote Access
• Local Launch 
• Remote Launch
• Local Activation
• Remote Activation

That's basically the list of things I wish I knew going into connecting to a DeltaV system via OPC.


Need A Pro Onsite?

OSIsoft PI OPC Interface and sub-second data

by Oliver Yu

I found out today that the PI-OPC Interface supports sub-second data. I'd imagine that this comes as no surprise to many of you, but it certainly does to me.

OSIsoft PI has supported the archival of sub-second data for quite some time. And for cell culture/fermentation processes, sub-second data is overkill. Cell culture happens over the course of days, production culture...weeks. Fermentations happen in hours, so very few things happen in between seconds.

Actually, there was this one time there was a rupture disk on a pasteurizing unit that had a setting of 50psi. When the transfer of media through the pasteurizer failed, due to the rupture disk, the highest pressure reading on OSIsoft PI was 29psi. As it turns, there was a pressure spike that happened on a sub-second basis, and was not captured... I suppose some large-scale manufacturing activities may require sub-second data for troubleshooting.

But ever since moving to sub-second data, it has been a pain because an event may happen at

18-Apr-12 01:24:03.5566

but if you were searching between

18-Apr-12 to 18-Apr-12 1:24, then you'd miss this event.

As is, people despise typing out more characters for specifying time. And in cell culture processes, it is simply not necessary. But as OSIsoft PI evolves to serve multiple industries, nuisances like sub-second data start cropping up.

In any case, the way to specify a sub-second scan-rate is at the interface. In the case of the PI-OPC Interface, you can specify the scan class as a fraction. If you wanted to specify scan rates at 1/10th, 1, 2, 5, 10, 30 and 60 seconds, your interface configuration file should read:

/f=0.1 /f=1 /f=2 /f=5 /f=10 /f=30 /f=60

Then any tag that you want to scan 10 times per second should have location4=1 (since 0.1 is the first scan class).

In any case,

• Few cell culture/fermentation processes require sub-second scan rates.
• Well duh: a PI system capable of archiving sub-second data has interfaces engineered to deliver data at sub-second scan rates.