SUPERVISION ET AUTOMATISMES OPC UA convient désormais à toutes les plates-formes Les dernières spécifications d OPC UA (Unified Architecture) sont sur le point d être validées. Avec cette nouvelle version, la fondation OPC révolutionne son standard de communication entre équipements industriels. OPC UA rompt les liens qui le rendaient indissociable de Windows, pour se déployer sur tous types de platesformes. Il conserve les fonctions des versions antérieures, avec lesquelles il est entièrement compatible. Enfin, il se base sur les Web Services, qui autorisent la création d applications multisite et renforcent la sécurité des communications. L essentiel OPC (OLE for Process Control) est un standard d échange et de mise à disposition de données entre équipements. OPC UA concentre en une seule spécification tous les modules OPC précédents (Data Access, Alarm & Events, Historical Data Access, etc.). Grâce aux technologies Web Services, OPC UA s applique à des réseaux distants. OPC UA devient multiplateforme : il sera désormais possible d implémenter des serveurs OPC directement sur les automates. La compatibilité avec les anciennes applications est totale. Vingt et un millions d installations dans le monde, et plus de 22000 produits certifiés OPC sont disponibles (clients, serveurs, mais aussi interfaces homme-machine et supervision). En près de vingt années d existence, le standard OPC est devenu incontournable pour les applications d automatismes, d instrumentation et de supervision dans l industrie. Quelles sont les clefs du succès de ce système d interfaces basé sur des relations clientserveur? Pour Michel Condemine, directeur de 4CE Industry et représentant en France d OPC Foundation, «OPC est pensé par et pour des industriels. Les avantages d un passage à OPC sont nombreux, mais ce protocole de communication assure surtout la pérennité des installations. En effet, la refonte complète d un système automatisé coûte très cher». Au coût du matériel, il faut ajouter le temps de réécriture des programmes. Or les concepteurs doivent composer avec des documentations souvent incomplètes, voire inexistantes, et La genèse d OPC doivent également prendre en compte l évolution des technologies. Avec OPC, on ne touche pas à l application existante. Le serveur OPC, chargé de mettre à disposition les données de production aux autres équipements et applications, s installe par-dessus l application originale. Pour les éditeurs de logiciels, il n y a plus qu une seule interface à développer. Peu importe la marque et le modèle de l équipement sur lequel l application va chercher ses données, il suffit que leur logiciel soit certifié client OPC. «Pour les fabricants de matériel d automatismes, il s agit d un bon moyen de délimiter les responsabilités», poursuit Michel Condemine. OPC DA face à ses limites Malgré ses attraits, OPC (ou OLE for Process Control) et sa spécification principale OPC DA (pour Data Access) se devaient d évoluer pour suivre les progrès technologiques et s adap- Le standard OPC est apparu au milieu des années 90 pour faciliter les échanges entre le monde des automatismes et celui de la supervision basée sur PC. Petit rappel : avant que PC et automates ne se généralisent dans l industrie, la solution traditionnelle consistait à utiliser un système numérique de contrôle commande (SNCC), performant, mais onéreux et délicat à faire évoluer. Au milieu des années 80, les PC deviennent suffisamment performants pour prendre en charge des applications de supervision. Des sociétés sont apparues pour proposer des superviseurs, sous Dos et OS2 essentiellement. Il s agissait d éditeurs tels qu ARC informatique, Citect, Wiscon, Intouch ou encore WinCC. Leurs logiciels, configurables, prenaient en charge l acquisition des données et l édition de rapports, en passant par la mise en forme et l archivage. Mais ces outils ne résolvaient pas le problème de la remontée d information. Afin que les automates communiquent avec le PC, les fabricants de matériels d automatismes développaient autant de drivers que d équipements. Les éditeurs de logiciels de supervision réécrivaient eux aussi tous les drivers à chaque nouvelle installation. Un capteur qui changeait de version, et c est toute l application qui risquait de planter. C est dans ce contexte que la fondation OPC est née. Le but : s affranchir des contraintes du développement des drivers en imaginant un concept d abstraction des protocoles de communication. Pour simplifier, prenons l exemple des drivers d imprimantes, qui sont aujourd hui inclus dans le système d exploitation. Grâce à des drivers génériques, il n est plus nécessaire au système d exploitation de connaître le modèle exact d imprimante connectée. Les relations clients-serveurs avec OPC reprennent le même concept. Pour poser les bases d OPC, les membres de la fondation se sont inspirés des travaux du groupe de spécification Corba, puis des travaux d Al Chimson (fondateur de la société Intellution), qui le premier eut l idée du contrat pour définir les échanges d objets entre un client et un serveur pour les marchés du process industriel. D où la dénomination OPC : Object Linking and Embedding for Process Control. 64
Iberdrola L une des plus vastes applications de supervision basées sur OPC a été effectuée par ARC Informatique pour Iberdrola, société de distribution électrique espagnole. Elle concerne la gestion de 200 parcs éoliens (soit plus de 10 000 éoliennes) et représente environ 2,5 millions de variables (dont 2 millions sont utilisées pour le moment). ter aux réalités du terrain. La définition des communications et des interactions entre les objets n est pas restée figée depuis la création du standard. Elle a subi des modifications. Au début des années 90, il a fallu passer de la technologie OLE (Object Linking and Embedding, inauguré avec Windows 3.0) à la technologie COM (Component Object Model, le concept de composant logiciel de Microsoft). Puis il a fallu offrir une réponse aux architectures distribuées qui devenaient de plus en plus systématiques dans l industrie. C était les débuts de la technologie DCOM (Distributed Component Object Model), lancée en 1996. Il s agissait d une évolution de COM pour les applications réparties, mais toujours sur un réseau local. Mais aujourd hui, quatorze ans après la création des premiers composants logiciels, DCOM atteint ses limites dans l industrie. La technologie DCOM était, il est vrai, plus adaptée aux applications grand public qu à celles liées au monde du process. Son principal défaut tient dans un timeout trop long et non configurable. Il s agit du laps de temps au bout duquel une application qui ne répond pas est considérée comme plantée. Avec DCOM, ce compteur était fixé de manière native à 20 secondes. Difficilement applicable à un process industriel critique, pour lequel le timeout devrait plutôt être de l ordre de 200 millisecondes. Autre point noir, la technologie DCOM n autorise pas le franchissement des firewalls, car elle n est pas compatible avec le concept d allocation dynamique de ports (une nouvelle adresse IP est allouée à chaque connexion). C est pourquoi OPC était réservé jusqu alors aux seuls réseaux locaux. Il était bien sûr possible de réaliser des passerelles d accès distant (des sociétés telles que Matrikon proposent ce type de produits, appelés outils de tunnelling ). Toutefois, cela impose de rajouter des couches de communication supplémentaires, et de disposer de la même brique logicielle propriétaire d un bout à l autre de la ligne. «Aujourd hui, il est impératif qu une application puisse traverser les firewalls de l entreprise, commente Michel Condemine, d autant plus que les usines multisite sont de plus en plus nombreuses. Les industriels ont besoin de pouvoir surveiller des productions partout dans le monde. Or la réponse existe : il s agit des Web Services.» De nombreuses applications migrent vers un fonctionnement entièrement basé sur les Web Services, plus récents et plus performants. La tendance est à la création de 65
SOA (Service Oriented Architectures). Dans ce contexte, OPC DA devait donc être remanié. Le nouveau standard OPC UA (Unified Architecture) devait tenir compte de ces évolutions. La fondation OPC avait identifié le potentiel des Web Services, et a conçu les spécifications OPC XML-DA pour partager des données à travers des réseaux distants. Cependant, XML-DA n a été perçu que comme un embryon de réponse. Les communications client-serveur basées sur le protocole http étant relativement lourdes, ses performances étaient insuffisantes. «Il fallait concevoir un protocole plus compact, indique Michel Condemine, un protocole qui fonctionne avec les mêmes performances sur Internet qu à travers un bus CAN.» XML-DA ne permettait pas non plus de créer des fonctions événementielles (une application qui démarre seule, lorsqu une donnée OPC atteint une certaine valeur), et il n y avait ni archivage ni alarme. C est pourquoi la fondation OPC a souhaité lancer un standard plus homogène et plus ambitieux. Une solution de supervision estampillée UA Parmi les sociétés proposant des outils OPC en France, on peut citer 4CE Industry, Resolucom ou Kepware. Kepware a d ailleurs récemment annoncé un partenariat avec la société Iconics, spécialisée dans les solutions de visualisation et de supervision. L objet de ce partenariat est la mise sur le marché de la première solution de supervision entièrement basée sur OPC UA. Cette offre, appelée OPC-UA for KEPServer associera tous les clients, serveurs et drivers compatibles OPC UA développés par Kepware aux logiciels de supervision et de création d IHM proposés par Iconics. Outre la simplicité d installation, cette solution exploite au maximum les capacités des objets étendus Web Services : elle intègre un outil de visualisation du réseau, ou maillage ( mesh ). Il est possible d afficher tous les clients et serveurs d une application, même si elle s étend sur plusieurs sites géographiques, d afficher tous les tags disponibles dans un serveur ou encore de visualiser tous les liens déjà établis entre clients et serveurs. Une avancée non négligeable, dans la mesure où la configuration d un système client-serveur OPC avec les outils classiques pouvait rebuter le profane (outils souvent austères et peu conviviaux). Ajoutons que, grâce à l adoption par OPC Foundation des dernières technologies W3C, les spécifications du standard OPC UA sont compatibles avec Windows Vista et avec les processeurs 64 bits, ce qui garantit des performances de premier ordre aux applications de visualisation. Les dessous des relations client-serveur Dans une relation client-serveur, le serveur est une machine hébergeant une application logicielle qui offre des services à un ou plusieurs clients. Le client est le logiciel ou la machine qui exploite ces services. Dans le cas d un système de supervision, par exemple, le logiciel de supervision joue le plus souvent le rôle de client et récolte des données en provenance de serveurs qui sont installées sur les différentes machines ou îlots de production. Ce client stocke les données, les met en forme, effectue les calculs et se charge de l affichage. Un serveur OPC fournit un certain nombre de services selon les modules qui sont installés (version OPC DA, ou COM), ou selon le profil de serveur choisi (version OPC UA) : de la simple mise à disposition de données à des services d exploration de données, d alarmes ou encore d abonnements. Le serveur ne travaille que sur demande (on parle de requête ). Lorsqu aucun client n est abonné ou n effectue de requête, le serveur OPC est inactif. Il est en attente. Au démarrage, le client OPC déclare à un serveur les données qui l intéressent et auxquelles il veut avoir accès. Cela peut Elle en a profité pour repenser le principe de propagation des données dans l entreprise. OPC ne devait pas rester cantonné au monde des automatismes. Il fallait que ce standard s applique aux systèmes de gestion de l entreprise (ERP), au MES (Manufacturing Execution System) et aux fonctions de gestion des actifs (Asset Management). Un fonctionnement transparent Le groupe de travail chargé de la définition d OPC UA (Unified Architecture) a été créé en 2003. Il est constitué des membres les plus actifs au sein du consortium, parmi lesquels se trouvent les sociétés SAP, Microsoft, Iconics, Kepware, Siemens, Rockwell, ABB, Honeywell, Wonderware, Areal ou encore Sisco. Leur projet : rien moins que de «créer un standard révolutionnaire, déclare Michel Condemine. Auparavant, pour OPC DA, il s agissait de concevoir une méthode de récolte, de mise à disposition et de mise en forme des données. Le principal but était de pouvoir rajouter une couche OPC sur n importe quelle application sans avoir à la modifier. Aujourd hui, avec OPC UA, nous voulons agréger toutes les spécifications définies depuis plus de vingt ans au sein d une être une demande ponctuelle ou un abonnement (ce qui signifie que le client demande à recevoir une valeur à intervalles réguliers, mais il peut aussi demander à n être averti que lorsque cette valeur change). Un serveur OPC est créé à partir du langage de programmation C++. Les industriels qui disposent d équipes de programmeurs peuvent les réaliser en partant uniquement des spécifications. Mais des toolkits sont proposés par des sociétés spécialisées dans les interfaces de communication Pour l application OPC cliente, plusieurs langages disponibles : il est possible d écrire un client OPC en C++, mais aussi avec la spécification Automation du langage VBA (Visual Basic for Applications) pour laquelle un adaptateur est disponible auprès de la fondation OPC, ou encore avec la technologie.net. Dans ce dernier cas, une couche de communication supplémentaire devra être rajoutée s il s agit des versions antérieures à OPC UA. Enfin, comme pour les serveurs OPC, de nombreux clients OPC sont disponibles sur le marché sous la forme de toolkits qui facilitent et accélèrent l installation. architecture unique. D où l importance de la signification du U de Unified.» Pour intégrer tous les modules OPC en un seul protocole commun, il a fallu revoir complètement le concept des communications OPC. Pour ce faire, les membres de la fondation se sont appuyés sur trois grands principes. Pour commencer, il fallait en finir avec DCOM pour passer à un fonctionnement entièrement SOA, plus performant et plus facile à migrer sur des plates-formes différentes. Cela devenait d autant plus primordial que Microsoft s est aujourd hui désengagé des technologies COM et DCOM, au profit des Web Services. C est donc l essence même d OPC qui a été modifiée : pour s adapter à ce nouveau concept de Web Services, OPC est passé d un modèle de présentation de données à un modèle d actions sur des objets. Un grand nombre de fonctions qui avaient été écrites jusqu à présent ont bien sûr été conservées, mais le principe a été recentré autour des quatre services de base d OPC : émettre une requête, lire une valeur, écrire une valeur ou s abonner à une variable 66
Afin de faciliter l implémentation de serveurs OPC UA directement à l intérieur des automates, le standard OPC UA intégrera bientôt un modèle de programmation compatible avec la norme IEC 61131-3. Cette initiative commune aux organisations OPC Foundation et PLCopen permettra aux constructeurs d automates programmables de réduire les coûts de développement de leurs serveurs OPC UA. (pour connaître son évolution en temps réel). Jusqu alors, OPC (communément appelé OPC COM) se composait d un ensemble d instructions et de fonctions dissociées les unes des autres et proposées dans des modules différents. Désormais, les quatre services de base sont indépendants, et traversent toutes les précédentes spécifications. Assurer une installation Plug & Play Par ailleurs, le consortium s est appliqué à ce qu OPC UA soit intégralement Plug & Play. Ses membres souhaitaient que le format d échange de données fonctionne indépen- Amener de l interopérabilité dans des architectures hétérogènes. damment de la plate-forme sur laquelle l application est installée : depuis les systèmes embarqués jusqu aux serveurs d entreprise, en passant par les PC d ateliers et les interfaces homme-machine (IHM). Leur travail a concerné le portage des données d un logiciel à un autre (système automatisé, ERP, Asset Management et MES), mais aussi d un système d exploitation à un autre. «Ce qui constitue une véritable révolution, assure Benoît Lepeuple, chef de produits chez ARC Informatique. OPC va pouvoir s étendre à l atelier. Auparavant, seuls des PC sous Windows pouvaient devenir des serveurs OPC, puisque ces derniers étaient écrits avec la technologie objet COM, spécifique à Microsoft.» En effet, pour connecter un automate à un serveur OPC, il fallait interfacer l automate à un PC sous Windows via un bus de terrain. Le serveur OPC était installé sur le PC. Cela compliquait fortement les installations. Avec une architecture OPC UA, clients et serveurs pourront être installés indifféremment sur des systèmes d exploitation Windows IHM, MES, ERP OPC classique (DCOM) IHM, MES, ERP OPC UA embarqué Serveur OPC Automate Protocoles propriétaires Contrôle commande Entrées/ Sorties Serveur OPC UA Automate Contrôle commande Entrées/ Sorties Le schéma ci-dessus illustre l avancée non négligeable apportée par OPC UA. Sur une architecture OPC DA (à gauche), il est nécessaire d installer des PC sous Windows pour faire la liaison entre les automates et les systèmes de gestion d entreprise. Avec OPC UA (à droite), les serveurs OPC programmés en C++ sont implémentés directement à l intérieur des automates et systèmes de contrôle commande. 67
OPC UA fait des nœuds avec les objets Si les spécifications d OPC étaient basées sur les travaux des groupes Corba et Oasis, l élaboration d OPC UA a essentiellement fait appel aux travaux du consortium W3C et de l organisation Mimosa. Les sociétés membres de Mimosa, groupement présidé par Alan Johnston (également directeur de la société Assetricity), travaillent depuis plusieurs années sur un standard de mise en forme des informations. Quant au W3C, il a fourni les définitions des Web Services, aujourd hui largement répandus dans le monde de l informatique bureautique et professionnelle. OPC UA est donc un nouveau modèle d organisation et de description des objets. On y trouve des objets de base appelés Nodes (nœuds). Ce sont des objets au sens de la norme ISO 88, dans le sens où l on se servira d instances de ces objets de base pour décrire l ensemble de l application. Un Node est caractérisé par un certain nombre d attributs. Et ces attributs peuvent être des propriétés, des méthodes ou des références. Pour illustrer ces concepts, on peut prendre l exemple d une roue. Une roue peut être caractérisée par un diamètre et une vitesse angulaire : ce sont ses propriétés. En revanche, si l on parle de méthode, on déterminera si la roue est en mouvement ou à l arrêt. Les références, enfin, représentent les liens qui existent entre la roue et son bâti. Ce sont les liens entre différents Nodes. Car contrairement à OPC DA, qui considérait les objets COM sous forme d arborescence, OPC UA utilise des objets reliés par un maillage ( mesh ). Auparavant, il était impossible pour un client d avoir accès à un autre serveur relié à un autre client. Les informations ne pouvaient pas remonter l arborescence. Prenons l exemple d une application consistant à surveiller une cuve : imaginons que le serveur remontant l information du capteur alerte niveau bas soit relié à un client dédié à la gestion des alarmes, et que le serveur remontant l information du capteur niveau de la cuve soit relié à un client qui concentre les valeurs de niveaux de toutes les cuves. Avec OPC DA, il était impossible pour l opérateur surveillant les alarmes d accéder au niveau réel de la cuve lorsque l alarme se déclenche. Dans le cas d OPC UA, un Node correspondra à la cuve dans sa globalité. Ainsi, en se connectant au serveur lié à la cuve l opérateur sera capable d accéder à toutes les informations la concernant. Grâce aux possibilités offertes par ce maillage entre objets, il pourra même piloter des actionneurs, pour commander des vannes par exemple. Différences entre OPC DA et UA illustrées par l exemple d une vanne. On passe d un système à arborescence à un système maillé, interconnecté. classiques, mais aussi des OS libres (comme Linux), pour terminaux portables (comme Windows CE) ou même temps réel (comme VxWorks). Grâce à cette portabilité, des serveurs OPC seront implémentés directement dans les automates, et des systèmes complets clients-serveurs OPC dialogueront sans se préoccuper du matériel sur lequel ils sont déployés. Trois versions différentes d architectures OPC UA sont proposées. Elles fournissent les mêmes fonctions (ou services) mais seul leur code de base diffère. Elles reposent sur les mêmes couches d abstraction, mais se programment sous C/C++, avec Microsoft. NET ou en langage Java selon le type de plate-forme sur laquelle elles sont installées. La version. NET sera préférée pour des applications sous Windows, celle en Java visera une utilisation sur des appareils portables et la version C/C++ (qui présente l empreinte mémoire la plus faible) sera destinée aux systèmes embarqués. L organisation des couches de communication d OPC UA montre que les anciennes spécifications d OPC (Data Access, Alarms and Conditions, etc.) sont situées au-dessus des couches de base d OPC UA. Cela garantit la compatibilité d UA avec les applications OPC DA. Une application des années 90 qui fonctionne toujours en 2010 Le consortium OPC a tenu à assurer une totale compatibilité ascendante des applications. «L abstraction des couches de communication a été obtenue grâce à une collaboration avec les organisations ISA et IEC, indique Thomas Burke, président de OPC Foundation. Avec Unified Architecture, OPC est devenu un moyen de transport unique pour toutes les données, qu elles viennent de n importe quel équipement ou application, et sur n importe quel réseau de l entreprise.» Bien entendu, une couche d abstraction supplémentaire sera toujours nécessaire pour exécuter OPC DA (ou OPC XML-DA) dans une application UA. Mais l application n aura à subir aucune modification. Les applications DA et UA peuvent cohabiter au sein d une même architecture. Un client COM (OPC DA) peut recevoir des données provenant d un serveur UA, et un serveur COM peut envoyer des données à un client UA. Sécurité et fiabilité «Nous voulions aussi proposer de nouvelles fonctions aux utilisateurs, observe Michel Condemine, qui participe activement aux travaux de la fondation OPC. Nous souhaitions apporter de la sécurité au transfert d informations distantes qui pouvait poser des problèmes avec les technologies 68
COM/DCOM. Notre collaboration avec les équipes du W3C (World Wide Web Consortium) nous a simplifié la tâche.» En effet, la technologie Web Services intègre la sécurité de manière native. Les fonctions WS Secure Conversation, WS Trust et WS Security, notamment, ont été reprises par la fondation pour écrire les spécifications d OPC UA. Cette technologie robuste et éprouvée est déjà à la base de la plupart des applications multisite actuelles. Enfin, OPC UA améliore la disponibilité des applications en intégrant des fonctions de redondance et de répartition de charge. La première permet de déclarer certains clients ou serveurs comme étant des ressources de secours, qui ne démarrent que lorsque le client ou le serveur principal ne répond plus (ou tombe en panne). La seconde permet à des clients d activer ces serveurs de secours lorsque les serveurs principaux sont trop sollicités et n arrivent pas à satisfaire toutes les requêtes. Les abonnements sont transférés automatiquement, et de manière transparente. Pour conclure, aux nouvelles fonctionnalités de OPC UA s ajoutent donc la compatibilité avec les anciennes applications OPC, l installation Plug & Play sur différentes plates-formes et l utilisation d un langage objet moderne. Et selon Michel Condemine, l une des forces d OPC «réside dans le fait que ses spécifications sont ouvertes et libres de droits». Tout le monde peut développer son propre système client-serveur OPC en DA ou en UA. Toutefois, en temps que fournisseur de solutions OPC, il préfère promouvoir l emploi de solutions commerciales telles que des toolkits (drivers de communication préparamétrés), qui facilitent la programmation. «Nous proposons également les wrappers COM vers UA, qui assurent la compatibilité des applications OPC COM au sein d un nouveau système UA», indique Michel Condemine. L offre devient mature Mais la disponibilité de produits OPC UA ne signifie pas que le marché est prêt à les adopter sans attendre. D une part parce que des spécifications sont encore en cours de validation. D autre part parce qu il faut toujours du temps pour que les industriels transforment leur intérêt pour une technologie en un projet concret à court terme. «Toutefois, la certification OPC UA commence à être un critère pour le choix d un superviseur, note Benoît Lepeuple. Même s ils ne sont pas forcément prêts à franchir le cap, ils sentent que ce standard va s imposer et choisissent leur fournisseur en fonction de son implication dans OPC UA. Les utilisateurs sont rassurés par les aspects de compatibilité ascendante. Quant à nous, éditeurs de logiciels, nous sommes assurés de pouvoir migrer facilement des applications de OPC COM vers UA, dès que les clients seront demandeurs.» Enfin, selon Russel Agrusa, p.-d.g. et fondateur de la société Iconics, «les analystes d ARC Advisory Group et d AMR Research prévoient qu OPC UA sera omniprésent d ici quelques années. Grâce aux différentes versions du code de base, tous les équipements (systèmes embarqués, automates, entrées/sorties et équipements réseau) peuvent désormais communiquer via OPC UA. Aussi peut-on s attendre à une baisse des coûts d intégration et de possession de ces matériels». Frédéric Parisot Pour en savoir plus www.opcfoundation.org 69