Client Node-RED OPC UA vers MQTT avec des topics ISA-95

Un flow Node-RED OPC UA vous permet de récupérer les valeurs d'automates modernes, de commandes numériques et de serveurs SCADA pour les publier sur MQTT, où de nombreux consommateurs peuvent les utiliser sans ouvrir chacun une session OPC UA. Dans ce tutoriel, vous allez vous abonner à des variables OPC UA avec node-red-contrib-opcua, associer leurs node IDs à des topics MQTT de style ISA-95 et publier chaque changement avec sa qualité et son horodatage source. Vous pouvez suivre le tutoriel avec un serveur de simulation gratuit et un broker MQTT gratuit.

Pourquoi combiner OPC UA et MQTT

OPC UA excelle à l'intérieur de l'usine : modèle d'information riche, espaces d'adressage navigables, types de données, sécurité et abonnements. Il est moins pratique pour une large diffusion. Chaque client maintient une session avec le serveur, les pare-feu entre l'usine et le cloud compliquent les connexions directes, et les contrôleurs peuvent limiter le nombre de sessions acceptées.

MQTT le complète. Une seule passerelle maintient une session OPC UA, reçoit les changements via un abonnement OPC UA et les publie sur un broker. De là, tableaux de bord, historiens, MES et outils d'analyse cloud s'abonnent à des topics qu'ils comprennent. La comparaison OPC UA vs MQTT détaille les compromis. En bref, OPC UA décrit la machine, MQTT distribue les données, et Node-RED est une passerelle pratique entre les deux pour les pilotes et les sites de petite à moyenne taille.

Ce dont vous avez besoin

Installez les nœuds OPC UA :

cd ~/.node-red
npm install node-red-contrib-opcua
# redémarrez Node-RED ensuite

Le paquet est volumineux car il embarque la pile node-opcua : l'installation peut prendre quelques minutes sur un Raspberry Pi.

Comme serveur de test, le Prosys OPC UA Simulation Server gratuit est très utilisé. Son endpoint par défaut ressemble à opc.tcp://<your-pc>:53530/OPCUA/SimulationServer, et il expose des variables simulées comme Counter, Random et Sinusoid. Les node IDs varient selon la version : relevez les identifiants exacts dans la vue Objects du serveur ; dans de nombreuses versions, ils ressemblent à ns=3;i=1001.

Étape 1 : trouver les node IDs

Chaque variable OPC UA possède un node ID composé d'un index d'espace de noms et d'un identifiant, par exemple ns=3;i=1001 (numérique) ou ns=4;s=Line2.Filler.Temperature (chaîne). Vous avez besoin de ces identifiants avant de pouvoir vous abonner.

Deux façons de les trouver :

1. Utilisez le nœud OpcUa-Browser dans Node-RED : pointez-le vers l'endpoint et naviguez à partir du dossier Objects.
2. Utilisez un client de bureau comme UaExpert, sélectionnez une variable et copiez son NodeId.

Notez aussi le type de données (Double, Int32, Boolean). Le nœud client l'utilise lors des écritures, et il vous indique comment formater la valeur dans MQTT.

Étape 2 : configurer le client OPC UA

Ajoutez un nœud OpcUa-Client et créez une configuration d'endpoint :

• Endpoint : opc.tcp://<server-host>:53530/OPCUA/SimulationServer
• Politique de sécurité : None et mode None pour le premier test
• Action : SUBSCRIBE
• Intervalle : 1000 ms (l'intervalle de publication de l'abonnement OPC UA)

Ajoutez ensuite un nœud OpcUa-Item par variable, avec l'item défini sur le node ID et le type sur le type de données de la variable. Reliez un seul nœud inject, réglé pour se déclencher une fois après 2 secondes, à tous les nœuds item, et reliez les nœuds item au client. Au démarrage du flow, chaque item demande au client de surveiller ce nœud ; dès lors, le client émet un message à chaque changement de valeur, avec la valeur dans msg.payload et le node ID dans msg.topic.

Déployez et ajoutez un nœud debug après le client. Vous devriez voir Counter s'incrémenter et Random changer chaque seconde. Si le statut du client affiche une erreur de connexion, vérifiez l'URL de l'endpoint, en particulier le nom d'hôte : de nombreux serveurs annoncent leur propre nom d'hôte, qui doit pouvoir être résolu depuis la machine Node-RED.

Étape 3 : associer les node IDs OPC UA à des topics MQTT ISA-95

Publier sur un topic comme opcua/ns=3;i=1001 fonctionnerait techniquement, mais personne en aval ne saurait ce qu'il signifie. Associez plutôt chaque node ID à un emplacement dans votre hiérarchie d'équipements : entreprise ou site, zone, ligne, cellule et tag. C'est l'idée qui sous-tend les structures de topics ISA-95 et l'Unified Namespace. Le guide des topics MQTT ISA-95 explique les niveaux.

Une table de correspondance dans un nœud function garde la correspondance explicite et facile à relire :

// Nœud function "opc ua to isa-95 topic"
// Associer les node IDs OPC UA à des chemins d'équipement et des noms de tags.
const PREFIX = "connectmq/demo/a7f3k2";    // préfixe de démo pour le broker public
const MAP = {
    "ns=3;i=1001": { path: "plant1/packaging/line2/filler", tag: "counter", unit: "" },
    "ns=3;i=1002": { path: "plant1/packaging/line2/filler", tag: "pressure", unit: "bar" },
    "ns=3;i=1004": { path: "plant1/packaging/line2/capper", tag: "torque", unit: "Nm" }
};

const nodeId = String(msg.topic);
const entry = MAP[nodeId];
if (!entry) {
    node.warn("Unmapped node ID: " + nodeId);
    return null;
}

// Qualité : les status codes de node-opcua exposent un nom comme "Good" ou "Bad..."
let quality = "Good";
if (msg.statusCode && typeof msg.statusCode === "object" && msg.statusCode.name) {
    quality = msg.statusCode.name;
}

const value = typeof msg.payload === "number"
    ? Math.round(msg.payload * 1000) / 1000
    : msg.payload;

msg.topic = `${PREFIX}/${entry.path}/${entry.tag}`;
msg.payload = {
    value: value,
    unit: entry.unit,
    quality: quality,
    sourceTimestamp: msg.sourceTimestamp || new Date().toISOString(),
    nodeId: nodeId
};
msg.retain = true;
return msg;

Le topic obtenu, par exemple connectmq/demo/a7f3k2/plant1/packaging/line2/filler/pressure, compte huit niveaux. Cela respecte la limite de huit niveaux de topic du broker public ; sur un broker privé, vous supprimeriez le préfixe de démo et pourriez ajouter un niveau entreprise.

Publier avec retain signifie que tout nouvel abonné reçoit immédiatement la dernière valeur de chaque tag, ce qui correspond exactement au comportement attendu d'un Unified Namespace : l'arborescence de topics représente l'état actuel. Conservez la qualité et l'horodatage source dans le payload. Un historien doit savoir quand la valeur a changé à la source, pas quand Node-RED l'a transmise, et une valeur de qualité « Bad » ne doit pas être tracée comme si elle était réelle.

Étape 4 : publier sur MQTT

Ajoutez un nœud mqtt out dont les champs topic et retain sont laissés vides, pour que les propriétés du message soient utilisées. Pour les tests, connectez-vous à broker.connectmq.com sur le port 1883 avec un client ID unique ; il s'agit du serveur MQTT public gratuit : remplacez donc a7f3k2 par votre propre chaîne aléatoire et n'y publiez pas de vraies données de production.

Vérifiez la sortie depuis un terminal :

mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-opcua-a7f3k2 -v \
  -t 'connectmq/demo/a7f3k2/plant1/#'

Chaque ligne affiche un topic et un payload JSON avec la valeur, l'unité, la qualité et l'horodatage.

Écrire en retour dans OPC UA (avec prudence)

Le même nœud client prend en charge une action WRITE. Un flow de commande MQTT s'abonnerait à un topic de commande dédié, validerait la valeur et sa plage dans un nœud function, définirait msg.topic sur un node ID fixe et l'enverrait via un OpcUa-Item configuré avec le bon type de données. Comme pour tout chemin d'écriture OT, ne laissez jamais le message entrant choisir le node ID, journalisez chaque écriture et publiez un topic d'acquittement. Beaucoup de sites gardent la passerelle en lecture seule tant qu'un besoin clair n'est pas apparu.

Sécurité en production

La configuration de test n'utilise aucune sécurité. Pour un vrai contrôleur :

1. Utilisez une politique sécurisée. Choisissez Basic256Sha256 avec le mode SignAndEncrypt dans la configuration de l'endpoint.
2. Approuvez les certificats. Lors de la première connexion, le serveur rejette généralement le certificat client de Node-RED. Déplacez-le dans la liste des certificats approuvés du serveur (dans Prosys, onglet Certificates), puis reconnectez-vous.
3. Utilisez un utilisateur dédié. Configurez un utilisateur OPC UA en lecture seule pour la passerelle si le serveur prend en charge l'authentification des utilisateurs.
4. Protégez le côté MQTT. Connectez-vous à un broker privé via TLS sur le port 8883 avec des identifiants, et non au broker de test public.

Dépanner les flows Node-RED OPC UA

Faire évoluer le modèle

Pour quelques machines, une instance Node-RED par site avec une table de correspondance fonctionne bien. Quand la table grossit, déplacez-la dans un fichier JSON ou dans un contexte de flow chargé au démarrage, afin que les ingénieurs puissent relire les modifications sans toucher au code. Lorsque de nombreux fabricants et protocoles sont en jeu, combinez ce flow avec la passerelle Node-RED Modbus pour les équipements plus anciens, et envisagez Node-RED Sparkplug B si vos consommateurs attendent la gestion des messages birth, death et d'état de Sparkplug. Les passerelles commerciales méritent d'être évaluées dès que vous avez besoin de centaines de tags par site avec une configuration centralisée.

Toutes ces passerelles ont besoin d'un broker digne de confiance. Un broker MQTT cloud permet aux passerelles de plusieurs sites de publier dans un même espace de noms via des connexions TLS sortantes. ConnectMQ, un broker MQTT managé, détecte les structures de topics ISA-95 et Unified Namespace et affiche les équipements par entreprise, site, zone, ligne et cellule dans son portail, ce qui permet de vérifier facilement que votre table de correspondance a produit la hiérarchie voulue. Pour revoir ce que fait un broker MQTT dans cette architecture, ou la configuration des nœuds MQTT, consultez le tutoriel Node-RED MQTT.

Publiez vos données OPC UA sur ConnectMQ

Inscrivez-vous sur app.connectmq.com avec l'offre gratuite Serverless, sans carte bancaire. Créez un broker, collez le nom d'utilisateur, le mot de passe et le client ID générés dans le nœud de configuration MQTT de Node-RED, passez au port 8883 avec TLS et retirez le préfixe de démo de la table de correspondance. Vos tags OPC UA apparaissent alors dans le portail ConnectMQ, organisés selon les niveaux ISA-95.

Questions fréquentes

Quel paquet Node-RED utiliser pour OPC UA ?

Le paquet le plus utilisé est node-red-contrib-opcua, construit sur la pile node-opcua. Il fournit des nœuds client, item, browser et server pour lire, écrire, s'abonner et tester.

Faut-il interroger ou s'abonner aux valeurs OPC UA dans Node-RED ?

Abonnez-vous dès que le serveur le permet. Le serveur n'envoie alors que les changements, à l'intervalle que vous définissez, ce qui ménage le contrôleur et offre des mises à jour plus rapides que l'interrogation.

Pourquoi associer les node IDs OPC UA à des topics MQTT ISA-95 ?

Les node IDs n'ont de sens qu'à l'intérieur d'un serveur donné. Les topics de style ISA-95 décrivent la provenance des données dans l'usine, si bien que chaque consommateur peut les trouver et les comprendre sans connaître l'espace d'adressage OPC UA.

Node-RED peut-il se connecter à des serveurs OPC UA avec la sécurité activée ?

Oui. Choisissez une politique de sécurité comme Basic256Sha256 avec SignAndEncrypt et approuvez le certificat client de Node-RED sur le serveur. L'authentification par utilisateur et mot de passe est également prise en charge.