By Randy Kandor, B.Sc. Eng. CompE
OPC HAS QUICKLY become the de facto open communication standard in the world of industrial connectivity. It offers improved data connectivity, while dramatically lowering the cost of data transfer between devices and applications.OPC communication is layered on top of various Microsoft operating system components. These components function very well under typical LAN conditions (high bandwidth and reliable connections), but under less favorable conditions, their behavior can lead to unreliable data delivery, and even data loss. OPC Tunnelling provides a solution to this problem.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 infrastructure for OPC
OPC is built on Microsoft technology called COM, which stands for Component Object Model. It is a framework that defines how applications communicate with each other and share data. When OPC applications are installed on the same computer they use COM to exchange data. However, when installed on 2 separate PCs, then the COM messages are wrapped in a Microsoft security layer called DCOM (Distributed COM).Most OPC configurations involve the use of DCOM. There are circumstances where DCOM can experience timeouts that can lead to unreliable data delivery and even data loss. Such circumstances can include:
- Hardware problems, such as a faulty network card, router or switch
- System issues, such as an overloaded network
- Inherently unstable network architectures that use satellite links, WAN, radio communication, etc.
It should be noted that most networks, even reliable ones, suffer from these problems from time to time.As an example, assume an OPC application has requested a value from another OPC application running on separate computer. After the request is sent, but before a reply is received, the network connection between the two applications is temporarily broken. In this case, the requesting application can be forced to wait for up to six minutes to realize that an error has occurred, even if the connection is immediately restored. Unfortunately, DCOM does not enable users to change the six minute timeout period.In the mean time, the requesting application simply waits for DCOM to reply, so that appropriate actions can be taken as needed. All process data for the application is unavailable during that time. While developers can create multi-threaded applications that monitor the DCOM connection and take corrective action, this adds a very high level of complexity and cost to the application.
Tunnelling Eliminates DCOM Risks
OPC Tunnelling provides an alternative approach that eliminates the DCOM risk altogether. This technology uses standards-based TCP/IP communications instead of DCOM for carrying OPC messages. It provides users with configurable timeouts that are appropriate for the specific installation.In a typical setup, an OPC Tunneller application is installed on each of the two PCs in use (see the diagram below). Each OPC Tunneller communicates with the locally installed OPC application with OPC (using COM). The two OPC Tunneller applications then pass the OPC messages using TCP/IP, which eliminates the requirement for DCOM.
