Machine Learning industrial no es entrenar un modelo en Jupyter y declarar victoria. Es un pipeline que va del tag OPC UA del PLC hasta una alarma en el SCADA del operador, pasando por feature engineering con conocimiento de proceso, entrenamiento con datos reales (sucios, con huecos, con cambios de turno), y deploy en un runtime que no se cae cuando el historian se llena.
ML industrial vs ML académico: lo que cambia
En la universidad, ML es: descargar dataset limpio, entrenar modelo, reportar accuracy, publicar paper. En planta, ML es:
- Datos sucios: tags con huecos (el PLC se reinició), timestamps desalineados entre sensores, cambios de escala por recalibración, valores atípicos por mantenimiento (no por falla).
- Cambio de contexto: el modelo entrenado con datos de verano pierde accuracy en invierno. El producto cambió de formulación. Pusieron un motor nuevo.
- Feature engineering con dominio: un ingeniero de proceso sabe que la relación presión/temperatura en un compresor es más informativa que cada variable por separado. Ese conocimiento vale más que probar 500 hiperparámetros.
- Deploy real: el modelo tiene que correr cada 5 segundos, no fallar cuando el historian está en backup, y generar una alarma que el operador entienda — no un número de 0.0 a 1.0.
El 80% del trabajo en ML industrial es ingeniería de datos y de proceso. El modelo en sí es el 20% restante.
Mantenimiento predictivo: predecir la falla antes de que ocurra
El mantenimiento predictivo (PdM) usa modelos de ML para estimar la probabilidad de falla de un activo en un horizonte de tiempo, basándose en datos de condición (vibración, temperatura, corriente, presión, flujo).
Tipos de modelos según el caso
| Enfoque | Modelo típico | Cuándo usarlo | Datos necesarios |
|---|---|---|---|
| Clasificación de estado | XGBoost, Random Forest | Cuando hay histórico de fallas etiquetadas | Features + etiquetas (bueno/degradado/falla) |
| Remaining Useful Life (RUL) | LSTM, Survival Analysis | Cuando importa cuánto tiempo queda | Series de tiempo hasta la falla (run-to-failure) |
| Detección de degradación | Autoencoder, Isolation Forest | Cuando NO hay histórico de fallas (lo normal) | Solo datos de operación normal |
Caso típico: motor eléctrico de 15 kW
Un motor que acciona una bomba centrífuga. Sensores disponibles: vibración triaxial (acelerómetro en rodamiento), temperatura de carcasa (RTD), corriente de alimentación (CT en tablero), flujo de salida (caudalímetro magnético).
- Features: RMS vibración X/Y/Z, kurtosis de vibración, corriente RMS, ratio flujo/corriente (eficiencia aproximada), temperatura delta vs ambiente, horas de operación desde último mantenimiento.
- Modelo: XGBoost entrenado con 6 meses de datos normales + 3 eventos de degradación conocidos.
- Resultado: score de salud 0–100 cada 5 minutos. Si baja de 60, alarma amarilla en SCADA. Si baja de 30, alarma roja + sugerencia de intervención.
- Impacto medido: 48 horas de aviso antes de falla de rodamiento. Evitó 1 paro no programado de 8 horas ($180,000 MXN en producción perdida).
El modelo más sofisticado no sirve si las features son malas. Feature engineering con conocimiento de proceso — saber que kurtosis de vibración sube antes que RMS en fallas de rodamiento — vale más que cualquier técnica de deep learning.
Detección de anomalías: encontrar lo que no sabías que buscabas
La detección de anomalías encuentra comportamientos inusuales sin necesidad de definir de antemano qué es una falla. Es especialmente valiosa cuando:
- No hay histórico de fallas etiquetadas (la mayoría de los casos).
- Las fallas posibles son muchas y variadas (no se pueden enumerar todas).
- Se busca detectar degradación lenta que no dispara alarmas convencionales.
Enfoques que funcionan en planta
1. Autoencoder (unsupervised): entrena solo con datos normales. Aprende a reconstruir el comportamiento normal. Cuando el error de reconstrucción sube, algo cambió. Funciona bien con 5–20 variables correlacionadas (presión + temperatura + flujo de un mismo equipo).
2. Isolation Forest: algoritmo basado en árboles que aísla puntos anómalos. Rápido, interpretable, bueno para datos tabulares. No requiere GPU.
3. Control estadístico multivariable (Hotelling T², PCA): cuando hay pocas variables y relaciones lineales conocidas. Más simple, más robusto, fácil de explicar al ingeniero de proceso.
Pipeline típico
- Recolectar 3–6 meses de datos normales (filtrar paros planeados, mantenimientos, arranques).
- Feature engineering: calcular estadísticos rodantes (media, std, RMS, kurtosis en ventanas de 5–30 minutos).
- Entrenar modelo solo con datos normales.
- Definir umbral de anomalía basado en distribución de errores de reconstrucción (percentil 99 típico).
- Deploy: el modelo corre cada N minutos, genera score de anomalía, escribe tag en historian/SCADA.
- Alarma en SCADA cuando score supera umbral por más de M muestras consecutivas (evitar false positives por ruido).
Optimización de proceso con MPC
El Model Predictive Control (MPC) usa un modelo del proceso para calcular los setpoints óptimos en tiempo real, anticipando el comportamiento futuro del sistema.
A diferencia de un PID que reacciona al error actual, el MPC predice N pasos adelante y optimiza la trayectoria completa considerando restricciones (límites de temperatura, velocidad máxima, consumo energético).
Dónde aplica en planta
- Extrusoras: optimizar temperatura de barril, velocidad de husillo y presión de cabezal para minimizar variación de espesor.
- Reactores químicos: controlar perfil de temperatura para maximizar rendimiento y minimizar subproductos.
- Torres de enfriamiento: minimizar consumo de agua y energía manteniendo temperatura de proceso.
- Hornos industriales: optimizar perfil de calentamiento para uniformidad de producto y ahorro de gas.
Stack técnico para MPC
Herramientas: CasADi (optimización no lineal), GEKKO (Python MPC framework), MATLAB/Simulink MPC Toolbox (para integración con Siemens/Rockwell). El modelo del proceso puede ser primeros principios (ecuaciones físicas), empírico (identificación de sistema), o híbrido (física + ML para las partes no modelables).
MPC no reemplaza PID — lo complementa. Los lazos PID siguen controlando en nivel bajo (válvulas, motores). MPC genera los setpoints óptimos que los PIDs ejecutan. Es una capa de supervisión inteligente, no un reemplazo del control básico.
Pipeline de datos: del PLC al modelo y de vuelta
El pipeline completo de ML industrial tiene 5 etapas, y cada una puede fallar:
| Etapa | Qué hace | Herramientas | Falla típica |
|---|---|---|---|
| 1. Adquisición | Leer tags del PLC/SCADA | OPC UA, MQTT, Modbus TCP | Tag cambia de nombre tras actualización de programa PLC |
| 2. Almacenamiento | Historian con retención y downsampling | InfluxDB, TimescaleDB, PI System | Disco lleno → pérdida de datos recientes |
| 3. Feature engineering | Calcular features del dominio | Python, Pandas, Polars | Feature calculada con timestamp local en vez de UTC → desalineación |
| 4. Inferencia | Correr el modelo entrenado | scikit-learn, ONNX, TensorRT | Modelo entrenado con 10 features pero llegan 9 (sensor desconectado) |
| 5. Acción | Escribir resultado en SCADA/historian | OPC UA write, REST API, tag historian | Operador ignora alarma porque hay demasiadas (alarm flood) |
Cada etapa necesita monitoreo: ¿llegaron datos? ¿El modelo corrió? ¿El resultado es razonable? Un pipeline de ML sin monitoreo es una bomba de tiempo — cuando falla, nadie se entera hasta que la predicción deja de llegar y el operador no recibe la alarma.
Cómo empezar con ML en su planta
El camino más corto a un resultado útil:
- Elegir UN activo crítico con datos disponibles. No arrancar con 50 motores — arrancar con el que más duele cuando falla.
- Verificar datos: ¿hay historian? ¿Cuántos meses de datos? ¿Qué variables se registran? ¿A qué frecuencia? Si no hay datos, el primer paso es instrumentar y historizar — no ML.
- Definir la métrica de éxito: "reducir paros no programados en bomba P-201 un 50%" es medible. "Implementar IA" no lo es.
- Piloto de 6–8 semanas: exploración, modelo, integración, validación. Costo típico: $150,000 – $350,000 MXN.
- Escalar si funciona: replicar a activos similares. El 70% del trabajo del piloto se reutiliza (pipeline, features, infraestructura).
El error más caro: comprar una plataforma de ML enterprise de $500K USD antes de validar que los datos existen y que el caso de uso tiene valor. Empezar con scikit-learn y un historian que ya tiene es casi gratis.
Preguntas frecuentes
¿Cuántos datos necesito para entrenar un modelo predictivo?
Mínimo 3–6 meses de datos de operación normal a frecuencia de muestreo razonable (1 dato/minuto para la mayoría de procesos, 1 dato/segundo para vibración). Si hay eventos de falla conocidos, al menos 2–3 para que el modelo aprenda el patrón. Sin eventos de falla: usar detección de anomalías (no supervisado).
¿El ML reemplaza al mantenimiento preventivo?
No lo reemplaza — lo complementa. El mantenimiento preventivo (calendario) sigue siendo necesario para tareas que no se pueden predecir (lubricación, inspección visual, limpieza). El ML agrega la capacidad de detectar degradación que el calendario no cubre y de priorizar intervenciones según condición real del activo.
¿Puedo usar ML sin un historian / SCADA?
Es posible pero difícil. Sin historian no hay datos históricos para entrenar. Sin SCADA no hay donde mostrar resultados al operador. El primer paso antes de ML es tener datos historializados — al menos los tags críticos del activo target — y una pantalla donde el operador vea la predicción.
¿Qué precisión se puede esperar de un modelo predictivo?
Depende del caso. Para mantenimiento predictivo de motores con buena instrumentación (vibración + corriente + temperatura): precision >85% y recall >75% es alcanzable. Para detección de anomalías: la métrica relevante es el ratio de falsos positivos vs verdaderos positivos. Un modelo útil tiene <5% de falsas alarmas. Siempre validar contra el baseline (¿cuántos paros no programados había antes vs después?).
¿Cuánto cuesta mantener un modelo de ML en producción?
Un modelo en producción necesita monitoreo de drift (¿el modelo sigue siendo preciso?), reentrenamiento periódico (típicamente cada 3–6 meses o cuando cambia el proceso), y soporte de infraestructura (historian, servidor de inferencia). Costo típico de mantenimiento anual: 15–25% de la inversión inicial del piloto. Es un compromiso continuo, no un proyecto puntual.