Modbus tells you where, not what

Most gateway projects begin as a transport question. There is equipment on a plant floor speaking an industrial protocol, there is a system somewhere that wants the data, and the request is to connect the two. Phrased that way it sounds like plumbing, it gets scoped like plumbing, and the part that consumes the schedule is not plumbing at all.

Consider what a Modbus device actually offers. It answers a request for a register and returns a value. Register 40007 holds 8,192. That is the complete content of the exchange. Whether 8,192 is a temperature in tenths of a degree, a flow in some unit chosen by an engineer in 1998, a bitfield of alarm states, or the top half of a 32-bit counter whose bottom half lives in 40008, is not in the protocol, not in the response, and frequently not in any document currently in the building.

This is not an accident of the protocol, it is the design¶

The Modbus application protocol specification (opens in a new tab) is explicit. It defines four primary tables (discrete inputs and coils as single bits, input registers and holding registers as 16-bit words) with each element addressed from 0 to 65535, and it then says that the data model has to be bound to the device application, giving an IEC 61131 object as the example of what it might be bound to. The binding is somebody else’s job by construction. The protocol is a way to name storage, not a way to describe a plant.

Two consequences follow and both are load-bearing. The first is that any quantity that does not fit in sixteen bits is carried by convention. A 32-bit float occupies two registers, and which register holds the high word, and which byte within a word comes first, is a decision each vendor made independently. The specification fixes byte order on the wire, so 0x1234 sends 0x12 first, and says nothing about how a vendor spreads a float across two of them. That is why the standard first-day failure on these networks is a value that is correct to four significant figures when read one way and astronomically wrong when read the other, and why byte-order options exist in every gateway product on the market.

The second consequence is the one with money attached. Because there is no type, there is no unit, no scale, no valid range, no name and no notion of quality. A reading that is stale, because the device beneath the controller stopped responding twenty minutes ago and the register still holds its last value, is indistinguishable from a live one. Nothing about that is a defect in Modbus. It is a protocol from 1979 doing precisely what it was designed to do, on plants where it will still be doing it in twenty years, and it should not be replaced merely for being old.

Where the meaning goes¶

Somebody has to say that 40007 is a discharge temperature in tenths of a degree Celsius, valid between minus forty and one hundred and fifty, sampled by controller 3, and stale if it has not changed since the controller last reported healthy. There are only three places that sentence can live, and choosing between them is the actual architectural decision inside a gateway project.

1. 1.In each consuming system. The cheapest first delivery and the most expensive estate. The historian, the dashboard, the maintenance system and the analyst’s notebook each grow their own copy of the scaling table, they drift, and when a plant engineer swaps a device and shifts a register block, the number of places that must change is the number of consumers, discovered one wrong report at a time.
2. 2.In the gateway. One team owns one model, the ambiguity is resolved once, close to the equipment, by the people who can walk out and look at it, and what leaves the edge is named, typed, scaled and stamped. This is the answer that is right in most plants, and it is the one that costs more in week two.
3. 3.In the device. Correct where the equipment is new enough to offer a real information model, and unavailable on the installed base that the project actually has to work with, which is why it is usually the answer to the next capital project rather than to this one.

What the model-carrying protocols are actually selling¶

OPC UA and MQTT with Sparkplug (opens in a new tab) belong in this argument at a place they are not usually put. They are not faster or more modern wires. They are places to put the decision above, with the shape of the answer already fixed.

Sparkplug is the clearer illustration because its session model is small enough to state. An edge node publishes a birth certificate when it comes online, which carries the definitions of the metrics it is about to report, so a consumer that connects later learns what the values mean from the infrastructure rather than from a spreadsheet. It registers a death certificate as the broker’s Will message, so a node that disappears is announced by the broker rather than inferred from silence. Both of those exist to answer questions that polling a register cannot: what is this, and is the thing that produces it still alive.

That is a genuine gain, and it is worth being precise about what it costs. It is a different operational posture: a broker becomes infrastructure with the availability requirements of infrastructure, the model becomes a versioned artifact that somebody has to own, and the edge devices become stateful participants rather than things that answer when asked. On a small plant with forty tags and one consumer, polling registers into a well-named table is the right answer and adding a broker is architecture theater. The point is not the technology. It is that the model has to be somebody’s, and these protocols make it explicit rather than optional.

What we would ask before scoping one of these¶

• How many consumers will there be in three years? One consumer makes almost every one of these decisions reversible. Four makes them permanent.
• Who currently owns the register map, and is it in a document or in a person? The second answer is more common than anybody likes to write down, and it changes the estimate.
• What happens today when a device is replaced? The existing answer tells you where the model already lives, whatever the architecture diagram says.
• Does anything downstream need to tell stale from current? If yes, that requirement lands on the edge, because it cannot be recovered from a register value that never changes.
• Is any of this data going to be defended to somebody outside the firm? If so, the frame and the chain matter as much as the transport, and that is a different piece.

Where this argument stops¶

None of the above is an argument for replacing working Modbus infrastructure, and a gateway project sold as a modernization is usually the wrong project. The installed protocol is fine. The equipment beneath it is often excellent and has fifteen years left. What is being bought is a boundary where the meaning gets attached, and the cheapest version of that boundary sits alongside the protocol that already works.

It is also true that a well-run single-consumer integration can carry its scaling table in the consumer for years without anybody suffering, and there is a version of this argument that becomes an excuse to build a modeling layer for a plant that has forty tags and one report. The discipline is worth what it prevents, and if there is nothing to prevent, it is overhead. The question is never whether the model is elegant. It is how many places have to change when the plant does.