Fabrication intelligente

Intégration MES MQTT : ordres de fabrication, comptages et qualité pilotés par événements

Remplacez les interfaces MES point à point fragiles par un namespace MQTT piloté par événements. Découvrez l'organisation des topics, les contrats de payload et un adaptateur fonctionnel pour les ordres, les comptages et les résultats qualité.

Schéma d'intégration MES MQTT avec des machines, un broker MQTT et un système d'exécution de la fabrication échangeant ordres de fabrication et comptages
Essayez-le sur votre propre broker MQTTObtenez un broker MQTT privé et managé avec l’offre Free et partez d’exemples de code prêts à l’emploi.
Essayer gratuitement Exemples de code Aucune carte bancaire requise

L'intégration MES MQTT remplace l'enchevêtrement d'interfaces sur mesure entre un système d'exécution de la fabrication (MES) et l'atelier par un namespace unique piloté par événements. Ce guide montre comment structurer les topics pour les ordres de fabrication, les comptages de production et les résultats qualité, ce que doivent contenir les payloads et comment écrire un petit adaptateur qui relie un MES à un broker MQTT.

Pourquoi l'intégration du MES est souvent la partie la plus difficile

Un système d'exécution de la fabrication suit ce qui est produit, sur quel équipement, par qui et avec quel résultat. Pour cela, il a besoin des données des machines et doit leur renvoyer des instructions. Traditionnellement, cela passe par des liaisons point à point : une connexion OPC ici, une table de base de données interrogée chaque minute là, un fichier CSV déposé sur un partage par l'automate d'une ligne.

Chaque liaison fonctionne isolément, mais ensemble elles créent des problèmes que tout ingénieur d'usine connaît :

  • Ajouter un deuxième consommateur (un tableau de bord OEE, un système de maintenance) oblige à construire une nouvelle interface vers la même machine.
  • Le polling introduit du retard et de la charge ; un comptage n'est jamais plus frais que la dernière requête.
  • Lorsque le MES est mis à jour ou remplacé, toutes les interfaces cassent en même temps.
  • Personne ne dispose d'un endroit unique pour voir quelles données circulent réellement.

Une approche pilotée par événements inverse la logique. Les machines et les passerelles publient ce qui se passe au moment où cela se passe. Le MES s'abonne aux événements dont il a besoin et publie ses propres décisions, comme un ordre de fabrication lancé. Les autres systèmes s'abonnent aux mêmes événements sans toucher au MES. Si vous ne savez pas bien où se situe le MES par rapport à l'ERP et au SCADA, lisez d'abord MES vs ERP vs SCADA.

Comment fonctionne l'intégration MES MQTT

La pièce centrale est un broker MQTT auquel chaque participant se connecte en tant que client. Personne ne se connecte directement à quelqu'un d'autre. Trois flux couvrent la plupart des besoins d'un MES :

Flux Sens Exemple de topic QoS typique
Envoi des ordres de fabrication MES vers ligne acme/plant1/assembly/line2/mes/order/current 1, retained
Comptages de production Machine vers MES acme/plant1/assembly/line2/cell3/count 1
État machine Machine vers MES acme/plant1/assembly/line2/cell3/state 1, retained
Résultats qualité Poste de test vers MES acme/plant1/assembly/line2/qc1/result 1
Acquittement d'ordre Ligne vers MES acme/plant1/assembly/line2/mes/order/ack 1

Le chemin du topic suit la hiérarchie d'équipements ISA-95 (entreprise, site, zone, ligne, cellule), qui constitue la colonne vertébrale d'un Unified Namespace. Les détails de ce nommage sont expliqués dans comment construire un Unified Namespace.

Deux fonctionnalités MQTT comptent particulièrement pour le trafic MES :

  • Retained messages. L'ordre de fabrication en cours et l'état actuel de la machine sont conservés (retained), si bien qu'une IHM qui redémarre sait immédiatement quoi produire sans interroger le MES.
  • QoS 1. Les comptages et les résultats qualité ne doivent pas être perdus ; ils sont donc publiés avec une livraison « au moins une fois ». Le MES doit par conséquent gérer les doublons, généralement en conservant un numéro de séquence par émetteur.

Des contrats de payload qui résistent au changement

Les topics indiquent d'où vient un événement ; les payloads indiquent ce qui s'est passé. Mettez-vous d'accord sur un contrat par type d'événement et versionnez-le. Un événement de comptage auquel un MES peut se fier ressemble à ceci :

{
  "schema": "count/v1",
  "ts": "2026-10-16T08:42:13.512Z",
  "seq": 18233,
  "orderId": "WO-2026-04417",
  "material": "HSG-220-B",
  "good": 1,
  "scrap": 0,
  "source": "cell3-plc"
}

Quelques règles rendent ces contrats robustes :

  1. Envoyez des incréments ou des totaux, pas les deux. Les incréments avec numéro de séquence sont faciles à dédoublonner ; les totaux sont faciles à récupérer après une interruption. Choisissez l'un des deux par signal et documentez-le.
  2. Transportez l'identifiant de l'ordre. La ligne connaît déjà l'ordre actif grâce au topic d'ordre retained ; l'apposer sur chaque événement évite au MES une recherche et empêche les comptages mal attribués lors d'un changement d'ordre.
  3. Horodatez à la source en UTC, à la milliseconde.
  4. Incluez un champ de schéma pour que les consommateurs puissent gérer count/v2 sans casser.

Un adaptateur MES fonctionnel en Python

La plupart des produits MES exposent une API REST ou une interface base de données plutôt que MQTT. Un petit adaptateur fait le pont entre les deux : il s'abonne aux événements de l'atelier et appelle le MES, puis publie les décisions du MES dans le namespace. L'exemple ci-dessous utilise paho-mqtt 2.x et une fonction factice post_to_mes que vous remplacez par l'appel à l'API de votre MES.

import json
import uuid

import paho.mqtt.client as mqtt

LINE = "connectmq/demo/mes-5c21/line2"   # en production, utilisez le chemin ISA-95 complet
last_seq = {}

def post_to_mes(kind, event):
    # Remplacez par un appel à l'API de votre MES, par ex. requests.post(...)
    print(f"MES <- {kind}: {event}")

def release_order(client, order_id, material, quantity):
    order = {"schema": "order/v1", "orderId": order_id,
             "material": material, "quantity": quantity, "status": "RELEASED"}
    client.publish(f"{LINE}/mes/order/current", json.dumps(order), qos=1, retain=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{LINE}/+/count", qos=1)
    client.subscribe(f"{LINE}/+/state", qos=1)
    client.subscribe(f"{LINE}/+/result", qos=1)
    client.subscribe(f"{LINE}/mes/order/ack", qos=1)
    release_order(client, "WO-2026-04417", "HSG-220-B", 500)

def on_message(client, userdata, msg):
    event = json.loads(msg.payload)
    kind = msg.topic.rsplit("/", 1)[-1]
    source = msg.topic.split("/")[-2]
    seq = event.get("seq")
    if seq is not None:
        key = (source, kind)
        if seq <= last_seq.get(key, -1):
            return  # doublon issu d'une relivraison QoS 1
        last_seq[key] = seq
    post_to_mes(kind, {"source": source, **event})

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"mes-adapter-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Testez-le avec le serveur MQTT public gratuit en publiant un comptage depuis la ligne de commande :

mosquitto_pub -h broker.connectmq.com -p 1883 -i cell3-test-5c21 -q 1 \
  -t "connectmq/demo/mes-5c21/line2/cell3/count" \
  -m '{"schema":"count/v1","seq":1,"orderId":"WO-2026-04417","good":1,"scrap":0}'

Publiez deux fois le même message : l'adaptateur ne le transmet qu'une seule fois. N'oubliez pas que le serveur public est lisible par tout le monde ; utilisez uniquement des numéros d'ordre inventés et réservez-le aux tests et prototypes, jamais aux données de production.

En production, stockez l'état de dédoublonnage (last_seq) dans un emplacement durable, exécutez l'adaptateur avec une session persistante pour qu'il reçoive les événements mis en file pendant un redémarrage, et attribuez-lui ses propres identifiants.

Modèles d'intégration et pièges à éviter

Les commandes ont besoin d'acquittements. Lorsque le MES lance un ordre, la ligne doit publier un acquittement avec l'identifiant de l'ordre et son statut (accepté, refusé, démarré). Sans cela, le MES ne peut pas savoir si l'ordre est arrivé. Le modèle requête/réponse de MQTT 5, avec un response topic et des correlation data, formalise ce schéma.

Gardez le MES hors de la boucle machine. Les verrouillages et la logique de sécurité restent dans l'automate. MQTT transporte des événements et des instructions, pas de la commande temps réel dur.

Ne laissez pas le MES devenir le namespace. Si chaque consommateur lit les données via le MES, vous revenez à une intégration point à point. Publiez les événements bruts sur le broker et laissez le MES être un abonné parmi d'autres, à côté des outils de collecte de données atelier, des tableaux de bord OEE et des historians.

Anticipez les changements de série. La plupart des comptages mal attribués surviennent dans les secondes qui entourent un changement d'ordre. Faites apposer l'identifiant de l'ordre sur chaque comptage par la ligne, et faites clôturer un ordre par le MES uniquement après réception d'un événement de fin explicite.

Piège Effet Prévention
Pas de numéros de séquence Doubles comptages après reconnexion seq par émetteur, dédoublonnage dans l'adaptateur
Ordre non retained L'IHM n'affiche rien après redémarrage Publier l'ordre en cours avec retain
Client IDs partagés Les adaptateurs se déconnectent mutuellement Un ID unique par instance
Broker sur un seul PC d'usine L'intégration s'arrête quand le PC s'arrête Utiliser un broker MQTT managé

Faire tourner le namespace sur un broker MQTT managé

Dès que le MES, les passerelles et les tableaux de bord dépendent du broker, sa disponibilité et sa sécurité deviennent celles de votre intégration. Un broker MQTT managé vous libère de la maintenance des correctifs, des certificats et de la supervision d'un broker. ConnectMQ fournit MQTT 3.1.1 et 5.0 sur TLS (8883) et WebSocket sécurisé (8084), des identifiants liés aux client IDs, et un portail avec un explorateur de topics en direct et une vue des appareils organisée par niveaux ISA-95, ce qui permet de vérifier facilement que les comptages et les états arrivent sous la bonne ligne et la bonne cellule.

Si vos machines parlent Sparkplug B, ConnectMQ peut le décoder et republier les données dans des topics ISA-95 lisibles, de sorte que l'adaptateur MES s'abonne à de simples chemins JSON plutôt qu'à du Protobuf. Pour une vue d'architecture plus large, consultez le guide de la fabrication intelligente et la présentation de ce qu'offre un broker MQTT cloud.

Connectez votre MES à ConnectMQ

Inscrivez-vous sur app.connectmq.com, créez un broker sur l'offre Serverless gratuite sans carte bancaire, et pointez l'adaptateur ci-dessus vers celui-ci avec YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID récupérés dans le portail.

Questions fréquentes

Mon MES doit-il prendre en charge MQTT nativement ?

Non. De nombreuses intégrations utilisent un petit adaptateur qui parle MQTT d'un côté et l'API ou la base de données du MES de l'autre. Le support natif supprime simplement l'adaptateur.

Le MES doit-il publier les ordres de fabrication en retained messages ?

Oui. L'ordre en cours par ligne est un état, pas un événement ; le conserver permet à tout client qui se connecte plus tard de savoir ce qui est en production. L'historique des ordres appartient à la base de données du MES.

Comment éviter les doubles comptages avec QoS 1 ?

Ajoutez un numéro de séquence par émetteur à chaque événement de comptage et ignorez toute séquence déjà traitée par l'adaptateur. Vous pouvez aussi publier des totaux cumulés et calculer les écarts côté MES.

MQTT est-il assez sûr pour le trafic MES ?

Avec TLS, des identifiants uniques par client et un broker qui impose la liaison au client ID, MQTT convient au trafic MES entre l'usine et le cloud. Gardez la logique de sécurité et de verrouillage dans l'automate.

Articles liés

TRS (OEE) vs TEEP vs OOE : quel indicateur utiliser ?

Le TRS (OEE), l'OOE et le TEEP partagent les mêmes facteurs de performance et de qualité, mais se mesurent sur des bases de temps différentes. Ce comparatif déroule un exemple unique et liste les signaux MQTT nécessaires à chaque indicateur.

7 min de lecture

Tous les articles →

Votre broker MQTT privé, à quelques clics

Créez un compte, récupérez les identifiants de votre broker et connectez votre premier appareil — aucun serveur à installer, mettre à jour ou dimensionner.