Industrial IoT (IIoT) gateways serve as the critical bridge between operational technology (OT) networks comprising PLCs, sensors, and industrial controllers and information technology (IT) cloud platforms, translating legacy industrial protocols into modern IP-based communication while providing edge computing, data buffering, security enforcement, and device management capabilities. A well-designed IIoT gateway must handle protocol translation (Modbus RTU/TCP, OPC UA, BACnet, PROFINET to MQTT/AMQP/HTTPS), perform edge preprocessing to reduce cloud data transfer by 80-95%, maintain a local store-and-forward buffer for intermittent connectivity, enforce network segmentation between OT and IT domains, and support remote configuration and OTA updates. Common hardware platforms include industrial-grade ARM Cortex-A processors (NXP i.MX8, TI AM64x), x86 embedded PCs, and ruggedized single-board computers running embedded Linux with container support for application deployment.
What Is the Architecture of an IIoT Gateway?
A production IIoT gateway follows a layered software architecture. The hardware abstraction layer interfaces with physical ports (RS-485, CAN, Ethernet, GPIO). Above that, the protocol engine hosts drivers for industrial protocols: Modbus RTU/TCP for legacy PLCs, OPC UA for modern industrial equipment, BACnet for building automation, and PROFINET/EtherCAT for real-time industrial Ethernet. The data processing layer normalizes readings into a unified data model, applies filtering, aggregation, and edge analytics. The northbound communication layer handles MQTT, AMQP, or HTTPS connections to cloud platforms with TLS encryption and certificate-based authentication. A management plane provides local and remote configuration, logging, diagnostics, and OTA updates.
How Do You Handle Protocol Translation?
# Python example: Modbus RTU to MQTT gateway
from pymodbus.client import ModbusSerialClient
import paho.mqtt.client as mqtt
import json, time
# Connect to Modbus RTU device
modbus = ModbusSerialClient(
port='/dev/ttyRS485',
baudrate=9600,
parity='N',
stopbits=1,
bytesize=8,
timeout=1
)
# Connect to MQTT broker
mqtt_client = mqtt.Client(client_id="gateway-001")
mqtt_client.tls_set(ca_certs="/etc/ssl/ca.pem",
certfile="/etc/ssl/client.pem",
keyfile="/etc/ssl/client.key")
mqtt_client.connect("iot.cloud.example.com", 8883)
def poll_and_publish():
modbus.connect()
# Read holding registers from PLC
result = modbus.read_holding_registers(address=0, count=10, slave=1)
if not result.isError():
payload = {
"timestamp": time.time(),
"temperature": result.registers[0] / 10.0,
"pressure": result.registers[1] / 100.0,
"flow_rate": result.registers[2] / 10.0,
"motor_rpm": result.registers[3],
}
mqtt_client.publish(
"factory/line1/sensors",
json.dumps(payload),
qos=1
)What Hardware Should You Use for an IIoT Gateway?
Hardware selection criteria and recommended platforms:
- NXP i.MX8M Plus: Quad Cortex-A53 + Cortex-M7 + NPU, dual Ethernet, ideal for gateways with edge AI capability.
- TI AM6442: Dual Cortex-A53 + Cortex-R5F + Cortex-M4F, EtherCAT/PROFINET support, designed for industrial gateways.
- Raspberry Pi CM4 (with industrial carrier): Cost-effective for prototyping, not recommended for production due to supply chain and temperature range limitations.
- Industrial ruggedized PCs (Advantech, Moxa): -40 to 75C operation, DIN-rail mounting, certified for industrial environments. Higher cost but production-ready.
- Consider: Operating temperature range (-40 to 85C), input voltage range (9-36V DC), industrial certifications (CE, UL, IEC 61131-2), and MTBF requirements.
How Do You Ensure Reliability and Data Integrity?
Industrial environments demand extreme reliability. Implement store-and-forward buffering using local persistent storage (eMMC or industrial-grade SD cards) so data is preserved during cloud connectivity outages. Use MQTT QoS 1 or QoS 2 for guaranteed delivery. Implement watchdog timers at both hardware and software levels—the hardware watchdog resets the system if the software watchdog fails. Use A/B root filesystem partitioning with automatic rollback for OTA updates. Monitor gateway health metrics (CPU temperature, memory usage, disk I/O, network throughput) and expose them via the management interface. For critical applications, deploy redundant gateways in hot-standby configuration with automatic failover.
Key takeaway: IIoT gateways bridge OT networks (Modbus, OPC UA, BACnet) to IT cloud platforms (MQTT, HTTPS) while providing edge preprocessing that reduces cloud data transfer by 80-95%. Use ARM Cortex-A processors with embedded Linux, implement store-and-forward buffering for connectivity resilience, and enforce strict network segmentation between OT and IT domains.
How Did We Deploy an IIoT Gateway in a Chemical Plant?
At EmbedCrest, we developed a custom IIoT gateway for a chemical processing plant that needed to connect 45 legacy Modbus RTU PLCs and 12 newer OPC UA-enabled controllers to Azure IoT Hub. We selected the NXP i.MX8M Plus SoC on a Toradex Verdin carrier board, running a Yocto-built embedded Linux image with Docker containers for each gateway service. The Modbus driver container polled 45 PLCs every 2 seconds over RS-485 multidrop networks, the OPC UA client container subscribed to 380 data points across 12 servers, and the MQTT publisher container forwarded aggregated data to Azure IoT Hub every 30 seconds. Local edge processing computed 1-minute rolling averages, rate-of-change alerts, and threshold violations, reducing cloud data transfer from 2.3 GB/day (raw) to 180 MB/day (processed). The gateway included a SQLite-based store-and-forward buffer on a 32 GB industrial eMMC, capable of buffering 72 hours of data during internet outages. Network segmentation was enforced using Linux iptables rules, physically separate Ethernet interfaces for OT and IT networks, and a DMZ configuration preventing any direct OT-to-internet routing.
What Are the Critical Reliability Patterns for IIoT Gateways?
Industrial deployments demand five-nines reliability (99.999% uptime, allowing only 5.26 minutes of downtime per year). Achieve this through layered fault tolerance. At the hardware level, use industrial-grade components rated for -40 to 85°C, dual redundant power inputs (9-36V DC) with automatic failover, and ECC RAM for memory reliability. At the OS level, implement A/B root filesystem partitioning with automatic rollback using Mender or RAUC: if the new rootfs fails health checks within 60 seconds of boot, the system automatically reverts to the previous partition. At the application level, use systemd watchdog integration with WatchdogSec=30 to automatically restart crashed services. Implement a supervisory process that monitors CPU temperature, memory usage, disk I/O, network throughput, and OT protocol response times, escalating from service restart to full system reboot to hardware watchdog reset based on severity. For mission-critical installations, deploy redundant gateways in hot-standby configuration with VRRP (Virtual Router Redundancy Protocol) for automatic IP failover.
How Do You Secure OT/IT Network Boundaries?
The IIoT gateway sits at the critical boundary between OT (Operational Technology) and IT networks, making it a prime target for cyberattacks. IEC 62443 defines security zones and conduits for industrial networks, and the gateway serves as a conduit between zones with different security levels. Implement defense-in-depth: use physically separate network interfaces for OT and IT connections (never bridge them at Layer 2). Configure iptables/nftables to allow only specific protocol traffic between interfaces (Modbus TCP on port 502 from OT side, MQTT on port 8883 to IT side, deny everything else). Use mutual TLS with client certificates for all northbound cloud connections. Disable all unnecessary services (SSH on IT interface only, with key-based authentication). Run gateway applications in unprivileged Docker containers with read-only root filesystems and minimal capabilities. Implement intrusion detection using network traffic anomaly monitoring on both OT and IT interfaces, alerting on unexpected Modbus function codes, new device addresses, or unusual traffic patterns.
