At 3 a.m., a vibration signal on a conveyor gearbox drifts a few percent from its usual pattern. Nothing has failed yet. The question that decides what happens next is not whether the software can spot the drift — it is where the software runs when it does. Put the detection on a small computer inside the control cabinet and you can act in milliseconds. Put it in a cloud region three hundred kilometres away and you get cheaper compute, better fleet-wide context, and a dependency on a link that may or may not be healthy that night.

Neither answer is universally right. They fail differently, they cost differently, and they suit different jobs. Here is how to think about the trade-offs without getting stuck in vendor talking points.

Start with the loop you have to close

Before comparing architectures, ask one question about the asset: how fast must a decision change something physical? A machine guard, an emergency stop, a torque limit on a drive — these live in the tens of milliseconds and belong on the machine, full stop. A maintenance ticket that tells a planner to inspect a bearing next Tuesday can tolerate seconds, minutes, or a night of queued messages.

That single distinction sorts most of your use cases into two piles before anyone mentions model size or hardware cost.

Latency: what the round trip really contains

People compare "local inference" against "cloud inference" as if the inference were the whole story. It is usually the smallest part. A cloud path includes sampling, local buffering, the uplink over Wi-Fi, Ethernet or cellular, broker ingress, queueing behind other tenants, inference, a response, and then the return journey. Local inference skips the network but not the sampling, buffering or scheduling.

When latency settles the argument

Closed-loop control, safety functions, and anything that must keep working while the plant's internet connection is down. If the answer is "within the same machine cycle," you are writing edge code.

When it does not

Trend analysis, fleet comparisons, warranty reporting, and maintenance planning. Here a two-second delay is irrelevant, and the cloud's advantages in storage, query tooling and model iteration matter far more than the milliseconds you gave up.

Bandwidth: the cost of shipping raw data

This is where budgets quietly break. Consider one three-axis accelerometer sampled at 20 kHz with 16-bit resolution. That is three channels times 20,000 samples per second times two bytes, or roughly 120 KB per second — close to 1 Mbps for a single sensor. Ten such sensors on a cellular plan is a continuous stream of nearly 10 Mbps that you are paying to move, store and back up, most of which contains nothing interesting.

Edge processing exists largely to answer this problem. Compute a small set of features locally and send a few hundred bytes per second instead. Useful things to extract on the device:

  • RMS and peak values per axis, per time window
  • Kurtosis and crest factor, which respond to impulsive faults
  • A reduced FFT — a handful of frequency bins rather than the full spectrum
  • Envelope or demodulated bands around known bearing frequencies
  • Temperature deltas, cycle counts, and runtime hours
  • Simple threshold and rate-of-change flags

Keep a rolling buffer of raw samples on the device anyway — thirty seconds is often enough — so that when something does trigger, you can upload the actual waveform instead of guessing from a summary.

Privacy, residency and the politics of data

In industrial settings, "privacy" is often really about confidentiality. High-frequency data can reveal production rates, recipe changes, machine settings and throughput — information a competitor or a customer's auditor would find interesting. Cameras and microphones bring in operator behaviour, which touches personal data rules in many jurisdictions.

A workable default: process video, audio and full-resolution waveforms on site, and send only derived features, events and short triggered clips. Keep raw archives local where you can, and be deliberate about anything that leaves the network. If your data crosses borders, or includes anything that could identify a person, take proper advice on the obligations that apply to you rather than assuming an exemption.

Cost: the arithmetic nobody runs

Cloud pricing is easy to model for compute and storage, and much harder for connectivity, egress, integration engineering, and the ongoing work of keeping pipelines alive. Edge pricing looks expensive at first glance — industrial-grade hardware, an enclosure, a truck roll to install it — but it is a one-time cost per site that does not scale with data volume.

The variables that move the answer most are sensors per site, how much you filter before transmission, and how many sites you have. One site with three sensors rarely justifies a fleet of edge devices. Two hundred sites with thirty sensors each usually does, if only because the cellular bill becomes absurd.

Predictive maintenance and anomaly detection: where each belongs

Anomaly detection has a hidden dependency: you cannot know what is anomalous without a solid picture of normal. That picture improves with breadth, and breadth is what the cloud is good at.

Keep at the edge

Detection that must survive a network outage. High-frequency signal processing that would be wasteful to centralise. Anything on a metered or unreliable link. Fast reactions on a single asset, such as backing a machine down when a signature turns hostile.

Keep in the cloud

Fleet-wide baselines that account for duty cycle, ambient conditions and machine variant. Model training and re-training. Long-horizon trends, spare-parts planning, and the dashboards a reliability engineer actually lives in.

A workable hybrid loop, in order:

  1. Sample raw data at the edge and compute features locally.
  2. Hold a short rolling buffer of raw samples for evidence.
  3. Stream features continuously; upload raw excerpts only on trigger.
  4. Score locally so immediate actions do not wait for the network.
  5. Send scores and events upstream to enrich them with fleet context.
  6. Review, retrain centrally, and push updated models back down.
  7. Version every model and record which version produced which alarm.

A decision you can finish this week

Pick one asset that matters and one failure mode you would like to see coming. Write down how fast a response must happen, then build the smallest version of both paths: local scoring on a modest industrial computer, and the same features piped to your existing cloud stack. Run them side by side for a month and watch three things — how often the link goes down, how often the model disagrees with the maintenance team, and what the data transfer actually costs.

That experiment will tell you more than any architecture diagram. Most real deployments end up hybrid, but the good ones get there deliberately: latency-critical work close to the metal, context-hungry work in the cloud, and a clear plan for what happens when the connection disappears. Decide which failure you can tolerate, and the rest follows.

Photo: Schäferle / Pixabay