The register-to-topic trap
Most factories still run equipment that speaks Modbus RTU or TCP. The tempting shortcut is a generic gateway or a one-off script that maps every register to a topic. It works on day one. Six months later nobody remembers what register 40123 actually means, which scale applies, or why two machines report the same quantity differently.
Model first, map second
Treat the gateway as three separate artifacts:
- The semantic model: what a “filler” or a “pump” is, and which properties it has (state, speed, counts, temperature) with units.
- The mapping: which register, address, data type, scale and byte order feeds each property for each physical machine. This is the register map, and it belongs in version control. See the register map validation checklist.
- The bindings: how the model is exposed, for example as an OPC UA address space, as MQTT topics (topic design) or through REST.
Keeping them separate means a replaced machine only changes the mapping, and a new consumer only needs a new binding.
Poll Modbus politely
- A serial line has one master. Do not let two systems poll the same RS-485 segment.
- Group contiguous registers into block reads instead of reading one register per request (limits are in Modbus addressing and function codes).
- Choose a polling interval from the process need, not from how fast the device can answer, and set timeouts and retry limits.
- Agree the load with the automation owner: reads consume controller and network resources.
Report changes, not just samples
Apply deadband and change-of-value reporting at the gateway, with a maximum interval so that a steady value still produces a heartbeat. This keeps traffic and storage proportional to what actually happens (see sizing an IIoT data budget).
Be honest about quality
When a device stops answering, publish a bad-quality status. Do not repeat the last value as if it were current, and never substitute zeros. Consumers can handle “unknown”; they cannot detect a frozen value that looks healthy. Include a gateway heartbeat so the loss of the gateway itself is visible.
Expose the same model on several protocols
If SCADA wants OPC UA and the analytics layer wants MQTT, generate both from the same model rather than writing logic for each. Differences between outputs are then a configuration question, not a coding one.
Version and document
- Version the model independently from the gateway software.
- Record byte order, scaling and units next to every mapped value (byte and word order).
- Name an owner for the gateway and its configuration, and keep the data contract current.
- Test restart behavior: after a reboot the gateway should come back with the same configuration and resume without manual steps.
Tools differ: a dedicated DataOps platform, an SCADA-integrated gateway or even a well-structured YAML schema can all work. The discipline of modeling first matters more than the product.