OPC UA

Un client OPC UA pour des serveurs tiers, avec une confiance gouvernée par les certificats, un adressage par identifiant de nœud et la découverte de l'espace d'adressage.

Le pilote OPC UA est un client pour des serveurs OPC UA tiers : automates, passerelles, historiens, autres systèmes SCADA, sur opc.tcp. C'est le pendant sortant du serveur OPC UA intégré qui publie l'espace d'adressage propre à cette station (décrit sous Serveur OPC UA); les deux partagent l'identité d'application de la station mais font confiance à leurs pairs indépendamment.

Équipement

Préparer le serveur

La plupart des serveurs OPC UA refusent d'origine un nouveau client, par deux réglages qui leur sont propres, tous deux faits sur le serveur :

Où les serveurs courants font confiance au certificat d'un client :

Quand le serveur refuse pour l'une ou l'autre raison, la page de l'équipement dit laquelle dans un avis qui prend la place de l'état du serveur. Pour le certificat, il donne son nom et son empreinte (SHA-1, celle par laquelle les serveurs l'affichent), chacun avec un bouton de copie, et le fichier avec un bouton qui ouvre son dossier. Pour l'utilisateur, il dit si le serveur n'accepte aucune session anonyme ou s'il a refusé l'utilisateur, et renvoie au Nom d'utilisateur et au Mot de passe de l'équipement. L'avis disparaît de lui-même dès qu'une session s'ouvre, et le journal et l'agent lisent la même consigne. Cette station émet un nouveau certificat quand son nom d'application ou son nom réseau change, et le serveur doit alors faire confiance au nouveau.

Sécurité et certificats

La connexion commence par la liste des endpoints du serveur : le client choisit l'endpoint le plus sûr que le serveur annonce et authentifie l'application avec le certificat propre à cette station, la même identité d'application OPC UA qu'emploie le serveur intégré. Beaucoup de serveurs exigent que ce certificat soit approuvé de leur côté avant d'accepter la session : Préparer le serveur dit où.

Un équipement qui n'annonce rien de mieux qu'un endpoint sans sécurité est refusé, et l'équipement dit pourquoi. Cette session ferait circuler les lectures et les identifiants en clair et ne prouverait aucune identité d'équipement : elle ne s'ouvre donc que là où vous l'avez demandée sur cet équipement, par Sécurité de la session, Autoriser une session sans sécurité, sur la carte de connexion. Le choix appartient à cet équipement-là, voyage dans son adresse sous la forme ?security=none et vaut aussi bien pour la session de lecture que pour le parcours de la découverte. L'activer ne dégrade jamais un équipement qui offre de la sécurité : c'est toujours l'endpoint le plus sûr annoncé qui est retenu.

Dans l'autre sens, la confiance est fermée par défaut et explicite. Le certificat de l'équipement est vérifié avant l'ouverture de la session :

• Un certificat que cette station n'a jamais approuvé est refusé, enregistré pour examen, et le volet de l'équipement montre un avis qui nomme l'approbation attendue : l'équipement n'est pas « hors ligne », il attend une décision.
• Vous examinez les certificats sur la carte Accès des équipements de cette page, la moitié sortante de la confiance par certificat : un certificat enregistré reste sous En attente d'approbation jusqu'à ce que vous cliquiez sur Approuver (de nouvelles sessions peuvent s'ouvrir) ou sur Bloquer (refusé sans redemander sans cesse). C'est la liste des équipements; Accès des clients, sur le volet du Serveur OPC UA, est l'autre sens : qui a le droit de se connecter en entrée au serveur propre à cette station.
• Retirer l'approbation, sur une ligne approuvée, ferme les sessions en cours qui reposaient sur ce certificat et le renvoie à la liste d'examen, si bien que la prochaine connexion vous redemandera.
• Un équipement qui ne présente aucun certificat ne prouve rien sur qui a répondu : il n'y a donc rien à approuver et la session est refusée, son adresse écrite au journal. Il ne se connecte que sous ce même Autoriser une session sans sécurité, qui tient alors lieu d'approbation.

Approuver le serveur d'un équipement n'autorise jamais ce certificat à se connecter en entrée au serveur propre à cette station : les deux sens gardent des dépôts distincts, délibérément.

Le comportement d'une session

Les tags sont scrutés : chaque lecture demande au serveur la valeur courante du nœud. Le verdict propre au serveur voyage avec chaque échantillon : une valeur marquée Bad ou Uncertain est refusée et le tag lit une mauvaise qualité, si bien qu'une source douteuse n'est jamais blanchie en une bonne lecture. Un nœud qui n'existe plus sur le serveur se lit comme aucune valeur plutôt que de faire échouer tout l'équipement.

L'horodatage du serveur voyage lui aussi avec l'échantillon : le SourceTimestamp qu'il a donné à une bonne valeur devient l'Horodatage source du tag sur la page du tag. Un serveur peut garder cet horodatage jusqu'à ce que la valeur ou sa qualité change, si bien qu'une valeur stable peut afficher un horodatage antérieur à l'Horodatage de l'application, qui est toujours l'instant où la station a reçu la lecture.

La session est surveillée par des messages de maintien; après trois maintiens manqués, le client lance une reconnexion automatique et poursuit. La boucle de reprise en arrière-plan de l'application possède la connexion initiale, si bien qu'un serveur injoignable ne coûte rien au démarrage.

Adressage d'un tag

Un tag est adressé par son ID de nœud, saisi en texte libre et envoyé tel quel. Les formes acceptées sont les notations OPC UA standard :

Le tag lit et écrit l'attribut Value du nœud.

Types de valeur

Les valeurs sont scalaires seulement : les tableaux, les structures et les autres valeurs complexes sont refusés comme illisibles plutôt qu'aplatis en un nombre trompeur, et le tag lit une mauvaise qualité. Un tel tag échoue tout seul; les autres tags de l'équipement continuent de lire, et rien n'est reconnecté à cause de lui. Une chaîne vide est une valeur, pas un échec. Les types hors de l'ensemble offert ne sont pas disponibles comme type d'un tag sur ce pilote : SByte, les largeurs non signées autres que Byte (UInt16, UInt32, UInt64), DateTime, Guid et ByteString.

Un tag dont le type diffère de celui du nœud est converti par son nombre, jamais relu à travers ses octets, et la même règle vaut en lecture comme en écriture. Un réel va vers un réel (Float et Double), et un entier vers un entier d'une autre largeur quand la valeur y tient; un tag Boolean sur un nœud entier lit 0 et 1 comme arrêt et marche et les écrit comme 0 et 1. Une valeur qui ne tient pas, ou un nœud qui porte une autre sorte de valeur (un réel pour un tag entier, un nombre pour un tag texte), est refusée sur ce seul point, et une écriture refusée ainsi n'est jamais envoyée au serveur.

Le balayage d'un serveur offre donc moins de voies que le serveur n'en porte : un nœud qui déclare une liste de valeurs ou qui en porte une quand le balayage le lit, et un nœud dont le type est hors de l'ensemble offert, sont laissés de côté. Bien des serveurs laissent ouverte la forme déclarée d'une variable (un ValueRank Any ou ScalarOrOneDimension) même quand elle ne porte jamais qu'une seule valeur; un tel nœud est donc jugé sur la valeur qu'il porte quand le balayage le lit, et il est offert sauf si cette valeur est une liste. S'il porte une liste plus tard, ce seul tag échoue sur ses propres lectures, comme pour toute valeur qu'un tag ne peut pas porter, et les autres tags de l'équipement continuent de lire. Le type d'un nœud est le type de base dont dérive le type qu'il déclare : un nœud déclaré en VersionTime porte un UInt32 et un nœud déclaré en UtcTime un DateTime, si bien que les deux sont laissés de côté, alors qu'un nœud déclaré en Duration porte un Double et est offert. Les serveurs qui laissent la forme ouverte laissent souvent ouvert aussi le type déclaré (BaseDataType, ou Number, Integer ou UInteger, des types sous lesquels aucune valeur ne voyage); un tel nœud prend donc le type de la valeur qu'il porte quand le balayage le lit, et il est offert ou laissé de côté selon ce type. Un tel nœud dont la lecture ne rapporte aucune valeur ne montre aucun type et est laissé de côté. Si le serveur envoie plus tard une valeur d'un autre type, cette valeur est lue selon la règle de conversion ci-dessus, et ce seul tag n'échoue que là où la règle la refuse. Ils ne sont pourtant pas abandonnés en silence. Le balayage les compte et son message de clôture dit combien et de quelle sorte, par exemple « 5 voies ont été laissées de côté : 3 de type UInt32, 2 qui portent une liste de valeurs au lieu d'une seule valeur. », si bien qu'une liste courte se lit comme une liste courte et non comme un automate nu.

Un nœud auquel le serveur répond sans aucune valeur est laissé de côté lui aussi, sans être compté : il ne porte rien, et une fois importé, il ne lirait jamais. Un nœud dont la valeur revient Bad est quand même offert, sauf s'il déclare une liste, ou s'il déclare un type ouvert et ne rapporte aucune valeur d'où le tirer : ce statut dit seulement que sa source n'a pas encore répondu, ou que la session anonyme du balayage n'a pas le droit de le lire, et l'équipement ouvre sa session avec ses propres identifiants.

Écritures

Un tag inscriptible écrit l'attribut Value du nœud par le service Write d'OPC UA. La réponse du serveur est le verdict : une écriture rejetée remonte comme un échec, et la valeur en cache n'avance qu'à l'acceptation. Comme partout, le champ d'écriture prend la valeur physique et la chaîne de conversion est remontée avant que la valeur brute ne parte.

Découverte

La commande Découvrir prend une cible dans le champ qui la précède : une adresse de serveur OPC UA telle que opc.tcp://plc-host:4840. Le balayage a deux étapes, et la ligne d'avancement nomme celle qui tourne :

1. Endpoints : le service de découverte standard de la cible est interrogé et chaque URL de découverte annoncée devient un endpoint candidat. Les ports et les chemins de serveur particuliers reviennent intacts dans les champs de connexion du candidat.
2. Voies : l'espace d'adressage de chaque candidat est parcouru depuis le dossier Objects vers le bas, et chaque variable lisible est listée comme tag candidat avec son type et son accès, sauf les nœuds que Types de valeur laisse de côté. Les zones de diagnostic du serveur sont sautées.

Un tag candidat porte le nom de son propre nœud (son BrowseName), précédé d'aussi peu de noms des nœuds au-dessus de lui qu'il en faut pour le distinguer des autres voies que le serveur offre : Level plutôt que Devices.Simulated.Tank.Level sur le serveur d'une autre station, et Line1.Speed à côté de Line2.Speed seulement là où deux nœuds nommés Speed se rencontreraient. Deux noms qui se liraient encore pareil, qui ne diffèrent que par la casse ou la ponctuation, sont départagés par un numéro. Le chemin complet du parcours reste sur la carte du candidat, sur une deuxième ligne sous le nom, pour que vous sachiez quel nœud chaque tag lit. Le tag lit son ID de nœud : le nom n'est donc que la façon dont il s'appelle, dans la grille des tags et à la fin de son adresse (Connector.OpcUa.Peer.Level).

Le parcours ouvre une session anonyme (avec la même sélection de l'endpoint le plus sûr, le même refus d'une session sans sécurité et la même barrière du certificat d'équipement). Un serveur qui refuse les sessions anonymes, un serveur qui n'annonce aucun endpoint sécurisé, ou un parcours qui échoue pour une raison quelconque, laisse tout de même l'endpoint ajoutable avec zéro tag : ajoutez-le, posez les identifiants et la sécurité de la session sur l'équipement, et configurez les tags à la main. Rien n'est enregistré tant que vous n'avez pas cliqué sur Ajouter pour un candidat, et annuler garde les candidats qui étaient déjà complets.

Un serveur que vous avez déjà lit davantage de ses nœuds depuis la page de son équipement : Découvrir les tags, dans l'en-tête de la carte des tags, parcourt l'endpoint de cet équipement en ouvrant la session comme le fait la session de l'équipement elle-même, avec son nom d'utilisateur, son mot de passe et la sécurité de sa session, si bien qu'un serveur qui refuse les sessions anonymes y montre aussi ses nœuds. Il ne propose que les nœuds qu'aucun tag de l'équipement ne lit encore, comparés au moyen de la table des espaces de noms du serveur : un tag écrit avec l'indice de son espace de noms (ns=2;s=Level) lit le nœud que le parcours nomme par l'URI de son espace de noms (nsu=…;s=Level), donc ce nœud n'est pas proposé de nouveau. Un serveur qui refuse la session termine le balayage avec la cause que donne la session de l'équipement elle-même (voir Découvrir les tags d'un équipement).

Des limites bonnes à connaître

• Les lectures sont des scrutations de l'attribut Value; le pilote ne crée aucun abonnement sur le serveur distant.
• Valeurs scalaires seulement : un tag ne peut adresser ni un élément de tableau, ni un champ de structure.
• La barrière d'approbation s'applique par certificat : un équipement qui renouvelle son certificat revient à la liste d'examen et attend une nouvelle décision.

Accès des équipements

La page du pilote OPC UA se termine par sa carte Accès des équipements : la moitié sortante de la confiance accordée aux certificats. Lorsque le Connector appelle un serveur OPC UA d'équipement, ce serveur prouve son identité par un certificat, et la station ne lit rien d'un équipement dont vous n'avez pas approuvé le certificat. L'en-tête de la carte le dit : « Lorsque le Connector appelle un serveur OPC UA d'équipement, ce serveur prouve son identité par un certificat. N'approuvez qu'une empreinte vérifiée auprès de la personne qui a mis l'équipement en service. » Voir Connector lit la carte; Configurer Connector décide, et les décisions se prennent sur le bureau propre à la station.

Le principe sous l'en-tête : « Rien n'est lu depuis un équipement que vous n'avez pas approuvé. Un équipement dont le certificat attend ici reste silencieux et le signale dans Connector. L'approuver lance la lecture; retirer l'approbation ferme la session et vous repose la question. Les noms de certificat sont déclarés par l'équipement; l'empreinte SHA-256 est l'identité à vérifier. »

La carte a délibérément la même forme qu'Accès des clients, avec les mêmes mots partout où l'idée est la même, et la même règle pour savoir qui peut décider : un navigateur sur un autre appareil voit « L'accès des équipements ne peut être modifié que dans l'application de bureau de la station. » et le bandeau « Ouvrez l'application de bureau pour modifier l'accès des équipements »; un rôle sans Configurer Connector ne se voit pas dessiner les boutons, et une unité en cours et une modification déjà en cours refusent chacune avec leur propre phrase. Chaque résultat aboutit dans la barre d'état.

Ce qu'un équipement en attente fait dans le Connector

La première fois que le Connector appelle un équipement OPC UA, le certificat de l'équipement est refusé, enregistré ici comme en attente, et l'équipement ne lit rien. Sur la page de l'équipement, le Connector montre un bandeau de prudence, En attente de l'approbation du certificat, avec un bouton Examiner le certificat qui ouvre cette section sur la ligne de l'équipement, et l'état de santé de l'équipement nomme le même état dans l'arborescence. L'échec propre au pilote dit la raison au lieu d'une erreur de poignée de main sans nom : « Le certificat de cet équipement (les 16 premiers caractères de l'empreinte) attend votre approbation sous Accès des équipements, sur la page du pilote OPC UA. La lecture commence dès que vous l'approuvez. » Un équipement bloqué affiche « … est bloqué sur cette station. Examinez-le sous Accès des équipements, sur la page du pilote OPC UA. » Le parcours de découverte passe le même contrôle avant l'ouverture de sa session.

Une fois approuvé, le Connector commence à lire à sa prochaine tentative. Un équipement qui lisait et qui se met à présenter un certificat différent à la même adresse cesse d'être lu et lève une carte persistante, « Certificat modifié : <name> » : « L'équipement à <address> lisait avec un certificat approuvé par cette station et en présente maintenant un autre (…), donc rien n'en est lu. Vérifiez l'empreinte auprès de la personne qui entretient l'équipement, puis approuvez-la. », avec Examiner, plus une notification Windows pour une fenêtre masquée. Un équipement en cours d'inscription à cet instant n'est pas annoncé ainsi : celui qui l'inscrit regarde déjà le Connector.

En attente d'approbation

Dessiné tant qu'au moins un certificat attend, avec en tête « Ces équipements ne sont pas lus tant que vous n'avez pas décidé. » et le compte. Chaque ligne montre un point ambre, le nom que le certificat déclare, « Identité d'équipement déclarée », l'empreinte, « <address> · Dernière tentative <date and time> · N tentatives de connexion », et un dépliage Détail du certificat avec le Sujet, l'Émetteur, l'URI de l'application, les Noms de domaine, Valide à partir du, Valide jusqu'au et Première apparition. La ligne vers laquelle un bouton Examiner a mené est marquée « Sélectionné pour examen » et amenée à l'écran.

La liste porte au plus 100 certificats. Tant qu'elle est pleine, un certificat de plus reste refusé mais n'est pas conservé, et la carte le dit : « La liste d'examen ci-dessous est pleine. Tant qu'elle l'est, un nouveau certificat est refusé sans être ajouté ici, donc l'équipement que vous attendez risque de ne jamais apparaître. Écartez les certificats en attente d'examen pour faire de la place. », avec le compte des refus depuis qu'elle est saturée dès qu'il y en a. Chacun de ces refus est journalisé.

Équipements approuvés

« Certificats avec lesquels le Connector peut ouvrir des sessions. », avec le compte. Chaque ligne montre un point neutre, le nom déclaré, « Identité d'équipement déclarée · Approuvé par <user> le <date and time> » (ou « sur cette station »), l'empreinte, et un dépliage de détail avec l'Adresse, le Sujet, l'Émetteur, l'URI de l'application, Valide jusqu'au et Dernière apparition. Quand il n'y en a aucun : « Aucun certificat d'équipement approuvé. »

L'indication sous l'en-tête : « Vous avez déjà le certificat public de l'équipement? Importez-le ici pour l'approuver avant la première connexion, au lieu de laisser la connexion échouer une fois. Vérifiez l'empreinte ajoutée par rapport à celle de la documentation de l'équipement. » Un équipement est habituellement livré avec son certificat, et c'est pourquoi ce côté-ci met l'import en premier. Importer un certificat bloqué lève le blocage. Retirer renvoie le certificat à l'examen, pas au blocage : vous avez demandé qu'on vous repose la question.

Équipements bloqués

Un dépliage replié, « Équipements bloqués » avec le compte, dessiné seulement tant qu'il en existe au moins un. Chaque ligne montre un point rouge, le nom déclaré, « Identité d'équipement déclarée · Bloqué par <user> le <date and time> », l'empreinte, et Débloquer, qui le ramène dans la liste d'examen sans l'approuver : « <name> est débloqué et est revenu dans la liste d'examen. » Un certificat bloqué ne revient jamais de lui-même.

Où vivent les décisions

Les magasins des équipements se trouvent sous ua\pki\southbound dans la racine de données de la station (pending, trusted, blocked et le rejected du SDK), avec l'adresse à laquelle chaque certificat a été vu, les comptes de tentatives et les décisions dans equipment-access.json. Ils sont séparés des magasins entrants, de sorte qu'un certificat d'équipement ne puisse jamais devenir une permission pour une application de se connecter au serveur propre à la station, ni apparaître comme une demande entrante. Ils ne font pas partie d'une sauvegarde de configuration.

Ce que cette section ne fait pas

Rien n'est approuvé automatiquement, et aucun réglage ne désactive cela. La carte ne configure pas l'équipement lui-même (l'adresse, les identifiants et la scrutation sont sur le Connector), ne montre pas les valeurs en direct de l'équipement, et ne décide pas au sujet des applications qui appellent cette station, ce qui est Accès des clients.