Industrial Edge & IIoT Gateways in Industrial Automation Projects

Industrial Edge & IIoT Gateways in Industrial Automation Projects

Industrial edge and IIoT gateways sit between the plant floor and higher-level IT/OT systems, translating protocols, buffering data, enforcing cybersecurity boundaries, and enabling analytics, remote access, and cloud connectivity. In industrial automation projects, this component category is not selected as a generic “router with Linux,” but as a defined part of the control architecture with requirements for determinism, interoperability, environmental robustness, and compliance. For European projects, the gateway often becomes part of the CE-relevant machinery or electrical assembly scope, so its functional role, safety boundary, and cybersecurity posture must be established early.

How the component is selected

Selection starts with the use case. A gateway for machine data collection is different from a gateway for brownfield PLC integration, OT remote access, or edge analytics. The key engineering questions are:

• Which northbound interfaces are required: MQTT, OPC UA, HTTPS/REST, Sparkplug B, Modbus TCP, or file transfer?
• Which southbound protocols must be supported: PROFINET, EtherNet/IP, Modbus RTU/TCP, BACnet, DNP3, serial ASCII, or proprietary PLC drivers?
• Does the device need store-and-forward buffering for intermittent WAN links?
• Will it terminate VPNs, run containers, host Node-RED, or execute analytics at the edge?
• What is the cybersecurity model: segmentation only, or active remote access with authentication, logging, and certificate management?

From a compliance perspective, the gateway should be assessed within the machinery and control system risk picture. If it is part of a machine control system, the design must support the relevant safety and control requirements under EN ISO 12100 and EN 60204-1. For networked industrial systems, IEC 62443-3-2 and IEC 62443-4-2 are the most relevant technical references for zoning, conduits, secure component requirements, authentication, session control, and audit logging. In EU projects, this also aligns with the NIS2 expectation of risk management and supply-chain security for essential and important entities.

How the gateway is sized

Sizing is usually driven by data volume, tag count, protocol conversion load, and retention requirements. A common mistake is to size only for CPU and memory while ignoring network burst rates and local buffering. A practical sizing model starts with expected payload:

$$D = N \\times F \\times S$$

where $D$ is data per second, $N$ is the number of tags or signals, $F$ is the sampling frequency, and $S$ is the average message size in bytes. If 2,000 tags are sampled every second at 80 bytes average, the raw rate is roughly 160 kB/s before protocol overhead. If store-and-forward is required for 24 hours of WAN outage, then local storage must be sized for:

$$Storage \\approx D \\times 86{,}400 \\times R$$

where $R$ is an overhead factor, often 1.3 to 2.0 depending on protocol and metadata. In practice, engineers should also check CPU headroom for encryption, container workloads, and protocol translation. For harsh industrial environments, the gateway should be rated for the ambient temperature, vibration, EMC, and enclosure class required by the installation. EMC coordination should be consistent with IEC 61000-6-2 for immunity and IEC 61000-6-4 for emissions in industrial environments, while the enclosure and installation environment should be matched to the panel design and IP rating requirements.

Integration inside the automation architecture

Integration must be treated as an OT architecture task, not a plug-in accessory. The gateway should be placed in an appropriate network zone, typically between the control network and the plant DMZ or enterprise network, depending on the traffic model. IEC 62443-3-2 supports the zoning and conduit approach, while IEC 62443-3-3 maps well to technical security requirements such as identification and authentication control, use control, system integrity, data confidentiality, and restricted data flow.

Typical integration patterns include:

• PLC-to-MES data collection via OPC UA server/client or MQTT publisher
• Brownfield serial protocol conversion from Modbus RTU to OPC UA or MQTT
• Remote vendor access through a hardened VPN or jump-host architecture
• Edge analytics using containerized applications with signed images and update control

Vendor families commonly used in industrial projects include Siemens Industrial Edge, Siemens IOT2050, Moxa UC/DA series, HMS Ewon Cosy/Flexy, Phoenix Contact PLCnext/Proficloud Gateway families, Advantech UNO and ECU platforms, Red Lion FlexEdge, and Hilscher netIOT or edge gateways. The right family depends on whether the project prioritizes protocol breadth, lifecycle support, cybersecurity features, or industrial certifications. For example, Ewon is often selected for secure remote access use cases, while Siemens Industrial Edge and PLCnext are often favored when edge applications need tighter integration with automation ecosystems and containerized services.

How the gateway is tested

Testing should be defined in the FAT and SAT plan, not left to commissioning. At minimum, verify protocol mapping, failover behavior, boot time, power-loss recovery, time synchronization, user access control, logging, and data integrity under network interruption. If the gateway is security-relevant, test password policy, certificate handling, backup/restore, firmware update process, and port exposure. IEC 62443-4-2 is useful as a checklist for component-level security validation.

For electrical and panel integration, acceptance should also confirm conformity with the panel standard and installation practices. Where applicable, NFPA 79 and IEC 60204-1 provide guidance on industrial machinery electrical equipment, including control circuit behavior, protective bonding, and documentation. If the gateway is mounted in a control panel, verify thermal management, segregation from power conductors, labeling, and maintainability. If it is used in a safety-related architecture, ensure it is not incorrectly inserted into the safety function path unless explicitly designed and validated for that role under the appropriate safety standard.

Quick decision table

Project need	Best-fit gateway profile	Typical vendor families
Remote access to legacy machines	Secure VPN, serial and Ethernet passthrough, audit logging	HMS Ewon, Moxa, Red Lion
Plant data to MES/SCADA	OPC UA/MQTT, buffering, protocol conversion	Siemens Industrial Edge, Phoenix Contact, Advantech
Edge analytics and containers	Higher CPU/RAM, Linux runtime, container support	Siemens IOT2050, PLCnext, Advantech UNO
Brownfield multi-protocol integration	Broad driver library, serial and Ethernet support	Moxa, Red Lion, Hilscher

Practical procurement and compliance notes

Procurement teams should request lifecycle documentation, cybersecurity update policy, country-of-origin and export-control statements where needed, and a clear declaration of supported firmware versions. Engineers should confirm whether the gateway is part of the machinery technical file, whether CE documentation is available, and whether the supplier provides vulnerability disclosure and patch support consistent with IEC 62443 expectations. For EU projects, this is increasingly important because gateway compromise can affect not just data visibility but operational continuity and regulatory exposure.

In short, industrial edge and IIoT gateways are selected for function, sized for data and resilience, integrated by architecture, and tested like any other critical OT component. When treated this way, they become a reliable bridge between field assets, SCADA, MES, and enterprise analytics without weakening the control system boundary. If you are defining a gateway scope for a new plant or retrofit, discuss your project requirements via /contact.