OPC continues to be the standard of choice for interoperability between software and hardware in the multi-vendor real world, with wide adoption of OPC DA Classic still in the majority compared to OPC UA. Accessing remote OPC Classic data sources (i.e. OPC clients and servers are on separate machines and, sometimes, even networks) can be challenging due to a reliance on Microsoft DCOM technology for security and authentication on remote OPC connections.
Anyone who has ever heard of or dealt with configuring DCOM security for remote OPC connections knows it has its challenges. The good news is that there is an alternative to DCOM for remote OPC Classic connectivity - a solution referred to as OPC tunneling. In the blog post, we'll discuss five of the key considerations to remember as you're evaluating the best OPC tunneling solution for your projects.
For applications requiring remote OPC Classic connectivity, the use of an OPC tunneler can reduce your security risk, improve the resiliency of your automation systems, and reduce your integration and startup costs. And when you're evaluating software applications to handle the tunneling of your data, there is more to making the choice than a checkbox that says “tunneling”.
What is OPC Tunneling?
In case you haven't dealt with OPC tunneling before, let's do a quick refresh of what tunneling is. First, we need to distinguish tunneling in this context from other usages of the term tunneling such as VPN tunnels. Tunneling of OPC data does NOT require the use of a VPN. You can certainly use a tunneling application inside a VPN, but it’s not required.
To explain what tunneling of OPC data is we need to first understand how OPC data is exchanged between an OPC server and OPC client.
To transfer OPC data from an OPC server to an OPC client, a Windows technology called COM is used. Your HMI, SCADA, MES, historian or other software used in your operations would be an example of an OPC client.
The OPC server is the driver that is talking to your control hardware such as PLCs, DCS, or other control systems. For applications where multiple clients need data from the devices, OPC server software is commonly installed on a separate computer to gain efficiencies in communication by eliminating redundant requests from multiple clients to the control hardware for the same data.
In that scenario, since the server and client are not on the same computer, Distributed COM or DCOM is used to manage security and authentication between the machines. The problem with DCOM is that it is notoriously hard to configure and when it does work it can leave an attack surface open on your OPC computers depending on how it has been configured.
Tunneling of OPC data was created as an easier, more secure alternative to DCOM for remote OPC connections. The word tunnel, as it relates to the use of the OPC standard for software-to-software data exchange has a specific meaning and application, as outlined in the following four items:
-
An OPC tunnel is designed to connect software applications and securely move data from many different sources, most typically moving data that originates in an OPC server software application, and is intended to be consumed in an OPC client software application. Operations technology users refer to this as “reading data”.
-
OPC tunnels can also move data from OPC client software to OPC server software. Operations technology users refer to this as “writing data”.
-
An OPC tunnel is designed to eliminate the issues associated with the use of DCOM technology in connecting OPC clients and servers that are not on the same computer.
-
An OPC tunnel is for use in any situation where you need to connect applications on different computer, not just for situations where the computers are at totally different physical locations in the business or “remote”.
Now that we've reviewed the "what" of OPC tunneling, you may be nodding to yourself and considering how tunneling could make your life easier (especially if you're remembering the last time you struggled with configuring DCOM). To give you some insights into the sorts of questions you should be asking when looking at a tunneling solution, let's look at five of the key considerations.
1. How long does it take to setup and configure the tunneler?
You'll want to consider the engineering resources that will be used to setup, configure and maintain your software over its lifetime. Supplier videos that walk you through the tunneler configuration are an easy way to determine ease–of–use.
If you are “hands-on”, download a copy of the demo (there should be a free trial/demo version available for evaluation) and take it for a test drive connecting to your own OPC systems. Additionally, a knowledgeable and responsive supplier will also provide helpful phone support before you’ve bought a product, without making you wait to have questions answered.
2. OPC Spec Support: Can the tunneler tunnel OPC UA and DA Data and Convert between OPC interface types?
You'll need to determine which OPC specifications your clients and servers support and then have a conversation with the potential supplier to ensure they will support all of your requirements. What OPC specifications does the OPC tunneler support?
Almost anytime someone says they need OPC, they actually need OPC Data Access (OPC DA). OPC DA has 3 major versions 1.0, 2.05 and 3.0. Make sure your OPC tunnel supports the version of OPC DA that your servers and clients support. OPC UA is the newest OPC specification and the adoption of UA is growing. If you have an OPC server that is OPC DA and a client that is OPC UA, will the tunneler support this and convert between the two specifications?
3. Can a tunneler work with another supplier’s OPC application?
If your automation software supplier claims they handle remote OPC connectivity without DCOM, ask them for clarity on specifically how they accomplish this. Some suppliers of industrial automation software include a remote connector software stub that is placed on a remote computer running OPC and they use their own protocol to retrieve the data to their application. It’s common for such remote OPC connectivity to be proprietary in nature and to only be supported between that specific supplier’s applications. As such, the tunneler is less flexible than one that can work with any OPC application.
Now, if you stay with one supplier for all your software, this is fine. However, most users have more than one automation software supplier over the course of time. If, for example, you have three different software applications and they all offer their own proprietary tunneling, and they need to connect to your OPC Server data sources, then you will have three tunnels to configure, maintain and secure. That means three times the traffic, three things to learn, and three things to worry about.
Ask your supplier if the tunneler tunnels data from any OPC server to any OPC client, or if they only support tunneling between their own software applications and OPC data sources. Choosing a tunneler that supports any supplier’s OPC solutions will lower your training costs, risks, and network bandwidth usage, ensuring that you'll be able to take full advantage of your investment in OPC technology and not getting locked into a single supplier for all your needs.
4. Does the tunneler just move data or does it also move the entire OPC function call?
Consider the setup of a train. There's a locomotive, cars, and cargo. When a tunneler passes an entire OPC command across your network, it’s sending the entire train, when all you care about is the cargo. Tunnelers that move the entire OPC command and the data are simply not as efficient as one that only tunnels the data with as little extra infrastructure as needed to carry the data.
An effective tunneler passes data only on data change events. Why move the entire train when you can move only the cargo in a lightweight package? This metaphor suggests moving contents of train cars without a train; in reality, the idea is that if you only need the data, use an express bullet train, not a lumbering freight train.
Tunnelers that only tunnel the calls also typically do not have a means to restrict what data is exposed from the OPC server over the tunnel. An effective tunneler will have the option to either expose all the tags in an OPC server, or only the tags that you want exposed. Only exposing what you need also increases the speed of OPC client configuration, because item discovery and browse operations on the OPC client occur faster with smaller data sets.
5. How is security handled?
Security is integral to consideration of a tunneling solution, and is an important feature of the product. You'll want the ability to encrypt the data being sent over the network using the highest level of SSL encryption available for the combination of operating systems that you are using. This will avoid data being sent in a plain text readable format over the network.
If you want even greater security and have a WAN between your sites that is already secured by a VPN, the tunneler should be able to run inside that VPN tunnel as well. A tunneler may also offer the ability to binary encode the data before it is SSL encrypted, which adds yet another layer of protection.
Choosing an effective tunneler that takes into account your application requirements will make a difference in your operational effectiveness, resiliency, and profitability. The above is only a few of the possible considerations when choosing. Learn more about the limitations of DCOM and many of the other considerations when choosing a tunneler in the free whitepaper “25 Considerations when choosing a tunneling application”.
