RS-1 Dashboard
Turns a surprise breakdown into scheduled work.
The problem
Equipment failure is not the expensive part. Being surprised by it is.
Mechanical equipment fails constantly, and no amount of maintenance stops that. What makes a failure costly is having no warning it was coming: the work becomes an emergency, it happens on the equipment's schedule rather than yours, and by the time anyone looks, a small problem has usually turned into a large one. The failure was never really avoidable. The surprise was.
What it makes possible
- 01
Time to fix it before it becomes major
Degradation is caught while the equipment is still running, so the repair happens as planned work at its current size rather than as an emergency after it has grown.
- 02
The cause and a fix, not just an alarm
Each warning names the channel driving it and carries a recommended remedy, so the work can be scoped and the right parts brought on the first trip.
- 03
A grade on how much to trust it
Every prediction is scored on how far the evidence behind it can be trusted, including whether past warnings on that same machine were borne out. The verdict is advice, not a number: plan on it, confirm on site first, or do not act on this alone.
- 04
It tells you when to stop trusting it
A frozen sensor, channels contradicting each other, or a poor track record on that machine will say so and recommend a qualified eye in person. Data problems override a high score outright, because a confident number built on a dead sensor is worse than an uncertain one.
- ~22 hTypical warning, simulated
- 43 hLongest warning recorded
- 13Assets monitored
- high 90sConfidence, up from ~75
In use
Notes
Where it stands
The dashboard is deployed and has been running continuously for a couple of months against a simulated plant, where it has called failures between 18 and 43 hours ahead, typically around 22. It has no live customers yet, but the path for one is built. A small bridge program runs on any always-on machine on the plant’s own network, polls the equipment over Modbus or BACnet, and forwards readings out over HTTPS, so a site needs no inbound connection to be monitored.
How it works
Each machine reports vibration, temperature and current draw. Rather than judging those against a generic limit, the dashboard learns what normal looks like for that specific machine and sets its failure thresholds relative to that, so a pump that has always run warm is not flagged for running warm. An engineer can set exact limits instead. From there it watches how far each machine has drifted from its own normal and how fast, and projects when it will reach the point of failure.
It is careful about what counts as a trend. A building breathes with the work day and the work week, and the predictor knows the difference between that rhythm and a machine wearing out. A repair resets its view, so a machine is judged on its life since the fix rather than its decline before it. And it can tell a slow drift from the accelerating wear that real bearing and insulation failures usually show. The window around each prediction comes from how well the trend actually fits, not from a fixed margin.
The predictor is deliberately walled off from the simulator. It never sees the failure the test data has scripted, only the same numbers a real sensor feed would deliver, so a result on simulated data means what it would mean on a plant. The simulator itself is built on real bearing behavior for each machine type, so a simulated failure looks the way a real one would.
The part worth pointing at
Most predictive tools hand back a date and let you work out whether to believe it. This one grades its own certainty and says what to do about it. When the evidence is thin, or a sensor looks frozen, or its own past calls on that machine were wrong, it says so and recommends having a professional confirm before anyone commits downtime or parts.
A prediction that admits its limits is worth more than one that never does, because the crew keeps listening to it.
It improves as the models do
Every time a new model is released I put the codebase back through it and have it audit what is there.
The clearest change is in the alerts. A few months ago one gave you a verdict and little else. Opening one now tells you what to go and check, and lays out the reasoning behind its own confidence instead of only printing the number. A score you can argue with is worth more than a score you have to accept.
The confidence itself moved too. Early on a typical asset scored around 75. Across the fleet now a lot of them read in the high 90s, and the warning window has stretched over the same period. A number climbing on its own would only mean the scorer got easier to please. What is worth reporting is that it climbed while the lead time grew and the reasoning went on show.
Making sure only one answer exists
The dashboard, the alert, the email and the push notification all run the same predictor and the same confidence scorer, so the drawer can never read “stable” while an alert claims the machine is about to fail.