Manufacturing AUTOMATION

The next generation of open connectivity: New specifications in OPC standards are opening doors in industrial automation

July 22, 2010
By Tony Paine

A new generation of OPC, or open connectivity in industrial automation, is upon us.

The latest specification is a major step forward in both technology and capability. Called OPC-UA, it starts by unifying the multiple specifications of the past, and redefines the abbreviation of OPC (formerly OLE for Process Control – a purposeful implementation of certain Microsoft technology) to OPC-UA (now standing for Open Connectivity – Unified Architecture).

Like everything the second time around, the latest generation of OPC-UA delivers solutions to problems of the past, delivers significant new capabilities and is a foundation to build on well into the future.

How far it’s come
The first generation of OPC primarily developed into three distinct specifications. They were 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).

Advertisement

Product developers could pick and choose from these separate specifications and implement what was most suitable to them. Since most of the automation world revolves around real-time data access, it was only natural that OPC-DA would become the most widely supported specification followed by OPC-A&E and finally 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, while communication drivers may be focused on real-time communications, they also generate status and error messages. A built-in support for the Alarm and Event portion of the specifications would allow access to not only data, but all related status messages, through one interface. The same can be said for Historic Data Access.

While few real-time communication devices need HDA support, there is a class of device called an RTU (Remote Terminal Unit) that typically offers all three forms of data, real-time Data Access, Alarm and Event Messages and Historic Data Access. Again, reliance on OPC-UA will facilitate one interface for these various data types where three were required in the past.

The OPC of 1995 was very Microsoft-centric, leveraging OLE (Object Linking and Embedding), a technology enabling applications-to-applications communications in Microsoft operating systems. This also involved a technology called COM (Component Object Model) and, when talking from one computer to another over a network, DCOM (Distributed Component Object Model).

While it is true that Microsoft dominates most of the machines we see on the plant floor, there is another layer of technology that is deeply embedded. This is the layer of devices and control systems, typically running an RTOS (Real-Time Operating System). These are designed for performance and compactness and generally have internal mechanisms very different from 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.

The next generation
OPC-UA is built around today’s leading technology and it’s what is known as a "Service Oriented Architecture" (SOA). Service Oriented Architectures involves creating programs (or services) that perform a very unique function, and that can expose that function to any remote application with the authority and need for the service.

The interface to a service is commonly through a well-designed and self described interface (typically XML). Hence, an application can connect to a service, pass information in an open and descriptive manner, and the service will provide a similar result. Additionally, by following the concepts of a Web interface (similar to logging onto a web port), OPC-UA behaves like any other Web interface and is as easily managed as other web applications, making it firewall friendly and manageable by system administrators.

The ability to define Ports for service access and the control of traffic is very straight forward and predictable in OPC-UA. This is a major benefit over OPC based on COM and DCOM, which required a great deal of Windows Security configuration to enable distributed operation and did not give precise control over the machine PC to PC communications in terms of Ports, making it difficult to manage through firewalls.

Developing a solution to perfectly fit a problem is far better than leveraging general purpose technology for a niche application. Whereas the first generation OPC leveraged Microsoft standards, OPC-UA is purposely built for the needs of the automation industry. This makes it a very effective solution in terms of both performance and security.

OPC-UA leverages 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, while extending them with new complex data, the ability to have clients access structures of information to maintain context and data relevance from the plant floor right through enterprise intelligence applications. Overall, OPC-UA is a much richer and more robust implementation over the past, specifically addressing the needs of the automation industry.

Making it to market
The OPC of years ago was new technology with no history to build on. All users were struggling to make headway and faced with the learning curve of a new technology. This go-around will be significantly different.

Yes, there are specifications to download and an implementation can be done from scratch, however, due to interoperability requirements that route would not be recommended. The OPC Foundation has developed a number of stack implementations (the software needed to manage the OPC-UA external interfaces). Joining the OPC Foundation will give you access to both specifications and reference stacks. Another likely solution for becoming OPC-UA enabled would be to leverage complete implementations available from vendors in this space.

If your goal is to add an OPC-UA interface to your product, why not license a widely proven solution from a technology provider. This option was not available in the past. This time around however, there are a number of OPC-UA early adopters, that can deliver a fully operational OPC-UA implementation along with other features and benefits that may be required.

Expect the first OPC-UA implementations to come in the form of complete solutions. Interoperability is always the greatest challenge in leveraging a new communications standard. Hence, the most reliable solutions will come in the form of a suite of products, delivering the new technology (OPC-UA) designed and tested as a complete solution.

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.

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, OPC interoperability was proven through self-certification tests and regular interoperability events. Today, while those earlier mechanisms are still available for starters, the ideal proof of interoperability will come through independent certification by sending your product to the lab.

A battery of tests will be performed and after several days of testing and communications analysis, if all goes well, a certification logo will be issued. This logo is good for the specific product tested and is version dependent. A major new version will require a re-certification.

What is next? Well, OPC is a very successful technology that has proven the test of time. It will not fall out of favour quickly and the OPC we have all grown to know and trust will continue on for many years. OPC-UA will become successful as it delivers exactly what is needed to solve the problems of the past, while delivering significant benefits for the future.

Tony Paine is president of Kepware Technologies. He is also a member of the OPC Foundation’s OPC-UA Technical Advisory Committee. For more information on OPC, contact the OPC Foundation www.opcfoundation.org.


Print this page

Advertisement

Story continue below