IMA5 2019/2020 P13
Sommaire
Présentation générale
Etudiants : Antoine Branquart, Juliette Obled
Encadrant : Anne Lise Gehin
Objectifs
Développer des algorithmes et implanter une interface de supervision pour gérer de manière optimale des différents modes de fonctionnement d'une pile à combustible.
Description
L'école, en partenariat avec le laboratoire CRIStAL dispose d'une plate-forme technologique permettant d'illustrer des enseignements dans le domaine des énergies propres. Cette plate-forme est constituée d'une éolienne, de deux panneaux photovoltaïques, d'un électrolyseur, d'une unité de stockage de l'hydrogène et d'une pile à combustible. L'idée est d'utilisée l'énergie produite par les sources renouvelables lorsqu'elles sont disponibles pour produire de l'hydrogène à partir de l'électrolyse de l'eau puis de réutiliser ultérieurement cet hydrogène pour produire de l'électricité via la pile à combustible, ceci permettant de palier l'intermittence des sources primaires.
La réalisation de ce projet de fin d'études s'inscrit dans le projet européen Electrons to high value Chemical products (E2C) ". Ce projet commun à plusieurs universités et centres de recherche localisés dans les régions côtières de la Manche a pour objectif de convaincre l'industrie d'investir dans le développement et la mise en œuvre de technologies qui utilisent les énergies renouvelables pour remplacer les sources d'énergie du pétrole et du gaz dans la production de produits chimiques.
Composition du système déjà existant
Sur la photo ci-dessus on peut voir le matériel utilisé faisant partie de la plateforme technologie acquit en 2016 par l'université, à savoir:
- Deux panneaux photovoltaïque
- Une éolienne
- Capteur de radiation solaire
- Capteur de température au niveau des panneaux
- Anémomètre qui informe de la vitesse et du sens du vent pour l'éolienne
- Une armoire de commande reliée aux sources d'énergie composée de:
- Un automate programmable industriel Beckhoff
- Capteur de tension et de courant
- Batterie
- Onduleur et transformateur afin d'obtenir une sortie 230V/50Hz
- Un électrolyseur pour la production d'hydrogène
- Un châssis National Instrument Compact DAQ
- Une carte d'entrée sortie National Instrument, disposée dans le châssis Compact DAQ
- Le "Hybrid Energy Lab" composé de différents éléments énumérés de haut en bas visiblement sur la vignette de droite:
- Un module de commande composé d'une interface homme machine permettant de contrôler le système sur place.Les algorithmes de commande du système ainsi que l'interface homme machine sont intégrés dans le Panel PC "AFL-07A-N270" de chez iEi.
- La charge électronique qui permet de simuler la consommation d'énergie. Elle dispose de plusieurs mode de régulation.
- Deux batteries au plomb
- Un module de gestion de l'énergie. Il transforme la tension de sortie non régulée de la pile à combustible en une tension régulée 24V et une tension alternative 110/230V. Il charge aussi les batteries et alimente les consommateurs interne du système.
- La pile à combustible Nexa 1200
- Réservoir d'hydrogène qui peut être équipé de trois différentes bouteilles à hydrures métalliques
Etat de l'art
Contexte
De nos jours, le réchauffement climatique est au centre de toutes les problématiques mondiales. Les ressources fossiles que nous utilisons, en plus de s’épuiser, polluent énormément. Le monde cherche donc à se tourner vers l’utilisation d’énergies renouvelables. Cependant, aussi prometteuses qu’elles soient, les énergies renouvelables (issues du rayonnement solaire, du vent, de l’eau) ne proposent pas d’énergie à la demande car dépendent de nombreux paramètres tels que la météo au moment dit, l’heure de la journée et le moment de l’année. Il se pose donc un problème de stockage de ces énergies pour réussir à se libérer totalement des énergies fossiles. C’est dans ce cadre que s’est constitué le projet européen “ Electrons to high value Chemical products (E2C) ". Pour la partie située au sein de l’Université de Lille, il consiste à étudier la combinaison de plusieurs énergies renouvelables afin d’en sortir une production la moins variable possible, ainsi que le stockage du surplus vers des batteries ainsi que sous forme d’hydrogène par l’électrolyse de l’eau.
Les avantages de ce mode de stockage sont les suivants : en l'associant au stockage par batterie disponible dans l'armoire de commande de la plateforme, on obtient un gain non seulement en autonomie mais aussi en disponibilité en énergie, comme on peut le voir sur le graphique ci contre :
Thèse d'Ibrahim Abdallah sur le système
Cette thèse est une étude appliquée à notre système, et contient notamment une description de celui-ci.
Le but est d’utiliser l’énergie fournie par les ressources renouvelables (éolienne, panneau solaire) tant que cela est possible, en stockant le surplus dans les batteries et sous forme hydrogène et en utilisant ce stockage en cas de besoin. Le scénario théorique de fonctionnement normal est le suivant :
- Si la puissance offerte est très supérieure à celle demandée, alors le surplus est stocké dans les batteries ainsi que sous forme hydrogène (tant que la pression dans les bombonnes est inférieure à 10bar).
- Si la puissance proposée est toujours supérieure à la demande mais de manière moins importante alors le stockage est uniquement dirigé vers les batteries.
- Si la puissance offerte est inférieure à la demande, le stockage dans les batteries est utilisé puis l’hydrogène et enfin le réseau électrique si cela est nécessaire.
Cependant, la pile à combustible n'est pour l'instant pas reliée au reste du système de manière automatisée. Elle est contrôlée par un automate différent du reste, et c'est manuellement que la fonction de la PAC est choisie.
Ces informations sont disposées aux pages 139 à 141 de la thèse dans le chapitre 4.
Interface Heliocentris
Pour ce projet, Heliocentris a pu fournir une base de composants ainsi que des interfaces de lecture des données. Voici donc ci dessous les logiciels déjà existants, avec à gauche celui du système énergies renouvelables et électrolyseur/batteries, et à droite celui de la pile à combustible.
Cependant, ces logiciels ne sont pas flexibles et ne peuvent pas être modifiés. De nouveaux composants comme des capteurs ou même une deuxième éolienne ne peuvent donc pas être ajoutés, et la commande ou la supervision ne peuvent pas être adaptées. Dans le cadre d’un projet de recherche ils ne sont donc pas exploitables.
PFE 2018 de François-Xavier Cockenpot
L’année dernière, l’IMA5 François-Xavier Cockenpot a également pu inscrire son PFE dans le projet européen E2C, afin de réaliser l’interface de commande et de supervision de la production de l’hydrogène (électrolyseur).
Il a tout d’abord travaillé sur la communication avec l’automate, en récupérant et identifiant les trames grâce au logiciel Wireshark. Une fois les variables récupérées il a automatisé la commande de l’électrolyseur et réalisé l’interface de supervision du système complet avec le logiciel LabView.
L’interface de supervision contient donc une partie de détection d’erreur des différents éléments basée sur des courbes de tendance des constructeurs et des valeurs issues d’équations théoriques.
Préparation du projet
Descriptif du système à commander et à superviser
L'objectif de notre PFE est donc de continuer sur les pas du PFE 2018 du point précédent en réalisant la commande et supervision cette fois de la production d’électricité depuis l’hydrogène grâce à la pile à combustible.
Le système étudié pendant le PFE de 2018 permet donc d'obtenir et de stocker de l'hydrogène à partir de sources d'énergies renouvelables. Le système sur lequel nous allons travailler utilisera donc cet hydrogène comme carburant pour la pile à combustible afin de constituer une partie de la plateforme technologique.
La pile à combustible permet d'obtenir de l'électricité à partir de l'oxydation sur une électrode de l'hydrogène couplée à la réduction sur l'autre électrode d'un oxydant, tel que l'oxygène de l'air. Ce fonctionnement revient finalement à l’électrolyse inverse de l'eau. On peut voir les équations qui résultent de cette réaction sur le schéma disposé à droite du paragraphe.
La tension et le courant produits par cette pile sont continus. Ils seront réutilisés pour : alimenter la charge électronique disponible au sein du système ou bien tout simplement alimenter une lampe pour s'assurer du bon fonctionnement de la commande du système
Il faudra donc commander les différents paramètres permettant la production d'électricité via la pile à combustible, détecter les erreurs qui empêche cette production ainsi que surveiller les valeurs entrantes et sortantes de la pile via une interface homme-machine permettant de visualiser l'ensemble du système.
Cahier des charges
Dans le cadre du projet européen E2C du développement de l’utilisation des énergies renouvelables, Polytech détient une plateforme d’étude composée notamment d’une pile à combustible. Celle-ci permet de transformer l’énergie issues d’énergies renouvelables précédemment stockée sous forme d’hydrogène (grâce à un électrolyseur) en électricité.
Lors de ce projet, l’étude sera tout d’abord centrée sur la pile à combustible (PAC). Pour palier au logiciel de commande et supervision trop contraignant déjà existant, le but sera de développer une commande plus flexible de l’automate ainsi que d’implémenter une interface de supervision. Si cela est possible, la commande et/ou l’interface seront mises en commun avec le reste du système (PLC, électrolyseur, batteries). L’ajout d’un système externe sera mis en place afin de tester l’efficacité de la production d’électricité du projet.
Choix techniques : matériel et logiciel
Matériel
- carte d'entrées sorties ?
Logiciel
- Wireshark pour l'identification des entrées/sorties
- LabView pour la récupération/envoie des données
- LabView pour la commande (utilisation de SIT - simulink interface toolkit - avec MATLAB ni besoin, voir semaine du 30 septembre)
Liste des tâches à effectuer
Voici une liste non exhaustive concernant le plan d'action du projet. Certaines parties contiendront bien entendu des sous-tâches supplémentaires.
- Acclimatation avec le système, mise en place du cahier des charges, renseignement sur les logiciels Labview, RTW, Wireshark et lecture des documentations
- Utilisation du logiciel Wireshark pour reconnaître les entrées/sorties de l’automate
- Récupération des données sur LabView
- Commande du système
- Supervision du système
- Interface Labview
- Regrouper les deux interfaces
- Regrouper l’ensemble du système
- Ajout d'un système externe pour tester l'efficacité de la production d'énergie
Calendrier prévisionnel
Réalisation du Projet
Semaines du 9 au 29 septembre
Durant ces premières semaines, nous avons rempli les premières parties de ce wiki en établissant la description du projet et du système, l'état de l'art ainsi que le cahier des charges avec les tâches à effectuer.
Pour cela nous nous sommes renseignés en lisant les documentations fournies, les anciens travaux ainsi qu'en ayant des réunions avec Mme Gehin. Nous avons également pu appréhender l'utilisation de la PAC avec le thésard Sumit Sood.
De plus, nous avons pu noter les problèmes que nous allons potentiellement rencontrer :
- Deux automates différents. L’automate contrôlant la PAC est un autre que celui contrôlant le reste du système. De ce fait, nous ne pouvons pas simplement reprendre le travail de récupération des données fait par FX Cockenpot mais recommencer de zéro. De plus, pour la même raison, le regroupement des deux interfaces dans la suite du PFE va probablement poser problème car les deux automates utilisent peut-être des adresses similaires pour des actions/capteurs différents.
- Automatisation générale du process. Pour recharger les bouteilles d’hydrogène, soit un opérateur sort une bouteille de la PAC pour la connecter à l’électrolyseur. Pour cela, la PAC doit être éteinte et des câbles débranchés pour pouvoir ouvrir la partie concernée. Une autre manière de recharger les bouteilles est de connecter directement l’électrolyseur à la PAC. De cette manière, la PAC doit être éteinte lorsque les bouteilles se rechargent donc les deux automates doivent être capables de communiquer entre eux afin que l’électrolyseur ne se mette pas en route si la PAC est en fonctionnement.
Semaine du 30 septembre au 6 octobre
Utilisation de Wireshark afin d'identifier le protocole de communication utilisé entre la PAC et le logiciel Heliocentris
Durant cette deuxième semaine notre objectif était de comprendre comment les données des différents capteurs sont récupérées et envoyées au logiciel de supervision et comment les ordres sélectionnés sur ce logiciel sont transmis aux différents modules de la pile.
Grâce à la documentation fournie avec le système, nous avons pu voir que la communication entre les différents modules est effectuée via un bus de données de type "CAN" (Controller Area Network). Le bus "CAN" met en application une approche de multiplexage qui consiste à raccorder à un même câble un grand nombre de capteurs qui communiquent à tour de rôle. Ce bus CAN est ensuite connecté au "panel PC" disposé sur le devant du système qui centralise ces données, les transforment pour qu'elles soient ensuite affichées via l'interface homme-machine intégrée à ce mini-ordinateur.
Le panel PC échange en temps réel ces données via un autre protocole de communication au logiciel Heliocentris installé sur un ordinateur à distance qui récupère ces données afin de les réutiliser pour les afficher sur l'interface de supervision du logiciel. On peut envoyer des ordres via cette interface, par exemple modifier les courants d'entrée et de sortie du convertisseur DC/DC. On en a donc déduit que lorsqu'on envoie un ordre comme celui-ci, le panel PC récupère l'ordre et le dispatche via le bus CAN au module concerné afin d'effectuer la régulation.
Pour connaître le protocole de communication utilisé pour la communication entre l'interface à distance et le mini-ordinateur de la pile, nous avons utilisé un sniffer réseau tel "Wireshark" afin d'analyser les trames de données échangées entre les deux systèmes.
Ce test nous a permis de voir que le protocole de communication utilisé est le TCP/IP et que la connexion entre les deux différents systèmes, l'échange des données des capteurs ainsi que les ordres envoyés à la pile sont effectué par le biais de ces trames TCP.
Sur l'image de gauche ci-dessous on peut observer les trames de connexion entre le panel PC et l'ordinateur à distance (en gris). Sur celle de droite on peut voir un exemple de trame de données envoyé du panel pc à l'ordinateur à distance.
Les trames de connexion entre le panel PC et l'ordinateur à distance (en gris)
Exemple de trame de données envoyé du panel pc à l'ordinateur à distance
Comparaison MATLAB/LabView
LabView :
- La carte d’acquisition à notre disposition est une National Instrument qui peut être gérée via l’utilitaire DAQ.
- La récupération et le contrôle de données sont de manière générale plus intuitifs sur LabView que sur MATLAB. De même que le design d’interface.
- Cependant, MATLAB Simulink propose de meilleurs modules de commande et simulation.
La meilleure solution serait donc d’associer LabView (récupération de données, envoie de données et interface générale) à MATLAB Simulink (simulation de comportements et commande).
Pour cela, plusieurs possibilités existent :
- Utiliser le Model Interface Tool (MIT) : 1200 euros
- Tunnel ActiveX : MATLAB vers tableur puis tableur vers LabView. Mais ce n’est pas une solution temps réel
- MATLAB script node : permet d’ajouter du code MATLAB dans le fichier LabView. Intéressant mais ne va pas jusqu’à l’utilisation de Simulink.
- Simulink Interface Toolkit (SIT) : permet de convertir le fichier simulink en fichier DLL (récupérable sous LabView). Problème : payant. Une version d’essai peut être installée mais certaines fonctionnalités sont alors indisponibles (et la version ne durera pas le temps du PFE).
Conclusion :
Pour le moment, uniquement LabView sera utilisé. Si des modules complexes sont nécessaires et indisponibles sur LabView (notamment pour la partie simulation de courbes), alors l’utilisation de SIT sera envisagée. Cependant, comme il est évoqué dans ce rapport de projet, des problèmes liés au temps réel ainsi qu’à la version d’essai vont probablement survenir.
Retards
Durant cette semaine, alors que nous pensions pouvoir finir l’identification des données, nous avons rencontré un certain nombre de problèmes.
Tout d’abord, la pile à combustible est complètement déchargée. Les batteries externes n'arrivent pas à la recharger et toutes les bouteilles d'hydrogène sont vides (il faut environ 12h pour en remplir une). De ce fait, elle fonctionne sous warning constant, peu d'ordres peuvent être envoyés et les trames perdent alors de leur sens.
De plus, le PC - sur lequel les logiciels LabView et Matlab sont installés et où une connexion internet est disponible - n'était pas configuré pour recevoir les données de la PAC, ce qui nous a beaucoup ralenti en attendant de résoudre ce problème.
Enfin, nous manquons de connaissances en Réseau et en LabView pour le moment afin d'être aussi efficaces que nous l'aurions souhaité.
Semaine du 7 au 13 octobre
Protocoles de communication
Nous avons continué à analyser les trames interceptées par Wireshark. En effet, alors que c'est un protocole TCP/IP et que la communication se fait via Ethernet, Wireshark ne les identifie pas comme du Modbus comme ce que à quoi l'on pourrait s'attendre (l'automate regroupant notamment l'électrolyseur provient du même constructeur et les données étaient transmises via Modbus). Le port n'est pas 502 (correspondant au Modbus) et nous n'avons pas accès aux registres. Notre port destination étant le 4242, après de nombreuses recherches et discussions avec différents professeurs, nous en sommes venus à la conclusion que nous faisons face à un protocole propriétaire créé par le constructeur Heliocentris, qui complexifie énormément l'étude. Nous avons contacté Heliocentris pour potentiellement avoir plus de détails sur ce protocole, et nous attendons une réponse.
En parallèle à cette conclusion, nous avons eu des informations de M. Mathieu BRESSEL, faisant également parti de l'équipe E2C. Nous avons donc récupéré des documents décrivant le protocole de communication CAN entre la pile et le panel PC et notamment les adresses utilisées pour différents contenus (comme les valeurs de tension, etc). Le panel PC fait donc office d'automate puisque c'est lui qui redirige toutes les informations à la fois vers la pile et éventuellement vers le logiciel PC si connexion il y a.
Depuis ces dernières informations, nous allons donc essayer de récupérer les données depuis le bus CAN. Alors que nous pensions devoir utiliser un convertisseur CAN vers USB (dispositif très cher), nous avons remarqué qu'il y avait déjà ce convertisseur dans la pile (vers le panel PC). Nous avons donc pour but de se placer en série au niveau de la connexion USB juste avant le panel PC, grâce à un switch USB.
Ayant désormais une description détaillée du protocole CAN et un moyen de se placer sur ce bus de transmission, nous espérons que cette méthode nous permettra de communiquer avec la pile à combustible.
Commande d'une nouvelle batterie
La pile à combustible n'ayant pas servi pendant un certain moment, l'une des batteries haute capacité rechargée par la conversion hydrogène-électricité s'est déchargée trop lourdement pour que l'on puisse la recharger. Cela a pour conséquence que le logiciel de supervision envoie constamment des warnings et empêche le système de fonctionner correctement ce qui est un handicap pour l'élaboration de notre interface de supervision.
Nous avons donc démonté et ouvert le module contenant les batteries puis avons repéré l'intensité et la tension nominale des batteries haute capacité.
Le module est composé de deux batteries au plomb, et de deux batteries au plomb 12V, 18 Ah. Après avoir vérifié la tension de chacune des batteries grâce à un voltmètre, nous avons donc repéré la batterie défaillante. Les batteries étant montées en série il suffit de commander une batterie ayant les mêmes caractéristiques et le système de recharge par hydrogène grâce à la PAC sera de nouveau opérationnel.
Nous avons retrouvé le même modèle commandable via cette entreprise allemande : Lien vers la batterie
La commande n'étant pas possible sur ce site si l'on veut être financé par Polytech nous allons dans un premier temps attendre la réponse du technicien avec qui nous avons repéré la batterie défaillante qui nous a confirmé pouvoir se procurer une batterie de même caractéristique inutilisée au sein de l'école.
Interface Labview
De plus, nous avons décidé de prendre en main le logiciel LabView et de prendre de l'avance au niveau de l'interface homme-machine en retranscrivant la première feuille d'interface du logiciel Heliocentris.
En utilisant les différents outils disponibles sous LabView pour la réalisation de la face avant, nous avons donc pu arriver à un résultat équivalant à l'interface constructeur. Bien sûr cette interface n'est pas définitive, elle sera apportée de modifications et de nouvelles fonctionnalités au fur et à mesure du projet. Le simple fait d'avoir recopié cette interface a permis d'améliorer nos facultés graphiques sur LabView et d'avancer sur le projet même en étant bloqué sur la partie communication. Par la suite du projet lorsque nous aurons établi une connexion avec la pile, nous pourrons aborder l'aspect programmation lié à cette face avant pour réaliser la commande et la supervision.
Semaine du 14 au 20 septembre
Solution communication CAN
Nous avons pu rencontrer Matthieu BRESSEL et discuté de différentes solutions pour récupérer les données de la PAC. Plutôt que de se positionner en série après le convertisseur CAN vers USB, nous en avons conclu que la meilleure idée est de sniffer le CAN à l'arrière de la pile.
Comme on peut le voir sur la photo ci-contre, il y a trois possibilités de récupération des données CAN :
- en haut de chaine, juste avant le PC panel
- en entrée/sortie du convertisseur DC/DC
- en fin de chaine, au niveau de la pile
Le mieux serait de se placer en haut de la chaîne, afin de pouvoir récupérer les données à la demande et non pas recevoir tout le flux de données comme en fin de chaîne. De plus, nous pourrions y envoyer la commande de différents éléments.
Comme dit plus tôt, l'objectif est de sniffer la communication CAN. Nous avons tout d'abord pensé à un shield CAN Arduino. Cependant cette solution prend énormément de temps (commande du matériel, réalisation du code, etc).
Heureusement, Polytech dispose de PC sniffeur CAN dans la salle C001, que nous avons utilisé l'année dernière dans le cadre des TP Réseaux industriels. Ce PC comporte le logiciel N SI527 qui permet d'établir une communication CAN et tester la récupération/envoie des données.
Recherches et réalisation d'un devis pour du matériel permettant la communication CAN via LabVIEW
Après avoir réussi à sniffer le bus CAN de la pile à l'aide de la carte d'interface NSi527 et du logiciel associé, il fallait donc trouver une solution pour pouvoir réaliser les mêmes fonctions mais cette fois à partir de LabVIEW pour pouvoir récupérer les trames et donc récupérer les valeurs des différents capteurs ce qui permettra de réaliser la commande et la supervision du système.
Pour cela nous nous sommes donc orientée vers la recherche de matériel National Instruments. Nous avons trouvé une carte d'interface CAN compatible avec le module CompactDAQ déjà en place dans la salle.Il nous suffira donc juste d'enficher cette carte d'interface afin de pouvoir récupérer les trames qui transitent sur le bus CAN mais aussi réinjecter des trames de commandes.
Voici la carte d'interface en question:
vers le module d'interface CAN NI-9862
Il dispose d'un port CAN avec une impédance interne de 120 ohms et il peut supporter des réseaux CAN communiquant à des vitesses maximum d'1Mbits/s. Le bus communique à une vitesse de 500Kbits/s et les ports ont une impédance interne de 120 ohms, le module d'interface supporte donc le bus CAN du système que l'on souhaite superviser.
Semaine du 21 au 27 septembre
=Documents Rendus=
