An industrial gateway is a device at the plant edge that translates between production equipment protocols (Modbus, Profinet, EtherNet/IP, S7, OPC-UA) and information system protocols (MQTT, HTTPS, message queues). It concentrates machine reads, normalises the data and forwards it to the data layer.
What it actually mediates
“Translate” undersells it, because a gateway does five separable jobs. First, speaking the machine’s language: it implements the clients or drivers for each field protocol, from Modbus RTU over RS-485 to the OPC-UA server of a modern controller, including vendor-proprietary protocols. Second, turning signals into data: applying type, scaling and units to values that at source are just 16-bit registers, grouping signals into meaningful structures and giving them stable names. Third, timestamping: stamping each measurement at the instant it was read, next to the machine, not when it reaches the server. Fourth, buffering: storing captured data locally while the upstream link is down and replaying it in order once it returns. Fifth, publishing: delivering the result to the data layer, usually as an MQTT client, with or without Sparkplug B, or exposing it as a unified OPC-UA server.
Hardware and deployment
The typical form factor is a DIN-rail device powered at 24 V DC, fanless, rated for a wide temperature range and built to live inside an electrical cabinet with vibration, dust and electromagnetic noise. What matters is not compute power but interfaces: two independent Ethernet ports so one leg sits on the plant network and the other on the corporate network, serial ports for legacy buses and often digital inputs for standalone signals. Purely software gateways also exist, deployed as a container on an industrial PC or an existing plant server; the line between “gateway” and edge computing node is about function, not about the box.
The architectural detail that matters most is the direction of connections. A well-designed gateway always acts as a client upwards: it initiates the outbound connection to the broker or platform, so no inbound port needs opening into the industrial network. That asymmetry is what allows a plant to be connected without turning it into attack surface, and it fits the zones-and-conduits model of IEC 62443.
Gateway, PLC, firewall and edge node
A gateway is not a PLC: it runs no control logic, takes no part in safety interlocks, and if it is switched off the machine keeps producing exactly as before. That is its most important design property and the reason it can be installed without requalifying plant safety. It is not a router or a firewall either: those work at packet level and decide which traffic passes, while the gateway works at application level and decides which data exists; they coexist rather than replace each other. Against a generic edge computing node the difference is one of scope: a gateway is defined by protocol mediation, whereas an edge node may also run analytics, models or local business logic. In practice many devices are both, and the term chosen says more about the assigned role than about the hardware.
Where you find it on the plant floor
In a plant with mixed equipment the gateway usually ends up being the single point through which data leaves production: installed in the cabinet next to the controller or in the technical room rack, connected to the same segment as the SCADA and the PLCs, and exposing one normalised stream towards the corporate side. It is also the standard answer to legacy equipment that speaks nothing modern: rather than replacing a machine that still produces well, an external translation layer brings it into the data layer untouched.
What it takes to get data out through a gateway
A gateway does not remove the limitations of the underlying protocol, it manages them. With Modbus below, polling remains and effective latency is set by the configured cycle; with OPC-UA it can subscribe to value changes and data moves when it happens. Sizing that cycle is the core engineering work: too slow and short events vanish, since a two-second micro-stop does not exist if you read every five; too fast and you load the serial bus or the device processor without gaining information, because a process temperature does not change a thousand times per second. The practical rule is to set each period from the dynamics of the variable, not from the capacity of the gateway.
Local storage is what separates a gateway from a plain converter. A two-hour network outage must not become a two-hour hole in the history: the device retains what it captured on disk and replays it in order once the link returns, with the original timestamp intact. That forces every upstream layer to distinguish two times, event time and ingestion time, because data can arrive late and still be correct.
None of this requires stopping the line. Installation is additive (power, network cable and read permissions) and reading does not modify control logic. The real precautions lie elsewhere: agreeing with the machine owner which signals are read and how often, documenting the signal map, electrically isolating serial buses, and deciding explicitly whether the gateway may write back to the plant or only read. That last decision is one of governance rather than technology: a read-only gateway with an outbound connection is a low-risk component, while a gateway able to write belongs to the control domain and deserves the same treatment.
Related terms
The gateway is the physical piece of the OT/IT bridge and the natural entry point to a Unified Namespace; sizing, buffering and quality-of-service levels are developed in the industrial edge guide. Deploying capture next to the machine is the scope of edge ingestion.