Edge computing in manufacturing means processing data on a device right next to where it is produced — the machine, the line or the remote site — and sending only the results to a central server or the cloud. Factories use it for millisecond decisions, jobs that must survive network drops and sensor streams too large to ship raw.
Where does your factory data actually go?
A familiar picture: a line with a handful of PLCs, some energy analysers, a vibration sensor and a camera for quality inspection. Management says, "Let's push everything to the cloud and monitor it from there." For a few weeks the dashboard looks great. Then the internet connection drops one afternoon and those hours appear as a gap. When someone tries to stream the camera feed to the cloud, the uplink cannot cope, and latency means defective parts pass the reject gate before the verdict arrives.
The problem is not the cloud. It is sending every job to the same place. Seeing within seconds that a machine has stopped, analysing a motor's vibration spectrum at thousands of samples per second, and reporting a monthly OEE trend have completely different architectural needs. Edge computing is simply the discipline of separating them.
Legacy equipment makes the point even clearer. When you retrofit older machines with sensors, the current clamps and counters already feed a gateway. Whether that gateway merely forwards data or actually processes it is an edge decision.
The cost of processing data in the wrong place
The most visible price of a purely centralised design is downtime. Siemens' True Cost of Downtime 2024 report found that large plants average 25 unplanned downtime incidents a month and lose 27 hours a month to them. The same report puts the cost of an hour's unplanned downtime at $2.3 million in a large automotive plant and $36,000 in fast-moving consumer goods.
Siemens estimates that the world's 500 largest companies lose almost $1.4 trillion a year to unplanned downtime, equivalent to 11% of their revenues. — Siemens, The True Cost of Downtime 2024
Some of that downtime can be prevented with early warning, but only if the warning is not lost to a network outage, cloud latency or sampling thinned out to save bandwidth. Central IT infrastructure is itself exposed to outages: in the 2025 survey of data centre and IT operators cited in Uptime Institute's Annual Outage Analysis 2026 announcement, 57% of respondents said their most recent major outage cost more than $100,000.
Condition monitoring is no longer niche either. Eurostat's statistics on IoT use in enterprises show that in 2021, 29% of EU enterprises with ten or more employees used IoT, and 24% of those used sensors for condition-based maintenance. As sensor counts grow, the network, storage and compute burden of "send everything raw to the centre" grows with them.
What is edge computing in manufacturing? Edge, fog and cloud tiers
Edge computing in manufacturing is usually described in three tiers. Drawing the boundaries clearly makes it much easier to agree on where each job belongs.
- Device and machine tier: PLCs, sensors, cameras and drives. Data is born here, and control loops close here.
- Edge tier: an industrial gateway or compact industrial PC on the line or in the control cabinet. Protocol translation, filtering, aggregation, local alarms, image inference and store-and-forward buffering during outages happen here.
- Central and cloud tier: the plant server or the cloud. Multi-site comparison, long-term storage, reporting, model training and ERP/MES integration live here. A digital twin of the line also lives here, fed by the clean data coming up from the edge.
Some vendors call the plant-server layer between edge and cloud "fog". The label matters less than having a written answer, for every data flow, to the question: "Where is the raw data processed, and what travels to the centre?"
The edge tier typically talks to field devices over Modbus or OPC UA and publishes upstream over MQTT. As mqtt.org describes it, MQTT is a lightweight, OASIS-standard publish/subscribe protocol with three quality-of-service levels: QoS 0 (at most once), QoS 1 (at least once) and QoS 2 (exactly once). For critical production counters, choosing the QoS level deliberately and giving each record a key the receiver can use to discard duplicates markedly reduces the risk of duplicated or missing records after an outage.
Edge or cloud? A decision table for factory workloads
The table below scores common manufacturing workloads against four criteria. If several criteria point to the edge for a given job, processing it next to the machine is usually the right call.
| Workload | Response time needed | Data volume | Must it keep running offline? | Recommended location |
|---|---|---|---|---|
| Machine run/stop signal and local alarm | Sub-second | Low | Yes | Edge |
| Vibration spectrum analysis (high sample rate) | Seconds | Very high | Yes | Edge (summary to centre) |
| Camera-based defect rejection | Milliseconds | Very high | Yes | Edge |
| 15-minute energy consumption summaries | Minutes | Low | With buffering | Edge collects, cloud stores |
| OEE and shift reports | Hours | Medium | No | Central / cloud |
| Multi-site benchmarking and model training | Days | High (historical) | No | Cloud |
Treat the table as a starting point, not a rulebook. Calculating OEE happens centrally, for instance, but the reliability of the stop signal it depends on is secured at the edge. Likewise, in computer vision quality inspection inference runs on the line while retraining happens centrally.
Rolling out edge computing: a six-step framework
- Inventory your data flows. For each machine, list which signals it produces, over which protocol, how often, and who uses them.
- Run every flow through the decision table. Mark it edge, central or cloud based on response time, volume and the need to run offline.
- Choose edge hardware for the environment. Specify an enclosure rated for the dust, humidity, vibration and temperature on site, the I/O count and the compute headroom; if image analysis is in scope, plan for an accelerator from day one.
- Write the buffering and sync rules. Decide how many hours of data are held locally during an outage, and in what order and at what QoS level they are sent once the link returns.
- Design security and remote management. Because the edge device touches both the OT network and the outside world, segmentation, certificate-based identity, remote software updates and access logging are non-negotiable.
- Pilot on one line, then replicate. Measure for two to four weeks on a machine group — latency, lost-data rate and alarm accuracy — then turn the configuration into a template.
Step five is the one most often skipped. An edge device is a new bridge between the plant network and the outside world, so the principles of OT and SCADA security apply in full. At the centre, remember that raw sensor streams do not fit comfortably in ordinary tables; your choice of time-series database for IoT data determines how the summaries arriving from the edge can be queried.
Edge computing vs SCADA vs remote monitoring
These three terms are often blurred. A SCADA system supervises the process and lets operators take control; edge computing is an architectural approach that can feed or complement SCADA. A remote monitoring IoT platform gives you visibility of dispersed sites and may run edge processing on its own field devices.
In short: SCADA says "I run the process", remote monitoring says "I can see the site", and edge computing says "I process data in the right place". A plant can — and usually should — have all three, provided their responsibilities do not overlap. Predictive maintenance follows the same pattern: in predictive maintenance programmes, raw vibration data is usually condensed at the edge while models are trained centrally.
How Digital Bridge delivers edge projects
Digital Bridge is a software and hardware company founded in Adana in 2013, serving manufacturers across Türkiye both remotely and on site. The same team covers electronics and PCB design, mechanical enclosures, embedded firmware and web/mobile dashboards, so we can design the edge tier around the line's real needs instead of forcing it into an off-the-shelf box.
- Discovery and needs analysis: Industry 4.0 engagements start with a free site assessment. We map machine protocols, the existing network and which data feeds whose decisions, then turn that into a written proposal with scope, phases and fees.
- Hardware: when an off-the-shelf industrial gateway is not enough, our IoT device manufacturing service designs a purpose-built edge device; the technical feasibility study for hardware is free.
- Pilot: we start with a single line or a few critical assets. In predictive maintenance pilots we work with one to three critical machines with the aim of making the value visible in metrics within the first 30–60 days.
- Integration: we connect edge data to custom SCADA and HMI screens, to our remote monitoring platform, and through system integrations to MES and ERP. Our MES works with Logo, SAP, Mikro and bespoke ERPs.
- Vision: for camera-based quality control we run computer vision models on a local server or on the line itself, cutting latency and bandwidth demand.
On custom SCADA projects the source code belongs to the client, with no additional licence fees, so the SCADA layer that consumes edge data can be extended later by any team you choose.
Where to start
Edge computing is not a product purchase; it is a decision about where data lives and gets processed. Map the data flows on one line, run them through the decision table and pilot on the machine that causes the most downtime. For the bigger picture, our Industry 4.0 roadmap for SMEs shows where edge fits in the sequence, and the Industry 4.0 topic hub collects the related guides.
If you would like to draw the edge, plant and cloud boundaries for your own line together with us, request a site assessment through our contact page. We will look at your machines and network and come back with a written recommendation.