Como Criar Códigos de Motivo de Parada que os Operadores Realmente Usam

Os códigos de motivo de parada decidem se os seus dados de parada geram ação ou apenas enchem um banco de dados. Este guia mostra como criar uma árvore de motivos curta e estruturada que o operador consegue usar em poucos segundos, como mapeá-la às perdas do OEE e como montar um fluxo de apontamento que publica os motivos via MQTT ao lado dos estados de máquina que seus sensores já detectam. Ao final, você terá uma árvore inicial, um formato JSON para ela e código funcional para o lado do operador.

Por que a maioria das listas de códigos de motivo fracassa

As plantas costumam começar o rastreamento de paradas com boas intenções e uma lista longa. Em poucos meses, os dados mostram sempre o mesmo padrão: uma grande parcela das paradas codificada como "Outros" ou "Diversos", alguns códigos usados para tudo e dezenas que nunca são usados. As causas são previsíveis:

• Códigos demais. Diante de uma lista rolante com sessenta opções, o operador escolhe a primeira que parece plausível.
• Códigos com nome de departamento. "Manutenção" ou "Qualidade" descrevem quem é responsável, não o que aconteceu, então ninguém consegue agir com base nisso.
• Significados sobrepostos. "Enrosco" e "Problema de material" servem para uma falha de alimentação, então o mesmo evento recebe dois códigos diferentes dependendo de quem está no turno.
• Nenhuma ligação com a detecção. Se o operador também precisa registrar quando a parada começou e terminou, a precisão desaba. O tempo deve vir da máquina; só o motivo deve vir de uma pessoa.

A solução é uma hierarquia curta, uma redação específica e detecção automática de estado.

Princípios para bons códigos de motivo de parada

1. Separe detecção de explicação. As máquinas informam RUNNING e STOPPED automaticamente; o operador só responde "por quê?".
2. Use uma árvore, não uma lista plana. Dois ou três níveis: uma categoria, um motivo e, opcionalmente, um detalhe. Cada tela mostra apenas algumas opções.
3. Nomeie a causa, não o departamento. "Aguardando material" é melhor que "Logística".
4. Torne os códigos mutuamente exclusivos. Se dois códigos podem descrever o mesmo evento, junte-os ou escreva uma definição de uma linha que os diferencie.
5. Mantenha um nível superior pequeno e fixo. Mapeie o nível superior às perdas do OEE para que os relatórios se consolidem automaticamente.
6. Limite o "Outros". Exija um comentário em texto livre quando "Outros" for escolhido e revise esses comentários toda semana; os recorrentes viram novos códigos.
7. Deixe os alarmes da máquina preencherem quando possível. Se o controlador informa um código de falha, sugira o motivo correspondente e deixe o operador confirmar.
8. Revise a árvore regularmente. Aposente códigos sem uso e divida os códigos que escondem coisas demais.

Uma árvore inicial de códigos de motivo

Use isto como ponto de partida e adapte o segundo nível ao seu processo. O nível superior se mapeia de forma limpa para disponibilidade, desempenho e tempo planejado.

Quinze códigos em seis categorias cabem em duas telas. Algumas plantas acrescentam um terceiro nível para quebras (qual unidade falhou), mas só depois que o segundo nível é usado de forma consistente. Observe que as categorias planejadas ficam separadas: elas são excluídas do OEE, mas importam nas comparações de OEE vs TEEP.

Paradas curtas abaixo do seu limite de microparada não devem pedir motivo algum. Elas são frequentes demais para apontamento manual e são mais bem explicadas pelos códigos de falha da máquina, como mostra o caso de uso de monitoramento de linha de embalagem.

Armazenando a árvore como dado

Mantenha a árvore em um único documento JSON e publique-o como retained message MQTT. Todo terminal de operador assina esse topic, então alterar um código significa atualizar uma mensagem em vez de reinstalar aplicativos.

{
  "version": 3,
  "min_prompt_seconds": 180,
  "categories": [
    {"id": "BRK", "label": "Breakdown", "loss": "availability", "reasons": [
      {"code": "BRK-MECH", "label": "Mechanical failure"},
      {"code": "BRK-ELEC", "label": "Electrical or control fault"},
      {"code": "BRK-TOOL", "label": "Tooling or fixture failure"}
    ]},
    {"id": "CHG", "label": "Changeover", "loss": "availability", "reasons": [
      {"code": "CHG-PROD", "label": "Product changeover"},
      {"code": "CHG-TOOL", "label": "Tool change"},
      {"code": "CHG-FAI", "label": "First-article approval"}
    ]},
    {"id": "WAIT", "label": "Waiting", "loss": "availability", "reasons": [
      {"code": "WAIT-MAT", "label": "Waiting for material"},
      {"code": "WAIT-OPR", "label": "Waiting for operator"},
      {"code": "WAIT-QA", "label": "Waiting for quality release"}
    ]},
    {"id": "PLN", "label": "Planned", "loss": "planned", "reasons": [
      {"code": "PLN-BRK", "label": "Break or meeting"},
      {"code": "PLN-PM", "label": "Planned maintenance"},
      {"code": "PLN-NOS", "label": "No orders scheduled"}
    ]},
    {"id": "OTH", "label": "Other", "loss": "availability", "reasons": [
      {"code": "OTH", "label": "Other", "comment_required": true}
    ]}
  ]
}

Publique-o uma vez (retido) em um topic no nível da planta. No servidor MQTT público, use um prefixo aleatório próprio:

mosquitto_pub -h broker.connectmq.com -p 1883 -i reasons-admin-b3z5 -r -q 1 -t "connectmq/demo/b3z5/plant1/config/downtime-reasons" -f reasons.json

O fluxo de apontamento do operador

O fluxo que funciona melhor no chão de fábrica é guiado por solicitação:

1. O sensor da máquina ou o CLP publica STOPPED no topic de estado da máquina. A contagem de tempo começa automaticamente. Veja rastreamento de paradas de máquina para o lado do sensor.
2. Se a parada durar mais que min_prompt_seconds, o terminal na máquina mostra a tela de categorias.
3. O operador toca em uma categoria e depois em um motivo. Dois toques, alguns segundos.
4. O terminal publica o motivo no topic reason da máquina com o horário de início da parada, para que o registrador possa associá-lo ao evento certo mesmo que chegue atrasado.
5. Quando a máquina volta a operar, o evento aberto é fechado. Se nenhum motivo foi informado, o supervisor o vê em uma lista de "não explicadas" ao fim do turno.

Aqui está o núcleo de um terminal baseado em navegador usando MQTT.js sobre WebSocket seguro. A renderização dos botões fica por conta do seu framework de UI; o que importa é a lógica MQTT.

import mqtt from "mqtt";

const PREFIX = "connectmq/demo/b3z5/plant1";
const MACHINE = "stamping/press04";
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId: "terminal-press04-" + Math.random().toString(16).slice(2, 8),
  protocolVersion: 5,
});

let tree = null;
let stoppedAt = null;
let promptTimer = null;

client.on("connect", () => {
  client.subscribe(`${PREFIX}/config/downtime-reasons`, { qos: 1 });
  client.subscribe(`${PREFIX}/${MACHINE}/state`, { qos: 1 });
});

client.on("message", (topic, payload) => {
  const data = JSON.parse(payload.toString());
  if (topic.endsWith("/downtime-reasons")) {
    tree = data;
    return;
  }
  if (data.state === "STOPPED" && stoppedAt === null) {
    stoppedAt = Date.now();
    promptTimer = setTimeout(() => showCategories(tree.categories), tree.min_prompt_seconds * 1000);
  } else if (data.state === "RUNNING") {
    clearTimeout(promptTimer);
    stoppedAt = null;
  }
});

export function submitReason(code, comment = "") {
  const msg = { code, comment, stop_started: stoppedAt, entered: Date.now() };
  client.publish(`${PREFIX}/${MACHINE}/reason`, JSON.stringify(msg), { qos: 1 });
  hidePrompt();
}

function showCategories(categories) {
  // Renderize um botão grande por categoria, depois os motivos da categoria escolhida,
  // e chame submitReason(reason.code) quando um motivo for tocado.
  console.log("Prompt operator with", categories.map((c) => c.label));
}

function hidePrompt() {
  console.log("Prompt closed");
}

Se você prefere low-code, o mesmo fluxo é fácil no Node-RED com botões do Dashboard 2.0 e um nó mqtt out, configurado contra broker.connectmq.com na porta 1883 para testes ou na 8883 com TLS em produção.

Implantando e mantendo os códigos

• Faça um piloto em uma linha por duas semanas. Observe quais códigos são usados, quais nunca são e o que as pessoas escrevem em "Outros".
• Treine com exemplos reais. Mostre aos operadores cinco paradas recentes e peça que as codifiquem juntos. As divergências revelam códigos ambíguos.
• Dê retorno. Exiba os principais motivos na linha toda semana. Os operadores apontam dados melhores quando veem que eles são usados.
• Versione a árvore. Mantenha o campo version e armazene-o com cada motivo, para que os relatórios continuem corretos depois que os códigos mudarem.
• Traduza os rótulos, não os códigos. Em plantas multilíngues, mantenha os códigos estáveis e adicione campos de rótulo por idioma, para que os relatórios se consolidem corretamente independentemente do idioma do terminal.
• Audite o momento do apontamento. Compare quando o motivo foi informado com quando a parada começou. Motivos informados muito depois de a máquina voltar a operar são menos confiáveis e apontam problemas de solicitação ou de pessoal.

Como a árvore vive em uma única retained message no seu broker ConnectMQ, publicar uma nova versão atualiza todos os terminais na próxima reconexão, e o explorador de topics do portal mostra exatamente qual versão está ativa.

Hospedando o fluxo de dados

Durante o projeto, o servidor MQTT público em broker.connectmq.com é suficiente; ele serve para testes e protótipos, não para dados de produção. Em produção, motivos e estados devem ficar em um broker privado. A ConnectMQ oferece um broker MQTT gerenciado com credenciais por cliente e WebSocket seguro na porta 8084, para que terminais de navegador se conectem diretamente, sem backend. O explorador de topics ao vivo do portal facilita conferir se os motivos chegam aos topics certos. Para ver como os dados de motivo se encaixam em um programa mais amplo da planta, consulte o guia de manufatura inteligente.

Comece com a ConnectMQ

Cadastre-se gratuitamente em app.connectmq.com, crie um broker Serverless sem cartão de crédito, publique sua árvore de motivos e conecte hoje mesmo o seu primeiro terminal de operador.

Perguntas frequentes

Quantos códigos de motivo de parada devemos ter?

Poucos o bastante para que o operador escolha em dois toques: normalmente de cinco a sete categorias com três a cinco motivos cada. Aumente a lista apenas quando os comentários em "Outros" mostrarem uma causa recorrente.

O operador deve informar horários de início e fim?

Não. Deixe a máquina detectar as paradas automaticamente e peça ao operador apenas o motivo. O apontamento manual de tempo é a principal fonte de dados de parada imprecisos.

O que fazer com paradas sem motivo?

Mostre-as como não explicadas ao supervisor no fim do turno. Uma parcela alta de paradas não explicadas geralmente indica que os códigos ou o momento da solicitação precisam de ajustes.

Os alarmes da máquina podem substituir os motivos do operador?

Em parte. Os códigos de alarme explicam bem muitas falhas e microparadas, mas esperas, setups e problemas de material ainda precisam de uma resposta humana.