- OLE for process control
-
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.
After the initial release, 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. [1]
While OPC originally stood for "OLE for Process Control", the official stance of the OPC Foundation[citation needed] is that OPC is no longer an acronym and the technology is simply known as "OPC". One of the reasons behind this is while OPC is heavily used within the process industries, it can be, and is, widely used in discrete manufacturing as well. Hence, OPC is known for more than just its applications within process control.
Contents
Origin and uses
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 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.
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 Specs. 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
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.[2]
See also
- Modbus
- Lonworks
- KNX (standard)
- IEC 61850
- MTConnect
References
- ^ What is OPC? opcfoundation.org
- ^ "OPC Foundation and MTConnect Institute Announce a Memorandum of Understanding". OPC Foundation. 2010-10-21. http://www.opcfoundation.org/Default.aspx/02_news/02_news_display.asp?id=845&MID=News. Retrieved 2010-10-26.
External links
Categories:- Automation
- Computer standards
- Application programming interfaces
Wikimedia Foundation. 2010.
