La surveillance de ligne de conditionnement porte sur les arrêts que personne ne consigne : une étiquette coincée, une bouteille tombée, une formeuse de caisses qui attend ses découpes. Ce cas d'usage montre comment capter chaque arrêt et chaque variation de cadence sur une ligne de conditionnement via MQTT, classer automatiquement les micro-arrêts et identifier la machine qui limite réellement la production. Vous repartirez avec un modèle d'événements simple, un détecteur de micro-arrêts fonctionnel et une liste d'actions à mener à partir des résultats.
Pourquoi les lignes de conditionnement cachent leurs pertes
Une ligne de conditionnement est une chaîne de machines rapides reliées par des convoyeurs et des tables d'accumulation. Quand une machine s'arrête 20 secondes, le tampon absorbe l'arrêt et la ligne continue : personne ne le note. Quand cela se produit quarante fois par poste, le tampon se vide, la machine amont se bloque et la ligne ralentit. Les relevés manuels saisissent les longues pannes, mais les arrêts courts et fréquents et les machines qui tournent sous leur cadence nominale restent généralement invisibles sur le papier.
Ces pertes cachées dépassent souvent les pannes qui accaparent toute l'attention. Les lignes de conditionnement sont donc l'un des endroits où la collecte automatique de données est rentabilisée le plus vite : les signaux existent déjà dans les automates des machines, et le phénomène n'apparaît que lorsque chaque événement est enregistré.
Les catégories d'arrêts à distinguer
Tous les arrêts ne sont pas imputables à la machine. Un système de surveillance de ligne de conditionnement utile distingue :
| Catégorie | Définition | Cause typique |
|---|---|---|
| Micro-arrêt | Machine arrêtée moins longtemps qu'un seuil (souvent 2 à 5 minutes), relancée sans intervention de maintenance | Bourrages, défauts d'alimentation, déclenchements intempestifs de capteurs |
| Panne | Arrêt au-delà du seuil ou nécessitant la maintenance | Défaillance mécanique ou électrique |
| Manque produit (starved) | Machine prête mais aucun produit n'arrive | Arrêt amont ou tampon vide |
| Saturation aval (blocked) | Machine prête mais sortie engorgée | Arrêt aval ou tampon plein |
| Perte de cadence | En marche, mais sous la cadence nominale | Cadence réduite par l'opérateur, alimentation instable |
| Arrêt planifié | Changement de série, nettoyage, pause | Activité programmée |
Le manque produit et la saturation aval sont la clé. Une boucheuse en manque produit n'a pas un problème de boucheuse : le problème est en amont. Sans cette distinction, toutes les machines paraissent mauvaises et la vraie contrainte reste cachée.
Signaux et conception des messages
L'automate de chaque machine expose généralement des bits marche, défaut, manque produit et saturation, une valeur de vitesse et des compteurs. Publiez un événement d'état à chaque changement et un message de compteurs périodique :
connectmq/demo/<your-id>/plant2/pack3/<machine>/state
connectmq/demo/<your-id>/plant2/pack3/<machine>/counts
{"state": "STOPPED", "cause": "FAULT", "code": 214, "speed": 0, "ts": 1792140125.42}
{"infeed": 120544, "outfeed": 120391, "reject": 153, "speed": 312, "rated_speed": 400, "ts": 1792140130.0}
À l'arrêt, utilisez les valeurs de cause FAULT, STARVED, BLOCKED et PLANNED. Le code de défaut provient de la liste d'alarmes de la machine elle-même, ce qui donne un motif à de nombreux arrêts sans solliciter les opérateurs. Les horodatages doivent être posés en edge avec une précision inférieure à la seconde, car les micro-arrêts sont courts et l'ordre des événements compte.
Un détecteur de micro-arrêts en Python
Cet abonné écoute le topic d'état de chaque machine, mesure la durée de chaque arrêt au redémarrage, le classe et publie un événement de synthèse. Il tient aussi un décompte par machine que vous pourriez pousser vers un tableau de bord chaque minute.
import json
import time
from collections import defaultdict
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/p9x2c6/plant2/pack3"
MICRO_STOP_SECONDS = 120
stopped_since = {} # machine -> (start_ts, cause, code)
tally = defaultdict(lambda: defaultdict(lambda: {"count": 0, "seconds": 0.0}))
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{PREFIX}/+/state", qos=1)
def on_message(client, userdata, msg):
machine = msg.topic.split("/")[-2]
event = json.loads(msg.payload)
ts = event.get("ts", time.time())
if event["state"] == "STOPPED" and machine not in stopped_since:
stopped_since[machine] = (ts, event.get("cause", "UNKNOWN"), event.get("code"))
return
if event["state"] == "RUNNING" and machine in stopped_since:
start, cause, code = stopped_since.pop(machine)
duration = ts - start
if cause == "FAULT":
category = "MICRO_STOP" if duration < MICRO_STOP_SECONDS else "BREAKDOWN"
else:
category = cause # STARVED, BLOCKED, PLANNED
bucket = tally[machine][category]
bucket["count"] += 1
bucket["seconds"] += duration
summary = {
"machine": machine,
"category": category,
"code": code,
"duration": round(duration, 1),
"ended": ts,
}
client.publish(f"{PREFIX}/{machine}/stop", json.dumps(summary), qos=1)
print(summary)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="microstop-p9x2c6")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
Testez-le sans ligne réelle en publiant des événements à la main :
mosquitto_pub -h broker.connectmq.com -p 1883 -i tester-p9x2c6 -t "connectmq/demo/p9x2c6/plant2/pack3/labeler/state" -m '{"state":"STOPPED","cause":"FAULT","code":214,"speed":0,"ts":1792140125.4}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i tester-p9x2c6 -t "connectmq/demo/p9x2c6/plant2/pack3/labeler/state" -m '{"state":"RUNNING","speed":380,"ts":1792140143.9}'
Le détecteur affiche un MICRO_STOP de 18,5 secondes pour l'étiqueteuse avec le code défaut 214. Chaque arrêt devient un enregistrement que vous pouvez stocker, représenter en graphique et additionner par code.
Détecter les pertes de cadence
Les arrêts ne sont que la moitié de l'histoire. Une ligne de 400 unités par minute nominales qui tourne à 330 pour ménager une étiqueteuse capricieuse perd de la capacité à chaque minute de marche, et aucun relevé d'arrêts ne le montre. Comparez speed à rated_speed dans le message de compteurs et cumulez l'écart uniquement pendant que la machine tourne. Un simple rapport quotidien des « minutes équivalentes perdues en cadence » par machine réserve souvent des surprises : les opérateurs réduisent la cadence pour de bonnes raisons, mais ces raisons peuvent être traitées une fois visibles.
Pertes de cadence et micro-arrêts forment ensemble la composante performance de l'OEE (TRS). Le guide de calcul de l'OEE montre comment ils se combinent avec la disponibilité et la qualité.
Check-list d'analyse : des données à l'action
Une fois une semaine de données collectée, déroulez cette liste :
- Trouvez la contrainte. La machine qui cumule le moins de temps en manque produit et en saturation aval est généralement le goulot. Les améliorations ailleurs n'augmentent pas la production de la ligne.
- Faites un Pareto des micro-arrêts par machine et par code défaut. Souvent, un petit nombre de codes provoque la majorité des arrêts sur le goulot.
- Examinez la répartition dans le temps. Des arrêts groupés après les changements de série ou à certaines heures signalent des problèmes de réglage ou de matière.
- Observez le comportement des tampons. Si le goulot manque souvent de produit, le tampon amont est peut-être trop petit ou la machine amont trop peu fiable.
- Revoyez les réglages de cadence. Comparez cadence réelle et nominale pour chaque machine et demandez-vous pourquoi l'écart existe.
- Associez des motifs aux arrêts longs. Les micro-arrêts s'expliquent par les codes défaut, mais les pannes exigent un motif humain. Une liste structurée de codes motifs d'arrêt garde ces saisies exploitables.
L'affichage en bord de ligne
Un grand écran à côté de la ligne, avec l'état de chaque machine, le nombre de micro-arrêts du poste en cours et les trois codes défaut les plus fréquents, change vite les comportements : les opérateurs voient l'effet du réglage d'un guide ou d'un capteur dans le même poste. Le tutoriel tableau de bord de suivi de ligne de production montre comment en construire un à partir de ces topics.
Dimensionner le flux de données
Les lignes de conditionnement génèrent plus d'événements qu'on ne le pense : mieux vaut estimer le débit de messages avant la mise en service. Une ligne typique compte cinq à huit machines. Chacune publie un message d'état à chaque changement et un message de compteurs toutes les quelques secondes. Lors d'un mauvais poste, une seule étiqueteuse peut s'arrêter des dizaines de fois par heure, mais même alors le total reste modeste : quelques messages par seconde pour toute la ligne, chacun bien en dessous du kilo-octet.
Quelques choix de conception le garantissent :
- Publiez les états uniquement sur changement. Ne jamais interroger et republier un état inchangé toutes les 100 ms.
- Envoyez les compteurs à intervalle fixe et lent. Toutes les cinq ou dix secondes suffisent, car les compteurs sont cumulatifs.
- Gardez le libellé des défauts hors du payload. Envoyez le code numérique et conservez la table des libellés dans le service d'analyse.
- Utilisez un client par passerelle. Une passerelle qui lit plusieurs automates peut publier tous les topics machine sur une seule connexion, ce qui économise des connexions sur votre offre broker.
Avec ce schéma, un seul broker ConnectMQ Serverless transporte confortablement une ligne de conditionnement, le détecteur, un historian et quelques écrans, et vous pouvez ajouter d'autres lignes en étendant l'arborescence de topics sans rien reconstruire.
Passer à un broker privé
Utilisez le serveur MQTT public gratuit pour le prototype, puis migrez la vraie ligne vers un broker privé afin que les données de production ne soient pas lisibles par d'autres. ConnectMQ fournit un broker MQTT managé où chaque passerelle automate, le détecteur et le tableau de bord se connectent avec des identifiants émis, sur TLS. Les 25 connexions de l'offre gratuite Serverless suffisent pour une ligne de conditionnement, et les offres payantes montent en charge avec le QoS 2, des messages plus volumineux et les shared subscriptions lorsque vous faites tourner plusieurs instances du détecteur en parallèle. Ces mêmes événements machine peuvent ensuite alimenter un jumeau numérique de la ligne. La feuille de route globale est détaillée dans le guide de l'industrie connectée.
Démarrez avec ConnectMQ
Inscrivez-vous sur app.connectmq.com, créez un broker Serverless gratuit sans carte bancaire, connectez votre première machine de conditionnement et commencez à compter les micro-arrêts que votre ligne vous cachait.
Questions fréquentes
Qu'est-ce qui compte comme micro-arrêt sur une ligne de conditionnement ?
Un arrêt court relancé par l'opérateur sans intervention de maintenance, généralement sous un seuil de quelques minutes. Choisissez un seuil unique pour l'usine et gardez-le fixe pour que les tendances restent comparables.
Les opérateurs doivent-ils saisir les motifs des micro-arrêts ?
Non. Les micro-arrêts sont trop fréquents pour une saisie manuelle ; utilisez plutôt les codes défaut des machines. Réservez la saisie opérateur aux arrêts plus longs.
Pourquoi distinguer manque produit et saturation aval des défauts ?
Parce qu'une machine en manque produit ou en saturation aval réagit à une voisine. Compter ces temps comme ses propres arrêts masque la vraie contrainte.
Quelle doit être la réactivité des données ?
Les changements d'état doivent être publiés immédiatement avec des horodatages posés en edge. Une précision inférieure à la seconde est utile, car beaucoup de micro-arrêts ne durent que quelques secondes.
