Log in
  
Home > Networking & Communications > Industrial Networking
Related topics: Industrial Networking,Automotive, Electronics & Computers, Feature, Industrial Automation, Intelligent Systems, Machine Manufacturing, Manufacturing Automation, Networking & Communications, Process Automation, Process Industries, Sensors Mag, Software, Standards & Protocols, Technologies in Depth
Industrial Networking

Meet the Next Generation of OPC

July 1, 2008 By: Tony Paine Sensors

Introduced in 1995, OPC enabled interoperability between Windows-based applications and process control hardware and software. The latest OPC specification, OPC-UA, seeks to improve and unify the earlier specifications into a single coherent foundation.


A new generation of OPC, known as OPC-UA, is upon us, unifying the multiple specifications of the past and redefining the acronym of OPC, formerly OLE for Process Control, to OPC-UA (OPen Connectivity-Unified Architecture). As often happens the second time around, this latest generation of OPC-UA delivers solutions to problems of the past, adds significant new capabilities, and provides a foundation for future developments.

OPC: Then and Now
OPC delivers a standard interface designed to meet the needs of automation, enabling applications from different vendors to exchange information. By using OPC as a common interface, you can choose from a variety of products, assembling them to meet the needs of your specific application.

The first generation of OPC developed primarily into three distinct specifications: OPC-DA, designed for real-time data access; OPC-A&E, designed for alarm and event message access; and OPC-HDA, designed for historian data access. Developers of data acquisition products could pick and choose from these specifications and implement the most suitable OPC functionality. Because most of the automation world revolves around real-time data access, OPC-DA became the most widely supported specification followed by OPC-A&E and, finally, by OPC-HDA.

One of the first goals of OPC-UA was to drive broad and consistent implementation for all data access when possible. For example, although communication drivers may focus on real-time communications, they also generate status and error messages. Built-in support for the alarm and event portion of the specifications would allow access to data—and all related status messages—through one interface. The same can be said for historic data access. Few real-time communication devices need HDA support. There is, however, a class of device called a remote terminal unit (RTU) that typically offers all three forms of data: real-time data access, alarm and event messages, and historic data access. OPC-UA can facilitate one interface for these various data types where three were required in the past.

The OPC of 1995 leveraged Microsoft's OLE (Object Linking and Embedding) technology to enable application-to-application communications in Microsoft operating systems. This also involved technologies called COM (Component Object Model) and, when talking from one computer to another over a network, DCOM (Distributed Component Object Model). This picture is very Microsoft-centric and, while it is true that Microsoft dominates most of the machines we see on the plant floor, there is another layer of deeply embedded technology. This is the layer of devices and control systems typically running a real-time operating system (RTOS). These are designed for reliable performance and compactness and they generally have internal mechanisms very different from those found in a Microsoft operating system. OPC-UA, unlike its predecessor, is designed for portability and is intended to be used in all manner of devices, potentially from a remote sensor all the way to an enterprise dashboard application.

OPC-UA is built around a technology known as a "Service Oriented Architecture" (SOA). SOA involves creating programs (services) that perform a very specific function. These services are available to any remote software application that has both the authority and the need for the service. Because automation systems require high reliability and performance, the interface must operate in a very reliable manner. Security is a major concern, so the interface must deliver both support for secure access and immunity to malicious attacks that may compromise an automation system. Further, as an industry standard, the interface must leverage common technologies that are self-describing for improved ease of implementation, e.g., XML. Third party applications can connect to an OPC-UA service, pass information to it in a secured yet open and descriptive manner, and the service will provide a similar result. OPC-UA follows the concepts of a Web interface and because it behaves like any other Web interface it works with firewalls and can be managed by system administrators. It allows you to define ports for service access and for network traffic control in a straightforward and predictable manner. This is a major improvement over OPC based on COM and DCOM, which required many changes to Windows' Security configuration to enable distributed operation and also failed to provide sufficient control over PC-to-PC communications in terms of ports, complicating the engineer's or IT professional's ability to manage communication through firewalls.

Whereas the first-generation OPC leveraged Microsoft standards, OPC-UA is purposely built for the needs of the automation industry. This makes it very effective in terms of both performance and security. OPC-UA uses a compressed and binary data transfer, while managing secure access through Security Certificates. Finally, OPC-UA builds on earlier concepts of the OPC data specifications and extends them with new complex data and the ability to maintain context and data relevance (by allowing clients to access structured information) from the plant floor through to enterprise-level intelligence applications.

Bringing OPC to Market
How will OPC-UA make it to the market? When OPC was first introduced it was a new technology, without history to build on. As a result, all users struggled to make headway and to cope with the new technology's steep learning curve. Users' experience with OPC-UA will be significantly different. Yes, there are specifications to download and it will still be possible to develop an implementation from scratch, although it's not a recommended route because of interoperability requirements. The OPC Foundation has developed a number of stack implementations (the software needed to manage OPC-UA external interfaces). Joining the OPC Foundation gives you access to both specifications and reference stacks. Another way to become OPC-UA enabled is to use vendor-supplied implementations. This allows you to add an OPC-UA interface to your product by licensing a proven product from a technology provider—an option that was not available in the past. There are currently a number of OPC-UA early adopters who can deliver a fully operational OPC-UA implementation, along with other features that may be required.

Expect the first OPC-UA implementations to come in the form of complete solutions. Because interoperability is always the greatest challenge in leveraging a new communications standard, the most reliable solutions will come in the form of a suite of products, delivering the new technology (OPC-UA), and designed and tested as a complete system. This can come as products from one vendor or through partnerships, where vendors work closely to deliver the latest technology in a beneficial and reliable manner (see sidebar "OPC-UA Implementations").

Certifying interoperability will be better than in the past. Earlier this year, the OPC Foundation introduced its first independent certification lab, located in Germany. In the past, vendors proved OPC interoperability through self-certification tests and regular interoperability events. Today, while those earlier mechanisms are still available, the ideal proof of interoperability will come by sending your product to the lab for independent certification. After undergoing a battery of tests and several days of testing and communications analysis (if all goes well) the product will be issued a certification logo. This logo is good for the specific product tested and is version dependent. Any major revision will require a re-certification.

What's Next?
OPC is a very successful technology that has stood the test of time. It will not fall out of favor quickly and the OPC we have all grown to know and trust will continue for many years. OPC-UA promises to deliver exactly what is needed to solve the problems of the past, while delivering significant benefits for the future. Expect the first implementations to come to market in the next few months.

For more information on OPC, please contact the OPC Foundation.


OPC-UA Implementations

Kepware has leveraged OPC-UA internally as their first release of the technology. Kepware's KEPServerEX (Figure 1) supports connectivity to thousands of devices through more than 130 protocols. The technology supports OPC today and can support OPC-UA as an additional interface. An OPC-UA Client interface for KEPServerEX will enable one KEPServerEX to communicate with another located remotely. This negates the need for DCOM remote communications and enables one KEPServerEX to communicate with, or aggregate information from, many remote KEPServerEX servers without the need for tunneling products. OPC-UA will effectively make OPC tunneling products obsolete.

 

figure
Figure 1. The KEPServerEX communication product with client application and driver plug-ins

Iconics has taken the approach of implementing OPC-UA throughout their new Genesis 64 products. At the same time, Iconics has partnered with Kepware as its primary communications provider and is using Kepware's new OPC-UA interface. By reselling Kepware under the Iconics label, Iconics can assure their customers that although OPC-UA is a new technology, through this partnership and Iconics' ability to provide the end-to-end solution, the first release of a new technology will be completely proven and reliable.






Sensors.tv