Réalisation - Green Brain, Mersen
Lien vers la version final de l'interface
Contexte:
Cette réalisation prend place lors de mon premier stage durant le BTS SIO en juillet 2015.
Il se déroule dans l'entreprise Mersen. Cette entreprise conçoit et produit, principalement de l'appareillage de protection électrique (fusible, porte fusible, etc...).
Mon travail prend place dans le cadre du développement d'un ensemble d'appareil de protection des installations photovoltaïque (panneau solaire) appelés Green Brain. Ces appareils permettent de couper une installation en cas de panne ou, à la demande de l'utilisateur. Permis ces appareils, un module optionnel de "monitoring" peut être ajouté. Celui-ci permet de suivre en temps réel l'état de l'installation. C'est sur l'interface d'utilisation de cet appareil que mon travail va se porter.
Détail d'une installation utilisant Green Brain:
Chaque panneau solaire de l'installation est équipé d'un appareil appelé Green Eyes. Celui-ci relève les mesures du panneau (tension, courant, température ).
Les panneaux sont regroupés en "String" (chaîne de panneau) relier à un appareil appelé GBS (Green Brain String). Celui-ci surveille le bon fonctionnement des panneaux.
Enfin un appareil appelé GBM (Green Brain Monitoring ), est connecté à 4 GBS au maximum. Celui-ci collecte les informations récoltées par les GBS.
Existant:
Le coeur de l'appareil de monitoring, appeler GBM (Green Brain Monitoring), est une carte électronique.
L'élément central, dans le cadre de mon travail, est le
microcontrôleur 32bits STM32F103 présent sur cette carte.
C'est celui-ci qui exécute le programme codé en C présent dans sa mémoire flash.
L'interface utilisateur est également stocker sur la mémoire du microcontrôleur et est codée en HTML / CSS / Javascript. C'est un programme libre appelé
uIP (micro IP) qui fait office de serveur HTTP.
Pour se connecter à l'interface utilisateur, un port RJ45 est présent sur la carte électronique. L'utilisateur tape l'adresse ip configuré dans uIP pour communiquer avec le microcontrôleur via un navigateur web classique.
Pour chaque page stocker dans la mémoire du microcontrôleur, uIP exécute un code qui récupère la page puis l'envoi au client. Ce code en mémoire peut être modifier pour intervenir sur la page (à la manière d'un interpèteur PHP).
Cahier des charges:
Mettre en place l'interface définitive du GBM, permettant de suivre l'état de l'installation.
La contrainte principale est due à la faible puissance du microcontrôleur et la faible capacité de stockage de sa mémoire. Ainsi, il faudra optimiser au maximum l'espace occupé et les ressources processeur consommé.
Environnement de travail :
SVN subversion tortoise : gestionnaire de version, intégré à l'explorateur windows.
Eclipse, pour le codage en C : colorisation du code, environnement de debug.
PSPad, pour le codage du HTML/CSS et Javascript: colorisation du code, divers outils.
Console développeur de Firefox (navigateur web):
- Possibilité de parcourir le code html d'une page facilement.
- Débuggeur javascript.
- Permet de modifier en temps réel le CSS d'une page.
- Console d'erreur sur la page.
Détaille de réalisations:
Découverte du fonctionnement du GBM :
Transfère du code en C sur le microcontrôleur une fois celui-ci compilé: l'ordinateur est relié à une carte électronique, disposant d'un port usb en entré. En sortie de cette carte, une nappe vient se connecter sur des pins du GBM. Sous Eclipse, un "external tool" spécialement configuré permet de transféré le programme compilé dans la mémoire du microcontrôleur. Une fois le transfert terminé, le microcontrôleur s'initialise automatiquement et exécute le programme présent. A ce stade, il écoute le port RJ45 de la carte et il est ainsi possible de communiqué par l'intermédiaire de celui-ci.
Choix techniques:
Afin de réduire au maximum la taille totale qu'occuperont les pages web, tout le code sera présent sur la page html, css et javascript compris. Cela diminue la taille totale comparée à un système avec un fichier pour chaque type de code.
Une fonction "compression" de PSPad permet également de diminuer la taille des fichiers en supprimant les espaces et sauts à la ligne présents dans le code.
Les images utilisées, sont compressées au maximum afin d'avoir le meilleur ratio taille/qualité.
Présentation interface :
Elle est composée de plusieurs page énuméré ci dessous:
- login.html : Page d'accueil permettant de s'identifier pour accédé aux fonctionnalités. Cette partie n'est pas implantée totalement et tout mot de passe et login sont accepté.
- switch.html : Permet de couper manuellement l'installation en envoyant un signal au microcontrôleur.
- gbc_setup.html : Page de configuration des appareils connecté à l'installation. Dialogue avec le microcontrôleurs grâce à un formulaire HTML. La partie cotée serveur n'est pas encore implanté.
- gbs_monitoring.html : Affiche les différentes mesures de l'installation (tension, courant, température).
- maintenance.html : Affiche le statut des GBS connectés à l'installation. A ce stade les couleurs n'ont pas de signification définit.
- cartographie.html : page non implanté, il y sera afficher un schéma d'ensemble de l'installation.
- 404.html : page affiché lorsque l'utilisateur demande l'affichage d'une page qui n'existe pas.
1ere version de l'interface:
Fonctionnement : Récupération des informations à afficher sur la page de monitoring (tension, courant, température). Lorsque la page est demandée au serveur http du microcontrôleur ( programme uIP ). Celle-ci est balayée (parsée) intégralement et les caractères % remplacer par les valeurs appropriées. Ce système posai problème car le caractère % est utilisé en CSS. De plus, pour que les valeurs s'actualisent régulièrement, un code html déclenchai régulièrement le rafraîchissement de la page. L'accès au microcontrôleur et sa rapidité étant faible : la page était trop lente à s'affiché.
Une solution fut trouvée: utilisé l'Ajax. En effet, l'Ajax permet d'envoyer une requête http de type GET sans recharger la page. Il suffisait de géré cette requête cotée serveur avec uIP afin de récupérer les valeurs de l'installation.
Détail de la recherche de solution aux problèmes lier au remplacement du caractère % par les valeurs de l'installation (prise en charge d'incident):
A l'origine j'ignorai le fonctionnement cité ci dessus, tous ce que je constatai était que la page ne s'affichai pas correctement, le CSS semblai ne pas fonctionné correctement. En utilisant la console de développement de Firefox, je pu remarque des erreurs dans le code du CSS. Afin de découvrir d'où viennent ces erreurs, j'utilise le débuggeur d'éclipse qui permet de faire avancer pas à pas le programme coté serveur lors du chargement d'une page, et scruté les variables en temps réel. Lors de l'exécution du programme, celui-ci va chercher la page stocker en mémoire dans le microcontrôleur et la place dans une variable.
En scrutant le contenu de cette variable, je ne constate aucune erreur dans la page dans la partie du CSS qui ne fonctionnai pas.
Mais c'est en continuant à faire défiler pas à pas les instructions du programme que je me rends compte que celui-ci modifie le contenu de la variable en remplacent les caractères % par une valeur. D'où les problèmes avec mon CSS contenant ce caractère (par exemple pour définir la taille d'un élément de la page). La solution sera celle cité plus haut, abandonné ce système de remplacement de caractère, et utilise l'Ajax pour récupérer les valeurs de l'installation.
2eme version de l'interface:
Le design de cette version de l'interface est basé sur une interface crée en flash par un précédent stagiaire. J'ai recrée cette interface en html, css et javascript pour la faire fonctionner sur le microcontrôleur.
Détail du fonctionnement : Comme indiqué précédemment, les différentes informations variables de l'installation sont récupère via Ajax.
Elles sont retournées par le serveur sous la forme de fichiers xml, facile à parcourir coté client.
Trois fichiers xml sont utilisés :
- etatSystem.xml : donne l'état du system, en marche ou arrêter.
- presenceGBS.xml : donne le nombre de GBS présent et leur état sous forme de nombre. A ce stade, la signification de chaque nombre n'est pas encore définie. Le principe se rapprochera de celui-ci : 1 en fonction, 2 en fonction mais un problème est présent, 3 arrêté.
- dynamiqueMonitoring.xml : donne les valeurs des mesures de l'installation pour chaque GBS présent (tension, courant, température).
Les différentes valeurs utilisées à ce stade sont statiques, écrit en dur dans uIP. Elles seront remplacer plus tard par des variables contenant les valeurs de l'installation (tension, courant, température), lorsque la partie du programme récupèrent les valeurs sera codé.
Coté client, des fonctions javascript sont utilisées pour traité les informations récupérées.
Il en existe 2 différentes type :
- Le premier type récupère le nombre de GBS connecter à l'installation et affiche le nombre de GBS correspondant. Elle est exécutée au chargement de la page. Les pages concernées sont : gbc_setup.html, gbs_monitoring.html et maintenance.html.
- Le second type est exécuté régulièrement à l'aide d'un timer. Ce type de fonction modifie les informations présent sur la page.
- Sur gbs_monitoring.html se sont les valeurs des mesures de l'installation(tension, courant, température).
- Sur switch.html, l'état de l'installation (marche ou arrête).
- Sur maintenance.html , l'état des GBS (représenté par des couleurs)
Bilan réalisation :
Les bases de l'interface sont présentes. Le travail restant est d'implanté coté serveur les valeurs de l'installation (tension, courant, température.) Il reste également la page cartographie.html, elle affichera un schéma global de l'installation. L'identification de l'utilisateur doit également être implanté.