OLE for Process Control

From Wikipedia, the free encyclopedia
Jump to: navigation, search

OLE for Process Control (OPC), which stands for Object Linking and Embedding (OLE) for Process Control, is the original name for a standards specification developed in 1996 by an industrial automation industry task force. The standard specifies the communication of real-time plant data between control devices from different manufacturers.

As of November 2011, the OPC Foundation has officially renamed the acronym to mean "Open Platform Communications" although they also use the tagline "Open Productivity & Connectivity" on their website.[1] The change in name reflects the applications of OPC technology for applications in Process Control, discrete manufacturing, building automation, and many others. OPC has also grown beyond its original OLE (Object Linking and Embedding) implementation to include other data transportation technologies including XML, Microsoft's .NET Framework, and even the OPC Foundation's binary-encoded TCP format.

After the initial release in 1996, the OPC Foundation was created to maintain the standard. Since then, standards have been added and names have been changed. As of June, 2006, "OPC is a series of standards specifications". (Seven current standards and two emerging standards.) "The first standard (originally called simply the OPC Specification"), is "now called the Data Access Specification", or (later on the same page) "OPC Data Access", or OPC Data Access Specification.[2]

Origin and uses[edit]

The OPC Specification was based on the OLE, COM, and DCOM technologies developed by Microsoft for the Microsoft Windows operating system family. The specification defined a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications to facilitate interoperability. The most common OPC specification is OPC Data Access, which is used to read and write real-time data. When vendors refer to OPC generically, they typically mean OPC Data Access (OPC DA). OPC DA itself has gone through 3 major revisions since its inception. Versions are backwards compatible, in that a version 3 OPC Server can still be accessed by a version 1 OPC Client, since the specifications add functionality but still require the older version to be implemented as well. However, a Client could be written that does not support the older functions since everything can be done using the newer ones, so a DA 3 compatible Client will not necessarily work with a DA 1.0 Server.

In addition OPC DA specification, the OPC Foundation also maintains the OPC HDA (Historical Data Access) specification. In contrast to the real time data that is accessible with OPC DA, OPC HDA allows access and retrieval of archived data.

Design[edit]

OPC was designed to provide a common bridge for Windows based software applications and process control hardware. Standards define consistent methods of accessing field data from plant floor devices. This method remains the same regardless of the type and source of data. An OPC Server for one hardware device provides the same methods for an OPC Client to access its data as any and every other OPC Server for that same and any other hardware device. The aim was to reduce the amount of duplicated effort required from hardware manufacturers and their software partners, and from the SCADA and other HMI producers in order to interface the two. Once a hardware manufacturer had developed their OPC Server for the new hardware device their work was done to allow any 'top end' to access their device, and once the SCADA producer had developed their OPC Client their work was done to allow access to any hardware, existing or yet to be created, with an OPC compliant server.

OPC servers provide a method for many different software packages (so long as it is an OPC Client) to access data from a process control device, such as a PLC or DCS. Traditionally, any time a package needed access to data from a device, a custom interface, or driver, had to be written. The purpose of OPC is to define a common interface that is written once and then reused by any business, SCADA, HMI, or custom software packages.

There is nothing in the OPC specifications to restrict the server to providing access to a process control device. OPC Servers can be written for anything from getting the internal temperature of a microprocessor to the current temperature in Monument Valley.

Once an OPC Server is written for a particular device, it can be reused by any application that is able to act as an OPC client. OPC servers use Microsoft’s OLE technology (also known as the Component Object Model, or COM) to communicate with clients. COM technology permits a standard for real-time information exchange between software applications and process hardware to be defined.

It is important to note that some OPC specifications are published, others are available only to member of the OPC Foundation. So whilst no company "owns" OPC and anyone can develop an OPC server, whether or not they are a member of the OPC Foundation, non-members will not necessarily be using the latest specifications. Anyone can integrate OPC products, and there is no pre-requisite for the system integrator to belong to any organization. It is therefore up to each company that requires OPC products to ensure that their products are certified and that their system integrators have the necessary training.

Future[edit]

The OPC Unified Architecture (UA) has been specified and is being tested and implemented through its Early Adopters program. It can be implemented with Java, Microsoft .NET, or C, eliminating the need to use a Microsoft Windows based platform of earlier OPC versions. UA combines the functionality of the existing OPC interfaces with new technologies such as XML and Web Services to deliver higher level MES and ERP support.

On September 16, 2010, The OPC Foundation and the MTConnect Institute announced a cooperation to ensure interoperability and consistency between the two standards.[3]

See also[edit]

References[edit]

External links[edit]