An IoT gateway can bridge field devices and application systems, providing protocol translation, local buffering or preprocessing where needed. A separate gateway is not mandatory in every project. An existing controller, measurement device or industrial computer may already perform the required responsibilities appropriately.
Identify the gap it fills
If a device only exposes Modbus RTU and the application receives records through a secure network connection, a bridge is needed. It can read registers, verify units and quality, and forward a normalised record. That can be more than converting a serial cable to Ethernet.
If existing equipment already provides the required interface and suitable security, another device may only add maintenance. Decide by mapping responsibilities to available components, not by assuming every architecture needs a product called a gateway.
Bound the responsibilities
| Duty | Design question |
|---|---|
| Protocol bridge | Which devices and versions are supported? |
| Normalisation | How are unit, time and quality preserved? |
| Buffering | What outage duration can be covered? |
| Preprocessing | Which summaries trace to which raw data? |
| Health | Are storage, clock and connection visible? |
Updates, storage life, power interruption and environmental suitability belong in the operating plan. Software that works on a desk is not automatically dependable in the field. Avoid concentrating unrelated critical duties in one device without considering the consequences of failure.
Calculate buffer needs
For illustration, one 500-byte record each second produces about 43.2 MB of raw data per day. This excludes indexes, filesystem overhead, metadata and reserve capacity. Measure real payloads and write patterns before deriving retention from the advertised disk size.
Specify whether a full buffer rejects new data or discards old data, and make the event visible. Limit replay after reconnection so historical traffic does not prevent current collection or overload the receiving application. A queue does not provide unlimited outage tolerance.
Illustrative meter flow
The gateway reads cumulative energy from a meter and stores source identity, time and quality. It sends the record through MQTT or HTTPS. Local completion follows the application’s agreed acknowledgement contract.
If the acknowledgement is lost, the same record may be sent again. Preserving an event identity lets the receiver recognise it. Generating a new identity for each attempt turns one measurement into several apparent observations. MQTT QoS does not eliminate this application-level concern.
Operating and acceptance checks
Remote updates can interrupt production data. Define maintenance windows, configuration backup and rollback. Device credentials should not be shared without control, and decommissioning a gateway should revoke its access. Local control and physical protection do not become safe merely because the data bridge is online.
Test ordinary polling, device loss, upstream outage, storage full, clock drift and restart. The result should explain both the expected behaviour and the operator’s response. Good gateway selection starts by agreeing on those behaviours, then finding equipment that meets them.
Size the buffer as an operating promise
Extend the illustrative 500-byte record calculation with an explicit outage requirement. If collection produces one such record per second, six hours contain 21,600 records and about 10.8 MB of raw payload. This is still not a disk-sizing result: record envelopes, indexes, journals and reserve capacity also use space. Measure the actual stored representation and leave a documented margin appropriate to the device and operating policy.
State what the buffer protects against. Upstream network loss can be covered only while measurement and local storage continue functioning. A failed sensor, damaged disk or complete loss of power has different consequences. A large disk cannot reconstruct observations that were never recorded. If power-loss behaviour matters, verify the selected hardware and storage implementation under an appropriate test plan rather than inferring durability from a successful software write call.
Record buffer occupancy and rejection behaviour in an operational view. An installation that repeatedly reaches capacity needs investigation before an outage exposes a larger loss. Define how operators learn about this condition and what they can do. A warning stored only on the same unreachable device may not be useful until recovery, so agree on how local and remote observations complement one another.
Test a replacement as well as a restart
A gateway replacement exercises more than the boot process. The new device needs the approved mapping, identity configuration, time settings and access permissions. Historical equipment identity should remain usable while the operational record identifies that the collection device changed. Reusing every credential without review can obscure which physical device is authorised to send data.
Verify that configuration can be restored from a controlled source and that an old gateway’s access can be revoked. Inspect the first records after replacement for units, scaling, timestamp origin and quality. A service can reconnect successfully while publishing with an incorrect mapping. Keep the restoration test result with the version of the configuration that was used.
When comparing candidate gateways, ask for evidence against these tasks rather than an unrestricted list of supported protocols. Does the selected device expose a readable health state, support the needed mapping and recover predictably from the failures that matter at your site? Bring source-device documentation, expected volume and outage conditions to the integration discussion. They determine whether a separate gateway is useful and which responsibilities it must actually carry.