Predictive Maintenance Software
Predictive maintenance software for faults your team can detect and act on.
A model is useful only when a measurable condition changes before failure and maintenance can respond in time. RaftLabs develops predictive maintenance software around one equipment class and failure mode, joining condition data with work history, validating warning performance, and sending evidence into the CMMS for technician review.
Bring the problem, the current workflow, or the existing code. We reply with a practical next step within one business day.
The brief
Start with what is not working.
Good software decisions begin with the constraint, not a list of features or a preferred technology.
Are critical assets still failing between scheduled services while healthy parts are replaced early?
Do condition alerts reach a dashboard without enough evidence or lead time for a technician to act?
Plain answer
Predictive maintenance software uses condition and work history to spot equipment faults before failure. RaftLabs develops one warning model, validates warning time and false alarms, and sends evidence to the CMMS for review. A focused first release starts at $30,000 and takes 12 to 18 weeks.
The alert arrived three minutes before the machine stopped.
The monitoring system was technically right. The temperature crossed its threshold, the alarm fired, and the fault appeared on a dashboard. Maintenance still had no time to inspect the asset or move production.
Predictive maintenance has to change the work plan before the failure. That means finding a reliable precursor, proving the useful warning window, and putting enough evidence into the technician's existing queue.
First scope
- kept inside the first model boundary
- 1 asset class
- Comparable equipment and operating states
- linked to a specific inspection response
- 1 failure mode
- An anomaly alone is not a diagnosis
- starting development price
- $30K
- Fixed after the signal and workflow audit
RaftLabs does not currently publish a named predictive-maintenance outcome case study. The first engagement therefore tests whether the available condition data supports a useful warning against the buyer's own maintenance history before broader development is recommended.
Prediction is worth developing only when warning time changes the maintenance plan.
Calendar maintenance or simple thresholds are better when they already control the risk at lower cost.
The asset is critical enough that avoidable downtime or early replacement carries material cost.
Condition and maintenance records can be aligned by stable asset identity and time.
A technician can inspect within the warning window and record what was found.
The asset is cheap, redundant, or easier to replace after failure.
The relevant condition is not measured and cannot be instrumented safely.
Maintenance outcomes are not recorded against stable assets or components.
Scope
What the first predictive-maintenance release needs
- 01
Asset and failure-mode boundary
One equipment class and one costly failure mode define the first test. The team agrees what counts as a useful warning, which inspection follows it, and who may change the alert policy. - 02
Condition and maintenance data model
Sensor streams are joined with operating state, component history, service records, inspections, and failures. Stable identifiers and time alignment prevent a healthy replacement component from inheriting the failed part's history. - 03
Warning model and evidence
A threshold, anomaly detector, classifier, or remaining-life model is selected from the data and response need. Each alert carries the condition change and context a technician needs to judge it. - 04
CMMS workflow and feedback
Qualified warnings enter the existing work process with the asset, urgency, evidence, and recommended inspection. Technician findings close the loop and show whether alerts remain useful as equipment and operating conditions change.
Mixed OEM fleets: mining equipment monitoring
Mining fleets are mixed by nature: one portal shows an engine condition, another system holds the asset identifier, and the CMMS records a repair against a different code. The shift report combines them by hand. Fleet visibility begins with identity and accountable maintenance, not a larger dashboard.
Start with an asset and telemetry contract: reconcile equipment, component, sensor, location, and CMMS identifiers, and map vendor units, codes, sampling cadence, timestamps, quality flags, operating modes, and access limits into a common model. Preserve raw evidence where needed; the common model gives users a stable operational view. Condition and alert decisions start with approved thresholds, trends, or combinations for one condition, each carrying evidence, confidence, severity, recommended next step, and suppression state. Communication loss and bad sensors are separated from equipment conditions so noisy data does not become a maintenance instruction. The alert-to-action loop closes in the CMMS: qualified warnings propose or create work with explicit mapping, duplicate prevention, acknowledgement, escalation, retry, and failure handling. Technician findings return to the monitoring record so rules and models can be judged against what actually happened. Fleet operations and stewardship show current condition, stale feeds, open alerts, acknowledged work, and exceptions by site or equipment class, with rule configuration, audit history, data-quality queues, and runbooks that do not hide vendor limitations.
Duty context changes everything. Two haul trucks with the same engine hours degrade very differently; a model that ignores payload, road, and ore learns hard work as failure. Equipment family drives the signal design: haul trucks need CAN and telematics, temperatures, pressures, payload, speed, grade, fault codes, and oil analysis; shovels need hydraulic pressure, temperature, vibration, and duty cycles. If the organisation cannot distinguish a failed component from a planned exchange, improve component-event history before promising a remaining-life model. Mines also operate far from reliable connectivity, so edge processing preserves inference locally, and offline behaviour, model updates, and time sync need explicit design. New pits, roads, haul distances, and ore blends change duty, so monitor feature distributions and retrain. Judge ROI in production terms: tonnes moved, plant throughput, equipment availability, not model accuracy.
Do not replace an OEM portal merely to reproduce its dashboard. Integrate the fleet when a maintenance decision crosses vendor boundaries and approved feeds with representative history are available for a bounded pilot.
Should you use preventive or predictive maintenance?
Preventive vs predictive maintenance
| Preventive maintenance | Predictive maintenance | |
|---|---|---|
| Trigger | Calendar time, usage, or manufacturer interval | A measured change associated with a developing fault |
| Best fit | Known wear intervals and inexpensive scheduled work | Critical assets where condition gives useful warning |
| Data | Asset register and service schedule | Condition, operating state, maintenance, and failure history |
| Main risk | Healthy parts replaced early or faults missed between visits | False alarms or warning too late for maintenance to respond |
| Decision | Service when the interval arrives | Inspect when evidence crosses the approved warning rule |
Many fleets need both. Prediction belongs only on asset and failure combinations where the extra signal changes cost, risk, or uptime.
How it works
From asset selection to monitored work orders
Prove one warning and response path before covering more equipment.
- Phase 101
Choose the asset and response
Define the equipment class, failure mode, consequence, warning window, inspection step, and maintenance owner.
- Phase 202
Align condition and work history
Join sensor, operating-state, maintenance, component, inspection, and failure records by asset and time. Inspect missing periods and changed sensors.
- Phase 303
Validate warning performance
Backtest alerts by lead time, missed faults, false alarms, operating regime, and the team's capacity to inspect them.
- Phase 404
Connect the CMMS and learn
Deliver evidence into work orders, record technician findings, monitor drift, and expand only when the first warning remains useful in operation.
What proof should a pilot produce?
A credible pilot should show which historical events would have triggered an alert and how much warning they provided. It should also show missed faults, false alarms entering the maintenance queue, and whether a technician could have changed the outcome. The result should expose assets or operating regimes where the data is insufficient.
That evidence is more useful than a generic claim about reducing downtime. RaftLabs does not publish a predictive-maintenance percentage because performance depends on the equipment, failure mode, sensors, maintenance records, and response window.
- An anomaly is called a fault
- A change from normal may reflect load, environment, maintenance, or a replaced sensor. Technician review and operating context decide whether it matters.
- Different assets share one baseline
- Equipment age, configuration, load, and sensor placement can change the healthy range. Compare like with like before training one fleet-wide model.
- The warning has no response owner
- A prediction that sits on a separate dashboard changes nothing. Route it into the CMMS with an inspection step and accountable person.
- Retraining erases the policy
- A new model can move alert behaviour. Compare it with the current version and require approval before promotion.
Scope and price
A focused predictive-maintenance release starts at $30,000.
Begin with one equipment class, one actionable failure mode, historical validation, and one CMMS path.
We test whether the signal supports useful warning before committing to more asset classes or automatic work orders.
Starting investment
Starts at $30,000
A focused first release usually takes 12 to 18 weeks. Instrumentation, safety controls, and sparse history move the estimate most.
Signal audit first
We inspect representative condition and maintenance history before fixing the production scope. If the precursor or response window is not credible, we say so.
Fixed-price phase
Once the asset, failure mode, acceptance measures, CMMS boundary, and handover are agreed, the phase price is locked in writing.
Related services
Where to go next
- 01
Manufacturing predictive analytics
Use forecasting and machine learning across production, quality, maintenance, and operational planning. This broader service fits teams comparing several factory decisions.
- 02
IoT development
Connect devices, sensor streams, edge software, and cloud services before prediction becomes the next layer.
- 03
Demand forecasting
Predict product or material demand for inventory, purchasing, and capacity planning rather than equipment condition.
Work with us
Show us the asset that fails between service dates.
Bring its condition history, maintenance records, failure mode, and response window. We will test whether prediction is justified.
- Scope and cost agreed before work starts. No surprises. No obligation.
- Working prototype within 3 weeks of kickoff.
- Pay by milestone. You see progress before each invoice.
- 60-day post-launch warranty. Bug fixes, UI tweaks, and deployment support. No retainer.
- All conversations are NDA-protected.
Common questions
The useful data depends on the failure mode. A first audit links condition signals such as vibration, temperature, pressure, current, alarms, or operating state with stable asset IDs, component changes, maintenance work, inspections, and confirmed failures. Data volume alone does not prove the required precursor exists.
Sometimes. Anomaly detection can learn a healthy operating baseline without many failure labels, but an anomaly is not automatically a fault. A technician still needs to assess whether the change is useful. Failure classification or remaining-life estimates need stronger outcome history and enough comparable events.
The integration should send the asset, suspected failure mode, supporting condition evidence, urgency, and recommended inspection into the maintenance workflow. Duplicate suppression prevents repeated orders while one inspection remains open. Technician findings then become feedback for the warning policy and model.
Measure whether the warning arrives early enough to change the maintenance plan, how many real faults it identifies, how many false alarms consume technician time, and whether the team records inspection outcomes. Compare the result with the current preventive or reactive baseline.
A focused first release for one equipment class and failure mode starts around $30,000 and usually takes 12 to 18 weeks. New sensors, several operating regimes, sparse maintenance history, safety controls, multiple asset classes, and deeper CMMS workflows increase the scope.
Yes, when each vendor or site exposes an approved API, export, gateway, or other supported interface. We map equipment identifiers, units, sampling cadence, fault codes, operating states, timestamps, and data-quality flags into a common contract. Integration feasibility and licence limits are confirmed during discovery, not assumed from a brand name.
Two haul trucks with the same engine hours degrade very differently; models that ignore duty variables learn hard work as failure. Equipment family drives the signal design: haul trucks need CAN and telematics, temperatures, pressures, payload, speed, grade, fault codes, and oil analysis; shovels need hydraulic pressure, temperature, vibration, and duty cycles. If the organisation cannot distinguish a failed component from a planned exchange, start by improving component-event history before promising an exact remaining-life model.
With a canonical asset model and an explicit data-access plan; the platform must handle mixed OEMs without requiring identical parameter sets. Mines operate far from reliable connectivity, so edge processing preserves inference locally, and offline behaviour, model updates, and time sync need explicit design. New pits, roads, haul distances, and ore blends change duty, so monitor feature distributions and retrain.
They can create or propose work when the CMMS interface and operational controls allow it. The design defines equipment mapping, priority, job plan, evidence, duplicate prevention, acknowledgement, status updates, closure, cancellation, and retry behaviour. High-consequence actions should retain the client-approved human review and safety process.