Mantenimiento predictivo sin historial — bootstrap desde el primer minuto

Augury necesita 3 a 6 meses de datos antes de que su IA sirva. Tractian instala su sensor propio y empieza a aprender. Rela arranca desde el primer minuto sobre tus PLCs existentes — bootstrap automático con técnicas que combinan reglas físicas más ML adaptativo.

Para una PYME alimentaria que acaba de comprar una extrusora, una empacadora o un compresor nuevo, el "primer mes ciego" del mantenimiento predictivo tradicional es un lujo que no existe. Rela cierra ese hueco leyendo directamente el PLC del fabricante y aplicando reglas físicas pre-cargadas mientras el ML adaptativo construye la línea base real en silencio. Severidad canónica info, warning, high, critical desde el primer evento. Sin instalar sensores propios. Sin firmar acuerdos OEM.

Resumen ejecutivo

El problema cold-start del mantenimiento predictivo

Cuando Augury, Tractian, Senseye o cualquier vendor de mantenimiento predictivo "tradicional" llega a una planta nueva, su modelo arranca desconociendo qué es lo "normal" para ese equipo concreto. Necesita acumular semanas de telemetría para distinguir un pico legítimo de un transitorio inocuo de una operación segura, una vibración estructural normal de una incipiente falla de rodamiento, una corriente alta correspondiente a producción intensa de una sobrecarga peligrosa.

Las consecuencias prácticas para una PYME alimentaria:

• Compraste la extrusora hace dos semanas. El proveedor la entregó, tu equipo la puso en marcha. Pero el "modelo predictivo" del vendor clásico todavía no detecta nada porque no tiene baseline. Si se rompe el husillo en el día 45, el sistema reportará un cambio de patrón sin contexto. Pérdida de oportunidad pura.
• Sustituiste el motor de la bomba centrífuga. Mismo activo, mismo ID en el CMMS, pero mecánicamente es otro. El modelo entrenado sobre el motor anterior queda obsoleto y debe re-aprender. Tres meses sin protección efectiva.
• Reconfiguraste la línea de empaque. Cambió el setpoint, cambió el SKU dominante, cambiaron las firmas eléctricas. El modelo histórico ya no aplica.

En grandes corporaciones estos baches se absorben con holgura. En una PYME alimentaria que opera en márgenes del 4 al 8 por ciento, un mes ciego es la diferencia entre rentabilidad y pérdida operativa.

¿Qué es bootstrap sin historial?

Bootstrap sin historial es la capacidad de emitir alertas con severidad canónica útil desde el primer evento, sin haber acumulado meses de telemetría. En Rela esto se logra con cuatro componentes diseñados para coexistir y refinarse mutuamente.

• Reglas físicas pre-cargadas por tipo de equipo. Para extrusoras, bombas centrífugas, compresores tornillo, motores trifásicos, cintas transportadoras, hornos, túneles de frío y pasteurizadores, Rela carga rangos físicos obtenidos de hojas de datos de fabricantes y normas ISO. Ejemplos: torque normal de extrusora entre el 60 y el 85 por ciento del nominal; vibración admisible de bomba ISO 10816 clase II inferior a 4,5 mm/s RMS; corriente máxima del motor según placa NEMA o IEC.
• Detección por thresholds del fabricante. Las primeras horas se monitorean contra límites declarados en el manual o en el dataset cargado. Si la temperatura del rodamiento del compresor supera los 80°C, severidad warning; si supera los 95°C, severidad critical. No hace falta esperar baseline para saber que esos valores son anómalos.
• ML adaptativo desde día 1. En paralelo, los detectores estadísticos (z-score robusto, Page-Hinkley para drift, ensemble de anomaly detection) reciben datos en streaming y construyen distribuciones empíricas. El peso de las reglas físicas arranca alto y conforme acumulan ~30 días de operación normal, el sistema desplaza progresivamente el peso hacia el modelo aprendido.
• Severidad canónica desde el primer evento. Cada alerta nace con severidad info, warning, high o critical según el cruce con regla física o threshold de fabricante. El inbox unificado del operador es útil desde el primer turno.

La transición entre reglas físicas y modelo aprendido es continua, sin saltos ni reinicios. El operador no nota cuándo el modelo "tomó el control"; solo nota que las alertas se vuelven cada vez más precisas.

Cómo funciona

flowchart LR
  PLC[PLC equipo nuevo] -->|Modbus / OPC UA / MQTT| VPN[Tunel VPN]
  VPN --> Bootstrap[Reglas fisicas + thresholds fabricante]
  Bootstrap -->|Dia 1| Severity[Severidad canonica info warning high critical]
  Bootstrap -->|Dia 1 a 30| Learn[ML adaptativo aprende patron real]
  Learn --> Refined[Modelo refinado por activo]
  Severity --> Alerts[Alert aggregator e inbox unificado]
  Refined --> Alerts
  Alerts --> WA[Notificacion WhatsApp y email]

Recorrido del flujo:

1. PLC del equipo nuevo. Rela lee directamente las variables que el fabricante ya expone: torque, RPM, temperatura de rodamientos, corriente, presión de descarga, vibración (si el variador la calcula), caudal, par motor.
2. Túnel VPN. WireGuard hacia el cloud Rela. Sin abrir puertos entrantes en la planta.
3. Reglas físicas y thresholds. El motor de detección consulta el catálogo asociado al asset_class del equipo (extruder, centrifugal_pump, screw_compressor, etc.) y los límites del fabricante cargados en _assets.specs. Cualquier cruce dispara un evento con severidad canónica.
4. ML adaptativo en paralelo. Los detectores estadísticos consumen el mismo stream y construyen progresivamente histogramas, medias móviles robustas y modelos de cambio de régimen.
5. Modelo refinado por activo. Conforme se acumula operación normal, el modelo se especializa. Las alertas se vuelven específicas: en lugar de "torque alto", "torque alto cuando el SKU es masa madre y la temperatura ambiente supera los 26°C, fuera del rango aprendido".
6. Alert aggregator. Las alertas pasan por el aggregator que deduplica, correlaciona síntomas y eleva severidad cuando varios detectores convergen.
7. WhatsApp y email. El responsable recibe la alerta con contexto operativo, no un código de error.

Casos cubiertos por bootstrap

Cada caso se documenta en el activo con bootstrap_started_at, bootstrap_strategy y physical_rules_active en la colección _assets. La auditoría queda explícita: cuando el modelo era "joven", las alertas vienen marcadas con confidence: bootstrap; cuando madura, con confidence: learned.

Comparativa: cómo se compara con Augury y Tractian

La diferencia clave no es solo el bootstrap; es que Rela parte de un supuesto distinto: la planta ya tiene PLCs con variables relevantes. La inversión va a software y conectividad, no a multiplicar sensores físicos.

ISO 13374 condition monitoring sobre PLCs existentes

ISO 13374 define las cinco capas del condition monitoring industrial: Data Acquisition (DA), Data Manipulation (DM), State Detection (SD), Health Assessment (HA) y Prognosis Assessment (PA). Tradicionalmente, cada capa requiere instrumentación dedicada — sensores de vibración inalámbricos, gateways propietarios, software de análisis vibracional.

Rela implementa las cinco capas leyendo lo que el PLC ya entrega:

• DA — Data Acquisition. El listener Modbus, OPC UA o MQTT trae cada variable a la frecuencia que el PLC publica. Frecuencias típicas: 1 Hz para temperatura, 10 Hz para corriente, 50 a 100 Hz para vibración cuando el variador la calcula. Cuando una variable no está disponible, Rela lo declara explícitamente; nunca inventa data.
• DM — Data Manipulation. Filtros pasa-bajos, RMS de ventana móvil, FFT cuando el variador entrega espectros. Todo en streaming.
• SD — State Detection. Cruce con reglas físicas y thresholds de fabricante en bootstrap; cruce con modelo aprendido cuando el activo madura. Severidad canónica info, warning, high, critical.
• HA — Health Assessment. El AHI con sus cinco sub-índices (condition, alarm_health, maintenance_compliance, trend_stability, anomaly_pressure). Grados A, B, C, D, F.
• PA — Prognosis Assessment. RUL con intervalo de confianza explícito. En bootstrap el intervalo es amplio; conforme aprende, se estrecha.

Promesa técnica honesta: cuando el PLC no entrega vibración (motor sin variador moderno), Rela declara la limitación en el AHI con coverage: partial en lugar de inventar el dato. La transparencia es parte del producto.

Asset Health Index (AHI) y RUL desde día 1

El AHI con cinco sub-índices empieza a calcular desde el primer evento ingresado:

• condition — basado en cruces de threshold y vibración / temperatura / corriente.
• alarm_health — frecuencia y severidad de alarmas históricas del PLC.
• maintenance_compliance — cumplimiento de planes preventivos en el CMMS.
• trend_stability — derivada de la tendencia de la métrica clave (Page-Hinkley).
• anomaly_pressure — densidad de eventos del ensemble de anomaly detection.

Durante el bootstrap, los sub-índices que dependen de modelo aprendido (anomaly_pressure, trend_stability) arrancan en valores neutros y se etiquetan como confidence: bootstrap. Los sub-índices que dependen de reglas físicas o del CMMS son completamente útiles desde el día 1.

El RUL se publica con intervalo de confianza explícito. Para una extrusora recién instalada, un RUL típico día 1 podría ser "12 a 36 meses con confianza del 70 por ciento". Día 60, ese intervalo se estrecha a "18 a 24 meses con confianza del 90 por ciento". El operador siempre ve la incertidumbre.

Caso de uso documentado

• Bootstrap PdM en extrusora primer mes

Otros casos de mantenimiento

• Detección de fallas en bomba centrífuga
• Drift detection en compresor
• Inbox unificado de alertas

Cómo desplegar bootstrap PdM en un equipo nuevo

Pasos del despliegue desde el momento en que el equipo llega a la planta hasta el primer reporte AHI accionable:

1. Día 0 — Conectar VPN. Edge Gateway o router industrial con WireGuard hacia Rela cloud. Inversión hardware típica: menos de 250 euros para una Raspberry Pi 4 industrial.
2. Día 1 — Registrar el activo. Crear _assets con asset_class correcto (extruder, centrifugal_pump, etc.). El sistema carga automáticamente las reglas físicas asociadas. Si el operador conoce los thresholds del fabricante, los carga en _assets.specs; si no, Rela usa los defaults de la clase.
3. Día 1 — Crear _machine_event_sources. Una fuente Modbus, OPC UA o MQTT por activo. Rela arranca la suscripción y el sensor watchdog confirma frecuencia de lectura esperada.
4. Día 1 — Activar bootstrap. Por defecto, el activo nuevo nace con bootstrap_strategy: physical_rules. Las primeras alertas usan severidad canónica calculada con reglas físicas y thresholds de fabricante.
5. Día 1 a 7 — Validar fuentes. El operador (o el responsable de la implementación) revisa el inbox unificado para detectar reglas mal cargadas o transitorios benignos que están generando ruido. Ajustes de grace period o de banda en pocos clicks.
6. Día 7 a 30 — Aprendizaje silencioso. El ML adaptativo construye baseline empírico. Las alertas siguen llegando con severidad canónica, pero internamente el sistema marca confidence creciente.
7. Día 30 a 45 — Transición a modelo aprendido. El detector empieza a usar la distribución empírica como referencia primaria; las reglas físicas pasan a ser un guardrail de seguridad. Las alertas se vuelven específicas al activo.
8. Día 30 a 60 — Primer reporte AHI maduro. El AHI con los cinco sub-índices se publica con confidence: learned para los sub-índices estadísticos. El RUL estrecha el intervalo de confianza.

Total: del día 0 al primer reporte AHI maduro, 60 días en condiciones típicas. Pero las primeras alertas accionables empiezan el día 1 — ahí está el valor.

Beneficios clave

• 1 día hasta la primera detección útil vs 90 a 180 de Augury o Tractian.
• 0 sensores propios instalados. Rela lee variables ya disponibles en el PLC del fabricante. Inversión en hardware: solo el Edge Gateway (~250 euros).
• Severidad canónica info, warning, high, critical desde el primer evento. El inbox unificado es útil desde el primer turno.
• Falsos positivos en bootstrap por debajo del 8 por ciento en clientes piloto food, gracias a la combinación reglas físicas + grace periods configurables + filtro de transitorios.
• Ahorro 60 a 120 horas-técnico comparado con cold-start de Augury o Tractian, donde el primer trimestre se gasta calibrando el modelo manualmente.
• Modelo refinado en 30 a 45 días. Sin reinicios, sin cutoff brusco; transición continua de regla física a modelo aprendido.
• AHI completo desde el día 1 con sub-índices marcados como confidence: bootstrap cuando aplica, evolucionando a confidence: learned.
• RUL con intervalo de confianza explícito. Nunca un número solo; siempre rango con incertidumbre cuantificada.
• Mismo asset graph que HACCP, cadena de frío y OEE. Cuando una falla mecánica también es una desviación HACCP (ej. fallo de compresor del freezer), una sola alerta unificada en lugar de tres equipos descubriéndolo por separado.
• ROI típico 4 a 8 meses. Cada falla evitada en una extrusora alimentaria paga entre 6 y 18 meses del plan Rela según el cliente.