Solutions pour l'opérateur connecté avec MQTT : instructions et alertes en temps réel

Un opérateur connecté est un opérateur, un technicien ou un superviseur dont les appareils reçoivent la bonne information au bon moment : la prochaine instruction de travail, une alarme machine, un blocage qualité ou une demande d'aide. Cet article présente les cas d'usage de l'opérateur connecté qui apportent de la valeur dans l'atelier, la manière de structurer les topics MQTT sous-jacents et un client navigateur fonctionnel qui reçoit des tâches et envoie des acquittements via WebSocket sécurisé.

Ce que fait réellement une solution pour l'opérateur connecté

Dans l'industrie, la plupart des opérateurs de terrain découvrent encore les problèmes en passant devant. Une machine attend de la matière jusqu'à ce que quelqu'un s'en aperçoive, un technicien de maintenance est appelé par radio, et les instructions de travail sont rangées dans un classeur au poste. Les solutions pour l'opérateur connecté comblent ce manque en apportant les données de l'usine en direct aux personnes, au lieu d'amener les personnes aux données.

Fonctionnalités typiques :

• Instructions de travail numériques qui changent automatiquement selon l'ordre de fabrication ou la variante en cours.
• Alertes ciblées : un arrêt machine est envoyé sur la montre du technicien responsable, pas à tout le monde.
• Demandes d'aide et escalade : un opérateur appuie sur « besoin de matière » et la demande est escaladée si personne ne l'accepte en quelques minutes.
• Check-lists et validations : contrôles de démarrage, contrôles qualité et changements de série enregistrés avec qui et quand.
• Retour d'information bidirectionnel : les opérateurs ajoutent des codes motifs, des références de photos ou des commentaires qui remontent dans les données.

Le mot clé est temps réel. Une liste de tâches rafraîchie toutes les quelques minutes ne suffit pas quand une ligne s'arrête ; les événements doivent arriver en quelques secondes.

Cas d'usage de l'opérateur connecté dans l'atelier

Beaucoup de ces cas recoupent un système andon numérique ; la différence est qu'une solution pour l'opérateur connecté achemine les événements vers des appareils individuels et enregistre la réponse de chaque personne.

Pourquoi MQTT convient aux applications pour l'opérateur connecté

Les appareils de terrain sont mobiles, fonctionnent sur batterie et se trouvent souvent sur un Wi-Fi inégal. La conception de MQTT correspond à cet environnement :

• Push plutôt que polling. Les appareils maintiennent une connexion légère et reçoivent les événements instantanément, ce qui économise batterie et réseau par rapport à l'interrogation d'une API.
• Fonctionne dans le navigateur. Grâce à MQTT over WebSocket, une simple application web sur tablette peut s'abonner sans rien installer.
• Les retained messages donnent à un appareil l'état actuel (ordre en cours, appels ouverts) dès qu'il se reconnecte.
• Les sessions persistantes avec expiration de session permettent à un appareil qui traverse une zone blanche de recevoir les messages QoS 1 mis en file pendant son absence.
• Le request/response de MQTT 5, avec response topics et correlation data, correspond naturellement au schéma « tâche envoyée, tâche acceptée ».

Conception des topics

Organisez les topics par zone de l'usine pour les événements diffusés, et par rôle ou par personne pour les tâches ciblées :

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

La tablette d'un technicien s'abonne à son rôle, à son propre topic utilisateur et aux appels ouverts de sa zone. Pour effacer un appel retained, on publie un message retained vide sur le même topic, ce qui le retire de tous les appareils en même temps.

Un client navigateur via WebSocket sécurisé

L'exemple ci-dessous est un client minimal pour l'opérateur connecté, écrit avec MQTT.js v5. Il se connecte en WebSocket sécurisé sur le port 8084, s'abonne aux appels ouverts et aux tâches personnelles, et publie une acceptation avec l'identifiant de l'opérateur. Il fonctionne dans n'importe quel bundle pour navigateur moderne (Vite, webpack) après npm install mqtt.

import mqtt from "mqtt";

const prefix = "connectmq/demo/cw-4f19";          // utilisez votre propre identifiant aléatoire
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 },   // conserve les messages QoS 1 en file pendant 30 minutes
  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);                     // appel résolu, retained message effacé
    } 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 })));
}

Lancez un appel de test depuis la ligne de commande et regardez-le apparaître sur l'appareil ; effacez-le ensuite avec un message retained vide :

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"

Le serveur MQTT public gratuit prend en charge les QoS 0 à 2 et une expiration de session jusqu'à 30 minutes, ce qui suffit pour tester le comportement à la reconnexion. N'oubliez pas que sa zone publique est lisible par tous : n'y envoyez jamais de vrais noms ni de données d'usine.

Check-list de déploiement pour les projets d'opérateur connecté

1. Commencez par un processus douloureux, généralement les appels pour arrêt machine ou les appels matière, et mesurez le temps de réponse avant et après.
2. Impliquez les opérateurs tôt. Si une alerte n'est que du bruit pour eux, elle sera ignorée ou mise en sourdine.
3. Acheminez par rôle et par zone, pas vers tout le monde. Les diffusions générales créent vite une fatigue des alertes.
4. Concevez l'escalade : si personne n'accepte un appel dans un délai défini, envoyez-le au niveau suivant.
5. Faites en sorte que les appareils se rétablissent en silence. Utilisez l'état retained et les sessions persistantes pour qu'une reconnexion ne demande aucune action de l'utilisateur.
6. Utilisez des identifiants uniques par appareil ou par instance d'application, uniquement via TLS ou WebSocket sécurisé.
7. Enregistrez les réponses dans une base de données pour analyser les temps de réponse et alimenter l'amélioration continue.
8. Prévoyez les appareils partagés : une connexion par poste détermine à quel topic utilisateur s'abonne la tablette d'un poste.

Mesurer si cela fonctionne

Un projet d'opérateur connecté doit prouver sa valeur avec des chiffres auxquels l'usine tient déjà. Comme chaque appel et chaque réponse est un événement MQTT, vous pouvez mesurer sans effort supplémentaire :

• Délai d'acceptation : entre le lancement de l'appel et son acceptation par une personne.
• Délai d'arrivée : entre l'acceptation et la confirmation par le technicien de son arrivée au poste.
• Délai de résolution : entre l'appel et le redémarrage de la ligne, directement lié aux arrêts.
• Taux d'escalade : la fréquence des appels restés sans réponse au premier niveau, signe d'un sous-effectif ou d'un mauvais acheminement.
• Appels par poste de travail et par équipe : un appel récurrent au même poste est un problème à résoudre, pas seulement à traiter.

Passez-les en revue avec l'équipe chaque semaine pendant le pilote. L'objectif n'est pas de courir plus vite d'un incendie à l'autre, mais d'avoir moins d'incendies : faites donc remonter les causes récurrentes dans votre processus d'amélioration.

Faire évoluer les applications pour l'opérateur connecté sur ConnectMQ

Chaque tablette, montre et écran de ligne maintient sa propre connexion : le nombre de connexions augmente donc rapidement. ConnectMQ est un broker MQTT managé qui fournit le WebSocket sécurisé sur le port 8084 avec un certificat Let's Encrypt, afin que les applications navigateur se connectent sans contournement de certificat. L'offre Serverless gratuite couvre un pilote jusqu'à 25 connexions, l'offre Serverless payante monte jusqu'à 1 000 connexions avec QoS 2 et shared subscriptions, et les clusters Dedicated isolent les déploiements plus importants. La logique d'escalade et la journalisation des réponses s'exécutent dans vos propres services, comme un flux Node-RED ou un petit worker Node.js, connectés comme des clients ordinaires.

Pour le contexte complet de l'usine, consultez le guide de l'industrie intelligente ; la présentation du broker MQTT cloud explique comment un broker hébergé connecte en toute sécurité l'usine et les appareils mobiles.

Connectez vos opérateurs avec ConnectMQ

Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire, copiez le nom d'utilisateur, le mot de passe et le client ID générés dans le client navigateur ci-dessus et envoyez dès aujourd'hui votre premier appel en direct vers une tablette.

Questions fréquentes

Quels appareils peuvent servir à l'opérateur connecté ?

Tablettes, smartphones, montres connectées, terminaux durcis et grands écrans de ligne conviennent tous. Tout appareil doté d'un navigateur moderne peut utiliser MQTT over WebSocket sécurisé ; les applications natives peuvent utiliser directement une bibliothèque MQTT.

Comment les opérateurs reçoivent-ils les messages manqués pendant qu'ils étaient hors ligne ?

Utilisez une session persistante avec un intervalle d'expiration de session et des abonnements en QoS 1, afin que le broker mette les messages en file pendant que l'appareil est déconnecté. Les retained messages fournissent l'état actuel à la reconnexion.

Chaque appareil doit-il avoir ses propres identifiants ?

Oui. Des identifiants et des client ID uniques par appareil ou par instance d'application permettent de révoquer une tablette perdue sans affecter les autres et de savoir qui a envoyé quelle réponse.

Une plateforme pour l'opérateur connecté est-elle la même chose qu'un système andon ?

Elles se recoupent. L'andon rend les problèmes visibles sur la ligne ; une solution pour l'opérateur connecté achemine aussi les tâches vers des personnes précises et enregistre leurs réponses.