Conception et réalisation d'un système de contrôle du centre de données

Année Universitaire : 2016/2017

RÉPUBLIQUE TUNISIENNE

*********** MINISTERE DE L'ENSEIGNEMEMT SUPÉRIEUR ET DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE

UNIVERSITÉ DE SFAX FACULTÉ DES SCIENCES DE SFAX **************** DÉPARTEMENT INFORMATIQUE ET DES COMMUNICATIONS

RAPPORT DE STAGE DE FIN D'ÉTUDES

Pour l'obtention du diplôme:

LICENCE APPLIQUÉE EN RÉSEAU INFORMATIQUE

Sujet:

Conception et réalisation d'un système de contrôle du
centre de données

Organisme d'accueil:
SOCOMMI
Elaboré par:

Imen BOUAZIZI et Abir MBAREK

Soutenu le 30/05/2017 devant le jury:
Mme.	Dorsaf	ZEKRI	Maître Assistant	FSS	Président
Mme.	Lamia	TOUNSI	Maître Assistant	FSS	Rapporteur
M.	Mohamed Ali	HADJ TAIEB	Maître Assistant	FSS	Encadrant
M.	Omar	IDRIS	Ingénieur	SOCOMMI	Encadrant Industriel

1

2

3

Dédicaces

C'est grâce a Dieu que tout a commencé, et c'est à lui que je rends grâce. Le reste n'est que dédicaces.

A l'esprit de Ma très chère Mère.

A l'homme de ma vie, mon exemple eternel, mon soutien moral et source de joie et de bonheur à Mon Amour Papa.

Aux personnes dont j'ai bien aimé leur présence dans ce jour, a Ma Famille, Mes Cousines, Mes Tantes, et Mes grands Mères, je dédie ce travail dont le grand plaisir leurs revient pour leurs amours et soutient.

4

Dédicaces

Je dédie ce modeste travail.

A ma mère, à ma chère Mère.

La personne que j'ai de plus précieuse et de plus chère. Que ce projet soit une occasion pour t'adresser mes vifs remerciements et pour exprimer ma reconnaissance pour tes nombreuses années de sacrifices, ton éternelle patience et ta grande tendresse. A mon père j'espère que ce travail soit la réalisation d'un de tes rêves.

A toutes les familles, vous m'avez toujours encouragée par votre amour et vos prières incessantes. Je vous dédie ce projet en témoignage de mon profond respect et mon grand attachement.

A tous ceux qui comptent pour moi ...

BOUAZIZI Imen.

5

6

Remerciements

C'est avec un grand plaisir que nous réservons cette page en signe de gratitude et de profonde reconnaissance à tous ceux qui nous ont aidés et ont contribué de près ou de loin à la réalisation de ce travail.

Nous tenons à remercier vivement notre encadreur,

M. Mohamed Ali Hadj Taieb maître assistant à la faculté des sciences, qui n'est pas épargne le moindre effort dans l'encadrement de ce projet. Nous le remercions pour ses conseils judicieux, ses encouragement et pour l'aide qu'il nous a accordé.

Nous tenons à présenter nos reconnaissances et nos remerciements aux membres de jury Mme Dorsal ZEKRI et Mme Lamia TOUNSI d'avoir accepté d'examiner notre travail.

Au terme de ce projet, nous souhaitons remercier M. Abes Mansouri, le directeur général de la société SOCOMMI, et M. Omar Driss notre encadreur industriel, et notamment tout le personnel de SOCOMMI pour leur accueil chaleureux et leur esprit de collaboration.

Nous exprimons finalement notre profonde gratitude à tout le personnel et les enseignants de la Faculté des Sciences de Sfax pour leurs efforts qui les on déployés durant toute les années universitaires, spécialement au département informatique.

7

8

9

Sommaire

Introduction générale 16

Chapitre1 19

Présentation générale du projet et spécification des besoins 19

I. Introduction 20

II. Présentation de l'organisme d'accueil 20

1. Présentation de la société SOCOMMI 20

2. Centre de données 21

III. Contexte du projet 21

1. Cadre général du projet 21

2. Problématiques et motivations 22

3. Solution proposée 22

4. Cahier des charges 23

IV. Les besoins attendus de l'application 23

1. Besoins fonctionnels 23

2. Besoin non fonctionnel 24

V. Diagramme de Gantt 24

VI. Conclusion 25

Chapitre 2. Technologies mises en oeuvre 26

I. Introduction 27

II. Environnement matériel 27

1. La Carte raspberry pi 27

2. Capteur telos 30

III. Environnement logiciel et langages utilisés 32

1. Raspbian OS 32

2. Contiki/Cooja 32

3. Outil de développement ANDROID STUDIO 34

4. XML 34

5. Java 34

6. Python 34

7. PHP 35

8. MySQL 35

9. Apache 35

10

IV. Le réseau de capteurs 35

1. Couche physique 36

2. La couche d'accès au médium (MAC) 36

5. Connexion entre les capteurs 38

V. Le Cloud : UBIDOTS 38

Chapitre 3. Etude conceptuelle 42

I. Introduction 44

II. L'architecture logicielle 45

III. Les diagrammes de cas d'utilisation 46

1. Description 46

2. Identification des acteurs 46

3. Diagramme de cas d'utilisation 47

IV. Etude dynamique : les diagrammes de séquences 50

1. Description 50

2. Diagramme de séquences « authentification » 51

3. Diagramme de séquences «Consulter les courbes». 52

4. Diagramme de séquence « Consulter réclamation » 53

V. Diagramme de classes 56

VI. Conclusion 57

Chapitre 4 : Réalisation 59

I. Introduction 60

II. Etape 1 : Collection des données : La simulation Contiki /Cooja 60

III. Etape 2 : Raspberry : réception et envoie des données 63

IV. Etape 3 : la connexion entre le Raspberry et le Cloud 64

V. Etape 4 : Codage et transmission de données à partir de l'application Android 65

1. Protocol et format de données 65

2. Description des interfaces de l'application Android 67

VI. Etape 5: Interprétation graphique des données collectées par l'application web 70

VII. Conclusion 75

Conclusion 76

11

Liste des figures

Figure 1: Plan SOCOMMI 21

Figure 2: Architecture de la solution proposée 23

Figure 3: Diagramme de Gantt du projet 25

Figure 4: Environnement matériel 27

Figure 5: RPI modèle B 28

Figure 7: Connectivité du Raspberry avec les périphériques 30

Figure 8: Echantillon des capteurs TELOS 30

Figure 10: Les capteurs Tmote Sky (TelosB) 31

Figure 11: Environnement logiciel 32

Figure 12: Architecture réseau du standard 6LoWPAN 37

Figure 13: Adaptation d'IPv6 par le standard 6LoWPAN 38

Figure 14: Le cloud 39

Figure 15: L'infrastructure as a Service (IaaS) 39

Figure 16: La couche PaaS 40

Figure 17: Logicielle as a service (SaaS) 40

Figure 18: architecture trois tiers 45

Figure 19: Diagramme de cas d'utilisation général 47

Figure 20: Diagramme de cas d'utilisation pour l'application web 49

Figure 21: Diagramme de cas d'utilisation pour l'application Android 50

Figure 22: Diagramme de séquence « authentification » 51

Figure 23: diagramme de séquences « consulter courbe » 52

Figure 24: Diagramme de séquence « Consulter réclamation » 53

Figure 25: Diagramme de séquences « ajouter superviseur » 54

Figure 26: diagramme de séquences « modifier superviseur » 55

Figure 27: diagramme de séquence « supprimer superviseur » 56

Figure 28: Diagramme de classes de l'application 57

Figure 29: Interface Cooja 61

Figure 30: les valeurs de sensors température et luminosité 62

Figure 31: Principe de la simulation du réseau 62

Figure 32: Passage entre les différentes parties par le Gateway Raspberry 63

Figure 33: connexion entre LBR et Raspberry 63

Figure 34: Interface Cloud 65

Figure 35: listes ordonnées sous format JSON 66

Figure 36: l'utilisation du Protocol HTTP et format de données JSON 66

Figure 37: Interface d'authentification du superviseur 67

Figure 38: Interface d'accueil de l'application Android 68

Figure 39: Interface de la supervision des états 68

Figure 40: Interfaces de supervision des graphes 69

Figure 41: Processus d'envoie de réclamation 69

Figure 42: Interface « passer reclamation » 70

12

Figure 43: Interface d'accueil pour l'application web 71

Figure 44: Formulaire d'ajout d'un nouveau superviseur 72

Figure 45: Formulaire de mise à jour d'un superviseur 72

Figure 46: Formulaire d'ajout d'un nouveau capteur 73

Figure 47: Formulaire de mise à jour d'un capteur 73

Figure 48: Historique 74

Figure 49: Consulter réclamation 74

13

14

Liste des tableaux

Tableau 1: Spécifications techniques des modèles des raspberry "famille B" 29

Tableau 2: Caractéristiques des capteurs les plus courants 30

15

16

Introduction générale

Quotidiennement, toutes les entreprises ayant une diversité des moyennes de supervision pour réduire les pannes et les défaillances dans leur centre de données qui peuvent causer des pertes considérables de données. Mais la plupart des ces solutions reste locale et insuffisante pour assurer les bons fonctionnements des différents équipements

Pour cela il faut chercher des nouvelles solutions de supervision en temps réel c'est-à-dire être servi en tout lieu et à tout moment, non seulement à travers des systèmes de gestion locale.

En effet, nous essayons d'utiliser plusieurs technologies permettant la supervision à distance pour assurer le bon fonctionnement des activités et vérifier l'état des différents équipements d'une manière plus simple. L'objectif est de concevoir et développer une solution permettant de rapporter et alerter suite aux fonctionnements anormaux des systèmes informatiques en cas de problèmes.

D'où l'intérêt du notre projet de fin d'études intitulé « Conception et réalisation d'un système de gestion d'un centre de données.

Ce projet a pour but donc de contrôler l'état d'un centre de données. Ceci inclut le domaine de la « IOT: Internet of things, » », les techniques d'automatisme, d'informatique et de la télécommunication qui à travers lesquels il rend possible de contrôler et de commander des systèmes à distance en ayant recours au réseau Internet.

Pour ce faire, nous divisons notre travail en quatre chapitres :

Dans le premier chapitre, intitulé «Présentation générale du projet et spécification des besoins», nous présentons la société au sein de laquelle le projet a été réalisé «SOCOMMI». Puis nous définissons la problématique, et nous identifions les objectifs à atteindre. Finalement, nous traçons les grandes lignes de la solution.

Le deuxième chapitre, intitulé « Technologies mises en oeuvre», présente les différentes technologies mises en oeuvre toute en détaillent les outils matériels et logiciels que nous avons utilisés dans la réalisation de notre projet.

Le troisième chapitre, intitulé « Étude conceptuelle», commence par une description de la méthode agile que nous avons suivie avec les différents diagrammes des cas d'utilisation et les diagrammes de séquences correspondant. Après, nous présentons les diagrammes de classes.

17

Dans le dernier chapitre, intitulé «Réalisation», nous présentons la partie réalisation de notre travail, à travers les interfaces développées pour mettre en oeuvre les fonctionnalités demandées.

Nous clôturons enfin par une conclusion et des perspectives.

18

19

Chapitre1

Présentation générale du projet et

spécification des besoins

I. 20

Introduction

Dans ce chapitre, nous donnons une brève description de la société d'accueil dans laquelle nous avons effectué notre projet. Par la suite, nous expliquons les différentes notions en rapport avec le sujet et ses objectifs ainsi nous posons la problématique et la solution envisagée. Enfin, nous présentons les services attendus de notre application.

II. Présentation de l'organisme d'accueil 1. Présentation de la société SOCOMMI

« SOCOMMI » est une société de construction métallique et maintenance industrielle.

Elle fournit une gamme de services couvrant les différents secteurs suivants :

· Mécanique

· Électrique

· Maintenance industrielle

· Construction métallique.

Les services sont fournis essentiellement dans les activités de l'industrie pétrolière et de gaz.

Les services principaux de cette société sont les suivants :

· La gestion des projets

· L'ingénierie

· La gestion des achats

· La construction métallique (soudure, chaudronnerie, tuyauterie, charpente,...) ;

· La maintenance industrielle

· Le domaine d'intervention de la société est le suivant :

· Les gisements du pétrole et de gaz

· Les usines de ciment

· Les usines de traitement d'eau

· Les unités industrielles

· Les unités minières et chimiques

· Pré-mise et mise en service, et démarrage

·

21

Les installations de gaz dans les domaines industriels

· Les installations électriques dans les domaines industriels

· Les ouvrages de transports des hydrocarbures liquides par canalisation La société contient un centre de données pour stoker leur informations comme il est présenté dans la figure suivante :

Figure 1: Plan SOCOMMI

2. Centre de données

Un centre de données se présente comme un lieu où se trouvent différents équipements électroniques (ordinateurs, des équipements de télécommunications, des systèmes de stockage, des serveurs, etc.). Il permet de stocker les informations nécessaires aux activités d'une entreprise. Il comprend en général un contrôle sur des enjeux environnementaux qui sont liés à la température, l'humidité, luminosité, énergie et l'incendie du centre de données.

III. Contexte du projet

1. Cadre général du projet

Ce projet est réalisé dans le cadre de la préparation du projet de fin d'études en vue de l'obtention du diplôme de licence en Réseaux Informatiques de la Faculté des Sciences de Sfax.

Notre stage a été effectué au sein de la société SOCOMMI à Sfax. L'encadrement à été assuré par M. Mohamed Ali Hadj Taieb, maître assistant à la Faculté des Sciences de Sfax, et M. Omar Driss, ingénieur à SOCOMMI.

2. 22

Problématiques et motivations

Des enjeux environnementaux sont liés à la consommation d'électricité des centres de données, et à leur coproduit qu'est la chaleur dissipée par les serveurs et les systèmes de stockage en particulier.

Pour superviser un centre de données, il faut que l'agent soit toujours présent à l'intérieur de la salle de contrôle. Ainsi qu'un manque des outils de supervision et les méthodes de supervision ne sont plus modernes (solution de câblage filaire et l'information sera plus transmise en temps réel).

3. Solution proposée

La solution consiste à automatiser la gestion et la supervision dans un centre de donnés.

Nous allons présenter le système global d'un point de vue macroscopique. En fait, un réseau de capteurs sans fils programmables pour récupérer les valeurs de température au niveau des racks, humidité, luminosité, énergie, et flamme. Toutes ces variables jouent le rôle principal au niveau de la supervision et la protection d'un centre de données, ensuite les données récupérées sur la passerelle Raspberry Pi (Gateway) vont être transmises vers notre serveur CLOUD (Ubidots) pour que l'application Android puisse achever ces valeurs en temps réel et les afficher pour l'agent sous différentes formes (graphes, valeurs...).

Donc, nous réalisons une application Android pour la supervision et une application web pour l'administration du système de gestion du centre de données.

23

Figure 2: Architecture de la solution proposée

4. Cahier des charges

.

L'objectif du stage est de concevoir un système de supervision de centre des données permettant à l'entreprise un contrôle sur l'environnement en temps réel, permanent et assez simple. Nous décrivons également le sujet qui nous a été confié, les méthodologies adoptées, et les besoins attendus

IV. Les besoins attendus de l'application

La spécification de besoins constitue la phase de départ de toute application à développer dans laquelle nous allons identifier les besoins de notre application. Nous distinguons des besoins fonctionnels qui présentent les fonctionnalités attendues de notre application et les besoins non fonctionnels pour éviter le développement d'une application non satisfaisante ainsi de trouver un accord commun entre les spécialistes et les utilisateurs pour réussir le projet.

Nos applications doit fournir à la fois des fonctionnalités pour l'administrateur et pour le superviseur.

1. Besoins fonctionnels

Les besoins fonctionnels ou besoins métiers représentent les actions que le système doit exécuter. En fait, il ne devient opérationnel que s'il les satisfait. L'application web doit permettre :

· L'accès et identification.

· Supervision des états.

· Supervision des graphes.

· Gestion des superviseurs.

·

24

Gestion des capteurs.

· Consulter les réclamations. L'application Android doit permettre :

· L'accès et identification.

· Supervision des états.

· Consulter courbes.

· Passer réclamation.

2. Besoins non fonctionnels

Les besoins non fonctionnels présentent les exigences internes pour le système et cachées vis à vis les superviseurs. Notre application doit être facile à utiliser et elle doit garantir un temps de réponse court.

Les principaux besoins non fonctionnels de notre application se résument dans les points suivants :

La sécurité des données : sécuriser les données revient à appliquer une stratégie d'identification (par login), d'authentification (par password), l'autorisation et contrôler chaque tentative d'accès à ces données. Dans notre système l'accès aux informations personnelles n'est autorisé qu'aux personnes propriétaires et selon un privilège qui détermine les droits d'accès.

La convivialité: Il faut fournir une interface simple à utiliser pour l'administrateur d'application web et pour les superviseurs d'application Android car elle présente le premier contact de l'utilisateur avec l'application.

Une solution ouverte et évoluée : l'application peut être améliorée par l'ajout d'autres modules pour garantir la souplesse, l'évolutivité et l'ouverture de la solution.

V. Diagramme de Gantt

Pour finir le travail dans les délais, nous avons commencé par la mise en place d'un chronogramme comportant la répartition des différentes tâches à réaliser au cours du temps. En effet, nous avons choisi un cycle de vies itératives et incrémental. Le logiciel utilisé Gantt projet. La Figure1 illustre le chronogramme que nous avons suivi tout au long du cycle de vie de l'application.

25

Figure 3: Diagramme de Gantt du projet

VI. Conclusion

Dans ce chapitre, nous avons commencé par la mise en contexte de ce travail en présentant son cadre, la problématique que nous y avons abordée et en donnant un aperçu sur la solution que nous proposons. Nous traitons au prochain chapitre la technologie mise en ouvre.

26

Chapitre 2.

Technologies mises en oeuvre

27

I. Introduction

Dans ce chapitre, nous présentons les différentes technologies mises en oeuvre tout en détaillant les outils utilisés pour la réalisation de notre système. Ce chapitre est composé en les grandes parties suivantes :

· Les spécifications matérielles.

· Les spécifications logicielles.

· Le réseau de capteurs.

· Le cloud: UBIDOTS

II. Environnement matériel

Ce chapitre récapitule l'essentiel des recherches que nous avons faites concernant les deux cotés hardware et software pour les différents composants du notre système. Il contient également une justification des différents choix adoptés ainsi que l'explication des étapes suivies.

Figure 4: Environnement matériel

1. La Carte raspberry pi

i. Description

Le Raspberry Pi est un nano-ordinateur mono_carte à processeur ARM conçu

par le créateur de jeux vidéo David Braben, dans le cadre de sa fondation Raspberry Pi. Cet ordinateur (carte Raspberry), qui a la taille d'une carte de crédit, est destiné à encourager l'apprentissage de la programmation informatique. Il permet l'exécution de plusieurs variantes du système d'exploitation libre GNU/Linux et des logiciels compatibles. Il est fourni nu (carte mère seule, sans boîtier, alimentation, clavier, souris ni écran) dans l'objectif de diminuer les coûts de carte.

28

ii. Modèles et choix de la carte raspberry

Tous les modèles de Raspberry Pi sont répartis en deux familles. En effet, chaque modèle appartient à une famille :

· Famille A: modèle A, modèle A+

· Famille B: modèle B, modèle B+, modèle B génération 2 Chaque famille de Raspberry pi se destine à un usage différent :

Famille A: elle est utilisée avec moins de matériel (pas de ports Ethernet, moins de RAM), et caractérisé par une faible consommation d'énergie par rapport à la famille B

Famille B: elle est utilisée avec un meilleur matériel. Ces modèles sont plutôt destinés à des utilisations plus exigeantes en ressources comme le traitement de texte ou le visionnage de vidéos.

Dans notre projet nous travaillons avec la modèle B illustré avec la Figure suivante.

Figure 5: RPI modèle B

iii. Spécifications techniques

Le tableau 1 ci-dessous présente les spécifications techniques du modèle de la

carte Raspberry pi que nous avons utilisée.

29

Tableau 1: Spécifications techniques des modèles des raspberry "famille B"

Critère	Modèle B	Modèle B+		B Génération 2	Processeur
700 MHz	700 MHz	900 MHz		Mémoire vive
512 Mo	512 Mo	1Go		Alimentation
700mA (3,5W) via micro-USB	600Ma (3,0W) via micro-USB	600mA (3,0W) via micro-USB		Stockage des données
Lecteur de carte SD/MMC	Lecteur de carte micro- SD	Lecteur de carte micro- SD		Port USB
2	4	4		Prix
358	358	358

Les périphériques du Raspberry

Les ports disponibles dans la carte Raspberry sont :

· Les ports GPIO

· Les ports USB 2.0

· La sortie audio et sortie vidéo

· Le port Ethernet

· Le port HDMI

· Le connecteur de carte SD,

On peut connecter au Raspberry Pi plusieurs périphériques tels que :

· Les périphériques d'entrée : un clavier, une souris

· Les périphériques de sortie : un moniteur qui est relié par un câble HDMI

· La carte MicroSD ayant comme rôle la mémoire du raspberry vu qu'il n'utilise pas de disque dur comme un ordinateur classique.

Un câble Ethernet pour pouvoir le connecter à Internet ou un dongle wifi USB qui doit être compatible avec le Raspberry- ou une clé dongle 3G

Une caméra qui peut être parmi ces trois types : Caméra IP ou Raspberry Pi

30

Figure 6 : Connectivité du Raspberry avec les périphériques

2. Capteur telos

Chaque modèle de capteur a des caractéristiques spécifiques en termes de capacité de mémoire, capacité de stockage, du modèle du microcontrôleur et du débit des données. La Figure 7 représente des échantillons de capteurs

Figure 7 : Echantillon des capteurs TELOS

Tableau 2 présente les principales caractéristiques des capteurs les plus connus et les plus utilisés dans le domaine de la recherche.

Tableau 2 : Caractéristiques des capteurs les plus courants

Nom du capteur	RAM	Mémoire	Stockage		Débit	Telos
4 KB	128 KB	512 KB	40 Kbps		TelosA
4 KB	60 KB	512 KB	250 Kbps		TelosB
10 KB	48 KB	1 MB	250 Kbps

Dans notre travaille nous choisissons le capteur TelosB à base des caractéristiques suivantes :

· Une faible consommation d'énergie.

· Une longue durée de vie de la pile.

· Un débit et une portée moyenne.

31

Caractéristiques TelosB:

· Processeur: MSP430 microcontrôleur, 8 Mhz, 10k RAM, 48k Flash(ROM).

· Sensors: Lumière, Température, Humidité.

· Transmission: Norme de transmission: IEEE 802.15.4 (ZigBee), Débit: 250 Kbps (Bande 2.4-2.4835GhZ), Antenne intégrée.

· Portée: Real-Test: 30 m (indoor: 1 obstacle), 80 m (outdoor), From datasheet: 50 m (indoor), 125 m (outdoor).

· Système d'exploitation: Contiki.

· Programmable via l'USB.

Figure 8: Les capteurs Tmote Sky (TelosB)

32

III. Environnement logiciel et langages utilisés

Dans notre projet nous utilisons les logiciels et les langages suivants :

Figure 9: Environnement logiciel

1. Raspbian OS

Raspbian est un système d'exploitation libre basé sur Debian optimisé pour le matériel Raspberry pi. Il gère les ressources matérielles du Raspberry Pi. Il exécute les applications en leur affectant les ressources nécessaires à leur bon fonctionnement, gère les entrées/sorties et permet d'unifier et de contrôler l'accès des programmes aux ressources matérielles par l'intermédiaire des pilotes.

Cependant, Raspbian ne fournit pas simplement un système d'exploitation basique, il est aussi livré avec plus de 35 000 paquets, c'est-à- dire des programmes pré-compilés livrés dans un format optimisé, pour une installation facile sur votre Raspberry Pi.

2. Contiki/Cooja i. Instant Contiki · Un environnement de développement simplifié. Sous la forme d'une virtuelle Vmware. Contiki est un système d'exploitation open source.

machine

· C'est un système configurable pour les réseaux de capteurs.

· Contiki est un système d'exploitation conçu pour prendre le moins de place possible, avec une faible empreinte mémoire parce qu' il est écrit en langage C.

·

33

Contiki autorise deux modes de fonctionnement : soit multitâche, soit basé sur les événements (orienté évènement.).

Un système utilisant Contiki contient des processus (des applications ou des services). La communication entre ces processus se fait par :

Le mode multitâche : une bibliothèque doit être installée. Les fonctions associées à cette bibliothèque n'accèdent pas directement à l'ensemble des ressources du capteur sans fil. Elles doivent, dans certains cas, faire appel à la partie du noyau dédié à la gestion des événements. Cette structure à deux niveaux a pour conséquence une dégradation des performances du système quand le mode multitâche est activé.

L'envoi d'événements : Le noyau du système Contiki est orienté évènement. L'idée d'un tel système est que chaque exécution d'un processus par une application ce n'est qu'une réponse à un évènement.

Les évènements peuvent être classés en trois types :

timer events: sont des évènements basés sur un temporisateur dans le but de générer un évènement après un certain laps de temps. C'est très pratique pour les actions périodiques, ou dans le monde des réseaux comme la synchronisation.

external events: sont des évènements qui proviennent de l'extérieur souvent par des équipements connectés au microcontrôleur par des interfaces d'entrée/Sortie (I/O). Ces équipements lancent des interruptions à chaque fois une actions est détectée (ex. accéléromètre, détecteur de mouvement, etc.)

internal events: sont des évènements internes générés par des processus pour communiquer avec d'autres processus (ex. informer le processus de traitement que les données sont prêtes pour le traitement).

Ces évènements peuvent avoir les informations suivantes :

process: un évènement adressé à un processus. Il peut être destiné à un processus spécifique ou bien à tous les processus enregistrés.

event type: le type d'évènement. Le programmeur peut définir les types d'évènements destinés au processus afin de pouvoir les différencier entre eux (comme le cas de réception de paquet ou de transmission de paquet).

data: certaines données peuvent être générer pour un processus via des évènements.

Ce type d'évènement est le principe de base du système d'exploitation Contiki.
Les évènements sont « postés » aux processus. Les processus s'exécutent pendant

34

qu'ils reçoivent les évènements et ils se bloquent pour attendre d'autres évènements lorsqu'il n'y en a plus.

ii. Simulateur Cooja

Cooja est un simulateur/ émulateur de réseau de capteurs appelé motes pour

Contiki.

Il permet de simuler les connexions réseaux et d'interagir avec les capteurs.

Le code exécuté par les noeuds est le même chargé sur des capteurs ou des

noeuds physiques.

Les capteurs supportés par Cooja sont : Telos, exp5438, wismote, micaz, etc.

La simulation avec Cooja fournit une grande flexibilité, un faible coût et un

contrôle total de la plate-forme expérimentale

3. Outil de développement ANDROID STUDIO

Pour réaliser le développement de notre application de supervision de centre de

données, plusieurs choix d'environnement de développement s'offre à nous (Android Studio, C#, Visual Basic, etc.). Nous avons choisi Android Studio 1.5.1, comme un environnement de développement.

La plateforme Android est un OS (Operating System) pour téléphone mobile et tablette tactile, promu par Google.

4. XML

XML permet à l'utilisateur de définir des marqueurs (balises) qui facilitent le

parcours au sein du fichier et donc la lecture de l'information. Utiliser dans l'application Android pour l'interface graphique.

5. Java

C'est un langage de programmation orienté objet utilisable sur divers systèmes d'exploitation. Il est un langage portable. Il est utilisé très largement dans le monde du développement Android.

6. Python

Python est un langage de programmation objet, multi-paradigme et

multiformes. Il favorise la programmation impérative structurée, fonctionnelle et orientée objet. Il est doté d'un typage dynamique fort, d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de gestion d'exceptions. Il est conçu

35

pour optimiser la productivité des programmeurs en offrant des outils de haut niveau et un système simple à utiliser.

Il permet d'une part, la connexion entre le coordinateur du réseau de capteur et le Raspberry et d'autre part, la connexion entre le carte Raspberry et l'UBIDOTS.

7. PHP

C'est un langage de programmation utilisé pour produire des pages web dynamiques via un serveur http.

Il permet la connexion entre l'application Android et le base de données. Il représente la niveau deux de l'architecture trois tiers.

8. MySQL

Il est un système de gestion de base de données (SGBD). Il est multithread et multiutilisateur. Utiliser pour la création de base de données de l'application.

9. Apache

Le logiciel libre apache http server (apache) est un serveur http créé et maintenu au sien de la fondation Apache.

IV. Le réseau de capteurs

Cette partie consiste à exposer les réseaux des capteurs sans fil qui sont de plus en plus utilisés dans l'environnement et l'industrie grâce notamment aux développements réalisés dans le domaine des technologies sans-fils.

Un réseau de capteurs sans fil RCSF : (WSN: Wireless Sensors Networks) est un ensemble de capteurs autonomes, interconnectés par des liaisons sans fil.

RCSF est un réseau ad hoc (des réseaux sans fil s'organisent sans infrastructure définie préalablement) capables de récolter et de transmettre des données environnementales d'une manière autonome.

Norme IEEE 802.15.4 (couche physique et couche MAC)

Le 802.15.4 est un protocole de communication défini par l'IEEE permet d'obtenir des liaisons sans fil à:

V' Très faible consommation des dispositifs embarqués par mise en veille.

V' faible portée de quelques centaines de mètres (théoriquement 100 mètres)

V' faible débit (maximum 250kB/s)

36

V' Faible taille du code à embarquer

V' Leur durée de vie est la durée de vie de leur batterie (Il faut minimiser les dépenses énergétiques, car l'énergie est une contrainte clé dans les réseaux de capteurs).

V' Bas prix.

Les appareils constituant les réseaux de capteurs sont donc très limités en termes d'énergie, mémoire, et capacité de processeurs.

La norme IEEE 802.15.4 propose une couche physique et une couche liaison de données adaptées aux applications à faible débit dont l'autonomie énergétique est une contrainte forte. Dans cette première partie, nous allons en présenter les rôles de ces deux couches.

1. Couche physique

La couche application a pour Rôle de :

· Détection d'énergie.

· Mesure de la qualité de la liaison.

· Disponibilité du canal.

· Emission et réception des données. Bande de fréquences:

· 16 canaux dans la bande de fréquence de 2.4 GHz: 250 kbps.

· 10 canaux dans la bande de fréquence de 902 à 928 MHz: 40 kbps.

· 1 canal dans la bande de fréquence de 868.3 MHz: 20 kbps.

2. La couche d'accès au médium (MAC)

Rôle de la couche MAC est :

· Gère le mécanisme d'accès au support

· Garantit l'intégrité des données

· Supporte les associations et dissociations au réseau.

· La validation des trames.

Il existe cependant deux modes de fonctionnement de la couche MAC selon le type de topologie utilisé et le besoin en débit garanti, à savoir :

· le mode non- beacon utilisant CSMA/CA

· le mode beacon, avec l'envoi à période régulière d'une balise pour synchroniser les dispositifs, garantissant un débit au capteur ayant un GTS (c'est le mode utilisée dans le réseau des capteurs).

3. Le standard 6LoWPAN

802.15.4 est utilisé par de nombreuses implémentations basées sur des protocoles propriétaires ou sur IP (Internet Protocol), comme le ZigBee et le 6LoWPAN.

La pénurie d'adresse IP est un problème connu qui dispose d'une solution :

(couche réseau et couche application)

37

IPv6. Une tendance est d'amener Internet sur des appareils de plus en plus petits pour pouvoir les contrôler à distance.

Ces deux aspects réunis en un même problème nous donnent comme solution le protocole 6LoWPAN (IPv6 Low Power Wireless Personnal Area Networks). Pour cela nous choisir 6lowpan le standard la plus adapté à être exploité dans notre travaille (on a besoin de l' Internet pour l'envoie de valeurs depuis réseau de capteurs vers Ubidots).

Figure 10 : Architecture réseau du standard 6LoWPAN

4. Couche réseau

6LoWPAN a été développé pour définir une couche d'adaptation d'IPv6 pour des systèmes à faibles ressources.

· Il défini les mécanismes d'encapsulation et de compression d'entêtes permettant

communication IEEE

aux paquets IPv6 d'être envoyés ou reçus via le protocole de 802.15.4.

· 6LoWPAN devrait permettre à IPv6 d'intégrer des matériels informatiques.

38

Figure 11 : Adaptation d'IPv6 par le standard 6LoWPAN

5. Connexion entre les capteurs

Chaque entité (noeud) communique directement avec sa voisine. Pour communiquer avec d'autres entités, il est nécessaire de faire passer ses données par d'autres qui se chargeront de les acheminer. Pour cela, il est d'abord primordial que les entités se situent les unes par rapport aux autres, et soient capables de construire des routes entre elles : c'est le rôle du protocole de routage.

Les capteurs sans fil communiquent par le biais des ondes radioélectriques. N'étant pas intégrés à un réseau préexistant; les capteurs communiquent grâce à un réseau dit « ad hoc », capable de s'organiser sans infrastructure définie préalablement. Ceci implique que chaque capteur puisse retransmettre une information

indépendamment ou avec l'aide des autres capteurs et ceci afin d'envoyer
l'information à une « station de base : sink » capable de transmettre l'information à l'utilisateur final par le biais d'Internet ou d'un réseau télécom GSM dans la majorité des cas (carte raspberry dans notre projet).

V. Le Cloud : UBIDOTS

Le Cloud est une plateforme informatique fournissant aux entreprises des services avec l'illusion d'une infinité des ressources accessible de n'importe quel lieu, quel temps, quel personne.

Il consiste à déporter sur des serveurs distants des stockages et des traitements informatiques traditionnellement localisés sur des serveurs locaux ou sur le poste de l'utilisateur.

Le Cloud est un modèle qui permet un accès réseau à la demande et partage des ressources informatiques configurables (telles que réseaux, serveurs, stockage, applications et services).

Figure 12: Le cloud

· Les différents services

Le Cloud peut être décomposé en trois couches :

1. IaaS (Infrastructure as a Service)

C'est le

: infrastructure en tant que service.

service de plus bas niveau. Il est géré par les architectes réseaux.

39

Figure 13: L'infrastructure as a Service (IaaS)

2. PaaS (Platform as a Service): plate-forme en tant que service. Elle est destinée aux développeurs d'applications

40

Figure 14: La couche PaaS

3. SaaS (software as a service) : logiciel en tant que service. Il est le « produit final » pour les utilisateurs.

Figure 15: Logicielle as a service (SaaS)

VI. Conclusion

Après avoir terminé l'étude du projet et nous choisissons une solution à étudiée, il nous reste de décider dans quel environnement nous allons travailler, exposer les choix techniques utilisés et le langage adopté. Dans le chapitre suivant nous présentent la phase de spécification et conception.

41

42

Chapitre 3.

Étude conceptuelle

43

44

I. Introduction

La conception est la phase la plus importante dans le cycle de développement d'une application et qui se concentre essentiellement sur la définition de l'architecture du système et sur les besoins des utilisateurs que nous essayons de représenter par les diagrammes de cas d'utilisations globales. Ainsi que sur les diagrammes de séquence et de classe qui nous permettent de traduire les besoins fonctionnels et les contraintes du cahier des charges par un langage plus compréhensible pour le(s) développeur(s) d'application.

Dans le cadre de notre projet nous avons utilisé la méthodologie UML pour la modélisation des différents diagrammes et nous avons travaillé avec trois vues (trois diagrammes)

· Vue fonctionnel :

- diagramme de cas d'utilisation : il décrit les besoins utilisateurs et permet de donner une vue globale de l'application.

· Vue dynamique :

- diagramme de séquence : scénarios et flots de messages : l'ordre chronologique des différentes opérations

· Vue statique :

-diagramme des classes : définit la structure statique des différents objets composant l'application.

Le choix de ce langage se fait selon les différents critères sous dissous :

· UML est un langage formel et normalisé.

· UML est un langage plus professionnel et compréhensible pour tous les individus intervenants dans la réalisation et l'utilisation de l'application

· Il caractérise par l'accessibilité : l'UML conçu pour s'adapter à n'importe quel langage de programmation orientée objet (Java, C++, Android, etc.).

· L'UML est un support de communication performant : Il cadre l'analyse et facilite la compréhension de représentations abstraites complexes.

45

II. L'architecture logicielle

L'architecture logicielle décrit d'une manière symbolique et schématique les différents éléments d'un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions. Le modèle d'architecture, produit lors de la phase de conception décrit comment le système informatique doit être conçu de manière à répondre aux spécifications. Alors que l'architecture décrit le « comment le faire ».

Nous avons choisi l'architecture trois tiers qui est connue aussi sous le nom d'architecture à trois niveaux, elle est très utilisée dans le développement d'application web et mobile. C'est une extension du modèle métier et accès aux données.

La première couche est la couche présentation, est une couche visible et interactive avec l'utilisateur. Elle présente généralement la partie graphique de l'application. Cette couche transmet les requêtes utilisateurs à destination de la couche métier, et en retour lui présente les informations renvoyées par les traitements de la couche métier.

La couche métier, qui consiste la deuxième couche de cette architecture, consiste la partie fonctionnelle et opérative de l'application. C'est dans cette couche que s'exécutant les différentes règles de gestion et de contrôle du système en s'appuyant sur les données du système fourni par le base des données.

La dernière couche est la couche accès aux données, cette couche regroupe le stockage et les mécanismes d'accès des données de façon à ce qu'elles soient utilisables par l'application au niveau traitement.

Figure 16: architecture trois tiers

46

III. Les diagrammes de cas d'utilisation

1. Description

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il comporte :

· Les acteurs : ce sont les entités externes au système qui interagissent avec lui.

· Les relations entre les cas d'utilisation (Use Case) sont :

y' Inclusion : lorsqu'un cas d'utilisation délègue une tâche à une autre, la dépendance est indiquée au moyen d'une flèche pointillée allant de cas d'utilisateur au cas utilisé. Cette notation indique que le fait d'exécuter le cas « utilisateur » inclut la fonctionnalité du cas « utilisé ».

y' Extension : Dans une relation d'extension entre cas d'utilisation, le cas d'utilisation source ajoute son comportement au cas d'utilisation de destination. L'extension peut être soumise à une condition. Cette relation est représentée par une flèche en traits pointillés et le mot clé « extend ».

y' La généralisation : Dans une relation de généralisation entre deux cas d'utilisation, le cas d'utilisation enfant est une spécialisation du cas d'utilisation parent. Une flèche à l'extrémité triangulaire représente une telle relation.

y' Association : Un trait simple reliant un acteur à un cas d'utilisation représente une association. L'association indique qu'il existe un chemin de communication entre l'acteur et le cas d'utilisation.

2. Identification des acteurs

Un acteur est une entité externe par rapport au système étudié (utilisateur humain, dispositif matériel ou autre système). Un acteur peut appliquer des opérations sur l'état du système en émettant et/ou recevant des messages susceptibles d'être porteurs de données.

Notre application contient trois acteurs:

· Superviseur: c'est un acteur humain, responsable de contrôler le système.

· Administrateur: c'est un acteur humain, responsable des gérer les capteurs et les superviseurs ainsi que contrôler le centre de données.

· Système de contrôle: Il gère l'authentification de différents acteurs du système, celui que contient la carte raspberry pi et les différents équipements. Son rôle est de vérifier l'état de ces équipements et de passer les commandes de l'utilisateur.

3. Diagramme de cas d'utilisation

Un cas d'utilisation est destiné à représenter les besoins des utilisateurs par

rapport au système et qui produisent un résultat observable pour l'acteur. C'est qui exprime les interactions acteurs /système.

47

Ce diagramme constitue un des diagrammes les plus structurants dans l'analyse d'un système.

i. Diagramme de cas d'utilisation générale

Figure 17: Diagramme de cas d'utilisation général

La figure 17 représente le diagramme de cas d'utilisation générale compose par un superviseur (client Android) qui faire les fonctionnalités suivantes :

·

48

Consulter courbes/états: les superviseurs peuvent contrôler les différentes valeurs des variables (température, humidité, luminosité, énergie, flamme) à travers une interface Android.

· Passer réclamation : en cas de panne le superviseur passer une réclamation a l'administrateur sous forme description, image ou les deux au même temps.

Dans ce diagramme il y a une relation de généralisation entre le superviseur et

l'administrateur donc le cas d'utilisation enfant (du superviseur) est une
spécialisation du cas d'utilisation parent (du l'administrateur).

L'administrateur ayant des fonctionnalités supplémentaire par rapport au superviseur qui sont les suivants :

· Gestion des superviseurs/Gestion des capteurs : l`administrateur aux les fonctions de gérer les différentes superviseurs et capteurs: ajout, suppression, mettre à jour...etc.

· Consulter reclamation: Cette notation n'est possible que lorsque le superviseur passer la réclamation : le cas « utilisateur : passer réclamation » inclut la fonctionnalité du cas « utilisé : consulter réclamation ».

Chaque utilisateur doit s'authentifier avant d'accéder à l'application.

ii. Diagramme de cas d'utilisation pour l'application web

L'application web donne à l'administrateur la possibilité de consulter les graphes, les états et les réclamations. En plus, il gère les superviseurs et les capteurs. Enfin, Chaque administrateur doit s'authentifier avant d'accéder à l'application.

49

Figure 18 : Diagramme de cas d'utilisation pour l'application web

Dans le premier cas d'utilisation « consulter les graphes » l'administrateur permet de contrôler les différentes variables (température, humidité, luminosité, énergie), qui déjà prendrons de système de contrôle, sous forme des courbes et histogramme ainsi, il permet de retourner à historique pour observer les anciennes valeurs.

Ensuite, l'administrateur permet de « consulter les états » c'est-à-dire visualiser les dernières valeurs de ces variables dans un temps réel.

Déplus, il permet de « consulter les réclamations ». Ce le message qui envoyer par le superviseur en cas de problème.

Enfin, il a l'accès des « gestion des superviseurs » et « gestion des capteurs ». Il permet d'ajouter, modifier et supprimer un capteur ou un superviseur.

50

iii. Diagramme de cas d'

utilisation pour l'application Android

La figure 19 montre les différentes fonctionnalités du superviseur (client Android).

Figure 19 : Diagramme de cas d'utilisation pour l'application Android

doit s' « authentifier » avant

d'accéder à son

D'abord, Chaque superviseur application Android.

Ensuite, il permet de « consulter les graphes » et « consulter les courbes » pour suivi les différentes variantes environnementales dans le centre des données.

En plus, il permet de « passer une réclamation » a l'administrateur qui décrire une description brève avec une capture récapitule ce qui c'est passe dans le centre.

IV. Etude dynamique

: les diagrammes de séquences

1. Description

Les diagrammes de séquence peuvent servir à illustrer les cas d'utilisations décrits dans la partie précédente. Ils permettent de représenter la succession chronologique des opérations.

Les composants d'un diagramme de séquence sont les suivants :

Les objets : sur un diagramme de séquence, les objets apparaissent toujours dans la partie supérieure, ce qui facilite l'identification des classes qui participent à l'interaction.

Le message : élément de communication unidirectionnel entre objets qui déclenche une activité dans l'objet destinataire. La réception d'un message provoque un événement

51

dans l'objet récepteur. La flèche pointillée représente un retour au sens UML. Cela signifie que le message en question est le résultat direct du message précédent.

Dans cette partie, les scénarios les plus importants sont décrits ainsi que leurs représentations par les diagrammes de séquence.

2. Diagramme de séquences « authentification »

Dans cette partie, nous décrirons le cas d'utilisation « s'authentifier ».

(login, mot

Figure 20 : Diagramme de séquence « authentification »

· Acteur : Les utilisateurs: administrateur et superviseur.

· Pré condition: L'utilisateur doit avoir ses propres paramètres de connexion de passe)

· Description des Scénarios :

y' L'utilisateur entre son login et son mot de passe.

y' Le système vérifie automatiquement les informations saisies par l'utilisateur.

y' Si l'authentification est correcte : les informations saisies sont validées avec succès et la fenêtre d'accueil de l'application lui apparaît.

y' Sinon les informations saisies sont non validées et l'utilisateur doit retaper son mot de passe.

y' Le système cède la main à l'utilisateur pour un nouvel essai d'authentification.

52

3. Diagramme de séquences « Consulter les courbes».

La Figure 21 présente le diagramme de séquences «Consulter courbe».

Figure 21 : diagramme de séquences « consulter courbe »

· Acteur: administrateur, superviseur.

· Description des Scénarios:

y' Le superviseur ou l'administrateur choisir une région qui va superviser puis choisir une variable qui souhaite a consulter

y' Le système importe la courbe approprié puis l'afficher

53

4. Diagramme de séquence « Envoie réclamation »

Dans cette partie nous décrirons le diagramme de séquences « passer réclamation » comme présente la figure suivante.

Figure 22 : Diagramme de séquence «Envoie réclamation »

· Acteur: superviseur.

· Pré condition: apparition d'une panne.

· Description des Scénarios :

pour

y' Le superviseur écrire une description avec une image (capture d'écran) et l'envoie au système.

y' Le système l'assigne enregistre le panne et l'envoie à l'administrateur avoir une solution.

54

Diagramme de séquence « Gérer les superviseurs »

Scénarios 1. « Ajouter un superviseur »

La Figure 23 présente le diagramme de séquences « Ajouter un superviseur ».

Figure 23 : Diagramme de séquences « ajouter superviseur »

· Acteur: Administrateur.

· Description des Scénarios:

V' L'administrateur fait entrer les attributs du superviseur à ajouter (Cin, nom, adresse, téléphone, E-mail, login, mot de passe).

V' Le système vérifie les informations entrées par l'administrateur.

V' Utilisateur ajouté avec succès.

V' Utilisateur non déjà ajouté : des champs obligatoires manquent ou un superviseur existe déjà. Le système cède la main à l'administrateur pour entrer de nouveau les informations manquantes ou erronées.

55

Scénarios 2. «Modifier un superviseur »

Figure 24 présente le diagramme de séquences «Modifier un superviseur».

modifier.

du

Figure 24 : diagramme de séquences « modifier superviseur »

· Acteur: Administrateur.

· Description des Scénarios:

V' L'administrateur choisit le superviseur à

V' Le système demande à l'administrateur d'entrer les nouvelles attributs superviseur choisi .

V' L'administrateur fait entrer les nouvelles attributs de superviseur à modifié. V' Le système vérifie les nouvelles informations entrées par l' administrateur. V' Superviseur modifié avec succès.

56

Scénarios 3. «Supprimer un superviseur »

Figure 25 Présente le diagramme de séquences «Supprimer un superviseur».

Figure 25 : diagramme de séquence « supprimer superviseur »

· Acteur: Administrateur.

· Description des Scénarios:

V' L'administrateur choisit le superviseur à supprimer.

V' Le système demande à l'administrateur de confirmer la suppression du

superviseur choisi.

V' La suppression est confirmée : le système supprime le superviseur.

V. Diagramme de classes

Le diagramme de classes exprime de manière générale la structure statique d'un système. Une classe décrit un ensemble d'objets et une association décrit un ensemble de liens. Les objets sont des instances de classes et les liens sont des instances de relations.

57

Nous présentons dans ce qui suit le diagramme de classes de notre application. Nous présentons toutes les classes de notre base de données, ainsi que les relations entre ces classes comme indiqué la figure 26 .

Figure 26: Diagramme de classes de l'application

VI. Conclusion

Dans ce chapitre, nous avons procédé à une identification des acteurs et nous avons fait une analyse des besoins par le biais des diagrammes de cas d'utilisation pour mieux comprendre le principe de fonctionnement de l'application. Par la suite nous avons détaillé nos applications en précisant la façon dont les objets et les acteurs doivent collaborer ensemble par l'utilisation des diagrammes de séquence. Finalement, nous avons décrit l'aspect statique avec un diagramme de classe globale.

Dans le chapitre suivant, nous montrons les stades de développement tout en détaillent les phases de la réalisation.

58

59

Chapitre 4 :

Réalisation

60

I. Introduction

Après avoir achevé l'étape de conception de l'application, on va entamer dans ce chapitre la partie réalisation et implémentation dans laquelle on s'assure que le système est prêt pour être exploité par les utilisateurs finaux (responsable, superviseur). A la fin de ce chapitre, les objectifs doivent avoir été atteints et le projet doit être terminé.

Cette partie consiste à concevoir la conception exprimée et de présenter quelques interfaces de notre application. Notre application est composée de trois grandes parties :

1. La première partie consiste à simuler un réseau de capteur avec Contiki pour collectée les données mesure au niveau du centre de donnes et envoie vers l'extérieur (internet, terminal distant...) à l'aide le carte Raspberry.

2. la deuxième partie consiste à créer des programmes en langage java permettant d'exécuter des scripts pour l'exécution des commandes bien spécifique et aussi pour la collecte d'information au niveau des machines du superviseur.

3. La troisième partie consiste à créer une interface web et d'interpréter graphiquement les données collectées.

4. Le dernière partie consiste à créer des tables au niveau de la base de données MySQL. Ces tables permettent l'enregistrement des données collectées.

Pour assure l'implémentation de l'application Android et la plateforme web nous passons par les étapes suivantes :

II. Etape 1 : Collection des données: par La simulation Contiki /Cooja

Il faut note bien que cette travaille reste une simulation pour les capteurs c'est-à-dire simulation de réseau (non des valeurs).

Dans notre travaille pour simuler le réseau de capteur nous utilisons un simulateur Cooja ouvrir sous le système d'exploitation Contiki version 2.6 installer sur un VMWare Player

Pour ouvrir Cooja il faut suivit les étapes ci-dessous :

1. Ouvrir le terminal

2. Entre en mode d'administration : sudo -s

3.

61

Aller dans le répertoire suivant a l'aide de commande « cd » : cd contiki-2.6/examples/ipv6/sky-websense/

4. Exécuter le simulateur Cooja pour afficher l'interface de travail par le

commande

: make TARGET = Cooja example-sky-websence.csc

Figure 27: Interface Cooja

Après, il faut ouvrir un autre terminale pour activer LBR (coordinateur du réseau) et affiche leur adresse ipv6.

Les commandes sont les suivantes:

1. Sudo -s

2. cd contiki- 2.6/examples/ipv6/sky-websense/

3. make connect-router-cooja

4. LBR sera active et son adresse afficher

5. Ouvrir le navigateur et coller l'adresse de LBR entre deux crochet [ ]

La table de routage sera affichée avec les différentes valeurs (température, luminosité)

Figure 28 : les valeurs de sensors température et luminosité

Les données captées par les noeuds sont acheminées grâce à un routage multi-saut à un noeud considéré comme un «point de collecte», appelé noeud-puits ou sink ou coordinateur.

62

Figure 29: Principe de la simulation du réseau

63

Puis, nous expliquons la partie en rouge de la figure 30

Figure 30: Passage entre les différentes parties par le Gateway Raspberry

III. Etape 2 : Raspberry

: réception et envoie des données

Figure 31: connexion entre LBR et Raspberry

Pour assure la connexion entre le coordinateur et Raspberry, nous utilisons un

câble USB et le protocole http écrit sous forme suivant :
Url= http://192.168.1.4/capteur.php

Matérielle utilisée : un clavier et une souris qui se brancheront justement sur les deux ports USB du Raspberry Pi. Et connectez un câble HDMI entre l'écran et le

Raspberry Pi.

64

Configuration de la carte Raspberry :

Installer Linux

La première chose à faire consiste à installer Linux sur le Raspberry Pi. Cela comprend les étapes suivantes :

· Télécharger et extraire l'installateur sur une carte SD (4 GO) formatée.

· Insérer la carte dans le Raspberry Pi

· Allumer le Pi, choisir ce qu'il faut installer, et attendre.

Une fois que c'est fait, vous êtes prêt à démarrer le Pi avec un bureau Linux graphique.

· Téléchargez _NOOBS_vX_Y_Z.zip et insérez la carte SD dans l'ordinateur.

· Après avoir décompressé le fichier, assurez-vous que le fichier _bootcode.bin_ est dans le répertoire racine de la carte SD.

Démarrage et installation de Raspbian

Il offre un menu graphique des différents systèmes d'exploitation.

Sélectionnez « Raspbian [RECOMMENDED] » et choisissez la langue et le type de clavier que vous utilisez. L'installation de Raspbian ne prend que quelques minutes.

Une fois que le Raspberry Pi a redémarré, vous vous retrouvez dans un environnement graphique et une session sera ouverte automatiquement.

Après vous être identifié, saisissez startx pour démarrer X Windows System, qui est l'interface graphique. Et l'interface Raspberry sera ouvrir.

IV. Etape 3 : la connexion entre le Raspberry et le Cloud

D'abord, il faut accéder au compte ( things.ubidots.com) et créez un nouveau projet (devices - add devices - Data Center). Puis, créez les différentes variables (variables- add variables- flamme). Chaque variables doit avoir un identifiant Id.

Id de variable: il s'agit d'un identifiant unique de la série chronologique qui stocke vos données.

65

Figure 32: Interface Cloud

La connexion entre le Raspberry et le Cloud se fait à l'aide d'api client. Puis, nous créons un script python à l'aide de votre éditeur de texte préféré pour envoyer les valeurs à partir l'entrée numérique dans le Raspberry Pi vers l'Ubidots

V. Etape 4 : Codage et transmission de données à partir de l'application Android

Pour accéder à l'application, l'utilisateur doit l'avoir sur son Smartphone ayant le système d'exploitation Android avec une version minimale de 4.0. Pour tester notre application, la première chose à faire consiste à télécharger et installer Android Studio.XML est utilisé pour créer les vues pour l'utilisateur.

Puis, nous importerons la bibliothèque Java d'Ubidots dans notre application pour autoriser la connexion entre l'application Android et le compte Ubidots.

Pour assurer cette connexion nous avons utilisé le protocole de communication http.

1. Protocol et format de données

Le HTTP est un protocole qui définit la communication entre un serveur et un client. Nous utilisons la méthode Post pour envoyer des données au programme situé à une URL spécifiée. La forme de la requête Post est la suivante :

http://Adresseip/nomapplication/nomfichier.php

JSON (JavaScript Object Notation) :

Est un format de données textuel, générique permet de représenter l'information

structurée. Un document JSON ne comprend que deux éléments structurels :

1.Des ensembles de paires nom / valeur ;

2.D es listes ordonnées de valeurs.

Ces mêmes éléments représentent 3 types de données :

· Des objets ;

· Des tableaux ;

· Des valeurs génériques de type tableau, objet, booléen, nombre, chaîne ou nulle.

Figure 33 : listes ordonnées sous format JSON

Le principe est donc que le client Android fait appel au script PHP et ce script va récupérer les données à partir de la base de données MySQL. Les données seront encodées au format JSON et le serveur les envoie au client. Ensuite l'application analyse et affiche ces données codées.

66

Figure 34 : l'utilisation du Protocol HTTP et format de données JSON

67

2. Description des interfaces de l'application Android

Dans ce qui suit nous présentons quelques interfaces de l'application en citant

les détails de chaque imprime écran.

· Interface de connexion

Cette interface permet au superviseur de s'authentifier et de se connecter au serveur de la base de données. Le superviseur doit entrer son login et son mot de passe pour accéder à l'application. La figure suivante présente la page authentification.

Figure 35: Interface d'authentification du superviseur

En cas d'erreur, un message d'erreur sera affiché dans le cas où les informations écrites ne sont pas présentes dans la base de données.

· Interface d'accueil

Cette interface donne la main aux superviseurs pour accéder aux différentes fonctionnalités après la vérification du login et du mot de passe. L'interface principale est présentée dans la figure suivante :

68

Figure 36: Interface d'accueil de l'application Android

· Interface supervisons des états

Un menu est fourni pour l'utilisateur, s'il choisit « supervision des états», le système enchaine à l'interface utilisateur relative à la «supervision des états». Si le superviseur peut accéder à l`interface relative aux déférentes états. C'est-à-dire afficher les dernières valeurs mesurées par le système.

Figure 37: Interface de la supervision des états

· Interface supervisons des courbes

Dans le menu principal le superviseur possède aussi la fonctionnalité de supervision des graphes Si l'utilisateur sélectionne l'icône consulter les courbes le

système affiche l`interface relative aux consultations de courbe, d'où le superviseur peut choisir l'un des fonctionnalités ; courbe température, courbe humidité, courbe luminosité, courbe énergie via les onglets correspondants. Si le superviseur choisit l' onglet température le système affiche la courbe de température comme il est illustré par la figure 38.

.

69

Figure 38: Interfaces de supervision des graphes

· Passer la réclamation

Le superviseur peut passer une réclamation sous forme d'une description ou d'une image en cas de panne pour alertes l'administrateur de centre de donnés.

Figure 39: Processus d'envoie de réclamation

· 70

Interface de Réclamation:

Une fois le superviseur a le droit d'accéder aux réclamations, il remplira le formulaire (image, description, date, heure). Ensuite, il doit l'enregistrer dans la base de données.

Figure 40: Interface « passer reclamation »

VI. Etape 5: Interprétation graphique des données collectées par l'application web

Dans cette partie, nous détaillons les principales fonctionnalités offertes par l'application web que nous avons développée. Pour ce faire, nous présentons quelques interfaces.

· Page d'accueil

Une fois les données sont valides, le superviseur accède au menu. Dans cette interface l'utilisateur peut gérer toutes les fonctionnalités de l'application.

71

Figure 41 : Interface d'accueil pour l'application web

· L'interface de gestion des superviseurs

L'administrateur a le droit de consulter les différents superviseur, il a le droit d'ajouter, modifier, ou effacer un superviseur.

L'administrateur peut ajouter un superviseur en cliquant sur l'option « ajout nouveau superviseur ». Un formulaire comportant plusieurs champs s'affiche pour la saisie des données. L'application gère le contrôle de saisie ainsi que la sauvegarde dans les bases des données.

La figure ci-dessous présente le formulaire d'ajout du superviseur.

72

Figure 42 : Formulaire d'ajout d'un nouveau superviseur

Même l'administrateur peut modifier ou supprimer un superviseur à l'aide du formulaire suivant :

Figure 43 : Formulaire de mise à jour d'un superviseur

· Interface gestion de capteur

Cette interface permet à l'administrateur d'ajouter un nouveau capteur comme il est présenté dans la figure ci-dessous :

73

Figure 44 : Formulaire d'ajout d'un nouveau capteur

Aussi, l'administrateur peut sélectionner un capteur pour le modifier ou le supprimer. La figure suivante présente la page de mise à jour du capteur.

Figure 45: Formulaire de mise à jour d'un capteur

·

Supervision des variables

Figure 46: Historique

· Consulter les réclamations

:

Après avoir reçu le message d'alerte de la part des superviseurs, l'administrateur peut à tout moment consulter les alertes, comme la montre la figure suivante

74

Figure 47: Consulter réclamation

75

VII. Conclusion

A travers ce chapitre, nous avons présenté la réalisation de l'application en représentant quelques interfaces graphiques que nous avons jugées les plus importantes et en décrivant brièvement comment nous avons planifié notre projet.

76

Conclusion

Notre travail s'inscrit dans le cadre d'un Stage de Fin d'Etudes effectué au sein de la société SOCOMMI en vue de l'obtention du diplôme de technicien en réseau informatique.

Le produit de ce projet est un système de gestion d'un centre de données avec l'utilisation des nouvelles technologies comme le réseau de capteurs, Raspberry PI, base de données, application mobile sous Android et application web.

Tout au long de ce stage, nous avons eu l'opportunité de travailler sur des problématiques techniques différentes : base des données, développement mobile et développement des services web.

Cette expérience a été bénéfique et bien fructueuse sur plusieurs plans: d'une part, elle nous a permis de consolider nos acquis tout au long de notre cursus à la Faculté des Sciences de Sfax. D'autre part, ce projet nous a été d'un grand apport pour approfondir nos connaissances en conception et en développement d'application entière. Il nous a aussi donné la possibilité d'utilisation et de configuration de différents outils dans le cadre d'une seule application, et l'apprentissage de nouvelles technologies. Enfin, et à travers ce stage, nous avons eu la chance d'améliorer nos aptitudes à communiquer et à travailler en collaboration ce qui va nous aider sans doute à bien nous intégrer dans le milieu professionnel.

Une des limites de ce système est l'absence de matérielle (le capteur réel), nous avons fait recours à la simulation. Cette limite s'inscrit dans le cadre d'une perspective d'amélioration de ce projet. La deuxième limite est qu'il ne permet pas un bon niveau de sécurité.

Ce projet reste extensible à travers l'intégration d'autres capteurs pour le contrôle du centre des données comme l'ajout d'une caméra de surveillance pour la supervision vidéo.

77

78

Webographie :

· Réseau de capteurs:

https://kadionik.vvv.enseirb-matmeca.fr/se/projetsavances/0708/rapportsujet3E30708.pdf

· Contiki:

https://tel.archives-ouvertes.fr/tel-00319073/document

· Caractéristique de capteur TelosB: exemple TelosB:

http://moodle.utc.fr/pluginfile.php/16811/modresource/content/0/Cours1/TI60sensorscours1.p df

· Standard IEEE:

http://moodle.utc.fr/pluginfile.php/16811/modresource/content/0/Cours1/TI60sensorscours1.p df

· 6lowPAN:

http://www.efort.com/rtutoriels/WPANEFORT.pdf

· Android:

https://www.raywenderlich.com/149112/android-fragments-tutorial-introduction http://www.phonandroid.com/toute-l-histoire-et-la-chronologie-d-android-dossier.html

· Python:

https://ubidots.com/docs/devices/raspberrypi.html#send-multiple-values-to-ubidots https://ubidots.com/docs/es/devices/raspberrypi.html

· Connexion entre Android et l'Ubidots:

http://www.survivingwithandroid.com/2015/12/iot-connect-android-to-arduino-chart-2.html

· Uml :

https://openclassrooms.com/courses/debutez-l-analyse-logicielle-avec-uml/uml-c-est-quoi

· Ubidots:

https://www.hackster.io/ubidots/products/ubidots

· php5:

http://creersonsiteweb.net/page-apprendre-php

http://stephaneey.developpez.com/tutoriel/php/php5nouveautes/

· Raspbian:

https://www.nextinpact.com/news/101561-raspberry-pi-avec-pixel-raspbian-fait-sa-revolution.htm https://www.raspberrypi.org/downloads/raspbian/

Mémoires

· Contiki:

https://tel.archives-ouvertes.fr/tel-01124373/document

79

Titre : conception et réalisation d'un système de contrôle d'un centre

de données

Résumé :

Le but de ce travaille consiste à faire la conception et la réalisation d'un système de contrôle d'un centre de données à travers l'intégration de nouvelles technologies telles que le réseau de capteurs WSN, Cloud, Raspberry et Android. Le système offert à l'utilisateur d'une part une application Android désignée pour les Smartphones ou les tablettes et d'autre part une application web pour la surveillance et la gestion des divers équipements du centre des données.

Mots clés : Centre de données, supervision, réseau de capteurs, Raspberry, Cloud, Android, web.

Title: Conception and realization of a data center control system

Abstract:

The objective of this work is the conception and the realization of a system in order to control a data center integrating new technologies such Wireless Sensor Network (WSN), Cloud, Raspberry and Android. The system offered to the user is composed of two parts which the first is an Android application designed for smartphones, and the second part is a web application for monitoring and managing various data center equipments, which help the user to show and remote control the various devices of the center.

Key words: Data center, supervision, wireless sensor network, Raspberry, Cloud, Android, Web.