Um dashboard de monitoramento de linha de produção transforma sinais brutos das máquinas em uma única tela que diz aos supervisores se a linha está rodando, quantas peças boas já produziu e onde está perdendo tempo. Neste tutorial você vai publicar dados das estações via MQTT, armazená-los com Telegraf e InfluxDB e montar o dashboard no Grafana, com uma alternativa mais leve em Node-RED para linhas pequenas. Tudo roda contra um broker real, então você pode acompanhar a partir de um notebook.
O que um bom dashboard de linha de produção mostra
Antes de ligar qualquer coisa, decida o que a tela precisa responder. A maioria dos dashboards de linha fracassa porque exibe todas as tags que o CLP expõe, em vez das poucas perguntas que as pessoas realmente fazem durante um turno.
| Pergunta no chão de fábrica | Sinal necessário | Widget típico |
|---|---|---|
| Cada estação está rodando agora? | state (RUNNING, IDLE, DOWN, SETUP) |
Blocos de status com código de cores |
| Estamos dentro do plano do turno? | Contagem de boas, contagem planejada | Número grande mais barra de progresso |
| De onde vem o refugo? | Contagem de rejeitos por estação | Gráfico de barras por estação |
| Qual estação é o gargalo? | Taxa real vs. taxa ideal | Tabela ordenada pela diferença de taxa |
| Qual a saúde geral da linha? | Disponibilidade, desempenho, qualidade | Medidor de OEE com três sub-barras |
| O que nos parou na última hora? | Mudanças de estado com timestamps | Linha do tempo de estados |
Mantenha a primeira versão nessas seis. Os supervisores vão pedir mais quando confiarem nos números, e a confiança vem de as contagens baterem com o que eles veem no chão de fábrica.
Arquitetura: da estação à tela
O caminho dos dados é curto e cada peça é substituível:
- Cada estação (gateway do CLP, PC de borda ou microcontrolador) publica uma pequena mensagem JSON de status em um broker MQTT sempre que seu estado muda e pelo menos a cada poucos segundos.
- O Telegraf assina os topics da linha e grava cada mensagem no InfluxDB como série temporal.
- O Grafana consulta o InfluxDB e renderiza os painéis.
- Opcionalmente, um fluxo Node-RED assina os mesmos topics e alimenta um dashboard leve em uma TV ao lado da linha.
O broker é o hub que desacopla as estações dos consumidores. Se esse papel for novo para você, este artigo sobre o que um broker MQTT faz cobre o básico. Como cada consumidor assina de forma independente, você pode adicionar depois um historiador, um painel andon ou uma calculadora de OEE sem mexer nas estações.
Passo 1: projete a estrutura de topics
Uma árvore de topics previsível economiza horas depois. Use uma hierarquia no estilo ISA-95 para que o dashboard possa filtrar por linha e estação com wildcards:
connectmq/demo/<your-id>/line1/<station>/status
Por exemplo connectmq/demo/a7f3k9/line1/filler/status. O payload é um único objeto JSON:
{
"state": "RUNNING",
"good": 1842,
"reject": 17,
"rate": 58.5,
"ideal_rate": 60,
"ts": 1792137600
}
As contagens são cumulativas no turno, o que torna os dados robustos: se uma mensagem se perder, a próxima ainda traz o total correto. As taxas são em peças por minuto. Adicione um nível de empresa e de site antes da linha quando expandir para mais de uma planta, por exemplo uma unidade em Joinville e outra em Manaus.
Passo 2: simule as estações
Para montar o dashboard antes de a linha real estar conectada, rode este simulador em Python. Ele usa paho-mqtt 2.x e o servidor MQTT público gratuito em broker.connectmq.com. Troque a7f3k9 pelo seu próprio ID aleatório, porque a área pública pode ser lida por todos.
import json
import random
import time
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/a7f3k9/line1"
STATIONS = {"filler": 60, "capper": 62, "labeler": 65, "packer": 58}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="line1-sim-a7f3k9")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
counters = {name: {"good": 0, "reject": 0, "state": "RUNNING"} for name in STATIONS}
try:
while True:
for name, ideal in STATIONS.items():
c = counters[name]
# De vez em quando muda o estado para deixar o dashboard interessante
roll = random.random()
if c["state"] == "RUNNING" and roll < 0.03:
c["state"] = random.choice(["DOWN", "IDLE"])
elif c["state"] != "RUNNING" and roll < 0.25:
c["state"] = "RUNNING"
rate = 0.0
if c["state"] == "RUNNING":
rate = round(ideal * random.uniform(0.85, 1.0), 1)
made = int(rate / 12) # aproximadamente 5 segundos de produção
rejects = 1 if random.random() < 0.04 else 0
c["good"] += made - rejects
c["reject"] += rejects
payload = {
"state": c["state"],
"good": c["good"],
"reject": c["reject"],
"rate": rate,
"ideal_rate": ideal,
"ts": int(time.time()),
}
client.publish(f"{PREFIX}/{name}/status", json.dumps(payload), qos=1, retain=True)
time.sleep(5)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Quatro estações publicando a cada cinco segundos ficam bem dentro do limite do servidor público de 10 mensagens por segundo por cliente. A flag retain faz com que um dashboard que conecta no meio do turno receba imediatamente o último estado conhecido de cada estação. Verifique o fluxo em um terminal:
mosquitto_sub -h broker.connectmq.com -p 1883 -i viewer-a7f3k9 -t "connectmq/demo/a7f3k9/line1/+/status" -v
Passo 3: armazene os dados com Telegraf e InfluxDB
O consumidor MQTT do Telegraf transforma cada mensagem em um ponto do InfluxDB, e o parsing de topics extrai a linha e a estação como tags. Salve como telegraf.conf:
[agent]
interval = "5s"
flush_interval = "5s"
[[inputs.mqtt_consumer]]
servers = ["tcp://broker.connectmq.com:1883"]
topics = ["connectmq/demo/a7f3k9/line1/+/status"]
client_id = "telegraf-a7f3k9"
qos = 1
data_format = "json"
json_string_fields = ["state"]
json_time_key = "ts"
json_time_format = "unix"
[[inputs.mqtt_consumer.topic_parsing]]
topic = "connectmq/demo/+/+/+/status"
measurement = "_/_/_/_/_/measurement"
tags = "_/_/_/line/station/_"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "YOUR_INFLUX_TOKEN"
organization = "plant"
bucket = "line"
Cada ponto cai no measurement status com as tags line=line1 e station=filler, mais os campos state, good, reject, rate e ideal_rate. Em produção, troque o servidor para ssl://broker.connectmq.com:8883 e adicione username = "YOUR_USERNAME", password = "YOUR_PASSWORD" e o seu client_id emitido. Mais opções estão no guia do consumidor MQTT do Telegraf.
Passo 4: monte o dashboard de monitoramento de linha de produção no Grafana
Adicione o InfluxDB como fonte de dados no Grafana (linguagem de consulta Flux) e crie estes painéis.
Blocos de status das estações. Use um painel Stat com mapeamento de valores: RUNNING para verde, IDLE para amarelo, DOWN para vermelho, SETUP para azul.
from(bucket: "line")
|> range(start: -5m)
|> filter(fn: (r) => r._measurement == "status" and r._field == "state")
|> last()
|> group(columns: ["station"])
Peças boas neste turno. Como as contagens são cumulativas, o último valor é o total:
from(bucket: "line")
|> range(start: today())
|> filter(fn: (r) => r._measurement == "status" and r._field == "good" and r.station == "packer")
|> last()
Use a última estação da linha (aqui a embaladora) como produção da linha; contar em todas as estações gera contagem dupla.
Taxa vs. ideal. Um painel Time series com rate e ideal_rate por estação mostra o gargalo de relance: a estação cuja taxa real fica mais abaixo da ideal enquanto está rodando.
Linha do tempo de estados. O painel State timeline do Grafana alimentado pelo campo state dá uma barra por estação colorida pelo estado ao longo do turno, que é a forma mais rápida de ver quando e onde a linha parou.
Medidor de OEE. Numa primeira versão, calcule o OEE em um subscriber separado e publique o resultado em line1/oee, depois faça o gráfico desse topic. A matemática está explicada em como calcular o OEE, e o tutorial de monitoramento de OEE em tempo real traz um subscriber pronto. Fazer o cálculo uma única vez, fora do Grafana, mantém todas as telas mostrando o mesmo número.
Alternativa em Node-RED para uma única linha
Se você só precisa de uma TV ao lado de uma linha e não quer um banco de séries temporais, o Node-RED é mais rápido. Configure um nó de configuração mqtt-broker com servidor broker.connectmq.com e porta 1883 (ou 8883 com TLS e suas credenciais em produção) e depois adicione:
- Um nó
mqtt inassinandoconnectmq/demo/a7f3k9/line1/+/status, com saída configurada como objeto JSON já interpretado. - Um nó
functionque extrai o nome da estação demsg.topic.split("/")[4]e o encaminha para o widget certo. - Widgets
ui-textdo Dashboard 2.0 para o estado, widgetsui-gaugepara a taxa e umui-chartpara as contagens de boas.
A contrapartida é o histórico: o Node-RED mostra bem o presente, mas não é um historiador. Muitas plantas rodam os dois, com o Node-RED no painel da linha e o Grafana para a revisão do turno. O artigo sobre dashboard de OEE no Node-RED aprofunda essa abordagem.
Armadilhas comuns e como corrigi-las
- Contagens zeram no meio do turno. Um reinício do CLP ou do gateway limpa o contador. Guarde a linha de base do turno na borda, ou faça o dashboard usar
difference()comnonNegative: truepara que os resets não criem produção negativa. - Blocos mostram um RUNNING desatualizado. Se uma estação fica offline, sua mensagem retida continua dizendo RUNNING. Adicione o campo
tsao bloco e pinte-o de cinza quando tiver mais de 30 segundos, ou use uma mensagem Last Will do MQTT que publique OFFLINE. - Client IDs duplicados. Duas instâncias do Telegraf com o mesmo client ID vão se derrubar mutuamente o tempo todo. Cada cliente precisa de um ID único.
- Painéis demais. Se a tela precisa de rolagem na TV do chão de fábrica, está carregada demais. Leve os detalhes para um dashboard de drill-down.
Do demo à produção
O servidor público é perfeito para construir, mas seus topics ficam visíveis para qualquer pessoa. Para uma linha real, migre para um broker privado: um broker MQTT gerenciado elimina o trabalho de atualizar e escalar um servidor, e um broker MQTT na nuvem permite que supervisores remotos e a matriz vejam o mesmo dashboard. Com o ConnectMQ você cria o broker no portal, recebe usuário, senha e client ID e muda apenas as configurações de conexão no simulador, no Telegraf e no Node-RED. O explorador de topics ao vivo do portal é útil para confirmar que todas as estações estão publicando antes de depurar um painel vazio no Grafana.
O plano Serverless gratuito suporta até 25 conexões, o que cobre uma linha piloto com seu gateway, o Telegraf e alguns dashboards. Plantas maiores costumam migrar para o plano Serverless pago ou para um cluster Dedicated conforme mais linhas entram em operação. Para a estratégia mais ampla, incluindo o caminho até um gêmeo digital da fábrica, veja o guia de manufatura inteligente.
Comece com o ConnectMQ
Crie um broker gratuito em app.connectmq.com no plano Serverless, sem cartão de crédito, aponte suas estações e o Telegraf para ele e tenha hoje mesmo um dashboard de linha de produção rodando em infraestrutura privada.
Perguntas frequentes
Devo usar Grafana ou Node-RED para um dashboard de linha de produção?
Use o Grafana quando precisar de histórico, comparações entre turnos e muitos usuários; use o Node-RED para um painel ao vivo rápido em uma linha. Muitas equipes rodam os dois a partir dos mesmos topics MQTT.
Com que frequência as estações devem publicar status?
Publique imediatamente a cada mudança de estado e envie um heartbeat a cada 5 a 10 segundos. Isso mantém os blocos atualizados sem inundar o broker.
Posso conectar CLPs diretamente?
A maioria dos CLPs precisa de um gateway de borda (Node-RED, um conversor de protocolo ou o cliente MQTT do próprio CLP) que lê as tags e publica JSON no broker. Depois que os dados estão no MQTT, o dashboard não se importa com a origem.
O servidor público é seguro para dados reais de produção?
Não. A área pública do broker.connectmq.com pode ser lida por qualquer pessoa, então use-a apenas para testes e leve os dados de produção para um broker ConnectMQ privado com credenciais e TLS.
