In today’s industrial operations environments, OPC is the standard of choice for interoperability between software and hardware in the multi-vendor real world. Major software applications that need data from other systems have implemented OPC client interfaces. Those same applications if they need to share data with others, have also implemented OPC server interfaces. Similarly, the OPC standard has allowed software vendors to write applications, called OPC Servers, which make it easy to access real-time data from any piece of equipment offered by any vendor.
Since 1995, the OPC Foundation estimates that over 30 million OPC server and client software applications have been deployed in operations management from the shop floor up through production and operations management layers. The result is that data from the factory floor is more available now than ever before.
The greater availability of data has generated greater demand for access to the data across a wider number of locations and users. However, getting that data from the factory floor to your systems and staff to monitor and act upon it has challenges.
The challenges of moving operational data where the business needs it are not limited to, but are in large part a result of the limitations of DCOM; the networking protocol used by the significant installed base of OPC applications. There are four key limitations of DCOM, translating into four specific reasons to move to a Tunnel for OPC data.
- Configuring & supporting DCOM is difficult & costly
- DCOM lacks reliability, resilience, and efficiency
- DCOM notification is delayed on a network break
- Security of your data and network
What is a Tunnel?
To appreciate the challenges of DCOM 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 software used in your operations is an example of an OPC client. The OPC server is the driver that is talking to your PLCs, DCS, or other control systems. In applications where multiple clients need data from the controllers, the OPC server software is typically put on a separate computer to gain efficiencies in communication by not having multiple clients asking the control hardware for the same data repeatedly. When the OPC server and OPC client are not on the same computer then Distributed COM or DCOM is used.
OPC tunneling 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.
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”. Conversely, “writing data” is when an OPC client application wants to send data to an OPC server. For example, changing machine operating set points involves writing data.
An OPC tunnel eliminates the issues associated with the use of DCOM. Learn more about the limitations of DCOM, how to calculate what using it is costing your business, and how a tunneler overcomes DCOM’s limitations in the free whitepaper “Four reasons to use tunneling for OPC data integration”.