OPC helps drive improved interoperability

High speed, real-time interlocking and rock solid connectivity are core requirements for implementing a motion control system

By Roy Kok, Kepware Technologies -- Plant Engineering, 11/18/2009 11:36:38 AM

High speed, real-time interlocking and rock solid connectivity are core requirements for implementing a motion control system. The most common interfaces are oriented around control network architectures based on protocols such as Profibus, DeviceNet, SERCOS, Profinet, EtherCAT, Ethernet I/P and many others. OPC has a beneficial place in this networking environment - today, and into the future.
OPC background
Introduced in 1996, OPC technology was developed by a group of companies - the founders of the OPC Foundation - to deliver a common specification for interoperability between software applications. OPC Specifications outlined how to pass data from one application to another in a client/server architecture.
The first generation of OPC developed 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 software solutions 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.
Understanding the technology behind OPC will shed light on its applicability and its continuing evolution. The term OPC has morphed over the years. Initially an acronym for OLE for Process Control, OPC has been updated and now stands for OPen Connectivity via open standards. This name change happened with the latest introduction of a new set of OPC specifications - OPC-UA.
OLE stands for Object Linking and Embedding. The objects are defined by another Microsoft technology called COM, which stands for Component Object Model. Microsoft uses these technologies within its operating system to enable application-to-application communications. This technology also enables applications to share components. For example, Word and Excel can share common spell-checking technology.
OLE and COM make up the fundamental "pipes" that enable data flows and application interoperability. Making them suitable for use in automation simply required defining how to handle different types of data and defining data access methods. OPC data access methods can support polling for data; subscribing to data changes; both synchronous and asynchronous read and write capability; and the ability to read from cache or require a read from the source. If this sounds like a lot of capability, it is, and it delivers all the requirements for both general purpose connectivity and high performance real-time connectivity for application communication within a PC.
The solution for communications from one PC to another requires an extension of COM technology called DCOM, which stands for Distributed COM. In a perfect world, DCOM offers excellent distributed connectivity. However, DCOM was designed for use in business systems, not distributed real-time interoperability.
So, failure modes, delays in detecting a network break and recovering, for example, preclude its use as a real-time pipe between computers in other than a perfect system setting. There are automation-tailored alternatives for PC-to-PC connectivity (for more information, research Tunneling solutions). With this understanding of OPC, we can now explore the applicability to motion controls.
Applying OPC to motion control
Motion control systems typically require tight coupling between drive elements and a controller. Vendor-specific control networks are almost always employed to deliver interoperability at the control level. However, the equipment being controlled is now under greater pressure than ever to operate with high reliability, optimum performance and deliver the best possible quality.
Motion control vendors are seeing new pressures to integrate motion control systems with supervisory systems that deliver machine performance analytics such as OEE and asset management information, which allows users to manage scheduled maintenance and calculate total cost of ownership, for example. These solutions are typically delivered by other companies, with that as their core competency and focus.
Today, interoperability between the motion control and third party applications is becoming a mainstream requirement. Integration requires the installation of a communications driver, supporting the automation protocol used in the motion control system and supporting the OPC standard interface for third party application integration. While Drivers exist for the motion control protocols, a more typical scenario involves communicating with the motion controller - typically a PLC or CNC - with a higher-level communication protocol.
The controllers will often contain more information than is available from the control network, aggregated information from several data sources, totalized counts, cycle times, operating speeds, etc.
These variables are more appropriate for supervisory analytics. The use of OPC as an interface for these supervisory solutions has become the industry norm. Most vendors have partnered with a communications company, removing their burden in having to offer and support the complexities of various protocols. OPC is the common layer that enables the connectivity of these systems with virtually any plant floor machine - including motion control equipment.

OPC moving forward
OPC technology is taking a major step forward. In 2009, the OPC Foundation released a new set of specifications for a technology called OPC-UA, or OPC - Unified Architecture. This new specification "unifies" the past specifications into one all-encompassing specification. OPC-UA offers the promise of delivering a higher level of interoperability.
OPC-UA is built around a technology known as a Service Oriented Architecture (SOA). High reliability and high performance are imperative for the automation world; the interface must operate in a very reliable manner. In addition, security is a major concern and the interface must deliver support for both secure access and be immune to malicious attacks that may compromise an automation solution.
OPC-UA operates as a Web service. And because it behaves like any other Web service, 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 the COM- and DCOM- based OPC of the past, which required many changes to a Windows' Security configuration to enable distributed operation. DCOM also failed to provide sufficient control over PC-to-PC communications in terms of ports, complicating an engineer or IT professional's ability to manage communication through firewalls.
These changes will enable OPC-UA to deliver even greater value in distributed applications where the communications server will be on one PC and the supervisory solution is remote, possibly even available as a hosted service. Whereas the first-generation OPC leveraged Microsoft standards, OPC-UA is purposely built for the needs of the automation industry and leverages more pervasive technologies. This makes it very effective in terms of ease of use, performance and security. OPC-UA based products are on the market today, and adoption is expected to ramp up during 2009.

Roy Kok is the vice president of Marketing and Sales for Kepware Technologies where he has worked since July of 2007. He can be reached at Roy.Kok@kepware.com. For more information about OPC and OPC-UA, visit www.opcfoundation.org.