An industrial IoT gateway is a device, or a piece of software on a small industrial computer, that sits between the machines on the shop floor and the systems that want their data. It reads values from PLCs, drives and meters in the protocols they speak, translates them into a format IT and cloud systems understand, and sends them on securely, usually without anyone having to change the machines themselves.

If you need PLC and machine data in a dashboard, a historian or a maintenance system, most of the practical decisions are about the gateway. Which protocols does it have to read? How much processing should happen next to the machine? And where in the plant network should it sit so that it doesn't become the weak point? This article works through those questions in that order.

In short

  • A gateway reads industrial protocols such as Modbus, OPC UA or EtherNet/IP on one side and publishes data, often over MQTT, on the other.
  • It also buffers data when the connection drops and keeps the control network closed to the outside.
  • Edge computing on the gateway reduces raw, high-rate data to the values that matter before it leaves the plant.
  • Gateway hardware for a factory is built for cabinets: DIN rail, 24 V DC, wide temperature range, serial and multiple Ethernet ports.

How does an industrial IoT gateway work?

Follow one value through a gateway and its jobs become clear. Say you want the motor current of an extruder, which its PLC already measures.

The gateway's southbound side connects to the machine. It has drivers for industrial protocols: Modbus RTU over an RS-485 serial line, Modbus TCP, OPC UA, EtherNet/IP, PROFINET or vendor-specific protocols such as Siemens S7. You configure it to read the PLC register or OPC UA node that holds the motor current, and how often, for example once a second.

Next, it gives the raw number meaning. A Modbus register might hold 1,523, which the PLC programmer intended as 152.3 amps. The gateway applies the scaling, attaches a name, a unit and a timestamp, and can drop or combine values according to rules you set.

Polling needs some care at this stage. A PLC's communication capacity is shared with everything else that talks to it, including the HMI and SCADA. Reading two hundred scattered registers once a second, one request at a time, can slow those other connections down. Good gateway configurations group neighboring registers into a single request, read slow-changing values such as temperatures every few seconds rather than every cycle, and only publish a value when it changes by more than a set amount, called a deadband.

Then comes the northbound side, where data leaves. Most modern gateways publish over MQTT, a lightweight publish/subscribe protocol in which devices send messages to a broker under named topics and any authorized system can subscribe. Some also offer HTTPS, OPC UA for other plant systems, or Sparkplug B, a specification that standardizes MQTT topics and payloads for industrial use.

Two more jobs happen quietly in the background. Store-and-forward buffering holds messages when the network connection drops and sends them, with their original timestamps, when it comes back. And security: the gateway starts encrypted outbound connections, so nothing outside the plant needs a way in.

Gateways come in many forms, from Node-RED flows on an industrial PC to Modbus2MQTT, Moxa and Advantech hardware, and commercial edge software such as Ignition Edge. Any of them connects to Kilo by pointing its MQTT output at a broker: either Cloud MQTT, which Kilo provisions for you and which accepts only TLS-encrypted connections, or your own broker through External MQTT. You then decide how each message finds its device in Kilo, by topic or by a device ID inside the JSON payload. If your machines expose an OPC UA server, a bridge that subscribes to its nodes and publishes JSON over MQTT is the usual route for connecting OPC UA equipment this way.

How to design an industrial IoT network

An industrial IoT network has to do two things that pull in opposite directions: get data out of the plant easily, and keep the control system protected. A layered industrial IoT architecture resolves that by deciding where each device lives and which way traffic is allowed to flow.

The layout most plants converge on looks like this, from the machine outward:

  • Machine and cell networks. PLCs, drives, remote I/O and HMIs talk on their own fieldbus or industrial Ethernet. This is where real-time control happens, and nothing here should depend on the cloud.
  • Plant control network. SCADA servers, engineering workstations and line-level systems connect the cells. Firewalls separate it from the office network.
  • Industrial DMZ. A buffer zone between the control network and the business network. The gateway often sits here, or straddles the boundary with one network port on each side, so it can read from controllers and publish outward without routing traffic between the two.
  • Business network and cloud. ERP, maintenance systems, dashboards and cloud platforms receive the data.

Traffic rules follow from the layout. The gateway initiates connections toward controllers on the inside and toward the broker on the outside; nothing on the outside initiates a connection inward. If a cloud system needs to send a command back to equipment, that command should still arrive through the gateway's own outbound connection, and the machine's local controller decides whether to accept it.

Wireless sensors add a parallel path. Battery-powered sensors that monitor vibration or temperature on older machines usually report to a LoRaWAN gateway or a mioty base station, which forwards their messages to a network server. That path never touches the control network at all, which is one reason retrofits on legacy equipment often use it.

A practical design check is to draw every arrow on a single page: each device, which network it's on, and which way each connection is opened. If an arrow points from the internet into the control network, the design needs another look.

Industrial IoT edge computing vs cloud

Industrial IoT edge computing means processing data on or near the gateway, before it leaves the plant. The cloud, or a central data center, handles what needs data from many machines or sites. Most projects use both, so the useful question is which job belongs where.

Vibration data makes the case for edge processing. A vibration sensor sampled at 10,000 times a second produces 864 million samples a day. At two bytes per sample, that's about 1.7 GB per day for one measurement axis on one machine. Sending that to the cloud for a plant with a hundred monitored bearings is neither cheap nor useful. An edge device that calculates the RMS vibration velocity and a few spectral values once a minute sends 1,440 sets of numbers a day instead, and keeps the raw waveform locally for an analyst who needs it.

The same thinking applies to ordinary process values. A tank level read every second but published only when it moves by more than 0.5% might send a few hundred messages a day instead of 86,400, with no loss of anything a person would act on. Choosing those deadbands per signal is one of the most useful pieces of edge configuration, and one of the most often left at a default.

Job Better at the edge Better in the cloud
Reducing high-rate signals to features Yes
Buffering during network outages Yes
Fast local reactions (milliseconds) Yes, though control stays in the PLC
Comparing machines across lines and sites Yes
Long-term history and reporting Yes
Alerts that need to reach people anywhere Yes
Updating logic for many sites at once Yes

Two rules of thumb fall out of the table. Anything that has to work when the internet is down belongs at the edge or in the PLC. Anything that needs a view across machines, sites or months belongs centrally. Safety functions belong in neither; they stay in dedicated safety controllers.

What industrial IoT hardware do you need?

The industrial IoT hardware for a plant project usually comes down to three kinds of device: gateways for wired equipment, sensors for things that aren't measured yet, and radio gateways for wireless sensors.

For a gateway that reads PLCs, look for features that suit a control cabinet rather than an office:

  • DIN-rail mounting and a 24 V DC supply input, so it fits beside the PLC and shares its power;
  • an operating temperature range that matches the cabinet, which in a hot plant can exceed 50 °C;
  • RS-485 serial ports for older Modbus RTU equipment, plus at least two Ethernet ports so the control and outbound networks stay separate;
  • enough storage to buffer several days of data during an outage;
  • secure boot and signed firmware updates, so the gateway can't be quietly reprogrammed;
  • a vendor that publishes security updates for the life of the device.

The gateway doesn't have to be a dedicated box. Gateway software can also run on an industrial PC that already sits in the cabinet, or in a virtual machine on a plant server, which suits sites that standardize on one hardware platform for many purposes. The trade-off is ownership: a dedicated gateway has one job and one update cycle, while shared hardware needs agreement between OT and IT on who patches it and when.

Many machines also have signals nobody measures yet: a bearing temperature, a tank level, a motor's run state. For those, battery-powered wireless sensors avoid new cabling, and one radio gateway mounted high in the hall can usually cover a whole building.

Older equipment that only speaks Modbus can also be connected through small converters that read its registers and pass the values on. Kilo Electronics stocks Modbus devices for this kind of connection.

Industrial IoT gateway FAQ

What is the difference between an IIoT gateway and a router?

A router forwards network packets between networks without understanding their content. An IIoT gateway understands industrial protocols: it reads specific values from machines, converts and labels them, and publishes them in a new format. Some devices combine both functions in one box.

Can a PLC act as an industrial IoT gateway?

Partly. Many newer PLCs include an OPC UA server or an MQTT client, so they can share data directly. A separate gateway is still common when a plant has controllers from several vendors or generations, because it gives one consistent connection point and keeps the PLC's processor focused on control.

Do industrial IoT gateways support Sparkplug B?

Many do. Sparkplug B, maintained by the Eclipse Foundation, defines a topic structure, a compact binary payload format and "birth" and "death" messages that tell subscribers when a device comes online or drops off. That state awareness is its main advantage over plain MQTT with custom JSON.

Choose one machine whose PLC already exposes data over Modbus TCP or OPC UA, and set up a gateway beside it that publishes four tags over MQTT: motor current, speed, a temperature and a fault code. Chart them in Kilo on the free plan, then unplug the gateway's outbound cable for an hour and watch whether its buffer sends the missing readings once the connection is back.