De los sensores a las predicciones: cómo funciona realmente una plataforma PdM

"Simplemente aplicaremos ML a los datos de los sensores" es el gesto vago que lanza mil proyectos PdM fallidos. La realidad es que el modelo ML representa quizás el 20 % del sistema. El otro 80 % consiste en llevar datos de forma fiable desde los sensores hasta los modelos, y en llevar las predicciones de forma fiable desde los modelos hasta las personas.

Así funciona el pipeline completo en una plataforma moderna, desde el sensor físico hasta el teléfono del ingeniero.

Capa 1: Recolección en el borde (Edge)

Los sensores industriales producen datos a tasas muy diferentes. Un acelerómetro de vibración en un rodamiento muestrea a 12 800 Hz. Una sonda de temperatura se actualiza cada 30 segundos. Un caudalímetro envía datos cada 5 segundos.

Un edge gateway se encarga de:

Traducción de protocolos — OPC-UA, MQTT, Modbus RTU y señales analógicas 4-20 mA requieren controladores distintos
Buffer local — Los cortes de red no deben provocar pérdida de datos. El gateway almacena lecturas localmente y las sincroniza cuando se recupera la conectividad
Downsampling — Los datos de vibración a 12,8 kHz se resumen (RMS, pico, curtosis) para la monitorización continua, y se capturan formas de onda brutas periódicamente para el análisis espectral

El reto de los protocolos

La traducción de protocolos suena sencilla en la presentación de un proveedor. En la práctica, es donde la mayoría de los despliegues PdM encuentran su primer obstáculo.

OPC-UA es el estándar moderno, aunque "estándar" es un término generoso: cada fabricante de equipo lo implementa de forma diferente. Pasará días configurando certificados de seguridad (OPC-UA exige el intercambio de certificados X.509), asignando IDs de nodo a nombres de etiqueta significativos y lidiando con servidores que solo implementan un subconjunto de la especificación. Los equipos más recientes suelen ser conformes; cualquier cosa fabricada antes de 2015 es una apuesta.

Modbus RTU/TCP es fiable pero rudimentario. El mapeo de registros es completamente manual: la documentación del sensor le indica "el registro 40001 es vibración en el eje X, float de 32 bits, big-endian", y usted lo traduce en configuración. Multiplíquelo por 50-200 sensores por instalación y entenderá por qué solo el mapeo de protocolos puede consumir una semana completa de puesta en marcha.

Las señales analógicas 4-20 mA requieren hardware adicional: acondicionadores de señal, conversores analógico-digital y una puesta a tierra cuidadosa para evitar ruido. Un offset de 0,1 mA en un lazo de corriente 4-20 mA se traduce directamente en un error de medición que su modelo ML interpretará como un cambio de proceso.

Los requisitos de hardware del borde suelen subestimarse. Un gateway que gestiona 200 sensores necesita cómputo suficiente para el buffer local (mínimo 32 GB de almacenamiento para 72 horas de capacidad sin conexión), la traducción de protocolos (con alta carga de CPU por el cifrado OPC-UA) y la inferencia opcional en el borde. Los gateways de grado industrial de fabricantes como Advantech, Moxa o Siemens IOT2050 tienen un coste típico de 500-2 000 € por unidad, con procesadores ARM o x86 y rangos de temperatura industrial (-40 a 70 °C).

Capa 2: Ingestión en streaming

Los datos salen del borde como mensajes MQTT y entran en un agente de mensajes (normalmente Apache Kafka) que proporciona:

Durabilidad — Los mensajes persisten hasta ser consumidos, sobreviviendo a los reinicios del servicio
Múltiples consumidores — Los mismos datos alimentan simultáneamente el procesamiento en tiempo real, el almacenamiento en frío y los pipelines ML
Cumplimiento del esquema — Los esquemas Avro validan la estructura de los datos antes de que entren en el pipeline

En esta etapa, los datos se validan: se verifican los IDs de los sensores, se comprueban los timestamps en busca de deriva y las lecturas fuera de los límites físicos se marcan. Una lectura de vibración de -500 mm/s o una temperatura de 3 000 °C se pone en cuarentena, sin pasar a los modelos ML. Un scoring de calidad (0-100) etiqueta cada lectura, y todo lo que esté por debajo de 50 se filtra antes de alcanzar la etapa de ingeniería de características.

Capa 3: Procesamiento en streaming

Un procesador de flujos (Apache Flink) transforma las lecturas brutas en características listas para ML en tiempo real:

Estadísticas rodantes — Media, desviación estándar, RMS, curtosis en ventanas de 60 s, 5 min y 30 min
Detección de tendencias — ¿La vibración aumenta, se mantiene estable o decrece durante la última hora?
Correlación entre sensores — Una temperatura en aumento con vibración estable sugiere un cambio ambiental, no degradación
Características de frecuencia — La FFT sobre los datos de vibración extrae frecuencias de rodamiento, frecuencias de engrane y armónicos

Ingeniería de características en detalle

La calidad de las predicciones ML se determina aquí, no en la arquitectura del modelo. Algunos ejemplos concretos:

RMS rodante frente a pico a pico: el RMS de vibración captura la energía total y es adecuado para detectar desequilibrio o desalineación. El pico a pico captura impactos transitorios y es más adecuado para la detección temprana de daños en rodamientos (donde el contacto metal-metal genera picos cortos y abruptos). Calcular ambos en múltiples tamaños de ventana (60 s, 300 s, 1 800 s) proporciona al modelo diferentes perspectivas del mismo proceso de degradación.

FFT y frecuencias de defecto de rodamientos: para la monitorización de rodamientos basada en vibración, la FFT bruta no es suficiente: hay que saber qué buscar. Cada rodamiento de elementos rodantes tiene cuatro frecuencias de defecto características, derivadas de la geometría del rodamiento y la velocidad del eje:

BPFO (Ball Pass Frequency Outer) = (N/2) × RPM × (1 - d/D × cos(α)) — defecto en pista exterior
BPFI (Ball Pass Frequency Inner) = (N/2) × RPM × (1 + d/D × cos(α)) — defecto en pista interior
BSF (Ball Spin Frequency) = (D/2d) × RPM × (1 - (d/D × cos(α))²) — defecto en el elemento rodante
FTF (Fundamental Train Frequency) = RPM/2 × (1 - d/D × cos(α)) — defecto en la jaula

Donde N = número de elementos rodantes, d = diámetro de la bola, D = diámetro primitivo, α = ángulo de contacto. El procesador de flujos calcula la FFT sobre las formas de onda brutas de vibración y extrae la amplitud en estas frecuencias específicas (más los armónicos de 2.º y 3.º orden). Una amplitud creciente en BPFO con armónicos es un defecto clásico de pista exterior: el tipo de patrón invisible en el RMS del dominio temporal pero inconfundible en el dominio de la frecuencia.

La elección del tamaño de ventana importa más de lo que la mayoría de los equipos reconoce. Una ventana de 60 segundos captura transitorios rápidos (arranque del motor, cambios de carga). Una ventana de 30 minutos los suaviza y revela tendencias lentas. Usar un solo tamaño de ventana obliga al modelo a aprender tanto la dinámica rápida como la lenta a partir de una única representación; proporcionar ambas le da la resolución temporal para distinguir "el motor acaba de arrancar" de "este rodamiento está empeorando".

Capa 4: Almacenamiento

Los datos procesados llegan a una base de datos de series temporales (TimescaleDB) optimizada para:

Hypertables — Particionado automático por tiempo para consultas rápidas por rango
Continuous aggregates — Rollups precalculados (1 min, 5 min, 1 h) para el rendimiento del panel de control
Políticas de retención — Datos calientes (90 días) en PostgreSQL; datos fríos exportados a almacenamiento columnar para análisis a largo plazo

La multitenencia se aplica a nivel de base de datos mediante seguridad a nivel de fila (RLS). Cada consulta, ya sea desde la API, un panel de control o un servicio interno, queda automáticamente circunscrita al tenant autenticado. No se trata de un filtrado a nivel de aplicación que un bug pueda eludir; es una restricción a nivel de base de datos que hace físicamente imposible el acceso a datos entre tenants sin credenciales de superusuario.

Capa 5: Inferencia ML

Tres tipos de modelos por activo:

Detección de anomalías

Un autoencoder LSTM aprende el patrón de operación normal de cada activo. Un error de reconstrucción elevado indica que el comportamiento actual no coincide con los patrones aprendidos. El modelo procesa una ventana deslizante de datos multivariados de sensores (normalmente 60 pasos temporales) y genera un score de error de reconstrucción. Cuando este score supera un umbral aprendido (calibrado por activo a partir de datos operativos sanos), se marca una anomalía.

Vida útil restante (RUL)

Los modelos LSTM estiman los días hasta el próximo evento de mantenimiento. Un LSTM que procesa 14 entradas brutas de sensores alcanzó un RMSE de 11,48 días en el benchmark NASA C-MAPSS, lo que significa que las predicciones son típicamente precisas dentro de 11 días. Para la planificación práctica del mantenimiento, esa es la diferencia entre "programárlo esta semana" y "programárlo este mes".

Diagnóstico de fallos

Una CNN-1D con atención clasifica las formas de onda de vibración en categorías de fallo: pista interior, pista exterior, defecto en el elemento rodante, defecto en la jaula, desalineación, desequilibrio. Preentrenada en el conjunto de datos de rodamientos CWRU y ajustada con datos específicos de la planta.

Requisitos de datos de entrenamiento y expectativas de precisión

El rendimiento del modelo depende en gran medida del volumen de datos:

| Volumen de datos | Mejor modelo | Precisión esperada | |---|---|---| | < 1 000 muestras | Isolation Forest | Detecta anomalías graves, sin RUL | | 1 000 - 50 000 | LSTM Autoencoder | Buena detección de anomalías, RUL básico | | 50 000 - 200 000 | LSTM + LightGBM | Sólidas predicciones de anomalías + RUL | | > 200 000 + GPU | TranAD (Transformer) | Anomalías + RUL de última generación |

Para un nuevo despliegue sin datos históricos, los modelos preentrenados (entrenados en el conjunto de rodamientos CWRU y en los datos de turbofan NASA C-MAPSS) proporcionan capacidad de línea base inmediata. No son perfectos para su equipo específico, pero codifican física de degradación general que se transfiere sorprendentemente bien entre clases de equipos similares.

Capa 6: Motor de alertas

El motor de alertas aplica reglas de negocio:

Mapeo de severidad — Los umbrales de score de anomalía se asignan a niveles de severidad. Un score 2× por encima del umbral es AVISO; 4× es CRÍTICO. Estos multiplicadores son configurables por clase de activo, porque una anomalía "crítica" en una bomba de respaldo tiene implicaciones operativas distintas a las del mismo score en un compresor de punto único de fallo.
Deduplicación — Un rodamiento en degradación genera scores de anomalía continuos por encima del umbral. Sin deduplicación, recibiría una alerta en cada ciclo de inferencia (normalmente cada 30-60 segundos). El motor de alertas agrupa las anomalías relacionadas por activo y modo de fallo, enviando una única alerta con actualizaciones en lugar de una avalancha de notificaciones repetitivas.
Escalado — ¿Un AVISO no reconocido en una ventana configurable (por defecto: 4 horas)? Escala a CRÍTICO y notifica al siguiente nivel. ¿CRÍTICO no reconocido en 1 hora? Se avisa al responsable de guardia.
Atribución de características — Cada alerta muestra qué sensores contribuyeron y en qué medida. Esto no es opcional ni una función premium: es la diferencia entre una alerta que se investiga y una que se descarta.

Patrones de integración

Las alertas deben llegar a las personas allí donde trabajan. El motor de alertas admite varios canales de entrega simultáneamente:

PagerDuty / OpsGenie — para la rotación de guardia y el escalado
ServiceNow / SAP PM / Maximo — órdenes de trabajo creadas automáticamente con contexto de diagnóstico
Webhooks — para integraciones personalizadas con sistemas internos
Correo electrónico / SMS — para equipos que no utilizan plataformas de gestión de incidentes
Notificaciones push en móvil — para operarios en planta

El problema del arranque en frío

La pregunta más frecuente en nuevos despliegues PdM: "¿Qué ocurre el primer día sin datos?"

Aquí es donde la mayoría de los proyectos PdM internos se detienen. Entrenar un autoencoder LSTM desde cero requiere semanas de datos operativos limpios. Entrenar un modelo RUL requiere datos históricos de fallos, que puede que no se tengan en formato estructurado.

Una plataforma moderna aborda el arranque en frío en tres fases:

Días 1-7: Modelos preentrenados. Los modelos entrenados en conjuntos de datos de referencia públicos (rodamientos CWRU, motores turbofan NASA C-MAPSS) y en datos anónimizados entre clientes ofrecen detección de anomalías inmediata. No capturarán modos de fallo específicos del equipo, pero sí los patrones de degradación comunes (desgaste de rodamientos, desequilibrio, desbordamiento térmico) que representan el 60-70 % de los fallos en equipos rotativos.

Semanas 2-4: Aprendizaje de línea base. Con 2-4 semanas de datos continuos, la plataforma entrena modelos específicos para cada activo. El autoencoder LSTM aprende cómo es el "estado normal" de cada máquina bajo sus condiciones operativas específicas. La precisión de la detección de anomalías mejora significativamente porque el modelo ya sabe que la Bomba 7A a 1 800 RPM vibra normalmente a 1,8 mm/s, no solo que "las bombas vibran entre 0 y 10 mm/s".

Mes 2 en adelante: ML progresivo. A medida que los datos se acumulan, la plataforma actualiza los modelos automáticamente: Isolation Forest → LSTM Autoencoder → TranAD (basado en Transformer). Cada actualización mejora tanto la sensibilidad de detección como el tiempo de anticipación. La transición es automática: la plataforma realiza un seguimiento de las métricas de rendimiento de cada modelo y promueve el mejor cuando se demuestra en datos de validación retenidos.

Capa 7: Acción

Las alertas desencadenan: notificaciones PagerDuty/ServiceNow, órdenes de trabajo creadas automáticamente, webhooks para integraciones personalizadas y visualización en el panel de control en tiempo real. La capa final cierra el ciclo: fallo predicho → alerta → investigación → orden de trabajo → reparación → confirmación. Cada paso queda registrado, creando la pista de auditoría que retroalimenta el reentrenamiento del modelo y la medición del ROI.

Prevly gestiona las siete capas como plataforma administrada. Vea cómo funciona con una demo interactiva que utiliza modelos ML reales.

Lecturas relacionadas: La predicción de RUL explicada · Monitorización OPC-UA de solo lectura · Cómo empezar con el análisis de vibraciones