Every stage of a sensor pipeline reduces data and discards something. The split between device and cloud is best chosen by looking at those two properties per stage, rather than by deciding in advance that processing belongs in one place.
The pipeline as a sequence of reductions
A typical path from transducer to decision passes through stages that could each run on either side of the link:
- Acquisition. Sampling and analogue-to-digital conversion. Necessarily on the device.
- Conditioning. Calibration coefficients applied, invalid samples flagged, units normalised.
- Filtering. Low-pass, de-spiking, outlier rejection.
- Reduction. Downsampling, aggregation into per-window statistics, report-by-exception.
- Feature extraction. Spectra, band energies, time-domain features per window.
- Inference. A model producing a classification or a score.
- Aggregation across devices. Fleet statistics, peer comparison, cross-device correlation. Necessarily central.
The first and last are fixed. Everything between is the decision, and the standard shape of the answer is a cut point: stages before it run on the device, stages after it run centrally.
Reduction ratio and irreversibility
Two numbers characterise each stage, and together they decide it.
Reduction ratio is bytes in divided by bytes out. Calibration is 1:1 — it changes values without changing volume, so running it on the device saves nothing in bandwidth. Aggregating a 100-sample window into four statistics is 25:1. A spectral feature vector from a 1,024-sample window might be 64:1. Inference producing one label from a window is a thousand to one or more. Ratios multiply along the chain, so the cut point’s cumulative ratio is what determines the link cost.
Irreversibility is what the stage destroys. A calibration is reversible if you keep the coefficients. Filtering is not: the removed frequency content is gone. Aggregation destroys everything except the retained statistics. Inference destroys everything but the answer, and if the model is later found to be wrong, the data that would let you retrain it never existed.
The rule that falls out is short. Push stages with high reduction and low irreversibility onto the device, because they are nearly free wins. Be very careful with stages that are highly irreversible, because on the device the discarded data is gone permanently, while in the cloud the raw stream is still on disk and the decision can be revisited. This is the same reasoning behind keeping raw data alongside lossy representations in sensor stream compression.
A worked split
A vibration monitor, with stated assumptions:
ASSUMPTIONS
sampling 3-axis at 5 kHz, 16-bit
duty 2-second burst every 10 minutes
link cellular, metered
device Cortex-M4F class, FPU, no accelerator
RAW BURST
3 * 5,000 * 2 s * 2 B = 60,000 B = 60 kB
bursts per day 144
per day 8.64 MB
per month 259 MB per device
CUT AFTER FILTERING (band-limit to 1 kHz, decimate 5x)
12,000 B per burst -> 51.8 MB/month ratio 5:1
CUT AFTER FEATURE EXTRACTION
per axis: 20 band energies + 8 time-domain stats = 28 float32
3 * 28 * 4 B = 336 B per burst
per month 336 * 144 * 30 = 1.45 MB ratio 179:1
CUT AFTER INFERENCE
1 label + 1 score = 8 B per burst
per month 8 * 144 * 30 = 34.6 kB ratio 7,500:1
COMPUTE ON DEVICE
FFT: 1,024-point real FFT is ~5 * 1024 * log2(1024) = ~51k flops
ten windows per axis per burst, three axes = ~1.5 Mflop per burst
at 144 bursts/day = 221 Mflop/day, trivially within budget
The interesting result is where the returns stop. Moving the cut from filtering to features cuts the link volume by 36 times. Moving it from features to inference cuts it by a further 42 times, but from 1.45 MB to 34.6 kB per month — both are already small enough that the link cost is negligible, so the second move buys almost nothing in bandwidth while costing all the ability to retrain from real data. On these numbers the feature cut is the right one, and the argument that decides it is not the reduction ratio but the fact that the extra reduction was no longer needed.
The constraints that override the arithmetic
- Latency requirements move the cut right to the device. If a response must happen within a control cycle, or when the link is unavailable, inference has to be local regardless of bandwidth. The connectivity assumption is doing the work here, not the data volume.
- Energy can make computing more expensive than sending. On a battery device with a short-range radio, the FFT may cost more energy than transmitting the samples would have. The comparison is derived in on-device inference battery cost and it does not always favour computing locally.
- Cross-device work cannot move to the device. Peer comparison, fleet baselines and correlated anomaly detection need data from many devices at once, so any stage depending on them stays central by definition.
- Updating device-side stages is expensive. A filter cutoff or a feature definition that lives in firmware requires an over-the-air campaign to change, so anything you expect to iterate on belongs in the cloud during development even if it will move to the device eventually.
- Regulated or safety functions may be constrained explicitly. Some domains require that data supporting a decision be retained, which forbids destroying it on the device. That is a compliance input, not an engineering preference.
- Privacy pushes the cut left. Where the raw signal is personal — audio, video, location, physiological data — reducing on the device so that identifiable data never leaves it is often the deciding consideration, and it can justify a cut that the bandwidth arithmetic would not.
The pattern that usually wins
The arrangement that resolves most of the tension is not a single cut at all. Run the reduction on the device and send the reduced stream continuously, but retain the raw data locally in a short circular buffer and upload the full-resolution window on demand — triggered by an anomaly, by a request from the platform, or by a random sampling rule that captures a small fraction of ordinary windows.
This gets the bandwidth of the aggressive cut and most of the retrainability of the conservative one. A device retaining the last ten minutes of raw data needs only a few megabytes of flash, and uploading one percent of windows plus every anomalous one adds a small fixed percentage to the link cost while producing a genuine, if biased, sample of raw data. The bias is the thing to be careful about: a training set made only of windows the current detector found interesting teaches the next model to agree with the current one, which is why the random component matters and should not be dropped as an economy.
Two implementation notes make this work in practice. The trigger has to be able to reach backwards, since by the time an anomaly is detected the interesting data is already in the past — that is what the circular buffer is for, and the buffer must be longer than the detection latency. And on-demand uploads need to be rate limited per device and per fleet, because a fault condition that affects many devices at once will otherwise trigger simultaneous full-resolution uploads across the entire fleet and produce a bill and a congestion incident at the worst possible moment. The cost arithmetic for that link is in what it costs to ingest a million sensor readings a day.
Top comments (0)