OPC tunnelling is a useful way to avoid the hassles of DCOM. Tunneling products such as the OPC DataHub convert OPC to TCP for networking, then back to OPC again. In today's market, there are two approaches to OPC tunnelling: 1) Extend the OPC transaction across the network, or 2) Keep all OPC transactions local to the sending or receiving computer.

Extending the OPC transaction across the network passes a typical OPC client request across the network to the OPC server, and the server's response is then passed all the way back to the client. The resulting network behavior is similar to DCOM's, exposing each transaction to issues like timeouts, delays, and blocking behaviour.

Keeping all OPC transactions local limits the client and server OPC transactions to their respective local machines. The tunnelling program's job is to continually synchronize the client and server copies of the data, which can be done very efficiently. When the OPC tunnelling program receives an OPC client request, it responds immediately with data from a locally cached copy. At the server end, the same thing happens. Thus, a minimal amount of data crosses the network, and both OPC server and OPC client are protected from all network irregularities.

The OPC DataHub uses the local OPC transaction approach.

To protect against network irregularities and breaks, any good tunnelling application will offer some kind of link monitoring. Typically this done with a "heartbeat" message, where the two tunnel programs send messages to one another on a timed interval, for example every few seconds. If a reply isn't received back within a user-specified time, the tunnelling application assumes that the network is down. The OPC client and server may then be informed that the network is broken.

Extending the OPC transaction across the network: A problem arises when you have to specify the timeout used to identify a network disconnection. If you set the timeout too long, the client may block for a long time waiting for a reply, only to discover that the network is down. On the other hand, setting the timeout too short will give you false indications of a network failure if for some reason the connection latency exceeds your expectations. The slower the network, the greater the timeout must be.

Keeping all OPC transactions local also provides link monitoring, but the OPC client and server are decoupled from the network failure detection. Consequently, the timeout can be set appropriately for the network characteristics—from a few hundred milliseconds for highly robust networks to many seconds, even minutes for extremely slow networks—without the risk of blocking the OPC client or server.

The OPC DataHub uses the local OPC transaction approach.

1. Every tunnelling connection has an associated cost in network load. Will multiple connections add significantly to this load?

Extending the OPC transaction across the network may allow many clients to connect through the same tunnel, but each client sends and receives data independently. For each connected client the network bandwidth usage increases.

Keeping all OPC transactions local can handle any number of clients and servers on either end of the tunnel, and the data flows across the network only once. Consequently, adding clients to the system will not add load to the network. In a resource-constrained system, this can be a crucial factor in the success of the control application.

2. Be sure to test for cross-coupling between clients in multiple tunnelling connections. Does a time-intensive request from a slow client block other requests from being handled?

Extending the OPC transaction across the network may serialize access to the OPC server when multiple clients are connected, handling the requests one by one. This may simplify the tunnel vendor’s code, but it can produce unacceptable application behavior. If one client makes a time-consuming request via the tunnel, then other clients must line up and wait until that request completes before their own requests will be serviced. All clients block for the duration of the longest request by any client, reducing system performance and increasing latency dramatically.

Keeping all OPC transactions local: This situation simply does not happen. The OPC transactions do not cross the network, so they are not subject to network effects nor to serialization across the tunnel.

The OPC DataHub uses the local OPC transaction approach.