Learn Automation with MINATA #76: MQTT in Industrial IIoT — Design Topics, Payloads and Store-and-Forward First
MQTT in Industrial IIoT: Design Topics, Payloads and Store-and-Forward First
MQTT is light and flexible, which suits sending data from a machine up to an IIoT system. And it is exactly that flexibility which makes a clear data convention necessary before a gateway is attached to a machine. Without one, the data arriving in the cloud is hard to use and hard to maintain.
Give topics a structure
A topic should express scope and ownership in a hierarchy — site/line/machine/data-type — without stuffing every changing detail into the name. A stable structure lets subscribers take whole groups and lets access be granted per branch. Topic names that keep changing leave the receiving side unable to follow.
Payloads need versions and context
A payload, usually JSON, should carry a version, a timestamp, a quality indication, the unit, and a sequence or event identifier where needed. A tidy payload with no timestamp is close to useless when the network is unreliable: the receiver cannot tell new data from old. Put a version in from the start, so the structure can change later without breaking every receiver.
Event, sample or aggregate
Decide, per data type, how it will be sent:
| Kind | Used for | How it is sent |
|---|
| Event | Machine state changes, alarms | Published when it happens |
| Sample | Measured values being monitored | Periodically, with a rate limit |
| Aggregate | Energy, output | Summed over an interval |
Do not publish every PLC tag at high frequency without a consumer, a cost estimate and a retention plan.
Store-and-forward when the network drops
The gateway should support store-and-forward: buffer while the connection is lost, then send once it returns, carrying the original timestamps so the receiver can order them correctly. Use an appropriate quality of service for important data, so state events are not lost.
A worked engineering situation
A gateway publishes an event when the machine changes state, sends energy as an aggregate per interval, and rate-limits the fast-moving values. Payloads carry a version and a timestamp. When the internet is interrupted, data is buffered and resent in the correct order once it returns. The cloud dashboard therefore loses no events, and never mistakes old data for fresh.
The topic structure, the payloads and the publishing policy all follow the needs of the receiving side, the cost and the retention plan.
Common mistakes
- Topics stuffed with changing details, impossible to subscribe to sensibly.
- Payloads with no version and no timestamp, useless after a dropout.
- Publishing every tag at high frequency with no consumer.
- No store-and-forward, so data is lost whenever the link drops.
- The wrong quality of service, losing important state events.
MQTT checklist
- [ ] Topics follow a stable hierarchy that expresses scope and ownership.
- [ ] Payloads carry version, timestamp, quality and unit.
- [ ] Each data type is classified as event, sample or aggregate.
- [ ] Store-and-forward buffers a dropout and preserves original timestamps.
- [ ] The quality of service suits the importance of the data.
Conventions agreed before the first publish are what make the data usable a year later. #77 turns to OT network segmentation.
Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation
Previous — #75: OPC UA for data integration: https://minatavn.com/en/blog/automation-75-opc-ua-data-integration
Next — #77: OT network segmentation: https://minatavn.com/en/blog/automation-77-ot-network-segmentation
View all MINATA technical articles