What is OPC?
OPC means “Open process control” or “Open platform communications” It is a standard that defines data communication between devices from different manufacturers .It Requires an OPC server to communicate with OPC clients .OPC allows “plug and play”, provides benefits as it reduces installation time and the opportunity to choose products from different manufacturers
Different standards: “Real-time” data (OPC DA), Historical data (OPC HDA), Alarm & Event data (OPC AE), etc.
What is the purpose of OPC ?
The objective of OPC is to provide a standards-based infrastructure for the exchange of process control data. For example, manufacturers have many different data sources, such as PLC, DCS, databases, meters, RTU and other devices. This information is available through different connections, such as serial, Ethernet or even radio transmissions. Different operating systems such as Windows, UNIX, DOS and VMS are also used by many process control applications.
OPC is an industrial standard published for the interconnection of systems. The OPC Foundation maintains all OPC specifications. OPC means OLE for process control. It uses Microsoft’s COMOM and DCOM technology to allow applications to exchange data on one or more computers using the aclient / server architecture. OPC defines a common set of interfaces. Therefore, applications retrieve data in exactly the same format, regardless of whether the data source is a PLC, a DCS, a meter, an analyzer, a software application or anything else. As a result, OPC is a ready-to-use plug and play communication solution
Why OPC Succeeds where Custom Drivers Fail?
The key to OPC’s success in creating truly vendor-independent communications is that OPC abstracts the Data Source (e.g., PLC) and Data Sink (e.g., HMI) implementation details from each side so data can be exchanged between them without requiring them to know anything about each other’s native communications protocol and internal data organization. This is in sharp contrast to the custom driver approach of writing applications that, by
definition, are required to natively communicate with both the Data Source and the Data Sink.
How OPC Communication works ?
OPC can be represented as an “abstraction” layer that sits between the Data Source and the Data Sink, allowing them to exchange data without knowing anything about each other.
The OPC “device abstraction” is realized by using two, specialized OPC components called an OPC Client and OPC Server. Each of which is described in a following section. What’s important to note is that just because the Data
Source and Data Sink can communicate with each other via OPC does not mean their respective native protocols are no longer necessary or have been replaced by OPC. Instead, these native protocols and/or interfaces are still present, but only communicate with one of the two OPC components. In turn, the OPC components exchange information amongst each other and the loop is closed. Data can travel from the Application to the Device without having one
talk directly to the other
OPC DA (Data Access)
The most common OPC specification is OPC DA, which is used to read and write “real-time” data. When vendors refer to OPC generically, they typically mean OPC DA.
• OPC HDA (Historical Data Access)
• OPC A & E (Alarms & Events)
These OPC specification are based on the OLE, COM, and DCOM technologies developed by Microsoft for the Microsoft Windows operating system family. This makes it complicated to make it work in a modern Network! Typically you need a Tunneller Software in order to share the OPC data in a network (between OPC Servers and Clients)
OPC UA (Unified Architecture)
OPC UA solves problems with standard/classic OPC
• Works only on Windows
• Cumbersome to use OPC in a network due to COM/DCOM
• OPC UA eliminating the need to use a Microsoft Windows based platform of earlier OPC versions.
• OPC UA combines the functionality of the existing OPC interfaces with new technologies such as XML and Web Services (HTTP, SOAP)
• Cross-platform
• No dedicated OPC Server is no longer necessary because the server can run on an embedded system
• OPC UA supports two protocols.
– “UA Binary” protocol opc.tcp://Server
This uses a simple binary protocol
– “UA XML” protocol http://Server
This used open standards like XML, SOAP (-> Web Service)
• This is visible to application programmers only via changes to the URL.
• Otherwise OPC UA works completely transparent to the API.
Difference between OPC classic server and OPC UA server
Classic OPC requires a Microsoft Windows operating system to implement COM/DCOM server functionality. By utilizing SOA and Web Services, OPC UA is a platform-independent system that eliminates the previous dependency on a Windows operating system. By utilizing SOAP/XML over HTTP, OPC UA can deploy on a variety of embedded systems regardless of whether the system is a general purpose operating system,such as Windows, or a deterministic real-time operating system
Benefits of using OPC Connectivity
At first glance, trading a single Custom Driver for two OPC components (OPC Client and OPC Server) may not look like much of an improvement but as experience has shown, it is. Following are some key benefits of using OPC:
1.An OPC enabled Application can freely communicate with any OPC-enabled Data Source visible to it on the network without the need for any driver software, specific to the Data Source.
2. OPC-enabled applications can communicate with as many OPC-enabled Data Sources as they need. There is no inherent OPC limitation on the number of connections made.
3. Today OPC is so common that there’s an OPC connector available for almost every modern and legacy device on the market. It’s easy to get started using OPC.
4. OPC-enabled Data Sources may be swapped out, exchanged, or upgraded without the need to update the drivers used by each application (Data Sink) communicating with the Data Source via OPC. Only the OPC Server for that Data Source needs to be kept current.
5. Users are free to choose the best-suited devices, controllers, and applications for their projects without worrying about which vendor each came from and whether they will communicate with each other… intercommunication is now assumed!
