Concevoir des codes causes d'arrêt que les opérateurs utilisent vraiment

Les codes causes d'arrêt déterminent si vos données d'arrêts débouchent sur des actions ou se contentent de remplir une base de données. Ce guide montre comment concevoir un arbre de causes court et structuré, utilisable par les opérateurs en quelques secondes, comment le rattacher aux pertes du TRS (OEE) et comment construire un parcours de saisie qui publie les causes en MQTT à côté des états machine que vos capteurs détectent déjà. Vous repartirez avec un arbre de départ, un format JSON pour le décrire et du code fonctionnel pour le poste opérateur.

Pourquoi la plupart des listes de codes échouent

Les usines démarrent généralement le suivi des arrêts avec de bonnes intentions et une longue liste. En quelques mois, les données montrent toujours le même schéma : une grande part des arrêts codés « Autre » ou « Divers », quelques codes utilisés pour tout, et des dizaines jamais utilisés. Les causes profondes sont prévisibles :

• Trop de codes. Face à une liste déroulante de soixante options, l'opérateur choisit la première plausible.
• Des codes nommés d'après les services. « Maintenance » ou « Qualité » désigne qui est responsable, pas ce qui s'est passé : personne ne peut agir dessus.
• Des sens qui se recouvrent. « Bourrage » et « Problème matière » conviennent tous deux à un défaut d'alimentation : le même événement reçoit deux codes différents selon l'équipe en poste.
• Aucun lien avec la détection. Si l'opérateur doit aussi noter quand l'arrêt a commencé et fini, la précision s'effondre. La chronologie doit venir de la machine ; seule la cause doit venir d'une personne.

La solution : une hiérarchie courte, une formulation précise et une détection automatique de l'état.

Principes de bons codes causes d'arrêt

1. Séparer la détection de l'explication. Les machines signalent RUNNING et STOPPED automatiquement ; les opérateurs répondent seulement à « pourquoi ? ».
2. Utiliser un arbre, pas une liste plate. Deux ou trois niveaux : une catégorie, une cause et éventuellement un détail. Chaque écran n'affiche qu'une poignée de choix.
3. Nommer la cause, pas le service. « Attente matière » vaut mieux que « Logistique ».
4. Rendre les codes mutuellement exclusifs. Si deux codes peuvent décrire le même événement, fusionnez-les ou rédigez une définition d'une ligne qui les distingue.
5. Garder un premier niveau court et fixe. Rattachez le premier niveau aux pertes du TRS pour que les rapports se consolident automatiquement.
6. Limiter « Autre ». Exigez un commentaire libre quand « Autre » est choisi et relisez ces commentaires chaque semaine ; ceux qui reviennent deviennent de nouveaux codes.
7. Laisser les alarmes machine pré-remplir quand c'est possible. Si l'automate remonte un code défaut, proposez la cause correspondante et laissez l'opérateur confirmer.
8. Revoir l'arbre régulièrement. Retirez les codes inutilisés et scindez ceux qui masquent trop de situations.

Un arbre de codes causes de départ

Servez-vous-en comme point de départ et adaptez le deuxième niveau à votre procédé. Le premier niveau se rattache proprement à la disponibilité, à la performance et au temps planifié.

Quinze codes répartis en six catégories tiennent sur deux écrans. Certaines usines ajoutent un troisième niveau pour les pannes (quel organe a lâché), mais seulement une fois que le deuxième niveau est utilisé de façon cohérente. Notez que les catégories planifiées restent à part : elles sont exclues du TRS mais comptent pour les comparaisons TRS vs TEEP.

Les arrêts courts sous votre seuil de micro-arrêt ne doivent pas demander de cause du tout. Ils sont trop fréquents pour une saisie manuelle et s'expliquent mieux par les codes défaut machine, comme le montre le cas d'usage de surveillance d'une ligne de conditionnement.

Stocker l'arbre sous forme de données

Conservez l'arbre dans un seul document JSON et publiez-le comme retained message MQTT. Chaque terminal opérateur s'y abonne : modifier un code revient à mettre à jour un message, pas à réinstaller des applications.

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

Publiez-le une fois (en retained) sur un topic de niveau usine. Sur le serveur MQTT public gratuit, utilisez votre propre préfixe aléatoire :

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

Le parcours de saisie opérateur

Le parcours qui fonctionne le mieux en atelier est déclenché par une invite :

1. Le capteur de la machine ou l'automate publie STOPPED sur le topic d'état de la machine. Le chronométrage démarre automatiquement. Voir le suivi des arrêts machine pour la partie capteur.
2. Si l'arrêt dure plus de min_prompt_seconds, le terminal de la machine affiche l'écran des catégories.
3. L'opérateur touche une catégorie, puis une cause. Deux touches, quelques secondes.
4. Le terminal publie la cause sur le topic reason de la machine avec l'heure de début de l'arrêt, pour que l'enregistreur puisse l'associer au bon événement même si elle arrive en retard.
5. Au redémarrage de la machine, l'événement ouvert se ferme. Si aucune cause n'a été saisie, le chef d'équipe la voit dans une liste « non expliqués » en fin de poste.

Voici le cœur d'un terminal dans le navigateur, basé sur MQTT.js via WebSocket sécurisé. L'affichage des boutons est laissé à votre framework d'interface ; c'est la logique MQTT qui compte.

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) {
  // Afficher un grand bouton par catégorie, puis les causes de la catégorie choisie,
  // et appeler submitReason(reason.code) quand une cause est touchée.
  console.log("Prompt operator with", categories.map((c) => c.label));
}

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

Si vous préférez le low-code, le même parcours se construit facilement dans Node-RED avec des boutons Dashboard 2.0 et un nœud mqtt out, configuré sur broker.connectmq.com au port 1883 pour les tests ou 8883 avec TLS en production.

Déployer et maintenir les codes

• Pilotez sur une ligne pendant deux semaines. Observez quels codes sont utilisés, lesquels ne le sont jamais et ce que les gens écrivent sous « Autre ».
• Formez avec des exemples réels. Montrez aux opérateurs cinq arrêts récents et demandez-leur de les coder ensemble. Les désaccords révèlent les codes ambigus.
• Faites un retour. Affichez chaque semaine les principales causes sur la ligne. Les opérateurs saisissent de meilleures données quand ils les voient utilisées.
• Versionnez l'arbre. Conservez le champ version et enregistrez-le avec chaque cause, pour que les rapports restent justes après un changement de codes.
• Traduisez les libellés, pas les codes. Dans les usines multilingues, gardez des codes stables et ajoutez un champ de libellé par langue, pour que les rapports se consolident correctement quelle que soit la langue du terminal.
• Auditez le délai de saisie. Comparez le moment où la cause a été saisie avec le début de l'arrêt. Les causes saisies longtemps après le redémarrage sont moins fiables et signalent un problème d'invite ou d'effectifs.

Comme l'arbre vit dans un seul retained message sur votre broker ConnectMQ, publier une nouvelle version met à jour chaque terminal à sa prochaine reconnexion, et l'explorateur de topics du portail montre exactement quelle version est active.

Héberger le flux de données

Pendant la conception, le serveur MQTT public gratuit broker.connectmq.com suffit ; il sert aux tests et prototypes, pas aux données de production. En production, causes et états doivent passer par un broker privé. ConnectMQ propose un broker MQTT managé avec des identifiants par client et un WebSocket sécurisé sur le port 8084 : les terminaux dans le navigateur se connectent directement, sans backend. L'explorateur de topics en direct du portail permet de vérifier facilement que les causes arrivent sur les bons topics. Pour voir comment les données de causes s'intègrent dans un programme d'usine plus large, consultez le guide de l'industrie intelligente.

Démarrer avec ConnectMQ

Inscrivez-vous gratuitement sur app.connectmq.com, créez un broker Serverless sans carte bancaire, publiez votre arbre de causes et connectez dès aujourd'hui votre premier terminal opérateur.

Questions fréquentes

Combien de codes causes d'arrêt faut-il prévoir ?

Assez peu pour que les opérateurs choisissent en deux touches : généralement cinq à sept catégories de trois à cinq causes chacune. N'allongez la liste que lorsque les commentaires « Autre » révèlent une cause récurrente.

Les opérateurs doivent-ils saisir les heures de début et de fin ?

Non. Laissez la machine détecter les arrêts automatiquement et ne demandez à l'opérateur que la cause. Le chronométrage manuel est la principale source de données d'arrêts inexactes.

Que faire des arrêts sans cause ?

Présentez-les comme non expliqués au chef d'équipe en fin de poste. Une part élevée de non expliqués signifie généralement que les codes ou le délai d'invite doivent être retravaillés.

Les alarmes machine peuvent-elles remplacer les causes saisies par l'opérateur ?

En partie. Les codes d'alarme expliquent bien de nombreux défauts et micro-arrêts, mais les attentes, les changements de série et les problèmes de matière nécessitent toujours une réponse humaine.