Edge vs cloud for industrial sensing: where should the data be evaluated?

The question of edge vs cloud for industrial sensing is usually framed as a philosophy. It is better treated as arithmetic. How much data does each sensor produce, how fast must a decision be made, what happens when the network fails, and who is allowed to hold which data? Answer those four, and the architecture mostly designs itself.

This article works through each question with numbers, then gives a decision table. Definitions first: edge computing means evaluating data on hardware at or near the machine. Cloud means evaluating it in a remote data centre, whether public cloud or a company's own. NIST's Fog Computing Conceptual Model (SP 500-325) describes the layer in between and names the reason it exists: traditional cloud-based IoT systems struggle with scale, device heterogeneity and high latency. For a broader introduction, see what edge AI in manufacturing means.

Edge vs cloud starts with data rates

Industrial sensing is not like IT telemetry. A temperature sensor reporting once a minute produces a trickle. A vibration or acoustic sensor sampled fast enough to see bearing impacts produces a flood.

The figures are simple multiplication: samples per second times bytes per sample times 86,400 seconds. A single machine with two vibration channels, a microphone and a thermal sensor is already above 170 GB a day before any camera is added. Uploading that continuously from one machine would need a dedicated uplink of more than 16 Mbit/s; from a hall of fifty machines, a data centre connection.

The conclusion is not that raw data is worthless. It is that raw data should be reduced where it is produced, and only the right parts should travel.

Latency: how fast must the answer arrive?

Some decisions are slow. A bearing that degrades over weeks gives a maintenance planner days to react, and an hourly cloud job is perfectly adequate.

Others are not. Chatter in a milling cut, a bad weld in a battery module, or a jam on a packaging line call for an answer within the cycle time of the process, often well under a second. A round trip over a factory network, a firewall, the internet and a cloud queue is unpredictable even when it is usually fast. Where the answer has to reach the operator or the line within the cycle, it belongs at the edge. Our posts on CNC spindle monitoring and time-stamping multimodal sensor data show why the timing of evaluation matters as much as its accuracy.

Availability: what happens when the network goes down?

Factory networks fail for ordinary reasons: switch replacements, firewall rule changes, a cut cable during building work. A cloud-only system goes blind during those hours, and unless the sensor buffers locally, the data is lost for good.

An edge system keeps measuring, keeps evaluating and keeps alerting locally. When the connection returns, it forwards what the cloud needs. The quality of that recovery is worth checking during procurement: is the gap logged, is it obvious in the data, and does recording resume without someone walking to the machine?

Regulation and data ownership

Two EU regulations shape where industrial sensor data goes.

The Data Act, Regulation (EU) 2023/2854, entered into force on 11 January 2024 and has applied since 12 September 2025, as the European Commission's Data Act overview states. It gives businesses and individuals the right to access data produced through their use of connected products such as machines. For a plant operator, data evaluated and stored on its own premises is the simplest situation to manage; data that only exists in a supplier's cloud needs contractual and technical access routes. We look at this in detail in our post on who owns your machine data.

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the Commission's CRA page, reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027. Every connected sensor, hub and gateway is a product with digital elements. Fewer open interfaces and less outbound traffic reduce the attack surface, which favours architectures that evaluate locally and push only what is needed. Our post on the Cyber Resilience Act covers the obligations.

What the cloud does better

None of this makes the cloud obsolete. It is the better place for:

• Fleet comparison. Spotting that one pump in forty behaves differently needs all forty in one place.
• Model training. Training on pooled data from many machines and sites needs compute and storage that a single edge device does not have.
• Long-term history. Years of features and events are cheap to keep centrally and valuable for reliability engineering.
• Integration. Maintenance management, ERP and reporting systems usually live centrally.

The workable pattern is a split: evaluate at the edge, send results, features, events and selected raw segments to central systems, retrain centrally, and deploy updated models back to the edge.

A decision table

Most real projects end up with ticks in both columns. That is the argument for a hybrid design rather than for choosing a side.

A procedure for deciding

1. List each sensor stream with its sample rate and bytes per sample, and calculate the daily volume.
2. For each use case, write down the latest useful time for a decision.
3. Ask IT how often the plant network has been unavailable in the last year, and for how long.
4. Clarify with legal and IT who must be able to access which data, under the Data Act and your contracts.
5. Decide which features, events and raw segments the central side really needs.
6. Size the edge hardware for evaluation plus local buffering for the longest expected outage.
7. Plan the model update path: how a retrained model gets back to the edge, tested and versioned.

How NeuroControls approaches this

We record and time-stamp data at the machine, and our hubs are designed to host models. Our Edge AI Hub runs on a RUBIK Pi 3 with a Qualcomm QCS6490, whose product brief lists an octa-core Kryo 670 CPU and up to 12 dense TOPS of AI performance, and the hub carries NVMe storage. Models are trained by our engineers on customer data; on-device inference as ONNX on the QCS6490's CPU was first proven on our Vibration Node, and NPU inference is coming soon. The hardware side is explained in our post on QCS6490-class hubs, and the hubs page lists both configurations.

Recording on site uses a versioned manifest, per-segment SHA-256 hashes, an append-only journal and tiered retention. After a power loss, the gap is logged, alerted and reported, and recording resumes by itself. Exports in NWB, MKV/HEVC, JSONL and CSV move data to central systems; Grafana, OpenSearch, Kafka and MES integration are available on request. The software page, the edge solution page and our architecture overview describe how the pieces connect, and the reasoning behind the hardware split is in why we build one node per function.