call: 1-780-784-4444
|
email:
call: 1-780-784-4444 |
| You are here: Home > Downloads & Resources > Reviews > OPC Data Logger by Software Toolbox | |
OPC Tunnel by Softing AGProduct Review
Overall Rating:
By Mark Hamblin
OverviewMany people familiar with, or new to, OPC will attest that configuring the DCOM security settings can be a major hassle - one they would happily to do without. For those of you not familiar with DCOM (and without getting into a lot of detail), it's a Microsoft Windows technology broadly used to communicate between processes on either local or remote computers. OPC uses DCOM to communicate between clients and servers. Unfortunately, DCOM was originally intended for business applications, and is not the best technology to use for "high speed" real-time communication. In addition to the security configuration issues, DCOM also does not operate well on unreliable networks, generates additional data overhead, and requires specific firewall ports to be opened. To say the least, none of these issues are especially appealing to network or system administrators. Luckily, there is an alternative to using DCOM for OPC called a "tunnel", such as Softing's very good OPC Easy Connect OPC Tunnel product. The "tunnel" converts data retrieved from an OPC server into a proprietary TCP/IP packet and ships it across the network without the overhead of DCOM. On the client side, it unpacks the data and turns it back into "OPC" (Figure 1).
In some cases DCOM configuration may be required for the communication between tunnel and OPC client or server, but this is generally easier to do than setting up permissions for access across the network.
InstallationSofting's OPC Tunnel is actually part of their comprehensive middleware product called OPC Easy Connect (OCT). This review focuses on the OPC Tunnel portion of the middleware only. Softing offers a fully-functional demo version for download that expires after 90 minutes. The demo comes with a good "Getting Started" guide and is a great way to investigate what the product has to offer. Since OPC Tunnel is intended to replace communication between the client(s) and server(s) on remote machines, it must be installed on both the client and server machines. For this review, I used two Dell Latitude D620s on a domain, each running a VMWare virtual machine on a workgroup. All machines were running Windows XP Pro. Installation is a fairly simple process - the installation program lets you select which demo applications you'd like to install, and automatically detects and installs missing OPC components (figure 2).
If you accept the default selections, the install wizard will install OPC Easy Connect and a few other demo applications on the start menu (figure 3).
UninstallingIt's important to be able to remove demo versions of applications from test machines without leaving a trace of the original installation. The OCT uninstall applications do a pretty good job of removing the software, so you should have no concerns installing the demos to try them out. The only minor drawback is the uninstall applications must be run individually - there's no consolidated uninstall application (figure 4).
Configuring OPC TunnelTo set up the tunnel, you run the OCT "Configurator" application from the start menu (figure 5).
The easiest way to get up and running quickly is to use the File->"Wizard 'New Project'..." menu. This launches the "New Project Wizard" (figure 6):
OPC Tunnel is part of a larger suite of middleware products from Softing, all contained in a single environment. We'll be focusing only on the tunnel portion of the configuration, but the Getting Started guide has good information on getting the other options running. The wizard is fairly simple to use and walks you through the basic configuration for the tunnel. I find it best to start with the configuration of the server side of the tunnel connection first. The difference between the server side and client side is what you connect to. On the server side, you need to connect to the OPC server you actually want the data from. On the client side, you'll be connecting to the tunnel that you configure on the server. After the basics (like IP addresses) are set up (I just accepted all the defaults), the wizard does a good job of letting you choose the server you want to connect to. OPC Tunnel does not support Historical Data Access (HDA), so you're limited to Data Access (DA) and Alarm & Events (A&E) servers. You can connect to multiple OPC servers and give each a unique item prefix that will help differentiate the source on the client side, or you can choose not to prefix items. You can also control what items are available from the server by specifying a static list, dynamic access (usually the best bet), or "startup" (which loads all items at startup). Once you're done in the wizard, there are a number of other options you can configure, such as diagnostics, security, connection optimizations, and other middleware functions. It would be nice if some of these, especially security, were configurable from the wizard. Another issue is that you can't use the wizard to edit your existing configuration - you'll have to either start from scratch or locate the parameter you want to change in the Configurator attribute lists. It took less than 10 minutes to set up both the server and client side of the tunnel and get a successful test connection to the tunnel server. I used the Softing OPC Toolbox Demo Client to test the tunnel connection, and everything worked seamlessly, without having to touch DCOM settings once (figure 7).
SecurityAfter the basic communication was running, I added some security to the connection. The OPC Tunnel allows you to create a username(s) and password(s) on the server that must be specified by the client when it connects. You configure the client-side username and password on a connection-by-connection basis. The usernames and passwords are stored in the XML configuration file, with the password encrypted. I did no evaluation on how well the password was encrypted or transmitted to the server, but I expect for the vast majority of organizations the security would be sufficient. For intranets and VPN connections, the additional security may not be warranted anyway. Not having used OPC Tunnel before, I found the security set-up taking longer than I would have liked. Once I understood it though, I could easily make changes. The first step in setting up security is to tell the server that clients must authenticate, and then set up user accounts. (It would be nice if there were options for integrated NTLM or Active Directory users rather than always having to create and manage a separate user database). The second step is to set the username and password on the client to match one of the users configured on the server. The frustration begins when you try to test your changes. The first issue is the connection testing capability ("Connect" button in the Configurator) always fails the connection when there's security set up. So you think everything's set up properly, but the connection appears to be failing. Also, anytime a change is made to users or passwords, you almost always need to restart both the client and server tunnel applications. If you're aware of these limitations ahead of time, setting up the security is fairly quick and easy. Once security was set up, it worked well (other than restarting the service), always blocking requests if the usernames or passwords did not match.
OPC Tunnel versus DCOMThe three primary reasons why you might want to use OPC Tunnel are:
DCOM SecurityI tested data access from a domain to a workgroup, and within a workgroup with both matching and different usernames and passwords. In many of these scenarios, direct OPC communication via DCOM simply did not work without adjusting DCOM settings. OPC Tunnel worked every time, with no additional configuration required. This is a clear advantage for OPC Tunnel, and will likely save many administrators a great deal of time.
BandwidthDCOM adds a fair amount of overhead to the raw data being transmitted. Because OPC Tunnel adds as little overhead as possible, it uses significantly less bandwidth. I used Windows' Performance Monitor (perfmon) to evaluate bandwidth usage for 31 items in the "increment" branch of Softing's demo OPC server, for both standard OPC/DCOM and OPC Tunnel. The graphs below show the total bytes (scale is in KB) transmitted for standard OPC and for OPC Tunnel. OPC Tunnel used, on average, about 50% of the bandwidth required for standard OPC (figure 8).
ReliabilityHow a client application reacts to a broken DCOM connection is highly dependent on how the client was designed and built. Since the OPC Tunnel is in charge of the communication, it isolates the job of dealing with network communication failures from the client. For this test, I simply disabled network communication between the client and server for both short and long periods, and evaluated how several different clients reacted with DCOM versus OPC Tunnel. A few seconds after disabling network communication, all clients connected to the OPC Tunnel client registered bad statuses for items. When the network was re-enabled, all clients quickly recovered and started displaying valid data. When connected to the remote machine via DCOM, it was a mixed bag. The Softing OPC Toolbox Demo Client did remarkably well, and recovered almost immediately when network connectivity was restored. One of the other (widely used) test clients did not register the network failure at all, even after waiting 10 minutes, and actually crashed completely when the connection was restored. The other test client registered the communication failure, but did not recover automatically when the connection was restored. With DCOM, your particular clients (HMIs historians, etc.) may react completely differently to network issues than the test clients I used. The beauty of using OPC Tunnel is that all certified OPC clients will behave the same way. One note, though: even though OPC Tunnel recovers nicely from communication failures, all data available at the server during the failure will be lost. If data loss is not acceptable, you need to make sure your OPC system design accounts for the possibility of network failure independently of OPC Tunnel or DCOM.
SummaryOPC Tunnel does a good job of replacing, and improving upon aspects, of DCOM communication for OPC. For those of you who have spent hours or even days trying to configure DCOM, you will definitely appreciate OPC Tunnel. The product is easy to install and configure. OPC Tunnel also supports bi-directional communication. I didn’t test this feature but Softing’s documentation outlines how to configure OPC Tunnel to work with OPC servers and clients installed on the same machine. I'd highly recommend you take OPC Tunnel for a test drive if you've ever had, or want to avoid, DCOM configuration or network-generated data issues.
For the purposes of this review, the following product version was used:
Vendor Recommended Specifications for OPC Tunnel:
Required Processor (CPU) Class: minimum Pentium 4 (WinCE: x86, XScale) Required Processor Speed: minimum 400 MHz Required Disk Space: 24 MB (WinCE: 1,6 MB) Required Memory (RAM): OS dependent (WinXP: 256MB) (WinCE: 16MB) Recommended Memory (RAM): OS dependent (WinXP: 512MB) (WinCE: 32MB)
Software Specifications: The following computer hardware was used for the review of OPC Tunnel:
Dell Latitude D620 Windows XP Professional This review is published by the OPC Training Institute. Copyright ©2008 OPC Training Institute (OPCTI). All rights reserved. The information contained in this review is proprietary to OPCTI. No part of this review may be reproduced, stored in a retrieval system, translated, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from OPCTI. |
| You are here: Home > Downloads & Resources > Reviews > OPC Data Logger by Software Toolbox |
