OPC UA brise la hiérarchie

En créant les blocs de fonctions client OPC UA, PLCopen et OPC Foundation brisent la hiérarchie classique dans les systèmes d’automatisation. Si jadis la communication devait toujours être initiée par un système hiérarchiquement supérieur dans la structure pyramidale, les contrôleurs peuvent désormais prendre l’initiative et mettre en place une communication. Et dès lors, un PLC peut par exemple très bien demander une recette dans un système MEC.

OPC est un standard très utilisé dans les systèmes d’automatisation pour échanger des données entre les contrôleurs, les systèmes de visualisation et le logiciel MES. Il peut s’agir de valeurs de processus en temps réel mais aussi de réglages, d’alarmes et de données historiques. OPC était initialement prévu pour OLE pour Process Control mais la signification de l’acronyme a été modifiée il y a quelques années par OPC Foundation en Open Platform Communications.

L’appellation initiale faisait allusion à la technologie mise en œuvre, lors du développement du standard fin des années ’90, pour la communication, à savoir Object Linking and Embedding, une technologie qui, à son tour, faisait usage du Distributed Component Object Model de Microsoft. Cela revenait au fait que les données étaient empaquetées dans les objets qui étaient proposés par un serveur OPC (une partie d’une PLC) et pouvaient être demandés par un client (un système de visualisation ou un logiciel MES).

Depuis, ce modèle a été remplacé par OPC UA, OPC signifiant Open Platform Communication et UA, Unified Architecture. Le nouveau standard repose sur l’architecture orientée services qui, à l’instar d’OLE jadis, est issu du monde IT.

Le réemploi de codes

Le point de départ de cette architecture orientée services est le principe selon lequel les programmeurs réutilisent des morceaux de codes au moyen de fonctions et de procédures. Une fonction est un morceau de code qui, lors d’une sollicitation, reçoit un input donné et fournit, en fonction de cela, un résultat donné.

Dans une architecture orientée services, ce principe est étendu et l’utilisation d’une fonction n’est plus limitée à un seul système mais plusieurs systèmes peuvent utiliser une même fonction.

Voici un exemple concret : lorsque vous consultez la carte météo sur le site web de votre journal, cette carte ne provient pas du journal. Le serveur du site web du journal demande, à ce moment-là, cette carte à un autre serveur appartenant à une entreprise proposant de telles cartes comme service. Le journal transmet éventuellement, lors de la demande, votre localisation au prestataire de services pour que la carte puisse être centrée sur cette localisation.

Plus de fonctions avancées

Le mode de réflexion d’une architecture orientée services a depuis trouvé son chemin vers le monde de l’automatisation. Les applications potentielles sont légion. Pensez à la demande d’une recette pour un produit spécifique, à la transmission d’un programme pour une machine CNC ou à la demande de spécifications client à un système ERP.

OPC UA est un standard qui rend possible l’application de ce concept. OPC UA se charge non seulement de la transmission des données mais aussi de la gestion des métadonnées, de l’autorisation, etc.

L’application pratique est fortement analogue à la manière de travailler avec le concept OPC original basé sur OLE, à savoir qu’un contrôleur, de quelque plateforme que ce soit, reçoit un serveur OPC, lequel propose ses données comme des services à des systèmes hiérarchiquement supérieurs comme les logiciels MES et ERP.

Une différence par rapport à avant, c’est qu’OPC UA n’est plus lié au système d’exploitation Windows de Microsoft et qu’il y a plus de fonctions avancées pour la communication de données dans le standard, comme la possibilité de faire un tampon avec les données et de les renvoyer si nécessaire, ainsi qu’une sécurité dans la communication.

OPC UA client

Une organisation qui a embrassé OPC UA dès la première publication du standard en 2006 est PLCopen, un lien ayant été créé entre le modèle d’information et le serveur OPC UA. Celui qui développe une application dans le langage de programmation standardisé peut aussi définir les services qui offriront cette application au monde extérieur.

Une fois que l’application est compilée pour un contrôleur donné, le serveur OPC UA de ce contrôleur peut utiliser les données de l’application et les proposer de manière totalement transparente à d’autres systèmes. De nombreuses autres organisations proposent depuis la possibilité d’intégrer un serveur OPC UA.

L’étape suivante dans la collaboration entre PLCopen et OPC Foundation fut le développement d’un client OPC UA. Ce qui a été finalisé plus tôt dans l’année avec la publication des spécifications pour les blocs de fonctions PLCopen permettant à un contrôleur d’agir non seulement comme un serveur mais aussi comme un client.

Il s’agit là d’une étape révolutionnaire car une machine peut désormais non seulement proposer ses données comme des services, mais elle peut aussi faire appel à des services qui sont proposés ailleurs.

Les systèmes cyber-physiques

Dès lors, certains exemples cités précédemment peuvent être réalisés avec OPC UA. Un contrôleur pourrait par exemple demander une recette dans le système MES. Une machine d’usinage pourrait choisir un programme CNC après la lecture d’un tag sur un produit.

Dans le passé, de telles applications étaient toujours réalisées via un système hiérarchiquement supérieur qui contrôlait la machine et son environnement et qui envoyait les données vers la machine. Désormais, le contrôleur d’une machine peut prendre cette initiative.

Tout ceci offre de nouvelles possibilités dans le développement des systèmes cyber-physiques – les machines et autres systèmes qui communiquent entre eux, sans système supérieur de coordination. Il y a aussi des possibilités pour utiliser pleinement le cloud, un contrôleur pouvant faire usage de services (cloud services) proposés par des partenaires externes, un peu comme le site web du journal qui va chercher ses cartes météo ailleurs. Le standard OPC UA garantit une communication sûre et correcte, avec une certaine qualité de service (Quality of service, QoS) qui doit permettre de réaliser aussi des applications en temps réel.

© Productivity.be, 10/12/2014, Texte: Erwin Vanvuchelen


Feel free to share

Productivity.be Update Alerts

Voulez-vous régulièrement recevoir les alertes de mise à jour sur les derniers articles et aperçus de produits?


Productivity.be

is een publicatie van
Redactiebureau ConScript

Contact

Erwin Vanvuchelen
+32 (0)475 64 99 34
erwin@conscript.be
erwinvanvuchelen