Modbus Unit Identifiers and Broadcasts: Routing TCP Requests onto an RTU Bus

A TCP connection identifies a gateway, but it does not necessarily identify the instrument behind that gateway. The MBAP Unit Identifier supplies a routing value whose meaning depends on the endpoint. Confusing that value with a universal device address creates a particularly misleading failure: an intentional serial broadcast is forwarded correctly, then reported as a timeout because no instrument replies.

This guide uses Modbus Application Protocol V1.1b3, Serial Line V1.02 and TCP/IP Implementation Guide V1.0b. The routing policy and checks below are proposed integration practices. They are not measurements of a particular gateway, and the product manual remains necessary for vendor-specific mappings.

Separate endpoint selection from downstream addressing

Write the destination as a tuple: gateway IP address, TCP port, configured serial segment, Unit Identifier and function. Two serial segments can each contain slave address 7 without identifying the same device. A gateway therefore needs enough configuration to choose the segment before the serial address becomes meaningful.

The TCP implementation guide, sections 3.1.3 and 4.4.1, places Unit Identifier in MBAP and describes its use through gateways. For a directly connected TCP server, the guide recommends the nonsignificant value 0xFF and also accepts zero. Consequently, Unit ID zero at a native TCP endpoint is not automatically a serial broadcast. Classify the endpoint before applying serial rules.

Make the mapping visible and reject ambiguous routes

For a simple bridge, Unit ID 7 may map to RTU address 7 on one configured port. A product may instead use a routing table. Record both values in diagnostics rather than logging only “device 7.” Include the configuration revision so a support engineer can interpret a capture taken before a mapping change.

The serial specification, sections 2.1–2.2, assigns individual slave addresses 1–247, reserves zero for broadcast, and reserves 248–255. Do not pass 255 through as a normal serial address merely because a TCP client uses it by default. Likewise, do not silently redirect an unmapped identifier to the first available slave. Prefer a documented local rejection that leaves the serial bus untouched.

Treat broadcast as a separately authorized operation

A serial broadcast is a writing request for all participating slaves, with no response. A read request to address zero cannot collect simultaneous answers. Do not discover broadcast support by trying writes on a production bus. Use a simulator or an isolated, explicitly approved test segment with harmless writable objects.

Define an allowlist covering the downstream segment, function and register range. A mixed installation may assign different meanings to the same register offset, so even a syntactically valid broadcast can change unrelated settings. Keep broadcast disabled when the inventory or register compatibility is unknown. Client access to unicast writes should not automatically grant access to all-device writes.

Define what the TCP caller will observe

The serial specification defines the absence of a slave response; it does not make a gateway-generated TCP acknowledgement proof of execution by every device. Products differ in whether they reject such requests, expose a special operation, or return a locally synthesized result. Document the actual behavior and label any local result with its origin.

Distinguish “accepted into gateway queue,” “serial transmission completed” and “device state verified.” A TCP send succeeding proves none of the last two. If the client library insists that every request must receive a normal Modbus reply, verify a compatible gateway contract before enabling broadcast. Otherwise a scheduled no-response operation may trigger repeated writes through the library’s generic retry path.

Keep turnaround separate from a response deadline

After serial broadcast transmission, the master allows a turnaround delay so slaves can process the request before the next exchange. This is a different state from waiting for a unicast reply, as shown in the Serial Line V1.02 master state model, section 2.4. Its duration must cover the documented devices and operation; it is not a universal constant selected from TCP latency.

The scheduler should therefore release the request through a broadcast-specific completion path, then respect the configured turnaround before another serial request. Do not replace this delay with the RTU frame-separation interval. One protects processing readiness; the other identifies frame boundaries. Record each independently in the configuration review.

Exercise boundary values without unsafe output changes

Build a route-test fixture with two simulated segments and known slave addresses. Send a safe unicast read to each supported route and capture the TCP identifier, selected port and emitted serial address. For an unmapped identifier, confirm that no serial bytes are emitted. Test zero, one, 247, 248 and 255 explicitly rather than only a convenient middle address.

In the isolated broadcast fixture, use an approved write and verify that the gateway does not wait for a slave response or retry because that response is absent. Then follow with a unicast request to check scheduler release after turnaround. Observe each simulated slave’s state independently; a quiet bus alone does not establish whether any slave accepted the write.

Accept a routing contract, not just a successful demo

• Every upstream endpoint and identifier resolves to an explicit segment, slave or documented rejection.
• Native TCP special values and serial reserved addresses are handled in the correct context.
• Broadcast scope, allowed writes, result origin and retry policy are visible to the caller.
• Turnaround timing is configured separately from unicast response deadlines.
• Unknown routes and forbidden broadcasts produce no downstream side effects.

Keep the route table, gateway firmware revision, client settings and fixture captures together. This evidence explains what the gateway promised and what it actually forwarded. It cannot certify delivery to every broadcast recipient; that requires device-specific observation and an application-level verification plan.