OPC UA

Un client OPC UA pour les serveurs tiers, avec une confiance conditionnée par certificat, un adressage par node id et une découverte de l'espace d'adressage.

Le pilote OPC UA est un client pour les serveurs OPC UA tiers : automates, passerelles, historiens, autres SCADA, sur opc.tcp. C'est la contrepartie sortante du serveur OPC UA intégré qui publie l'espace d'adressage de cette station (décrit sous Serveur OPC UA) ; les deux partagent l'identité applicative de la station mais accordent leur 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 le listent), 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é applicative OPC UA que le serveur intégré emploie. Beaucoup de serveurs exigent que ce certificat soit accordé de leur côté avant d'accepter la session : Préparer le serveur dit où.

Un matériel 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é de matériel : 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 matériel 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 du matériel 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 nommant l'approbation qu'il attend : 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 pressiez Approuver (de nouvelles sessions peuvent s'ouvrir) ou Bloquer (refusé sans relancer d'invites répétées). C'est la liste des matériels ; Accès des clients, sur le volet du Serveur OPC UA, est l'autre sens, qui peut se connecter en entrée au serveur propre à cette station.
• Retirer l'approbation, sur une ligne approuvée, ferme les sessions en cours qui s'appuient sur ce certificat et le renvoie dans la liste d'examen, si bien que la prochaine connexion vous redemande.
• Un matériel 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 un serveur d'équipement n'autorise jamais ce certificat à se connecter en entrée au serveur propre à cette station : les deux sens gardent des dépôts séparés à dessein.

Le comportement d'une session

Les tags sont scrutés : chaque lecture demande au serveur la valeur courante du nœud. Le verdict du serveur lui-même voyage avec chaque échantillon : une valeur estampillée Bad ou Uncertain est refusée et le tag se lit en mauvaise qualité, si bien qu'une source douteuse n'est jamais blanchie en lecture correcte. 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 valeur correcte 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 keep-alive ; après trois keep-alive 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 des tags

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 se lit en mauvaise qualité. Un tag comme celui-là échoue tout seul ; les autres tags de l'équipement continuent de se 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 proposé 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.

Un balayage de serveur propose 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 proposé, sont laissés de côté. Beaucoup de 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 proposé 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 se 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 proposé. 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 proposé 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 écartés en silence. Le balayage les compte et son message de clôture dit combien et de quel type, 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 importé il ne se lirait jamais. Un nœud dont la valeur revient Bad est toujours proposé, 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 apparaît 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 soit envoyée.

Découverte

La commande Découvrir prend une cible dans le champ à côté d'elle : une adresse de serveur OPC UA telle que opc.tcp://plc-host:4840. Le balayage a deux étapes, et la ligne de progression 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 personnalisés font l'aller-retour 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 en 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, ne différant 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 se connecte anonymement (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 de certificat de matériel). 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, réglez les identifiants et la sécurité de la session sur l'équipement, et configurez les tags à la main. Rien n'est conservé tant que vous n'avez pas pressé Ajouter sur un candidat, et l'annulation garde les candidats 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 se connectant comme 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 namespaces du serveur : un tag écrit avec l'index de son namespace (ns=2;s=Level) lit le nœud que le parcours nomme par l'URI de son namespace (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 à connaître

• Les lectures sont des scrutations de l'attribut Value ; le pilote ne crée pas d'abonnement sur le serveur distant.
• Des 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 matériel qui renouvelle son certificat revient dans 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 sur 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 se pose 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 balayage de découverte passe le même contrôle avant l'ouverture de sa session.

Une fois approuvé, le Connector commence la lecture à 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 à l'adresse <address> lisait avec un certificat que cette station avait approuvé et en présente désormais un autre (…), donc rien n'en est lu. Vérifiez l'empreinte auprès de la personne qui entretient l'équipement, puis approuvez-le. », avec Examiner, plus une notification Windows pour une fenêtre masquée. Un équipement en cours d'enregistrement n'est pas annoncé de cette façon : celui qui l'enregistre regarde déjà le Connector.

En attente d'approbation

Dessiné tant qu'au moins un certificat attend, sous le titre « Ces équipements ne sont pas lus tant que vous n'avez pas décidé. » avec le compte. Chaque ligne montre un point orangé, 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épliant Détail du certificat avec Sujet, Émetteur, URI de l'application, 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 contient au plus 100 certificats. Tant qu'elle est pleine, un certificat supplémentaire 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. Chaque refus de ce genre 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épliant de détail avec Adresse, Sujet, Émetteur, URI de l'application, Valide jusqu'au et Dernière apparition. Avec 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 généralement livré avec son certificat, et c'est pourquoi ce côté-ci présente l'import en premier. Importer un certificat bloqué lève le blocage. Retirer l'approbation renvoie le certificat à l'examen, pas à un blocage : vous avez demandé qu'on vous repose la question.

Équipements bloqués

Un dépliant 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 rend à 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, si bien qu'un certificat d'équipement ne peut jamais devenir la 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 paramètre 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 l'Accès des clients.