IoT Gateway vs Edge Device: The Two Patterns for Getting Plant Data Off the Floor

Key takeaways

• IoT gateway = device that aggregates data from many sensors/PLCs and forwards to higher systems.
• Edge device = device that computes locally on the data before (or instead of) forwarding.
• Gateways minimize compute at the plant; edge devices push compute toward the sensor.
• Most plants need both: gateway for aggregation, edge for low-latency analytics or bandwidth-constrained sites.
• The right choice depends on data volume, latency requirements, and connectivity reliability.

Short answer: An IoT gateway aggregates data from many sensors and PLCs and forwards it to higher systems (OEE platform, cloud, historian). An edge device computes locally on the data before forwarding (or instead of forwarding). Gateways centralize compute at the higher layer; edge devices distribute it. Most plants need both, gateways for aggregation and edge for low-latency analytics or bandwidth-limited sites.

What a gateway does

An IoT gateway:

• Talks multiple protocols (Modbus, OPC UA, MQTT) to sensors and PLCs.
• Aggregates the data.
• Translates formats.
• Buffers during connectivity issues.
• Forwards upstream to the OEE platform, historian, or cloud.

Gateways minimize compute at the plant. Decisions happen in higher systems.

What an edge device does

An edge device:

• Receives data from a small set of sensors (often colocated).
• Runs compute locally, anomaly detection, OEE calculation, control loops.
• Acts locally without round-tripping to the cloud.
• Forwards results (not raw data) upstream.

Edge devices push compute toward the sensor. Low-latency, bandwidth-efficient.

When to use a gateway

• Many PLCs and sensors to aggregate.
• Compute happens centrally (OEE platform, cloud).
• Bandwidth to upstream is sufficient.
• Latency requirements are moderate (seconds).

When to use edge

• Latency requirements are tight (sub-second).
• Bandwidth to upstream is limited or expensive.
• Connectivity is unreliable; local compute must continue.
• Raw data volume is high (vision, vibration) but decisions are simpler.

Hybrid patterns

Most real deployments combine both:

• Edge devices on critical assets for low-latency analytics.
• Gateway aggregating edge outputs and broader sensor data.
• Cloud or OEE platform receiving aggregated stream.

This pattern preserves edge benefits where they matter while maintaining gateway-level aggregation.

What runs where

Edge:

• Anomaly detection on vibration.
• Vision-based defect detection.
• Real-time OEE for a single line.
• Local control loops.

Gateway:

• Protocol translation.
• Data buffering.
• Aggregation across many assets.
• Format normalization.

Cloud / OEE platform:

• Cross-line analytics.
• Trend analysis.
• Multi-site rollup.
• Predictive models.

Common mistakes

1. Edge for everything. Distributed compute is harder to manage. Use edge where it pays off.

2. Gateway for everything. Misses the latency and bandwidth benefits of edge.

3. Insufficient edge hardware. Edge devices need real compute for real workloads. Underpowered devices fail under load.

4. Skipping the buffer. Connectivity drops happen. Both gateway and edge need local storage for recovery.

Security considerations

Both layers need security:

• Authentication to PLCs and sensors.
• Encrypted transport upstream.
• Device authentication to the cloud.
• Update mechanism for security patches.

Edge devices in particular need a managed update path, they sit at the network edge and are common attack targets.

Vendor categories

Gateways: Hilscher netRAPID, Moxa, Advantech, Siemens IoT2050, opensource solutions on industrial PCs.

Edge devices: NVIDIA Jetson (vision/ML), Litmus Edge, Crosser, custom Linux on industrial hardware.

Many vendors blur the line, devices that do both. Evaluate based on capability, not category.

How OEE platforms consume both

Many OEE platforms connect to gateways via OPC UA, MQTT, or REST. They consume edge device outputs as derived metrics rather than raw data, and unify the inputs into a single OEE view.

Fabrico connects to PLCs and IoT sensors over protocols including OPC UA and MQTT, and brings the data into one OEE view. Confirm your controllers and gateways with us in a demo.

See how Fabrico captures this automatically, read our OEE guide or book a demo.

Frequently asked questions

Is edge computing the same as fog computing?

Fog computing usually refers to compute at the network edge, similar to edge. Vendors use the terms slightly differently.

Do I need both gateway and edge?

For most production plants, yes. Gateways aggregate broadly; edge handles latency-critical work.

How is unified namespace related?

Unified namespace (UNS) is a pub/sub architecture often implemented via MQTT. Gateways and edge devices both publish to UNS.

Can I run ML on a gateway?

Sometimes. Lightweight ML works on gateways. Heavy ML (vision, deep learning) usually requires edge devices with GPU.

What protocols should gateways support?

At minimum OPC UA and MQTT. Modbus, Ethernet/IP, and legacy serial for older equipment.