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) — 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 implementació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, capacitació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ñada 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.