Connected devices that interpret, not just report.

Where intelligence belongs in a connected product

Most connected products start by reporting: a device measures something and sends it somewhere. The value ceiling of that arrangement is reached quickly, because someone still has to look at the data and decide what it means.

Adding analysis moves that interpretation into the system. A vibration reading becomes “this bearing is behaving differently from last month”. A power trace becomes “this cycle used more energy than the same cycle normally does”. The engineering question is where that interpretation should happen, and whether your data can support it at all.

Edge or cloud

This is a design decision with real consequences, not a preference.

• At the edge, on the device itself, when the response has to be immediate, when connectivity is unreliable or expensive, when raw data volumes are too large to transmit, or when the data should not leave the site. The cost is constrained memory, compute and power.
• In the cloud, when models are large, when they benefit from data across many devices, when they change often, or when the device cannot spare the resources. The cost is dependence on connectivity and ongoing running cost per device.
• Split between the two, which is common in practice: lightweight screening on the device to decide what is worth transmitting, deeper analysis centrally.

Problems that suit this approach

• Anomaly detection. Learning what normal looks like for a specific installation and flagging departures from it. Often the most practical starting point, because it does not require examples of failures.
• Classification. Identifying which of several known states or events a signal represents.
• Forecasting. Estimating a future value or a remaining interval from historical patterns.
• Vision. Inspection, counting, presence detection and reading, where a camera is a practical sensor.
• Signal interpretation. Extracting meaning from vibration, acoustic, current or spectral data that a simple threshold cannot capture.

Your data decides what is possible

This is the part that determines whether a project succeeds, and it is worth being blunt about it.

A model learns from examples. If you have no recorded examples of the condition you want to detect, no model can be trained to detect it, regardless of the technique used. If your data was collected at a sampling rate that does not capture the phenomenon, the information simply is not there. If it was gathered from one machine in one season, a model built on it may not transfer to a different machine or a different month.

So the first step is usually an honest look at what you already hold: what was recorded, at what rate, over what period, under what conditions, and whether the interesting events are represented in it. Where the data does not yet exist, the sensible first project is to build the collection system properly and accumulate it, which is useful on its own and makes the later work possible.

Running models on constrained hardware

Deploying to a microcontroller is an engineering problem in its own right: model size against available flash and RAM, inference time against the sampling interval, arithmetic precision after quantisation, and the power cost of running inference on a battery-operated device. These constraints often reshape the model rather than the other way round, which is why hardware, firmware and model work belong in the same conversation from the start.

Keeping models working after deployment

A model is not finished when it is deployed. Conditions drift, equipment is replaced, processes change, and accuracy degrades quietly unless someone is watching. A workable system includes a way to measure performance in the field, a route to update models on deployed devices, versioning so you know which device is running what, and a rollback path when an update makes things worse.

When this is not the answer

Plenty of problems are better solved without machine learning, and we would rather say so early than bill for the alternative. If a fixed threshold detects the condition reliably, use the threshold: it is cheaper, explainable and easier to certify. If the underlying physics is well understood, a model derived from it usually beats one inferred from limited data. If you have no labelled data and no route to collecting any, the project is a data-collection project first, whatever it is called.

How a project usually runs

An assessment of the problem and the available data. A feasibility stage on recorded data, before any hardware commitment, to establish whether the signal supports the goal. Then device and system development, deployment to a limited pilot, and measurement of real-world performance against the agreed criteria.

Discuss an AI-enabled product

Tell us what you want the system to recognise or predict, and what data you already collect. If the equipment is already installed and running, see AI for industrial machinery.