An edge gateway is the boundary device that sits between field instrumentation and the upper IT/cloud layer, and its job extends far beyond translating Modbus RTU into MQTT [S1][S2]. Modern industrial gateways on the market support over 300 industrial protocols including Modbus, Profinet, and CANopen, and expose rule engines for rapid conversion configuration [S1].
The selection question is therefore not "which brand," but which combination of protocol breadth, edge compute tier, ruggedization, and security segmentation matches the site [S2][S3]. A serial converter solves a different layer (RS485/RS232 to IP), and an IoT platform solves yet another (long-term device operations); confusing the three is the most common procurement error [S5].
Where an edge gateway fits in the stack
The edge gateway is the first IT-friendly stop after sensors, PLCs, cameras, and meters, and it handles protocol translation, local filtering, buffering, and security controls before data leaves the site [S2]. It typically sits between the OT layer (PLCs, instruments, drives) and an optional on-site edge compute node, with the cloud as a secondary destination [S2].
In industrial deployments, the same box is expected to bridge Modbus RTU/TCP, Profinet, EtherNet/IP, OPC UA, BACnet, IEC-61850, and CANbus simultaneously, then normalize the traffic into a consistent data model or message structure [S1][S7]. That multi-protocol normalization is the functional reason an edge gateway exists, and a serial converter cannot replace it [S5].
Edge gateway vs serial converter vs IoT platform
The practical split is direct: a serial converter connects RS485/RS232 devices to a network, an edge gateway handles field protocols, buffering, local rules, and security boundaries, and an IoT platform turns connected devices into long-term operational assets [S5]. Each owns a different layer, and teams that mix the layers usually end up with a connected device that cannot be managed, or a platform that looks complete while the data path remains unstable [S5].
Selection rule of thumb: if the question is "how does this device join the network," start with a serial converter; if it is "how does field data reach the upper system reliably," specify an edge gateway; if it is "how do we operate these devices over time," evaluate an IoT platform [S5]. For a deeper look at how gateways differ from routers and edge servers, the fieldbus gateway reference covers the OT-side definitions, while a protocol gateway explains the protocol-bridging role specifically.
Selection criteria that actually change the decision
Four criteria tend to drive a real go/no-go, and each has a measurable threshold rather than a vendor slogan [S1][S3][S4]. First, protocol count and translation depth: industrial gateways commonly claim 300+ protocols including Modbus, Profinet, EtherNet/IP, CANopen, BACnet, OPC UA, and IEC-61850, but the more important figure is the number of native drivers maintained per firmware release [S1][S7].
Second, compute tier and memory: a gateway handling thousands of tags needs adequate RAM and a CPU capable of real-time processing, edge analytics, and store-and-forward buffering without dropping samples [S3]. Third, ruggedization: industrial edge gateways targeting factory floors, remote energy sites, and mobile assets are commonly specified with fanless cooling, ventless chassis, and tolerance to temperature extremes, vibration, shock, and dust [S4]. Fourth, security stack: data encryption in transit and at rest, device authentication, session and access control, and secure OTA updates are baseline, not optional, for any deployment beyond a pilot [S3].
Protocol conversion patterns in real plants
In a typical automotive plant, an edge gateway pulls vibration, temperature, and pressure from PLCs on the line, runs millisecond-level acquisition with filtering and anomaly detection at the gateway, and only ships feature extracts and OEE metrics northbound [S1]. In a photovoltaic site, the same gateway class converts Modbus RTU and DLT645 from inverters and meters into MQTT+JSON for the energy management platform, and buffers data during cellular outages for replay on reconnect [S1].
In cold-chain logistics, the gateway adds GPS/BeiDou dual-mode positioning, data compression to cut traffic cost, and 4G/5G plus Wi-Fi dual-link redundancy, with the conversion job still being the central function [S1]. Across all three, the conversion pattern is the same: many southbound OT protocols, one normalized northbound payload, with buffering and security handled at the boundary. For projects that also need downstream instrumentation guidance, a pressure transmitter reference explains how field-side devices are typically described in the same spec sheet.
Limits, failure modes, and what to avoid
An edge gateway is not the right answer when the only need is to expose one serial device to a network, that is a serial converter job, and paying for gateway hardware and licensing for it wastes budget and adds an unnecessary attack surface [S5]. It is also the wrong answer when the real need is cross-site device governance, permissions, work orders, and long-term analytics, because those are platform responsibilities and the gateway should not own them [S5].
Common field failures include limited protocol support breaking integration in mid-scale projects, gateways that buffer but cannot replay in order after a link drop, and security features present on the datasheet but disabled by default [S3]. On the architecture side, treating the gateway as a substitute for a proper DMZ between OT and IT, or as a replacement for an edge server running containerized analytics, both create operational debt [S2][S4]. Where the upstream signal is a 4-20 mA loop, the pressure sensor page covers the sensor-side interface; where the controlled element is a final control device, industrial valve is the matching downstream reference.
Sourcing, standards, and field-procurement signals
There is no universal best edge gateway, and vendors explicitly say selection should be driven by scenario and requirements rather than by brand ranking [S6]. What is universal is the procurement checklist: confirm the protocol driver list version-stamped to the firmware you will receive, verify the buffering and store-and-forward behavior with a documented replay order, check the ruggedization rating against the actual site (temperature range, vibration, IP rating), and confirm the security stack is enabled by default rather than sold as an add-on license [S1][S3][S4].
Where the downstream device is a flow element, the flow meter reference defines the typical signal interface the gateway will need to terminate. Trackable next signals to watch: firmware releases that publish a dated protocol-driver changelog (rather than a marketing "supports X" claim), and any deployment case study citing a measured improvement in data acquisition success rate or downtime reduction, since these are the two figures vendors and operators most often quote in 2025-2026 selection guides [S1][S4].
For a related operations-side question, see automatic downtime reason detection signals, reason codes, and where it works, which sits one layer above the gateway on the same OT/IT boundary, and edge fleet management for OTA, provisioning, and targeted updates, which covers the long-tail operations that the gateway alone cannot solve.