IMA5 2019/2020 P13 : Différence entre versions

De Wiki de Projets IMA
(→‎Semaine du 16 au 22 décembre)
(→‎Livrables)
 
(85 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 453 : Ligne 453 :
  
 
Nous avons testé ce VI dans un VI test comprenant l'association entre la communication CAN et la communication USB. L'envoi et la réception de valeurs sont toujours fonctionnels pour les deux communications. Nous pouvons donc ajouter cette partie de code dans le VI principal. Quelques ajustements seront bien sûr faits pour n'avoir que l'affichage des valeurs finales. Pour l'instant, la requête état du système ne sera pas prise en compte car pas utilisée dans HEL.<br>
 
Nous avons testé ce VI dans un VI test comprenant l'association entre la communication CAN et la communication USB. L'envoi et la réception de valeurs sont toujours fonctionnels pour les deux communications. Nous pouvons donc ajouter cette partie de code dans le VI principal. Quelques ajustements seront bien sûr faits pour n'avoir que l'affichage des valeurs finales. Pour l'instant, la requête état du système ne sera pas prise en compte car pas utilisée dans HEL.<br>
 +
 +
==Semaine du 6 au 12 janvier ==
  
 
===Trames TCP/IP===
 
===Trames TCP/IP===
−
Sous les conseils du jury lors de notre soutenance, nous avons repris l'étude des trames reçues sur le bus éthernet afin de prouver qu'un reverse engineering n'est pas faisable. <br>
+
Sous les conseils du jury lors de notre soutenance, nous avons repris l'étude des trames reçues sur le bus éthernet. <br>
−
''' à compléter '''<br>
+
 
 +
L'échange de données entre le panel PC et notre PC s'effectue de manière continue. Les données qui transitent sur le réseau CAN, RS 485 et USB sont centralisé sur le panel PC qui les envois en continu au PC via la liaison TCP/IP. Le protocole de communication n'est pas de type requête/réponse ce qui complique la rétro-engineering qui permettrait de faire correspondre les valeurs que l'on modifie sur le système avec celles que l'on reçoit. En effet cela aurait été plus simple si le PC envoie des requêtes de demande des données uniquement de la charge par exemple et que les informations qui ne concernent que la charge soient renvoyées sur une seule trame. Ce n'est pas le cas ici mais nous avons essayé différents tests.
 +
 
 +
Nous enregistrons les trames sur Wireshark pour plusieurs tests isolant les communications : d'abord aucune communication n'est reliée au panel PC (ni CAN, ni RS, ni USB), puis uniquement la liaison RS, uniquement la liaison USB et uniquement la liaison CAN.<br>
 +
 
 +
'''Premier cas, trames du PC vers panel PC ( IP 192.168.0.2 vers IP 192.168.0.1)'''<br>
 +
Dans les trois tests : trames de longueur 54 octets, aucun octet de données.<br>
 +
 
 +
'''Deuxième cas, trames du panel PC vers PC = les données (IP 192.168.0.1 vers IP 192.168.0.2)'''<br>
 +
* pour aucune communication, uniquement RS ou uniquement USB, on a : longueur 847 avec 793 octets de données.
 +
* pour seulement CAN, longueur 947 avec 893 octets de données
 +
On remarque que sur les 20 dernières lignes de paquets, on arrive à trouver des similitudes, et notamment à isoler les paquets associés à la communication RS et à la communication USB : c'est ce que montrent les captures ci-dessous (entre temps un test avec la communication CAN et RS a été réalisé pour appuyer nos résultats).<br>
 +
[[Fichier:Id paquets usb rs.png|thumb|left|700px|identification des paquets correspondants aux données RS et USB]]<br style="clear:both" />
 +
 
 +
La correspondance de ces différents paquets d'octets en code ASCII ne donne rien d'exploitable il va donc également falloir trouver en quelle unité il faut convertir les paquets pour pouvoir faire correspondre de possible valeur avec les valeurs indiquées par l'interface homme-machine. On remarque également que la dernière partie de la trame où l'on voit indiqué "High Capacity" dans la correspondance en ASCII correspond aux valeurs de configuration des batteries (état de charge, profondeur de charge) qui sont contenues dans un fichier sur le panel PC mais uniquement les indicatifs nominaux sont remarquables dans cette trame.
 +
 
 +
Sur le système de pile à combustible la charge communique au panel PC uniquement 3 valeurs, la valeur de tension, de courant et de puissance dans la charge. Nous avons donc modifié la valeur de tension dans la charge et réaliser une capture de trame lorsque la tension est à 0 et lorsqu'elle est a 26V. Voici le résultat de la comparaison entre les deux trames:  <span
 +
 
 +
 
 +
Cependant, pour le test avec uniquement la communication CAN, énormément de données sont transmises. Par curiosité, nous avons cherché si les paquets pouvaient correspondre aux paquets détaillés sur les documentations CAN, mais sans surprise aucune correspondance n'est possible. Ayant déjà réussi à reprendre les données circulant sur ce bus, nous n'irons pas plus loin par rapport à la communication CAN. <br>
 +
De la même manière que pour le CAN, les paquets correspondant aux données du bus USB ne correspondent pas à la documentation que nous avons pu trouver précédemment (sans surprise une nouvelle fois). Comme les paquets sont assez petits, et la charge assez facile à faire varier, nous allons tout de même essayer de retrouver les données. Cela nous permettrait d'ailleurs de connecter la charge au panel PC tout en recevant les valeurs sur PC, ce qui n'est possible lorsque l'on lit les données du bus USB via Labview (comme expliqué en décembre). <br>
 +
Nous allons donc essayer par la suite de trouver des liens entre les données reçues sur le logiciel HEL et les paquets circulants sur le bus Ethernet pour identifier les valeurs sur le bus RS485 et USB.<br>
 +
 
 +
Un problème survient : <br>
 +
Lorsque l'on associe plusieurs communications (notamment CAN avec RS), d'autres trames sont transmises du panel PC au PC. N'ayant pas eu le temps de faire beaucoup plus de tests avant les vacances, nous ne pouvons pas encore avancer sur ces points. En effet, pour le moment nous avons de nouveau des problèmes de batterie associée à la pile à combustible, due à sa non-utilisation pendant les vacances. De ce fait, aucun test n'est possible </span>(nous n'arrivons pas à démarrer la pac ni le panel PC donc aucune communication n'est possible) que ce soit au niveau du bus Ethernet, des tests RS485 de décembre, etc.<br>
 +
 
 +
==Semaine du 13 au 19 janvier ==
 +
 
 +
Lors de cette semaine, nous sommes restés bloqués dû au problème de batteries (une commande est en cours). Cela nous empêche d'effectuer une quelconque connexion à la pile à combustible (panel PC ne s'allume pas) et donc d'avancer sur le RS, les trames tcp/ip, la charge, etc.<br>
 +
 
 +
Nous avons donc décidé de nous tourner vers d'autres points du projet, et notamment la mise en commun de l'interface faite par François Xavier l'année dernière avec la notre. Nous avons réussi à fusionner les Labview après quelques mises à jour et problèmes de compatibilité. Nous avons donc ajouté l'interface de 2018 dans un nouvel onglet. <br>
 +
Cependant, même si à première vue il n'y a pas l'air d'avoir de problème, nous ne pouvons pas entièrement vérifier la fusion car il semblerait y avoir un soucis d'automate sur le bloc Heliocentris (Power management) sur lequel travaillent les étudiants en Master. Après avoir vu avec le thésard Sumit qui n'a pas trouvé l'erreur, nous avons contacté les étudiants en Master. En fin de semaine, ils nous ont confirmé qu'un des composants était grillé (arrivé pendant les vacances) et qu'il ne sera sûrement pas remplacé d'ici la fin de notre PFE. <br>
 +
 
 +
Malgré ces contre-temps, nous essayons de ne pas perdre trop de temps. Nous avons repris la piste du Moteur en tant que charge externe pour simuler l'utilisation de l'énergie issue de la PAC par une voiture. Après y avoir réfléchi et vu les nombreuses difficultés associées (difficultés matérielles), nous avons discuté avec M. Matthieu Bressel (qui nous avait orienté sur la connexion CAN en début de projet) qui nous a conseillé de plutôt réaliser une simulation de moteur sur la charge déjà existante, en s'inspirant notamment du [https://fr.wikipedia.org/wiki/Nouveau_cycle_europ%C3%A9en_de_conduite Nouveau cycle européen de conduite] (NEDC, New European Driving Cycle).<br>
 +
 
 +
===Cycle de conduite===
 +
Un cycle de conduite est un test s'appliquant aux voitures entrant sur le marché pour déterminer leur consommation en carburant ainsi que leurs émissions de substances polluantes. Ces tests sont effectués sur des bancs à rouleaux et sont censés simuler des conditions de conduite plus ou moins réalistes.<br>
 +
Avant 2017, le test utilisé était le NEDC, mais désormais le [https://fr.wikipedia.org/wiki/Proc%C3%A9dure_d%27essai_mondiale_harmonis%C3%A9e_pour_les_voitures_particuli%C3%A8res_et_v%C3%A9hicules_utilitaires_l%C3%A9gers cycle WLTP] (Worldwide harmonized Light vehicles Test Procedures) est entré en vigueur. Après quelques années de cohabitation entre les deux tests pour faciliter la transition aux constructeurs, à partir de 2020 la réglementation exige l'utilisation du WLTP plutôt que du NEDC, qui se veut beaucoup plus réaliste. Comme nous sommes justement début 2020, nous avons décidé de travailler sur le cycle WLTP dans un soucis de correspondance avec l'actualité.<br>
 +
Comme dit plus tôt, le cycle WLTP permet donc d'être plus réaliste puisque, par exemple, il prend désormais en compte le poids et les accessoires du véhicule, la durée et distance du test sont plus importantes tout comme la vitesse moyenne et la vitesse maximale. Les conditions météorologique et les situations de conduite sont adaptées. [https://beev.co/fiscalite/cycle-wltp-quelles-differences-avec-le-cycle-nedc/ Ce lien] entre un peu plus en détails sur les différences entre le cycle WLTP et le NEDC.<br>
 +
Au niveau de l'impact sur les véhicules, le cycle WLTP permet de montrer une hausse de la consommation et émission des véhicules thermiques, et pour les véhicules thermiques une baisse de leur autonomie. Cependant, ce cycle introduit [https://www.automobile-propre.com/cycle-wltp-ce-qui-change-pour-les-voitures-electriques-et-thermiques/ différents types d'utilisation] (urbain, extra-urbain,...) et les constructeurs peuvent comme toujours essayer de valoriser leurs véhicules électriques en mettant en avant la valeur urbaine de ces derniers.<br>
 +
Pour finir, ce cycle permet d'encourager les constructeurs à travailler sur leur [https://www.caradisiac.com/le-cycle-wltp-a-aussi-un-impact-sur-les-voitures-electriques-180046.htm gestion de l'énergie] et amélioration de leur batterie pour être plus compétitifs.<br>
 +
 
 +
==Semaine du 20 au 26 janvier ==
 +
Cette semaine à partir du mercredi, nous avons pu effectuer de nouveaux tests sur la pile à combustible. Le système possédait une batterie et un fusible défaillant se qui forçait la mise en sécurité et empêchait la mise en route de la pile. Une solution a été trouvée en attente de la réception de la commande de la nouvelle batterie et du nouveau fusible, un technicien a conçu un fusible de fortune qui permet de faire fonctionner la pile sur les plus petite batteries. nous avons donc pu reprendre nos tests pour récupérer les données qui transitent sur les communications RS 485 et USB.
 +
 
 +
 
 +
===RS 485===
 +
[[Fichier:DCONcommand.png|thumb|300px|left|trames de commandes]]
 +
[[Fichier:DCONreponse.png|thumb|300px|left|trames de réponses]]
 +
[[Fichier:Detection_RS.png|thumb|500px|right|Détection du module sur DCON Utility Pro]]
 +
 
 +
 
 +
 
 +
Dans un premier temps, nous avons voulu revérifier la configuration du module ICPDAS 7019R. Nous avons donc lancé le logiciel DCON utility, qui permet la configuration du module, directement sur le panel PC. Nous avons pu noter l'adresse du module, le baud rate, le nombre de bits de stop et tous les paramètres de la liaison série entre le panel PC et le module I-7019R. <br>
 +
Des recherches ont également été effectuées pour comprendre le protocole de communication "DCON" utilisé par le module. Les communications avec les modules I-7000 se composent de commandes générées par l'hôte et de réponses transmises par les modules I-7000.Chaque module possède un numéro d'identification unique qui est utilisé à des fins d'adressage et est stocké dans une mémoire non volatile. L'ID est 01 par défaut et peut être modifié à l'aide d'une commande utilisateur. Dans notre cas l'ID est configuré sur 00. Toutes les commandes des modules contiennent l'adresse ID, ce qui signifie que seul le module adressé répondra. On peut voir ci-contre le format des trames de commandes et de réponse : <br>
 +
 
 +
Toutes ces trames sont envoyées sous format ASCII. Le calcul du checksum est relativement simple puisqu'il suffit de calculer la somme du code ASCII de tous les caractères de la chaîne de commande / réponse, à l'exception du caractère de retour (CR). La somme de contrôle est égale à la somme masquée par 0ffh.<br>
 +
Un envoi d'une requête de commande permettant de récupérer toutes les valeurs analogiques des différents capteurs connectés au module a été envoyé grâce à PuTTY au module à partir du panel PC et nous avons bien récupéré les valeurs des capteurs.<br>
 +
 
 +
L'objectif qui suivait était donc de réaliser la même chose à partir de notre PC. Dans un premier temps nous avons recréé un montage permettant la connexion entre le module et notre PC grâce à un convertisseur RS-485 to USB. Une fois le port COM détecté, nous avons essayé de lancer le logiciel DCON_Utility afin de détecter le module. Cette fois-ci nous arrivons bien à détecter le module ICPDAS 7019R, ce que nous parvenions pas avant les vacances du fait de notre mauvaise configuration matérielle. En effet, cette semaine nous avons abandonné le fait de se coupler à la connexion RS déjà existante, et maintenant nous remplaçons le panel PC de la même manière qu'avec la charge.<br>
 +
 
 +
Nous avons donc réeffectué le test avec PuTTY et nous arrivons également à récupérer les valeurs analogiques des différents capteurs via la communication RS-485 à partir de notre PC. <br>
 +
[[Fichier:RS-485_putty.png|thumb|500px|center|Requête de demandes des valeurs analogiques des capteurs connectés au module]]
 +
 
 +
La dernière partie à faire est donc de pouvoir communiquer avec le module ICPDAS via la communication RS-485 depuis notre PC mais cette fois en développant un algorithme sur LabVIEW afin de compléter notre interface qui sera dans ce cas complète et comportera toutes les données provenant de tous les capteurs du système. Pour cela un test a été effectué mais des erreurs de réception des réponses se présentent pour le moment.<br>
 +
<br style="clear:both" />
 +
 
 +
===USB - Charge électronique===
 +
 
 +
Nous avons également repris le Labview de la charge. Précédemment, nous avions réussi à récupérer les données de tension, courant et puissance via l'envoie d'une trame de manière manuelle.<br>
 +
Cette semaine, nous avons amélioré le VI en reprenant et décortiquant la documentation de la charge ainsi que les tests effectués avant les vacances avec le Beagle12.<br>
 +
* Envoie cyclique des requêtes 71 et 70 (lecture variable et état système)
 +
* Ajout d'une condition permettant la lecture de l'état de la charge (mode utilisé, input ON/OFF, mode de régulation, etc). Pour cela nous avons décortiqué la trame de réponse de la requête 70 (0x46).<br>
 +
* Boutons ON/OFF de Remote et Input avec la requête 54 (0x36)
 +
Nous avons pu bien vérifier que les envoies de changement d'état sont effectués grâce à la lecture de l'état de la charge, et pour le Remote, cela est directement indiqué sur le panneau de la charge.
 +
* Début de code pour contrôler le mode de régulation et le level avec la requête 54, pas encore de test d'envoie sur la charge
 +
Cela fonctionne correctement en parallèle avec la communication CAN.<br>
 +
Voici la documentation avec laquelle nous travaillons pour connaitre les requêtes à envoyer à la charge: [[Fichier:Object list el3000 el9000 de en.pdf]]<br>
 +
[[Fichier:CHARGE VI janv.JPG|thumb|left|600px|Détails du VI de la connexion avec la charge au mois de janvier]]<br style="clear:both" />
 +
 
 +
=== Interface avec Onglets ===
 +
 
 +
Cependant, nous avons eu des problèmes avec l'interface globale. En effet, il s'avère que l'utilisation de la Commande Onglet était mal réalisée : les données s'actualisaient uniquement au moment du RUN. Nous avons donc tout remettre en place, ce qui n'était pas compliqué mais fastidieux.<br>
 +
De plus, la semaine dernière nous avions ajouté le ''Solar panel Management Monitor'' du PFE 2018. Il s'est avéré cette semaine lorsque nous avons pu vérifier notre VI, qu'il ne fonctionne pas avec la communication de la charge en même temps. Nous n'avons pas encore trouvé la raison.<br>
 +
 
 +
==Semaine du 27 janvier au 2 février==
 +
 
 +
===USB - charge électronique===
 +
* amélioration de la structure du code avec de nombreux Structure Case (pour éviter des blocs IF trop nombreux)
 +
* envoie de requêtes sécurisé avec la mise en place de boutons grisés si le système n'est pas en Remote, afin d'éviter des erreurs d'envoie et réception. On peut voir sur l'onglet 1 (paragraphe Interface) le mode remote activé et les boutons disponibles, et sur les onglets 2 et 3 le free access avec les boutons grisés.
 +
* envoie de la requête 54 avec contrôle du level, fonctionne avec vérification par la trame décrivant l'état du système
 +
* mise en place des requêtes de changement de type de régulation et Set de valeurs. Mais problème non identifié (trames correctes par rapport à la documentation) et ces commandes ne fonctionnent pas. Nous attendons de re récupérer le sniffer Beagle 12 de M.Vantroys pour étudier les trames envoyées par le panel PC vers la charge.
 +
 
 +
===RS485===
 +
[[Fichier:RS485 vi labview.JPG|thumb|400px|right|Méthode de séparation des 7 valeurs des capteurs reliés au bus RS-485]]
 +
La semaine dernière nous étions bloqués sur la partie communication série via le bus RS485 depuis LabVIEW. Après recherches nous avons identifié le problème qui provenait du caractère de terminaison des trames envoyées et reçues sur ce bus.Nous avons donc fait en sorte qu'un carriage return (\r) soit envoyés et reçus en fin de chaque trame et nous avons donc bien reçu l'intégralité des données provenant des capteurs connectés au module IICPDAS 7019R connecté au bus RS-485 relié à notre PC.<br>
 +
Nous avions le choix pour récupérer les valeurs de chaque port analogique:
 +
*Soit nous envoyons les 7 requêtes correspondant chacune à la demande d'un retour de valeur d'une entrée analogique correspondant.<br>
 +
*Soit nous envoyons la requête permettant de récupérer une seule chaîne de caractères et nous travaillons sur celle-ci afin de récupérer chaque valeur en trouvant la bonne approche pour séparer les valeurs.<br>
 +
 
 +
Nous nous sommes orientés vers la seconde solution car nous avons remarqué que les valeurs sont décrites avec le même nombre de caractères. Il suffisait donc simplement de faire une séparation en fonction de la longueur des valeurs afin de récupérer les 7 valeurs qui nous intéresse. Le diagramme de programmation,présent dans la vignette ci-contre, illustre la méthode.<br>
 +
 
 +
Une fois les 7 valeurs récupérées, il a donc fallu faire le lien avec celle affichée sur le logiciel Heliocentris. Pour cela nous nous sommes servis du logiciel DCON_utility pro qui permet de sélectionner quel canal analogique on veut utiliser. La méthode de test a donc été de sélectionner un seul canal et de vérifier à chaque fois quelle valeur était correctement affichée uniquement lorsque le bus RS-485 était connecté au système. De ce fait nous avons pu faire la liaison avec les valeurs analogiques reçues et celle affichée sur l'interface.<br>
 +
 
 +
Le dernier souci a été de trouver comment traiter les valeurs que l'on recevait avec des intervalles différents (+5v/-5v; 4mA..20mA). Des fonctions dans LabVIEW nous ont permis de traiter ces données afin qu'elles soient affichées comme elles l'étaientt dans l'interface Heliocentis. Ainsi nous avons pu compléter notre interface globale qui contient désormais toutes les valeurs des capteurs présents sur le système.
 +
 
 +
===Gestion de la pile et DCDC converter via CAN===
 +
 
 +
Nous avons eu quelques problèmes avec la communication CAN pour laquelle nous avons du redéfinir les sessions XNET.<br>
 +
Nous avons ensuite ajouté une partie écriture :
 +
* la gestion de la pile grâce à la requête 500x ainsi que sa réponse dans la requête 310x : cela permet de start, reset et stop la pile de la même manière que sur l'interface Heliocentris.
 +
* la gestion du convertisseur DCDC grâce à la requête 490x. Pour l'instant, elle ne fonctionne pas : en effet, la req490 est une requête envoyée constamment du panel pc vers le système. De ce fait, il semblerait qu'il y ait un conflit lorsque nous envoyons nous-même cette trame et de ce fait cela bloque le pc panel. Dans tous les cas, la trame envoyée ne semble pas démarrer le convertisseur, alors qu'elle correspond à celle lue sur NI NXET Monitor. Nous n'avons pas encore résolu ce problème.<br>
 +
 
 +
===Interface globale===
 +
Nous avons avancé sur les problèmes rencontrés la semaine dernière. Désormais, les onglets de l'interface globale sont entièrement fonctionnels (plus de problème d'actualisation). Sur cette interface se trouve les données issues de la communication CAN, des données de la charge, celles de la communication RS485 et l'interface du PFE 2018. Sur le côté gauche se situe une partie Commande, où il est possible de gérer une partie de la charge (depuis la comm USB) ainsi que la gestion de la pile (depuis le CAN). <br>
 +
Pour cela, nous avons repris complètement le VI associé. Nous avons utilisé la fonction onglet pour l'affichage des données uniquement en ce qui concerne le CAN. <br>
 +
Nous avons également retravaillé le VI de François-Xavier en réduisant le nombre de boucles while en une seule. Nous avons ajouté un paramètre de connexion au DAQ qui manquait. Enfin, pour associer les trois communications nous rentrons les parties de code associées à la connexion DAQ à notre boucle principale de récupération des données de la charge. Cela ralentit l'acquisition des données de François-Xavier mais permet une communication fonctionnelle avec la charge.<br>
 +
Voici ci-dessous l'interface Labview à ce jour, avec les trois onglets différents.<br>
 +
[[Fichier:O1 janv.JPG|400px|page 1 face avant Labview]]
 +
[[Fichier:O2 janv.JPG|400px|page 1 face avant Labview]]
 +
[[Fichier:O3 janv.JPG|400px|page 1 face avant Labview]]
 +
<br style="clear:both" />
 +
Cette interface est donc complète en terme d'acquisition de données. Il y manque la gestion du convertisseur DC DC ainsi que l'envoie de commande des valeurs de référence de la charge mentionnés plus tôt. De plus, la première connexion à la charge n'est pas toujours un succès et nous aimerions résoudre ses bugs. <br>
 +
Le fait de bloquer sur l'envoie de commande à la charge nous empêche d'avancer comme nous le souhaiterions sur la simulation de cycles. Nous espérons que le sniffer Beagle nous débloquera (demandé mais M. Vantroys indisponible cette semaine)<br>
 +
 
 +
==Semaine du 3 au 9 février==
 +
===HEL Remote du fournisseur===
 +
 
 +
Cette semaine nous avons voulu tester l'API délivrer par Heliocentris que nous avions reçu une fois demandé à l'entreprise. Cette interface de programmation permet de récupérer la plupart des valeurs des capteurs du système mais aussi de contrôler la pile à combustible ainsi que le convertisseur DC/DC. Après étude du diagramme de l'API sur Labview, nous avons vu que le programme utilise des variables PSP. Ce sont des variables qui sont publiées sur un réseau par un autre programme labview par le biais d'un URL qui permet donc à d'autres programmes de récupérer les valeurs associées à ces variables partagées afin de les exploiter.<br>
 +
 
 +
Nous avons donc essayé de lancer l'API en lecture et en écriture mais nous n'avons pas réussi à récupérer les valeurs de ces variables partagées et cela même malgré l'aide de monsieur Conrard qui a des connaissances en programmation LabView. Le problème semblerait venir de l'accès à ces variables qui ne se réalise pas. Nous pousserons nos recherches dans la semaine à venir si nos différents objectifs sont remplis.<br>
 +
 
 +
===Analyse trames TCP/IP===
 +
Pendant la première soutenance, un travail de fond sur les trames TCP/IP a été demandé afin de prouver qu'un reverse engineering était réellement compliqué à mettre en place et que le fait de lire les bus en aval du panel PC est justifié. Voici ci-dessous le fichier reprenant les premiers tests menés début janvier ainsi que la suite cette semaine. <br>
 +
''Rapport d'analyse des trames TCP/IP : [[Fichier:Identification des trames TCP_IP.pdf]]''<br>
 +
Pour résumer, les données issues du CAN sont trop nombreuses et non isolables donc extrêmement difficiles (pour ne pas dire impossible) à identifier et comprendre. Celles du RS485 sont elles facilement identifiables mais nous n'avons pas réussi à trouver la conversion permettant de retrouver la valeur réelle des variables. Pour les données du bus USB (données de la charge), certaines données d'état sont identifiables et compréhensibles, mais pour les valeurs de courant tension et puissance nous n'avons pas réussi à retrouver les valeurs réelles pour les mêmes raisons que les données du bus RS485. <br>
 +
 
 +
===Gestion de la charge===
 +
Nous n'avons finalement pas eu de réponse de M. Vantroys par rapport au Beagle 12 mais nous avons réussi à retrouver les trames circulant sur le bus en installant Serial Bus Monitor sur le panel PC. Cela nous a permis de régler le problème de régulation, et pour les consignes de valeurs U, I, P nous avons fait un petit reverse engineering où nous nous sommes rendus compte d'un oubli dans la documentation.<br>
 +
Durant cette semaine, nous avons beaucoup amélioré l'expérience utilisateur en réglant le plus de bugs pouvant apparaître. Nous avons eu de nombreuses difficultés avec la gestion de type en programmation Labview, ainsi que les requêtes cachées mais nécessaires à la charge.<br>
 +
 
 +
SET VALUES
 +
* Changement du types de conversion des données en lecture en écriture selon la documentation (apparition d'un pourcentage) avec changement des valeurs nominales selon ce que l'on a pu déduire
 +
* Envoie de la nouvelle valeur de consigne lorsque celle-ci est modifiée (structure événement)
 +
* Bouton grisés en fonction du mode de contrôle choisi pour éviter les bugs (U disponible en CV, I en CC, P en CP et tous requièrent l'input ON activé)
 +
 
 +
SET REGULATION
 +
* Envoie de la régulation choisie lorsque celle-ci est modifiée (structure événement) donc plus besoin de bouton de validation
 +
* Séquence d'envoie de requêtes avec d'abord check Remote ON et input OFF, changement de régulation, valeurs initiales de I et P (établies grâce au sniffer série), puis input ON afin d'éviter toute erreur
 +
* Toujours quelques bugs lorsque le contrôle en tension est choisi sur l'interface physique de la charge, mais cela n'a pas l'air d'être dû à la programmation.
 +
* Inspirés par l'interface HEL, seuls les modes de contrôle CC et CP sont accessibles, même si l'on sait au besoin que les autres modes peuvent être rajoutés.
 +
 
 +
INTERFACE USER-FRIENDLY
 +
* Le Remote Off (accès libre à l'interface physique) n'est disponible qu'en Input Off
 +
* Le input ON/input OFF n'est disponible qu'en Remote ON
 +
* La liaison série est désormais correctement fermée à chaque fin d'utilisation (Close de la connexion), après un bloc de fin (Input Off, Remote Off automatique), le tout exécuté après une erreur sur la connexion ou l'appui d'un bouton stop commun à toutes les boucles (stop également commun à la boucle RS)
 +
* Présence d'un bloc d'initialisation au début de la connexion : mode Remote ON, Level A et input OFF. Désormais, seulement le mode Level A est accepté pour éviter d'autres erreurs
 +
* Ce bloc d'initialisation est de nouveau appelé à chaque fois que l'utilisateur passe de ''free access'' à ''remote ON'' afin d'éviter toute erreur. Cela permet d'avoir la possibilité d'être en free access (pas disponible sur HEL du PC) tout en empêchant les bugs une fois le contrôle de nouveau établi sur le PC.
 +
* Une led "fonctionnement de la charge" a été ajoutée dans la face avant et s'allume lorsque la connexion avec la charge est établie
 +
 
 +
===Gestion de la pile===
 +
Nous avons retravaillé la lecture du tableau ''information flags'' issu du CAN permettant d'avoir les valeurs d'ouverture/fermeture des vannes ainsi qu'un bit de fonctionnement/arrêt de la pile, car nous avions commis des erreurs en début de projet. Cela a permis la mise en place de sécurités pour l'utilisateur afin d'avoir une expérience user-friendly :
 +
* Bouton stop grisé tant que la pile n'est pas en fonctionnement
 +
* Bouton start grisé pendant le fonctionnement de la pile jusqu'à la fin de l'arrêt (utilisation d'une structure événement)
 +
 
 +
Cependant, nous n'avons pas pu effectuer énormément de nouveaux tests car en fin de semaine il nous a été impossible de démarrer le système (mise en défaut automatique) alors que les batteries n'ont aucun problème (nous les rechargeons désormais régulièrement et nous avons vérifié la tension à leur borne) et les connexions à l'arrière n'ont à priori pas de problème.<br>
 +
 
 +
===Cycles sur Labview===
 +
 
 +
Dans la suite de notre projet, l'idée d'appliquer un cycle de véhicule électrique à la charge électronique de notre système a déjà été citée précédemment dans ce wiki. Pour compléter cet objectif nous avons donc essayé cette semaine d'envoyer différentes valeurs en courant à la charge de manière cyclique qui répondrait donc à la demande de vitesse du cycle du véhicule. Pour cela nous avons tout d'abord écrit un script Matlab qui créé deux tableaux, l'un qui contient les valeurs en courant et l'autre qui contient les valeurs de temps liés aux valeurs de courant.<br>
 +
[[Fichier:diagramme_test_charge.jpg|thumb|300px|right|Diagramme illustrant l'exploitation des tableaux grâce à un script Matlab]]
 +
[[Fichier:graphe_test_charge.jpg|thumb|300px|right|Consigne en courant et trames envoyées à la charge sous forme de graphe]]
 +
 
 +
Labview permet également d'exploiter les scripts Matlab et donc d'exploiter les tableaux associés. Nous avons affiché sous forme de graphe dans un premier temps  la consigne du cycle de courant qui devait être injecté dans la pile ainsi que les valeurs associés aux trames de "set values" en courant envoyées à la charge. Nous obtenions le bon cycle en courant mais comme plusieurs valeurs étaient négatives nous n'avons pas choisi ce cycle pour le tester sur la charge.<br>
 +
 
 +
Nous avons modifié le script Matlab afin d'obtenir un "step"(0 pendant un certain temps puis 1 pour le reste du temps et les valeurs associées aux trames envoyées correspondent toujours bien à la consigne.<br>
 +
 
 +
Nous n'avons pas encore testé l'envoi du cycle à la charge car nous souhaitons instaurer une sécurité au niveau de l’accès à la charge durant l'envoie du cycle en courant ainsi que vérifier la fiabilité des trames en lisant les valeurs reçues lorsqu'on envoie de manière continue une requête de "request value" en courant.<br>
 +
 
 +
===Cycles sur Matlab===
 +
Comme expliqué quelques semaines plus tôt, nous avons pour but de réaliser une simulation de test de véhicule électrique avant sa mise sur le marché en lui faisant subir un cycle de conduite (ECE, WLTP, ...). Notre charge externe représenterait donc ce véhicule.<br>
 +
Nous avions vu que ces cycles imposent donc une vitesse afin de connaître la consommation/autonomie du véhicule. Pour notre charge, nous pensons imposer un courant et il faut donc travailler sur une conversion vitesse vers courant.<br>
 +
 
 +
Pour cela, nous retravaillons les cours de VEH et REM que nous avons eu pendant notre cursus IMA. La REM (Représentation Energétique Macroscopique) permet de mettre sur papier les différents éléments composants un système (vision globale) tout en respectant la causalité des événements. Elle permet ensuite de réaliser une SMC (Structure Maximale de Commande) qui correspond à la REM inverse afin de retrouver la commande du système pour une valeur de sortie souhaitée. Grâce à cela, on peut alors retrouver le courant à imposer à la charge correspond à une vitesse.<br>
 +
 
 +
Nous sommes entrain de travailler sur la REM et SMC de notre cas et nous avons donc vu avec Mme Semail quel courant injecter dans notre charge, qui serait celui en sortie de MCC. Cependant, lors d'une phase de freinage, le courant devient négatif. Or, notre charge ne peut pas recevoir de consigne négative. C'est très dommage car cela compromet notre volonté de suivre un cycle de test type WLTP, qui contient forcément des zones de freinage pour tester au mieux les réactions des véhicules. Nous allons devoir ajuster ces cycles en transformant les moments de freinage en moment de "roue libre" soit un courant nul. Cela forcément perd de son sens mais cela reste intéressant de pouvoir imposer à la charge des cycles et non pas simplement des valeurs. Si la charge venait à être modifiée ou si une autre type de charge venait à être ajouté, nos travaux pourraient alors prendre plus de sens. <br>
 +
Plus de détails sur le simulink sera donné dans la semaine prochaine une fois qu'il sera fonctionnel.<br>
 +
 
 +
==Semaine du 10 au 16 février==
 +
===Réinitialisation du convertisseur===
 +
Depuis le début du projet nous avions un problème avec le convertisseur DC/DC du système. On ne pouvait plus démarrer le convertisseur même en réinitialisant à chaque fois celui-ci par le biais de l'interface HEL. L'erreur "DC/DC over critical voltage battery" s'affichait et revenait à chaque fois après n'importe quelle manipulation.<br>
 +
 
 +
Il était encore jusqu'à cette semaine impossible de recharger les batteries via la pile à combustible ce qui est le principe et l'avantage de ce système.<br>
 +
 
 +
Voulant régler ce souci nous avons donc demandé de l'aide à la personne qui a vendu le système à l'école.<br>
 +
Cette personne a fait le relais entre l'entreprise qui a produit le système et nous a donc indiqué comment réinitialiser les paramètres de configuration du convertisseur depuis l'interface ce qui a permis de refaire fonctionner le convertisseur DC/DC correctement.<br>
 +
 
 +
Le système peut donc de nouveau recharger les batteries depuis la pile à combustible.<br>
 +
 
 +
===Gestion du convertisseur DC/DC===
 +
Une fois l'erreur, au niveau du convertisseur, supprimée nous avons pu approfondir la commande du convertisseur qui jusqu'ici ne permettait que la réinitialisation de celui-ci. Des améliorations ont été produite afin que l'on puisse démarrer, éteindre ou réinitialiser le convertisseur depuis notre interface.<br>
 +
 
 +
Nous avons également ajouté la commande de la valeur en courant désirée pour recharger les batteries ou bien alimenter une charge en sortie du convertisseur DC/DC. Cette option était disponible sur l'interface développée par Heliocentris, on a donc décidé de trouver comment intégrer cette commande sur notre interface.<br>
 +
 
 +
En effectuant un "reverse engineering" via la modification de la valeur de commande, nous avons pu déterminer l'allure de la trame d'identifiant 490 qui est envoyée par le panel PC au convertisseur via le bus CAN.<br>
 +
 
 +
En réalisant l'envoi de cette trame via notre interface nous avons donc réussi à intégrer la commande de la valeur en courant en sortie du convertisseur.<br>
 +
 
 +
===Acquisition de données===
 +
Pour améliorer notre interface, nous avons décidé de donner la possibilité aux utilisateurs d'enregistrer les différentes valeurs présentes sur l'interface sur un temps d'enregistrement que l'utilisateur décide (il lance l'acquisition puis l'arrête quand il le souhaite).<br>
 +
 
 +
Les valeurs sont enregistrées à une fréquence décidée également par l'utilisateur et sont envoyées dans un fichier de type CSV, exploitable avec un tableur comme Excel ou LibreOffice Calc.<br>
 +
 
 +
Pour réaliser cette amélioration nous nous sommes servi des outils disponibles sur Labview et des exemples sur internet pour intégrer l'ouverture d'un fichier depuis sa racine et l'écriture de valeurs dans celui-ci depuis notre diagramme de programmation.<br>
 +
 
 +
Le tout intégré dans une boucle for, cette amélioration de notre programme a donc permis d'ajouter la possibilité d'acquérir des données depuis notre interface.<br>
 +
 
 +
===Cycle d'un véhicule électrique===
 +
 
 +
Voici le document expliquant la mise en oeuvre du Simulink représentant la REM d'un véhicule électrique : [[Fichier:REM véhicule électrique.pdf]] <br>
 +
De cette étude nous obtenons donc le simulink suivant, et nous récupérons la valeur i_dcm_ref : <br>
 +
[[Fichier:Simulink REM SMC vehicule.JPG|600px|left|thumb|Simulink matlab représentant la REM et SMC d'un véhicule électrique]]<br style="clear:both" />
 +
 
 +
Depuis le fichier d'initialisation associé
 +
* modification de I_dcm_ref (ce qui affecte nécessairement le cycle) pour ne pas avoir de valeurs négative ou trop grande
 +
* ajustement nombre de valeurs pour que la période d'envoi ne soit pas trop rapide (500ms contre 0.001ms à la base)
 +
* travail sur 3 cycles : ECE (3min), NEDC (20min), WLTP (30min)
 +
 
 +
Ci dessous pour les trois cycles ECE, NEDC et WLTP la différence entre le i_dcm théorique à injecter, et celui qui est injecté dans la charge soit toujours positif (avec la vitesse associée). On remarque que la commande fonctionne parfaitement mais, comme le courant n'est pas être négatif dans le deuxième cas, la vitesse réelle a plus de mal à suivre la vitesse de référence car sans l'utilisation des freins, le véhicule ne peut pas freiner depuis le courant.<br>
 +
[[Fichier:Cycle ECE comp charge th.jpg|300px|left|thumb|cycle ECE, comparaison entre le i_dcm théorique celui injecté dans la charge, avec leur v_veh associée]]
 +
[[Fichier:Cycle NEDC comp charge th.jpg|300px|left|thumb|cycle NEDC, comparaison entre le i_dcm théorique celui injecté dans la charge, avec leur v_veh associée]]
 +
[[Fichier:Cycle WLTP comp charge th.jpg|300px|left|thumb|cycle WLTP, comparaison entre le i_dcm théorique celui injecté dans la charge, avec leur v_veh associée]]
 +
<br style="clear:both" />
 +
Le VI Labview associé est composé :
 +
* d'un script Matlab pour récupérer les tableaux (selon le cycle choisi la variable récupérée est différente)
 +
* conversion de la valeur en requête vers la charge
 +
* envoie de valeurs cyclique (toutes les 500ms)
 +
* envoie d'une requête de lecture pour lire la valeur réelle de la charge
 +
* trace un graphe de la valeur de référence, un graphe de la valeur réelle (tracé en temps réel) et et un graphe combinant les deux
 +
La période de 500ms a été choisie afin que le Labview ait le temps d'envoyer à la charge la valeur de référence, puis la requête de lecture de la valeur réelle puis la lecture.<br>
 +
A tout moment l'utilisateur peut décider d'arrêter ce cycle grâce au bouton STOP. <br>
 +
De plus, ce sous-VI est appelé depuis un bouton sur la face avant générale de l'interface, et ouvre une nouvelle fenêtre avec ces graphes pour une meilleure lecture.<br>
 +
Voici ci-dessous un résultat obtenu lors de l'envoi d'un cycle ECE adapté à la charge :<br>
 +
[[Fichier:Cycle ECE labview.JPG|500px|left|thumb|cycle ECE en courant en consigne de la charge depuis Labview, avec référence en rouge et valeur réelle en bleu]]
 +
<br style="clear:both" />
 +
Cependant, quelques problèmes surviennent encore de temps en temps. <br>
 +
 
 +
===Recharge des bouteilles stockées directement dans le système===
 +
 
 +
Jusqu'à maintenant nous rechargions les bouteilles en dehors du système de pile à combustible via l'électrolyseur. Après étude de la documentation nous avons remarqué qu'il était possible de recharger les bouteilles directement lorsqu'elles sont placées dans le système de pile à combustible en connectant directement l'électrolyseur à la chambre de stockage d'hydrogène.<br>
 +
 
 +
Après tests nous avons réussi à recharger les bouteilles en essayant la configuration décrite au-dessus ce qui laisse de nombreuses ouvertures à ce projet.<br>
 +
 
 +
En effet comme nous avons lié l'interface réalisée l'année dernière par FX sur le système de production d'hydrogène, on peut imaginer le développement d'une nouvelle interface permettant le contrôle de l'électrolyseur qui n'est jusqu'ici pas disponible depuis un PC. Cette interface permettra donc, en la liant à la notre et celle de FX, de développer des algorithmes d'automatisation du système de production d'hydrogène et de recharge des bouteilles en fonction de la production des sources d'énergies renouvelables qui est supervisé grâce à l'interface de FX.<br>
  
−
===Charge externe : un moteur===
+
Par exemple, les sources d'énergies renouvelables produisent assez de puissance pour produire de l'hydrogène et donc recharger les bouteilles qui alimentent la pile à combustible qui recharge des batteries ou qui alimentent une charge grâce au convertisseur DC/DC. L'autre cas de figure est donc que la puissance délivrée par les sources d'énergies renouvelables n'est pas suffisante dans ce cas la recharge est interrompue et on passe sur un fonctionnement sur batterie pour l'alimentation d'une charge. Bien sûr tout cela sans que l'homme n'est besoins de sortir les bouteilles du système pour les recharger, qui était la problématique précédente pour l'automatisation, puisque l'on a vu que l'on pouvait recharger les bouteilles en connectant directement l'électrolyseur à la chambre de stockage de bouteille d'H2 du système de pile à combustible.<br>
−
Nous avons cherché quel genre de charge externe ajouter à notre système.<br>
+
 
−
''' à compléter '''<br>
+
===Calcul des puissances===
 +
 
 +
Notre interface indique des valeurs de puissance qui jusqu'ici ne correspondaient pas à celles indiquées par le logiciel Heliocentris car des calculs étaient nécessaires pour retomber sur les valeurs correctes. Durant cette semaine nous avons donc cherché des liens entre les valeurs que nous récupérions et les puissances qui en étaient déduites. Nous avons réussi à retrouver les valeurs de puissance entourées sur la  mais il nous reste des valeurs inconnues.<br>
 +
 
 +
=Livrables=
 +
* Ensemble des tests sur les données TCP : [[Fichier:Identification des trames TCP.pdf]]
 +
* Explications REM et SMC d'un véhicule électrique : [[Fichier:REM SMC vehicule elec.pdf]]
 +
* Dossiers Matlab pour le cycle de commande : [[Fichier:P13 cycles de conduite.zip]]
 +
* Schémas du code Labview : [[Fichier:VI labview final.pdf]] , [[Fichier:VI CAN.pdf]] , [[Fichier:VI charge.pdf]] , [[Fichier:VI RS485.pdf]]
 +
* Rapport de fin de projet : [[Fichier:PFE13 rapport final.pdf]]
 +
* Notice d'utilisation : [[Fichier:Notice d’utilisation PFE2019.pdf]] <br>
  
 
=Documents rendus=
 
=Documents rendus=
  
 
Rapport de mi-projet: [[Fichier:PFE13 rapport intermédiaire.pdf]]<br>
 
Rapport de mi-projet: [[Fichier:PFE13 rapport intermédiaire.pdf]]<br>
−
Diaporama de mi-projet : [[Fichier:PFE13 soutenance intermédiaire.pdf]]
+
Diaporama de mi-projet : [[Fichier:PFE13 soutenance intermédiaire.pdf]]<br>
 +
 
 +
Rapport fin de projet : [[Fichier:PFE13 rapport final.pdf]]<br>
 +
Diaporama de fin de projet : [[Fichier:PFE13 diapo soutenance finale.pdf]]<br>

Version actuelle datée du 19 février 2020 à 17:03

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

Plateforme technologique à disposition

Pile à combustible de la plateforme

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

Avantages des différentes sources d'énergies

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

versions v1 et v2 de stockage de l'énergie

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.

Logiciel Heliocentris de la première partie fourni à l’achat du système complet
Logiciel Heliocentris de la PAC fourni à l’achat

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

interface du système complet réalisée en 2018

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.

commande de l'électrolyseur réalisée en 2018

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

Principe de fonctionnement d'une cellule pour une pile à membrane à échange de protons

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

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

IHM développée sur 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 octobre

Solution récupération de trames du bus CAN

Ports de communication du bus CAN à l'arrière de la PAC

Nous avons pu rencontrer Mathieu 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 bus 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 du bus, juste avant le PC panel
  • en entrée/sortie du convertisseur DC/DC
  • en fin de bus, au niveau de la pile à combustible

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 NSi527 qui permet d'établir une communication CAN et tester la récupération/envoie des trames de données.

Réception des trames sur sniffer CAN

Système pour sniffer le bus CAN, avec la PAC à gauche, le PC sniffer CAN au milieu et l'écran avec l'interface NSI527 à droite

La première étape fut de vérifier que nous recevons bien les données du bus CAN sans qu'elles soient cryptées comme pour l'éthernet. Nous nous sommes donc connecté comme le montre la photo ci-contre avec le PC sniffer CAN.
Nous avons réalisé 2x3 tests : comme expliqué dans la partie précédente, il y a trois possibilités de récupération de données CAN. Pour chacune de ces possibilités, nous avons essayé de récupérer les trames avec et sans connecter le PC panel. Nous obtenons les résultats suivants :

  • en fin de chaîne (en bas), on récupère un flux constant de trames de données si la pile est allumée et si le bouton start est enclenché (mais pas besoin du pc panel allumé)
  • même chose en milieu de chaîne
  • en haut de chaîne, on ne peut pas recevoir les données de la pile comme les deux cas précédents car le câble CAN va vers le PC et non pas vers le reste de la PAC. Mais on reçoit des commandes du PC panel (avec notamment une trame de déconnexion du logiciel). Cette fois si le pc panel n'est pas allumé rien ne transite (Il y a une erreur au niveau du logiciel NSI527).

Voici ci dessous trois captures d'écran montrant la bonne réception de données (trames RX), et d'envoie (trames TX), dans l'ordre connexion en fin de chaine, milieu et haut respectivement.
trames issues du sniffer CAN - connexion sur le port en fin de chaîne trames issues du sniffer CAN - connexion sur le port en milieu de chaîne trames issues du sniffer CAN - connexion sur le port en début de chaîne
En conclusion de ces premiers tests, on arrive bien à recevoir les données envoyées par la pile et le convertisseur DC/DC vers le panel PC. Cependant, alors que nous pensions pouvoir faire de la récupération de données à la demande, il s'avère que le flux de données est constant quelque soit l'emplacement du port CAN. Le port en fin de chaîne étant un extra port (pas besoin d'enlever une connexion pour pouvoir s'y placer), c'est celui-ci que nous choisissons pour la suite des tests, puisqu'il permet de récupérer les trames tout en potentiellement envoyant des commandes depuis le panel PC. Par la suite, nous verrons s'il est plus judicieux de se placer en début de chaîne afin de jouer le rôle de panel PC depuis notre interface LabView, si cela revient au même ou si l'on risque de manquer certaines informations. Il y a notamment une connexion RS485 au niveau du panel PC que nous n'avons pas encore identifié, et se positionner en haut de la PAC empêche l'éventuel flux de données avec cette connexion (si flux de données il y a).

Identification des trames

Grâce à la documentation de la pile ( Fichier:ProtocoleCAN Nexa1200.pdf ) envoyée la semaine dernière par Mathieu BRESSEL, nous avons pu facilement retrouver un grand nombre de trames associées à la pile. Pour celles associées au convertisseur, nous avons fait la demande pour avoir la documentation, et sommes en attente d'une réponse d'un contact du fournisseur.

identifiants des trames de la pile circulant sur le CAN bus

Nous avons alors fait une comparaison entre les données du logiciel HEL et celles sniffées sur le logiciel NSI527. Voici les captures d'écran des données sur lesquelles nous nous basons, prises à un temps T sur une absence d'évolution des valeurs. De gauche à droite respectivement la première fenêtre du logiciel HEL, la deuxième fenêtre puis le logiciel NSI527.
données du logiciel fenêtre 1 au temps T données du logiciel fenêtre 2 au temps T trames issues de la communication CAN au temps T

En plus du tableau, on peut retrouver dans la documentation le détail bit par bit des données. On sait par exemple que la trame 0x100 contient l'information de tension de la pile sur les deux premiers paquets : XX XX XX XX XX XX, et que cette tension peut varier entre -10V et 50V.
Sur le logiciel NSI527, on retrouve la trame 00 44 00 00 00 00, soit 00 44 les données associées à la tension de la pile.

Nous avons regroupé et comparé les données dans le tableau ci-dessous. En vert les données que nous avons retrouvé dans le logiciel HEL, en jaune celles que nous n'avons pas retrouvé sur les captures d'écran.
En voulant réaliser la conversion hexadécimal vers unité des données, nous observons quelques problèmes (cases rouges). En effet, pour les plages de données allant d'une valeur négative vers une valeur positive, les données ne correspondent pas. Nous allons nous pencher sur le problème dans les jours à venir, une des idées étant que les valeurs binaires seraient signées et ainsi la conversion serait un peu plus complexe que simplement une fonction affine.

identification et comparaison avec le logiciel HEL des données reçues de la pile, au premier essai.


Recherches et réalisation de devis

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és 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: Lien 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.
Un devis a donc été transmis à Mme GEHIN qui s'occupe de la commande du matériel pour ce projet : Fichier:NIQuote 1693974-1.pdf

Au niveau de la batterie défaillante, un devis a été réalisé et la commande de celle-ci va être effectuée par Mme GEHIN : Fichier:Devisbatterie.pdf

Une fois que tout ce matériel sera réceptionné nous pourrons donc attaquer la partie LabVIEW en réalisant dans un premier temps une réception et un envoi de trames de données sur le bus CAN de la pile.

Réunion avec les étudiants en Master

Ce vendredi 18 nous avons eu une réunion avec les quatre étudiants en Master intégrant le projet, Sumit Sood le thésard associé au projet, Mme Gehin, M. Ould Bouamama, et M. Dieulot.
Cette réunion avait pour but de présenter le projet aux nouveaux étudiants, ainsi que de leur assigner leur tâches. Ils travailleront donc sur la partie modèle, commande et supervision de l'électrolyseur sur MATLAB, et de notre côté nous continuons nos tâches prévues sur la pile à combustible. Une fois les deux parties terminées, le but sera de les regrouper afin d'avoir une interface commune pour l'ensemble du système présenté en début de wiki.

Semaine du 21 au 27 octobre

Identification des trames

Reprise de la piste des nombres signés

  • Essai 1 : En considérant que le bit de poids fort correspond à l'aspect positif/négatif (0/1), nous avons dans un premier temps estimé que la valeur maximale était 7FFF et celle minimale 8000, associées aux extrema respectifs de la documentation. Cela paraissait à première vue cohérent puisque la seule valeur négative issue du logiciel HEL correspondait à un code au bit de poids fort 1. Cependant, en faisant un produit en croix, les valeurs ne corrèlent toujours pas.

M. Blaise Conrard nous a alors suggéré de se placer à l'entrée du panel PC et jouer le rôle de la PAC en envoyant les trames sur lesquelles nous travaillons au panel PC. Cela permet de facilement changer les valeurs affichées sur le panel PC sans pour autant avoir un quelconque impact sur le système. De cette manière, on peut vérifier la concordance entre les données issues de la documentation et celles réelles.

  • Essai 2 : Nous nous sommes alors rendu compte que les valeurs hexadécimales n'avait aucun lien avec la documentation. Par exemple, envoyer l'information hexadécimale 8000 sur le paquet correspondant au courant de la pile (I Stack) affiche une valeur de -327,3A, tout comme une température de -327,3°C si l'on envoie cette même information hexadécimale sur le paquet correspondant à la température de la pile (T Stack). Ces valeurs devraient correspondre au minimum (0A pour le courant, 22,3°C pour la pile) et pourtant ce n'est pas le cas. Les intervalles de valeurs données par la documentation sont donc à but purement informatif sur le système mais n'ont pas de lien avec la communication CAN.
  • Essai 3 : Après un peu plus de réflexion, nous avons remarqué qu'en convertissant la valeur hexadécimale signée vers sa valeur décimale associée, on retrouve la valeur affichée sur le panel PC, à une ou plusieurs puissance de 10 près. Cela est donc enfin une réussite.

Un des éléments nous ayant ralenti, est que nous avons travaillé sur la valeur V Stack (tension de la pile), car c'est la première information de la trame 100h tout simplement. Et il s'avère que celle-ci à un offset de 0040 (en décimal, et 0,4 en V) par rapport à toutes les autres. De ce fait, lorsque nous avons cherché le point 0, la valeur hexadécimale était différente de simplement 0000 et notre raisonnement fut biaisé pendant un temps.

Pour conclure, nous avons identifié toutes les informations grâce à la documentation, et compris comment retrouver la valeur réelle depuis une conversion hexadécimale signée vers décimal (puis une division par 10 ou 100 selon les données). Nous avons trouvé où se situaient les valeurs "manquantes" de la semaine dernière et nous sommes donc prêts à récupérer ces trames sous LabView, les exploiter correctement et réaliser l'interface.

NB : nous avons reçu la documentation du convertisseur DC/DC et donc avons pu effectuer nos vérifications également sur les valeurs issues de ce dernier, le fonctionnement étant le même que pour les données issues de la pile.

Conversion hexadécimal signé vers décimal

Pour convertir un nombre hexadécimal vers décimal sous LabView, plusieurs choix s'offrent à nous. Voici une proposition.

  • conversion hex -> binaire
  • si le bit de point fort vaut 0
    • faire la conversion binaire -> décimal
  • si le bit de point fort vaut 1
    • faire le complément à 1 (not X)
    • faire le complément à 2 (ajouter 1)
    • faire la conversion binaire -> décimal

Pour les conversions, il n'y a pas l'air d'avoir de blocs dédiés sur LabView. Un simple bloc script Matlab pourra nous permettre d'insérer du code facilement, et effectuer les conversions sans problème.

Matériel commandé

Nous avons bien reçu la batterie ainsi que la carte d'acquisition

Semaine du 4 au 17 novembre

Pendant l'interruption pédagogique, le service informatique a effectué un basculement de réseau dans la salle C006 de l'adresse polytech vers les serveurs de l'université. De ce fait, les PC ne retrouvaient pas les licences NI instrument et donc ni Labview ni NI MAX ne pouvaient fonctionner. Nous avons donc du faire en sorte que ce problème soit résolu la première semaine.Ce problème s'est résolu grâce à monsieur Scrive qui a pu réactiver la licence.

Carte d'acquisition NI9862 et connexion CAN

décomposition du câble CAN

Après avoir installé le driver logiciel NI XNET pour la carte d'interface CAN que nous avons commandé, nous avons donc essayé de recevoir les données via le câble D-Sub directement relié au bus CAN de la pile. Cependant, il s'avère que l'interface NI9862 requiert une alimentation continue entre 9 et 30V (consommation d'1W) en entrée, et le bus CAN de la pile ne fournit pas cette alimentation.
Nous avons utilisé un adaptateur mâle vers femelle en tant qu'élément intermédiaire (pour ne pas travailler directement sur le câble CAN), sur lequel nous avons soudé des câbles pour ressortir chaque pin. L'autre extrémité de chaque pin est alors soudée vers un autre adaptateur qui lui est connecté à la carte d'acquisition. Entre les deux adaptateur se trouve donc une zone tampon où nous pouvons placer l'alimentation appropriée sur les pin 6 (masse) et 9 (VSup). Ci contre une photo du résultat.
Dans un premier temps nous avons travaillé avec les grosses alimentations stabilisées-réglables des salles C20x pour tester notre montage. Grâce à l'interface NI XNET Bus Monitor (capture ci-dessous) nous pouvons facilement voir que nous recevons les données, et en se plaçant juste avant le pc panel nous arrivons à envoyer des données vers celui-ci, comme précédemment avec le sniffer CAN disponible en C00x.
réception des trames dans le logiciel NI XNET

Dans un second temps, nous avons utilisé l'alimentation du châssis CompactDAQ. Nous avons donc coupé le câble pour placer un borgnier entre les deux extrémités. De ce fait, nous avons pu récupérer la tension fournie par l'alimentation du châssis directement. Nous pouvons donc maintenant récupérer les données sans l'une des alimentations des salles c20x. Ci-dessous le montage final, avec la carte d'acquisition à gauche, l'alimentation entourée en violet et le borgnier pour la en haut à droite.
montage au niveau de la carte d'acquisition

Réception de trames via LabView

Nous avons alors pu commencer à récupérer les trames sur Labview. Pour cela, nous avons utilisé les modules de programmation graphiques de la bibliothèque NI-XNET pour pouvoir lire les données issues de la carte NI9862. Ce code est pour l'instant une ébauche et sera amélioré aux prochaines séances, mais nous pouvons déjà voir sur la capture ci-dessous que nous arrivons à afficher une trame et donc par la suite la décomposer pour l'exploiter correctement.

récupération des trames sur Labview, essai 1


Semaine du 18 au 24 novembre

Récupération des trames et affichage des données sur LabView

  • Lors de cette semaine, nous avons pu approfondir le code LabView. Nous avons donc extrait toutes les trames contenant des données (depuis datasheet) en les distinguant par leur adresse. De là, elles sont traitées dans un sous-VI particulier (selon l'adresse) puis affichées dans la face avant, comme le montre le montage ci-dessous. La face avant est pour l'instant uniquement pratique et nous utiliserons l'interface réalisée quelques semaines plus tôt une fois le programme entièrement fonctionnel.
VI (à gauche) et face avant (à droite) du programme Labview permettant la récupération, traitement et affichage des données de la PAC


  • Le traitement des trames se fait donc dans des sous-VI pour plus de clarté. Ci-dessous un exemple de traitement des données, avec la trame d'adresse x200.

Pour récupérer la valeur de la concentration d'hydrogène du système, on récupère les valeurs du deuxième et troisième indice. Ces valeurs étant en décimal, on les convertit en hexadécimal. De cette manière, on peut concaténer les deux valeurs afin de former 4 chiffres hexadécimaux correspondant à la valeur hexa signée de p H2 FC. On convertit une nouvelle fois ces 4 chiffres pour d'obtenir la valeur décimale signée. Puis, on divise cette valeur par 100 afin d'être dans la même unité que le PC panel.
Sur la face-avant du VI, on peut vérifier nos conversions et extractions de données en comparant visuellement avec la trame initiale, sans pour autant afficher toutes ces valeurs dans le VI principal.
Pour les données correspondants à des messages d'erreurs ou d'avertissement, on convertit non pas vers une chaîne hexadécimale mais une chaîne de bits, puisque un bit à 1 signifie que le message du même indice doit être affiché. C'est pour l'instant une solution provisoire, puisque nous n'avons pas encore trouvé comment exploiter ces valeurs.

VI (à gauche) et face avant (à droite) du sous VI permettant le traitement des données issues de la trame x200


  • Pour traiter ces données, nous avons rencontré quelques obstacles, et notamment la division d'un nombre signé.

En effet, nous ne recevons quasiment aucune donnée dans l'unité souhaitée (exemple : 1000 pour 10V), et une division est donc nécessaire avant l'affichage. Cependant, dès que le nombre était négatif, le résultat obtenu par le module diviseur basique de Labview ne correspondait pas à la réalité (car faisait une transformation en non signé). Après de nombreux autres essais, la seule solution que nous avons trouvé est de transformer le type des données grâce à des variables tampons, afin de garder le signe et la valeur initiale. Nous avons regroupé cela dans un sous-VI pour plus de clarté et facilité d'utilisation.

sous VI permettant la division d'un nombre signé


Nous arrivons donc à recevoir et afficher correctement une grande partie des variables.

Envoie de trames de test sur le PC panel

De plus, nous avons réussi à envoyer des données de l'interface Labview vers le panel PC, en connectant notre interface CAN à l'entrée de celui-ci pour observer facilement le changement des données.
Nous avons par exemple testé avec la température de la pile TStack, dont les informations se situent sur les deux premiers éléments de la trame x110. On peut voir sur le montage ci-dessous que lorsque l'on communique la valeur 1000 (le module division n'a pas été utilisé ici mais sera nécessaire par la suite), le panel PC reçoit bien la valeur 10°C.
Pour cela nous avons du convertir la valeur 1000 en hexadécimal, puis séparé cette dernière en deux éléments. Nous avons ensuite re-créé toute la trame avec les éléments, l'adresse, le temps, le type, etc. Sur la face avant du VI on peut donc choisir la valeur, et nous est affiché la conversion hexadécimale ainsi que la trame qui est envoyée pour vérifier le bon fonctionnement. Par la suite, nous pourrons, de la même manière que la réception, programmer chaque trame d’envois (selon la datasheet).
Note : la session NI-XNET est différente entre le protocole de réception et celle d’envois. Nous n'avons pour l'instant pas testé les deux en même temps.

VI, face avant Labview et interface du panel PC pour l'envoie des données vers la PAC


Semaine du 25 Novembre au 1er Décembre

Affichage des messages sur Laview

Dans un premier temps, nous avons réglé le problème d'affichage des messages d'erreurs. Après être partis sur la piste des menus déroulants, ces derniers ne sont finalement pas pratiques car il n'est pas possible de voir le contenu des menus pendant que le programme tourne. En attendant de trouver une solution aussi proche graphiquement parlant de l'interface HEL, nous utilisons des tableaux pour afficher les messages : même lorsque le programme tourne, il est possible de voir le contenu entier du tableau.

initialisation de tous les messages reçus par la PAC

Pour cela, nous stockons la valeur étudiée dans un tableau binaire. Si le bit vaut 1, le message associé à l'indice doit s'afficher, sinon non. Il faut noter que plusieurs bits peuvent être à 1 et donc plusieurs messages doivent pouvoir s'afficher.
On initialise en parallèle, un tableau global recensant tous les messages possibles de la valeur associée (par exemple, pour la trame x100 les indices 2 et 3 correspondent aux Warnings, qui correspond à 16 messages possibles. On rentre donc dans un tableau ces 16 messages). Ci-contre tous les tableaux de messages communiqués par la PAC.
Enfin, on parcourt le tableau binaire : si le bit est à 1, on récupère le message correspondant du tableau global pour le stocker dans un tableau final. A la fin de la boucle, le tableau final contient donc tous les messages du tableau global dont la valeur associée dans le tableau binaire vaut 1. Ci-dessous le VI de ce traitement.

sous VI permettant d'associer un tableau binaire à une liste de messages


Envoi et réception de trames sur le même VI

Nous avons travaillé sur l'envoi et la réception de trames sur le même VI. Un problème de configuration des clusters utilisés nous a ralenti, mais finalement avec deux sessions (une pour la lecture, une pour l'écriture) utilisant le même fichier cluster, il n'y a aucun problème.
Pour tester notre VI, nous avons utilisé les trames x120 et x520. En effet, la trame x120 est envoyée (par la PAC vers le PC) en réponse à la trame x520 (envoyée du PC vers la PAC). Sur la capture ci-dessous, on voit en bleu que la valeur envoyée par la trame 520 est retrouvée dans la trame 120 de réponse (avec le reste des données associées).

envoi et réception simultanée de trames sur LabView


Interfaces HEL sur Labview

Nous avons ensuite réutilisé les interfaces dessinées en début de projet pour afficher toutes nos variables. Nous avons utilisé l'outil "Onglet" pour ressembler au mieux à l'interface HEL. Cela nous a permis plus facilement de voir les variables qui nous manquaient et les éventuelles erreurs. En effet, toutes les données ne transitent pas par CAN. Une partie utilise une communication RS485 et une autre USB. Nous avons donc rassemblé les données dans le tableau ci-dessous.

types de communication par lesquelles les variables transitent


Communications RS485

convertisseur RS-485 to USB

Le bus CAN fait transiter des données que nous affichons correctement dans Labview. Nous devons maintenant nous occuper des deux autres moyens de communication qui sont utilisés pour envoyer des données vers le panel PC. En effet le "power management system" transmet des données via une liaison RS-485 et la charge électronique transmet elle des données via une liaison USB. L'objectif de ces prochaines semaines va donc être de trouver des solutions matérielles et logicielles afin de récupérer ces données pour pouvoir les intégrer dans notre interface sur LabVIEW.

La liaison RS-485 entre le "power management system" et le panel PC permet de remonter des données de mesures supplémentaires comme le débit-mètre, la température des réservoirs d'hydrure, ICC et Ucc de l'onduleur etc... Tous ces données proviennent de capteurs indépendants du système qui ont des sorties analogiques en 4..20mA ou 0..10V qui sont ensuite envoyées vers le module de mesure ICPCON 7019R qui est relié au PC panel par le bus RS-485.
Une première solution pour cette liaison était de s'acquérir d'un convertisseur RS-485 to USB afin de pouvoir communiquer avec le module.

De plus, le module I-7019R utilise le protocole de communication DCON. ICPDAS, le fabriquant du module, fournit un logiciel permettant de se connecter à ce module.

Logiciel DCON utility qui permet de se connecter au module
.

Apres s'être donc connecté sur le bus RS-485 grâce au convertisseur cité plus haut fourni par M. Conrard, nous avons essayé de rechercher le module via ce logiciel. Malheureusement nous ne parvenons pas à établir une liaison car nous ne connaissons pas l'adresse sur laquelle a été configuré le module. Nous avons donc envoyé un mail à M. Granjon, qui est la personne qui a vendu la PAC à Polytech, qui lui a des contacts avec l'usine qui a fabriqué et configuré la pile.

Semaine du 2 au 8 décembre

Communication USB

A la différence du CAN où un port était libre pour ajouter un câble, l'interface USB de la charge ne propose pas plusieurs ports. Nous devons donc faire en sorte de se placer en série entre la charge et le PC panel.

Nous avons donc pensé à un hub USB. Le premier problème que nous avons rencontré est de trouver un câble USB vers USB mâle mâle afin de connecter le pc au reste de la communication. Cependant, un autre problème bien plus important se présente : connecter deux PC en USB (le PC panel au PC) peut provoquer des courts-circuits et complètement cramer les systèmes si le câble ne propose pas une inversion de son RX/TX.
Il faut également noter que le hub USB ne permet que de recevoir les données de la pile uniquement dans une configuration : la charge en entrée du hub et la sortie du hub vers le pc panel.

Grâce à M. Flamen, nous avons fabriqué un câble USB vers USB (mâle mâle) avec inversion interne des bus de transmission. En théorie, cela ne provoque pas de courts circuit au niveau des PC, et le câble PC to PC permettrait de recevoir les données traversants le hub USB. Cependant, une fois tout cela fait, il s'avère que l'ordinateur ne reconnait pas du tout la connexion USB dans le gestionnaire de périphériques. Alors que nous nous attendions à rencontrer des problèmes plus loin dans la communication, comme ne pas réussir à lire de données sur le bus, nous sommes arrêtés beaucoup plus tôt que prévu et n'avons pour l'instant pas de solution à ce problème. Cela s'explique finalement assez simplement : pour établir une connexion USB, le PC envoie une requête au système et attend une réponse, et là aucune réponse n'est générée.

Une autre tentative a été réalisée : regarder sur un oscilloscope si des données passent sur le bus. Nous avons donc coupé un câble USB simple, branché le côté avec le port au hub USB. De la coupe, la masse en aluminium du fil est placée à la masse de l'oscilloscope et le RX ou TX (fil blanc ou vert) sur une channel. Malheureusement, aucune différence n'est notée quand la charge est déconnectée ou connectée sur le bus.

Finalement, la connexion USB est donc beaucoup plus complexe que prévue.

Semaine du 9 au 15 décembre

Communication USB

Réception des trames de la communication USB sur l'oscilloscope
  • Depuis les expériences de la semaine dernière, nous en déduisons que le hub peut être le problème si il empêche les communications de se transmettre dans les deux sens. Pour palier à cela, M. Flamen nous aide en préparant un câble à 3 ports USB (mâles) dont un dénudé. Les deux ports USB vont respectivement à la charge et au PC panel, et la partie dénudée est sniffée via un oscilloscope.

Comme le montre la photo ci-contre, en plaçant la masse interne (fil noir) à l'external et le fil de données (vert ou blanc) on réceptionne bien des formes de trames (même si elles sont fortement bruitées). L'inconvénient de cette méthode est que, de la même manière que la semaine dernière, on ne peut pas connecter ce câble simplement entre les deux PC car il ne va pas reconnaitre de connexion, il faut une interface supplémentaire afin de traiter les données.
La solution de l'arduino ou d'une carte d'acquisition NI instrument se présente. Cependant, nous sommes vites ramené à la réalité car la fréquence à laquelle nous recevons les trames est bien trop rapide pour être reçue via une carte d'acquisition, sans compter le fait que le protocole USB est très complexe à décoder manuellement.

  • Nous nous attardons alors sur l'interface de transmission de données de la charge, le IF-U1.

Il s'avère qu'en plus du port USB, il y a des ports RJ45. Nous pensons donc au fait que ces ports sont peut-être des doubles de la communication USB et les trames pourraient être récupérées en utilisant un câble RJ45 vers USB. Cependant, la documentation des IF-U1 insiste sur le fait que ces ports sont des System Link Ports c'est à dire des ports à n'utiliser que pour associer l'alimentation de plusieurs charges, et uniquement des charges de type PSI9000 (en plus de cela notre charge est une de type EL3000) : " System Link ports are only usable with power supplies of the series PSI9000 ". Cette idée n'est donc pas retenue.

  • Dans cette même documentation sur le IF-U1, de nombreuses informations sur la programmation de ces interfaces sont données.

Une liste de requêtes et commandes nous est donnée, avec les réponses théoriques attendues. En se basant sur des exemples, nous re-tentons donc de sniffer la communication en se plaçant de la charge vers notre PC (sans le PC panel). Nous réussissons alors à recevoir des données à notamment la requête 71 correspondant à "Quel est l'état des variables tension, courant et puissance", mais le Checksum est incorrect et les valeurs n'ont pas de sens. C'est un début mais il y a sûrement quelques erreurs dans la trame de requête.

  • Au même moment, M. Vantroys accepte gentillement de nous prêter un sniffer USB Beagle 12.

Ce sniffer permet de se placer entre le panel PC et la charge, à lire le bus de communication sans avoir d'impact sur celle-ci.
À partir de ce point nous avons alors avancé dans nos recherches puisque l'on reçoit bien sur le logiciel associé Total Phase Data Center les trames d'envoie du panel PC ainsi que celles avec les données de la charge. Grâce aux documentations du IF-U1 et la programmation sur laquelle nous travaillions juste avant, nous arrivons à retrouver les trames résultant de la requête 71 avec les Bytes associées aux données V_DC_Load I_DC_Load P_DC_Load.

Réception des trames venant de la communication USB sur le logiciel Total Phase Data Center (module Beagle)

Depuis la documentation, nous arrivons à comprendre comment convertir correctement cette valeur pour obtenir la valeur réelle à afficher :
- conversion de hexadécimal vers décimal
- division par la valeur nominale associée (160V pour la tension, 60A pour le courant, 400W pour la puissance)
Avec la capture d'écran plus haut, la réponse à la requête 71 (47 en hexa) correspond à :
- 05 2D pour la tension soit 1325 en décimal => 1325/160 = 8,28V
- 00 00 pour le courant et la puissance soit 0A et 0W respectivement.
Ces trois valeurs correspondent bien à ce qu'affiche le PC panel dans le même temps.

De plus, le Beagle 12 peut être associé à Labview : des modules présents sur le CD d'installation sont déjà créer pour récupérer les données sur un VI (n'a pas encore été testé). Nos données pourraient donc être affichées sur notre interface avec le reste des données provenant du CAN.
Cependant, il y a un problème : par définition ce sniffer n'a aucun impact sur le bus et de ce fait aucune donnée ne peut être envoyée depuis notre PC de cette manière.

Un choix doit donc être fait :
- Soit nous décidons que la partie charge électronique (charge présente sur le système en tout cas) n'est pas commandable sur notre PC, et dans ce cas on ne fait que lire les valeurs grâce au Beagle. Le Beagle fera donc parti du système et un VI Labview communicant grâce à ce système doit être développé.
- Soit nous décidons que le panel PC n'a plus accès aux données de la charge car nous connectons directement la charge à notre PC. De cette manière, si l'on arrive à répertorier toutes les requêtes nécessaire à la bonne lecture/commande de la charge et que nous arrivons à les envoyer depuis le port série comme au troisième point, alors on peut se passer du beagle et avoir une interface entièrement fonctionnelle.
Ce choix est à discuter avec notre tutrice et les différents enseignants. De plus, nous n'écartons pas encore la possibilité de trouver un moyen d'interconnecter la charge, le panel PC et notre PC.

Communication RS

schéma des différentes configurations testées pour le sniffage du bus RS485

Nous avons mis en place un split de la connexion grâce à deux convertisseurs male/femelle de RS485 ainsi que le bornier fourni avec le convertisseur RS/USB. Deux configurations sont possibles, comme le montre le schéma ci-contre.

  • Pour la première configuration, si on ne connecte pas le convertisseur RS/485 au PC, les données communiquent bien jusqu'au panel PC. Cependant, dès que l'on se connecte au PC, le panel PC ne reçoit plus de données et le logiciel Utility Pro ne détecte pas de connexion.
  • Pour la deuxième configuration, sans se connecter au PC via le convertisseur, aucune donnée ne transite jusqu'au panel PC.

De ces expériences il semble donc qu'il y ait un problème au niveau du bornier. Alors que les fils de données sont bien connectés, le port RS semble ne pas arriver à envoyer ses données dans le bornier. Pourtant, au multimètre les connexions sont correctes et on a bien un lien entre l'entrée et la sortie du bornier.
Pendant ces tests, nous avons essayé avec résistance de 120Ohm (entre le data+ et data-) et sans. Nous supposons que nous devons creuser cette piste et que potentiellement la résistance n'est pas correctement choisie.

Nous avons également réussi à accéder au logiciel DCON Utility sur le panel PC, où la connexion est bien reconnue dans un mode de fonctionnement normal. Cela nous a permis de vérifier que nous utilisions bien le logiciel et que le problème de transit de données vient d'un autre endroit.
Cependant, en se connectant uniquement de la pile vers notre PC grâce au convertisseur RS/USB, ce dernier ne la reconnait pas. Il y a donc très sûrement une autre difficulté cachée en plus du bornier.

Wireshark sur le panel PC

Nous avons également tenté d’installer Wireshark sur le panel PC pour voir si plus d’informations sur les trames y circulaient, mais le logiciel ne reconnait aucune communication.
Nous tentons toujours de contacter Heliocentris pour les trames circulant via le port Ethernet, mais sans succès.

Semaine du 16 au 22 décembre

Communication USB

Test d'envoi de requêtes via Serial Port Monitor

Une fois les trames échangées entre le panel PC et la charge répertoriées et analysées grâce au Beagle USB(voir pdf suivant:Fichier:Tramesech.pdf), l'objectif de cette semaine est de pouvoir se mettre à la place du Panel PC pour communiquer avec la charge. Nous avons donc connecté notre PC à la charge via l'interface USB et son driver qui permet au PC de visualiser le port USB comme un port COM virtuel.

Serial Port Monitor est un logiciel permettant de visualiser et d'envoyer des trames circulant sur des liaisons série. On utilise donc ce logiciel dans notre cas afin d'envoyer une trame de requête qui permet d'obtenir les valeurs de tension, de courant et de puissance dans la charge électronique (requête 75 01 47 00 BD, voir .pdf).

On obtient le même résultat que lorsqu'on observait les trames envoyées par la charge vers le panel PC (trames 85 01 47 00 05 00 00 00 00 00 D2, voir .pdf).

Ces tests nous permettent de se positionner dans la configuration où le panel PC n'a plus accès aux données de la charge car nous connectons directement la charge à notre PC. De cette manière on peut se passer du Beagle USB et utiliser LabVIEW afin de réaliser un "virtual instrument" qui permettra d'envoyer et de recevoir les trames provenant de la charge électronique maintenant que l'on connaît parfaitement le format et la signification de celles-ci.

Labview et charge électronique

Nous avons donc réalisé le VI Labview permettant d'envoyer et recevoir des trames sur le bus USB grâce au module VISA. Ci dessous à gauche le VI et à droite la face avant associée.

VI Labview pour la communication avec la charge électronique
Face avant du VI Labview pour la communication avec la charge électronique

Il y a donc une première partie à gauche pour la connexion au port série virtuel, avec donc tous les paramètres de cette communication. On décide de lire les valeurs toutes les 500ms.
On rentre ensuite dans une grande boucle While où deux choix sont possibles :
- demander l'état de la charge
- demander les valeurs de la charge (V,I,P)
Ce choix doit être validé avec l'activation d'un bouton "envoie" pour réellement envoyer la trame et lire la réponse espérée. Chaque choix est donc associé à une requête et à une longueur de trame à recevoir. Dans le cas où aucune erreur est possible et que la demande effectuée concerne les valeurs de la charge, la réponse est alors traitée comme expliqué dans un paragraphe plus tôt. Pour rappel, les paquets associés à respectivement la tension, le courant ou la puissance sont extraits puis divisés par leur valeur nominale respective pour enfin être affichée. Une partie de ce traitement se fait dans un sous-VI pour plus de lisibilité et praticité.
On voit bien sur la face avant ci dessus que la valeur de tension 00 05 en hexa est bien affichée 0,031V après traitement.

Nous avons testé ce VI dans un VI test comprenant l'association entre la communication CAN et la communication USB. L'envoi et la réception de valeurs sont toujours fonctionnels pour les deux communications. Nous pouvons donc ajouter cette partie de code dans le VI principal. Quelques ajustements seront bien sûr faits pour n'avoir que l'affichage des valeurs finales. Pour l'instant, la requête état du système ne sera pas prise en compte car pas utilisée dans HEL.

Semaine du 6 au 12 janvier

Trames TCP/IP

Sous les conseils du jury lors de notre soutenance, nous avons repris l'étude des trames reçues sur le bus éthernet.

L'échange de données entre le panel PC et notre PC s'effectue de manière continue. Les données qui transitent sur le réseau CAN, RS 485 et USB sont centralisé sur le panel PC qui les envois en continu au PC via la liaison TCP/IP. Le protocole de communication n'est pas de type requête/réponse ce qui complique la rétro-engineering qui permettrait de faire correspondre les valeurs que l'on modifie sur le système avec celles que l'on reçoit. En effet cela aurait été plus simple si le PC envoie des requêtes de demande des données uniquement de la charge par exemple et que les informations qui ne concernent que la charge soient renvoyées sur une seule trame. Ce n'est pas le cas ici mais nous avons essayé différents tests.

Nous enregistrons les trames sur Wireshark pour plusieurs tests isolant les communications : d'abord aucune communication n'est reliée au panel PC (ni CAN, ni RS, ni USB), puis uniquement la liaison RS, uniquement la liaison USB et uniquement la liaison CAN.

Premier cas, trames du PC vers panel PC ( IP 192.168.0.2 vers IP 192.168.0.1)
Dans les trois tests : trames de longueur 54 octets, aucun octet de données.

Deuxième cas, trames du panel PC vers PC = les données (IP 192.168.0.1 vers IP 192.168.0.2)

  • pour aucune communication, uniquement RS ou uniquement USB, on a : longueur 847 avec 793 octets de données.
  • pour seulement CAN, longueur 947 avec 893 octets de données

On remarque que sur les 20 dernières lignes de paquets, on arrive à trouver des similitudes, et notamment à isoler les paquets associés à la communication RS et à la communication USB : c'est ce que montrent les captures ci-dessous (entre temps un test avec la communication CAN et RS a été réalisé pour appuyer nos résultats).

identification des paquets correspondants aux données RS et USB

La correspondance de ces différents paquets d'octets en code ASCII ne donne rien d'exploitable il va donc également falloir trouver en quelle unité il faut convertir les paquets pour pouvoir faire correspondre de possible valeur avec les valeurs indiquées par l'interface homme-machine. On remarque également que la dernière partie de la trame où l'on voit indiqué "High Capacity" dans la correspondance en ASCII correspond aux valeurs de configuration des batteries (état de charge, profondeur de charge) qui sont contenues dans un fichier sur le panel PC mais uniquement les indicatifs nominaux sont remarquables dans cette trame.

Sur le système de pile à combustible la charge communique au panel PC uniquement 3 valeurs, la valeur de tension, de courant et de puissance dans la charge. Nous avons donc modifié la valeur de tension dans la charge et réaliser une capture de trame lorsque la tension est à 0 et lorsqu'elle est a 26V. Voici le résultat de la comparaison entre les deux trames: <span


Cependant, pour le test avec uniquement la communication CAN, énormément de données sont transmises. Par curiosité, nous avons cherché si les paquets pouvaient correspondre aux paquets détaillés sur les documentations CAN, mais sans surprise aucune correspondance n'est possible. Ayant déjà réussi à reprendre les données circulant sur ce bus, nous n'irons pas plus loin par rapport à la communication CAN.
De la même manière que pour le CAN, les paquets correspondant aux données du bus USB ne correspondent pas à la documentation que nous avons pu trouver précédemment (sans surprise une nouvelle fois). Comme les paquets sont assez petits, et la charge assez facile à faire varier, nous allons tout de même essayer de retrouver les données. Cela nous permettrait d'ailleurs de connecter la charge au panel PC tout en recevant les valeurs sur PC, ce qui n'est possible lorsque l'on lit les données du bus USB via Labview (comme expliqué en décembre).
Nous allons donc essayer par la suite de trouver des liens entre les données reçues sur le logiciel HEL et les paquets circulants sur le bus Ethernet pour identifier les valeurs sur le bus RS485 et USB.

Un problème survient :
Lorsque l'on associe plusieurs communications (notamment CAN avec RS), d'autres trames sont transmises du panel PC au PC. N'ayant pas eu le temps de faire beaucoup plus de tests avant les vacances, nous ne pouvons pas encore avancer sur ces points. En effet, pour le moment nous avons de nouveau des problèmes de batterie associée à la pile à combustible, due à sa non-utilisation pendant les vacances. De ce fait, aucun test n'est possible (nous n'arrivons pas à démarrer la pac ni le panel PC donc aucune communication n'est possible) que ce soit au niveau du bus Ethernet, des tests RS485 de décembre, etc.

Semaine du 13 au 19 janvier

Lors de cette semaine, nous sommes restés bloqués dû au problème de batteries (une commande est en cours). Cela nous empêche d'effectuer une quelconque connexion à la pile à combustible (panel PC ne s'allume pas) et donc d'avancer sur le RS, les trames tcp/ip, la charge, etc.

Nous avons donc décidé de nous tourner vers d'autres points du projet, et notamment la mise en commun de l'interface faite par François Xavier l'année dernière avec la notre. Nous avons réussi à fusionner les Labview après quelques mises à jour et problèmes de compatibilité. Nous avons donc ajouté l'interface de 2018 dans un nouvel onglet.
Cependant, même si à première vue il n'y a pas l'air d'avoir de problème, nous ne pouvons pas entièrement vérifier la fusion car il semblerait y avoir un soucis d'automate sur le bloc Heliocentris (Power management) sur lequel travaillent les étudiants en Master. Après avoir vu avec le thésard Sumit qui n'a pas trouvé l'erreur, nous avons contacté les étudiants en Master. En fin de semaine, ils nous ont confirmé qu'un des composants était grillé (arrivé pendant les vacances) et qu'il ne sera sûrement pas remplacé d'ici la fin de notre PFE.

Malgré ces contre-temps, nous essayons de ne pas perdre trop de temps. Nous avons repris la piste du Moteur en tant que charge externe pour simuler l'utilisation de l'énergie issue de la PAC par une voiture. Après y avoir réfléchi et vu les nombreuses difficultés associées (difficultés matérielles), nous avons discuté avec M. Matthieu Bressel (qui nous avait orienté sur la connexion CAN en début de projet) qui nous a conseillé de plutôt réaliser une simulation de moteur sur la charge déjà existante, en s'inspirant notamment du Nouveau cycle européen de conduite (NEDC, New European Driving Cycle).

Cycle de conduite

Un cycle de conduite est un test s'appliquant aux voitures entrant sur le marché pour déterminer leur consommation en carburant ainsi que leurs émissions de substances polluantes. Ces tests sont effectués sur des bancs à rouleaux et sont censés simuler des conditions de conduite plus ou moins réalistes.
Avant 2017, le test utilisé était le NEDC, mais désormais le cycle WLTP (Worldwide harmonized Light vehicles Test Procedures) est entré en vigueur. Après quelques années de cohabitation entre les deux tests pour faciliter la transition aux constructeurs, à partir de 2020 la réglementation exige l'utilisation du WLTP plutôt que du NEDC, qui se veut beaucoup plus réaliste. Comme nous sommes justement début 2020, nous avons décidé de travailler sur le cycle WLTP dans un soucis de correspondance avec l'actualité.
Comme dit plus tôt, le cycle WLTP permet donc d'être plus réaliste puisque, par exemple, il prend désormais en compte le poids et les accessoires du véhicule, la durée et distance du test sont plus importantes tout comme la vitesse moyenne et la vitesse maximale. Les conditions météorologique et les situations de conduite sont adaptées. Ce lien entre un peu plus en détails sur les différences entre le cycle WLTP et le NEDC.
Au niveau de l'impact sur les véhicules, le cycle WLTP permet de montrer une hausse de la consommation et émission des véhicules thermiques, et pour les véhicules thermiques une baisse de leur autonomie. Cependant, ce cycle introduit différents types d'utilisation (urbain, extra-urbain,...) et les constructeurs peuvent comme toujours essayer de valoriser leurs véhicules électriques en mettant en avant la valeur urbaine de ces derniers.
Pour finir, ce cycle permet d'encourager les constructeurs à travailler sur leur gestion de l'énergie et amélioration de leur batterie pour être plus compétitifs.

Semaine du 20 au 26 janvier

Cette semaine à partir du mercredi, nous avons pu effectuer de nouveaux tests sur la pile à combustible. Le système possédait une batterie et un fusible défaillant se qui forçait la mise en sécurité et empêchait la mise en route de la pile. Une solution a été trouvée en attente de la réception de la commande de la nouvelle batterie et du nouveau fusible, un technicien a conçu un fusible de fortune qui permet de faire fonctionner la pile sur les plus petite batteries. nous avons donc pu reprendre nos tests pour récupérer les données qui transitent sur les communications RS 485 et USB.


RS 485

trames de commandes
trames de réponses
Détection du module sur DCON Utility Pro


Dans un premier temps, nous avons voulu revérifier la configuration du module ICPDAS 7019R. Nous avons donc lancé le logiciel DCON utility, qui permet la configuration du module, directement sur le panel PC. Nous avons pu noter l'adresse du module, le baud rate, le nombre de bits de stop et tous les paramètres de la liaison série entre le panel PC et le module I-7019R.
Des recherches ont également été effectuées pour comprendre le protocole de communication "DCON" utilisé par le module. Les communications avec les modules I-7000 se composent de commandes générées par l'hôte et de réponses transmises par les modules I-7000.Chaque module possède un numéro d'identification unique qui est utilisé à des fins d'adressage et est stocké dans une mémoire non volatile. L'ID est 01 par défaut et peut être modifié à l'aide d'une commande utilisateur. Dans notre cas l'ID est configuré sur 00. Toutes les commandes des modules contiennent l'adresse ID, ce qui signifie que seul le module adressé répondra. On peut voir ci-contre le format des trames de commandes et de réponse :

Toutes ces trames sont envoyées sous format ASCII. Le calcul du checksum est relativement simple puisqu'il suffit de calculer la somme du code ASCII de tous les caractères de la chaîne de commande / réponse, à l'exception du caractère de retour (CR). La somme de contrôle est égale à la somme masquée par 0ffh.
Un envoi d'une requête de commande permettant de récupérer toutes les valeurs analogiques des différents capteurs connectés au module a été envoyé grâce à PuTTY au module à partir du panel PC et nous avons bien récupéré les valeurs des capteurs.

L'objectif qui suivait était donc de réaliser la même chose à partir de notre PC. Dans un premier temps nous avons recréé un montage permettant la connexion entre le module et notre PC grâce à un convertisseur RS-485 to USB. Une fois le port COM détecté, nous avons essayé de lancer le logiciel DCON_Utility afin de détecter le module. Cette fois-ci nous arrivons bien à détecter le module ICPDAS 7019R, ce que nous parvenions pas avant les vacances du fait de notre mauvaise configuration matérielle. En effet, cette semaine nous avons abandonné le fait de se coupler à la connexion RS déjà existante, et maintenant nous remplaçons le panel PC de la même manière qu'avec la charge.

Nous avons donc réeffectué le test avec PuTTY et nous arrivons également à récupérer les valeurs analogiques des différents capteurs via la communication RS-485 à partir de notre PC.

Requête de demandes des valeurs analogiques des capteurs connectés au module

La dernière partie à faire est donc de pouvoir communiquer avec le module ICPDAS via la communication RS-485 depuis notre PC mais cette fois en développant un algorithme sur LabVIEW afin de compléter notre interface qui sera dans ce cas complète et comportera toutes les données provenant de tous les capteurs du système. Pour cela un test a été effectué mais des erreurs de réception des réponses se présentent pour le moment.

USB - Charge électronique

Nous avons également repris le Labview de la charge. Précédemment, nous avions réussi à récupérer les données de tension, courant et puissance via l'envoie d'une trame de manière manuelle.
Cette semaine, nous avons amélioré le VI en reprenant et décortiquant la documentation de la charge ainsi que les tests effectués avant les vacances avec le Beagle12.

  • Envoie cyclique des requêtes 71 et 70 (lecture variable et état système)
  • Ajout d'une condition permettant la lecture de l'état de la charge (mode utilisé, input ON/OFF, mode de régulation, etc). Pour cela nous avons décortiqué la trame de réponse de la requête 70 (0x46).
  • Boutons ON/OFF de Remote et Input avec la requête 54 (0x36)

Nous avons pu bien vérifier que les envoies de changement d'état sont effectués grâce à la lecture de l'état de la charge, et pour le Remote, cela est directement indiqué sur le panneau de la charge.

  • Début de code pour contrôler le mode de régulation et le level avec la requête 54, pas encore de test d'envoie sur la charge

Cela fonctionne correctement en parallèle avec la communication CAN.
Voici la documentation avec laquelle nous travaillons pour connaitre les requêtes à envoyer à la charge: Fichier:Object list el3000 el9000 de en.pdf

Détails du VI de la connexion avec la charge au mois de janvier

Interface avec Onglets

Cependant, nous avons eu des problèmes avec l'interface globale. En effet, il s'avère que l'utilisation de la Commande Onglet était mal réalisée : les données s'actualisaient uniquement au moment du RUN. Nous avons donc tout remettre en place, ce qui n'était pas compliqué mais fastidieux.
De plus, la semaine dernière nous avions ajouté le Solar panel Management Monitor du PFE 2018. Il s'est avéré cette semaine lorsque nous avons pu vérifier notre VI, qu'il ne fonctionne pas avec la communication de la charge en même temps. Nous n'avons pas encore trouvé la raison.

Semaine du 27 janvier au 2 février

USB - charge électronique

  • amélioration de la structure du code avec de nombreux Structure Case (pour éviter des blocs IF trop nombreux)
  • envoie de requêtes sécurisé avec la mise en place de boutons grisés si le système n'est pas en Remote, afin d'éviter des erreurs d'envoie et réception. On peut voir sur l'onglet 1 (paragraphe Interface) le mode remote activé et les boutons disponibles, et sur les onglets 2 et 3 le free access avec les boutons grisés.
  • envoie de la requête 54 avec contrôle du level, fonctionne avec vérification par la trame décrivant l'état du système
  • mise en place des requêtes de changement de type de régulation et Set de valeurs. Mais problème non identifié (trames correctes par rapport à la documentation) et ces commandes ne fonctionnent pas. Nous attendons de re récupérer le sniffer Beagle 12 de M.Vantroys pour étudier les trames envoyées par le panel PC vers la charge.

RS485

Méthode de séparation des 7 valeurs des capteurs reliés au bus RS-485

La semaine dernière nous étions bloqués sur la partie communication série via le bus RS485 depuis LabVIEW. Après recherches nous avons identifié le problème qui provenait du caractère de terminaison des trames envoyées et reçues sur ce bus.Nous avons donc fait en sorte qu'un carriage return (\r) soit envoyés et reçus en fin de chaque trame et nous avons donc bien reçu l'intégralité des données provenant des capteurs connectés au module IICPDAS 7019R connecté au bus RS-485 relié à notre PC.
Nous avions le choix pour récupérer les valeurs de chaque port analogique:

  • Soit nous envoyons les 7 requêtes correspondant chacune à la demande d'un retour de valeur d'une entrée analogique correspondant.
  • Soit nous envoyons la requête permettant de récupérer une seule chaîne de caractères et nous travaillons sur celle-ci afin de récupérer chaque valeur en trouvant la bonne approche pour séparer les valeurs.

Nous nous sommes orientés vers la seconde solution car nous avons remarqué que les valeurs sont décrites avec le même nombre de caractères. Il suffisait donc simplement de faire une séparation en fonction de la longueur des valeurs afin de récupérer les 7 valeurs qui nous intéresse. Le diagramme de programmation,présent dans la vignette ci-contre, illustre la méthode.

Une fois les 7 valeurs récupérées, il a donc fallu faire le lien avec celle affichée sur le logiciel Heliocentris. Pour cela nous nous sommes servis du logiciel DCON_utility pro qui permet de sélectionner quel canal analogique on veut utiliser. La méthode de test a donc été de sélectionner un seul canal et de vérifier à chaque fois quelle valeur était correctement affichée uniquement lorsque le bus RS-485 était connecté au système. De ce fait nous avons pu faire la liaison avec les valeurs analogiques reçues et celle affichée sur l'interface.

Le dernier souci a été de trouver comment traiter les valeurs que l'on recevait avec des intervalles différents (+5v/-5v; 4mA..20mA). Des fonctions dans LabVIEW nous ont permis de traiter ces données afin qu'elles soient affichées comme elles l'étaientt dans l'interface Heliocentis. Ainsi nous avons pu compléter notre interface globale qui contient désormais toutes les valeurs des capteurs présents sur le système.

Gestion de la pile et DCDC converter via CAN

Nous avons eu quelques problèmes avec la communication CAN pour laquelle nous avons du redéfinir les sessions XNET.
Nous avons ensuite ajouté une partie écriture :

  • la gestion de la pile grâce à la requête 500x ainsi que sa réponse dans la requête 310x : cela permet de start, reset et stop la pile de la même manière que sur l'interface Heliocentris.
  • la gestion du convertisseur DCDC grâce à la requête 490x. Pour l'instant, elle ne fonctionne pas : en effet, la req490 est une requête envoyée constamment du panel pc vers le système. De ce fait, il semblerait qu'il y ait un conflit lorsque nous envoyons nous-même cette trame et de ce fait cela bloque le pc panel. Dans tous les cas, la trame envoyée ne semble pas démarrer le convertisseur, alors qu'elle correspond à celle lue sur NI NXET Monitor. Nous n'avons pas encore résolu ce problème.

Interface globale

Nous avons avancé sur les problèmes rencontrés la semaine dernière. Désormais, les onglets de l'interface globale sont entièrement fonctionnels (plus de problème d'actualisation). Sur cette interface se trouve les données issues de la communication CAN, des données de la charge, celles de la communication RS485 et l'interface du PFE 2018. Sur le côté gauche se situe une partie Commande, où il est possible de gérer une partie de la charge (depuis la comm USB) ainsi que la gestion de la pile (depuis le CAN).
Pour cela, nous avons repris complètement le VI associé. Nous avons utilisé la fonction onglet pour l'affichage des données uniquement en ce qui concerne le CAN.
Nous avons également retravaillé le VI de François-Xavier en réduisant le nombre de boucles while en une seule. Nous avons ajouté un paramètre de connexion au DAQ qui manquait. Enfin, pour associer les trois communications nous rentrons les parties de code associées à la connexion DAQ à notre boucle principale de récupération des données de la charge. Cela ralentit l'acquisition des données de François-Xavier mais permet une communication fonctionnelle avec la charge.
Voici ci-dessous l'interface Labview à ce jour, avec les trois onglets différents.
page 1 face avant Labview page 1 face avant Labview page 1 face avant Labview
Cette interface est donc complète en terme d'acquisition de données. Il y manque la gestion du convertisseur DC DC ainsi que l'envoie de commande des valeurs de référence de la charge mentionnés plus tôt. De plus, la première connexion à la charge n'est pas toujours un succès et nous aimerions résoudre ses bugs.
Le fait de bloquer sur l'envoie de commande à la charge nous empêche d'avancer comme nous le souhaiterions sur la simulation de cycles. Nous espérons que le sniffer Beagle nous débloquera (demandé mais M. Vantroys indisponible cette semaine)

Semaine du 3 au 9 février

HEL Remote du fournisseur

Cette semaine nous avons voulu tester l'API délivrer par Heliocentris que nous avions reçu une fois demandé à l'entreprise. Cette interface de programmation permet de récupérer la plupart des valeurs des capteurs du système mais aussi de contrôler la pile à combustible ainsi que le convertisseur DC/DC. Après étude du diagramme de l'API sur Labview, nous avons vu que le programme utilise des variables PSP. Ce sont des variables qui sont publiées sur un réseau par un autre programme labview par le biais d'un URL qui permet donc à d'autres programmes de récupérer les valeurs associées à ces variables partagées afin de les exploiter.

Nous avons donc essayé de lancer l'API en lecture et en écriture mais nous n'avons pas réussi à récupérer les valeurs de ces variables partagées et cela même malgré l'aide de monsieur Conrard qui a des connaissances en programmation LabView. Le problème semblerait venir de l'accès à ces variables qui ne se réalise pas. Nous pousserons nos recherches dans la semaine à venir si nos différents objectifs sont remplis.

Analyse trames TCP/IP

Pendant la première soutenance, un travail de fond sur les trames TCP/IP a été demandé afin de prouver qu'un reverse engineering était réellement compliqué à mettre en place et que le fait de lire les bus en aval du panel PC est justifié. Voici ci-dessous le fichier reprenant les premiers tests menés début janvier ainsi que la suite cette semaine.
Rapport d'analyse des trames TCP/IP : Fichier:Identification des trames TCP IP.pdf
Pour résumer, les données issues du CAN sont trop nombreuses et non isolables donc extrêmement difficiles (pour ne pas dire impossible) à identifier et comprendre. Celles du RS485 sont elles facilement identifiables mais nous n'avons pas réussi à trouver la conversion permettant de retrouver la valeur réelle des variables. Pour les données du bus USB (données de la charge), certaines données d'état sont identifiables et compréhensibles, mais pour les valeurs de courant tension et puissance nous n'avons pas réussi à retrouver les valeurs réelles pour les mêmes raisons que les données du bus RS485.

Gestion de la charge

Nous n'avons finalement pas eu de réponse de M. Vantroys par rapport au Beagle 12 mais nous avons réussi à retrouver les trames circulant sur le bus en installant Serial Bus Monitor sur le panel PC. Cela nous a permis de régler le problème de régulation, et pour les consignes de valeurs U, I, P nous avons fait un petit reverse engineering où nous nous sommes rendus compte d'un oubli dans la documentation.
Durant cette semaine, nous avons beaucoup amélioré l'expérience utilisateur en réglant le plus de bugs pouvant apparaître. Nous avons eu de nombreuses difficultés avec la gestion de type en programmation Labview, ainsi que les requêtes cachées mais nécessaires à la charge.

SET VALUES

  • Changement du types de conversion des données en lecture en écriture selon la documentation (apparition d'un pourcentage) avec changement des valeurs nominales selon ce que l'on a pu déduire
  • Envoie de la nouvelle valeur de consigne lorsque celle-ci est modifiée (structure événement)
  • Bouton grisés en fonction du mode de contrôle choisi pour éviter les bugs (U disponible en CV, I en CC, P en CP et tous requièrent l'input ON activé)

SET REGULATION

  • Envoie de la régulation choisie lorsque celle-ci est modifiée (structure événement) donc plus besoin de bouton de validation
  • Séquence d'envoie de requêtes avec d'abord check Remote ON et input OFF, changement de régulation, valeurs initiales de I et P (établies grâce au sniffer série), puis input ON afin d'éviter toute erreur
  • Toujours quelques bugs lorsque le contrôle en tension est choisi sur l'interface physique de la charge, mais cela n'a pas l'air d'être dû à la programmation.
  • Inspirés par l'interface HEL, seuls les modes de contrôle CC et CP sont accessibles, même si l'on sait au besoin que les autres modes peuvent être rajoutés.

INTERFACE USER-FRIENDLY

  • Le Remote Off (accès libre à l'interface physique) n'est disponible qu'en Input Off
  • Le input ON/input OFF n'est disponible qu'en Remote ON
  • La liaison série est désormais correctement fermée à chaque fin d'utilisation (Close de la connexion), après un bloc de fin (Input Off, Remote Off automatique), le tout exécuté après une erreur sur la connexion ou l'appui d'un bouton stop commun à toutes les boucles (stop également commun à la boucle RS)
  • Présence d'un bloc d'initialisation au début de la connexion : mode Remote ON, Level A et input OFF. Désormais, seulement le mode Level A est accepté pour éviter d'autres erreurs
  • Ce bloc d'initialisation est de nouveau appelé à chaque fois que l'utilisateur passe de free access à remote ON afin d'éviter toute erreur. Cela permet d'avoir la possibilité d'être en free access (pas disponible sur HEL du PC) tout en empêchant les bugs une fois le contrôle de nouveau établi sur le PC.
  • Une led "fonctionnement de la charge" a été ajoutée dans la face avant et s'allume lorsque la connexion avec la charge est établie

Gestion de la pile

Nous avons retravaillé la lecture du tableau information flags issu du CAN permettant d'avoir les valeurs d'ouverture/fermeture des vannes ainsi qu'un bit de fonctionnement/arrêt de la pile, car nous avions commis des erreurs en début de projet. Cela a permis la mise en place de sécurités pour l'utilisateur afin d'avoir une expérience user-friendly :

  • Bouton stop grisé tant que la pile n'est pas en fonctionnement
  • Bouton start grisé pendant le fonctionnement de la pile jusqu'à la fin de l'arrêt (utilisation d'une structure événement)

Cependant, nous n'avons pas pu effectuer énormément de nouveaux tests car en fin de semaine il nous a été impossible de démarrer le système (mise en défaut automatique) alors que les batteries n'ont aucun problème (nous les rechargeons désormais régulièrement et nous avons vérifié la tension à leur borne) et les connexions à l'arrière n'ont à priori pas de problème.

Cycles sur Labview

Dans la suite de notre projet, l'idée d'appliquer un cycle de véhicule électrique à la charge électronique de notre système a déjà été citée précédemment dans ce wiki. Pour compléter cet objectif nous avons donc essayé cette semaine d'envoyer différentes valeurs en courant à la charge de manière cyclique qui répondrait donc à la demande de vitesse du cycle du véhicule. Pour cela nous avons tout d'abord écrit un script Matlab qui créé deux tableaux, l'un qui contient les valeurs en courant et l'autre qui contient les valeurs de temps liés aux valeurs de courant.

Diagramme illustrant l'exploitation des tableaux grâce à un script Matlab
Consigne en courant et trames envoyées à la charge sous forme de graphe

Labview permet également d'exploiter les scripts Matlab et donc d'exploiter les tableaux associés. Nous avons affiché sous forme de graphe dans un premier temps la consigne du cycle de courant qui devait être injecté dans la pile ainsi que les valeurs associés aux trames de "set values" en courant envoyées à la charge. Nous obtenions le bon cycle en courant mais comme plusieurs valeurs étaient négatives nous n'avons pas choisi ce cycle pour le tester sur la charge.

Nous avons modifié le script Matlab afin d'obtenir un "step"(0 pendant un certain temps puis 1 pour le reste du temps et les valeurs associées aux trames envoyées correspondent toujours bien à la consigne.

Nous n'avons pas encore testé l'envoi du cycle à la charge car nous souhaitons instaurer une sécurité au niveau de l’accès à la charge durant l'envoie du cycle en courant ainsi que vérifier la fiabilité des trames en lisant les valeurs reçues lorsqu'on envoie de manière continue une requête de "request value" en courant.

Cycles sur Matlab

Comme expliqué quelques semaines plus tôt, nous avons pour but de réaliser une simulation de test de véhicule électrique avant sa mise sur le marché en lui faisant subir un cycle de conduite (ECE, WLTP, ...). Notre charge externe représenterait donc ce véhicule.
Nous avions vu que ces cycles imposent donc une vitesse afin de connaître la consommation/autonomie du véhicule. Pour notre charge, nous pensons imposer un courant et il faut donc travailler sur une conversion vitesse vers courant.

Pour cela, nous retravaillons les cours de VEH et REM que nous avons eu pendant notre cursus IMA. La REM (Représentation Energétique Macroscopique) permet de mettre sur papier les différents éléments composants un système (vision globale) tout en respectant la causalité des événements. Elle permet ensuite de réaliser une SMC (Structure Maximale de Commande) qui correspond à la REM inverse afin de retrouver la commande du système pour une valeur de sortie souhaitée. Grâce à cela, on peut alors retrouver le courant à imposer à la charge correspond à une vitesse.

Nous sommes entrain de travailler sur la REM et SMC de notre cas et nous avons donc vu avec Mme Semail quel courant injecter dans notre charge, qui serait celui en sortie de MCC. Cependant, lors d'une phase de freinage, le courant devient négatif. Or, notre charge ne peut pas recevoir de consigne négative. C'est très dommage car cela compromet notre volonté de suivre un cycle de test type WLTP, qui contient forcément des zones de freinage pour tester au mieux les réactions des véhicules. Nous allons devoir ajuster ces cycles en transformant les moments de freinage en moment de "roue libre" soit un courant nul. Cela forcément perd de son sens mais cela reste intéressant de pouvoir imposer à la charge des cycles et non pas simplement des valeurs. Si la charge venait à être modifiée ou si une autre type de charge venait à être ajouté, nos travaux pourraient alors prendre plus de sens.
Plus de détails sur le simulink sera donné dans la semaine prochaine une fois qu'il sera fonctionnel.

Semaine du 10 au 16 février

Réinitialisation du convertisseur

Depuis le début du projet nous avions un problème avec le convertisseur DC/DC du système. On ne pouvait plus démarrer le convertisseur même en réinitialisant à chaque fois celui-ci par le biais de l'interface HEL. L'erreur "DC/DC over critical voltage battery" s'affichait et revenait à chaque fois après n'importe quelle manipulation.

Il était encore jusqu'à cette semaine impossible de recharger les batteries via la pile à combustible ce qui est le principe et l'avantage de ce système.

Voulant régler ce souci nous avons donc demandé de l'aide à la personne qui a vendu le système à l'école.
Cette personne a fait le relais entre l'entreprise qui a produit le système et nous a donc indiqué comment réinitialiser les paramètres de configuration du convertisseur depuis l'interface ce qui a permis de refaire fonctionner le convertisseur DC/DC correctement.

Le système peut donc de nouveau recharger les batteries depuis la pile à combustible.

Gestion du convertisseur DC/DC

Une fois l'erreur, au niveau du convertisseur, supprimée nous avons pu approfondir la commande du convertisseur qui jusqu'ici ne permettait que la réinitialisation de celui-ci. Des améliorations ont été produite afin que l'on puisse démarrer, éteindre ou réinitialiser le convertisseur depuis notre interface.

Nous avons également ajouté la commande de la valeur en courant désirée pour recharger les batteries ou bien alimenter une charge en sortie du convertisseur DC/DC. Cette option était disponible sur l'interface développée par Heliocentris, on a donc décidé de trouver comment intégrer cette commande sur notre interface.

En effectuant un "reverse engineering" via la modification de la valeur de commande, nous avons pu déterminer l'allure de la trame d'identifiant 490 qui est envoyée par le panel PC au convertisseur via le bus CAN.

En réalisant l'envoi de cette trame via notre interface nous avons donc réussi à intégrer la commande de la valeur en courant en sortie du convertisseur.

Acquisition de données

Pour améliorer notre interface, nous avons décidé de donner la possibilité aux utilisateurs d'enregistrer les différentes valeurs présentes sur l'interface sur un temps d'enregistrement que l'utilisateur décide (il lance l'acquisition puis l'arrête quand il le souhaite).

Les valeurs sont enregistrées à une fréquence décidée également par l'utilisateur et sont envoyées dans un fichier de type CSV, exploitable avec un tableur comme Excel ou LibreOffice Calc.

Pour réaliser cette amélioration nous nous sommes servi des outils disponibles sur Labview et des exemples sur internet pour intégrer l'ouverture d'un fichier depuis sa racine et l'écriture de valeurs dans celui-ci depuis notre diagramme de programmation.

Le tout intégré dans une boucle for, cette amélioration de notre programme a donc permis d'ajouter la possibilité d'acquérir des données depuis notre interface.

Cycle d'un véhicule électrique

Voici le document expliquant la mise en oeuvre du Simulink représentant la REM d'un véhicule électrique : Fichier:REM véhicule électrique.pdf
De cette étude nous obtenons donc le simulink suivant, et nous récupérons la valeur i_dcm_ref :

Simulink matlab représentant la REM et SMC d'un véhicule électrique

Depuis le fichier d'initialisation associé

  • modification de I_dcm_ref (ce qui affecte nécessairement le cycle) pour ne pas avoir de valeurs négative ou trop grande
  • ajustement nombre de valeurs pour que la période d'envoi ne soit pas trop rapide (500ms contre 0.001ms à la base)
  • travail sur 3 cycles : ECE (3min), NEDC (20min), WLTP (30min)

Ci dessous pour les trois cycles ECE, NEDC et WLTP la différence entre le i_dcm théorique à injecter, et celui qui est injecté dans la charge soit toujours positif (avec la vitesse associée). On remarque que la commande fonctionne parfaitement mais, comme le courant n'est pas être négatif dans le deuxième cas, la vitesse réelle a plus de mal à suivre la vitesse de référence car sans l'utilisation des freins, le véhicule ne peut pas freiner depuis le courant.

cycle ECE, comparaison entre le i_dcm théorique celui injecté dans la charge, avec leur v_veh associée
cycle NEDC, comparaison entre le i_dcm théorique celui injecté dans la charge, avec leur v_veh associée
cycle WLTP, comparaison entre le i_dcm théorique celui injecté dans la charge, avec leur v_veh associée


Le VI Labview associé est composé :

  • d'un script Matlab pour récupérer les tableaux (selon le cycle choisi la variable récupérée est différente)
  • conversion de la valeur en requête vers la charge
  • envoie de valeurs cyclique (toutes les 500ms)
  • envoie d'une requête de lecture pour lire la valeur réelle de la charge
  • trace un graphe de la valeur de référence, un graphe de la valeur réelle (tracé en temps réel) et et un graphe combinant les deux

La période de 500ms a été choisie afin que le Labview ait le temps d'envoyer à la charge la valeur de référence, puis la requête de lecture de la valeur réelle puis la lecture.
A tout moment l'utilisateur peut décider d'arrêter ce cycle grâce au bouton STOP.
De plus, ce sous-VI est appelé depuis un bouton sur la face avant générale de l'interface, et ouvre une nouvelle fenêtre avec ces graphes pour une meilleure lecture.
Voici ci-dessous un résultat obtenu lors de l'envoi d'un cycle ECE adapté à la charge :

cycle ECE en courant en consigne de la charge depuis Labview, avec référence en rouge et valeur réelle en bleu


Cependant, quelques problèmes surviennent encore de temps en temps.

Recharge des bouteilles stockées directement dans le système

Jusqu'à maintenant nous rechargions les bouteilles en dehors du système de pile à combustible via l'électrolyseur. Après étude de la documentation nous avons remarqué qu'il était possible de recharger les bouteilles directement lorsqu'elles sont placées dans le système de pile à combustible en connectant directement l'électrolyseur à la chambre de stockage d'hydrogène.

Après tests nous avons réussi à recharger les bouteilles en essayant la configuration décrite au-dessus ce qui laisse de nombreuses ouvertures à ce projet.

En effet comme nous avons lié l'interface réalisée l'année dernière par FX sur le système de production d'hydrogène, on peut imaginer le développement d'une nouvelle interface permettant le contrôle de l'électrolyseur qui n'est jusqu'ici pas disponible depuis un PC. Cette interface permettra donc, en la liant à la notre et celle de FX, de développer des algorithmes d'automatisation du système de production d'hydrogène et de recharge des bouteilles en fonction de la production des sources d'énergies renouvelables qui est supervisé grâce à l'interface de FX.

Par exemple, les sources d'énergies renouvelables produisent assez de puissance pour produire de l'hydrogène et donc recharger les bouteilles qui alimentent la pile à combustible qui recharge des batteries ou qui alimentent une charge grâce au convertisseur DC/DC. L'autre cas de figure est donc que la puissance délivrée par les sources d'énergies renouvelables n'est pas suffisante dans ce cas la recharge est interrompue et on passe sur un fonctionnement sur batterie pour l'alimentation d'une charge. Bien sûr tout cela sans que l'homme n'est besoins de sortir les bouteilles du système pour les recharger, qui était la problématique précédente pour l'automatisation, puisque l'on a vu que l'on pouvait recharger les bouteilles en connectant directement l'électrolyseur à la chambre de stockage de bouteille d'H2 du système de pile à combustible.

Calcul des puissances

Notre interface indique des valeurs de puissance qui jusqu'ici ne correspondaient pas à celles indiquées par le logiciel Heliocentris car des calculs étaient nécessaires pour retomber sur les valeurs correctes. Durant cette semaine nous avons donc cherché des liens entre les valeurs que nous récupérions et les puissances qui en étaient déduites. Nous avons réussi à retrouver les valeurs de puissance entourées sur la mais il nous reste des valeurs inconnues.

Livrables

Documents rendus

Rapport de mi-projet: Fichier:PFE13 rapport intermédiaire.pdf
Diaporama de mi-projet : Fichier:PFE13 soutenance intermédiaire.pdf

Rapport fin de projet : Fichier:PFE13 rapport final.pdf
Diaporama de fin de projet : Fichier:PFE13 diapo soutenance finale.pdf

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P13&oldid=82239 »