Échange de données indépendant de la plateforme : OPC UA – un aperçu

Au-delà d’un certain niveau de complexité, la spécialisation reste le moyen le plus rapide d’accomplir une tâche. La création d’OPC (Open Platform Communications) en 1996 découle précisément de ce constat. Une équipe de développement issue des sociétés Rockwell, Opto 22, Fisher-Rosemount, Intellution et Intuitive Technologies a conçu un schéma de communication indépendant des fabricants sous le nom OLE for Process Control.

Leur objectif était de créer une interface permettant aux API de fournir des informations temps réel et historiques ainsi que de déclencher des alarmes. Avec le temps, la forte dépendance à Microsoft OLE (Object Linking and Embedding) s’est révélée être une limite compliquant inutilement l’utilisation du standard hors de Windows.

Pour résoudre ce problème, une nouvelle variante du protocole a été introduite selon le paradigme alors en vogue de l’architecture orientée services, avec séparation entre les données et les services qui les fournissent.

Qui bénéficie d’OPC UA et à quel coût ?

Avant d’aborder les détails techniques, il convient d’examiner le rôle d’OPC UA (Unified Architecture) dans les systèmes interconnectés. En principe, OPC UA est une couche d’abstraction permettant de relier des composants d’automatisation de fabricants différents. Pour les développeurs, le système présente un intérêt à deux niveaux. D’abord comme interface de programmation pour interagir avec des composants d’automatisation existants. Ensuite, OPC UA peut aussi intéresser les composants d’automatisation développés sur mesure — toute prise en charge de cette technologie favorise une large adoption sur le marché.

La question suivante concerne les coûts. Les systèmes OPC UA réels se composent presque toujours de deux éléments ; d’une part les spécifications fournies par l’OPC Foundation, et d’autre part le code proprement dit. En général, les spécifications sont disponibles sous diverses licences open source, ce qui signifie que leur utilisation n’engendre aucun coût. En revanche, toute personne souhaitant utiliser le code exemple de la Foundation implémentant la spécification doit devenir membre de la Foundation. Des informations supplémentaires sont disponibles sur. Pour les petites entreprises, l’adhésion annuelle peut coûter moins de 1 000 €.

Le second facteur de coût majeur est le code servant de base à l’implémentation. Compte tenu de l’ampleur du sujet, il est irréaliste pour une petite entreprise de développer seule une pile OPC UA ; le fournisseur de la pile attendra donc une rémunération pour son travail. Le prix dépend des capacités de négociation, de la plateforme cible et du volume commandé. Il existe également des versions d’essai et de démonstration des différentes piles, ainsi que des implémentations open source d’un serveur OPC-UA et d’autres composants (voir plus loin).

Système multi-technologies

En raison de l’expérience acquise avec OLE dans la première version d’OPC, OPC UA a été conçu pour rester aussi indépendant des technologies que possible. Ainsi, différents protocoles standard peuvent être utilisés selon la tâche à accomplir. Voici un bref aperçu des technologies les plus utilisées :

Le bloc fondamental de toute architecture OPC UA est l’objet OPC UA uniforme qui — représenté ici de façon schématique et non scientifique — apparaît comme illustré à la figure 1.

Un objet OPC UA peut exposer des propriétés et des données de processus via ses variables, incluant non seulement des informations actuelles mais aussi explicitement des données historiques. Grâce aux méthodes, les appelants peuvent déclencher des actions dans l’objet OPC UA, tandis que les événements se comportent globalement comme dans MQTT et technologies comparables.

Pour la communication et l’interaction avec les différents paramètres et attributs contenus dans l’objet OPC UA, la spécification définit deux approches fondamentales. D’une part, il existe un modèle client/serveur basé sur le principe SOA (service-oriented architecture) . Par exemple, un API stockant des données de mesure peut jouer le rôle de serveur. Des clients tels qu’une application tablette, un tableau de bord PC ou un outil d’analyse peuvent alors récupérer ces données. Une telle structure client/serveur est familière dans d’autres systèmes d’information distribués. Un aspect important est que la récupération des données de mesure depuis le serveur s’effectue par interrogation périodique.
 

Avec Pub(lish)/Sub(scribe), un autre schéma de communication est disponible, orienté programmation événementielle et fondamentalement comparable aux systèmes d’événements implémentés dans MQTT. Il convient aussi de souligner que les informations reçues dans des brokers MQTT peuvent être transmises à OPC UA.
 

Je recommande un article détaillé  consacré à la terminologie OPC UA, qui présente en profondeur les concepts d’OPC UA.
 

Un réseau de serveurs OPC UA agit également comme système unificateur, l’idée étant que, notamment dans les projets complexes d’automatisation industrielle, les informations sont réparties dans des systèmes très divers.

Dans les spécifications d’un « modèle d’espace de noms global », l’OPC Foundation souligne à plusieurs reprises que différents systèmes d’adressage – comparer bus de terrain et TCP/IP – sont normalisés via le framework OPC-UA. Il est également important que le modèle inclue non seulement les instances réelles mais aussi les types d’instances présents dans le système d’automatisation concerné.

Mise en service d’un serveur OPC UA

Malgré sa forte présence sur le marché, il existe peu d’implémentations de serveurs OPC UA facilement accessibles à titre d’exemple. Dans les étapes suivantes, nous nous appuierons sur un système à conteneurs dérivé de Microsoft Azure.
 

Malgré l’indépendance décrite plus haut, les technologies .NET jouent un rôle particulier dans l’univers OPC UA. On trouve par exemple le dépôt UA.NET de l’organisme de normalisation, disponible sur, qui propose des implémentations de référence du standard en technologies .NET.
 

Dans les étapes suivantes, nous utiliserons le serveur de démonstration disponible sur, car il fournit un ensemble de fonctions plus ou moins prêtes à l’emploi pour l’analyse. Il faut également noter que l’Eclipse Foundation propose un produit comparable nommé Milo ; le conteneur de démonstration Milo est disponible sur.

Dans les étapes suivantes, l’auteur utilisera une station de travail huit cœurs sous Ubuntu 24.04 comme système de test. La version de Docker installée apparaît comme suit :

tamhan@TAMHAN18:~$ docker --version

Docker version 28.4.0, build d8eb465

Idéalement, la mise en service s’effectue avec la commande suivante, qui fournit plusieurs réglages par défaut pour l’implémentation API exécutée dans le conteneur :

tamhan@TAMHAN18:~$ docker run --rm -it -p 50000:50000 -p 8080:8080 --name opcplc mcr.microsoft.com/iotedge/opc-plc:latest --pn=50000 --autoaccept --sph --sn=5 --sr=10 --st=uint --fn=5 --fr=1 --ft=uint --gn=5 --aa --ut

Lors du premier démarrage, docker télécharge les composants requis depuis le dépôt, après quoi le message PLC simulation started, press Ctrl+C to exit... apparaît dans le terminal une fois le lancement terminé. Laissez la fenêtre ouverte afin de maintenir l’API (automate programmable industriel) actif et supervisable. Pendant le fonctionnement, le conteneur y affichera continuellement des informations d’état.

Les paramètres --aa et --ut sont importants, car ils désactivent l’authentification client basée sur les certificats. OPC UA se distingue de la version précédente, également connue sous le nom OPC DA, notamment par des fonctions de sécurité plus strictes, peu pratiques pour nos essais en laboratoire (voir).

Tester la connexion avec un client générique

Les développeurs connaissent bien cette situation : quiconque souhaite, par exemple, mettre en service un système Bluetooth LE a tout intérêt à commencer par analyser le serveur avec un scanner Bluetooth LE. La structure formelle d’OPC UA implique l’existence de scanners plus ou moins génériques.

Nous utiliserons UA Expert, disponible sur. Il s’agit d’une « offre promotionnelle » de Unified Automation : l’entreprise propose des SDK permettant aux développeurs de créer des programmes interagissant avec OPC UA dans de nombreux langages. UA Expert n’est qu’un exemple parmi l’offre très large du marché OPC UA. Une liste régulièrement mise à jour d’autres composants est disponible sur.

Avant de télécharger le scanner, disponible sous Windows et Linux, une inscription auprès de Unified Automation est requise. Les utilisateurs Linux reçoivent une archive .tar.gz, qui doit être extraite puis préparée pour exécution et lancée comme suit :

tamhan@TAMHAN18:~/Downloads/UaExpert-2.0.1-x86_64-linux$ chmod +x UaExpert-2.0.1-x86_64.AppImage

tamhan@TAMHAN18:~/Downloads/UaExpert-2.0.1-x86_64-linux$ ./UaExpert-2.0.1-x86_64.AppImage

Lors du premier lancement, le système demande la création d’une identité cryptographique. La figure 2 montre les paramètres utilisés par l’auteur.

Ensuite, il faut cliquer avec le bouton droit sur le dossier Servers et créer une nouvelle configuration de serveur. Comme notre serveur d’exemple n’expose pas ses services sur le port standard 4840, nous passons au champ Advanced. Sous Server Information  arrow Endpoint Url, la chaîne opc.tcp://localhost:50000 doit être saisie.

Une fois la connexion établie – comme indiqué plus haut, les paramètres --aa et --ut autorisent une connexion non sécurisée – le panneau d’espace de noms présenté ci-dessous se remplit avec les différents objets, comme illustré à la figure 3.

UA Expert affiche tous les attributs fournis par les différents serveurs dans cette boîte de réception, dans cet exemple, nous n’utilisons qu’un seul serveur.

L’objet OPC PLC (représentant l’API) présente un intérêt particulier ; la figure 4 montre son arbre de méthodes. Cliquer sur les fonctions à droite ouvre une boîte de dialogue d’appel. La figure 5 montre comment UA Expert confirme un appel de méthode réussi.

Profils et facettes

L’un des aspects les plus innovants de Bluetooth LE était son système de profils ; il permettait une implémentation flexible tout en restant générique. L’idée est qu’un « Système X » implémente au moins certains attributs exposant les fonctions de base de manière générique. Les fonctions spécifiques au fabricant peuvent être réalisées via des attributs supplémentaires apparaissant comme « transparents » pour un interlocuteur inconnu.

OPC UA contient un système relativement similaire. La base repose sur les types de données OPC UA : des types de variables qui, comme dans les langages fortement typés, décrivent les formats de données entre systèmes et architectures. On y retrouve généralement des types familiers comme Integer, Boolean et autres ; le sujet est résumé sur.

À l’étape suivante apparaissent les facettes. Il s’agit d’interfaces spécifiant une fonction particulière. L’idée sous-jacente est qu’un système implémentant une facette donnée peut être traité par un consommateur attendant cette même facette. Les similitudes avec les profils Bluetooth LE ou les interfaces de la programmation orientée objet ne sont pas fortuites.

Un niveau au-dessus se trouvent les profils qui, dans OPC UA, regroupent un ensemble de facettes obligatoires et optionnelles. Une liste des profils généraux est disponible sur. Les standards spécifiques à certains secteurs incluent par exemple OPC for woodworking bois, décrit sur, centré sur les besoins de l’industrie du bois.

Lors du développement de systèmes certifiés OPC UA, on rencontre également le terme Conformance Unit. Un bon résumé du sujet est disponible sur.

open62541 : serveur OPC UA open source

Toute personne souhaitant utiliser OPC UA dans un projet commercial trouvera du support auprès de différentes sociétés proposant des SDK plus ou moins prêts à compiler.

Même si des versions d’essai existent pour presque toutes les piles, l’implémentation totalement open source open62541  mérite une attention particulière. Il s’agit d’une pile OPC UA classique basée sur le langage C. Sur, on trouve une variante plus ancienne illustrant le portage vers l’environnement de développement ESP-IDF d’Espressif.

Bien qu’une présentation complète de la programmation de cette pile dépasse le cadre de cet article, nous souhaitons malgré tout introduire les concepts essentiels. Techniquement et conceptuellement, open62541 évoque un mélange d’ESP-IDF et de Palm OS. Un serveur OPC-UA de base peut être lancé avec le code suivant :

#include <open62541/server.h>

int main(void) {

  UA_Server *server = UA_Server_new();

  UA_Server_runUntilInterrupt(server);

  UA_Server_delete(server);

  return 0;

}

L’objet UA_Server est particulièrement important ici. Il représente un serveur OPC UA dans son ensemble. Dans cet exemple de code, nous supposons que la plateforme hôte prend en charge le multithreading. L’appel runUntilInterrupt() crée un thread qui fournit ensuite le serveur OPC UA jusqu’à son arrêt via CTRL+C.

Si vous souhaitez ajouter une variable au serveur, la première étape consiste à créer une instance de la classe UA_VariableAttributes. Celle-ci reçoit ensuite les différents attributs devant être exposés à un client OPC UA :

static void

addVariable(UA_Server *server) {

  UA_VariableAttributes attr =

       UA_VariableAttributes_default;

  UA_Int32 myInteger = 42;

  UA_Variant_setScalar(&attr.value,

      &myInteger, &UA_TYPES[UA_TYPES_INT32]);

  attr.description =

      UA_LOCALIZEDTEXT("en-US","the answer");

  attr.displayName =

      UA_LOCALIZEDTEXT("en-US","the answer");

  attr.dataType =

      UA_TYPES[UA_TYPES_INT32].typeId;

  attr.accessLevel = UA_ACCESSLEVELMASK_READ |

                     UA_ACCESSLEVELMASK_WRITE;

À l’étape suivante, une structure conteneur est créée afin de définir la position de la variable dans l’espace de noms. Enfin, la méthode addVariableNode() est appelée avec une référence vers l’objet serveur afin d’achever l’intégration de la variable dans la mémoire du serveur :

  UA_NodeId myIntegerNodeId =

        UA_NODEID_STRING(1, "the.answer");

  UA_QualifiedName myIntegerName =

        UA_QUALIFIEDNAME(1, "the answer");

  UA_NodeId parentNodeId =

        UA_NS0ID(OBJECTSFOLDER);

  UA_NodeId parentReferenceNodeId =

        UA_NS0ID(ORGANIZES);

  UA_Server_addVariableNode(server,

          myIntegerNodeId, parentNodeId,

          parentReferenceNodeId, myIntegerName,

          UA_NS0ID(BASEDATAVARIABLETYPE),

          attr, NULL, NULL);

}

Bien entendu, les valeurs stockées dans les variables peuvent ensuite être mises à jour. Pour cela, consultez le tutoriel disponible sur, qui explique en détail les différentes approches.

Pour implémenter les méthodes présentées plus haut, cette pile s’appuie sur des pointeurs de fonctions. Là encore, la documentation associée fournit davantage d’informations sur les paradigmes de programmation.

Conclusion

OPC UA peut être considéré comme une source d’inspiration du modèle de gestion des données mis en œuvre dans Bluetooth LE. Imaginer ce protocole comme un « Bluetooth LE pour l’automatisation » simplifie sans doute un peu les choses, mais n’est pas totalement faux. Dans l’ensemble, l’interaction avec la technologie OPC UA est nettement plus simple que ne le laisserait penser l’ampleur des documents de normalisation.

L’auteur et l’équipe éditoriale espèrent que ces réflexions encourageront les lecteurs à explorer l’automatisation industrielle. Il s’agit d’un immense secteur en croissance dans lequel il est possible d’obtenir des rémunérations horaires élevées.

Questions ou commentaires ?

Envoyez un courriel à l'auteur tamhan@tamoggemon.com, ou contactez Elektor redaction@elektor.fr.

Note de la rédaction : Cet article (250864-01) est paru dans Elektor, juillet/août 2026.