OEE en tiempo real: arquitectura abierta con MQTT, Andon digital y Machine Learning para PYMES

Una arquitectura abierta, replicable y de bajo costo para que cualquier planta industrial deje de calcular su OEE en planillas mensuales y empiece a operarlo hora por hora, con apoyo de modelos predictivos.

Lectura estimada: 8–10 minutos · Python Open source Orientado a PYMES

Demo en vivo · sin instalación Antes de leer, abre el sistema funcionando en tu navegador:

• ⭐ Repositorio en GitHub (código abierto · MIT) — clónalo y ejecuta el stack completo en tu computadora con un solo comando.
• Pantalla de planta (dashboard) — OEE hora a hora, semáforo por máquina, Pareto y tendencia.
• Andon móvil (tablet del operario) — tres semáforos clickeables y registro de causa con un toque.

Las dos aplicaciones detectan que no hay una base de datos conectada y muestran datos sintéticos representativos. Cuando se ejecutan en su propia infraestructura, se conectan a la planta real.

1. El problema operativo que se repite en la mayoría de las plantas

En la mayoría de las plantas industriales que he visitado, el OEE se calcula los lunes por la mañana a partir de los datos de la semana anterior. Para ese momento el problema ya generó un costo, el operario ha olvidado el detalle de la mitad de las paradas y la información ya no permite tomar decisiones correctivas oportunas.

El patrón suele ser el mismo:

• El operario registra únicamente lo que recuerda al cierre del turno.
• Las microparadas, que constituyen la mayor pérdida oculta, no quedan documentadas.
• El reporte llega cuando la oportunidad de mejora ya se perdió.

Para responder a esta situación desarrollé un sistema de código abierto, disponible en GitHub, que aborda el problema desde la captura del dato hasta la decisión en planta. A continuación presento la propuesta y su arquitectura.

2. Qué es el OEE y por qué es relevante

El OEE (Overall Equipment Effectiveness) es el indicador estándar de manufactura para responder una pregunta concreta: del tiempo total que una línea podría producir, ¿qué porcentaje se aprovecha efectivamente, con la calidad esperada y a la velocidad nominal?

OEE de clase mundial según Nakajima: 85.4% (0.90 × 0.95 × 0.999). Promedio observado en manufactura discreta: 55–60%.

Nivel	OEE	Interpretación
Clase mundial	≥ 85%	Top 10% de la industria a nivel global
Aceptable	60–85%	Rango habitual en la mayoría de las PYMES
Bajo	< 60%	Margen significativo de mejora operativa

3. El problema de fondo: los datos no se generan solos

Calcular el OEE es matemáticamente trivial. El verdadero desafío es disponer de datos confiables en tiempo real. Mientras la captura dependa del operario y de una planilla manual, el indicador llegará tarde, sesgado y sin las paradas menores, las cuales en muchas plantas pueden representar hasta el 89% del tiempo total de inactividad.

El salto cualitativo no está en la fórmula, sino en el modo de captura.

4. Arquitectura propuesta

La solución se compone de tres capas, todas basadas en software libre y desplegables mediante Docker:

Del PLC o sensor hasta el tablero ejecutivo. Mosquitto opera como Unified Namespace (UNS), TimescaleDB como historian y Streamlit como capa de visualización.

¿Qué es MQTT y por qué es la columna vertebral?

MQTT (Message Queuing Telemetry Transport) es el protocolo de mensajería estándar de la Industria 4.0. Un servidor central llamado broker recibe lo que publican las máquinas y lo reparte a todas las aplicaciones que necesitan esa información. Productor y consumidor no se conocen entre sí: el broker desacopla a ambos. Frente a HTTP, MQTT mantiene una conexión persistente, su sobrecarga es de apenas dos bytes por mensaje y entrega los eventos en milisegundos, características que lo hacen ideal para sensores con poco ancho de banda y comunicaciones de planta.

El concepto de Unified Namespace (UNS) fue acuñado por Walker Reynolds en 2005, cuando construyó la primera implementación en una mina de sal de Estados Unidos para centralizar el monitoreo de equipos. Hoy Reynolds (4.0 Solutions / Intellic Integration, Dallas) es referente global del enfoque y se le considera el principal evangelista de la idea en la comunidad de Industria 4.0. La definición es directa: un único broker MQTT en el que toda la planta publica datos con tópicos jerárquicos alineados al estándar ISA-95, por ejemplo lmp/planta1/empaque/linea1/maquina01/cycle. Cualquier aplicación, ya sea el tablero de planta, el Andon, los modelos de Machine Learning, Power BI o el ERP, se suscribe al broker y consume la información. Se eliminan las integraciones punto a punto, los archivos planos y los procesos por lotes. Si la solución escala a un entorno multisitio con miles de puntos, se incorpora Sparkplug B sobre la misma capa MQTT.

5. Cómo conectar máquinas reales, incluso las de generaciones anteriores

Tipo de equipo	Camino recomendado
PLC moderno (S7-1500, CompactLogix)	Cliente OPC UA con puente hacia MQTT Sparkplug B
PLC anterior (S7-300, sin Ethernet)	Modbus TCP a través de un gateway (Moxa, Ewon) hacia MQTT
Máquina sin PLC	ESP32 con sensor inductivo en la salida (aprox. USD 50)
Banda con piezas difíciles de detectar	Cámara con modelo YOLO ligero para conteo, publicado a MQTT

Retrofit IIoT de bajo costo: sensor, microcontrolador ESP32 y MQTT, sin necesidad de modificar el PLC original.

Recomendación práctica: con una inversión menor a USD 50 es posible adaptar una máquina antigua y comenzar a leer ciclos de manera automática, sin licenciamiento, sin contratos anuales y sin depender de un integrador externo.

6. Cálculo del OEE en streaming

El procesador se suscribe al broker, mantiene una ventana móvil de 60 minutos por máquina y recalcula los tres componentes (Disponibilidad, Rendimiento, Calidad) ante cada evento recibido.

La Disponibilidad y el Rendimiento se obtienen directamente del PLC o del sensor que cuenta ciclos: tiempo en marcha y piezas producidas son señales eléctricas. La Calidad requiere un mecanismo adicional que decida si la pieza salió buena o no — esto se resuelve, según el tipo de planta, con alguna de estas vías:

• Báscula al final de línea con umbral: una balanza pesa cada pieza; fuera de tolerancia, se marca como defecto y se desvía a scrap. Frecuente en empaque, alimentos y llenado.
• Visión por computadora: una cámara con un modelo ligero (YOLO o CNN) detecta defectos visuales — etiqueta faltante, deformación, color fuera de spec.
• Test funcional automatizado: estaciones tipo ICT, prueba de hermeticidad o pull-test que devuelven pass/fail al PLC.
• Sensor dimensional: encoder, láser o palpador que compara dimensiones críticas contra la especificación.
• Pulsador del inspector: cuando aún no hay un sensor automatizado, una estación de control con dos botones (aprobada / rechazada) publica al broker. No es 100% automático, pero el dato sigue siendo limpio porque el inspector solo confirma.

Cualquiera de los anteriores publica al tópico quality un evento por pieza con un campo booleano good. La ratio piezas buenas sobre piezas totales se calcula sobre la misma ventana móvil que los otros dos factores. Si una planta aún no tiene ninguno de estos mecanismos, el factor Calidad puede arrancar con un porcentaje histórico (por ejemplo 97%) y refinarse a medida que se instrumenta — el OEE deja de ser perfecto, pero gana confiabilidad mes a mes. El núcleo del motor luce de la siguiente manera:

def metrics(self, now):
    self.trim(now)

    planned_s        = self.minutes * 60
    unplanned_down_s = sum(s.duration_s for s in self.stops if s.cause != "STARTUP")
    operating_s      = max(planned_s - unplanned_down_s, 0)

    pieces_total = len(self.cycles)
    pieces_good  = sum(1 for q in self.quality if q.good)

    availability = operating_s / planned_s
    performance  = (pieces_total * self.ideal_cycle_s) / operating_s
    quality      = pieces_good / pieces_total if pieces_total else 1.0

    return availability * performance * quality

Cada minuto se persiste una instantánea en TimescaleDB (hypertable sobre PostgreSQL). Esto habilita consultas SQL estándar, integración directa con Power BI y la construcción de tableros o reportes posteriores sin necesidad de duplicar la capa de datos.

7. La pantalla de planta

La pantalla principal de planta se diseña bajo la regla de los cinco segundos: cualquier persona que pase frente al televisor debe poder identificar el estado operativo de la planta en menos de cinco segundos. Encabeza la vista la fórmula del OEE con sus tres componentes en español, de modo que cualquier visitante a la planta entienda en un solo vistazo qué se está midiendo. La demo pública del dashboard está disponible en línea; el siguiente esquema muestra el layout que adopta la pantalla, útil cuando se planifica el montaje en un televisor de planta:

Vista para televisor de planta: tarjetas con semáforo, OEE actual, meta y delta, tendencia de las últimas ocho horas y diagrama de Pareto de causas en vivo.

8. El Andon digital sobre tablet

El Andon móvil presenta a la línea de producción como tres semáforos de gran tamaño: verde cuando la máquina opera con normalidad, amarillo cuando aparecen microparadas frecuentes, rojo cuando la máquina queda detenida. El operario toca cualquiera para abrir el detalle: en verde ve los KPIs de producción, en amarillo el conteo de microparadas y en rojo las tres causas más probables, sugeridas por un modelo de Machine Learning. La confirmación se realiza con un solo toque, sin escribir texto. La demo pública del Andon está disponible en línea.

El esquema siguiente muestra el detalle del panel de causa cuando una máquina entra en rojo:

Aplicación Andon móvil desarrollada en Streamlit. El operario no requiere escribir texto.

Flujo operativo: detectar, alertar, sugerir, confirmar y retroalimentar el modelo.

Lo que no se mide en tiempo real, se termina justificando al final del turno.

9. El rol del Machine Learning en la solución

Los modelos de ML cumplen cuatro funciones concretas dentro del sistema; cada una responde a un problema operativo claramente identificado:

Modelo	Algoritmo	Aporte operativo
Detección de microparadas	Isolation Forest	Identifica paradas no reportadas por el operario
Clasificación de causas	LightGBM	Sugiere las tres causas más probables para confirmación en un toque
Pronóstico de OEE de turno	Regresión con bootstrap de residuos	Anticipa el cierre del turno a media jornada
Mantenimiento predictivo	XGBoost o regresión	Anticipa fallas a partir de vibración y consumo eléctrico

El siguiente extracto corresponde al clasificador de causas que alimenta al Andon:

features = ["machine_id", "hour", "shift", "alarm_code", "stop_duration_s"]
model = LGBMClassifier(n_estimators=300, learning_rate=0.05, class_weight="balanced")
model.fit(X_train, y_train)

# Las 3 causas mas probables que iran a la tablet del operario
proba = model.predict_proba(X_new)
top3  = sorted(zip(model.classes_, proba[0]), key=lambda p: -p[1])[:3]

Entrenado sobre un conjunto sintético realista, el modelo alcanza un 83% de exactitud (accuracy), con un 100% en la categoría BREAKDOWN y por encima del 90% en MICROSTOP. En producción el desempeño mejora de manera incremental, ya que cada confirmación del operario funciona como nuevo dato de entrenamiento.

Microparadas: la pérdida que rara vez aparece en los reportes

Las microparadas, esos intervalos de 30 a 90 segundos sin producción que el operario no suele documentar, constituyen la mayor pérdida oculta de OEE en planta. Un modelo de Isolation Forest aplicado sobre la serie de tiempos entre ciclos las identifica de manera automática:

Todo intervalo que se aleje del patrón normal se clasifica como microparada y se incorpora al OEE real, sin requerir intervención humana.

Pronóstico del cierre del turno

A mitad de jornada, el modelo proyecta el cierre del turno con una banda de incertidumbre del 95%. De este modo, un KPI tradicionalmente post-mortem se transforma en una alerta accionable:

“De mantenerse las condiciones actuales, el turno cerrará en 78%. Para alcanzar la meta es necesario recuperar 8 piezas adicionales por hora.”

10. Resultados esperables

Las cifras siguientes corresponden a referencias públicas del sector (HiveMQ, EMQ, TEEPTRAK y casos documentados) cuando la arquitectura se implementa con disciplina:

• Mejora promedio de OEE entre 15% y 25% luego de implementar conectividad OPC UA / MQTT correctamente.
• Reducción del tiempo de respuesta a paradas cercana al 60% con la incorporación del Andon digital.
• Dos o tres causas concentran entre el 70% y el 89% del tiempo de inactividad (Pareto), por lo que focalizar allí las acciones de mejora ofrece el mayor retorno.
• Las microparadas suelen ser el mayor componente de pérdida en el factor Rendimiento, y solo se hacen visibles con captura automatizada.

11. Cómo probar el sistema

Opción rápida: la demo pública

No es necesario instalar nada para conocer la solución. Las dos aplicaciones están publicadas en Streamlit Community Cloud con datos sintéticos representativos:

• Dashboard de planta: abrir dashboard en Streamlit Cloud
• Andon móvil: abrir Andon en Streamlit Cloud

Opción para implementarlo: clonar el repositorio

El código completo está publicado en GitHub bajo licencia MIT en github.com/leanmasterpymes/oee-andon-ml. Cualquiera puede clonarlo, correr el stack en su computadora y conectar máquinas reales. La vía recomendada usa Docker:

git clone https://github.com/leanmasterpymes/oee-andon-ml
cd oee-andon-ml
docker compose up -d

Una vez levantado, los puntos de acceso locales son http://localhost:8501 (pantalla de planta), http://localhost:8502 (Andon) y localhost:1883 (broker MQTT). El simulador comienza a publicar datos de tres máquinas de manera inmediata; en menos de dos minutos el OEE ya se visualiza en pantalla. Para entornos donde Docker no está disponible, el README del repositorio documenta una opción B con instalación nativa sobre Ubuntu / WSL.

Si este contenido le resultó útil

👀 Pruebe el dashboard y el Andon antes de cerrar la pestaña — ambos están en línea con datos sintéticos representativos. ⭐ Marque el repositorio en GitHub para darle visibilidad y poder clonarlo en su propia planta. 💬 Comparta el artículo con su responsable de producción o de mantenimiento; el sistema puede evaluarse en una sola jornada. 📩 Si desea adaptar la solución a su planta o integrarla a sus PLC, queda abierto el canal de mensajes directos.

Crédito al creador del concepto de Unified Namespace que sustenta esta arquitectura: Walker Reynolds — referente global de Industria 4.0 (4.0 Solutions / Intellic Integration).