Predictive maintenance
Predictive maintenance that tells you which asset to fix first
Explore reads the sensors and BMS points you already have, forecasts equipment behavior before it fails, and turns the result into one ranked queue — not another alarm stream.
Book a time directly- EU-hosted, GDPR-compliant
- Grounded inference — nothing invented
- No new hardware required
Why most predictive-maintenance projects stall
The model was never the hard part. Getting someone to act on its output is.
Most predictive-maintenance pilots don't fail because the anomaly detection is wrong. They fail because the output is another alert stream, and the team already ignores three of those. A vibration spike, a temperature drift, a runtime anomaly — each lands in its own dashboard, competing for attention with everything else that's already flashing red.
Explore starts from the actionability problem, not the detection problem. The same detection engine that powers BMS analytics runs six anomaly-detection methods against every point continuously, then forecasts where each one is heading with a confidence bound — so a developing bearing fault or a refrigerant leak shows up days or weeks before it trips a threshold, not after.
The output isn't a feed. It's a ranked decision queue: one list, ordered by cost and risk, that tells a technician what to look at first — instead of a wall of equally-urgent alarms nobody has time to triage.
This page is the product view. The methodology behind it — why most predictive-maintenance projects stall, and the failure modes that actually show up in sensor data — is in Predictive maintenance for buildings: a practical guide. How Explore stacks up against Clockworks, Facilio and CopperTree Analytics on this specific job is in the vendor comparison. For where predictive maintenance ends and condition-based maintenance begins, see the CBM guide.
What Explore actually does
Four capabilities, one ranked queue
Six-method anomaly detection
Every BMS point and connected sensor is checked continuously against six detection methods, not one fixed threshold. Covers drift, stuck values, runtime anomalies, and pattern breaks a static alarm limit misses. Full mechanics are on the anomaly detection glossary entry.
Forecasting with confidence bounds
Detection tells you something is already wrong. Forecasting tells you it's about to be. Explore projects equipment behavior forward with a confidence interval, so slow bearing wear or coil fouling surfaces while there's still time to schedule a fix instead of an emergency callout.
One ranked decision queue
Findings are ranked by cost and risk and merged into a single queue — not scattered across a BMS alarm panel, a spreadsheet, and three inboxes. A technician opens one list and knows what to look at first.
Read-only by default, action on request
Explore starts read-only by default. Findings can feed the Edge Agent to propose a maintenance action or schedule change — a person reviews it, or it executes automatically inside a scope you've explicitly granted. Nothing runs on your BMS without that scope.
How the three approaches compare
Raw alarms and a paper calendar vs. a ranked queue
| Raw BMS alarms | Manual PM schedule | Explore | |
|---|---|---|---|
| Trigger | Fixed threshold breach only | Fixed calendar interval, regardless of condition | Condition and forecast, six detection methods |
| Lead time | After the limit is already crossed | Arbitrary — unrelated to actual wear | Days to weeks ahead, with a confidence bound |
| Coverage | Only points with a hardcoded limit set | Only equipment on the PM calendar | Every point already in your historian |
| Prioritisation | None — every alarm is equally urgent | None — fixed schedule regardless of risk | Ranked by cost and risk, one queue |
| False positives | High — floods the operator | N/A, but wastes visits on healthy equipment | Filtered by confidence before it reaches the queue |
| New hardware | Usually none, but limited to already-sensored points | None | None — reads existing BACnet, Modbus, OPC UA, oBIX points |
| Path to action | Manual triage by an operator | Technician dispatched whether needed or not | Read-only by default; Edge Agent can propose or execute inside a granted scope |
At a glance
The mechanics
Predictive maintenance in Explore isn't a separate module bolted onto a BMS dashboard — it's the same sensor-intelligence layer used for energy and BMS analytics, applied to equipment health.
How it works
From sensor data to a ranked fix list
01 — In
Sensor and BMS data
Explore reads points you already have over BACnet, Modbus, OPC UA, and oBIX. No new sensors, no new gateway hardware.
02 — Analyse
Detection + forecasting
Six anomaly-detection methods run continuously; forecasting projects each point forward with a confidence bound, catching developing faults before they trip a threshold.
03 — Out
Ranked decision queue
Findings merge into one queue, ranked by cost and risk. Read-only by default — or feed the Edge Agent to propose and execute fixes inside a scope you've granted.
Questions
Predictive maintenance, answered
Predictive maintenance uses sensor and BMS data to forecast when equipment is likely to fail, so a fix can be scheduled before a breakdown, instead of waiting for a fixed calendar date or an alarm that already means something broke.
BMS alarms fire after a fixed threshold is crossed — a temperature limit, a runtime cap. Explore forecasts where a point is heading with a confidence bound, so a developing fault can surface days or weeks before it would ever trip that threshold, and every finding lands in one ranked queue instead of a raw alarm panel.
A calendar-based PM schedule services equipment on a fixed interval regardless of actual condition — sometimes too early, sometimes too late. Explore ranks findings by real condition and forecasted risk, so maintenance effort goes where it's actually needed first.
Condition-based maintenance triggers a maintenance action when a measured condition crosses a defined limit. Predictive maintenance goes a step further and forecasts when that limit will be crossed, with a confidence bound, before it happens. Explore does both: continuous condition monitoring plus forward-looking forecasts, merged into one ranked queue.
Usually not. Explore reads the points your BMS and existing sensors already expose over BACnet, Modbus, OPC UA, and oBIX. New hardware is only needed where a piece of equipment genuinely isn't instrumented yet.
Explore starts read-only by default — it detects and forecasts, nothing more, until you say otherwise. Findings can feed the Edge Agent to propose a maintenance action or schedule change, which a person reviews, or which executes automatically inside a scope you've explicitly granted. It can't act outside that scope.
See what Explore finds in your own data
Connect your BMS, point Explore at it, and get a ranked list of what actually needs attention — not another dashboard to check.