Connecter OPC UA à Azure IoT Edge / OPC Publisher
| Produit | Azure IoT Edge / OPC Publisher |
|---|---|
| Catégorie | Cloud |
| Rôle OPC UA | Client |
OPC Publisher est un client OPC UA qui s'exécute comme module IoT Edge, s'abonne aux nœuds que vous listez dans un fichier de configuration et les transmet à Azure IoT Hub en JSON. C'est le chemin OPC UA vers le cloud le mieux documenté, et son problème le plus difficile relève des certificats et non du code.
Avant de commencer
- Un runtime IoT Edge sur une passerelle capable d'atteindre à la fois les serveurs OPC UA et le cloud.
- Un fichier de configuration published-nodes listant les endpoints et les node ids auxquels s'abonner.
- Un plan indiquant comment le certificat du publisher sera approuvé sur chaque serveur auquel il parle. C'est cette partie qui retarde les déploiements, pas le conteneur.
- Un accès réseau sortant depuis la passerelle. Le côté OPC UA est uniquement entrant du point de vue du publisher, ce qui le rend compatible avec un réseau en couches.
Mise en place
- Rédigez le fichier published-nodesUne entrée par endpoint, chacune avec une liste de node ids, leurs intervalles de publication et d'échantillonnage et une bande morte optionnelle. Stockez l'URI de namespace dans le node id là où la syntaxe le permet, plutôt qu'un index brut, pour qu'un chargement d'automate ne casse pas silencieusement la collecte.
- Déployez le moduleDéployez-le comme module IoT Edge avec le fichier de configuration et un volume persistant pour son répertoire PKI. Le volume n'est pas optionnel - voir les pièges.
- Faites approuver le publisher sur chaque serveurÀ la première connexion, le certificat du publisher atterrit dans le magasin des rejetés de chaque serveur. Un administrateur doit le déplacer vers le magasin de confiance, sur chaque serveur. Prévoyez un temps réel pour cela à l'échelle d'un parc, ou déployez d'abord une approche de gestion des certificats.
- Choisissez l'encodage délibérémentLe publisher peut émettre du JSON réversible ou non réversible. Le non réversible est plus compact et plus lisible, mais il perd l'information de type et ne peut pas faire l'aller-retour. Décidez-en avant que des consommateurs en aval ne soient écrits contre lui.
- Vérifiez ce qui arriveContrôlez les messages dans IoT Hub et confirmez que le code de statut et le SourceTimestamp ont survécu. En encodage JSON, un statut Good vaut 0 et est entièrement omis : un champ de statut absent signifie donc Good et non donnée manquante - le code en aval doit être écrit en le sachant.
- Réglez avant de monter en chargeFixez les intervalles de publication à ce dont le consommateur cloud a besoin plutôt qu'au plus rapide que le PLC accepte, appliquez des bandes mortes sur les analogiques, et gardez un petit nombre d'intervalles distincts. Chaque intervalle distinct devient un abonnement de plus sur le serveur.
À quoi ressemble l'espace d'adressage
Le publisher ne modélise rien: il retransmet les nœuds que vous listez. La sémantique reste là où vous l'avez mise, ce qui signifie en pratique soit que les identifiants de nœuds portent du sens par convention, soit que quelque chose en aval la rattache. Si la machine implémente une spécification companion, cette structure est perdue, sauf si vous l'encodez dans le nommage de vos topics ou de vos tags.
Les pièges
- Un volume PKI non persistant régénère le certificat d'application à chaque redémarrage du conteneur : la liste de confiance de chaque serveur se périme donc à chaque déploiement. C'est la défaillance de déploiement la plus courante d'OPC Publisher.
- La documentation dit clairement que faire accepter le certificat du publisher par les équipements est le plus gros obstacle que rencontrent la plupart des administrateurs OT. Traitez-le comme une tâche de projet avec un responsable, pas comme un détail de configuration.
- Le JSON non réversible perd silencieusement l'information de type. Un consommateur en aval ne peut pas distinguer un Int32 d'un Double, ce qui compte dès que quelqu'un fait un calcul.
- Le reverse connect n'est pris en charge qu'en opc.tcp, et le publisher écoute pour cela sur un port configurable. Utile à travers un réseau segmenté selon Purdue où seul le sortant est autorisé.
- Des indices de namespace codés en dur dans un fichier published-nodes cassent après un chargement de programme automate. Utilisez les URI de namespace là où la syntaxe des identifiants de nœuds le permet.
En extraire les données OEE
La disponibilité, les comptages et les motifs remontent tous vers le cloud si la machine les expose, mais le publisher transmet des valeurs sans les interpréter. Les transitions de machine à états arrivent comme des changements de valeur : le calcul des durées se fait donc en aval et dépend de votre intervalle de publication - un intervalle de 10 secondes ne peut pas résoudre un micro-arrêt de 3 secondes. Abonnez-vous aux événements de condition de la Part 9 pour les motifs d'arrêt plutôt que d'interroger un registre de motifs. Le temps de production planifié et le contexte d'ordre de fabrication ne sont pas dans la machine et n'apparaîtront pas ici.
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.