OPC DA et OPC UA : différences et migration

Un site qui remplace un historien ou une IHM OPC DA par une solution OPC UA découvre que le nouveau client ne peut pas ouvrir l’ancien serveur. Un composant doit traduire entre les deux, et ce choix détermine si un hôte Windows et un serveur COM restent nécessaires sur site après la migration.

OPC DA (Data Access) utilise Microsoft COM sur un même ordinateur et DCOM entre ordinateurs. La connexion s’ouvre sur TCP 135, le mappeur de points de terminaison RPC, puis passe à un port attribué dynamiquement. Sous Windows Vista, Windows Server 2008 et versions ultérieures, la plage par défaut va de 49152 à 65535. Un abonnement DA renvoie aussi des données du serveur au client : le pare-feu doit donc autoriser DCOM dans les deux sens.

Le renforcement de DCOM par Microsoft pour CVE-2021-26414 (KB5004442) exige désormais le niveau d’authentification avec intégrité des paquets (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) lors de l’activation DCOM. Il est actif par défaut depuis le 14 juin 2022 et ne peut plus être désactivé depuis le 14 mars 2023. Un client Windows à jour élève automatiquement son niveau. Un client sur un hôte non corrigé, ou utilisant une pile DCOM non Windows, ne parvient pas à activer le serveur. Le serveur consigne l’événement 10036 et le client l’événement 10037 ou 10038. Les liaisons DA distantes non préparées à ce niveau ont cessé de fonctionner : c’est un motif fréquent de migration.

OPC UA utilise un protocole binaire sur un seul port TCP, 4840 par défaut, avec des certificats d’application X.509. Il fonctionne sur différents systèmes d’exploitation.

Ce que couvre OPC Classic

Chaque spécification Classic possède son propre espace d’adressage et ses propres services. OPC UA réunit les trois dans un seul espace d’adressage et un ensemble de services (OPC 10000-1, article 4.3).

Inventoriez les trois services utilisés par le système actuel. Un wrapper DA ne déplace que les valeurs actuelles. Il ne transfère ni l’acquittement des alarmes ni les requêtes historiques.

A&E exige une attention particulière. L’annexe D de la partie 9 associe les catégories d’événements A&E à des types d’événements UA lorsque le wrapper connaît leur sens. Par exemple, une condition de niveau nommée HI HI peut devenir un NonExclusiveLevelAlarmType. L’annexe ne définit aucune correspondance générique pour les sous-conditions A&E : configurez donc le wrapper pour chaque catégorie d’alarme utilisée par les opérateurs et vérifiez le résultat.

Trois chemins de migration

La fondation OPC publie des exemples COM UA Wrapper et COM UA Proxy (partie 8, A.1). Les produits commerciaux emploient parfois ces termes librement. Un « tunnel OPC », par exemple, transporte généralement DA entre deux ordinateurs sans DCOM et présente DA aux deux extrémités : il résout le problème DCOM, mais ne fournit pas de serveur UA. Indiquez le rôle client et le rôle serveur de chaque côté de chaque produit.

Un wrapper conserve les anciennes dépendances : hôte Windows, serveur DA et sa licence, comptes de service et ordre de démarrage. Installez-le sur le même hôte que le serveur DA. COM reste alors local et aucun trafic DCOM ne traverse le réseau. Désignez un responsable de l’hôte et un calendrier de correctifs.

Testez l’ordre de démarrage. Après un redémarrage Windows, le service du wrapper peut démarrer avant que le serveur DA soit prêt. Certains wrappers ne réessaient pas, et leurs points restent Bad jusqu’à ce qu’une personne redémarre le wrapper.

La version DA de l’ancien serveur détermine les possibilités du wrapper (partie 8, A.3.3 et A.3.4). Avec un serveur DA 2.05a, chaque UA Read accède à l’appareil et le wrapper ignore le paramètre maxAge. Une écriture UA comprenant un code d’état ou un horodatage échoue avec Bad_WriteNotSupported. Avec DA 3.0, une lecture peut venir de l’appareil ou du cache du serveur ; maxAge permet de choisir. Une écriture peut porter ensemble valeur, qualité et horodatage.

Associer les points DA aux nœuds UA

Construisez la correspondance point par point :

La partie 8, A.3.1.5 décrit trois façons de construire un NodeId. Un wrapper qui parcourt tout l’espace d’adressage DA et en conserve une copie hors ligne peut prendre l’ItemID comme identifiant. Un wrapper qui découpe chaque ItemID à un séparateur configuré peut faire de même, mais uniquement si les ItemID du serveur sont des chemins. Un troisième type de wrapper code dans le NodeId à la fois l’ItemID et le nom du point. Le NodeId ne correspond alors plus à l’ItemID, et une personne peut difficilement associer les deux.

Par exemple, le point DA BoilerA.Flow peut devenir ns=2;s=BoilerA.Flow. Le 2 est une position dans la NamespaceArray du serveur, pas un nom fixe. Cet index peut changer quand la configuration du wrapper change, mais l’URI d’espace de noms reste identique. Conservez l’URI et l’identifiant de chaque point, puis résolvez l’index à chaque connexion du client. Le guide d’identité des nœuds détaille ce fonctionnement. Incluez la configuration du wrapper dans le dossier de retour arrière : un wrapper reconstruit qui attribue de nouveaux identifiants rompt tous les consommateurs.

Vérifiez les types de données dans le tableau A.2 de la partie 8. La plupart correspondent directement, comme VT_R4 vers Float et VT_I4 vers Int32. VT_DATE devient Double, et non DateTime. Une date DA arrive donc comme un nombre de jours depuis le 30 décembre 1899 ; un consommateur qui attend un horodatage affiche alors un nombre tel que 46289.5.

Un point possédant les propriétés High EU et Low EU devient un AnalogItemType doté d’EURange et d’EngineeringUnits. Vérifiez la mise à l’échelle sur tout le chemin. Un débit de 21,7 m³/h ne doit pas devenir 2,17 parce que le nouveau collecteur répète une conversion déjà faite par le serveur DA.

Qualité et heure

Une valeur DA possède une qualité sur 16 bits. L’octet de poids faible a la forme QQSSSSLL : deux bits de qualité principale, quatre bits de sous-état et deux bits de limite. L’octet de poids fort est propre au fabricant. Les valeurs courantes de l’octet faible sont 0xC0 (Good), 0x40 (Uncertain) et 0x00 (Bad).

Une valeur UA possède un StatusCode sur 32 bits. Ses deux bits de poids fort indiquent la gravité : 0x00000000 signifie Good, 0x40000000 Uncertain et 0x80000000 Bad. La partie 8, A.3.2.3 associe la qualité principale DA à la gravité, le sous-état au sous-code et les bits de limite aux bits de limite. Elle écarte l’octet propre au fabricant.

Deux lignes méritent une vérification particulière. D’abord, l’octet du fabricant est perdu. Si un serveur DA marque une valeur saisie à la main par un bit dans cet octet, par exemple une qualité 0x80C0, la valeur issue du wrapper apparaît simplement comme Good. Ensuite, le tableau A.3 fait correspondre l’état DA « dernière valeur connue » à Bad_OutOfService. Un consommateur qui interprète OutOfService comme « arrêt volontaire » signale alors une panne de communication comme arrêt planifié. La partie 8, A.1 autorise des correspondances propres au fabricant : consultez aussi la documentation du wrapper. Si une application utilise l’octet du fabricant, convenez d’un autre moyen de le transmettre ou acceptez explicitement sa perte par écrit.

Pour l’heure, le wrapper utilise l’horodatage DA comme SourceTimestamp UA. Il fixe ServerTimestamp à l’heure de début de la lecture (partie 8, A.3.2.4). L’horodatage DA correspond généralement à la dernière réception de la valeur par le serveur DA depuis l’appareil. Ce n’est pas l’heure d’échantillonnage du capteur, sauf si le système source le définit ainsi.

Un wrapper peut fournir un état UA détaillé que le collecteur suivant supprime. Vérifiez donc l’enregistrement dans l’historien ou l’outil d’analyse, pas seulement dans le wrapper. Avant la migration, décidez de l’effet des valeurs périmées, manquantes et invalides sur les graphiques, totaux et alarmes.

Fréquences de mise à jour et bandes mortes

Un client DA définit une fréquence de mise à jour et une bande morte en pourcentage pour chaque groupe ; le serveur effectue un rappel lorsque la valeur change. Dans le wrapper de la fondation OPC, un UA MonitoredItem crée l’abonnement DA. L’UA SamplingInterval et la bande morte définissent le rappel DA (partie 8, A.3.5).

Le wrapper ne prend en charge que le filtre PercentDeadband. Une bande morte en pourcentage est calculée sur EURange : elle exige donc un point possédant High EU et Low EU sur le serveur DA. Un point qui n’en dispose pas n’a pas d’EURange, et le filtre ne peut pas s’appliquer.

Un client qui interroge par le service UA Read n’utilise aucune de ces fonctions. Il reçoit une valeur pour chaque point à chaque interrogation. Avec un serveur DA 2.05a derrière le wrapper, chaque interrogation lit aussi l’appareil : dimensionnez donc l’intervalle pour la charge du serveur DA et de son réseau de terrain.

Sécurité des deux côtés

Du côté UA, configurez le point de terminaison en SignAndEncrypt avec une politique actuelle, telle que Basic256Sha256, Aes128_Sha256_RsaOaep ou Aes256_Sha256_RsaPss. N’acceptez pas le mode None, même si le wrapper le propose. Configurez la confiance des certificats d’application dans les deux sens et n’accordez au compte utilisateur du client que les opérations nécessaires. La partie 2 de la norme décrit le modèle.

Les certificats ont une période de validité : les horloges comptent. Un certificat expiré ou non encore valide à cause d’une horloge erronée provoque Bad_CertificateTimeInvalid. Le client cesse alors de lire jusqu’au renouvellement du certificat ou à la correction de l’horloge. Inscrivez la date d’expiration de chaque certificat d’application dans le plan de maintenance.

Du côté DA, COM DA ne possède pas d’identité utilisateur propre (partie 8, A.2). Un wrapper peut accepter un nom d’utilisateur et un mot de passe UA, puis emprunter cette identité Windows avant de se connecter au serveur DA. Beaucoup de wrappers se connectent plutôt sous leur compte de service. Notez quel compte Windows voit le serveur DA et quels droits d’écriture il possède. Si une liaison DA reste distante, elle doit respecter la règle DCOM sur l’intégrité des paquets ci-dessus.

Ne résolvez pas une difficulté de mise en service en désactivant la sécurité ou en donnant des droits d’écriture à un compte de lecture.

Tester la migration

Testez un point de chaque type de données avant de migrer les autres. Incluez une valeur analogique mise à l’échelle, un booléen, une chaîne et, si le projet en comporte, un tableau et une date. Pour chaque point d’essai :

1. Notez l’URI d’espace de noms et le NodeId créés par le wrapper.
2. Lisez la valeur par le chemin DA et le chemin UA dans une même période de scrutation DA, puis comparez-les. Recherchez une double mise à l’échelle.
3. Avec autorisation, arrêtez l’appareil ou son pilote. Enregistrez la qualité DA, le StatusCode UA et ce que montre le consommateur final. La dernière valeur ne doit pas apparaître comme une nouvelle mesure Good.
4. Redémarrez l’hôte du wrapper. Confirmez que les points reviennent à Good sans modification de la liste de points et mesurez le délai.
5. Lisez un ItemID inexistant et écrivez sur un point sans droit d’écriture. Attendez Bad_NodeIdUnknown et Bad_NotWritable.

Faites ensuite fonctionner les deux chemins en parallèle pendant au moins un cycle d’exploitation complet, par exemple un poste, un lot ou une semaine. Incluez un redémarrage planifié de la source. Le chemin DA signale les changements selon une bande morte et le client UA peut interroger périodiquement : les deux chemins produisent donc des nombres de messages différents. Comparez les valeurs et l’âge de la dernière valeur à chaque instant. Convenez avant l’essai de l’écart admis et du délai de reprise.

Séparez les commandes. Ne laissez pas les anciens et les nouveaux chemins commander simultanément le même équipement et vérifiez le résultat physique de chaque écriture. Le guide des priorités BACnet montre comment une commande partagée peut survivre à son propriétaire.

OPC UA avec Edge

Edge sur le Gateway ZGW-20 est un client OPC UA. Il se connecte à cinq points de terminaison opc.tcp au maximum, natifs ou issus d’un wrapper, et ne se connecte pas à OPC DA. Un système uniquement DA exige d’abord un wrapper.

Edge lit chaque point par le service Read selon un calendrier allant d’une fois par seconde à une fois par jour. Il ne crée pas d’abonnements : les règles de bande morte ci-dessus ne s’appliquent donc pas. Il horodate chaque valeur à l’heure de lecture prévue par le Gateway, et non au SourceTimestamp. Il applique aussi son propre multiplicateur et décalage à chaque point : réglez-les à 1 et 0 si le serveur DA met déjà la valeur à l’échelle.

Edge accepte None, Sign et SignAndEncrypt ; un nouvel emplacement de point de terminaison démarre en mode None. Configurez vous-même SignAndEncrypt avec Basic256Sha256 ou une politique Aes, puis veillez à l’exactitude de l’horloge du Gateway pour les contrôles de certificat.