Edge vs Cloud Processing for Industrial Data

Fifty vibration sensors on a production line, each sampling at 25.6 kS/s, produce about 20 megabits per second of raw data, around the clock. Sending all of it to the cloud is possible on a good connection and pointless for most of what the plant needs to know. Throwing it all away at the machine and sending one number per hour loses the information that makes diagnosis possible. The edge vs cloud processing decision for industrial data is less a choice between two places than a decision about which step of the processing chain runs where. This article explains the trade-offs researchers and standards bodies describe, works through a data budget, and gives a way to place each step.

Key Takeaways

• Satyanarayanan (2017) described four reasons to compute at the edge: responsiveness, scalability by reducing data at the source, enforcing privacy and data policies, and masking cloud outages.
• Shi and colleagues (2016) framed edge computing as a response to devices becoming data producers rather than only consumers, with bandwidth, latency, energy and privacy as the driving constraints.
• Control loops and safety functions stay local. Cloud round-trip times and outages make the cloud unsuitable for anything that must act within milliseconds or keep acting when the link is down.
• Reducing raw data to features at the edge can cut volume by orders of magnitude. In the worked example, from about 220 GB per day to tens of megabytes, plus periodic raw captures.
• The cloud is where data from many machines and sites meet: fleet comparison, model training, long-term history and access for people who aren’t on site.

The problem: the data is produced where it’s least convenient to use

Industrial data is generated at the machine, often at high rates, and most of it is uninteresting most of the time. The people and systems that use it are spread out: the operator at the line, the reliability engineer at headquarters, the vendor who supports the equipment, the analytics team training a model on a year of data from twenty plants.

Traditional cloud architectures assume devices send data to a central place where all processing happens. That works for low-rate data and for questions that span the whole fleet. It breaks when raw data rates are high, when a decision must be made quickly, when the connection is unreliable, or when the data can’t leave the site for contractual or security reasons.

What researchers and standards bodies describe

Edge computing as a response to devices producing data

Shi, Cao, Zhang, Li and Xu’s 2016 paper “Edge Computing: Vision and Challenges” in the IEEE Internet of Things Journal argued that as devices at the edge of the network increasingly produce data rather than only consume it, processing at least part of that data near its source reduces bandwidth demands and response time, and can reduce energy use and protect privacy. They also listed what makes edge computing hard: programmability across heterogeneous devices, naming and discovery, data abstraction, service management, and privacy and security at many distributed points.

Four reasons to compute near the source

Mahadev Satyanarayanan’s 2017 article in Computer, “The Emergence of Edge Computing,” described edge computing in terms of small data centers or servers close to devices (cloudlets) and gave four benefits: highly responsive services because of low latency to the device; scalability, because analytics at the edge reduces the data sent to the cloud; the ability to enforce privacy policies before data leaves its source; and the ability to mask cloud outages by continuing to operate locally. Each maps directly onto an industrial requirement.

Fog: a layer in between

NIST Special Publication 500-325, Fog Computing Conceptual Model (Iorga and colleagues, 2018), describes a distributed, federated computing layer between devices and the cloud, intended to address the scale, device diversity and latency problems of purely cloud-based IoT systems. It also distinguishes mist computing, lightweight processing at the very edge, in the devices or sensors themselves. In plant terms: a sensor that computes features is mist, a gateway or industrial PC on the line is fog, and a cloud platform is the cloud.

The processing chain and security boundary

ISO 13374-1 divides condition-monitoring processing into blocks from data acquisition and manipulation through state detection, health assessment, prognostics and advisory output. That chain is a natural way to split work: acquisition and manipulation (filtering, feature extraction) near the sensor, state detection at the edge or in the cloud, and health assessment and prognostics wherever enough history and fleet data exist.

NIST SP 800-82 Rev. 3, the guide to operational technology security, adds the constraint that the plant’s control network should be separated from other networks. An edge device that collects data and sends it outward, without accepting inbound connections from the internet, fits that architecture better than a cloud service that reaches into the plant.

A data budget, worked through

Illustrative numbers for 50 single-axis vibration sensors:

• Raw rate per sensor: 25.6 kS/s × 2 bytes = 51.2 kB/s.
• All sensors: 2.56 MB/s, about 20.5 Mbit/s of continuous upload.
• Per day: 2.56 MB/s × 86,400 s ≈ 221 GB.

Now move feature extraction to the edge:

• Features (overall RMS, peak, kurtosis, a few band energies): about 200 bytes per sensor per minute, about 14 MB per day for all 50.
• Raw captures for diagnosis and model training: one second every ten minutes per sensor, about 7.4 MB per sensor per day, about 370 MB per day for all 50.

Total: under 400 MB per day instead of 221 GB, a reduction of more than 500 times, while keeping enough raw data to diagnose a fault or retrain a model. If the link goes down, a gateway with local storage can buffer days of features and captures and forward them when it’s back.

Latency is the other half. A protection or control function that must respond within milliseconds runs in the controller or the device. A local alarm to an operator, which must appear within seconds even when the internet is down, runs at the edge. A weekly fleet report runs in the cloud.

Where each step usually belongs

Processing step	Device (mist)	Edge (fog)	Cloud	Why
Control and protection	Yes	Sometimes	No	Millisecond timing; must work offline
Sampling, filtering, feature extraction	Yes	Yes	Rarely	Raw rates too high to send
Local alarms and operator display	Sometimes	Yes	No	Seconds; must work during outages
Buffering and store-and-forward	Limited	Yes	No	Masks link outages
Fleet comparison and dashboards for remote staff	No	No	Yes	Needs data from many machines and sites
Model training	No	Rarely	Yes	Needs history and compute
Model inference	Sometimes	Yes	Sometimes	Depends on latency and data rate
Long-term storage	No	Limited	Yes	Cost and durability

What to actually do

Place each step, not the whole system

List the processing steps from acquisition to decision and decide for each one where it runs, using latency, data rate, outage tolerance and data policy as criteria.

Reduce data at the source, but keep raw samples

Compute features at the edge and send them frequently. Keep periodic raw captures as well, so diagnosis and new features remain possible.

Design for the link going down

Buffer at the edge, timestamp everything at the source, and make sure local alarms and displays work without the cloud.

Keep the plant’s network boundary intact

Use edge devices that send data outward and don’t require inbound connections from the internet, and keep them separate from the control network.

Plan how edge software gets updated

Edge devices need the same update discipline as any embedded product: signed updates, staged rollouts, and a way to recover from a bad release.

What not to do

Don’t put a control function behind a cloud round trip. And don’t throw away raw data at the edge just because the dashboard only shows averages.

How to put it to work

If you have an hour

Draw the processing chain for one data stream and mark, for each step, the latency it needs, the data rate going in and what happens if the internet is down.

If you have a sprint

Prototype feature extraction on a gateway for a few sensors, with store-and-forward and periodic raw captures, and measure bandwidth, alert latency and behavior during a deliberate network disconnection.

If you want it to last the product’s lifetime

Version feature definitions and edge software together, keep a record of which processing ran where for each period of data, and revisit the placement when data rates, models or connectivity change.

The question to ask yourself: “If the plant’s internet link were down for two days, what would stop working, and is that acceptable?”

Frequently asked questions

What is the difference between edge and cloud processing?

Edge processing happens on or near the machine, in a sensor, gateway or local server. Cloud processing happens in remote data centers. The edge offers low latency, less data to send and independence from the internet link; the cloud offers data from many sites, large compute and long-term storage.

When should industrial data be processed at the edge?

When the function needs fast responses, when raw data rates are too high to send economically, when it must keep working during outages, or when data must stay on site. Feature extraction, local alarms and buffering are common edge functions.

Is edge computing more secure than the cloud?

Not automatically. Keeping data on site and avoiding inbound connections can reduce exposure, but edge devices are many, distributed and physically accessible, and each needs secure configuration and updates.

What is fog computing?

NIST describes fog computing as a distributed computing layer between devices and the cloud, such as gateways and local servers, with mist computing as lightweight processing in the devices themselves.

Can machine learning models run at the edge?

Inference often can, on gateways or even microcontrollers, depending on the model. Training usually happens in the cloud, where history from many machines and enough compute are available.

Related reading: vibration data for predictive maintenance, Modbus vs OPC UA vs MQTT and vibration anomaly detection at the edge.

Sources

1. Shi, W., Cao, J., Zhang, Q., Li, Y., & Xu, L. (2016). “Edge Computing: Vision and Challenges.” IEEE Internet of Things Journal, 3(5), 637–646. https://doi.org/10.1109/JIOT.2016.2579198
2. Satyanarayanan, M. (2017). “The Emergence of Edge Computing.” Computer, 50(1), 30–39. https://doi.org/10.1109/MC.2017.9
3. Iorga, M., Goren, N., Feldman, L., Barton, R., Martin, M., & Mahmoudi, C. (2018). Fog Computing Conceptual Model. NIST Special Publication 500-325. https://csrc.nist.gov/pubs/sp/500/325/final
4. International Organization for Standardization (2003). ISO 13374-1:2003, Condition monitoring and diagnostics of machines – Data processing, communication and presentation – Part 1: General guidelines. https://www.iso.org/standard/21832.html
5. Stouffer, K., et al. (2023). Guide to Operational Technology (OT) Security. NIST Special Publication 800-82 Rev. 3. https://doi.org/10.6028/NIST.SP.800-82r3