OPC Tunneling Eliminates Setup Headaches

OPC Under Duress

From the shop floor to the top floor, OPC is the preferred communication standard for sharing process control data at all levels of the enterprise.  But as OPC pours into mainstream acceptance, integrators are finding configurations where OPC can be a hindrance to the panacea of plug-and-play application interconnectivity.  The most common situation occurs when applications on different Windows domains must communicate with each other.  Still, other designs call for the use of low-bandwidth or unreliable networks.  It is in these setups that OPC can make use of new “tunneling” technology, which eliminates the biggest OPC headache for integrators: setting up DCOM.

OPC

OPC (OLE for Process Control) standardizes data sharing between plant floor devices (DCSs, PLCs, analyzers, etc) and software applications (such as HMIs, Process Historians, trenders, etc).  No matter what the device is, data is always shared with an application in a standardized format.  Of course, standards-based communication is only half the task – the other half deals with the actual method by which the data moves across the network.

COM/DCOM: The Basis of OPC

When OPC applications are installed on the same computer, they use Microsoft’s COM (Component Object Model) technology to exchange data.  But, when installed on 2 separate PCs, they use DCOM (Distributed COM) for the data exchange.  Unfortunately, OPC developers have no programmatic control over DCOM, and are thus bound by DCOM’s limitations.  Consider two OPC applications that are installed on two PCs on two different Domains.  Clearly, their OPC communication must use DCOM.  Consequently, the Domains must share at least one common username and password.  This can be a serious issue, especially when these domains and applications are owned by different groups (IT and Process Control), different vendors (two different DCS vendors), or even different businesses altogether (when plants must share information).  OPC applications from any vendor will be stopped dead in their tracks, unless this DCOM issue can be overcome.  While these may be simple technical hurdles that are easy to overcome, they may also present serious political issues.

Tunneling Eliminates DCOM

DCOM problems can sometimes be overcome with a few hours of work and good corporate maneuvers (politics).  But, another approach is to eliminate DCOM altogether with Tunneling technology.  In this case, an OPC Tunneller is placed on each of the two PCs.  Each OPC Tunneller object communicates with its local OPC application using reliable COM.  The two OPC Tunneller objects are then free to exchange data via any appropriate communication technology, such as TCP/IP, HTTP, HTTPS, XML, etc.  The data transport technology can be selected by either the user or programmer to accommodate for the special needs of the required design.  Third party passwords are immediately nullified, Domains become irrelevant, and network performance (bandwidth and reliability) is a non-issue.  Thus, each OPC Tunneller has two objectives: to transfer the data in the most reliable way to the other OPC Tunneller object, and to translate all data back to standards-based OPC, so that the communication remains persistent and consistent.  The result?  All of the headaches typically associated with DCOM are alleviated.  Specifying an IP address or computer name within OPC is all that is required.

Looking back

OPC is an accepted standard within the process control industry.  Whenever possible, users should use the existing infrastructure: COM/DCOM.  However, in cases where the underlying technology cannot accommodate the project’s specific needs, OPC Tunneling provides a viable and reliable alternative.

Since its inception in 1996, the OPC Foundation has been working to build awareness and offer an alternative to exchanging data with proprietary drivers and application.  The demand for OPC drivers and tools is increasing exponentially.  More and more vendors and developers are working towards making their products OPC compliant.  The ability for OPC to now tunnel its way across connections where DCOM may be inappropriate is just another step towards creating a truly open, robust and scalable solution for the process control industry.  No longer does DCOM cause headaches for integrators.

***

This article was written by Randy Kondor, OPC Product Manager at Matrikon. Randy is responsible for Matrikon’s OPC business unit which is comprised of over 50 full time employees. Since 1996, Randy has been vastly involved within the OPC industry and a strong supporter of the OPC Foundation. He continues to dedicate himself to spreading the OPC Foundation's message about system interoperability and inter-vendor cooperation.

Matrikon Inc.

10405 Jasper Avenue

Edmonton, Alberta, Canada

T5J 3N4

Additional Resources:

Matrikon OPC: www.matrikon.com/opc

Multimedia Tutorial: www.matrikon.com/tutorial