# Rethinking Modbus-UDP for Real-Time IIoT Systems
## 2 Related Work  
The first part of this section discusses the relevance of Modbus for the IIoT and, more generally, Internet of Things (IoT) applications, as well as the recent research in this regard. The second part highlights the importance of broadcast communication in Modbus and of automatic datagram retransmission when UDP is used as transport. It then surveys the main Modbus implementations and briefly discusses the use of QUIC as an alternative to TCP. The last part overviews Modbus security and how this important issue can be addressed. Although, as outlined in the Introduction, Modbus initially targeted single- or multi-drop serial buses, it then evolved into a protocol that can be used in any network that supports TCP transport, which includes most communication networks available today and, in particular, Ethernet-based networks. Since its inception, it has been used in a wide variety of IoT [15; 16] and IIoT [17] systems due to its relative simplicity and its modest computing and network resource requirements. Other recently proposed applications of Modbus, a testimonial to its longevity, are about universal testing machines [18] and terminal asset identification in Power IoT systems [19]. Furthermore, ref. [6] describedin detail the experimental validation of an IIoT architecture, highlighting the widespread use of Modbus-TCP at the network layer in the advanced industrial scenarios foreseen by Industry 4.0. Notwithstanding its long history, the Modbus protocol and its evaluation are still a research subject, ranging from tools for schedulability analysis [20] to scalability evaluation for the management of distributed energy resources [21] to the use of supervised machine learning to decode the protocol automatically [22]. Significant research has also been devoted to studying and improving the performance of Modbus-TCP \(\leftrightarrow\) Modbus-RTU gateways [23] by introducing an enhanced version of UDP (AUDP) based on the advanced statistical analysis of the UDP protocol. Although the cited work does not explicitly undertake broadcast communication support, gateways and middleware similar to the ones it describes could be profitably used to take advantage of the protocol proposed in this paper without necessarily implementing it on every end node. Further extensions to the Modbus protocol are still being proposed [24] and evaluated [25] as well. A remarkable aspect of the protocol extension just cited [24] is that it relies on Modbus broadcast--the feature that Modbus-TCP is lacking--to synchronize slaves and send commands to them all at once (for instance, the request to start a data acquisition cycle) in an efficient manner. Other practical applications of broadcast messages, beyond the master election protocol mentioned previously [13], include the efficient delivery of alarms and debug messages [26]. Due to its widespread adoption, the Modbus protocol is available for a variety of general-purpose platforms and programming languages, ranging from C [9] to Java [10] and PHP [27]. Other more specific Modbus libraries, like FreeMODBUS [28] and Modbus Master[29], are tailored to embedded systems. Due to their focus on execution efficiency, small footprint, and suitability for real-time applications, these are the libraries that were used for the experimental evaluation presented in Section 4. However, to the extent of the author's knowledge, all the implementations of the Modbus protocol mentioned so far either do not implement Modbus-UDP [28; 29] or implement it merely by sending and receiving standard Modbus-TCP messages as UDP datagrams [9; 10; 27]. They support neither broadcast nor datagram loss detection and subsequent retransmission. Starting from 2012, the QUIC protocol [30] has been adopted, especially for HTTP data transfer, as a higher-performance alternative to TCP. All the major web browsers currently support it, and it carries an ever-increasing share of web traffic [31].