SOMMAIRE

1. INTRODUCTION
2. CANopen
3. etc…

1. INTRODUCTION

Durant ce projet, nous allons devoir compléter l’architecture d’un serveur OPC DA. Ce serveur OPC existant déjà, nous allons y ajouter des équipements CANopen que nous allons pouvoir superviser à distance. Pour cela, nous avons différentes tâches à effectuer pour pouvoir finaliser le projet.
Tout d’abord, il faut savoir que nous allons utiliser le logiciel Automation Studio qui est un logiciel de conception de circuits, de simulation et de documentation de projets. Nous utiliserons également le logiciel InTouch nous permettant de faire de la supervision industrielle et de commander notre système à distance.

2. CANopen

Le protocole CAN, initialement créé pour le marché de l’automobile, est un Bus qui priorise les messages sans altérer ou détruire la requête. Il intègre la 2ème couche du modèle OSI alors que la plupart des protocoles se limitent à la 1ère couche.
Ensuite, nous allons mettre en place le module CANopen sur notre système et le paramètrer. CANopen permet de garder un profil standard dans les systèmes de contrôle industriel. Il convient aux automates en temps réel car c’est une solution efficace destinée aux applications industrielles.
Sur ce module, nous allons y brancher quatre équipements de différents fabricants. Nous commencerons donc par un équipement d’un fabricant en le paramétrant pour le tester grâce au server OPC puis en y ajoutant une supervision. Nous répéterons cette opération avec 4 equipements (Entrée/Sortie) de 4 fabricants différents et un dernier équipement qui sera un variateur.

Introduction

Notre projet consistait en la gestion de tout les équipements de la salle contrôlable en Modbus. Dans le cadre des études et réalisations des semestres 3 et 4, nous avons eu l’occasion de développer une application de test et de contrôle de l’ensemble des équipements présents dans la salle B018 (salle de Réseaux), par le biais du protocole Modbus/TCP avec une visualisation VNC. Pour mener à bien ce projet nous avons eu recours au logiciel Automation Studio qui nous a permis d’effectuer les différents essais et applications.

Comme le montre ce schéma, on va se servir d’une interface qui apparaîtra sur le PC, cependant tout le programme sera exécuté dans l’automate à l’adresse 200.200.200.175 qui, lui, contrôlera les équipements et nous permettra d’avoir une visualisation sous VNC (l’automate est serveur VNC, le PC, lui, est client VNC). La liste des équipements est la suivante, accompagnés de leur adresse IP dans la salle.

Intitulé :	Modules :	@IP :
Colonne Lumineuse	MOXA	.252 :2
Lampes Fluocompactes	WAGO	.215
Portique 206	WAGO	.214/.219
RECDIGIT	WAGO	.210 :6
JANITZA	JANITZA	.251
WAGO 352	WAGO	.179/.189/.199
BC0087	B&R	.243/.244/.245
CIE-H10	SOLLAE	.240
WAGO 841	WAGO	.216/.217/.218
WAGO 315	WAGO	.210 :9
CPU	CP3586	.176

Fonctionnement Modbus

Généralités

Le Client, par l’intermédiaire d’une trame requête, va envoyer des informations aux serveurs, dans notre cas, nos équipements. Les serveurs, à leur tour, vont répondre par le biais d’une trame réponse pour envoyer les informations demandées ou les actions demandées.

Avec Automation Studio, pour gérer la communication Modbus, nous allons créer les équipements et leurs attribuer une adresse IP. Au niveau de la configuration, nous allons créer des blocs qui seront composés d’un ou plusieurs « channels ». Ainsi, ces « channels » apparaîtront dans la gestion des entrées et sorties et auront donc une variable associée.

Modes de fonctionnement

Les échanges entre l’automate Client et les équipements serveur peuvent se faire de plusieurs façon, suivant le mode sélectionné lors de la configuration. Cyclique, Non-Cyclique ou bien Send Once.

Mode cyclique :

En mode cyclique, la communication est toujours active et va renvoyer constamment la valeur. On peut ici voir lorsque la valeur est a 1 on envoie 1.

Mode non-cyclique :

En mode non-cyclique, il y aura une valeur (ici, le bouton) qui va décider d’activer ou non la communication. Lorsqu’elle est active, elle fonctionne comme en mode cyclique. Lorsqu’elle est désactivée, la communication s’arrête et la valeur va se figer. La LED va donc rester allumer jusqu’à l’ordre d’arrêt.

Mode Send Once :

En mode « SendOnce », grâce au petit bout de programme (ci-dessus), nous n’occuperons la communication que lors de l’envoi (ou de la réception). En effet, quand « SendOnce » passe à 1, nous envoyons nos valeurs. Dans notre cas, vu qu’on veut envoyer la valeur de notre bouton, nous allons attendre un front sur celui-ci. Quand un front sera détecté, nous allons faire passer « SendOnce » à 1, ce qui permettra d’envoyer la valeur que le bouton aura pris. « SendOnce » ne repassera pas à 0 automatiquement, c’est pourquoi, on attend l’acquittement, qui passe à 1 seulement si les valeurs sont bien reçues par l’équipement. Une fois l’acquittement reçu, on remettra « SendOnce » à 0. Quant à l’acquittement, il repassera automatiquement à 0.

Visualisation

Nous pouvons voir ci-dessus, le menu général de notre tableau de bord. Un simple clic sur n’importe quel équipement vous amènera à une page détaillée. Nous avons disposé des témoins lumineux sur chaque équipement afin de vérifier l’état de celui-ci, repérés par leur adresse IP. Nous avons aussi regroupé les appareils similaires entre eux par souci d’ergonomie.

Par exemple lorsqu’on cliquera sur « Colonne Led » on aura la page ci-dessous (à gauche) qui permet de contrôler les trois lumières, une lumière par bouton. Et si l’on clique sur « Wago 841 » on aura la page ci-dessous (à droite) qui permet de contrôler 3 Wago différent et donc de contrôler leur sorties ainsi que de visualiser leurs entrées.

Module Janitza

Le module Janitza est un appareil de mesures intégré dans le réseau électrique de la salle de classe. Il est capable de mesurer des dizaines de grandeurs physiques. Nous l’avons configuré pour en transmettre 22 sur notre visualisation. Celle-ci affiche ces grandeurs selon deux modes de fonctionnement :

Le mode de visualisation en « temps réel », où l’évolution sur les graphiques se fait en continu par rapport aux mesures. Cela est réalisé grâce à la lecture des ports du Janitza associé à chaque grandeur physique.

Le mode de visualisation « historique », où les graphiques sont figés, représentant une évolution ayant eu lieu dans le passé. Ce mode de visualisation est plus pratique pour étudier ces mesures, et est permis grâce à la lecture d’un tableau préalablement rempli et donc les valeurs ont été stockées sans avoir été écrasées.

Nous avons configuré cet appareil de telle sorte à ce qu’il puisse nous communiquer :
La fréquence du réseau
Les intensités des courants sur chacune des trois phases
Les tensions entre chacune des phases et entre chacune de ces phases avec le neutre
Les puissances réelles, actives, réactives et le cos φ sur chacune des phases

Ainsi, il convenait de pouvoir visualiser toutes ces mesures grâce à notre application VNC. Voici un extrait de notre visualisation en temps réel :

Ci-dessous, vous pouvez vous apercevoir que les valeurs relevées sur les graphiques (partie de droite) correspondent, en temps réel, avec celle qu’indique le module Janitza via ses ports, chacun associés à une grandeur physique (partie de gauche – visualisation en mode monitoring du mapping du Janitza).

Ensuite, la visualisation « historique » consiste en la lecture de tables, une pour chaque grandeur physique, servant de lieu de stockage aux variables.

Ainsi, sur le graphique suivant vous pouvons observer un graphique en cours de remplissage :

Module NetIO4ALL

Un autre appareil était directement lié au module Janitza, il s’agit de la multiprise NetIO4All. Cette multiprise est commandable à distance, et permets d’appliquer des charges supplémentaires sur le réseau. Grâce à cet appareil on a pu effectuer des tests en envoyant des charges sur le réseau et en observer l’impact sur les mesures du Janitza, vérifiant que l’on pouvait observer les modifications sur nos graphiques.

Il convenait de configurer quatre commandes sur chacun des quatre Channels (les quatre prises) du module :
Une commande ON/OFF classique
Une commande ON DELAY, lançant le système pour un temps bien précis
Une commande OFF DELAY, eteignant le système pour un temps bien précis
Une commande TOGGLE, lançant le système lorsqu’il est éteint et l’éteignant lorsqu’il est en fonctionnement
De plus, pour les deux modes DELAY, nous devons pouvoir choisir le délai grâce à une fenêtre d’écriture numérique et un bouton UPDATE pour valider notre choix.

Ensuite, nous avons trois fenêtres d’affichage en temps réel pour les valeurs suivante : le courant, la puissance et l’énergie générés par la prise commandée.

Conclusion

Cette application répond maintenant au cahier des charges lié au projet. Elle permettra de rapidement voir l’état des équipements en ModbusTCP, et ainsi les nouveaux étudiant pourront rapidement voir les équipements Modbus de la salle, ainsi que ce que l’on peut faire avec ce protocole. En effet pour expliquer quelque chose comme un protocole c’est beaucoup plus agréable d’avoir un exemple, de plus il est possible d’observer les trames sous Wireshark. Cependant, pour éviter d’avoir trop de problème, l’automate n’accepte qu’un seul client VNC à la fois.

Ce projet se sera révélé très intéressant car il nous aura permis d’encore plus explorer les réseaux d’automates industriels. En effet, les TP ont été beaucoup moins poussés que le projet que nous avons fait. De plus, nous avions, lors du semestre 2, pu installer et configurer des automates. Ces deux projets, en plus des cours, nous donnent un véritable bagage pour le domaine de l’automatisme industriel.

Pour finir, nous tenons à remercier, bien évidemment, M.MERCKLE pour sa présence et, surtout, sa disponibilité nous permettant de parfois trouver des solutions à nos problèmes grâce à ses connaissances qui étaient plus étendues sur le sujet.

Synthèse du projet de pilotage synchronisé de moteurs asynchrones

Sommaire

1. Introduction
2. Cahier des charges
   1. Bête a corne
   2. Diagramme pieuvre et Tableau des fonctions
3. Étude de l’installation
   1. Ancienne installation
   2. Installation actuelle
4. Développement du pilotage synchronisé
   1. Moteur asynchrone
   2. Moteur Pas à Pas
   3. Servomoteurs
5. Conclusion
6. Annexe

1.Introduction

Dans le cadre de notre projet d’étude et réalisation, nous avons réalisé un projet permettant la commande synchronisé de deux moteurs asynchrones. Ce projet à été fait durant le Semestre 3 et 4. Nous avons eu pour objectif d’élaborer un banc d’expérimentation et de démonstration du contrôle de mouvement synchronisé basé sur deux moteurs asynchrones. Lors de ce projet nous avons 2 grandes parties qui ce sont dégagées. Nous avions une première partie sur l’étude et la réalisation de l’installation. Celle-ci consistait à étudier l’ancienne installation ayant seulement un moteur asynchrone, puis dans un second temps réaliser l’installation complète ayant deux moteurs asynchrones. La seconde partie concerne le développement des commandes pour les moteurs asynchrones. Pour cela nous avons tous d’abord étudié et développé des commandes de base sur différents types de moteurs. Puis dans un second temps nous avons développé les commandes et la visualisation des moteurs asynchrones avec leurs colonnes lumineuses.

Récapitulatif de l’ensemble de l’installation avant/après

Cahier des charges

Bête a corne

Ce projet doit permettre la synchronisation du mouvement de deux moteurs asynchrones grâce au contrôles de commandes

Diagramme pieuvre et Tableau des fonctions

FP1: Contrôle de mouvement synchronisé des moteurs : Pouvoir contrôlé la synchronisation des moteurs

FP2: Opérateurs : Permettre une utilisation facile des commande

FC1: Alimentation 230V triphasé : Alimenter l’installation en 230V triphasé

FC2: Ethernet Powerlink : Communiqué grâce à Ethernet

FC3: Normes : Respecter les normes de protection et de sécurité

FC4: Visualisation des commandes : Avoir une visualisation complète et fonctionnelle

Étude de l’installation

Ancienne installation

Dans un premier temps nous avons étudié l’ancienne installation. Cela avait pour but de comprendre le fonctionnement de l’installation ainsi que de connaître les principaux composants de celle-ci. Par la suite nous avons fait un croquis de l’installation pour avoir un schéma propre et compréhensible.

A la suite de ce schéma nous avons réalisé plusieurs autres schémas allant de la partie alimentation à la partie commande du moteur. Lors de l’étude de la partie alimentation, nous nous sommes aperçus que certains équipements étant assez anciens ont dû être changés. L’installation est alimentée par un transformateur triphasé produisant du 230V. Le moteur asynchrone est câblé en couplage triangle. Pour la partie commande, nous avons remarqué que la boitier de marche/arrêt est alimenté par une phase du 230V triphasé.

Sur le schéma ci-dessus nous avons le boitier Marche/Arrêt ainsi que son équipement de sécurité qui sont représenté. Nous pouvons voir que KM1 et KM2 permettent la connexion des différentes phases pour alimenter le variateur du moteur asynchrone. Nous pouvons voir que le contacteur permet de faire la connexion entre la partie puissance et la partie commande de l’ensemble variateur/moteur.

Installation actuelle

Après avoir étudié l’ancienne installation, nous avons conçus le schéma de la nouvelle installation. Celle-ci ressemble à l’ancienne installation avec quelques modifications.

L’installation permettra de piloter deux moteurs asynchrones avec deux variateurs. Pour cela nous avons juste à réalisé l’installation en double comme sur le schéma ci-dessus. Les boitiers de Marche/Arrêt ne seront plus alimentés par une phase du 230V triphasé mais ils seront alimentés en 24V. Pour cela nous devons intégrer un transformateur 230/24V. Celui-ci permet d’avoir 230V au primaire et 24V au secondaire. Nous avons rajouté deux disjoncteurs, le premier en amont et le second en aval du transformateur.Cela permet la protection des boitier Marche/Arrêt. Le reste de l’installation reste en 230V triphasé. Son fonctionnement reste similaire à l’ancienne installation. Les deux nouveaux ensembles variateurs/moteurs sont installés sur une même grille, pour avoir les deux ensembles côte à côte.

Développement du pilotage synchronisé

Moteur asynchrone

Nous avons commencé à étudié le pilotage du moteur asynchrone grâce à un ancien projet d’étudiants. Cela nous a permis de prendre en main le logiciel Automation Studio. Par la suite nous avons étudié les commandes existantes permettant de contrôler le moteur en créant une configuration permettant de relier la partie matérielle a la partie logicielle comme on peut le voir dans l’image suivante.

Pour pouvoir interagir avec le moteur, nous avons testé toutes les commandes étant déjà en place sur l’interface Homme-Machine. Nous pouvions par exemple démarrer,arrêter où choisir la vitesse de rotation du moteur. Par la suite nous avons améliorer le programme ainsi que l’interface. Nous avons ajouté et vérifié si toutes les variables étaient correctes et nous les avons fait apparaître sur l’interface.

Ci-dessus nous avons l’interface Homme-Machine du moteur asynchrone. Pour pouvoir démarrer le moteur nous devons suivre quelques étapes. Tous d’abord la variable « MpAxisBasic » doit être activé. Elle permet de contrôlé l’axe du moteur et à été ajouté par nos soins pour pouvoir choisir le type d’axe que nous voulons pour plus tard. Puis la variable « Power » doit être activé ainsi que la variable « Home ». La variable « Power » met le moteur en marche et la variable « Home » met le moteur en position initial. Puis nous mettons en marche la variable « Move Velocity » qui va faire tourner le moteur si une valeur est donnée. Nous avons un graphique qui trace l’évolution de la vitesse du moteur en fonction du temps. Par la suite nous avons rajouté 2 nouvelles variables une pour la décélération et une pour l’accélération. Nous pouvions donc entrer une valeur dans ces deux variables et voir que le graphique changeait selon les valeurs rentrées. Pour arrêter le moteur nous avions la variable « Stop » et si un problème survenait nous avons la variable « ErrorReset » qui permettait de remettre à zéro toutes les variables pour pouvoir redémarrer le moteur.

Moteur Pas à Pas

Après avoir étudié le moteur asynchrone, nous nous sommes intéressés aux moteurs Pas à Pas. Nous nous sommes aidés de l’interface faite précédemment pour cette partie. Dans cette partie nous devions créer et utilisé une visualisation comportant 2 couplages. Nous aurions le choix entre un couplage linéaire et un couplage CAM entre les deux moteurs. Nous avons réutilisé le programme et les blocs utilisé dans la partie précédente pour vérifier le bon fonctionnement des moteurs. Pour la suite de cette partie nous avons créer 2 blocs permettant de contrôler un moteur chacun et un troisième bloc pour gérer le couplage entre les deux moteurs.

Le premier bloc nommé « MpAxisBasic_0 » permet de contrôle l’axe d’un des deux moteurs, celui-ci servira d’axe maître. Les 3 variables les plus importantes de ce bloc sont encadrer en rouge. La première variable « gMpLinkAxe2 » permet de gérer la mise en route du moteur maître. La seconde variable « AxisPar2 » quand à elle permet de gérer les réglages du moteur (sens de rotation,vitesse de rotation…). Puis la dernière variable « gAxis03 » permet l’identification de notre axe maître par rapport à l’axe esclave. Nous avons un second bloc similaire appelé « MpAxisBasic_1 » qui permet de contrôler le second moteur.

Le second bloc nommé « MpAxisCoupling » permet de contrôlé l’axe et le couplage du moteur esclave. Nous aurons le choix entre le couplage linéaire ou le couplage CAM. Le couplage linéaire ressemble à des roues dentées de son fonctionnement donc nous choisissons la vitesse de multiplication de l’axe esclave par rapport à l’axe maître. Cette axe suis les besoins de l’axe maître mais est plus difficile à mettre en place pour un mouvement balancier. Contrairement au couplage linéaire, le couplage CAM est quand à lui beaucoup plus performant. Ce couplage permet d’utilisé n’importe qu’elle sens de manière précise et efficace. Les 3 variables les plus importantes sont aussi encadrées en rouges. La première variable « gMpLinkAxe1 » permet de gérer la mise en route du moteur esclave. La seconde variable « AxisPar3 » quand à elle permet de gérer les réglages du couplage. Puis la dernière variable « gMpLinkAxe2 » permet la représentation de l’axe maître que l’axe esclave va devoir suivre.

Après avoir crée les différents blocs nous avons introduit les nouvelles variables sur l’interface. Nous avons une partie pour activer et commander l’axe maître. Puis nous avons une seconde partie pour activer l’axe esclave. Pour finir nous avons une partie permettant de voir si les moteurs sont prêt à être couplés puis nous pouvons choisir entre les 2 couplages différents. Nous pouvons donc choisir de contrôler les moteurs de manière séparé ou de manière couplé.

Pour pouvoir démarrer les moteurs nous devons refaire les mêmes étapes énoncés dans la partie moteur asynchrone. Puis pour choisir le couplage nous avons la variable « GEAR » qui est la variable pour avoir le couplage linéaire et nous avons la variable « CAM » qui est pour la couplage CAM. Nous avons 2 entrée numériques qui sont « NUM » et « DEN » qui permettent de rentrer 2 valeurs une au numérateur et l’autre au dénominateur pour calculé un rapport de transformation. Puis pour prendre en compte les nouveaux réglages fait nous avons la variable « UPDATE ».

Servomoteurs

Nous allons étudié un dernier type de moteurs. Ces moteurs sont des servomoteurs. Un servomoteur est un système produisant un mouvement grâce à une commande externe. Pour cette partie nous allons nous aidés des blocs de la partie précédentes. Nous gardons les mêmes variables, les seuls qui changent sont les variables encadrées en rouge.

Le bloc nommé « MpAxisBasic_0 » permet de contrôlé l’axe maître. Celui-ci sera un axe virtuel contrairement à la partie précédente où nous avons un axe maître réel. La première variable nommée « gAxisBasic » permet de contrôlé les différentes commandes de l’axe. La seconde variable « AxisPar » permet de contrôlé les différents réglages concernant le moteur. Pour la dernière variable « gVAxis01 », celle-ci permet d’identifiée l’axe que nous allons contrôler. Pour cette variable nous allons utilisé l’axe virtuel. Nous avons 2 autres blocs nommé « MpAxisBasic_1 et MpAxisBasic_2 », qui sont similaire au bloc ci-dessus mais permettent de contrôler les axes réels des servomoteur 1 et servomoteur 2.

Le bloc ci-dessus nommé « MpAxisCoupling_1 » nous permet de faire le couplage entre deux axes. Nous avons la première variable « gAxisBasic_2 » cette variable représente l’axe esclave d’un des moteurs. La second variable « AxisPar4 » celle-ci permet de choisir les réglages de l’axe. La dernière variable « gAxisBasic » représente l’axe maître que va devoir suivre l’axe esclave. Nous avons un second bloc de couplage pour le second servomoteurs ayant les variables différentes mais un fonctionnement similaire.

Pour la partie visualisation nous avons réutilisé IHM de la partie précédente que nous avons amélioré et ajouté les différentes variables nécessaires.

Nous avons ajouté une partie maître pour nous permettre d’allumer et de contrôler l’axe virtuel. Le reste des variables restent les mêmes et les étapes pour allumer les moteurs sont identiques à toutes les parties. Nous avons juste à active la partie maître en premier si nous voulons que les moteurs suivent l’axe virtuel.

Conclusion

Remerciements

Nous tenons à chaleureusement remercier notre enseignant de réseaux et notre superviseur de projet Monsieur MERCKLÉ. Pour sa disponibilité lorsque nous avions besoin d’aide et pour son engouement autour du sujet ce qui a boosté notre curiosité et nous a beaucoup motivé pour donner le meilleur de nous-même durant ce travail.

Sommaire

IV).a) Pages d’Aide

IV).b) Réalisation du support de la colonne lumineuse

IV).c) Pilotage d’une colonne lumineuse

V) Améliorations

VI) Conclusion

I) Introduction

Ce projet Études & Réalisation du 3ème et 4ème semestre en DUT GEII, traitait le protocole de communication OPC UA (Open Platform Communications Unified Architecture). 

En effet, ce protocole de communication industriel développé par OPC Foundation qui est un regroupement de 5 entreprises fait en 1994, permet la communication au sein d’une machine, entre machines et entre une machine et sa supervision. Il a plusieurs points forts, notamment le fait d’être compatible toutes plateformes (Windows, Linux, Android et Mac). Ce qui permet son utilisation au sein de n’importe quelle entreprise industrielle tout en gardant leurs postes informatiques actuel sans se soucier de l’OS. Ce qui est une restriction en moins et une économie financière en plus.

Ce protocole fonctionne suivant le principe client-serveur avec plusieurs types de clients.

De plus, le fait que les transferts de données se fassent par un et unique protocole et que les connections à différents clients nécessitent plusieurs étapes, tout cela fait que c’est un protocole sécurisé.

L’OPC UA va indéniablement se démocratiser de plus en plus au sein des industries étant donné que nous sommes aux prémices de la 4ème Révolution Industrielle, dans laquelle toutes les machines/objets industriels seront interconnectés entres eux et c’est ce que permettra ce protocole. Protocole qui est d’ailleur standardisé pour permettre l’Industrie 4.0 .

II) Présentation

L’aboutissement de notre projet est la mise en oeuvre d’un tutoriel complet expliquant  l’OPC UA. Ce tutoriel est destiné à notre enseignant Monsieur MERCKLÉ et aux futurs étudiants de DUT/LP SARII car il agit sur le cours traitant du protocole de communication OPC UA dans le but de faciliter sa compréhension au travers d’une prise en main concrète et appuyé par des pages d’aide. Ci-dessous la Bête-à-cornes définissant synthétiquement  notre projet :

II).a) Gestion du projet :

Pour réaliser ce projet nous nous somme fixé durant les heures de TP plusieurs objectifs. Ce projet qui totalise environ 100h de travail a été divisé en plusieurs parties.

Tout d’abord nous avons consacré environ 12h de travail sur la découverte et l’apprentissage du logiciel Automation Studio, afin de comprendre ses fonctionnalitées et son utilisation. Puis nous avons pris connaissance et développé le client 01 sur 14h pour mieux s’approprier et appréhender le protocole OPC UA. Nous avons passé ensuite 10h sur le client 02 qui possédait des outils différents rendant son utilisation plus complexe. Pour finir nous avons étudié et mis en place le client 05 en environ 15h. Nous sommes resté cohérent sur nos objectifs tout au long du projet tout en respectant les temps impartis.

II).b) L’OPC UA?

Présent sur la couche 4 du modèle OSI (Transport), OPC UA contrairement à d’autres protocole est indépendant, il n’est donc pas développé par un fabricant d’automates, mais par OPC Foundation un Consortium industriel de 5 entreprises à but non lucratif (Fisher-Rosemount, Rockwell Software, Opto, Intellution, Intuitive Technology), son développement a commencé en 1994. Il fonctionne classiquement sur le principe client-serveur avec une communication transparente, des capteurs-actionneurs aux systèmes ERP ou au cloud. Le protocole est indépendant de la plateforme et contient de base des mécanismes de sécurité. 

Plus simplement, le but d’OPC UA est d’unifier les communications des appareils et des composants, il est donc compatible avec tous les OS (Mac, Linux, Android et Windows), et avec une grosse partie des appareils : exactement ce qu’il faut dans l’industrie dite “4.0”. Très utilisé chez nos voisins Allemand, il tend à se développer en France (l’entreprise allemande Hager de gestion de l’énergie l’utilise dans ses usines en France par exemple)  et finira inéluctablement par prendre le dessus sur d’anciens protocoles moins universels, car il ne demande pas de changement d’équipements.  

OPC UA est un modèle cohérent, global et normalisé (IEC 62451), il est invisible pour les équipements et permet l’échange de données au sein d’une machine, entre machines et également entre une machine et un système. Via cette unification, les systèmes, les machines et les composants deviennent toutes des ressources pilotées par un superviseur. Là est la pierre angulaire d’OPC UA, l’universalisme dans l’utilisation et la transmission des données, qui permet et permettra à l’industrie de réduire drastiquement ses coûts. 

OPC Foundation a également axé le développement d’OPC UA sur la cyber sécurité, comme vous le verrez tout au long de ce projet le protocole intègre un système d’authentification et d’autorisation utilisateurs, certains utilisateurs auront accès ou non à l’écriture ou à la lecture de données contenues sur le ou les serveurs, bien évidemment les données sont chiffrées et les actions faites par les utilisateurs peuvent être tracées.

Structure du réseau OPC

Le standard de l’OPC UA comporte au minimum un Serveur OPC qui possède le langage propriétaire du matériel ou du logiciel  où il va collecter les informations à exploiter.

Il possède également une application ou Client OPC qui met en oeuvre les spécifications du standard et qui communique avec n’importe quel Serveur  OPC.

Il peut également contenir des informations ou données à exploiter telles que : des valeurs stockées sur des automates, des bases de données ou tout autres fichiers). 

Ce standard est résumé sur le schéma ci-dessous:

II).c) OPC DA/ OPC UA

L’OPC classique, est le prédecesseur de l’OPC UA qui lui mêle les différentes variantes telles que l’OPC DA, AE ou encore  HDA. L’OPC classique utilise DCOM (une technique de communication entre logiciels dans un réseau) pour établir un lien entre serveur et client, alors que l’OPC UA lui utilise différents protocoles de communication comme le TCP/IP ou encore le HTTPS qui permettent l’utilisation de données externes telles que des fichiers excels ou drives. Ces protocoles dépendent du SDK (kit de développement qui dispose d’un convertisseur de langage de programmation en langage machine) qui rend l’utilisation de ces protocoles possible et rend la communication efficace.

L’OPC DA est un groupe de standards qui se focalise sur l’acquisition des données en continu, il est très facile de récupérer la valeur d’une variable et de lui affecter plusieurs éléments comme par exemple une heure d’échantillonnage ou la qualité d’un signal. En revanche les valeurs sont publiques, entraînant une faible sécurité des données notamment pour les variables pilotées. OPC DA est aussi OS dépendant car le protocole est uniquement défini pour windows. Le protocole fonctionne avec une architecture reliant tous les appareils entre eux. 

Le protocole OPC UA reprend le protocole OPC DA classique en corrigeant ses défauts. Cette fois le logiciel est OS indépendant et sécurisé.

II).d) Disposition réelle des équipements

Pour mener à bien ce projet nous avons utilisé plusieurs équipements. Nous avions à notre disposition deux PC pour développer sur le logiciel Automation Studio, Ainsi que deux Automates programmables avec CPU  (automate avec unité de calcul). Chaque automate possède sa propre adresse IP, la CPU 1 a pour adresse : 200.200.200.186 et la CPU 2 : 200.200.200.184. 

Par la suite nous avons ajouté un Coupleur de Bus ou BC (Bus Controller) qui lui a pour adresse 200.200.200.165. La CPU 1 est utilisé pour les clients et communique avec la CPU 2 et le coupleur de bus sur lesquels sont stockés le serveur. Sur les sorties de notre coupleur de bus il y a deux leds branchées, nous verrons ce que nous pouvons en faire…

III) Réalisation

Configuration des Automates 

Au début, nous allons faire tourner les clients en simulation sur un poste, et le serveur en simulation sur un autre,  une fois que ce sera fonctionnel, nous allons faire communiquer le client stocké sur un CPU automate avec le serveur sur un autre CPU automate, enfin, nous ajouterons un coupleur de bus sur lequel tournera également le serveur et dont nous essayerons de piloter les entrées et les sorties.

Etapes de Réalisation 

Il faut bien comprendre que OPC UA est un protocole permettant de donner précisément des droits d’accès ou non à des utilisateurs aux données stockées sur le serveur, par conséquent lorsqu’on lance un projet OPC UA, il y a des pages utilisateurs déjà faites, chacune ayant des droits précis et différents, ainsi qu’une page serveur avec des variables stockées dessus. Par exemple VarX, VarY et VarZ qui s’incrémentent avec le temps via une fonction codée sur le serveur (ce qui peut permettre de vérifier par exemple que l’on récupère bien sur le client les valeurs d’une variable en temps réel si il a cette permission). Mais on peut très bien déclarer nos variables et y accéder. 

Durant ce projet nous avons développé l’accès et la supervision de 3 d’entre eux, le “Client 01”, “Client 02” et le “Client 05”. Le Client 01 utilise des blocs fonctions qui lui permettent uniquement d’écrire ou lire une valeur d’une données du serveur. Il aura accès à la valeur de cette donnée uniquement lorsqu’il en fait la demande. Le Client 2 lui, peut lire une variable mais cette fois ci de manière monitoré, c’est à dire que le serveur lui renvoie la valeur d’une données en temps réel, à un interval de temps défini. Ces deux clients nécessitent que le serveur tourne sur une CPU car il effectue des calculs continu. 

Le Client 05 quant-à-lui est un peu différent, car il sera utilisé pour communiquer avec des matériels n’ayant pas d’unité de calcul, comme un coupleur de bus par exemple. Nous disposons d’un coupleur de bus B&R sur lequel deux leds sont installées, nous tâcherons de pouvoir les allumer et les éteindre à notre guise.

Librairie ASOPCUAC & Bloc fonction

Le projet OPC UA créé contient plusieurs bibliothèques (library), la plus importante et celle que nous utiliserons le plus est “AsOpcUac”, elle contient tous les blocs fonctions (structure) de données utilisées par les clients. 

Durant ce projet, une bonne partie des blocs fonctions présents dans la bibliothèque ont été utilisés, il faut donc bien comprendre ce qu’est un bloc fonction.

Ils sont très utilisés en automatisme, ils sont l’équivalent des structures en programmation classique, c’est un ensemble de programmes ou de fonctions contenu dans un autre élément (ici la liste à gauche). Ils contiennent donc des méthodes qui leurs sont propres et des variables qui peuvent être de type différents et défini en temps que entrée ou sortie. C’est comme un programme dans le programme, ce qui facilite grandement la compréhension du code.

Tous les blocs fonctions utilisées durant le projet sont disponibles en annexe.

III).a) Serveur 

Nous avons d’abord réalisé une visu serveur, afin de visualiser la valeur des variables stockées sur celui-ci.

Déclaration des variables :

Visu du serveur : 

III).b) Protocole du Client 01 

Voici le Protocole donné dans la documentation du Client01 :

L’organigramme est le suivant : 

Nous pouvons voir que les blocs fonctions comportent des variables booléennes d’états, “occupé” (busy) et “terminé” (done), qui permettent de vérifier l’accès aux blocs fonctions. 

Voici dans le détail les explications des actions effectuées par chaque bloc : 

Avant toute choses il nous a fallu modifier la valeur de “ServerEndPointUrl” dans la page de code du client 01, en donnant l’adresse du serveur, ici notre serveur est à l’adresse IP 200.200.200.184.

Nous avons ensuite créé une visu et à l’aide de bouton, un par bloc, nous avons pour chaque bloc fonction, passé à 1 leurs variables booléennes “Execute”.  

Il faut donc, passer par les blocs : 

• Connect
• NameSpaceGetIndex
• NodeGetHandle

Afin de pouvoir lire ou écrire sur une variable stockée sur le serveur. 

Une fois les opérations voulues terminées, pour se déconnecter il faudra passer par les blocs : 

• NodeReleaseHandle
• Disconnect

Pour chaque bloc fonction nous avons affiché leurs variables d’état, le voyant de gauche devient orange si le bloc fonction est occupé (busy) et celui de droite devient vert lorsqu’il n’a pas renvoyé d’erreurs (done). 

Le bloc fonction “Connect” contient une variable qui renvoie une valeur qui est l’indice de connexion qui nous est propre (ce qui fait que la connexion peut être retracée comme nous l’avons vu précédemment), nous affichons également la valeur stockée dans “NameSpaceIndex” qui est une valeur propre à la machine sur laquelle nous nous connectons. Si plusieurs clients sont connectés sur la même machine, ils auront le même NameSpaceIndex.

“NodeGetHandle” renvoie également une valeur qui sera propre à la connexion à une variable, la modification par exemple d’une donnée par un utilisateur peut donc également être retracée. 

Lorsque qu’on exécute le bloc Read ou Write, une variable de type “DATE” est renvoyée nous l’avons également affichée, on peut non seulement savoir qui a accédé ou modifié une valeur, mais également quand. 

Coté client nous avons deux variables, VarA et VarB, lorsque nous exécutons un “READ”, VarA et VarB récupère la valeur de la variable VarX stockée sur le serveur. Les valeurs ne se mettent pas à jour automatiquement, il faudra donc exécuter le bloc fonction “READ” dès que l’on veut récupérer la valeur actuelle de VarX.

VarB dans notre visu est un objet dans lequel on peut écrire une valeur lorsque qu’on exécute un “WRITE” la valeur de VarX récupère la valeur de VarB, et VarB s’incrémente de 1. 

Voici la visu créée pour le client 01 :

III).c) Protocole Client 02 

Voici les étapes d’utilisation données dans la documentation technique du client 02 :

Voici l’organigramme du client 02, avec en petit les blocs fonctions similaires au client 01, nous pouvons voir que le bloc Read/Write a été remplacé par 4 autres blocs :

Explication des 4 nouveaux blocs fonctions : 

Le client 02 contrairement au client 01 peut donc, cycliquement lire la valeur d’une variable contenue sur le serveur, c’est à dire qu’une fois qu’il aura fait le lien avec une variable grâce à SubscriptionCreate (ici VarX), il pourra monitorer une variable coté client avec MonitoredItemAdd (ici VarA). 

VarA récupère donc la valeur de VarX à un intervalle de temps donné, défini dans le programme, ici 1 seconde. Toute les secondes, SubscriptionCreate envoie une alerte (uniquement si VarX est modifié, rappelons que VarX s’incrémente en continu sur le serveur. Si sa valeur était constante SubscriptionCreate n’enverrait pas d’alerte), quand MonitoredItemAdd reçoit cette alerte, il déverse la valeur de VarX dans VarA. Ca y est, nous lisons une valeur du serveur cycliquement ! 

Il nous a fallu également modifier la valeur de “ServerEndPointUrl” dans la page de code du client 02, en donnant l’adresse du serveur. Ici notre serveur est aussi à l’adresse IP 200.200.200.184.

Visu du client 02 :

III).d) Protocole Client 05 

Voici les étapes de connexion au client 05 (comme nous les avons utilisées) : 

Comme vous pouvez le voir le protocole de connexion de ce client est quasiment similaire à celui du client 02 il permet cependant de lire une variable sur le serveur et de stocker sa valeur dans une variable monitorée et également d’écrire via celle-ci, le client 05 possède donc une étape Read/Write.  

Pour ce client, nous souhaitons donc piloter les leds branchées (via un “Write”) sur le coupleur de bus, il faudra donc dans le code du client 05 comme pour les précédents définir l’adresse IP sur laquelle on veut se connecter, ici 200.200.200.165. Afin de pouvoir piloter la led en temps réel, il faudra donc qu’on envoie une information cycliquement. Pour ce client nous avons décidé de ne pas utiliser les blocs SubscriptionCreate et MonitoredItemAdd. Pour les shunter et avoir un résultat équivalent, nous avons créé un programme ST “Clock” qui sera appelé cycliquement toutes les 1000ms. 

Dès que la “Clock” s’exécute nous modifions la variable “Execute” du bloc fonction “Write”, ce qui enverra donc cycliquement l’information voulue au serveur (soit ON soit OFF afin de piloter la led).

Avant toutes choses voici les modifications à apporter sur le code afin de se connecter au coupleur de bus : 

Username passe à Anonymous (donné dans l’aide d’AS) : 

On modifie “ServerEndPointUrl”, en donnant l’adresse du serveur, ici notre serveur est notre coupleur de bus à l’adresse IP 200.200.200.165.

Dans le bloc exécutant “GetNameSpaceIndex” la valeur de “NamespaceUri” doit être modifiée (donné dans l’aide d’AS).

Nous sommes maintenant prêt à intégrer notre bloc fonction “Write”. 

Voici l’organigramme du client 05 : 

Un bloc fonction est venu se rajouter : “TranslatePath”, nous vous expliquerons son fonctionnement, mais pour le définir il faut utiliser un autre outil, UA Expert…

III).e) UA Expert

Pour le client 05 et la connexion avec le coupleur nous avons été amené à utiliser UA expert, un logiciel ayant de multiples fonctionnalités, il nous permet par exemple d’accéder aux données du serveur, aux historiques de connexions… Nous l’utiliserons afin de diagnostiquer notre matériel, en accédant à notre coupleur de bus avec UA expert nous pouvons visualiser les chemins d’accès aux entrées et sorties de nos variables et nous pouvons également les piloter. Nous avons donc deux leds branchées sur notre coupleur de bus, ainsi nous pouvons vérifier sur quelle sortie elles sont branchées. Après les avoir tester nous avons pu voir qu’elles étaient branchées sur les sorties “DigitalOutput01” pour la bleue et “DigitalOutput02” pour la blanche.

Le Client 05 qui pilotera les sorties de notre coupleur de bus dispose donc d’un bloc fonction TranslatePath qui convertit un chemin d’accès à une sortie d’un appareil (Relative Path) en un “NodeIDs” compris et utilisable par OPC UA. Dans la documentation technique, il est expliqué comment construire son Relative Path. 

Pour notre led bleue (DigitalOutput01) Le chemin d’accès sera donc : 

‘/2:DeviceSet/2:X20BC008U/2:X2X/2:SubDevices/:ST3/2:ProcessData/2:DigitalOutput01’ 

Et notre ligne de code : 

RelativePath:=‘/2:DeviceSet/2:X20BC008U/2:X2X/2:SubDevices/:ST3/2:ProcessData/2:DigitalOutput01’

Arbre des dossiers du coupleur de bus sur UAexpert, que nous avons dû suivre pour écrire notre RelativePath

Le bloc servant à écrire (Write, voir ci-dessous) est donné dans l’aide, mais bien évidemment des modifications sont à effectuer pour coller à notre système. “StartNodeID_Root.Identifier” prend la valeur 85 (pour Objects, voir image ci-dessus). Ensuite il faut donner notre RelativePath, notons qu’avec la fonction strcat() de la librairie AsString (à ajouter) on peut concaténer des chaînes de caractères et découper le RelativePath pour qu’il soit plus facilement modulable, ce qui peut permettre par exemple de n’avoir qu’à modifier le “01” final en “02” pour se connecter à la sortie numéro 2. Ca y est, nos leds sont pilotables !

Visu client 05 :

IV).a) Pages d’aide

Pour finir, afin de rendre le logiciel que l’on a développé plus compréhensible, nous avons créé des pages d’aide, qui expliquent les protocoles de connexions aux différents clients. 

Dans un premier temps nous avons créé une page d’accueil, puis dans celle-ci nous avons ajouté une aide concernant l’OPC UA et ses fonctionnalités permettant aux utilisateurs de mieux comprendre les étapes communes aux différents clients. Par la suite nous avons également créé une aide pour chaque clients et ainsi détaillés leurs blocs fonctions. Il y a par conséquent une aide pour le client 01, le client 02 et le client 05 qui lui reprend des méthodes du client 02 et dispose d’un renvoie à l’aide de celui-ci. En effet dans le client 05, certaines étapes ne sont pas utilisées car nous les avons contourné étant donné que nous utilisons une méthode différente permettant d’effectuer les mêmes opérations (Clock).

IV).b) Réalisation du support de la colonne lumineuse 

La colonne lumineuse que nous allons piloter est constituée de 4 Leds, un buzzer et un bouton poussoir. Pour assembler les composants et former une colonne lumineuse nous avons élaboré et construit une boîte pouvant contenir l’ensemble des composants et pouvant être directement fixé sur des supports du panneau. 

Voici le rendu final du boîtier, accueillant l’ensemble des équipements (Leds, buzzer, bouton poussoir).

IV).c) Pilotage d’une colonne lumineuse

Nous allons dans cette partie controller une colonne lumineuse constitué de plusieurs entrées (bouton poussoir) et plusieurs sorties (4 Leds et un buzzer). Pour cela il est nécessaire de pouvoir contrôler plusieurs entrée/sortie. 

V) Améliorations

Une fois la découverte de tous les types de clients, à nous de composer. On pourrait imaginer fusionner des clients pour créer le nôtre afin de lui donner des droits bien précis que l’on aurait défini. Dans certaines variantes du client 1, le client peut lire ou écrire des tableaux sur le serveur, on pourrait imaginer, en le fusionnant avec le client 02, lire cycliquement la valeur d’un tableau stocké sur le serveur. 

Enfin on pourrait modifier le serveur afin qu’il effectue d’autres opérations, on pourrait concevoir une calculatrice, à qui on enverrait des valeurs depuis le client et qui effectuerait les opérations sur le serveur. 

On pourrait également rajouter d’autres appareils, communiquer avec d’autres automates qui effectueront des tâches bien précises, ou un autre coupleur de bus, voire même un capteur. OPC UA est de toute manière compatible avec une énorme partie des appareils disponibles dans notre salle de TP.

L’OPC UA tire aussi sa force dans sa sécurité et nous pourrions mettre en place des protocoles de sécurité (définition d’un mot de passe par client, d’un historique de connexion…).

Ce ne sont que des suppositions, peut être que nous déciderons à terme de faire autre chose si d’autres idées nous viennent. Si on peut en faire autant c’est que le protocole OPC UA est tellement vaste et offre tellement de possibilités que l’on aurait de quoi l’explorer et l’analyser pendant des semaines ! 

VI) Conclusion

Nous n’avions jamais entendu parler de ce protocole avant le premier cours d’étude et réalisation, et nous nous rendons compte à terme que nous avons vraiment bien fait de choisir ce projet. En effet, le protocole OPC UA tend tellement à se démocratiser, qu’on pourrait se demander s’il ne va pas devenir un standard dans l’industrie ? 

De part sa sécurité ou encore son utilisation il nous a permis de mieux comprendre l’enjeu des communications client serveur dans l’industrie. Il reste notamment accessible et est appliqué dans de nombreux domaines tels que le pharmaceutique, le pétrole, le gaz ou encore la robotique. 

Nous avons perçu ce projet comme bénéfique car il nous a permis de développer plus de connaissances dans ce domaine et de maîtriser efficacement l’OPC UA. Il nous reste de nombreux points à découvrir ou à approfondir. 

Ce projet rend bien compte de l’importance de la communication et ses protocoles liés au sein de  l’industrie et du basculement vers “l’industrie connectée”.

Annexes

Blocs Fonctions