Predictive maintenance
Turning telemetry into a decision about a physical asset is the oldest industrial-analytics problem, and the thing that usually fails is not the model. It is that the output is a score nobody can act on or argue with.
The platform's prognostics produce health, a remaining-useful-life bound, and a governed advisory that shows its reasoning, on the same substrate as everything else, so the answer carries its provenance and its classification.
Two ways in
| Path | For | What it needs |
|---|---|---|
| Registered devices | A fleet you already run | Devices enrolled in the platform, with telemetry arriving |
| A raw dataset | An asset you have data for but have not enrolled | Telemetry records with a column map and any asset identifier. No device enrollment |
The second path matters more than it looks. It means you can point prognostics at a historian export, an object-store dataset, or a catalog table and get the same health, remaining-useful-life and governed advisory a registered device gets, which is how a customer evaluates the capability before committing a fleet to it.
That dataset path is read-only analysis and persists nothing, so it is safe to run against production history.
What it computes
Prognostics follow the OSA-CBM model, the open standard for condition-based maintenance, rather than an ad-hoc pipeline.
| Stage | What happens |
|---|---|
| Condition indicators | Featurization from raw signals: spectral features, motor-current signature analysis, and bearing-defect indicators |
| State detection | Where the asset is in its condition states |
| Remaining useful life | Produced as bounds rather than a single number, because a point estimate of a failure date is a claim the data does not support |
| Backtesting | The estimator checked against history rather than trusted |
| Fleet health | The roll-up across assets |
| A governed advisory | The recommendation, with its rationale shown and an asset-criticality weighting |
The bounds and the rationale are the product. An operator who is asked to take a machine out of service needs to be able to argue with the recommendation, and a bare score cannot be argued with. A bounded estimate with its reasoning exposed can be accepted, overridden, or escalated, and each of those is a decision someone can defend afterward.
How it runs across a fleet
The scheduled path scans active devices once per node and produces a prognosis per device. Two operational properties are worth knowing, because they are the difference between a feature and something you can leave running.
It is off by default. The worker runs only where the asset-prognosis capability is enabled, and the capability is derived by the fleet's worker policy rather than checked by the worker at tick time. So "which cells run prognostics" is a governed declaration, not a per-worker decision.
It fires once per node, not once per cell. The tick is gated by a node-converged lease, so a single-cell node always wins it and an N-cell node fires exactly once. Without that, every cell in a node would independently scan the same fleet.
On a lease error the lock degrades to firing, matching the platform's other converged schedules: a scheduling failure should produce a duplicate scan rather than silent non-execution, because a missed prognosis is the worse outcome.
Prognostics at the edge
The same condition-indicator feature set is computed on the device. An asset can therefore be scored where it lives, which matters when the asset is on a link that is intermittent, contested, or absent.
That is the shape the industrial case actually needs: the telemetry that matters is highest-rate closest to the machine, and shipping all of it to a core to decide whether a bearing is failing is the arrangement that breaks first when the site loses connectivity.
Where the data comes from
- Sensor intake, with clock synchronisation across sensors and a cognition policy governing what may be inferred from a given sensor.
- Time series, the tiered store telemetry lands in.
- Plant and field protocols, reached directly: OPC-UA, MTConnect, Modbus, DNP3, IEC 61850, BACnet, PROFINET, EtherCAT, CAN bus, plus historian and controller integrations. See industrial and sensor support.
Why it is different
The pitch is not that the platform does prognostics. Several vendors do.
It is that the prognosis inherits the substrate. The telemetry it reads is already catalogued, classified and lineage-tracked. The advisory it produces is recorded on the same tamper-evident ledger as everything else. The device that captured the signal has a cryptographic identity, so the reading is attributable. And the same features compute on the device when the link is gone.
An advisory you can trace back to a signed reading from an identified device, and argue with because its reasoning is exposed, is a different artifact from a number on a dashboard.
Related
- Sensor intake, how observations arrive and what may be inferred from them.
- Industrial and sensor support, the protocol reach and the sensing modalities.
- Time series, the store underneath.
- Worker policy, how a fleet decides where this runs.
- Core and edge, the on-device feature computation.