Chaque nœud d’un serveur OPC UA possède un NodeId : un index d’espace de noms et un identifiant, notés ns=2;s=LineA.Temperature. L’identifiant appartient à l’un des quatre types suivants : numérique (i=), chaîne (s=), GUID (g=) ou octets opaques (b=). Un client, par exemple un système SCADA ou une passerelle, se connecte à un point de terminaison du serveur et utilise les NodeIds pour lire, écrire ou s’abonner.
Une intégration OPC UA qui lit la bonne valeur aujourd’hui peut en lire une autre après une mise à jour du serveur si l’identifiant enregistré n’est pas stable. Un serveur OPC UA possède un espace d’adressage : un ensemble de nœuds décrivant les équipements, leurs valeurs et leurs relations. Une intégration fiable identifie chaque valeur par son NodeId et son espace de noms, et conserve son état et ses horodatages. Ce guide explique ces identités et montre comment valider un point avant d’en ajouter cent.
Ce guide fait partie de la série OPC UA et MQTT. Il traite des échanges habituels entre client et serveur fondés sur une session, et non d’OPC UA PubSub.
Client et serveur OPC UA
La vue d’ensemble de l’OPC Foundation (partie 1) distingue deux rôles. Le serveur possède l’espace d’adressage et propose des services qui y donnent accès. Le client se connecte et utilise ces services. Une application peut exercer les deux rôles : une passerelle peut lire le serveur d’un automate comme client et proposer son propre serveur à un système SCADA. Ce sont deux interfaces à spécifier et à tester séparément. Une couche qui expose un ancien serveur OPC DA par un serveur UA est un cas courant ; le guide de migration OPC DA l’explique.
Vérifiez séparément chaque service nécessaire au projet : Browse, Read, Write, abonnements (éléments surveillés), appels de méthodes et accès à l’historique. La lecture réussie d’une valeur scalaire prouve seulement que la lecture fonctionne pour ce nœud et cet utilisateur.
URL de point de terminaison et sécurité
Une URL de point de terminaison comme opc.tcp://plc-line-a.example:4840/UA/Process identifie une connexion, pas une valeur. opc.tcp désigne le protocole binaire sur TCP. Le port 4840 est celui que l’IANA enregistre pour OPC UA sur TCP, mais de nombreux serveurs en écoutent un autre : copiez donc l’URL indiquée par le serveur. Chaque point de terminaison annonce dans son EndpointDescription :
- une politique de sécurité, soit l’ensemble des algorithmes ;
- un mode de sécurité des messages : None, Sign ou SignAndEncrypt ;
- les types de jeton utilisateur acceptés : accès anonyme, nom d’utilisateur et mot de passe, ou certificat.
Deux décisions de confiance distinctes suivent. Le client et le serveur doivent reconnaître leurs certificats d’application respectifs. Le serveur doit ensuite autoriser l’utilisateur. Reconnaître un certificat n’autorise pas l’utilisateur ; l’ouverture d’une connexion TCP ne prouve ni l’un ni l’autre. Consignez le point de terminaison, la politique et le mode de sécurité, l’identité de l’utilisateur et l’emplacement où chaque certificat est reconnu.
NodeIds et espaces de noms
Un NodeId identifie un nœud. La partie 3 de la spécification (OPC 10000-3, 8.2) lui donne trois éléments : un index d’espace de noms (un UInt16), un type d’identifiant et l’identifiant. La partie 6 (OPC 10000-6, 5.1.12) définit la forme textuelle ns=<index>;<type>=<identifiant>. Il existe quatre types d’identifiant :
| Type d’identifiant | Préfixe | Exemple | Règles |
|---|---|---|---|
| Numérique | i= | ns=3;i=1001 | Un entier non signé. Les nœuds définis par l’OPC Foundation sont numériques : i=2258 est l’heure actuelle du serveur |
| Chaîne | s= | ns=2;s=LineA.Temperature | Jusqu’à 4 096 caractères, sans caractère de contrôle |
| GUID | g= | ns=4;g=09087e75-8e5e-499b-954f-f2a9603db28a | 32 chiffres hexadécimaux sous la forme 8-4-4-4-12 |
| Opaque | b= | ns=5;b=M/RbKBsRVkePCePcx24oRA== | Octets codés en Base64, jusqu’à 4 096 octets, dans un format défini par le serveur |
L’espace de noms 0 est celui d’OPC UA, http://opcfoundation.org/UA/, et ses NodeIds s’écrivent sans ns=, comme i=2258. L’index 1 est réservé à l’espace de noms local du serveur (OPC 10000-5, 6.3.1). Les espaces de noms du modèle d’information d’un appareil ou des variables d’un automate commencent à l’index 2 ou au-delà. La partie 6 autorise aussi l’URI à la place de l’index, comme nsu=urn:example:process-model;s=LineA.Temperature, mais les clients et outils plus anciens n’acceptent pas cette forme.
L’index d’espace de noms désigne une position dans le NamespaceArray du serveur ; chaque position contient un URI d’espace de noms. L’URI est le nom stable. L’index peut changer quand la configuration ou le micrologiciel du serveur change. La partie 5 interdit à un serveur de modifier ou de supprimer des entrées tant qu’un client a une session ouverte et lui recommande de n’ajouter que de nouvelles entrées, mais elle admet qu’un changement peut être inévitable : un client doit donc vérifier les index à l’ouverture de chaque session :
Consignez l’URI d’espace de noms avec chaque NodeId dans la liste des points. Après toute modification du serveur, vérifiez le NamespaceArray avant de réutiliser les anciens index.
Un nom d’affichage et un chemin de navigation ne sont pas non plus des NodeIds. Utilisez-les pour trouver un nœud, puis consignez son NodeId.
Valeur, état et horodatages
Une lecture renvoie un DataValue, défini dans la partie 4. Conservez tous ses éléments :
| Champ | Ce qu’il indique |
|---|---|
| Value | La valeur, selon le type de données du nœud : scalaire, tableau ou structure |
| StatusCode | Good, Uncertain ou Bad, avec un motif |
| SourceTimestamp | Instant où la valeur a été mesurée ou modifiée à la source, si le serveur le connaît |
| ServerTimestamp | Dernier instant où le serveur savait que la valeur était à jour |
Règles d’utilisation :
- Vérifiez d’abord l’état. Une valeur Bad n’est pas une mesure. Définissez une règle pour les valeurs Uncertain.
- Distinguez les deux horodatages. Une valeur stable peut conserver un ancien horodatage source tandis que le serveur la confirme à plusieurs reprises. « Aucune variation depuis une heure » ne signifie pas « aucune communication depuis une heure ».
- Vérifiez le type de données. Consignez le type déclaré et le fait que la valeur soit ou non un tableau. Un compteur UInt64 est valide en OPC UA, mais peut perdre en précision dans un logiciel qui stocke les nombres en virgule flottante sur 64 bits.
- Sachez quel horodatage conserve le collecteur. Certains collecteurs enregistrent celui du serveur ou de la source ; d’autres enregistrent l’heure de leur propre lecture. Le guide des horodatages explique la différence.
Valider un point, puis élargir
Pour le premier point, notez le point de terminaison, les réglages de sécurité, l’utilisateur, l’URI d’espace de noms, le NodeId, le type de données, l’unité, tout facteur d’échelle et l’intervalle de lecture. Ensuite :
- Comparez la valeur à une référence indépendante pendant qu’elle varie.
- Relevez le code d’état et les horodatages sur le serveur, dans le collecteur et à la destination finale.
- Arrêtez la source ou la connexion, avec autorisation. Les données doivent présenter une lacune ou un état Bad ou Uncertain, pas une ancienne valeur avec un nouvel horodatage.
- Redémarrez le collecteur et vérifiez qu’il relit le même nœud.
- Lisez un nœud inexistant, puis un nœud auquel cet utilisateur n’a pas accès. Chaque essai doit échouer clairement, sans renvoyer la valeur d’un autre nœud.
Testez les écritures séparément, avec l’autorisation du responsable de l’équipement et une vérification indépendante de l’effet physique.
OPC UA avec Edge
Edge, sur le Gateway ZGW-20, est un client OPC UA. Il se connecte à un point de terminaison avec la politique et le mode de sécurité proposés par le serveur (None, Sign ou SignAndEncrypt), en accès anonyme, avec un nom d’utilisateur ou avec un certificat. Il lit chaque nœud de variable selon une fréquence définie, d’une fois par seconde à une fois par jour, et applique si besoin un multiplicateur et un décalage. Edge adresse chaque nœud par la chaîne complète de son NodeId, jusqu’à 512 caractères, index d’espace de noms compris. Copiez le NodeId depuis l’espace d’adressage du serveur, car un nom de navigation seul n’est pas une adresse, et vérifiez l’index après toute modification du serveur. Chaque valeur reçoit un horodatage lorsque Edge la lit.
Questions fréquentes
Qu’est-ce qu’un NodeId en OPC UA ?
L’identifiant d’un nœud dans l’espace d’adressage d’un serveur. Il comprend un index d’espace de noms et un identifiant, qui peut être un nombre, une chaîne, un GUID ou des octets. Par exemple, ns=2;s=LineA.Temperature est l’identifiant de chaîne LineA.Temperature dans l’espace de noms 2.
Qu’est-ce qu’un espace de noms OPC UA ?
Un groupe d’identifiants de nœuds nommé par un URI. Le serveur énumère ses espaces de noms dans son NamespaceArray ; un NodeId en désigne un par sa position dans ce tableau. L’URI est stable, mais la position (l’index) peut changer lorsque la configuration du serveur change.
Quelle différence entre client et serveur OPC UA ?
Le serveur possède l’espace d’adressage et y propose des services. Le client se connecte pour parcourir les nœuds, lire, écrire ou s’abonner. Une application peut exercer les deux rôles : une passerelle peut lire le serveur d’un automate comme client et proposer son propre serveur à un SCADA.
Que signifie un code d’état OPC UA ?
Chaque valeur renvoyée par un serveur comporte un code d’état : Good, Uncertain ou Bad, avec un motif. Une valeur Bad ne doit pas être utilisée comme mesure. Le projet doit convenir d’une règle pour les valeurs Uncertain.
Que signifie ns=2;s= dans un NodeId OPC UA ?
ns=2 est l’index d’espace de noms, la position 2 du NamespaceArray du serveur. s= indique que l’identifiant qui suit est une chaîne. Les autres types d’identifiant sont i= pour un nombre, g= pour un GUID et b= pour des octets opaques en Base64. Un NodeId de l’espace de noms 0, comme i=2258, s’écrit sans ns=.
L’index d’espace de noms d’un NodeId peut-il changer ?
Oui. OPC 10000-5 interdit à un serveur de modifier ou de supprimer des entrées de sa table des espaces de noms tant qu’un client a une session ouverte, et lui recommande de n’ajouter que de nouvelles entrées. La norme admet aussi qu’un changement peut être inévitable : un client doit donc vérifier les index à l’ouverture d’une session. L’URI de l’espace de noms, lui, ne change pas.