Protocols About 2 min read

Modbus family

Modbus exchanges values using function codes and addresses. Use the device's register map to interpret data types, byte order, units and permitted operations.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Inherited check dated 10 September 2026. Supporting evidence for this inherited check has not been independently confirmed.

Recorded scope: The Modbus Organization specification index, application specification version and Security transport summary were checked. Device register maps remain product specific.

Covers the public application specification and transport relationships; device register maps and product limits are vendor specific.

Verification and testing

Overview#

Modbus defines a compact application protocol above several transports. Its logical data areas are coils, discrete inputs, input registers, and holding registers. The standard defines protocol data units and function semantics; it does not define what register 40001 means for a particular panel, lift, meter, or controller.1

Layering#

text
device meaning and register map     vendor/product profile
function code + addresses + data    Modbus PDU
serial address + CRC                Modbus RTU ADU
or transaction/unit header          Modbus TCP ADU
or TLS-protected TCP                Modbus Security transport

Read Modbus RTU, Modbus TCP, and Modbus Security for transport specific behaviour.

Data model traps#

  • Protocol addresses are zero based fields. Human facing documents often use 0xxxx, 1xxxx, 3xxxx, or 4xxxx reference notation. Store both the original notation and the on wire address; never guess an offset.
  • A register is 16 bits, but multi register integers, floating point values, text, byte order, word order, scaling, signedness, and sentinel values are profile specific.
  • Read/write access and function support are device specific. An address responding to a read doesn't establish that writes are safe.
  • Exception responses are protocol outcomes, not transport failures. Preserve the exception code and request correlation.
  • A successful write response proves protocol acceptance, not physical completion or safe actuation.

Adapter contract#

For every point, record unit/slave identifier, function, zero based address, width, encoding, scale, unit, access, poll interval, stale threshold, validity rules, write interlocks, and source document revision. Decode into a value plus quality and source timestamp. Retain an explicit unknown state.

Coalesce only adjacent reads with identical access semantics and within both the protocol limit and the device's documented maximum. A theoretically legal large request can still overrun a small gateway. Bound outstanding requests, randomise reconnect backoff, and prevent fleet wide synchronised polling.

Security and safety#

Classic Modbus provides no cryptographic peer identity, confidentiality, or authorisation. Treat network location and unit identifier as routing hints, not identity. Segment the path, allowlist exact peers and function codes, make write capability opt in, and monitor new unit IDs, write functions, scan like address patterns, and exception rate changes. Prefer Modbus Security when all endpoints support it, while retaining application authorisation and engineering controls.

Never use exploratory writes on production equipment. Reads can also cause load or interact with fragile gateways. Bench test against a documented register map, then deploy with an asset owner approved poll budget and rollback plan.

Primary sources#

Section overview · Wiki home

  1. Modbus Organization, Modbus Application Protocol Specification V1.1b3 ↩