Edge before it was called edge: what to compute at the machine, what to send to the center
Reaction time, latency, and network reliability demand different places for computation. How to think about distributing logic between a device and a central system.
The term "edge computing" is not yet part of everyday conversation. But the problem it describes has existed for a long time - and in automated manufacturing it comes up constantly. Where should the logic live: next to the device, or in a central system?
When I talk to engineers on the floor, this question surfaces in different forms. "We cannot rely on the network in the workshop." "The controller reacts too slowly when it has to go through the server." "We need a decision in milliseconds, not seconds." Each of those phrases points to the same thing: computation distributed in the wrong place.
Three reasons why logic needs to live near the device
The first is reaction time. If a robot or machine controller makes decisions through a central server, speed is bounded by network latency. On a warehouse floor with patchy Wi-Fi that can mean seconds. In a task requiring a response in fractions of a second, a centralized architecture simply does not work.
The second is network reliability. An industrial environment is not an office. Interference, outages, channel congestion. A system that depends on a constant connection has a single point of failure right at the critical moment in the process. Logic that lives near the device keeps running when connectivity drops.
The third is data volume. A high-speed camera on a quality control line generates gigabytes per minute. Streaming the full feed to the center makes no sense - neither in bandwidth terms nor in storage cost. Filtering and primary processing logic should sit where the data is born.
The data volume challenge from field equipment is one reason industrial systems start speaking like platforms rather than simply pointing everything at a central server.
What belongs in the center
Computing near the device is not an end in itself. It covers tasks with hard requirements on latency and connectivity. Everything else is better done centrally.
Training models, aggregating statistics across a whole equipment fleet, long-term history storage, analytics across multiple production areas, configuration management - these are tasks where centralization wins. There are no millisecond reaction requirements here. What matters is scale, a single point of control, and the ability to work with accumulated data.
A good architecture does not choose "everything on the device" or "everything in the center". It explicitly distributes tasks according to their nature and purpose.
Where the boundary falls in practice
In manufacturing I have seen several stable patterns.
Drive control and sensor response - always local. This is the physical layer, where latency is measured in milliseconds and the network plays no part at all.
Primary signal processing and operational decision-making - on an industrial controller or a local computer next to the line. This is the layer where logic is already complex enough to need programming, but still needs to be independent of the network.
Data aggregation, equipment health diagnostics, event forwarding - between device and center. A few seconds of latency is acceptable here, but buffering during connectivity loss is required.
Analytics, reporting, model training - in the central system or in the cloud. Computational resources and a unified picture of operations matter here.
Practical questions before designing
When you need to decide how to distribute logic, a few questions help:
- What is the acceptable latency for each decision - milliseconds, seconds, or minutes?
- What should the system do when connectivity is lost - stop, run in a degraded mode, or continue normally?
- How much data is generated, and what portion of it actually needs to be transmitted?
- Who is responsible for the device locally, and who owns the central system?
- How will logic on the device be updated when requirements change?
The last question is often underestimated. Updating logic across a hundred distributed devices is a separate problem that needs to be designed in from the start.
The word "edge" has not settled into common use yet, but the problem it describes is already clear. Those who address it deliberately today gain reliability and speed where they need it most.