Predictive Maintenance with Machine Learning: Features, Labels and Models

Predictive maintenance machine learning uses condition data from machines to estimate whether a failure is coming, so maintenance can be planned before a breakdown instead of after it. In this guide you will learn how to collect the right signals over MQTT, turn them into features and labels, choose a first model, and validate it in a way that reflects how it will behave on the shop floor.

What Machine Learning Adds to Maintenance

Most plants already do some form of condition monitoring: a vibration alarm at a fixed level, a temperature limit on a bearing. Those static thresholds work for obvious faults but miss slow, multi-signal degradation, and they often trip late. Machine learning adds two things. It can combine several weak signals into one stronger indicator, and it can learn what "normal" looks like for each machine under different loads, instead of applying one limit to all.

It is worth being clear about the limits too. A model can only learn failure patterns that are present in its data. If a machine type has failed twice in five years, a supervised failure classifier will not learn much; an anomaly detection or degradation-trend approach is a better fit. Choosing the problem framing correctly matters more than choosing the algorithm.

Framing the Problem

Many teams start with anomaly detection because it needs no labels, then move to classification once they have collected enough labeled events. The IoT anomaly detection article covers that first step, and remaining useful life prediction covers the regression framing.

Collecting Condition Data over MQTT

The signals should follow the failure modes you care about. For rotating equipment, the usual set is vibration features, bearing or winding temperature, motor current and speed. For hydraulic and pneumatic systems, pressure, flow and cycle times. Always include operating context such as load, speed setpoint and product, because a model that does not know the load will mistake a heavy batch for a developing fault.

A practical MQTT layout publishes features per asset under a hierarchy, with source timestamps:

connectmq/plant1/line2/pump3/condition   {"ts":..., "vib_rms":..., "vib_peak":..., "bearing_temp":..., "current":..., "load":...}
connectmq/plant1/line2/pump3/events      {"ts":..., "type":"maintenance", "action":"bearing replaced"}

Compute vibration features at the edge rather than streaming kHz waveforms. A one-second window yields RMS, peak, crest factor and a few spectral band energies, which is small enough to publish every few seconds. The events topic is just as important as the telemetry; without recorded maintenance actions and failures, you cannot build labels. The labeling time series sensor data guide shows how to capture those events from operators.

Feature Engineering for Predictive Maintenance Machine Learning

Raw readings are rarely the best model inputs. Degradation shows up as changes in level, variability and trend over time, so features are typically computed over rolling windows.

• Level features: rolling mean of RMS vibration, temperature, current.
• Variability features: rolling standard deviation, peak-to-peak, crest factor.
• Trend features: slope of a linear fit over the last hours or days.
• Relative features: temperature rise over ambient, current per unit load, vibration compared with the same machine's baseline.
• Spectral features: energy in bands linked to bearing defect frequencies or imbalance.
• Operating context: load, speed, running hours since last maintenance.

Normalize per asset where machines differ. A pump that has always vibrated slightly more than its neighbours is not necessarily degrading; the change relative to its own history is what matters.

Building Labels Without Leakage

For a classification framing, a common label is "will fail within the next H hours". You take each failure timestamp and mark the windows inside the horizon before it as positive, everything else as negative. Three rules keep the labels honest:

1. Exclude the period right after maintenance for a short time, because readings during run-in are not representative.
2. Drop windows that contain the failure itself, otherwise the model learns to recognise a stopped machine.
3. Never compute features with data from after the window's timestamp. Centered rolling windows are a classic source of leakage.

A Working Example in Python

The script below generates simulated condition data for several pumps with occasional degradation, publishes it to the public MQTT test broker, collects it back with a subscriber, and trains a gradient boosting classifier that is evaluated on pumps it never saw during training. In practice the collector would read from your historian instead.

import json
import random
import time
import uuid

import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.metrics import classification_report

BROKER = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1"
rows = []


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    p["asset"] = msg.topic.split("/")[-2]
    rows.append(p)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe(f"{PREFIX}/+/condition", qos=1)
client.loop_start()
time.sleep(1)

# Simulate 6 pumps x 600 steps; some degrade toward failure at the end
for asset in range(6):
    fails = asset % 2 == 0
    for step in range(600):
        wear = max(0, step - 400) / 200 if fails else 0
        body = {
            "step": step,
            "vib_rms": round(1.0 + 1.5 * wear ** 2 + random.gauss(0, 0.08), 3),
            "bearing_temp": round(55 + 12 * wear + random.gauss(0, 0.5), 2),
            "current": round(14 + 1.5 * wear + random.gauss(0, 0.2), 2),
            "load": round(random.uniform(0.6, 1.0), 2),
            "failed_at": 600 if fails else None,
        }
        client.publish(f"{PREFIX}/pump{asset}/condition", json.dumps(body), qos=0)
        time.sleep(0.11)  # stay under the public broker's 10 msg/s per client

time.sleep(3)
client.loop_stop()

df = pd.DataFrame(rows).sort_values(["asset", "step"])
HORIZON = 100
df["label"] = ((df["failed_at"].notna()) & (df["failed_at"] - df["step"] <= HORIZON)).astype(int)

feats = []
for col in ["vib_rms", "bearing_temp", "current"]:
    g = df.groupby("asset")[col]
    df[f"{col}_mean20"] = g.transform(lambda s: s.rolling(20, min_periods=5).mean())
    df[f"{col}_std20"] = g.transform(lambda s: s.rolling(20, min_periods=5).std())
    df[f"{col}_slope50"] = g.transform(lambda s: s.diff(50) / 50)
    feats += [f"{col}_mean20", f"{col}_std20", f"{col}_slope50"]
feats.append("load")
df = df.dropna(subset=feats)

# Asset-based split: train on pumps 0-3, test on pumps 4-5 the model has never seen
train, test = df[~df["asset"].isin(["pump4", "pump5"])], df[df["asset"].isin(["pump4", "pump5"])]
model = HistGradientBoostingClassifier(max_iter=200, learning_rate=0.05)
model.fit(train[feats], train["label"])
print(classification_report(test["label"], model.predict(test[feats]), digits=3))

Install the dependencies with pip install paho-mqtt pandas numpy scikit-learn. The run takes several minutes because the simulator respects the public broker's rate limit. With your own ConnectMQ broker, using YOUR_USERNAME, YOUR_PASSWORD and YOUR_CLIENT_ID over port 8883, you can publish from many devices in parallel.

Choosing a First Model

• Gradient boosted trees (scikit-learn, XGBoost, LightGBM) are the default for tabular features. They handle mixed scales, need little tuning and give feature importances that maintenance engineers can discuss.
• Logistic regression is a useful baseline and easy to explain.
• Isolation Forest or autoencoders for anomaly framing when labels are scarce.
• Sequence models (LSTM, 1D CNN, transformers) only once you have a lot of history and simple models have plateaued.

Validating Like Production

Random train-test splits overstate performance on time series because neighbouring windows are nearly identical. Use a time-based split, and ideally hold out entire assets to check that the model generalises to machines it has not seen. Report precision and recall at the alert threshold you plan to use, and translate them into operational terms: how many false alarms per week, and how many failures caught with how much lead time. Those are the numbers a maintenance planner cares about.

Deploying and Closing the Loop

A deployed model is just another MQTT client. It subscribes to condition topics, scores each new window, and publishes a risk score:

connectmq/plant1/line2/pump3/health   {"ts":..., "risk":0.82, "model":"pdm-gbt-1.4"}

Dashboards, CMMS connectors and alerting tools subscribe to that topic. In the ConnectMQ portal you can also define threshold alert rules on the published risk value, so a score above your chosen limit appears in the alerts log without extra code. Track every alert's outcome as an event, feed it back into labels, and retrain periodically; the IoT MLOps article covers that lifecycle.

For the broader picture of models and devices working together, see the AI and IoT guide. For a digital twin perspective on the same problem, digital twin predictive maintenance adds physics context to the data-driven approach.

Get Started with ConnectMQ

Start collecting condition data today: create a free Serverless broker at app.connectmq.com, no credit card required, and connect your edge devices with the generated credentials. ConnectMQ gives you a fully managed MQTT service with TLS, a live topic explorer and threshold alerts, so you can focus on features and models rather than broker operations. If you later need more connections or isolation, the same topics move to a cloud MQTT broker plan with more capacity.

Frequently Asked Questions

How much data do I need for predictive maintenance machine learning?

For supervised failure prediction you need multiple recorded failures per failure mode, along with condition data before each one. If you have few failures, start with anomaly detection on normal data and collect labeled events as you go.

Which algorithm is best for predictive maintenance?

Gradient boosted trees on well-engineered rolling features are a strong starting point for most condition data. Deep sequence models can help with large histories, but they rarely beat good features on small datasets.

Why does my model look accurate in testing but fail in production?

The most common causes are random splits that leak near-identical windows into the test set, features computed with future data, and missing operating context. Use time-based or asset-based splits and check feature windows carefully.

Can the MQTT broker run the model?

No, the broker routes messages. Run the model as a separate MQTT client, at the edge or in the cloud, that subscribes to condition topics and publishes scores back to the broker.