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.
Clients et serveurs
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.
Points 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. 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. Il contient un index d’espace de noms et un identifiant :
| NodeId | Index d’espace de noms | Type d’identifiant | Identifiant |
|---|---|---|---|
ns=2;s=LineA.Temperature | 2 | Chaîne | LineA.Temperature |
ns=3;i=1001 | 3 | Numérique | 1001 |
i=2258 | 0 (espace de noms OPC UA) | Numérique | 2258, heure actuelle du serveur |
L’index d’espace de noms désigne une position dans le NamespaceArray du serveur ; chaque position contient un URI d’espace de noms. La partie 3 de la spécification définit cette relation. L’URI est le nom stable. L’index peut changer quand la configuration ou le micrologiciel du serveur change :
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 la valeur actuelle |
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 son NodeId complet, index d’espace de noms compris : vérifiez donc cet 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.