Edge computing in manufacturing means processing data on or near the machine that produced it, on a device on the plant floor, instead of sending everything to a distant cloud first. You compute at the edge when the decision has to be fast, the data is too big to ship, or the line must keep running when the internet does not.
The short version: the cloud is where you aggregate, train, and look across plants; the edge is where you sense, decide, and act in the moment. Most real deployments are not edge-versus-cloud at all. They are a deliberate split, and getting that split right is the actual engineering problem.
What is edge computing on a plant floor?
It is running software, filtering, analytics, or AI inference, on hardware physically close to the equipment. That hardware might be an industrial PC in a control cabinet, a small server in the plant's network closet, or compute built into a smart camera or gateway. The defining trait is location: the processing happens feet from the PLC and sensors, not in a data center hundreds of miles away.
This sits just above the control layer. Your PLCs and SCADA systems already do hard real-time control in milliseconds. Edge computing adds a layer that can do heavier work, a vibration model, a vision inference, a downtime-reason classifier, on the same fast timescale, then pass summaries and exceptions upward rather than raw firehoses of data.
It is worth being precise about what "edge" is not. It is not the PLC itself, the PLC does deterministic control and is the wrong place for a machine-learning model or a heavy analytic. And it is not a private cloud you happen to own; a server two buildings away over a congested link has most of the cloud's latency problems. The edge is specifically compute placed where the data is generated, sized for local decisions, and independent enough to keep working when the rest of the network is not.
Why compute at the edge instead of the cloud?
Four reasons come up again and again on real lines.
- Latency. A round trip to the cloud and back is tens to hundreds of milliseconds on a good day. If you are pulling a bad part off a line or stopping a press, that is too slow. A decision made at the edge happens in single-digit milliseconds.
- Bandwidth and cost. A single high-speed vision camera or a rack of vibration sensors can generate more data than your plant's internet link can carry, and shipping all of it to the cloud is expensive. Filtering at the edge sends kilobytes of results instead of gigabytes of raw signal.
- Resilience. Plant internet goes down. If your quality checks or downtime logging depend on a live cloud connection, they stop when the link does. Edge compute keeps working offline and syncs when the connection returns.
- Data gravity and privacy. Some process data is sensitive or simply too large to move. Keeping it local, and sending only derived results upstream, is often the cleaner architecture.
The trend behind this is not hype. Gartner has forecast that around 75% of enterprise-generated data will be created and processed outside a traditional centralized data center or cloud, a large jump from a small fraction only a few years earlier. Manufacturing, with its wall of sensors and machines, is squarely in the middle of that shift.
What belongs at the edge, and what belongs in the cloud?
The split is not ideological; it follows the timescale and the purpose of the work. Anything that must happen now, survive an outage, or shed data volume belongs at the edge. Anything that benefits from scale, history, or cross-plant comparison belongs in the cloud.
| Work | Runs best at | Why |
|---|---|---|
| Reject a defective part inline | Edge | Milliseconds; cannot wait for a round trip |
| Detect a vibration anomaly on a motor | Edge | High-rate data; filter locally, alert on exception |
| Log downtime and OEE during an outage | Edge | Must keep working when the link drops |
| Train the anomaly model on a year of data | Cloud | Needs scale, history, and heavy compute |
| Compare OEE across five plants | Cloud | Aggregation across sites |
| Long-term storage and audit trail | Cloud | Durable, searchable, cheap at rest |
How does AI change the case for the edge?
AI is the reason edge computing in manufacturing went from a niche to a default. Running a trained model, vision inspection, anomaly detection, a downtime classifier, is inference, and inference wants to be close to the data for exactly the latency and bandwidth reasons above. You train the model centrally on lots of history, then push it to the edge to run against the live line. This "train in the cloud, infer at the edge" pattern is now the standard shape for agentic AI on a plant floor: the model senses and reasons locally, and only the conclusions and actions travel upward.
That is also where an operational layer earns its keep. The edge is good at one machine's decision; it is not where you want to reconcile the ERP, the MES, the paperwork, and every line's edge nodes into one picture. A real-time operational layer aggregates the edge, pulling the summaries, exceptions, and actions from many nodes into a coherent view a supervisor can act on and an machine-monitoring program can trust.
How do you deploy edge computing without a science project? A five-step approach
Edge deployments fail the same way big cloud projects do, too much at once. Keep it bounded.
- Start from one painful, fast decision. Pick a use case where latency or an outage actually hurts: inline reject, a motor you keep losing, downtime logging that dies with the wi-fi. Not "collect all the data."
- Decide the edge/cloud split explicitly. Write down what the edge node decides locally and what it sends upstream. Ambiguity here is how firehoses of raw data end up in the cloud by accident.
- Right-size the hardware. Match compute to the model. A downtime classifier runs on a small industrial PC; a high-speed vision model may need a GPU gateway. Do not overbuy for a demo.
- Plan for offline first. Assume the network will drop. The edge node must keep logging and deciding, then reconcile cleanly when the link returns. Test this on purpose.
- Aggregate to one operational layer. Feed the edge results into a single real-time view rather than a dozen separate screens, so the plant sees one truth instead of many.
By the numbers
The center of gravity for enterprise data is moving to the edge. Gartner has forecast that roughly 75% of enterprise-generated data will be created and processed outside a traditional centralized data center or cloud, up from around 10% only a few years before (Gartner, "What Edge Computing Means for Infrastructure and Operations Leaders"). For manufacturing specifically, the drivers are the same ones on any plant floor: sensor data volumes that outrun the network, decisions that cannot wait for a round trip, and lines that must run through an outage. Edge computing is less a new product category than a return of compute to where the data is born.
What are the trade-offs and failure modes?
Edge computing is not free lunch. Every node you place on the floor is a small computer someone has to patch, secure, and eventually replace, and a plant with fifty edge devices has a fifty-device fleet-management problem. Models drift, too: a vision model trained last year on last year's product can quietly start passing bad parts, and because it runs locally, nobody notices until the complaints arrive. The discipline that keeps edge fleets healthy is treating them like managed assets, versioned software, monitored health, and a way to push updated models, rather than boxes you install and forget.
The other common failure is fragmentation. Each vendor's smart camera, sensor gateway, and analytics box comes with its own screen and its own data format, and a plant can end up with a dozen edge islands that each know one thing and none of which talk. That is the exact silo problem the edge was supposed to solve, relocated to the floor. The fix is to insist that whatever runs at the edge can hand its results to one shared operational layer, so local speed does not cost you a single view of the plant.
Where does the edge fit in the bigger picture?
The edge is a tier, not a strategy on its own. It handles the fast, local, resilient work; the cloud handles scale and history; and something has to connect them to the ERP, the MES, and the paperwork so the plant sees one coherent picture instead of a scatter of clever but isolated nodes. That connective role is where Harmony sits, pulling machine signals, edge results, existing systems, and digitized paperwork into one real-time operational layer, no rip-and-replace. It is the same foundation that makes smart factory technology and generative AI useful rather than academic. See how CLS made its floor data real-time or the connectivity groundwork in industrial IoT.