OPC DataHub™ :  Version 6.4
Prev Chapter 19. Properties Window Next

19.3. Tunnel/Mirror

This option in the Properties Window lets you set up the OPC DataHub to act as a master or slave for tunnelling. Tunnelling allows you to send OPC data across a network without the security and time-out issues associated with using DCOM. Tunnelling is done over TCP, which provides connectivity across a network or over the Internet.

Tunnelling and Mirroring

The OPC DataHub tunnelling connection is sometimes referred to as a mirroring connection. Mirroring means that the data and any updates to that data on one DataHub are exactly mirrored across the network onto the other DataHub, and vice-versa. For all practical purposes, tunnelling and mirroring are identical. People working with OPC tend to use the term "tunnelling" while people from other backgrounds often say "mirroring". So Cogent uses "tunnelling" for the OPC DataHub, and "mirroring" for other Cogent products. For example, the OPC DataHub can tunnel (mirror) data to the Cascade DataHub running in the Linux or QNX operating systems. Please refer to the Mirroring Data section of the Cascade DataHub for Linux and QNX manual for details about those operating systems.

Direct TCP connections

In addition to tunnelling, the OPC DataHub can accept direct connections from any TCP client using the DataHub APIs for C++, Java, and .NET, such as DataSim or other, custom applications.

Master and Slave

We identify the two tunnelling DataHubs as master and slave. The only difference between the master DataHub and slave DataHub is that the slave initiates the connection. Once the connection is established, they function exactly the same. It is possible for a DataHub to be both tunnelling slave and master simultaneously—acting as a slave to one or more DataHubs and a master to one or more others. For slave mode you need to specify each master.

Tunnelling Master

You can configure your DataHub to act as a master for either plain-text tunnelling, secure tunnelling using SSL, or both. Each mode uses a separate port number or service name.

[Important]

If you enter a name for the service/port instead of a number, that name must be listed in the Windows services file. Please refer to The Windows Services file Appendix for details.

The DataHub installs an SSL Certificate for you. If you wish to move it or use a different one, you can change the directory path here. The SSL implementation uses the default SSL-3 encryption cipher: DHE-RSA-AES256-SHA. This is a 256-bit encryption. The server and client negotiate the best encryption based on what both can support. The DataHub does not validate the SSL certificate with any outside certificate authority. It uses the SSL connection for encryption only, not authentication.

You can also configure the master to attempt to send "old" data (superseded by more recent data). Check any or all of Boolean, Integer, Float, or String that apply to the kind of superseded data that you wish to have sent.

[Note]

To optimize throughput using this option, please refer to Section 18.7, “How to Optimize”.

Tunnelling Slave

Check the Act as a tunnelling/mirror slave to these masters box to have the OPC DataHub act as a slave.

To add a master for this mode, click the Add Master... button. To edit a master, double-click it, or select it and press the Edit... button. Either button opens the Tunnel/Mirror Master window:

Type in the following information:

Primary/Secondary Host

The name or IP address of the host computer. This slave DataHub will alternate attempts to connect first on the primary host, then on the secondary host, back and forth until a connection is made. The secondary host is optional, and if not entered, all attempts to reconnect will be on the primary host. If the connection is interrupted, the DataHub will again alternate attempts at reconnection on the primary and secondary hosts.

Port

The port number or service name as entered in the Master service/port entry box of the master on the remote computer.

Secure (SSL)

You can establish a secure connection using SSL tunnelling as long as the tunnelling master DataHub you are attempting to connect to has been configured for secure connections. (See above.)

Local data domain

The local OPC DataHub data domain for this slave. It is common, but not necessary, to create or use an existing local data domain that has the same name as the remote data domain.

Remote data domain

The name of the remote Cascade DataHub data domain, which is the tunnelling master. Point names will be mapped from that data domain into the local data domain, and vice versa.

Remote user name

The user name for TCP security, established on the tunnelling master, using the DataHub Security option in the Properties window.

Remote passwork

The password for TCP security, established on the tunnelling master, using the DataHub Security option in the Properties window.

[Note]

There is a DataHub running on Cogent's server that you can connect to for testing. Here are the parameters you will need to enter for it:

    Primary Host: developers.cogentrts.com

    Port: 4600

    Local data domain: test

    Remote data domain: test

You now have several options for the mirrored connection.

  1. Data Flow Direction lets you determine which way the data flows. The default is read-only data flow from master to slave, but you can set up a read-write or write-only connection by choosing those options.
    [Note]

    To optimize throughput, check the Read-only: Receive data from the Master, but do not send option. Only do this if you actually want a read-only connection. If you do not require read-write access, a read-only tunnel will be faster.

  2. When the connection is initiated determines how the values from the points are assigned when the slave first connects to the master. There three possibilities: the slave gets all values from the master (the default), the slave sends all its values to the master, or the data from master and slave gets synchronized. The availability of these options depends on the data flow direction selected above.
  3. When the connection is lost determines where to display the data quality as "Not Connected", on the master, on the slave, or neither.
    [Note]

    If you have configured When the connection is initiated as Synchronize based on time stamp (see above), then this option must be set to Do not modify the data quality here or on the Master to get correct data synchronization.

  4. Connection Properties gives you these options:

      Replace incoming timestamp... lets you use local time on timestamps. This is useful if the source of the data either does not generate time stamps, or you do not trust the clock on the data source.

      Transmit point changes in binary gives users of x86 CPUs a way to speed up the data transfer rate. Selecting this option can improve maximum throughput by up to 50%, depending on the type of data being transmitted. This option uses a more efficient message encoding scheme than the default ASCII encoding, but it will only work if both sides of the tunnel are running on an x86 architecture CPU. This would be typical of Windows communicating with Linux or QNX, or with another Windows computer. Numeric data benefits most from this option.

      Target is a Cogent Embedded Toolkit server allows this slave to connect to an Embedded Toolkit server rather than to another DataHub.

      Heartbeat sends a heartbeat message to the master every number of milliseconds specified here, to verify that the connection is up. Setting this value to 0 stops the heartbeat from being transmitted.

      Timeout specifies the timeout period for the heartbeat. If the slave DataHub doesn't receive a response from the master within this timeout, it drops the connection. You must set the timeout time to at least twice the heartbeat time. Setting this value to 0 will cause the DataHub to rely on the TCP implementation for detecting a broken connetion. This can be useful when your network connection is very slow. Please refer to Section 18.2, “Tunnel/Mirror (TCP) Connections for Slow Networks” for details.

      Retry specifies a number of milliseconds to wait before attempting to reconnect a broken connection.

Prev Up Next
19.2. OPC Home 19.4. Bridging

Copyright © 1995-2010 by Cogent Real-Time Systems, Inc. All rights reserved.