OLE for Process Control OPC

In automated systems there are a lot of things that have to be integrated.   Communications is just one of the many components.  Therefore, we want components that are easy to use, high performance, and low cost.  The most common ways to implement communications are OPC, ActiveX, DLLs, and now .NET objects. 

Comparing OPC to ActiveX and DLL products -- we prefer OPC the least.  It's not that OPC is a bad thing.  In fact the theories behind OPC are great ideas.  However, there are numerous problems that don't make OPC a good choice for VB and C# programmers today. 

We would estimate that today there are as many people (or more) developing SCADA type applications in Visual Basic and C# as with Wonderware, Intellution, and all the others combined.  Ironically, OPC does not make it easy for VB users to use OPC.  Typically, ActiveX controls are the easiest to use but DLLs offer higher performance than ActiveX. 

We have tried to get software manufacturers to show different response times using DLLs, ActiveXs, and OPC for typical operations of reading 100 values and writing 100 values and then 1000 values (the most typical operations).  We would do these tests if we didn't have to pay all the money to buy the software just to test them.  Our suspicions were that OPC was relatively slow.  However, we have had some user reports that claim 20 to 30 millisecond response times using OPC. 

OPC is founded on the Microsoft COM model.  COM can be very difficult for VB programmers to use unless the supplier provides special interfaces for the VB programmers.  VB users expect a ready to use (already developed) OPC client (like an ActiveX control or DLL) which nobody wants to provide. 

We did one OPC project and it was a nightmare trying to get OPC to work in VB. The famous line was "oh -- you need to get a VB OPC client".  We were like "okay, but where do we get one".  No one could tell us!  They would say the OPC foundation site, which directed us back to the OPC server supplier. 

What no one wanted to tell us was that we needed to spend thousands of dollars for each OPC server and thousands of dollars for each client.  So another major problem with OPC is that OPC servers are typically licensed for one computer -- you have to buy a separate license for each computer it runs on.  ActiveX and DLLs are licensed for each developer and can be used on many computers.

There was one company that tried to assist the VB programmer.  They made software that generated an OPC client (actually a DLL) that could work with any OPC server.  They originally charged $1,000 for their software (no additional licensing fees), then had a sale price of $500, and then went out of business. 

The Microsoft COM model, which OPC is based on, is going away with the introduction of Microsoft's new .NET model.  OPC software can run with the .NET framework -- just slower than it currently does.  Therefore OPC software will have to be rewritten to take advantage of .NET.  The OPC foundation started several years ago rethinking their specifications using XML and SOAP.  What is interesting is that XML and SOAP will be available to all operating systems -- not just Microsoft.  So OPC should work easily on all platforms.  Hopefully a Microsoft remoting and sockets version of OPC will also be produced for faster response times. 

But the biggest problem is ...

An additional problem is that the OPC foundation and OPC users are being sued by a company called Solaia that claims to have a patent on communications with PLCs.  We are not patent attorneys, nor understand all the details, but do not understand this claim since other companies claim to have patents on the same thing -- communications with PLCs.  For example, there is a PLC company that has a patent on sending "blocks" (packets) of data over a serial communications link.  This is the basis of all computer (not just PLC) communications (before and after the patent was issued) so we don't understand why many patents were issued in the first place.  We think and hope that this will be worked out in the next few years. 

Summary

OPC has done the hard part.  They have gotten individuals from competing companies to work together to try to standardize communications.  They have already accomplished monumental tasks.  We hope that the OPC foundation will continue their work, work out all of these problems and within a few years all of these problems should be behind them. 

From reading this webpage you would think that we are totally against OPC.  But there are a lot of very interesting changes taking place in the computing and automation worlds.  Every few years, major revolutionary events occur in the computer market to shake up automation.  .NET may be that perfect opportunity for OPC to take the lead in automation communications. 

For more information see:

• Industrial communications. 
• The OPC Foundation
• OLE for Process Control book
• Computer - PLC communications
• Interkama Article about the Solaia lawsuits
• Control Engineering Article about the Solaia lawsuits
• Our thoughts regarding the Square D / Solaia Patent
• Visavi Software -- Classes and controls for interfacing to OPC in .NET
• OPCWare -- OPC Client development software

We try to offer a fair and balanced opinion on every page of our website.  We would appreciate more information from other OPC users to express their opinions which we will then incorporate.  If you have questions or comments please post them on our message board (see button in left hand column) so that others can read and benefit.