# Rethinking Modbus-UDP for Real-Time IIoT Systems
## 1 Introduction  
The original versions of the Modbus protocol [1], Modbus-RTU and Modbus-ASCII [2], were designed as strict master-slave protocols for RS-485 [3] and RS-232 [4] serial buses. Each Modbus transaction starts with a unicast or broadcast request sent by the master. The addressed slave responds to a unicast request by transmitting a reply back to the master. Most broadcast requests do not evoke a response from any slaves or, in the case of more complex broadcast-based transactions, such responses are not in a one-to-one relationship with the request. When working with these serial buses, broadcast communication is readily implemented by relying on the fact that the underlying physical medium inherently broadcasts all the messages to all the connected stations. Transactions are uniquely identified by a function code and typically involve the transfer of a number of _registers_ between the master and the slave. A register is a 2-byte-wide entity that is the basic data transfer unit in Modbus. As an example, Figure 1 shows the Protocol Data Unit (PDU) format of two Modbus transactions, _Read Holding Register_ (RH) and _Write Multiple Register_ (WM). In an RH transaction, the master communicates to the slave, in addition to the function code, the starting address and the number of registers \(N\) it wants to read. In its reply, the slave sends back the same function code, a byte count, and the content of the requested registers. Symmetrically, in a WM transaction, the master sendsa function code, the starting address, and the number of registers being written, followed by a byte count and the registers' content. The slave acknowledges the request by sending back a summary of the request. As shown at the bottom of Figure 1, Modbus PDUs are preceded by a header that contains addressing and other transport-dependent information. As reported in [5] and, more recently, in [6], the Modbus protocol is widely used at the Network layer of the typical four-layer IIoT architecture outlined in Figure 2 for wired data exchange among IIoT nodes. In complex systems, its usage may also extend partly into the Sensing layer (also called the Perception layer), where it serves as a local bus that links, for instance, multiple sensors to a single Programmable Logic Controller (PLC). Both Modbus-RTU and Modbus-ASCII supported broadcast transmission, that is, the possibility of sending the same message to all the slaves connected to the same bus by means of a special slave address, address zero. As the protocol was ported to other bus types, for instance, with the definition of the Modbus-CAN protocol [7], this capability was retained until the protocol further evolved into Modbus-TCP [8] to support TCP-based networks. At that point, support for broadcast messages was dropped, likely due to the inherent point-to-point nature of TCP connections and the shift of the protocol from a master-slave towards a client-server architecture, in which slaves take the role of servers and the master is the client. In that scenario, simulating a broadcast transmission would have entailed transmitting multiple identical messages, one for each active master-slave connection, which would have been inefficient from the network utilization point of view. Figure 1: Typical Modbus PDUs and transport-dependent headers (field width not to scale). Figure 2: Typical four-layer IIoT architecture with its associated software and hardware. The layers where Modbus is currently employed are highlighted in gray. Later proposals defined the Modbus-UDP protocol [9; 10] but did not reinstate the broadcast transmission capability in spite of the fact that UDP, the underlying transport layer, readily supported both multicast and broadcast communication. In addition, to the extent of the author's knowledge, those proposals did not define any built-in mechanism for the automatic retransmission of UDP datagrams and left datagram loss detection and recovery to the application layer.