Um trabalhador conectado é um operador, técnico ou supervisor cujos dispositivos recebem a informação certa no momento em que ela importa: a próxima instrução de trabalho, um alarme de máquina, uma retenção de qualidade ou um pedido de ajuda. Este artigo cobre os casos de uso de trabalhador conectado que geram valor no chão de fábrica, como estruturar os topics MQTT por trás deles e um client de navegador funcional que recebe tarefas e envia confirmações via WebSocket seguro.
O que uma solução de trabalhador conectado realmente faz
A maioria dos trabalhadores de linha de frente na manufatura ainda descobre os problemas ao passar por eles. Uma máquina espera material até alguém perceber, um técnico de manutenção é chamado pelo rádio e as instruções de trabalho ficam em uma pasta no posto. As soluções de trabalhador conectado fecham essa lacuna levando os dados ao vivo da planta até as pessoas, em vez de levar as pessoas até os dados.
Capacidades típicas:
- Instruções de trabalho digitais que mudam automaticamente com a ordem ou variante ativa.
- Alertas direcionados: uma parada de máquina vai para o relógio do técnico responsável, não para todo mundo.
- Pedidos de ajuda e escalonamento: um operador toca em "preciso de material" e o pedido escala se ninguém o aceitar em poucos minutos.
- Checklists e aprovações: verificações de partida, verificações de qualidade e setups registrados com quem fez e quando.
- Feedback nos dois sentidos: os trabalhadores adicionam códigos de motivo, referências de fotos ou comentários que voltam para os dados.
A palavra-chave é tempo real. Uma lista de tarefas que atualiza a cada poucos minutos não basta quando uma linha para; os eventos precisam chegar em segundos.
Casos de uso de trabalhador conectado no chão de fábrica
| Caso de uso | Origem do evento | Quem recebe | Resposta registrada |
|---|---|---|---|
| Chamado por parada de máquina | Mudança de estado no CLP | Técnico da linha | Aceito, chegou, resolvido |
| Reposição de material | Botão do operador ou sensor de nível baixo | Logística | Aceito, entregue |
| Retenção de qualidade | Padrão de falhas na estação de teste | Engenheiro de qualidade, líder da linha | Retenção confirmada, liberada |
| Instruções de setup | Mudança de ordem no MES | Operador no posto | Cada etapa confirmada |
| Alerta de segurança ou meio ambiente | Sensor de gás, limite de temperatura | Todos em uma área | Reconhecido |
| Passagem de turno | Aplicativo do supervisor | Supervisor do próximo turno | Confirmação de leitura |
Muitos desses casos se sobrepõem a um sistema andon digital; a diferença é que uma configuração de trabalhador conectado encaminha eventos para dispositivos individuais e registra a resposta de cada pessoa.
Por que o MQTT combina com aplicativos de trabalhador conectado
Os dispositivos de linha de frente são móveis, alimentados por bateria e muitas vezes ficam em Wi-Fi instável. O design do MQTT combina com esse ambiente:
- Push, não polling. Os dispositivos mantêm uma única conexão leve e recebem eventos instantaneamente, o que economiza bateria e rede em comparação com consultar uma API repetidamente.
- Funciona no navegador. Com MQTT sobre WebSocket, um simples aplicativo web em um tablet pode assinar topics sem instalar nada.
- Retained messages entregam ao dispositivo o estado atual (ordem ativa, chamados abertos) no momento em que ele reconecta.
- Sessões persistentes com expiração de sessão permitem que um dispositivo que passa por uma zona sem sinal receba as mensagens QoS 1 enfileiradas enquanto estava fora.
- Request/response do MQTT 5, com response topics e correlation data, mapeia naturalmente para "tarefa enviada, tarefa aceita".
Projeto de topics
Organize os topics por área da planta para eventos de difusão e por função ou pessoa para tarefas direcionadas:
acme/plant1/assembly/line2/calls/open/<callId> retained, cleared when resolved
acme/plant1/assembly/line2/instructions/station4 retained, current instruction
acme/plant1/workers/role/maintenance/tasks tasks for anyone in a role
acme/plant1/workers/user/u1042/tasks tasks for one person
acme/plant1/workers/responses accept, arrive, resolve events
O tablet de um técnico assina sua função, seu próprio topic de usuário e os chamados abertos da sua área. Para limpar um chamado retido, basta publicar uma mensagem retida vazia no mesmo topic, o que o remove de todos os dispositivos de uma só vez.
Um client de navegador via WebSocket seguro
O exemplo abaixo é um client mínimo de trabalhador conectado com MQTT.js v5. Ele se conecta via WebSocket seguro na porta 8084, assina os chamados abertos e as tarefas pessoais e publica uma aceitação com o ID do trabalhador. Ele roda em qualquer bundle moderno de navegador (Vite, webpack) depois de npm install mqtt.
import mqtt from "mqtt";
const prefix = "connectmq/demo/cw-4f19"; // use seu próprio id aleatório
const workerId = "u1042";
const clientId = `cw-${workerId}-${Math.random().toString(16).slice(2, 8)}`;
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId,
protocolVersion: 5,
clean: false,
properties: { sessionExpiryInterval: 1800 }, // guarda mensagens QoS 1 enfileiradas por 30 minutos
reconnectPeriod: 2000,
});
const openCalls = new Map();
client.on("connect", () => {
client.subscribe(
[`${prefix}/line2/calls/open/+`, `${prefix}/workers/user/${workerId}/tasks`],
{ qos: 1 }
);
});
client.on("message", (topic, payload) => {
if (topic.includes("/calls/open/")) {
const callId = topic.split("/").pop();
if (payload.length === 0) {
openCalls.delete(callId); // chamado resolvido, mensagem retida limpa
} else {
openCalls.set(callId, JSON.parse(payload.toString()));
}
render();
} else {
const task = JSON.parse(payload.toString());
navigator.vibrate?.(300);
console.log("New task:", task);
}
});
export function acceptCall(callId) {
client.publish(
`${prefix}/workers/responses`,
JSON.stringify({ callId, workerId, action: "ACCEPTED", ts: Date.now() }),
{ qos: 1 }
);
}
function render() {
console.table([...openCalls.entries()].map(([id, c]) => ({ id, ...c })));
}
Abra um chamado de teste pela linha de comando e veja-o aparecer no dispositivo; depois limpe-o com uma mensagem retida vazia:
mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 \
-t "connectmq/demo/cw-4f19/line2/calls/open/C-001" \
-m '{"type":"MACHINE_STOP","station":"press2","reason":"jam"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 -n \
-t "connectmq/demo/cw-4f19/line2/calls/open/C-001"
O servidor MQTT público suporta QoS 0 a 2 e expiração de sessão de até 30 minutos, o que basta para testar o comportamento de reconexão. Lembre-se de que sua área pública pode ser lida por qualquer pessoa, então ele serve apenas para testes e protótipos: nunca envie nomes reais nem dados da planta para ele (dados pessoais de colaboradores também estão sujeitos à LGPD).
Checklist de implantação para projetos de trabalhador conectado
- Comece por um processo que dói, geralmente chamados por parada de máquina ou por material, e meça o tempo de resposta antes e depois.
- Envolva os operadores desde o início. Se um alerta for ruído para eles, será ignorado ou silenciado.
- Encaminhe por função e por área, não para todo mundo. Difusões geram fadiga de alertas rapidamente.
- Projete o escalonamento: se ninguém aceitar um chamado em um tempo definido, envie-o para o próximo nível.
- Faça os dispositivos se recuperarem em silêncio. Use estado retido e sessões persistentes para que uma reconexão não exija nenhuma ação do usuário.
- Use credenciais únicas por dispositivo ou por instância do aplicativo, somente via TLS ou WebSocket seguro.
- Registre as respostas em um banco de dados para análise de tempo de resposta e melhoria contínua.
- Planeje para dispositivos compartilhados: um login por turno decide qual topic de usuário o tablet de um posto assina.
Medindo se funciona
Um projeto de trabalhador conectado deve provar seu valor com números que a planta já acompanha. Como cada chamado e cada resposta é um evento MQTT, você pode medir sem esforço extra:
- Tempo até aceitar: desde a abertura do chamado até uma pessoa aceitá-lo.
- Tempo até chegar: desde a aceitação até o técnico confirmar a chegada ao posto.
- Tempo até resolver: desde o chamado até a linha voltar a rodar, o que se liga diretamente às paradas.
- Taxa de escalonamento: com que frequência os chamados ficam sem resposta no primeiro nível, sinal de falta de pessoal ou de encaminhamento ruim.
- Chamados por turno e por posto: um chamado recorrente no mesmo posto é um problema a corrigir, não apenas a atender.
Revise esses números com a equipe toda semana durante o piloto. O objetivo não é correr mais rápido entre incêndios, mas ter menos incêndios, então leve as causas recorrentes para o seu processo de melhoria.
Escalando aplicativos de trabalhador conectado na ConnectMQ
Cada tablet, relógio e painel de linha mantém sua própria conexão, então o número de conexões cresce rapidamente. A ConnectMQ é um broker MQTT gerenciado que oferece WebSocket seguro na porta 8084 com certificado Let's Encrypt, para que aplicativos de navegador se conectem sem gambiarras de certificado. O plano Serverless gratuito cobre um piloto de até 25 conexões, o plano Serverless pago escala até 1.000 conexões com QoS 2 e shared subscriptions, e os clusters Dedicated isolam implantações maiores. A lógica de escalonamento e o registro de respostas rodam nos seus próprios serviços, como um fluxo do Node-RED ou um pequeno worker em Node.js, conectados como clients comuns.
Para o contexto completo da planta, veja o guia de manufatura inteligente, e a visão geral de broker MQTT na nuvem explica como um broker hospedado conecta com segurança a planta e os dispositivos móveis.
Conecte seus trabalhadores com a ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, copie o usuário, a senha e o client ID gerados para o client de navegador acima e envie hoje seu primeiro chamado ao vivo para um tablet.
Perguntas frequentes
Quais dispositivos podem atuar como dispositivos de trabalhador conectado?
Tablets, smartphones, smartwatches, coletores robustos e grandes painéis de linha funcionam. Qualquer coisa com um navegador moderno pode usar MQTT via WebSocket seguro; aplicativos nativos podem usar uma biblioteca MQTT diretamente.
Como os trabalhadores recebem as mensagens que perderam enquanto estavam offline?
Use uma sessão persistente com intervalo de expiração de sessão e assinaturas QoS 1, para que o broker enfileire as mensagens enquanto o dispositivo estiver desconectado. As retained messages fornecem o estado atual na reconexão.
Cada dispositivo deve ter suas próprias credenciais?
Sim. Credenciais e client IDs únicos por dispositivo ou instância do aplicativo permitem revogar um tablet perdido sem afetar os outros e rastrear quem enviou cada resposta.
Uma plataforma de trabalhador conectado é a mesma coisa que um sistema andon?
Eles se sobrepõem. O andon torna os problemas visíveis na linha; uma solução de trabalhador conectado também encaminha tarefas para pessoas específicas e registra suas respostas.
