Predictive maintenance alerts

Predictive maintenance alerts traslada el mantenimiento de equipos del modo reactivo («se rompe, lo reparamos») al proactivo. La automatización analiza continuamente la telemetría, detecta señales tempranas de desgaste y avisa al equipo antes del fallo. El objetivo es eliminar los tiempos de inactividad no planificados y pasar de las reparaciones urgentes a las programadas.

El proceso paso a paso:

1. Recopilación de telemetría. Los datos de los sensores (vibración, temperatura, presión, consumo energético) y de los registros del equipo llegan al stack de observabilidad: Prometheus, InfluxDB o el SCADA/MES sectorial.
2. Normalización y almacenamiento. Las métricas se unifican en un formato común, se agregan en series temporales y se almacenan con una retención de 6-24 meses para el entrenamiento de modelos.
3. Modelo baseline. Para cada unidad de equipo se construye un perfil estadístico del funcionamiento normal: rangos de métricas, estacionalidad, correlaciones entre parámetros.
4. Detector de anomalías. Los modelos ML (Isolation Forest, LSTM-autoencoder o reglas rule-based) comparan las lecturas actuales con el baseline y calculan el anomaly score.
5. Clasificación por niveles. Las alertas se clasifican por gravedad: watch (observar), warning (programar una inspección), critical (detener y revisar ahora).
6. Notificación al equipo. La alerta se envía a Slack, email o SMS con contexto: qué nodo, qué métrica se desvió, recomendación de acción, pronóstico del tiempo hasta el fallo.
7. Cierre del bucle. El ingeniero confirma la causa (true positive / false positive / planned maintenance), y los datos se devuelven al modelo para su reentrenamiento.
8. Repuestos y planificación. Con las alertas warning, el sistema crea automáticamente una solicitud de repuesto en el ERP y una tarea en el calendario maintenance.

Lo que la automatización NO hace:

• No reemplaza al ingeniero de diagnóstico. La alerta es una señal de «mira aquí», no un diagnóstico listo de la causa del fallo. La causa raíz la determina una persona.
• No funciona sin historial de fallos. Se necesitan mínimo 3-6 meses de datos de funcionamiento normal y varios fallos documentados para que el modelo distinga el ruido de las anomalías reales.
• No cubre equipos sin sensores. Si la prensa no tiene sensor de vibración, el predictive maintenance por vibración es imposible: primero se requerirá el equipamiento IoT adicional como proyecto separado.

El flujo técnico de datos se divide en tres niveles: ingest (recopilación), analytics (modelos) y delivery (alertas). Cada nivel se resuelve con un conjunto separado de herramientas y se implementa en custom-code, porque no existen soluciones end-to-end listas para un parque de equipos específico.

Nivel ingest. Las fuentes son PLC, SCADA, sensores IoT individuales, registros de software industrial. Los datos se obtienen a través de OPC UA, MQTT, Modbus o la API del fabricante del equipo. El colector (Telegraf, Node-RED, custom Python) normaliza el formato y escribe en una base time-series (Prometheus, InfluxDB, TimescaleDB).

Nivel analytics. Aquí se aplican modelos de tres tipos:

1. Threshold-based rules. Reglas simples «si la vibración > X durante Y minutos, alert». Funcionan de inmediato, sin entrenamiento, pero generan muchas falsas alarmas.
2. Modelos estadísticos. Z-score, EWMA, ARIMA sobre series temporales. Detectan desviaciones del baseline estacional sin un stack de ML pesado.
3. Modelos ML. Isolation Forest para anomaly detection, LSTM-autoencoder para señales multidimensionales, XGBoost para la clasificación de tipos de fallo. Se entrenan con datos históricos y requieren un pipeline de reentrenamiento.

Las salidas de los modelos son anomaly score y la estimación de la probabilidad de fallo en el horizonte (24 horas, 7 días, 30 días).

Nivel delivery. El alert router (Alertmanager, custom-code o motor de workflow) filtra duplicados, aplica reglas de escalación y envía notificaciones a Slack/Teams, email, SMS o llamada de voz para critical.

Ejemplo de componentes:

Etapas de implantación:

1. Discovery (1-2 semanas). Inventario del equipo, fuentes de datos, historial de fallos. Formulación de hipótesis sobre las señales predictoras para los nodos clave.
2. Data pipeline (2-3 semanas). Conexión de fuentes, configuración de colectores, carga de datos históricos (backfill) de 6-12 meses.
3. Baseline y modelos (2-3 semanas). Análisis exploratorio, elección de la arquitectura de modelos, entrenamiento con datos históricos, validación en el conjunto reservado.
4. Alert logic (1-2 semanas). Configuración de tiers, reglas de deduplicación, plantillas de notificación, cadenas de escalación.
5. Pilot (2-4 semanas). Lanzamiento en 3-5 unidades de equipo. Los ingenieros evalúan cada alerta, la precision del modelo se ajusta hasta los valores que el equipo considera aceptables para el critical-tier.
6. Rollout (2-4 semanas). Extensión a todo el parque, formación del equipo, documentación de runbooks para alertas típicas.

El bucle de retroalimentación es crítico: cada alerta cerrada se etiqueta como true positive, false positive o planned maintenance. Estas etiquetas se destinan al reentrenamiento de los modelos cada 1-3 meses. Sin este bucle, la exactitud se degrada: el nuevo equipo, los cambios de régimen y las fluctuaciones estacionales desestabilizan el baseline.

Para lanzar el mantenimiento predictivo se necesitan tres grupos de requisitos: datos, accesos, equipo. Sin cualquiera de ellos, el proyecto se alarga o choca con el techo de precisión.

Datos y equipamiento:

• Sensores en nodos críticos: vibración, temperatura, presión, corriente. Si no hay sensores, el primer paso es la ampliación IoT (presupuesto y plazos separados).
• Datos históricos de mínimo 3-6 meses, mejor 12+ meses.
• Registro de fallos del período equivalente con anotaciones: tipo de fallo, tiempo, costes de reparación.
• Fichas técnicas del equipamiento: rangos normativos de métricas, reglamentos de mantenimiento.

Accesos e integraciones:

• Acceso a PLC/SCADA/MES mediante OPC UA, Modbus, MQTT o API del fabricante.
• Espacio para la base time-series: servidor on-premise o nube (Prometheus, InfluxDB Cloud, AWS Timestream).
• Canales de notificaciones con posibilidad de crear un bot o webhook: Slack, Teams, Twilio para SMS.
• ERP o sistema de mantenimiento con API, si se necesita una solicitud automática de repuestos.

Equipo y procesos:

• Ingeniero jefe o maintenance lead: dueño de la lógica de negocio de alertas y clasificación por niveles.
• Ingeniero OT/IoT: para la conexión del equipamiento y el trabajo con protocolos industriales.
• Data engineer o ingeniero ML: para el pipeline de datos y los modelos.
• Acuerdo sobre el SLA de respuesta a alertas: quién recibe warning, quién critical, en qué horario.

Cronograma: 6-10 semanas para un lanzamiento completo con sensores e historial disponibles. Si se parte de la ampliación IoT, añade 4-8 semanas. El piloto en 3-5 unidades de equipamiento cabe en 4-6 semanas y aporta datos para la decisión de escalado.