How to Choose an Industrial IoT Gateway: Protocols, Uplink Channels and Certificates
When a plant buys a gateway, the purchase list often names only the brand and the model. The model matches, then the unit arrives and the protocol will not read, the point table will not export, and the uplink and certificates will not line up with the platform. Rework starts there. On scattered pump houses, energy substations and factory edge cabinets the link is rarely steady. What decides whether data reaches the cloud is the gateway's protocols, point table, channels and certificates — not the name on the case. This article sets out what to verify at selection, and what happens if you skip a check.
Five things you miss if you select by brand alone
- Protocol coverage does not match the site: the datasheet lists Modbus, but the floor uses a private protocol or a specific PLC port that is not in the gateway driver list
- The point table cannot be exported from the gateway: registers are copied by hand, and addresses drift when you add a line, change staff or connect a platform
- There is only one uplink: MQTT or REST, not both — and when the platform or leased line needs both, it is too late to rebuild
- The certificate model does not match: the platform asks for a client certificate, while the gateway only offers a self-signed one, or has no certificate management at all
- There is no outage buffer: data is lost while 4G or the leased line is down, and history curves keep gaps after the link returns
All five show up after the gateway has already been delivered. What you verify is not the brand name, but whether five capabilities — protocol, point table, channel, certificates and buffer — line up with site conditions and platform requirements. Not every device can be wired straight into a gateway. Interface and adaptation conditions have to be checked first.
Protocols and the point table: what the gateway reads down, and what it hands up
Downward, the gateway is a collection port; upward, it is a data exit. The southbound protocol decides whether a device can be read. The point table decides whether each value has a name, an address and an engineering unit. If you only count how many protocols are listed and never look at how the point table is kept, tags scatter as soon as the job expands.
We integrate IoT gateways from multiple vendors and match them to the site. The gateway has a built-in web configuration page: the device list and register addresses are prepared there and exported in one action as an address table that SCADA and the platform both consume. A common path on the floor is Modbus TCP into the devices, then MQTT and REST as a dual uplink to the cloud. Legacy and special equipment still need their interface and adaptation conditions checked first.
- Southbound protocol: first confirm the protocol and port the device actually opens (Modbus TCP/RTU, vendor driver, and so on), then match them against the gateway driver list; mismatches go to an adaptation assessment
- Point-table structure: each point needs device, address, data type, scale, unit and read/write flag, and the export must be usable by SCADA and the platform without retyping
- Built-in web configuration page: devices and points are configured on the gateway itself, with no need for an outside network — useful for unattended cabinets and commissioning
- One-action address-table export: the file is a single input, so hand-copied registers do not make points drift between lines or between the gateway and the platform
- Adaptation boundary: free protocols, obsolete controllers and machines with no communications port are outside “select the gateway and it connects”; they are checked separately, and the collection path is changed if needed
Uplink channels: how MQTT, REST, leased line and 4G fit together
The channel answers how data leaves the site. Pump stations and energy sites are spread out: some have a leased line, some have only 4G, some have both and neither is steady. A channel is not “pick one protocol”. You decide the primary path, the fallback path and the buffer for the time the link is down — together.
A path used on projects is Modbus TCP collection with MQTT and REST as a dual uplink to the cloud. MQTT fits continuous publish and subscribe; REST fits platform pull, reconciliation and backfill. Leased line and 4G are the bearer. They do not replace that pair of application channels.
- MQTT: the device side publishes continuously and the platform subscribes; it fits status, curves and alarms; agree topic structure, QoS and session keep-alive first
- REST: the platform pulls on demand or the gateway POSTs; it fits reconciliation, backfill and hooks into existing business systems; agree path, authentication and retry
- Leased line: latency and bandwidth are relatively steady, but drops still happen; firewalls, fixed addresses and certificates on both sides must match the gateway channel setup
- 4G: covers unattended stations and temporary links; traffic, signal and tariff are sized from the poll period; a local buffer is required during an outage, with automatic backfill after recovery
Certificates and access: an open channel is not admission to the platform
A working channel only means frames leave the site. The platform usually still authenticates which gateway and which client they came from. Wrong certificates or rights mean the cloud refuses the session, rights are too wide, or the whole station drops when a certificate expires. Gateway certificates, client certificates and self-signed certificates are three different forms. They do not stand in for one another.
- Gateway certificate: identifies this unit; the platform recognises the site by the certificate. Check format, validity, revocation and replacement; on an unattended station, remote renewal must be possible
- Client certificate: used when the platform or an external cloud requires mutual authentication. The gateway must import the client certificate and private key and bind them to the MQTT and REST channels
- Self-signed certificate: common on an internal network or a private platform, and quick to deploy, but the root must be distributed and the trust chain kept; public clouds and cross-organisation platforms usually will not accept it
- Rights and roles: the web configuration page, point-table export, channel start/stop and certificate replacement are split by role. Commissioning accounts stay separate from control-room accounts, and actions are auditable
Site conditions, gateway capabilities and the cost of skipping a check
Before you issue a proposal, line up site conditions and gateway capabilities against the table below. Rows that do not match are adaptation work. Do not leave them until after delivery.
| Site condition | Gateway capability to verify | If you skip the check |
|---|---|---|
| Device protocol and port are already open | Whether southbound protocol and drivers cover these devices | Points cannot be read after delivery; wiring or the gateway has to change |
| Point count is high and the station type will be copied | Whether the web page can hold the table and export addresses in one action | Each station is typed by hand; points drift when copied to the next station |
| The platform requires both MQTT and REST | Whether both channels plus topic and API agreements are supported | With a single channel, platform reconciliation or subscribe will not line up; extra development follows |
| Leased line and 4G are mixed, and the link drops | Whether there is an outage buffer and automatic backfill after recovery | Curves go blank during the outage; energy use and alarms cannot be traced |
| The platform requires mutual authentication or a private deployment | Whether gateway, client and self-signed certificates can be set per scenario | The channel is up but the platform refuses the session, or the whole station drops when the certificate expires |
Legacy and special equipment need their interface and adaptation conditions checked before the gateway is chosen. Not every device can be connected to a gateway as it stands. Whether it connects, which protocol it uses, and whether the point table can be exported are decided by the site survey.
In short
Brand is only the entry point when you choose an industrial IoT gateway. What you actually verify is the southbound protocol and point table, the uplink (MQTT, REST, leased line, 4G), certificates and rights, and store-and-forward across an outage. When those blocks line up with site conditions and platform requirements, the gateway can send data to the cloud on a steady basis.
Start with a site check: record device protocols and ports, where the point table comes from, which uplinks are available and what certificates are required — then tick them against gateway capabilities item by item. Mismatches are assessed as adaptation. Do not assume that changing the brand will close them.
Check gateway selection conditions on your site
Send the station type, device protocols and the uplinks you plan to use. We can line up protocol, point table, channels and certificates before anything is shipped. An English-speaking contact is available.
Contact Us