Open Platform Communications
Open Platform Communications (OPC) is a series of standards and specifications for industrial telecommunication. An industrial automation industry task force developed the original standard in 1996 under the name OLE for Process Control (Object Linking and Embedding for Process Control). OPC specifies the communication of real-time plant data between control devices from different manufacturers.
After the initial release in 1996, the OPC Foundation was created to maintain the standard.[1] As OPC has been adopted beyond the field of process control, the OPC Foundation changed the name to Open Platform Communications in 2011.[2] The change in name reflects the applications of OPC technology for applications in building automation, discrete manufacturing, process control and many others. OPC has also grown beyond its original OLE (Object Linking and Embedding) implementation to include other data transportation technologies including Microsoft's .NET Framework, XML, and even the OPC Foundation's binary-encoded TCP format.
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). OPC DA itself has gone through three 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.
Next, you have the OPC AE specification. This OPC AE (Alarms & Events) is also maintained by the OPC Foundation. The OPC A&E specification defines the exchange of alarm and event type message information, as well as variable states and state management.
Design
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 members 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
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
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]
References
- ↑ What is OPC? opcfoundation.org
- ↑ https://opcfoundation.org/about/what-is-opc/
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
