La detección de anomalías IoT consiste en identificar automáticamente lecturas o patrones de sensores que no encajan con el comportamiento normal, con tiempo suficiente para actuar. Esta guía compara las principales familias de detectores, muestra dónde debe ejecutarse cada una en relación con tu broker MQTT y te ofrece una arquitectura de referencia para publicar eventos de anomalía en los que puedan confiar los dashboards y las personas.
Qué se considera una anomalía en datos IoT
No todas las anomalías tienen el mismo aspecto, y el tipo que te interesa determina el método.
- Anomalías puntuales. Una única lectura muy fuera del rango normal: una temperatura de 140 grados en un sensor que nunca supera los 80.
- Anomalías contextuales. Un valor normal en un contexto y anómalo en otro: 30 grados es normal a mediodía en verano y sospechoso a las 3 de la madrugada en una cámara frigorífica.
- Anomalías colectivas. Un patrón a lo largo del tiempo: una vibración que está dentro de los límites en cada muestra, pero cuyo espectro se desplaza lentamente hacia la frecuencia de fallo de un rodamiento.
- Anomalías multivariantes. Cada señal es normal por sí sola, pero la combinación no lo es: una corriente de motor alta con un caudal bajo sugiere una bomba obstruida.
También hay una categoría que no tiene nada que ver con el proceso: las anomalías de calidad de datos, como un sensor plano, un valor bloqueado, un cambio repentino de unidades o marcas de tiempo que llegan desordenadas. En la práctica, se encuentran entre las alertas más frecuentes, y detectarlas primero evita que tus detectores de proceso generen falsas alarmas.
Familias de métodos de detección de anomalías IoT
| Familia | Ejemplos | Adecuada para | Necesita datos de entrenamiento | Se ejecuta en microcontrolador |
|---|---|---|---|---|
| Reglas y umbrales | Límites fijos, límites de velocidad de cambio | Modos de fallo conocidos, límites de seguridad | No | Sí |
| Estadísticos | Z-score, IQR, EWMA, ventanas móviles | Señales individuales con línea base estable | Un historial breve | Sí |
| Machine learning clásico | Isolation Forest, One-Class SVM, Local Outlier Factor | Características tabulares multivariantes | Datos normales, sin etiquetar | A veces |
| Deep learning | Autoencoders, predictores LSTM o CNN 1D | Formas de onda, espectros, patrones temporales complejos | Gran conjunto de datos normales | Solo modelos pequeños |
| Residuo de pronóstico | Modelos estacionales, pronósticos con gradient boosting | Señales estacionales como la demanda energética | Historial con estaciones | Rara vez |
Detectores estadísticos
Empieza por aquí. Una media y una desviación típica móviles, o una mediana y un rango intercuartílico, detectan una proporción sorprendente de problemas reales con casi ningún esfuerzo de ingeniería. La EWMA (media móvil ponderada exponencialmente) se adapta a la deriva lenta sin almacenar una ventana. Estos métodos son explicables, baratos y fáciles de ajustar. Los detalles y el código están en detección de outliers en datos de sensores con Z-score, IQR y EWMA.
Detectores de machine learning
Cuando las anomalías se esconden en la relación entre señales, entrena un modelo no supervisado con el funcionamiento normal. Isolation Forest es una opción práctica por defecto: se entrena rápido, es robusto ante características irrelevantes y no necesita etiquetas. Diseñas características por ventana (media, RMS, pico, pendiente por señal) y el modelo puntúa lo aislada que está cada ventana. Tienes un recorrido completo en Isolation Forest para datos de sensores.
Detectores de deep learning
Para formas de onda en bruto, como la vibración y el sonido, los autoencoders aprenden a reconstruir los patrones normales; un error de reconstrucción alto señala algo nuevo. Necesitan más datos y capacidad de cálculo y son más difíciles de explicar, así que úsalos cuando las características más sencillas fallen de verdad. El sonido de las máquinas es un buen ejemplo, tratado en detección de anomalías por audio en máquinas.
Dónde se ejecutan los detectores respecto al broker
MQTT ofrece una separación limpia: los dispositivos publican datos, los detectores se suscriben y los detectores publican los resultados como nuevos mensajes. El broker MQTT está en el medio y no necesita saber qué hace cada detector. Eso deja tres opciones de ubicación.
En el dispositivo
Ejecuta umbrales, comprobaciones de velocidad de cambio y modelos diminutos directamente en el nodo sensor. Ventajas: reacción inmediata, sin dependencia de la conectividad, y puedes enviar solo resúmenes más eventos de anomalía en lugar de datos en bruto a alta frecuencia. Limitaciones: modelos pequeños, actualizaciones más difíciles y ningún contexto entre dispositivos.
En el gateway de borde
Un gateway o un PC industrial se suscribe a las máquinas locales, ejecuta modelos más pesados como Isolation Forest o autoencoders y publica puntuaciones. Es el punto óptimo para la detección multivariante dentro de una máquina o línea, y mantiene los datos de alta frecuencia en la planta.
En la nube
Un servicio en la nube se suscribe a muchas plantas a la vez. Puede comparar máquinas similares entre plantas, ejecutar modelos costosos y combinar datos de proceso con contexto de negocio. La latencia es mayor y depende del enlace de subida, así que no es el lugar adecuado para nada relacionado con la seguridad.
La mayoría de los sistemas reales combinan las tres: límites en el dispositivo, ML en el borde y comparaciones de flota en la nube, todo comunicado mediante topics.
Una arquitectura de topics de referencia
connectmq/site1/area2/line1/pump3/telemetry raw or aggregated readings
connectmq/site1/area2/line1/pump3/anomaly detector output per asset
connectmq/site1/alerts confirmed alerts for people
connectmq/site1/area2/line1/pump3/detector/status retained: model, version, health
Un mensaje de salida del detector debe explicarse por sí mismo:
{
"ts": "2026-10-16T09:12:30Z",
"asset": "pump3",
"detector": "iforest-v3",
"score": 0.71,
"threshold": 0.62,
"isAnomaly": true,
"features": {"currentA": 18.4, "flowLpm": 41.0},
"reason": "high current with low flow"
}
Incluir el umbral, la versión del detector y las características que más contribuyen convierte una luz roja opaca en algo que un técnico puede comprobar.
Un bucle de detección mínimo
El núcleo de cualquier detector en streaming cabe en unas pocas líneas. Este evaluador de z-score móvil es el patrón que el tutorial completo de detección de anomalías en tiempo real con Python desarrolla hasta convertirlo en un servicio MQTT completo:
from collections import deque
import statistics
window = deque(maxlen=120)
def score(value, k=3.5):
if len(window) < 30:
window.append(value)
return None
mean = statistics.fmean(window)
std = statistics.pstdev(window) or 1e-9
z = (value - mean) / std
if abs(z) < k:
window.append(value) # aprende solo de los valores normales
return z
Fíjate en el último detalle: los valores anómalos no se añaden a la línea base, así que un fallo prolongado no se convierte poco a poco en la nueva normalidad.
Reducir las falsas alarmas
Las falsas alarmas acaban con los proyectos de detección de anomalías más rápido que las detecciones fallidas, porque los operarios dejan de prestar atención. Una lista de comprobación que ayuda:
- Filtra primero la calidad de datos. Marca los valores bloqueados, ausentes y fuera de rango por separado de las anomalías de proceso.
- Usa el contexto. Ignora las lecturas durante arranques, limpiezas y cambios de formato, que puedes detectar a partir de un topic de estado.
- Exige persistencia. Genera una alerta solo tras N ventanas anómalas de M, no por una única muestra.
- Añade histéresis. Borra la alerta con un umbral inferior al que la disparó para evitar oscilaciones.
- Separa la puntuación de la alerta. Publica las puntuaciones en bruto de forma continua y decide las alertas en un paso aparte que puedas ajustar.
- Revisa cada semana. Marca cada alerta como útil o como ruido y ajusta los umbrales según ese registro.
- Versiona los detectores. Incluye la versión del detector en cada mensaje para poder comparar antes y después de un cambio.
La capa de mensajería
Los detectores, los dashboards, los historians y las herramientas de alertas dependen del mismo broker, así que su fiabilidad importa. Para experimentar, el servidor MQTT público gratuito que ConnectMQ ofrece en broker.connectmq.com basta para conectar un simulador, un detector y un dashboard en minutos, siempre con datos de prueba y nunca con datos de producción. Para datos reales de planta, necesitas un broker MQTT en la nube privado y protegido con TLS, con credenciales por dispositivo.
ConnectMQ, como broker MQTT gestionado, proporciona exactamente esa capa: MQTT 3.1.1 y 5.0 sobre TLS y WebSocket seguro, una vista de dispositivos organizada por niveles ISA-95, un explorador de topics en directo para ver las puntuaciones en tiempo real y reglas de alerta por umbral con un registro de alertas para límites numéricos sencillos. Los modelos de detección se ejecutan en tus propios servicios, lo que te deja libertad para usar cualquier biblioteca.
Para ver cómo encaja la detección de anomalías con la predicción, la visión artificial y los asistentes basados en LLM, lee la guía de IA e IoT.
Construye tu canal de anomalías en ConnectMQ
Crea un broker en el plan gratuito Serverless en app.connectmq.com sin tarjeta de crédito, publica lecturas simuladas y ejecuta un detector que publique de vuelta las puntuaciones. En cuestión de minutos verás los valores en bruto y los eventos de anomalía uno al lado del otro en el explorador de topics.
Preguntas frecuentes
¿Con qué método de detección de anomalías debo empezar?
Empieza con umbrales y un z-score móvil o una EWMA en cada señal importante. Pasa a Isolation Forest o a autoencoders solo cuando tengas pruebas de que las anomalías residen en las relaciones entre señales o en la forma de las ondas.
¿Necesito datos de fallos etiquetados?
No. La mayor parte de la detección de anomalías IoT es no supervisada: los modelos aprenden el comportamiento normal y señalan las desviaciones. Las etiquetas cobran valor más adelante para evaluar y ajustar las alertas.
¿La detección de anomalías debe ejecutarse en el borde o en la nube?
Ejecuta las comprobaciones rápidas y relevantes para la seguridad en el dispositivo o en el borde, y las comparaciones de toda la flota en la nube. MQTT te permite mover un detector de una ubicación a otra sin cambiar los dispositivos.
¿Cómo publico los resultados de anomalías?
Publica un mensaje JSON por activo en un topic de anomalías dedicado que incluya la puntuación, el umbral, la versión del detector y las características que contribuyen. Mantén las alertas confirmadas para personas en un topic separado.
