Réf : 2014/II/ Soutenu à la session de Juin 2014
Université de la Manouba
Ecole Nationale des Sciences de L'Informatique
R...
Résumé
LA localisation et la navigation personnelles sont devenues un domaine d'envergure
dans une société de mobilité. Le...
Abstract
THE personal positioning and navigation became a very challenging topic in our
dynamic time. The urban canyons an...
Signatures des encadrants
Prof. Maroua Bakri
(ENSI)
Madame Noura Baccar
(Cynapsys)
Remerciements
C'EST parce que j'ai beaucoup estimé tous ceux qui m'ont écouté, conseillé, cri-
tiqué et encadré que je tie...
REMERCIEMENTS vii
Notre dernier mot s'adresse à tous les membres du jury pour l'honneur qu'ils nous
font de participer à l...
Table des matières
Remerciements vi
Introduction générale 1
1 Contexte du projet 3
1.1 Présentation de l'organisme d'accue...
TABLE DES MATIÈRES ix
2.1.4 Technologies et méthodes . . . . . . . . . . . . . . . . . . . . . 13
2.1.5 La géolocalisation...
TABLE DES MATIÈRES x
3.3.3.1 Diagramme de cas d'utilisation . . . . . . . . . . . . . 31
3.3.3.2 Description textuelle de ...
TABLE DES MATIÈRES xi
5 Réalisation 54
5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 54...
Liste des gures
1.1 Les secteurs d'activité de CynapsysTM . . . . . . . . . . . . . . . . . . 4
1.2 Le cycle de vie incrém...
LISTE DES FIGURES xiii
3.8 Diagramme de séquence :  se localiser dans un bâtiment . . . . . . . 35
3.9 Diagramme de cas d'...
LISTE DES FIGURES xiv
5.8 Test et simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.9 Le plan de...
Introduction générale
LA Localisation est un sujet brûlant, en eet, l'encouragement actuel pour la lo-
calisation de pétio...
INTRODUCTION GÉNÉRALE 2
tion de la position de l'équipement. Une étude approfondie des diérentes approches
est nécessaire ...
CHAPITRE
1 Contexte du projet
Dans ce chapitre, Nous exposons le contexte général du projet. On présente en
premier lieu l...
CHAPITRE 1. CONTEXTE DU PROJET 4
des décisions de la direction ont été considérablement prises en vue de certication
CMMI ...
CHAPITRE 1. CONTEXTE DU PROJET 5
1.2 Cadre du projet
1.2.1 Contexte du projet
Ce projet intitulé Conception et développeme...
CHAPITRE 1. CONTEXTE DU PROJET 6
Validation de l'idée retenue : Le cabinet ABI Research évalue le marché de la géo-
locali...
CHAPITRE 1. CONTEXTE DU PROJET 7
étape le produit est testé exploité et maintenu dans son ensemble. Ce cycle de vie
permet...
CHAPITRE
2 Étude préalable
Eectuer une étude préliminaire détaillant les principaux concepts en rapport avec
la problémati...
CHAPITRE 2. ÉTUDE PRÉALABLE 9
2.1.1 Localisation indoor/outdoor
Jusqu'à maintenant, les signaux de navigation GPS qui sont...
CHAPITRE 2. ÉTUDE PRÉALABLE 10
Figure 2.1 Dicultés du positionnement à l'intérieur [MA13]
localisation des nourrissons, de...
CHAPITRE 2. ÉTUDE PRÉALABLE 11
rait permettre de guider l'équipe technique mobile la plus proche vers la source
du problèm...
CHAPITRE 2. ÉTUDE PRÉALABLE 12
sion d'informations spatiales de l'environnement [ecdsdteddscpsadpáremIEO13].
Il existe plu...
CHAPITRE 2. ÉTUDE PRÉALABLE 13
4. Navigation :
Les systèmes de localisation sont en générale couplé avec un système de nav...
CHAPITRE 2. ÉTUDE PRÉALABLE 14
dans un bâtiment. La position du badge est alors déterminée à l'aide de la position du
réce...
CHAPITRE 2. ÉTUDE PRÉALABLE 15
d'autres équipements sensibles ou sans l, ce qui rend les radios RF une alternative pro-
me...
CHAPITRE 2. ÉTUDE PRÉALABLE 16
cadre de la localisation par WiFi est la trame de balisage. Le point d'accès émet pé-
riodi...
CHAPITRE 2. ÉTUDE PRÉALABLE 17
position. Ces éléments doivent permettre de diérencier chacune des positions par rap-
port ...
CHAPITRE 2. ÉTUDE PRÉALABLE 18
Cette méthode présente un avantage majeur : elle n'est pas sensible aux réexions.
En eet, l...
CHAPITRE 2. ÉTUDE PRÉALABLE 19
célération, des gyroscopes mesurant des vitesses angulaires, des compas mesurant une
direct...
CHAPITRE 2. ÉTUDE PRÉALABLE 20
brutes pour construire une polyline, représentant ainsi la trajectoire de l'utilisateur.
Da...
CHAPITRE 2. ÉTUDE PRÉALABLE 21
systèmes le plus connu dans ce domaine.
2.2.1 Applications existantes
Sur le marché interna...
CHAPITRE 2. ÉTUDE PRÉALABLE 22
Figure 2.6 Avantages et inconvénients des applications du marché
2.3 Solution proposée
Un s...
CHAPITRE 2. ÉTUDE PRÉALABLE 23
2.3.1 Cartographie
Une carte interactive, visible et compréhensible est une exigence pour u...
CHAPITRE 2. ÉTUDE PRÉALABLE 24
Localisation initial : An d'obtenir la position initiale de l'utilisateur à l'instant
d'exé...
CHAPITRE 2. ÉTUDE PRÉALABLE 25
ascenseurs à l'intérieur, et aux principaux axes de circulation et aux passerelles à l'ex-
...
CHAPITRE
3 Spécication
Après avoir mis le projet dans son cadre théorique, nous venons à présenter sa
spécication. En eet,...
CHAPITRE 3. SPÉCIFICATION 27
Figure 3.1 Diagramme de contexte dynamique du système IndoorLNS
3.2.1 Besoins fonctionnels
Le...
CHAPITRE 3. SPÉCIFICATION 28
3.2.2 Les besoins non fonctionnels
Les besoins non fonctionnels peuvent être considérés comme...
CHAPITRE 3. SPÉCIFICATION 29
3.3 Analyse des besoins
Dans ce qui suit nous allons approfondir la description des besoins p...
CHAPITRE 3. SPÉCIFICATION 30
Figure 3.2 Diagramme de cas d'utilisation général de système IndoorLNS
3.3.2.1 Diagramme de c...
CHAPITRE 3. SPÉCIFICATION 31
Figure 3.3 Diagramme de cas d'utilisation : Calculer un ngerprint
3.3.2.3 Diagramme de séquen...
CHAPITRE 3. SPÉCIFICATION 32
Figure 3.4 Description textuelle de cas d'utilisation calculer un ngerprint
3.3.3.2 Descripti...
CHAPITRE 3. SPÉCIFICATION 33
Figure 3.5 Diagramme de séquence : Calcul de ngerprint
Figure 3.6 Diagramme de cas d'utilisat...
CHAPITRE 3. SPÉCIFICATION 34
Figure 3.7 Description textuelle de cas d'utilisation se localiser
3.3.3.3 Diagramme de séque...
CHAPITRE 3. SPÉCIFICATION 35
Figure 3.8 Diagramme de séquence :  se localiser dans un bâtiment
3.3.4 Description de cas d'...
CHAPITRE 3. SPÉCIFICATION 36
Figure 3.9 Diagramme de cas d'utilisation : Naviguer à l'intérieur de bâtiment
Figure 3.10  D...
CHAPITRE 3. SPÉCIFICATION 37
3.3.4.3 Diagramme d'activité
Le diagramme d'activité représente les règles d'enchaînement des...
CHAPITRE
4 Conception
La conception est un processus créatif et d'importance majeure dans le cycle de
développement d'un p...
CHAPITRE 4. CONCEPTION 39
4.1.1 Vue logique :
Un sous-système est une dénition cohérente qui traite une partie du problème...
CHAPITRE 4. CONCEPTION 40
Un sous système de cartographie pour l'extraction de données spatiales à partir
de base de donné...
CHAPITRE 4. CONCEPTION 41
Figure 4.2 Diagramme de déploiement
4.1.2.1 Le serveur d'application
Pour le serveur d'applicati...
CHAPITRE 4. CONCEPTION 42
Figure 4.3 Architecture du serveur d'application
cation et traite le logique métier contenu dans...
CHAPITRE 4. CONCEPTION 43
MapFish en Python, GeoDjango en Python et ArcGIS SDK Android... En résumé,
un serveur traite et ...
CHAPITRE 4. CONCEPTION 44
An de bien détailler l'architecture de base de données, nous avons conçu le modèle
entité/associ...
CHAPITRE 4. CONCEPTION 45
Figure 4.7 Description de la base de données
4.2.2 Conception détaillée de la couche métier
La c...
CHAPITRE 4. CONCEPTION 46
Figure 4.8 Les composants d'une application android
tant de gérer le cycle de vie d'une applicat...
CHAPITRE 4. CONCEPTION 47
Figure 4.9 Diagramme de classe
CHAPITRE 4. CONCEPTION 48
4.2.3 Conception de la couche présentation
Apprenons maintenant à présenter la couche présentati...
CHAPITRE 4. CONCEPTION 49
Figure 4.11 Module Admin
à savoir les dialogues, les contrôles et les entités. le diagramme de s...
CHAPITRE 4. CONCEPTION 50
Figure 4.12 Diagramme de navigation de l'utilisateur
4.3.2 Scénarios de Localisation
Lorsque l'u...
CHAPITRE 4. CONCEPTION 51
Figure 4.13  Diagramme de séquence détaillé du cas d'utilisation  calculer un
ngerprint
CHAPITRE 4. CONCEPTION 52
Figure 4.14 Diagramme de séquence détaillé du cas d'utilisation  se localiser
CHAPITRE
5 Réalisation
Ce chapitre constitue le dernier volet de ce rapport, il a pour objectif d'exposer le
travail achev...
CHAPITRE 5. RÉALISATION 54
Système d'exploitation : Windows 7.
Outils de développement : Eclipse ADT, Eclipse STS.
Serveur...
CHAPITRE 5. RÉALISATION 55
met de gérer vos bases de données PostgreSQL. Il fournit une interface graphique pour
votre SGB...
CHAPITRE 5. RÉALISATION 56
Figure 5.1 Fonctionnement de Geoserver
entrepôts.
Entrepôts : zone de stockage de données de mê...
CHAPITRE 5. RÉALISATION 57
la base de données PostGIS, construire des couches et les publier sous forme des web
services g...
CHAPITRE 5. RÉALISATION 58
5.1.4 JSON
C'est le format choisi pour le transfert de données entre le client android et le se...
CHAPITRE 5. RÉALISATION 59
5.2.2 Interface Homme/Machine
Dans ce qui suit, nous présentons quelques imprimes écran de notr...
CHAPITRE 5. RÉALISATION 60
Figure 5.4 Écran d'inscription
Figure 5.5 Écran d'inscription
5.3 Test et optimisation
Dans cet...
CHAPITRE 5. RÉALISATION 61
Figure 5.6 Écran du visiteur
Figure 5.7 Écran du Map User
5.3.1 Test et simulation
Le cycle de ...
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor
Prochain SlideShare
Chargement dans…5
×

Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor

6 270 vues

Publié le

La localisation et la navigation personnelles sont devenues un domaine d'envergure dans une société de mobilité. Les zones urbaines et, en particulier, les espaces fermés représentent les zones les plus exigeantes pour la navigation personnelle. Des problèmes comme la réception des signaux satellitaires rendent le positionnement impossible à l'intérieur d'un bâtiment. Parallèlement, les infrastructures de télécommunications sont en développement croissant, toutefois le positionnement basé sur ces systèmes sans fils, n'assurent pas la précision nécessaire en localisation et n'offrent pas une couverture complète. Ce projet permit le développement d'un système intelligent de positionnement et de navigation minimisant la consommation énergétique. L'approche présentée ici est basée sur l'utilisation des réseaux locaux, sur l'utilisation des mesures du déplacement de personnes par des capteurs inertiels et sur le contenu d'une base de données géographique qui représente les plans de circulation dans les espaces fermés. En utilisant cet ensemble d'information, on a développé une méthodologie, basée sur l'interaction des données, pour assurer un processus de positionnement et de navigation able.

Publié dans : Logiciels
0 commentaire
14 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
6 270
Sur SlideShare
0
Issues des intégrations
0
Intégrations
55
Actions
Partages
0
Téléchargements
14
Commentaires
0
J’aime
14
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor

  1. 1. Réf : 2014/II/ Soutenu à la session de Juin 2014 Université de la Manouba Ecole Nationale des Sciences de L'Informatique RAPPORT DE MEMOIRE DE FIN D'ETUDES Présenté en vue de l'obtention du titre d'INGENIEUR EN INFORMATIQUE Par Rim Elaire Sujet : Conception et développement d'une application de géolocalisation indoor Organisme d'accueil : Cynapsys Responsable : Mr. Souhail kchaou Encadré par : Mme Noura Baccar Supervisé par : Mme Maroua Bakri
  2. 2. Résumé LA localisation et la navigation personnelles sont devenues un domaine d'envergure dans une société de mobilité. Les zones urbaines et, en particulier, les espaces fermés représentent les zones les plus exigeantes pour la navigation personnelle. Des problèmes comme la réception des signaux satellitaires rendent le positionnement im- possible à l'intérieur d'un bâtiment. Parallèlement, les infrastructures de télécommu- nications sont en développement croissant, toutefois le positionnement basé sur ces systèmes sans ls, n'assurent pas la précision nécessaire en localisation et n'orent pas une couverture complète. Ce projet permit le développement d'un système intelligent de positionnement et de navigation minimisant la consommation énergétique. L'ap- proche présentée ici est basée sur l'utilisation des réseaux locaux, sur l'utilisation des mesures du déplacement de personnes par des capteurs inertiels et sur le contenu d'une base de données géographique qui représente les plans de circulation dans les espaces fermés. En utilisant cet ensemble d'information, on a développé une méthodologie, ba- sée sur l'interaction des données, pour assurer un processus de positionnement et de navigation able. Mots clés : Pédestre, positionnement, localisation, bâtiment, navigation, guidage, base de données cartographiques, consommation énergétique.
  3. 3. Abstract THE personal positioning and navigation became a very challenging topic in our dynamic time. The urban canyons and particularly indoors represent the most dicult areas for personal navigation problematic. Problems like disturbed satellite si- gnals make the positioning impossible indoors. Recently developed systems for indoor positioning do not assure the necessary positioning accuracy or are very expensive. Our concept stands for a fully autonomous positioning and navigation process. That is, a method that does not rely on the reception of external information, like satellite or ter- restrial signals. Therefore, this traineeship is based on the use of inertial measurements of the human walk and the map database which contains the graphic representation of the elements of the building, created by applying the link-node model. Using this reduced set of information the task is to develop methodology, based on the interaction of the data, to assure reliable positioning and navigation process. Key words : Pedestrian, localization, navigation, guidance, indoors, indoor positio- ning, map database.
  4. 4. Signatures des encadrants Prof. Maroua Bakri (ENSI) Madame Noura Baccar (Cynapsys)
  5. 5. Remerciements C'EST parce que j'ai beaucoup estimé tous ceux qui m'ont écouté, conseillé, cri- tiqué et encadré que je tiens à leur faire part de toute ma gratitude, et plus particulièrement, je tiens à remercier à travers ces courtes lignes : Monsieur Imed Ammar, Directeur Général de Cynapsys pour nous avoir prodigué l'honneur de travailler dans son équipe. Notre encadrant professionnel Madame Noura Baccar qui nous a suggéré le sujet de ce projet et qui nous a fait l'honneur de nous diriger tout au long de sa réalisation. Sa modestie et sa gentillesse n'ont d'égales que ses grandes qualités professionnelles. Qu'il soit assuré de l'expression de notre profonde gratitude. Monsieur Souhail kchaou, directeur de département de recherche et de développement à Cynapsys pour la conance qu'ils nous ont accordée, pour leur assistance continue tout au long de la réalisation de ce projet et pour le temps précieux qu'ils nous ont généreusement consacré. Monsieur Faissal Elamraoui, ingénieur informatique, pour son soutien aussi bien moral que technique. Notre superviseur Madame Maroua Bakri qui a eu la bienveillance de nous prodiguer ses conseils et de superviser ce travail. Ma famille dont je ne me permettrai pas d'oublier de la remercier, pour son soutien à la fois moral et matériel durant toute ma carrière et surtout durant les moments diciles.
  6. 6. REMERCIEMENTS vii Notre dernier mot s'adresse à tous les membres du jury pour l'honneur qu'ils nous font de participer à l'examen de notre projet, sans oublier tous nos professeurs à l'ENSI pour la formation de qualité qu'ils nous ont prodiguée tout au long de notre cursus universitaire.
  7. 7. Table des matières Remerciements vi Introduction générale 1 1 Contexte du projet 3 1.1 Présentation de l'organisme d'accueil . . . . . . . . . . . . . . . . . . . 3 1.1.1 Cynapsys Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Secteurs d'activités . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2 Problématique du projet . . . . . . . . . . . . . . . . . . . . . . 5 1.2.3 Travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Etude de faisabilité du projet . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Méthodologie et formalisme adoptés . . . . . . . . . . . . . . . . . . . . 6 1.5 Cycle de vie adopté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Étude préalable 8 2.1 État de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1 Localisation indoor/outdoor . . . . . . . . . . . . . . . . . . . . 9 2.1.2 La géolocalisation indoor : dénition et usage . . . . . . . . . . 9 2.1.3 Les enjeux de localisation indoor . . . . . . . . . . . . . . . . . 11
  8. 8. TABLE DES MATIÈRES ix 2.1.4 Technologies et méthodes . . . . . . . . . . . . . . . . . . . . . 13 2.1.5 La géolocalisation indoor hybride . . . . . . . . . . . . . . . . . 15 2.1.5.1 Le standard WiFi et la localisation indoor . . . . . . . 15 2.1.5.2 La technique de ngerprinting . . . . . . . . . . . . . 16 2.1.5.3 Le système de navigation inertiel (INS) . . . . . . . . . 18 2.1.5.4 La fusion WiFi/INS . . . . . . . . . . . . . . . . . . . 20 2.2 Étude de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.1 Applications existantes . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.2 Étude comparative . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.1 Cartographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.2 La localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.3 La navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3 Spécication 26 3.1 Les acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2 Spécication des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 28 3.3 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Diagramme de cas d'utilisation principal . . . . . . . . . . . . . 29 3.3.2 Description de cas d'utilisation calculer un ngerprint . . . . . . 29 3.3.2.1 Diagramme de cas d'utilisation . . . . . . . . . . . . . 30 3.3.2.2 Description textuelle de cas d'utilisation calculer un ngerprint . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2.3 Diagramme de séquence . . . . . . . . . . . . . . . . . 31 3.3.3 Description de cas d'utilisation se localiser dans un bâtiment 31
  9. 9. TABLE DES MATIÈRES x 3.3.3.1 Diagramme de cas d'utilisation . . . . . . . . . . . . . 31 3.3.3.2 Description textuelle de cas d'utilisation se localiser dans un bâtiment . . . . . . . . . . . . . . . . . . . . 32 3.3.3.3 Diagramme de séquence . . . . . . . . . . . . . . . . . 34 3.3.4 Description de cas d'utilisation naviguer à l'intérieur de bâti- ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.4.1 Diagramme de cas d'utilisation . . . . . . . . . . . . . 35 3.3.4.2 Description textuelle de cas d'utilisation naviguer à l'intérieur de bâtiment . . . . . . . . . . . . . . . . . 35 3.3.4.3 Diagramme d'activité . . . . . . . . . . . . . . . . . . 37 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4 Conception 38 4.1 Architecture globale de la solution . . . . . . . . . . . . . . . . . . . . . 38 4.1.1 Vue logique : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1.2 Vue de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1.2.1 Le serveur d'application . . . . . . . . . . . . . . . . . 41 4.1.2.2 Serveur Cartographique . . . . . . . . . . . . . . . . . 42 4.2 Conception détaillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.1 Conception de base de données . . . . . . . . . . . . . . . . . . 43 4.2.2 Conception détaillée de la couche métier . . . . . . . . . . . . . 45 4.2.2.1 les composants d'androïd . . . . . . . . . . . . . . . . 45 4.2.2.2 Conception de la couche métier . . . . . . . . . . . . . 46 4.2.3 Conception de la couche présentation . . . . . . . . . . . . . . 48 4.3 Scénarios de quelques cas d'utilisation . . . . . . . . . . . . . . . . . . 48 4.3.1 Scénarios de calcul de Fingerprint . . . . . . . . . . . . . . . . 49 4.3.2 Scénarios de Localisation . . . . . . . . . . . . . . . . . . . . . 50 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
  10. 10. TABLE DES MATIÈRES xi 5 Réalisation 54 5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . 54 5.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 54 5.1.3 Choix des outils de travail . . . . . . . . . . . . . . . . . . . . . 55 5.1.3.1 PostgreSQL/PostGIS . . . . . . . . . . . . . . . . . . 55 5.1.3.2 Geoserver . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.1.3.3 WMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1.3.4 Technologie JEE . . . . . . . . . . . . . . . . . . . . . 58 5.1.4 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.1 Etape de réalisation . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.2 Interface Homme/Machine . . . . . . . . . . . . . . . . . . . . 60 5.3 Test et optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.3.1 Test et simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.2 Vérication et validation . . . . . . . . . . . . . . . . . . . . . . 63 5.4 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.5 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Conclusion et Perspectives 66 Bibliographie 68 Acronymes ii A Méthodes de localisation indoor iii A.1 Received Signl Strength Indicator (RSSI) . . . . . . . . . . . . . . . . . iii A.2 Mesurer le temps de propagation des ondes (RToA, ToA, TDoA) . . . . iv A.3 Angle d'incidence (Angle of Arrival - AOA) . . . . . . . . . . . . . . . v
  11. 11. Liste des gures 1.1 Les secteurs d'activité de CynapsysTM . . . . . . . . . . . . . . . . . . 4 1.2 Le cycle de vie incrémentalTM . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Dicultés du positionnement à l'intérieur [MA13] . . . . . . . . . . . . 10 2.2 Technologies de localisation indoor . . . . . . . . . . . . . . . . . . . . 15 2.3 Principe de Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Capteurs inertiels utilisées pour la navigation . . . . . . . . . . . . . . 19 2.5 Les applications existantes . . . . . . . . . . . . . . . . . . . . . . . . 21 2.6 Avantages et inconvénients des applications du marché . . . . . . . . . 22 2.7 Décomposition de Projet . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.8 le plan de construction de Cynapsys . . . . . . . . . . . . . . . . . . . . 23 2.9 Localisation par WiFi/INS . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.10 Navigation et théorie de graphe . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Diagramme de contexte dynamique du système IndoorLNS . . . . . . . 27 3.2 Diagramme de cas d'utilisation général de système IndoorLNS . . . . . 30 3.3 Diagramme de cas d'utilisation : Calculer un ngerprint . . . . . . . . . 31 3.4 Description textuelle de cas d'utilisation calculer un ngerprint . . . 32 3.5 Diagramme de séquence : Calcul de ngerprint . . . . . . . . . . . . . . 33 3.6 Diagramme de cas d'utilisation : se localiser . . . . . . . . . . . . . 33 3.7 Description textuelle de cas d'utilisation se localiser . . . . . . . . . . 34
  12. 12. LISTE DES FIGURES xiii 3.8 Diagramme de séquence : se localiser dans un bâtiment . . . . . . . 35 3.9 Diagramme de cas d'utilisation : Naviguer à l'intérieur de bâtiment . . 36 3.10 Description textuelle de cas d'utilisation guider la navigation de l'uti- lisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.11 Diagramme de séquence : naviguer à l'intérieur du bâtiment . . . . . 37 4.1 Diagramme de composant du système IndoorLNS . . . . . . . . . . 39 4.2 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3 Architecture du serveur d'application . . . . . . . . . . . . . . . . . . . 42 4.4 Serveur cartographique . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5 Modèle entité/association de la base de données . . . . . . . . . . . . . 44 4.6 Modèle relationnel de base de données . . . . . . . . . . . . . . . . . . 44 4.7 Description de la base de données . . . . . . . . . . . . . . . . . . . . . 45 4.8 Les composants d'une application android . . . . . . . . . . . . . . . . 46 4.9 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.10 Diagramme Globale du Flux Android . . . . . . . . . . . . . . . . . . 48 4.11 Module Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.12 Module U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.13 Diagramme de séquence détaillé du cas d'utilisation calculer un n- gerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.14 Diagramme de séquence détaillé du cas d'utilisation se localiser . . 53 5.1 Fonctionnement de Geoserver . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 Structuration des données avec Geoserver . . . . . . . . . . . . . . . . . 57 5.3 Écran d'authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.4 Écran d'inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.5 Écran d'inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.6 Écran du visiteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.7 Écran du Map User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
  13. 13. LISTE DES FIGURES xiv 5.8 Test et simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.9 Le plan de Cynpasys avec les points de référence (les ngerprints) . . . 64 5.10 Test de localisation avec IndoorLNS . . . . . . . . . . . . . . . . . . . . 64 5.11 Chronogramme du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 65 A.1 Méthodes de localisation indoor . . . . . . . . . . . . . . . . . . . . . . iii A.2 Localisation par mesure des RSSI . . . . . . . . . . . . . . . . . . . . . iv A.3 Localisation par mesure de temps de propagation des ondes . . . . . . v A.4 localisation par mesure d'ongles d'arrivées des ondes radio . . . . . . . v
  14. 14. Introduction générale LA Localisation est un sujet brûlant, en eet, l'encouragement actuel pour la lo- calisation de pétions à l'intérieur des bâtiments résulte de la mise en place de nouvelles régulations et de l'évolution des besoins des usagers. L'expression services géolocalisés (en anglais, LBS pour Location-Based Services) regroupe l'ensemble de ces services basés sur la position géographique de l'utilisateur. De nombreux usages sont imaginables, et certains sont même déjà mis en place. Il existe plusieurs moyens de connaître, avec plus ou moins de précision, la position d'un appareil à l'intérieur des bâtiments. Mais, contrairement à la navigation routière, la réalisation d'un tel système de la navigation des piétons butte sur deux verrous prin- cipaux. Le premier concerne l'absence d'une cartographie susamment ne de l'espace urbain et des bâtiments. Cette cartographie est beaucoup plus dicile à obtenir que celle du réseau routier. Le second verrou technologique est l'obtention une localisation précise et able permettant de pister chaque personne à l'extérieur comme à l'intérieur d'un bâtiment. En eet, lorsque l'objet à localiser se trouve dans un environnement à ciel ouvert, le système GPS est utilisé mais cette technologie présente de sérieuses limites : elle est inopérante en intérieur et ore à l'extérieur une précision insusante pour la navigation pédestre (de l'ordre de 10 mètres), conditionné à la bonne récep- tion des signaux d'au moins trois satellites, souvent déciente dans les zones urbaines denses. Il faut donc développer d'autres techniques. Dans ce cadre, plusieurs systèmes de localisation indoor sont proposés pour résoudre le problème de localisation et de navigation dans ces environnements. Parmi ceux-ci, les systèmes de positionnement basés sur les réseaux déployés à l'intérieur comme WiFi, Zigbee, Bluetooth... Un tel système peut aussi être issu de la fusion de plusieurs tech- nologies. En eet, Les technologies indoor, prises individuellement, connaissent des limitations comme une portée limitée, ou une dérive au cours du temps. Il est alors né- cessaire de combiner plusieurs technologies de localisation à l'aide d'une infrastructure les faisant coopérer entre elles. Une telle solution doit conduire à une meilleure estima-
  15. 15. INTRODUCTION GÉNÉRALE 2 tion de la position de l'équipement. Une étude approfondie des diérentes approches est nécessaire pour prévoir la meilleure solution à déployer. Le large déploiement des réseaux WiFi, à des ns de communication, doit permettre aussi de se localiser. Cette fonctionnalité n'est pas prévue à l'origine pour ces réseaux. Cependant, des informations de puissance du signal sont disponibles au niveau des équipements déjà installés. La notion de puissance du signal est liée à la distance émetteur/récepteur puisque la puissance d'un signal diminue avec la distance. Ce type de réseau est donc un candidat potentiel et séduisant car il permet de communiquer en haut débit (transfert de données, téléphonie sur IP, etc.), et maintenant de localiser le terminal. Dans ce cadre notre travail a pour objectif de concevoir et d'expérimenter un sys- tème complet de navigation (localisation/planication/guidage) à l'intérieur des bâti- ments d'un utilisateur équipée d'un Smartphone en utilisant les réseaux locaux WiFi basée sur des technologies combinées et des algorithmes intelligents pour avoir une précision de positionnement acceptable pour ce milieu. L'organisation du rapport sera comme suit : Le premier chapitre est un chapitre introductif présentant le contexte dans lequel a été émergé le projet : le sujet, l'organisme d'accueil et la méthodologie adoptée, Le deuxième chapitre est dédié à une étude préalable et un état de l'art des travaux de recherche dans ce domaine ainsi que les grands systèmes utilisés, Le troisième chapitre comporte une spécication des besoins du projet suite à une étude de scénarios réels d'utilisation, Le quatrième chapitre est consacré pour la dinition de l'architecture de système et à la conception de ces composantes, le dernier chapitre sera dédié à la réalisation et mise en oeuvre de l'application.
  16. 16. CHAPITRE 1 Contexte du projet Dans ce chapitre, Nous exposons le contexte général du projet. On présente en premier lieu l'organisme d'accueil. Ensuite, nous présenterons le contexte du projet ainsi que les diérents facteurs qui ont suscité le besoin de notre projet et à la solution proposée. Enn, nous exposerons la méthodologie et le formalisme adoptés. 1.1 Présentation de l'organisme d'accueil 1.1.1 Cynapsys Tunisie Cynapsys, SSII en Tunisie, fondée en 2004, est considérée comme étant un acteur dynamique dans le secteur de l'ingénierie informatique. La société a pour mission de concevoir et de mettre en place des solutions parfaitement adaptées aux besoins de ses clients et partenaires. Cynapsys compte à ce jour plus de 130 collaborateurs. L'équipe CYNAPSYS est constituée d'architectes de logiciels, de programmeur, de conseillers et de chefs de projets expérimentés, hautement qualiés, et issus des grandes écoles tunisiennes, fran- çaises et allemandes. Depuis sa création, cet organisme a acquis une bonne expérience dans la gestion des projets o-shore et near-shore et a toujours l'ambition d'être un partenaire compétent auprès de ces clients à chaque étape du processus de développement logiciels. Elle a développé à ce propos, une bonne connaissance tant du marché national. A travers ses liales en France et en Allemagne, Cynapsys a su développer une connais- sance profonde du marché européen et mise actuellement sur la puissance des normes internationales. Pour ceci, et depuis 2007, elle a opté pour une démarche qualité ou
  17. 17. CHAPITRE 1. CONTEXTE DU PROJET 4 des décisions de la direction ont été considérablement prises en vue de certication CMMI niveau 3 et ISO 9001-V 2000 pour l'optimisation de la qualité des services et la standardisation des processus professionnels. Ces modèles CMMI (Capability Maturiry Model Intégration développé par le SEI-Software Engineering Institute) ISO 9001 V 2000 ont été choisi en tant que référence mondialement reconnues. 1.1.2 Secteurs d'activités CYNAPSYS opère principalement dans trois domaines technologiques diérents : J2EE, .Net et système embarqués et possède, pour la variation de son expertise et la multitude de ces compétences, des clients d'envergure internationale, telles que Sie- mens, Sagem, Orascon, Telecom, DIGI télécommunication, Tunisie Telecom... Comme le montre la gure 1.1, CYNAPSYS ore les services suivants : Développement spécique Tierce Maintenance Applicative Tierce Qualication Applicative Conseil en TIC Formation Conseil Etudes et conseil Infogérance Figure 1.1 Les secteurs d'activité de CynapsysTM
  18. 18. CHAPITRE 1. CONTEXTE DU PROJET 5 1.2 Cadre du projet 1.2.1 Contexte du projet Ce projet intitulé Conception et développement d'un système de géolocalisation indoor, est réalisé au sein du département Recherche et Développement du Groupe Cynapsys IT dans le cadre d'un stage de n d'études d'ingénieur en informatique et vient conclure notre cycle de formation ingénieurs à l'ENSI. 1.2.2 Problématique du projet La géolocalisation à l'intérieur présente plusieurs axes de recherche. Dans ce projet, l'axe principal est la mise en oeuvre d'une architecture optimisée de géolocalisation indoor par WiFi. Plusieurs technologies et techniques sont proposées pour localiser l'utilisateur dans un lieu fermé où les signaux GPS est inaccessible. Une des solutions proposées est la localisation par les ondes radio WiFi des réseaux locaux déjà déployés dans la plus par des lieux public. 1.2.3 Travail demandé L'objectif du projet est d'étudier dans un premier temps les technologies, les tech- niques et les algorithmes qui peuvent être utilisées lors de la phase de conception de notre solution et de proposer ensuite une solution à base des techniques combinées et des algorithmes intelligents. La création d'un système de géolocalisation indoor inter- actif, facile à maintenir et performant avec une précision améliorée est notre objectif principal en tenir compte du dilemme qualité-coût qui présente un challenge à prendre en considération. 1.3 Etude de faisabilité du projet La vérication de la réalisabilité du projet est nécessaire avant le lancement de la mise en oeuvre concrète du projet, bien évidement avant la phase de développement. C'est ce qu'on l'appelle étude de faisabilité.
  19. 19. CHAPITRE 1. CONTEXTE DU PROJET 6 Validation de l'idée retenue : Le cabinet ABI Research évalue le marché de la géo- localisation indoor à 4 milliards de dollars à horizon 2018. En 2014, près de 25 000 systèmes de géolocalisation indoor devraient avoir été déployés dans le monde. Tout le monde tend à améliorer la précision et de facilité la mise en place d'un tel système ce qui vérie le caractère innovant de notre idée. Etude de faisabilité technologique : Cynapsys dans son département de recherche et développement a déjà utilisé la technologie envisagée WiFi dont l'infrastructure peuvent être utiliser pour ce projet. Etude de faisabilité économique : La géolocalisation indoor par Wi-Fi s'appuie sur les réseaux Wi-Fi public ou privé existants. 1.4 Méthodologie et formalisme adoptés Nous avons utilisé, pour la spécication et la conception de ce travail, le langage de modélisation UML (Unied Modeling Langage). UML permet de décrire les besoins et documenter les systèmes ainsi que d'esquisser les architectures logicielles et il s'articule autour de neuf diagrammes dédié à la présentation d'un concept particulier du sys- tème étudié. Toutefois, pour éviter de surcharger le rapport et d'entrer dans certains détails techniques, nous ne présenterons que quelques diagrammes que nous avons jugés utiles pour comprendre le projet à savoir les diagrammes des cas d'utilisation, le dia- gramme de déploiement, le diagramme de composant, les diagrammes de paquetages les diagrammes de classes et les diagrammes de séquences. 1.5 Cycle de vie adopté Le cycle de vie d'un logiciel désigne toutes les étapes du développement d'un logiciel, de sa conception à sa disparition. Le découpage permet de valider la conformité du logiciel aux besoins exprimés et de vérier le processus de développement. Nous avons choisi, pour la conception et le développement de notre application, le cycle de vie incrémental. Ce modèle de cycle de vie prend en compte le fait qu'un logiciel peut être construit étape par étape. Il utilise le principe de diviser pour régner . Le logiciel est spécié et conçu dans son ensemble. La réalisation se fait par incréments de fonctionnalités. Chaque incrément est intégré à l'ensemble des précédents et à chaque
  20. 20. CHAPITRE 1. CONTEXTE DU PROJET 7 étape le produit est testé exploité et maintenu dans son ensemble. Ce cycle de vie permet de prendre en compte l'analyse de risques et de faire accepter progressivement un logiciel par les utilisateurs plutôt que de faire un changement brutal des habitudes. Figure 1.2 Le cycle de vie incrémentalTM 1.6 Conclusion Ce chapitre constitue une partie introductive dans laquelle une présentation des organismes d'accueil a été élaborée en premier lieu. En second lieu, une présentation des grandes lignes du sujet a été établie. Compte tenu de cette présentation, une étude de l'état de l'art est indispensable an de dénir les grands axes à développer puis d'extraire les principales fonctionnalités à satisfaire.
  21. 21. CHAPITRE 2 Étude préalable Eectuer une étude préliminaire détaillant les principaux concepts en rapport avec la problématique étudiée est un préalable incontournable à la réalisation de tout pro- jet. Dans ce chapitre, nous présentons l'étude préalable que nous avons élaborée dans le but de réussir les phases de conception et de développement de notre projet. Nous commençons notre étude par dénir les diérentes notions de base liées à la localisation indoor. Nous décrirons, ainsi, les principales méthodes et technologies adoptées pour la localisation indoor en se focalisant particulièrement sur la méthode de localisation par WiFi. Nous présentons, par la suite, une analyse critique des diérentes applications existant sur le marché suite à laquelle nous avons pu dégager les diérentes amélio- rations à apporter. Ces améliorations sont détaillées dans la Section 2.3 décrivant la solution que nous venons de proposer dans le cadre de ce projet. 2.1 État de l'art De nos jours, les techniques de localisation sont multiples. Une bonne maîtrise et connaissance de ces diverses méthodes sont nécessaires pour pouvoir dimensionner ju- dicieusement notre propre solution de localisation. Dans cette section, nous discutons les spécicités ainsi que les principaux enjeux auxquels est soumise la localisation in- door par rapport à la localisation outdoor et nous énumérons les diérentes méthodes et technologies proposées jusqu'ici pour faire face à ces enjeux. Nous présentons éga- lement une étude comparative des performances attendues des diérentes technologies employées en termes de précision, réactivité, coût, etc.
  22. 22. CHAPITRE 2. ÉTUDE PRÉALABLE 9 2.1.1 Localisation indoor/outdoor Jusqu'à maintenant, les signaux de navigation GPS qui sont utilisés pour le posi- tionnement à l'extérieur ne peuvent pas être bien captés dans les zones urbaines et à l'intérieur des bâtiments. Dans un tel environnement, le système GPS fonctionne en mode dégradé, ou ne fonctionne plus. Ces limites proviennent de : Atténuation : En eet, il est presque impossible d'acquérir et de poursuivre les si- gnaux de façon autonome à cause de l'importance des obstacles qui impliquent une forte atténuation des signaux. Les signaux reçus sont de faibles SNR [Signal- to-Noise Ratio] (30 dB de moins qu'à l'extérieur). En outre, à chaque obstacle traversé correspond une atténuation de la puissance du signal. Ce qui implique une faible précision de positionnement. Multi-trajets : De plus, le positionnement à l'intérieur est soumis aux problèmes de multi-trajets, de masquage, des interférences.. La superposition des diérents signaux qui ont suivi diérents chemins à l'antenne de réception, produit une distorsion du signal original. Le multi-trajet est la principale source de dégradation des signaux. Il peut causer une erreur de positionnement. [MA13] La gure 2.1 montre les limites d'utilisation de GPS à l'intérieur des bâtiments en représentant les diérents phénomènes exercés sur les signaux GPS. 2.1.2 La géolocalisation indoor : dénition et usage Egalement connue sous les appellations indoor location ou indoor positioning, la géolocalisation indoor permet de connaître, avec une précision plus ou moins grande, la localisation d'une personne ou d'un produit dans un espace ou un lieu fermé c'est- à-dire à l'intérieur des bâtiments [Fil14]. De nombreux usages sont imaginables, et certains sont même déjà mis en place[Blo13]. Parmi ceux-ci, on peut citer : TRANSPORTS : Permettre à un voyageur de naviguer non seulement en extérieur, mais aussi à l'intérieur d'un lieu de type aéroport, gare ou station de métro. SANTÉ : Permettre au personnel de santé de retrouver des patients ou du matériel est un besoin souvent formulé. Concrètement, une application peut permettre la géo-
  23. 23. CHAPITRE 2. ÉTUDE PRÉALABLE 10 Figure 2.1 Dicultés du positionnement à l'intérieur [MA13] localisation des nourrissons, des personnes sourant d'Alzheimer, ou des appareils spécialisés égarés. MARKETING : Il est possible de personnaliser des ores marketing, non seulement selon les don- nées connues sur le client par la marque (carte de délité) mais aussi selon le contexte géographique d'un client en magasin. AIDE À LA NAVIGATION : Dans le cas d'une navigation allant de l'outdoor à l'indoor (ex : Un client utilisant son application GPS pour se rendre de chez lui à un point d'intérêt précis situé à l'intérieur d'un centre commercial), celle-ci se doit d'être sans coutures : le mobile devra immédiatement détecter que l'utilisateur est rentré dans un bâtiment, et passer de manière transparente en mode navigation intérieure. SITES INDUSTRIELS : Une fois un problème identié sur un site industriel, une application mobile pour-
  24. 24. CHAPITRE 2. ÉTUDE PRÉALABLE 11 rait permettre de guider l'équipe technique mobile la plus proche vers la source du problème. Ensuite, une fonctionnalité d'aide à la résolution de problème type Réalité augmentée ou Télé-assistance pourrait prendre le relai si besoin. Les besoins ne manquent pas et la recherche d'une solution performante et optimale est une nécessité pour améliorer plusieurs services pour plusieurs domaines. 2.1.3 Les enjeux de localisation indoor La localisation indoor présente plusieurs enjeux qui sont traité par plusieurs sujet de recherche et à l'industrie. Les principaux enjeux sont [Blo13] : 1. La cartographie : La localisation ou le positionnement d'un objet ou d'une personne détermine son emplacement dans un certain système de référence. Donc pour pouvoir se repérer dans un bâtiment, qui est souvent un lieu fermé et privé, il est donc nécessaire de construire une cartographie des lieux, propre à chaque bâtiment, qui répertorie les obstacles xes (escaliers, portes, ...) et intermittents (panneaux d'achage,..), intégrant une mise à jour. Dans les environnements externes, à l'aide du GPS, les coordonnées sur un plan ou une carte donnée sont représentées en 2D : la longitude et la latitude. Cependant, ce type de référence ne peut être utilisé pour les espaces intérieurs où il peut exister une connectivité entre les escaliers, les murs, les portes et les diérents niveaux. Les techniques traditionnelles de cartographies n'étant pas adaptées, d'autres solutions existent parmi ceux-ci[Blo13] : • Réalisations professionelles de cartes en 2D et en 3D, basées sur les plans du bâtiment. • Google streetview s'est adapté, avec du matériel léger, pouvant tenir dans des sacs à dos. • Crowdsourcing : Google propose à sa communauté d'utilisateurs de télécharger eux-même les plans de leurs bâtiment. • SLAM (Simultaneous Localization And Mapping) ou CML (Concurrent Map- ping and Localization) : Au fur et à mesure des observations, la carte de l'en- vironnement est enrichie par de nouvelles primitives, sur lesquelles s'appuie la localisation. La position des anciennes primitives est anée en tenant compte des nouvelles observations. Une modélisation d'un espace en intérieur doit représenter essentiellement une vi-
  25. 25. CHAPITRE 2. ÉTUDE PRÉALABLE 12 sion d'informations spatiales de l'environnement [ecdsdteddscpsadpáremIEO13]. Il existe plusieurs types de modèles (sémantique, topologique, hybride..) pou- vant représenter des structures de diérents éléments d'un environnement interne (construction, design ...) ou des visions graphiques via un support de navigation. Les modèles sémantiques décrivent les diérents types d'entités présents dans un environnement indoor en termes de propriétés et de relations. Ce modèle joue un rôle important dans la localisation et la navigation. Les modèles topologiques re- présentent les connectivités des propriétés dans un espace indoor. La navigation dans les environnements internes nécessite aussi l'utilisation d'une représentation appropriée. En général, la topographie des espaces en 3D représente un aspect fondamental de la navigation en intérieur. 2. Précision du positionnement : À la diérence de la géolocalisation externe, la géolocalisation interne doit inté- grer la dimension de l'espace (c'est à dire les étages, les escaliers...) mais aussi la taille de l'espace. S'il y a plusieurs petits espaces, le système permettant la géo- localisation interne doit permettre une localisation ne pour pouvoir distinguer aisément les diérents espaces. La précision de positionnement doit être inférieure à 4 métre avec une précision de l'espace contenant la position estimé de l'utilisa- teur. La précision du positionnement est l'un des critères les plus importants pour la géolocalisation interne. 3. Infrastructures : Le prix des éléments d'un système gêne parfois le déploiement d'une technologie, et particulièrement lorsque de très nombreux éléments relativement onéreux doivent être installés. Une contrainte forte pour le déploiement de technologies dans des conditions d'applications réelles est d'être soit peu chères, soit non dédiées, ou en- core de réutiliser une infrastructure déjà existante pour d'autres raisons. Certains systèmes de géolocalisation interne ont besoin d'infrastructures et d'équipements tandis que d'autres s'appuient sur des technologies plus accessibles comme les smartphones. Les systèmes avec infrastructures bien que précis sont souvent très coûteux et diciles à mettre en place. Parfois, pour éviter d'utiliser du matériel coûteux, des systèmes de localisation se contentent d'utiliser des technologies déjà existantes dans les environnements indoor ou embarquées dans les téléphones mo- biles des utilisateurs, et n'hésitent pas à les combiner avec d'autres technologies à faible coût d'achats.
  26. 26. CHAPITRE 2. ÉTUDE PRÉALABLE 13 4. Navigation : Les systèmes de localisation sont en générale couplé avec un système de naviga- tion pour la recherche de plus court chemin pour atteindre une destination. La navigation implique plusieurs concepts : • La localisation : En se basant sur la position de l'utilisateur, le système cherche à trouver le lieu destiné et à calculer le plus court chemin pour l'atteindre. En suit le système doit suivit le déplacement de l'utilisateur en le positionnant en temps réel. • La planication d'itinéraires : Des algorithmes sont nécessaires pour trouver des chemins appropriés entre la source et la destination en fonction de la distance, du temps ou d'autres critères comme par exemple la rapidité. Ces algorithmes dé- pendent du type de modèle choisi, du contexte ou encore du prol de l'utilisateur. Des informations comme la connectivité sont essentielles pour la planication d'itinéraires. • L'orientation : L'utilisateur doit être assisté par l'application tout au long du parcours du chemin qu'il a choisi. Une idée proposée par un projet pour le calcule d'itinéraire et le guidage pour le campus de l'Ecole Polytechnique de Lausanne (EPFL)[SPA07], composé de nom- breux bâtiments et d'espaces de circulation, consiste à construire un réseau de navigation basé sur la théorie des graphes (modèle arête/noeud) a permis de dé- velopper les principales fonctions de navigation qui interagissent avec la base de données. 2.1.4 Technologies et méthodes Aujourd'hui, la localisation indoor se place au coeur de beaucoup d'activités de recherche. An d'obtenir des précisions de l'ordre du mètre ou voire meilleures, plu- sieurs technologies de proximité ont été explorées. Ils peuvent être classiés dans quatre grandes : Infrarouge (IR), Ultrason (US), localisation basée sur l'image et Radio- Fréquence (RF). Les systèmes de localisation [Eve07] basés sur la technologie IR sont parmi les pre- miers systèmes de localisation proposée pour des environnements indoor. Ces systèmes fournissent à chaque personne un badge qui émet périodiquement une identication à l'aide d'un rayon IR. Ce rayon IR est reçu par un ou plusieurs récepteurs dispersés
  27. 27. CHAPITRE 2. ÉTUDE PRÉALABLE 14 dans un bâtiment. La position du badge est alors déterminée à l'aide de la position du récepteur le plus proche. Tous les systèmes basés sur les rayons IR imposent l'existence d'un chemin direct entre l'émetteur et le récepteur, ce qui n'est pas possible dans tous les cas de gure. Il existe aussi un certain nombre de systèmes de localisation ultrasonores présentés dans la littérature : Active Bat [Ra92] et Cricket [ea00]. Ces systémes donnent un bon niveau de précision en eet les systèmes basés sur les ultrasons ont des niveaux de précision en millimètre et en centimètre. Mais ils ne sont donc pas compatibles avec les Smartphones. Cependant, ils sont sensibles au bruit et nécessitent également la présence d'un chemin direct entre l'émetteur et le récepteur. D'autres technologies basées sur le traitement des vidéos [refa] et les dispositifs recevant des images d'une scène permettent de localiser un élément dans cette scène. Avec les puissances de calcul actuelles, il est possible de construire un système de suivi visuel à une fréquence vidéo qui peut suivre de multiples cibles en utilisant simplement des processus de détection au niveau pixel. Les approches basées sur la vision pour la localisation dans les milieux internes ne reposent pas sur l'infrastructure et sont donc évolutives et pas chères. Mais cette technique possède a pour inconvénient la portée limitée du système. Dans les environnements indoor, la portée se trouve restreinte à une seule pièce (emplacement de la caméra). Ainsi, des problèmes d'identication peuvent se poser. Toutes les technologies énumérées ci-dessus ont l'inconvénient d'avoir soit des limites au niveau de la précision, soit des coûts d'installation assez élevés, soit une installation complexe et des limites techniques des dispositifs utilisées. Ces limites peuvent devenir des freins quant à leur déploiement. Face à ces limitations, la vision est une solution alternative pour une localisation précise à l'intérieur par un système autonome en minimisant le coût de déploiement. Avec l'émergence des nouveaux réseaux sans l, de nouvelles solutions peuvent être envisagées pour se localiser à l'ntérieur des bâtiments. Des précisions de l'ordre du mètre sont atteignables grâce aux réseaux locaux sans l [vdLLM+ 13]. Cette catégorie de localisation est appelé la localisation par onde radio . Les avantages des ondes radio RF sont multiples. Entre autres, les stations RF fournissent une couverture mon- diale, tandis que les tuners RF sont facilement disponibles dans de nombreux appareils mobiles. De plus, ils ont une faible consommation d'énergie et ils n'interfèrent pas avec
  28. 28. CHAPITRE 2. ÉTUDE PRÉALABLE 15 d'autres équipements sensibles ou sans l, ce qui rend les radios RF une alternative pro- metteuse pour la géolocalisation interne. Dans cette sous-section, nous avons présenté Figure 2.2 Technologies de localisation indoor diérents systèmes de localisation indoor. Dans ce qui suit, nous nous focalisons sur la localisation indoor avec les technologies WiFi/INS sur laquelle se base notre projet. 2.1.5 La géolocalisation indoor hybride 2.1.5.1 Le standard WiFi et la localisation indoor La norme IEEE 802.11 est un standard international décrivant les caractéristiques des réseaux locaux sans l (WLAN). Un réseau WiFi est un réseau répondant à la norme 802.11 [refb]. Grâce au WiFi, il est possible de créer des réseaux locaux sans ls à haut débit pour peu que la station à connecter ne soit pas trop distante par rapport au point d'accès. Des informations sur la communication sont accessibles et disponibles au niveau des interfaces physiques des cartes de communication. Les informations proviennent de trames de management émises par les points d'accès. Parmi ces trames, on trouve des trames d'authentication, d'association, etc. La trame qui nous intéresse dans le
  29. 29. CHAPITRE 2. ÉTUDE PRÉALABLE 16 cadre de la localisation par WiFi est la trame de balisage. Le point d'accès émet pé- riodiquement ces trames an de signaler sa présence et pour relayer des informations telles qu'une référence temporelle, le SSID et d'autres informations caractérisant ce point d'accès. Ces trames sont captées par les clients se trouvant dans la couverture radio de ce point d'accès. Le client, de son côté, scrute en permanence tous les canaux disponibles an de capter ces balises qui lui permettent de déterminer le point d'accès avec lequel il est plus avantageux de s'associer. Lorsque le réseau est en mode infrastructure, ces balises sont émises périodiquement. Par défaut, cet intervalle est à 100 ms, car cette valeur est optimale pour assurer de bonnes performances dans bon nombre d'applications. L'utilisation de ces trames de balisage est un bon moyen pour eectuer de la locali- sation puisqu'elles sont émises périodiquement et naturellement par le réseau. Il n'est pas nécessaire de modier la nature intrinsèque du réseau pour établir les opérations nécessaires à la localisation. Par la suite la technique de localisation présentée est basée sur l'exploitation des informations disponibles dans ces balises. Exploiter cette information de puissance n'est pas simple. La puissance du signal reçu n'est pas reliée directement à l'information de distance par une relation aussi simple que celle qu'on trouve dans les problèmes de trilatération classiques où la dis- tance est liée au temps par la relation : distance = vitesse * temps. Il existe deux manières de traiter ce problème. La première technique est le ngerprinting, ou pat- tern matching, ou bien de reconnaissance de signature. Pour cette première technique, il est nécessaire d'exploiter une base de données, constituée de mesures. La seconde technique est basée sur l'exploitation d'un modèle de propagation qui est une formu- lation mathématique de la valeur de signal que devrait capter un terminal mobile. Plusieurs degrés de complexité existent pour les modèles de propagation en fonction de la précision à atteindre. La combinaison de ces deux techniques est possible dans certaines situations, comme dans des environnements multi-étages notamment. 2.1.5.2 La technique de ngerprinting Le mot ngerprinting vient du terme ngerprint qui signie empreinte digitale. Pour fonctionner, cette technique nécessite une base de données qui à certaines posi- tions de l'environnement considéré associe un ensemble d'éléments caractérisant cette
  30. 30. CHAPITRE 2. ÉTUDE PRÉALABLE 17 position. Ces éléments doivent permettre de diérencier chacune des positions par rap- port aux autres positions de l'environnement. Si cette condition n'est pas réalisée dans ce cas les éléments considérés pour composer cette emprunte ne sont pas signicatifs. Les caractéristiques du signal qui sont choisies pour constituer les ngerprints ont évi- demment une grande inuence sur la précision de la localisation. Les caractéristiques les plus couramment utilisées sont les puissances reçues, ou Received Signal Strength Indicators (RSSI) [ecdsdteddscpsadpáremIEO13]. Cet algorithme présente deux étapes distinctes représenté dans la gure 2.3 : Phase oine : Construction des cartes de couverture radio : Pour obte- nir des cartes de couverture radio réalistes, les systèmes RF construisent une carte de couverture radio en mesurant expérimentalement la puissance du signal des points d'accès en un nombre ni de points. La construction de cette base est dé- nommée phase oine . La carte de couverture obtenue est stockée dans une base de données qui répertorie les niveaux de signaux reçus de chaque point d'accès en un point du plan. Phase online : Localisation d'un utilisateur mobile : Dans la phase on- line , est quant à elle, l'utilisateur normale du système où l'élément mobile se localise dans l'environnement. Pour ce faire, le système mesure la puissance des signaux reçus par les points d'accès visibles. A l'aide de la base de données créée pendant la phase oine, il cherche à localiser le point de la base pour lequel on observe un ensemble de signaux similaire aux signaux mesurés. Figure 2.3 Principe de Fingerprinting
  31. 31. CHAPITRE 2. ÉTUDE PRÉALABLE 18 Cette méthode présente un avantage majeur : elle n'est pas sensible aux réexions. En eet, l'intensité du signal ne représente plus une notion de distance, mais une indication d'emplacement traitée dans son état le plus brut. Cependant, elle comporte certains inconvénients. En eet, nous cherchons à obtenir un système non gourmand en ressources et assez dynamique. La phase de localisation telle que décrit précédemment suppose que cette matrice de localisation soit enregistrée en mémoire de mobile ou sur un serveur distant et dans les deux cas la recherche dans la matrice peut également être une opération coûteuse en ressources, ce qui répercutera sur l'autonomie de la batterie. En plus, la matrice de localisation est fastidieuse à réaliser. Si l'environnement change, la carte des ngerprints n'est plus invalide. Il est nécessaire alors de car- tographier à nouveau la zone an d'avoir une matrice à jour. La précision moyenne d'une information de localisation obtenue à partir de cette technique de ngerprinting de donnée WiFi est médiocre, environ 3m. Cette précision pourrait être améliorée en densiant les mesures d'initialisation de la base de données de vecteurs RSS. 2.1.5.3 Le système de navigation inertiel (INS) Le système de navigation inertiel (INS) utilise un ou plusieurs capteurs délivrant des informations quant au comportement de l'utilisateur. Ces capteurs sont embarqués sur le mobile lui même. L'exploitation des équations de la mécanique, comme l'équation du mouvement, permet de déterminer la position du mobile à partir des informations délivrées par les diérents capteurs. Plusieurs systèmes de navigation cherchent à combiner cette navigation inertielle avec d'autres technologies de navigation comme GPS et WiFi par exemple. En ef- fet, le service GPS est parfois momentanément indisponible quand un véhicule circule dans un tunnel. L'application de localisation ne dispose alors plus d'informations de localisation par GPS. En exploitant les informations de navigation inertielle, on peut fournir à l'application de navigation une estimation de la position issue du traitement des mesures relevées par des capteurs de navigation inertielle, tant que le service de navigation GPS reste indisponible. On obtient une bonne précision sur la localisation d'un véhicule sur une vingtaine de kilomètres sans que le GPS soit disponible. Aujourd'hui, plusieurs capteurs ont été intégrés dans les smartphones. Générale- ment, les capteurs utilisés pour la navigation sont des accéléromètres mesurant l'ac-
  32. 32. CHAPITRE 2. ÉTUDE PRÉALABLE 19 célération, des gyroscopes mesurant des vitesses angulaires, des compas mesurant une direction par rapport au nord magnétique, des sondes barométriques... La gure 2.4 montre le concept de base de l'utilisation des capteurs inertiels pour notre système de navigation. Pour orir une expérience de navigation en continu, la localisation de Figure 2.4 Capteurs inertiels utilisées pour la navigation l'utilisateur doit être en temps réel, pour cela notre système utilise les capteurs inertiels avec l'algorithme de Piéton Dead Reckoning (PDR). La principale idée de cet algorithme (PDR) est d'utiliser les signaux des accéléro- mètres pour détecter les pas, estimer la longueur d'un pas et extrapoler la position en utilisant une direction mesurée. Le cap peut être calculé en utilisant un gyroscope ou un magnétomètre. L'utilisation d'un magnétomètre n'est pas la meilleure solution pour une navigation urbaine parce qu'une boussole est fortement sujette aux pertur- bations magnétiques provoquées par les lignes électriques, les objets et les structures métalliques. On considère une personne équipée d'un système qui contient l'ensemble des cap- teurs inertiels. La vitesse, la direction de marche et l'altitude sont mesurés par les capteurs et datés à chaque pas de la personne. L'algorithme PDR utilise ces mesures
  33. 33. CHAPITRE 2. ÉTUDE PRÉALABLE 20 brutes pour construire une polyline, représentant ainsi la trajectoire de l'utilisateur. Dans cette approche de localisation, l'association de la trajectoire de l'utilisateur avec le contenu de la base de données géographique (le graphe) prend une place centrale, ce processus est appelé map-matching [Dra04]. 2.1.5.4 La fusion WiFi/INS On veut utiliser la technologie INS pour améliorer la couverture du service de lo- calisation, améliorer la précision de localisation avec WiFi, minimiser les ressources utilisées et minimiser l'erreur de l'estimation de position. La collaboration entre ces deux technologies permet la corrigent mutuellement des resultats obtenues par chaque technologie à part. En eet, la localisation avec wi donne une précision entre 2 et 3 mètre sans ltre et entre 1.5 m et 2 m avec des outils de ltrage alors que un système de localisation avec fusionnement WiFi/INS donne une précision entre 1 m et 1.5 m. Pour fonctionner, le système doit connaître au préalable sa position de départ. À cause de l'intégration des données au cours du temps, le bruit entachant les me- sures conduit à une dérive de la position estimée. Pour notre système de localisation, nous proposons une architecture permettant d'exploiter les données WiFi pour initia- liser/resynchroniser les données INS et les données INS pour guider l'estimateur de localisation WiFi. Le Dead Reckoning (navigation à l'estime) consiste à prolonger le signal du WiFi dans les endroits où il n'est pas disponible ou erroné. Nous utilisons pour cela des capteurs (accéléromètres et gyroscopes) mesurant le déplacement instantané du mobile par inertie. On part d'une position connue WiFi et le déplacement est ajouté à la position précédente pour calculer la position actuelle. 2.2 Étude de l'existant Nous retrouvons aujourd'hui des systèmes de géolocalisation indoor dans plusieurs types de lieux fermés comme les aéroports, les centres commerciaux ou culturels, les parcs d'expositions. Cette section présente les systèmes de localisation indoor avec WiFi mise en place sur le marché international dans le but d'améliorer notre système qui doit être capable d'entrer en concurrence avec ce qui existe. Nous avons choisi les
  34. 34. CHAPITRE 2. ÉTUDE PRÉALABLE 21 systèmes le plus connu dans ce domaine. 2.2.1 Applications existantes Sur le marché international, il apparait plusieurs systèmes de géolocalisation indoor depuis 2011. Les grands acteurs de l'informatique dans le monde cherche à développer un tel système parmi ces acteurs on peut citer : Google, Apple, orange, Pole Star, Insiteo... Ces systèmes sont actuellement disponibles dans certains pays. Le tableau de la gure 2.5 présente des exemples des applications de géolocalisation en précisant leurs précisions de positionnement et des exemples des bâtiments utilisant ces systèmes. Figure 2.5 Les applications existantes 2.2.2 Étude comparative Dans cette sous-section, nous étudions les avantages et les inconvénients des sys- tèmes cités précédemment avec le tableau de la gure 2.6. Après cette étude compara- tive, Nous pouvons envisager des caractéristiques de notre système de géolocalisation tels que la précision de l'application qui ne doit pas dépasser le trois mètre en assurant sa performance et en minimisant le temps de calcule.
  35. 35. CHAPITRE 2. ÉTUDE PRÉALABLE 22 Figure 2.6 Avantages et inconvénients des applications du marché 2.3 Solution proposée Un système de géolocalisation est en générale décomposable en trois grandes parties comme il est représenté dans la gure2.7. Figure 2.7 Décomposition de Projet
  36. 36. CHAPITRE 2. ÉTUDE PRÉALABLE 23 2.3.1 Cartographie Une carte interactive, visible et compréhensible est une exigence pour un système de localisation et de navigation performant. Le calcule de positionnement de l'utilisateur, de l'itinéraire et de plus court chemine nécessite des données spatiaux correspond aux structure des bâtiments et de relation topologique entre ces diérents composants. Pour la cartographie de notre solution, nous avons utilisé les données cartogra- phiques extraites et enregistrées dans une base de données. Cette approche nécessite l'extraction des données à partir des plans de construction des bâtiments lors de la phase préliminaire à n de construire une base de données contient des locaux et des détails de construction sous la forme de polygones, de droites et d'arcs de cercles. L'utilisation de cette approche nécessite une modélisation sémantique et topologique de bâtiment à nan d'assurer la connectivité les connectivités entre les escaliers et les diérentes zones d'un espace indoor. Nous travaillerons sur le plan de construction de Cynapsys montré dans la gure2.8. Figure 2.8 le plan de construction de Cynapsys 2.3.2 La localisation La capacité de positionnement de l'utilisateur est une partie nécessaire d'un système de navigation. Pour la localisation, comme on a expliqué, nous utilisons la technologie WiFi avec l'algorithme de ngerprinting et les technologies INS avec l'algorithme de Dead Reckoning (PDR). Il y a deux étapes de localisation :
  37. 37. CHAPITRE 2. ÉTUDE PRÉALABLE 24 Localisation initial : An d'obtenir la position initiale de l'utilisateur à l'instant d'exécution de l'application, le système IndoorLNS utilise l'algorithme de nger- printing en scannant les puissance des signaux WiFi (RSSI) provenant de diérents point d'accès et en les comparant avec les enregistrements de base de données des ngerprints. Localisation contenu : La deuxième partie est consacrée à la localisation continue, où la position de l'utilisateur est estimée à chaque pas. Nous avons testé la tech- nologie INS et nous avons trouvé qu'on peut avoir une bonne estimation de posi- tionnement pendant 5 secondes. Au delà de cet intervalle, la précision de système diminue à cause d'accumulation des erreurs des capteurs inertiels. Par conséquence, dés que l'utilisateur commence à naviguer, nous utilisons les capteurs inertiels de Smartphone pendant 5 secondes puis nous réinitialisons la position avec la mé- thode de ngerprinting... la gure 2.9 montre l'enchainement de localisation par WiFi/INS. Figure 2.9 Localisation par WiFi/INS 2.3.3 La navigation Pour assurer le service de navigation, nous utilisons la théorie des graphes (modèle arête/noeud) (Figure.2.10). Les arêtes correspondent aux couloirs, aux escaliers et aux
  38. 38. CHAPITRE 2. ÉTUDE PRÉALABLE 25 ascenseurs à l'intérieur, et aux principaux axes de circulation et aux passerelles à l'ex- térieur et les noeuds représentent des portes, des jonctions, des connecteurs d'étages et des points d'intérêt. Ensuite, On peut se baser sur un algorithme classique (Dijkstra) pour calculer du chemin optimal. Une fois que la position de l'utilisateur est connue, il est facile de calculer le chemin jusqu'à son point de destination et de lui indiquer les directions à suivre. Le problème est d'assurer la continuité du processus de la naviga- tion dans le cas où la personne a perdu ou quitté son chemin. Dans ce cas la solution consiste à donner de nouvelles instructions à l'utilisateur pour retrouver son chemin ou à calculer un nouveau chemin depuis la position courante de l'utilisateur jusqu'à son point de destination. Cette approche est entièrement dépendante de la qualité de localisation continue. Figure 2.10 Navigation et théorie de graphe 2.4 Conclusion Nous avons présenté, tout au long de ce chapitre, les principaux concepts liés à notre projet. Nous vons également menée une étude critique de l'existant qui nous a permis de déterminer les méthodes et technologies adéquates à adopter dans notre solution et dégager les améliorations à apporter lors de la réalisation de notre projet. En se basant sur cette étude, nous nous proposons d'entamer la phase de conception que nous détaillerons dans le chapitre qui suit.
  39. 39. CHAPITRE 3 Spécication Après avoir mis le projet dans son cadre théorique, nous venons à présenter sa spécication. En eet, une première partie de ce chapitre sera consacrée à énoncer les diérents besoins fonctionnels auxquels devrait répondre l'application à réaliser, ainsi que les besoins non fonctionnels que l'application à développer devrait respecter. Une seconde partie sera guidée par l'élaboration des diérents cas d'utilisation qui sont dénis comme un ensemble de scénarios d'utilisation, chaque scénario représentant une séquence d'interaction des acteurs avec le système. 3.1 Les acteurs du système Le système IndoorLNS a comme fonction principale la navigation et la localisation des visiteurs d'un bâtiment. Cette fonction met en interaction deux acteurs avec le système (Figure 3.1) : L'administrateur : c'est le propriétaire ou le responsable d'un site public, centre commerciale, entreprise, aéroport, hôpital... qui veut permettre à ces visiteurs de se localiser en temps réel en utilisant notre application. L'utilisateur : c'est un visiteur de bâtiment qui veut se localiser et naviguer à l'inté- rieur de ce lieu fermé. 3.2 Spécication des besoins Dans cette partie, nous allons dénir les diérents besoins fonctionnels et non fonc- tionnels de notre solution IndoorLNS.
  40. 40. CHAPITRE 3. SPÉCIFICATION 27 Figure 3.1 Diagramme de contexte dynamique du système IndoorLNS 3.2.1 Besoins fonctionnels Les besoins fonctionnels doivent répondre aux exigences du futur système en termes de fonctionnalités. Ils constituent une sorte de promesse ou de contrat au comporte- ment du système généré. De ce fait, La solution proposée doit répondre aux besoins fonctionnels suivants : acher une carte de bâtiment claire et facile à lire par un utilisateur. permettre à positionner l'utilisateur par rapport au plan de bâtiment en temps réel. permettre à l'utilisateur de chercher une destination et naviguer en représentant le chemin optimal pour lui arriver. ger/déger la carte : permet de reprendre la mise à jour automatique de la posi- tion. permettre d'acher les informations en cliquant sur les lieux de bâtiment visité : info bull. permettre à l'utilisateur d'évaluer la précision de positionnement. permettre à l'utilisateur d'enrichir la base de données relative au plan du centre par des notications de précision (impression, évaluation, commentaires...) permettre à l'administrateur de mettre en place la plateforme, de la maintenir et de consulter les statistiques des utilisateurs et ses avis sur l'application.
  41. 41. CHAPITRE 3. SPÉCIFICATION 28 3.2.2 Les besoins non fonctionnels Les besoins non fonctionnels peuvent être considérés comme des besoins fonctionnels spéciaux. Parfois, ils ne sont pas rattachés à un cas d'utilisation particulier, mais ils caractérisent tout le système (l'architecture, la sécurité, le temps de réponse, etc...). Le système doit garantir les besoins opérationnels suivants : Besoins matériels : Le système doit s'exécuter de la même façon sur les diérentes catégories des Smartphones androïde disponibles sur le marché. Besoins de déploiement : Le système doit : S'adapter à l'infrastructure Wi déployée au sein du bâtiment. Assurer la facilité de la mise en place et du déploiement de l'application de localisation indoor Besoins de performance : Le système devra répondre rapidement au besoin de l'utilisateur : Délai d'acquisition de la première position au lancement de l'application : 5 seconde Taux de rafraîchissement de la position : jusqu'à une fois par seconde. Pas de latence, rafraichissement de la position en temps réel. Précision : La précision de système doit être bornée entre 2 à 3 mètre. Besoins de disponibilité /abilité : Le système doit : être disponible pour les utilisateurs lorsqu'il le demande donc une utilisation 24/24 heures, 7/7 sauf période de maintenance et mise à jours de carte de ngerprints. fonctionner correctement lors de la demande de l'utilisateur. Besoins de robustesse : Le système doit être capable de s'adapter aux changements de l'environnement, et à la nature de l'indoor (obstacles, murs, mobilités des acteurs, lumières...). être robuste face à l'instabilité du signal Wi (l'aaiblissent, Le fading, Le shadowing) Besoins de maintenance : Le système doit être facile à installer et à maintenir. Besoins de exibilité : Le système doit être souple pour une extension future. L'ergonomie des interfaces : Le module doit présenter une interface claire, ergono- mique et intuitive.
  42. 42. CHAPITRE 3. SPÉCIFICATION 29 3.3 Analyse des besoins Dans ce qui suit nous allons approfondir la description des besoins précédemment spéciés par construction des diagrammes de cas d'utilisation correspondants avec une description des scénarios associés, par la suite nous proposons quelques diagrammes de séquence pour une meilleure visibilité de l'application conçue. 3.3.1 Diagramme de cas d'utilisation principal Les cas d'utilisation permettent de dénir d'une manière normalisée les relations fonctionnelles entre les acteurs et le système étudié. Ils sont une représentation orientée fonction du système, et permettent de modéliser les attentes des utilisateurs. La gure 3.2 illustre les diérents cas d'utilisation de l'application IndoorLNS des acteurs précédemment identiés. Ce diagramme décrit une vue générale de l'ensemble des cas d'utilisation relatifs à notre système et décrire éventuellement les diérents scénarios susceptibles d'avoir lieu. Une description détaillée des diérents cas d'utilisation que nous avons développé (Calculer les ngerprints, se localiser dans le bâtiment, naviguer vers une destination) sera alors faite dans la suite. Nous allons maintenant décrire de façon détaillée les cas d'utilisation an d'obtenir une expression précise des besoins avant d'attaquer la conception. Pour détailler la dynamique du cas d'utilisation, la façon la plus simple de procéder consiste à recenser textuellement toutes les interactions entre les acteurs et le système. Nous complétons la description textuelle des cas d'utilisation par un diagramme d'activité ou un diagramme de séquence. 3.3.2 Description de cas d'utilisation calculer un ngerprint Comme on a expliqué, l'administrateur de l'application calcule les forces de signaux des diérents points d'accès (RSSI) pour une position donnée. Ces signaux représente une caractéristique qui identié cette position par rapport aux autres positions de bâ- timent. Cette position avec ces caractéristiques est appelé ngerprint . Ce calcule est eectué au cours de la phase oine (phase d'apprentissage) et aussi pour la mainte- nance de système de localisation lors d'une modication de l'environnement (ex : ajout d'une point d'accès ou retire d'une point d'accès).
  43. 43. CHAPITRE 3. SPÉCIFICATION 30 Figure 3.2 Diagramme de cas d'utilisation général de système IndoorLNS 3.3.2.1 Diagramme de cas d'utilisation Le diagramme de cas d'utilisation de la gure 3.3 présente les étapes par lesquelles l'administrateur doit passer pour arriver à créer un ngerprint. 3.3.2.2 Description textuelle de cas d'utilisation calculer un ngerprint La che de description textuelle d'un cas d'utilisation n'est pas normalisée par UML. Le tableau représenté dans la gure 3.4 représente une description textuelle de la cas d'utilisation calculer un ngerprint.
  44. 44. CHAPITRE 3. SPÉCIFICATION 31 Figure 3.3 Diagramme de cas d'utilisation : Calculer un ngerprint 3.3.2.3 Diagramme de séquence Nous représentons le diagrammes de séquence système d'un scénario représentatif de la cas d'utilisation calculer un ngerprint décrit précédemment dans la gure 3.5. 3.3.3 Description de cas d'utilisation se localiser dans un bâ- timent Comme on a expliqué, la localisation de l'utilisateur passe par deux grandes étapes la localisation initial avec WiFi par l'algorithme ngerprinting et la localisation conti- nue en fusionnant les mesures calculées par les capteurs de Smartphones et l'algorithme de ngerprinting. Ces deux technologies de localisation se corrigent mutuellement pour donnée une précision améliorée et pour minimiser l'erreur de positionnement. 3.3.3.1 Diagramme de cas d'utilisation La localisation est la principale fonctionnalité du système IndoorLNS. La gure 3.6 présente le diagramme de cas d'utilisation se localiser.
  45. 45. CHAPITRE 3. SPÉCIFICATION 32 Figure 3.4 Description textuelle de cas d'utilisation calculer un ngerprint 3.3.3.2 Description textuelle de cas d'utilisation se localiser dans un bâ- timent Le tableau de la gure 3.7 représente la description textuelle de la cas d'utilisa- tion se localiser dans un bâtiment pour montrer l'enchainement des messages entre l'utilisateur et le système.
  46. 46. CHAPITRE 3. SPÉCIFICATION 33 Figure 3.5 Diagramme de séquence : Calcul de ngerprint Figure 3.6 Diagramme de cas d'utilisation : se localiser
  47. 47. CHAPITRE 3. SPÉCIFICATION 34 Figure 3.7 Description textuelle de cas d'utilisation se localiser 3.3.3.3 Diagramme de séquence Le diagramme de séquence système qu'illustre la gure 3.8 suivante décrit le cas d'utilisation se localiser dans un bâtiment.
  48. 48. CHAPITRE 3. SPÉCIFICATION 35 Figure 3.8 Diagramme de séquence : se localiser dans un bâtiment 3.3.4 Description de cas d'utilisation naviguer à l'intérieur de bâtiment Naviguer signie chercher un lieu destiné, tracer le chemin optimal vers ceux-ci et orienter l'utilisateur pour arriver à sa destination. La navigation nécessite une locali- sation contenue et en temps réel. 3.3.4.1 Diagramme de cas d'utilisation Le diagramme de cas d'utilisation représenté dans la gure 3.9 rane le cas d'uti- lisation naviguer à l'intérieur de bâtiment . 3.3.4.2 Description textuelle de cas d'utilisation naviguer à l'intérieur de bâtiment La description textuelle de cette cas d'utilisation est réprésenté dans le tableau de la gure 3.10.
  49. 49. CHAPITRE 3. SPÉCIFICATION 36 Figure 3.9 Diagramme de cas d'utilisation : Naviguer à l'intérieur de bâtiment Figure 3.10 Description textuelle de cas d'utilisation guider la navigation de l'utilisateur
  50. 50. CHAPITRE 3. SPÉCIFICATION 37 3.3.4.3 Diagramme d'activité Le diagramme d'activité représente les règles d'enchaînement des actions et déci- sions au sein d'une activité. Il permet d'une part de consolider la spécication d'un cas d'utilisation, d'autre part de concevoir une méthode. Le diagramme d'activité qu'illustre la gure 3.8 suivante décrit le cas d'utilisation naviguer à l'intérieur du bâtiment. Figure 3.11 Diagramme de séquence : naviguer à l'intérieur du bâtiment 3.4 Conclusion Dans ce chapitre, nous avons cerné les objectifs de notre application. Ces objec- tifs doivent tenir compte des problèmes de la solution existante. Cette phase va nous permettre de bien élaborer le modèle de conception de l'application. Dans le prochain chapitre nous aborderons la partie conception décrivant la modélisation des besoins exprimés dans cette section.
  51. 51. CHAPITRE 4 Conception La conception est un processus créatif et d'importance majeure dans le cycle de développement d'un projet. Ainsi ce chapitre sera consacré à la présentation des dif- férentes étapes de la conception de notre application, et an de présenter au mieux cette partie nous allons donner une vue globale décrivant l'architecture générale de notre système an d'en extraire les diérents modules qui le composent. Puis, nous allons détailler chacun de ces modules conformément à la notation UML, en présentant les vues statiques décrivant l'état physique du système via le diagramme de compo- sants, le diagramme de déploiement et des diagrammes de classe, les vues dynamiques montrant le fonctionnement du système via des diagrammes de séquences basés sur quelques scénarios bien déterminés et la conception de base de données en utilisant le représentation entité-relation. 4.1 Architecture globale de la solution L'architecture d'un système est sa conception de haut niveau. L'architecture in- formatique dénit la structuration d'un système informatique, matériel et logiciel, en termes de composants et d'organisation de ses fonctions. Les vues structurelles d'une architecture logicielle sont : La vue logique qui dénit les principaux composants d'une architecture sans se soucier des détails physiques (équipements, machines...). La vue physique qui est une description de l'intégration et de la distribution de la partie logicielle sur la partie matérielle.
  52. 52. CHAPITRE 4. CONCEPTION 39 4.1.1 Vue logique : Un sous-système est une dénition cohérente qui traite une partie du problème déni en termes des services qu'il fournit. C'est un ensemble de classes, d'associa- tions, d'opérations, d'événements, de contraintes, ayant des interfaces bien dénies et restreintes avec les autres sous-systèmes. La division du système en sous-systèmes indé- Figure 4.1 Diagramme de composant du système IndoorLNS pendants et faiblement couplés, chacun fournissant un type de service permet de réduire la complexité de conception et de développement de l'application. Le diagramme de composants peut servir à représenter la vue logique d'une architecture en dénissant les principaux composants d'une architecture sans se soucier des détails physique de déploiement. Le système IndoorLNS est composé par les sous systèmes suivants (réf. Figure.4.1) : Un sous système de localisation chargé d'implémenter les algorithmes de localisa- tion déjà expliqués. Un sous système de Navigation pour la recherche d'un lieu et la calcule d'itinéraire.
  53. 53. CHAPITRE 4. CONCEPTION 40 Un sous système de cartographie pour l'extraction de données spatiales à partir de base de données et l'achage de la carte, de la position calculée, de l'itinéraire trouvé et des informations des diérents lieux. Une sous système pour l'évaluation de l'application par les utilisateurs. La conception d'un sous-système est indépendante et sans aectation sur les autres sous-systèmes ce qui nous permet de minimiser la complexité de conception et de développement. 4.1.2 Vue de déploiement Le modèle de conguration matérielle a pour but d'exprimer les contraintes de mise en oeuvre au niveau physique. On y trouve les noeuds et les connexions physiques du système, qui sont les diérents types de machines connectées par des moyens divers. Les modèles de déploiement et de conguration matérielle s'expriment tous deux à l'aide d'un diagramme de déploiement. Un système de localisation exige le suivie le déplacement de l'utilisateur en temps réel. Cependant la capacité de calcul de certains terminaux étant limitée, les méthodes de localisation nécessitant des calculs lourds nécessiteront l'utilisation d'un serveur plus puissant pour les eectuer. La Figure 4.2 représentant le diagramme de déploiement de notre système décrit la répartition phy- sique des fonctions-métiers du système et la localisation des diérents serveurs. On a décidé d'utiliser deux serveur l'un pour la cartographie du bâtiment spécialisé dans la gestion d'information géographique, ce système permet d'acher des objets spa- tiaux rendus accessibles au travers d'un réseau et l'autre un serveur d'application pour localiser les terminaux mobiles. Les composantes décrites par le diagramme de composantes peuvent être déployé sur diérents machines en même temps. Par exemple, la composante localisation implémentée sur la partie client Android et sur le serveur d'application. Le diagramme de déploiement représenté dans la gure 4.1 montre l'utilisation d'un serveur données spatial PostGIS, une extension de PostgreSQL, GeoServeur comme un serveur carto- graphique, un serveur d'application J2EE et un client Android. Nous détaillons les architectures de ses noeuds (équipements) et les connecteurs qui les relient.
  54. 54. CHAPITRE 4. CONCEPTION 41 Figure 4.2 Diagramme de déploiement 4.1.2.1 Le serveur d'application Pour le serveur d'application on a utilisé la plateforme J2EE avec une architecture en couche. Parmi les diérentes façons de structurer une architecture, la mieux comprise et maîtrisée en informatique est l'approche par couches. Une couche (Layer en anglais) est une division logique, horizontale d'un système qui fournit une abstraction particulière du système aux couches supérieures. Chaque couche possède des rôles spéciques. Dans une structuration par couches, les couches inférieures prennent en charge des rôles qui orent un fonctionnement de base pour les couches supérieures, permettant par la suite d'abstraire l'implémentation de ces services basiques. Une telle architecture permet également d'obtenir un bon niveau de réutilisation, à travers l'utilisation des solutions aux problèmes ayant un fonctionnement similaire. La gure.4.3 représente l'architecture du serveur d'application. La couche Persistance : Cette couche est responsable du stockage physique de données. Elle assure le support transactionnel. En ce qui concerne notre système, cette couche se basera sur le modèle relationnel. La Couche Domaine : Cette couche est certainement l'une des plus impor- tantes, c'est ici où se trouve les fonctionnalités de base qui permettent de créer, rechercher, modier et supprimer les entités métier dans le respect des propriétés transactionnelles. La Couche Services : La couche service reçoit les requêtes de la couche appli-
  55. 55. CHAPITRE 4. CONCEPTION 42 Figure 4.3 Architecture du serveur d'application cation et traite le logique métier contenu dans ces requêtes. C'est un package qui comporte les classes chargées, d'une part, de garantir la validation sémantique de l'information métier, et d'autre part, de gérer l'interaction avec la base de don- nées. La communication avec la couche Application se fait à travers les interfaces services. La Couche métier : Ces services correspondent aux règles du métier dénies lors de la phase d'analyse. Elle prend en charge les aspects de contrôle des cas d'utilisation. La couche métier du serveur est exposée au client via un service REST (REpresentational Rest Transfer). La Couche web/REST : représente l'interface entre la couche métier et les services web. 4.1.2.2 Serveur Cartographique Un serveur cartographique, comme leur nom l'indique, serve des cartes sous formes de services, dénis par l'OGC (Open Geospatial Consortium). Parmi les serveurs gra- tuits, on trouve MapServer, GeoServer, ArcGis Server... Parmi les formes des services, on trouve WMS qui signie Web Map Service. C'est un protocole déni par l'Open Geospatial Consortium (OGC) permettant au moyen d'une URL formatée d'interroger des serveurs cartographiques et d'obtenir ainsi des cartes géo-référencées. Pour traiter ces services, il faut des librairies ou des programmes. Parmi les librairies qui permettent de le faire dans un navigateur, il y OpenLayers, GeoExt, Leaet etc. en JavaScript,
  56. 56. CHAPITRE 4. CONCEPTION 43 MapFish en Python, GeoDjango en Python et ArcGIS SDK Android... En résumé, un serveur traite et fournit les données, une librairie traite les services. La gure 4.2 présente cette architecture de service cartographique. On a utilisé pour le serveur car- Figure 4.4 Serveur cartographique tographique GeoServer et pour la communication entre le client android et le serveur cartographique se fait par un web service WMS. Côtè client, on a utilisé ArcGIS SDK Android pour l'interrogation de ces services. 4.2 Conception détaillé 4.2.1 Conception de base de données La principale question concernant la mise en oeuvre de la base de données est : Comment organiser et stocker toutes les informations utilisées dans la navigation In- doorLNS à savoir la géométrie et topologie du plan, les informations des signaux WiFi dans la base de données pour servir les principales fonctionnalités oertes par ce sys- tème, à savoir la localisation et navigation? L'objectif de l'application IndoorLNS est la localisation et la navigation, ainsi le modèle de données doit fournir une structure ecace pour les requêtes spatiales et calcul d'itinéraire. La base de données doit contenir des données concernant les données géométriques représentant la structure du bâtiment, des données concernant le réseau topologique pou la navigation, des données concernant l'algorithme de localisation par ngerprinting liée aux forces des signaux des diérents points d'accès et les données des utilisateurs.
  57. 57. CHAPITRE 4. CONCEPTION 44 An de bien détailler l'architecture de base de données, nous avons conçu le modèle entité/association représenté dans la gure 4.5 et un modèle relationnel donné par la gure 4.6. Figure 4.5 Modèle entité/association de la base de données Figure 4.6 Modèle relationnel de base de données Le tableau représenté dans la gure.4.7 explique les diérents tables de la base de données.
  58. 58. CHAPITRE 4. CONCEPTION 45 Figure 4.7 Description de la base de données 4.2.2 Conception détaillée de la couche métier La couche métier de l'application est distribuée sur le client androïde, le serveur cartographique et le serveur d'application. Pour bien expliquer la conception de la couche métier, on va commencer par une présentation des diérents composants android qui représente la spécicité de ce système. 4.2.2.1 les composants d'androïd Le SDK d'Android propose un modèle de composants et des APIs pour gérer dif- férents dispositifs qui font la particularité des plateformes mobiles : connectivité, cap- teurs, téléphonie, multimédia ... L'activité est le premier composant essentiel permet-
  59. 59. CHAPITRE 4. CONCEPTION 46 Figure 4.8 Les composants d'une application android tant de gérer le cycle de vie d'une application et l'interactivité avec l'utilisateur mais qu'en est-il lorsqu'on souhaite exécuter un traitement en tâche de fond, qui démarre automatiquement, et qui doit réagir à des événements externes? Le framework propose pour cela des composants de type service et receiver qui utilisent des intentions (Intent) pour collaborer. Le service peut être vu comme une activité à longue durée de vie (po- tentiellement innie), en tâche de fond, et privée d'IHM. Un service peut, comme une activité, enregistrer des écouteurs spécialisés (listeners) pour obtenir des informations sur un capteur particulier. Le receiver est un composant susceptible de recevoir des intentions exprimées par le système Android ou d'autres applications. L'intérêt de ce composant réside en son exécution automatique dès qu'un événement correspondant survient. Il agit donc souvent comme un déclencheur : par exemple, pour lancer un service. 4.2.2.2 Conception de la couche métier Le diagramme de classes de conception est un document indispensable représente la vue de conception statique d'un système. Le diagramme de classe représenté dans la gure.4.9 explique la structuration de la couche métier et sa relation avec les autres couches de l'application.
  60. 60. CHAPITRE 4. CONCEPTION 47 Figure 4.9 Diagramme de classe
  61. 61. CHAPITRE 4. CONCEPTION 48 4.2.3 Conception de la couche présentation Apprenons maintenant à présenter la couche présentation pour modéliser précisé- ment la navigation dans l'application mobile. 1. Navigation Globale dans l'interface de l'application : la gure.4.10 représente la navigation pour les deux acteurs de l'application. Figure 4.10 Diagramme Globale du Flux Android 2. Navigation dans le module de l'administrateur : On va détailler les IHM associé à l'administrateur qui est représenté dans la gure 4.11 par Module Admin : 3. Navigation dans le module de l'utilisateur : La gure.4.12 représente Module User représenté dans la gure.4.10. 4.3 Scénarios de quelques cas d'utilisation Par rapport aux diagrammes de séquence système du chapitre 3, nous allons rem- placer le système vu comme une boîte noire par un ensemble d'objets en interaction. Pour cela, nous utiliserons encore dans ce chapitre les trois types de classes d'analyse,
  62. 62. CHAPITRE 4. CONCEPTION 49 Figure 4.11 Module Admin à savoir les dialogues, les contrôles et les entités. le diagramme de séquence indique ainsi visuellement la séquence relative des envois et réceptions de messages. Pour illus- trer notre démarche, nous allons étudier les deux premiers cas d'utilisation majeurs de l'application, à savoir : Le calcul des ngerprints. la localisation de l'utilisateur. Pour chaque cas d'utilisation, nous réaliserons un diagramme de séquence représentant notre choix d'allocation de responsabilités dynamiques. 4.3.1 Scénarios de calcul de Fingerprint Nous avons représenté le scénario nominal de le cas d'utilisation calculer un n- gerprint sur le diagramme de la gure 4.13 :
  63. 63. CHAPITRE 4. CONCEPTION 50 Figure 4.12 Diagramme de navigation de l'utilisateur 4.3.2 Scénarios de Localisation Lorsque l'utilisateur s'authentie, le système calcule sa position dans le cas où il a détecté les points d'accés connu par le système. La gure 4.14 représente le scénario nominal pour le cas d'utilisation se localiser . 4.4 Conclusion Dans ce chapitre, nous avons présenté les patterns de conception utilisés pour conce- voir notre application. Par la suite, nous avons passé à la conception détaillée pour expliquer les classes de notre application. Ensuite, nous avons conçu quelques aspects dynamiques de notre application en se basant sur les diagrammes de séquence. Dans le prochain chapitre, nous passerons à une description de l'état de la réalisation du projet.
  64. 64. CHAPITRE 4. CONCEPTION 51 Figure 4.13 Diagramme de séquence détaillé du cas d'utilisation calculer un ngerprint
  65. 65. CHAPITRE 4. CONCEPTION 52 Figure 4.14 Diagramme de séquence détaillé du cas d'utilisation se localiser
  66. 66. CHAPITRE 5 Réalisation Ce chapitre constitue le dernier volet de ce rapport, il a pour objectif d'exposer le travail achevé. Pour ce faire, nous commençons par la description des outils de travail. Ensuite, nous exposons les diérentes étapes de construction de l'application. Enn, nous clôturons ce chapitre par la présentation du résultat obtenu avec quelques captures d'écran de l'interface homme/machine. 5.1 Environnement de travail La réalisation de ce projet a nécessité l'utilisation d'un nombre d'outils et de tech- nologies cités ci-dessous. 5.1.1 Environnement matériel Pour le développement : Un ordinateur portable Dell avec les caractéristiques sui- vantes : Processeur : Intel(R) Core i3 CPU M380 2.53 GHz, 2.53GHz. RAM : 4 Go. Cache : 4Mo. Pour le test : Une tablette Samsung tab3. 5.1.2 Environnement logiciel Le long de la phase de développement, nous avons utilisé l'environnement logiciel suivant :
  67. 67. CHAPITRE 5. RÉALISATION 54 Système d'exploitation : Windows 7. Outils de développement : Eclipse ADT, Eclipse STS. Serveur cartographique : geoserver. Serveur d'application : Apache Tomcat 7. SGBD : PostgreSQL/PostGIS. Outils de gestion de base de données : pgAdmin. La rédaction du rapport : Latex en utilisant l'éditeur WinEdt 5.4 et miktex 2.7. Conception UML : Gliy 5.1.3 Choix des outils de travail 5.1.3.1 PostgreSQL/PostGIS PostGIS est aujourd'hui la base de données spatiale OpenSource la plus populaire au monde. Elle est une extension (plugin) du SGBD PostgreSQL, véritable référence dans le champ des Systèmes de Gestion de Bases de Données Relationnelles Open- Source. PostgreSQL est connu pour ses qualités : robuste, able, performant... et pour ses modules additionnels dont le plus connu est PostGIS [refc]. Une base de données PostGIS peut stocker et gérer des données spatiales sous la forme de points, lignes et polygones, et fournit également de nombreuses fonctions spatiales qui permettent de calculer des longueurs, des surfaces, d'unir des objets, de calculer des intersections, de construire des objets à partir de croisement de couches, etc... Projet ociel de l'OSGéo, PostGIS dispose d'une communauté d'utilisateurs large et dynamique, particulièrement dans le monde francophone, ainsi que d'un jeu toujours plus étendu de fonctionnalités spatiales. Respectant les standards internationaux de la géomatique, PostGIS est uti- lisée avec succès pour tous types de projets car elle est accessible autant par des outils bureautiques , que par des clients Web plus légers à travers des architectures distri- buées englobant des serveurs cartographiques libres : GeoServer, Mapserver ou encore Mapnik. Baser son SIG sur PostGIS présente de nombreux avantages. Les données SIG sont stockées sous la forme de tables au sein d'un serveur et non plus comme des chiers. Cela permet une administration sécurisée et surtout une mise à disposition de vos données par plusieurs utilisateurs simultanément. Vous visualisez les couches grâce à un serveur cartographique comme geoServer. PgAdminIII est le client lourd qui per-
  68. 68. CHAPITRE 5. RÉALISATION 55 met de gérer vos bases de données PostgreSQL. Il fournit une interface graphique pour votre SGBDR. Avec lui, vous pouvez parcourir vos données, écrire et exécuter des requêtes SQL, réaliser les tâches d'administration courantes. Postgis contient des mo- dules comme pgdijkstra model et le pgRouting pour le calcule de plus courte chemin. En eet, nous utilisons le plugin pgRouting pour la fonction de navigation. pgRouting est un extension de PostGIS et ajoute les fonctionalités de routing au couple Post- GIS/PostgreSQL. pgRouting est un développement antérieur à pgDijkstra. pgRouting Implémente plusieurs algorithme pour le calcule de plus court chemin le plus connu l'algorithme de Diskstra. 5.1.3.2 Geoserver GeoServer est un logiciel open-source serveur qui permet de diuser et modier des données GeoSpatiales sur le web. Il permet ainsi de publier et de modier une grande variété de formats ouverts sous forme de cartes, d'images ou encore de données géogra- phiques. Il est écrit en langage Java et fonctionne coté serveur en tant que servlet , c'est-à-dire comme une application gérée par un serveur d'application java. Cette par- ticularité a des conséquences sur le type d'hébergement nécessaire au fonctionnement du logiciel, moins répandu, et donc sur la capacité à déployer cette solution. Parmi ses qualités, on peut noter sa facilité d'utilisation et sa compatibilité avec diérentes bases de données (Oracle Spatial, ArcSDE, PostGIS, etc.), implémentation des standards OGC, protocoles (WFS-T, WMS, etc.) et chiers cartographiques (SVG, KML/KMZ, SHP, etc.). Les capacités transactionnelles présentent ainsi un support solide pour l'édition partagée de cartes. Développé intégralement en Java, Geoserver peut intégrer des librairies qui facilitent et accélèrent les opérations complexes telles que la prise en charge de nombreux formats de données cartographiques ou encore les transformations et traductions de systèmes de coordonnées spatiales. La uidité des interfaces issues du langage Java rend la gestion des objets géométriques et de leurs attributs intrinsèques intuitive. GeoServer est devenu l'implémentation de référence (c'est-à-dire le logiciel modèle) de l'OGC pour la diusion de données selon les normes WFS et WCS et reste d'un des meilleurs logiciels pour diuser des cartes en WMS. Dans GeoServer les données sont structurées de la manière suivante (Figure.5.2) : Espaces de travail : répertoires qui ne servent que de moyens pour regrouper des
  69. 69. CHAPITRE 5. RÉALISATION 56 Figure 5.1 Fonctionnement de Geoserver entrepôts. Entrepôts : zone de stockage de données de même format (vecteur ou raster). Les entrepôts dénissent une source de données et la décrivent . Couches : les couches sont un moyen de présenter les informations des entrepôts, en précisant coordonnées de l'emprise (bounding box), et en aectant un style d'achage de ces données. Figure 5.2 Structuration des données avec Geoserver Pour notre projet, nous utilisons geoserver pour extraire les données geographiques de
  70. 70. CHAPITRE 5. RÉALISATION 57 la base de données PostGIS, construire des couches et les publier sous forme des web services géo-spatiaux WMS. 5.1.3.3 WMS WMS qui signie Web Map Service est un protocole déni par l'Open Geospatial Consortium (OGC) permettant au moyen d'une URL formatée d'interroger des serveurs cartographiques et d'obtenir ainsi des cartes géoréférencées. Ce protocole est devenu un standard implémenté par la quasi-totalité des serveurs cartographiques tels que Map- Server, GeoServer, ArcGis Server... Côté client, de nombreuses applications permettent l'interrogation de ces services : OpenLayers, GoogleMap, PMapServer, MapGuide OS, ArcGIS SDK... 5.1.3.4 Technologie JEE Pour le serveur de calcul implémenté avec la plateforme JEE, on a utilisé plusieurs frameworks : Hibernate : c'est une solution open source de type ORM (Object Relational Mapping) qui permet de faciliter le développement de la couche persistance d'une application. Il permet donc de représenter une base de données en objets Java et vice versa. Il facilite la persistance et la recherche de données dans une base de données en réalisant lui-même la création des objets et les traitements de rem- plissage de ceux-ci en accédant à la base de données. La quantité de code ainsi épargnée est très importante d'autant que ce code est généralement fastidieux et redondant. Spring :c'est un framework libre pour construire et dénir l'infrastructure d'une application java2, dont il facilite ledéveloppement et les tests. Maven : c'est un outil pour la gestion et l'automatisation de production des projets logiciels Java en général et Java EE en particulier. Junit : c'est un framework de test unitaire pour le langage de programmation Java. Le choix de J2EE se base sur la performance de langage java et la robustesse de ce plateforme.
  71. 71. CHAPITRE 5. RÉALISATION 58 5.1.4 JSON C'est le format choisi pour le transfert de données entre le client android et le serveur J2Ee. Ces types de données sont susamment génériques et abstraits pour, d'une part, pouvoir être représentés dans n'importe quel langage de programmation, d'autre part, pouvoir représenter n'importe quelle donnée concrète. Le principal avantage de JSON est qu'il est simple à mettre en oeuvre par un développeur tout en étant complet. Son avantage est de fournir un support pour une écriture simple et légère au format texte, compréhensible par les développeurs et facile d'analyse et de génération par les machines. 5.2 Implémentation 5.2.1 Etape de réalisation Pour réaliser notre système IndoorLNS, il y a des étapes à réaliser dans l'ordre suivant : 1. Conception de la base de données : La conception d'une base de données est la première étape. Le choix des algorithmes et de l'approche de travail exige l'utilisation d'une base de données spatiale. 2. Extraction des données : Comme on a expliqué, on va utiliser le plan de Cynapsys pour tester notre application. Ce plan est disponible sous la forme d'une image. Puisque on a besoin des données géographique pour positionner et naviguer, on va utiliser AutoCAD et PostGIS pour extraire les données nécessaires pour réaliser les fonctions du système. 3. Publier les données géo-spatiaux sous la forme des web service WMS : 4. Conception et développement de front-end et de back-end : Cette étape consiste de détailler la conception coté client et coté serveur. 5. Développement de back-end : on commence par le développement de l'appli- cation coté serveur. 6. Développement de front-end : on développe la partie client en ajoutant le nécessaire pour le serveur de calcul.
  72. 72. CHAPITRE 5. RÉALISATION 59 5.2.2 Interface Homme/Machine Dans ce qui suit, nous présentons quelques imprimes écran de notre produit nal. 1. Ecran d' Authentication : La gure 5.3 représente l'interface d'authentica- tion de notre application mobile. Elle permet aux utilisateurs de s'identier, en introduisant leurs identiants et leurs mots de passe. La demande d'authentica- Figure 5.3 Écran d'authentication tion du client est traitée pour vérier ses paramètres dans la base de données. Une réponse négative engendre une alerte d'erreur d'authentication. 2. Écran d'inscription : Cette écrans de la gure 5.4 représente un formulaire d'inscription des nouveaux utilisateurs. 3. Écran du Map Admin : Étant connecté, l'administrateur peut visualiser le carte de cynapsys avec les ngerprints calculés. Le procédure de calcul de ngerprint est représenté par les écrans de la gure 5.5. Il sut que l'administrateur choisit une position sur la carte, un popup sera aché pour verier le choix de cet acteur puis le calcule de ngerprint est calculé en en arriére plan et une message de succés s'ache et le nouvel point de mesure s'ache sur la carte 4. Écrans du Map User : Les écrans de la gure 5.6 représentes les diérents interfaces correspondant au visiteur de Cynapsys. L'écran Map User de la gure 5.7 consiste à acher la carte et l'emplacement de l'utilisateur :
  73. 73. CHAPITRE 5. RÉALISATION 60 Figure 5.4 Écran d'inscription Figure 5.5 Écran d'inscription 5.3 Test et optimisation Dans cette partie nous présentons les diérents tests réalisés pour vérier le bon fonctionnement de notre application. Pour tester et optimiser l'application , il est in- dispensable de compiler sur un Smartphone ou une tablette android. Durant cette phase, nous avons eu des problèmes d'intégration et nous avons eu recours de nouveau à l'application dans le but de l'améliorer. En plus, le test de l'application a conduit à plusieurs modications surtout au niveau du métier.
  74. 74. CHAPITRE 5. RÉALISATION 61 Figure 5.6 Écran du visiteur Figure 5.7 Écran du Map User 5.3.1 Test et simulation Le cycle de vie Incrémental , adoptée pour la réalisation de notre projet, nous permet de diviser le système en sous-systèmes et de valider le travail à chaque étape (chaque incrément est validé par des tests unitaires). Dans cette optique, nous avons établi une séquence de tests an de valider les fonctionnalités envisagées et détecter les éventuels problèmes. Le tableau de la gure 5.8 illustre les principaux tests fonctionnels eectués.

×