Rapport de stage (du 14 Avril au 23 Juin 2014)kosted.free.fr/pdf/rapport.pdf · 2015. 9. 7. ·...

Institut Universitaire de Technologie Département Informatique

Université Toulouse le Mirail

Rapport de stage (du 14 Avril au 23 Juin 2014)

ADREAM : mise en place d’un système de gestion des données environnementales – Application

aux données électriques, météorologiques et photovoltaïques.

L.A.A.S. du C.N.R.S. - 7, Avenue du

Colonel Roche –BP 54200 31031

Toulouse Cédex 4 - 05.61.33.62.00

Tuteur de l’entreprise : Christelle ECREPONT

Tuteur pédagogique : Amélie LEGRAND

Jehu KOSSOKO

2013-2014

sur 68

Institut Universitaire de Technologie Département Informatique

Université Toulouse le Mirail

ADREAM : mise en place d’un système de gestion des

données environnementales – Application aux données

électriques, météorologiques et photovoltaïques.

sur 68

Remerciements

Je tiens à remercier toutes les personnes qui m’ont permis de réaliser ce stage. Je remercie particulièrement Christelle ECREPONT, tutrice de stage, pour son

apprentissage et sa présence tout au long du stage. Merci également à Jeremy BLOY, qui nous a installé et configuré l’environnement de

travail sous Netbeans, à Matthieu HERBB membre de sysadmin (administrateur système), qui à distance m’a installé tous les logiciels dont j’avais besoin, configuré le serveur en fonction de

certains besoins… Je remercie Amélie LEGRAND, superviseuse de stage, pour ses conseils et son soutien.

Par ailleurs, je remercie mon collègue Arnaud LODS pour son aide pendant tout le stage.

Enfin, je remercie les professeurs de l’IUT de Blagnac qui m’ont enseigné les bases de

l’informatique tout au long de ces deux années de formation.

sur 68

Sommaire

Table des matières Table des illustrations ........................................................................................................................... 6

Introduction ........................................................................................................................................... 7

I. Présentation de l’entreprise .............................................................................................................. 8

I.1 Le LAAS CNRS ........................................................................................................................... 8

I.1.1 Historique ............................................................................................................................. 8

I.1.2 L’organigramme ................................................................................................................. 10

I.2 Le projet ADREAM................................................................................................................... 13

II. Présentation du service, de l’existant, de l’environnement de travail et analyse du

prévisionnel .......................................................................................................................................... 17

II.1 Le service informatique IDEA ................................................................................................ 17

II.2 L’existant .................................................................................................................................. 17

II.3 L’environnement de travail ..................................................................................................... 18

II.4 analyse du prévisionnel ............................................................................................................ 19

III. Le projet ........................................................................................................................................ 20

III.1 Les différentes tâches à réaliser ............................................................................................. 20

III.2 Un projet réalisé en binôme ................................................................................................... 20

III.3 La sauvegarde totale .............................................................................................................. 21

Traitement : ................................................................................................................................. 21

Problèmes rencontrés : ............................................................................................................... 23

III.4 La sauvegarde du fichier de variables .................................................................................. 23

Traitement : ................................................................................................................................. 23


III.5 La sauvegarde incrémentale .................................................................................................. 24

III.5.1 Explication de l’algorithme du script de sauvegarde incrémentale : ........................ 25


III.5.2 Exécution automatique du script grâce à la crontab : ................................................ 27

III.5.3 Utilisation du script incrémental pour corriger l’erreur survenue lors de la

sauvegarde générale : .................................................................................................................. 27

III.6 Réalisation d’une IHM avec Symfony2 ................................................................................ 27

III.6.1 IHM pour Interface Home Machine ............................................................................ 27

III.6.2 Symfony2 pour réaliser une application web en MVC ............................................... 28

III.7 Analyse conceptuelle de l’application ................................................................................... 31

sur 68

III.7.1 Les Cas d’Utilisation ....................................................................................................... 31

III.7.2 Le Schéma Navigationnel d’Interface (SNI) ................................................................ 32

III.8 Les différentes composantes de l’application ...................................................................... 33

III.8.1 La page de recherche simple .......................................................................................... 33

III.8.2 La page de recherche « avancée » ................................................................................. 34

III.8.3 La page de modification d’une variable ....................................................................... 37

III.8. La page d’ajout d’une variable ........................................................................................ 38

III.9. Bilan d’avancement du projet ......................................................................................... 38

Conclusion ............................................................................................................................................ 41

- Bilan Technique ....................................................................................................................... 41

- Bilan Humain ........................................................................................................................... 41

- Bilan Professionnel .................................................................................................................. 42

Glossaire ............................................................................................................................................... 43

Bibliographie ........................................................................................................................................ 44

Sommaire des annexes ........................................................................................................................ 45

sur 68

Table des illustrations

Image 1 : Bâtiment ADREAM aussi appelé Bâtiment H (Image de synthèse) ....................................... 13

Image 2 : Système de production de l’énergie électrique du bâtiment ADREAM ................................ 14

Image 3 : Vue de la consommation en électricité du bâtiment ............................................................ 15

Image 4 : Variation électrique ............................................................................................................... 16

Image 5 : Modèle Logique de données de la base PostgreSQL ............................................................. 18

Image 6 : Tâches à accomplir au début du projet ................................................................................. 19

Image 7 : Diagramme de GANTT de ces tâches..................................................................................... 19

Image 8 : Modèle de la table CVC (Chauffage-Ventilation-Climatisation) dans la base de données: .. 21

Image 9 : Schéma de la sauvegarde générale ....................................................................................... 22

Image 10 : Différents traitements réalisés ............................................................................................ 26

Image 11 : Logo de Symfony2 ............................................................................................................... 28

Image 12 : Relation entre le Modèle, la Vue et le Contrôleur .............................................................. 29

Image 13 : Modèle de la table CVC (Chauffage-Ventilation-Climatisation) dans la base de données .. 30

Image 14 : Diagramme de classes découlant du modèle précédent avec les méthodes et les attributs

............................................................................................................................................................... 30

Image 15 : Interprétation du diagramme de classe en code Symfony2 ............................................... 30

Image 16 : Cas d’utilisation d’une partie de l’application ..................................................................... 32

Image 17 : Schéma Navigationnel d’Interface de l’application réalisé ................................................. 33

Image 18 : Liste déroulante auto-complétée de la page recherche de variables ................................. 34

Image 19 : Résultat d’une recherche affiché à l’utilisateur .................................................................. 34

Image 20 : Formulaire de recherche avancée ....................................................................................... 35

Image 21 : Résultat d’une recherche .................................................................................................... 36

Image 22 : Formulaire de modification d’une variable sélectionnée.................................................... 37

Image 23 : Page de recherche de variable avec lien de modification de cette variable. ...................... 37

Image 24 : Formulaire d’ajout d’une nouvelle variable ........................................................................ 38

Image 25 : tâches réalisées ................................................................................................................... 39

Image 26 : Diagramme de GANTT réel .................................................................................................. 40

sur 68

Introduction

Dans le cadre de ma formation à l’IUT informatique de Blagnac, j’ai choisi d’effectuer un stage de fin d’étude (10 semaines) au laboratoire LAAS1 CNRS2, un laboratoire spécialisé dans le domaine des Sciences et Technologies de l’Information et de la

Communication. Mon travail s’est déroulé sous la supervision de Mme Christelle ECREPONT, Ingénieur de Recherche et Responsable Technique ADREAM. Du côté de l’IUT,

j’ai été supervisé par Mme Amélie LEGRAND, professeur de Communication.

Le stage a débuté le lundi 14 Avril 2014 et s’est achevé le lundi 23 Juin 2014. L’objectif

premier était de mettre en place un système de gestion des données (données électriques, photovoltaïques et météorologiques) récupérées grâce aux différents capteurs présents dans le bâtiment intelligent ADREAM et tout autour. Il fallait donc mettre en place un système de duplication (sauvegarde) et de manipulation des données (formulaires d’enregistrements et

de recherches), afin de fournir aux chercheurs les données du bâtiment indépendamment du système de supervision et collecte PCVue3

Ce rapport expose l’ensemble de mes activités pendant ces trois mois. Dans un premier temps, je présenterai d’une façon précise le LAAS CNRS, puis le pôle dans lequel j’ai effectué

mon stage. Ensuite je présenterai méthodiquement les différentes tâches que j’ai eues à réaliser. Enfin, je dresserai un bilan de cette expérience, au niveau technique, humain et professionnel.

Ce document est composé de plusieurs parties afin d’en faciliter la lecture et

l’organisation. Un glossaire est aussi fourni, afin de définir les termes techniques employés tout au long de ce rapport. L’ensemble des documents jugés utiles pour la compréhension de ce

rapport se trouve en annexes.

1 Laboratoire d’Analyse et d’Architecture des systèmes 2 Centre National de la Recherche Scientifique 3 Voir page 15

sur 68

I. Présentation de l’entreprise

I.1 Le LAAS CNRS

I.1.1 Historique 4

Fondé en 1967 par Jean Lagasse et inauguré en 1968, le LAAS (laboratoire d’analyse

et d’architecture des systèmes) est l’un des plus grands laboratoires du Centre national de la recherche scientifique (CNRS). Il est rattaché à deux des dix instituts du CNRS : l’institut

des sciences de l’information et de leurs interactions (INS2I) et l’institut des sciences de

l’ingénierie et des systèmes (INSIS). Associé à l’ensemble des établissements d’enseignement

supérieur fondateurs de l’Université de Toulouse (UPS, INSAT, INPT, UTM, ISAE, UT1), il est fortement impliqué dans les formations universitaires et dans les écoles doctorales dans ces domaines.

Solidement ancré dans sa région et ses environs académique et industriel, il mène des collaborations avec les grands centres de recherche en Europe et dans le monde.

Le LAAS-CNRS conduit des projets à fort impact socio-économique en collaboration avec l’industrie dans les secteurs de l’aéronautique,

l’espace, les transports, l’énergie, la défense et la

sécurité. Cette relation privilégiée a conduit en 1990 à la création d’un « club des affiliés ». Le club compte aujourd’hui 78 entreprises dont ¾ de PME

et PMI. Enfin, le LAAS a été labélisé « Institut Carnot » en 2006 et renouvelé en 2011.

Les 22 équipes de recherche du laboratoire sont réparties dans huit thèmes scientifiques : informatique critique, réseaux et communications, robotiques, décision et optimisation, gestion de l’énergie, micronanobiotechnologies, hyperfréquences et optique : de l’électromagnétisme aux systèmes, nanoingenierie et intégration. Le laboratoire développe deux axes interdisciplinaires : l’intelligence ambiante, la mobilité, les systèmes embarqués

cyber-physique avec le programme Adream ; les interactions avec le vivant et l’environnement

(biologie, santé, humain) avec le programme Alive.

Les recherches menées au LAAS-CNRS requièrent des puissants moyens expérimentaux et technologiques. Ces ressources sont mutualisées au sein de plates-formes technologiques : salle blanche de 1500 m2 du réseau nationale Renatech pour les micro et nanotechnologies ; plus de 1000 m2 de salles de caractérisation dont 400 m2 dédiés à l’analyse

biologique et chimique (Alive) ; flotte d’une douzaine de robots ; bâtiment instrumenté et à énergie optimisée de l’axe Adream ; conception de micro et nanosystèmes. S’y ajoutent les

ateliers d’électronique et de mécanique. Trois services techniques assurent l’évolution de ces

4 Ces informations proviennent du « Guide des nouveaux arrivants » qui m’a été remis lors de mon entrée au LAAS

Au LAAS, aujourd’hui :

- 206 Chercheurs et enseignants chercheurs

- 252 doctorants et post-doctorants

- 122 ingénieurs, techniciens et administratifs

- 32 chercheurs temporaires

sur 68

plates-formes et la participation des ingénieurs et techniciens aux projets de recherche. Enfin, les services administratifs, logistiques et de soutien à la recherche, colonne vertébrale du laboratoire, veillent à son infrastructure et à son bon fonctionnement.

Dans un environnement scientifique, matériel et humain de grande qualité, le laboratoire LAAS-CNRS est un endroit où on prend plaisir à travailler.

sur 68

I.1.2 L’organigramme

Axes, thèmes et équipes de recherches

INFORMATIQUE CRITIQUE - Tolérance aux fautes et sûreté de

fonctionnement informatique - Vérifications des systèmes

temporisés critiques - Ingénierie système et intégration

RESEAU ET COMMUNICATION - Services et architectures pour les

réseaux avancés - Calcul distribué et asynchronisme

ROBOTIQUE - GEPETTO : Mouvement des

systèmes anthropomorphes - Robotique, action et perception - Robotique et interaction

MICRONANIBIOTECHNOLOGIE - Nano biosystèmes - Microsystème d’analyse - Matériaux et procédés pour la

nanoélectronique GESTION DE L’ENERGIE

- Intégration des systèmes de gestion de l’énergie

- Energie et systèmes embarqués HYPERFREQUENCE ET OPTIQUE

- Nanoingenierie et intégration des systèmes

- -micro et nano systèmes pour les communications

DECISION ET OPTIMISATION - Diagnostic, supervision et service

qualitatif - Méthode et algorithme de commande - Recherche opérationnelle,

optimisation combinatoire et contrainte

sur 68

Organisation fonctionnelle

Direction Jean Arlat, directeur

Anne-Marie Gué, directrice adjointe

Gestion et pilotage Pascale Thevenod

Assistant de direction, Secrétaires d’équipes et de thèmes Communication

Conseil de direction

Conseil de laboratoire

Commission hygiène et

sécurité

Thèmes scientifiques

Axes stratégiques

Services techniques

Commission enseignement et

recherche

Services administratifs,

soutien et logistiques

sur 68

Les locaux

Le LAAS compte 8 bâtiments identifiés par des lettres de A à H. Les bâtiments G et H (local du stage et bâtiment du programme ADREAM) portent respectivement les noms du directeur fondateur du LAAS en 1968, Jean Lagasse et de son adjoint d’alors, Georges Giralt.

A

B

D

C F

G

H

E 1

5

2

3

Hall

4

6

9 10

8

8

7

13

1 2 3

4

5 6

10

9

11

12

1 2 3 4 5

6

8 9

10

Accueil Bibliothèque Edition Magasin Cafétéria

Salle blanche

Salle de sport Ping-pong Douches

7

7 Baby-foot

1 Rez-de-chaussée er Sous-sol Étage

1 2 3 4 5 6 7 8

9 10 11 11 12 13

Salle de conférences Salle Vignemale Salle de direction Salle du conseil Salle S11 Salle S13 Salle S28 Salle Cagire Visioconférence Salle Europe Salle Tourmalet Salle Bardeen Salle Moore Salle Feynman Salle Hourgade

sur 68

I.2 Le projet ADREAM I.2.1 Présentation5

Le projet ADREAM «Architectures dynamiques reconfigurables pour les systèmes embarqués autonomes mobiles », sous-titré «Composants et systèmes embarqués, matériels et logiciels, pour réseaux de capteurs et d'actionneurs mobiles, sans fil, dans la conduite, la supervision et le diagnostic en aéronautique, espace, environnement et transports» est une action structurante soutenue par le Contrat de Projets Etat-Région Midi-Pyrénées 2007-2013.

Ce projet scientifique ambitieux, soutenu par des moyens technologiques novateurs, a

pour objectif de développer, d’intégrer, et de valider de nombreux travaux de recherche et de développement dans plusieurs domaines avancés, tels que les systèmes embarqués, les réseaux de capteurs, l’internet des objets, les interconnexions de services, les robots

compagnons, le respect de la vie privée, et la gestion optimisée de l’énergie.

Le but de ce projet est de développer ces différents domaines, de préparer leurs futures synergies, d’anticiper les outils nécessaires à la définition d’un cadre de conception

adapté, et de proposer les premières expérimentations s’y rapportant. Ces recherches vont ainsi renforcer les compétences du LAAS et de ses partenaires de la recherche et de l’industrie, sur

les capteurs, les mesures, les systèmes de communication, la sécurité informatique, les robots rendant de multiples services en interaction avec les humains, et les systèmes énergétiques, ainsi que sur la conception de tous les nouveaux systèmes soumis à de fortes contraintes de performance, d’énergie, de résilience ou d’autonomie.

De plus, le fort besoin de disposer d’un site expérimental adéquat, c’est-à-dire d’un

site qui soit suffisamment représentatif pour être un démonstrateur significatif tout en restant de complexité maîtrisable, a conduit à la construction d’un nouveau bâtiment, conçu pour être

lui-même ce support des recherches et des expérimentations.

Il est fondamental de souligner que le contexte expérimental choisi, celui des bâtiments innovants, constitue un domaine d’application extrêmement important, économiquement et socialement.

5 http://www.laas.fr//files/ADREAM/ADREAM-ProgrammeScientifique113-01-15.pdf

Figure 1 : Bâtiment ADREAM aussi appelé Bâtiment H (Image de synthèse) Image 1 : Bâtiment ADREAM aussi appelé Bâtiment H (Image de synthèse)

sur 68

I.2.2 ADREAM, un bâtiment intelligent

Le bâtiment, a pour but d’intégrer les travaux interdisciplinaires nécessaires en électronique, énergie, informatique, et commande. Sa construction a été achevée fin 2011 et il est occupé par des chercheurs et des techniciens du laboratoire depuis le mois de mars 2012.

Des points de vue électronique et énergétique, la plate-forme du bâtiment comporte un mur façade et deux toitures (dont une terrasse) entièrement équipés en panneaux photovoltaïques pour la production d’énergie et la recherche s’y rapportant. Associés à trois pompes à chaleur géothermiques et un puits canadien, ces équipements constituent des moyens uniques en leur genre pour l’étude et l’optimisation des nouveaux systèmes de

conversion et d’optimisation d’énergie.

Les cellules photovoltaïques permettent d’alimenter tout le bâtiment en électricité et les autres bâtiments du LAAS en cas de fort ensoleillement.

Des points de vue informatique et robotique, l’ensemble des équipements, des mesures,

des données, des logiciels et des actions, sera intégré et enrichi par l’interconnexion intelligente

de réseaux à qualité de service garantie et par les actions de robots autonomes navigant dans le bâtiment.

I.2.3 PCVue : Un logiciel de supervision et de gestion des informations

Plus de 6000 capteurs sont répartis dans tout le bâtiment. Certains capteurs permettent de suivre et/ou gérer l’éclairage, d’autres ont pour fonction de suivre l’évolution de

la température ambiante. Le bâtiment dispose également de capteurs permettant de suivre le fonctionnement des panneaux solaires et la consommation électrique.

Figure 2 : Système de production de l’énergie électrique du bâtiment ADREAM Image 2 : Système de production de l’énergie électrique du bâtiment ADREAM

sur 68

Le logiciel PCVue est un logiciel SCADA6 de GTB7 qui permet le suivi du fonctionnement du bâtiment et en plus permet aux chercheurs qui travaillent sur le projet Adream de modéliser le bâtiment et de faire des expérimentations et des simulations grâces aux données des capteurs. Ce logiciel qui est donc un outil de supervision fonctionne en interaction avec les automates qui modélisent les différentes informations envoyées par les capteurs.

Par abus de langage, l’ordinateur sur lequel tourne PCVue est nommé comme le logiciel. Le logiciel est en connexion permanente avec la base de données Microsoft SQL Server, qui permet le stockage de toutes les informations des capteurs. Etant donné que les capteurs envoient une information à chaque seconde, la base de données contient des millions de lignes d’information qui rendent le requêtage8 de la base longue et pénible pour les chercheurs. Aussi, le fait que les informations transmises par les capteurs soient des chiffres (ex :12345899665995998716 pour désigner le temps en secondes) ou des codes particuliers (ex :PHV.SYNT.EX), font que le requêtage de la base sans une formation au préalable ne sert à rien car les informations toutes seules ne sont pas interprétables. Le but donc du stage était donc de rendre les données interprétables, indépendamment de PCVue, afin que les chercheurs puissent mener leurs projets. Il a donc fallu pour cela dupliquer la base de données existante, créer des formulaires de recherches et des formulaires d’insertion de nouveaux capteurs dans la

base de données. L’un des points les plus importants de projet que constitue ce stage, a

également été d’arriver à grapher9 les informations sur un intervalle de jours ou de mois. Grapher les différentes informations sur un intervalle de jours ou de mois permettrait aux chercheurs de suivre à l’aide des courbes les différentes variations de températures, de

production d’électricité… Il faut rappeler que PCVue peut générer des courbes en fonctions des

informations de la base.

Quelques vues de PCVue :

6 SCADA : Système de contrôle et d’acquisition des données 7 GTB : Gestion Technique du Bâtiment 8 Action de rechercher des informations dans une base de données 9 Cette partie du stage a été détaillé dans le rapport d’Arnaud LODS

Figure 3 : Vue de la consommation en électricité du bâtiment Image 3 : Vue de la consommation en électricité du bâtiment

sur 68

On peut remarquer sur l’image précédente (en haut, à droite) qu’il y a un apport d’EDF

en électricité le jour où cette capture a été prise. Lorsqu’on est dans cette situation, on est le

plus souvent un jour de très faible ensoleillement. Dans le cas contraire, la flèche rouge devient verte et ce sont les autres bâtiments du LAAS qui bénéficient de l’électricité produite.

Les deux images suivantes nous montrent respectivement la variation de la production électrique pendant une période (ici entre 11/10/12 11:00 et 11/10/12 18:30) et la production et consommation en électricité d’un moment précis (ici 19/04/13 09 :55 :00).

Figure 4 : Variation électrique

Image 5 : Consommation et production électrique

Image 4 : Variation électrique

sur 68

II. Présentation du service, de l’existant, de l’environnement de travail et analyse du prévisionnel

II.1 Le service informatique IDEA

J’ai réalisé le stage en étant rattaché au service IDEA qui est le service informatique du LAAS. Le service IDEA Informatique : Développement, Exploitation et Assistance offre un soutien technique aux projets de recherche, à l’administration des moyens informatiques et

au développement du système d’information, pour l’ensemble du laboratoire.

Il est composé de 23 ingénieurs et techniciens (avril 2013). Une partie des ingénieurs du service IDEA assurent un soutien aux projets de recherche dans les domaines de l’informatique et de la robotique. Les projets soutenus sont définis annuellement par une commission présidée par le Directeur.

Le service gère les moyens informatiques du laboratoire (réseau, serveurs, logiciels, postes de travail, site Web), développe et maintient le système d’information du laboratoire

ainsi que les applications Web associées, et assure la gestion et le support technique des plates-formes : robots, réseaux et conception. Cette activité porte principalement sur les moyens informatiques, matériels et logiciels. Elle s’applique aux moyens communs ainsi qu’à la plus

grande partie des moyens propres des groupes de recherche.

II.2 L’existant

L’objectif du stage a d’abord été de dupliquer la base de données MSSQL de PCVue puis de créer une application web permettant de récupérer et d’analyser les données provenant

de cette base. L’existant se limite à cette base. Tout devrait donc être réalisé pendant le stage.

Il faut également souligner le fait que la base de données PostgreSQL, dans laquelle les données ont été dupliquées a été installée et les tables créées au début du stage. Cet environnement de travail a été choisi par le laboratoire pour des raisons de performance et d’uniformisation. Cette base de données contenait cinq tables nommées « luminaire, elec, photov, cvc et variables ». Au début du stage, ces tables étaient « plates » i.e. qu’elles n’avaient

aucune relation entre elles. Plus tard, après le remplissage de la table des variables, une relation de clé étrangère a été générée entre cette table variable et toutes les autres tables. Le diagramme des classes se présente comme suit :

sur 68

Image 5 : Modèle Logique de données de la base PostgreSQL

II.3 L’environnement de travail

Le laboratoire LAAS m’a fourni un ordinateur DELL avec un système d’exploitation

xubuntu, une variante d’ubuntu. Par la suite, il a fallu plus d’une semaine pour avoir une

configuration totale du serveur, une installation complète des logiciels nécessaires. La configuration et l’installation de ces outils ont pris beaucoup de temps car ce travail était

effectué à distance par des administrateurs système, qui s’occupent également des autres 612 personnes du LAAS. Il fallait donc attendre, suivant sa disponibilité, pour avoir le logiciel d’installé.

Voici une liste non exhaustive des logiciels installés et utilisés :

- Netbeans, un IDE fiable et puissant qui a servi d’hôte pour le template Symfony2 - Eclipse, un autre IDE, équivalent de Netbeans - Geany, un éditeur de texte, équivalent de notepad++ sous linux. Logiciel très performant

et très ergonomique - pgAdmin, un outil d’administration de la base de données PostgreSQL

sur 68

- dbVisualizer, un outil d’administration de base de données. Très ergonomique et

pratique, cependant très peu utilisé lors du stage

En plus de ces logiciels précédents, ajoutant tous les logiciels gratuits de linux à savoir le pack open office fortement utilisé lors de la manipulation des données des fichiers CSV.

II.4 analyse du prévisionnel

La toute première tâche proposée au début du stage a été la duplication de la base MSSQL de PCVue. Cette tâche se découpait en deux sous-tâches. Une tâche de sauvegarde générale, et une tâche de sauvegarde incrémentale grâce à un script lancé directement depuis la crontab. En me basant sur l’expérience de certains professeurs de l’IUT, j’ai estimé que cette

tâche pouvait être réalisée en deux semaines. Une première semaine pour la sauvegarde générale et une autre pour la sauvegarde incrémentale. De nouvelles devraient donc être données en fonction de l’évolution donc à partir de la troisième semaine. En fonction de cette estimation j’ai réalisé le diagramme de GANTT prévisionnel suivant :

Image 6 : Tâches à accomplir au début du projet

Image 7 : Diagramme de GANTT de ces tâches

sur 68

III. Le projet

III.1 Les différentes tâches à réaliser

Les deux premières importantes fonctionnalités du stage ont été de réaliser une sauvegarde générale et une sauvegarde incrémentale de la base de données de la machine PCVue. La mise en place d’un tel système permet de protéger les données contre les erreurs de manipulation des utilisateurs ou des catastrophes naturelles dans certains cas. Mon travail consistait donc à réaliser un script/des scripts permettant la sauvegarder ces données.

Le mécanisme de sauvegarde mis en œuvre doit impérativement être pensé de manière

à assurer la pérennité et la récupération de l'ensemble des données critiques de l'organisation, quel que soit le sinistre subi, sans perturber le fonctionnement du système d’information. Ainsi, le choix du mécanisme de sauvegarde doit faire l'objet d'une stratégie de sauvegarde, définissant les données à sauvegarder, la fréquence et le mode de sauvegarde, et d'un plan de reprise sur sinistre indiquant la démarche nécessaire pour rétablir le fonctionnement normal en cas d'incident.

On distingue habituellement les catégories de sauvegardes suivantes :

Sauvegarde totale Sauvegarde différentielle Sauvegarde incrémentale Sauvegarde à delta Journalisation

Dans le cadre de ce stage, j’ai effectué deux types de sauvegarde : une sauvegarde totale et une sauvegarde incrémentale.

Les tâches supplémentaires ont été de créer, en utilisant le template Symfony2 une application web composée de différents formulaires : des formulaires de recherches, formulaires d’insertion ou de modification de données présentent dans la base de données.

III.2 Un projet réalisé en binôme

La réalisation de l’application web a été faite à deux. Le binôme Arnaud LODS s’est

occupé de la partie qui permet de grapher les données sur un intervalle de temps, d’enregistrer

de nouveaux problèmes... Toutes les tâches qu’il a eu à faire dépendaient des traitements que j’ai effectués sur la base de données à savoir la sauvegarde, qui permettait d’avoir des données

sur lesquelles travailler.

sur 68

III.3 La sauvegarde totale

Traitement :

Selon le site commentcamarche.net, l'objectif de la sauvegarde totale (parfois sauvegarde générale ou en anglais full backup) est de réaliser une copie conforme des données à sauvegarder sur un support séparé. Néanmoins, pour de gros volumes de données, la sauvegarde complète peut poser des problèmes de lenteur (si les données sont modifiées en cours de sauvegarde), de disponibilité car elle crée des accès disques longs et intenses ou encore de coût étant donné la capacité nécessaire. En revanche elle permet d'obtenir une image fidèle des données à un temps t.

Le full backup réalisé dans cette première partie du stage a été de transférer les deux ans d’informations présentes sur la base Microsoft SQL Server vers une base PostgreSQL. La base MSSQL (Microsoft SQL) est la base de données intégrée à la machine PCVue. Sur cette base de données existent quatre tables nommées CNRS_DATA_CVC, CNRS_DATA_ELEC, CNRS_DATA_LUMINAIRE et CNRS_DATA_PHOTOV. Ces quatre tables contiennent toutes les informations transmises par les capteurs.

Afin de faire le transfert des données de cette base vers la nouvelle base PostgreSQL, il a fallu générer quatre fichiers CSV10 contenant ces informations. Ce format de fichier étant facilement manipulable.

L’étape suivante a été de faire les scripts qui se chargent de lire les données dans chacun de ces fichiers, de sélectionner les colonnes indispensables, puis de les insérer dans la nouvelle base dont les tables (CVC, ELEC, PHOTOV, LUMIN) équivalentes des bases sous mssql, ont été créées au préalable.

L’image précédente représente la structure d’une des tables de la base de données

PostgreSQL. Cette table contient un Chrono qui représente un temps (Mois-Jour-Année-Minutes-Secondes) bien précis. La norme utilisée pour enregistrer ces informations est celle du FILE TIME. Le FILE TIME est le temps écoulé en nanosecondes écoulés depuis le 1er 10 Fichier dont le contenu est disposé en colonne et séparé par une virgule

Figure 6 : Modèle de la table CVC (Chauffage-Ventilation-Climatisation) dans la base de données: Image 8 : Modèle de la table CVC (Chauffage-Ventilation-Climatisation) dans la base de données:

sur 68

Janvier 1601. Ensuite nous avons une colonne « Name » qui contient le nom des variables qui permettent de savoir de quel capteur proviennent les informations liées à cette variable. La colonne « Value » et « Quality » contiennent des valeurs numériques qui servent à vérifier s’il

y a ou pas des anomalies au niveau des informations récupérées. Le Champ description quant à lui sert à avoir certaines informations complémentaires concernant chaque capteur.

Les tables ainsi créées posent un problème de conception : on peut noter l’absence d’une

colonne auto-incrémentée permettant de connaître la dernière insérée dans la base. Or, la connaissance de cette dernière ligne est très importante pour la suite car lors de la sauvegarde incrémentale (voir II.3), la dernière ligne insérée est une ligne de référence permettant de savoir quel couple chrono-Name été inséré dans la base lors de la dernière sauvegarde.

Le langage de programmation qui a été choisi pour faire ce traitement a été le PHP. J’ai

décidé d’utiliser PHP pour la simple raison que je maîtrise le langage et vu que la tâche de

sauvegarde est une tâche couramment effectuée certains morceaux de codes disponibles sur le site de PHP sont facilement réutilisables.

PHP est un langage principalement utilisé pour créer des pages web dynamiques via un serveur HTTP, i.e. qui réagissent suivant les traitements de l’utilisateur. Etant donné que

certains traitements effectués en PHP, notamment la lecture du contenu d’un fichier csv, sont

assez fréquents, le site officiel du langage PHP propose un code source qui fait ce travail et s’adapte à tous les fichiers csv, peu importe son contenu.

Cette portion de code, un peu adapté au contexte, a permis de résoudre à elle seule 80% de cette tâche de sauvegarde. Les 20 % restantes, ont été la sélection de la bonne colonne selon le fichier, puis de faire une requête basique d’insertion en langage SQL dans la table adéquate.

Il a également fallu créer un fichier d’erreur par fichier csv, qui en cas d’erreur lors de l’insertion

mémorisait le numéro de la ligne où l’erreur s’est produite afin de faciliter les vérifications par la suite.

Le schéma de ce traitement se présente de la sorte :

Image 9 : Schéma de la sauvegarde générale

sur 68

Chaque fichier comprenant énormément de lignes (soit plus de deux années d'enregistrements), leur génération demandait un temps de traitement conséquent. Le plus gros fichier comportait plus de 108 millions de lignes et le plus petit 5 millions. Il fallait donc lancer l’exécution des scripts et attendre le lendemain matin pour avoir les résultats et s’assurer du bon fonctionnement des différentes tâches.

Le travail de la sauvegarde totale a pris exactement trois jours. Le plus souvent ce traitement peut se faire en quelques heures, mais vu la taille des différents fichiers csv en présence et le temps d’exécution, il a fallu plus de temps pour que cette tâche soit totalement

effectuée.

Problèmes rencontrés :

Le premier problème rencontré a été la redondance des données dans les fichiers fournit. Il s’est trouvé que dans tous les fichiers csv, certaines lignes étaient redondantes, ce qui est anormal. En théorie et même de manière plus concrète, il ne devait y avoir aucune redondance de lignes dans la base. Lors de la sauvegarde, j’ai créé un fichier pour qu’à chaque

fois qu’une erreur était levée par la base de données à cause d’une ligne existante, le numéro de

la ligne et les informations sur cette ligne était écrites dans ce fichier, afin de pouvoir facilement récupérer ces lignes au niveau de la base MSSQL de PCVue.

Cette sauvegarde complète, après vérification des données récupérées, un mois plus tard, s’est montrée insuffisante car certaines informations notamment la description liée à chaque variable était erronée. Pour retrouver cette description, il a fallu concaténer certains champs précis de chaque ligne du fichier. Le fichier n’étant pas uniforme, les lignes ne

contenaient donc pas le même nombre de champs (colonne dans le fichier CSV), ce qui a conduit à des amalgames entre les informations faussant ainsi la description des variables dans la base. Les données importées n’étaient plus fiables. Pour corriger cette erreur, un processus développer plus tard sera utilisé.

III.4 La sauvegarde du fichier de variables

Traitement :

Entre les deux grands traitements à savoir la sauvegarde générale des deux ans d’information et la sauvegarde incrémentale, il a fallu sauvegarder un fichier contenant toutes les variables de références qui iront dans la colonne « Name » dans la table « Variables ».

Ce fichier étant un fichier .XLS, il a fallu le convertir en CSV afin de refaire le traitement similaire à celui de la sauvegarde générale. L’objectif de cette sauvegarde est d’arriver à la fin

à créer une clé étrangère (relation entre les colonnes d’une table mère avec celle d’une table

« fille » afin que toutes les informations présentent dans la colonne de la table fille (ici colonne « name »), doivent impérativement se retrouver dans la colonne de la table mère).

sur 68

Problèmes rencontrés :

Après la sauvegarde du contenu de ce fichier, il s’est trouvé que certaines variables présentes dans la colonne « name » de toutes les tables filles (CVC, ELEC, LUMINAIRE, PHOTOV), étaient absentes de la table mère (table Variables).

Pour corriger ce problème, j’ai donc fais une requête afin de déterminer toutes les informations présentes dans la colonne « name » des tables filles et qui ne l’étaient pas dans

celle de la table mère de références. Ces information récupérées, il a juste fallu mettre ces informations dans un fichier CSV et de les importer dans la table mère de références afin de combler les différences et créer facilement les clés étrangères.

Quelques semaines plus tard, il a été nécessaire de refaire cette sauvegarde, car la récupération des variables à partir des tables filles pour compléter la table mère ne permettait pas de compléter la colonne " description" pour ces variables. Le fichier de référence des variables a donc été retravaillé, certaines variables systèmes de PCVue présentent dans les tables filles, mais inutiles pour la suite du projet ont été supprimées ; Certaines lignes du fichier ont subi des traitements spéciaux. Il a fallu reconvertir l’encodage du fichier…puis les données du fichier ont été correctement importées.

Cette sauvegarde a été l’une des plus complexes, non pas à cause de la méthode ou algorithme utilisé pour faire le traitement, mais à cause du contenu du fichier. La sauvegarde a été répétée plus d’une vingtaine de fois avant d’obtenir le résultat escompté.

III.5 La sauvegarde incrémentale

La sauvegarde incrémentale (en anglais incremental backup) consiste à copier tous les éléments modifiés depuis la sauvegarde précédente. Ce type de sauvegarde est plus performant qu'une sauvegarde totale car elle permet de se focaliser uniquement sur les fichiers modifiés avec un espace de stockage plus faible, mais nécessite en contrepartie de posséder les sauvegardes précédentes pour reconstituer la sauvegarde complète.

L’objectif de ce travail était donc de permettre aux chercheurs d’avoir une copie à

jour (24 heures de différence) entre la base PostgreSql et la base MSSQL. Pour implémenter ce genre de traitement, il faut arriver à récupérer la dernière ligne ajoutée dans notre base PostgreSql ; on fait alors face au problème de conception précisé plus haut : en une seconde par exemple, il y a plusieurs « Chrono » qui sont rajoutés dans la base de données avec des noms de variables différents. Or vu que la base de données trie les informations par ordre croissant, il devient alors impossible de récupérer avec précision la dernière ligne insérée. Pour résoudre ce problème, il a fallu faire un traitement spécial afin d’avoir à tout moment les bonnes informations.

sur 68

III.5.1 Explication de l’algorithme du script de sauvegarde incrémentale11 :

Dans cette partie, nous allons nous appliquer à expliquer en détail l’algorithme utilisé

pour la sauvegarde incrémentale. Pour ce programme, nous avons trois fichiers importants : un fichier qui permet d’ouvrir

des connexions aux deux bases de données, un fichier qui permet de fermer les connexions ouvertes dans le fichier précédent et enfin un fichier contenant toute la partie importante du processus. Tout le processus commence d’abord par le fichier « connexion.php » (Ce fichier est inclus dans les en-têtes de programmes). Dans ce fichier, on ouvre deux connexions, une pour la base MSSQL et une autre pour la base PostgreSql. On crée ensuite un fichier d’erreurs nommé FicErreurConnexion.txt qui devra contenir toutes les erreurs survenues lors de la tentative de connexion aux bases ; ces erreurs sont les informations renvoyées par la base sur laquelle la tentative de connexion a échouée. Dans le cas où l’une des bases est inaccessible, le script s’arrêtera automatiquement, et le contenu du fichier précédent est envoyé par mail à

l’adresse [email protected] .

Dans le cas où les deux connexions sont ouvertes sans problèmes, on rentre directement dans le « corps » du script qui est soit le fichier SauvegardeIncrementaleCVC.php ou l’un des

trois autres (un fichier par table). Un fichier d’erreurs est généré. Dans le cas d’exemple sur les

données CVC, ce fichier s’appellera FicErreurCvC.txt. Ce fichier devra contenir l’heure du

début du script, les erreurs levées par les bases lors des différentes requêtes, le nombre cumulé de lignes insérées par requêtes, le nombre d’erreurs par banc de requêtes, l’heure à laquelle le

script a arrêté de s’exécuter.

On effectue dans un premier temps une requête afin de récupérer le dernier Chrono qui a été inséré dans la base de données MSSQL CNRS_DATA_CVC au moment où le script a été lancé. Ce chrono sera le chrono de référence (Chrono1), donc la condition d’arrêt de notre

script.

Ensuite, on récupère dans la table CVC dans la base PostgreSQL le plus grand chrono. Ce chrono correspond à la dernière ligne insérée dans la base lors de la dernière sauvegarde. Or il se trouve qu’il existe plusieurs occurrences de ce dernier chrono avec des noms de variables

différents. Ce qui rend dans ce cas l’identification de la véritable dernière ligne insérée impossible, étant donné que la base de données trie les informations.

Pour résoudre le problème précédent, on récupère quand même ce dernier chrono (Chrono2) puis on supprime toutes ses occurrences dans la table CVC (Pour réaliser cette opération de suppression, la base de données doit être accédée avec les droits d’administrateur

ou un profil permettant au script de faire des suppressions et des insertions.).

Après cette suppression, on effectue une nouvelle requête sur la base de données mssql, précisément dans cet exemple la base CNRS_DATA_CVC. On récupère les 50000 lignes contenant les chronos supérieurs ou égale au Chrono2. La requête peut ramener moins de lignes en fonction des informations présentes dans la base. On insère les lignes récupérées

11 Voir l’algorithme dans les annexes, page 50

mailto:[email protected]

sur 68

dans la table CVC. On recommence alors le traitement qui consiste à récupérer le dernier plus grand chrono (Chrono2), à supprimer ce chrono, à requêter la base mssql avec le Chrono2 comme condition de départ…jusqu’à ce que le chrono de référence (Chrono1) soit atteint ou dépassé.

Lorsqu’on sort de la boucle de requêtes, on a alors le plus grand Chrono dans la table

CVC qui est égal ou supérieur au chrono de référence récupéré plus haut. On rentre alors dans le fichier de déconnexion, on ferme les connexions aux bases de données, aux fichiers, puis on envoie le contenu des fichiers d’erreurs par mail, puis on vide le fichier.

Cet algorithme nous permet d’avoir, si le script est lancé chaque jour, un jour de

différences d’informations entre les différentes bases.

Image 10 : Différents traitements réalisés

Problèmes rencontrés : Au début du stage, j’ai réalisé quatre scripts pour la sauvegarde des quatre tables. Or le

fait d’avoir quatre fichiers pour cette sauvegarde rendait la maintenance moins performante car il fallait appliquer à chaque fois les modifications sur les quatre scripts. Donc, sur demande de ma responsable de stage, un seul script a été implémenté afin de s’exécuter en fonction du nom

de la base mis en paramètre.

sur 68

III.5.2 Exécution automatique du script grâce à la crontab :

« Crontab est le nom du programme sous Unix (et Linux) qui permet d'éditer des tables de configuration du programme cron. Ces tables spécifient les tâches à exécuter et leur horaire d'exécution avec possibilité d'horaire périodique. Par extension, on appelle souvent cron (ou cron job en anglais) toute tâche lancée à horaire périodique. »

Le programme expliqué dans la partie précédente devait être lancé périodiquement. Cependant, afin de ne pas surcharger la base de données de PCVue, il a fallu faire quelques tests afin de déterminer les bonnes heures auxquelles le script pourra être lancé. Pour cela, il a fallu lancer le script manuellement et vérifier le temps d’exécution en fonction du nombre d’informations récupérées.

Les vérifications et tests terminés, le programme a donc été programmé pour se lancer à une heure bien précise (3h30 du matin) au moment où la base et PCVue sont moins solliciter.

III.5.3 Utilisation du script incrémental pour corriger l’erreur survenue lors de

la sauvegarde générale :

Le script de sauvegarde incrémentale a ensuite été utilisé pour réimporter toutes les informations importées lors de la sauvegarde totale. Lors de cette réimportation, étant donné qu’il y avait des millions de lignes à réimporter par base, certains comportements inattendus ont été observés : la base de données MSSQL un certain temps d’accès en lecture arrêtait

d’envoyer les données demandées par le script, le script rentrait alors dans une boucle infinie,

et il fallait donc arrêter le script manuellement.

Pour résoudre ce problème, le script a été modifié et automatisé afin de s’arrêter ou se

relancer en fonction des différentes réponses de la base MSSQL.

La tâche de sauvegarde incrémentale qui était estimée à environ une semaine a finalement duré plus de trois semaines car il a fallu de temps en temps par semaine faire quelques modifications pour pallier à certaines erreurs inattendues, que la version courante du script ne prenait pas en compte.

III.6 Réalisation d’une IHM avec Symfony2

III.6.1 IHM pour Interface Home Machine

La seconde partie du stage a été de réalisé une IHM permettant aux chercheurs de manipuler les données présentes dans la base de données PostgreSql. Une IHM, selon le JDD12, est ensemble de dispositifs matériels et logiciels permettant à un utilisateur de communiquer

12 Journal Du Net (site d’informations informatique)

sur 68

avec un système informatique. Dans le contexte de notre stage, cette IHM a été une application web réalisée avec Symfony2.

III.6.2 Symfony2 pour réaliser une application web en MVC

III.6.2.1 Définition

Tout d’abord Symfony2 est un « framework ». Le mot « framework » provient de l'anglais « frame » qui veut dire « cadre » en français, et « work » qui signifie « travail ». Littéralement, c'est donc un « cadre de travail ». Concrètement, c'est un ensemble de composants qui servent à créer les fondations, l'architecture et les grandes lignes d'un logiciel. Il existe des centaines de frameworks couvrant la plupart des langages de programmation. Ils sont destinés au développement de sites web ou bien à la conception de logiciels.

Un framework est une boîte à outils conçue par un ou plusieurs développeurs à destination d'autres développeurs. Contrairement à certains scripts tels que WordPress, Dotclear ou autres, un framework n'est pas utilisable tel quel. Il n'est pas fait pour être utilisé par les utilisateurs finaux.

III.6.2.2 Objectif d’un Framework

L'objectif premier d'un framework est d'améliorer la productivité des développeurs qui l'utilisent. Souvent organisé en différents composants, un framework offre la possibilité au développeur final d'utiliser tel ou tel composant pour lui faciliter le développement, et lui permet ainsi de se concentrer sur le plus important. L'avantage premier est donc, on vient de le voir, le gain en productivité. Mais il en existe bien d'autres ! On peut les classer en plusieurs catégories : le code, le travail et la communauté ; le Framework aide donc à réaliser un bon code, à améliorer la façon de travailler (Plusieurs personnes peuvent travailler en simultanée sur un même projet comme c’est le cas pour ce stage).

Image 11 : Logo de Symfony2

sur 68

III.6.2.3 Symfony2 : un Framework pour réaliser une application en MVC

Symfony est un Framework MVC libre écrit en PHP 5. En tant que Framework, il facilite et accélère le développement de sites et d'applications Internet et Intranet comme expliqué précédemment. Le patron MVC pour Modèle-Vue-Contrôleur est un modèle destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective.

Image 12 : Relation entre le Modèle, la Vue et le Contrôleur

- Le Cœur de l’application : le Modèle

Le Modèle dans le MVC correspond au cœur (algorithmique) de l'application : traitements des données, interactions avec la base de données, etc. Il décrit les données manipulées par l'application. Il regroupe la gestion de ces données et est responsable de leur intégrité. La base de données sera l'un de ses composants. Le modèle comporte des méthodes standards pour mettre à jour ces données (insertion, suppression, changement de valeur). Il offre aussi des méthodes pour récupérer ces données. Les résultats renvoyés par le modèle ne s'occupent pas de la présentation. Le modèle ne contient aucun lien direct vers le contrôleur ou la vue.

Le modèle peut autoriser plusieurs vues partielles des données. Si par exemple le programme manipule une base de données pour les emplois du temps, le modèle peut avoir des méthodes pour avoir tous les cours d'une salle, tous les cours d'une personne ou tous les cours d'un groupe de TD.

Dans notre cas, le modèle a été des classes représentant chaque table de la base de données ou des classes permettant de créer des formulaires. Pour des classes représentant la base, chaque attribut de cette classe représente une colonne d’une table de la base. Les informations de la base sont récupérées grâce à des méthodes publiques.

Modèle

VueContrôleur

sur 68

Le schéma suivant reprend la structure de la table présentée plus haut, montre le diagramme de classe qui en ressort et l’interprétation de ce diagramme en code symfony2.

Le schéma précédent nous permet de voir le modèle sous ses différentes formes. On remarquera Symfony2 traduit directement le diagramme de classe en php, sans omettre ni rajouter des attributs ou des méthodes. Un attribut dans l’exemple précédent est par exemple « chrono » dans le diagramme des classes. Ce chrono devient « $chrono » sous symfony2. Les méthodes (setChrono ou getChrono) permettent respectivement de modifier ou de récupérer un chrono directement dans la base de données.

<?php class CVC { protected $chrono; protected $name; protected $value; protected $quality; protected $description; // Et bien sûr les getters/setters : public function setChrono($chrono) { $this->chrono = $chrono; } public function getChrono() { return $this->chrono; } // Le reste est le même pour $name, $value, // $quality et $description

Image 13 : Modèle de la table CVC (Chauffage-Ventilation-Climatisation) dans la base de données

Image 14 : Diagramme de classes découlant du modèle précédent avec les méthodes et les attributs

Image 15 : Interprétation du diagramme de classe en code Symfony2

sur 68

- La partie visible de l’application : la Vue

Dans une application conçue en se basant sur le patron MVC, la vue est la partie visible par l’utilisateur, donc l’interface. Cette vue permet à l’utilisateur d’interagir avec le modèle. Cependant le lien entre la vue et le modèle dans le MVC passe obligatoirement par le contrôleur, et le template Symfony2 respecte rigoureusement ce principe.

- Une étape obligatoire : le Contrôleur

Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle, et ce dernier notifie la vue que les données ont changée pour qu'elle se mette à jour. Le contrôleur n'effectue aucun traitement, ne modifie aucune donnée. Il analyse la requête du client et se contente d'appeler le modèle adéquat et de renvoyer la vue correspondant à la demande.

III.7 Analyse conceptuelle de l’application

L’application web réalisée pendant ce stage est composée de différentes pages (services) permettant à l’utilisateur de réaliser une tâche particulière. Comme précisée plus haut, ce travail

a été réalisé en binôme. Certaines pages réalisées par le binôme pourront être mentionnées ou apparaîtront dans les schémas suivants, cependant, ces pages ne seront pas expliquées.

Rappelons que l’application a pour but de permettre aux utilisateurs de rechercher des

informations sur des capteurs, de grapher des données, de rentrer de nouveaux problèmes survenus dans la base…

III.7.1 Les Cas d’Utilisation

Selon Wikipédia, Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d'un système logiciel. Ils sont utiles pour des présentations auprès de la direction ou des acteurs d'un projet, mais pour le développement, les cas d'utilisation sont plus appropriés. Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail.

Le diagramme suivant représente le cas d’utilisation de l’application réalisée :

sur 68

Dans ce cas d’utilisation, on remarque les différents services disponibles. On remarque

également que certains services sont accessibles que par l’administrateur, notamment tous les services qui touchent à la création ou à la modification de variables dans la base de données.

III.7.2 Le Schéma Navigationnel d’Interface (SNI)

Le Schéma Navigationnel d’Interface ou SNI est un patron de conception d’IHM

(Interface Homme Machine) permettant de représenter des interfaces homme-machine d'une part, de concevoir une IHM tenant compte des exigences des utilisateurs, et d'autre part de générer automatiquement, par transformation de modèles, un squelette du logiciel souhaité.

Le SNI permet de concevoir et de modéliser la logique d’enchaînement des fonctions

de l’application en fonction du comportement supposé de l’utilisateur13.

Le SNI est purement conceptuel :

il est indépendant du type d’interface utilisé (Windows, WEB, Multimédia…) il ne représente pas la manière de faire de l’utilisateur (menu déroulant, bouton,

glisser-déposer…) il fait abstraction de tout aspect matériel (clavier, type d’écran, souris…)

13 http://webetud.iut-blagnac.fr/file.php/147/acsi.html

Image 16 : Cas d’utilisation d’une partie de l’application

sur 68

il ne représente pas les traitements réalisés dans l’application

Le SNI concerne de la partie "Vue" du MVC.

Image 17 : Schéma Navigationnel d’Interface de l’application réalisé

Sur le SNI précédent, on peut remarquer que certaines pages sont accessibles que par l’administrateur. Le SNI vient compléter les informations déjà présentes dans le Use Case

précédent. Il fait apparaitre les différentes pages, donc les différents services proposés à l’utilisateur.

Ce SNI, n’est pas complet car il ne contient pas toutes les pages développés dans ce

projet, le reste des pages étant développé par le binôme apparait dans son rapport. Dans la section suivante, chaque page sera minutieusement expliquée.

III.8 Les différentes composantes de l’application

III.8.1 La page de recherche simple

Cette page de recherche « simple » permet à l’utilisateur d’avoir toutes les informations

sur une variable.

Pour implémenter cette page de recherche, la liste déroulante qui contient toutes les variables a été, en utilisant un plug-in JavaScript, dotée d’un système d’auto-complétion. Le plug-in permet à la liste de suggérer à l’utilisateur au fur et à mesure qu’il saisit le nom ou une

sur 68

partie du nom de la variable, une liste de variables comportant les caractères saisis. L’avantage

est que l’utilisateur n’a pas à parcourir une liste de plus de cinq milles variables.

Lorsqu’on sélectionne la variable dont on désire avoir les informations et qu’on valide

le formulaire, les détails concernant cette variable sont affichés juste en dessous du champ de recherche, permettant ainsi à l’utilisateur de pouvoir refaire une recherche si besoin est.

III.8.2 La page de recherche « avancée »

Ce service permet à l’utilisateur d’avoir un ou une liste de variable en fonction des bribes d’informations qu’il possède sur la variable. Ces bribes d’informations peuvent être

une partie de la description ou du nom, l’unité, le room ou même le sensor. Afin réduire le

Image 18 : Liste déroulante auto-complétée de la page recherche de variables

Image 19 : Résultat d’une recherche affiché à l’utilisateur

sur 68

champ de recherche, le domaine de la variable est obligatoire. Lorsque l’utilisateur valide le

formulaire sans saisir le domaine (CVC, ELEC, LUMINAIRE ou PHOTOV), le processus de recherche n’est pas déclenché et un message d’erreur est affiché.

Image 20 : Formulaire de recherche avancée

Lorsque les données à soumettre sont valides, comme dans l’exemple ci-dessous, toutes les variables correspondantes à la recherche sont retournées. Si le nombre de variables retournées est supérieur à dix, seules les dix premières sont affichées ; le reste est mis dans un fichier qui est proposé en téléchargement à l’utilisateur.

sur 68

Image 21 : Résultat d’une recherche

On peut remarquer que toutes les variables affichées ont le même domaine et contiennent toutes les caractères « PHV ». Dans tous les cas, qu’il plus ou moins de dix

variables retournées lors de la recherche, le fichier CSV contenant tout le résultat de la recherche est proposée à l’utilisateur.

En plus des deux pages précédentes, il y a deux pages utilitaires : la première est une aide en contenant la description de chaque page de l’application et la seconde est un lien de

téléchargement permettant à l’utilisateur d’avoir, dans un fichier CSV, toutes les variables de la base de données.

Les pages décrites précédemment sont des pages accessibles par n’importe quel

utilisateur pouvant avoir accès au site. Les pages suivantes sont des pages d’administration

permettant à l’administrateur d’ajouter ou de modifier une variable dans la basse de données.

sur 68

III.8.3 La page de modification d’une variable

Avant de modifier une variable, il faut d’abord la retrouver. Pour cela, la page

permettant de modifier une variable n’est accessible qu’après avoir utilisé une page permettant de faire une recherche de variables. La page de recherche simple expliquée précédemment a été dupliquée, puis complété afin de réaliser ce nouveau traitement. Sur cette version de la page de recherche, lorsque les détails sur la variable sont affichés après la validation du formulaire, un lien redirigeant sur la page de modification est également proposé. En cliquant sur le lien, l’administrateur accède à un formulaire contenant des champs de saisies lui permettant de

rentrer les nouvelles informations. A côté de ces champs de saisies, sont réaffichés les détails sur la variable choisie précédemment. L’administrateur ne peut pas modifier le nom de la

variable, ni son domaine. Les autres champs peuvent être modifiés à volonté.

Image 23 : Page de recherche de variable avec lien de modification de cette variable.

Image 22 : Formulaire de modification d’une variable sélectionnée

sur 68

La modification de n’importe quel champ de la variable mettra à jour la description

affichée à droite dans le formulaire.

III.8. La page d’ajout d’une variable

Comme les deux pages précédentes, cette page n’est utilisable que par l’administrateur.

Elle permet de rajouter une nouvelle variable référençant un capteur, dans la base de données.

Le principe de fonctionnement est très simple. Le formulaire ne doit pas être validé à vide (aucun champ rempli). Le nom de la nouvelle variable et sont domaines sont obligatoires. Si ces conditions ne sont pas réunies, un message d’erreur est affiché à l’administrateur. Dans

le cas contraire, la nouvelle variable sauvegardée est affichée juste en dessous du formulaire d’insertion de nouvelle variable.

III.9. Bilan d’avancement du projet

Ce qui est terminé :

La sauvegarde des deux ans d’informations, la réalisation du script de sauvegarde

incrémentale, la page d’ajout de capteurs, les pages de recherche de variables, la page de

modifications des données d’une variable, un lien de téléchargement de toutes les variables, une page d’aide, les documentations utilisateurs, administrateurs et développeurs.

Ce qui n’a pas été fait :

L’amélioration de l’interface graphique, de l’ergonomie, du design.

Image 24 : Formulaire d’ajout d’une nouvelle variable

sur 68

Ce qui reste à faire :

Cartographier les capteurs, rajouter les variables externes, grapher les données d’une variable appartenant à un capteur sélectionnée sur une vue.

Au début du stage j’ai réalisé un diagramme de GANTT prévisionnel, pour les premières

tâches du stage (voir page 19). A la fin du stage, le diagramme de GANTT réel, très différent du prévisionnel, fait apparaître concrètement le temps mis pour effectuer les différentes tâches. Afin d’harmoniser le diagramme, dans la mesure où certaines tâches ont dû être reprises au moment où d’autres tâches étaient en cours, j’ai décidé de les présenter comme si elles s’étaient

déroulées séquentiellement, afin de faciliter l’interprétation du diagramme :

Image 25 : tâches réalisées

sur 68

Lorsqu’on analyse le GANTT réel et le prévisionnel, on constate de grandes

différences dues au fait que le prévisionnel a été établi sur une période de deux semaines tandis que le réel prend en compte toute la durée du stage. Les deux semaines du GANTT réel ne se sont pas déroulés comme prévu dans le prévisionnel. Ces deux semaines ont été des semaines de configuration du serveur, d’installations de logiciels, de prise en main de l’environnement de travail…Malgré cela, ces tâches auraient pu être fini plus tôt. J’ai pris

« du retard » car il a fallu refaire plusieurs fois certaines tâches, notamment la sauvegarde générale ou celle du fichier de variables. Le traitement sur le script de sauvegarde incrémentale, a quant à elle été faite jusqu’à la fin du stage ; des dernières modifications à apporter aux comportements de temps en temps. Il faut noter également qu’avec les jours de

congés et les ponts, j’ai perdu 10 jours de travail.

Image 26 : Diagramme de GANTT réel

sur 68

Conclusion

- Bilan Technique Ce stage informatique au laboratoire LAAS-CNRS m’a apporté des connaissances

techniques dans le domaine du développement web. J’ai eu à apprendre à concevoir une

application web en utilisant le paradigme MVC, paradigme utilisé jusqu’avant le début du stage dans des domaines opposés au web. J’ai eu à compléter toutes les connaissances reçues à l’iut

notamment le développement et la connexion à un serveur sous Unix.

Pour la réalisation des tâches de ce stage, je n’ai utilisée aucune méthode particulière comme les méthodes Agiles, ou le cycle en V. Les tâches ont été faites d’une manière

séquentielle : conception, implémentation, tests et documentation.

Les connaissances acquises à l’IUT au niveau du développement m’ont beaucoup aidé pour ce stage. Les matières telles que la base de données ou le php ont été des bases pour le développement que j’ai effectué durant le stage.

J’ai également pu me rendre compte de l’importance de la documentation informatique.

Il a fallu lire toute une documentation sur Symfony2 afin d’en comprendre le principe. Il a

également fallu rédiger à la fin du stage une documentation utilisateur, une documentation administrateur et une documentation développeur qui permettront de savoir comment utiliser l’application ou y rajouter de nouvelles fonctionnalités. Toutes ces documentations m’ont

permis d’améliorer ma qualité rédactionnelle.

Enfin, pour réaliser toutes ces documentations ainsi que mon rapport de stage, j’ai su

mettre en profit mes cours de communication sur les petits rapports journaliers qui permettent à la fin d’un projet d’avoir des informations logiques à utiliser pour réaliser un rapport complet

et cohérent.

- Bilan Humain Sur le plan humain, le stage m’a permis d’améliorer mon autonomie. En effet lors du

stage, il a fallu à des moments prendre des décisions ou faire des propositions. J’ai également

fait certains choix de conception afin d’avoir le plus rapidement un résultat.

Je n’ai pas pu améliorer mes qualités relationnelles car les interactions entre les acteurs du stage se faisaient en grande partie par mail, le bureau où j’effectuais le stage et celui

de ma responsable étant à des niveaux différents. Cependant les réunions d’équipes et les visite quotidiennes étaient très importantes, fréquentes et régulières afin que chacun puisse faire part de ses impressions, des problèmes rencontrés, dire ce qui ne va pas dans son travail et fixer les objectifs à atteindre dans un délai plus ou moins long.

sur 68

- Bilan Professionnel Ce stage m’a permis de préciser mon projet professionnel. Tout d’abord, intégrer une

grande organisation a été pour moi une première expérience enrichissante. En effet, je pensais que mon adaptation serait difficile du fait de nombreux concepts à intégrer. Cependant, cette dernière s’est faite naturellement, grâce à ma tutrice de stage qui m’a, dès le début, exposé le

fonctionnement de l’entreprise et le but du logiciel sur lequel je devais travailler, les différentes

commandes à exécuter pour me connecter au serveur ou à la base de données…. De plus, si

mon intégration s’est déroulée aussi bien, c’est grâce à aux administrateurs qui bien qu’étant à

distance, ont toujours pris la peine de répondre à toutes mes sollicitations.

.

sur 68

Glossaire

Ce glossaire contient tous les termes techniques employés dans ce document :

PHP : (Hypertext Preprocessor) : langage de programmation dynamique principalement utilisé pour produire des pages Web dynamiques via un serveur http.

PostgreSql : Système de gestion de base de données relationnelle

Microsoft SQL Server : Système de gestion de base de données relationnelle de Microsoft

CRON : programme qui permet aux utilisateurs des systèmes Unix d'exécuter automatiquement des scripts, des commandes ou des logiciels à une date et heure fixée

SCADA : Système de contrôle et d’acquisition des données GTB : Gestion Technique du Bâtiment

CSV : (Comma-separated values) : format de fichier informatique représentant des données tabulaires sous forme de valeurs séparées par des virgules.

Serveur HTTP : Logiciel servant des requêtes respectant le protocole de communication client-serveur HyperText Transfer Protocol (HTTP), qui a été développé pour le World Wide Web.

UML : Langage de Modélisation Unifié

sur 68

Bibliographie

Sites internet consultés :

- http://www.laas.fr/files/ADREAM/ADREAM-ProgrammeScientifique113-01-15.pdf - http://www.commentcamarche.net/contents/1080-sauvegarde-backup - http://www.laas.fr/ - http://fr.wikipedia.org/wiki/UML_%28informatique%29 - http://fr.wikipedia.org/wiki/Diagramme_des_cas_d%27utilisation

http://www.laas.fr/files/ADREAM/ADREAM-ProgrammeScientifique113-01-15.pdf

http://www.commentcamarche.net/contents/1080-sauvegarde-backup

http://www.laas.fr/

http://fr.wikipedia.org/wiki/UML_%28informatique%29

http://fr.wikipedia.org/wiki/Diagramme_des_cas_d%27utilisation

sur 68

Sommaire des annexes

I. Résumé ......................................................................................................................................... 46

II. Abstract .................................................................................................................................... 46

III. Guide administrateur du script incrémental ........................................................................ 46

IV. Documentation utilisateur de l’application web ................................................................... 51

V. Documentation administrateur de l’application AdreamData ............................................... 63

sur 68

I. Résumé J’ai effectué mon stage de deuxième année d’IUT Informatique au LAAS un laboratoire de

recherche scientifique du CNRS. Le sujet de mon stage était de dupliquer une base de données existante puis de créer une

application web permettant d’interagir avec les données de la base.

D’un point de vue technique, j’ai beaucoup appris. Mes connaissances en php se sont

améliorées. De plus, j’ai appris à utiliser le framework symfony2, et NetBeans, un environnement de développement gratuit très efficace.

D’un point de vue humain, j’ai découvert la vie d’une grande entreprise. De plus, je

travaillais dans un bureau avec mon collègue Arnaud Lods, j’étais donc en totale autonomie. J’ai également rencontré d’autres stagiaires qui travaillaient sur un projet complémentaire au mien.

II. Abstract I did my internship in second year of IUT computer science at LAAS a scientific

research of the CNRS laboratory. The subject of my internship was to duplicate an existing database and then to create a

web application to interact with the data in this database. From a technical point of view, I learnt a lot. My php skills were improved. In addition,

I learned to use the symfony2 framework, and NetBeans, a highly effective free development environment.

From a human point of view, I discovered a great corporate life. In addition, I worked

in an office with Mr Arnaud Lods, I was in total autonomy. I also met other trainees who were working on a complementary project to mine.

III. Guide administrateur du script incrémental

Introduction :

Le présent document contient l’ensemble des informations permettant aux administrateurs des systèmes d’information d’ADREAM de comprendre le processus de duplication journalière des bases de données MSSQL de PCVue vers la base de données PostgreSql fonctionnant sur le serveur Pelican, de savoir où se situe les fichiers et comment sont générés les erreurs.

Combien y a-t-il de fichiers ?

sur 68

Il y a au total huit fichiers : on trouve trois programmes portant l’extension « .php » qui contiennent l’ensemble du code permettant la sauvegarde incrémentale et cinq fichiers d’erreurs. Les fichiers d’erreurs sont générés dans un répertoire nommé Erreur.

Le fichier SauvegardeI.php contient l’algorithme qui permet les transferts de données

entre les deux bases. Les deux autres fichiers php (connexionBase.php et deconnexion.php) permettent respectivement d’ouvrir et de fermer les connexions aux bases de données. Dans le fichier connexionBase.php cité précédemment, on ouvre une connexion sur la base de données de PCVue grâce une fonction php. Le profil utilisé pour la connexion est un profil dont l’utilisateur (ici le fichier) n’a droit qu’à la lecture des informations dans la base. En cas de

suppression de ce profil, il faut renseigner les nouveaux identifiant et mot de passe dans la fonction mssql_connect.

Les cinq autres fichiers (.Txt) sont des fichiers temporaires de log générés automatiquement lors de la toute première utilisation des scripts. Ces fichiers contiennent (le temps d’exécution de chaque script) toutes les informations relatives au processus en cours, à savoir la bonne exécution ou non de chaque script. A la fin de chaque traitement, le contenu des fichiers d’erreurs est envoyé par mail à [email protected] puis le fichier est vidé.

Où se trouvent les fichiers ?

Au moment où ce document est rédigé, les six fichiers se trouvent sur le serveur Pelican, dans /data/adream-PCVue/sauvegardeI. A noter que les cinq autres fichiers de logs se trouvent eux dans /data/adream-PCVue/sauvegardeI/Erreur.

Quelles sont les différentes étapes du traitement ? Tout le processus commence d’abord par le fichier « connexion.php » (Ce fichier est inclus dans l’en-tête du programme). Dans ce fichier, on ouvre deux connexions, une pour la base MSSQL et une autre pour la base PostgreSql. On crée ensuite un fichier d’erreurs nommé

FicErreurConnexion.txt qui devra contenir toutes les erreurs survenues lors de la tentative de connexion aux bases ; ces erreurs sont les informations renvoyées par la base sur laquelle la tentative de connexion a échouée. Dans le cas où l’une des bases est inaccessible, le script

s’arrêtera automatiquement, et le contenu du fichier précédent est envoyé par mail à l’adresse

[email protected] . Ce fichier d’erreur n’est jamais formaté automatiquement, il pourra servir à retracer l’exécution du script en cas d’erreur. Il doit donc être vidé de temps en temps pour ne pas occuper trop de place sur le serveur.

Dans le cas où les deux connexions sont ouvertes sans problèmes, on rentre directement dans le « corps » du script qui est soit le fichier. Un fichier d’erreur est généré. Dans le cas

d’exemple sur les données CVC, ce fichier s’appellera FicErreurCvC.txt. Ce fichier devra contenir l’heure du début du script, les erreurs levées par les bases lors des différentes requêtes, le nombre cumulé de lignes insérées par requêtes, le nombre d’erreurs par banc de requêtes,

l’heure à laquelle le script a arrêté de s’exécuter.

On effectue dans un premier temps une requête afin de récupérer le dernier Chrono qui a été inséré dans la base de données mssql CNRS_DATA_CVC au moment où le script a été

mailto:[email protected]

sur 68

lancé. Ce chrono sera le chrono de référence (Chrono1), donc la condition d’arrêt de notre

script.

Ensuite, on récupère dans la table CVC dans la base PostgreSQL le plus grand chrono. Ce chrono correspond à la dernière ligne insérée dans la base lors de la dernière sauvegarde. Or il se trouve qu’il existe plusieurs occurrences de ce dernier chrono avec des noms de variables

différents. Ce qui rend dans ce cas l’identification de la véritable dernière ligne insérée

impossible, étant donné que la base de données trie les informations.

Pour résoudre le problème précédent, on récupère quand même ce dernier chrono (Chrono2) puis on supprime toutes ses occurrences dans la table CVC (Pour réaliser cette opération de suppression, la base de données doit être accédée avec les droits d’administrateur

ou un profil permettant au script de faire des suppressions et des insertions. Dans le cas où le profil actuel (ierase) est supprimé, il faut obligatoirement renseigner les nouvelles informations (nom du profil, mot de passe) dans le fichier « connexion.php » plus précisément dans les paramètres de la fonction pg_connect).

Après cette suppression, on effectue une nouvelle requête sur la base de données mssql, précisément dans cet exemple la base CNRS_DATA_CVC. On récupère les 50000 lignes contenant les chronos supérieurs ou égale au Chrono2. La requête peut ramener moins de lignes en fonction des informations présentes dans la base. On insère les lignes récupérées dans la table CVC. On recommence alors le traitement qui consiste à récupérer le dernier plus grand chrono (Chrono2), à supprimer ce chrono, à requêter la base mssql avec le Chrono2 comme condition de départ…jusqu’à ce que le chrono de référence (Chrono1) soit atteint ou dépassé.

Lorsqu’on sort de la boucle de requêtes, on a alors le plus grand Chrono dans la table

CVC qui est égal ou supérieur au chrono de référence récupéré plus haut. On rentre alors dans le fichier de déconnexion, on ferme les connexions aux bases de données, aux fichiers, puis on envoie le contenu des fichiers d’erreurs par mail, puis on tronque le fichier.

Cet algorithme nous permet d’avoir, si le script est lancé chaque jour, un jour de

différences d’informations entre les différentes bases.

sur 68

Illustrons ces explications par un court et schéma et un pseudo-code :

Algorithme en pseudo-code :

Le pseudo-code ci-après ne fait pas apparaître les différents tests effectués.

Figure 4: Vue générale du traitement effectué.

sur 68

//fichier connexion.php DEBUT 1.Ouverture de connexion mssql en lecture 2. Ouverture de connexion postgreSql avec un compte administrateur 3. Création du fichier d''erreur qui devra contenir les différentes erreurs lors de la tentative de connexion 4. On rentre dans le fichier principal grâce au mécanisme d''inclusion de fichiers //fichier principal : ex SauvegardeIncrementaleCVC.php 5. On crée un nouveau fichier txt permettant de récupérer les erreurs lors des traitements suivants ChronoDeReference <- max(Chrono) dans base mssql Répéter { DernierChronoCVC <- max(Chrono) dans la table CVC 6.On supprime toutes les occurences de ce Chrono

NouvellesLignes <- 50 000 Chrono >= DernierChronoCVC dans base mssql

Tq (NouvellesLignes non vide) { 7.Insertion dans la table cvc } } Jusqu’à (DernierChronoCVC>=ChronoDeReference) //fichier deconnexion.php 8. fermeture de toutes les connexions 9. envoie des contenus du fichier d''erreur par mail FIN

sur 68

Traitements spéciaux

Le script a été implémenté pour se relancer automatiquement lorsque la base de données MSSQL ne répond pas après 100 requêtes échouées, puis s’arrêter après dix relances. Pour lancer le script, il faut exécuter la commande suivante : php SauvegardeI.php nomTableEnMajuscule 0. Le 0 est le nombre de relance ; à chaque fois que le script se relance, ce nombre est incrémenté. A 10, le script s’arrête, et un message d’erreur est envoyé à

l’administrateur.

Que faire en cas d’erreurs ?

En cas d’erreurs, il faut lire attentivement le contenu du mail envoyé à la fin du script. Le contenu du mail permet de déterminer avec précision la source de l’erreur: si l’erreur

provient du script lui-même, de la base mssql ou de la base PostgreSQL. Cependant, il sera rare qu’une erreur provienne du script lui-même.

Il faut juste retenir qu’en cas d’erreur lors de l’exécution du script, les erreurs seront

mentionnées dans les mails envoyés, ce qui implique qu’il faut contrôler ces mails tous les jours. Dans le cas où aucun mail n’est reçu, il faut exécuter le script manuellement en ligne de

commande (php nomduScript.php). Si aucune erreur n’est levée, il faut dans ce cas, vérifier la

configuration du serveur.

On peut également contrôler l’exécution du script grâce au fichier FicErreurConnexion.txt. Ce fichier contient la date de début, la date de fin, et les erreurs de connexion lors de l’exécution du script.

Comment exécute-t-on le script à la main ?

Il suffit juste de taper la commande « php nomDuScript.php nomTableEnMajuscule 0 » dans l’invite de commande du le répertoire courant des fichiers.

Comment mettre le script dans la crontab ?

Pour exécuter un fichier php automatiquement grâce à la crontab, il faut la commande php : 30 7 * * * php /repertoireScript/SauvegardeI LUMINAIRE 0 pour l’exécution par

exemple de ce script pour la table LUMINAIRE tous les 7h30 du matin.

IV. Documentation utilisateur de l’application web

Cette documentation, très complète fait également apparaître les autres pages développées par le binôme.

sur 68

DOCUMENTATION UTILISATEUR Application AdreamData

sur 68

REQUÊTAGE DE DONNEES

A quoi sert-il ? Ce formulaire vous permet de requêter la base de données afin de récupérer les différentes valeurs contenues dans celle-ci pour un domaine sélectionné entre deux dates distinctes.

Il est par ailleurs possible de limiter le champ de recherche à une variable précise ou à un ensemble de variables.

Remplissage du formulaire Les champs obligatoires Plusieurs champs sont obligatoires dans ce formulaire.

Date de début : ce champ correspond à la date à partir de laquelle vous souhaitez récupérer les données dans la base de données. Par défaut, les heures, les minutes et les secondes sont à 0, et la date correspond à celle de la veille.

Date de fin : ce champ correspond à la date où l’on récupèrera la dernière donnée. Par défaut, les

heures, les minutes et les secondes sont à 0, et la date correspond à celle du jour.

Domaine : ce champ correspond au domaine sur lequel vous voulez effectuer la requête. 4 domaines sont disponibles : Photovoltaïque, Luminaire, Electrique et Chauffage Ventilation Climatisation (CVC).

sur 68

Les champs optionnels Variable : ce champ permet de limiter la recherche de données à une ou plusieurs variables. Si vous souhaitez rechercher par variable, alors il faut cocher la case correspondante ‘Par variable’. Le cas échéant, la recherche récupèrera les données de toutes les variables contenant la chaîne de caractères rentrée dans le champ. Si vous avez rentré le nom complet de la variable et souhaitez uniquement rechercher celle-ci, alors il suffit de cocher la case ‘Ceci est le nom complet de la variable’.

Nb : il n’est pas nécessaire de respecter la casse. (Ex : si votre variable s’appelle

‘CNRS.RDC.puissance’, saisir ‘cnrs.rdc.puissance’ récupèrera correctement la variable)

Récupération du résultat Après avoir saisi votre formulaire, il vous suffit d’appuyer sur le bouton ‘Rechercher’. Si le formulaire

est correctement rempli, alors deux cas se présenteront à vous :

Aucune donnée n’a été trouvée avec les paramètres de votre recherche, un message s’affichera

Votre recherche a retourné une ou plusieurs lignes. Suivant votre navigateur, le fichier ce téléchargera directement ou un pop-up apparaîtra pour vous permettre de télécharger ou d’ouvrir directement le fichier. Il vous suffit alors de faire votre choix pour récupérer le fichier .csv contenant toutes les données récupérées.

Exemple de contenu d’un fichier .csv généré après une recherche

sur 68

RECHERCHE DE PROBLEMES

A quoi sert-il ? Ce formulaire vous permet de requêter la base de données afin de rechercher les problèmes pour un – ou tous – domaine en fonction de la date d’apparition et/ou de résolution du problème.

Remplissage du formulaire Les champs obligatoires Domaine : ce champ correspond au domaine sur lequel vous voulez effectuer la requête. 6 domaines sont disponibles : Tous les domaines, Photovoltaïque, Luminaire, Electrique, Chauffage Ventilation Climatisation (CVC) et PCVue.

Au moins un champ date doit être rempli.

Les champs optionnels Problème apparu avant : ce champ permet de rechercher tous les problèmes dont la ‘date de début’ du problème est antérieure à celle saisie.

Problème apparu après : ce champ permet de rechercher tous les problèmes dont la ‘date de début’ du problème est postérieure à celle saisie.

Problème résolu avant : ce champ permet de rechercher tous les problèmes dont la ‘date de fin’ du

problème est antérieure à celle saisie

Problème résolu après : ce champ permet de rechercher tous les problèmes dont la ‘date de fin’ du

problème est postérieure à celle saisie

sur 68

Récupération du résultat Après avoir saisi votre formulaire, il vous suffit d’appuyer sur le bouton ‘Rechercher’. Si le formulaire

est correctement rempli, alors deux cas se présenteront à vous :

Aucune donnée n’a été trouvée avec les paramètres de votre recherche, un message s’affichera

Votre recherche a retourné une ou plusieurs lignes. Suivant votre navigateur, le fichier se téléchargera directement ou un pop-up apparaîtra pour vous permettre de télécharger ou d’ouvrir directement le fichier. Il vous suffit alors de faire votre choix pour récupérer le fichier .csv contenant toutes les données récupérées.

Exemple de contenu d’un fichier .csv généré après une recherche

sur 68

CREATION DE GRAPHES

A quoi sert-il ? Ce formulaire vous permet de créer un graphe contenant une – ou deux – courbe(s) représentant les données d’une – ou deux – variable(s) présentes dans la base de données pour un intervalle de temps saisi.

Remplissage du formulaire Les champs obligatoires Date de début : ce champ correspond à la date à partir de laquelle vous souhaitez récupérer les données dans la base de données. Par défaut, les heures, les minutes et les secondes sont à 0, et la date correspond à celle de la veille.

Date de fin : ce champ correspond à la date où l’on récupèrera la dernière donnée. Par défaut, les heures, les minutes et les secondes sont à 0, et la date correspond à celle du jour.

Domaine : ce champ correspond au domaine sur lequel vous voulez effectuer la requête. 4 domaines sont disponibles : Photovoltaïque, Luminaire, Electrique et Chauffage Ventilation Climatisation (CVC).

Variable1 : ce champ correspond à la première variable dont vous voulez récupérer les données afin de créer le graphe. Le nom de la variable doit être complet pour correspondre à celui présent dans la base de données.



Les champs optionnels Variable2 : ce champ correspond à la première variable dont vous voulez récupérer les données afin de créer le graphe. Le nom de la variable doit être complet pour correspondre à celui présent dans la base de données.



sur 68

Récupération du graphe Après avoir saisi votre formulaire, il vous suffit d’appuyer sur le bouton ‘Créer le graphe’. Si le

formulaire correctement rempli, alors deux cas se présenteront à vous :

Aucune donnée n’a été trouvée pour la variable1 avec les paramètres de votre recherche, un

message s’affichera alors

La requête a retourné une ou plusieurs lignes pour la variable1 au moins, dans ce cas-là le graphe créé sera affiché

Nb : si le nombre de données dépasse 150.000 pour une variable ou 200.000 pour deux variables (100.000 / variable) alors la création du graphe se limitera à ces 100.000 / 150.000 premières variables pour éviter de dépasser les capacités de création de celui-ci.

Imprimer le graphe Pour imprimer le graphe, il vous suffit de cliquer – ou d’effectuer un double-clic suivant votre navigateur – sur celui-ci. Un pop-up apparaîtra vous permettant de sélectionner les paramètres de l’impression – de même, la forme et les options d’impression varient selon les navigateurs.

sur 68

Note : pour une impression optimale, réglez l’impression sur ‘Paysage’.

Télécharger le graphe Pour télécharger le graphe (format .png), il vous suffit de cliquer droit sur l’image et de sélectionner

‘Enregistrer l’image sous’, puis de nommer le fichier et choisir le dossier de destination.

sur 68

DETAILS D’UNE VARIABLE

A quoi sert-il ? Ce formulaire contenant une unique liste déroulante permet à l’utilisateur d’obtenir toutes les

informations concernant une variable, c’est-à-dire son domaine, sa description et son unité. Cela suppose que l’utilisateur connaît le nom de la variable (l’auto-complétion facilite la recherche de la variable).

Remplissage du formulaire Les champs obligatoires L’unique champ présent doit être rempli avec le nom d’une variable complète et correct. L’auto-complétion permet à l’administrateur de chercher plus facilement une variable tout en lui permettant

d’en vérifier son existence.

Récupération du résultat Après la soumission du formulaire, un tableau détaillant la variable apparaît.

sur 68

RECHERCHE DE VARIABLES

A quoi sert-il ? Ce formulaire permet de retrouver toutes les variables pour un domaine – Photovoltaïque, Electrique, Chauffage Ventilation Climatisation, Luminaire ou Autres. Il permet aussi de rechercher en fonction du nom, de la description, de l’unité ou de la room des variables afin de limiter le champ de recherche et

les résultats.

Remplissage du formulaire Les champs obligatoires Domaine : ce champ, correspondant au domaine de la variable (Photovoltaïque, Electrique, Luminaire, Chauffage Ventilation Climatisation, Autres).

Les champs optionnels Nom : ce champ correspond au nom de la variable. Il peut correspondre au nom complet de la variable, ou alors à une partie de celui-ci (ex : si CNRS est rentré, alors on recherchera toutes les variables dont le nom contient la chaîne CNRS).

Room : ce champ correspond au lieu précis du bâtiment dans lequel le capteur renvoyant cette variable est situé.

Description : ce champ correspond à la description de la variable. Il peut correspondre à la description complète de celle-ci, ou à une partie (même principe que Nom).

Unité : ce champ correspond à l’unité de la variable.

sur 68

Récupération du résultat Le résultat de la recherche est affiché dans un tableau. Si celle-ci a retourné plus de 10 lignes, seules les 10 premières lignes seront affichées. Dans tous les cas, le résultat de celle-ci peut être téléchargé sous forme d’un fichier CSV en cliquant sur le lien situé sous la table.

sur 68

V. Documentation administrateur de l’application

AdreamData

AJOUT DE PROBLEMES

A quoi sert-il ? Ce formulaire permet d’ajouter un nouveau problème dans la base de données suivant les informations saisies.

Remplissage du formulaire Les champs obligatoires Démarré le : ce champ correspond à la date d’apparition du problème. Par défaut, les heures, les minutes

et les secondes sont à 0.

Domaine : ce champ correspond au domaine concerné par le problème. 6 domaines sont possibles : Tous les domaines, Photovoltaïque, Electrique, Luminaire, Chauffage Ventilation Climatisation (CVC) et PCVue.

Equipement concerné : ce champ correspond au nom de l’équipement concerné par le problème que

vous souhaitez ajouter.

Description : ce champ correspond à la description du problème. Vous pouvez agrandir la fenêtre d’insertion.

Les champs optionnels Résolu le : ce champ correspond à la date à laquelle le problème rentré a été résolu. Si celui-ci a été résolu, il est nécessaire de cocher la case ‘Résolu le’ afin d’ajouter correctement la date de résolution –

sur 68

ainsi que le chrono – dans la table des problèmes. Par défaut, les heures, les minutes et les secondes sont à 0, et la date correspond à celle du jour.

Solution : ce champ permet de décrire la solution utilisée pour résoudre le problème. Ce champ peut être saisi indépendamment du champ ‘Résolu le’ et sera inséré dans la base de données même si ce dernier n’est pas coché. Vous pouvez agrandir la fenêtre d’insertion.

MODIFICATION DE PROBLEMES

A quoi sert-il ? Ce formulaire permet de mettre à jour un problème présent dans la base de données qui n’était pas encore résolu ; c’est-à-dire dont la date de résolution n’avait pas été indiquée précédemment.

Il reprend les données insérées précédemment dans la base de données pour le problème sélectionné et permet de modifier les différentes données insérées (description, équipement concerné, solution …).

Remplissage du formulaire Les champs obligatoires Démarré le : ce champ correspond à la date d’apparition du problème. Par défaut, il correspond à la

date précédemment saisie du problème.

Domaine : ce champ correspond au domaine concerné par le problème. 6 domaines sont possibles : Tous les domaines, Photovoltaïque, Electrique, Luminaire, Chauffage Ventilation Climatisation (CVC) et PCVue.

sur 68

Equipement concerné : ce champ correspond au nom de l’équipement concerné par le problème que vous souhaitez ajouté.

Description : ce champ correspond à la description du problème. Vous pouvez agrandir la fenêtre d’insertion.

Les champs optionnels Résolu le : ce champ correspond à la date à laquelle le problème rentré a été résolu. Si celui-ci a été résolu, il est nécessaire de cocher la case ‘Résolu le’ afin d’ajouter correctement la date de résolution

dans la table des problèmes. Par défaut, les heures, les minutes et les secondes sont à 0, et la date correspond à celle du jour.

Solution : ce champ permet de décrire la solution utilisée pour résoudre le problème. Ce champ peut être saisi indépendamment du champ ‘Résolu le’ et sera inséré dans la base de donnée même si ce

dernier n’est pas coché. Vous pouvez agrandir la fenêtre d’insertion.

DETAILS D’UNE VARIABLE

A quoi sert-il ? Cette liste déroulante permet à l’utilisateur d’avoir toutes les informations sur une variable à savoir son

domaine, sa description et son unité. Cela suppose que l’administrateur connaît le nom de la variable.

Ce formulaire est une étape nécessaire afin d’accéder à celui de Modification de variables. En effet il

permet de sélectionner la variable qui sera modifié.

Remplissage du formulaire Les champs obligatoires L’unique champ présent doit être rempli avec le nom d’une variable complète et correct. L’auto-complétion permet à l’administrateur de chercher plus facilement une variable tout en lui permettant

d’en vérifier son existence.

sur 68

Récupération du résultat Après la soumission du formulaire, un tableau détaillant la variable apparaît, proposant un lien permettant de modifier celle-ci grâce à un second formulaire.

MODIFICATION D’UNE VARIABLE

A quoi sert-il ? Ce formulaire permet à l’administrateur de faire des modifications sur une variable sélectionnée précédemment. Il ne peut cependant modifier ni le nom de la variable, ni son domaine. Lorsqu’une

information n’est pas présente – par exemple l’unité sur l’image ci-dessus – la description du champ correspond à « Aucune », et doit donc être si possible renseignée.

Remplissage du formulaire Les champs obligatoires Tous les champs présents dans ce formulaire sont optionnels.

Les champs optionnels Unité : ce champ permet de rentrer l’unité de la variable (ex : C, VA, W…).

sur 68

Room : ce champ correspond au lieu précis du bâtiment dans lequel le capteur renvoyant cette variable est situé.

Description : ce champ permet de rentrer la description de la variable.

Capteur : ce champ permet de rentrer le nom du capteur auquel est associée la variable.

Si aucun de ces précédents champs n’est rempli lors de la validation du formulaire, alors aucune

modification n’est apportée à la variable.

Si un champ, précédemment renseigné, est ici vide lors de la validation du formulaire, alors il n’est pas

modifié.

AJOUT D’UNE VARIABLE

A quoi sert-il ? Ce formulaire permet à l’administrateur de rajouter une variable référençant un capteur.

Remplissage du formulaire Les champs obligatoires Variable : ce champ correspond au nom de la variable à ajouter dans la base de données.

Domaine : ce champ prend les initiales du domaine de la variable. Tant que ce champ n’est pas

correctement rempli, le formulaire n’est pas validé.

Les initiales valides sont respectivement :

C : Chauffage, Ventilation, Climatisation L : Luminaire

P : Photovoltaïque A : Autres

E : Electrique

sur 68

Les champs optionnels Room : ce champ correspond au lieu précis du bâtiment dans lequel le capteur renvoyant cette variable est situé.

Description : ce champ correspond à la description de la variable.

Unité : ce champ correspond à l’unité de la variable (ex : C, VA, W…).

Rapport de stage (du 14 Avril au 23 Juin 2014)kosted.free.fr/pdf/rapport.pdf · 2015. 9. 7. ·...

Documents

Transcript of Rapport de stage (du 14 Avril au 23 Juin 2014)kosted.free.fr/pdf/rapport.pdf · 2015. 9. 7. ·...