Connecter OPC UA à Node-RED

Avant de commencer

• Une installation Node-RED avec un runtime Node.js supporté, et le droit d'y installer des nodes de palette. Dans un réseau OT, ce droit est souvent le vrai point bloquant.
• Un jeu de nœuds client OPC UA installé depuis la palette. Plusieurs paquets communautaires concurrents existent, avec des noms de nœuds, des configurations et des niveaux de maintenance différents ; choisissez-en un et restez cohérent sur l'ensemble de vos flux.
• Une URL d'endpoint qui fonctionne et une décision claire sur la sécurité. Si vous comptez tourner en signé et chiffré, vérifiez que le paquet de nœuds choisi prend en charge la politique proposée par le serveur avant de construire le flow.
• Un endroit où envoyer les données qui ne soit pas Node-RED. Il n'a pas de tampon durable propre.

Mise en place

1. Installez un seul paquet de nœuds OPC UA et restez dessusInstallez-le depuis le gestionnaire de palette, puis notez le nom et la version du paquet dans vos notes de projet. Mélanger deux paquets OPC UA dans une même instance Node-RED produit des types de nœuds dupliqués déroutants et des répertoires de certificats conflictuels.
2. Validez d'abord l'endpoint avec la sécurité NoneConfigurez le nœud client avec l'URL d'endpoint et sans sécurité, et lisez un seul nœud connu. Cela sépare les problèmes de réseau et d'endpoint des problèmes de certificats, et cela prend une minute.
3. Traitez explicitement le travail sur les certificatsRepérez où votre paquet de nœuds stocke sur le disque son certificat client et ses dossiers trusted et rejected, puis réalisez l'échange dans les deux sens : le serveur doit faire confiance au certificat du client Node-RED, et le client doit faire confiance au certificat du serveur. C'est l'étape qui transforme une démo en quelque chose qui survit à une revue de sécurité.
4. Adressez les nœuds par URI d'espace de noms quand le package le permetLa plupart des nodes communautaires prennent une chaîne NodeId avec un index d'espace de noms littéral, souvent porté par le topic du message. Si le package supporte la résolution par URI d'espace de noms, utilisez-la. Sinon, lisez le NamespaceArray dans un function node au démarrage du flow et construisez les chaînes NodeId à partir de là, plutôt que de coller des index dans chaque node.
5. Abonnez-vous plutôt que d'interroger, et limitez le débit avant tout traitement en avalUtilisez le nœud d'abonnement ou d'écoute du paquet, avec un intervalle de publication ajusté au besoin réel du consommateur. Placez ensuite un limiteur de débit ou un nœud d'agrégation entre l'abonnement et tout nœud qui fait un vrai travail, car chaque message s'exécute sur la même boucle d'événements que le reste de vos flux.
6. Traitez la reconnexion comme un cas de premier planReliez la sortie de statut du node client à quelque chose qui journalise et alerte. Testez en bloquant l'endpoint au pare-feu et regardez si le flow récupère seul ou s'il faut un redeploy, car la réponse dépend du package et de la version.
7. Sortez les données vers un stockage durable immédiatementEnvoyez les messages directement vers un broker MQTT, une base de données temporelle ou un fichier, et gardez les transformations après ce saut. Node-RED redémarre à chaque déploiement, et tout ce qui n'est alors conservé que dans le contexte du flow est perdu.

À quoi ressemble l'espace d'adressage

Node-RED ne construit pas de modèle. Chaque message transporte une valeur, ou un petit lot, avec ce que le paquet de nœuds a choisi d'exposer du DataValue : en général la valeur elle-même, parfois le StatusCode et les horodatages, et souvent pas l'information de type. La structure de l'espace d'adressage est quelque chose que vous redécouvrez flux par flux avec un nœud de browse, et elle n'est pas conservée. C'est acceptable pour du prototypage et pour de la glu, mais cela signifie que la sémantique de vos données vit dans la disposition du flux et dans les noms de nœuds, qui ne sont ni interrogeables, ni versionnés par défaut, ni portables vers la machine suivante. Si la même correspondance doit servir deux fois, générez la liste de NodeId à partir d'un browse et conservez-la dans un fichier que le flux lit.

Les pièges

• Les nœuds communautaires ne sont uniformes ni en qualité ni en maintenance. Les noms de nœuds, les formats de message et l'organisation des répertoires de certificats varient d'un paquet à l'autre et d'une version à l'autre d'un même paquet : notez donc contre quel paquet et quelle version un flow a été construit.
• Un index d'espace de noms littéral collé dans chaque node est le mode de défaillance classique de Node-RED. Après un chargement de programme automate, tout le flow renvoie BadNodeIdUnknown d'un coup, et il n'y a pas d'endroit unique où corriger.
• La gestion des certificats est le point faible de la plupart des paquets, ce qui explique pourquoi tant de collecteurs Node-RED en production tournent discrètement avec la sécurité None. C'est une décision que quelqu'un doit prendre consciemment, pas un défaut dont on hérite.
• Node-RED est monothread. Un abonnement avec un intervalle de publication de 50 ms sur quelques centaines d'items affamera la boucle d'événements et rendra l'éditeur lui-même inutilisable, et le symptôme ressemble à un problème réseau.
• Un déploiement redémarre les flux, ce qui coupe les sessions et les abonnements. Déployer une petite modification de tableau de bord interrompt la collecte : une instance Node-RED qui collecte ne devrait donc pas être aussi celle que l'on édite pendant un poste.
• Il n'y a pas de store-and-forward. Si le puits en aval est indisponible, les messages sont simplement perdus, sauf si vous avez construit vous-même un tampon.
• Les limites de sessions côté serveur sont consommées par nœud client, et un flow comportant plusieurs nœuds client contre un seul serveur automate embarqué peut les épuiser.

En extraire les données OEE

Node-RED est un bon outil pour explorer ce qu'une machine expose et un mauvais outil pour calculer le TRS. Il sait lire une variable d'état, un compteur et un code motif et les transmettre, ce qui est réellement utile pour une preuve de concept ou pour une machine qu'aucun autre moyen n'atteint. Ce qu'il ne vous donnera pas, c'est la fiabilité qu'exige le calcul : pas de tampon durable, une collecte interrompue à chaque déploiement, et un séquencement qui dépend d'une boucle d'événements partagée avec tout le reste de l'instance. Si un collecteur Node-RED part en production, limitez-le à une seule tâche, acheminez les valeurs immédiatement vers un broker ou une base de données en conservant intacts les horodatages serveur, et calculez disponibilité, performance et qualité en aval, là où un trou est visible et retraitable. Le temps de production planifié, les calendriers d'équipe et les temps de cycle standard ne sont pas dans la machine et ne doivent pas être codés en dur dans un flow.

Dernière vérification le 7 septembre 2026 par rapport à OPC UA 1.05.07. OPC UA Connect est une ressource pédagogique et n'est pas affiliée à l'OPC Foundation.