Analytics and models on the data
We do not start here. Models built on telemetry with clock drift, missing calibration and silent gaps produce confident nonsense. Once the pipeline is trustworthy, this is where the return usually is.
The pitch for predictive maintenance is easy and the delivery is not. Failure data is rare by definition, labels are inconsistent because two technicians describe the same fault differently, and a model that cries wolf gets ignored within a fortnight.
What the work actually involves
What we actually do
- Data quality assessment first: gaps, drift, duplicates, timestamp integrity
- Baseline statistical detection before anything is called machine learning
- Anomaly detection on vibration, current draw and thermal signatures
- Remaining-useful-life estimates from duty cycles, with honest confidence intervals
- Small quantised models that run on the gateway when the uplink is down
- A feedback loop so technicians can mark a prediction wrong, and that lands in training data
How we keep it honest
- Precision and recall reported against the cost of a false alarm to your team
- Shadow mode first: the model runs and is scored before anyone is paged by it
- Drift monitoring, because a model trained on last summer's fleet ages
- A plain explanation attached to every alert, so the planner knows why it fired
What you get to keep
- Data quality report on your existing telemetry
- Baseline and model performance compared on the same held-out period
- Deployed inference, on the gateway or in the cloud as the case requires
- Retraining pipeline your team can run without us
It depends entirely on how many failures are in it and how well they are labelled. Three years with nine labelled failures is not a training set. We will tell you that in the assessment rather than after the model is built.
Not always. Where latency, bandwidth or connectivity make it impractical, a quantised model on the gateway runs the same detection locally and only reports conclusions.
What this normally sits next to
These capabilities come up in almost every engagement that includes the one above.
Node.js ingestion and services
An MQTT front door, a device registry, a rules engine and clean HTTP and WebSocket APIs. Written in TypeScript, sized to your message rate, and load tested with a simulated fleet before real hardware arrives.
Cloud, deployment and monitoring
Infrastructure as code, one-command environments, and dashboards that page a human before a customer notices. We hand you the keys and the runbook, or keep running it for you.
Talk to the engineers who do this work
The first call is with whoever would lead the build, not an account manager. Bring the constraint you think is going to be a problem.