Remote Asset Health and Failure Prediction

Remote asset health prediction watches telemetry from machines already at customer sites and raises a service event while there is still time to plan a visit. The first notice of trouble should be a model-backed alert, not a customer call that the asset has stopped.

This is a service-quality problem on the installed base. You do not control the customer's production calendar, site access, or spare-parts stocking. You do control warranty exposure, technician capacity, and whether the customer hears about a failing asset from you or from a breakdown.

Factory predictive maintenance optimizes equipment you operate. Remote asset health prediction covers products you shipped, connected, and still service. The failure still happens in someone else's operation. The work order, entitlement, and customer conversation sit with the remote-service organization, not with a plant reliability team.

Quality is judged as avoided unplanned downtime at the customer and as honesty of the health signal, not as an internal OEE lift. The service lead cares whether the alert arrived early enough to schedule, whether the predicted failure mode matched what was found, and whether silent assets were treated as unknown rather than healthy.

When the machine is yours, use Predictive Maintenance on Production Assets. This page is for connected products already in the field, under warranty or a service contract.

The input is a time series from the product: temperatures, vibration or current signatures, cycle counts, pressures, error codes, duty cycle, firmware version, and contextual tags the gateway can attach, such as location, application, or ambient conditions. The useful features are the ones that move before the failure mode you sell against, not every channel the sensor can emit.

Models in this setting are usually a mix of anomaly detection on healthy baselines and remaining-useful-life or failure-mode classifiers trained on past claims, work orders, and tear-down findings. The output service can use is narrow: a predicted failure mode, a risk or confidence score, a time window, and the serial or asset identifier. A dashboard of unlabeled health is not an actionable alert.

Industrial IoT platforms commonly used to ingest this data and run the analytics include PTC ThingWorx, Siemens MindSphere, and AWS IoT. They store telemetry, host the model or stream it to a scoring service, and emit events. They are not the service system of record. The work order, parts reservation, entitlement check, and technician assignment still live in the field-service or ERP stack. Treat the IoT platform as the sensor-to-signal layer. Treat the service planner as the layer that decides whether a human goes on site.

Scoring should run on a defined cadence per asset class. High-duty rotating equipment may justify frequent scoring. Low-duty or battery-constrained devices may only report in bursts. The service design has to match that reality. An alert that arrives after the failure is a quality miss even if the model was correct in hindsight.

When telemetry is missing, stale, or gated, the correct model output is an empty prediction. It is not a green health score. Missing data is not evidence that the asset is healthy. Publishing an all-clear because the last packet is days old is a quality defect, because planners and customers will treat silence as permission to wait.

Define stale explicitly per product family. A compressor that reports every five minutes is stale after a short gap. A battery-powered logger that reports daily is stale on a different clock. Encode those thresholds next to the model, not as a tribal rule on the planning desk. When the stream is offline, you may raise a connectivity or data-quality flag if you need a follow-up queue. Do not invent a failure probability to fill the gap.

The planner still opens the work. Calendar-based inspections, contract visits, safety-related jobs, customer-requested calls, and campaign retrofits do not wait for a score. Remote prediction is an overlay that inserts extra work when the evidence is good. It does not replace planned maintenance and entitlement. If the model is dark, those paths continue.

This rule also protects later training. Scoring on interpolated or last-known-good values teaches the organization to trust numbers that were never observed. It also pollutes the dataset if those imputed healthy windows get labeled as true negatives.

A usable alert is one a planner can convert without a research project. The minimum payload is asset identity, site, predicted failure mode, recommended window, confidence, and an evidence snapshot of which signals moved. Entitlement and contract cover should be resolved in the same handoff so the planner is not guessing whether the visit is billable.

Human review still sits between the event and the truck. False positives consume technician time and erode customer trust if you arrive to replace a part that is fine. Route high-confidence, high-impact modes to an automatic work-order draft. Route ambiguous scores to a reliability or service-engineering queue. The automation boundary is a policy choice per product line, not a global switch.

Once the work order exists, dispatch is a separate problem: skills, parts, geography, and customer access. AI-Assisted Field Technician Dispatch covers that step. Do not collapse prediction and dispatch into one score. A correct failure call with the wrong technician or a missing part still shows up as a quality miss at the customer.

Parts pre-positioning is often the difference between a proactive visit and a two-trip repair. If the predicted mode maps to a known kit, reserve or ship that kit when the work order is created, not when the technician is already on site. Where the same serial or family keeps predicting the same mode, feed that pattern to commercial and product teams. Chronic remote failures are an input to Installed Base Churn and Upgrade Prediction, because customers who live through repeat breakdowns rarely wait for the next generation.

Customer communication belongs in this flow. A proactive visit needs a reason the site will accept: the specific risk, the window, and what happens if they delay. Vague notices that the machine looks unhealthy train customers to ignore you.

Quality here is the customer's uptime and the honesty of the signal, not the volume of alerts. Watch lead time from first alert to confirmed failure or to successful intervention, broken out by failure mode. Watch precision: of the visits opened from the model, how often was the predicted mode confirmed on site or at tear-down. Watch recall only where you have a closed loop on actual failures, including those that never generated an alert.

Watch the offline rate. The share of the connected base with stale or missing telemetry is a service-quality metric, because those assets cannot be protected by this use case. A strong model on a minority of the fleet is not a remote-health program.

Watch the mix of proactive versus customer-reported work on the covered population. The point of the system is to move failures earlier, into planned visits. If reactive break-fix volume does not move, the alerts are not reaching planners, not trusted, or not early enough to schedule.

Governance sits with the remote-service or connected-product lead: who may change thresholds, how often models are retrained against confirmed tear-downs, who owns false-positive cost, and when a product family is allowed to auto-create work. Review those rules when firmware, duty cycle, or the installed mix changes. A model frozen at launch will drift as the field population ages.

Remote asset health prediction is successful when the customer gets a scheduled repair instead of a surprise stop, when silent assets are treated as unknown rather than healthy, and when the planner can still run the book of work if the telemetry pipe is down.