Analyse approfondie du protocole OPC UA : Du contexte, de l'évolution et des principes à la configuration pratique
Dernière mise à jour : 12 oct.
Introduction : Pourquoi OPC UA est devenu le "langage standard" de l'ère de l'interconnexion industrielle
Avec l’Industrie 4.0 et l’Internet industriel des objets (IIoT), les systèmes d’automatisation qui échangeaient auparavant des données par des interfaces propres à chaque fournisseur sont désormais connectés. L’intégration ne consiste pas seulement à transférer des octets : les applications doivent s’accorder sur le sens des données, leur comportement de mise à jour et leur sécurité. OPC UA (Open Platform Communications Unified Architecture) répond à ce besoin par une architecture indépendante de la plateforme, dotée d’un modèle d’information, de services et de mécanismes de communication définis. Modbus, PROFIBUS et les autres protocoles déjà installés restent adaptés à leurs usages ; une passerelle peut être nécessaire pour mapper les données des équipements vers un modèle OPC UA.
OPC UA associe des modèles d’information interopérables, des mécanismes de sécurité des applications et des implémentations allant des appareils embarqués aux systèmes d’entreprise. Les spécifications complémentaires peuvent fournir un vocabulaire commun aux équipements de différents fournisseurs. Les certificats, les politiques de sécurité, l’autorisation des utilisateurs et la gestion opérationnelle de la confiance doivent néanmoins être configurés correctement. Une ligne de production peut exposer les mesures des API aux applications de supervision et de maintenance au moyen d’un modèle documenté ; le bénéfice réel dépend des équipements, des mappages et du déploiement. L’architecture ne permet pas de déduire la compatibilité, le nombre d’équipements installés, les prévisions de marché ni les performances d’une usine nommée.
En bref, OPC UA n'est pas seulement un protocole technique, c'est la "grammaire universelle" de la numérisation industrielle, permettant aux machines de "dialoguer" de manière aussi efficace et sûre que les humains, favorisant la transition de "l'automatisation" vers "l'intelligence".
Un routeur industriel peut acheminer le trafic entre un réseau d'automates et une application de supervision sans comprendre les valeurs d'un message OPC UA. Une passerelle ou un automate peut héberger le serveur OPC UA, tandis qu'un client ailleurs lit les données ou s'y abonne. Il faut attribuer ces rôles avant d'affirmer que le routeur « prend en charge OPC UA ».
Transport de paquets, hébergement d'un point de terminaison et traduction d'un autre protocole en OPC UA sont des fonctions distinctes.
Contexte et historique d'évolution d'OPC UA
Naissance d'OPC Classic
OPC Classic est apparu pour réduire le besoin de pilotes et d’interfaces Windows distincts pour chaque fournisseur d’automatisation. Il s’appuyait sur Microsoft COM/DCOM afin de normaliser les communications entre applications industrielles. Les principales spécifications Classic portaient sur les données en temps réel, les données historiques et les alarmes/événements :
DA (Data Access) : Lecture/écriture en temps réel de variables, support d'un mécanisme d'abonnement.
HDA (Historical Data Access) : Requêtes et agrégation de données historiques.
AE (Alarms & Events) : Notification d'événements et d'alarmes.
OPC Classic s’est imposé dans les installations SCADA et DCS. Sa dépendance à COM/DCOM compliquait les déploiements entre différents systèmes d’exploitation et au-delà des frontières réseau. DCOM possède ses propres mécanismes d’authentification et de contrôle d’accès ; il est donc inexact de dire qu’OPC Classic n’offre ni autorisation ni chiffrement. OPC UA a été conçu pour supprimer cette dépendance à Windows et fournir un espace d’adressage commun, des services et un modèle de sécurité des communications adaptés à une plus grande variété de systèmes.
Tableau comparatif : OPC Classic vs. Besoins modernes
Aspect | Contexte d’OPC Classic | Limite d’OPC Classic | Différence apportée par OPC UA |
|---|---|---|---|
Dépendance à la plateforme | Les interfaces COM/DCOM ont été conçues pour les environnements Windows. | Un déploiement multiplateforme peut exiger un travail d’intégration supplémentaire. | La spécification prévoit des implémentations indépendantes de la plateforme ; les profils pris en charge varient selon le produit. |
Accès aux données | DA, HDA et AE couvrent respectivement l’accès aux variables, l’historique et les alarmes/événements. | Les spécifications Classic n’utilisent pas le modèle d’information AddressSpace d’OPC UA. | Les services et modèles d’information UA prennent en charge les données structurées et leurs relations ; les modèles complémentaires dépendent du domaine applicatif. |
Sécurité | La sécurité repose sur la configuration COM/DCOM, du système d’exploitation et du site concernés. | Le comportement de sécurité dépend du déploiement et de sa configuration. | UA définit des mécanismes de sécurité des applications et des communications ; les points de terminaison et les utilisateurs doivent être configurés et vérifiés. |
Extensibilité | Les interfaces Classic répondent aux cas d’usage définis pour l’accès aux données. | La connexion à d’autres applications peut nécessiter des passerelles ou des mappages. | UA prend en charge des modèles d’information extensibles et, lorsque l’implémentation le permet, les modèles Client/Server ou PubSub. |
D’OPC Classic à une architecture multiplateforme
OPC Classic utilisait Microsoft COM/DCOM pour accéder aux données sous Windows. OPC UA, normalisé dans la série IEC 62541, définit un espace d’adressage, des services et des correspondances de communication sans dépendre de ce mécanisme Windows. Migrer exige donc plus que l’ouverture d’un port : identifiez l’automate, la passerelle ou le serveur qui publie les données, le client qui les utilise et la correspondance des anciens tags avec leur sens dans le nouvel espace. Le routeur transporte la connexion sans créer cette correspondance par simple routage.
Proposition et vision d'OPC UA
L’OPC Foundation a développé OPC UA comme successeur des spécifications Classic. L’objectif était de créer une architecture unifiée capable de représenter les informations industrielles et d’exposer des services sans dépendre de COM/DCOM sous Windows. Cette vision consistait à étendre les communications normalisées aux appareils, aux systèmes d’exploitation et aux applications d’entreprise :
Indépendance de la plateforme : définir l’espace d’adressage et les services sans dépendre d’un système d’exploitation, d’un langage d’implémentation ou d’un environnement d’exécution COM/DCOM particulier.
Échange sémantique : décrire les valeurs à l’aide de types, d’attributs et de relations afin que les consommateurs puissent en interpréter le sens.
Services unifiés : prendre en charge la découverte, les données actuelles et historiques, les méthodes, les événements et les abonnements lorsque le serveur implémente les capacités correspondantes.
Cette approche facilite l’intégration entre les systèmes de contrôle et des applications telles que les MES, la maintenance et les systèmes d’information d’entreprise. L’adoption d’UA exige néanmoins un modèle d’information défini, des capacités applicatives compatibles et des mappages éprouvés à partir des tags existants. Le choix d’un protocole ne garantit pas à lui seul une réduction donnée du temps d’intégration.
Standardisation internationale et développement de l'écosystème
OPC UA est normalisé dans la série IEC 62541. Les spécifications couvrent l’architecture, la sécurité, l’espace d’adressage, les services, le modèle d’information, les mappages et des fonctionnalités supplémentaires. L’écosystème de l’OPC Foundation réunit des fournisseurs d’automatisation, des développeurs de logiciels, des utilisateurs et des organisations qui définissent des modèles sectoriels. Pour un projet, consultez les versions actuellement publiées des spécifications au lieu de supposer qu’un nombre historique de parties ou d’adhérents décrit l’ensemble de l’écosystème.
Spécifications complémentaires : des groupes sectoriels définissent des modèles communs pour les équipements et les applications, notamment pour les machines et l’identification automatique. Vérifiez le modèle exact et sa version, pris en charge par les deux applications.
Déploiement : les usines, les services publics et d’autres secteurs utilisent OPC UA pour l’intégration des données ; la norme ne permet pas de déduire un chiffre national sur le parc installé.
Implémentations open source : des projets comme open62541 mettent des implémentations UA à la disposition des développeurs. La prise en charge des plateformes, les fonctionnalités et la conformité dépendent de la version et de la compilation choisies.
L’interopérabilité suppose un accord sur les profils, les services, les modèles d’information et les paramètres de sécurité. Les tests de conformité et la certification de l’OPC Foundation peuvent apporter des éléments probants pour le périmètre défini d’un produit, mais ne remplacent pas les essais réunissant le client, le serveur et les exigences réelles de l’application.
Tableau : Jalons clés
Jalon | Ce que les sources de spécification fournies établissent | Importance pour l’ingénierie |
|---|---|---|
OPC Classic | Les spécifications fondées sur Windows COM/DCOM comprennent DA, HDA et AE. | Les systèmes anciens peuvent nécessiter une passerelle explicitement configurée ou un mappage de données. |
OPC UA | Une architecture unifiée définit des services, des modèles d’information, des encodages et des mappages. | La prise en charge multiplateforme ne dispense pas de vérifier les profils et les modèles des appareils. |
IEC 62541 | OPC UA est publié sous la forme d’une série de spécifications IEC en plusieurs parties. | Utilisez la partie et la version pertinentes pour la fonctionnalité à implémenter. |
Version 1.04 | L’historique officiel de la partie 1 indique que la version 1.04 a été publiée le 22/11/2017. | Vérifiez la prise en charge de la fonctionnalité selon la version de spécification et le profil du produit concernés. |
Version 1.05.06 | L’historique de la partie 1 fourni indique que la version 1.05.06 a été publiée le 22/10/2025. | Il s’agit de la version consignée dans l’instantané des sources fourni, et non d’une garantie que tous les produits l’implémentent. |
PubSub, TSN et modèles liés à l’IA | La spécification PubSub fournie définit des modèles PubSub et des mappages ; les sources n’établissent ni prise en charge universelle des produits, ni performances, ni date de publication pour chaque thème d’intégration. | Évaluez ces éléments comme des fonctionnalités ou des sujets au regard de la spécification et de l’implémentation choisies. |
Architecture globale d'OPC UA
Architecture multiplateforme tournée vers l'avenir
OPC UA adopte une architecture orientée services (SOA), dont le cœur est une couche d'abstraction garantissant l'indépendance vis-à-vis de l'OS/du matériel. Composants clés :
Application et modèle d’information : implémenter la logique métier, les nœuds, les valeurs et le comportement des services exposés aux autres applications.
Implémentation ou SDK : fournir des API et l’intégration à la plateforme ; .NET, Java, C/C++ et d’autres langages sont des options d’implémentation, et non des couches obligatoires du protocole.
Mappages de communication : choisir les encodages, profils de sécurité et transports réellement pris en charge par les applications qui communiquent.
Les implémentations UA peuvent fonctionner sur des contrôleurs embarqués, des ordinateurs de périphérie et des systèmes d’entreprise ou cloud si les ressources et profils requis sont disponibles. La prise en charge multiplateforme ne crée pas à elle seule un déploiement zero trust. Par rapport à une API HTTP générique, UA définit un espace d’adressage industriel, des services et des conventions de modèle d’information ; l’implémentation doit toujours gérer les identités, les états et les autorisations d’accès.
OPC UA définit un modèle d'information et des services pour découvrir, lire, écrire et s'abonner aux données. La présentation de l'OPC Foundation distingue l'architecture d'un équipement réseau particulier. Dans une architecture client/serveur courante, le serveur expose un point de terminaison et le client ouvre une session. D'autres modes de communication existent : vérifiez le profil réel de l'application plutôt que de supposer le même trajet partout.
Tracez le chemin du client au serveur : adresse et port, terminaison DNS ou VPN, interfaces du routeur, pare-feu, NAT et éventuelle passerelle. Si un appareil Modbus se trouve derrière une passerelle, celle-ci doit transposer les registres et leur signification dans son modèle OPC UA ; le simple routage IP ne le fait pas. Le guide Modbus distingue données de registre et transport.
Composant | Rôle à vérifier | Preuve |
|---|---|---|
Automate ou passerelle | Point serveur, espace de noms, NodeIds et actualisation | Le client parcourt et lit les valeurs attendues |
Routeur industriel | Chemin IP, segmentation, NAT/VPN et sens autorisé | Le client autorisé n'atteint que le point prévu |
Client OPC UA | Paramètres de confiance, session et abonnements | Lectures, écritures ou alarmes satisfont l'application |
Équipe d'exploitation | Certificats, journaux, sauvegardes et responsable de reprise | Confiance et service reviennent après une panne planifiée |
Le routage IP peut transporter le trafic OPC UA ; il ne crée pas automatiquement de serveur OPC UA et ne convertit pas un autre protocole.
Structure de la pile de communication
OPC UA peut se comprendre à travers les applications et les modèles d’information, les services, les encodages de données, les mécanismes de sécurité et les mappages de transport. Il ne s’agit pas d’une pile OSI obligatoire à sept couches. Distinguez le modèle applicatif UA des connexions réseau et physiques sous-jacentes :
Application et services : modéliser les informations industrielles et exécuter des opérations telles que Browse, Read, Write, Call et la gestion des abonnements.
Représentation des données : utiliser les encodages définis pour le mappage et le profil choisis ; UA Binary, XML et JSON répondent à des usages spécifiés différents.
Mappage de communication : choisir un transport Client/Server ou PubSub pris en charge, ainsi que ses règles de message et de sécurité.
Réseau sous-jacent : TCP/IP, UDP/IP, Ethernet et les supports physiques ou sans fil assurent la connectivité selon le mappage choisi. Ils ne constituent pas des couches de service UA supplémentaires.
Sécurité : prendre en compte l’identité de l’application, la protection du canal sécurisé ou des messages et l’autorisation des utilisateurs selon le modèle de communication choisi.
La latence et le comportement temps réel dépendent des applications, de l’encodage, du transport, de l’ingénierie réseau, de la charge des appareils et de la configuration. TSN ou un profil de transport particulier peut faire partie d’un système conçu à cet effet, mais le choix d’OPC UA ne garantit pas une latence de bout en bout fixe.
Tableau : Détail des couches de la pile de communication
Élément | Concept OPC UA | Exemple | Vérification |
|---|---|---|---|
Application | Services Client/Server ou échange d’informations PubSub. | Services Browse et Read ; messages DataSet d’un éditeur. | Confirmer que le serveur ou le profil PubSub implémente le comportement requis. |
Modèle d’information | Les nœuds, attributs et références décrivent les données et leurs relations. | Une Variable représente une valeur avec un DataType et d’autres attributs. | Utiliser le modèle de l’appareil et l’URI de l’espace de noms ; ne pas déduire le sens du seul nom. |
Encodage | Le mappage choisi définit l’encodage des messages. | UA Binary ou JSON dans les mappages applicables. | Vérifier le mappage et le point de terminaison ; ne pas supposer que tous les encodages sont pris en charge. |
Transport | Les mappages transportent les messages OPC UA via les transports pris en charge. | OPC UA TCP pour Client/Server ; mappages UDP, Ethernet ou broker spécifiés pour PubSub. | Vérifier le profil de point de terminaison ou PubSub annoncé et la prise en charge du produit. |
Sécurité | MessageSecurityMode, SecurityPolicy, identité utilisateur, certificats et contrôles réseau remplissent des fonctions différentes. | Protection des messages du SecureChannel ou mappage TLS pris en charge. | Configurer chaque couche selon les besoins ; aucune ne prouve à elle seule la protection de bout en bout. |
Modèle d'information et organisation des données
Le modèle d’information utilise des nœuds, des types, des attributs et des références pour décrire les informations industrielles. Les fichiers XML NodeSet permettent d’échanger des définitions de modèles ; XML n’est pas l’unique représentation des données à l’exécution. Les concepts fondamentaux de modélisation sont les suivants :
Object : représente une entité ou regroupe des informations, par exemple un appareil.
Variable : expose une Value typée avec des attributs associés tels que DataType et ValueRank.
Method : expose une opération appelable avec des arguments d’entrée et de sortie définis.
Reference : relie des nœuds au moyen d’un ReferenceType ; les relations peuvent être hiérarchiques ou non hiérarchiques.
L’AddressSpace est un graphe de nœuds et de références typées. Un client parcourt souvent une vue hiérarchique de ce graphe, mais un nœud peut participer à plusieurs relations. BrowseName, DisplayName, Description, les types et les références aident un consommateur à localiser et interpréter les informations ; une étiquette d’affichage ne constitue pas à elle seule un NodeId stable.
Caractéristiques techniques fondamentales d'OPC UA
Système de sécurité (authentification, chiffrement, autorisation)
OPC UA définit son propre modèle de sécurité applicative et ses mappages de communication. Dans un déploiement Client/Server, évaluez séparément l’authentification des applications, la protection des messages et l’autorisation des utilisateurs :
Authentification des applications : valider le certificat de l’application homologue, son identité, sa chaîne de confiance, sa période de validité et les contrôles de certificat pertinents pour le point de terminaison choisi.
Protection des messages : choisir une SecurityPolicy et un MessageSecurityMode compatibles. Les algorithmes et tailles de clé sont définis par cette politique, et non par une combinaison universelle AES/SHA.
Authentification et autorisation des utilisateurs : choisir un jeton utilisateur pris en charge et accorder au compte uniquement les autorisations requises sur les nœuds et services. La confiance accordée au certificat de l’application est une décision distincte.
Exploitation : gérer les listes de confiance, le renouvellement des certificats et les informations de révocation, ainsi que les journaux et l’audit selon les capacités des produits.
MessageSecurityMode sélectionne None, Sign ou SignAndEncrypt. SecurityPolicy spécifie les algorithmes de sécurité et les règles associées ; Basic256Sha256 est le nom d’une politique, et non un quatrième mode de message. Choisissez une politique et un mode pris en charge par les deux parties et adaptés au déploiement. Les options de sécurité OPC UA n’établissent pas automatiquement la conformité à IEC 62443. La sécurité de MQTT dépend également de son déploiement, de la protection du transport et de l’autorisation applicative : le nom d’un protocole ne suffit pas à évaluer son niveau de sécurité.
Tableau : Comparaison des modes de sécurité
Paramètre | Fonction | Protection/comportement | Vérification |
|---|---|---|---|
MessageSecurityMode: None | N’applique ni signature ni chiffrement aux messages du SecureChannel. | N’assure ni confidentialité ni intégrité au niveau des messages. | À utiliser uniquement si le déploiement et la politique du point de terminaison l’autorisent. |
MessageSecurityMode: Sign | Signe les messages. | Assure l’intégrité et l’authentification des messages ; leur contenu n’est pas chiffré. | Vérifier les certificats, la SecurityPolicy et la prise en charge du point de terminaison. |
MessageSecurityMode: SignAndEncrypt | Signe et chiffre les messages. | Assure l’intégrité et la confidentialité des messages sur le SecureChannel, selon les capacités prises en charge. | Vérifier les deux points de terminaison, la confiance des certificats et la politique choisie. |
SecurityPolicy, par exemple Basic256Sha256 | Sélectionne les algorithmes de sécurité et les exigences associées ; ce n’est pas un MessageSecurityMode. | Les combinaisons autorisées et les recommandations actuelles dépendent de la version de la spécification et du profil. | Choisir selon la prise en charge des points de terminaison et les recommandations de sécurité actuelles ; ne pas combiner des paramètres en se fondant uniquement sur leur nom. |
Une connexion TCP établie n'est pas encore une session OPC UA de confiance.
Vérifiez point serveur, politiques de sécurité, certificats applicatifs, listes de confiance et authentification des utilisateurs dans la documentation actuelle des produits. Le modèle de sécurité OPC UA décrit ces concepts ; il ne certifie pas un routeur ou une passerelle. Prévoyez le renouvellement et la révocation des certificats avant de laisser un site distant sans surveillance.
SecurityPolicy, MessageSecurityMode, la confiance dans les certificats d’application et les droits des utilisateurs sont des paramètres distincts. Vérifiez ces quatre éléments.
Mécanisme des Services
OPC UA regroupe les opérations associées dans des Service Sets. Les clients utilisent les services pris en charge pour la découverte, les sessions, l’accès aux données, les méthodes et les abonnements ; les capacités exactes dépendent du profil et de la configuration du serveur :
Découverte : rechercher des serveurs et interroger la description de leurs points de terminaison et les options de sécurité prises en charge.
SecureChannel et Session : établir, lorsqu’elle est configurée, une communication applicative protégée, créer une session et l’activer avec une identité utilisateur autorisée.
Read et Write : accéder aux attributs des nœuds, comme la Value d’une Variable, si le serveur l’autorise ; l’accès historique utilise HistoryRead et HistoryUpdate plutôt que Read/Write ordinaires.
Subscriptions et MonitoredItems : surveiller les changements de données ou les événements avec des comportements d’échantillonnage, de mise en file et de publication ; un abonnement ne se limite pas aux événements.
Call : appeler une Method exposée avec les arguments et les autorisations requis.
Les services utilisent un modèle requête-réponse, les codes d'erreur sont standardisés (BadNodeIdUnknown, etc.).
Modélisation de l'information
La modélisation POO supporte l'héritage/la composition :
Définitions de types : les nœuds ObjectType et VariableType définissent des types pour les Objects et les Variables ; les nœuds DataType définissent les types de valeurs. Ces NodeClasses ne sont pas elles-mêmes les noms de types de base particuliers.
Instances : les Objects et les Variables instancient les types de modèle correspondants ; les Methods représentent des opérations avec des arguments et des autorisations définis.
Extensions : enregistrer des espaces de noms applicatifs et utiliser les spécifications complémentaires pertinentes, par exemple les modèles d’identification automatique, dans des versions prises en charge par les deux applications.
Les modèles d’information rendent explicites la structure et le sens des données. Les consommateurs peuvent les interpréter à l’aide des modèles complémentaires et des métadonnées pris en charge. Cela peut aider les applications d’analyse ou d’IA, mais la présence de données UA ne garantit pas à elle seule qu’un consommateur comprend un modèle qui lui est inconnu.
Tableau : Types d'éléments de modélisation
Type d’élément | Description | Attributs/propriétés associés | Exemple d’accès/de relation |
|---|---|---|---|
Object | Représente une entité ou un regroupement. | BrowseName, DisplayName, EventNotifier | Parcourir et lire ses attributs ; il peut avoir des références de type component ou organization. |
Variable | Représente une valeur. | Value, DataType, ValueRank, AccessLevel | Lire ; écrire uniquement si la variable est modifiable et que l’utilisateur est autorisé ; surveiller au moyen d’un MonitoredItem si cette fonction est prise en charge. |
Method | Représente une opération appelable. | Executable, UserExecutable ; InputArguments et OutputArguments sont des Properties | Appeler la Method si elle existe et si l’accès est autorisé. |
ReferenceType | Définit la manière dont les Nodes sont liés. | IsAbstract, Symmetric, InverseName | Exemples : Organizes, HasComponent et HasSubtype. |
DataType | Définit le type de valeur d’une Variable. | IsAbstract, DataTypeDefinition lorsqu’il est défini | Lire ou parcourir le nœud concerné ; GetEndpoints n’est pas le service approprié. |
View | Définit un sous-ensemble ou une projection de l’AddressSpace. | Attributs propres à la View | Parcourir la View si le serveur la prend en charge. |
Modes de transmission de données (Client/Serveur, Pub/Sub)
Client/Server : un client utilise les services d’un serveur pour parcourir des données, les lire, les écrire, appeler des méthodes ou établir des abonnements. Ce modèle convient à la configuration comme à la surveillance continue lorsque les fonctions correspondantes sont implémentées.
PubSub : les éditeurs produisent des messages DataSet pour les abonnés via un transport et un mappage de messages pris en charge. Les métadonnées des lecteurs/éditeurs, les identifiants, le comportement de livraison et la sécurité nécessitent leur propre configuration. PubSub est spécifié dans la partie 14 ; cela ne constitue pas une affirmation de compatibilité RTPS/DDS.
PubSub peut distribuer des DataSets sélectionnés à plusieurs consommateurs sans que chacun conserve le même chemin d’abonnement Client/Server. Les abonnements Client/Server évitent également les interrogations répétées de chaque valeur au niveau applicatif. Pour le déploiement concerné, comparez la diffusion, les besoins de mise à jour, les métadonnées, la reprise et la sécurité au lieu de supposer que PubSub utilise toujours moins de bande passante.
Tableau : Comparaison des modes de transmission
Mode | Modèle de communication | Fonctionnalités possibles | Choix/vérification |
|---|---|---|---|
Client/Server | Un client appelle les services d’un serveur. | Découverte, navigation, accès à la demande, méthodes, abonnements et autres services pris en charge. | Vérifier le profil du point de terminaison, les limites du serveur, les autorisations utilisateur et la charge mesurée. |
PubSub | Les éditeurs envoient des messages DataSet configurés aux abonnés correspondants. | Distribution un-à-plusieurs sur un transport et un mappage PubSub pris en charge. | Vérifier les métadonnées, la cadence de mise à jour, le transport, la correspondance des lecteurs, la sécurité et le comportement du réseau. |
Choisir client/serveur ou PubSub selon la tâche
Dans le modèle client/serveur habituel, le client découvre un endpoint, établit canal sécurisé et session, puis parcourt, lit ou crée des abonnements pour les éléments surveillés. OPC UA PubSub est un mode de publication distinct, avec son propre transport, sa sécurité et sa configuration des abonnés. Tout endpoint client/serveur ne devient pas pour autant un broker ou un émetteur multicast. Notez les modes réellement pris en charge par les produits avant de concevoir routes, pare-feu et reprise WAN. Pour un client SCADA central lisant quelques nœuds connus, partez du chemin client/serveur documenté.
Espace d'adressage et modèle de nœuds d'OPC UA
L’AddressSpace est un graphe qui comprend le RootFolder standard (ns=0;i=84). Ses enfants standards comprennent ObjectsFolder (ns=0;i=85), TypesFolder et ViewsFolder. Un NodeId associe un index d’espace de noms à un identifiant numérique, chaîne, GUID ou opaque. L’espace de noms 0 est réservé aux définitions standard ; le serveur doit enregistrer les espaces de noms applicatifs. Stockez l’URI de l’espace de noms et résolvez son index sur ce serveur au lieu de considérer un index tel que ns=2 comme portable. Les NodeClasses sont les suivantes :
Object : Organisation.
Variable : Données.
Method : Opération.
ObjectType/VariableType : Modèle.
DataType/ReferenceType : Définition.
View : Sous-vue.
Browse et BrowseNext parcourent les références de l’AddressSpace ; Read obtient des attributs et Call appelle des Methods. Des références comme Organizes, HasComponent, HasProperty et HasSubtype expriment des relations différentes. Un PLC peut être représenté par un Object contenant des Variables et des Methods, mais parcourir cette représentation ne garantit pas que chaque Value est à jour ou modifiable.
Tableau : Détail des classes de nœuds
NodeClass | Attributs/propriétés associés | Exemples de références | Utilisation courante des services |
|---|---|---|---|
Object | BrowseName, DisplayName, EventNotifier | Organizes, HasComponent, HasProperty | Parcourir et lire les attributs pris en charge. |
Variable | Value, DataType, ValueRank, AccessLevel | HasProperty, HasComponent | Lire ; écrire uniquement si la fonction est prise en charge et autorisée ; surveiller avec un MonitoredItem. |
Method | Executable, UserExecutable ; InputArguments et OutputArguments sont des Properties | HasComponent, HasProperty | Appeler si la Method existe et si l’autorisation le permet. |
ReferenceType | IsAbstract, Symmetric, InverseName | Organizes, HasComponent, HasSubtype | Parcourir les relations définies par le modèle. |
DataType | IsAbstract, DataTypeDefinition lorsqu’il est défini | HasSubtype | Décrit le type de valeur d’une Variable ; GetEndpoints ne permet pas d’y accéder. |
View | Attributs propres à la View | Organizes et références définies par le modèle | Parcourir le sous-ensemble si le serveur le prend en charge. |
Accordez-vous sur le modèle de données autant que sur le lien. Consignez URI de l'espace de noms, NodeIds, unités, qualité/état, horodatages et droit d'écriture. Un parcours réussi ne démontre ni la fraîcheur d'une valeur ni la sûreté d'une action sur l'automate. Comparez une valeur connue à une référence locale et définissez qui peut écrire. Le guide d'accès distant aux automates et IHM sépare accès réseau et permission de modifier une machine.
Consigner namespace, NodeId et qualité de la valeur
Une NodeId identifie un nœud dans l’espace du serveur et contient un namespace et un identifiant numérique ou textuel. L’indice de namespace peut varier entre instances ; conservez donc son URI avec la NodeId vérifiée. BrowseName et références aident à retrouver une variable, tandis que DataValue porte valeur, statut et horodatages fournis par le serveur. Notez type, unité, échelle et droit d’écriture. Une valeur numérique plausible avec mauvais statut ou ancien horodatage ne constitue pas une mesure saine.
RootFolder est ns=0;i=84 et ObjectsFolder est ns=0;i=85. Pour les nœuds applicatifs, conservez l’URI de l’espace de noms et résolvez son index à l’exécution.
Configuration et exemples pratiques d'OPC UA
Configuration de base
Utilisez l’interface de configuration ou l’API fournie par le serveur OPC UA choisi. Les noms d’outils, les schémas de configuration et les profils pris en charge varient selon le produit et le SDK. Commencez par les décisions courantes suivantes :
Définir un ApplicationUri stable pour l’instance de l’application et le faire correspondre au certificat de l’application lorsque l’authentification par certificat est utilisée.
Configurer le point de terminaison à l’écoute et le nom d’hôte prévus, par exemple opc.tcp://server.example:4840, puis vérifier que les clients peuvent utiliser l’adresse annoncée par le serveur. Un suffixe de chemin propre à un fournisseur n’est pas universel.
Sélectionner une SecurityPolicy, un MessageSecurityMode et un type de jeton utilisateur pris en charge de part et d’autre, puis configurer la confiance et les autorisations. Considérer un point de terminaison de test sans sécurité comme un choix délibéré pour un test isolé, et non comme une solution de production.
Après le démarrage du serveur, examinez les descriptions de points de terminaison annoncées avec GetEndpoints et un client UA adapté. Vérifiez le nom d’hôte du point de terminaison, le mode et la politique de sécurité ainsi que les options de jeton utilisateur avant d’activer une session et de lire un nœud connu. Si le déploiement implique du NAT ou un accès distant, l’adresse annoncée doit rester utilisable depuis le réseau du client.
Tableau : Étapes de configuration de base
Étape | Opération | Outil/commande | Remarques |
|---|---|---|---|
1 | Consigner le point de terminaison et l’identité de l’application | Documentation du serveur ou client pris en charge | Confirmer l’URL du point de terminaison, l’ApplicationUri, l’identité du certificat et les profils pris en charge. |
2 | Résoudre le modèle d’information | Navigation ou outil de configuration de modèle | Enregistrer ou lire le NamespaceUri et résoudre le NamespaceIndex propre au serveur ; ne pas supposer ns=1. |
3 | Choisir la sécurité et tester une valeur connue | Client OPC UA pris en charge | Choisir séparément un MessageSecurityMode et une SecurityPolicy pris en charge ; valider la confiance du certificat, les autorisations utilisateur, Browse et une opération Read documentée. |
Vérifiez routage, VLAN, VPN et pare-feu du firmware exact du routeur. N'ouvrez pas un port OPC UA public simplement pour réussir une démonstration ; utilisez un chemin d'accès contrôlé adapté au site. Le guide VLAN explique pourquoi la limite d'un domaine de diffusion ne constitue pas, à elle seule, une politique d'accès complète.
Dans un essai limité, interrompez tour à tour WAN, VPN, alimentation du routeur et serveur OPC UA. Notez quand le client détecte la panne, si les anciennes valeurs sont signalées, comment session et abonnements se rétablissent, et quand reviennent les premières données fraîches. La spécification des services OPC UA définit les services ; les réglages du client et du serveur déterminent délais et reprises réels. Le retour du routeur en ligne ne prouve pas qu'un abonnement valide a repris.
Documentez modèles de l'automate ou de la passerelle, routeur, firmware, version du client, point de terminaison, configuration de confiance, routes et résultat du test. Si une page produit mentionne seulement « compatible OPC UA », demandez rôle, profil, fonctions prises en charge et démonstration avec le point réel.
Mettre en service le chemin dans un ordre sûr
Relevez produits et versions serveur/client, URL de l’endpoint, nom DNS ou pair VPN, port, interfaces du routeur, VLAN, routes et règles de pare-feu. Vérifiez d’abord la joignabilité, puis la découverte de l’endpoint, la confiance des certificats, la connexion utilisateur, un nœud connu en lecture seule et enfin l’abonnement prévu. Notez la première étape en échec : un socket TCP joignable ne valide pas toute l’application OPC UA. Sous NAT, vérifiez que l’adresse d’endpoint annoncée reste utilisable depuis le réseau du client distant.
Configuration des Certificats de Sécurité
Les certificats d’instance d’application peuvent être autosignés ou délivrés par une autorité de certification. Pour que la configuration fonctionne, l’application doit posséder sa propre clé privée et son certificat, et valider le pair selon les règles de confiance configurées. Un répertoire de certificats rejetés conserve les certificats refusés ; il ne contient pas la liste des pairs de confiance. La procédure de déploiement doit couvrir les points suivants :
Générer ou provisionner la clé privée et le certificat de l’application, ou créer une CSR pour le processus d’AC choisi. Protéger la clé privée et conserver l’identité d’application attendue.
Installer le certificat de l’application et les certificats pertinents des pairs ou autorités émettrices dans les magasins requis par le SDK choisi. Examiner un certificat rejeté avant toute décision explicite de lui accorder sa confiance.
Choisir un MessageSecurityMode et une SecurityPolicy pris en charge par les deux parties, puis effectuer les contrôles pris en charge de validité, d’identité, de chaîne et de révocation. Basic256Sha256 est le nom d’une politique ; un suffixe tel que Basic256Sha256_RSA n’est pas un paramètre standard universel.
Tester le point de terminaison configuré et les autorisations utilisateur avec un nœud connu en lecture seule. Consigner la procédure de renouvellement, de révocation et de mise à jour de la confiance.
Logique de configuration des certificats (pseudocode illustratif, et non configuration exécutable d’un SDK .NET) :
# Illustrative pseudocode; not a version-specific .NET SDK API
application_uri = "urn:example:opcua:server"
certificate = provision_application_certificate(application_uri)
verify_certificate_identity_and_validity(certificate, application_uri)
trust_lists = configure_trust_lists(
trusted_peers=validated_peer_certificates,
trusted_issuers=validated_issuer_certificates,
rejected_store=separate_store_for_rejected_certificates
)
endpoint = select_advertised_endpoint(
security_policy=supported_policy,
message_security_mode=supported_mode,
user_token_policy=supported_user_token
)
# Keep certificate validation enabled; resolve identity, trust, and revocation failures.Distribuez les certificats publics, les autorités de confiance et les informations de révocation au moyen du processus approuvé propre au produit ou d’un service de gestion pris en charge. Ne copiez pas les clés privées dans les magasins de confiance des pairs. Une simple copie de répertoire ou une connexion LDAP ne vérifie pas l’identité du pair et ne constitue pas une décision de confiance sûre.
Tableau : Bonnes pratiques de gestion des certificats
Bonne pratique | Description | Période | Outil/registre |
|---|---|---|---|
Provisionner le certificat de l’application | Vérifier l’ApplicationUri, l’identité du certificat, la protection de la clé et les noms de points de terminaison requis. | Configuration initiale et remplacement selon la politique PKI/de l’appareil. | PKI du site ou processus de gestion des certificats pris en charge. |
Échanger la confiance | Valider l’identité, la validité, la chaîne et l’identité du pair visé avant de l’ajouter à la liste de confiance appropriée. | Avant d’établir la confiance et à chaque changement de confiance. | Processus documenté de liste de confiance ou GDS. |
Renouveler et vérifier la révocation | Renouveler ou réémettre avant expiration selon la politique des certificats ; vérifier la révocation lorsque cela est pris en charge et requis. Expiration et révocation sont distinctes. | Selon la période de validité, le risque et la politique PKI ; aucun intervalle universel de 90 jours ou d’un an. | Inventaire des certificats et processus CRL/OCSP pris en charge. |
Auditer | Consigner les erreurs de certificat, de canal et d’application à l’aide des diagnostics pris en charge par l’implémentation. | Lors de la mise en service et pendant l’exploitation. | Diagnostics client/serveur et journalisation du site. |
Séparer certificats et droits des utilisateurs
Examinez l’endpoint annoncé, la politique de sécurité et le mode de sécurité des messages. Avec l’authentification par certificat applicatif, client et serveur valident l’identité du pair et entretiennent les listes de confiance et de rejet ; compte utilisateur et rôles forment une autre couche. Ne corrigez pas un certificat inconnu en désactivant sa vérification. Contrôlez nom d’hôte, validité, décision de confiance et droit du compte sur le nœud visé. Planifiez renouvellement et mise à jour des listes avant expiration pour éviter une interruption de collecte.
Le magasin des certificats rejetés n’est pas une liste de confiance. Vérifiez l’identité, la validité et la confiance avant d’approuver un certificat ; ne désactivez pas la validation pour masquer une erreur.
Exemples de Configuration Serveur et Client
Exemple de serveur (pseudocode illustratif, et non code C open62541 compilable) : exposer une Variable de température dans un espace de noms applicatif enregistré. Utilisez la version du SDK choisie pour les véritables appels d’API et le cycle de vie.
# Illustrative server pseudocode; SDK calls and types vary by version
application_uri = "urn:example:opcua:server"
model_namespace_uri = "urn:example:temperature-model"
namespace_index = server.register_namespace(model_namespace_uri)
objects_folder = NodeId(namespace_index=0, identifier=85) # ObjectsFolder
temperature_node = server.add_variable(
parent=objects_folder,
reference_type="Organizes",
node_id=NodeId(namespace_index, "Temperature", type="String"),
browse_name=QualifiedName(namespace_index, "Temperature"),
data_type="Int32",
value=initial_temperature
)
set_access(temperature_node, read=True, write=False)
start_server(advertised_endpoint, application_uri, application_certificate)
# Enable a write only in a separately approved use case with explicit permissions.L’exemple enregistre un espace de noms applicatif et ajoute une Variable sous l’ObjectsFolder standard au moyen d’une référence appropriée. La valeur, le type de données et les droits d’accès sont configurés explicitement. Le point de terminaison du serveur, son certificat applicatif, l’authentification des utilisateurs et les autorisations doivent encore être configurés selon le déploiement visé.
Exemple de client (pseudocode illustratif, et non exemple exécutable d’un SDK Python) : résoudre le même URI d’espace de noms et lire le NodeId configuré. L’écriture est volontairement exclue du test initial.
# Illustrative client pseudocode; not a version-specific Python API
client = connect_to_advertised_endpoint(endpoint_url, supported_security_settings)
subscription = None
try:
namespace_index = resolve_namespace_index(client, "urn:example:temperature-model")
node_id = NodeId(namespace_index, "Temperature", type="String")
data_value = read_value_and_quality(client, node_id)
verify_value_status_and_timestamps(data_value, expected_process_value)
subscription = create_subscription(client, publishing_interval=application_setting)
subscription.add_monitored_item(node_id)
process_notifications_until_planned_test_completes(subscription)
finally:
if subscription is not None:
close_subscription(subscription)
disconnect(client)
# This initial test is read-only; an approved write requires a separate step.Pour tester les changements de données, créez une Subscription avec le SDK client choisi, créez un MonitoredItem pour la Variable testée et traitez les notifications. Vérifiez le statut renvoyé ainsi que toute révision des paramètres d’échantillonnage ou de publication. Les API d’abonnement varient selon les SDK ; après une interruption contrôlée, vérifiez la reprise de la connexion, de la session et de l’abonnement, ainsi que la première DataValue actualisée.
Rendre la valeur testée vérifiable
Choisissez un nœud en lecture seule dont la valeur physique ou automate peut être vérifiée séparément. Conservez URI du namespace, NodeId, type, unité, statut et horodatages source et serveur s’ils existent. Comparez une valeur en direct puis une valeur modifiée volontairement avant d’ajouter une longue liste d’abonnements. Avec une passerelle Modbus vers UA, gardez registre, fonction, signe, échelle et ordre des octets d’origine avec la correspondance UA. Vous distinguerez ainsi panne IP et tag présent mais mal interprété.
Observer les abonnements pendant une coupure
Un abonnement contient des éléments surveillés et des réglages de publication ; session et canal sécurisé interviennent aussi. Après une coupure WAN ou VPN, le client peut devoir se reconnecter, rétablir la session ou recréer les abonnements selon le produit et la durée. Testez une seule coupure contrôlée à la fois. Mesurez détection de panne, signalement des valeurs périmées, retour du lien et première valeur fraîche. Une bascule du routeur ne conserve pas forcément la session TCP et une nouvelle connexion ne rétablit pas automatiquement les éléments surveillés.
Diagnostiquer la couche qui échoue
Sans connexion TCP, examinez nom, chemin opérateur, route, pare-feu et service à l’écoute. Si une erreur de certificat ou d’utilisateur suit la connexion, examinez identité, confiance et droits. Une session établie avec BadNodeIdUnknown suggère namespace ou NodeId erronés ; une valeur avec ancien horodatage suggère acquisition serveur, conversion de passerelle ou cache client. Conservez endpoint, code de statut et nœud testé sans identifiants sensibles. La réparation reste ciblée sans affaiblir la sécurité pour masquer un défaut de routage ou de modèle.
Exemple de Configuration Pub/Sub
Une configuration PubSub relie un PublishedDataSet et un DataSetWriter côté éditeur à un DataSetReader compatible et à un mappage cible côté abonné. Voici un pseudocode illustratif des accords nécessaires ; il ne s’agit ni d’un fichier XML UANodeSet, ni d’un message UADP, ni d’une configuration produit importable :
# Conceptual PubSub configuration outline; not XML or a runnable configuration file
publisher:
connection: select_supported_transport_and_address()
writer_group:
publishing_interval: configured_for_application
message_mapping: UADP_or_JSON_as_supported
security: configure_policy_mode_and_security_group_if_required
data_set_writer:
writer_id: configured_unique_identifier
data_set: select_fields_from_address_space()
metadata: publish_or_provision_matching_data_set_metadata()
subscriber:
connection: match_transport_and_address()
reader_group:
data_set_reader:
publisher_id: match_publisher()
writer_group_id: match_writer_group()
data_set_writer_id: match_data_set_writer()
metadata: match_data_set_schema()Pour le transport choisi, configurez une adresse ou un broker/topic accessible des deux côtés et faites correspondre le PublisherId, le WriterGroupId, le DataSetWriterId, les métadonnées des champs et les mappages cibles utilisés par le lecteur. La multidiffusion UDP exige une prise en charge réseau adaptée et n’est pas automatiquement routée sur un WAN ou un VPN. La sécurité des messages PubSub repose sur le mode, la politique et les clés de groupe configurés ; lorsqu’elle est prise en charge, un Security Key Service peut distribuer des clés aux membres autorisés du groupe. La sécurité du transport et la sécurité des messages PubSub sont deux décisions distinctes.
Tableau : Éléments de configuration Pub/Sub
Élément | Configuration de l’éditeur | Configuration de l’abonné | Vérification/sécurité |
|---|---|---|---|
PublisherId | Identifier l’éditeur dans le mappage de messages configuré. | Faire correspondre le PublisherId attendu lors du filtrage. | Le type et l’encodage dépendent du mappage ; ce n’est pas une association à une clé de chiffrement. |
WriterGroupId | Identifier le WriterGroup dans le NetworkMessage. | Faire correspondre le WriterGroupId attendu lorsque cela est requis. | Ne pas le substituer à un DataSetWriterId. |
DataSetWriterId | Identifier un DataSetWriter. | Faire correspondre le DataSetWriterId attendu. | Ce n’est pas génériquement un « stream ID » ; vérifier le mappage choisi. |
DataSet et métadonnées | Sélectionner les champs et fournir les métadonnées/le schéma du DataSet. | Configurer des métadonnées correspondantes et l’interprétation des champs. | Vérifier les URI d’espace de noms, les NodeIds, les DataTypes et l’ordre des champs. |
Mappage de transport | Choisir un mappage UDP, Ethernet ou broker pris en charge, tel que MQTT le cas échéant. | Configurer un mappage, une adresse/topic et un comportement de lecteur correspondants. | AMQP, TSN et les autres options dépendent de la spécification/du profil applicable et de la prise en charge produit. |
Sécurité | Configurer la sécurité des messages prise en charge, le SecurityGroupId et les SecurityKeyServices si nécessaire. | Utiliser des paramètres de sécurité compatibles et obtenir les clés auprès du service de clés configuré. | Valider séparément les certificats d’application, les autorisations, la rotation des clés et les contrôles réseau. |
Scénarios et cas d'application concrets par secteur
OPC UA peut relier les données opérationnelles aux applications de production, de maintenance, de qualité et d’énergie lorsqu’un modèle d’information et un chemin de données adaptés sont implémentés. Les exemples ci-dessous sont des scénarios d’ingénierie, et non des résultats vérifiés de déploiements clients nommés. Les bénéfices et les performances doivent être évalués dans le système réel.
Industrie manufacturière : exposer les données des PLC et des machines aux applications MES ou de maintenance au moyen d’un modèle documenté ; vérifier les identifiants, les unités, l’état des mises à jour et la propriété des données.
Énergie : intégrer des mesures et l’état des équipements pour la supervision et l’analyse, en validant les horodatages, les unités et la politique d’accès.
Industrie pharmaceutique : échanger des informations relatives aux équipements et aux lots à des fins de traçabilité. OPC UA n’établit ni conformité réglementaire ni validation d’un dossier de production à lui seul.
Automobile : partager des informations de machines ou de robots avec les systèmes de production et de maintenance. Les exigences de commande de mouvement, de sécurité fonctionnelle et de temps réel nécessitent leur propre solution conçue à cet effet.
Pétrole et gaz : assurer une surveillance à distance au moyen d’un serveur ou d’une passerelle adaptés et d’un chemin réseau maîtrisé ; tester les pertes de communication, le signalement des données périmées et la reprise.
Tableau : Résumé des scénarios d'application
Secteur | Scénario illustratif | Rôle possible d’OPC UA | Éléments à recueillir |
|---|---|---|---|
Industrie manufacturière | Intégration d’une ligne de production | Échanger des données modélisées d’équipements entre applications PLC/MES compatibles. | Profils pris en charge, mappage du modèle et résultats mesurés par l’application. |
Énergie | Surveillance d’un poste ou d’une centrale | Exposer certaines mesures et certains états à des clients de supervision. | Prise en charge du point de terminaison, comportement de mise à jour et mesures énergétiques du projet. |
Industrie pharmaceutique | Traçabilité des lots et des équipements | Utiliser un modèle d’information pertinent pour représenter les paramètres des équipements. | Version de la spécification complémentaire, exigences d’audit et enregistrements validés. |
Automobile | Automatisation d’une chaîne d’assemblage | Échanger certaines données de production ou de robot lorsque les profils sont compatibles. | Compatibilité des appareils, tests de synchronisation et indicateurs de qualité du projet. |
Pétrole et gaz | Surveillance à distance | Exposer certaines données de terrain au moyen d’une conception réseau et d’accès testée. | Sécurité, connectivité et mesures du comportement de détection/réponse. |
Comparaison d'OPC UA avec MQTT, Modbus, Profinet
Ces protocoles répondent à des besoins différents dans un système industriel. OPC UA définit des services et un modèle d’information typé ; MQTT distribue des messages par l’intermédiaire d’un broker ; Modbus fournit une interface d’appareil fondée sur des fonctions et des adresses ; PROFINET prend en charge l’Ethernet industriel et les profils applicatifs associés. Comparez la sémantique des données requise, la prise en charge des appareils, les délais, le contrôle d’accès et l’effort d’intégration. Le nom d’un protocole ne détermine à lui seul ni la bande passante, ni la latence, ni la sécurité, ni le coût.
Tableau : rôles des protocoles et points à prendre en compte pour l’ingénierie
Fonctionnalité | OPC UA | MQTT | Modbus | PROFINET |
|---|---|---|---|---|
Modèle de communication | Services Client/Server et PubSub lorsque cette option est prise en charge. | Publication/abonnement par l’intermédiaire d’un broker. | Échange requête/réponse fondé sur des codes de fonction. | Profils Ethernet industriel pour l’automatisation ; les détails dépendent de la classe de conformité et du produit. |
Sécurité | Mécanismes UA configurables ; vérifier le mode, la politique, l’identité, la confiance et les autorisations. | TLS et l’authentification/l’autorisation auprès du broker dépendent du client, du broker et de leur configuration. | Modbus de base ne fournit ni authentification applicative ni chiffrement ; prévoir une architecture protégée ou une extension prise en charge. | Les fonctions de sécurité dépendent de la version PROFINET, du profil et de la configuration applicables. |
Bande passante | Dépend de l’encodage choisi, des champs, des métadonnées et de la cadence. | Dépend de la charge utile, du topic, du QoS et du transport. | Dépend de la fonction, de la quantité de données et du transport. | Dépend des données cycliques/acycliques et de la configuration réseau. |
Interopérabilité | Les services et modèles d’information y contribuent ; des profils et modèles compatibles restent nécessaires. | Le schéma de charge utile et les conventions de topic doivent faire l’objet d’un accord. | Les mappages de registres et l’interprétation des données dépendent de l’appareil. | Les profils et les descriptions d’appareils déterminent l’interopérabilité. |
Latence | Mesurer le point de terminaison, le service, le réseau et la charge choisis. | Mesurer le chemin du broker, le QoS et le comportement des abonnés. | Mesurer le temps de réponse de l’appareil et le chemin série/TCP. | Mesurer le réseau et la classe d’appareil configurés. |
Évolutivité/historique | Les limites dépendent du serveur, du profil, du modèle et de l’application ; l’accès historique est un service/modèle distinct pris en charge. | La capacité du broker et des consommateurs dépend de l’implémentation ; l’historique exige un stockage et une conception applicative distincts. | Les limites varient selon l’appareil et l’application ; la lecture d’un registre n’implique pas l’historisation. | Les limites et fonctions de diagnostic dépendent des profils et des équipements. |
Coût | Les coûts de SDK, de licence, d’intégration et de validation dépendent du produit et du projet. | Les coûts de broker, de client, d’hébergement et d’exploitation varient. | Les équipements existants peuvent limiter les remplacements ; les passerelles et l’intégration ont néanmoins un coût. | Les coûts du matériel, de l’ingénierie et des licences dépendent du produit et du projet. |
Usage courant | Échange structuré d’informations industrielles et de services. | Télémétrie et distribution d’événements par l’intermédiaire d’un broker. | Échange simple de données d’appareils et intégration de systèmes anciens. | Communications d’automatisation industrielle nécessitant le profil PROFINET applicable. |
Ces protocoles peuvent coexister. Par exemple, une passerelle adaptée peut mapper des points Modbus vers un modèle UA, et un mappage PubSub UA pris en charge peut distribuer des DataSets via MQTT. Le routage seul n’effectue aucune conversion. Vérifiez le profil exact du produit, le mappage des informations, la sécurité et le comportement de reprise pour la combinaison retenue.
Comparer les rôles de données avec Modbus et MQTT
Modbus expose des points au moyen de fonctions et de conventions d’adresse. Un serveur OPC UA peut les représenter par des nœuds nommés avec types, unités et relations, mais une passerelle adaptée doit effectuer la conversion. MQTT diffuse des messages par topics et broker sans définir l’espace d’adressage ni les services OPC UA. Choisissez selon la tâche : interrogation d’équipement, données industrielles contextualisées ou diffusion d’événements. Séparez conversion de protocole, routage IP et rôle VPN du routeur industriel.
Perspectives d'évolution
Les pistes d’évolution comprennent des modèles complémentaires plus riches, des implémentations de périphérie, l’intégration de l’analyse et des options de transport PubSub. Les données UA structurées peuvent servir aux jumeaux numériques et aux applications d’IA lorsque ces consommateurs comprennent le modèle. Le sans-fil industriel ou TSN peut faire partie d’un réseau conçu à cet effet, mais les délais applicatifs et l’interopérabilité doivent être validés. Ces pistes ne constituent ni un calendrier de publication confirmé, ni une prévision de marché, ni une preuve de l’existence d’une spécification d’IA particulière.
Les difficultés persistantes comprennent l’interprétation cohérente des modèles complémentaires, l’interopérabilité entre les profils pris en charge, la gestion du cycle de vie des certificats et des clés, ainsi que les ressources disponibles sur les appareils de petite taille. Planifiez les mises à niveau en fonction des normes publiées et des versions de produits réellement prises en charge, plutôt qu’en vous fondant sur un nombre supposé de futures spécifications ou sur une feuille de route cryptographique promise.
Tableau : Prévision des tendances futures
Sujet | Piste possible | Réserve |
|---|---|---|
Modèles liés à l’IA | Représenter les données du domaine et leurs relations au moyen de modèles d’information définis. | Il faut un modèle complémentaire précis et des implémentations compatibles ; aucun gain en maintenance prédictive n’est implicite. |
Déploiement en périphérie | Exécuter des applications ou piles OPC UA prises en charge à proximité des appareils de terrain. | Le matériel, le profil du SDK, la mémoire et les limites de performance dépendent du produit. |
5G et TSN | Associer des applications OPC UA à des réseaux sans fil ou déterministes adaptés. | L’interopérabilité, la latence, la couverture et la disponibilité exigent des tests à l’échelle du système. |
Données environnementales | Modéliser des mesures énergétiques ou environnementales dans un modèle d’information propre à l’application. | Aucune spécification « verte », conformité ESG ou réduction énergétique n’est automatique. |
Visualisation de jumeau numérique | Utiliser les modèles d’information comme une entrée parmi d’autres d’une application de jumeau numérique. | La visualisation et la collaboration dépendent du logiciel applicatif et de la validation des données. |
Résumé
OPC UA s’appuie sur les besoins d’accès aux données industrielles auxquels répondait OPC Classic, tout en fournissant un espace d’adressage multiplateforme, des services, des modèles d’information et des mécanismes de sécurité. Sa valeur pratique dépend de rôles applicatifs clairs, de capacités compatibles et d’un déploiement correct. Commencez par une valeur connue en lecture seule, vérifiez l’identité et les autorisations, testez l’abonnement prévu et sa reprise, puis élargissez le modèle. Appuyez-vous sur la documentation actuelle du SDK, les modèles complémentaires pertinents et les preuves de conformité des produits concernés. Les nouvelles technologies d’analyse et de réseau peuvent étendre cette architecture, mais elles ne dispensent pas de valider l’application.
FAQ
Quelle est la différence entre OPC UA et OPC Classic ?
Les spécifications OPC Classic telles que DA, HDA et AE utilisent des interfaces Windows COM/DCOM. OPC UA définit un espace d’adressage indépendant de la plateforme, des services, des modèles d’information, des mappages de communication et des mécanismes de sécurité configurables. La migration n’est pas automatiquement transparente : identifiez le serveur OPC UA (qui peut être une passerelle) et vérifiez le mappage des tags, des types et des autorisations.
Comment gérer l’expiration d’un certificat OPC UA ?
Vérifiez la période de validité du certificat, l’ApplicationUri et l’identité du point de terminaison, la chaîne de confiance, l’état de révocation lorsque le contrôle est requis et pris en charge, ainsi que les listes de confiance du serveur et du client. Renouvelez ou réémettez le certificat via la PKI du site ou un processus de gestion des certificats pris en charge, puis validez et distribuez le certificat de remplacement. Connectez-vous au point de terminaison prévu et lisez un nœud connu. Les autorisations des utilisateurs et la confiance dans le certificat applicatif sont deux contrôles distincts ; ne désactivez pas la validation. Désactiver les contrôles de révocation ne renouvelle pas un certificat expiré ; aucun intervalle universel de 90 jours ne s’applique.
Dans quels cas PubSub est-il préférable à Client/Server ?
Envisagez PubSub lorsqu’un éditeur doit distribuer des messages DataSet sélectionnés à plusieurs abonnés et que les produits prennent en charge un transport, un mappage, des métadonnées et une configuration de sécurité compatibles. Client/Server reste utile pour la découverte, la navigation, les lectures et écritures à la demande, les méthodes et les abonnements. PubSub peut réduire les interrogations répétées, mais les gains de bande passante et de latence dépendent de la sélection des messages, de leur cadence, du réseau et de l’implémentation.
Quels langages de programmation peut-on utiliser avec OPC UA ?
La spécification OPC UA est indépendante du langage de programmation. Des SDK et des piles logicielles existent dans plusieurs langages, notamment C/C++, .NET, Java et Python, mais leurs profils pris en charge, leurs fonctions de sécurité et leur maintenance diffèrent. Vérifiez la bibliothèque et sa version exactes au regard des fonctions serveur requises par l’application.
Comment utiliser OPC UA avec la 5G ?
Un déploiement peut transporter le trafic OPC UA sur un chemin réseau comprenant la 5G. Le comportement PubSub ou Client/Server dépend toujours du mappage, du point de terminaison et de la conception réseau choisis. La 5G, le TSN et l’URLLC ne garantissent pas à eux seuls une latence inférieure à la milliseconde ni une commande sans fil en temps réel ; testez le système complet au regard de ses exigences.
Quelles sont les erreurs de configuration OPC UA fréquentes et comment les vérifier ?
Vérifiez le point de terminaison annoncé et le chemin réseau, puis le MessageSecurityMode et la SecurityPolicy sélectionnés, l’identité, la validité et la confiance du certificat, la politique de jeton utilisateur et les autorisations, l’URI d’espace de noms et le NodeId, ainsi que le DataType et le statut de la Variable. Consultez le statut de diagnostic et les journaux du serveur/client ; un test de port ou un outil générique ne prouve pas à lui seul que l’opération applicative fonctionne.
Le routeur doit-il décoder OPC UA pour transporter ce trafic ?
Non. Un routeur IP peut acheminer un flux client/serveur autorisé sans interpréter le modèle de données OPC UA. Traduction ou hébergement local sont des capacités distinctes à vérifier.
Un port joignable prouve-t-il que la connexion OPC UA fonctionne en sécurité ?
Non. Vérifiez identité du point de terminaison, certificats, droits des utilisateurs, établissement de session et valeur applicative connue. La joignabilité réseau n'est qu'une étape.
Un appareil Modbus devient-il serveur OPC UA grâce au routage ?
Non. Un automate ou une passerelle capable doit fournir le serveur OPC UA et associer les données Modbus aux types, unités et significations corrects.
Les abonnements reprennent-ils automatiquement après une bascule WAN ?
Pas nécessairement. Paramètres client/serveur, état de session et changement de chemin comptent. Testez l'abonnement d'origine et la première valeur fraîche après une interruption contrôlée.
Références
OPC-10000-1 – OPC Unified Architecture - Part 1: Overview and Concepts — Architecture, concepts fondamentaux et distinction entre Client/Server et PubSub.
OPC-10000-2 – OPC Unified Architecture - Part 2: Security Model — Sécurité applicative et utilisateur, validation des certificats, confiance et responsabilités opérationnelles.
OPC-10000-3 – OPC Unified Architecture - Part 3: Address Space Model — Nœuds, références, attributs, NodeIds et notions d’espace de noms.
OPC-10000-4 – OPC Unified Architecture - Part 4: Services — Découverte, sessions, lecture, écriture, abonnements et codes d’état des services.
OPC-10000-5 – OPC Unified Architecture - Part 5: Information Model — Modèle d’information standard, espace de noms 0 et définitions des dossiers standard.
OPC-10000-6 – OPC Unified Architecture - Part 6: Mappings — Encodages, sécurité et correspondances de transport.
OPC-10000-14 – OPC Unified Architecture - Part 14: PubSub — Éditeurs et abonnés DataSet, profils de transport et sécurité PubSub.
