In an ideal world, integration of process control would be very simple.
One could buy all the computers, instrumentation and electrical equipment from a single source field and connect, using a single network standard. But in real life is not so simple, rarely ios PLCs, DCSs, drives, motor control, field instruments and computers are purchased from a single provider. Moreover, when they are, the provider has equipment in which the interface is not as clean.
We said that the much hyped Ethernet and TCP / IP does not solve the problem. They need additional protocols in the application layer (... do you remember the ISO model?) To perform useful tasks on the network, such as reading information from a specific record of a PLC. Of course, each vendor has their own idea of the best protocol at the application layer to use.
For example, a Modicon PLC and an Allen Bradley could have both Ethernet-TCP/IP but have different application protocol. If we try to connect, discover that they can not communicate.
In process control, has necessitated a common language for some time, this is OLE for Process Control (OPC) which is one of the most promising. OPC is a standard set of interfaces, properties and methods that define how individual components of the program can interact and share information.

Not that Allen Bradley PLCs spontaneously. "Talk" using Modbus (Modicon), but it creates a common language between the two. Each provider OPC creates programs to "speak" their native language more OPC, then both programs are loaded on a PC and OPC is used to program the two parts interact.
OPC is based on Microsoft's OLE (now called ActiveX OLE). Many people have heard of OLE y.lo used whenever we use the ability to "paste" an Excel spreadsheet in a Word text document.
OLE allows the spreadsheet dynamically update the information contained in the document. Moreover, the user typically requires no configuration beyond making a click with the mouse. The OLE specification completely defines as the spreadsheet (in this case, the OLE server) formats and sends the information to the text document (in this case, the client OLE).
OPC adds some features to the OLE for addressing requirements in process control. For example, an OLE server does not verify if the client received the information, just send it and forget the rest. Just because it is poorly suited for process control applications, OPC, adds this ability to acknowledge and validate the transaction client / server.
One advantage of OPC is that it provides a common interface for communication of various devices, despite the control protocols or programs used in the process. Before OPC exist, application developers had to prepare "drivers" specific control system which want to connect. A provider of human-machine interface (HMI) had to develop more than 200 "drivers" for different PLCs and DCSs.
With OPC, application providers do not need to develop "drivers" for each network separately or processor, only need to create a "driver" OPC optimized for your product. It communicates with other OPC servers designed and sold by manufacturers of other networks and controllers.
It is important to understand that OPC does not eliminate the need for "drivers" none of the currently existing PLC "talk" OPC, each manufacturer will develop the OPC driver for a specific product. Once there the OPC driver for a piece of equipment or an application, it is very simple to integrate that information with OPC compliant devices.
For end users, configuring the OPC is significantly simpler to configure different drivers:
- OPC does not need an intermediate map information in addition to the respective maintenance.
- OPC provides information in native format and syntax.
- OPC provides a browser for easy setup.
... In summary, we conclude that
OLE for Process Control (OPC) has been designed as a method to allow business applications (general commercial) to access data consistently Plant.
The acceptance of OPC in the industry will provide many benefits:
- Hardware manufacturers only have to do a set of software components for customers to use in their applications.
- The software repairers do not have to re-write "drivers" every time an update or hardware changes.
- Customers have more options for developing manufacturing systems and integrated information.
With OPC, system integration and equipment will be a simple task.




