Many Devices, One Solution

Imagine you’re working at a food manufacturing plant, and your job is to double the capacity of fruit snack production. As part of the project, you need to connect multiple, disparate systems—including dryers, wrappers, conveyors and depositors—to a centralized manufacturing information system. The catch—try to avoid writing expensive drivers to interface with all of the proprietary equipment.

Enter OPC, a communications standard for plant systems connectivity. At Stretch Island Fruit’s plant in Allyn, Wash., Aspen Technology Inc., based in Cambridge, Mass., standardized on OPC to connect food production equipment to AspenTech’s InfoPlus 2.1 information management system. AspenTech applied OPC servers and clients from Matrikon, in Edmonton, Alberta, Canada, and eliminated the need to develop custom device driver software.

In the nearly 10 years since OPC was created, it has become the preferred method for plant connectivity, according to a recent survey by ARC Advisory Group, in Dedham, Mass. The survey shows that manufacturing companies prefer to use OPC over other methods for connecting systems in plant environments, especially among programmable logic controllers (PLCs), distributed control systems (DCSs), supervisory control and data acquisition systems (SCADAs), and manufacturing execution systems (MESs).

OPC to the rescue

"One of the secrets to OPC’s success is the cost savings it has provided to system suppliers and manufacturers," says Dave Emerson, who is on the OPC Foundation Technical Steering Committee and is the principal systems architect in the Yokogawa U.S. Development Center, in Carrollton, Tex. "Before OPC was widely accepted, it was not unusual for a software provider to have specialists, or even an entire department, dedicated to writing interfaces to the various software products their customers wanted to interface their products with. While this cost was passed on to the customer, it was not a core product, it was difficult to test, and it was often the source of more problems than profit."

Manufacturing users have also benefited from OPC. Emerson explains, "Manufacturing companies wanting to interface products from different suppliers were forced to pay for custom interfaces, and were constrained in upgrading individual products until there were new interfaces available. The use of OPC has reduced costs significantly by reducing the number of interfaces used between systems."

OPC itself is a set of specifications issued by the OPC Foundation, a non-profit organization that consists of member companies who contribute dues and work to develop and maintain OPC. Originally named "OLE for Process Control" after Microsoft’s Object Linking and Embedding technology, it is now known simply as "OPC," which stands for Open Connectivity.

The OPC specifications define in detail the programming interfaces, which are built upon communication technologies such as distributed common object model (DCOM) and Web Services. By themselves, the OPC specifications are only documents. When used by programmers, these specifications lead to programs and systems that can exchange data with other software that follows the same standard.

There are currently eight OPC specifications that have been released by the OPC Foundation, and two additional specifications are in development. The OPC Specifications chart above describes all ten specifications, along with their release dates and current versions.

The original specification, OPC Data Access (DA), was first released in 1996 and is used to move discrete quantities of real-time data from PLCs, DCSs and other control devices to data clients. Other specifications have since been added to the OPC portfolio, including specs for historical and eXtensible Markup Language (XML) data access, complex data, data exchange (DX), alarms and events, batch and security. The two under development are a commands specification and the next-generation OPC spec, called OPC Unified Architecture (UA). (See "Interview with the OPC Chief Architect" for more on OPC UA.)

Data plumbing

OPC specs define a means to pass data among client and server programs, but they do not define what data should be passed. This is analogous to how a pipe provides a means to send material between two locations, but does not define the material to be sent.

Following this analogy, different types of pipes may be used for different types of materials. Says Emerson, "The Data Access specification is the pipe to use for passing discrete values, such as a flow rate or temperature, while the Alarm & Event specification is the pipe to use for passing alarm messages. OPC specifications do not dictate which temperature or pressure value is to be sent using an OPC DA interface—this is decided by the user of the interface. OPC, however, does provide the data plumbing so the information is moved accurately and securely between programs."

The OPC architecture is based upon a client/server computer model. An OPC server is a data source, in that it receives requests for data from an OPC client, obtains the data from the internal, often proprietary system, and serves the data to the OPC client. The OPC client is free to use the data as it wishes, be it in a human-machine interface, historian, interactive dialog box or other use. The client/server architecture may be used with any number of servers and clients working together.

This illustrates another benefit of OPC—its ability to provide a high degree of interoperability among different suppliers’ systems. Says Emerson, "The OPC Foundation has developed a series of compliance tests to certify that OPC servers adhere to the specifications. In addition, the OPC Foundation sponsors Interoperability Workshops each year in the United States, Europe, and Japan, where member companies connect products to verify that their OPC clients and servers work together."

The OPC Foundation is evolving OPC technology in order to stay current with emerging security and Web Services standards. The OPC UA specification, due to be released in 2005, will enable communication among different operating systems and across firewalls, as enterprise-level systems move to Web Service-based architectures.

See sidebar to this article: Interview with the OPC Chief Architect

See sidebar to this article: OPC Specification