PdM PlatformThe ToolboxServicesAcademyLibraryAboutContactOpen PdM →Open the Toolbox →
Predictive Maintenance · The Platform

Inside the Bluestream PdM platform

Bluestream PdM predicts when industrial equipment will fail and explains why — from the sensors you already own. Every number traces back to a standard: an ISO 14224 failure mode, a population base rate, a position on the P–F curve, and a NORSOK Z-008 criticality. So a reliability engineer and an auditor both accept the call.

OPC UAModbusMQTTISO 14224NORSOK Z-008P–F interval
Strategies
1Corrective (CM)After failure 2Preventive (PM)Before failure 3Predictive (PdM)Data-driven 4The PdM PlatformYou are here

One idea, three moves

Most predictive-maintenance tools force a trade-off: a proprietary sensor you are locked into, a black-box score no engineer trusts, or an offline reliability spreadsheet with no live data. Bluestream refuses the trade-off — ingest anything, reason against standards, act in your own CMMS.

Ingest
Bring your own sensors

Any existing sensor or PLC over OPC UA, Modbus, MQTT or I²C. No proprietary hardware, no rip-and-replace.

Reason
Ground it in standards

Anchored in industry reliability data and ISO 14224 failure modes — a credible answer from day one, not after months of training.

Act
Push a ranked work order

Every finding becomes a criticality-ranked, failure-mode-labelled job in your CMMS. The loop closes.

It opens on what needs you today

The dashboard does not greet you with a wall of gauges. It opens on a single ranked queue — what to act on first — sorted by severity, then criticality, then how much lead time is left. Healthy assets collapse out of the way.

The Bluestream PdM live dashboard: fleet health 60 percent, three healthy assets, one predicted and one in alarm, with a ranked Needs-action queue showing P-101 in alarm on winding temperature and F-101 predicted on vibration.
Live The real dashboard. P-101 is in alarm — winding temperature has already crossed 80 °C. F-101 is a prediction — vibration is trending, with about 23 hours of lead time left. That distinction is the whole product: one is a report from the past, the other is time to do something.
Why it matters

You start with the two assets that actually need you today. Alert fatigue is the number-one reason maintenance teams end up tuning predictive tools out — so the queue is short by design, and everything healthy stays folded away.

It shows its work

Open the predicted asset and there is no spectrum plot to interpret. There is a plain-language verdict, the signals that produced it, and the reasoning behind the number — assembled end to end, on one screen.

F-101 asset detail in the Bluestream PdM platform: a vibration verdict tagged VIB and ISO 14224, four live signal traces with their rule limits, a remaining-useful-life band of P10 15 hours to P90 2 days, a P-F curve marking the detection point P, and a population reliability prior.
F-101 — the same asset from the queue above. The verdict names the failure mode in a public standard (VIB · ISO 14224). The signals show exactly which rule fired: vib_rms at 6.4 mm/s against a 7.1 mm/s limit, plus the derived hours_to_limit that drives the countdown. The remaining-life panel gives an honest range, not a single date. And the prior names the population it comes from — an industry failure-rate dataset for this equipment class, λ ≈ 0.94/10⁶h.

Nothing there is a black box. A signal became a failure mode, the failure mode was checked against an industry base rate, the asset was placed on its P–F curve, and only then did a remaining-life number appear — carrying its own uncertainty.

Grounded in

ISO 14224 names the failure mode, industry reliability data supplies the population base rate and repair effort, the P–F interval frames the lead time, and NORSOK Z-008 sets the criticality that ranks it.

Reading the P10–P90 band. The remaining-life figure isn't a single date — it is the 10th, 50th and 90th percentiles of the predicted time-to-failure. P50 (~23 h) is the median, the most likely time to failure; P10 (~15 h) is the conservative end you plan the work by — only a 10 % chance it fails sooner; and P90 (~2 days) is the optimistic end, by which failure is nearly certain. The band narrows as live data accumulates. See Predictive Maintenance & RUL for how the band is built, and Weibull’s B10 life for the population version of the same idea.

One tap to a work order

"Create work order" opens a job that already knows why it exists — pre-filled with the asset, failure mode, criticality, remaining life and the population repair estimate — plus a checklist scoped to that specific failure mode. Print it for the technician, or push it to the CMMS.

Create work order · F-101
WO-F-101-VIB
Bearing degradation — air-cooler fan
Failure mode
VIB — Vibration · ISO 14224
Criticality
C2 · NORSOK Z-008 · schedule before the window closes
Evidence
RUL ~23h · ~93% through P–F · repair ~13h (industry data)
Guided procedure · VIB
☑ Confirm vib_rms trend and current level
☐ Check alignment and balance ⚠ isolate first
☐ Inspect bearing — noise, heat, play
☐ Verify mounting and looseness
☐ Replace bearing; post-check vibration in band

The same maintenance intelligence behind the Work Instruction Generator in our Toolbox builds that checklist — each step tied to the failure mode, with acceptance checks and hazard callouts. One vocabulary, both products.

Under the hood: what makes the answers trustworthy

Nothing on screen is a black box, and that is a design constraint rather than a claim. Six choices carry it:

Hardware-agnostic ingest

A small edge service normalises OPC UA, Modbus, MQTT and I²C into one contract, so any sensor — new or already installed — feeds the same pipeline.

No cold start

A population failure-rate prior gives a credible remaining-life estimate on day one, then sharpens with live trend as evidence accumulates.

A pump is not its motor

A close-coupled pump body and its motor driver draw on separate reliability records — the granularity ISO 14224 defines and most tools flatten away.

The “why” is generated, not written

Each prediction cites a failure mode, a base rate and a P–F position — an audit-grade rationale, not a post-hoc gloss on a score.

CMMS write-back closes the loop

Findings become work orders in Microsoft Dynamics 365 or your own CMMS, ranked by NORSOK criticality and hours-to-limit.

It teaches as it works

Every alert links to a plain-English explainer of the standard behind it — you are reading one now.

The through-line: every number on the screen can be traced to a reliability standard. That is what lets Bluestream be explainable and hardware-agnostic at once — the combination the rest of the market leaves open.

What it monitors — and where it fits

Industry reliability data and ISO 14224 are richest on rotating machinery, so that is where a standards-grounded prior is strongest and where the platform starts.

Centrifugal pumps 1.1
Electric motors 1.2
Fans & blowers 1.3
Compressors 1.4
Gearboxes 1.5
Cooling towers 2.1
HVAC & air handling 2.2
Heat exchangers 2.3

Typical failure modes: bearing degradation, imbalance, misalignment, looseness, winding and insulation deterioration, cavitation, fouling, seal wear.

A good fit if…

  • You have rotating equipment with existing instrumentation — or somewhere sensible to add one sensor.
  • Failures are gradual and have a detectable P–F interval (bearings, imbalance, fouling, wear).
  • You already run a CMMS and want work orders to land there, not in another portal.
  • You care why a prediction was made, because someone will have to justify the shutdown.
  • You want to keep your sensor and CMMS choices open rather than being locked to one vendor.

Not a fit — yet

  • Sudden, random failures. If there is no detectable degradation before failure, no predictive method helps — including this one.
  • No data at all. The platform needs a signal. If an asset is entirely uninstrumented and unreachable, start elsewhere.
  • Instant precision on day one. A prior gets you started; calibration sharpens as your own data accumulates.
  • A replacement for your CMMS. It feeds yours; it is not trying to be it.
  • A hardware sales pitch. The starting assumption is always that we use what you already have. We can supply and install sensors where an asset genuinely needs them — but that is a service, not the business model, and never a condition of using the platform.
Why say this out loud

Reliability engineers have been oversold to for twenty years. Naming the boundary is faster than discovering it three months into a pilot — and it is the quickest way to tell whether this is worth your meeting.

Where this is going

What runs today is the first horizon of a longer arc. Each stage deepens the same contextualised, standards-grounded data layer — which is precisely what an augmented-reality field layer needs underneath it before any overlay can be trusted.

Augmented-reality field view in an onshore chemical plant: a semi-transparent process vessel showing its internal oil/water interface, with pressure, temperature, remaining useful life and a bearing-wear warning rendered in place on the equipment.
The north star — live equipment health rendered in place: see inside the vessel, see the why, hands-free.
H1 · Predict
The PdM platform

Explainable RUL and the right work order out.

You are here
H2 · Contextualise
Asset knowledge graph

Every reading tied to item, standard, position and history.

H3 · Spatialise
Spatial digital twin

The graph bound to 3D geometry and plant layout.

H4 · In place
The AR field layer

The twin overlaid on the real asset, hands-free.

H5 · Ambient
Complete solution

AR as the default interface for field O&M.

Practical questions

Do I have to buy your sensors?
No. The platform is designed around the instrumentation you already have, read over OPC UA, Modbus, MQTT or I²C, or from your historian — and it is never tied to a particular vendor's kit. Where an asset genuinely has no useful signal, a single added sensor is usually enough. We can supply and install that hardware if you want us to, or you can buy it from whoever you like; the platform does not care either way.
How long before predictions are any good?
You start with an industry reliability prior for that equipment class, so there is a defensible baseline from day one rather than a cold start. The prior is then updated with live data — accuracy sharpens as weeks of your own operating history accumulate. Anyone promising calibrated predictions on day one with no prior and no history is describing something that does not exist.
Will it flood my team with alerts?
Alert fatigue is the main reason condition-monitoring programmes get switched off, so the platform separates the two things most tools blur: an alarm (a threshold already crossed — it happened) and a prediction (remaining life with lead time — it will happen). They render differently, and the queue is ranked by severity, criticality and lead time so healthy assets stay collapsed.
Which CMMS does it write work orders into?
Microsoft Dynamics 365 is the first connector, with SAP PM and IBM Maximo next. The output is a failure-mode-tagged work order, so it arrives in your ISO 14224 taxonomy rather than as free text. The connector layer is deliberately generic — if you run something else, ask.
What happens to our data?
Your operational data remains yours. It is used to run your predictions, and in de-identified, aggregated form to improve the underlying models. If you need a specific data-handling arrangement, raise it early and it goes in writing.
The platform is early. Why would I risk a pilot?
A fair question. The reason the predictions are trustworthy is not the algorithm — it is 25+ years of hands-on O&M leadership behind the failure-mode logic, and standards (ISO 14224, NORSOK Z-008) you can audit rather than a proprietary score. Pilot sites get the platform at no license cost during validation. If it does not work on your equipment, you will find out quickly — and that is the point of a pilot.

Across the Academy