Qu'est-ce qu'un NodeId opaque en OPC UA ?

Un NodeId OPC UA identifie un nœud dans l'espace d'adressage d'un serveur. Le format le plus documenté est une chaîne lisible (ns=2;s=Temperature), mais certains serveurs, CODESYS notamment, utilisent aussi un identifiant binaire encodé (ns=2;b=...), impossible à deviner ou à retaper à la main.

Comment parcourir l'espace de noms OPC UA avec UaExpert ?

UaExpert se connecte au serveur puis affiche une arborescence à partir du nœud ObjectsFolder. Chaque dossier peut être déplié pour révéler ses variables, avec leur NodeId réel et leur valeur en direct. La méthode reste la même quel que soit le format du NodeId, lisible ou opaque.

← Blog Lire en anglais

NodeId OPC UA opaque : pourquoi on ne le retape pas à la main

6 septembre 2026· OPC UA · CODESYS · UaExpert

La documentation OPC UA donne toujours le même exemple de NodeId : ns=2;s=Temperature. Un index de namespace, un identifiant texte lisible. Sur cette base, la tentation est de considérer le NodeId comme une simple chaîne à taper une fois qu'on connaît le nom de la variable côté automate.

Ça fonctionne, jusqu'au jour où le serveur renvoie autre chose :

ns=2;b=AQAAAAQAAABudW1iZXI=

Pourquoi certains identifiants sont illisibles

OPC UA autorise plusieurs types d'identifiant pour un même nœud : une chaîne (s=), un entier numérique (i=), un GUID (g=), ou une séquence d'octets encodée (b=). Le standard ne force aucun serveur à choisir la forme lisible.

Sur un test réel contre un automate CODESYS (Control Win V3, serveur OPC UA local), une bonne partie des variables applicatives exposaient leur NodeId sous cette dernière forme opaque. Rien dans le nom de la variable côté programme ne permettait de reconstituer la chaîne : l'identifiant est généré par le serveur, pas par le développeur de l'automate.

Face à ce format, retaper un NodeId à la main n'est plus une option lente. C'est une opération impossible : il n'existe rien à retaper, l'identifiant n'a pas d'équivalent lisible qu'un humain pourrait déduire.

La seule méthode qui marche dans tous les cas

Un client OPC UA (UaExpert est le plus répandu pour cet usage) ne demande jamais à l'utilisateur de connaître un NodeId à l'avance. Il se connecte au serveur, puis parcourt son espace de noms à partir du nœud racine (ObjectsFolder), dossier par dossier, jusqu'aux variables. Le NodeId réel, lisible ou opaque, apparaît alors dans l'outil : il n'y a plus besoin de le deviner, seulement de le lire.

Cette méthode fonctionne pour un NodeId s= comme pour un NodeId b=, parce qu'elle ne dépend jamais du format de l'identifiant. C'est la seule approche qui marche à tous les coups, pas seulement quand le serveur choisit la forme lisible.

Ce qu'on trouve en pratique : beaucoup de bruit, peu de signal

Un espace de noms OPC UA ne contient pas que les variables applicatives. Il porte aussi toute la structure standard du protocole : informations sur le serveur, ses capacités, ses espaces de noms déclarés.

Sur le même test réel, le parcours complet du serveur a remonté 51 nœuds. 47 d'entre eux appartenaient à cette structure standard (Server/ServerCapabilities, Server/Namespaces, Server/ServerStatus) et existent à l'identique sur n'importe quel serveur OPC UA, quel que soit l'automate branché derrière. Seuls 3 nœuds correspondaient à de vraies variables de l'application : une température, une pression, un code défaut.

Parcours de l'espace de noms

0 / 51 nœuds

Serverns=0;i=2253

Server / ServerCapabilitiesns=0;i=2268

Server / ServerStatusns=0;i=2256

Server / Namespacesns=0;i=11715

Application / Ligne1 / Temperaturens=2;b=AQAAAAQAAA==

Application / Ligne1 / Pressionns=2;b=AQAAAAUAAA==

Server / VendorServerInfons=0;i=2254

Application / Ligne1 / DefautCodens=2;b=AQAAAAYAAA==

3 variables utiles sur 51 nœuds parcourus — le reste est la tuyauterie standard OPC UA, présente sur tout serveur.

Trouver ces 3 variables dans un tableau plat de 51 lignes est fastidieux et source d'erreur. Filtrer la branche standard du serveur avant de présenter le résultat change concrètement le temps passé à configurer un point.

Comment Nodal automatise ce parcours

Le principe reste celui d'UaExpert, intégré directement dans l'écran d'ajout d'un équipement OPC UA : renseigner l'IP et le port du serveur suffit. La passerelle se connecte, parcourt l'espace de noms, filtre les nœuds de structure standard (le nœud Server, NodeId bien connu ns=0;i=2253, et ses descendants), et affiche le résultat sous forme d'arborescence dépliable. Un dossier peut se cocher entièrement, ou partiellement si seule une partie de son contenu intéresse.

Deux points valent d'être précisés, parce qu'ils ne sont pas visibles à l'écran :

Le scan se lance depuis la passerelle, pas depuis le cloud. Un serveur OPC UA vit sur le réseau privé du client, que le cloud ne peut pas joindre directement : c'est la passerelle qui exécute le parcours et transmet le résultat.
La saisie manuelle d'un NodeId reste possible en parallèle. Pour un serveur qui expose des identifiants lisibles et déjà connus, taper la chaîne directement reste plus rapide que de parcourir l'arborescence.

Le scan n'est donc pas une alternative de confort à la saisie manuelle. Pour un NodeId opaque, c'est la seule voie qui fonctionne.

Questions fréquentes

Qu'est-ce qu'un NodeId opaque en OPC UA ?: Un NodeId OPC UA identifie un nœud dans l'espace d'adressage d'un serveur. Le format le plus documenté est une chaîne lisible (ns=2;s=Temperature), mais certains serveurs, CODESYS notamment, utilisent aussi un identifiant binaire encodé (ns=2;b=...), impossible à deviner ou à retaper à la main.
Comment parcourir l'espace de noms OPC UA avec UaExpert ?: UaExpert se connecte au serveur puis affiche une arborescence à partir du nœud ObjectsFolder. Chaque dossier peut être déplié pour révéler ses variables, avec leur NodeId réel et leur valeur en direct. La méthode reste la même quel que soit le format du NodeId, lisible ou opaque.

Dayen Driss

CEO, Nodal

Fondateur de Nodal, où il développe la passerelle Edge et la plateforme cloud.