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:
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.
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:
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.
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:
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:
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 (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.
An example of an OPC UA server is the MX-AOPC UA Suite from MOXA. MX-AOPC UA Suite includes 3 programs:
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.
Common mistakes when using OPC include:
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 where 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 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.
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 firstname.lastname@example.org