Cómo diseñar códigos de motivo de parada que los operarios realmente usen

Los códigos de motivo de parada deciden si tus datos de paradas llevan a la acción o solo llenan una base de datos. Esta guía muestra cómo diseñar un árbol de motivos corto y estructurado que los operarios puedan usar en pocos segundos, cómo vincularlo a las pérdidas del OEE y cómo construir un flujo de entrada que publique los motivos por MQTT junto a los estados de máquina que tus sensores ya detectan. Terminarás con un árbol inicial, un formato JSON para él y código funcional para el lado del operario.

Por qué fracasan la mayoría de las listas de códigos

Las plantas suelen empezar a registrar paradas con buenas intenciones y una lista larga. En pocos meses los datos muestran el mismo patrón: una gran parte de las paradas codificadas como "Otros" o "Varios", unos pocos códigos usados para todo y docenas que nunca se usan. Las causas de fondo son previsibles:

• Demasiados códigos. Un operario frente a una lista desplegable de sesenta opciones elige la primera que parece encajar.
• Códigos con nombre de departamento. "Mantenimiento" o "Calidad" describen quién es responsable, no qué ocurrió, así que nadie puede actuar sobre ello.
• Significados que se solapan. "Atasco" y "Problema de material" encajan ambos con un fallo de alimentación, de modo que el mismo evento recibe dos códigos distintos según quién esté de turno.
• Sin vínculo con la detección. Si el operario además tiene que anotar cuándo empezó y terminó la parada, la precisión se desploma. Los tiempos deben venir de la máquina; solo el motivo debe venir de una persona.

La solución es una jerarquía corta, una redacción específica y la detección automática del estado.

Principios para unos buenos códigos de motivo de parada

1. Separa la detección de la explicación. Las máquinas informan RUNNING y STOPPED automáticamente; los operarios solo responden "¿por qué?".
2. Usa un árbol, no una lista plana. Dos o tres niveles: una categoría, un motivo y, opcionalmente, un detalle. Cada pantalla muestra solo unas pocas opciones.
3. Nombra la causa, no el departamento. "Esperando material" es mejor que "Logística".
4. Haz que los códigos sean mutuamente excluyentes. Si dos códigos pueden describir el mismo evento, fusiónalos o escribe una definición de una línea que los distinga.
5. Mantén un nivel superior pequeño y fijo. Vincula el nivel superior a las pérdidas del OEE para que los informes se agreguen automáticamente.
6. Limita "Otros". Exige un comentario de texto libre cuando se elija "Otros" y revisa esos comentarios cada semana; los recurrentes se convierten en códigos nuevos.
7. Deja que las alarmas de la máquina completen lo que puedan. Si el controlador informa un código de fallo, propone el motivo correspondiente y deja que el operario lo confirme.
8. Revisa el árbol con regularidad. Retira los códigos que no se usan y divide los que esconden demasiado.

Un árbol de códigos inicial

Úsalo como punto de partida y adapta el segundo nivel a tu proceso. El nivel superior se corresponde limpiamente con disponibilidad, rendimiento y tiempo planificado.

Quince códigos en seis categorías caben en dos pantallas. Algunas plantas añaden un tercer nivel para las averías (qué unidad falló), pero solo cuando el segundo nivel se usa de forma coherente. Observa que las categorías planificadas se mantienen aparte: se excluyen del OEE, pero importan en las comparaciones de OEE frente a TEEP.

Las paradas cortas por debajo de tu umbral de microparada no deberían pedir motivo. Son demasiado frecuentes para la entrada manual y se explican mejor con los códigos de fallo de la máquina, como se muestra en el caso de uso de monitorización de líneas de envasado.

Guardar el árbol como datos

Mantén el árbol en un único documento JSON y publícalo como mensaje MQTT retenido (retained message). Cada terminal de operario se suscribe a él, así que cambiar un código significa actualizar un mensaje en lugar de reinstalar aplicaciones.

{
  "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}
    ]}
  ]
}

Publícalo una vez (retenido) en un topic de nivel de planta. En el servidor MQTT público gratuito, usa tu propio prefijo aleatorio:

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

El flujo de entrada del operario

El flujo que mejor funciona en planta es el guiado por avisos:

1. El sensor de la máquina o el PLC publica STOPPED en el topic de estado de la máquina. El cronometraje empieza automáticamente. Consulta seguimiento de paradas de máquina para la parte de sensores.
2. Si la parada dura más de min_prompt_seconds, el terminal junto a la máquina muestra la pantalla de categorías.
3. El operario toca una categoría y luego un motivo. Dos toques, unos segundos.
4. El terminal publica el motivo en el topic reason de la máquina con la hora de inicio de la parada, para que el registrador pueda asociarlo al evento correcto aunque llegue tarde.
5. Cuando la máquina vuelve a arrancar, el evento abierto se cierra. Si no se introdujo ningún motivo, el supervisor lo ve en una lista de "sin explicar" al final del turno.

Este es el núcleo de un terminal basado en navegador que usa MQTT.js sobre WebSocket seguro. Dibujar los botones queda en manos de tu framework de interfaz; lo que importa es la 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) {
  // Dibuja un botón grande por categoría, luego los motivos de la elegida,
  // y llama a submitReason(reason.code) cuando se toque un motivo.
  console.log("Prompt operator with", categories.map((c) => c.label));
}

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

Si prefieres low-code, el mismo flujo es sencillo en Node-RED con botones de Dashboard 2.0 y un nodo mqtt out, configurado contra broker.connectmq.com en el puerto 1883 para pruebas o en el 8883 con TLS en producción.

Despliegue y mantenimiento de los códigos

• Haz un piloto en una línea durante dos semanas. Observa qué códigos se usan, cuáles nunca se usan y qué escribe la gente en "Otros".
• Forma con ejemplos reales. Muestra a los operarios cinco paradas recientes y pídeles que las codifiquen juntos. Los desacuerdos revelan códigos ambiguos.
• Devuelve la información. Muestra los motivos principales en la línea cada semana. Los operarios introducen mejores datos cuando ven que se usan.
• Versiona el árbol. Conserva el campo version y guárdalo con cada motivo, para que los informes sigan siendo correctos tras cambiar los códigos.
• Traduce las etiquetas, no los códigos. En plantas multilingües, mantén los códigos estables y añade campos de etiqueta por idioma, para que los informes se agreguen correctamente sea cual sea el idioma del terminal.
• Audita el momento del motivo. Compara cuándo se introdujo el motivo con cuándo empezó la parada. Los motivos introducidos mucho después de que la máquina rearrancara son menos fiables y apuntan a problemas con el aviso o con la dotación de personal.

Como el árbol vive en un único mensaje retenido en tu broker de ConnectMQ, publicar una nueva versión actualiza todos los terminales en la siguiente reconexión, y el explorador de topics del portal muestra exactamente qué versión está activa.

Alojamiento del flujo de datos

Durante el diseño, el servidor MQTT público gratuito en broker.connectmq.com es suficiente; recuerda que es para pruebas y prototipos, no para datos de producción. En producción, los motivos y los estados deben ir a un broker privado. ConnectMQ ofrece un broker MQTT gestionado con credenciales por cliente y WebSocket seguro en el puerto 8084, de modo que los terminales de navegador se conectan directamente sin backend. El explorador de topics en vivo del portal facilita comprobar que los motivos llegan a los topics correctos. Si además quieres ver cada parada sobre un gemelo digital 3D de la línea, los mismos topics sirven como fuente. Para ver cómo encajan los datos de motivos en un programa de planta más amplio, consulta la guía de fabricación inteligente.

Empieza con ConnectMQ

Regístrate gratis en app.connectmq.com, crea un broker Serverless sin tarjeta de crédito, publica tu árbol de motivos y conecta hoy mismo tu primer terminal de operario.

Preguntas frecuentes

¿Cuántos códigos de motivo de parada deberíamos tener?

Los suficientemente pocos para que los operarios elijan en dos toques: normalmente de cinco a siete categorías con tres a cinco motivos cada una. Amplía la lista solo cuando los comentarios de "Otros" muestren una causa recurrente.

¿Deben los operarios introducir las horas de inicio y fin?

No. Deja que la máquina detecte las paradas automáticamente y pide al operario solo el motivo. El cronometraje manual es la principal fuente de datos de paradas inexactos.

¿Qué debe pasar con las paradas sin motivo?

Muéstralas como "sin explicar" al supervisor al final del turno. Una proporción alta de paradas sin explicar suele indicar que hay que mejorar los códigos o el momento del aviso.

¿Pueden las alarmas de la máquina sustituir los motivos del operario?

En parte. Los códigos de alarma explican bien muchos fallos y microparadas, pero las esperas, los cambios y los problemas de material siguen necesitando una respuesta humana.