Développement d une application de supervision d installations photovoltaïques

Transcription

1 Mémoire pour l obtention d un diplôme de chef de projet en informatique et robotique Développement d une application de supervision d installations photovoltaïques Guillem SAINT-GERMES Promotion Stallman Le 9 septembre 2011 Tuteur école : Blaise MADELINE Tuteur entreprise : Vladimir GUEVEZOV

2 Préambule Durant ma formation en apprentissage au sein de la société Internet-Consult à Cabestany, et à l Institut Méditerranéen d Etudes et Recherches en Informatique et Robotique (IMERIR), il m'a été donné la possibilité d apprendre des techniques et technologies de programmation informatique ainsi que des méthodologies de gestion de projets. Ce mémoire conclut ces trois ans de formation. Il est présenté en vue de l obtention d un diplôme de «chef de projet en informatique et robotique». Il fait découvrir la société Internet-Consult, puis explique mon travail d avril à octobre 2011, et plus précisément le déroulement du projet de «développement d une solution de supervision d installations solaires photovoltaïques». Le document a été soumis à Tecsol et Internet-Consult pour validation et respect du secret professionnel. Il a pour but de prouver mes capacités de synthèse et de gestion d un projet informatique. Mémoire Saint-Germes Guillem 2

3 Remerciements Ma reconnaissance va d'abord à Guy Blazy qui a contribué à mon orientation vers l'imerir, puis m a présenté mon maître d'apprentissage Vladimir Guevezov pour valider mon option de formation en alternance. Mes plus vifs et sincères remerciements à Vladimir Guevezov, gérant de la société Internet- Consult pour l attention et la confiance qu il m a accordées au cours de mes trois ans en qualité d apprenti au sein de son entreprise. Toute ma gratitude aussi à François Figarola, développeur chez I-Consult, qui a su m'accompagner et me guider dans mon travail dans la société, et Béatrice Masse, infographiste chez I-Consult, pour sa gentillesse et son écoute. Je remercie vraiment toute l'équipe d'enseignement de l'imerir pour la qualité de la formation dispensée. Mémoire Saint-Germes Guillem 3

4 Sommaire I. Glossaire... 8 II. Introduction Présentation du sujet a) Contexte b) Le projet Plan du mémoire III. L entreprise Internet-Consult Implantation Evolution IV. Etude du projet Etude du besoin a) Besoins du bureau d études b) Utilisateurs Analyse du problème a) Mode de fonctionnement b) Modélisation c) Collecte et Stockage d) Traitement e) Télésuivi f) Visualisation Etat de l Art a) Concurrence b) Projet précédent : «PV monitor» Conception d une solution a) Modélisation b) Collecte des données c) Traitement avant stockage d) Télésuivi et alarmes e) Visualisation des données Mémoire Saint-Germes Guillem 4

5 V. Réalisation et résultats Choix des technologies Matériels et logiciels a) Linux Ubuntu b) Environnement de développement c) Serveur Apache / PHP d) Serveur base de données Postgresql e) Serveur FTP f) Schéma matériel de l application Langages a) PHP b) Javascript c) CSS / HTML d) PGSQL et SQL Technologies Résultats a) Démonstration en ligne b) Interface graphique c) Gestion d une installation d) Administration et configuration e) Interface mobile Chiffres clés VI. Gestion de projet Ressources Planification a) Délais et objectifs b) Retards c) Planning Méthodologie a) Cycle de développement b) Versionnage c) Outils collaboratifs Qualité a) Réunions b) Documentation c) Tests et environnement de test Validation et mise en production Mémoire Saint-Germes Guillem 5

6 6. Avenir du projet VII. Conclusion Bilan du projet Bilan personnel VIII. Bibliographie Livres Sites IX. Annexes Mémoire Saint-Germes Guillem 6

7 Table des illustrations Figure 1 : Plan du mémoire Figure 2 : Schéma de récupération des données de l installation Figure 3 : Flux des données jusqu au serveur FTP Figure 4 : Schéma de l architecture globale de l application Figure 5 : Représentation d'une installation Figure 6 : Représentation de la table de stockage Figure 7 : Exemple de structures de tables pour les mesures de l installation id Figure 8 : Schéma de la structure des tables de stockage des mesures Figure 9 : Flux de données de la production d un onduleur Figure 10 : Procédure d unification des données Figure 11 : Représentation schématique de la page d accueil de l application Figure 12 : Représentation schématique d une page de visualisation d une installation Figure 13 : Représentation schématique de l interface web mobile Figure 14 : Diagramme de composant de l'application Figure 15 : Page d accueil de l application Figure 16 : Page de sélection d une installation Figure 17 : Page d informations générales sur une installation Figure 18 : Page de visualisation des données de production Figure 19 : Page d administration d une installation Figure 20 : Fenêtre modale de gestion des onduleurs Figure 21 : Page d administration générale des modèles de matériels Figure 22 : Page d informations générales Figure 23 : Page de visualisation des données Figure 24 : Répartition de l'utilisation des différents langages de programmation Figure 25 : Chiffres clés du développement Figure 26 : Diagramme de Gantt de la réalisation du projet Figure 27 : Représentation du cycle en spirale Liste des annexes Annexe 1 : Diagramme de Gantt prévisionnel du cahier des charges Annexe 2 : Diagramme UML de la base de données Annexe 3 : Exemple de fichier de configuration de datalogger Annexe 4 : Exemple de fichier de configuration d'un onduleur Annexe 5 : Exemple de fichier de données au format CSV visualisé sous forme de tableau Mémoire Saint-Germes Guillem 7

8 I. Glossaire I. Glossaire Bureau d études Désigne le bureau d études en énergies solaire { l origine du projet : «Tecsol». Client CSV Datalogger FTP GPRS Irradiance XML Dans le document le terme «client» sera utilisé pour nommer un utilisateur non administrateur de l application, c'est-à-dire un client du bureau d études en énergies solaires. Comma-Separated Values est un format de fichier informatique représentant des données tabulaires sous forme de «valeurs séparées par des virgules». Désigne un matériel présent sur chaque installation et sur lequel sont connectés l ensemble des matériels. Il a pour but de récupérer leurs données puis de les transmettre. File Transfert Protocol est un protocole de communication utilisé pour échanger des données informatiques sur un réseau TCP/IP. Global Packet Radio Service est une évolution du standard de téléphonie mobile «GSM» qui permet notamment transferts les données par paquets. Désigne la puissance d un rayonnement lumineux sur une surface, elle est exprimée en watt par mètre carré (W/m²). On peut schématiquement affirmer que cela correspond à la puissance de l ensoleillement. extensible Markup Language est un langage informatique de balisage générique. Sa syntaxe est reconnaissable par l usage de chevrons (< et >) encadrant les balises. exemple : <section>glossaire</section> Ce glossaire reprend les mots inhabituels employés à plusieurs reprises dans le document. Des notes de bas de pages sont placées pour les mots utilisés ponctuellement. Certaines définitions ont été adaptées depuis le site Mémoire Saint-Germes Guillem 8

9 II. Introduction II. Introduction 1. Présentation du sujet 1. a) Contexte Depuis plus de dix ans l Internet se développe et nous avons pu constater une explosion des demandes de création de sites ou d applications Web. En effet il est maintenant inconcevable qu une entreprise innovante n ait pas de site à son nom. De plus les technologies relatives à l Internet ne cessent de s améliorer pour fournir de meilleurs services, en termes de vitesse de connexion ou en termes d interactions possibles. D un tout autre côté nous assistons à une montée en puissance des technologies énergétiques dites de développement durable comme l éolien ou le solaire. De plus en plus de collectivités ou de particuliers décident de contribuer à cet effort général en faisant installer chez eux des systèmes autonomes de production d énergie «écologique». Cependant malgré leur autonomie de production, il est vrai que de tels systèmes demandent de l entretien et une supervision afin de détecter le plus rapidement possible un dysfonctionnement et d y remédier. C est { ce niveau qu interviennent les nouvelles technologies de communication et d échanges de données telles que l Internet. Le projet présenté se situe à la frontière entre les deux sujets : les énergies renouvelables et l Internet. Mais nous nous consacrerons plus précisément à la supervision d installations solaires photovoltaïques. L origine du projet est le bureau d études Tecsol, spécialisé dans l énergie solaire et référence dans ce domaine depuis plus de 20 ans. Il propose notamment des offres d études, de supervision et de gestion de projet sur des mises en place d installations photovoltaïques ou thermiques pour des particuliers ou des sociétés. Ces installations sont capables de générer une grande quantité de données sur leur état ou de mesurer la production et l ensoleillement à partir de capteurs qui leurs sont rattachés. Afin de superviser et de détecter d éventuels problèmes, ces données peuvent être récupérées puis analysées. C est donc dans l optique de fournir un meilleur service { ses clients, mais aussi d être capable de gérer les installations à distance, que Tecsol a décidé de faire appel à la société Internet- Consult pour «le développement d une application de supervision d installations photovoltaïques». Mémoire Saint-Germes Guillem 9

10 II. Introduction 1. b) Le projet Le projet consiste au développement d une application Web de supervision d installations solaires photovoltaïques. Il s intitule «Tecsol PV Analytics» et s organise autour des fonctionnalités suivantes : Modélisation des installations, matériels et connexions. Collecte et stockage des données. Traitement des données. Télésuivi des installations (détection de dysfonctionnements, alarmes ). Visualisation des données. Cette application doit permettre au bureau d études de gérer ses installations à distance, mais aussi de fournir à ses clients un moyen d accès aux données de leurs installations. Il est intéressant de présenter ce sujet pour plusieurs raisons. Tout d abord il s agit d un projet complexe, tant du point de vue de sa structure que du point de vue des flux des données qu il doit gérer. La quantité de valeurs en jeu est énorme car les mesures sont effectuées toutes les dix minutes et que chaque installation compte des dizaines voire des centaines de sources de données. D un autre coté c est un projet qui par sa nature doit être flexible et modulable pour s adapter et pouvoir gérer un maximum de matériels différents, en limitant l ajout de code. Enfin c est une expérience personnelle et professionnelle de plus de cinq mois, qui m a occupé à temps plein, et il peut être considéré comme le témoignage particulièrement significatif de ma période d apprentissage au sein de la société Internet-Consult. Mémoire Saint-Germes Guillem 10

11 II. Introduction 2. Plan du mémoire Introduction et contexte Besoins et Demandes Expression des besoins et attentes Analyse du problème et conception d'une solution Réponses Réalisation de la solution Organisation et gestion du projet Bilan Figure 1 : Plan du mémoire. Le mémoire présente le projet «Tecsol PV Analytics» avec ses problématiques et ses attentes, puis apporte une analyse des demandes pour proposer une réponse. Il présente ensuite cette réponse en détaillant les technologies et techniques mises en place ainsi que l organisation des ressources pour la réalisation du projet. Ce plan permet de suivre pas à pas les différentes étapes du projet en séparant convenablement les besoins, de la solution réalisée. Ce document présente le travail réalisé sur le projet «Tecsol PV Analytics» d avril à septembre Mémoire Saint-Germes Guillem 11

12 III. L entreprise III. L entreprise 1. Internet-Consult Créée en 2000 la société Internet-Consult a pour objet la vente de prestations et des solutions orientées Internet ou utilisant des technologies Internet. Les prestations vont du conseil jusqu { la réalisation de systèmes «clef en main». Architecture des systèmes d informations. Conception, Développement et Distribution des produits et services basés sur des technologies Internet. Services, hébergement et gestion externalisée (Infogérance). Néo Géographie. Formation (Technologies Internet, Multimédia, Bases de données). Édition d applications Internet / Intranet. Consulting et assistance. Assistance dans la production et la gestion des contenus. 2. Implantation Basée à Cabestany, à côté de Perpignan, et restant à taille humaine en employant trois salariés, Internet-Consult développe principalement des solutions pour les entreprises et les collectivités de la région Languedoc-Roussillon, mais étend aussi son influence avec des contrats en Espagne ou dans des métropoles françaises. Voici quelques entreprises ou collectivités avec qui Internet-Consult travaille : Banque populaire Agglomération de Perpignan Mairie de Perpignan Mairie de Saint-Cyprien Réseau culturel La semaine du Roussillon Tecsol 3. Evolution Avec l explosion de la téléphonie et de l Internet mobile, Internet-Consult commence à proposer des prestations dans ce domaine comme le développement de sites ou d applications natives pour smartphone. Elle souhaite aussi acquérir une expérience et un savoir faire reconnu régionalement dans le domaine des gestionnaires de contenu (VCMS 1 ), afin de devenir une référence pour les collectivités locales. Site : 1 Visual Content Management System : logiciel destinée à la création et à la mise à jour de sites Web. Mémoire Saint-Germes Guillem 12

13 IV. Etude du projet IV. Etude du projet 1. Etude du besoin 1. a) Besoins du bureau d études Avec le développement des énergies renouvelables le bureau d études travaille de plus en plus sur des projets d installations photovoltaïques chez des particuliers ou des collectivités. L application de supervision des installations photovoltaïques «Tecsol PV Analytics» a pour but de faciliter le travail de gestion des installations et de permettre de proposer un nouveau service de télésuivi à ses clients. Les objectifs principaux de l application sont les suivants : Partie administration des installations o Définir et configurer les matériels des installations. o Modifier à distance les fichiers de configuration des dataloggers. o Détecter automatiquement des dysfonctionnements sur les installations. o Conserver un suivi des interventions de maintenance o Stocker les contrats de télésuivi et de maintenance Partie télésuivi pour les clients o Visualisation { partir d un site Internet o Version du site internet pour les téléphones mobiles (iphone et Android) o Interface d utilisation simple et efficace. Caractéristiques globales de l application o Flexible, il doit être possible d ajouter de nouveaux modèles de matériels o Evolutive, des plugins ou ajout de fonctionnalités doivent être possible 1. b) Utilisateurs Le système permet une identification de l'utilisateur pour définir les fonctionnalités auxquelles il a accès. L application prend en charge trois types d utilisateurs : Les administrateurs du bureau d études, qui peuvent configurer, modéliser les installations et gérer l application. Les clients du bureau d études, qui ont accès en visualisation aux données de leur installation. Les intervenants (installateurs, mainteneurs), qui ont un accès en visualisation ainsi qu un accès restreint en modification sur les installations dont ils sont responsables. Mémoire Saint-Germes Guillem 13

14 IV. Etude du projet 2. Analyse du problème Il est intéressant de comprendre la procédure de récupération des données qui est indépendante de l application. Figure 2 : Schéma de récupération des données de l installation. Chaque installation est équipée d un datalogger chargé de récupérer et de stocker temporairement les données arrivant sur ses ports, puis de les envoyer sur un serveur FTP à intervalles réguliers (10 min, 1 heure, 1 jour ), grâce à une connexion Internet ou par le réseau GPRS (radio) si l installation n a pas d accès Internet. Cette procédure est indépendante de l architecture serveur de l application. Cependant «Tecsol PV Analytics» doit être capable de générer des fichiers de configuration qui pourront être lus et utilisés par les dataloggers depuis le serveur FTP. Ces fichiers de configuration définiront les données de l installation { récupérer. Les fichiers de données récupérés sur le serveur FTP peuvent avoir deux formats différents (XML ou CSV) en fonction du type de datalogger { l origine de l envoi, ils sont transmis par les dataloggers dans des archives ZIP. 2. a) Mode de fonctionnement Outre les questions d'informatique pure de traitement des données, il est important de déterminer la nature de l'application : client-serveur classique ou web application. Etant donné la nature «distribuée» des clients et des intervenants, et la non maîtrise du matériel informatique des utilisateurs, le choix est quasi déterminé web application. Mémoire Saint-Germes Guillem 14

15 IV. Etude du projet 2. b) Modélisation L une des premières fonctions de l application est la modélisation des installations par les administrateurs. La modélisation d une installation doit être complète et prendre en compte l ensemble des données suivantes : Les informations générales (nom, position géographique, date de mise en service, photographies ). La configuration des bâtiments et pentes (inclinaisons et orientations). Les Matériels (panneaux solaires, capteurs, onduleurs ) et leurs connexions physiques sur le datalogger. Des données de production théoriques. A partir de cette modélisation qui doit correspondre à la réalité, il doit être possible de définir les données des matériels à relever, puis de générer des fichiers de configuration qui seront utilisés par l installation pour envoyer correctement les données. La modélisation permet de plus aux administrateurs de connaître en détail le matériel utilisé, ainsi que d accéder rapidement et { distance aux données techniques de l installation. 2. c) Collecte et Stockage Chaque installation envoie les données de ses matériels (selon le fichier de configuration) à intervalles réguliers (10 minutes, 1 heure ou 1 jour ). Ces données sont récupérées sous format CSV ou XML sur un serveur FTP. L application doit être capable pour chaque installation de récupérer les fichiers de données correspondants, de les lire, et de remplir une base de données afin de faciliter et d optimiser l utilisation ultérieure des données. Mémoire Saint-Germes Guillem 15

16 IV. Etude du projet 2. d) Traitement En pratique un panneau solaire n est pas directement branché au datalogger, des onduleurs sont utilisés pour stocker l énergie récupérée, et des compteurs sont généralement en place pour mesurer cette production. Figure 3 : Flux des données jusqu au serveur FTP. Depuis la valeur réelle jusqu'à la récupération des données sur le serveur FTP, les grandeurs physiques des valeurs ne sont pas forcément unifiées et varient en fonction du type de matériel utilisé. L application permet pour chaque matériel de convertir les valeurs récupérées dans une unité unifiée (W, W/m², Wh, C ). 2. e) Télésuivi L application doit détecter automatiquement des valeurs anormales ou incohérentes de production ou d ensoleillement. Pour cela l ensemble des données sera analysé et comparé à des seuils limites pour détecter les anomalies et envoyer des messages d alertes ( ou SMS) aux responsables de l installation en question. De plus le datalogger est capable d envoyer des fichiers d alertes pour des dysfonctionnements qu il détecte sur un matériel. L application utilise ces fichiers d alertes pour générer un évènement pour avertir. 2. f) Visualisation La visualisation comprend une partie d administration, utilisée pour modéliser et configurer les installations, et une partie de visualisation «publique» utilisée pour accéder aux données stockées et aux alarmes. L application doit être accessible et fonctionner sur la majorité des navigateurs actuels. Une version pour téléphone mobile iphone et Android doit être développée, avec des fonctionnalités réduites. Mémoire Saint-Germes Guillem 16

17 IV. Etude du projet 3. Etat de l Art 3. a) Concurrence Il existe déj{ des applications Web de gestion d installation photovoltaïques comme par exemple : Dielh AKO ( La Compagnie Electrique ( PVSoft ( Solarco ( Mais le code source de ces applications n'est pas accessible car il appartient aux entreprises qui les proposent. On peut cependant affirmer que lors de l installation de panneaux photovoltaïques chez un particulier ou une commune, le télésuivi est un argument de vente, et si l entreprise en charge du projet ne le propose pas, cela apparait comme un service en moins. Il est donc préférable de proposer ce service pour égaler la concurrence au niveau du télésuivi d installation. 3. b) Projet précédent : «PV monitor» Il ne s agit pas du premier projet qu Internet-Consult réalise avec le bureau d études Tecsol. Un projet du nom de «PV monitor» a été développé en 2010, qui intègre des fonctionnalités de visualisation des données sous forme de graphes ainsi que de stockages de ces données dans une base. Ce projet est cependant moins complet que «Tecsol PV Analytics», mais nous avons pu réutiliser les technologies mises en œuvre précédemment dans le but d accélérer le développement. Il est intéressant de noter que ce projet n a pas été repris comme base du projet «Tecsol PV Analytics» car le bureau d études a décidé de développer entièrement une nouvelle application, avec une nouvelle interface ainsi qu une gestion plus complexe et complète des données. Mémoire Saint-Germes Guillem 17

18 IV. Etude du projet 4. Conception d une solution Figure 4 : Schéma de l architecture globale de l application. La structure proposée met logiquement en place une base de données et un serveur web pour fournir l accès distant aux utilisateurs. La configuration de l application, la modélisation et la configuration des installations sont possibles { partir de l interface web. La récupération des données depuis le serveur FTP se fait à partir de scripts exécutés toutes les nuits, qui remplissent la base de données après avoir correctement converti les valeurs lues. Mémoire Saint-Germes Guillem 18

19 IV. Etude du projet 4. a) Modélisation 4. a) 1) Installation L élément central de l application est le concept «d installation». Une installation est composée de bâtiments (maximum 10) et ces derniers sont composés de pentes (maximum 4 par bâtiment) représentant les différentes orientations et inclinaisons possibles pour les panneaux solaires. Un client du bureau d études demande la supervision de son (ou de ses) installation(s) : de ce fait tout les objets modélisés par l application (matériels, données, intervenants ) sont rattachés à une installation. La modélisation définie des bâtiments et des pentes, ce qui permet une plus grande précision sur l organisation physique de l installation. De plus il est important de connaître la structure (bâtiment où pente) où sont rattachés les matériels afin d analyser plus finement les données récupérées (l irradiance est notamment différente sur deux pentes ayant une orientation ou une inclinaison différente). Bâtiment 1 : Résidence avec 1 pente (Sud) Bâtiment 2 : Garage avec 2 pentes (Sud et Est) Figure 5 : Représentation d'une installation. Mémoire Saint-Germes Guillem 19

20 IV. Etude du projet 4. a) 2) Intervenants Une gestion des utilisateurs est réalisée, ce qui permet de définir leurs droits d accès { l application. Pour définir ces droits, il a été mis en place la représentation des relations qu ils ont avec une installation. En dehors du fait qu un utilisateur soit administrateur, ces rôles définissent l accès { l application et aux installations : Maître d ouvrage (propriétaire de l installation) o Visualisation o Configuration simplifiée Bureau d études o Visualisation Installateur o Visualisation o Gestion des interventions Mainteneur o Visualisation o Configuration simplifié o Gestion des interventions 4. a) 3) Matériel Ce concept clé représente l ensemble des matériels qui peuvent être présents sur une installation. La plupart du temps il s agit de dataloggers, capteurs, onduleurs ou compteurs. Mais il peut aussi y avoir des matériels moins habituels comme des écrans, anémomètres ou encore antennes. Ils sont tous reliés à une installation, soit en y étant directement rattachés, soit par l intermédiaire de structures. La liste des types de matériels est la suivante : Datalogger Onduleur Compteur Capteur ensoleillement Capteur température Anémomètre Centraliseur Antenne Ecran Autre La majorité des matériels est la source d une ou plusieurs valeurs : on appellera ces différentes valeurs les «paramètres» d un matériel. Ainsi un capteur de température ne renvoie qu un paramètre par défaut qui est la température. Mais un onduleur par exemple peut générer un paramètre par défaut qui est son énergie, mais aussi une liste de paramètres supplémentaires comme sa tension en entrée, son intensité en entrée, ou sa durée depuis laquelle il est actif. Le paramètre est important lors de la récupération des données, afin de bien faire correspondre une valeur à un matériel. Mémoire Saint-Germes Guillem 20

21 IV. Etude du projet D une façon générale, le comportement des matériels est rattaché à leur modèle. Il a donc été mis en place le concept de «Modèle» qui regroupe toutes les caractéristiques communes à plusieurs matériels partageant ce même modèle. Un administrateur peut ainsi configurer globalement le comportement d un matériel { sa création dans la modélisation. 4. a) 4) Points de mesures Les matériels sont les sources de données de l application, mais il a rapidement été indispensable de définir des valeurs particulières comme «la production de l installation» ou «la production d une pente». De plus beaucoup de matériels génèrent une multitude de paramètres mesurables en plus de leur valeur par défaut (uptime 2, charge max, température ). Il est donc apparu que certaines valeurs ne pouvaient pas être directement récupérées depuis un matériel, mais devaient plutôt être calculées (ex/ la production d un bâtiment qui serait une addition de production d onduleurs). Dans ce but il a été mis en place le concept de «point de mesure» comme source de données utilisable. Un point de mesure définie une donnée utilisable pour les graphes et pour les vérifications de cohérence des valeurs. Il peut être défini de deux façons différentes : Directement relié au paramètre d un matériel, il utilise les valeurs de ce paramètre comme données. Calculé { partir d autres points de mesures, pour récupérer par exemple la production totale des onduleurs. L utilisateur peut saisir une équation avec comme variable le nom des points de mesures en question. Il a fallu ensuite définir à quoi correspondaient réellement les valeurs récupérées depuis un point de mesure par rapport à une installation. Nous avons donc mis en place un concept de «référence», et un point de mesure peut ainsi référencer des données importantes et notables de l installation. Ces références doivent être obligatoirement renseignées pour un bon fonctionnement de l application : Installation o Référence production o Référence compteur EDF o Référence compteur installation o Référence production des onduleurs Pour chaque pente o Référence production o Référence ensoleillement o Référence température Ces points de mesures référents sont ensuite utilisés pour la détection des incohérences et pour l affichage des graphes de la partie visualisation. 2 L uptime est le temps depuis lequel un matériel est sous tension. Mémoire Saint-Germes Guillem 21

22 IV. Etude du projet 4. b) Collecte des données 4. b) 1) Configuration des dataloggers Le modèle de datalogger spécifie des normes de fichiers de définitions et de configurations, ainsi que la structure des fichiers de données. Il faut donc pour chaque modèle coder des méthodes différentes pour les fonctions suivantes : Ecriture et lectures : o Des fichiers de configuration du datalogger o Des fichiers de configuration des matériels branchés Détection d absence de fichiers Cette obligation d écriture de nouvelles portions de code pour chaque nouveau modèle de datalogger a obligé de trouver une solution d ajout simple de code, dans l éventualité où le bureau d études demande la gestion d un nouveau datalogger. Les possibilités suivantes ont été étudiées : Classe / Interface + Pattern 3 Factory : Créer une interface au niveau du modèle objet qui déclare l ensemble des méthodes dont un datalogger a besoin. Puis pour chaque modèle implémenter cette interface dans une nouvelle classe. Les séquences de code spécifique sont ainsi réparties dans l ensemble des classes filles de l interface. Lorsqu un datalogger doit lire des données, en se basant sur le modèle, l application instancie 4 dynamiquement un objet de la classe correspondante. L objet crée hérite de l interface mère et implémente donc l ensemble des méthodes nécessaires au fonctionnement d un datalogger. Cette solution est très orientée modèle objet, et offre une bonne flexibilité. Namespaces 5 : Grâce aux espaces de noms (en français) il est possible de déclarer des fonctions portant un même nom. A partir de là, il faut fixer une liste de fonctions à implémenter par chaque modèle de datalogger, puis pour chaque modèle définir ces fonctions dans un nouveau namespace. Lorsqu un datalogger doit lire des données, l application se base sur son modèle pour charger dynamiquement les fonctions du namespace correspondant. Cette solution permet d accéder aux fonctions sans utiliser d objets, elle offre aussi une bonne flexibilité. 3 Un design pattern est un concept informatique destiné à résoudre les problèmes récurrents rencontrés dans un développement d applications utilisant le modèle de conception dit «objet». 4 Instancier est un terme technique qui décrit la création d un objet informatique (allocation de mémoire et initialisation). 5 Un namespace désigne en informatique un lieu abstrait conçu pour accueillir des ensembles de termes appartenant à un même répertoire. Cela permet notamment d avoir plusieurs éléments portant un même nom, mais se trouvant dans deux namespaces différents. Mémoire Saint-Germes Guillem 22

23 IV. Etude du projet Mise en place de plugins à partir de namespaces La solution des namespaces a été choisie car considéré comme plus facile à mettre en place et à maintenir (même si la solution par interface convenait très bien). Chaque modèle de datalogger utilise donc un paramètre pour stocker le namespace qu il doit utiliser pour charger ses fonctions spécifiques. Pour l ajout d un nouveau modèle il suffit de créer un nouveau fichier implémentant dans un nouveau namespace la liste des fonctions fixées précédemment. Cette liste est contenue dans un fichier texte réservé aux développeurs. Un gros avantage partagé par les deux solutions est la possibilité de charger dynamiquement les séquences de code complémentaires, sans perturber le fonctionnement de l application. 4. b) 2) Récupération des données La récupération des données sur le serveur FTP est faite à partir de scripts exécutés toutes les nuits, et qui après conversion et correction des valeurs lues, remplissent la base de données. Les données présentes dans la base sont donc à J-1, et il n est pas possible de visualiser les graphes de données en temps réel. Cette décision a été prise parce qu en fonction des modèles de datalogger, les données n était pas reçues au même moment ou avec le même intervalle de temps. Les données sur le serveur FTP étant sous format XML ou CSV compressées dans archives ZIP, pour tenir à jour les données à traiter, les archives ZIP déjà lues sont déplacées dans un répertoire d archivage. Elles sont ensuite conservées pour une durée d au moins un an, car dans le contrat de télésuivi le client doit pouvoir avoir accès aux données brutes de son installation pendant la durée de son contrat. Mémoire Saint-Germes Guillem 23

24 IV. Etude du projet 4. b) 3) Stockage des mesures Même si l intervalle d envoi des données diffère selon les dataloggers, l ensemble des données reçues utilise un intervalle de temps de 10 minutes. Le stockage des données est donc organisé dans une table tbl_mesures_10 contenant les valeurs espacées d intervalles de 10 minutes. Figure 6 : Représentation de la table de stockage. En prenant en compte le fait qu une installation classique est composée de plusieurs dizaines de matériels branchés, et que chaque matériel peut être { l origine de plusieurs mesures ou valeurs, il a été calculé qu une installation générait en moyenne 300 Mo de données par an (avec les index dans la base). Ce nombre est relativement important étant donné que l application doit pouvoir gérer 1000 installations sur plusieurs années. Cette énorme quantité de données à 10 minutes pose deux problèmes : L espace de stockage nécessaire à la base de données Le temps d accès et de calcul (pour des graphes mensuels par exemple) Le bureau d études a affirmé qu il était conscient que les installations génèrent beaucoup de données et qu il mettrait en œuvre le matériel nécessaire au niveau des serveurs pour supporter cette charge. L impératif est donc de trouver une façon d optimiser le temps d accès aux données, et le temps de calcul lorsque des données journalières ou mensuelles sont utilisées. Mémoire Saint-Germes Guillem 24

25 IV. Etude du projet 4. b) 4) Optimisations du stockage Optimisation du temps d accès aux données : Pour optimiser le temps d accès aux données il a été décidé d utiliser l héritage des tables d une base de données, et ainsi de diviser les mesures par installation et par mois. Figure 7 : Exemple de structures de tables pour les mesures de l installation id 22. Cette technique offre deux avantages majeurs : Les tables filles partagent les champs de la table mère. Un utilisateur peut récupérer des données des tables filles en émettant des requêtes sur la table mère. Grace à cette technique les valeurs sont réparties dans plusieurs tables ce qui diminue le temps de recherche et d accès { ces données. La création des tables filles ainsi que la répartition des données sont faite grâce à des fonctions triggers 6 activées lors de l insertion (insert) ou la mise à jour de données (update) sur la table mère. 6 Une fonction triggers est définie dans une base de données, et peut être exécutée lors d une action sur une table (ajout, modification ou suppression de données). Mémoire Saint-Germes Guillem 25

26 IV. Etude du projet Optimisation du temps de calcul : Pour éviter le calcul des totaux journaliers qui peut être très chronophage dans le cas d un graphe mensuel par exemple, un pré-calcul des ces valeurs a été mis en place (les totaux mensuels restent récupérés par calcul, car le calcul est moindre). Une table tbl_mesures_jours contenant les totaux journaliers a donc été mise en place pour stocker pour chaque matériel, la somme à la journée ou la moyenne en fonction du type de données. Cette table, rassemblant de grandes quantités de données, utilise la même technique d héritage que la table tbl_mesures_10 pour optimiser le temps d accès aux données. De plus deux tables ont été ajoutées pour pré-calculer des valeurs utilisées fréquemment dans l application : tbl_mesures_totaux : stocke les totaux globaux pour chaque installation (production, production théorique, moyenne ensoleillement ) tbl_mesures_installations : stocke les totaux journaliers des points de mesures de référence de chaque installation. Ceci permet d accéder directement { la production totale d une journée par exemple. Ces tables sont utilisées pour récupérer les valeurs de compteurs présentes sur l application. Malgré le fait qu ajouter des tables augmente la quantité de données dans la base, la compensation est la réduction très importante des temps de calcul pour la récupération des totaux. De plus le bureau d études a accepté de donner une grande quantité de stockage aux serveurs en production. Mémoire Saint-Germes Guillem 26

27 IV. Etude du projet Figure 8 : Schéma de la structure des tables de stockage des mesures. Mémoire Saint-Germes Guillem 27

28 IV. Etude du projet 4. c) Traitement avant stockage L unité avec laquelle les données arrivent sur le serveur FTP dépend du type de matériel et du type de datalogger { l origine des données. Pour unifier la base de données, les données présentes dans la base doivent utiliser une grandeur «unité» comme le Watt, le Watt/h ou le Watt/m². Figure 9 : Flux de données de la production d un onduleur. Afin de connaitre les modifications à apporter aux valeurs et d obtenir des valeurs unifiées, il est renseigné sur chaque matériel une formule de conversion et une formule de correction (les dataloggers sont aussi des matériels). Une fois les valeurs récupérées sur le serveur FTP, le script de lecture applique successivement les formules des matériels concernés pour obtenir des valeurs unifiées qu il sauvegarde dans la base de données. Figure 10 : Procédure d unification des données. Ces formules ont pour but de retranscrire le flux des données pour retrouver la grandeur physique de base. Mémoire Saint-Germes Guillem 28

29 IV. Etude du projet 4. c) 1) Conversion La formule de conversion apparait comme un polynôme où la variable «X» représente la valeur récupérée. Pour les matériels autres que les dataloggers, ce polynôme a pour but de convertir la valeur récupérée dans une grandeur unifiée. Dans le cas d un datalogger, celui-ci doit transformer la valeur pour récupérer la valeur que le datalogger a reçue depuis le matériel. 4. c) 2) Correction La formule de correction est optionnelle, elle apparait comme un polynôme où la variable «X» représente la valeur récupérée. Son but est de corriger d éventuelles erreurs provenant des matériels ou du flux des données. La formule de correction ne change pas la grandeur des données qu elle reçoit, elle ne fait que corriger les valeurs. 4. d) Télésuivi et alarmes Il existe deux sources d événements pour une installation : les évènements récupérés directement depuis un matériel, et envoyés par le datalogger. les évènements détectés par l application et basés sur des calculs prédéfinis. Tous les soirs à la fin du script de récupération des données, les alarmes matérielles sont lues et ajoutées dans la base, puis une procédure de vérification des données de la veille est lancée. Cette procédure permet de détecter automatiquement des incohérences au niveau de la production ou de l ensoleillement. Elle ne prend en compte que les journées et mois terminés. 4. d) 1) Définition et déclenchement des alarmes Ce sont les administrateurs qui configurent les seuils de déclenchement des alarmes. Les alarmes détectées par l application et comparant des valeurs à des seuils se basent sur les données des points de mesures référents. Les valeurs vérifiées sont les suivantes : La bonne réception des données pour les points de mesures référents. Facteur de performance (production / irradiance) au dessus d un seuil. Erreur entre le compteur EDF et le compteur de l installation en dessous d un seuil. Erreur entre le compteur EDF et la production des onduleurs en dessous d un seuil. Erreur entre la production réelle et la production théorique en dessous d un seuil. Pour chaque vérification si les conditions ne sont pas respectées, l application envoie des notifications par ou par SMS (selon la configuration) aux gérants de l installation. Mémoire Saint-Germes Guillem 29

30 IV. Etude du projet 4. d) 2) Conséquences et traitement Après la détection et la génération d alarmes, les administrateurs ou gérants d une installation peuvent en prendre connaissance puis les traiter. Pour cela les alarmes ont un niveau et un état. Le niveau défini la gravité de l évènement et peut prendre trois valeurs : Critique : problème impactant la production de l installation. Moyen : problème dans la récupération des données ou données incohérentes. Information : événement notable mais sans conséquences. L état défini la prise en charge de l alarme, il peut prendre trois valeurs : A traiter : l alarme vient d être générée, et aucun gérant n en a pris connaissance. En cours de traitement : un gérant a pris connaissance du problème et il est en cours de résolution. Traité : l alarme a été traitée, et n apparait plus qu { titre informatif. Ce système permet aux gérants d une installation d être informés des dysfonctionnements, puis de gérer l avancement de la résolution du problème. De plus une trace des évènements précédents est conservée. Mémoire Saint-Germes Guillem 30

31 IV. Etude du projet 4. e) Visualisation des données La visualisation des données et la configuration des données sont séparées. On retrouve donc le schéma suivant : front-office (visualisation des graphes et des alarmes, partie publique accessible par les clients, les intervenants et les administrateurs) back-office (administration et configuration, partie accessible par les administrateurs) 4. e) 1) Charte graphique La charte graphique utilisée est celle d un site Internet. Il est important qu elle soit simple d utilisation et ergonomique. Des couleurs claires bleues et orangées ont été utilisées pour s approcher du thème des énergies solaires. 4. e) 2) Front-Office L identification { l application est unique et redirige vers la partie publique. La page d accueil propose un récapitulatif des évènements et des données des installations auxquels l utilisateur a accès. Figure 11 : Représentation schématique de la page d accueil de l application. Mémoire Saint-Germes Guillem 31

32 IV. Etude du projet La page d accueil permet notamment de sélectionner une installation à visualiser. Une fois l installation sélectionnée, il est possible de visualiser ses données, ou pour un administrateur de modifier sa configuration. Chaque page de l application retrouve cinq éléments : Le bandeau de l application, qui est configurable par un administrateur pour chaque utilisateur. Un bouton d accès aux pages d administration de l application o Gestion des utilisateurs o Gestion des modèles o Qualification des alarmes o Paramétrage de l application o Création d une installation Un fil d Ariane. Une zone de déconnexion (avec le nom de l utilisateur connecté). Un pied de page qui, comme le bandeau, est configurable par un administrateur pour chaque utilisateur. Figure 12 : Représentation schématique d une page de visualisation d une installation. Mémoire Saint-Germes Guillem 32

33 IV. Etude du projet Le menu, présent { gauche lorsqu une installation est sélectionnée, permet aux utilisateurs de naviguer et d accéder aux informations de l installation. Les entrées du menu sont les suivantes : Mes installations : permet de sélectionner une autre installation à visualiser. Informations générales. Tableau de bord : accès aux graphes de production et d ensoleillement de l installation. Supervision o Etat des onduleurs : accès aux graphes de production des onduleurs. o Compteurs EDF : comparaison de production entre le(s) compteur(s) EDF et le compteur d installation, et/ou la production des onduleurs. o Diagrammes : accès { des graphes d analyse de la production de l installation. o Alarmes : historique des évènements de l installation, ainsi que liste des alarmes à traiter. Rapports : page de génération de rapports de production, il est aussi possible de télécharger les contrats de maintenance et de télésuivi ainsi que d accéder aux données brutes de l installation. Analyses / Mesures (intervenants et administrateurs) : accès à des graphes personnalisable sur l installation. Interventions : liste des interventions sur l installation. Configuration : pour les clients et intervenants, accès à une configuration mineure de l installation, pour les administrateurs accès { la configuration complète de l installation. Informations personnelles : page de gestion des données de l utilisateur. Mémoire Saint-Germes Guillem 33

34 IV. Etude du projet 4. e) 3) Interface web mobile L interface pour téléphone mobile est plus minimaliste que la version ordinateur. Elle propose moins d informations, mais permet { un client de savoir si son installation fonctionne correctement. Elle utilise le même principe que l application ordinateur en présentant une page de sélection d une installation (sans carte). Une fois l installation sélectionnée, le menu de navigation apparait en position fixe en bas de l écran, il permet d accéder aux pages suivantes : Mes installations : choix de l installation { visualiser. Informations générales Graphes : accès au graphe de production, ensoleillement et température journaliers, et au graphe de production des onduleurs. Alarmes : accès { la liste des alarmes en cours sur l installation. Contacts : les personnes responsables de l installation (maitre d ouvrage, bureau d études, installateurs et mainteneurs). Figure 13 : Représentation schématique de l interface web mobile. Mémoire Saint-Germes Guillem 34

35 V. Réalisation et résultats V. Réalisation et résultats 1. Choix des technologies Tout d abord il est important de définir les critères de sélection utilisés pour choisir les technologies mise en œuvre dans l application, ainsi que les choix disponibles. Critères de sélection : Robustesse et prévisibilité de comportement en exploitation de longue durée. Disponibilité des outils. Possibilités d'adaptations ou d'extensions des fonctionnalités. Performances. Scalabilité 7. Communauté internet conséquente. Choix disponibles : Plateforme o.net Windows. o J2EE Linux. o Apache Linux. La plateforme : La décision de base se porte d'abord sur les logiciels libres à sources ouverts (open source), ce qui élimine le choix.net et Windows. D un autre côté, la plateforme J2EE malgré des qualités ne s est pas présentée comme pertinente. Il s agit d une plateforme lourde et complexe, avec une faible communauté et une faible réactivité aux évolutions et innovations du domaine. Elle semble plus adaptée au «Mainstream 8» d'internet et aux projets classiques de grande ampleur. En définitive notre choix s'est porté sur la plateforme Apache - Linux. Car, outre ses excellentes performances et la meilleure scalabilité, cette plateforme est la seule à proposer une multitude d'outils annexes indispensable au projet. 7 La scalabilité est la capacité d un système, ou de ses composants, { être utilisé sur des plateformes de tailles très inférieures ou très supérieures. 8 L expression «Mainstream» d Internet se rapproche en français de «l Internet de masse», elle représente la méthode classique de conception de sites et d applications Web. Mémoire Saint-Germes Guillem 35

36 V. Réalisation et résultats 2. Matériels et logiciels 2. a) Linux Ubuntu Le système d exploitation utilisé pendant le développement est Linux Ubuntu parce que c est un système fiable et robuste adapté au développement informatique. De plus le projet étant hébergé sur un serveur Apache, Ubuntu permet d exécuter une version locale du serveur pour faciliter les tests. 2. b) Environnement de développement Le projet utilisant des technologies Web, il est possible d utiliser des IDE (Integrated Development Environment) comme Eclipse/PHP ou Netbeans/PHP pour faciliter le développement en accédant { des fonctionnalités d auto-complétion intelligente, de gestion de fichiers et de compilation (pour les projets non Web). Cependant par l habitude de travailler simplement et pour éviter un environnement lourd, il a été préféré l éditeur SciTE basé sur SCIntilla. Offrant une auto-complétion simple et une coloration syntaxique (PHP/Javascript/HTML), il est apparu plus facile d utilisation et adapté aux besoins. site : 2. c) Serveur Apache / PHP Un serveur apache avec le plugin PHP a été utilisé comme base logique de l application. L ensemble des pages visibles est fourni par ce serveur. De plus il est sollicité de nuit pour exécuter les scripts PHP de récupération des données. Le choix c est porté sur Apache car c est un serveur HTTP puissant, rapide et sûr, qui de plus est un logiciel libre. site : 2. d) Serveur base de données Postgresql En ce qui concerne la base de données, le choix s est porté sur Postgresql car le projet nécessite une base avec une puissance de calcul et une vitesse conséquentes. Elle supporte aussi le modèle relationnel qui permet une gestion des clés étrangères lors des transactions. Postgresql offre aussi la possibilité d héritage et de partitionnement des tables, indispensable pour l optimisation du temps d accès aux données. Enfin il s agit d un logiciel libre, ce qui s inscrit dans la volonté de l entreprise d utilisation maximale de ce type de logiciel. site : Mémoire Saint-Germes Guillem 36

37 V. Réalisation et résultats 2. e) Serveur FTP Un serveur FTP (File Transfert Protocol) est utilisé comme tampon pour la récupération des données. Cette technologie est utilisée car c est la seule supportée par les dataloggers pour l envoi distant des fichiers. Ce protocole est cependant très largement utilisé par ailleurs, et offre de bonnes capacités de transfert en termes de vitesse et de taille de fichier acceptées. 2. f) Schéma matériel de l application Figure 14 : Diagramme de composant de l'application. Le choix du bureau d études s est porté vers un hébergement de l application sur un serveur de la société OVH car Internet-Consult n a pas l architecture matérielle suffisante pour supporter la montée en charge de la base de données. L ensemble des serveurs logiciels nécessaires au fonctionnement de l application (Apache, Postgresql et FTP) est installé sur la machine d OVH afin de centraliser les informations. Mémoire Saint-Germes Guillem 37

38 V. Réalisation et résultats 3. Langages 3. a) PHP Le PHP est un langage qui s exécute du coté serveur de l application, il est notamment utilisé pour les taches suivantes : Accès à la base de données Génération initiale des pages de l application Scripts périodiques 3. b) Javascript Il s agit d un langage s exécutant du coté client de l application, il intervient après le chargement initial de la page pour la dynamiser. Il est utilisé pour les taches suivantes : Interactions et dynamisation des pages Effets graphiques sur les pages Génération des graphes En combinaison avec le PHP pour récupérer des données depuis la base de données sans rechargement des pages (technologie Ajax) 3. c) CSS / HTML Ces derniers permettent de définir le design des pages Web. Ils sont utilisés pour toute l interface graphique. 3. d) PGSQL et SQL Le SQL est un langage de requête utilisé pour gérer les données dans une base de données. Le PGSQL est un langage proposé par postgresql qui permet de définir des fonctions basées sur des requêtes SQL, qui offrent plus de possibilités au niveau de la gestion des données d une base. Il est notamment utilisé pour l optimisation du stockage des mesures. Mémoire Saint-Germes Guillem 38

39 V. Réalisation et résultats Ajax 4. Technologies C est une technologie basée sur le javascript qui permet de récupérer dynamiquement des données depuis une page Web en évitant le rechargement complet de page. Elle est très utilisée avec la combinaison javascript / PHP qui offre à partir des interactions de l utilisateur, la possibilité de mettre { jour les données d une page ou données de la base sans changer de page. jquery jquery est une librairie javascript simplifiant la modification du code HTML et offrant une multitude de fonctions utilitaires comme une API pour appels Ajax. Elle permet de simplifier le code javascript. site : jqueryui jqueryui est un plugin de jquery proposant des composants graphiques javascript facile à mettre en place et à utiliser (ex/ sélectionneur de date). site : jqplot jqplot est une librairie basé sur jquery offrant une API puissante de génération de graphiques. Elle permet notamment de présenter des graphes dynamiques avec visualisation des valeurs par passage de la souris, ou de redimensionner des graphes dynamiquement. site : Google maps La version 3 de cette API javascript de géo-localisation a été utilisée pour positionner les installations de l application sur une carte. site : Mémoire Saint-Germes Guillem 39

40 V. Réalisation et résultats Google documents Ce service proposé à partir de comptes gmail est utilisé par l équipe pour gérer les taches en cours, les bugs et les tests. Il permet notamment d accéder et de modifier simultanément des feuilles de calcul. site : Wkhtml2pdf Cet exécutable est utilisé pour la génération des rapports de production des installations. Il permet de transformer des pages HTML en document PDF. Il a été choisi car il offre notamment la possibilité d inclure et d exécuter du code Javascript dans le document HTML avant la génération du PDF. site : Procédures «crontabs» L application étant basée sur le système d exploitation Unix, ces procédures sont utilisées car elles permettent de programmer l exécution de taches à intervalles réguliers. Les scripts PHP de mise à jour périodique des données sont donc lancés par une procédure crontab. documentation : Envoi de SMS En ce qui concerne la procédure d envoi de SMS, le service de la société FlyTelecom est utilisé. Il permet d envoyer des SMS par l intermédiaire d . L application envoie donc simplement des s formatés correctement à ce service, et sont ensuite transmis aux gérants des installations sous forme de SMS. Les prestations de FlyTelecom sont proposées par l achat de packs de SMS, et limitées au seul nombre de SMS restant sur le compte utilisateur du service. (pas de site disponible) Mémoire Saint-Germes Guillem 40

41 V. Réalisation et résultats 5. Résultats 5. a) Démonstration en ligne Il est possible d accéder en ligne { l application avec un compte de démonstration : Adresse de l application : 5. b) Interface graphique Figure 15 : Page d accueil de l application. Conformément { une demande du bureau d études la charte graphique de l application utilise pour toutes les pages une image de fond représentant des panneaux photovoltaïques afin d immédiatement centrer les utilisateurs sur le sujet. De plus elle se base sur un jeu de couleurs douces : bleu, orange et vert qui se rapportent au ciel, au soleil et { l écologie. Mémoire Saint-Germes Guillem 41

42 V. Réalisation et résultats Figure 16 : Page de sélection d une installation. Les éléments principaux de la charte graphiques sont présents sur cette page : 1. Le bandeau en haut de page avec le nom de l application. 2. Le fil d Ariane indiquant la page visitée. 3. Le bouton de déconnexion. 4. Le contenu central. 5. Le bandeau de bas de page avec le contact de Tecsol. Il est aussi intéressant de noter que beaucoup de formes arrondies sont utilisées par la charte graphique afin d estomper le côté technique de l application, et de faciliter l accès et l usage aux utilisateurs (amélioration de l ergonomie). Mémoire Saint-Germes Guillem 42

43 V. Réalisation et résultats Figure 17 : Page d informations générales sur une installation. Cette capture d écran montre la réalisation d une page de visualisation d une installation. Le menu de navigation à gauche apparait une fois une installation sélectionnée et permet d accéder aux diverses pages de supervision. Mémoire Saint-Germes Guillem 43

44 V. Réalisation et résultats Figure 18 : Page de visualisation des données de production. Les pages de visualisation des données présentent au maximum 4 graphes différents. Les intervalles de temps peuvent être modifiés indépendamment pour chaque graphe ce qui permet une visualisation ciblée de données antérieures. Pour améliorer le confort d analyse et de lecture des graphes, il est possible de les afficher individuellement dans une nouvelle fenêtre en cliquant dessus. Ceci permet de maximiser la taille du graphe par rapport { l écran et ainsi de mieux voir les données. Mémoire Saint-Germes Guillem 44

45 V. Réalisation et résultats 5. c) Gestion d une installation Figure 19 : Page d administration d une installation. La page de gestion d une installation accessible par les administrateurs abandonne le menu de navigation afin d optimiser l espace disponible. Elle présente trois onglets : Informations générales : utilisé pour visualiser et modifier les informations d une installation (nom, adresse, photos ). Schéma : qui propose une représentation des matériels de l installation par bâtiment, et qui permet notamment d accéder { la gestion des matériels (configuration, récupération des données et alarmes). Tableau synthétique : qui propose un tableau regroupant des informations utiles comme la liste des matériels avec leurs formules de conversion et de correction, et la liste des points de mesures. Mémoire Saint-Germes Guillem 45

46 V. Réalisation et résultats Figure 20 : Fenêtre modale de gestion des onduleurs. La gestion des matériels se fait par l intermédiaire de fenêtres modales 9 qui apparaissent lors du click sur un matériel dans la représentation de l installation, ou par click sur le bouton de gestion d un type de matériel. Ce mode de fonctionnement par fenêtres modales permet d éviter les rechargements de pages lors de la modification de plusieurs matériels. 9 Dans une interface graphique une fenêtre modale bloque les actions en dehors de son cadre. Mémoire Saint-Germes Guillem 46

47 V. Réalisation et résultats Figure 21 : Page d administration générale des modèles de matériels. 5. d) Administration et configuration Les pages de configuration accessibles par le menu administration permettent de configurer le comportement global de l application, indépendamment d une installation en particulier. Il est remarquable que la charte graphique des pages accessibles seulement par les administrateurs utilise moins de couleurs et de formes arrondies que la charte de la partie publique. Ceci s explique principalement par deux raisons : Ces pages ne sont pas accessibles par le public et elles se concentrent sur les fonctionnalités. Pour la majorité elles ont été développées avant la création de la charte graphique publique et le bureau d études n a pas exprimé le besoin qu elles y soient intégrées. Mémoire Saint-Germes Guillem 47

48 V. Réalisation et résultats 5. e) Interface mobile Figure 22 : Page d informations générales. Figure 23 : Page de visualisation des données. L interface pour téléphones mobiles reprend la charte graphique de l application ordinateur, mais propose des fonctionnalités simplifiées. De plus l ergonomie et les interactions sont optimisées pour la navigation tactile, afin de fournir la meilleure expérience possible { l utilisateur final. Il est possible d accéder { la version mobile depuis un smartphone Android ou iphone avec les mêmes informations de connexions que la version principale de l application. Il est donc possible de s y connecter avec le compte de démonstration. Mémoire Saint-Germes Guillem 48

49 V. Réalisation et résultats 6. Chiffres clés Javascript 15% CSS 4% SQL / PGSQL 1% HTML 20% PHP 60% Figure 24 : Répartition de l'utilisation des différents langages de programmation. Dû { l ensemble des traitements effectués sur les données pour la lecture et l utilisation, ainsi que la gestion des accès à la base, la majorité du projet repose sur du code PHP (exécuté coté serveur). En seconde, troisième et quatrième position se place le HTML, le Javascript et le CSS (exécutés ou lus coté client) utilisés pour l interface graphique de l application. Enfin les requêtes et fonctions SQL / PGSQL ne représentent que 1% de l ensemble du code car généralement elles ne dépassent pas les quelques lignes. Ressources 10 Heures-homme 1500 Développeurs 2 Infographiste 1 Développement Lignes de code Fichiers 300 Fonctions 1400 Requêtes SQL 300 Tables 48 Figure 25 : Chiffres clés du développement. Il est juste d affirmer que «Tecsol PV Analytics» est un projet conséquent en termes de taille. Il a mobilisé 2 développeurs à plein temps pendant 5 mois et se constitue de centaines de fichiers. De plus un ingénieur du bureau d études a aussi travaillé en collaboration avec Internet-Consult pour tester l application et vérifier la cohérence des données récupérées. 10 Ressources salariales de Internet-Consult. Mémoire Saint-Germes Guillem 49

50 VI. Gestion de projet VI. Gestion de projet 1. Ressources Quatre ressources ont travaillé sur le développement de ce projet. Un ingénieur chef de projet (Michel Marcenac) Chef de projet dans le bureau d études, il est le contact client, et est { l origine des besoins en fonctionnalité de l application. Pendant le projet il a assumé une position de chef de projet et a vérifié et testé l application. Un développeur (François Figarola) Développeur chez Internet-Consult, il a participé { l ensemble de développement de l application, mais { principalement travaillé sur la partie gestion des matériels et récupération des données. Une infographiste (Béatrice Masse) Infographiste chez Internet-Consult, elle a créé la charte graphique de l application. Un apprenti ingénieur, développeur (Guillem Saint-Germes) : mon rôle Développeur en apprentissage chez Internet-Consult, j ai participé dans le développement de l ensemble des parties du projet, mais j étais notamment en charge du fonctionnement de la partie publique du site, ainsi que de la gestion et de l utilisation des données matériels. J ai du rechercher des solutions { des problèmes spécifiques tel que : La méthode de stockage des données dans la base. L affichage des données sous forme de graphes paramétrables. Les algorithmes de détection des dysfonctionnements. La génération de rapports de production au format PDF. Mémoire Saint-Germes Guillem 50

51 VI. Gestion de projet 2. Planification 2. a) Délais et objectifs Dans le cahier des charges, il avait été prévu par le bureau d études que le projet commence mi-janvier et finisse fin avril. En réalité le projet a réellement été commencé en mars par François Figarola (Internet-Consult) et Michel Marcenac (Tecsol). L objectif était de finir le projet relativement rapidement afin que le bureau d études puisse proposer ses offres de télésuivi. Le projet a été installé sur le serveur de Tecsol fin Juillet, et a été soldé début Septembre. 2. b) Retards Le projet a souffert de quatre mois de retard par rapport aux prévisions du cahier des charges pour plusieurs raisons : Début tardif, plus de deux mois après le prévisionnel. Difficultés de développement pour la modélisation et la récupération des données dues { l ensemble des cas particuliers des différents modèles de matériels et dataloggers. Délais dans l obtention de fichiers de données pour les tests. Sous-estimation du temps de développement. Malgré cela le projet a été terminé dans un timing raisonnable, et le bureau d études semble satisfait de la solution proposée. 2. c) Planning Figure 26 : Diagramme de Gantt de la réalisation du projet. Mémoire Saint-Germes Guillem 51

52 VI. Gestion de projet 3. Méthodologie 3. a) Cycle de développement Durant le projet un cycle de développement en spirale a été utilisé. Ce cycle s adapte particulièrement bien à des projets développés avec une méthode itérative, le principe étant d avoir un noyau fonctionnel et d y ajouter de nouveaux modules au fur et { mesure, tout en le gardant fonctionnel. Chaque itération du cycle en spirale peut être assimilée à un cycle en V, regroupant les étapes suivantes : Figure 27 : Représentation du cycle en spirale. Ce cycle a été adopté car certaines parties de l application comme la visualisation, ou le télésuivi n étaient pas clairement définies dans le cahier des charges et n ont été définies que plus tard pendant le projet, en collaboration avec Michel Marcenac. Mémoire Saint-Germes Guillem 52

53 VI. Gestion de projet 3. b) Versionnage Le versionnage lors d un projet informatique est d une importance majeure. Il permet notamment { des membres d une équipe de travailler simultanément et indépendamment sur les différents fichiers relatifs au projet. Mais il permet aussi de garder une trace de chaque fichier pour chaque étape du projet, rendant possible la récupération d une ancienne version d un fichier par exemple. La plupart des logiciels de versionnage s organise en deux parties : Le serveur, regroupant la source globale des fichiers du projet Le client, ayant une copie locale des fichiers du projet Le système consiste ensuite pour chaque client à faire des modifications du projet sur leur copie locale, puis de mettre à jour les informations du serveur, et bien sûr de récupérer régulièrement les informations depuis le serveur pour bénéficier du travail des autres membres du projet. Dans le cadre de ce projet, il a été mis en place et utilisé le logiciel GIT. La fréquence des sauvegardes sur le serveur (PUSH) étaient de deux à trois par jours, en fonction des besoins. 3. c) Outils collaboratifs Pour partager des fichiers et organiser le travail d équipe, il a été utilisé les Google Documents. Afin de suivre le travail { effectuer et l avancement du projet, des documents on ainsi été mis en ligne pour permettre aux différents collaborateurs de s organiser : Liste des taches Liste des bugs Liste des tests Cela a permis de suivre l avancement du projet, et d organiser le développement autour des points les plus importants. De plus le bureau d études donnait des retours constants sur le travail effectué et sur les possibles modifications ou améliorations à apporter. Mémoire Saint-Germes Guillem 53

54 VI. Gestion de projet 4. Qualité 4. a) Réunions Des réunions ont été organisées toutes les semaines du projet pour faire un point sur l avancement global, les taches en cours, et donner des objectifs pour la semaine suivante. A cette occasion les listes sur les documents en lignes étaient complétées et vérifiées. Ces réunions étaient indispensables au bon déroulement du projet, pour mettre en place un plan de travail et une organisation adéquats. 4. b) Documentation Deux fichiers de documentation de l application ont été produits, un pour l utilisation de la partie publique de l application, et un pour l utilisation de la partie administration et configuration. Ces documents décrivent l interface et les actions possibles, et expliquent le comportement de l application. Du coté code source du projet, chaque fichier contient en commentaire un entête descriptif de son utilité et de son utilisation. De plus d autres commentaires ont été placé dans l ensemble du code pour décrire fonctions et structures. 4. c) Tests et environnement de test Les tests se sont organisé autours de trois différents axes : Tests continus durant le développement, de la part des développeurs et de Michel Marcenac qui vérifiait l avancement. Des pages et des fonctions de test ont été mises en place pour empêcher les régressions et valider les nouvelles fonctionnalités. Fin juillet, deux semaines de tests ont été effectuées par Michel Marcenac et l équipe de développement pour vérifier les fonctionnalités et les comportements de l application. Ceci a permis de livrer une application conforme aux attentes du bureau d études et contenant peu de bugs. Mémoire Saint-Germes Guillem 54

55 VI. Gestion de projet 5. Validation et mise en production La mise en production s est effectuée avant la validation du projet car le bureau d études désirait proposer le plus rapidement possible l offre de télésuivi { ses clients. De plus il préférait valider le projet déjà installé sur leur serveur pour simplifier l aboutissement du projet. La recette 11 a été effectuée début septembre et le projet semble satisfaire les attentes du bureau d études, tant d un point de vue fonctionnalités que d un point de vue ergonomique. 6. Avenir du projet La base du projet est terminée, mais le bureau d études prévoit le développement d une version 2 intégrant de nouvelles fonctionnalités : Présentation de nouveaux graphes d analyses. Gestion plus poussée et précise des alarmes. Ajout d un module complet de gestion des interventions sur les installations. Le développement de plugins pour la prise en charge de nouveaux modèles de dataloggers est aussi prévu. 11 La recette est une phase pendant laquelle les différents acteurs du projet se rencontrent afin de vérifier que le produit est conforme aux attentes formulées. Mémoire Saint-Germes Guillem 55

56 VII. Conclusion VII. Conclusion 1. Bilan du projet Globalement le projet s'est bien déroulé, même si les délais de livraison initialement prévus n ont pas été strictement respectés. Le système final remplit toutes les fonctionnalités demandées par Tecsol (pour une version 1), il présente une flexibilité de configuration très importante et un temps d accès aux données acceptable lorsque l on prend en compte la quantité de données stockées. Cependant le projet en lui-même reste très complexe au niveau de sa conception et de son code source. Les plus grosses erreurs commises durant le projet ont été la sous-évaluation du temps de développement et la non définition stricte de certains besoins dès le début. Il ne s agit pas d erreurs techniques, mais d erreurs de gestion de projet et elles sont notamment { l origine du retard de livraison. Il faudra donc retenir que la solution pour résoudre ces problèmes est de passer un maximum de temps sur l analyse des besoins avant de commencer un projet de cette taille. En ce qui concerne l avenir du projet on peut dire que la version 1 de l application est terminée et en production, mais qu une version 2 est déjà en réflexion pour intégrer notamment une nouvelle gestion des alarmes et ajouter la gestion de nouveaux modèles de dataloggers. De plus de nouveaux besoins sont susceptibles d apparaitre lorsque l application sera utilisée par beaucoup d utilisateurs. Au niveau de sa position dans le marché, on peut affirmer que le superviseur n a rien à envier aux services proposés par les concurrents du bureau d études, et qu il s inscrit comme une solution puissante avec une facilité de mise en place sur de nouvelles installations ou des installations existantes. Donc même si le service n est pas totalement innovant il est cependant de bonne qualité par rapport { l existant. Pour conclure on peut simplement dire que le bureau d études Tecsol semble satisfait de l application développée par Internet-Consult. Mémoire Saint-Germes Guillem 56

57 VII. Conclusion 2. Bilan personnel D'un point de vue personnel, le projet a été très prenant puisqu'il m'a occupé à temps plein pendant plus de cinq mois. Il m'a permis de découvrir de nouvelles technologies relatives à internet, comme le framework jquery et ses plugins, mais il m'a aussi et surtout permis de développer mes connaissances en PHP/Javascript et gestion de base données. J'ai particulièrement apprécié la confiance accordée et les responsabilités confiées en me donnant la charge fonctionnelle de certaines parties du projet. Il m a aussi été donné l opportunité de mettre en place des techniques de programmation et d appliquer des méthodes de gestion de projet apprises durant ma formation, et qui ont bénéficié { l ensemble de l équipe. En dehors de mes capacités techniques, le projet m a permis de développer des qualités dans les domaines du travail d équipe, de l organisation et de la communication grâce notamment aux nombreux échanges et réunions. Ce fut donc une bonne expérience personnelle qui m'a prouvé que j'étais capable de participer à la conception et { la réalisation d un projet complexe tout en assurant { l équipe des apports techniques complémentaires. En ce qui concerne mon avenir professionnel, j envisage de travailler au Canada durant les prochaines années, dans le but d acquérir une expérience solide et d améliorer mon anglais. Je n ai pas encore choisi de technologie ou de spécialité dans laquelle évoluer, mais je pense m orienter vers d autres voies que le développement Web, comme par exemple le développement d applications en Java ou C/C++. Pour finir je remercie une nouvelle fois Béatrice Masse, François Figarola et Vladimir Guevezov, pour leur soutien, leur professionnalisme et leur disponibilité pendant ma période d apprentissage dans la société Internet-Consult. Mémoire Saint-Germes Guillem 57

58 VIII. Bibliographie VIII. Bibliographie 1. Livres Daspet E. & Pierre de Geyer C., php5 avancé, 2007, édition Eyrolles. Morville P & Rosenfeld L., Information architecture for the World Wide Web, 2006, édition O'Reilly. Mariel S., Postgresql, 2004, édition Eyrolles. Gardarin G., Bases de données, 2003, édition Eyrolles. Nielsen J. & Loranger H., Prioritizing web usability, 2000, édition New Riders 2. Sites Documentation de PHP. Documentation de Postgresql. Documentation HTML et Javascript. Documentation et des techniques CSS. Documentation jquery. Forum d aide en programmation. Encyclopédie en ligne. Mémoire Saint-Germes Guillem 58

59 IX. Annexes IX. Annexes Mémoire Saint-Germes Guillem 59

60 IX. Annexes Annexe 1 : Diagramme de Gantt prévisionnel du cahier des charges. Mémoire Saint-Germes Guillem 60

61 IX. Annexes Annexe 2 : Diagramme UML de la base de données. Mémoire Saint-Germes Guillem 61