Modbus (RTU / TCP)

Modbus was developed by Modicon (now Schneider Electric) in 1979 for PLCs. Because it is open and royalty-free, it became the common language of industrial automation. The specifications are published by the Modbus Organization. It follows a master/slave model, now called client/server: the client sends a request and the server device replies. Servers never send data on their own initiative.

There are two main variants. Modbus RTU runs over an RS-485 (or RS-232) serial line using binary frames with CRC-16 error checking, with devices addressed from 1 to 247. A standard RS-485 segment supports 32 unit loads without repeaters, and cable runs can reach about 1,000–1,200 metres at low baud rates. 120 Ω termination resistors should be fitted at both ends. Modbus TCP uses TCP port 502 over Ethernet, relies on TCP instead of a CRC, and uses the Unit ID field to reach RTU devices behind a gateway.

The data model has four tables: coils (read/write bits, function codes 01/05/15), discrete inputs (read-only bits, code 02), input registers (read-only 16-bit values, code 04) and holding registers (read/write 16-bit values, codes 03/06/16). A common field problem is an off-by-one error between the 1-based notation in documentation (e.g. 40001) and the 0-based address on the wire. Vendor-specific byte/word order for 32-bit integers and floats spread across two registers is another. Forgetting scale factors (e.g. ×0.1) that must be applied to raw values is also frequent.

Modbus has no authentication or encryption. Modbus TCP ports must never be exposed to the internet, and traffic should be isolated with VLANs or VPNs. A TLS-based Modbus/TCP Security specification exists but is not widely deployed. In IoT projects, a gateway polls Modbus devices periodically and forwards the data to the cloud via MQTT, or over LoRaWAN or NB-IoT from remote sites. Polling intervals and timeouts should be tuned to the number of devices on the line.