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

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

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.

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.

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 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.

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.

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

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

TABLE DES MATIÈRES x
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.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

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

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

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

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

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-

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.

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

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

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é.

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

é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.

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.

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-

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-

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-

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.

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

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

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

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

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

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-

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

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

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.

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

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 :

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

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.

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.

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.

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.

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).

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.

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.
La localisation est la principale fonctionnalité du système IndoorLNS. La gure
3.6 présente le diagramme de cas d'utilisation se localiser.

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.

Figure 3.5 Diagramme de séquence : Calcul de ngerprint
Figure 3.6 Diagramme de cas d'utilisation : se localiser

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.

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.
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.

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

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.

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.

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.

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.

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-

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,

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.

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.

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-

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.

Figure 4.9 Diagramme de classe

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,

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 :

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.

Figure 4.13 Diagramme de séquence détaillé du cas d'utilisation calculer un
ngerprint

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é. 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 :

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-

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

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

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.

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.

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 :

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.

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.

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

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

Similaire à Mon Projet Fin d'étude: Conception et développement d'une application de géolocalisation indoor (20)

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