Modbus Data Model, Transactions & Transport

Modbus is a compact application protocol for reading and writing device data. Its simplicity is also its main integration trap: the protocol standard defines tables, function codes, addresses, and response rules, but it does not give a register a universal engineering meaning. The device data map is a second contract that must define value type, units, scaling, access, consistency, and multi-register layout.

Four logical tables #

The four-table model is conceptual. A device can implement separate storage for every table, overlap them over the same underlying data, or omit tables and ranges. “Read-only” and “read/write” describe the intended table semantics, not a physical memory technology.

PDU, ADU, and transport #

The transport-independent protocol data unit (PDU) is:

function code | function-specific data

The Modbus application protocol limits the PDU to 253 bytes. A transport wraps it in an application data unit (ADU):

On TCP, the length field makes framing explicit because TCP is a byte stream and does not preserve message boundaries. A receiver must accumulate a complete ADU and must not assume one socket read equals one Modbus response. The transaction identifier relates a response to its request when several requests share a connection.

The TCP unit identifier is especially relevant when a TCP-to-serial gateway routes the request to a downstream serial server. On a direct native TCP server it may have product-specific handling; it must not be mistaken for the IP address.

A read transaction #

To read three holding registers beginning at protocol address 0x006B, the PDU is:

request:  03 00 6B 00 03
          │  └address┘ └quantity┘
          └ read holding registers

response: 03 06 02 2B 00 00 00 64
          │  │  └──── three 16-bit registers ────┘
          │  └ byte count
          └ function code

This only proves that six data bytes were returned. Whether they mean three integers, a 32-bit floating-point value plus a status word, or something else comes from the device map.

Registers are not application types #

A Modbus register is exactly 16 bits at the protocol boundary. The following are outside the universal data model and therefore require an explicit device contract:

• signed versus unsigned interpretation;
• scale and offset, such as raw 253 meaning $25.3\ ^\circ\text{C}$;
• unit and valid range;
• text encoding and string termination;
• order of 16-bit registers within a 32- or 64-bit value;
• byte order inside a register when a device exposes a nonstandard interpretation;
• whether a multi-register value is captured atomically;
• sentinel values and quality/status registers.

There is no protocol-level “Modbus float endianness” setting that is correct for every device. Name the exact mapping, for example IEEE-754 binary32, high-order register first, big-endian bytes within each register, and test with a value whose byte pattern is known.

Normal response, exception, timeout #

A normal response echoes the request function code. A protocol exception sets the high bit of that function code and returns a one-byte exception code:

request function:    03
exception function:  83
exception data:      02   (illegal data address)

An exception is a valid Modbus response: the server understood enough of the request to reject it. A timeout, TCP reset, CRC failure, truncated frame, or mismatched transaction ID is a transport or framing failure. Operations and retry policies should preserve this distinction.

Retries also depend on operation semantics. Repeating a read is normally safe. Repeating “write this value” is often idempotent, but repeating a vendor command encoded as a register write may trigger an action twice. Do not automatically retry a write unless the device contract says the operation is idempotent or provides a way to reconcile its result.

Consistency and polling #

Reading several consecutive registers in one request reduces overhead but does not automatically guarantee that the underlying process values came from one coherent sample. The server may update its data between register accesses unless it documents snapshot behavior. For counters, timestamps, energy totals, and 32-bit values on a 16-bit device, use the vendor's atomic block, latch command, sequence counter, or consistency procedure.

Poll rate is a system design decision. Account for serial baud rate or TCP server capacity, number and size of requests, worst-case response latency, retries, gateway queues, and the freshness actually required. Fast polling cannot make a slowly updated device value fresher; it only repeats the same sample and consumes capacity.

Security boundary #

Classic Modbus does not by itself authenticate the peer, authorize individual operations, or protect request confidentiality and integrity. Network placement, authenticated gateways, strict allowlists, monitoring, and least write access therefore matter. The Modbus organization also publishes a separate Modbus Security protocol using TLS and X.509 credentials; support for classic Modbus TCP does not imply support for that security profile.

Integration checklist #

• Record the table and zero-based protocol address separately from the manual's printed reference.
• Specify type, scale, unit, range, word/byte order, write semantics, and consistency rules.
• Validate MBAP length and transaction ID on TCP; validate address, timing, and CRC on RTU.
• Treat exceptions, timeouts, malformed frames, and stale values as different states.
• Set polling and retry behavior from device capacity and operation semantics.
• Test known patterns, boundary addresses, exception responses, disconnects, and gateway routing.