OPC UA: An End-User's Perspective

OPC UA (Unified Architecture) represents the OPC Foundation’s most recent set of specifications for Process Control and Automation system interconnectivity. This paper explains OPC UA from the perspective of the organization that will benefit from the connectivity, in other words: the End User.

The first form of OPC relied on DCOM for its data transportation, which was very powerful and versatile, but posed a problem for those who did not understand how to configure DCOM. Instead of DCOM, OPC UA relies on Web Services for its data transportation. OPC UA also uses objects to help with data description. Even though these are major additions and modification to OPC, OPC UA will be backwards compatible with older products through the use of wrappers. All this will ensure that OPC UA will be even better suited to penetrate the entire plant enterprise. Of course, with all the new connectivity that OPC UA offers, the new challenge will be system security.

1. OPC Overview

OPC is an industrial communication standard that enables manufacturers to use data to optimize production, make operation decisions quickly and generate reports. OPC enables plants to automate the transfer of data from a control system (PLC, DCS, analyzer, etc) to an industrial software application (HMI, Historian, Production system, Management system, etc). OPC is typically found in Level 3 networks and higher. Thus, OPC transfers process control data between the Control (Level 2) network and the Operations/Manufacturing (Level 3) network. It also exchanges data between the Operations/Manufacturing network and the Business (Level 4) network. In essence, OPC is the Modbus of the new century. It is not a replacement for low-level communication standards such as 4-20mA, Hart, Profibus, or Foundation Fieldbus. Rather, organizations use OPC in high-level communication.

Note: OPC is no longer an acronym. When OPC first released in 1996 it was an acronym for OLE for Process Control, and was restricted to the Windows operating system. OPC is now available on other operating systems and enjoys significant adoption outside of process control. So, the original name (OLE for Process Control) is no longer appropriate and OPC changed from an acronym to a word. Thus, OPC no longer stands for anything (OPC is just OPC).

Image 1: OPC communication enables applications to interoperate and simplifies system architecture.

2. OPC communication started with DCOM

When OPC first released in 1996, with OPC Data Access 1.0 (OPC DA 1.0) specification, it used Microsoft’s DCOM as the data transportation mechanism. Data moved between OPC applications on different computers using DCOM. At the time, DCOM was an outstanding choice because it provided a working communication infrastructure complete with all the necessary security services (authentication, authorization, and encryption). Thousands of vendors were already using DCOM because it was a relatively versatile API (Application Programming Interface). DCOM was a clear winner at the time, but while it provided a reliable communication backbone for OPC, it did have several challenges.

First, DCOM configuration eludes Automation personnel who do not take time to learn it. DCOM is actually very predictable and is not difficult to configure. While there are training classes that explain DCOM configuration in detail, most people do not take the time to learn it and so DCOM’s behavior frustrates them. Consequently, Automation personnel needlessly experience problems when connecting two computers and configuring firewalls. Nevertheless, knowledgeable users can easily configure DCOM in a matter of minutes.

Second, many programmers assume that network communication will occur without any data loss. This assumption leads them to create products that are highly susceptible to data loss and communication timeouts. As a result, End-Users might sometimes experience a delay in application responses and complain to their vendors. However, since the programmers fail to understand DCOM’s behavior, they often incorrectly blame DCOM for poor application behavior, which further promotes the false myth that DCOM is unreliable. Again, informed programmers are easily able to compensate for data loss and are able to make DCOM work reliably, and in a way that End-Users would expect.

The third problem is DCOM does not work through NAT (Network Address Translation). Thus, DCOM does not work in the rare cases that communication must occur between two private networks that are separated by a public network. Such is the case when two plants attempt communication over the Internet. NAT is sometimes used inside industrial facilities, but this is often unnecessary as a firewall would suffice.

The fourth problem is DCOM is proprietary to Microsoft. This makes OPC difficult (to impossible) for vendors to port to non-Windows operating systems. While some vendors are able to embed Windows directly on their own controller (PLC, DCS, analyzer, etc) hardware, others are unable to do this. Also, companies that use non-Windows operating systems (UNIX/Linux, VMS, etc) are having a difficult time importing OPC data into their applications.

Image 2: OPC initially relied on DCOM for data transportation. DCOM is a highly secure and fast API from Microsoft that provides applications with services for authentication, authorization, and encryption.

3. OPC UA uses Web Services

OPC UA uses Web Services instead of DCOM for data transportation. This is the change that most End-Users will notice immediately. Two of the biggest advantages for Web Services are ease of communication between networks and independence from specific operating systems. The challenge for the plant itself will be the implementation of security to keep the data safe.

Perhaps the biggest technical advantage for Web Services is that they enable OPC to communicate over a single port using a protocol that most firewalls will allow to pass by default. This should make it easier for Integrators to setup a system for communication between networks. Many firewalls are already configured to let web traffic pass across port 80. This will make it easier for IT to open the ports necessary to implement OPC communication. Previously, DCOM required multiple ports to establish communication. While this was possible to configure, a significant portion of automation personnel did not take the time to learn how to do it. Nevertheless, opening port 80 opens communication for a plethora of applications (not just those that are needed for Operations), so emphasis on security will be required immediately.

In addition, Web Services are not bound to any specific operating system. Thus, vendors will have an easier time implementing OPC Servers on their automation hardware and non-Windows operating systems. Vendors are already working on PLCs that include an embedded native OPC Server that does not require an external computer. However, this implementation might not be as simple as it seems because an automation application (HMI, Historian, APC, etc) typically requires a PC anyway. Nevertheless, it would be possible to have a PLC communicate with a software application using OPC without requiring an intermediate computer that uses Windows.

Part 1 : Part 2

Randy Kondor, President, OPC Training Institute, has more than 15 years of leadership experience building global OPC and security awareness and acceptance. An accomplished engineer, his vision and capable expertise have been a driving force in making the OPC Training Institute the world's largest OPC training company. Randy's success is due to the priority he has placed on educating industry about OPC standards. Education continues to be his focus today. His significant impact in the industry continues to be felt as ....... See Details....