Les plates-formes de communication industrielle OPC fêtent leurs 10 ans. La Fondation en profite pour présenter Architecture Unifiée (UA), qui a pour but d’unifier les technologies existantes des serveurs OPC.
Les plates-formes de communication industrielle OPC viennent de fêter leurs 10 ans. La Fondation OPC en a profité pour présenter sa nouvelle Architecture Unifiée (UA), qui a pour but d’unifier toutes les technologies existantes des serveurs OPC fondées sur la technologie COM de Microsoft.
OPC UA est une plate-forme ouverte à travers laquelle des systèmes industriels variés peuvent communiquer en s’envoyant des Messages, suivant une structure Clients/Servers sur des réseaux disparates.
« OPC UA va remplacer, moderniser, et améliorer toutes les fonctionnalités des interfaces OPC existantes » selon Jim Luth, directeur technique pour la Fondation OPC. Jim Luth explique l’origine du projet de l’architecture unifiée « il est l’émanation d’une demande des utilisateurs qui désiraient une meilleure intégration des modules, comme par exemple Alarmes & Events (A&E) : la précédente version OPC DA permettait à un Client de lire/écrire, souscrire une donnée comme la température, mais ne permettait pas d’apposer une alarme sur cette donnée. Le Server OPC A&E, qui permet aux Clients de répertorier des alarmes, est une interface serveur séparée. Du coup, le Client ne pouvait pas faire le lien entre un paramètre lu sur OPC DA et cette alarme. Cette situation survient parce qu’il n’y a pas de fonctionnalités pour nommer le paramètre ‘température’ de façon identique dans les deux serveurs ».
« Au final, l’utilisateur a deux interfaces Clients séparées, répertorie ses informations dans deux arborescences séparées, et doit faire un travail de recherche pour retrouver les paramètres similaires. La solution est d’utiliser le même browser, les mêmes fonctions de lecture, écriture et souscription pour les données de DA et Alarms&Events. Conséquemment, UA va découpler les structures de données qui différencient Data Access, Historical Data Access et Alarms&Events par exemple, mais va fournir les mêmes méthodes génériques pour opérer sur chacun d’eux ».
OPC UA fournit un AdressSpace (informations que le Server rend visible à ces Clients) intégré et un modèle de Services (opération ‘appelable’ par le Client, comme un contrat WSDL dans un WebService). Cela permet à un unique Server OPC UA d’intégrer les données, leur historique, les Alarms&Events, directement dans l’AdressSpace suscité. Pour reprendre l’exemple d’une mesure de température, OPC UA avec son modèle objet permet aux Servers OPC UA de fournir des définitions pour des Objects et leurs composants. Celles-ci peuvent être standards ou spécifiques au système. Du coup, les Servers OPC UA sont capables de représenter un capteur de température comme un objet, accompagné de la valeur de la mesure de celle-ci, d’un jeu de paramètres pour les alarmes, et les limites qui déclenchent ces dites alarmes.
Les WebServices sont des technologies de communication ‘application to application’ capables de supporter des plateformes de différents fournisseurs tels que Microsoft, IBM, Sun, Linux. « Nous croyons que les performances actuelles et à venir de cette technologie rendront OPC UA encore plus interopérable. Mais peut être qu’à l’avenir les WebServices seront remplacés par des technologies plus performantes. Par conséquent, les spécifications d’UA sont écrites afin de le rendre indépendant des plateformes. Cela simplifie les tâches de migrations ou de transferts de technologies » explique Jim Luth.
D’un autre côté, il existe une centaine de Serveurs OPC sur le marché qui sont en mesure d’assurer la connexion aux systèmes de terrain divers et variés. « La fondation OPC fournira les wrappers nécessaires pour permettre à OPC UA installée sur des serveurs OPC existants, d’accélérer le processus de développements de Clients OPC UA » argumente Jim Luth.
Les groupes responsables de la création de standards en automatisation, comme ISA ou Mimosa, produisent des spécifications pour les modèles d’informations. Par exemple, ISA-S88, ISA-S95 et IEC TC 57-CIM pour ne citer qu’eux. Avec la popularité d’XML et sa capacité à encoder et mettre en relation des données hétérogènes, la plupart de ces spécifications sont étendues afin d’inclure des schémas XML standards.
« Bien que ces spécifications soient utilisées pour unifier les nomenclatures qui décrivent les acteurs et leurs relations, l’interopérabilité d’un point de vue logiciel n’est pas toujours assurée. Même si l’application logicielle utilise des schémas XML, il n’existe pas toujours de moyen de partager ces documents XML. OPC produit une spécification qui permettra l’échange de ces données issues de modèles variés, indépendamment des applications développées. Dans ce but, OPC travaille avec les organisations de standardisation ».
Fonctionnement de l’architecture UA
L’architecture d’OPC UA modélise les Clients et Servers comme des partenaires en mesure d’interagir mutuellement. Chaque système peut contenir plusieurs Client/Server. Chaque Client peut interagir avec un ou plusieurs Servers et réciproquement. (Fig.4 et Fig.5)
Une Session représente une connexion entre les Clients et les Servers. Les Servers ont la possibilité de limiter le nombre de sessions en regard des disponibilités des ressources, les restrictions dues à l’usage de licences, ou d’autres contraintes. Chaque Session est indépendante des protocoles de communications sous-jacents. Du coup, une défaillance de la part de ces protocoles engendrent la fin de la Session. Par ailleurs, cette fermeture de Session peut être issue d’une requête d’un Client ou d’un Server, ou suite à l’inactivité du Client.
L’application Client OPC UA représente le code de la fonction du Client. Elle utilise l’API (Application Program Interface) du Client OPC UA pour envoyer et recevoir des réponses et des requêtes de Services (définis dans la partie 7 de la spécification, opérations appelables par le Client dans le Server OPC UA) de la part du Server.
D’un autre côté, l’application du Server, qui elle aussi représente le code de la fonction de celui-ci, utilise l’API du Server pour envoyer et recevoir des Messages de la part des Clients.
Le Communication Stack (couche entre l’applicatif et le matériel) convertit les appels d’API Clients en Messages, qui seront envoyés au Server. Le Communication Stack reçoit aussi des réponses et des Notification Message et les délivre à l’application Client à travers l’API de ce-dit Client.
Précisons que les API des Clients et Servers OPC UA sont des interfaces internes qui isolent l’application des Clients/Servers respectifs du Communication Stack d’OPC UA.
En outre, une application peut combiner des composants d’un couple Client/Server pour permettre une interaction avec d’autres Client/Server. Dans ce cas, c’est une interaction entre deux Servers pour laquelle un Server joue le rôle d’un Client de l’autre Server. Ce type d’interaction permet, dans le cadre de déploiement de serveurs, que les informations soient échangées sur une base peer to peer, et que les serveurs s’enchaînent suivant une architecture en couche (Fig.7).
Enfin, OPC UA autorise la création de Clients et Servers redondants, pour la sécurité ou la répartition de la charge de travail. Les détails de cet aspect de redondance se trouvent dans la partie 4 de la spécification.
OPC UA définit les standards de Services (opération que le Client peut appeler dans un Server) que le Server doit fournir, et les Servers individuels spécifient aux Clients quels Services ils doivent supporter. L’information est convoyée en utilisant des données standard ou constructeur. Les Servers définissent des modèles objets que les Clients peuvent découvrir en dynamique.
Par exemple, les Servers peuvent fournir à la fois l’accès aux données courantes et horodatées, et notifier les changements importants aux clients. « OPC UA peut être mappé selon différents modèles de protocoles de communication, et les données peuvent être encodées de différentes façons pour optimiser la transmission et l’efficacité » précise la fondation OPC. OPC UA permet la manipulation de données encodées en différents formats, notamment en structure binaire et les documents XML. Le format de cette donnée sera défini par OPC, ou par les organisations de standards. Quant au mapping concernant le transport des données, il s’effectue via TCP ou SOAP sur http. Ces mappings et ces encodages de données sont décrits dans la partie 6 de la spécification.
Migration et sécurité
OPC UA a été conçu pour permettre aux Clients/Servers OPC existants, qui utilisent la technologie Microsoft COM, de migrer vers l’architecture unifiée. Selon la fondation OPC, les données issues des Servers OPC COM (Data Access, Historical Data Access et Alarms&Events) peuvent facilement être mappées et exposées au sein du nouveau OPC UA. Chaque spécification OPC précédente définit son propre modèle d’AddressSpace et son propre jeu de Services. OPC UA unifiera ces modèles dans un unique AdressSpace intégré doublé de son unique jeu de Services.
« Les communications sont sécurisées et assurent ainsi les identités des Clients et des Servers » selon la Fondation OPC. La sécurité avec OPC UA concerne plusieurs niveaux : l’authentification des Clients/Servers, des utilisateurs, l’intégrité et la confidentialité des communications. OPC UA fournit un modèle pour la sécurité, défini dans la partie 2 de la spécification. Celui-ci comprend des mécanismes et des paramètres de sécurité standards. Les Profils de sécurité sont définis dans la partie 7 de la spécification.
Selon la Fondation OPC, l’aspect sécuritaire garantit un canal de communication sécurisé pendant toute la durée de la Session (connexion entre Client/Server) et assure l’intégrité des Messages échangés. D’un point de vue technique, quand une Session est établie, l’application du couple Client/Server négocie un canal de communication sécurisé et échange les Certificates logiciels (structure de données qui décrit les capacités d’un Client ou d’un Server) qui identifient les Clients/Servers concernés.
Ces Certificates, générés par la fondation OPC, indiquent quels Profils (jeu de fonctionnalités auquel le Server doit se conformer) l’application utilise. Les Certificates issus d’autres organisations sont aussi échangés durant l’établissement de la session. Le Server peut authentifier l’utilisateur, et autoriser la requête d’accès à ses Objects (Systèmes, Sous-sytèmes et équipements).
Encadré
Abréviations :
A&E : Alarms&Events
API : Application Programming Interface
COM : Component Object Model
DA : Data Access
DX : Data Exchange
HDA : Historical Data Access
HMI : Human-Machine Interface
MES : Manufacturing Execution System
PLC : Programmable Logic Contoller
SCADA : Supervisory Control And Data Acquisition
SOAP : Simple Object Access Protocol
UA : Unified Architecture
UML : Unified Modelling Language
WSDL : Web Services Definition Language
XML : Extensible Mark-up Language.
Encadré
Structure de OPC UA :
Cette spécification est organisée comme une spécification multi-parties, comme illustré sur la fig (carré avec les parties).
Les sept premières parties de la spécification spécifient les capacités du noyau d’OPC UA. Ces capacités définissent la structure de l’AdressSpace et des Services qui opèrent dessus. On retrouve dans les parties de huit à onze les types spécifiques d’accès qui étaient auparavant sur les spécifications OPC COM, comme Data Access (DA), Alarms&Event (A&E), et Historical Data Access (HDA).
Partie 1 : OPC UA Concepts : cette spécification décrit les concepts applicables aux Servers et Clients OPC UA.
Partie 2 : OPC UA Security Model : décrit le modèle pour sécuriser les interactions entre les Servers et Clients OPC UA.
Partie 3 : OPC UA Address Space Model : décrit le contenu et la structure du Server d’AddressSpace.
Partie 4 : OPC UA Services : spécifie les Services fournis par les Servers OPC UA.
Partie 5 : OPC UA Information Model : spécifie les types standards et leurs relations avec les Servers OPC UA.
Partie 6 : OPC UA Service Mappings : spécifie le mapping des transport et les encodage des données supportés par OPC UA.
Partie 7 : OPC UA Profiles : spécifie les Profiles qui sont disponibles pour les Clients et Server OPC.
Partie 8 : OPC UA Data Access : spécifie l’utilisation de OPC UA pour l’accès aux données.
Partie 9 : OPC UA Alarms and Conditions : spécifie l’usage du support d’OPC UA pour l’accès à Alarms et condition.
Partie 10 : OPC UA Programs : spécifie le support pour l’accès aux Programs.
Partie 11 : OPC UA Historical Access : spécifie l’utilisation de OPC UA pour l’accès à l’historique. Cet accès inclut à la fois les données et les Events.
j51p73
Les plates-formes de communication industrielle OPC viennent de fêter leurs 10 ans. La Fondation OPC en a profité pour présenter sa nouvelle Architecture Unifiée (UA), qui a pour but d’unifier toutes les technologies existantes des serveurs OPC fondées sur la technologie COM de Microsoft.
OPC UA est une plate-forme ouverte à travers laquelle des systèmes industriels variés peuvent communiquer en s’envoyant des Messages, suivant une structure Clients/Servers sur des réseaux disparates.
« OPC UA va remplacer, moderniser, et améliorer toutes les fonctionnalités des interfaces OPC existantes » selon Jim Luth, directeur technique pour la Fondation OPC. Jim Luth explique l’origine du projet de l’architecture unifiée « il est l’émanation d’une demande des utilisateurs qui désiraient une meilleure intégration des modules, comme par exemple Alarmes & Events (A&E) : la précédente version OPC DA permettait à un Client de lire/écrire, souscrire une donnée comme la température, mais ne permettait pas d’apposer une alarme sur cette donnée. Le Server OPC A&E, qui permet aux Clients de répertorier des alarmes, est une interface serveur séparée. Du coup, le Client ne pouvait pas faire le lien entre un paramètre lu sur OPC DA et cette alarme. Cette situation survient parce qu’il n’y a pas de fonctionnalités pour nommer le paramètre ‘température’ de façon identique dans les deux serveurs ».
« Au final, l’utilisateur a deux interfaces Clients séparées, répertorie ses informations dans deux arborescences séparées, et doit faire un travail de recherche pour retrouver les paramètres similaires. La solution est d’utiliser le même browser, les mêmes fonctions de lecture, écriture et souscription pour les données de DA et Alarms&Events. Conséquemment, UA va découpler les structures de données qui différencient Data Access, Historical Data Access et Alarms&Events par exemple, mais va fournir les mêmes méthodes génériques pour opérer sur chacun d’eux ».
OPC UA fournit un AdressSpace (informations que le Server rend visible à ces Clients) intégré et un modèle de Services (opération ‘appelable’ par le Client, comme un contrat WSDL dans un WebService). Cela permet à un unique Server OPC UA d’intégrer les données, leur historique, les Alarms&Events, directement dans l’AdressSpace suscité. Pour reprendre l’exemple d’une mesure de température, OPC UA avec son modèle objet permet aux Servers OPC UA de fournir des définitions pour des Objects et leurs composants. Celles-ci peuvent être standards ou spécifiques au système. Du coup, les Servers OPC UA sont capables de représenter un capteur de température comme un objet, accompagné de la valeur de la mesure de celle-ci, d’un jeu de paramètres pour les alarmes, et les limites qui déclenchent ces dites alarmes.
Les WebServices sont des technologies de communication ‘application to application’ capables de supporter des plateformes de différents fournisseurs tels que Microsoft, IBM, Sun, Linux. « Nous croyons que les performances actuelles et à venir de cette technologie rendront OPC UA encore plus interopérable. Mais peut être qu’à l’avenir les WebServices seront remplacés par des technologies plus performantes. Par conséquent, les spécifications d’UA sont écrites afin de le rendre indépendant des plateformes. Cela simplifie les tâches de migrations ou de transferts de technologies » explique Jim Luth.
D’un autre côté, il existe une centaine de Serveurs OPC sur le marché qui sont en mesure d’assurer la connexion aux systèmes de terrain divers et variés. « La fondation OPC fournira les wrappers nécessaires pour permettre à OPC UA installée sur des serveurs OPC existants, d’accélérer le processus de développements de Clients OPC UA » argumente Jim Luth.
Les groupes responsables de la création de standards en automatisation, comme ISA ou Mimosa, produisent des spécifications pour les modèles d’informations. Par exemple, ISA-S88, ISA-S95 et IEC TC 57-CIM pour ne citer qu’eux. Avec la popularité d’XML et sa capacité à encoder et mettre en relation des données hétérogènes, la plupart de ces spécifications sont étendues afin d’inclure des schémas XML standards.
« Bien que ces spécifications soient utilisées pour unifier les nomenclatures qui décrivent les acteurs et leurs relations, l’interopérabilité d’un point de vue logiciel n’est pas toujours assurée. Même si l’application logicielle utilise des schémas XML, il n’existe pas toujours de moyen de partager ces documents XML. OPC produit une spécification qui permettra l’échange de ces données issues de modèles variés, indépendamment des applications développées. Dans ce but, OPC travaille avec les organisations de standardisation ».
Fonctionnement de l’architecture UA
L’architecture d’OPC UA modélise les Clients et Servers comme des partenaires en mesure d’interagir mutuellement. Chaque système peut contenir plusieurs Client/Server. Chaque Client peut interagir avec un ou plusieurs Servers et réciproquement. (Fig.4 et Fig.5)
Une Session représente une connexion entre les Clients et les Servers. Les Servers ont la possibilité de limiter le nombre de sessions en regard des disponibilités des ressources, les restrictions dues à l’usage de licences, ou d’autres contraintes. Chaque Session est indépendante des protocoles de communications sous-jacents. Du coup, une défaillance de la part de ces protocoles engendrent la fin de la Session. Par ailleurs, cette fermeture de Session peut être issue d’une requête d’un Client ou d’un Server, ou suite à l’inactivité du Client.
L’application Client OPC UA représente le code de la fonction du Client. Elle utilise l’API (Application Program Interface) du Client OPC UA pour envoyer et recevoir des réponses et des requêtes de Services (définis dans la partie 7 de la spécification, opérations appelables par le Client dans le Server OPC UA) de la part du Server.
D’un autre côté, l’application du Server, qui elle aussi représente le code de la fonction de celui-ci, utilise l’API du Server pour envoyer et recevoir des Messages de la part des Clients.
Le Communication Stack (couche entre l’applicatif et le matériel) convertit les appels d’API Clients en Messages, qui seront envoyés au Server. Le Communication Stack reçoit aussi des réponses et des Notification Message et les délivre à l’application Client à travers l’API de ce-dit Client.
Précisons que les API des Clients et Servers OPC UA sont des interfaces internes qui isolent l’application des Clients/Servers respectifs du Communication Stack d’OPC UA.
En outre, une application peut combiner des composants d’un couple Client/Server pour permettre une interaction avec d’autres Client/Server. Dans ce cas, c’est une interaction entre deux Servers pour laquelle un Server joue le rôle d’un Client de l’autre Server. Ce type d’interaction permet, dans le cadre de déploiement de serveurs, que les informations soient échangées sur une base peer to peer, et que les serveurs s’enchaînent suivant une architecture en couche (Fig.7).
Enfin, OPC UA autorise la création de Clients et Servers redondants, pour la sécurité ou la répartition de la charge de travail. Les détails de cet aspect de redondance se trouvent dans la partie 4 de la spécification.
OPC UA définit les standards de Services (opération que le Client peut appeler dans un Server) que le Server doit fournir, et les Servers individuels spécifient aux Clients quels Services ils doivent supporter. L’information est convoyée en utilisant des données standard ou constructeur. Les Servers définissent des modèles objets que les Clients peuvent découvrir en dynamique.
Par exemple, les Servers peuvent fournir à la fois l’accès aux données courantes et horodatées, et notifier les changements importants aux clients. « OPC UA peut être mappé selon différents modèles de protocoles de communication, et les données peuvent être encodées de différentes façons pour optimiser la transmission et l’efficacité » précise la fondation OPC. OPC UA permet la manipulation de données encodées en différents formats, notamment en structure binaire et les documents XML. Le format de cette donnée sera défini par OPC, ou par les organisations de standards. Quant au mapping concernant le transport des données, il s’effectue via TCP ou SOAP sur http. Ces mappings et ces encodages de données sont décrits dans la partie 6 de la spécification.
Migration et sécurité
OPC UA a été conçu pour permettre aux Clients/Servers OPC existants, qui utilisent la technologie Microsoft COM, de migrer vers l’architecture unifiée. Selon la fondation OPC, les données issues des Servers OPC COM (Data Access, Historical Data Access et Alarms&Events) peuvent facilement être mappées et exposées au sein du nouveau OPC UA. Chaque spécification OPC précédente définit son propre modèle d’AddressSpace et son propre jeu de Services. OPC UA unifiera ces modèles dans un unique AdressSpace intégré doublé de son unique jeu de Services.
« Les communications sont sécurisées et assurent ainsi les identités des Clients et des Servers » selon la Fondation OPC. La sécurité avec OPC UA concerne plusieurs niveaux : l’authentification des Clients/Servers, des utilisateurs, l’intégrité et la confidentialité des communications. OPC UA fournit un modèle pour la sécurité, défini dans la partie 2 de la spécification. Celui-ci comprend des mécanismes et des paramètres de sécurité standards. Les Profils de sécurité sont définis dans la partie 7 de la spécification.
Selon la Fondation OPC, l’aspect sécuritaire garantit un canal de communication sécurisé pendant toute la durée de la Session (connexion entre Client/Server) et assure l’intégrité des Messages échangés. D’un point de vue technique, quand une Session est établie, l’application du couple Client/Server négocie un canal de communication sécurisé et échange les Certificates logiciels (structure de données qui décrit les capacités d’un Client ou d’un Server) qui identifient les Clients/Servers concernés.
Ces Certificates, générés par la fondation OPC, indiquent quels Profils (jeu de fonctionnalités auquel le Server doit se conformer) l’application utilise. Les Certificates issus d’autres organisations sont aussi échangés durant l’établissement de la session. Le Server peut authentifier l’utilisateur, et autoriser la requête d’accès à ses Objects (Systèmes, Sous-sytèmes et équipements).
Encadré
Abréviations :
A&E : Alarms&Events
API : Application Programming Interface
COM : Component Object Model
DA : Data Access
DX : Data Exchange
HDA : Historical Data Access
HMI : Human-Machine Interface
MES : Manufacturing Execution System
PLC : Programmable Logic Contoller
SCADA : Supervisory Control And Data Acquisition
SOAP : Simple Object Access Protocol
UA : Unified Architecture
UML : Unified Modelling Language
WSDL : Web Services Definition Language
XML : Extensible Mark-up Language.
Encadré
Structure de OPC UA :
Cette spécification est organisée comme une spécification multi-parties, comme illustré sur la fig (carré avec les parties).
Les sept premières parties de la spécification spécifient les capacités du noyau d’OPC UA. Ces capacités définissent la structure de l’AdressSpace et des Services qui opèrent dessus. On retrouve dans les parties de huit à onze les types spécifiques d’accès qui étaient auparavant sur les spécifications OPC COM, comme Data Access (DA), Alarms&Event (A&E), et Historical Data Access (HDA).
Partie 1 : OPC UA Concepts : cette spécification décrit les concepts applicables aux Servers et Clients OPC UA.
Partie 2 : OPC UA Security Model : décrit le modèle pour sécuriser les interactions entre les Servers et Clients OPC UA.
Partie 3 : OPC UA Address Space Model : décrit le contenu et la structure du Server d’AddressSpace.
Partie 4 : OPC UA Services : spécifie les Services fournis par les Servers OPC UA.
Partie 5 : OPC UA Information Model : spécifie les types standards et leurs relations avec les Servers OPC UA.
Partie 6 : OPC UA Service Mappings : spécifie le mapping des transport et les encodage des données supportés par OPC UA.
Partie 7 : OPC UA Profiles : spécifie les Profiles qui sont disponibles pour les Clients et Server OPC.
Partie 8 : OPC UA Data Access : spécifie l’utilisation de OPC UA pour l’accès aux données.
Partie 9 : OPC UA Alarms and Conditions : spécifie l’usage du support d’OPC UA pour l’accès à Alarms et condition.
Partie 10 : OPC UA Programs : spécifie le support pour l’accès aux Programs.
Partie 11 : OPC UA Historical Access : spécifie l’utilisation de OPC UA pour l’accès à l’historique. Cet accès inclut à la fois les données et les Events.
