Agent MQTT Kepware : publier des tags vers un broker MQTT cloud en TLS

La publication MQTT depuis Kepware est l'un des moyens les plus rapides de faire remonter vers le cloud les données d'une usine équipée d'automates hétérogènes : Kepware maîtrise déjà les drivers, et sa fonction IoT Gateway y ajoute un client MQTT. Dans ce tutoriel, vous allez configurer l'agent MQTT Client de Kepware pour publier des tags vers un broker cloud en TLS, choisir et mettre en forme le payload JSON, ajouter un Last Will, vérifier les données et, si vous le souhaitez, éclater les messages groupés de l'agent en une arborescence propre d'un topic par tag.

Fonctionnement de l'agent MQTT de Kepware

Kepware (KEPServerEX et son successeur Kepware Server) est un serveur de connectivité industrielle doté de drivers pour des centaines de protocoles d'automates et d'équipements. Son plug-in IoT Gateway ajoute des agents qui poussent les données de tags vers des systèmes externes. L'agent MQTT Client en fait partie : il se connecte à un broker comme un client MQTT ordinaire et publie les valeurs des tags en JSON.

Le modèle est simple :

1. Les canaux et les équipements interrogent vos automates via les drivers Kepware, comme ils le font déjà pour le SCADA.
2. Un agent MQTT Client porte la connexion au broker, les paramètres de publication et le format du payload.
3. Les IoT items sont les tags que vous ajoutez à cet agent, chacun avec sa propre fréquence de scrutation et son comportement sur changement.
4. À chaque cycle de publication, l'agent envoie sur son topic un message JSON contenant les valeurs à transmettre.

Comme l'agent établit une connexion sortante, vous n'ouvrez aucun port entrant vers la machine Kepware. C'est en grande partie ce qui rend ce schéma si populaire pour envoyer les données OT vers un broker MQTT cloud. Les libellés et valeurs par défaut varient légèrement selon les versions de Kepware : considérez les noms de champs ci-dessous comme un guide et consultez l'aide de votre version si quelque chose diffère.

Avant de commencer

• Kepware avec la fonction IoT Gateway installée et sous licence.
• Au moins un canal et un équipement qui renvoient déjà des tags de bonne qualité. Vérifiez-le d'abord dans le Quick Client.
• Les paramètres de connexion au broker. Pour un premier test, utilisez le serveur MQTT public gratuit, réservé aux tests et aux prototypes, uniquement avec des tags non sensibles. Pour la production, créez un broker privé et notez son nom d'utilisateur, son mot de passe et son client ID.
• Un accès sortant depuis l'hôte Kepware vers le port TCP 8883 (TLS) du broker.

Étape 1 : créer l'agent MQTT Client

Dans l'outil de configuration de Kepware, dépliez IoT Gateway, faites un clic droit pour ajouter un nouvel agent et choisissez le type MQTT Client. L'assistant demande les paramètres principaux :

Ouvrez ensuite les paramètres de sécurité ou de client de l'agent et renseignez :

• Client ID : pour le serveur MQTT public gratuit, n'importe quelle valeur unique et non vide, comme kepware-k7q2. Pour un broker privé, le client ID exact fourni avec vos identifiants ; les client IDs sont liés à ces identifiants.
• Nom d'utilisateur et mot de passe : vides pour le serveur MQTT public gratuit ; YOUR_USERNAME et YOUR_PASSWORD pour un broker privé.
• Version TLS : TLS 1.2 ou ultérieure.

Le broker présente un certificat Let's Encrypt reconnu publiquement : vous n'avez normalement pas besoin d'importer de certificat d'AC. Si votre organisation inspecte le trafic TLS via un proxy, l'hôte Kepware doit plutôt faire confiance au certificat de ce proxy.

Étape 2 : ajouter un Last Will

Configurez le Last Will de l'agent pour que les consommateurs sachent quand Kepware disparaît :

• Topic : connectmq/demo/k7q2/plant1/kepware/status
• Message : offline

Lorsque l'agent se déconnecte de façon inattendue, le broker publie ce message à sa place. Associez-le à une règle de tableau de bord qui grise les valeurs dès que le statut indique offline.

Étape 3 : ajouter des IoT items

Faites un clic droit sur l'agent et ajoutez des IoT items en parcourant les tags souhaités. Pour chaque item, définissez :

1. Scan rate : la fréquence à laquelle Kepware échantillonne le tag pour cet agent. Adaptez-la à la vitesse réelle de variation de la valeur ; une à cinq secondes conviennent à la plupart des grandeurs process.
2. Publication à chaque scrutation ou sur changement : privilégiez la publication sur changement pour les états et les grandeurs analogiques lentes. C'est le report by exception intégré de Kepware, expliqué dans notre guide sur le report by exception.
3. Deadband : pour les grandeurs analogiques bruitées, une bande morte supprime les variations inférieures à un seuil.

Commencez par quelques tags, validez le flux de bout en bout, puis ajoutez le reste.

Étape 4 : vérifier les données

Abonnez-vous depuis n'importe quelle machine avec le client Mosquitto :

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i kepware-viewer-k7q2 -t "connectmq/demo/k7q2/#" -v

Avec le format Standard, chaque message sur le topic de l'agent ressemble à ceci :

{
  "timestamp": 1792137600000,
  "values": [
    { "id": "Line1.Filler.Speed",     "v": 118.4, "q": true, "t": 1792137599950 },
    { "id": "Line1.Filler.Running",   "v": true,  "q": true, "t": 1792137599950 },
    { "id": "Line1.Filler.GoodCount", "v": 48211, "q": true, "t": 1792137599950 }
  ]
}

id est le chemin complet du tag dans Kepware, v la valeur, q indique si la qualité est bonne et t est l'horodatage du tag en millisecondes depuis l'epoch. Sur un broker ConnectMQ privé, le client MQTT intégré au navigateur et l'explorateur de topics en direct du portail affichent les mêmes messages sans rien installer.

Étape 5 : mettre en forme le payload avec un modèle Advanced

Le format Advanced permet d'écrire un modèle avec des marqueurs que Kepware remplit. Voici un modèle qui renomme les champs de façon plus lisible pour le code en aval :

{
  "source": "kepware-plant1",
  "sent": |SERVERTIMESTAMP|,
  "tags": [
    |#each VALUES|
    { "name": "|TAGNAME|", "value": |VALUE|, "good": |QUALITY|, "ts": |TIMESTAMP| }|#unless @last|,|/unless|
    |/each|
  ]
}

Le modèle doit produire du JSON valide pour toutes les combinaisons de valeurs, y compris lorsqu'un seul tag a changé. Testez-le en observant les messages pendant que vous faites varier des tags dans le simulateur d'automate ou le Quick Client.

Étape 6 : répartir les données dans une arborescence d'un topic par tag

L'agent publie des lots sur un seul topic. C'est efficace, mais de nombreux consommateurs préfèrent un topic par valeur dans une hiérarchie ISA-95, ce qui rend aussi un Unified Namespace facile à parcourir. Un petit republisher peut se charger de la séparation. Il s'exécute n'importe où, se connecte au broker comme un client normal et associe les chemins de tags Kepware à des topics :

# kepware_fanout.py - éclater les lots au format Standard de Kepware en topics par tag
import json, uuid
import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/k7q2/plant1"
SOURCE = f"{ROOT}/kepware"

def to_topic(tag_id: str) -> str:
    # "Line1.Filler.Speed" -> "connectmq/demo/k7q2/plant1/line1/filler/speed"
    return f"{ROOT}/" + "/".join(part.lower() for part in tag_id.split("."))

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(SOURCE, qos=1)

def on_message(client, userdata, message):
    batch = json.loads(message.payload)
    for item in batch.get("values", []):
        payload = {"value": item["v"], "quality": "good" if item["q"] else "bad", "ts": item["t"]}
        client.publish(to_topic(item["id"]), json.dumps(payload), qos=1, retain=True)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"kep-fanout-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.tls_set()
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")  # broker privé
client.connect("broker.connectmq.com", 8883, keepalive=30)
client.loop_forever()

Chaque lot Kepware devient plusieurs messages retenus, un par tag : la limite du serveur MQTT public gratuit de dix messages par seconde et par client s'applique donc au client de répartition, alors gardez une liste de tags de test réduite. Sur un broker privé, les limites dépendent de votre plan. Notre article sur les topics MQTT ISA-95 vous aide à concevoir la hiérarchie cible, et ConnectMQ détecte automatiquement les topics structurés selon ISA-95 dans la vue des équipements.

Dépannage de l'agent MQTT de Kepware

Checklist de mise en production

1. Broker privé avec TLS sur le port 8883 et identifiants issus du portail.
2. Un client ID unique par agent, jamais partagé avec les outils de test.
3. Last Will configuré et surveillé.
4. Publication sur changement et bandes mortes sur les tags analogiques.
5. Taille des messages dans la limite de votre plan : 256 Ko sur le plan gratuit Serverless, 1 Mo sur Serverless payant.
6. Pare-feu de l'hôte Kepware : uniquement le 8883 en sortie.
7. Une procédure de rotation des certificats et des identifiants.

Pour une vue d'ensemble de la place de Kepware entre automates, passerelles et consommateurs, consultez le guide MQTT pour l'IoT industriel. Si vous comparez Kepware à une passerelle sur mesure, notre tutoriel passerelle OPC UA vers MQTT présente l'alternative open source.

Démarrer avec ConnectMQ

Donnez une destination cloud à votre serveur Kepware en quelques minutes. Inscrivez-vous sur app.connectmq.com, choisissez le plan gratuit Serverless sans carte bancaire, créez un broker et copiez le nom d'utilisateur, le mot de passe et le client ID générés dans l'agent MQTT Client. ConnectMQ est un broker MQTT managé : aucun serveur à mettre à jour, et les règles d'alerte à seuil du portail peuvent surveiller vos tags dès leur arrivée.

Questions fréquentes

Kepware prend-il en charge MQTT sur TLS ?

Oui. Utilisez une URL ssl:// avec le port 8883 dans l'agent MQTT Client et sélectionnez une version de TLS récente. Les brokers dotés de certificats reconnus publiquement ne nécessitent normalement aucune importation de certificat supplémentaire.

Kepware peut-il publier chaque tag sur son propre topic MQTT ?

L'agent MQTT Client publie des lots sur le topic de l'agent, et les options de topics par tag dépendent de la version de Kepware. Un petit client de répartition qui éclate les lots en topics par tag fonctionne avec toutes les versions.

Quelle QoS l'agent MQTT de Kepware doit-il utiliser ?

La QoS 1 est un bon choix par défaut pour les données de tags : la livraison est garantie au moins une fois, avec peu de surcoût. La QoS 2 est rarement nécessaire pour de la télémétrie.

Une application cloud peut-elle écrire des tags en retour via Kepware MQTT ?

L'agent peut être configuré pour accepter des requêtes d'écriture sur un topic auquel il est abonné, mais ne l'activez qu'avec un contrôle d'accès strict et un besoin clair. La plupart des déploiements gardent le chemin cloud en lecture seule.