OPC (Open Platform Communications, formerly OLE for Process Control) is a set of software technologies that provide a single, unified interface for controlling various devices and exchanging data. The OPC specifications were developed by the international non-profit organization OPC Foundation, which was developed in 1994 by leading manufacturers of industrial automation products. The goal of OPC creation was to provide engineers with a universal interface to control various devices.
By implementing support for the OPC client, SCADA system developers got rid of the need to support hundreds of drivers for various devices, and equipment manufacturers, by adding an OPC server, gained confidence that their product can be used by users of any SCADA system.
OPC technology includes several standards that describe a set of functions for a specific purpose. Current standards:
- OPC DA (Data Access) is the most common standard which describes a set of functions for real-time data exchange with PLC, DCS, HMI, CNC and other devices.
- OPC HDA (Historical Data Access) provides access to already saved data and history.
- OPC AE (Alarms & Events) provides on-demand notification functions for various events: emergency situations, operator actions, information messages and others.
- OPC Batch provides the functions of step and recipe control of the technological process.
- OPC DX (Data eXchange) provides functions for organizing data exchange between OPC servers via an Ethernet network. The main purpose of this standard is to create gateways for data exchange between devices and programs fr om different manufacturers.
- OPC Security defines the functions of organizing client access rights to OPC server data.
- OPC XML-DA (XML-Data Access) provides a flexible, rule-driven format for exchanging data over XML, SOAP and HTTP.
- OPC Complex Data is a set of additional specifications for OPC DA and XML-DA that allow servers to work with complex data types such as binary structures and XML documents.
- OPC Commands is a set of programming interfaces that allows OPC clients and servers to identify, send, and control commands executed in a controller or I/O module.
- OPC UA (Unified Architecture) is the most recent specification that is not based on Microsoft COM technology, which provides cross-platform compatibility.
The most widespread standard is OPC DA, but it has a significant drawback. At the time of its development, it was built on then-modern Windows technologies: OLE, ActiveX, COM/DCOM, but since then the industry has undergone changes and other operating systems and technologies have become popular. Therefore, the OPC technology was made platform independent and the OPC UA (Unified Architecture) standard was developed on open cross-platform technologies.
Where OPC is used
Usually, OPC technology is used to exchange data between controllers and a SCADA system, but it is also possible to organize complex systems at different levels of the process control system.
OPC consists of two parts: OPC client and OPC server. The OPC server software polls various devices via device drivers via fieldbuses. The OPC client software is usually built into the SCADA system and is designed to receive data from the OPC server.
Here, we can visualize several levels of ACS in a company:
- The lower level would be fieldbuses and individual controllers
- Middle level is shop networks
- APCS level is the level of operation of SCADA-type systems
- MICS level is the level of enterprise resource management applications, ERP, MES
Each of these layers can be served by an OPC server, supplying data to an OPC client at a higher layer or to a neighboring device.
How OPC DA server works
The OPC DA server provides data exchange (writing and reading) between the client program (usually a SCADA system) and end devices. Data in OPC is a Tag variable with some properties. A variable can be of any type allowed in OLE: various integer and real types, boolean, string, date, array, etc. Properties can be required, recommended, or custom.
Required variable properties:
- The current value of the variable, its type and access rights (read and/or write).
- The quality of a variable depends on the measured value going beyond the dynamic range, lack of data, communication error, and other parameters. Usually takes on values: good/bad/indefinite and additional information.
- The timestamp reports the time when the variable received the given value.
- The frequency of polling the variable by the OPC server sets the time when the value of the variable is updated.
- Variable description, which contains information for the user about what this variable is.
Additionally, optional properties can be specified, such as: range of value change, unit of measurement and other custom parameters.
Various modes can be used to read data from the OPC server:
- Synchronous mode: the client sends a request to the server and waits for a response from it.
- Asynchronous mode: the client sends a request and immediately proceeds to perform other tasks. After processing the request, the server sends a notification to the client and he takes the provided data.
- Subscription mode: the server sends to the client only those tags that have changed. In order to prevent the noise of the data from being mistaken for their change, the concept of a "dead zone" is introduced, which slightly exceeds the maximum possible amplitude of the interference.
- Data refresh mode: the client invokes the simultaneous reading of all active tags. All tags are called active except those designated as "passive". This division of tags reduces the load on the processor by updating the data received from the physical device.
The client receives data from the OPC server either from the buffer or directly from the end device. Reading from the buffer is faster, but the data in it may be out of date by the time it is read. The OPC server periodically updates data by requesting information from end devices.
Data is written to the end device in synchronous or asynchronous modes without intermediate buffering. In synchronous mode, the client writes data and waits until it receives confirmation of the command execution from the end device. This process can take a long time, during which the client is waiting. Asynchronous mode allows the client to send a request to the server and do other tasks. After the end of the recording, the server will send a notification to the client.
OPC UA standard
OPC UA (Unified Architecture) is a modern standard for data transmission in industrial networks. It provides secure and reliable communication between devices, while being hardware and platform independent, which allows communication between devices with different operating systems.
The strengths of OPC UA are the object-oriented information model, which allows data to be “viewed” (in a web browser style), and service-oriented architecture (SOA). If earlier you had to use several OPC servers: OPC DA for real-time data, OPC HDA for history and OPC AE for events, now all this and much more is available in one OPC UA standard. Instead of a tag tree, the concept of nodes or objects is now introduced. Each node includes variables, methods and other data structures of a real object.
Data exchange is now carried through binary structures and XML documents. In addition to the client/server model, a publisher/subscriber model becomes available. The standard also defines a mechanism to support redundancy (if one client becomes unavailable, then another takes its place) and quickly restore communication in the event of a failure. Data transfer occurs through the transport layer TCP, HTTP/SOAP, or HTTPS. Instead of Windows access control mechanisms, OPC UA supports digital certificates and the ability to encrypt transmitted data.
Implemented backward compatibility with OPC DA through a special wrapper and proxy module. To transfer data through routers and firewalls, OPC DA required the use of middleware, while OPC UA works without this medium. The OPC UA specification includes several parts that describe the logic of the operation of servers and clients. A detailed version of the specification is available in the IEC 62541 standard.
OPC UA server example
An example of an OPC UA server is the MX-AOPC UA Suite from MOXA. MX-AOPC UA Suite includes 3 programs:
- Server is a program for receiving data from Modbus devices
- Viewer is a program to view tags and server status (Viewer is built into Server)
- Logger is for logging the history of data changes, as well as integration with databases and cloud solutions
First of all, MX-AOPC UA Server is focused on MOXA I/O modules, because of the Active Tag function, but it also supports third-party devices via Modbus RTU and Modbus TCP protocols. The Active Tag function allows you to update the state of channels immediately after their change, without waiting for a command from the server.
MX-AOPC UA Logger allows you to send data to Microsoft Azure Cloud and Microsoft SQL Server, MySQL, Oracle, Microsoft Office 2003 Access or Excel databases via ODBC.
MX-AOPC UA implements data protection through encryption with the Basic128Rsa15 key and confirmation with the X509 certificate.
Cons of using OPC
Common mistakes when using OPC include:
- Relying on OPC technologies to much
- Unnecessary use of WEB technologies in APCS
- Using real-time protocols in telemechanical tasks
Let’s say you have learned about good OPC technology and are striving to replace all lower layer protocols with OPC only. But converting Modbus, Profibus and any other industrial protocols to a PC format will take additional time and waste computing power. Tests have shown that the SCADA system works directly with industrial protocols twice faster than through an intermediate OPC server. Of course, there are systems wh ere the process does not need to be monitored in real time, but this must be considered when designing an automated process control system.
The disadvantages also include the complexity of setting up the OPC server and the need to manually input thousands of tags. In addition, an OPC server is not always supplied free of charge, and most often you will have to buy a separate license for each PC.
If the system sends data via the Internet to the Cloud, then a weak encryption scheme can become a potential vulnerability and a target for hacker attacks, which casts doubt on the security of the entire ICS.
OPC UA for real-time operation
OPC UA over TSN is designed to support real-time operation, this OPC UA technology can use a publisher/subscriber model(instead of a client/server model) in combination with TSN (Time-Sensitive Networking) technology.
The client/server model works fine in the case of a point-to-point connection, but if there are a lot of devices, then there are delays in data updates. The publisher/subscriber model provides a one-to-many and many-to-many relationship. The server sends its data to the network (publication) and each client can receive this data (subscription).
Ethernet with TSN technology complements existing Ethernet facilities in terms of quality of service (QoS), including bandwidth allocation, timing, low latency assurance and redundancy. The data is transmitted by various devices over an Ethernet network in streams. Ethernet switches with TSN allow you to allocate an own bandwidth for each stream and ensure its transmission in real time. Multiple streams can be combined (called network convergence) and sent over the same network in real time. It turns out that without TSN technology, only one real-time protocol can be transmitted over one Ethernet network, and with TSN several.
The combination of OPC UA over TSN technologies allows organizing communication between equipment produced by different manufacturers and emsuring continuous receipt of data in real time.
The OPC Foundation plans to use OPC UA not only to transfer data between controllers and the SCADA system, but also at the field level from sensors and IoT devices to controllers, as well as from local systems in the Cloud. To do this, they plan to split the OPC UA standard into 4 parts, depending on the performance of the device and the capabilities it needs.
- Nano Embedded Device Server: suitable for the smallest sensors
- Micro Embedded Device Server: suitable for inexpensive PLCs
- Embedded UA Server: suitable for more powerful PLCs and border gateways
- Standard UA Server: full-fledged implementation supporting all functions
OPC UA perspectives
It is safe to say that although the OPC DA standard is still widely used, it no longer meets modern automation requirements. It is based on legacy technology, is difficult to configure, and does not meet modern security standards. It was replaced by the modern OPC UA standard with the ability to encrypt data and build unified data transmission systems from sensors to the Cloud. The joint use of OPC UA with TSN significantly expands the capabilities of the technology for real-time data transmission. Of course, you shouldn't run and get rid of OPC DA right now, but you can gradually upgrade existing systems and switch to OPC UA through special wrappers and proxy modules.
For further technical information, inquiries about offers or placement of orders, please contact our sales team at sales@ipc2u.com
