Putting Intelligence at the Edge of an IoT Estate

The default architecture for a connected product is to send everything somewhere else. The device samples, transmits, and a server decides what it means.

It is the default because it is the easiest thing to build and because the intelligence is then somewhere you can update. But for a large proportion of deployed estates it is the wrong trade, and the reasons show up only after the fleet is in the field.

What the default costs

Bandwidth spent on non-events. A vibration sensor sampling at any useful rate produces an enormous amount of data describing a machine behaving exactly as expected. Transmitting all of it to establish that nothing happened is the bulk of the traffic on most estates.

Power, which is usually the binding constraint. On a battery device the radio dominates the energy budget — transmitting is far more expensive than computing. A device that sends every reading and one that sends only anomalies can differ by years of battery life, and battery life determines whether the product needs a maintenance visit.

Latency on the decisions that matter. If a reading means "stop the machine", a round trip to a data centre is the wrong path, and a round trip over a connection that might be down is not a path at all.

A dependency on connectivity that the site does not have. Industrial sites, basements, tunnels, remote estates: intermittent is the normal condition rather than the exception.

The division that works

Put classification at the edge and interpretation at the centre.

The device decides whether a reading is interesting. That is a small, bounded question — is this within the envelope, does this pattern match a known fault signature, has the distribution shifted — and it can be answered by a small model or, very often, by a well-chosen threshold and some arithmetic. Microcontroller-class hardware handles this comfortably.

The server decides what interesting means across the estate: correlating devices, spotting a fault developing across a site, comparing this machine to the other three hundred like it, and updating what counts as normal.

The result is that the device transmits events rather than measurements. Traffic drops by orders of magnitude, battery life extends accordingly, and — the part usually underestimated — the system keeps making its most time-critical decisions when the network is down, because those decisions never needed the network.

We have made this argument concretely elsewhere: the cheapest sensor on an industrial estate is usually one already installed, and the value comes from processing its output better rather than from deploying more of them.

The hard part is updating what the device believes

This is where edge intelligence gets genuinely difficult, and it is worth being honest about it before committing.

A server-side model is updated by deploying. An edge model is updated by reaching several thousand devices, some of which are behind an intermittent link, some of which are on a battery that cannot afford a large download, and all of which must keep working if the update fails halfway.

Requirements that are not optional: the update must be atomic, the device must roll back automatically if the new model fails to load, the model must be versioned separately from the firmware so you are not re-flashing everything to change a threshold, and the device must report which version it is actually running rather than which one you believe you sent. Fleets drift, and the only way to know what is deployed is to ask.

Keep a path back to the raw data

An estate that only ever transmits events loses the ability to answer questions nobody thought of when the thresholds were set.

The compromise that works is to keep a short rolling buffer of raw data on the device, and transmit a window around anything flagged. You get the context needed to investigate a real event, without the cost of continuous streaming. For the rare case where a full capture is needed — commissioning, or diagnosing a fault the classifier is getting wrong — make it something the server can request on demand for a single device.

Where the mobile app fits

Most connected products acquire an app, and the app is usually the weakest part of the system: it is the piece users judge the product by and the piece most likely to be built last.

It is also, in the field, the most useful diagnostic surface available. An engineer standing in front of a device with a phone that can talk to it directly — over local transport, with no dependency on the site's connectivity — is worth a great deal more than a dashboard that needs the network the engineer came to fix.