ian_verhappen3

OPC as the network glue

March 22, 2006
Industrial Networking columnist, Ian Verhappen, addresses open process connectivity (OPC) and how you can use different flavors of it depending on the application and system requirements.
By Ian Verhappen, Columnist

AS MOST of us know, no single network can meet all the communications needs of all the different types of processes for which we use automation. In many cases, it’s necessary to share information in real time or at least as close to real time as we can manage across these networks, because we’re unable to use one network in our facility.

The most commonly used solution to this challenge is OPC, the Open Process Connectivity managed by the OPC Foundation. You’ll use different flavors of OPC depending on the application and system requirements. To determine which of the seven OPC versions you need, investigate each at the foundation’s web site, and/or consult with your system integrator, who will have experience in this area.

Present versions of OPC are derived from COM and DCOM, the same technology used to link an embedded “Excel” table into a “Word” document, thus having legacy connections with the Windows Operating System. The recently defined OPC-UA (Unified Architecture) is designed to be platform independent.

Despite the fact that OPC is the de facto real-time communications “glue,” like anything else, it has its limitations, including:

  • “Mapping” of parameters is much like what is required for Modbus registers. Until the contents of the information to be shared across the system is fully defined in a common language—and efforts are underway on many parallel fronts—it will be necessary to create pointers between the pieces of information on the two systems being connected. For example, EU_RANGE, the full-scale range in engineering units from manufacturer A, might be EU-RANGE in the system from manufacturer B. However, rven if they have the same name on both sides of the relationship, they might be in different memory locations on each system, and, therefore, still need to be linked manually. And, if one or the other devices is changed out or upgraded to a newer model, the memory location might also change, thus requiring the remapping of all the device parameters a second time.
  • The interoperability testing done by the OPC Foundation is not as rigorous as one might expect for applications being used in real-time operations. They certainly aren’t as stringent as those of the hardware foundations, such as the Fieldbus Foundation, HART Communications Foundation and Profibus Trade Organization, where a single failure of any of their multiple tests is grounds for rejection. With OPC, each manufacturer “self-tests” and then, periodically, the OPC solution providers get together and link up in one large system to see if they can all “talk” to each other. If communications can be established, the systems are defined as interoperable. The good news is that the OPC Foundation is developing more rigorous testing protocols that will remedy this problem in the near future.
  • Security “work-arounds” are to some extent proprietary and supplier-specific. Though they enable communications across firewalls and VPNs, they restrict users to the OPC software solution from one supplier, which defeats the purpose of using the technology to bridge across systems. Because of this limitation, it might be necessary in some cases to install an extra OPC Client-Server on one side or the other of the firewall to interface between the two “interoperable” OPC systems.

Driven by the requirements of the above-mentioned foundations for tight interoperability, and the fact that the joint effort to update EDDL technology includes OPC UA, it’s necessary that, once released, UA address some of the above concerns. OPC UA should be available from several manufacturers later this year, and my expectation is that we will see it demonstrated at ISA Expo 2006, Oct. 17-19, in Houston.

The OPC Foundation, like many other industry associations, followed the lead of the Fieldbus Foundation and formed an End-User Council to channel feedback directly from customers to their organization, and improve their products. If you have any comments on limitations or improvements you would like to see to make OPC more user-friendly, please let me know and I will pass the information along.

  About the Author
Ian Verhappen is an ISA Fellow and director of ICE-Pros Inc., an independent instrumentation and systems engineering firm focused on fieldbus, process analyzer systems and oil sands technology. He can be reached at[email protected]or via the web atwww.ICE-Pros.com.