Un tableau de bord de suivi de ligne de production transforme les signaux bruts des machines en un seul écran qui indique aux chefs d'équipe si la ligne tourne, combien de pièces bonnes elle a produites et où elle perd du temps. Dans ce tutoriel, vous publierez les données des postes en MQTT, les stockerez avec Telegraf et InfluxDB, puis construirez le tableau de bord dans Grafana, avec une alternative plus légère sous Node-RED pour les petites lignes. Tout fonctionne avec un vrai broker : vous pouvez suivre depuis un simple ordinateur portable.
Ce qu'un bon tableau de bord de ligne doit afficher
Avant de câbler quoi que ce soit, décidez à quelles questions l'écran doit répondre. La plupart des tableaux de bord de ligne échouent parce qu'ils affichent toutes les variables exposées par l'automate au lieu des quelques questions que les gens se posent réellement pendant un poste.
| Question à l'atelier | Signal nécessaire | Widget typique |
|---|---|---|
| Chaque poste tourne-t-il en ce moment ? | state (RUNNING, IDLE, DOWN, SETUP) |
Tuiles d'état codées par couleur |
| Sommes-nous dans le plan pour ce poste ? | Pièces bonnes, objectif | Grand chiffre et barre de progression |
| D'où viennent les rebuts ? | Rebuts par poste | Histogramme par poste |
| Quel poste est le goulot d'étranglement ? | Cadence réelle vs cadence idéale | Tableau trié par écart de cadence |
| Quelle est la santé globale de la ligne ? | Disponibilité, performance, qualité | Jauge de TRS avec trois sous-barres |
| Qu'est-ce qui nous a arrêtés la dernière heure ? | Changements d'état horodatés | Chronologie des états |
Limitez la première version à ces six éléments. Les chefs d'équipe en demanderont davantage dès qu'ils feront confiance aux chiffres, et cette confiance vient de compteurs qui correspondent à ce qu'ils voient sur le terrain.
Architecture : du poste à l'écran
Le chemin des données est court et chaque brique est remplaçable :
- Chaque poste (passerelle automate, PC industriel en périphérie ou microcontrôleur) publie un petit message d'état JSON vers un broker MQTT à chaque changement d'état et au moins toutes les quelques secondes.
- Telegraf s'abonne aux topics de la ligne et écrit chaque message dans InfluxDB sous forme de série temporelle.
- Grafana interroge InfluxDB et affiche les panneaux.
- En option, un flow Node-RED s'abonne aux mêmes topics et pilote un tableau de bord léger sur un écran installé près de la ligne.
Le broker est le point central qui découple les postes des consommateurs. Si ce rôle est nouveau pour vous, cet article sur le rôle d'un broker MQTT en présente les bases. Comme chaque consommateur s'abonne indépendamment, vous pourrez ajouter plus tard un historien, un tableau andon ou un calculateur de TRS sans toucher aux postes.
Étape 1 : concevoir la structure des topics
Une arborescence de topics prévisible fait gagner des heures par la suite. Utilisez une hiérarchie de type ISA-95 afin que le tableau de bord puisse filtrer par ligne et par poste avec des jokers :
connectmq/demo/<your-id>/line1/<station>/status
Par exemple connectmq/demo/a7f3k9/line1/filler/status. Le payload est un unique objet JSON :
{
"state": "RUNNING",
"good": 1842,
"reject": 17,
"rate": 58.5,
"ideal_rate": 60,
"ts": 1792137600
}
Les compteurs sont cumulés sur le poste de travail, ce qui rend les données robustes : si un message est perdu, le suivant porte toujours le bon total. Les cadences sont exprimées en pièces par minute. Ajoutez un niveau entreprise et site devant la ligne lorsque vous déployez sur plus d'une usine.
Étape 2 : simuler les postes
Pour construire le tableau de bord avant que la vraie ligne ne soit raccordée, lancez ce simulateur Python. Il utilise paho-mqtt 2.x et le serveur MQTT public gratuit broker.connectmq.com. Remplacez a7f3k9 par votre propre identifiant aléatoire, car l'espace public est lisible par tout le monde.
import json
import random
import time
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/a7f3k9/line1"
STATIONS = {"filler": 60, "capper": 62, "labeler": 65, "packer": 58}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="line1-sim-a7f3k9")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
counters = {name: {"good": 0, "reject": 0, "state": "RUNNING"} for name in STATIONS}
try:
while True:
for name, ideal in STATIONS.items():
c = counters[name]
# Change d'état de temps en temps pour animer le tableau de bord
roll = random.random()
if c["state"] == "RUNNING" and roll < 0.03:
c["state"] = random.choice(["DOWN", "IDLE"])
elif c["state"] != "RUNNING" and roll < 0.25:
c["state"] = "RUNNING"
rate = 0.0
if c["state"] == "RUNNING":
rate = round(ideal * random.uniform(0.85, 1.0), 1)
made = int(rate / 12) # environ 5 secondes de production
rejects = 1 if random.random() < 0.04 else 0
c["good"] += made - rejects
c["reject"] += rejects
payload = {
"state": c["state"],
"good": c["good"],
"reject": c["reject"],
"rate": rate,
"ideal_rate": ideal,
"ts": int(time.time()),
}
client.publish(f"{PREFIX}/{name}/status", json.dumps(payload), qos=1, retain=True)
time.sleep(5)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Quatre postes publiant toutes les cinq secondes restent largement sous la limite du broker public de 10 messages par seconde et par client. Le flag retain garantit qu'un tableau de bord qui se connecte en cours de poste reçoit immédiatement le dernier état connu de chaque poste. Vérifiez le flux depuis un terminal :
mosquitto_sub -h broker.connectmq.com -p 1883 -i viewer-a7f3k9 -t "connectmq/demo/a7f3k9/line1/+/status" -v
Étape 3 : stocker les données avec Telegraf et InfluxDB
Le consommateur MQTT de Telegraf transforme chaque message en point InfluxDB, et l'analyse des topics extrait la ligne et le poste sous forme de tags. Enregistrez ceci dans telegraf.conf :
[agent]
interval = "5s"
flush_interval = "5s"
[[inputs.mqtt_consumer]]
servers = ["tcp://broker.connectmq.com:1883"]
topics = ["connectmq/demo/a7f3k9/line1/+/status"]
client_id = "telegraf-a7f3k9"
qos = 1
data_format = "json"
json_string_fields = ["state"]
json_time_key = "ts"
json_time_format = "unix"
[[inputs.mqtt_consumer.topic_parsing]]
topic = "connectmq/demo/+/+/+/status"
measurement = "_/_/_/_/_/measurement"
tags = "_/_/_/line/station/_"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "YOUR_INFLUX_TOKEN"
organization = "plant"
bucket = "line"
Chaque point arrive dans la mesure status avec les tags line=line1 et station=filler, ainsi que les champs state, good, reject, rate et ideal_rate. En production, passez le serveur à ssl://broker.connectmq.com:8883 et ajoutez username = "YOUR_USERNAME", password = "YOUR_PASSWORD" ainsi que le client_id qui vous a été attribué. D'autres options sont détaillées dans le guide du consommateur MQTT de Telegraf.
Étape 4 : construire le tableau de bord de suivi de ligne de production dans Grafana
Ajoutez InfluxDB comme source de données dans Grafana (langage de requête Flux) et créez les panneaux suivants.
Tuiles d'état des postes. Utilisez un panneau Stat avec des correspondances de valeurs : RUNNING en vert, IDLE en jaune, DOWN en rouge, SETUP en bleu.
from(bucket: "line")
|> range(start: -5m)
|> filter(fn: (r) => r._measurement == "status" and r._field == "state")
|> last()
|> group(columns: ["station"])
Pièces bonnes sur le poste. Les compteurs étant cumulés, la dernière valeur donne le total :
from(bucket: "line")
|> range(start: today())
|> filter(fn: (r) => r._measurement == "status" and r._field == "good" and r.station == "packer")
|> last()
Prenez le dernier poste de la ligne (ici l'encaisseuse) comme sortie de ligne ; compter à chaque poste revient à compter plusieurs fois les mêmes pièces.
Cadence vs cadence idéale. Un panneau Time series avec rate et ideal_rate par poste révèle le goulot d'un coup d'œil : c'est le poste dont la cadence réelle reste la plus éloignée de sa cadence idéale lorsqu'il tourne.
Chronologie des états. Le panneau State timeline de Grafana, alimenté par le champ state, affiche une barre par poste colorée selon l'état sur toute la durée du poste de travail : c'est le moyen le plus rapide de voir quand et où la ligne s'est arrêtée.
Jauge de TRS. Pour une première version, calculez le TRS (OEE) dans un abonné séparé et publiez le résultat sur line1/oee, puis tracez ce topic. Le calcul est expliqué dans comment calculer le TRS, et le tutoriel de suivi du TRS en temps réel contient un abonné prêt à l'emploi. Faire le calcul une seule fois, en dehors de Grafana, garantit que tous les écrans affichent le même chiffre.
Alternative Node-RED pour une seule ligne
Si vous avez seulement besoin d'un écran près d'une ligne et ne voulez pas de base de séries temporelles, Node-RED est plus rapide. Configurez un nœud de configuration mqtt-broker avec le serveur broker.connectmq.com et le port 1883 (ou 8883 avec TLS et vos identifiants en production), puis ajoutez :
- Un nœud
mqtt inabonné àconnectmq/demo/a7f3k9/line1/+/status, avec une sortie en objet JSON analysé. - Un nœud
functionqui extrait le nom du poste avecmsg.topic.split("/")[4]et l'oriente vers le bon widget. - Des widgets Dashboard 2.0
ui-textpour l'état,ui-gaugepour la cadence et unui-chartpour les pièces bonnes.
Le compromis porte sur l'historique : Node-RED montre bien le présent mais n'est pas un historien. Beaucoup d'usines utilisent les deux, avec Node-RED sur l'écran de ligne et Grafana pour la revue de poste. L'article sur le tableau de bord TRS sous Node-RED va plus loin dans cette approche.
Pièges courants et comment les éviter
- Les compteurs repartent à zéro en cours de poste. Un redémarrage de l'automate ou de la passerelle efface son compteur. Stockez la référence de début de poste en périphérie, ou faites utiliser au tableau de bord
difference()avecnonNegative: trueafin que les remises à zéro ne créent pas de production négative. - Les tuiles affichent un RUNNING périmé. Si un poste se déconnecte, son message retenu indique toujours RUNNING. Ajoutez le champ
tsà la tuile et passez-la en gris au-delà de 30 secondes, ou utilisez un message MQTT Last Will qui publie OFFLINE. - Client ID en double. Deux instances Telegraf avec le même client ID vont s'éjecter mutuellement en permanence. Chaque client a besoin d'un identifiant unique.
- Trop de panneaux. Si l'écran de l'atelier doit défiler, il est trop chargé. Déplacez le détail vers un tableau de bord d'exploration.
De la démo à la production
Le broker public est parfait pour construire, mais ses topics sont visibles par tous. Pour une vraie ligne, passez à un broker privé : un broker MQTT managé vous libère des mises à jour et du dimensionnement d'un serveur, et un broker MQTT cloud permet aux responsables à distance et au siège de consulter le même tableau de bord. Avec ConnectMQ, vous créez le broker dans le portail, obtenez un nom d'utilisateur, un mot de passe et un client ID, et ne modifiez que les paramètres de connexion du simulateur, de Telegraf et de Node-RED. L'explorateur de topics en direct du portail est pratique pour confirmer que chaque poste publie bien avant de déboguer un panneau Grafana vide.
L'offre Serverless (Free) prend en charge jusqu'à 25 connexions, ce qui couvre une ligne pilote avec sa passerelle, Telegraf et quelques tableaux de bord. Les usines plus importantes passent généralement à l'offre Serverless (Paid) ou à un cluster Dedicated à mesure que de nouvelles lignes sont raccordées. Pour la stratégie d'ensemble, consultez le guide de l'industrie connectée.
Démarrer avec ConnectMQ
Créez un broker gratuit sur app.connectmq.com avec l'offre Serverless, sans carte bancaire, pointez-y vos postes et Telegraf, et faites tourner dès aujourd'hui un tableau de bord de ligne de production sur une infrastructure privée.
Questions fréquentes
Faut-il utiliser Grafana ou Node-RED pour un tableau de bord de ligne de production ?
Utilisez Grafana lorsque vous avez besoin d'historique, de comparaisons entre postes et de nombreux utilisateurs ; utilisez Node-RED pour un affichage en direct rapide sur une seule ligne. Beaucoup d'équipes utilisent les deux à partir des mêmes topics MQTT.
À quelle fréquence les postes doivent-ils publier leur état ?
Publiez immédiatement à chaque changement d'état et envoyez un heartbeat toutes les 5 à 10 secondes. Les tuiles restent à jour sans inonder le broker.
Peut-on connecter les automates directement ?
La plupart des automates ont besoin d'une passerelle en périphérie (Node-RED, un convertisseur de protocole ou le client MQTT intégré à l'automate) qui lit les variables et publie du JSON vers le broker. Une fois les données sur MQTT, le tableau de bord ne se soucie pas de leur provenance.
Le broker public convient-il à de vraies données de production ?
Non. L'espace public de broker.connectmq.com est lisible par tout le monde : utilisez-le uniquement pour des tests et déplacez les données de production vers un broker ConnectMQ privé avec identifiants et TLS.
