Durant notre cours d’Etude et réalisation, nous avons choisi le projet « Supervision de la salle de TP B018 ». Il est en effet possible de contrôler certains équipements électriques présents dans la salle directement depuis notre ordinateur.
Pour ce faire, nous allons procéder par étapes. Nous allons débuter par une étude complète de la salle afin de déterminer quels équipements pourront être supervisable. Ensuite, nous étudierons le moyen de communication entre notre ordinateur et les équipements et mettrons en place cette communication. Enfin, nous créerons une supervision claire et intuitive permettant à une personne ne faisant pas partie du projet de pouvoir contrôler les différents équipements facilement.
Une fois cette partie terminée, nous pourrons également mettre en place une serveur OPC UA qui nous permettra un contrôle plus rapide des équipements ainsi que la possibilité d’accéder à un navigateur internet depuis notre supervision.
ETUDE DE LA SALLE
Pour débuter ce projet, il était nécessaire d’étudier l’ensemble de la salle afin de sélectionner les équipements les plus pertinents à notre projet. Il a en effet fallu choisir les installations compatibles à la communication via le logiciel Indusoft.
Voici quelques équipements que nous avons choisi de superviser :
Maquette de voiture
Multiprise Netio
Banc de supervision
CONNEXION DES EQUIPEMENTS
Afin de connecter les coupleurs d’entrées et les équipements à notre supervision Indusoft, nous avons ajouté un driver MOTCP-MODBUS qui nous permettra de connecter la plupart de nos équipements. Chacune de nos variables devaient être connectées à la bonne adresse IP ainsi qu’à la bonne adresse d’entrée/sortie.
Fiche de driver MOTCP
Pour connecter notre supervision aux serveurs OPC UA et OPC DA, il nous fallait trouver l’adresse de ce serveur sur Indusoft. Ensuite, nous utilisions le logiciel KSP Client qui nous permettait de trouver l’adresse de chaque entrée et sortie des équipements reliés aux serveurs.
Table de connexion OPC UA
SUPERVISION DE LA SALLE
Il était important de créer une supervision de la salle simple à utiliser et intuitive. Ainsi, une personne n’ayant aucun lien à notre projet peut contrôler la salle sans difficultés. Nous avons donc créé une interface simple avec une navigation claire et simple entre les simulations des équipements.
Voici quelques pages de la supervision sur Indusoft :
Page d’accueil de NOTRE supervision
Supervision d’une voiture
Représentation du serveur OPC
MISE EN PLACE D’UN SERVEUR OPC UA
Pour finir notre projet, nous avons mis en place un serveur OPC UA. Nous avons utilisé un projet Automation Studio qui nous avons téléversé dans un automate. Cela nous a permis de créer le serveur. Nous pouvions alors visualiser les données présentes dans le serveur comme une horloge ou la mesure de la température du CPU.
Supervision du serveur OPC UA
Avec ce serveur, nous pouvions également permettre à l’utilisateur d’entrer un lien http et de naviguer sur le web dans l’interface de la supervision. Nous avons aussi ajouté des boutons dans lesquels nous avons prédéfinis des liens internet communiquant avec des sites crées spécifiquement sur le serveur OPC.
Interface lié au navigateur internet
CONCLUSION
Durant ce projet, nous avons put créer une supervision facile à utiliser et pouvant contrôler un grand nombre d’équipements présents dans la salle de TP. Pour cela, nous avons travaillé sur la connexion Modbus ainsi que sur les connexions OPC. Nous avons également mis en place un serveur OPC UA permettant à l’utilisateur de naviguer sur internet.
Afin d’approfondir ce projet, il pourrait être possible de retravailler sur certains équipements difonctionnels ou dont la communication était impossible via Indusoft. De plus, il serait possible de changer certains équipements liés à la multiprise Netio. Nous pouvons imaginer brancher un petit ventilateur, un panneau led affichant un message (GEII par exemple) ou bien un écran.
Pour finir, nous remercions Monsieur Merckle qui nous a guidé et aidé durant ce projet.
Pour le projet d’ER du semestre 4, notre groupe a décidé de choisir comme thème l’exploitation de moteurs pas-à-pas, notamment via une maquette qui reprend la réalité des équipements en industrie.
Cette maquette est composée uniquement d’équipements industriels de marque B&R, une marque proposant des équipements d’automatisme et de supervision industrielle.
Elle permet dans un milieu éducatif, d’apprendre le fonctionnement d’un automate et, dans un milieu industriel, de contrôler des équipements, tout en offrant une mobilité élevée. Elle est composée d’un IHM (Interface Homme Machine) qui permet de créer un lien entre l’Homme et la Machine pour que l’Homme puisse contrôler et surveiller la Machine, d’un variateur qui sera l’intermédiaire entre l’IHM et les équipements, de boutons, d’un moteur PAP intégré et un capteur RFID.
Buts du projet
Exploiter au maximum les capacités des équipements de la maquette, pour pouvoir utiliser toutes ses fonctionnalités, et qu’elle puisse contrôler des moteurs PAP.
On cherche à comprendre les différentes chose qui puissent être faites avec la maquette, et comprendre comment contrôler les môteurs fournis.
Description des équipements hors maquette
Dans notre cas, nous avons dû utiliser des équipements externes à la maquette pour pouvoir exploiter la maquette au maximum. Nous disposons donc de 2 moteurs pas à pas externes.
Exploitation d’un moteur PAP via logiciel Automation Studio
Une fois que le variateur est mis en place et qu’il est bien relié au moteur il est possible d’effectuer un test afin de verifier qu’il n’y ait aucun problème avec ces derniers. Pour ce faire, il faut s’assurer que la CPU soit bien en mode RUN. Une fois que tout est prêt, il suffit d’être dans le centre de test afin de voir le bon fonctionnement de toute l’installation.
v
Une fois la phase de test faite, l’ajout de la librairie qui permet la programmation du moteur grâce à un bloc de fonction. Ce dernier contient toutes les variables permettant d’effectuer une action grâce au moteur.
Le moteur est donc controllé via des variable comme Update, MyVelocity, Home… COntenues dans la librairie.
Exploitation du moteur intégré
Tout d’abord nous avons voulu exploiter le moteur pas à pas présent sur la maquette. Nous n’avons réussi que à faire tourner le moteur partiellement : le moteur ne tournait pas continuellement.
Ceci est un problème auquel nous n’avons pas pu remédier.
Le problème provient des paramètres du moteur dans le logiciel Automation Studio, car le moteur se déplace avec des positionnements angulaires, et ce type de position nécessite plus de paramétrages, que nous n’avons pas pu faire.
Automate à partir d’un automate
Nous avons alors décidé avec l’aide et l’autorisation de Mr MERCKLE de relier le variateur de la maquette à deux autres variateurs qui sont externes à la maquette. Les modules E/S des deux variateurs sont chacun liés à un moteur.
Voici une capture du système vu sur logiciel :
Il faut faire attention à ne pas oublier d’insérer les variateurs, les modules E/S, les moteurs PAP, ainsi que les librairies pour chaque moteur (nous avons pu les ajouter à l’aide du tutoriel de MERCKLE).
Exploitation des boutons
Afin d’exploiter au maximum le module, nous avons décidé dans un premier temps d’ouvrir les pages de chaque moteur et une page générale avec les 3 boutons physiques. Cependant, il était impossible, car les fonctionnalités du module restaient un minimum limité.
Pour exploiter tout de même les boutons, nous avons décidé de donner comme utilité aux boutons, le contrôle des équipements. Il y a de nombreuses possibilités (en fonction des équipements) dans notre cas (moteur PàP), car à l’aide des boutons nous pouvons faire de nombreuses actions : changer de direction, allumer le moteur, lancer la rotation du moteur, Remettre à 0 la valeur de la position, actualiser les valeurs des variables moteurs (UPDATE), etc…
Voici un schéma démonstratif des nombreuses possibilités :
Simplification de l’interface
our pouvoir utiliser simplement et efficacement le moteur, nous avons mis en place une interface avec 4 pages au total :
– 1 page d’accueil avec bouton Général et Moteur 1/2
– 1 page générale (ensemble des moteurs)
– 1 page pour chaque moteur et toutes leurs fonctionnalités.
Les boutons entourés d’un rectangle noir ont un voyant qui peut s’illuminer de 2 couleurs : Rouge si une variable n’est pas à jour ou n’est pas prête, et Vert si une variable est à jour ou prête.
Exemple 1 : Si le moteur est allumé, le cadre du bouton POWER sera Vert. Si le moteur est éteint, le cadre sera Rouge.
Exemple 2 : Si la position est remise à 0 en cliquant sur RESET POSITION, le cadre de ce bouton sera Vert, sinon ce sera Rouge.
Dans notre cas, les variables UPDATE (qui actualise les valeurs de la variable) sont affectées aux boutons physiques, comme dans l’exemple du schéma dans la partie « Module de boutons ».
Support de maquette sur-mesure
Pour utiliser confortablement la maquette, nous avons crée un support sur-mesure afin de consolider l’ensemble et de le transporter sans s’inquiéter d’abimer un câble ou un composant.
En effet, les câbles lorsque la maquette est posée sur une surface plate, se frottent contre celle-ci, et avec le temps, risquent de s’abimer et donc de causer des problèmes sur le fonctionnement global de la maquette.
Le support permet de tenir la maquette inclinée, offrant une meilleure vue de l’ensemble et principalement de l’IHM.
Capteur RFID
Ce capteur aurait donné d’autres fonctionnalités à cette maquette : possibilité de se connecter à un utilisateur précis via ce capteur, activer ou désactiver le mode Manuel, allumer/éteindre les moteurs, faire office d’arrêt de secours, etc…
Nous pouvions exploiter le capteur RFID, pour permettre seulement aux utilisateurs munis d’un badge à induction, d’utiliser l’interface de la maquette.
Mais malheureusement nous ne disposions pas de badges à induction lors de la réalisation de notre projet.
Couplage des deux moteurs
Capture d’un bloc fonction permettant le couplage des moteurs Les 2 moteurs tournant individuellement, montrent le bon fonctionnement de ces derniers. Suite à cela, une nouvelle exploitation aurait pu être faite : Le couplage des moteurs. Cela consiste à faire tourner un des moteurs grâce à la rotation effectuée par l’autre.
Plus précisément, lorsque le premier moteur dit « Moteur maitre » est en rotation grâce à la programmation d’un bloc de fonction prévue pour le couplage des deux, le deuxième dit « Moteur esclave » sera entrainé par la rotation du premier. La programmation de ce bloc permettrait de choisir les sens de rotation du deuxième moteur en fonction du premier.
Avec les bonnes valeurs le premier moteur pourrait faire tourner le deuxième moteur dans le même sens, ou bien dans le sens opposé.
Conclusion
Le but de ce projet étant d’exploiter un maximum la maquette, nous avons pu en exploiter 70%. Les exploitations éventuelles comme celles du couplage, et le changement de pages avec les boutons physiques auraient peut-être été faites avec légèrement plus de temps.
Avec une recherche plus détaillée et plus d’éléments, une exploitation du capteur RFID aurait pu être faite, mais le résultat final est que l’on connaît son utilité et son fonctionnement, et que sa mise en place du aurait certainement été rapide.
Nous tenons a remercier comme il se doit Mr. MERCKLE pour son soutien et son apport de connaissance qui nous a énormément aidé à mener à bien ce projet, et Mr. DE SABBATA pour l’aide à l’IUT Lab lors de la réalisation de la maquette.
Pour notre projet d’étude et réalisation, nous avons choisis de réaliser la « Commande de moteurs asynchrones ». La possibilité de contrôler des moteurs asynchrones sur un système peut nous permettre d’imaginer de multiples idées d’améliorations par la suite.
Mais avant cela il fallait tout d’abord faire tourner ces moteurs correctement, telle était notre objectif de base, mais voulant aller plus loin nous envisagions de faire le couplage des moteurs asynchrones.
Ce projet consiste à aboutir un précédent projet effectuer par des étudiants de l’an passé qui n’ont malheureusement pas pu finir ce dernier pour cause de crise sanitaire. On a donc pris la relève et en partant des études qu’ils ont pu réaliser, nous avons dû finaliser le projet.
Il a fallu reprendre les documents rédigés par ce groupe pour, au préalable, nous familiariser avec ce projet et ainsi pouvoir travailler dans des conditions idéales au bon développement et finalisation de ce projet.
Études réalisées
Plusieurs études ont été effectuer afin de faciliter la réalisation du câblage.
À l’aide du logiciel QElectrotech, nous avons pu réaliser un schéma électrique au propre.
Nous avons pratiquement obtenu un résultat avec tous les symboles normalisés, cependant, certains symboles tels que le variateur et les colonnes lumineuses ne sont pas disponible dans le logiciel. Il n’y a donc pas pu avoir intégration de ces derniers sur le schéma. Pour pallier cela, des blocs explicatifs ont été rajoutés pour combler le vide.
Par ailleurs, après plusieurs vérifications, nous avons réalisé un schéma de câblage.
Voulant avoir un retour sur l’état de notre système, nous avons dû faire une étude sur les colonnes lumineuses afin de pouvoir les intégrer au système.
Cela se traduit tout d’abord de la réalisation d’un code couleur.
Il faut savoir que les colonnes lumineuses comportent plusieurs câbles de différentes couleurs. Il a donc fallu trouver à quelles entrées du variateur devaient être relié chacun de ces câbles.
Notre système est alimenté en 230 V, c’est pourquoi il a fallu étudier comment coupler chacun des moteurs. La plaque signalétique du moteur (voir annexe) nous indique que pour une alimentation en 230 V, le moteur doit être couplé en triangle. Pour coupler le moteur en triangle, il est indiqué sur le couvercle des moteurs que pour avoir un couplage triangle, il faut placer des barres de cuivres comme sur l’image suivante.
Réalisation du câblage
Notre câblage, c’est dérouler en deux parties. La première partie consistait à câbler la partie du bas de notre tableau électrique.
Une fois ce câblage réaliser, nous avons pu effectuer un test permettant de vérifier le bon fonctionnement de notre câblage mais aussi de ces composants. Pour réaliser ce test, nous avons directement alimenter cette perte du système à partir d’une prise secteur.
Le test réussis avec succès, nous avons alors pu continuer notre câblage et donc passer à la deuxième partie.
Développement d’un programme
Le programme nous permet de contrôler un moteur sur plusieurs plans. L’affichage ci-dessous est l’interface homme-machine permettant le contrôle du moteur par un individu. Entre autres, avoir la main sur sa vitesse de rotation, à l’aide du potentiomètre, mais également sur son sens de rotation et son arrêt.
Conclusion
Durant ce projet, nous avons dû effectuer un contrôle des moteurs asynchrones sur notre système.
Afin de réaliser au mieux ce projet, nous avons dû anticiper le matériel nécessaire, réaliser un schéma électrique adapté à notre système, réaliser également un schéma de câblage pour par la suite câbler le système de la manière la plus optimale. Par ailleurs, une étude sur la partie programmation a été effectué de pouvoir réaliser les tests adéquats.
Une amélioration possible à ce projet pourrait être la réalisation d’un programme permettant le couplage des deux moteurs asynchrones.
Pour finir, nous voulons remercier Mr. Merckle pour son aide, ses conseils, sa présence tout au long de notre projet.
Nous voudrions premièrement remercier M. MERCKLE, notre professeur d’Etude et Réalisation qui nous aura de nombreuse fois aidé dans ce projet. Mais également M. De SABBATA sans qui nous n’aurions pas eu accès aux outils nécessaire pour réaliser ce projet. Et enfin M. VERRON qui nous aura lui aussi grandement aidé lors de la réalisation des circuits imprimés.
La finalité de ce projet est de permettre le contrôle de 2 moteurs Courant Continu à partir d’une visualisation sur un ordinateur.
Figure 1: Système final
Voici le cahier des charges de ce projet :
Etudier la borne moteur ainsi que les capteurs.
Réaliser un schéma de la maquette
Choisir et commander le matériel manquant (s’il y en a)
Elaborer un programme test
Développer une application complète.
Matériel
Pour réaliser ce projet, voici le matériel que nous avions à disposition :
Maquette L’objectif premier étant la réalisation de la maquette (sans celle-ci, impossible de pouvoir effectuer le moindre test), il était donc impératif de la commencer le plus tôt possible. Nous avons alors réalisé une première maquette pour supporter les moteurs, ainsi que souder des câbles aux moteurs afin de permettre leur connexion à l’automate.
Programmation
Dans ce projet, la programmation a pour but d’apporter à l’utilisateur une interface de commande fiable, ergonomique et intuitive. La première étape était le design de la visualisation
La visualisation devra supporter plusieurs types de commandes :
Une commande manuelle permettant de contrôler chaque moteur indépendamment par modulation d’impulsion (PWM) avec en plus, la possibilité de choisir le sens de rotation.
Une commande temporelle, capable de faire tourner chaque moteur pour un temps donné (en utilisant pour base de temps celle de l’automate)
Une commande asservie qui utilisera des capteurs de proximité pour détecter le nombre de tours que fera chaque moteur.
Electronique
La partie électronique du projet à pour rôle d’assurer le bon fonctionnement de la maquette et de permettre une utilisation fiable. L’électronique est elle-même répartie en deux parties :
Motorisation
Capteur
Motorisation La motorisation s’articule autour des deux moteurs et des ports de contrôle du module automate. Chaque moteur à une tension d’alimentation de 24V et un courant absorbé à vide d’environ 80mA, le module automate ayant une limite de courant de 3,5A par moteur, le système aurait été capable normalement d’actionner les moteurs sans difficulté. Toutes fois, en raison du pique de courant demandé par les moteurs au démarrage, il nous était impossible de lancer les moteurs (Voir Problème Rencontrés). Pour résoudre ce problème, nous avons alors connecté une résistance de 5,6Ohm en série de chaque moteur pour réduire le pique de courant et ainsi permettre le démarrage des moteurs.
Capteur Les capteurs ont pour but de retourner les informations sur la position/Vitesse des moteurs à la manière d’un encodeur et/ou codeur incrémental. Nous utilisons pour ce projet des capteurs Infra-RougeIR (TCRT5000L) ainsi que des disques amovibles ayant une découpe particulière suivant la manière dont on veut se servir des capteurs (position initial, vitesse, sens, …).
Conclusion
Atteinte des objectifs La date de fin de projet étant maintenant passée, il était essentiel de faire un point entre les attentes et la réalisation effectuée.
En reprenant depuis le début, l’étude de la borne moteurs ainsi que celle des capteurs a été une grande réussite car sans cette étape, nous n’aurions pas pu aller aussi loin.
La structure physique du projet (support + électronique) a elle aussi été une réussite. Cette structure permet d’obtenir une grande facilité d’utilisation, de plus, son côté modulable permet de remanier ce projet dans son entièreté, il est donc très aisé de rajouter des composants ou modules afin d’ajouter de nouvelles fonctionnalités.
Pour finir, il reste l’aspect software (programmation + interface utilisateur). Tout n’a pas pu être entièrement complété, comme la détermination de la vitesse de chaque moteur, ou bien la représentation de la position et rotation sur la visualisation. Cependant, les objectifs clés, tels que la commande manuelle, temporelle ou bien asservie ont, eux, été réalisé.
Ce projet n’aura donc pas été réalisé à 100% mais une grande majorité aura elle, bien été faîtes. Ces quelques éléments manquants pourront par la suite faire place à une phase d’amélioration de ce projet.
Améliorations
Nous avons jusqu’ici réalisé une grande majorité de nos objectifs. Cependant, il reste de nombreuses améliorations à apporter à ce projet.
La maquette a été conçue de sorte que chaque moteur puisse être utilisé avec 2 capteurs. Il est donc désormais possible de déterminer la vitesse de rotation d’un moteur et de l’afficher sur une page de la visualisation. On pourrait également créer une nouvelle commande de moteur avec cette fois la vitesse pour ordre.
Sur les visualisations déjà créées (Voir Figure 3) on retrouve un emplacement central destiné à représenter la position et rotation en temps réelle des moteurs. Par soucis de temps, cet objectif n’aura pas été atteint mais peut néanmoins servir d’améliorations à ce projet.
Et enfin, l’amélioration la plus ambitieuse, serait la conception puis réalisation d’un bras robotisé a 2 axes de rotation. Ce bras permettrait le déplacement sur axe à 2 dimensions. Il pourrait par exemple tenir un marqueur et dessiner sur un support que ce soit par commande manuelle ou bien par une succession d’instructions prédéfinies.
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.
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
Introduction
Cahier des charges
Bête a corne
Diagramme pieuvre et Tableau des fonctions
Étude de l’installation
Ancienne installation
Installation actuelle
Développement du pilotage synchronisé
Moteur asynchrone
Moteur Pas à Pas
Servomoteurs
Conclusion
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.
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
I) Introduction
II) Présentation
II).a) Gestion du projet :
II).b) L’OPC UA ?
II).c) OPC DA / OPC UA:
II).d) Disposition réelle des équipements
III) Réalisation
III).a) Serveur
III).b) Protocole Client 01
III).c) Protocole Client 02
III).d) Protocole Client 05
III).e) UA Expert
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 :
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”.