Prédiction de la durée de vie résiduelle (RUL) expliquée

La prédiction de la durée de vie résiduelle estime combien de temps un composant ou une machine peut encore fonctionner avant d'atteindre un état de défaillance. Au lieu de demander « y a-t-il un problème ? », elle demande « combien de temps nous reste-t-il ? », ce qui est précisément la question à laquelle les planificateurs de maintenance ont besoin d'une réponse. Cet article présente les principales familles de modèles de RUL, l'historique de données que chacune exige des actifs connectés via MQTT, et comment calculer et publier une estimation avec une incertitude honnête.

Ce que signifie la durée de vie résiduelle

La durée de vie résiduelle (RUL, pour Remaining Useful Life) est le temps, le nombre de cycles ou d'heures de fonctionnement restant avant qu'un actif ne franchisse un seuil de défaillance défini. Trois éléments de cette définition méritent attention :

L'unité. Le temps calendaire est facile à communiquer mais trompeur quand l'utilisation varie. Les heures de fonctionnement, les cycles, les courses ou les unités produites suivent souvent mieux l'usure.
Le seuil de défaillance. La RUL a besoin d'un point final défini : un niveau de vibration auquel on remplace un roulement, une perte de charge de filtre à partir de laquelle le débit devient inacceptable, une capacité à laquelle une batterie est mise au rebut. Sans seuil, il n'y a rien à prédire.
L'incertitude. Un chiffre unique comme « 212 heures » masque le degré de confiance du modèle. Une estimation de RUL utile s'accompagne toujours d'une fourchette.

La prédiction de la RUL est l'une des formulations de la maintenance prédictive par machine learning. Elle convient aux actifs qui se dégradent de façon progressive et reproductible, comme les roulements, les filtres, les outils de coupe, les batteries, les courroies et les joints. Elle convient mal aux pannes soudaines, comme les défauts électroniques.

Les familles de modèles pour la prédiction de la durée de vie résiduelle

Approche	Principe	Données nécessaires	Point fort	Point faible
Statistiques de fiabilité (Weibull)	Ajuster une loi de durée de vie à partir des dates de panne passées	Dates de panne et de remplacement uniquement	Aucun capteur nécessaire	Ignore l'état de cette unité précise
Modèles de tendance de dégradation	Suivre un indicateur de santé et l'extrapoler jusqu'à un seuil	Historique d'état de l'unité en cours et un seuil	Intuitif, fonctionne avec peu de pannes	Suppose que la forme de la tendance reste la même
Modèles par similarité	Comparer la trajectoire actuelle aux trajectoires passées jusqu'à la panne	Plusieurs historiques run-to-failure complets	Capte des trajectoires réalistes	Nécessite des unités historiques comparables
Régression ML directe	Apprendre la RUL à partir de features (gradient boosting, LSTM, CNN)	De nombreux historiques run-to-failure labellisés	Peut capter des schémas complexes	Gourmand en données, plus difficile à expliquer
Modèles physiques	Modéliser les mécanismes d'usure (propagation de fissures, vieillissement thermique)	Connaissances d'ingénierie, paramètres des matériaux	Fonctionne avant même d'avoir des données	Coûteux à construire pour chaque type d'actif

La plupart des projets concrets commencent par un modèle de tendance de dégradation, car il ne nécessite que l'historique d'une unité et un seuil. Les méthodes par similarité et ML viennent plus tard, une fois que l'organisation a consigné suffisamment de cycles de vie complets. Les modèles physiques, eux, sont souvent au cœur d'un jumeau numérique de l'actif, alimenté par les mesures en direct.

L'historique de données dont les modèles de RUL ont besoin

La prédiction de la RUL est plus exigeante en historique que la détection d'anomalies. Prévoyez ces flux de données dès le départ, car ils ne peuvent pas être reconstitués après coup.

Les signaux d'état sur toute la durée de vie de chaque unité, pas seulement les dernières semaines. Des features comme le RMS vibratoire, l'échauffement ou la perte de charge, échantillonnées de façon cohérente.
Les compteurs d'utilisation comme les heures de fonctionnement, les cycles ou le débit, afin d'exprimer la RUL dans l'unité qui pilote l'usure.
Le contexte de fonctionnement comme la charge, la vitesse et la température ambiante, pour distinguer la dégradation des variations de conditions.
Les événements du cycle de vie : installation, remplacement, réparation et panne, chacun avec un horodatage et le numéro de série du composant. Ils définissent où une vie se termine et où la suivante commence.
Les définitions de défaillance : quel état correspond à la fin de vie, consigné par type de composant.

Via MQTT, cela signifie généralement un topic d'état, un topic d'utilisation et un topic d'événements par actif, tous avec des horodatages source, stockés par un abonné historian. Le guide sur la labellisation des séries temporelles de capteurs montre comment recueillir les événements du cycle de vie et les saisies des opérateurs en parallèle de la télémétrie, pour que les enregistrements run-to-failure soient complets.

Construire un indice de santé

La plupart des méthodes de RUL travaillent sur un indicateur de santé unique plutôt que sur de nombreux signaux bruts. Un indice de santé (HI, pour Health Index) combine des features en un seul nombre qui évolue de façon monotone à mesure que l'actif se dégrade. Façons courantes de le construire :

Utiliser une seule feature physiquement significative, comme le RMS vibratoire d'un roulement ou la pression différentielle d'un filtre.
Combiner des features normalisées avec des pondérations choisies par les ingénieurs.
Utiliser l'erreur de reconstruction d'un modèle entraîné sur des données saines.
Utiliser la première composante principale des features sur des historiques allant de l'état sain à la panne.

Les bons indices de santé partagent trois propriétés : ils sont monotones (ils reculent rarement), pronostiquables (la panne survient à un niveau d'HI constant) et ils évoluent suffisamment tôt pour être utiles.

Un exemple de tendance de dégradation en Python

Le script suivant s'abonne à un topic d'indice de santé, ajuste un modèle de dégradation exponentielle sur l'historique récent, extrapole jusqu'à un seuil de défaillance, estime une bande d'incertitude par bootstrap et republie la RUL sur MQTT. Un simulateur intégré publie l'indice de santé pour que vous puissiez l'exécuter de bout en bout avec le serveur MQTT public gratuit.

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        # valeur d'HI définie comme fin de vie (par ex. RMS vibratoire en mm/s)
MIN_POINTS = 30
history = []           # (heures_de_fonctionnement, hi)


def fit_rul(hours, hi):
    # Ajuster ln(hi - baseline) = a + b * t, puis résoudre le franchissement du seuil
    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()

Installez avec pip install paho-mqtt numpy. En début d'exécution, la bande entre p10_h et p90_h est large ; à mesure que l'indice de santé s'infléchit vers le haut, l'estimation se stabilise et la bande se resserre. Ce comportement est normal et il est important de le communiquer : les estimations de RUL ne deviennent fiables qu'une fois la dégradation clairement visible.

Publier des estimations de RUL exploitables par d'autres

Publiez l'estimation sous forme de retained message sur un topic dédié par actif, comme .../fan2/rul, pour que les tableaux de bord et les connecteurs de GMAO obtiennent immédiatement la dernière valeur dès leur abonnement. Incluez la méthode et sa version, le seuil utilisé et la plage d'incertitude. Dans le portail ConnectMQ, vous pouvez suivre le topic dans l'explorateur de topics en direct et ajouter une règle d'alerte à seuil, par exemple lorsque p10_h passe sous une fenêtre de planification, afin que ce soit la borne basse, et non l'estimation ponctuelle, qui déclenche l'alerte.

Erreurs courantes dans les projets de RUL

Prédire en jours calendaires une usure liée à l'utilisation. Convertissez d'abord en heures de fonctionnement ou en cycles.
Mélanger les vies. Si un remplacement de composant n'est pas consigné, deux vies fusionnent en une trajectoire incompréhensible.
Ignorer l'incertitude. Un planificateur qui ne voit qu'une estimation ponctuelle lui fera soit trop confiance, soit l'ignorera.
Entraîner des modèles ML sur une poignée de pannes. Commencez par des modèles de tendance ou de similarité et passez au ML quand l'historique le permet.
Oublier les changements de régime. Une variation de charge peut décaler l'indice de santé sans aucune dégradation ; normalisez selon le contexte de fonctionnement.

La place de la RUL dans votre stack

L'estimation de la RUL repose sur des données d'état fiables, qui dépendent elles-mêmes d'une couche de messagerie stable. ConnectMQ fournit cette couche sous forme de broker MQTT managé, tandis que les modèles tournent comme vos propres clients. Pour des techniques de prévision qui complètent l'extrapolation de tendance, consultez la prévision des séries temporelles IoT, et pour une vue d'ensemble des modèles associés aux appareils connectés, le guide IA et IoT.

Commencez à collecter des données de cycle de vie sur ConnectMQ

Les modèles de RUL ne valent que par l'historique qui les sous-tend : le meilleur moment pour commencer à enregistrer, c'est maintenant. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, connectez vos actifs avec le nom d'utilisateur, le mot de passe et le client ID générés, et commencez à stocker les événements d'état, d'utilisation et de cycle de vie via un abonné historian. Lorsque votre parc s'agrandit, une offre de broker MQTT cloud vous apporte davantage de connexions et d'isolation sans changer vos topics.

Questions fréquentes

Qu'est-ce que la prédiction de la durée de vie résiduelle ?

C'est l'estimation du temps de fonctionnement, du nombre de cycles ou de l'utilisation qu'il reste à un actif avant qu'il n'atteigne un état de défaillance défini, généralement à partir de ses données d'état et du comportement d'actifs similaires.

Combien de pannes faut-il pour prédire la RUL ?

Les modèles de tendance de dégradation peuvent fonctionner avec l'historique d'une seule unité et un seuil défini par l'ingénierie. Les modèles par similarité et de machine learning nécessitent de plusieurs à de nombreux historiques run-to-failure complets pour chaque type de composant.

Pourquoi l'estimation de RUL varie-t-elle autant au début ?

Avant que la dégradation ne devienne visible, la tendance est dominée par le bruit et l'extrapolation est instable. Indiquez une plage d'incertitude et fiez-vous à l'estimation une fois que cette plage se resserre.

La RUL doit-elle être exprimée en jours ou en heures de fonctionnement ?

Utilisez l'unité qui pilote l'usure, généralement les heures de fonctionnement, les cycles ou le débit, et ne convertissez en dates calendaires que pour la planification, en vous appuyant sur le taux d'utilisation prévu.

La prédiction de la durée de vie résiduelle (RUL) expliquée