Monitoramento de linha de embalagem e microparadas

O monitoramento de linha de embalagem trata das paradas que ninguém anota: um rótulo enroscado, uma garrafa caída, uma formadora de caixas esperando chapas. Este caso de uso mostra como capturar cada parada e cada mudança de velocidade em uma linha de embalagem via MQTT, classificar as microparadas automaticamente e encontrar a máquina que realmente limita a produção. Ao final, você terá um modelo de eventos simples, um detector de microparadas funcionando e uma lista do que fazer com os resultados.

Por que as linhas de embalagem escondem suas perdas

Linhas de embalagem são cadeias de máquinas rápidas ligadas por transportadores e mesas de acúmulo. Quando uma máquina para por 20 segundos, o pulmão absorve a parada e a linha continua, então ninguém registra. Quando a mesma coisa acontece quarenta vezes em um turno, o pulmão esvazia, a máquina anterior bloqueia e a linha desacelera. Os registros manuais capturam as quebras longas, mas as paradas curtas e frequentes e as máquinas rodando abaixo da velocidade nominal costumam ser invisíveis no papel.

Essas perdas ocultas muitas vezes são maiores do que as quebras que recebem toda a atenção. Por isso, as linhas de embalagem estão entre os lugares onde a coleta automática de dados se paga mais rápido: os sinais já existem nos CLPs das máquinas, e o padrão só aparece quando todos os eventos são registrados.

Categorias de parada que você precisa separar

Nem toda parada é culpa da máquina. Um bom sistema de monitoramento de linha de embalagem diferencia:

Categoria	Definição	Causa típica
Microparada	Máquina parada por menos que um limite (muitas vezes abaixo de 2 a 5 minutos), resolvida sem manutenção	Enroscos, falhas de alimentação, disparos falsos de sensor
Quebra	Parada acima do limite ou que exige manutenção	Falha mecânica ou elétrica
Sem alimentação (starved)	Máquina pronta, mas sem produto chegando	Parada a montante ou pulmão vazio
Bloqueada (blocked)	Máquina pronta, mas com a saída congestionada	Parada a jusante ou pulmão cheio
Perda de velocidade	Em operação, mas abaixo da velocidade nominal	Operador reduziu a velocidade, alimentação instável
Parada planejada	Setup, limpeza, intervalo	Atividade programada

Sem alimentação e bloqueada são a chave. Uma tampadora sem alimentação não é um problema da tampadora; ela aponta para montante. Sem separar essas categorias, todas as máquinas parecem ruins e a restrição real fica escondida.

Sinais e projeto das mensagens

O CLP de cada máquina normalmente expõe bits de funcionamento, falha, sem alimentação e bloqueio, um valor de velocidade e contadores. Publique um evento de estado a cada mudança e uma mensagem periódica com os 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}

Use os valores de cause FAULT, STARVED, BLOCKED e PLANNED quando a máquina estiver parada. O code de falha vem da própria lista de alarmes da máquina, o que dá um motivo para muitas paradas sem precisar perguntar aos operadores. Os timestamps devem ser definidos na borda com precisão abaixo de um segundo, porque as microparadas são curtas e a ordem importa.

Um detector de microparadas em Python

Este assinante escuta o topic de estado de cada máquina, mede a duração de cada parada quando a máquina volta a funcionar, classifica a parada e publica um evento de resumo. Ele também mantém uma contagem por máquina que você poderia enviar a um dashboard a 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 = {}  # máquina -> (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()

Teste sem uma linha real publicando eventos à mão:

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}'

O detector imprime uma MICRO_STOP de 18,5 segundos para a rotuladora com o código de falha 214. Cada evento de parada agora é um registro que você pode armazenar, colocar em gráfico e somar por código.

Encontrando perdas de velocidade

As paradas são metade da história. Uma linha com velocidade nominal de 400 unidades por minuto que roda a 330 para não irritar uma rotuladora temperamental perde capacidade a cada minuto em que roda, e nenhum registro de paradas mostra isso. Compare speed com rated_speed na mensagem de contagens e acumule a diferença apenas enquanto a máquina estiver em operação. Um relatório diário simples de "minutos equivalentes perdidos por velocidade" por máquina costuma surpreender: os operadores reduzem a velocidade por bons motivos, mas esses motivos podem ser corrigidos quando ficam visíveis.

Perda de velocidade e microparadas juntas formam o componente de desempenho do OEE. O guia de cálculo do OEE mostra como elas se combinam com disponibilidade e qualidade.

Checklist de análise: dos dados à ação

Depois de coletar uma semana de dados, siga esta lista:

Encontre a restrição. A máquina com menos tempo sem alimentação e bloqueada geralmente é o gargalo. Melhorias em outros pontos não aumentam a produção da linha.
Faça um Pareto das microparadas por máquina e código de falha. Muitas vezes um pequeno número de códigos causa a maioria das paradas no gargalo.
Verifique o padrão no tempo. Paradas concentradas após setups ou em horários específicos apontam para problemas de setup ou de material.
Observe o comportamento dos pulmões. Se o gargalo fica sem alimentação com frequência, o pulmão a montante pode ser pequeno demais ou a máquina a montante pouco confiável.
Revise as configurações de velocidade. Compare a velocidade real e a nominal de cada máquina e pergunte por que existe a diferença.
Atribua motivos às paradas longas. As microparadas são explicadas pelos códigos de falha, mas as quebras precisam de um motivo informado por uma pessoa. Uma lista estruturada de códigos de motivo de parada mantém esses registros utilizáveis.

Exibindo na linha

Uma tela grande ao lado da linha com o estado de cada máquina, a contagem atual de microparadas do turno e os três principais códigos de falha muda o comportamento rapidamente, porque os operadores veem o efeito de corrigir uma guia ou ajustar um sensor dentro do mesmo turno. O tutorial de dashboard de monitoramento de linha de produção mostra como montar um a partir desses topics. Com os mesmos eventos, também é possível alimentar um gêmeo digital da linha de embalagem.

Dimensionando o fluxo de dados

Linhas de embalagem geram mais eventos do que a maioria das pessoas espera, então vale estimar a taxa de mensagens antes de entrar em produção. Uma linha típica tem de cinco a oito máquinas. Cada uma publica uma mensagem de estado a cada mudança e uma mensagem de contagens a cada poucos segundos. Em um turno ruim, uma única rotuladora pode parar dezenas de vezes por hora, mas mesmo assim o total continua modesto: algumas mensagens por segundo para a linha inteira, cada uma bem abaixo de um kilobyte.

Algumas decisões de projeto mantêm esse cenário:

Publique estados apenas na mudança. Nunca faça polling e republique um estado inalterado a cada 100 ms.
Envie as contagens em um intervalo fixo e lento. A cada cinco ou dez segundos é suficiente, porque as contagens são acumuladas.
Deixe o texto dos códigos de falha fora do payload. Envie o código numérico e mantenha a tabela de descrições no serviço de análise.
Use um cliente por gateway. Um único gateway lendo vários CLPs pode publicar todos os topics das máquinas por uma única conexão, o que economiza conexões no plano do seu broker.

Com esse padrão, um único broker ConnectMQ Serverless suporta com folga uma linha de embalagem, o detector, um historiador e algumas telas, e você pode acrescentar outras linhas estendendo a árvore de topics em vez de reconstruir qualquer coisa, seja em uma fábrica de bebidas em Manaus ou em um frigorífico no Sul.

Migrando para um broker privado

Use o servidor MQTT público para o protótipo e depois leve a linha real para um broker privado, para que os dados de produção não possam ser lidos por outras pessoas. A ConnectMQ oferece um broker MQTT gerenciado em que cada gateway de CLP, o detector e o dashboard se conectam com credenciais emitidas via TLS. As 25 conexões do plano Serverless gratuito bastam para uma linha de embalagem, e os planos pagos escalam com QoS 2, mensagens maiores e shared subscriptions quando você roda várias instâncias do detector lado a lado. O roteiro mais amplo está no guia de manufatura inteligente.

Comece com a ConnectMQ

Cadastre-se em app.connectmq.com, crie um broker Serverless gratuito sem cartão de crédito, conecte sua primeira máquina de embalagem e comece a contar as microparadas que a sua linha vem escondendo.

Perguntas frequentes

O que conta como microparada em uma linha de embalagem?

Uma parada curta resolvida pelo operador sem manutenção, normalmente abaixo de um limite de alguns minutos. Escolha um limite para a planta e mantenha-o fixo para que as tendências continuem comparáveis.

Preciso que os operadores informem os motivos das microparadas?

Não. As microparadas são frequentes demais para registro manual; use os códigos de falha das máquinas. Reserve a entrada dos operadores para as paradas mais longas.

Por que separar sem alimentação e bloqueada das falhas?

Porque uma máquina sem alimentação ou bloqueada está reagindo a uma vizinha. Contar isso como tempo parado dela esconde a restrição real.

Com que rapidez os dados precisam chegar?

As mudanças de estado devem ser publicadas imediatamente, com timestamps definidos na borda. Precisão abaixo de um segundo é útil, porque muitas microparadas duram apenas alguns segundos.

Monitoramento de linha de embalagem: encontrando microparadas e perdas de velocidade com MQTT