Industrial Edge Computing: Low Latency Where Data Happens

Actualizado: 2026-05-03

Industrial edge computing is the movement of computing capacity from the centralised cloud to where data is generated — the plant floor, the machine, the robotic cell. The reason is not primarily technological: it is physical. A welding robot’s control loop requiring 10 ms feedback cannot wait 150 ms round-trip to a cloud region. Latency is not a metric you can improve with more bandwidth; it is a consequence of the speed of light and distance.

Key takeaways

• Local latency (10-50 ms) vs cloud (100-500 ms): the difference is critical in process control and is non-negotiable.
• Edge reduces cloud bandwidth: industrial sensors generate volumes that would make it prohibitively expensive to send everything to the cloud.
• The plant keeps running without external connectivity, eliminating an entire category of availability risks.
• OPC UA is the dominant interoperability protocol between OT/IT systems; any mature edge architecture incorporates it.
• K3s and MicroK8s bring container orchestration to hardware with less than 512 MB of RAM.

Why edge in industry

The central distinction of industrial edge vs telecom or retail edge is that here latency requirements are not preferences but safety and process requirements. Three concrete reasons justifying the investment:

Control latency: a modern PLC can execute a control cycle in 1-10 ms. Adding a cloud round-trip destroys that window. For motion control, robotic welding, laser cutting, or CNC applications, compute must be metres from the actuation, not hundreds of kilometres away.

Data volume: an industrial machine vision line can generate 2-5 GB/s of raw images. Filtering, compressing, and sending only the relevant events to the cloud — detected defects, process anomalies — reduces traffic by 100x to 1,000x. Edge does not eliminate the cloud; it feeds it with valuable data, not noise.

Operational resilience: a plant depending on external connectivity to operate has a critical single point of failure. In industry, process availability takes priority over any other metric. A well-designed edge architecture maintains full local operation when the WAN goes down, and synchronises with the cloud when connectivity is restored.

Typical architecture

The typical industrial edge architecture has three clearly differentiated layers:

Field layer: PLCs, sensors, actuators, and robots speaking industrial protocols — Modbus, Profinet, EtherNet/IP, CC-Link. Most legacy devices do not have IP; modernisation usually means adding gateway adapters, not replacing hardware.

Edge layer: one or more edge servers with x86 or ARM CPUs, frequently in rugged form factor (DIN rail, IP65). Here lives the local processing: the OPC UA gateway that normalises field protocols, real-time analytics containers, the machine vision inference model, and the MQTT broker managing local messaging.

Cloud/corporate layer: receives filtered and enriched data from the edge, stores it in a data lake, processes it with historical analytics, and returns configurations, updated models, or policies to the edge.

[PLCs / Sensors] → OPC UA Gateway → [Edge Server]
                                          ↓
                              [MQTT Broker / Analytics]
                                          ↓
                              [5G/Fiber] → Cloud / MES

OPC UA: the common language between OT and IT

OPC UA (Unified Architecture) is the interoperability standard that lets systems from different manufacturers communicate without proprietary middleware. In practice, the OPC UA gateway at the edge:

• Speaks Profinet with Siemens PLCs, Modbus with temperature sensors, EtherNet/IP with Fanuc robots.
• Exposes all that data under a unified information model accessible via standard TCP.
• Adds authentication, encryption, and access control to OT traffic — something that Modbus, for example, lacks.

For industrial architectures also considering private 5G on the plant floor, OPC UA over TSN (Time-Sensitive Networking) is the technical combination enabling deterministic control over shared 5G infrastructure.

Kubernetes at the edge: K3s and MicroK8s

Bringing container orchestration to industrial edge seemed excessive three years ago. With K3s (Rancher Labs, now CNCF) and MicroK8s (Canonical) it no longer does. Both reduce Kubernetes requirements to:

• K3s: 512 MB RAM minimum, 70 MB single binary, embedded certificates, SQLite by default instead of etcd.
• MicroK8s: 1 GB recommended, snap installation, addons activatable with one command (local registry, Istio, GPU operator).

What Kubernetes enables at the edge is the same benefit as in the cloud: declarative deployment, rolling updates without downtime, automatic container recovery, and uniform configuration and secret management. For teams already running Kubernetes in production, the K3s learning curve at the edge is minimal.

A concrete use case: updating the machine vision model at ten geographically distributed manufacturing points. Without Kubernetes, the process involves SSH to each server, manual model transfer, service restart. With K3s and a local registry, a single kubectl rollout propagates the change in a controlled way, with automatic rollback if the new model fails its health check.

Private 5G: deterministic connectivity on the plant floor

Private 5G — an operator or own-operator cell within the plant perimeter — changes the edge connectivity equation in two ways:

• Deterministic latency: 5G URLLC (Ultra-Reliable Low-Latency Communication) guarantees latencies below 1 ms between devices on the same cell, enabling wireless control use cases that WiFi 6 cannot guarantee due to its collision management.
• Mobility: AGVs (Automated Guided Vehicles) and collaborative robots can move freely on the plant floor without losing connectivity between access points, something Ethernet cabling can never provide.

The most common architecture combines the edge server as a Multi-access Edge Computing (MEC) node within the 5G cell, processing device data at maximum one-millisecond latency before deciding whether to propagate anything to the cloud layer.

Cases where edge clearly beats cloud

Not every use case justifies the additional complexity of edge. Those that clearly do:

• Inline visual quality control: real-time machine vision model inference on each part, at line speeds of 20-60 parts per minute.
• Local predictive maintenance: vibration and temperature analysis of motors with local LSTM or FFT models, without sending signal streams to the cloud.
• Safety systems: intrusion detection in safety zones, emergency stops, and safety logic that cannot depend on external connectivity.
• Cloud-free synchronisation: plants in areas with intermittent connectivity (mining, offshore) that need to operate autonomously for days.

Where edge does not pay: historical analytics over months of data, model training, cross-site reporting, or any load without local latency or resilience requirements.

Conclusion

Industrial edge computing is not a trend; it is an engineering response to physical constraints that the cloud cannot solve. Control latency, bandwidth economics, and operational resilience are objective arguments, not marketing ones. The stack — OPC UA, K3s, MQTT, private 5G — is mature enough for production projects. The relevant decision is no longer “edge or cloud?” but “what processing lives at which layer, and how do they synchronise reliably”.