Étiquetage de séries temporelles de capteurs pour le machine learning

L'étiquetage de séries temporelles de capteurs est généralement la partie la plus difficile du machine learning supervisé en IoT, non pas parce que les outils sont compliqués, mais parce que la vérité terrain est dispersée entre la mémoire des opérateurs, les registres papier et les systèmes de maintenance. Ce guide montre comment capturer les événements et les labels opérateur via MQTT au moment où ils se produisent, comment concevoir un schéma de labels qui résiste à l'usage réel et comment transformer ces événements en fenêtres étiquetées jointes à votre télémétrie.

Pourquoi les labels sont le goulot d'étranglement

Les données de capteurs sont peu coûteuses à collecter. Une passerelle qui publie toutes les quelques secondes produit des millions de points en quelques semaines. Mais un modèle censé reconnaître un filtre colmaté, un bris d'outil ou un défaut de qualité a besoin d'exemples où quelqu'un a dit « ceci s'est produit, ici, à ce moment-là ». Ces exemples sont rares, et les sources habituelles sont peu fiables :

• Les ordres de travail de maintenance enregistrent le moment de la réparation, pas celui du début du défaut, et contiennent souvent du texte libre comme « pompe réparée ».
• Les cahiers de quart sont rédigés en fin de poste, avec des heures approximatives.
• Les historiques d'alarmes enregistrent des franchissements de seuil, qui ne correspondent pas forcément à de vrais défauts.
• L'étiquetage rétrospectif par des ingénieurs qui examinent des courbes est lent et varie d'une personne à l'autre.

La solution la plus efficace consiste à capturer les labels sous forme d'événements structurés, au moment où ils se produisent, sur la même couche de messagerie que la télémétrie. Si l'opérateur appuie sur « bourrage résolu » sur une tablette et que cela devient un message MQTT avec un horodatage et un chemin d'actif, le label est déjà aligné sur les données de capteurs.

Les types de labels pour les données de capteurs

La plupart des projets ont besoin de plusieurs types à la fois. Les intervalles d'état machine (en marche, réglage, nettoyage, défaut) sont particulièrement précieux, car ils permettent d'exclure des périodes qui, sinon, perturberaient le modèle.

Concevoir un schéma de labels

Avant de construire la moindre interface, mettez-vous d'accord sur un schéma. Un schéma pratique comprend :

1. Un vocabulaire fixe de codes de labels, par exemple STATE_SETUP, STATE_CLEANING, FAULT_JAM, FAULT_LEAK, MAINT_BEARING_REPLACED. Le texte libre va dans un champ de commentaire séparé.
2. Un type d'événement : start, end ou point. Les intervalles sont construits à partir de paires début/fin.
3. Le chemin de l'actif, avec la même hiérarchie que la télémétrie, pour que la jointure soit triviale.
4. L'horodatage de l'événement et l'horodatage de saisie. L'opérateur peut saisir « bourrage commencé il y a 5 minutes » ; enregistrez à la fois le moment où cela s'est produit et le moment de la saisie.
5. L'auteur du label (rôle ou badge, pas nécessairement un nom) et le niveau de confiance le cas échéant.
6. Un identifiant d'événement unique, pour que les corrections puissent référencer et remplacer un label antérieur.
7. Une version de schéma pour gérer les évolutions sans casser les données plus anciennes.

Gardez un vocabulaire court. Dix codes bien définis et utilisés de façon cohérente valent mieux qu'une centaine de codes que chaque opérateur interprète différemment. Le guide sur la modélisation des données IIoT couvre l'aspect chemin d'actif de cette conception.

Capturer les labels via MQTT

Publiez les labels sur un sous-topic dédié de chaque actif, à côté de sa télémétrie :

connectmq/plant1/line2/filler1/telemetry/vibration
connectmq/plant1/line2/filler1/labels

Les labels doivent utiliser la QoS 1 pour ne pas être perdus silencieusement, et ne doivent pas être retenus, car chaque label est un événement et non un état courant. Si vous voulez aussi rendre l'état actuel de la machine visible dans les tableaux de bord, publiez-le séparément sur un topic state retenu.

Voici un petit client d'étiquetage Python qu'un poste opérateur ou un script de test peut utiliser. Il publie des événements de labels structurés sur le serveur MQTT public gratuit ; en exploitation réelle, utilisez les identifiants de votre propre broker.

# label_client.py
import json
import sys
import time
import uuid

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
ASSET = "connectmq/demo/lbl-4c2e/line2/filler1"
CODES = {"STATE_SETUP", "STATE_CLEANING", "FAULT_JAM", "FAULT_LEAK", "MAINT_BEARING_REPLACED"}


def publish_label(client, code, event, minutes_ago=0, comment="", operator="op-station-2"):
    if code not in CODES:
        raise ValueError(f"unknown label code {code}")
    now = int(time.time() * 1000)
    label = {
        "schema": 1,
        "id": str(uuid.uuid4()),
        "code": code,
        "event": event,                      # start | end | point
        "ts": now - int(minutes_ago * 60000),
        "entered": now,
        "by": operator,
        "comment": comment,
    }
    info = client.publish(f"{ASSET}/labels", json.dumps(label), qos=1)
    info.wait_for_publish()
    print("sent", label["code"], label["event"])


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="labeler-" + uuid.uuid4().hex[:8])
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()

# Utilisation : python label_client.py FAULT_JAM start 3 "bottle stuck at infeed"
code, event = sys.argv[1], sys.argv[2]
minutes = float(sys.argv[3]) if len(sys.argv) > 3 else 0
comment = sys.argv[4] if len(sys.argv) > 4 else ""
publish_label(client, code, event, minutes, comment)

client.loop_stop()
client.disconnect()

En pratique, le même message peut provenir d'un bouton de tableau de bord Node-RED, d'une application tablette utilisant MQTT over WebSocket, d'un lecteur de codes-barres sur un poste de contrôle qualité ou d'un automate qui publie ses propres changements d'état. Les labels générés par les machines, comme les codes d'état d'automate, sont souvent la source la plus fiable pour les intervalles d'état ; les opérateurs ajoutent ensuite ce que la machine ne peut pas savoir, comme les causes racines.

Transformer les événements en données d'entraînement

Une fois les labels et la télémétrie stockés par un abonné historian, l'étape suivante consiste à convertir les événements de début et de fin en intervalles et à les affecter à des fenêtres de télémétrie. Le script suivant le fait avec pandas.

# build_dataset.py
import pandas as pd

# labels.csv: id,code,event,ts   telemetry.csv: ts,vib_rms,current
labels = pd.read_csv("labels.csv", parse_dates=["ts"]).sort_values("ts")
tele = pd.read_csv("telemetry.csv", parse_dates=["ts"]).sort_values("ts")

# 1. Apparier les événements start/end par code en intervalles
intervals = []
open_events = {}
for row in labels.itertuples():
    if row.event == "start":
        open_events[row.code] = row.ts
    elif row.event == "end" and row.code in open_events:
        intervals.append((row.code, open_events.pop(row.code), row.ts))
intervals = pd.DataFrame(intervals, columns=["code", "start", "end"])

# 2. Construire des fenêtres fixes de caractéristiques de télémétrie
win = (tele.set_index("ts").resample("1min")
       .agg({"vib_rms": ["mean", "std", "max"], "current": ["mean"]}))
win.columns = ["_".join(c) for c in win.columns]
win = win.dropna().reset_index()
win["window_end"] = win["ts"] + pd.Timedelta(minutes=1)

# 3. Attribuer un label lorsqu'une fenêtre chevauche un intervalle sur plus de la moitié
def label_for(w):
    for iv in intervals.itertuples():
        overlap = (min(w.window_end, iv.end) - max(w.ts, iv.start)).total_seconds()
        if overlap > 30:
            return iv.code
    return "NORMAL"

win["label"] = [label_for(w) for w in win.itertuples()]

# 4. Écarter les fenêtres ambiguës proches des limites d'intervalle
for iv in intervals.itertuples():
    near = ((win["ts"] - iv.start).abs() < pd.Timedelta(minutes=2)) | \
           ((win["ts"] - iv.end).abs() < pd.Timedelta(minutes=2))
    win.loc[near, "label"] = "EXCLUDE"

dataset = win[win["label"] != "EXCLUDE"]
print(dataset["label"].value_counts())
dataset.to_csv("training_windows.csv", index=False)

Deux détails comptent ici. Les fenêtres situées aux limites sont exclues, car le début exact d'un bourrage ou d'une fuite est incertain, et entraîner le modèle sur ces fenêtres lui apprend du bruit. Et les événements de début non appariés ne sont pas fermés silencieusement : vérifiez-les, car un appui oublié sur « fin » peut transformer des heures de fonctionnement normal en label de défaut.

Contrôles qualité des labels

Utilisez cette liste de contrôle avant l'entraînement :

1. Comptez les labels par code et par actif ; des volumes très déséquilibrés révèlent souvent une équipe ou un site qui n'étiquette pas du tout.
2. Repérez les débuts et fins non appariés, ainsi que les intervalles qui se chevauchent avec des codes incompatibles.
3. Comparez l'heure de saisie et l'heure de l'événement ; de grands écarts indiquent des estimations rétrospectives.
4. Tracez la télémétrie autour d'un échantillon aléatoire de labels et vérifiez que le signal change réellement.
5. Faites relire un échantillon par une deuxième personne et mesurez le taux d'accord.
6. Versionnez le jeu de données avec la version du schéma de labels et la requête qui l'a produit.

Maintenir le flux de labels

L'étiquetage n'est pas un projet ponctuel. Intégrez-le au travail quotidien : le bouton qui acquitte une alarme de bourrage peut aussi publier le label, et le formulaire de clôture de maintenance peut publier le mode de défaillance. Renvoyez les alertes du modèle comme candidats labels que les opérateurs confirment ou rejettent ; cette confirmation est elle-même un label précieux. L'article MLOps IoT décrit comment ces boucles de rétroaction pilotent le réentraînement, et le machine learning pour la maintenance prédictive montre comment les labels de défaillance deviennent des cibles d'entraînement. Pour les modèles de dégradation, des événements couvrant tout le cycle de vie sont essentiels, comme l'explique la prédiction de la durée de vie résiduelle.

Labels et télémétrie sur ConnectMQ

Utiliser un seul broker pour la télémétrie et les labels garde tout aligné par chemin d'actif et par horodatage. ConnectMQ fournit un broker MQTT managé avec MQTT over WebSocket sécurisé sur le port 8084, afin qu'une page d'étiquetage dans le navigateur puisse publier directement, et l'explorateur de topics en direct vous permet de vérifier les messages de labels au moment où les opérateurs les envoient. Le stockage et la construction des jeux de données s'exécutent dans vos propres abonnés, comme un enregistreur historian et le script ci-dessus. Pour une vue d'ensemble de l'IA appliquée aux objets connectés, consultez le guide IA et IoT.

Démarrer avec ConnectMQ

Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire. Utilisez les identifiants générés YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID pour votre passerelle et vos clients d'étiquetage, et commencez dès aujourd'hui à collecter des labels à côté de votre télémétrie : chaque semaine de labels cohérents améliore votre prochain modèle.

Questions fréquentes

Quelle est la meilleure façon d'étiqueter des séries temporelles de capteurs ?

Capturez les labels sous forme d'événements structurés au moment où ils se produisent, avec un vocabulaire fixe, un chemin d'actif et des horodatages, sur la même couche de messagerie que la télémétrie. L'étiquetage rétrospectif à partir de courbes est plus lent et moins cohérent.

Les messages de labels doivent-ils être retenus dans MQTT ?

Non. Les labels sont des événements : publiez-les en QoS 1 sans le flag retain et stockez-les à l'aide d'un abonné. Publiez séparément l'état actuel de la machine sur un topic retenu si les tableaux de bord en ont besoin.

Comment gérer des heures de début de label incertaines ?

Enregistrez à la fois l'heure estimée de l'événement et l'heure de saisie, et excluez de l'entraînement les fenêtres proches des limites d'intervalle. Cela élimine les exemples les plus ambigus sans supprimer le label.

Les machines peuvent-elles générer des labels automatiquement ?

Oui. Les codes d'état d'automate, les événements d'alarme et les résultats des postes de contrôle qualité sont de bons labels automatiques. Les opérateurs ajoutent ensuite les informations que la machine ne peut pas connaître, comme la cause racine ou la confirmation d'une alerte du modèle.