Why OPC UA Matters
Overview
OPC is a standard interface to communicate between numerous data sources, including devices on a factory floor, laboratory equipment, test system fixtures, and databases. The OPC Foundation defined a set of standard interfaces that allow any client to access any OPC-compatible device using a protocol now referred to as OPC Classic. This protocol uses the Microsoft-based COM/DCOM technology to provide standard specifications for data access (DA), historical data access (HDA), and alarms and events (A&E). Although basing a protocol on this technology made sense in the 1990s, OPC Classic has several limitations because of this reliance on the Microsoft Windows platform, in the form of security issues and platform dependency.
OPC Unified Architecture (UA) is a communication technology standard that was first released by the OPC Foundation in 2006 as an improvement on its predecessor, OPC Classic. OPC UA includes all the functionality found in OPC Classic. This is done by bringing together the different specifications of OPC Classic into a single entry point to a system offering current DA and A&E, combined with the history of both.
Furthermore, OPC UA is based on a cross-platform, business-optimized Service-Oriented Architecture (SOA), which expands on the security and functionality found in OPC Classic instead of the Microsoft-based COM/DCOM technology. OPC UA supports two protocols: a binary protocol that employs minimal resources, allowing for easy enablement through a firewall, and a web service protocol (SOAP) that uses standard HTTP/HTTPS ports. Because of the benefits of this new protocol, more and more industrial applications have adopted the UA protocol both in the traditional OPC-centric industrial automation space and emerging areas such as energy.
Contents
- Cross-Platform Capabilities
- Expanded Security
- IT Integration
- Compatibility
- Applications
- Conclusion
- Additional Resources
Cross-Platform Capabilities
OPC Classic requires a Microsoft Windows OS to implement COM/DCOM server functionality. By using an SOA and web services, OPC UA is a platform-independent system that eliminates the previous dependency on a Windows OS. By using SOAP/XML over HTTP, OPC UA can deploy on a variety of embedded systems regardless of whether the system is a general-purpose OS, such as Windows, or a deterministic real-time OS.
Figure 1: OPC UA bypasses the need for a Windows-based component and can communicate directly with embedded OPC UA servers on PLCs.
Because of the benefits of OPC UA, National Instruments has chosen to integrate the creation of OPC UA clients and servers communication into two NI LabVIEW add-on modules. For Because of the benefits of OPC UA, National Instruments has chosen to integrate the creation of OPC UA clients and servers communication into LabVIEW through the LabVIEW OPC UA Toolkit. The LabVIEW OPC UA Toolkit is an API for the creation of OPC UA servers and clients for both Windows and Real-Time operating systems. This API includes support for the Data Access facet of the protocol as well as two additional facets: Historical Access (HA) and Alarms and Conditions (AC). The Historical Access facet allows the creation, retrieving, updating, and deleting of archived data and annotations. The Alarms and Conditions facet allows the definition, management, and acknowledgement of state driven notifications that require interaction with an operator or user such as infringement of safety limits, maintenance service, or confirmation of steps in a process.
Expanded Security
One of the most important benefits of eliminating the reliance on COM/DCOM technology is the expanded security features. Classic OPC systems rely on difficult and complex configuration of DCOM to provide inter-process security. Too commonly, vendors overlook this step in testing stages, which resulted in to difficult configuration for users. This often leads to security being disabled all together and thus, large security gaps in the network. In Classic OPC, developers must use Access Control lists stored in DCOM settings to configure the security settings for each component. In contrast, OPC UA uses standard web technologies as a security foundation including both authentication and encryption capabilities to protect data.
Figure 2: PC UA requires handshaking between clients and servers using X.509 Web standard certificates for authentication before they are able to talk with one another.
In Figure 2, OPC UA servers and clients rely on unique certificates to communicate with one another. OPC UA supports PKCS12 Public-Key Cryptography Standards to provide the X.509 private keys and certificate files that contain public keys. Both server and client can select which pair of public keys and private keys to use. To communicate between the server and client, the user can choose from three kinds of messaging modes: None, Sign, Sign and Encrypt. Additionally, the user can enable one of the two security policies: Basic256 and Basic128Rsa15. These security policies are the bases for the algorithm to sign or encrypt the data between the client and server.
IT Integration
As a direct result of the standardized security model, OPC UA allows for easy integration into pre-existing IT networks which limits configuration costs. OPC UA can communicate through any standard HTTP or UA TCP port. Through this standardization, OPC UA can connect securely over a VPN and through firewalls to allow seamless, remote client-to-server connectivity. As previously mentioned, OPC UA also implements standard network protocols including authentication with certification and data encryption.
Compatibility
Because of the shift in data communication technology, the OPC UA protocol is not inherently backwards compatible with Classic OPC data access (DA) models. OPC DA servers require a UA Wrapper to access UA client applications. Additionally, to access UA servers, OPC DA clients need a UA Proxy which is a DCOM EXE Server that connects to UA servers by creating COM pseudo-servers.
Figure 3: Classic OPC COM-based Clients require a UA Proxy to communicate with UA Servers.
Figure 4: Classic OPC COM-based Servers require UA Wrappers to interact with UA Clients.
One solution to bridge DA and UA is NI OPC Servers 2012 and later. NI OPC Servers provides an OPC UA Client Driver that can be republished through an OPC DA Server to connect to an NI OPC DA Client. In addition, NI OPC Servers includes an OPC DA client driver that can be republished through an OPC UA server to connect to an NI OPC UA Server.
Applications
OPC UA can be used for supervisory control, now eliminating the use of Windows-based intermediate systems to streamline the data transfer process from the field and control levels vertically to the management and enterprise levels.
Figure 5: OPC UA Serving Information Transport in Traditional Supervisory Control
However, OPC UA is also suitable for M2M communications between multiple controllers from different vendors at the control level. This allows for a common language between controlling devices and sensors to communicate data in a secure and reliable way between systems and subsystems in smart machine applications.
Figure 6: OPC UA Enabling M2M Communications in Smart Machines
Conclusion
OPC UA extends the functionalities of the original OPC model, Classic OPC, by improving upon security and migrating to a platform-independent implementation based on standard web technologies. The improvements of OPC UA overcome many of the challenges with Classic OPC, and will help to drive the adoption of this open industry standard further in the Industrial Automation area as well as other application areas that require a standard, open, and secure communication interface.