Construire un serveur OPC UA pleinement conforme — des Companion Specs au brownfield

Il existe de nombreux serveurs OPC UA sur le marché. La plupart exposent une simple liste de tags. On obtient une valeur, un horodatage et un code qualité. C'est utile — c'est certainement mieux que rien — mais cela passe à côté de l'intérêt fondamental d'OPC UA.

Un serveur OPC UA conforme ne se contente pas de servir des données. Il expose un modèle d'information : des objets typés, des variables structurées, des unités d'ingénierie, des conditions d'alarme, des méthodes avec des arguments définis, et des relations entre les actifs. Il implémente les Companion Specifications standardisées par l'industrie afin que n'importe quel client — quel que soit le fournisseur — puisse comprendre les données sans configuration spécifique.

Construire ce serveur est difficile. Le connecter à une vraie usine — à des automates qui communiquent en Modbus, S7, EtherNet/IP, ou via des protocoles propriétaires — l'est encore davantage.

Cet article explique comment faire les deux, et comment l'outillage moderne permet de tout configurer plutôt que de tout coder.

Les trois couches d'un vrai serveur OPC UA

Chaque serveur OPC UA en production comprend trois couches. La plupart des projets réussissent la première et échouent sur les deux autres.

Couche 1 : le modèle d'information

C'est la description sémantique de vos équipements. Pas une liste de tags — un modèle. Il définit :

• Types d'objets. Quels types d'actifs existent (pompes, convoyeurs, réacteurs, robots).
• Types de variables. Quelles données chaque actif expose (température, vitesse, état, nombre de cycles), avec les types de données et les unités d'ingénierie.
• Types de méthodes. Quelles opérations peuvent être effectuées (démarrer, arrêter, réinitialiser, acquitter une alarme).
• Types d'événements. Quelles notifications l'actif émet (alarme déclenchée, changement d'état, lot terminé).
• Références. Comment les actifs sont liés entre eux (Pump_3 fait partie de CoolingLoop_1, qui fait partie de ProductionLine_A).

Une Companion Specification fournit le modèle de base. PackML décrit comment modéliser la machine à états d'une machine d'emballage. Euromap 77 décrit comment modéliser une presse à injection. PADIM décrit comment modéliser un transmetteur de pression.

Votre travail consiste à instancier la Companion Spec pour vos équipements spécifiques — vos pompes, vos convoyeurs, l'agencement de vos lignes.

Couche 2 : la couche pilotes (connectivité brownfield)

Le modèle d'information décrit ce que les données signifient. La couche pilotes décrit d'où les données proviennent.

Dans un déploiement greenfield, vous pourriez disposer d'automates modernes qui parlent déjà OPC UA. Mais en réalité, la plupart des usines sont des environnements brownfield avec un mélange de :

• Siemens S7 (S7-300, S7-400, S7-1200, S7-1500) — utilisant le protocole S7 ou PROFINET.
• Modbus TCP/RTU — la lingua franca des instruments de procédé.
• EtherNet/IP (Allen-Bradley, Rockwell) — utilisant CIP sur Ethernet.
• BACnet — en gestion technique du bâtiment.
• MQTT — pour les capteurs IoT et les équipements en périphérie.
• CSV/REST/bases de données — pour les historiens, SCADA et les systèmes hérités.
• Protocoles propriétaires — chaque fournisseur a le sien.

La couche pilotes se connecte à ces sources hétérogènes et mappe leurs points de données bruts vers le modèle sémantique. Le registre 40001 d'un appareil Modbus devient CoolingPump.DischargeTemperature avec un type Double, une unité °C, et une plage d'ingénierie de 20.0 – 65.0.

Couche 3 : la couche de services OPC UA

C'est la pile OPC UA elle-même — les services que les clients utilisent pour interagir avec le serveur :

• Browse. Les clients découvrent le modèle d'information à l'exécution.
• Read/Write. Les clients lisent les valeurs de procédé et écrivent les consignes.
• Subscribe. Les clients reçoivent les mises à jour en temps réel via les éléments surveillés.
• Call. Les clients invoquent des méthodes sur le serveur.
• Events. Les clients reçoivent des notifications structurées d'alarmes et d'événements.
• HistoryRead. Les clients interrogent les données historiques.
• Sécurité. Certificats X.509, chiffrement, contrôle d'accès basé sur les rôles.

Un serveur conforme implémente correctement l'ensemble de ces services — pas seulement Read et Subscribe.

Pourquoi la plupart des serveurs OPC UA échouent

Listes de tags plates

L'échec le plus courant : le serveur expose un espace de noms plat de tags — Tag_001, Tag_002, Temperature_Pump3 — sans information de type, sans hiérarchie d'objets, sans unités, sans relations. C'est essentiellement un serveur OPC DA enveloppé dans un habillage OPC UA. Les clients peuvent lire des valeurs, mais ils ne peuvent pas comprendre les données.

Modèles codés en dur

De nombreux serveurs OPC UA codent le modèle d'information en dur en C++ ou C#. Ajouter une nouvelle variable implique de recompiler et de redéployer le serveur. Modifier la structure du modèle représente des mois de développement. Cela tue l'agilité — les usines doivent adapter leurs modèles à mesure que les équipements évoluent, que de nouvelles lignes sont ajoutées et que les Companion Specs évoluent.

Pas de connectivité brownfield

Certains serveurs disposent d'excellentes piles OPC UA mais n'offrent aucun moyen de se connecter aux équipements existants. Ils fonctionnent très bien avec d'autres serveurs OPC UA, mais ils sont incapables de lire un registre Modbus ou un bloc de données S7. Dans une usine brownfield, cela les rend inutilisables comme point d'agrégation en périphérie.

La sécurité comme réflexion tardive

Le serveur supporte la sécurité OPC UA en théorie, mais en pratique elle n'est jamais activée parce que la gestion des certificats est trop complexe. Consultez notre article sur le GDS pour comprendre pourquoi c'est important et comment y remédier.

L'approche configurable

La manière traditionnelle de construire un serveur OPC UA est d'écrire du code : définir des types en C++, instancier des objets, implémenter des callbacks de données, gérer les abonnements. C'est puissant mais coûteux. Chaque modification requiert un développeur.

L'approche moderne sépare les trois couches en configuration :

1. Définition du modèle (YAML / NodeSet)

Le modèle d'information est défini dans un fichier structuré — YAML, XML NodeSet, ou un concepteur visuel — pas dans le code applicatif. Le modèle référence les Companion Specifications en important leurs fichiers NodeSet. Vos types personnalisés étendent les types des Companion Specs.

Cela signifie :

• Un expert métier (pas un programmeur) peut définir le modèle.
• Le modèle est versionné dans Git.
• Les modifications sont revues, comparées et annulées comme du code.
• Le même modèle peut être déployé sur plusieurs serveurs.

2. Mapping des pilotes (configuration)

Le mapping entre le modèle d'information et les sources de données brownfield est défini dans un fichier de configuration. Pour chaque variable du modèle, vous spécifiez :

• Protocole source (Modbus, S7, MQTT, OPC UA, CSV, …)
• Détails de connexion (adresse IP, port, rack/slot pour S7, identifiant d'unité pour Modbus)
• Adresse (numéro de registre pour Modbus, DB/offset pour S7, topic pour MQTT)
• Type de donnée et transformation (mise à l'échelle, inversion d'octets, extraction de bits)
• Intervalle de scrutation ou déclenchement sur événement

Pas de code. Un changement de configuration. Quand l'usine ajoute un nouvel automate ou remplace un transmetteur, vous mettez à jour le mapping — pas le logiciel.

3. Déploiement du serveur (conteneurisé)

Le serveur s'exécute sous forme de conteneur (Docker, Kubernetes, ou un service natif) avec le modèle et la configuration des pilotes montés en tant que fichiers. La mise à jour du modèle consiste en un rechargement de configuration ou un redémarrage du conteneur — pas une recompilation.

Un exemple concret

Prenons une ligne de production pharmaceutique comprenant :

• 3 cuves de réaction (automates Siemens S7-1500, protocole S7)
• 12 instruments de procédé (Endress+Hauser, Modbus TCP)
• 1 machine d'emballage (Beckhoff, EtherNet/IP)
• 1 unité de nettoyage en place (CIP) (Modbus RTU hérité via passerelle série)

Étape 1 : Définir le modèle.

Importez la Companion Specification PADIM pour les instruments de procédé, le modèle ISA-88 BatchML pour les séquences de réaction, et PackML pour la machine d'emballage. Définissez votre type de réacteur spécifique en étendant le réacteur BatchML avec vos variables personnalisées (vitesse de l'agitateur, température de la double enveloppe, pH). Instanciez trois réacteurs, douze instruments, une machine d'emballage et une unité CIP.

Étape 2 : Configurer les pilotes.

Mappez la consigne de température du Reactor_1 vers le S7-1500 à l'IP 10.0.1.10, DB100, offset 0, type REAL. Mappez la valeur mesurée du FlowMeter_7 vers Modbus TCP à l'IP 10.0.2.7, registre 30001, type Float32, ordre d'octets BigEndian. Mappez l'état du Packager_1 vers EtherNet/IP à l'IP 10.0.3.1, chemin CIP 1/0/Assembly/100. Mappez le numéro d'étape du CIP_Skid vers Modbus RTU via la passerelle série à l'IP 10.0.4.1, identifiant d'unité 1, registre 40010.

Étape 3 : Déployer.

Démarrez le serveur OPC UA. Les clients qui s'y connectent voient un espace d'adressage entièrement navigable avec des objets typés, des unités d'ingénierie, des conditions d'alarme et des méthodes — le tout alimenté par des données en direct provenant de quatre protocoles différents. Le client ne sait pas et ne se soucie pas de savoir si les données proviennent de Modbus, S7 ou EtherNet/IP. Il voit OPC UA.

Ce que la conformité signifie réellement

Un serveur OPC UA « conforme » n'est pas seulement un serveur qui réussit un test de certification. En pratique, la conformité signifie :

Points clés à retenir

1. Une liste de tags plate n'est pas un serveur OPC UA. Un vrai serveur OPC UA expose un modèle d'information — des objets typés avec une structure, des unités et des relations.

2. Les Companion Specifications fournissent les modèles de base. Votre travail consiste à les instancier pour vos équipements spécifiques.

3. La connectivité brownfield est la partie difficile. Votre serveur doit mapper les variables sémantiques vers des registres Modbus, des blocs de données S7, des tags EtherNet/IP et des topics MQTT.

4. L'approche moderne est la configuration, pas le code. Modèle en YAML, mapping des pilotes en configuration, déploiement en conteneurs.

5. La conformité va au-delà des tags. Elle inclut la sécurité, les alarmes, l'historique, la navigation, les méthodes et les diagnostics.

Références

1. OPC Foundation — OPC UA Part 5: Information Model. opcfoundation.org
2. OPC Foundation — OPC UA Companion Specifications. opcfoundation.org/developer-tools/documents
3. ISA — ISA-88 / PackML. isa.org
4. FieldComm Group — PA-DIM. fieldcommgroup.org
5. Euromap — Euromap 77/83. euromap.org

C'est ce que nous construisons chez Sterfive. Omni-Edge est un serveur OPC UA entièrement configurable qui implémente les Companion Specifications, se connecte aux équipements brownfield via des pilotes intégrés (S7, Modbus, MQTT, EtherNet/IP, et plus), et se déploie sous forme de conteneur léger. OPC UA Modeler vous permet de définir le modèle d'information visuellement et de l'exporter sous forme de fichier NodeSet que Omni-Edge consomme directement. Aucun code requis. Parlons de votre déploiement.