Mantenimiento predictivo industrial: de la vibración al RUL

El mantenimiento predictivo industrial deja de ser una promesa de dashboard cuando la planta lo usa para decidir cuándo parar una máquina, qué repuesto comprar y a qué turno asignar la intervención. Esta guía documenta cómo Captia Technology lo construye en operaciones reales: qué señales medir, qué arquitectura sostiene el caso, qué modelos funcionan sobre datos industriales sucios y cómo medir ROI sin autoengañarse.

Por qué el predictivo industrial falla con tanta frecuencia

La mayoría de proyectos de mantenimiento predictivo no fracasan por un problema de modelo. Fracasan por tres motivos silenciosos: datos que no representan el fallo real, una promesa de negocio que nadie firmó y una integración débil con el flujo de trabajo del técnico. Cuando se corrige solo uno de los tres, el piloto brilla seis semanas y se apaga cuando cambian las condiciones de línea.

En entornos industriales, los datos siempre son escasos donde más importan: cerca del fallo. Las plantas que funcionan bien registran miles de horas de operación normal por cada hora de anomalía. Si el equipo de datos aprende solo de la clase mayoritaria, acaba construyendo un detector de rutina, no un predictor de avería. Asumir eso desde el día uno cambia qué datos se priorizan, cómo se etiquetan y qué modelos se consideran válidos.

Hay un cuarto motivo que se descubre tarde: el desequilibrio entre lo que cuesta un falso positivo y lo que cuesta un falso negativo. Una alerta injustificada consume dos horas de un técnico y algo de credibilidad. Un fallo no detectado puede costar un turno completo de producción. Ese ratio, distinto en cada activo, es el que debería fijar los umbrales de alerta. Cuando nadie lo calcula, los umbrales se ajustan a ojo y el sistema oscila entre el silencio y el ruido.

De la vibración al Remaining Useful Life

La señal más citada en mantenimiento predictivo es la vibración. Existe una tradición de décadas (ISO 10816, ISO 20816) que traduce amplitud de vibración a estado mecánico. Esa tradición es el punto de partida, no la llegada. Un programa moderno combina vibración con otras familias de señal para estabilizar la decisión:

• Vibración: aceleración en banda ancha más envolvente para capturar rodamientos; FFT sincronizada con rpm para detectar desalineamiento, desbalance y holguras.
• Temperatura: infrarroja sobre carcasa y termopares en aceite; útil para correlacionar carga térmica con fricción y pérdida de lubricación.
• Corriente del motor (MCSA): detecta asimetrías, barras rotas y problemas en cojinetes sin instrumentación mecánica adicional.
• Acústica ultrasónica: fugas de aire comprimido, cavitación en bombas, descargas parciales en cuadros eléctricos.
• Calidad del producto: desviaciones en dimensión, peso, color o defectos visuales son muchas veces la primera señal observable de un proceso que se degrada.
• Variables de proceso: presión diferencial, caudal, consumo específico. Un filtro que se colmata o un intercambiador que se ensucia se ven antes en el proceso que en la mecánica.

La decisión final es el Remaining Useful Life (RUL): cuántas horas o ciclos le quedan al activo antes de cruzar un umbral de operación seguro. El RUL no se predice directamente con una regresión ingenua. Se construye combinando tres capas:

1. Una capa de features físicas que respetan la dinámica del equipo (armónicos de rpm, orden tracking, kurtosis del envelope, crest factor). Sin esto, el modelo aprende ruido.
2. Una capa de modelo probabilístico que devuelve una distribución sobre RUL, no un número. Los técnicos de mantenimiento operan con incertidumbre: darles un intervalo es más útil y honesto que darles un punto.
3. Una capa de decisión operativa que traduce la distribución a acción: programar revisión en el próximo paro de turno, pedir repuesto con plazo X, escalar a ingeniería cuando la cola izquierda del intervalo cruza el umbral crítico.

Entre la señal y el RUL hay un paso intermedio que conviene nombrar: el indicador de salud. Es una variable sintética entre 0 y 1 que resume la condición del activo y que degrada de forma monótona a medida que el fallo progresa. Construir un buen indicador de salud, validado con el histórico de averías de la propia planta, suele aportar más valor que cambiar de arquitectura de modelo. Y tiene una ventaja política: el jefe de mantenimiento lo entiende sin traducción.

Arquitectura de referencia en cuatro planos

Las arquitecturas que aguantan años en planta comparten una forma. El modelo mental útil es pensar en cuatro planos, cada uno con latencia y criticidad distintas.

Edge

En el edge vive el muestreo de alta frecuencia: 10-50 kHz en vibración, 1 kHz en corriente, series temporales crudas en variables de proceso. Ese plano trocea, hace pre-processing (ventanas, FFTs, RMS) y publica al siguiente plano usando protocolos industriales (OPC UA, MQTT con Sparkplug B). El edge también ejecuta modelos livianos cuando la decisión tiene que tomarse en milisegundos (parar la línea, disparar una alarma de seguridad).

Brokers y unified namespace

Todas las señales llegan a un broker MQTT con un espacio de nombres unificado. Ese espacio es el contrato: cada tópico es el mismo entre plantas, cada payload cumple un esquema versionado. Sin contrato de datos, cada nuevo activo necesita reingeniería. Con contrato, añadir una línea es configuración. Captia Connect ataca exactamente este plano.

Almacenamiento y features

El plano de datos necesita dos almacenes: uno crudo (time series sin alterar, con retención alta y coste bajo) y uno de features (agregaciones por ventana, transformaciones espectrales, etiquetas de fallo validadas por personal de mantenimiento). Los modelos siempre entrenan desde el store de features, no desde la base cruda; así las reproducciones son exactas meses después.

Modelado y servicio

El plano de modelos cubre entrenamiento, versionado, evaluación y despliegue. El principio rector es glass-box first: antes de proponer deep learning, se documenta el baseline físico. Si un baseline basado en umbrales ISO, reglas de orden y kurtosis del envelope resuelve el 70% del valor, se congela como referencia inatacable. Cualquier modelo nuevo tiene que batirlo en una métrica que importe al negocio, no solo en AUC.

Qué modelos funcionan con datos industriales reales

No hay un único modelo ganador. Hay una familia de técnicas que sobrevive al choque con la realidad:

• Detección de anomalías no supervisada (isolation forests, autoencoders, métodos basados en reconstrucción) cuando las etiquetas son escasas o inexistentes. Gran cobertura, baja precisión si no se combina con reglas físicas.
• Clasificación supervisada (gradient boosting, random forests) sobre features agregadas, para modos de fallo con histórico etiquetado. Fiable, interpretable, productizable.
• Modelos de supervivencia (Cox, AFT, DeepSurv) para estimar RUL respetando que los datos están censurados: muchos equipos se revisan antes de fallar y ese es un dato válido, no un hueco.
• Redes temporales (LSTM, temporal convolutional networks, transformers ligeros) cuando hay millones de horas de operación y el cliente acepta un modelo menos interpretable. Útil para turbinas, compresores grandes y prensas donde hay instrumentación densa.

Esta progresión, desde el baseline físico hasta las redes temporales, es la que Captia AI empaqueta como modelos avanzados de IA: el cliente no elige una técnica, elige un nivel de ambición, y la técnica se justifica contra el baseline en cada escalón. Subir de escalón solo tiene sentido cuando el anterior ya está exprimido y el dato disponible lo permite.

La regla operativa de Captia AI es sencilla: todo modelo que llegue a producción declara su ventana de validez (condiciones de operación bajo las que fue entrenado), su métrica de aceptación (por ejemplo, tasa de falsos positivos < 5% en condiciones de arranque) y el canal por el que se recupera un humano cuando hace falta. Sin esos tres elementos, ningún modelo se promueve.

De la alerta a la decisión: el diseño del canal

Un modelo excelente con un canal de alertas mal diseñado produce el mismo resultado que un modelo malo: nadie actúa. El canal merece tanto diseño como el modelo. Tres decisiones lo definen:

• Quién recibe qué. El técnico de turno necesita una instrucción accionable (revisar rodamiento lado acoplamiento de la bomba P-204 en el próximo paro). El responsable de mantenimiento necesita la tendencia semanal. Dirección necesita el agregado mensual con euros. Mandar los tres mensajes al mismo buzón mata el canal en un mes.
• Con cuánta antelación. Una alerta que llega dos horas antes del fallo sirve para mitigar; una que llega dos semanas antes permite planificar repuesto, turno y parada. El valor del predictivo está en la segunda, y eso condiciona qué features y qué horizonte de predicción se eligen.
• Con qué presupuesto de ruido. Acordar con la planta un máximo de alertas semanales por activo obliga a priorizar precisión y crea confianza. Un sistema que respeta su presupuesto de ruido durante seis meses se gana el derecho a interrumpir un turno.

Este diseño del canal, con enrutado por rol, umbrales acordados y trazabilidad de cada aviso hasta su cierre, es lo que Captia AI implanta como predicción y alertas. La pieza técnica es la misma en todas las plantas; lo que cambia es la negociación de umbrales con quien vive las consecuencias.

Todo lo anterior es metodología. Si lo que buscas es la capacidad concreta que ejecuta esto dentro de la plataforma, qué señales y qué eventos consume, qué devuelve y qué hace falta para activarla, está descrito en el módulo de mantenimiento predictivo de Captia.ai.

MLOps industrial: lo que nadie enseña en un curso

El modelo en producción es el principio, no el final. Tres rutinas separan un programa serio de uno que se apaga:

1. Monitorización de drift. Si el proceso cambia (materia prima distinta, cambio de consigna, envejecimiento del activo), las features de entrada se mueven. El sistema detecta el drift antes de que la métrica de calidad caiga y dispara reentrenamiento controlado.
2. Human-in-the-loop. Cada alerta que el técnico cierra como falso positivo, verdadero positivo o inspección rutinaria vuelve al training set. Seis meses después el modelo está mejor ajustado a esa planta que cualquier modelo genérico.
3. Gobernanza del modelo. Quién puede entrenar, quién puede promover, qué registros quedan, cómo se revierte un modelo mal comportado. Este es el trabajo invisible que separa un piloto bonito de un activo de la compañía.

Cada una de estas rutinas tiene su propia disciplina: cómo se mide el drift de datos frente al drift de concepto, cómo se fijan umbrales de confianza y cuándo conviene retirar un modelo en lugar de reentrenarlo. Lo desarrollamos en profundidad en la guía de MLOps industrial, que es la continuación natural de este pilar cuando el primer modelo ya está en producción.

ROI real: cómo se mide y cómo se audita

Un programa de predictivo se justifica por tres vectores de ahorro, en este orden de impacto:

• Coste de parada no planificada evitado: horas de producción salvadas × margen de contribución por hora. Este es el número que ejecutivos entienden y el que marketing tiende a inflar. Medir bien exige comparar tasa de paradas antes y después del programa en un activo instrumentado, manteniendo iguales el resto de variables. Si no se puede comparar, no es ROI: es storytelling.
• Coste de repuesto optimizado: menos piezas sustituidas por precaución, menos stock inmovilizado y compras mejor temporizadas. Suele ser entre el 15% y el 30% del ahorro total.
• Seguridad y calidad: reducción de incidentes de seguridad y de lotes defectuosos. Más difícil de monetizar pero, a veces, el motivo real por el que el CEO firma.

El OEE (Overall Equipment Effectiveness) es el KPI clásico. El programa debe demostrar mejora en disponibilidad y en rendimiento; la calidad mejora por la vía indirecta cuando el activo deja de operar degradado. Sin un panel que separe los tres, no hay conversación honesta con operaciones.

Ejemplo resuelto: bomba centrífuga de proceso

Un caso genérico pero completo aterriza mejor que diez principios. Tomemos una bomba centrífuga de proceso que trabaja en continuo, con motor de 75 kW y acoplamiento directo, cuyo modo de fallo dominante según la FMEA es la degradación del rodamiento del lado acoplamiento.

1. Instrumentación: dos acelerómetros (radial y axial) sobre el alojamiento del rodamiento, medida de corriente en el variador y temperatura de carcasa. Nada más. El resto de variables (caudal, presión de descarga) ya existen en el sistema de control y se recuperan por OPC UA.
2. Baseline físico: umbrales de velocidad de vibración según la clase de máquina de ISO 20816 y seguimiento de la energía en la banda de frecuencia característica del rodamiento (calculable a partir de su geometría y las rpm). Este baseline opera en sombra cuatro semanas para conocer la variabilidad normal.
3. Modelo: sobre las features espectrales agregadas por hora se entrena un clasificador supervisado con el histórico de intervenciones del GMAO como etiquetas débiles. La salida no es "fallo sí o no", sino un indicador de salud y una estimación de RUL con intervalo.
4. Decisión: si la cota inferior del RUL supera las tres semanas, no se hace nada. Si baja de tres semanas, se genera orden de trabajo en el GMAO con el repuesto reservado. Si baja de setenta y dos horas, se escala a jefe de turno para programar el paro en la próxima ventana.
5. Cierre del ciclo: tras la intervención, el técnico registra el estado real del rodamiento. Esa etiqueta, la única verdad del sistema, realimenta el modelo y ajusta los umbrales.

Lo notable del ejemplo es lo que no aparece: no hay deep learning, no hay nube obligatoria, no hay cientos de sensores. Hay una FMEA que eligió un modo de fallo, una física que definió las features y un flujo de decisión que un turno de mantenimiento puede ejecutar sin cambiar su forma de trabajar. Esa es la forma del primer caso ganador; la sofisticación llega después y sobre esta base.

Errores comunes que matan programas de PdM

• Instalar sensores antes de acordar modos de fallo. Sin una FMEA (Failure Mode and Effects Analysis) priorizada, se acaba con una orgía de datos y ninguna hipótesis.
• No guardar datos crudos. Si solo se almacenan agregados, el modelo de mañana no puede recomputar features.
• Confundir alerta con recomendación. Un sistema que genera 40 alertas/día es un sistema roto. La métrica clave es precisión en condiciones reales de planta.
• Ignorar el flujo de trabajo del técnico. Si la alerta no llega al GMAO/CMMS que ya usa el equipo, nadie la lee.
• No planificar el relevo. Un programa depende de un experto: cuando se va, muere. Documentar, automatizar y entrenar al segundo anillo es obligatorio desde el primer mes.
• Validar el modelo con particiones aleatorias. En series temporales industriales, mezclar pasado y futuro en el test infla las métricas. La validación honesta es siempre hacia delante en el tiempo y, si hay varios activos, dejando activos completos fuera del entrenamiento.

Cómo encaja con el resto del sistema Captia

Un programa de mantenimiento predictivo no se sostiene en vacío. En la arquitectura Captia se apoya en tres unidades más:

• Captia Consulting define el alcance, identifica activos críticos, ancla el caso de negocio y lo audita cada trimestre.
• Captia Connect asegura que los datos llegan estables y gobernados: OPC UA, MQTT, unified namespace y contratos de datos versionados.
• Captia Service conecta las decisiones del modelo con el ERP (Odoo), el mantenimiento (GMAO/CMMS) y los flujos operativos reales del equipo.

La unidad que toma el protagonismo es Captia AI: el sistema que interpreta, predice y convierte el dato en una recomendación accionable. Sin el resto del sistema, el mejor modelo se queda sin manos y sin canal.

Roadmap de adopción en seis pasos

1. Semanas 1-4: diagnóstico operacional, FMEA priorizada, definición de activos piloto y métrica de éxito.
2. Semanas 5-10: instrumentación del piloto, contratos de datos, baseline físico operando en sombra.
3. Semanas 11-16: primer modelo ML batiendo el baseline, integración con CMMS, rutina de feedback del técnico.
4. Semanas 17-20: primera auditoría trimestral de impacto, ajuste de umbrales y reglas.
5. Meses 6-9: escalado a segunda línea, reutilización de features y arquitectura, formación del segundo anillo.
6. Meses 9-12: programa en régimen, KPIs mensuales, gobernanza de modelos y ciclo anual de replanificación.

Normativas y estándares a conocer

Un programa sólido se apoya en estándares reconocidos; no es cosmético, es lenguaje común con auditores, aseguradoras y proveedores. Los más relevantes para mantenimiento predictivo industrial:

• ISO 10816 / ISO 20816: clasificación de severidad de vibración por tipo de máquina y montaje. Sigue siendo la referencia para umbrales iniciales.
• ISO 13374 y ISO 17359: arquitectura de procesos de monitorización de condición (data acquisition, manipulation, detection, diagnostics, prognostics).
• ISO 55000 / ISO 55001: gestión de activos. Ubica al predictivo dentro del proceso mayor de decisión sobre el ciclo de vida del equipo.
• IEC 62443: ciberseguridad industrial. Cualquier integración OT↔IT que se dedique a llevar datos fuera de la planta tiene que cumplir los niveles de seguridad que el cliente exija.
• NIS2: la directiva europea que, para sectores esenciales, convierte en obligación parte de las prácticas que antes eran recomendación.

Plantilla de caso de ROI en doce líneas

Para discutir un caso concreto con una dirección industrial, basta una plantilla de doce líneas. Cualquier número que falte es una pista de qué hay que medir antes de seguir:

1. Activo crítico seleccionado y modo de fallo principal.
2. Tasa de parada no planificada en los últimos 24 meses.
3. Duración media de la intervención (MTTR) para ese modo de fallo.
4. Margen de contribución por hora de producción perdida.
5. Ahorro bruto anual si se evita el 40% de esas paradas.
6. Coste del programa: instrumentación, integración, modelo, soporte.
7. Horas del técnico liberadas si las alertas son precisas.
8. Reducción estimada de stock de seguridad.
9. Riesgo residual en caso de falso negativo (seguridad, calidad).
10. Margen de ROI tras payback (meses, no años).
11. Responsable interno del programa y patrocinador ejecutivo.
12. Ventana de auditoría acordada (próxima fecha, métrica a mostrar).

Preguntas frecuentes

Conclusión

El mantenimiento predictivo industrial no se resuelve comprando un sensor ni entrenando un autoencoder. Se resuelve diseñando un sistema de decisión: qué se mide, cómo se almacena, qué modelo aporta, qué técnico actúa y qué dinero se ahorra. Cuando ese sistema existe, el modelo de ML es la pieza más interesante, pero no la más frágil. En Captia Technology lo construimos combinando las cuatro unidades (Consulting, Connect, AI y Service) en un mismo plan operativo, con auditoría trimestral y KPIs que se pueden defender delante de un director industrial y de un CFO.

Si quieres discutir un caso concreto sobre tu planta, en Captia AI podemos aterrizar un diagnóstico en semanas y no en trimestres: activo piloto, modo de fallo prioritario y plantilla de ROI sobre tus números.