Etiquetado de series temporales de sensores para machine learning

El etiquetado de series temporales de sensores suele ser la parte más difícil del machine learning supervisado en IoT, no porque las herramientas sean complicadas, sino porque la verdad de referencia está repartida entre la memoria de los operarios, los registros en papel y los sistemas de mantenimiento. Esta guía muestra cómo capturar eventos y etiquetas de operarios por MQTT en el momento en que ocurren, cómo diseñar un esquema de etiquetas que resista el uso real y cómo convertir esos eventos en ventanas etiquetadas unidas a tu telemetría.

Por qué las etiquetas son el cuello de botella

Recoger datos de sensores es barato. Un gateway que publica cada pocos segundos genera millones de puntos en unas semanas. Pero un modelo que deba reconocer un filtro obstruido, la rotura de una herramienta o un defecto de calidad necesita ejemplos en los que alguien haya dicho "esto pasó, aquí, a esta hora". Esos ejemplos son escasos, y las fuentes habituales no son fiables:

• Las órdenes de trabajo de mantenimiento registran cuándo se hizo la reparación, no cuándo empezó el fallo, y a menudo contienen texto libre como "bomba arreglada".
• Los partes de turno se escriben al final del turno, con horas aproximadas.
• Los históricos de alarmas registran cruces de umbral, que no son lo mismo que fallos reales.
• El etiquetado retrospectivo por parte de ingenieros que revisan gráficas es lento e inconsistente entre personas.

La solución más eficaz es capturar las etiquetas como eventos estructurados, en el momento en que ocurren y en la misma capa de mensajería que la telemetría. Si el operario pulsa "atasco resuelto" en una tablet y eso se convierte en un mensaje MQTT con marca de tiempo y ruta del activo, la etiqueta ya está alineada con los datos de los sensores.

Tipos de etiquetas para datos de sensores

La mayoría de los proyectos necesitan varios tipos a la vez. Los intervalos de estado de máquina (en marcha, preparación, limpieza, fallo) son especialmente valiosos porque permiten excluir periodos que de otro modo confundirían a un modelo.

Diseñar un esquema de etiquetas

Antes de construir cualquier interfaz, acordad un esquema. Uno práctico incluye:

1. Un vocabulario fijo de códigos de etiqueta, por ejemplo STATE_SETUP, STATE_CLEANING, FAULT_JAM, FAULT_LEAK, MAINT_BEARING_REPLACED. El texto libre va en un campo de comentario aparte.
2. Un tipo de evento: start, end o point. Los intervalos se construyen a partir de pares de inicio y fin.
3. La ruta del activo, con la misma jerarquía que la telemetría, para que la unión sea trivial.
4. Marca de tiempo de origen y marca de tiempo de registro. El operario puede introducir "el atasco empezó hace 5 minutos"; registra tanto cuándo ocurrió como cuándo se introdujo.
5. Quién lo etiquetó (rol o tarjeta, no necesariamente un nombre) y la confianza cuando corresponda.
6. Un ID de evento único, para que las correcciones puedan hacer referencia a una etiqueta anterior y reemplazarla.
7. Una versión de esquema para gestionar cambios sin romper los datos antiguos.

Mantén el vocabulario corto. Diez códigos bien definidos y usados con coherencia valen más que cien códigos que cada operario interpreta a su manera. La guía de modelado de datos IIoT trata la parte de la ruta del activo de este diseño.

Capturar etiquetas por MQTT

Publica las etiquetas en un subtopic dedicado de cada activo, junto a su telemetría:

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

Las etiquetas deben usar QoS 1 para que no se pierdan en silencio y no deben ser retained, porque cada etiqueta es un evento y no un estado actual. Si además quieres que el estado actual de la máquina sea visible en los dashboards, publícalo por separado como un topic state retenido.

Aquí tienes un pequeño cliente de etiquetado en Python que puede usar un puesto de operario o un script de pruebas. Publica eventos de etiqueta estructurados en el servidor MQTT público gratuito, pensado para pruebas y prototipos; para la operación real y los datos de producción, usa las credenciales de tu propio 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()

# Uso: 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 la práctica, el mismo mensaje puede venir de un botón en un dashboard de Node-RED, de una app de tablet que usa MQTT sobre WebSocket, de un lector de códigos de barras en un puesto de calidad o de un PLC que publica sus propios cambios de estado. Las etiquetas generadas por máquinas, como los códigos de estado del PLC, suelen ser la fuente más fiable para los intervalos de estado; los operarios añaden después lo que la máquina no puede saber, como las causas raíz.

Convertir eventos en datos de entrenamiento

Una vez que un suscriptor historian ha almacenado las etiquetas y la telemetría, el siguiente paso es convertir los eventos de inicio y fin en intervalos y asignarlos a ventanas de telemetría. El siguiente script lo hace con 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. Emparejar eventos start/end por código en intervalos
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. Construir ventanas fijas de características de telemetría
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. Asignar una etiqueta cuando una ventana se solapa con un intervalo más de la mitad
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. Descartar ventanas ambiguas cerca de los límites de los intervalos
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)

Aquí importan dos detalles. Las ventanas de los límites se excluyen porque el inicio exacto de un atasco o una fuga es incierto, y entrenar con esas ventanas enseña ruido al modelo. Y los eventos de inicio sin pareja no se cierran en silencio; revísalos, porque olvidar pulsar "fin" puede convertir horas de funcionamiento normal en una etiqueta de fallo.

Controles de calidad de las etiquetas

Usa esta lista de comprobación antes de entrenar:

1. Cuenta las etiquetas por código y por activo; unos recuentos muy desiguales suelen revelar que un turno o una planta no etiqueta en absoluto.
2. Busca inicios y fines sin pareja, y solapamientos de intervalos con códigos incompatibles.
3. Compara la hora de registro con la hora del evento; las grandes diferencias indican estimaciones retrospectivas.
4. Representa la telemetría alrededor de una muestra aleatoria de etiquetas y comprueba que la señal cambia de verdad.
5. Pide a una segunda persona que revise una muestra y mide el grado de acuerdo.
6. Versiona el dataset con la versión del esquema de etiquetas y la consulta que lo generó.

Mantener el flujo de etiquetas

El etiquetado no es un proyecto puntual. Intégralo en el trabajo normal: el botón que borra una alarma de atasco también puede publicar la etiqueta, y el formulario de cierre de mantenimiento puede publicar el modo de fallo. Devuelve las alertas del modelo como candidatas a etiqueta que los operarios confirman o rechazan; esa confirmación es en sí misma una etiqueta valiosa. El artículo de MLOps para IoT describe cómo estos bucles de retroalimentación impulsan el reentrenamiento, y machine learning para mantenimiento predictivo muestra cómo las etiquetas de fallo se convierten en objetivos de entrenamiento. Para los modelos de degradación, los eventos completos del ciclo de vida son imprescindibles, como se explica en predicción de la vida útil remanente.

Etiquetas y telemetría en ConnectMQ

Usar un único broker para la telemetría y las etiquetas mantiene todo alineado por ruta de activo y por tiempo. ConnectMQ ofrece un broker MQTT gestionado con MQTT sobre WebSocket seguro en el puerto 8084, de modo que una página de etiquetado en el navegador puede publicar directamente, y el explorador de topics en directo te permite verificar los mensajes de etiqueta a medida que los operarios los envían. El almacenamiento y la construcción de datasets se ejecutan en tus propios suscriptores, como un escritor de historian y el script anterior. Las mismas rutas de activo permiten además situar las etiquetas y las alarmas sobre un gemelo digital 3D de la línea. Para una visión más amplia de la IA con dispositivos conectados, consulta la guía de IA e IoT.

Empieza con ConnectMQ

Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Usa los YOUR_USERNAME, YOUR_PASSWORD y YOUR_CLIENT_ID generados para tu gateway y tus clientes de etiquetado, y empieza hoy mismo a recoger etiquetas junto a tu telemetría; cada semana de etiquetas coherentes mejora tu próximo modelo.

Preguntas frecuentes

¿Cuál es la mejor forma de etiquetar series temporales de sensores?

Captura las etiquetas como eventos estructurados en el momento en que ocurren, con un vocabulario fijo, ruta del activo y marcas de tiempo, en la misma capa de mensajería que la telemetría. El etiquetado retrospectivo a partir de gráficas es más lento y menos coherente.

¿Los mensajes de etiqueta deben ser retained en MQTT?

No. Las etiquetas son eventos, así que publícalas con QoS 1 y sin el flag retain, y almacénalas con un suscriptor. Publica el estado actual de la máquina por separado como un topic retenido si los dashboards lo necesitan.

¿Cómo gestiono las horas de inicio inciertas de las etiquetas?

Registra tanto la hora estimada del evento como la hora de registro, y excluye del entrenamiento las ventanas cercanas a los límites de los intervalos. Así eliminas los ejemplos más ambiguos sin descartar la etiqueta.

¿Pueden las máquinas generar etiquetas automáticamente?

Sí. Los códigos de estado del PLC, los eventos de alarma y los resultados de los puestos de calidad son buenas etiquetas automáticas. Después, los operarios añaden la información que la máquina no puede conocer, como la causa raíz o la confirmación de una alerta del modelo.