IoT & predictive maintenance
On this page
Connected equipment emits a constant stream of readings: temperature, vibration, pressure, cycle counts. Turning that stream into action is a rule-matching problem: which assets are showing the patterns that precede a failure, right now?
⚡ Where speed pays for itself
Telemetry arrives continuously and per-reading. Evaluating rules fast enough to run at the edge (inside a gateway or on-prem service, with no cloud round-trip per reading) cuts both bandwidth and central compute: decisions are made where the data is, on modest hardware, and only the alerts travel onward.
The stakes🔗
Catching problems early pays off heavily. Deloitte and McKinsey analyses find predictive maintenance can cut unplanned downtime by 30–50% and maintenance costs by 18–30% (Deloitte), against a backdrop where unplanned downtime is estimated to cost industrial manufacturers on the order of $50 billion a year. The rules that flag at-risk assets have to run against a high-volume sensor stream without falling behind.
How it works🔗
Each failure signature is a rule, evaluated against incoming readings. For example, "flag assets running above 85.5 °C with elevated vibration, in machine classes 2 or 5, that are more than 2,000 hours past service." Sensor readings are held as real decimal values, so a threshold is written exactly as an engineer would state it; counters and timestamps are number checks, and asset class and site are category checks. A rule can also compare one reading against another: a live reading against its rolling baseline, say.
🤖 With AI in the loop
Industrial AI pairs learned models with engineering rules. GE Vernova's SmartSignal uses digital-twin models to flag anomalies across 19,500+ monitored assets, then matches them against a library of failure-precursor rules and alarm limits to decide what becomes a work order. Rolls-Royce's engine health monitoring trends per-flight sensor data with neural networks while hard-limit rules fire in real time on the engine. The combination mitigated 75% of potential in-flight events in a study year. On inspection lines, Landing AI's vision models emit a confidence score per defect, and a threshold rule decides accept or reject; moving that threshold is an instant policy change, no retraining. In Winnow, model outputs (anomaly scores, confidences, forecasts) are columns; the alarm limits, persistence conditions, and work-order triggers around them are rules your engineers own. More patterns: Deep Dive: AI + Rules Engines.
Why Winnow fits🔗
- Sensor data is numeric and bursty: threshold checks sweep thousands of assets per pass, and "above its own baseline" rules compare one reading directly against another.
- Keeps up with the stream: microsecond evaluation, applied to whole batches of readings at once, scales to high-frequency telemetry without a per-reading round trip.
- Embeddable at the edge: a self-contained component with no server dependency runs inside a gateway or on-prem service, close to the equipment.
- Tunable signatures: maintenance engineers refine thresholds as they learn an asset's behavior, editing rules as text and applying them live.
🧪 In simulation — 200,000 condition rules, 750,000 sensor readings
To put numbers on the above, we loaded 200,000 condition rules covering 10,000 assets — per-asset thresholds, per-model operating bands, line-level time windows, duty-cycle rules, and a narrow vibration band with no asset key at all — and ran 750,000 telemetry readings against the book. Each reading carries real temperature, vibration and pressure values with their decimals intact, plus a precise timestamp — the honest shape of sensor data rather than a rounded-off version of it. The run touched 9,615 different assets and covered just under 21 hours of combined sensor time; a third of readings tripped at least one rule.
What this is: a test run on generated equipment and generated telemetry, not a customer deployment — the assets and readings are invented, the speeds and costs are measured. It ran on one ordinary 16-core desktop computer, priced at a standard cloud rate of $0.043 per processor-hour running around the clock, the same basis as the Deep Dive: Cost Savings. Every alert was double-checked against a slow, exhaustive pass over all 200,000 rules before any stopwatch started — that slow way takes about 34 times longer — so none of the speed comes from work quietly skipped. Treat the speeds as approximate, moving by about a fifth with machine load, and the counts as exact; the test ships with Winnow for your team to re-run on your own equipment and rules.