Gateway industrial exchange protocols on Linux. Gather yourself
I am engaged in the development, implementation and operation of automatic process control systems (ACS TP). At first he worked with SCADA-systems. Then he quickly switched to working with industrial device exchange protocols. Both self-writing drivers and setting up data collection systems. At the moment, my work is undergoing the atmosphere of Modbus, IEC-101/104, ORS and other protocols.
Fig. 1. The variety of exchange protocols used in process control systems
Briefly about how a typical data collection system is structured (A bit simplistic).
Fig. 2. Data acquisition system
Special software, called OPC-server, polls devices connected to the RS-485 interface. The OPC server is a kind of layer between the SCADA system and devices, translating the language in which the devices communicate in a language that the SCADA system understands. The Ethernet / RS-485 converter is used to convert TCP / IP packets into packets that run on the physical RS-485 environment.
This scheme has several disadvantages:
For the above situations, a protocol is more suitable in which data is transmitted upward by change (sporadically) and grouped by several values into a single TCP packet. Such protocols are IEC-60870-5-104 and OPC UA. ModBus-TCP is also suitable, there is no transmission for change, but then, if there is little data, you can pack them in one packet. It would be nice to have any controller that can be hung on a DIN-rail, connect devices to it via RS-485 and transfer data via Ethernet to a SCADA system.
In general, some hardware gateways are in considerable quantity. But in the form of ready-made indivisible solutions. All in one. And I don't really like it. I once needed a gateway that converts the protocols of the SET-4TM counters to OPC UA with six RS-485 ports and two Ethernet. One vendor has a gateway that supports the necessary exchange protocols, but few RS-485 ports, the other has the right number of RS-485 ports, but not two Ethernet ports. The third has two Ethernet ports, but there are no all exchange protocols. The fourth one has almost everything, but there is no OPC UA available on board IEC-60870-5-104 or ModBus-TCP require an OPC server for these protocols.
And how wonderful it would be: buy a controller or a mini-PC with OS from one manufacturer. Buy software for the controller from another. If one software vendor does not support something, purchase something from the software from another, merge the software components together via a standard software interface. It would seem that here it is a bright future!
That is why protocol gateways are used less often than a bunch of “OPC server and Ethernet Converter to RS-485” - because of their indivisibility into components.
One of the reasons why SCADA for Linux is underdeveloped: there is SCADA, it doesn’t support exchange protocols, and there are no OPC servers for communicating with the equipment. SCADA leaves the integrator one on one with iron.
The reader may already ask the question: What can you offer? What is already there? There are OPC UA servers for Linux for the following protocols:
In order to transfer data to the upper level not only via the OPC UA protocol, the “ OPC UA to Modbus Converter and IEC 60870-5-104 ” was created. In addition to the data transfer function for these protocols, the “Converter” has an embedded web-server. With the help of a special editor, you can draw a diagram, display the tag values on it, and then open it in the browser. It turns out mini-SCADA directly in the controller. As scheme revival works I already wrote here , about the editor here . In the future, it is planned “OPC UA to MQTT Converter”.
OPC UA servers and converter work on x64, ARMv7 and AARCH64 architectures.
Thus, for hardware, you can use both time-tested solutions based on mini industrial computers and various “raspberry pi compatible” ARM minicomputers. How to install and configure software with examples you can read here or here .
In general, the structure of the complex looks like this:
The system has scalability. Components necessary only for the solution of the current task are used.
With the use of the OPC UA server, our scheme is converted:
We have the following:
Thus, instead of the OPC server and Ethernet Converter to RS-485, we get one device that combines their functionality. I like this scheme more. And you?
Fig. 1. The variety of exchange protocols used in process control systems
Briefly about how a typical data collection system is structured (A bit simplistic).
Fig. 2. Data acquisition system
Special software, called OPC-server, polls devices connected to the RS-485 interface. The OPC server is a kind of layer between the SCADA system and devices, translating the language in which the devices communicate in a language that the SCADA system understands. The Ethernet / RS-485 converter is used to convert TCP / IP packets into packets that run on the physical RS-485 environment.
This scheme has several disadvantages:
- Set, for example, in the OPC server, the response timeout is 200 ms. In the ideal case, when the packets go on the Ethernet without delays, the exchange with the devices goes with a good speed (intensity). But if the packet containing the response is delayed, for example, by 300 ms (this is longer than the waiting timeout for 200 ms), then the OPC server considers that the response to the request did not arrive and sends the next request. At this time, the answer to the previous request comes, but the OPC server thinks that it came the answer to the current request and sends the wrong data to the top. As a result, the data on the ARM "jump". To get away from such situations, set the timeout longer. Take with a margin - 3000 ms. If the answer comes before 3000 ms, then the remaining time is not waiting, go to the next request. So far everything is going well, but it costs several devices to stop responding, How to form delays of 3000 ms for each device. Poll time increases.
- Most of the protocols used in the process control system (Modbus, electricity meters) are based on the sequential polling of the same parameters. Considering that most of the time the values of the parameters remain unchanged, the data network is used to transmit the same. It is irrational if the transmission medium is GPRS, and the traffic costs money. In addition, in the GPRS transmission medium, packet transmission delays can reach several seconds. Why waste time and resources to transmit the same thing?
For the above situations, a protocol is more suitable in which data is transmitted upward by change (sporadically) and grouped by several values into a single TCP packet. Such protocols are IEC-60870-5-104 and OPC UA. ModBus-TCP is also suitable, there is no transmission for change, but then, if there is little data, you can pack them in one packet. It would be nice to have any controller that can be hung on a DIN-rail, connect devices to it via RS-485 and transfer data via Ethernet to a SCADA system.
In general, some hardware gateways are in considerable quantity. But in the form of ready-made indivisible solutions. All in one. And I don't really like it. I once needed a gateway that converts the protocols of the SET-4TM counters to OPC UA with six RS-485 ports and two Ethernet. One vendor has a gateway that supports the necessary exchange protocols, but few RS-485 ports, the other has the right number of RS-485 ports, but not two Ethernet ports. The third has two Ethernet ports, but there are no all exchange protocols. The fourth one has almost everything, but there is no OPC UA available on board IEC-60870-5-104 or ModBus-TCP require an OPC server for these protocols.
And how wonderful it would be: buy a controller or a mini-PC with OS from one manufacturer. Buy software for the controller from another. If one software vendor does not support something, purchase something from the software from another, merge the software components together via a standard software interface. It would seem that here it is a bright future!
That is why protocol gateways are used less often than a bunch of “OPC server and Ethernet Converter to RS-485” - because of their indivisibility into components.
One of the reasons why SCADA for Linux is underdeveloped: there is SCADA, it doesn’t support exchange protocols, and there are no OPC servers for communicating with the equipment. SCADA leaves the integrator one on one with iron.
The reader may already ask the question: What can you offer? What is already there? There are OPC UA servers for Linux for the following protocols:
- IEC 60870-5-104;
- IEC 60870-5-101;
- Counters Mercury 230, 231, 233, 234, 236 ;
- Counters СЭТ-4ТМ, ПЧЧ-3ТМ, ПЧЧ-4ТМ ;
- Energomera counters ;
- SNMP ;
- MQTT ;
- Counters Mercury 200 .
In order to transfer data to the upper level not only via the OPC UA protocol, the “ OPC UA to Modbus Converter and IEC 60870-5-104 ” was created. In addition to the data transfer function for these protocols, the “Converter” has an embedded web-server. With the help of a special editor, you can draw a diagram, display the tag values on it, and then open it in the browser. It turns out mini-SCADA directly in the controller. As scheme revival works I already wrote here , about the editor here . In the future, it is planned “OPC UA to MQTT Converter”.
OPC UA servers and converter work on x64, ARMv7 and AARCH64 architectures.
Thus, for hardware, you can use both time-tested solutions based on mini industrial computers and various “raspberry pi compatible” ARM minicomputers. How to install and configure software with examples you can read here or here .
In general, the structure of the complex looks like this:
The system has scalability. Components necessary only for the solution of the current task are used.
With the use of the OPC UA server, our scheme is converted:
We have the following:
- OPC UA server collects data from devices via RS-485 without long delays between requests;
- The data in SCADA is issued in several pieces in a single TCP packet for change;
- It is possible to connect several equally configured workstations to the OPC UA server. It is useful if you need duplication.
Thus, instead of the OPC server and Ethernet Converter to RS-485, we get one device that combines their functionality. I like this scheme more. And you?