How to Build an Industrial MQTT Edge Gateway Architecture
Build an industrial MQTT edge gateway architecture around an agreed data contract: who operates the broker, how the gateway identifies itself, which topics it publishes and how consumers interpret the payload. For a Robustel EG5120 with a compatible E2C Factory installation, define those choices before commissioning. Then prove the complete path with representative values at the actual receiver. A broker connection by itself does not establish correct naming, timestamps, units or business meaning.
Illustrative industrial environment; final implementation is project specific.
Key Takeaways
- Name the broker owner and obtain the real connection requirements before gateway setup.
- Treat topics and payload meaning as a versioned contract shared with consumers.
- Separate software compatibility evidence from a tutorial's tested hardware configuration.
- Verify normal delivery, missing data and reconnection using the intended application.
In This Guide
- Where should responsibilities sit?
- What belongs in the data contract?
- How should the contract be tested?
- How do changes stay compatible?
Where should MQTT responsibilities sit?
Draw the intended sequence as field source, gateway collection application, MQTT broker and consuming application. Name the owner at every handoff. The source owner confirms measurement meaning; the gateway integrator maps the agreed values; the broker administrator supplies connection requirements; the consumer owner verifies the result.
The Robustel MQTT guide assumes an external broker is already available. It describes a Tag Group, an MQTT Cloud Service and a publish rule. Its worked example was tested on EG3120. Use the Factory compatibility listing for EG5120 prerequisites, then verify your selected build and broker together.
Do not leave the broker's location implicit. A broker hosted by the customer, a cloud endpoint and a temporary commissioning broker create different operational handoffs. Record its administrator, support contact and change process, regardless of where it runs.
The connection record should reference the endpoint, port, authentication method and certificate handling required by the selected service. Store secret material in the approved credential system. The architecture document needs a reference and an owner, not private keys.
What belongs in the topic and payload contract?
Write one example message and ask both the machine owner and the consumer developer to explain it. Where their interpretations differ, resolve the meaning before adding more tags.
The following is a proposed integration worksheet, not an E2C Factory default payload or required topic format:
| Contract item | Example decision | Acceptance question |
|---|---|---|
| Asset identity | A stable machine ID distinct from its display name | Can the consumer identify the same asset after a rename? |
| Topic ownership | A project-defined path reserved for one producer | Could another publisher unintentionally use that path? |
| Value meaning | Engineering unit and scaling recorded per measurement | Does the consumer interpret the same physical quantity? |
| Time meaning | State what the chosen timestamp represents | Can delayed observations be distinguished from current ones? |
| Missing observation | Define what absence or an invalid value means | Does the application avoid treating silence as zero? |
| Schema revision | Record a revision with the integration specification | Can a change be introduced without guessing? |
If the selected publisher format cannot represent a requested field, record how that requirement will be handled and who will implement it. Do not describe a desired schema as already produced by the gateway.
How should the MQTT contract be tested?
Begin with two or three measurements that expose different interpretation risks: a scaled numeric value, a status and a value whose change is easy to observe. Use the real field-device definition and the actual consuming application whenever possible.
Capture a small evidence set. For each test observation, record the source value, gateway value, received message and final application value. Include times and configuration revisions so a later reviewer can distinguish data conversion from a display setting.
A Robustel EG5120 SiteWise guide provides an official example using E2C Factory and MQTT over TLS. It is evidence for that documented integration path, not a compatibility guarantee for every cloud service or message model.
Illustrative MQTT integration test environment.
Extend the test beyond a happy-path connection:
- Verify that the subscriber observes the exact intended topic.
- Confirm that a safe source change appears with the agreed interpretation.
- Stop the approved test publisher and check how the consumer represents missing observations.
- Restore the test connection and inspect the arriving data.
- Restart the intended consumer and verify its application state.
For each event, record what happened to freshness, ordering and repeated observations. Set project acceptance criteria for those behaviors and test them with the selected configuration. Do not infer storage, replay, exactly-once business processing or guaranteed ordering from the presence of MQTT alone.
Keep commissioning tools in their proper role. A message visible in a diagnostic client proves one receiving path, but the business application may still apply a different parser, filter or identity mapping.
How do you change the contract without surprises?
Make the consumer owner part of the change review. Renaming a source tag, changing an engineering unit or combining messages can affect a downstream calculation even when the gateway remains connected.
Maintain an example message for each supported contract revision. Record the producer version, affected consumers and the agreed transition date. Before approving a change, replay safe example observations through the planned consumer test environment and compare the interpreted results.
For a new asset, reuse the contract structure but assign its own identity and connection configuration. For a changed measurement definition, create a visible revision rather than relying on an undocumented convention. Ask which historical comparisons would become invalid and whether the application needs an explicit transition record.
The finished architecture should let an engineer answer four questions without guessing: where the message originates, where it is delivered, what it means and who fixes each handoff.
Frequently asked questions about industrial MQTT architecture
Must the MQTT broker run on the gateway?
No. The cited E2C Trinity publishing guide uses an external broker. Choose the broker's location and operating responsibility as part of the project design.
Can I copy the example topic directly into production?
Treat it as a tutorial value. Agree a project topic with the broker and consumer owners, and check naming collisions and access rules before deployment.
Does an MQTT connection prove that the measurement is correct?
No. Compare a known source observation with the received payload and the final application value. Connection status does not prove units, scaling or identity.
Is offline replay guaranteed by this architecture?
No. If replay is required, specify retention, ordering and duplicate-handling expectations, confirm the selected application's documented behavior and test that exact combination.
What should you do next?
Bring one proposed topic, one sample payload and one consumer acceptance test to the EG5120 evaluation. Use the official MQTT workflow to configure the supported path, then validate the project's actual contract.
About the Author
Mark, Technical Support Engineer at Robustel
Mark is a Technical Support Engineer at Robustel with hands-on experience in industrial networking and edge connectivity. He helps customers plan, deploy, configure, and troubleshoot industrial IoT solutions, including cellular routers, edge gateways, and LoRaWAN systems. His work spans technical support, product training, configuration review, and practical deployment guidance for reliable and repeatable field operations across global projects and long-term operational support.
Leave a comment