OPC shortcomings?

InTech, Jun 2004 by Sheble, Nicholas

An exchange on the Controls Manufacturing Community List piques InTech's and others' interest. Greg Potter from Azimuth-Solutions contributed this.

I was recently involved in a project in which we linked the operator interface stations at two pipeline terminals together using OPC (OLE [object linking and embedding] for process control) over a corporate wide-area network to facilitate consolidated operations of the facilities.

During the course of the project we ran into several problems that from my perspective highlight fundamental problems in the implementation of OPC on industry-standard Windows operating systems, which are not particular to the vendor of the systems we used and which I will detail further.

It would be interesting to hear others' similar observations and the solutions they arrived at and from those who have product-based solutions that address these issues both from an implementation and diagnostic perspective.

Having carried out a number of system control and data acquisition projects over the past twenty plus years of my career in the control and automation field and having written a number of serial communication drivers in the old days before the widespread adoption of Ethernet and the Winsock application programming interface (API), I have an expectation as to the level of diagnostic capability that a user should expect in an industrial communication system.

While working through the problems that we encountered on this project and spending considerable time consulting with the vendor and researching OPC, distributed common object model (DCOM), and the Winsock interface, my impression is that there is an almost complete disconnect between the application sitting on top of the OPC/Windows OS-based system and the low-level communications resources from a communication control and diagnostic perspective.

Once a call goes to the Winsock API the details of what happens below in the operating system (OS) and communication system is nearly totally abstracted.

One of the results of this is that there is almost no information returned to the application (in our case operator interface) by the API; hence the diagnostic information presented to the operator interface application is extremely limited.

Third party tools must be used to observe what is going on within the communication system (stack counters, diagnostic status flags, Ethernet packets), and from a diagnostic perspective there is no ability to link a specific communication request from the application to communication events occurring within the communications subsystem.

A second result of the disconnect between the application and the communications system is the inability to exercise any control over the communication system.

The Winsock API offers no real access to do this. This is good from the perspective of ease of implementation; however it is inadequate from the perspective of providing control over the communications system used for industrial control. To access the limited control that is available in the Windows OS the user must access the system registry using yet another disconnected tool.

I believe that OPC is a great concept, and I believe that it has a lot to offer.

However, I believe that to get it to the point where it offers the integrity and diagnostics that industrial users are accustomed to, the shortcomings of the communications resources provided by the off-the-shelf Windows OS need attention and mitigation.

Nicholas Sheble edits the Networking & Communications department. Write him at nsheble@isa.org.