La monitorización de una línea de envasado trata de las paradas que nadie anota: una etiqueta atascada, una botella caída, una formadora de cajas esperando cartones. Este caso de uso muestra cómo capturar cada parada y cada cambio de velocidad en una línea de envasado por MQTT, clasificar las microparadas automáticamente y encontrar la máquina que realmente limita la producción. Terminarás con un modelo de eventos sencillo, un detector de microparadas que funciona y una lista de qué hacer con los resultados.
Por qué las líneas de envasado esconden sus pérdidas
Las líneas de envasado son cadenas de máquinas rápidas unidas por transportadores y mesas de acumulación. Cuando una máquina se detiene 20 segundos, el pulmón lo absorbe y la línea sigue, así que nadie lo registra. Cuando lo mismo ocurre cuarenta veces por turno, el pulmón se vacía, la máquina anterior se bloquea y la línea se ralentiza. Los registros manuales recogen las averías largas, pero las paradas cortas y frecuentes y las máquinas que funcionan por debajo de su velocidad nominal suelen ser invisibles sobre el papel.
Esas pérdidas ocultas suelen ser mayores que las averías que acaparan toda la atención. Por eso las líneas de envasado son uno de los lugares donde la captura automática de datos se amortiza más rápido: las señales ya existen en los PLC de las máquinas, y el patrón solo aparece cuando se registra cada evento.
Categorías de parada que debes separar
No todas las paradas son culpa de la máquina. Un sistema útil de monitorización de líneas de envasado distingue:
| Categoría | Definición | Causa típica |
|---|---|---|
| Microparada | Máquina detenida menos de un umbral (a menudo entre 2 y 5 minutos), resuelta sin mantenimiento | Atascos, fallos de alimentación, disparos falsos de sensores |
| Avería | Parada por encima del umbral o que requiere mantenimiento | Fallo mecánico o eléctrico |
| Falta de producto (starved) | Máquina lista pero sin producto entrante | Parada aguas arriba o pulmón vacío |
| Bloqueada (blocked) | Máquina lista pero con la salida colapsada | Parada aguas abajo o pulmón lleno |
| Pérdida de velocidad | En marcha, pero por debajo de la velocidad nominal | El operador redujo la velocidad, alimentación inestable |
| Parada planificada | Cambio de formato, limpieza, pausa | Actividad programada |
Las situaciones de falta de producto y de bloqueo son la clave. Una taponadora sin producto no tiene un problema de taponadora; el problema está aguas arriba. Si no las separas, todas las máquinas parecen malas y la restricción real queda oculta.
Señales y diseño de mensajes
El PLC de cada máquina suele exponer bits de marcha, fallo, falta de producto y bloqueo, un valor de velocidad y contadores. Publica un evento de estado en cada cambio y un mensaje periódico con los contadores:
connectmq/demo/<your-id>/plant2/pack3/<machine>/state
connectmq/demo/<your-id>/plant2/pack3/<machine>/counts
{"state": "STOPPED", "cause": "FAULT", "code": 214, "speed": 0, "ts": 1792140125.42}
{"infeed": 120544, "outfeed": 120391, "reject": 153, "speed": 312, "rated_speed": 400, "ts": 1792140130.0}
Usa los valores de cause FAULT, STARVED, BLOCKED y PLANNED cuando la máquina esté parada. El code de fallo procede de la propia lista de alarmas de la máquina, lo que te da un motivo para muchas paradas sin preguntar a los operadores. Las marcas de tiempo deben fijarse en el edge con precisión inferior al segundo, porque las microparadas son cortas y el orden importa.
Un detector de microparadas en Python
Este suscriptor escucha el topic de estado de cada máquina, mide la duración de cada parada cuando la máquina vuelve a arrancar, la clasifica y publica un evento de resumen. También mantiene un recuento por máquina que podrías enviar a un panel cada minuto.
import json
import time
from collections import defaultdict
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/p9x2c6/plant2/pack3"
MICRO_STOP_SECONDS = 120
stopped_since = {} # machine -> (start_ts, cause, code)
tally = defaultdict(lambda: defaultdict(lambda: {"count": 0, "seconds": 0.0}))
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{PREFIX}/+/state", qos=1)
def on_message(client, userdata, msg):
machine = msg.topic.split("/")[-2]
event = json.loads(msg.payload)
ts = event.get("ts", time.time())
if event["state"] == "STOPPED" and machine not in stopped_since:
stopped_since[machine] = (ts, event.get("cause", "UNKNOWN"), event.get("code"))
return
if event["state"] == "RUNNING" and machine in stopped_since:
start, cause, code = stopped_since.pop(machine)
duration = ts - start
if cause == "FAULT":
category = "MICRO_STOP" if duration < MICRO_STOP_SECONDS else "BREAKDOWN"
else:
category = cause # STARVED, BLOCKED, PLANNED
bucket = tally[machine][category]
bucket["count"] += 1
bucket["seconds"] += duration
summary = {
"machine": machine,
"category": category,
"code": code,
"duration": round(duration, 1),
"ended": ts,
}
client.publish(f"{PREFIX}/{machine}/stop", json.dumps(summary), qos=1)
print(summary)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="microstop-p9x2c6")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
Pruébalo sin una línea real publicando eventos a mano:
mosquitto_pub -h broker.connectmq.com -p 1883 -i tester-p9x2c6 -t "connectmq/demo/p9x2c6/plant2/pack3/labeler/state" -m '{"state":"STOPPED","cause":"FAULT","code":214,"speed":0,"ts":1792140125.4}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i tester-p9x2c6 -t "connectmq/demo/p9x2c6/plant2/pack3/labeler/state" -m '{"state":"RUNNING","speed":380,"ts":1792140143.9}'
El detector imprime una MICRO_STOP de 18,5 segundos en la etiquetadora con el código de fallo 214. Cada evento de parada es ahora un registro que puedes almacenar, graficar y sumar por código.
Detectar las pérdidas de velocidad
Las paradas son la mitad de la historia. Una línea con una velocidad nominal de 400 unidades por minuto que funciona a 330 para mantener contenta a una etiquetadora caprichosa pierde capacidad cada minuto que está en marcha, y ningún registro de paradas lo refleja. Compara speed con rated_speed en el mensaje de contadores y acumula la diferencia solo mientras la máquina está en marcha. Un sencillo informe diario de "minutos equivalentes perdidos por velocidad" por máquina suele ser una sorpresa: los operadores reducen la velocidad por buenos motivos, pero esos motivos pueden corregirse en cuanto se hacen visibles.
La pérdida de velocidad y las microparadas forman juntas el componente de rendimiento del OEE. La guía de cálculo del OEE muestra cómo se combinan con la disponibilidad y la calidad.
Lista de análisis: de los datos a la acción
Una vez recogida una semana de datos, recorre esta lista:
- Encuentra la restricción. La máquina con menos tiempo de falta de producto y de bloqueo suele ser el cuello de botella. Las mejoras en otros puntos no aumentan la producción de la línea.
- Haz un Pareto de microparadas por máquina y código de fallo. A menudo un número reducido de códigos provoca la mayoría de las paradas en el cuello de botella.
- Revisa el patrón temporal. Las paradas concentradas tras los cambios de formato o a determinadas horas apuntan a problemas de ajuste o de material.
- Observa el comportamiento de los pulmones. Si el cuello de botella se queda a menudo sin producto, el pulmón anterior puede ser demasiado pequeño o la máquina anterior demasiado poco fiable.
- Revisa los ajustes de velocidad. Compara la velocidad real y la nominal de cada máquina y pregunta por qué existe la diferencia.
- Asocia motivos a las paradas largas. Las microparadas se explican con los códigos de fallo, pero las averías necesitan un motivo humano. Una lista estructurada de códigos de motivo de parada mantiene útiles esas entradas.
Mostrarlo en la línea
Una pantalla grande junto a la línea con el estado de cada máquina, el recuento de microparadas del turno en curso y los tres códigos de fallo principales cambia los comportamientos rápidamente, porque los operadores ven el efecto de corregir una guía o ajustar un sensor dentro del mismo turno. El tutorial del panel de monitorización de líneas de producción muestra cómo construir uno a partir de estos topics. Si además quieres ver la línea en su contexto espacial, los mismos topics pueden alimentar un gemelo digital 3D en el navegador.
Dimensionar el flujo de datos
Las líneas de envasado generan más eventos de los que la mayoría espera, así que vale la pena estimar la tasa de mensajes antes de la puesta en marcha. Una línea típica tiene entre cinco y ocho máquinas. Cada una publica un mensaje de estado en cada cambio y un mensaje de contadores cada pocos segundos. En un mal turno, una sola etiquetadora puede pararse decenas de veces por hora, pero incluso así el total sigue siendo modesto: unos pocos mensajes por segundo para toda la línea, cada uno muy por debajo de un kilobyte.
Algunas decisiones de diseño lo mantienen así:
- Publica los estados solo cuando cambian. Nunca consultes y vuelvas a publicar un estado sin cambios cada 100 ms.
- Envía los contadores con un intervalo fijo y lento. Cada cinco o diez segundos es suficiente, porque los contadores son acumulativos.
- Deja fuera del payload el texto de los códigos de fallo. Envía el código numérico y mantén la tabla de descripciones en el servicio de análisis.
- Usa un cliente por gateway. Un único gateway que lee varios PLC puede publicar todos los topics de las máquinas por una sola conexión, lo que ahorra conexiones en el plan de tu broker.
Con ese patrón, un único broker Serverless de ConnectMQ soporta con holgura una línea de envasado, el detector, un historiador y un par de pantallas, y puedes añadir más líneas ampliando el árbol de topics en lugar de reconstruir nada.
Pasar a un broker privado
Usa el servidor MQTT público gratuito para el prototipo y después pasa la línea real a un broker privado para que otros no puedan leer los datos de producción. ConnectMQ ofrece un broker MQTT gestionado en el que cada gateway de PLC, el detector y el panel se conectan con credenciales emitidas sobre TLS. Las 25 conexiones del plan gratuito Serverless bastan para una línea de envasado, y los planes de pago escalan con QoS 2, mensajes más grandes y shared subscriptions cuando ejecutas varias instancias del detector en paralelo. La hoja de ruta general se trata en la guía de manufactura inteligente.
Empieza con ConnectMQ
Regístrate en app.connectmq.com, crea un broker Serverless gratuito sin tarjeta de crédito, conecta tu primera máquina de envasado y empieza a contar las microparadas que tu línea ha estado escondiendo.
Preguntas frecuentes
¿Qué se considera una microparada en una línea de envasado?
Una parada corta que el operador resuelve sin mantenimiento, normalmente por debajo de un umbral de unos pocos minutos. Elige un único umbral para la planta y mantenlo fijo para que las tendencias sigan siendo comparables.
¿Necesito que los operadores introduzcan los motivos de las microparadas?
No. Las microparadas son demasiado frecuentes para la entrada manual; usa en su lugar los códigos de fallo de las máquinas. Reserva la intervención del operador para las paradas más largas.
¿Por qué separar la falta de producto y el bloqueo de los fallos?
Porque una máquina sin producto o bloqueada está reaccionando a una vecina. Contar esas situaciones como tiempo de parada propio oculta la restricción real.
¿Con qué rapidez deben llegar los datos?
Los cambios de estado deben publicarse inmediatamente con marcas de tiempo del edge. La precisión inferior al segundo es útil porque muchas microparadas duran solo unos segundos.
