Abstract
Background
In industrial disasters, early detection of problems and crisis management are critical for saving the lives of people and reducing the impact of disasters.
Purpose
In this study, we design a special gateway system that bridges the gap between different communication protocols and enables legacy supervisory control and data acquisition systems to function early detection systems for potential industrial disasters.
Methods
The system uses a new queue mechanism to substantially improve the problem of data loss found in conventional supervisory control and data acquisition systems and utilizes identification (ID) prioritization to enable early detection of problems. The proposed system is implemented and tested on a Linux-based, 3G-capable Modbus gateway system. Modbus is used as the communication protocol and 3G technology is utilized to provide high-speed wireless data transfer components. The Modbus gateway device uses an ARM-based EP9302 processor and has digital input/output, relay outputs, and RS485 outputs.
Conclusion
This study is significant as it is the first work to show the application of the priority query execution method for Modbus gateway devices.
Keywords
Introduction
SCADA (supervisory control and data acquisition) systems are a type of industrial control system widely used in virtually all industrial plant and production facilities to monitor and control industrial processes. They are critical for increasing the efficiency of processes and detecting possible problems in facilities. SCADA systems use RTUs (remote terminal units) or PLCs (programmable logic controllers) to collect measurements and equipment status data. The collected data are compiled, formatted, and presented to a control room operator using a special dashboard that enables supervisory decisions to adjust or override normal RTU controls. The main application of SCADA is alarm handling—the SCADA system monitors whether certain alarm conditions are satisfied or not.
Early SCADA system computing was done using large minicomputers. Common network services did not exist at the time SCADA was developed. Thus, SCADA systems were independent, with no connectivity to other systems, and the communication protocols were strictly proprietary. In second-generation SCADA systems, information and command processing were distributed across multiple stations, which were connected through a local area network. Each station was responsible for a particular task, which reduced the cost compared to the first-generation systems. Information was shared in near real time but the network protocols used were still not standardized. In third-generation SCADA systems, similar to a distributed architecture, several distributed SCADAs run in parallel, with a single supervisor. More recent SCADA systems—fourth-generation systems - have the ability to report in near real-time. Fourth-generation systems also use the horizontal scaling available in cloud environments to implement more complex control algorithms, which are not practically feasible using traditional PLCs. 1 – 3
Although current SCADA systems have many improvements compared to earlier SCADA systems, current systems still suffer from proprietary communication protocols and data loss issues in the collection process. 4 In this study, we develop a Modbus gateway-based system that addresses communication protocol and data loss problems and works as an early detection system. Modbus gateway devices provide a convenient solution for connecting existing RTU devices to a SCADA network and are one of the most important components of SCADA systems. We use a Modbus gateway to bridge different proprietary protocols in SCADA systems and to implement a queue mechanism with ID prioritization to address data loss problem and to improve early detection of problems.
In the literature, a few Modbus gateway devices have been studied for use in remote monitoring and control systems for industrial applications. The first design of these studies, which uses an embedded Linux operating system and Modbus protocol, was implemented by Flores and Campos. 5 These authors produced a Modbus gateway device with 3G access. Another study that utilized a Modbus protocol with a PowerPC processor for remote monitoring and control platform was that of Tamboli et al. 6 In the work of Wang et al., 7 a remote monitoring smart home system was presented using an ARM9 processor and 3G technologies. The early detection gateway system can also be extended to networked control systems, in which early detection of malicious attacks in the data transmission process from RTU units is important.10–12
In the current study, an embedded Linux-based Modbus gateway system is implemented using an ARM-based EP9302 processor for data collection, remote monitoring, and control. The control center uses a Modbus protocol to access RTU units over the RS485 port of a Modbus gateway device. The responses that come from the RS485 port of the Modbus gateway are sent to the control center via GSM (Global System for Mobile) or ethernet infrastructure. The proposed system improves legacy SCADA systems by integrating a standard communication infrastructure and by introducing a lossless data collection process. The proposed system is significant as it is the first work that shows the application of the priority query execution (PQE) method in a Modbus gateway device.
The rest of this paper is organized as follows. Section “Design of the system” reviews the design of the Modbus gateway device with the Modbus protocol. In section “Software design of system,” software design of the Modbus gateway device is described in detail. Section “Hardware design and testing” first introduces the hardware platform and the test environment and then presents the test results. Section “Conclusion” concludes the paper.
Design of the system
In this study, a Linux-based, 3G-capable Modbus gateway device is designed to remotely monitor and control the RTUs in a SCADA system. The SCADA architecture is illustrated in Figure 1. Modbus is used as a communication protocol and 3G technology is utilized to provide a high-speed wireless data transfer infrastructure. The Modbus gateway device uses an ARM-based EP9302 processor and has digital I/O, relay outputs, and RS485 outputs. The open-source embedded Linux operating system is used to solve the increased design complexity due to the use of Modbus TCP and Modbus RTU protocols, and 3G technology.
designed SCADA system.
The designed Modbus gateway device consists of an embedded Linux board with a Modbus protocol feature. The 3G modem connection structure is used to provide Internet access and a Sim5218 development board is used as a 3G modem. The Modbus gateway device communicates with the 3G modem over a USB connection. In order to enable USB connection, the USB driver on the Linux board is activated as a module while compiling the kernel.
The designed system communicates with the SCADA system using Modbus TCP and Modbus RTU modes. The Modbus gateway device acts as a converter between Modbus TCP and Modbus RTU modes. For communication over the Internet, a 3G infrastructure is used; for communication with RTUs (transmission mode), an RS485 infrastructure is used. The Modbus gateway device operates in server mode. The gateway device operates as a master in Modbus RTU mode and as a slave in Modbus TCP mode. As a master, the gateway sends out the request data; as a slave, it responds to the request after receiving the correct data. The data packets received in Modbus TCP mode are from clients. This process is illustrated in Figure 2, where it is shown that the input or output can be a query in Modbus TCP mode. The RTU devices can be queried by converting the Modbus TCP data package to the Modbus RTU data package. To respond, the Modbus RTU package must be converted to the Modbus TCP package.
Modbus gateway device in Modbus protocol.
Communication infrastructure design
In this study, the Modbus protocol is used for communication. Modbus is an open, serial messaging protocol that is used to establish communication between devices connected together in the same network. It was first introduced by Modicon in 1979. Since then, due to its simplicity and robustness, Modbus has become a de facto standard communication protocol connecting electronic devices in industrial automation systems. 8
Like most communications protocols, Modbus devices communicate using a master–slave (client–server) technique, in which a single Modbus master controls all of the other devices on a network. In the Modbus protocol only one device—the master—can request information (or initiate queries) from up to 247 slaves using a serial connection, either RS485 or RS232. The slaves decode the query and send back a response with the requested data or by taking the action requested in the query. The master device can send a message to slaves individually or can broadcast a message to all slaves. Slaves respond to all queries addressed to them serially, but do not respond to broadcast messages. The master can also write information to the slave devices using the RS485 or RS232 serial connection.
The Modbus protocol has three different transmission modes: Modbus TCP/IP is used to communicate over the Internet infrastructure; Modbus RTU and Modbus ASCII are used for serial communication. The selected transmission mode defines the communication infrastructure, available functions, encoding scheme, data package structure, and how the message is decoded. Detailed information about Modbus RTU and TCP modes is available in the Modbus reference guide. 9
Software design of system
In order to bridge communications between different protocols and provide more reliable data transfer, a Modbus gateway device is used with a new queue mechanism and an ID prioritization approach. To prevent any data loss, data packets that come from the client are sorted into two different queues according to their slave IDs and their time spent in the queue. Then, the queries are answered by ID in the queue that holds the queries that have waited for longer than a predetermined time. In this way, the Modbus gateway device has a more reliable query operation on the Modbus protocol using 3G communication techniques. This feature assists in the reliable detection of possible problems to identify potential industrial disasters.
The general requirements of the designed Modbus gateway device are given as follows:
The Modbus gateway device must work as a master in Modbus RTU mode and as a slave in Modbus TCP mode.
The queue created using the ID parameter must be checked periodically. The checking period is defined by the user.
When checking the queue, if any if the queries have timed out, take this devices queries to the second queue.
The second queue has priority over the first one.
The following software algorithm and techniques are used to satisfy these requirements:
For accepting the connections from clients, a sufficient number of socket must be open.
For connection requests and responses, the multi-thread feature of the operating system is used.
The Modbus TCP packet is converted to a Modbus RTU packet.
The Modbus TCP request is added to the queue using the slave ID value.
Requests that come from clients are added to the queue and these requests are responded to using a thread mechanism.
A mutex mechanism is used to avoid the risk of adding and deleting elements in the same queue at the same time.
The connections that come from clients are accepted by the open sockets. First, a sufficient number of sockets for clients to connect is estimated, and these sockets are set to the listen() function. Send() and recv() functions are used to send and receive data over the socket architecture.
The Modbus RTU request and response package flow is given in Figure 3. In the query package, the function code notifies the addressed slave device what action to perform. The data contain any additional information that the slave needs to perform the function. The data field must contain the information telling the slave which register to start at and how many registers to read. The error check field provides a method for the slave to validate the integrity of the message content. In the response package, if the slave makes a normal response, the function code in the response is an echo of the function code in the query. The data contain the information collected by the slave, such as register values or status. If an error occurs, the function code is modified to indicate that the response is an error response, and the data bytes contain a code that describes the error. The error check field allows the master to confirm that the message contents are valid. 9
Modbus RTU request and response packages.
The client can connect to the Modbus gateway device and request any query from RTUs over the Modbus protocol. The system uses a thread mechanism to accept the request and to add it to the queue and to respond to these queries efficiently. The queue is created by the link list mechanism. This mechanism is used to add the request to queue, ordered using the slave ID value in the Modbus TCP package. Figure 4 shows the thread mechanism that is used for enqueuing and dequeuing processes. The query array includes RTU slave IDs 1, 3, 3, 6, 9, 10, and 15. In this array, there are two successive queries for RTU slave ID 3, as it is possible to see more than one query for the same RTU by the same or different clients. While retrieving data, the mutex lock mechanism is used to eliminate the risk of writing to and deleting from the same memory at the same time.
Using the thread mechanism for enqueue and dequeue process.
The enqueue process that is made by the list_add() function is shown in the block diagram in Figure 5.
The block diagram of enqueuing requests by slave ID value.
Requests are queued by slave ID value, ordered from low value to high value. Response order always starts from the first element of the queue. Because of responding to prioritized RTUs in this queue, the requests from other RTUs may not receive a response in the predefined time frame. As such, these requests may reach a time-out situation. Due to this time-out risk, the queue created based on slave ID is checked periodically at predefined time intervals. At this point, elements that have passed their time-out value are taken to the second queue, the time-out value being defined as the maximum time for being in the first queue. Responses to the second queue have priority over those to the first. Applying this feature to the system, the mechanism of inquiry has been made more secure.
In Figure 6, the checking period of the queue is defined as 1500 ms, and the maximum time for being in the queue is 50 ms. In Figure 6, it is seen that if any of the slave ID queries in the queue are taken to the second queue, the two queues are refreshed. After adding the request to the second queue, it is deleted from the first queue. This process is done using the Modbus gateway device.
Checking the queue periodically and refreshing queues.
Hardware design and testing
The hardware design of the system is shown in Figure 7. The designed device has a CPU module on the development board and the peripherals on the development board are used for digital inputs, digital outputs, relay outputs, and RS485 units.
The designed Modbus gateway system.
After the design of the software and hardware, the Modbus gateway device is ready for testing. The hardware used for testing the device is shown in Figure 8.
The device in the test environment.
For test application, the Modpoll program is used to query the connected RTUs and integrated inputs and outputs as a client. In Figure 9, querying of two RTU device parameters and integrated inputs and outputs with Modpoll by a client is presented. The ID parameter and querying period can be seen.
Query of integrated inputs and outputs and RTU by a client with Modpoll software.
In order to show the query operation by clients, a computer is connected to the Modbus gateway device, where telnet is used as a terminal. In this query operation, it can be understood that RTU IDs are 1, 2, and 3. A query list is created on the Modbus gateway device for query operation. After answering each query, that query is deleted from the list. To avoid a query not being responded to within a defined time period, a periodic checking of the queue to examine each RTU ID is added. Using this checking process, if any of the RTU IDs exceed their predetermined time limit for being in the queue (determined by the user), this RTU ID is taken to the second queue.
The periodic queue check occurs every 1500 ms; if any of the RTU IDs have been in the queue for longer than the time determined by the user, then this slave ID is added to the second queue. The second queue has priority over the first queue. The two queue mechanism provides more reliable query operations.
Conclusion
In this study, the design of a Modbus gateway device for remotely monitoring and controlling the RTUs in legacy SCADA systems is explained. 3G technology is used to provide high-speed data over wireless communication with a control center. Modbus TCP and Modbus RTU modes are used to communicate in a standard way with RTUs. The designed Modbus gateway device uses a queue technique to prevent data loss in query operations and provides ID prioritization to achieve early detection of possible disasters. The proposed early detection system is important as it demonstrates the first application of the PQE method into Modbus gateway devices.
The next steps for modernization are eliminating the delay of query responses to geographically distributed RTUs and developing prioritization techniques to identify the most critical RTUs to allow for near-real-time disaster detection and monitoring. Application of prioritization mechanisms to large SCADA systems (combination of several sub-SCADA systems) is another potential area of study.
Footnotes
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.