Edge computing has become one of the more overused terms in industrial technology marketing. Like most overused terms, it started with a useful meaning and has since been applied to such a broad range of products and approaches that it risks becoming meaningless. This guide explains what edge computing actually means in the context of industrial IoT, where it genuinely adds value, and where it is an unnecessary complication.
The Core Idea
In a traditional industrial monitoring architecture, a field device – a sensor, a PLC, an RTU – sends raw data back to a central server for processing. The server runs the logic: threshold comparisons, aggregations, alarming. Edge computing moves some or all of that logic closer to the data source, typically running it on a device at or near the field device itself. The “edge” refers to the edge of the network – the furthest point from the central server.
Why Edge Processing Matters for Industrial Sites
There are three main reasons to process data at the edge rather than sending everything to a central server. First, bandwidth reduction: a temperature sensor reading every second generates 86,400 data points per day. Sending averages every minute instead of raw readings reduces this to 1,440. Second, latency: decisions that need to happen in milliseconds cannot wait for a round trip to a cloud server. Third, resilience: if the WAN connection fails, an edge device can continue making local decisions and buffer data until connectivity restores.
Where Milesight Routers Fit
The Milesight UR75 runs Python scripts natively in its firmware environment. This means you can deploy data preprocessing logic directly on the router at the field site. A typical use case: the router collects Modbus readings from multiple field devices via RS485, applies local logic (calculate average, detect threshold breach, format data as MQTT payload), and publishes only processed events to the cloud SCADA platform. The raw Modbus polling never leaves the site. Only meaningful events travel over the cellular WAN.
When Edge Processing is Worth the Complexity
Edge processing adds complexity to the system. Firmware on a router is harder to update and test than code on a server. For most standard monitoring applications – polling, storing, alarming – running all logic at the SCADA server is simpler and more maintainable. Edge processing makes sense when: WAN bandwidth is genuinely constrained and expensive, when local decisions need to happen without WAN dependency, or when regulatory requirements mandate local data retention.