Remaining Useful Life (RUL) Prediction Explained

Remaining useful life prediction estimates how long a component or machine can keep operating before it reaches a failure condition. Instead of asking "is something wrong?", it asks "how much time do we have?", which is the question maintenance planners actually need answered. This article explains the main RUL model families, the data history each one requires from MQTT-connected assets, and how to compute and publish an estimate with honest uncertainty.

What Remaining Useful Life Means

Remaining useful life (RUL) is the time, cycles or operating hours left until an asset crosses a defined failure threshold. Three parts of that definition deserve attention:

• The unit. Calendar time is easy to communicate but misleading when usage varies. Operating hours, cycles, strokes or produced units often track wear better.
• The failure threshold. RUL needs a defined end point: a vibration level at which a bearing is replaced, a filter pressure drop at which flow becomes unacceptable, a capacity at which a battery is retired. Without one, there is nothing to predict.
• The uncertainty. A single number such as "212 hours" hides how confident the model is. A useful RUL estimate always comes with a range.

RUL prediction is one framing of predictive maintenance machine learning. It suits assets that degrade gradually and repeatably, such as bearings, filters, cutting tools, batteries, belts and seals. It suits sudden failures, such as electronic faults, poorly.

Model Families for Remaining Useful Life Prediction

Most practical projects begin with a degradation trend model because it needs only one unit's history and a threshold. Similarity and ML methods come later, once the organisation has recorded enough complete lifecycles.

The Data History RUL Models Need

RUL prediction is more demanding about history than anomaly detection. Plan for these data streams from the start, because they cannot be reconstructed later.

1. Condition signals over the whole life of each unit, not just the last weeks. Features such as vibration RMS, temperature rise or pressure drop, sampled consistently.
2. Usage counters such as operating hours, cycles or throughput, so RUL can be expressed in the unit that drives wear.
3. Operating context such as load, speed and ambient temperature, to separate degradation from changing conditions.
4. Lifecycle events: installation, replacement, repair and failure, each with a timestamp and the component serial number. These define where one life ends and the next begins.
5. Failure definitions: what condition counts as end of life, written down per component type.

Over MQTT this usually means a condition topic, a usage topic and an events topic per asset, all with source timestamps, stored by a historian subscriber. The labeling time series sensor data guide shows how to capture lifecycle events and operator input alongside telemetry so the run-to-failure records are complete.

Building a Health Index

Most RUL methods work on a single health indicator rather than many raw signals. A health index (HI) combines features into one number that changes monotonically as the asset degrades. Common ways to build it:

• Use one physically meaningful feature, such as bearing vibration RMS or filter differential pressure.
• Combine normalised features with weights chosen by engineers.
• Use the reconstruction error of a model trained on healthy data.
• Use the first principal component of the features over healthy-to-failed histories.

Good health indices share three properties: they are monotonic (they rarely move backwards), they are prognosable (failure happens at a consistent HI level), and they trend early enough to be useful.

A Degradation Trend Example in Python

The following script subscribes to a health index topic, fits an exponential degradation model to the recent history, extrapolates to a failure threshold, estimates an uncertainty band by bootstrap, and publishes the RUL back to MQTT. A built-in simulator publishes the health index so you can run it end to end against the free public MQTT broker.

import json
import math
import random
import threading
import time
import uuid

import numpy as np
import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1/fan2"
THRESHOLD = 4.0        # HI value defined as end of life (e.g. vibration RMS in mm/s)
MIN_POINTS = 30
history = []           # (operating_hours, hi)


def fit_rul(hours, hi):
    # Fit ln(hi - baseline) = a + b * t, then solve for the threshold crossing
    baseline = 0.9 * min(hi)
    y = np.log(np.maximum(np.array(hi) - baseline, 1e-6))
    b, a = np.polyfit(hours, y, 1)
    if b <= 0:
        return None
    t_fail = (math.log(THRESHOLD - baseline) - a) / b
    return t_fail - hours[-1]


def estimate():
    hours = np.array([h for h, _ in history[-120:]])
    hi = np.array([v for _, v in history[-120:]])
    point = fit_rul(hours, hi)
    if point is None:
        return None
    boots = []
    for _ in range(200):
        idx = np.sort(np.random.choice(len(hours), len(hours), replace=True))
        r = fit_rul(hours[idx], hi[idx])
        if r is not None:
            boots.append(r)
    low, high = np.percentile(boots, [10, 90])
    return {"rul_h": round(point, 1), "p10_h": round(low, 1), "p90_h": round(high, 1)}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/health", qos=1)


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    history.append((p["op_hours"], p["hi"]))
    if len(history) >= MIN_POINTS:
        est = estimate()
        if est:
            est.update({"ts": p["ts"], "threshold": THRESHOLD, "method": "exp-trend-v1"})
            client.publish(f"{BASE}/rul", json.dumps(est), qos=1, retain=True)
            print(est)


def simulate(pub):
    for step in range(400):
        hours = step * 5.0
        hi = 1.0 + 0.05 * math.exp(hours / 600) + random.gauss(0, 0.04)
        body = {"ts": int(time.time() * 1000), "op_hours": hours, "hi": round(hi, 3)}
        pub.publish(f"{BASE}/health", json.dumps(body), qos=0)
        time.sleep(0.5)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="rul-" + uuid.uuid4().hex[:8])
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
threading.Thread(target=simulate, args=(client,), daemon=True).start()
client.loop_forever()

Install with pip install paho-mqtt numpy. Early in the run the band between p10_h and p90_h is wide; as the health index bends upward, the estimate settles and the band narrows. That behaviour is normal and important to communicate: RUL estimates become trustworthy only once degradation is clearly visible.

Publishing RUL Estimates Others Can Use

Publish the estimate as a retained message on a dedicated topic per asset, such as .../fan2/rul, so dashboards and CMMS connectors get the latest value immediately when they subscribe. Include the method and version, the threshold used and the uncertainty range. In the ConnectMQ portal you can watch the topic in the live topic explorer and add a threshold alert rule, for example when p10_h falls below a planning window, so the lower bound rather than the point estimate drives the alert.

Common Mistakes in RUL Projects

• Predicting calendar days for usage-driven wear. Convert to operating hours or cycles first.
• Mixing lives. If a component replacement is not recorded, two lives merge into one confusing trajectory.
• Ignoring uncertainty. A planner who sees only a point estimate will either over-trust or ignore it.
• Training ML models on a handful of failures. Start with trend or similarity models and graduate to ML when history allows.
• Forgetting regime changes. Load changes can shift the health index without any degradation; normalise for operating context.

Where RUL Fits in Your Stack

RUL estimation sits on top of reliable condition data, which in turn depends on a stable messaging layer. ConnectMQ provides that layer as a managed MQTT broker, while the models run as your own clients. For forecasting techniques that complement trend extrapolation, see IoT time series forecasting, and for the overall picture of models working with connected devices, the AI and IoT guide.

Start Collecting Lifecycle Data on ConnectMQ

RUL models are only as good as the history behind them, so the best time to start recording is now. Create a free Serverless broker at app.connectmq.com, no credit card required, connect your assets with the generated username, password and client ID, and begin storing condition, usage and lifecycle events through a historian subscriber. When your fleet grows, a cloud MQTT broker plan gives you more connections and isolation without changing your topics.

Frequently Asked Questions

What is remaining useful life prediction?

It is the estimation of how much operating time, cycles or usage an asset has left before it reaches a defined failure condition, usually based on its condition data and the behaviour of similar assets.

How many failures do I need to predict RUL?

Degradation trend models can work with a single unit's history and an engineering threshold. Similarity-based and machine learning models need several to many complete run-to-failure histories for each component type.

Why does the RUL estimate change so much early on?

Before degradation becomes visible, the trend is dominated by noise and the extrapolation is unstable. Report an uncertainty range and rely on the estimate once the range narrows.

Should RUL be expressed in days or operating hours?

Use the unit that drives wear, typically operating hours, cycles or throughput, and convert to calendar dates only for planning using the expected utilisation.