Indexation dans les bases de données capteurs temps réel.csidoc.insa-lyon.fr/these/2006/noel/these.pdf · Indexation dans les bases de données capteurs temps réel. Application

Indexation dans les bases de donnéescapteurs temps réel.

Application à la surveillance de phénomènes environnementaux

et de risques naturels.

Présentée devantL'Institut National des Sciences Appliquées de Lyon

pour obtenirLe grade de docteur

École doctorale : École Doctorale Informatique et Information pour la Société

parGuillaume Noël

Jury MM.

A. BOUJU MdC HDR (L3I La Rochelle)

Rapporteur C. CLARAMUNT Professeur (IRENav Brest)

R. LAURINI Professeur (LIRIS Lyon)

J. LE MAITRE Professeur (LSIS Marseille)

Rapporteur H. MARTIN Professeur (LSR IMAG Grenoble)

S. SERVIGNE MdC (LIRIS Lyon)

D. SOL MARTINEZ Professeur (ITESM Puebla)

Guillaume NOËL / Thèse d'Informatique / 2006 / Institut National des Sciences Appliquées de Lyon 1

N° d'ordre 2006-ISAL-0091 Année 2006

Thèse


SIGLE ECOLE DOCTORALE NOM ET COORDONNEES DU RESPONSABLE

CHIMIE DE LYON

Responsable : M. Denis SINOU

M. Denis SINOUUniversité Claude Bernard Lyon 1Lab Synthèse Asymétrique UMR UCB/CNRS 5622Bât 3082ème étage43 bd du 11 novembre 191869622 VILLEURBANNE CedexTél : 04.72.44.81.83 Fax : 04 78 89 89 [email protected]

E2MCECONOMIE, ESPACE ET MODELISATION DES COMPORTEMENTS

Responsable : M. Alain BONNAFOUS

M. Alain BONNAFOUSUniversité Lyon 214 avenue BerthelotMRASH M. Alain BONNAFOUSLaboratoire d’Economie des Transports69363 LYON Cedex 07Tél : 04.78.69.72.76Alain.bonnafous∂ish-lyon.cnrs.fr

E.E.A.ELECTRONIQUE, ELECTROTECHNIQUE, AUTOMATIQUE

M. Daniel BARBIER

M. Daniel BARBIERINSA DE LYONLaboratoire Physique de la MatièreBâtiment Blaise Pascal69621 VILLEURBANNE CedexTél : 04.72.43.64.43 Fax 04 72 43 60 [email protected]

E2M2EVOLUTION, ECOSYSTEME, MICROBIOLOGIE, MODELISATION http://biomserv.univ-lyon1.fr/E2M2

M. Jean-Pierre FLANDROIS

M. Jean-Pierre FLANDROISUMR 5558 Biométrie et Biologie EvolutiveEquipe Dynamique des Populations Bactériennes Faculté de Médecine Lyon-Sud Laboratoire de Bactériologie BP 1269600 OULLINS Tél : 04.78.86.31.50 Fax 04 72 43 13 88E2m2∂biomserv.univ-lyon1.fr

EDIISINFORMATIQUE ET INFORMATION POUR LA SOCIETEhttp://www.insa-lyon.fr/ediis

M. Lionel BRUNIE

M. Lionel BRUNIEINSA DE LYONEDIISBâtiment Blaise Pascal69621 VILLEURBANNE CedexTél : 04.72.43.60.55 Fax 04 72 43 60 71ediis @insa-lyon.fr

EDISSINTERDISCIPLINAIRE SCIENCES-SANTEhttp://www.ibcp.fr/ediss

M. Alain Jean COZZONE

M. Alain Jean COZZONEIBCP (UCBL1)7 passage du Vercors69367 LYON Cedex 07Tél : 04.72.72.26.75 Fax : 04 72 72 26 [email protected]

MATERIAUX DE LYONhttp://www.ec-lyon.fr/sites/edml

M. Jacques JOSEPH

M. Jacques JOSEPHEcole Centrale de LyonBât F7 Lab. Sciences et Techniques des Matériaux et des Surfaces36 Avenue Guy de Collongue BP 16369131 ECULLY CedexTél : 04.72.18.62.51 Fax 04 72 18 60 [email protected]

Math IFMATHEMATIQUES ET INFORMATIQUE FONDAMENTALEhttp://www.ens-lyon.fr/MathIS

M. Franck WAGNER

M. Franck WAGNERUniversité Claude Bernard Lyon1 Institut Girard DesarguesUMR 5028 MATHEMATIQUESBâtiment Doyen Jean BraconnierBureau 101 Bis, 1er étage69622 VILLEURBANNE CedexTél : 04.72.43.27.86 Fax : 04 72 43 16 [email protected]

MEGAMECANIQUE, ENERGETIQUE, GENIE CIVIL, ACOUSTIQUEhttp://www.lmfa.ec-lyon.fr/autres/MEGA/index.html

M. François SIDOROFF

M. François SIDOROFFEcole Centrale de LyonLab. Tribologie et Dynamique des Systêmes Bât G836 avenue Guy de CollongueBP 16369131 ECULLY CedexTél :04.72.18.62.14 Fax : 04 72 18 65 [email protected]


http://www.lmfa.ec-lyon.fr/autres/MEGA/index.html

http://www.ens-lyon.fr/MathIS

http://www.ec-lyon.fr/sites/edml

http://www.ibcp.fr/ediss

http://www.insa-lyon.fr/ediis

http://biomserv.univ-lyon1.fr/E2M2


Remerciements

En premier lieu, je désire remercier mes superviseurs Sylvie Servigne et Robert Laurini. C'est grâce à eux que j'ai découvert les systèmes de surveillance de phénomènes naturels. Au fil des ans, leurs idées, conseils et avis se sont avérés d'une valeur inestimable à mes yeux.

Je voudrais également remercier messieurs Christophe Claramunt et Hervé Martin d'avoir accepté les charges de rapporteurs de cette thèse et de membre du jury de cette thèse.

Mes remerciements vont également à Alain Boujou, Jacques Le Maitre et David Sol pour avoir, eux-aussi, accepté de participer au jury.

Merci également à ma chère et tendre Amandine, à mes parents et grand-parents ainsi qu'à Rantanplan, le chien de la famille, pour d'une part m'avoir patiemment supporté au cours de ces années (dans plus d'une acception du terme), et avoir su calmement opiner du chef lorsque j'essayais d'expliquer ma dernière idée en date.

Je ne peux également que manifester ma gratitude envers le directeur du laboratoire LIRIS, monsieur Bernard Péroche, pour m'avoir accueilli au sein de celui-ci.

Je ne saurais oublier les doctorants et autres étudiants avec j'ai pu échanger des idées et des impressions, que ce soit sur des travaux de recherche ou bien sur des sujets plus variés. Ces quelques lignes s'adressent plus particulièrement à Claudia Catalina Gutierez Rodriguez, Ludwig Seitz, Hassan Naderi, Maria del Rocio Abascal Mena, Suela Berisha-Bohé et Vivien Guillet.

La liste des personnes méritant de figurer sur cette page serait assurément incomplète sans citer le personnel de l'INSA que j'ai côtoyé jours après jours, années après années.

Parmi les personnes rencontrées à l'INSA, une pensée particulière ne peut qu'aller vers la centaine d'élève de premier cycle qui ont vu arriver devant eux un drôle de phénomène avec une paire de dés en poche et toute une panoplie de métaphores pour illustrer ses TDs de programmation.

Et enfin, pour conclure cette liste, une dernière exclamation de gratitude va vers tous ceux que je considère comme des amis. Un mot bien petit, mais une signification autrement plus conséquente. Merci donc à Cécile, Christelle, Guillaume, Jean, Marie, Raphaël, Sébastien, Thomas, Véronique...



Résumé

L'objectif de cette thèse est d’offrir aux spécialistes des systèmes de surveillance de phénomènes environnementaux une méthode de structuration, de recherche et d'accès rapide aux informations spatio-temporelles en temps-réel et sur différents critères, notamment spatiaux et temporels. Plus précisément, le problème qui nous concerne est celui de l'indexation dans une base de données en mémoire vive d'une masse de données référencées spatio-temporellement avec des contraintes de temps pour la mise à jour de l’index et pour l'exécution des requêtes. Les mesures collectées par un réseau de capteurs doivent être indexées en fonction du capteur dont elles sont issues et de la date de la mesure. De plus, les données les plus récentes doivent valorisées, ce qui n'est actuellement pas le cas pour les index existants.

Trois solutions d'indexations sont proposées. Elles se distinguent des solutions existantes en regroupant les données issues des capteurs dans des sous-structures dédiées. Des sous-structures d'accès permettent d'identifier les capteurs concernés par une requête.

La première proposition, le PoTree, vise à indexer en mémoire vive les données spatio-temporelles issues d'un réseau de capteurs temps-réel fixes.

La seconde, le PasTree, vise à indexer en mémoire vive les données spatio-temporelles issues d'un réseau de capteurs temps-réels agiles, c'est à dire dont les capteurs disposent d'une mobilité restreinte. Il permet un accès multicritère aux données : selon des facteurs spatiaux ainsi que selon l'identifiant du capteur.

La dernière proposition se nomme le Spatio-temporal / Heat (StH) et indexe en mémoire vive les données issues d'un réseau de capteurs temps-réel agiles, en permettant un accès multicritère. Il permet de prendre en compte des données d'observation, sur des zones. La principale innovation de cette structure est l'intégration d'outils de gestion de la saturation de la base de données en offrant un mécanisme permettant un transfert progressif des données vers un entrepôt. Les données transférées sont choisies en fonction de leur chaleur, leur importance.

Ces solutions ont été implémentées et offrent des performances supérieures aux solutions actuellement utilisées grâce à leurs approches centrées sur les capteurs.

Mots-clefs

Base de données en mémoire, indexation, temps réel, réseau de capteurs, spatio-temporel, multicritère, capteurs fixes / agiles, saturation de base de données



Abstract

This thesis's aim is to provide methods for structuring, querying and fast accessing to spatio-temporal data in real time. These solutions aim at helping specialists in environmental phenomenon monitoring systems. Different data selection criterion can be used, in particular spatial and temporal ones. More precisely, we focus on the indexing of an « in memory » database for masses of spatio-temporally referenced data. Time constraints limit updates and queries of the database. The measurements collected by a sensor network must be indexed according to the source sensor and the date of measurement. Moreover, the most recent data are usually considered as more interesting, a specificity that is usually not featured in existing indexing systems.

Three indexing solutions are proposed. They differ from the existing solutions by storing the data from sensors in dedicated substructures. “Access substructures” are used to link a query to a set of sensors.

The first proposal, the PoTree, aims at « in-memory » indexing of spatio-temporal data issued from a network of fixed real time sensors.

The second, the PasTree, aims at « in-memory » indexing of spatiotemporal data issued from a network of agile real time sensors, i.e. of which the sensors have a restricted mobility. It allows for a multi-criterion access to the data, using spatial references or sensor identifiers.

The last proposal, the Spatio-temporal Heat (StH) aims at « in-memory » indexing of spatio-temporal data issued from a network of agile real time sensors. It can also manage observation zones. The main innovation of this structure is the integration of a database saturation management policy. It allows a progressive data transfer towards a warehouse. Transferred data are elected according to their heat, the amount of information of a specific measurement.

These solutions were implemented and offer better performances than the solutions currently in use, thanks to their sensor-centric approach.

Key-Words

in-memory database, indexing, real time, sensor network, spatio-temporal, multi-criterion, fixed / agile sensors, database saturation



Table des matières


Introduction.................................................................................23

1 Présentation de la problématique..........................................27

2 Les réseaux de capteurs..........................................................31

2.1 Application à la surveillance de phénomènes environnementaux..32

2.1.1 Les mesures..........................................................................................33 2.1.1.1 Types de mesures.....................................................................................33 2.1.1.2 Localisation des mesures........................................................................33

2.2 Les capteurs........................................................................................35

2.2.1 Les classes de capteurs.......................................................................35

2.2.2 Capteurs fixes, agiles, mobiles..........................................................37

2.2.3 Fonctionnement des capteurs et gestion de l'énergie...................38

2.2.4 Considérations Réseau.......................................................................39 2.2.4.1 Routage.....................................................................................................39 2.2.4.2 Transmission............................................................................................39 2.2.4.3 Surveillance de l'état du réseau..............................................................40

2.2.5 Les difficultés liées à l'utilisation de capteurs...............................41

2.2.6 Conclusion sur l'utilisation des capteurs........................................42

2.3 Cas d'utilisation d'un réseau de capteurs........................................43

2.3.1 Du réseau de capteur au système de surveillance.........................44

2.3.2 Les données collectées........................................................................45

2.3.3 Spécification des besoins....................................................................47

2.4 Conclusion sur les réseaux de capteurs pour la surveillance de phénomènes...................................................................................48

3 Contexte : définition de Temps Réel.....................................51

3.1 Une définition du temps réel.............................................................52

3.1.1 Ordonnancement et assignation de priorité...................................54 3.1.1.1 Earliest deadline first...............................................................................54 3.1.1.2 Rate Monotonic........................................................................................55 3.1.1.3 Gestion des transactions apériodiques...................................................55


3.1.2 Méthodes répandues de contrôle de la concurrence.....................55 3.1.2.1 Contrôle à verrou.....................................................................................56 3.1.2.2 Contrôle optimiste...................................................................................56 3.1.2.3 Contrôle Multiversion.............................................................................57 3.1.2.4 Résumé des contrôles de concurrence...................................................57

3.2 Restrictions imposées aux BDTR......................................................58

3.2.1 Fonctionnement d'une base de données temps réel......................58

3.2.2 Les bases de données temps réel existantes....................................60RODAIN.................................................................................................................61

3.3 Évolution des systèmes temps réel liée aux avancées technologiques..............................................................................62

3.3.1 Systèmes d'indexation avec prise en compte de la mémoire cache.......................................................................................................64

3.4 Conclusion : temps réel et BDTR......................................................65

4 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes..................................................................67

4.1 Indexation spatio-temporelle.............................................................69

4.1.1 Taxonomies spatio-temporelles........................................................69 4.1.1.1 Approche spatiale....................................................................................69 4.1.1.2 Approche temporelle...............................................................................71 4.1.1.3 Approche spatio-temporelle....................................................................71

4.1.2 Indexation et requêtes........................................................................72 4.1.2.1 Bases de données spatiales.....................................................................72

4.1.2.1.1 La famille des binary-tree..............................................................73kd-Tree [7].....................................................................................73

4.1.2.1.2 Techniques d’indexation basées sur les B-Tree...........................74R-Tree [22]....................................................................................74R* Tree [6].....................................................................................75DR-Tree [40].................................................................................75

4.1.2.1.3 Méthodes de cellules basées sur le hachage dynamique.............76Grid File [56].................................................................................76

4.1.2.1.4 Ordonnancement des objets spatiaux............................................77Quadtree et Linear Regional Quadtree (LRQ) [20][66]...........77

4.1.2.2 Bases de données temporelles................................................................78 4.1.2.2.1 Index basés sur les B+ Tree...........................................................79

Append-Only Tree [56]................................................................79B+ Tree avec ordre linéaire [56].................................................79


Multi Version B Tree (MVBT) [5] [76].....................................80 4.1.2.2.2 Méthode basées sur l’indexation spatiale....................................80

Index Time-Polygon [56].............................................................80R-Tree [22]....................................................................................81

4.1.2.2.3 Bases de données bitemporelles....................................................81GR-Tree [9]...................................................................................81

4.1.2.2.4 Base de données spatio-temporelles.............................................823DR-Tree [78]...............................................................................82HR Tree, MR Tree [49]................................................................83MV3R-Tree [74]...........................................................................84

4.1.2.3 Indexation et Temps-Réel.......................................................................85CR-Tree [34]..................................................................................85PR-Tree [70]..................................................................................85PCR-Tree [69]...............................................................................85

4.1.3 Critique des index disponibles..........................................................86

4.2 Le PoTree............................................................................................88

4.2.1 Contexte d'utilisation.........................................................................88 4.2.1.1 Rappels sur les aspects spatiaux et temporels.......................................88 4.2.1.2 Représentation des données et temps-réel.............................................90 4.2.1.3 Lien avec la base de données..................................................................91

4.2.2 Structure du PoTree...........................................................................92 4.2.2.1 Le sous-arbre spatial................................................................................95

4.2.2.1.1 Lien avec les capteurs....................................................................95 4.2.2.1.2 La structure du sous-arbre et l'accès aux données......................95 4.2.2.1.3 Insertion et suppression de données.............................................97 4.2.2.1.4 Accès aux données : quelques requêtes moins fréquentes..........99 4.2.2.1.5 Performances théoriques................................................................99

4.2.2.2 Les sous-arbres capteur.........................................................................100 4.2.2.2.1 Amélioration de l'accès en mémoire...........................................101 4.2.2.2.2 Mise en avant des données les plus récentes.............................102 4.2.2.2.3 Performances théoriques..............................................................104

4.2.3 Exemples de requêtes.......................................................................105

4.2.4 Implémentation et tests....................................................................106

4.2.5 Résumé sur le PoTree.......................................................................109

4.3 Conclusion sur l'indexation spatio-temporelle de données issues d'un réseau de capteurs fixes.....................................................110

5 Indexation spatio-temporelle de données issues d'un réseau de capteurs agiles...............................................................113


5.1 Agilité, mobilité et index spatio-temporel......................................114

5.1.1 Concepts.............................................................................................114

5.1.2 Indexer le passé.................................................................................1153DR-Tree [78].............................................................................116HR-Tree, MR-Tree [49].............................................................116HR+Tree [74]..............................................................................116MV3R-Tree [75].........................................................................116Multiversion Linear Quadtree (MVLQ) [81]..........................117Partially persistent R Tree (PPR) [35]......................................117Scalable and Efficient Trajectory Index (SETI) [14]..............118Start/End timestamp B-tree (SEB) [72]....................................1182+3 R-tree [50]............................................................................119

5.1.3 Indexer la position courante...........................................................119Lazy Update R-tree (LUR) [36]................................................119Hashing 119

5.1.4 Indexer les positions courante et futures......................................120PMR Quadtree pour objets mobiles [77]..................................120Time Parametrized R-Tree (TPR) [65].....................................121

5.1.5 Synthèse et critique des index disponibles...................................121

5.2 Le PasTree........................................................................................123

5.2.1 Contexte d'utilisation.......................................................................123 5.2.1.1 Des nouveautés, mais également des points communs avec le PoTree

..........................................................................................................................124 5.2.1.2 L'agilité des capteurs.............................................................................125 5.2.1.3 Accès aux données.................................................................................125

5.2.2 La structure du PasTree..................................................................126 5.2.2.1 Les principales modifications...............................................................127

5.2.2.1.1 La gestion multicritère.................................................................128 5.2.2.1.2 La gestion de l'agilité...................................................................129 5.2.2.1.3 Ajout d'un niveau d'abstraction au sous-arbre capteur............130 5.2.2.1.4 Gestion des accès concurrentiels................................................131

5.2.2.2 L'interface centrale................................................................................132 5.2.2.3 Le sous-arbre d'identifiants...................................................................133

5.2.2.3.1 Politique de nommage des capteurs............................................134 5.2.2.3.2 Accès aux données, les arbres de capteur..................................134 5.2.2.3.3 Mise à jour de la structure...........................................................135 5.2.2.3.4 Suppression de données et de capteur........................................136 5.2.2.3.5 Coût de fonctionnement de la structure......................................137

5.2.2.4 Le sous-arbre spatial..............................................................................137 5.2.2.4.1 Un Quadtree multiversion............................................................138


5.2.2.4.2 L'accès aux arbres capteur..........................................................139 5.2.2.4.3 La mise à jour................................................................................142 5.2.2.4.4 La suppression de données..........................................................145 5.2.2.4.5 Coût de la structure......................................................................146

5.2.2.5 Le sous-arbre capteur............................................................................146 5.2.2.5.1 Réutilisation du sous-arbre capteur du PoTree, avec quelques

ajouts................................................................................................147 5.2.2.5.2 Niveau d'abstraction au niveau des données : mesure /

mouvement.......................................................................................147 5.2.2.5.3 La gestion de la position au sein du B+Tree.............................149 5.2.2.5.4 Accès aux données........................................................................150 5.2.2.5.5 Les mises à jour.............................................................................152 5.2.2.5.6 Suppression de données................................................................154 5.2.2.5.7 Aspect mathématique....................................................................154

5.2.3 Exemples de requêtes.......................................................................155

5.2.4 Implémentation et tests....................................................................156

5.2.5 PasTree : conclusion.........................................................................161

5.3 Conclusion sur l'indexation de données issues de capteurs agiles......................................................................................................162

6 La gestion de la saturation...................................................165

6.1 Contexte général...............................................................................166

6.2 Le StH................................................................................................168

6.2.1 Contexte d'utilisation.......................................................................168 6.2.1.1 Rappels sur les besoins liés aux bases de données capteurs.............168Ajout de la notion d'observations.......................................................................169 6.2.1.2 Les spécificités de la gestion de la saturation.....................................169 6.2.1.3 Considérations sur l'importance de données.......................................170 6.2.1.4 La structure du StH................................................................................172

6.2.1.4.1 Métaphore du jardin.....................................................................174 6.2.1.4.2 L'interface......................................................................................175 6.2.1.4.3 La sous-structure d'accès d'identifiants.....................................175 6.2.1.4.4 La sous-structure d'accès spatial................................................176 6.2.1.4.5 La sous-structure capteur............................................................178

La racine de l'escalier.................................................................179Les marches de l'escalier et les écailles...................................181La fonction de chaleur................................................................184La mise à jour de l'escalier........................................................185Le processus de transfert............................................................188L'accès aux données....................................................................190La suppression de données.........................................................192


6.2.2 Exemple de requêtes.........................................................................192 6.2.2.1 Mises à jour du StH...............................................................................192 6.2.2.2 Accès aux données du StH....................................................................193

6.2.3 Implémentation et test du StH........................................................194

6.2.4 Conclusion sur le StH.......................................................................197

6.3 Conclusion générale sur la gestion de la saturation dès la construction de l'index...............................................................199

7 Conclusion............................................................................201


Index des illustrationsFigure 1: Capteur de visibilité (jour/nuit) ...............................................................35

Figure 2 : Exemple de réseau de capteur..................................................................36

Figure 3 : Division du temps TDMA entre 3 tâches...............................................40

Figure 4 : Stations de mesure du volcan Popocatépetl...........................................43

Figure 5 : Système de surveillance de phénomène naturel....................................45

Figure 6 : Formats des données.................................................................................46

Figure 7 : Différence entre différents types de mémoire.......................................63

Figure 8 : Structure du kd-Tree (schéma de [56])...................................................73

Figure 9 : Structure d'un R-Tree (schéma de [56]).................................................74

Figure 10 : Découpage d'un objet et structure du DR-Tree correspondant [40]..76

Figure 11 : Image, Quadtree et Linear Regional Quadtree correspondants[66]. .78

Figure 12 : Structure du 3DR-Tree [78]...................................................................83

Figure 13 : Structure du HR-tree [49]......................................................................84

Figure 14 : Structure du MV3R-Tree [74]...............................................................84

Figure 15: Plan du jardin botanique PoTree............................................................93

Figure 16 : Structure générale du PoTree................................................................93

Figure 17 : Différence structurelle entre R-Tree et PoTree...................................94

Figure 18 : Structure d'un nœud du sous-arbre spatial...........................................95

Figure 19 : Explication de la notation des schémas d'enregistrements.................95

Figure 20 : Recherche dans l'arbre spatial à partir d'un point...............................97

Figure 21 : Mise à jour du PoTree via l'arbre spatial.............................................98

Figure 22 : Sous-arbre Capteur...............................................................................100

Figure 23 : Structure des composants du sous-arbre capteurs.............................101

Figure 24 : Processus de recherche d'une mesure dans l'arbre capteur à partir d'une date donnée......................................................................................................103

Figure 25 : Processus de résolution d'une requête sur un point spatial et un intervalle temporel....................................................................................................105

Figure 26 : Évolution du temps de construction des structures en fonction du nombre de données à indexer..................................................................................107

Figure 27 : Influence du nombre de capteurs fixes sur le temps de création de l’arbre (indexation de une seconde de données à 100 Hz)...................................107

Figure 28: Exemple de courbe d'étouffement du système....................................108

Figure 29 : Temps de résolution d’une requête de Fenêtre spatiale / Intervalle temporel en fonction du nombre de données présentes dans la base (68 capteurs)....................................................................................................................................109

Figure 30 : Image d'origine, Quadtree et enregistrement multiversion [81]......117

Figure 31 : Construction du SEB-Tree [72]...........................................................118

Figure 32 : TPR-Tree [65].......................................................................................121


Figure 33 : Structure globale du PasTree...............................................................127

Figure 34 : Structure du PasTree............................................................................130

Figure 35 : Rôle de l'interface.................................................................................132

Figure 36 : Processus d'échanges via l'Interface lors d'une mise à jour.............133

Figure 37 : Structuration de l'arbre d'identifiants.................................................134

Figure 38 : Mise à jour via l'arbre d'identificateur...............................................135

Figure 39 : Suppression de capteur à partir de l'arbre d'Indentifiants................136

Figure 40 : Structure du Quadtree multiversion....................................................137

Figure 41 : Structuration du Quadtree multiversion..........................................138

Figure 42 : Recherche de capteur via l'arbre spatial (point spatial, instant temporel)....................................................................................................................139

Figure 43 : Modification des intervalles des requêtes en fonction de la présence du capteur C au point P............................................................................................140

Figure 44 : modification des intervalles de recherche en fonction des enregistrements.........................................................................................................141

Figure 45 : Processus de mise à jour de données via l'arbre spatial...................143

Figure 46 : Modification d'enregistrement multiversion lors d'une suppression ....................................................................................................................................145

Figure 47 : Structure du sous-arbre capteur...........................................................147

Figure 48 : Structuration de la racine de l'arbre capteur......................................147

Figure 49 : Structuration des nœuds de l'arbre capteur........................................148

Figure 50 : Lien entre le nœud et la position du capteur......................................149

Figure 51 : Accès à la position d'un capteur pour une date déterminée.............151

Figure 52 : Accès à la position du capteur à une date déterminé à partir d'un nœud...........................................................................................................................151

Figure 53 : Processus de mise à jour de l'arbre capteur.......................................153

Figure 54 : Temps de construction du PasTree en fonction du nombre de données à indexer pour 68 stations fixes...............................................................157

Figure 55 : Influence du taux d'agilité sur le temps de construction du PasTree, avec un nombre de capteurs et de données fixes...................................................158

Figure 56 : Temps de construction PoTree / PasTree en fonction du nombre de points à indexer pour 68 capteurs fixes..................................................................159

Figure 57 : Temps de résolution d’une requête de recherche sur une fenêtre spatiale / intervalle temporel en fonction du nombre de données contenues dans la base........................................................................................................................160

Figure 58 : Exemple de chaleur de données liée à un signal continu.................170

Figure 59 : Exemple de chaleur associée à un signal carré..................................171

Figure 60 : Structure globale du StH......................................................................173

Figure 61 : Rôle de l'Interface.................................................................................175

Figure 62 : Structure d'un enregistrement multi-version......................................177

Figure 63 : Représentation de l'escalier capteur....................................................178


Figure 64 : Structure de l'escalier capteur.............................................................179

Figure 65 : Structure de la racine de l'escalier......................................................179

Figure 66 : Structure d'une marche de l'escalier...................................................182

Figure 67 : Structure d'une écaille de l'escalier.....................................................182

Figure 68 : Processus de mise à jour mesure de l'escalier...................................186

Figure 69 : Processus de mise à jour de mouvement de l'escalier......................187

Figure 70 : Processus de transfert de données de l'escalier.................................189

Figure 71 : Résolution d'une requête d'accès aux données via un instant temporel....................................................................................................................................191

Figure 72 : Temps de création du R-Tree et du QuadTree selon le nombre de capteurs......................................................................................................................195

Figure 73 : temps de construction de l'escalier en fonction de la fonction de chaleur........................................................................................................................195

Figure 74 : Temps de création de l'escalier en fonction du nombre d'écailles dans la structure.................................................................................................................196

Figure 75 : Temps de construction de l'escalier selon le nombre de données par écaille.........................................................................................................................197


Index des tablesTableau 1 : Représentation des évènements selon la dimension temporelle........72Tableau 2: Comparatif entre les index spatio-temporels........................................87Tableau 3 : Exemple de table de localisation de capteurs [33].............................89Tableau 4 : Représentation des positions de plusieurs capteurs............................96Tableau 5: Récapitulatif des index couvrant l'agilité ou la mobilité..................122Tableau 6 : Types d'accès en fonction des requêtes.............................................131



Introduction

Introduction

De nombreuses applications actuelles requièrent des outils permettant de gérer et localiser de l’information sur des données spatio-temporelles temps-réel. Le suivi de l’environnement, la gestion de crises (catastrophes, feux, …), la gestion des risques urbains (autoroutiers, routiers, industriels…) ou environnementaux (crues, avalanches, volcans…), la gestion de flotte de véhicules en temps-réel (transport, taxis…), nécessitent des systèmes informatiques élaborés capables d’exploiter des données spatio-temporelles temps-réel issues de capteurs et de systèmes de localisation fixes, agiles1 ou mobiles. Ces données sont spatiales et temporelles et de plus, temps-réel. Le temps-réel traité ici est le temps-réel immédiat de l’ordre de la seconde ce qui a des implications fortes sur la gestion et l’exploitation de ces données (structuration, stockage, indexation, interrogation, visualisation…). Si les Systèmes d’information géographiques (SIG) actuels gèrent et permettent d’exploiter des données spatiales, l’aspect temporel des données est encore mal introduit et aucun SGBD temps-réel n’est commercialisé, ni a fortiori un SGBD spatio-temporel temps-réel. Pourtant, le besoin est crucial, notamment en termes de structuration et d’interrogation de ces données. Plusieurs questions se posent, entre autres : comment stocker rapidement ces données sans débordement des capacités mémoire et de calcul? Comment indexer ces données en temps-réel en privilégiant les données récentes plutôt que les anciennes tout en permettant les requêtes en temps continu? Comment gérer l'agilité des capteurs? Quelles sont les spécifications des architectures de collecte, de communication, de stockage dans la base de données?

Cette thèse se focalise sur la structuration de données spatio-temporelles temps-réel exploitables pour des applications de surveillance environnementales, et plus particulièrement de surveillance de risques naturels. De telles applications exploitent des informations localisées ou spatialisées à partir principalement de capteurs fixes ou agiles.

Les réseaux de capteurs historiques utilisent des capteurs ponctuels fixes. Dans ce cas de figure, les données apparaissent comme issues d'un point dans l'espace. Les méthodes d'indexation classiques utilisent l'identifiant du capteur comme référence. Le but premier de cette thèse est de proposer des méthodes d'accès spatio-temporelles, fonction de la position du point de mesure et de la date de celle-ci.

Les systèmes de surveillance environnementaux, en particulier ceux dédiés à la surveillance de phénomènes naturels utilisent généralement un réseau de capteurs fixes, ou agiles. Les mesures sont alors expédiées vers une base de données centralisées. Elles sont indexées en fonction du capteur dont elles sont issues et de la date de la mesure. L'indexation ne porte pas directement sur les mesures, mais sur les facteurs qui ont conduit à cette mesure.

1Un capteur est dit agile lorsque sa position change ponctuellement et non en continu dans le temps et l’espace.


Introduction

Du fait du grand nombre de capteurs et de la masse de données, la mise à jour en temps-réel et le risque de saturation de la base de données en mémoire vive qui recueille les données sont des enjeux majeurs. L’offre d’accès multi-critère et temps-réel aux données est également un besoin des utilisateurs sachant que les systèmes d'analyse en aval (temps-réel ou non) des capteurs utilisent en priorité les données les plus récentes.

L’étude de l'indexation de données temps-réel issues d'un réseau de capteurs référencés spatialement et temporellement dans une base de données en mémoire vive a conduit à la conception du PoTree et du PasTree. Le PoTree est dédié aux données issues de capteurs fixes et à l'indexation spatio-temporelle pure tandis que le PasTree gère l'agilité (mobilité restreinte) des capteurs ainsi qu'un accès multicritères aux données. Ces solutions d'indexation centrées sur les capteurs différencient les dimensions spatiales et temporelles. Toutes les données issues d'un même capteur sont regroupées dans une même sous-structure indexant les données en fonction du marqueur temporel lié aux données. D'autres structure d'accès ont pour but de déterminer lequel de ces sous-arbres est concerné par une requête déterminée. Cette division met l'accent sur le rôle premier des capteurs et permet de limiter le nombre de données à prendre en considération lors de la résolution de requêtes. La structure du PasTree est plus complexe que celle du PoTree afin de permettre de nouveaux types de requêtes, basés sur les identifiants de capteurs et sur des critères spatio-temporels, et supporte l’agilité des capteurs; ceci au détriment d’une faible baisse de performance en raison d’un temps de création de l'arbre supérieur et par une augmentation des temps de réponse aux requêtes. Cependant, la structure du PasTree permet également la prise en compte des problématiques de plus en plus présentes dans les réseaux de capteurs comme la distribution des données afin de diminuer le coût de la mise à jour ; la structure en sous-arbres du PasTree pouvant alors s'avérer un point de départ intéressant. Enfin, des tests effectués sur ces structures ainsi que sur le R*tree, arbre le plus fréquemment rencontré dans les bases de données disponibles ont mis à jour l'intérêt d'utiliser le PoTree pour l'indexation de données issues de capteurs fixes et le PasTree pour des capteurs agiles.

Cependant ces deux structures ne sont pas à même d’apporter une réponse au problème de la saturation de la base de données. La masse de données engendrées par un réseau de capteurs risque en effet de saturer une base en un temps restreint. Une politique de gestion de ce phénomène peut tirer parti d’un système d’indexation dédié. Le StH, (SpatioTemporal-Heat index) a ainsi été conçu dans cette optique. Il s’agit d’une structure héritant du PasTree et qui gère la saturation de la mémoire en préservant en mémoire les données les plus importantes.

Une structure d’accès spatial multiversion, basé sur un R-Tree permet l’enregistrement de données liées à des zones et non plus seulement à des points. Cette structure, ainsi qu’un arbre d’identifiant de capteurs permettent de distinguer différents escaliers, chacun étant lié à un capteur particulier. Chaque escalier permet d’indexer les données d’un capteur particulier en fonction du temps mais également de l’importance de la données, sa chaleur. Lorsqu’un nombre de données dans la première marche (temporelle) de l’escalier est atteint, on décale celle-ci vers la droite, on transfert la partie la plus basse de la marche, la plus froide et donc la moins importante, vers un entrepôt de données. On crée alors une nouvelle marche où seront insérées les nouvelles données. Ce mécanisme permet d’obtenir une sous-


Introduction

structure de capteur analogue à un escalier mécanique, où les données les moins importantes sont envoyées vers un entrepôt de données pour des analyses à plus long terme. Les données contenues par la structure perdant graduellement de l’importance. Deux sous-parties de cet escalier permettent de conserver les enregistrements des anciennes positions occupées par les capteurs ainsi que certaines données explicitement signalées comme étant importante.

Les travaux sur le StH portent sur des séries d’expérimentations qui pour l’heure ont permis de mettre en évidence le rôle primordial de la fonction de détermination de chaleur des données. Cette fonction devant assurer une répartition homogène des données entre les différentes classes de chaleur. D’autres expérimentations portent sur les aspects de transfert de données vers un entrepôt et sur les conditions de mises à jours de la structure.

Les études effectuées au cours de cette thèse ont été réalisés en coopération avec l'Université de Puebla au Mexique, et le CENAPRED, centre national de prévention des désastres Mexicain. Les travaux ont été réalisés dans le cadre du projet GETM, soutenu par le CNRS. Ils entrent également dans le cadre du programme interdisciplinaire « société de l'information » (projet SETHLANS [68]) également soutenu par le CNRS, l'IGN et le CEMAGREF.

Ces travaux ont permis d'étudier et d'apporter des solutions aux problèmes liés à la saturation de bases de données capteurs temps-réels, jusque là peu traités. Ces travaux ont fait l'objet de huit publications dans des conférences françaises, européennes et internationales ainsi qu'un article dans une revue et un chapitre d'un ouvrage sur la gestion de risques. A ces publications s'ajoutent finalement deux posters.

La présente thèse se décompose en plusieurs grandes parties. Il a été choisit de rédiger les parties afin de limiter le besoin de parcourir l'ensemble du document à la recherche de rappels ou de définitions.

La première partie reprend la problématique de l'indexation de données issues d'un réseau de capteurs.

Par la suite, une présentation des réseaux de capteurs, et plus particulièrement des réseaux dédiés à la surveillance de phénomènes permet d'aborder les spécificités de ces systèmes. La principale d'entre-elles, l'aspect temps-réel, est ensuite détaillée.

La partie suivante aborde l'indexation de données issues d'un réseau de capteurs fixes. Une présentation des techniques d'indexation spatiales, temporelles et spatio-temporelles permet de comprendre les limites des systèmes actuels. Une première solution, le PoTree est alors détaillée. Cet arbre permet l'indexation de données issues d'un réseau de capteurs temps-réel fixes et permet la résolution de requêtes spatio-temporelles.

Le chapitre suivant élargit le contexte et aborde l'indexation de données issues d'un réseau de capteurs agiles. Une première sous-partie aborde plus précisément les techniques existantes permettant l'indexation spatio-temporelle d'objets capables de se déplacer. Le PasTree est alors introduit. Cet arbre reprend les concepts développés pour le PoTree en ajoutant la gestion de l'agilité des capteurs ainsi que l'accès multi-critère aux données.


Introduction

La dernière partie aborde enfin un point souvent négligé dans la conception de solution d'indexation : la gestion de la saturation mémoire de la base de données. Reprenant le concept du PasTree, le StH, la dernière solution présentée propose d'intégrer des mécanismes de gestion de la saturation de la base dès la conception de l'index de la base de données.


Présentation de la problématique

1 Présentation de la problématique

Les réseaux de capteurs sont de plus en plus courants et tendent à devenir presque invisibles aux yeux des utilisateurs. Les progrès techniques ont permis une diminution de la taille ou encore une plus grande autonomie de leurs composants.

Les systèmes de surveillance de phénomènes sont intimement liés à la notion de réseaux de capteurs. Ils furent parmi les premiers systèmes à les utiliser à grande échelle et ont connu les balbutiement de nombreuses technologies électroniques ou informatiques.

L'héritage historique de ces systèmes a poussé à une forme de standardisation des architectures rencontrées. Alors que différents projets scientifiques proposent une décentralisation des données, le pragmatisme et l'expérience pousse à l'utilisation d'architectures centralisées. Les données collectées par les différents éléments du réseau sont envoyées vers un noeud central où elles peuvent être collectées et analysées.

L'architecture centralisée permet de s'affranchir de différents risques inhérents à la nature des capteurs : ceux-ci peuvent tomber en panne ou se dérégler au fil du temps. De plus, cette approche permet de centraliser la résolution des requêtes, ce qui peut grandement faciliter l'accès aux données en cas de crise.

La centralisation impose également le besoin d'un système informatique robuste, à même de gérer des masses de données importantes, principalement au niveau des mises à jours qui sont de facto temps-réel. L'utilisation de bases de données en mémoire vive est courante. Elle est utilisée pour la gestion des données sur court terme alors que des entrepôts de données recueillent les mesures les plus anciennes. La présente thèse vise à proposer différentes solutions permettant l'indexation spatio-temporelle des données dans la base en mémoire vive, liée à un réseau de capteurs temps-réels.

Les mesures ne sont pas directement indexées en tant que tel. Elles sont liées aux capteurs ponctuels dont elles sont issues et à la date de la mesure. L'indexation doit donc s'effectuer sur ces deux critères. Historiquement, les capteurs étaient référencés en fonction de leurs identifiants. Le travail proposé ici permet de les référencer en fonction de coordonnées géographiques et de marqueurs temporels de mesures.

De fait, les transactions de mises à jours sont les plus nombreuses. La perte de certaines mesures est acceptable lorsque les fréquence des capteurs sont élevées et que la phase d'activité du système est sans incidence.

Les transactions de mise à jour, incrémentales et temps-réel, revêtent une importance supérieure aux consultations normales (non temps-réel pour la plupart). Les mises à jour sont temps-réel (une mesure doit être indexée avant qu'une version plus récente n'atteigne le système). Les mises à jour sont prioritaires lorsque le



système est en phase d'activité minimale. Lorsqu'un pic d'activité du système observé est détecté, les demandes d'accès émises depuis les centre de gestion de crises sont alors tout autant importantes. L'index de la base doit être compatible avec la gestion de ces différentes transactions.

Les experts analysant les données collectées sont généralement plus intéressés par l'évolution récente du système. En d'autre termes, les données les plus récentes ont une plus grande probabilité d'être lues. Le système d'indexation de la base de données doit donc faciliter l'accès à ces données récentes.

Ces différentes particularités sont communes à de nombreux systèmes de surveillance de phénomènes basés sur l'utilisation d'un réseau de capteur et d'une base de données centralisée en mémoire vive.

Une première évolution possible au sujet originel permet de combiner l'accès spatio-temporel à l'accès en fonction des identifiants de capteurs. Les mesures sont alors référencées par la date de la mesure ainsi que par la position du capteur ou par son identifiant. Ceci permet une compatibilité avec les modes d'utilisation existants de la base de données.

Une seconde évolution prend en compte les développements des technologies réseaux et électronique et propose de gérer des données issues de capteurs agiles, capables de se déplacer entre deux séries de mesures.

Une troisième évolution permet l'utilisation de données relatives à des zones spatiales. Les capteurs peuvent alors céder la place à des observations sur des zones.

Une dernière évolution, la plus ambitieuse, vise à intégrer la gestion de la saturation de la base de données dès la conception de l'index. Les masses de données arrivant au niveau de la base imposent l'utilisation de mécanismes permettant le transfert des données les plus anciennes vers un entrepôt de données. Ces mécanismes sont généralement des processus semi-autonomes. Le but de la dernière évolution est donc d'intégrer des outils permettant une gestion intégrée de ce transfert, en exploitant la structure de l'index de données.

En résumé, les différentes solution proposées ici ont pour but l'indexation en mémoire vive de données spatio-temporelles issues de réseaux de capteurs afin de permettre un accès rapide aux données et de faciliter la gestion de masses de données à mettre à jour ou à transférer vers un entrepôt. Ces données ont en point commun un référencement spatial en fonction des capteurs et temporel selon la date des différentes mesures. De même, elles valorisent l'accès aux données les plus récentes.

Le présent travail vise à apporter des solutions à la problématique dont les spécifications et les objectifs sont les suivants :

● Indexation de base de données centralisées en mémoire vive, liée à un entrepôt

● Indexation de mesures issues d'un réseau de capteurs

○ Adaptation à des capteurs fixes

○ Adaptation à des capteurs agiles

● Capteurs définis spatialement



○ Capteurs ponctuels

○ Observations de zone

● Indexation des mesures en fonction du capteur et de la date de la mesure

○ Accès spatio-temporel

○ Accès multi-critère

● Indexation de masses de données

● Valorisation des données les plus récentes

● Valorisation des requêtes de mise à jour (en temps-réel)

● Gestion de la saturation de la base de données

La problématique générale étant définie, il convient de présenter plus précisément les différentes particularités des systèmes de surveillance de phénomènes, en particulier les réseaux de capteurs.




De cape et de crocs - Jean sans Lune - ©Delcourt

Les réseaux de capteurs

2 Les réseaux de capteurs

Les réseaux de capteurs sont régulièrement utilisés dans le cadre de la surveillance de phénomènes naturels aussi bien qu'urbains. La notion de capteur recouvre des réalités variées, et leur mise en réseau demande une compréhension des problématiques propres à ces appareils.

Ce chapitre vise à familiariser le lecteur avec différentes notions liées aux réseaux de capteurs : leurs spécificités, leurs modes de fonctionnements, leurs possibilités mais aussi les limites à leur utilisation.

Le chapitre commence par mettre en relation l'utilisation de réseaux de capteurs et les systèmes de surveillance de phénomènes environnementaux. Par la suite, il aborde plus précisément les spécificités de la typologie et du fonctionnement de capteurs. La présentation d'un cas d'utilisation d'un réseau de capteurs, dans un contexte de surveillance volcanique, vient clore le chapitre tout en permettant d'étudier une mise en application des principes déjà évoqués.



2.1 Application à la surveillance de phénomènes environnementaux

L'étude d'habitats et de milieux spécifiques (écosystèmes difficiles d'accès, volcans,...) reste pour l'heure assez limitée. Alors qu'il est grossièrement possible d'étudier des macroclimats par le biais des techniques aujourd'hui employées, il reste difficile pour les scientifiques d'étudier les microclimats et microcosmes spécifiques à un milieu ou à une espèce. Au sein d'une forêt, on peut dénombrer de très nombreux microclimats différents. La température à l'intérieur d'un terrier sera différente de celle en haut d'un arbre, de même que l'hygrométrie. Par conséquent il est important pour les biologistes (entre autre) d'obtenir des informations précises sur ces microclimats. De même, les volcanologues doivent pouvoir être en mesure de déterminer l'état des volcans qu'ils surveillent afin de pouvoir prévenir les populations locales des risques liés l'activité volcanique. La gestion du risque environnementale impose elle-aussi l'utilisation de nombreux systèmes de surveillance. Et pour cela, les spécialistes de ces milieux peuvent avoir recours à des réseaux de capteurs. Il en est de même pour d'autres applications.

Ces capteurs doivent réunir différentes particularités. Ils doivent être économiques tant par rapport aux coûts de production qu'en terme de maintenance et surtout de consommation énergétique. Une fois mis en place, ils doivent pouvoir continuer à opérer pendant une longue durée sans intervention humaine.

Bien souvent, les capteurs, hétérogènes, sont déployés en un réseau dense. Plusieurs algorithmes de routages permettent l'envoi et la réception d'informations de la part d'un nœud particulier. Souvent, un point d'entrée de ces sous-réseaux permet l'accès au réseau de transit. Les données collectées sont par la suite centralisée vers un centre de récupération de données, en passant par le réseau de transit. Une fois collectées, les données peuvent être traitées, vérifiées, puis publiées pour être accessible depuis l'Internet.

Du fait de l’importante masse de données, il est peu envisageable de contrôler manuellement toutes les informations reçues par les capteurs. La vérification des mesures peut être faite en partie au niveau du capteur, via un contrôle algorithmique des résultats, ou bien encore par comparaison avec des résultats publiés par certains instruments de calibration. L'utilisation de ces instruments passe par un réseau de vérification, qui doit permettre un accès rapide et fiable aux données pour permettre d'ajuster les paramètres des capteurs (drift temporel,...) et éliminer ceux qui ne sont plus en état de fonctionner.



2.1.1 Les mesures

2.1.1.1 Types de mesures

On peut décomposer les données transmissibles en plusieurs grandes catégories. D'un coté, on trouvera les données continues, en streaming. C'est par exemple le cas des données issues d'un sismographe qui sont prises avec des intervalles de fréquence réguliers. Ce type de données peut par la suite tirer parti de techniques de partage de charge entre différents nœuds d'un réseau. Mais les données peuvent être également émises par suite à un événement déclencheur. Par exemple lorsqu'un radar routier repère une voiture en infraction de vitesse. Dans ce cas, il est nécessaire que le réseau offre une latence minimale.

2.1.1.2 Localisation des mesures

Pour des raisons de coût d'accès à l'information, plusieurs études se sont concentrées sur la localisation des données. On distingue principalement trois types d'approches [19] [61].

D'un coté les approches locales proposent de conserver le maximum de données au niveau local. Cette approche minimise le coût de transmission des mises à jour. Cependant, pour les requêtes sur les données, il devient alors souvent nécessaire de propager la requête au travers les différents éléments du réseau, augmentant ainsi le coût des requêtes. De plus, dans des systèmes demandant de conserver un historique des données recueillies, il devient tôt ou tard nécessaire de transmettre les données sous une forme ou sous une autre.

A l'opposé, les approches externes, souvent retrouvées dans les systèmes d'informations géographiques, proposent de centraliser les données dans une base à l'extérieur du réseau de capteurs. Dans ce cas de figure, le coût de transmission des mises à jours est bien évidemment largement supérieur. Cependant, cette approche permet de minimiser le coût de requêtage. Dans les systèmes d'aide à la décision, ou d'analyse de phénomènes comportant plusieurs variables interagissant entre-elles, le consensus actuel se veut favorable à la centralisation des données. De plus, cette approche offre une relative indépendance face aux problèmes de pannes de capteurs [67]. Si un capteur tombe soudainement en panne pendant une période critique, les données collectées par celui-ci qui ont été transmises à la base centralisée sont toujours accessibles. Enfin, force est de constater que l'approche externe est pour l'heure actuelle l'architecture la plus répandue en matière de réseaux de capteur, malgré le nombre d'études théoriques sur d'autres modèles.

Entre ces deux extrêmes se trouvent diverses approches, offrant des systèmes de réplication des données entre différents nœuds du réseau. Il s'agit d'un compromis entre les deux approches. Cependant, cela pose différents problèmes. L'utilisation de techniques de localisation spatiale des données, le stockage centré sur les données permet de définir des nœuds de réplication dans le réseau où il devient possible d'accéder aux données. En répartissant les données entre différents points du réseau, il devient possible de chercher un compromis entre les différents coûts de



requêtes (mise à jour / accès aux données). Pourtant la prise en compte de la mobilité impose de régler des problèmes de re-localisation de données, de détermination de nœuds de réplication, d'accès au réseau, etc… Et ce, en prenant en compte des restrictions temps-réelles.

En somme, la localisation des données, hétérogènes, est importante dans la mesure où elle influe sur les coûts d'accès aux données, ainsi que sur les mécanismes de réplication ou liés à la sécurisation des données. Il convient cependant de garder à l'esprit la différence fondamentale entre un réseau classique et un réseau de capteurs : les capacités limités de ces derniers. Bien que la loi de Moore [47] s'applique aux avancées technologiques effectuées dans le domaine des capteurs, leurs capacités de stockage et de calcul restent encore très hétérogènes, et d'une manière générale bien plus limitée que pour des PDAs ou autres ordinateurs.

De fait, la majorité des systèmes de surveillance actuellement en activités se basent sur une architecture utilisant un stockage de données externes. Ceci permet de centraliser les requêtes tout en maintenant une certaine sécurité des données. Ces systèmes ont généralement recours à l'utilisation d'une base de données ou de files pour la gestion de données à court terme, et exploitent des entrepôts de données pour le long terme.

Les systèmes de surveillance sont tributaires du bon fonctionnement des différents nœuds du réseau de capteurs. Ces capteurs, souvent hétérogènes, possèdent cependant certaines particularités communes.



2.2 Les capteurs

Dans ce chapitre, on définira sous le nom de capteur (cf. figure 1 [29] ) un appareil qui à la fois mesure une ou plusieurs données et les envoie à l'extérieur. Ainsi, les phases d'acquisition et de transmission sont inhérentes du capteur. Parfois, un mécanisme de stockage et de calcul peuvent compléter ce dispositif.

Les réseaux de capteurs se distinguent des autres types de réseaux de différentes manières. En premier lieu, les composants d'un réseaux de capteurs peuvent posséder des tailles de l'ordre de quelques millimètres cube. Ces nœuds sont disséminés dans le milieu à étudier et doivent assurer la prise de mesures sans intervention extérieure, tout en gérant au mieux les problèmes d'économie d'énergie et de détection de pannes. La gestion de l'énergie constitue ainsi une des principales caractéristiques de l'architecture des capteurs.

2.2.1 Les classes de capteursPlusieurs classes de capteurs peuvent être distinguées. Des capteurs spécifiques, mais généralement économiques à la construction et de tailles restreintes peuvent être utilisés pour des rôles limités. Si la flexibilité est de mise, des capteurs génériques, offrant des interfaces plus variées peuvent être mis en réseau. D'autres


Figure 1: Capteur de visibilité (jour/nuit)


capteurs peuvent offrir des capacités de gestion de flux de données plus importants, comme la vidéo ou la voix. Ces capteurs sacrifient généralement la mobilité et la consommation énergétique au profit d'une bande passante plus importante. Finalement, certains capteurs peuvent agir en tant que passerelle entre des réseaux filaires, Internet, et des réseaux de capteurs sans-fil, agiles ou mobiles.

Ces différents types de capteurs sont généralement utilisés communément au sein d'un même réseau (cf. figure 2). Les exemples de mise en place de réseaux de capteurs tendent à créer une hiérarchie entre les différents types de capteurs. A chaque niveau de cette hiérarchie, les données peuvent être agrégées, analysées. Différentes études tendent à valoriser ces processus au niveau du capteur [28]. Les différents niveaux correspondant aux potentiels de traitement des capteurs ainsi qu'aux potentiels de bande passante.

Au niveau inférieur de la hiérarchie se trouvent les capteurs spécialisés, de tailles réduites. Les données collectées par ceux-ci sont expédiées à des capteurs génériques. Ceux-ci collectent à leur tour des données plus complexes, mais sont également en charge de l'agrégation des mesures collectées par les capteurs du niveau inférieur, en fonction de leurs localisations ou du type de mesures.

Le niveau supérieur est composé de capteurs disposant de bande passante plus conséquente, ainsi que de capacités de calcul et de stockage en conséquence. Ici encore, le rôle des nœuds est de procéder à de nouvelles mesures tout en agrégeant les données des niveaux inférieurs. Ces capteurs peuvent à leur tour être en charge de zones géographiques plus importantes, permettant une division du système étudié.

Le dernier niveau, le plus élevé, est composé des nœuds les plus imposants, les moins mobiles, mais également ceux qui peuvent disposer de ressources mémoire et de calcul les plus grandes. Passerelles vers les réseaux filaires ou Internet, ces


Figure 2 : Exemple de réseau de capteur

Internet

Portail d'entréeCapteurs puissants

Station de supervisionCapteur / Station de Base



Capteurs légers mobiles


nœuds servent de point d'entrée au réseau de capteur. Les requêtes ainsi que les données devant transiter vers l'extérieur sont ainsi transférées via ces nœuds.

2.2.2 Capteurs fixes, agiles, mobilesLe paragraphe précédent a présenté une première classification des capteurs. Il existe cependant une autre distinction qui peut être introduite pour différencier les différent capteurs, liés à des critères de changement de position. Il s'agit de différencier les capteurs fixes, agiles et mobiles.

Historiquement, les capteurs déployés étaient le plus souvent fixes. Lourds et encombrants, il n'était pas possible de les déplacer sans de difficiles et coûteux réglages, mises au point. Pour cette raison, une fois mis en place, ils étaient conservés tels quels. Un radar météorologique au sol représentait, jusqu'à récemment l'exemple typique de ce genre de capteur. Depuis lors, les progrès techniques ont permis d'apporter plus de souplesse dans l'utilisation des capteurs.

Une meilleure gestion de l'énergie, des batteries plus puissantes, et un besoin de pouvoir utiliser des capteurs en des points différents ont conduit au développement de capteurs agiles. Ce terme désigne des capteurs dont le fonctionnement normal est analogue à celui de capteurs fixes pour ce qui est de la prise de mesure, mais qui peuvent être déplacés entre deux campagnes de collectes de données. Ces capteurs, plus légers, peuvent être installés par des équipes réduites de techniciens. Ils peuvent le cas échéant être démontés et ré-assemblés afin de fournir des données pertinentes collectées en d'autres points. Lors des collectes de mesure, ces capteurs sont généralement utilisés d'une manière analogue à leurs prédécesseurs. On notera que le déplacement des capteurs correspond habituellement à un mouvement discret. Ce genre de capteur est le plus souvent employé lorsque des équipes de scientifiques désirent étudier un milieu hostile ou difficile d'accès sans installer de station de mesure fixe. Des capteurs de mesure de pression de la glace, transportables dans une caisse, sont ainsi régulièrement utilisés par les glaciologues en mission aux pôles.

Les capteurs mobiles ont bénéficier des avancées de la miniaturisation des équipement électroniques. Ils peuvent être déployés en grand nombre dans de nombreux contextes où le sujet étudié est appelé à changer de position. Pour de tels capteurs, le changement de position constitue en lui-même une mesure à collecter. Le changement de position peut être discrétisé mais la collecte d'information concerne généralement des changements de positions continus. L'exemple le plus fréquent de l'utilisation de ce type de capteurs concerne la gestion de flotte de véhicules. Chaque véhicule équipé d'un GPS mobile peut ainsi être localisé.

En résumé, il existe différentes classifications entre les types de capteurs. Nos travaux ont principalement porté sur l'utilisation de réseaux de capteurs fixes ou agiles, les plus fréquents dans les systèmes de surveillance de phénomènes. Les progrès effectués en matière d'électronique ont permis de progressivement réduire la masse et le volume des capteurs, les rendant transportables puis bientôt mobiles. Ces capteurs sont fréquemment utilisés dans les systèmes actuels. Cependant, alors que le domaine du mobile bénéficie de la popularité du public et que le domaine du



fixe peut se fier à l'expérience accumulée, très peu de travaux concernent les capteurs agiles. Or, ces capteurs sont bien souvent au coeur de systèmes de surveillance de phénomènes.

2.2.3 Fonctionnement des capteurs et gestion de l'énergieLes différents types de capteurs imposent des architectures matérielles et logicielles en conséquence. Les capteurs des niveaux inférieurs ne peuvent se permettre d'utiliser des systèmes d'opération réservés habituellement réservés à des ordinateurs. Des solutions, telles TinyOS [80], permettent de créer des systèmes correspondant aux capacités spécifiques des capteurs les plus légers, en proposant des interfaces simplifiées et des capacités de connexions réseaux. TinyOS possède en outre la possibilité d'être utilisé avec des ressources restreintes. Lorsque les capacités augmentent, certains systèmes d'opérations embarqués, souvent des variantes de Linux, permettent des opérations plus complexes.

Un des facteurs d'optimisation principal porté par les concepteurs de réseaux de capteurs concerne la gestion de l'énergie. Un capteur doit pouvoir fonctionner sans intervention humaine pendant plusieurs semaines, plusieurs mois, voire années. Les systèmes d'opération embarqués, tout comme TinyOS permettent une gestion approfondie de l'énergie des capteurs. Plusieurs facteurs doivent être pris en compte. La prise de mesure nécessite évidemment une consommation d'énergie. Mais il s'agit là d'une consommation qu'il est difficile de réduire. Un autre facteur de consommation d'énergie est lié aux éventuels processus de validation des mesures. Ceux-ci demandent l'accès à certaines ressources, certains calculs et par conséquent génèrent une déperdition d'énergie. Mais il s'agit là une fois encore d'une déperdition minime.

La principale source de déperdition d'énergie est liée à la transmission de données. Les capteurs utilisant des ondes radios doivent prendre en compte le coût de transmission des données. Ils doivent également prendre en compte le coût de l'écoute, même passive des canaux utilisés pour les transmissions. Dans l'idéal, le capteur devrait être à même d'éteindre l'émetteur lorsque celui-ci n'est pas activement utilisé. Le cycle d'utilisation de celui-ci pouvant à son tour être programmé en fonction des spécificités des capteurs, et des spécificités du système de vérification des données.

En somme, les capteurs mis en réseaux peuvent être répartis dans des classes en fonction des ressources disponibles. On peut différencier des capteurs légers spécifiques, des capteurs génériques, des capteurs à grandes bandes passantes et des passerelles de réseaux. Ces différents capteurs peuvent être classés selon une hiérarchie dont les premières classes représentent les éléments inférieurs. Ces capteurs, pour assurer un fonctionnement optimum doivent prendre en compte les ressources disponibles et la consommation d'énergie. Les différents systèmes d'opérations utilisés doivent ainsi prendre en compte ces spécificités pour régler les problèmes de la mise en réseaux de capteurs.



2.2.4 Considérations RéseauLa mise en réseau de capteurs impose l'adaptation des protocoles et usages en cours dans le monde du réseau afin de correspondre aux réalités des capteurs.

2.2.4.1 Routage

Du fait des différentes contraintes imposées aux réseaux de capteurs, leur conception doit être couplée à l'utilisation de techniques de routage et de répartition de tâches spécifiques.

Le routage dans ce type de réseau possède quelques particularités. En premier lieu, il doit pouvoir prendre en compte les changements de topologie, la qualité des liaisons entre les nœuds, le taux de mises à jour et éventuellement la répartition des nœuds à partir desquels les informations seront utilisées.

Alors que dans certains cas la disposition fixe des capteurs permet de faciliter les techniques de routage (par exemple en connaissant leur fréquence de prise de mesure), dans d'autres conditions le routage s'avère plus complexe. Tout particulièrement lorsque les capteurs sont mobiles.

Les techniques de routages doivent également prendre en compte le type de requêtes formulables et la localisation des données.

2.2.4.2 Transmission

Le mode de transmission de données est lié aux techniques de routage et au type de données à transmettre. La localisation des données influe ainsi considérablement sur les capacités de transmission des différents éléments du réseau de capteurs.

De plus, le mode de transmission est lié au type de capteurs. Dans la mesure où les capteurs doivent pouvoir rester en activité sans intervention humaine pendant une longue période, ils doivent économiser leurs batteries. Or, dans le cas de réseaux sans-fil, l'utilisation de la radio pour transmettre ou recevoir des informations est coûteuse en terme d'énergie. Par conséquent les capteurs doivent limiter leur utilisation de la radio. Ceci se traduit par un duty-cycle2 faible [32].

Les techniques d'accès au canal filaires, tels CSMA (Carrier Sense Multiple Access) [26] sont peu adaptées au monde non filaire. Il est possible pour un capteur de rester en sommeil et de ne se réveiller qu'à intervalle régulier pour écouter le canal. S'il perçoit une transmission, le capteur se réveille et écoute les paquets qui sont transmis. Ceci implique que l'émetteur doit envoyer plusieurs fois le même paquet et que le récepteur doit se réveiller au moins une fois durant ce temps de transmission. Cette technique a été baptisée Low Power Listening (LPL) [32]. Du fait de la répétition, le coût de transmission est plus élevé que pour CSMA. LPL offre cependant des résultats corrects pour traiter des évènements déclenchés à un instant donné.

2Duty-cycle : pourcentage de temps pendant lequel le capteur est à l'écoute du réseau ou transmet



D'autres techniques comme TDMA (Time Division Multiple Access) [10] partage le temps créneaux temporels utilisables par les capteurs (cf. figure 3). Lorsque les créneaux ne sont pas assignés, il n'est pas nécessaire que le capteur écoute. Les difficultés commencent dès lors que l'environnement devient multisaut (il est nécessaire de passer par des nœuds intermédiaires pour permettre à deux nœuds de se connecter), avec des besoins de synchronisation accrus. Dans l'ensemble, TDMA est caractérisé par un temps de latence plus important. TDMA sera plus efficace pour gérer des données issues d'une prise de mesures en continu. Une utilisation conjointe avec LPL peut permettre d'offrir des outils pour la synchronisation de différents nœuds.

On pourra également se reporter en terme d'accès au canal à différents protocoles du monde réseau. L'expérience 802.11 sur les réseaux locaux sans fils [27] a montré l'influence de comportements purement physique sur le réseau. Ainsi dans le cas de communication centralisée (infrastructure), la position des nœuds par rapport au point d'accès revêt une grande importance. Un nœud situé dans un endroit inapproprié va ralentir le débit du réseau lors de sa transmission, du fait du mécanisme d'adaptation de vitesse de transfert. Ou encore, on notera les influences des différentes zones de recouvrement avec les interférences et les brouillages possibles.

Bluetooth [11] offre d'autres exemples. Cette norme a été à l'origine pensée pour limiter la consommation d'énergie. Elle utilise entre autre plusieurs techniques de gestion de l'accès au canal. Entre autre, elle définit dans ses standards la possibilité d'utilisation de techniques TDMA (fréquence 1600 Hz). Après un temps d'inactivité, un nœud peut passer en sommeil. Dès lors, il repassera en écoute à intervalles régulier pour écouter si le maître du piconet lui demande de se réveiller. Si c'est le cas, il se remet en activité. La synchronisation des éléments du piconet s'effectuant à partir de l'horloge de celui-ci.

2.2.4.3 Surveillance de l'état du réseau

Dans la mesure où les capteurs sont laissés à la merci de l'environnement (intempéries,...), un système de surveillance de l'état du réseau est nécessaire . Il doit permettre d'éteindre certains capteurs défaillants, de vérifier la validité des mesures,... Pour cela, il peut utiliser des signaux implicites et explicites. Certains capteurs peuvent être utilisés explicitement pour mesurer l'état du réseau. Les


Figure 3 : Division du temps TDMA entre 3 tâches

Temps

1 2 3 1 2 3

ΔT ΔT ΔT


mesures implicites peuvent être déduites à partir des autres données (dérive temporelle,...). [42][67] Il apparaît légitime de s’interroger sur la possibilité d'assurer des prises de mesures sur l'état du réseau principal et de les transmettre de manière hors bande, par le biais d'un réseau secondaire pour pallier les défaillances du primaire.

2.2.5 Les difficultés liées à l'utilisation de capteursL'utilisation de capteurs ne se fait pas sans aléas. En effet, les capteurs sont souvent censés opérer dans des environnements difficiles, si ce n'est ouvertement hostiles.

Les conditions climatiques peuvent se montrer tout particulièrement problématiques. Vent, pluie, orages ou encore courants marins sont souvent la cause de pannes de capteurs.

Un frein bien plus restrictif à l'utilisation des capteurs vient de leur dépendance en énergie. En effet, ils doivent souvent opérer en autonomie ou en semi-autonomie, ne disposant que d'une source limitée d'énergie (batteries, piles, panneaux solaires). Il convient donc de développer des protocoles, des techniques d'utilisation et de fonctionnement des capteurs visant à limiter leur consommation énergétique, bien souvent au détriment de la précision des données ou au détriment de l'accès en temps-réel aux données.

Un problème plus discret, mais assurément bien plus dangereux de l'utilisation des capteurs vient du dérèglement des instruments de mesure des capteurs. Avec le temps, la précision s'amenuise, pouvant à terme mener à des mesures erronées. Ces dérèglements peuvent être en partie repérés au niveau du capteur, mais également au niveau du réseau. Ainsi, un niveau de batterie faible peut entraîner une perte de qualité des mesures, mais entraînera également un décalage dans l'ordonnancement des transmissions. En d'autres termes, les données seront transmises en retard. De plus, lorsque le nombre de capteurs le permet, une mise en corrélation des différentes mesures permet une correction des mesures.

Une donnée peut être fausse non pas à cause des capteurs, mais à cause des conditions d'utilisation du capteur. Il est à noter que l'utilisation de réseaux de capteurs peut amener à des résultats parfois troublants. Ainsi, tous les navires transitant dans les eaux canadiennes transmettent régulièrement des données météorologiques, utilisées par l'agence éponyme [71]. Une donnée en particulier s'est révélée imperméable à toute analyse pendant plusieurs semaines en montrant des vents bien plus importants qu'ils n'auraient dû l'être. Il s'est avéré que le capteur opérait à la perfection. Cependant, la position du navire, temporairement mis en cale, l'avait placé dans un couloir à vents, faussant ainsi les données collectées.

D'autres problèmes liés à l'utilisation de capteurs peuvent apparaître. Ainsi, une part non négligeable des pannes des capteurs installés le long des autoroutes du nord-est français seraient liés à des accidents de sangliers... Il ne faut cependant pas sous-estimer le nombre de vol de capteurs, de détériorations volontaires ou d'une manière générale l'impact de l'homme sur l'efficacité du réseau...



De fait, la qualité des données issues d'un réseau de capteurs est sensible à de nombreux facteurs liés aussi bien au milieu extérieur qu'à l'architecture du capteur lui-même.

Il convient donc de mettre en place des systèmes visant à repérer ces dysfonctionnements. Ces derniers peuvent être repérés au niveau du capteur, au niveau du système collectant les différentes mesures ou bien encore au niveau du réseau de capteur.

2.2.6 Conclusion sur l'utilisation des capteursLes réseaux de capteurs recouvrent des réalités diverses. Un capteur peut être imposant, volumineux ou au contraire de taille très modeste. Certaines particularités sont cependant partagées par ces appareils, en premier lieu le besoin d'une gestion efficace de l'énergie.

Les réseaux de surveillance de phénomènes utilisent de nombreux capteurs. Alors que les premiers systèmes historiques utilisaient des capteurs volumineux, les progrès en électronique ont permis l'utilisation de capteurs de plus en plus légers et agiles / mobiles.

Les systèmes de surveillance de phénomènes possèdent généralement une architecture organisée autour d'un système central chargé de collecter et de traiter les mesures collectées. Ceci permet de limiter le risque de perte de données suite à une panne capteur tout en favorisant le traitement des données.

Chaque système de surveillance possède ses propres caractéristiques. Ceux qui utilisent des réseaux de capteurs nécessitent l'utilisation de méthodes d'indexation de données basées sur les positions des différents capteurs et les temps de mesures effectuées. Les mesures n'entrent pas directement dans la partie indexation.

De nombreux systèmes utilisent des capteurs, mais les particularités de ces utilisation sont souvent spécifiques au milieu étudié.



2.3 Cas d'utilisation d'un réseau de capteurs

Le Popocatepetl, volcan mexicain, est depuis plusieurs années sous la surveillance du CENAPRED [13], centre national de prévention des catastrophes naturelles au Mexique. Un réseau de capteurs a été mis en place pour collecter les données relatives à ce volcan (cf. figure 4). Alors que les capteurs mesurant les concentrations des gaz ont des fréquences de prélèvement relativement faibles, les sismographes, pouvant atteindre les 100 Hz imposent à la base de données chargée de collecter celles-ci des contraintes temps réel, plus particulièrement pour la mise à jour.

Figure 4 : Stations de mesure du volcan Popocatépetl

Les volcanologues admettent que la perte d'une faible partie des mesures est acceptable; les contraintes rencontrées sont alors dites « souples ». Une définition plus précise de ce terme sera fournie dans la partie traitant du temps-réel.

De même, ces spécialistes ont pour habitude de travailler en premier lieu sur l'évolution des données collectées. La valeur brute de la mesure est bien souvent secondaire vis à vis de l'évolution au cours du temps des mesures prises. Ainsi, certains facteurs externes diminuant la qualité d'une mesure peuvent voir leurs impacts diminués. Un décalage constant et systématique dans les mesures collectées affecte le rapport entre deux mesures d'une manière moindre qu'une variation ponctuelle d'une mesure.

De par la nature même du phénomène surveillé (volcanisme), il est nécessaire de prendre en compte les risques de défaillance des différents capteurs. Ceux-ci sont exposés aux intempéries et aux dangers liés au volcanisme. Par conséquent, le système de surveillance du volcan doit prendre en considération la probabilité selon



laquelle les capteurs puissent tomber en panne, et notamment au moment même où ils deviendraient les plus utiles (éruption,...).

De plus, différents programmes utilisent les données collectées pour pouvoir calculer certains pronostics quant à l'activité présente et future du volcan. Or, ces pronostics se font sur la base de comparaisons de données hétérogènes étalées dans le temps et également réparties dans l'espace. Ces processus doivent également prendre en compte la qualité des données collectées.

Il devient donc nécessaire de pouvoir centraliser les données sur une base afin de pouvoir effectuer les différentes analyses nécessaires. Dans le cas du Popocatépetl, une station centrale récupère dans une base de données les informations provenant des autres stations, les traite, puis finit par les stocker dans un entrepôt de données passé un délai donné.

2.3.1 Du réseau de capteur au système de surveillanceLorsque les différents capteurs collectent des mesures, celles-ci sont expédiées à intervalles temporels réguliers vers un système centralisé, conformément aux exigences du système EarthWorm de l'USGS [82].

Le système Earthworm peut être séparé en deux parties. La première, Automatic Earthworm est chargé de la notification en temps-réel (pas de conservation de données passées) tandis que l'Interactive Earthworm permet de travailler sur du plus long terme, avec des données passées. C'est ce second type de structure qui est généralement dans les systèmes de surveillance volcanique.

Automatic Earthworm est un système utilisant des messages pour transmettre les informations. Des annonces porteuses d'en-têtes relatives au type de message et à l'émetteur sont envoyées sur le réseau de surveillance constitué des différents nœuds chargés de l'affichage ou de l'analyse immédiate des données. Les différents éléments du système de surveillance peuvent dès lors décider de recevoir les messages dont ils ont besoin.

Interactive Earthworm utilise une base de données pour conserver les données plus anciennes, celles qui viennent de quitter l'Automatic Earthworm. Une fois encore, des messages sont envoyés entre les différents éléments du réseau. Les différents éléments permettent ici une analyse des mesures collectées sur moyen voire long terme.

Il est à noter que les détails de l'implémentation peuvent fortement varier d'un système à l'autre, en fonction des affinités des administrateurs avec les spécificités informatiques d'Earthworm.

Les mesures des différents capteurs sont libellées en fonction de ces derniers et des dates des mesures. Dans le cas d'une agrégation au sein du capteur, les mesures agrégées peuvent être assimilées à une unique mesure particulière ou être redécoupée en mesures individuelles.

Arrivée à l'entrée du réseau de surveillance Earthworm, la mesure est généralement placée dans un tourniquet. Les différents processus de validation de la mesure ou



d'affichage des mesures actuelles peuvent alors y avoir accès via l'Automatic Earthworm.

En fin de circuit, les données sont collectées au sein d'une base de données en mémoire centrale. Pour l'heure, elles sont indexées en fonction de l'identifiant du capteur émetteur et du marqueur temporel de la mesure. Les différents processus d'analyse de données peuvent alors avoir recours à cette base afin de collecter les données nécessaires.

En fin de cycle, après un temps prédéterminé, les données sont transférées vers un entrepôt de données afin de permettre un accès aux données sur de long voire très long terme.

On pourra noter que les mesures sont jusqu'alors indexées en fonction des identifiants des capteurs émetteurs et des marqueurs temporels des mesures. Les besoins des chercheurs ayant évolué, ils souhaitent désormais utiliser des références spatiales pour différencier les capteurs, tout en conservant les indices temporels pour différencier les mesures d'un même capteur.

2.3.2 Les données collectéesLes données collectées par le réseau de surveillance sont hétérogènes, provenant de différents types de capteurs. Alors que les capteurs sont majoritairement fixes, certains traitements informatisés des données recueillies peuvent générer des agrégats qui peuvent être considérés comme des données agiles ou mobiles. Par exemple, il est possible de considérer la localisation de l'épicentre (déterminée par études des données sismographiques) d'un séisme comme provenant d'un capteur mobile.

De même, les développements technologiques permettent d'utiliser des stations de mesures agiles ou mobiles afin d'accéder à des données plus précises, relatives à des zones particulières. Les spécialistes s'intéressent alors plus aux données issues d'un endroit particulier qu'aux coordonnées précises du capteur. Celui-ci peut changer de


Figure 5 : Système de surveillance de phénomène naturel

CommunicationManagement

Sensors Management

Sensor acquisition

CommunicationManagement

RAM BasedDatabase

DataWarehouse

Sensor System Central System


position, mais il redevient momentanément fixe lors de la prise de mesures, ou tout du moins, la valeur mesurée apparaît plus intéressante que la position du capteur.

Pour l'heure, les données collectées sont référencées par l'identifiant du capteur qui a pris la mesure et de par la date de la mesure. Ces données sont centralisées dans une base de données conforme aux spécifications Earthworm, développées par l'USGS [82] comme présenté par la figure 5. On note cependant la volonté d'utiliser à l'avenir les localisations spatiales des capteurs comme moyen de repère servant de base à l'indexation.

La figure 6 présente une modélisation des données utilisées. Trois notions centrales apparaissent : celles de capteur, date et mesure. Toute mesure est liée à un capteur particulier. Chaque mesure est également liée à une date. Les mesures sont ainsi référencées en fonction du capteur et de la date de la mesure. La mesure n'est pas indexée par elle-même, ce sont les références (identifiant du capteur / date) de celle-ci qui le sont.

Concernant le mode de requêtage des données de la base par les volcanologues, il s'agit le plus souvent d'agréger les données sur un certain intervalle temporel. Les volcanologues utilisent généralement les données issues de certaines stations de références pour se forger une première impression sur l'état du volcan avant d'affiner leur analyse en consultant les données d'autres capteurs. Historiquement, l'accès aux données s'effectuait par l'intermédiaire des identifiant des capteurs. Ils sont cependant plus intéressés par les données spatialement localisées en un point (le capteur), et temporellement matérialisées par un intervalle (se terminant à l'instant présent).


Figure 6 : Formats des données


2.3.3 Spécification des besoinsLe cas du Popocatépetl montre certaines particularités qui peuvent être étendues à d'autres systèmes de surveillance de phénomènes en temps-réel [39].

En premier lieu, la nature des éléments figurant dans la base de données. Notons que pour le système de gestion de la base, ce ne sont pas les mesures qui sont directement indexées. L'indexation doit s'effectuer en fonction de la localisation du capteur et du marqueur temporel associé à la mesure. Ainsi, le système ne manipule pas directement les valeurs mesurées. Il travaille sur des dimensions spatiales et temporelles associées aux mesures, par l'intermédiaire des capteurs.

Les données les plus récentes sont valorisées par rapport aux données plus anciennes. En d'autres termes, les volcanologues sont généralement plus intéressés par l'état récent ou actuel du volcan que par son état passé (à l'exception de périodes d'activités types).

Les spécialistes, utilisateurs du système ont exprimé la volonté d'exploiter les aspects spatiaux liés aux positions des capteurs pour les référencer dans la base de données, et non plus seulement leurs identifiants. Ceci devrait permettre d'effectuer des requêtes spatio-temporelles et de gérer de manière plus précise la mobilité potentielle des capteurs.

Un nombre important de mises à jour provient de capteurs transmettant vers une base de données centralisée. Du fait du nombre de capteurs et de leur fréquence de mise à jour, on se trouve face à des contraintes temps-réel au niveau de la mise à jour. Les mesures des capteurs à Ti doivent être insérées dans la base avant que les mesures à Ti+1 n'arrivent.

Pour la même raison, il devient nécessaire de valoriser les mises à jours par rapport aux autres requêtes possibles. Alors que les autres processus utilisant les données collectées travaillent en tâche de fond, les mises à jours doivent être effectuées en priorité.

En somme, la spécification des besoins des volcanologues est centrée sur la gestion de données spatio-temporelles. Les données, mises à jour régulièrement sont marquées par une position spatiale liée à un capteur agile (lui-même possédant un identifiant), et un indicateur temporel marquant l'instant de la mesure. Les données sont envoyées à une base de données centralisée qui doit se mettre à jour suivant des contraintes temps-réel douces. L'index de la base doit également faciliter l'accès aux données les plus récentes et prendre en compte l'agilité, la propension des capteurs à changer de position.



2.4 Conclusion sur les réseaux de capteurs pour la surveillance de phénomènes

Les réseaux de capteurs sont de plus en plus fréquemment utilisés. Historiquement, les réseaux se composaient d'éléments onéreux, lourds et immobiles. Les progrès techniques ont permis de s'affranchir de certaines de ces contraintes.

Les capteurs tendent à plus d'agilité, voire de mobilité. L'agilité peut se définir comme la propension d'un capteur à changer de position entre deux séries de mesures (mouvement discrets). Un abus de langage pourra comparer l'agilité à une mobilité fortement restreinte.

Du fait de la généralisation de ce type de capteurs, il devient nécessaire de prendre en compte ce phénomène d'agilité ou de mobilité. Plus spécifiquement, les systèmes de surveillance de phénomènes se doivent de prendre en compte les particularités de ces capteurs, via une gestion de l'historique de déplacement des capteurs et / ou une gestion plus fine des positions de capteurs.

Les travaux développés dans cette thèse portent ainsi sur l'indexation de données issues de ces capteurs tout en tirant parti de la nature fixe ou agile de certains capteurs.

La conception des capteurs et des technologies les utilisant doit également prendre en compte certaines spécificités, au premier rang desquelles le besoin d'économiser l'énergie. Un capteur agile, et plus encore un capteur mobile doit pouvoir limiter sa consommation afin d'augmenter sa durée d'utilisation.

Il est souvent possible d'établir une hiérarchie entre les capteurs. Les capteurs les plus légers sont généralement spécialisés dans un type de mesure précis. D'autres, légèrement plus volumineux offrent plus de versatilité et des capacités de stockage et de calcul supérieures. Il en va de même de l'échelon supérieur, généralement en charge d'une partie du réseau de collecte de mesure. Enfin, au niveau le plus élevé se trouvent les capteurs les plus encombrants, mais aussi les plus performants en terme de calcul, bande passante ou de stockage de données. Ils servent généralement de points d'entrée au réseau de capteurs, d'interface vers des réseaux extérieurs.

Les différentes architectures de réseau proposent de conserver les mesures effectuées directement au sein du réseau de capteurs ou bien dans un centre externe.

L'utilisation de réseaux de capteurs pour la surveillance de phénomènes est généralement liée à l'utilisation d'un système centralisé de collecte et d'analyse des données. Le risque de disparition d'un capteur est généralement réel. En cas de crise majeure, la disponibilité des données impose l'utilisation de mécanisme permettant un accès aux données dans des conditions optimales. Une approche externe de collecte de données est préconisée, fondée sur l'utilisation d'une base et / ou d'un entrepôt de donnée.



Les mesures collectées sont habituellement référencées en fonction du capteur dont elles sont issues et de la date de la mesure. Un système d'indexation pour ces mesures devra donc assurer une indexation en fonction de ces facteurs. Les données ne sont pas directement référencées par les valeurs de mesure collectées mais par la corrélation entre une clef et une date.

Les réseaux de capteurs gagnant en taille, le nombre de mesures collectées ne cesse de croître. Dans le cadre de l'utilisation d'un système centralisé, l'indexation de ces mesures doit répondre à des contraintes temps-réel. Ces contraintes sont issues de la masse de données à gérer. Une mesure doit être indexée avant qu'une version plus récente ne parvienne au système...

De même, dans le cas de la gestion d'une crise, l'accès aux données doit également répondre à des impératifs temporels. De facto, la gestion d'un réseau de capteurs est liée à la notion de temps-réel.




De cape et de crocs – Chasseurs de Chimères - ©Delcourt

Contexte : définition de Temps Réel

3 Contexte : définition de Temps Réel

L'expression « temps réel » est régulièrement utilisée par de nombreux publicistes, journalistes et plus généralement un nombre certain de technophiles auto-proclamés. Sous leurs plumes, ces deux termes accolés deviennent la preuve scientifique irréfutable (sic) que tel appareil fournit des résultats d'une qualité supérieure et plus rapidement que la concurrence ou que tel service est accessible directement à la suite d'un simple appel téléphonique (nécessairement sur-facturé). Autant d'éloges qui placent la rapidité d'action, d'exécution ou de disponibilité au premier plan. Mais cette définition dont s'enorgueillissent nombre de vendeurs laisse de marbre ceux qui ont eu l'occasion de découvrir au hasard de leurs recherches une définition plus « informatique » du temps réel.

Le présent chapitre s'allouera l'opportunité de remettre en cause des années de propagande publicitaire pour dans un premier temps présenter une définition informatique du temps réel. Par la suite, les applications des concepts énoncés dans le cadre de bases de données illustreront les enjeux, tenants et aboutissants de l'utilisation d'un système temps réel. Finalement, une réflexion sur l'évolution de cette notion clôturera cette partie.



3.1 Une définition du temps réel

Alors que les commerciaux d'une majorité de société informatique cherchent à affubler du sigle 'temps réel' tous les produits sortant de leurs usines, les utilisateurs peuvent se demander quelle est la définition véritable de ce terme.

En des termes simples, le principe consiste à s'assurer qu'une tâche, un travail sera effectué selon des contraintes de temps. Ce travail doit être achevé en temps et en heure. Dans un langage plus informatique, et plus orienté base de données, les requêtes doivent s'exécuter dans un intervalle de temps déterminé. La notion de temps réel est donc quelque peu différente de la notion d'exécution rapide, de calcul rapide. Selon cette définition, de nombreuses tâches quotidiennes peuvent s'estampiller au sceau du temps réel, la condition première posant le respect de contraintes temporelles comme un impératif [12][37].

Il est possible d'établir un ordre d'importance entre les différentes contraintes temporelles d'exécution qui peuvent exister. Un exemple peut éclairer ce commentaire. « Il faut arroser telle plante une fois par semaine. » Dans un sens très élargi, il s'agit d'un travail temps réel. Si l'arrosage est oublié à l'occasion, les feuilles risquent de jaunir quelque peu, mais les conséquences sont encore relativement minimes. En revanche, si un capteur de surveillance du noyau d'une centrale nucléaire venait à ne plus respecter les intervalles de prises de mesures, n'en prenant qu'une toutes les 5 minutes au lieu de toutes les secondes, les conséquences pourraient ici être catastrophiques. Et ce, que les informations collectées soient visualisées avec un alphabet cyrillique ou latin. Il devient par la même possible de hiérarchiser les types de contraintes temporelles, le plus souvent en assignant des priorités, signalant non pas quelle opération doit s'effectuer avant une autre, mais quelle opération est plus importante qu'une autre. Examinons les différents types de contraintes [37] :

● Les contraintes souples (soft deadlines), sont les moins exigeantes. Le non-respect d'une de ces contraintes est à éviter. S'il devait arriver, ce non-respect serait gênant, mais pas « incapacitant » pour le système. L'arrosage de sa plante verte peut servir d'exemple. Il a été décidé que la plante qui orne la fenêtre du bureau sera arrosée tous les lundis et jeudis à huit heures du matin, avec une marge d'une demi-heure. Si pour des raisons d'emploi du temps personne n'est présent au bureau un lundi matin avant dix heures, il est peu probable que la plante dépérisse...

● Les contraintes fermes (firm deadlines) sont plus contraignantes. Le non-respect de ces contraintes est à éviter, puisqu'il a des conséquences plus lourdes pour le système. Cependant, il est admis qu'un tel dépassement puisse exceptionnellement arriver. Il arrive parfois de dépasser la date d'une piqûre de rappel de vaccin de quelques jours... Ce n'est pas recommandé, mais cela peut arriver exceptionnellement, pour certains vaccins.



● Les contraintes dures (hard deadlines) sont les plus sévères. Leur non-respect a des conséquences désastreuses pour le système. Si l'une d'entre elle venait à ne pas être respectée, tout le système pourrait s'arrêter de fonctionner correctement. Il est donc impératif que ces contraintes soient respectées. De nombreuses applications militaires ont des impératifs temporels de l'ordre de la milliseconde...

En informatique, de telles contraintes ont donné naissance à quelques fausses idées. En premier lieu, travailler en temps réel n'implique pas nécessairement de travailler avec une machine possédant une grosse capacité de calcul. Calculer vite n'est pas synonyme de calculer en temps réel. Il est possible qu'une ressource demandée par une opération de haute priorité soit bloquée par une opération de plus faible priorité, empêchant ainsi un fonctionnement optimal du système, et risquant ainsi de faire dépasser certaines limites temporelles.

Il convient également de remarquer que les systèmes prenant en charge des transactions temps réel peuvent également être appelés à gérer d'autres transactions non-temps réel.

Dans le domaine des bases de données, la tendance veut qu'il soit préférable de conserver la base en mémoire vive pour limiter les accès disques, plus lents, et ainsi avoir de meilleures chances de respecter les contraintes. Cependant cette technique est-elle aussi sensible au même problème d'inversion de priorité3 [37].

Il est également vain de croire que les avancées au niveau matériel informatique vont résoudre les problèmes liés au temps réel, pour les mêmes raisons.

Concernant les bases de données, il semble illusoire de supposer que les progrès techniques vont directement apporter une solution aux problèmes temps réel. De la même manière, il est faux de croire qu'une base de donnée temporelle soit une base temps réel. Une base de données temporelles gère des informations relatives au temps (par exemple en archéologie), mais n'impose pas intrinsèquement le respect de limitations temporelles aux transactions.

Il est possible de déduire de ces remarques qu'un système temps réel a pour vocation de permettre à des opérations de s'effectuer dans des limites de temps déterminées. Pour cela, le système peut utiliser différentes techniques liées à l'attribution de priorités. Toutes les tâches entrantes dans le système se voient attribuer une priorité en fonction de leur importance. Par la suite, le système devra mettre en place une politique de contrôle de la concurrence entre les opérations. C'est à dire qu'il devra mettre en place des méthodes pour déterminer quelle transaction pourra accéder à une ressource donnée lorsque plusieurs autres voudront y accéder également...

Deux méthodes de gestion de priorités se distinguent de leurs concurrentes :

- La première, Rate Monotonic [41], donne aux différentes transactions une priorité fixe, fonction de la fréquence de celles-ci.

3L'inversion de priorité découle d'un blocage d'une ressource par une transaction de priorité faible. Lorsqu'une transaction de priorité plus importante tente d'apposer un verrou sur la ressource, celle-ci n'est déjà plus disponible. La transaction de haute priorité est contrainte d'attendre la fin de celle de basse priorité.



- La seconde, Earliest Deadline First (EDF) [16], propose d'affecter des priorités variables, fonction du temps entre le moment présent et la fin de la limite temporelle.

3.1.1 Ordonnancement et assignation de prioritéEn termes informatiques, l'ordonnancement consiste à l'établissement d'une planification dans le but d'une utilisation optimale des ressources disponibles. L'ordonnancement utilise les priorités attribuées aux transactions. Ainsi, dans un système temps réel, la première difficulté consiste à attribuer aux différentes tâches les priorités correspondantes. La tendance actuelle s'oriente autour de deux solutions : Earliest Deadline First (EDF) [16] et Rate Monotonic [41].

3.1.1.1 Earliest deadline first

Dans cette approche en ligne4, les transactions se voient attribuer des priorités qui peuvent varier au cours du temps. Une priorité originelle est attribuée à la transaction, en fonction de son importance. Puis, alors qu'elle se rapproche de sa limite temporelle, sa priorité augmente.

Ce système permet à des transactions d'importance restreinte mais avec des délais courts d'avoir une chance de pouvoir se réaliser. En effet, si des transactions plus importantes mais avec des délais plus longs arrivent, elles risquent de monopoliser les ressources. Elles empêcheront ainsi certaines transactions moins importantes de s'effectuer à temps. Par là-même, la méthode EDF est utilisable dans les systèmes avec des tâches périodiques et non périodiques.

Cependant cette solution n'est pas parfaite. Si l'ordonnancement n'est pas adéquat, les résultats peuvent être catastrophiques, aucune transaction ne réussissant à s'effectuer à temps.

Least Laxity [45], une autre technique d'ordonnancement, s'inspire de cette première solution. La laxité correspond au temps entre le moment où le traitement serait terminé si il commençait immédiatement et la limite temporelle de la transaction. Least laxity valorise les transactions avec la laxité la plus faible. Il est cependant nécessaire de connaître au préalable le temps de calcul et la limite temporelle. De plus, cela implique aussi une gestion des dépassements de temps de calcul.

On notera cependant que ces techniques ne sont pas idéales dans le cas de systèmes périodiques. Il est souvent préférable d'utiliser rate monotonic pour gérer les transactions périodiques.

4En ligne : un élément est dit « en-ligne » lorsque celui-ci est opérationnel au moment considéré. Par opposition, un élément « hors ligne » n'est pas directement accessible par le système.



3.1.1.2 Rate Monotonic

Dans cette approche, orientée système périodique, la priorité est fixée en fonction de la fréquence d'un évènement. Remarquons que de nombreux systèmes ne sont pas purement périodiques, y compris ceux utilisant les réseaux de capteurs.

Inverse Deadline, ou Deadline Monotonic est une alternative à ce système. La notion de délai critique est utilisée pour déterminer l'ordonnancement. Une tâche prioritaire possède le plus petit délai critique avant la fin de son intervalle de validité. Cet algorithme possède les mêmes performances que Rate Monotonic pour ce qui est des tâches à échéances sur requête mais lui est supérieur pour les autres types de configuration.

3.1.1.3 Gestion des transactions apériodiques

Alors que les systèmes précédents ont d'abord été mis en place pour prendre en compte les particularités des systèmes périodiques, il apparaît que les besoins réels dans le domaine temps réel sont de prendre en compte la nécessité de répondre à des transactions apériodiques. Ce cas de figure est courant lorsque le système doit répondre à des évènements particuliers. Alors que EDF permet une gestion de ces transactions, d'autres solutions existent...

Il est possible de traiter les transactions apériodiques en arrière-plan. C'est à dire que le système se charge de celles-ci lorsque le processeur est inactif, après avoir traité les transactions périodiques. Ce système montre vite ses limites lorsque la charge périodique du système augmente.

Une autre solution consiste à utiliser un serveur de tâches périodiques. Une tâche périodique particulière est créée, avec sa propre période et sa propre place dans l'ordonnancement des autres tâches. Elle a pour but de veiller à l'ordonnancement des transactions apériodiques. Ce serveur prend en charge l'exécution des tâches apériodiques. Une solution est de les exécuter lorsque le serveur accède aux ressources. S'il n'existe pas de transaction apériodique, il peut alors « rendre la main » et le système peut alors passer à la transaction suivante.

Il convient de garder à l'esprit que la priorité n'est pas supposée déterminer quelle transaction doit s'effectuer en premier. La priorité doit indiquer quelle transaction est plus importante qu'une autre. Il appartient au contrôle de la concurrence d'aider à déterminer laquelle aura accès aux ressources demandées.

3.1.2 Méthodes répandues de contrôle de la concurrence.Pour ce qui est des protocoles de contrôle de la concurrence, deux grandes familles permettent un classement : les protocoles avec gestion de verrous, et ceux dits « optimistes ». L'utilisation de tels contrôles permet de réglementer l'accès aux données en fonction des priorités assignées. Si EDF ou Rate Monotonic attribuent des priorités, il appartient au contrôle de concurrence de s'assurer du bon



fonctionnement du système en respectant ces contraintes et en s'assurant que les données accédées respectent ces priorités.

3.1.2.1 Contrôle à verrou

Les algorithmes basés sur le Priority Ceiling Protocol (PCP) [21], utilisent des priorités de plafond. Chaque ressource se voit attribuer une priorité égale à la plus haute priorité des transactions susceptibles d'y accéder : la priorité plafond. Une transaction peut accéder à une ressource lorsque sa priorité correspond à celle de la ressource.

L'algorithme 2PL-HP [1], aussi connu sous le nom de « protocole d'abandon de priorité » force une transaction de plus faible priorité à abandonner son exécution lorsqu'une inversion de priorité apparaît. Si au contraire la nouvelle transaction possède une priorité plus faible, elle attend la libération du verrou qui intervient lorsque la transaction de forte priorité se termine. De plus, une transaction de lecture ne peut être ajoutée à la liste des transactions à exécuter que si elle possède une priorité supérieure à toute autre transaction d'écriture. Ce protocole favorise les transactions de haute priorité.

3.1.2.2 Contrôle optimiste

Le principe de contrôle optimiste suppose qu'une transaction s'exécute en trois phases : Read / Validation / Write.

Durant la phase read, les changements à effectuer (mises à jour) sont enregistrés dans un fichier temporaire.

La phase de validation, centrale, peut elle-même se décliner selon deux approches, afin de vérifier l'existence de blocages ou d'incohérences entre les transactions.

• Backward validation : vérification en fonction des transactions ayant déjà reçu un acquittement (commit) signifiant la fin d'une transaction.

• Forward validation : mieux adaptée aux bases de données temps réel, elle se base sur les autres transactions en phase de traitement ou d'attente, et de leurs états.

La phase write enregistre les résultats des transactions au sein de la base.

Dans le cas de OCC-BC (Optimistic Concurrency Control – Broadcast Commit) [44], qui utilise la Forward validation, une transaction avertit les autres transactions de priorité inférieures avec lesquelles elle est en conflit afin que ces dernières soient redémarrées. Cet avertissement a lieu juste avant l'entrée dans la phase de validation. S'il existe des transactions conflictuelles avec une priorité supérieures, notre transaction attend la validation de celles-ci avant de pouvoir continuer le processus. Cette solution impose la conservation de verrous jusqu'au terme de la transaction, ce qui peut amener à des blocages du système.



3.1.2.3 Contrôle Multiversion

Dans cette approche, utilisée dans les bases de données, les transactions de mises à jour du système n'effacent pas les données antérieures. Elles les complètent en ajoutant une nouvelle version des données, estampillée temporellement. Il s'agit là du principe de fonctionnement multiversion. Ces estampilles sont par la suite utilisées afin de déterminer quelles versions sont valides lors de la résolution de requêtes. La nature même de cette approche la rend plus complexe à mettre en place.

3.1.2.4 Résumé des contrôles de concurrence

D'après diverses études, il convient d'utiliser les protocoles optimistes dans les environnements non surchargés, et les protocoles par verrou dans les environnements surchargés (masses de données à mettre à jour, grand réseau de capteurs,...) [38].

L'utilisation des concepts liés à l'assignation de priorités et à leur utilisation effective complexifie la mise en place d'une base de données temps réel. D'autant plus que les répercutions de l'utilisation de ces concepts imposent à leur tour des modifications de tous les différents modules de la base de données.



3.2 Restrictions imposées aux BDTR

Dans un système de base de données 'classique' les contraintes ACID sont régulièrement utilisées. Elles correspondent au besoin l'Atomicité des données, la Cohérence des transactions, l'Isolation des opérations et la Durabilité des données [17] [59]. Ces contraintes visent à assurer une conservation optimale des données dans une base.

Un système de base de données temps réel reprend ces contraintes, en les modifiant quelque peu en ajoutant des propriétés plus spécifiques à la notion de temps réel.

- Ainsi une attention plus grande doit être portée à la taille de la base de données. Parallèlement, le temps de réponse de Lecture / Écriture mérite également une étude plus particulière. Plus il sera long, et plus la gestion des contraintes ACID pourra être fine.

- Le Temps de Cohérence Externe (External Consistency Time) pourra être associé à la notion de durée d'une contrainte temporelle dure.

- On appellera Temps de Cohérence Temporelle (Temporal Consistency Time) le temps maximum entre deux lectures permettant d'obtenir une représentation valide de l'environnement.

- La durabilité enfin s'assimile au temps de fonctionnement, sans avoir à relancer le système.

De fait, le consensus actuel veut qu'il soit le plus souvent préférable de limiter les accès aux disques dans les bases de données temps réel, afin de répondre à ces nouvelles exigences.

Les mécanismes temps réel couvrent différentes fonctionnalités. Puisqu'il est possible de se retrouver confronté à un afflux important de transactions, il est nécessaire de leur attribuer des priorités respectives, mais également de s'assurer qu'il sera possible de répondre à ces transactions. Le rôle du contrôle d'admission devra s'assurer que ne seront traitées que les transactions qui peuvent s'effectuer. Lors de leur résolution, le contrôle de concurrence, collaborant avec l'ordonnanceur devra s'assurer qu'il n'y a pas de conflit entre les transactions, et si nécessaire les résoudre. Finalement, le mécanisme de recouvrement pourra en une certaine mesure faire l'impasse sur certaines données devenues obsolètes.

3.2.1 Fonctionnement d'une base de données temps réelLe principe premier des systèmes temps réel est le respect de contraintes temporelles [37]. Pour une base de données, cela signifie que les transactions doivent s'effectuer dans des délais fixes. Pour parvenir à cette fin, il est généralement préférable d'utiliser différentes priorités. Elles ne doivent pas



déterminer quelle transaction doit s'effectuer avant une autre, mais l'importance de cette transaction par rapport aux autres. Idéalement, la paradigme temps réel ajoute qu'un système devrait être déterministe. Il devrait être possible de pouvoir connaître l'état du système à tout moment T.

Plusieurs approches permettent de déterminer les priorités associées aux transactions. Certaines (Rate Monotonic [41]) donnent une priorité fixe à la création de la transaction. D'autres (EDF [16]) fixent une priorité pouvant évoluer avec le temps. Les principaux problèmes associés aux priorités proviennent du fait qu'une transaction de faible priorité peut monopoliser les ressources demandées par une transaction de haute priorité, et ainsi lui faire rater sa limite temporelle.

La résolution de ce type de problèmes dans une base de données passe en premier lieu par les protocoles de contrôle de la concurrence. Ils déterminent à qui allouer les ressources demandées. Il existe principalement deux familles de protocoles. Les premiers utilisent des verrous pour signifier qu'une ressource n'est plus disponible alors que les seconds sont dit 'optimistes', validant l'accès et n'appliquant des règles de choix qu'en cas de conflit important.

Un autre aspect à prendre en compte vient de la similarité. Lorsque deux données sont liées, la modification de l'une entraîne la modification de l'autre. Ce point ne doit pas être négligé lors de la sérialisation.

Un certain type de contrôle de la concurrence est lié aux index des bases de données [24] [25]. L'index permet d'organiser les données de telle sorte à permettre un accès optimisé à celles-ci. Dans le cas de l'indexation temps réel, et plus particulièrement l'indexation liée à des masses de données issues de capteurs, l'index doit pouvoir favoriser les mises à jours par rapport aux requêtes de lectures simples. Il existe trois grandes familles de protocoles issus des B-tree. Dans les deux premiers, différents types de verrous sont utilisés pour prendre possession des nœuds de manière descendante dans l'arbre. Le second est un peu plus conséquent, puisqu'il permet des split et des merge préventifs. La dernière solution lie tous les nœuds d'un même niveau. Cependant ces solutions ne sont pas temps réel. Il y a des risques d'inversion de priorité (une transaction de forte priorité bloquée par une transaction de faible priorité disposant d'un verrou sur une ressource). Par conséquent, ces méthodes ont été modifiées. L'héritage de priorité permet à une transaction bloquante de faible priorité d'hériter momentanément de la priorité plus forte d'une autre transaction bloquée. Il existe cependant un risque d'héritage en cascade. Une autre approche permet de préempter les transactions de plus faible priorité (on force le passage du verrou à la transaction prioritaire), ce qui offre généralement les meilleures performances.

Une fois l'index accédé, il faut permettre aux données d'atteindre le processeur [37]. Une première étape est le buffer, la mémoire cache entre le stockage de masse ou la mémoire vive et le processeur. Trop d'accès au disque ralentissent le système, alors qu'un nombre insuffisant d'accès peut entraîner des données invalides. Il est possible classer les données par priorité. Les pages mémoires non utilisées et celles de plus faible priorité pouvant être vidées au profit d'autres plus importantes.

La gestion des accès au disque combine différentes approches. Les données les plus importantes sont valorisées tandis que le déplacement de la tête de lecture / écriture



sur le disque est utilisé pour accéder au données sur disque lorsque celles-ci sont requises et se situent dans la trajectoire de la tête.

En cas d'erreur du système, il est recommandé d'utiliser des journaux [37]. Ils peuvent être éphémères, ne gardant que les derniers changements pour une donnée, ou être complet. Il est conseillé d'éviter de les conserver sur disque, et préférer les NVRAM plus rapides. Certaines approches utilisent également plusieurs listes permettant de distinguer les informations les plus importantes des autres.

En cas de surcharge du système, un système basé sur des règles permet de déterminer quelles transactions sont à accepter et lesquelles sont à rejeter au niveau du contrôle d'admission des transactions.

Concernant la sécurité des transactions, il est possible d'utiliser des niveaux d'accréditation de transaction et de classification de données pour déterminer les actions admissibles de la part des transactions. Cependant il convient alors de se méfier des protocoles de contrôle de concurrence qui peuvent modifier les priorités des transaction. Une transaction « peu-sûre » pourrait alors hériter des droits d'une transaction sûre. Parmi les solutions existantes, 2PL-HP [1] est un protocole compatible avec nos besoins.

La réplication et la disponibilité des données posent un autre problème. La cohérence mutuelle est nécessaire : toutes les copies doivent être similaires. Il s'agit là du paradigme write one, read all. Une donnée est répliquée sur différents nœuds. Il est possible de lire de n'importe quelle copie de la donnée originale, mais toutes les copies doivent être écrites ensembles. Ceci peut s'effectuer via les maîtres (nœuds prioritaires en charge de la gestion de certaines données) qui ordonneront aux cohortes (répliques) de changer les données. En cas de panne, le journal des transactions pourra être utilisé afin de reconstruire la base en local. Puis le journal d'un autre site pourra être récupéré pour pouvoir compléter ce qui manque.

Les bases de données temps réel semblent disposer d'un avenir intéressant dans de nombreux domaines, que ce soit financiers ou environnementaux. Avec les besoins croissants en matière de système, il est permis de supposer qu'il sera bientôt intéressant de tirer parti des techniques multiprocesseurs. Cependant ces constats doivent être mis en regard des différents systèmes effectivement disponibles sur le marché des bases de données.

3.2.2 Les bases de données temps réel existantesLà encore, l'estampille temps réel est souvent accolée par des commerciaux en quête de marges bénéficiaires. Là encore cette fameuse estampille flatte plus qu'elle ne dévoile la réalité des faits. Une simple recherche sur un moteur de recherche ouèbe révélera un nombre d'offres prometteuses, sinon aguicheuses. Cependant, à l'heure actuelle, en 2006, les promesses effectuées sont généralement mensongères. Temps réel est encore souvent associé à une idée d'exécution rapide.

Les offres concernent régulièrement des bases fonctionnant en mémoire vive, sans mécanisme particulier de contrôle de concurrence. Parfois cependant les bases proposées peuvent tirer parti de l'utilisation de « systèmes d'exploitation temps réel ».



Or, ces systèmes d'exploitation sont encore relativement rares. Hormis des systèmes conçus spécifiquement pour des applications déterminées, le RTOS (Real Time Operating System) le plus connu reste certainement VxWorks [84], réputé pour sa qualité autant que pour son prix. Pour cette raison, différentes alternatives basées sur Linux ont vu le jours. Mais dans ce cas, un noyau temps réel est souvent utilisé au-dessus d'une base Linux, qui n'a pas été conçu dans l'optique temps réel (RTAI [63], LynuxWorks [43],...). Il sera également possible de noter la présence de deux RTOS libres qui commencent à être connus : RTEMS [64] et eCos [18].

Les bases de données réellement temps réel restent rares et souvent expérimentales. Il est par ailleurs intéressant de noter que de telles bases doivent être à même de gérer des données temps réelles ou non. Ces systèmes doivent prendre en compte un mode de fonctionnement mixte. Plusieurs grands noms ont ainsi borné le chemin de la recherche dans ce domaine, tels DeeDS [4] ou bien encore RODAIN [73]. Une brève description de ce dernier permet un aperçu du fonctionnement effectif d'une base de données temps réel.

RODAIN

RODAIN [73] est une base de données temps réel distribuée et résidante en mémoire centrale. Elle utilise également un système secondaire de stockage de données. La base est distribuée via des transferts de journaux. Il existe ainsi une différence entre données chaudes en mémoire principale et froides en mémoire secondaire. A chaque transaction qui arrive sur le nœud appelé Primaire, une entrée dans un journal de redo est créée. Celui-ci permet de rejouer des transactions passées. Cette entrée est envoyée au nœud Miroir, avant même l'acquittement afin de mettre à jour son image. Seul le Primaire peut répondre aux transactions, le Miroir servant en cas de problème sur le premier nœud. Les journaux servent dans ce cas à la fois à reconstruire localement la base en cas de problème mais également à maintenir une seconde base si nécessaire.

Les différentes bases de données, et d'une manière générale les différents systèmes temps réels actuellement disponibles, ont généralement été pensés et réalisés à l'aide de paradigmes exprimés, corrigés au cours des années 1990. Cependant, un phénomène est venu perturber le monde du temps réel... Le temps réel a été rattrapé par la loi de Moore.



3.3 Évolution des systèmes temps réel liée aux avancées technologiques

La loi de Moore [47], par ailleurs formulée par Carver Mead, affirme que le nombre de transistors dans un circuit intégré double tous les 18 mois (24 mois dans l'observation originelle de Moore). Par extension, elle reflète l'évolution constante des capacités de calcul des processeurs en informatiques. L'équivalent de cette loi pour le stockage des données se nomme la loi de Kryder [15]. Bien que la loi d'origine ait été infirmée depuis (elle se basait sur un doublement des capacités de stockage des disques durs tous les 13 mois), son nom a été conservé comme un synonyme de « loi de Moore appliquée au stockage des données. »

Cependant, depuis la fin des années 1990, une tendance semble se dégager : alors que la loi de Moore pour les processeur semble respectée d'une manière générale, sa variante pour le stockage de données est mise en défaut.

Les quantités de mémoires vives disponibles ont effectivement augmenté, mais la vitesse d'accès à ces mémoires a stagné, ou tout du moins progressé à un rythme moindre. Ainsi, alors que les processeurs étaient en mesure d'effectuer des opérations supplémentaires, la mémoire dans laquelle se trouvaient les données devenait petit à petit un facteur limitant à l'accès aux données. Différentes équipes ont dès lors commencé à délaisser les mémoires vives pour s'attacher à l'exploration des possibilités offertes par les mémoires caches, plus rapides.

Le domaine temps réel s'oriente progressivement vers les mémoires caches. Depuis les années 1970, le paradigme du temps réel recommandait l'utilisation de la mémoire vive afin de limiter le coût d'accès aux données pour des opérations disposant de contraintes temporelles restrictives. Depuis le début des années 2000, la recherche dans le domaine des bases de données temps réel et des systèmes d'indexation temps réel porte d'avantage sur l'étude des propriétés de la mémoire cache.

Une mémoire cache est un bloc de mémoire temporaire ou sont conservées des copies des données dont la probabilité d'accès par le processeur est grande. Le but d'une telle mémoire est d'assurer un accès rapide aux données (cf. figure 7). L'utilisation du cache permet des gains de temps et économise des cycles processeurs. Cependant, elle suppose l'adjonction d'une politique de gestion spécifique de la mémoire.



Le processus de fonctionnement de la mémoire cache peut se représenter de la manière suivante :

1. Le demandeur (processeur) réclame l'accès à une donnée

2. Le cache vérifie si cette donnée est déjà en mémoire ou non.

○ Si la donnée est en mémoire (cache hit), elle est transférée au demandeur

○ Sinon (cache fault), le cache demande l'accès à la mémoire principale (mémoire RAM), place cette donnée en cache et transfert au demandeur

3. Le demandeur renvoie le résultat au cache

4. Le cache stocke le résultat et le renvoie à la mémoire principale.

Des politiques de gestion de la mémoire cache prennent en compte différents facteurs. Il a été remarqué que la majorité des calculs avaient recours à un minimum de données récurrentes. Ainsi, certains modes de gestion de la mémoire cache proposent différentes solutions pour tenter de conserver au maximum les données les plus fréquemment accédées [30]. D'autres solutions de prefetching tentent de charger en mémoire cache les données qui ont une probabilité d'être accédées par la suite. Dans ces politiques, la gestion de la localité des données est prise en compte [31].

Il existe plusieurs définitions de localité : spatiale, temporelle et séquentielle.

● La localité spatiale est un concept qui affirme qu'une donnée physiquement proche d'une donnée récemment utilisée a une probabilité d'être utilisée à son tour relativement importante. Un cuisinier amateur ira chercher dans son réfrigérateur les différents ingrédients dont il a besoin. La probabilité pour qu'un élément conservé dans le réfrigérateur (le persil) soit sorti à la suite d'un autre (le beurre) est non négligeable.

● La localité temporelle affirme qu'une donnée accédée à un moment précis sera probablement accédée à nouveau dans un proche futur. Pour notre cuisinier amateur de salades, il est possible qu'il utilise du persil régulièrement.


Figure 7 : Différence entre différents types de mémoire

Volume de mémoire

Temps d'accès Mémoire

DisqueMémoire Vive

Mémoire Cache


● La localité séquentielle affirme qu'une mémoire a de fortes chances d'être accédée séquentiellement. Après avoir sorti un oeuf du rayonnage de son réfrigérateur, notre amateur d'omelette en sortira un second, un troisième...

En somme, la puissance des processeurs croît plus rapidement que les vitesses d'accès aux mémoires vives. Ceci implique des changements dans la conception des systèmes temps réel. Ainsi, l'accès à la mémoire vive devient un goulot d'étranglement pour les systèmes temps réel. Ceci est tout particulièrement vrai dans le cas de bases de données. En réponse à ces spécificités, différents travaux sur les méthodes d'indexation ont été développées pour tirer parti des spécificités de la mémoire cache.

3.3.1 Systèmes d'indexation avec prise en compte de la mémoire cache.

Jusque vers la fin des années 1990, l'indexation de bases de données pour des applications temps réel utilisait principalement des méthodes basées sur des arbres binaires. En effet, la famille des B+Tree était considérée comme trop complexe pour offrir des performances temps réel acceptables. Les différents calculs liés aux différents splits et merge de cette structure réclament en effet un temps de calcul non-négligeable aux ressources systèmes. Cependant, avec le gain en puissance des processeurs, cette limitation a peu à peu diminué. La restriction d'accès à la mémoire est alors apparue plus visiblement. Une structure binaire impose l'utilisation de nombreux nœuds distincts pour représenter l'ensemble des données. Par conséquent, une interrogation sur ce type de structure implique un grand nombre d'accès à des nœuds différents. La mémoire vive est donc fortement sollicitée. Des solutions tirant parti de la mémoire cache ont été cherchées.

Les travaux sur le B+Tree ont montré l'adéquation de cette structure avec l'utilisation des mémoires caches. Le coût d'accès au processeur est certes toujours présent, cependant, l'accès à la mémoire peut tirer parti de la structure du B-Tree. Alors que d'autres structures multiplient les utilisations de pointeurs, le B-Tree peut utiliser des tableaux. Or, les tableaux sont généralement représentés dans des zones mémoires connexes. Ainsi lorsqu'un nœud d'un B-Tree doit être chargé en mémoire cache pour être utilisé par le processeur il devient évident de tirer parti de cette localité séquentielle. La ligne mémoire du cache peut être intégralement remplie par le tableau utilisé dans le nœud du B-Tree pour représenter les identifiants, la série de liens vers les données.

C'est sur cette idée qu'a été développé le CSB+Tree [60], Cache Conscious B Tree, qui valorise l'utilisation de tableaux dans le B-Tree. Dans cette structure, un pointeur non-feuille contient un seul pointeur et une liste de clefs, à la place d'une série d'associations <clef; pointeur>. Le pointeur unique référence un groupe de nœuds fils. Il existe un nombre de fils égal au nombre de clefs plus un. Un nouveau fil est référencé en ajoutant un offset, basé sur la clef, au pointeur.

Par la suite, d'autres structures ont été utilisées en reprenant cette logique afin de créer des structures tirant parti de l'utilisation de la mémoire cache, tel le SIB-Tree [58].



3.4 Conclusion : temps réel et BDTR

Le temps réel se définit par le besoin de respecter certaines contraintes temporelles. Des priorités sont généralement utilisées afin de déterminer quelles transactions sont plus importantes et de mettre en place des ordonnancement permettant de répondre aux besoins temps réel.

Les bases de données temps réel sont généralement en mémoire-vive afin de faciliter et de diminuer le coût d'accès au données. Du point de vue de l'index, les développements technologiques ont mis en avant le besoin d'utiliser des structures prenant en compte les spécificités des mémoires cache.

Dans le cadre de systèmes de surveillance de phénomènes naturels, l'aspect temps réel peut prendre plusieurs aspects. En premier lieu, les données collectées par les capteurs doivent être intégrées à la base avant qu'une version plus récente ne lui parvienne. Par-là même il est possible de définir des contraintes temps réel pour les capteurs périodiques. D'autres requêtes sont également temps réel. Lors de crises ou de phases d'activités spécifiques, les requêtes d'accès aux données émises par les autorités décisionnelles sont également temps réel. Elles sont appelées à prendre des décisions importantes dans des délais limités, aussi ne peuvent-elles pas se permettre un accès aux données trop long.

Alors qu'il est généralement admis que les mises à jours puissent suivre des contraintes temps réel douces, les demandes d'accès aux données en période de crise par des personnes responsables de la prise de décisions suivent des contraintes fermes.

Bien qu'il existe de nombreux systèmes de gestion de la concurrence et de contrôle d'accès, la base de données offre des performances en rapport avec la méthode d'indexation utilisée. Aussi les chapitres à venir traitent-ils de méthodes d'indexations pour des bases de données en mémoire vive, reliées à des capteurs. L'indexation doit être réalisée en fonction de la localisation des capteurs et des instants correspondant aux différentes mesures. Les mesures en elle-même pouvant prendre des formes diverses et variées.




De cape et de crocs - Le Mystère de l'Île Étrange - ©Delcourt

Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes

4 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes

Ce chapitre traite de l'indexation d'une base de données spatio-temporelles en mémoire vive, collectant les données issues d'un réseau de capteurs temps-réels fixes. Cette base de données, utilisée pour la résolution de requêtes sur des mesures à court-terme doit prendre en compte les spécificités temps-réel des capteurs, mais d'abord et surtout la dimension spatio-temporelle des données.

Historiquement, les principaux systèmes de surveillance de phénomènes ont été construits autour de réseaux de capteurs fixes. Les grands phénomènes naturels ont depuis toujours fasciné les hommes. Tiraillés entre curiosité, émerveillement et peur, les scientifiques de tout temps ont cherché à percer les mystères de la nature qui les entouraient. Les premiers sismographes ont ainsi été développés en Chine dès la première moitié du second siècle de notre ère.

Les progrès en électronique depuis les années 1950 ont permis une généralisation de l'utilisation des instruments de mesures automatiques. Cependant, la taille des outils utilisés limitait alors grandement leur autonomie ainsi que les capacités à les déployer in-situ. Les améliorations constantes apportées en matière d'électronique ont permis de s'affranchir de nombreuses contraintes, mais les habitudes de travail fondées sur l'utilisation de capteurs fixes ont persisté.

Les systèmes de surveillance se sont basés sur une infrastructure réseau de capteurs fixes. Les capacités de déplacement d'un capteur étant limitées, l'architecture du réseau et de la base de donnée adjacente se centrent sur la notion d'identifiant de capteur et de temps de mesure.

L'apport de la dimension spatio-temporelle reste encore relativement récent. En effet, la majorité des réseaux de capteurs historiques ne représentent la position que comme un attribut secondaire lié au capteur. L'identifiant de celui-ci est utilisé pour la résolution de toute requête atteignant la base de données. Un chercheur désireux d'obtenir une information relative à la position d'un capteur disposait alors de classeurs de référence permettant de lier un capteur et une position sur une carte. C'est en grande partie grâce à la publicité de technologies de géolocalisation GPS ou autres que la communauté scientifique a commencé à évaluer l'intérêt de l'utilisation de bases de données spatio-temporelles.

Ce chapitre se divise en deux parties. La première présente un aperçu de l'indexation spatiale, temporelle et spatio-temporelle. Après une description des grands concepts utilisés, tant spatiaux que temporels, différentes solutions d'indexation sont présentées. Ces solutions offrent des capacités intéressantes mais



souffrent cependant de limitations. Parmi les plus communes se trouve la nécessité de prendre en compte l'ensemble des données contenues dans la base pour résoudre des requêtes. La seconde partie du chapitre propose le PoTree, une solution spatio-temporelle centrée sur les capteurs fixes. Les données sont ainsi regroupées dans des sous-structures temporelles relatives aux capteurs. Ces sous-structures sont à leur tour reliées par l'intermédiaire d'une sous-structure spatiale. Ceci permet de limiter la portée d'une requête tout en offrant un vaste panel de requêtes possibles.



4.1 Indexation spatio-temporelle

Un index a pour but de faciliter et d'accélérer l'accès aux données contenues dans une base. Cette définition généraliste s'applique à tous les types d'index et de bases de données. L'indexation de données spatio-temporelles ajoute à cette définition des informations complémentaires quant à la nature des objets indexés.

Les travaux de recherche sur l'indexation spatio-temporelle ont débuté il y a plus de trente ans, connaissant un véritable essor dès le milieu des années 1970. La recherche se concentrait alors sur l'indexation de points spatiaux fixes. La mobilité ne connaissait pas encore l'intérêt qui lui est désormais porté, ni à la visualisation en trois dimensions via des appareils de réalité augmentée; l'indexation ne prenait pas en charge la forme des objets ni leur déplacement.

L'expérience obtenue par ces années de recherche a permis de constituer ce qui forme pour l'heure le paradigme de l'indexation spatio-temporelle pour des données fixes.

4.1.1 Taxonomies spatio-temporellesLa recherche dans le domaine de l'indexation spatio-temporelle est le fruit de nombreuses années de travaux. Historiquement, le domaine du spatial a ouvert la voie vers la recherche temporelle avant d'offrir enfin une vision spatio-temporelle [56].

4.1.1.1 Approche spatiale

La modélisation des données spatiales est utilisée dans de nombreux domaines : les Systèmes d'Information Géographiques mais également la robotique,… Elle suppose néanmoins une connaissance a priori de certains concepts.

En premier lieu, la notion d'approche spatiale est liée à celle d'espace. Les espaces les plus couramment utilisés sont de dimension 2 ou 3, mais il n’est pas exclu d’augmenter le nombre de dimensions. Il devient alors possible de prendre en compte d'autres facteurs tel que le temps ou la température. Berstold et Keim proposent un ensemble de techniques permettant d’indexer dans des espaces de plus grandes dimensions [8].

Afin de représenter des objets, en vue de les indexer ou d’effectuer des opérations sur ceux-ci, il est généralement admis de les décrire comme appartenant à une structure englobante (MBR, Minimum Bounding Rectangle). Il s'agit le plus régulièrement d'un rectangle ou d'un cube. Il est en effet plus aisé et économique en terme de place et de calcul d’indexer un rectangle, définissable selon les



coordonnées de deux points, que d’indexer une forme plus complexe, tel qu’une théière par exemple. Certains travaux, comme ceux de Lee et Chung [40] proposent une subdivision plus fine des objets via plusieurs structures englobantes contiguës. Apparaît alors le problème de la notation de cette contiguïté.

Lee et Chung ont décomposé les objets modélisables en trois grandes familles. [40]

Les points : qu’il s’agisse d’objets en eux même ou bien de la représentation de centres de gravité, les points sont les éléments de base de l’approche spatiale. Ils sont le plus souvent utilisé dans des modèles discrets (par opposition aux modèles continus). Un index peut être utilisé pour les identifier, en réponse à des requêtes d’appartenance ou d’identité (est ce que le point est dans ce rectangle ?)

Les lignes sont constituées d’une suite de points. Elles ne sont cependant pas les éléments les plus pertinents. En effet, si les lignes permettent de faire une séparation entre deux sous-espaces, elles ne proposent guère plus que des structures englobantes. De plus, les méthodes de classification d’objets ne permettent généralement pas une véritable différenciation entre un segment et un rectangle, tous deux définis par deux coordonnées. En résultent alors des problèmes lors des requêtes, ce que nous verrons un peu plus loin.

Les régions, le plus souvent des rectangles, mais potentiellement d'autres formes (disques,...). Les régions permettent de définir des sous-espaces, de créer des distinctions au sein de cet espace. Elles permettent également de représenter des objets plus complexes (elles agissent alors comme des MBR, bounding structures). Dans ce cas, dans la mesure où les objets représentés n’épousent pas nécessairement la forme de ces structures, deux objets suffisamment proches peuvent être englobés dans des MBRs qui se chevaucheront. La pertinence des résultats de requêtes d'accès peut en être diminuée (faux résultats,...).

Plusieurs difficultés se posent lors du choix de l’approche spatiale [83]. En premier lieu, il convient de spécifier si le système utilise une représentation discrète ou continue.

Un autre problème découle du choix d’utiliser comme élément de travail une observation ou une description. L’observation sera plus fine, précise, mais la description permettra un travail sur les données plus aisé.

De ce constat découlent deux possibilités : l’utilisation d’images raster (telle qu’une image bitmap) ou de représentations vectorielles.

En somme, les approches spatiales permettent d'utiliser des points, des lignes ou des formes plus complexes. Les représentations peuvent être discrètes ou continues et se différencient en trois familles :

• Approche par transformation (l’espace lui-même peut être modifié pour le rendre plus facilement modélisable).

• Approche d’espace natif sans recouvrement de zones.

• Approche d’espace natif avec recouvrement de zones.



4.1.1.2 Approche temporelle

L’approche temporelle est plus généralement centrée sur la modélisation des états rencontrés. Elle impose à son tour la connaissance et l’assimilation de certains concepts.

La dimension temporelle se distingue des dimensions spatiales par plusieurs aspects. Sa monotonicité en est un élément de base. Sauf preuve du contraire, personne n'est parvenu à remonter dans le temps. Celui-ci s'écoule de manière monotone. Certaines approches tentent d’utiliser le temps comme une dimension complémentaire de la dimension spatiale, mais elles ne prennent alors pas en compte cette monotonicité. Dans les bases de données temporelles, les données apparaissent généralement comme collections de points ou de segments. Les points représentent des instants précis alors que les segments représentent un intervalle de validité (défini entre Td pour le temps de début et Tf pour la fin, Tf pouvant prendre la valeur spéciale Maintenant pour des actions non finies).

Il a été proposé plusieurs type pour les bases de données [56] :

• Le temps de transaction (transaction time), représente une séquence de relations indexées dans la base par le temps permettant des « rembobinages » (rollback). Il n’y a pas de mises à jour rétroactives. Une nouvelle version vient remplacer l’ancienne. Il n’y a pas non plus de mise à jour prédictive. Les données sont rentrées « au jour, le jour ». Le temps est assimilable à un point ou un intervalle.

• Le temps de validité (valid time) définit une période où un fait est vrai dans la réalité. Une clef invariante peut avoir plusieurs versions avec des temps valides croisés s’il y a des attributs temporels qui diffèrent. Les mises à jours rétroactives sont permises si une erreur est découverte. Ceci interdit le rembobinage. Les mises à jour prédictives sont également possibles. Le temps est noté comme un intervalle.

• Le temps « bitemporal », qui cumule les propriétés des temps de transaction et de validité. Il est possible de rembobiner, de faire des mises à jours rétroactives et prédictives. Pour cela, il faut garder en mémoire le temps de validité des faits, et le temps où ceux-ci sont entrés dans le système.

4.1.1.3 Approche spatio-temporelle

Wang, Zu et Lu définissent 3 types d’applications spatio-temporelles : [83]

• Applications avec des objets en mouvement continu

• Applications avec des changements discrets

• Applications avec des changements continus de mouvement.

Cette approche permet de remarquer l’importance du mouvement (tableau 1).

En reprenant la notion de couches (pour la distinction entre continu et discret) et en définissant un niveau d’abstraction spatial au-dessus du simple objet, il est possible



d’obtenir un tableau des différents types de données spatio-temporelles conservés au sein d'une base de données :

Objet Spatial Couche

Point Temporel Instantané (Snapshot)Instantané Temporel

(Snapshot)

Intervalle Temporel ChangementMouvement

ChangementMouvement

Période

InstantanéVersion

ChangementMouvement

InstantanéVersion

PhénomèneChangement

Tableau 1 : Représentation des évènements selon la dimension temporelle

Ce tableau permet de mettre en avant plusieurs difficultés. En premier lieu, il convient de déterminer s'il est nécessaire de se concentrer sur les changements spatio-temporels ou bien sur une approche multiversion. De même, il convient de déterminer s'il est préférable de travailler avec des objets ou bien avec des vecteurs.

De toutes ces considérations se dégagent les grandes étapes de la démarche spatio-temporelle [79] :

● Représenter les objets dans l’espace et le temps (le temps sera-t-il considéré comme une nouvelle dimension ? Privilégiera-t-on l’approche spatiale sur la temporelle ?)

● Capturer le changement spatial dans le temps

● Définir des attributs spatiaux (longueur,…)

● Définir des opérateurs pour ces attributs

● Lier ces attributs aux objets

● Représenter des relations temporelles entre ces attributs

● Spécifier les contraintes d’intégrités (certaines sont spécifiées par les concepteurs, d’autres peuvent s’imposer à lui)

En somme, la représentation spatio-temporelle combine les travaux effectués dans les domaines spatiaux et temporels afin de fournir un ensemble de concepts. Ces concepts permettent à leur tour différentes représentations des données conservées dans une base, et référencées au niveau de l'index.

4.1.2 Indexation et requêtes

4.1.2.1 Bases de données spatiales

Il existe plusieurs types de requêtes admissibles par une base de données spatiale. Celles-ci varient selon le choix d'une représentation continue ou discrète. Il est



possible de distinguer des requêtes d’appartenance (« quels sont les objets qui sont dans ce rectangle ? »), les requêtes d’intersection (« quels objets traversent telle parcelle de terrain ?»), les requêtes d’adjacence (« quelles parcelles jouxtent celle-ci ? »), de proximité , (« quels sont les voisins de tel objet ?»),…

Il est généralement nécessaire de définir des structures englobantes pour permettre la résolution de telles requêtes. Comme énoncé précédemment, le choix de ces structures influence beaucoup la qualité des résultats retournés. Les concepteurs doivent donc trouver la technique qui correspond le mieux à leurs besoins, en prenant en compte les problèmes de recouvrement (overlapping), d’espace vides dans les structures englobantes.

Les index de base de données quant à eux peuvent être classés en grandes familles relatives à leurs structures sous-jacentes.

4.1.2.1.1 La famille des binary-treeLa spécificité des binary trees est que les valeurs de l’index sont ordonnées de manière linéaire. Pour cela, l’espace de données est subdivisé afin de créer l’arbre. Cette idée a été reprise dans de nombreux types d’index.

kd-Tree [7]

Cet arbre (cf. figure 8) permet la recherche binaire d’ordre k. Il représente une subdivision récursive de tout l’espace via des plans iso-orientés. Chaque séparation doit contenir au moins un point, utilisé dans la représentation de l’arbre. Ce point devient alors le point de référence pour subdiviser l’espace, en fonction d’un critère (un axe, alternativement vertical ou horizontal pour un espace deux dimensions). Les points inférieurs à celui de référence (LOSON) sont placés à gauche dans l’arbre, ceux supérieurs (HISON) sont placés à droite. Les nœuds internes peuvent avoir un ou deux descendants. Lors de la descente dans la structure, les points et axes de références changent.


Figure 8 : Structure du kd-Tree (schéma de [56])


Lors des insertions, un trop grand nombre de points génère un split (séparation) de l'espace, la nouvelle séparation s'effectue de telle sorte que les données soient partagées équitablement entre les deux branches de l'arbre.

La recherche est simple, mais la suppression de données compliquée du fait de la réorganisation de l’arbre. De plus, la structure de l’arbre et ses performances dépendent de l’ordre d’insertion des données.

Il existe des arbres non-homogènes dans lesquels les données ne sont pas dans les nœuds internes, mais dans les feuilles, au dernier niveau de l’arbre.

Les arbres basés sur les arbres binaires offrent généralement des solutions d'indexation rapide et permettant une mise à jour en ligne des données. Cependant, ceux prenant origine sur le kd-tree souffrent généralement des limitations imposées par celui-ci : structure et performance dépendant de l'ordre d'insertion des données.

4.1.2.1.2 Techniques d’indexation basées sur les B-TreeAlors même que les arbres binaires étaient les sujets d'études poussées, d'autres structures reprenant l'héritage des B-Tree ont été développées. Parmi celles-ci, le R-Tree devait devenir la structure de référence du domaine spatio-temporel.

R-Tree [22]

Les R-Tree (cf. figure 9 ) sont une généralisation multidimensionnelle des B-Tree. Les nœuds feuilles possèdent un OID (identifiant) et un MBR (Minimum Bounding Rectangle), rectangle englobant de délimitation de dimension k. Les nœuds internes possèdent des pointeurs (vers d’autres nœuds en dessous) et des rectangles englobants.

Il existe quelques règles permettant de créer des R Tree :

• chaque nœud feuille contient entre m et M entrées, sauf s’il s’agit du nœud racine

• chaque nœud intermédiaire a entre m et M enfants, sauf s’il s’agit du nœud racine


Figure 9 : Structure d'un R-Tree (schéma de [56])


• le nœud racine a au moins deux enfants, sauf s’il est feuille

• toutes les feuilles apparaissent au même niveau

Pour trouver un objet qui intersecte un rectangle, il suffit de descendre dans l’arbre à partir de la racine. Une fois arrivé au niveau des nœuds feuilles, les résultats sont testés. Pour l'insertion de données, l’arbre est parcouru, et le rectangle qui requiert le plus faible agrandissement pour englober le nouvel objet est choisi. Dans le cas d’une égalité entre deux rectangles, le plus petit des deux est choisi. Il en va de même pour une suppression.

Plusieurs rectangles peuvent se superposer, ce qui augmente les difficultés de recherche. Pour minimiser le croisement, deux algorithmes sont utilisés : insertion et split des nœuds. Ce dernier a le plus d’influence. En tout état de cause, ce type d’arbre est lourd à maintenir et à utiliser mais offre un vaste panel de requêtes admissibles.

R* Tree [6]

Cette structure vise à minimaliser la couverture et les croisements importants. Dans les R*Tree, les MBRs relativement carrés seront valorisés. Créer des clusters de carrés tend à minimiser la taille du rectangle (carré) du cluster englobant.

Dans les nœuds feuilles, un enregistrement est ajouté si, après l’élargissement, le rectangle du nœud a le plus faible recouvrement comparé autres rectangles. En cas d’égalité, le plus petit rectangle sera choisi. Dans les nœuds internes, un nouvel enregistrement est créé pour les rectangles ayant le plus faible accroissement de taille.

Les index spatiaux dynamiques sont sensibles à l’ordre d’insertion des données. Il est donc nécessaire de remettre à jour l’index. Il est aussi possible d'utiliser un mécanisme de suppression / réinsertion quand un nœud déborde avant de le découper.

Les performances du R*Tree montrent un coût de création généralement supérieur à celui du R-Tree, mais des coûts d'interrogation moindre [6]. Cependant, les performances se dégradent rapidement lorsque le nombre de données croît.

DR-Tree [40]

Cet index permet de stocker un objet décomposé en mémoire primaire (cf. figure 10). Pour cela, des DMBR sont utilisés. Il s’agit de MBRs associés pour une meilleure description d’un objet, pour limiter les espaces vides. L’espace est subdivisé en sous-espaces. Si plus d’un certain taux de cet espace est occupé (par exemple 25% de l’image originelle), il est conservé, et est affiné pour former un nouveau sous-MBR de l’objet.

Les nœuds non-feuilles possèdent des entrées de la forme <pointeur gauche(vers un nœud), rectangle, pointeur droit (vers un autre nœud)>. Les nœuds feuille possèdent



des entrées de la forme <pointeur data, rectangle> Les DR Tree comportent, du par la division des objets, des enregistrements de taille variables.

Cette solution souffre des mêmes limitations que le R-Tree, mais permet une gestion plus fine de zones spatiales. Cependant, il se révèle d'un intérêt tout relatif lorsque les données indexées sont ponctuelles.

En somme, les différentes structures basées sur les R-Tree permettent l'indexation de données de forme et ont été l'objet de développements et d'expérimentations poussés. Il est intéressant de remarquer que leurs structures imposent qu'une requête doive prendre en compte l'ensemble des données disponibles. Ainsi, les mises à jours se révèlent être généralement plus coûteuses. Cependant, les performances et la variété des requêtes disponibles ont permis au R-Tree de s'imposer comme la référence des bases de données commerciales.

4.1.2.1.3 Méthodes de cellules basées sur le hachage dynamiqueOn vise ici à partitionner un espace de dimension k selon un grillage orthogonal. Le grillage est défini en échelles (scales) formées de k tableaux de une dimension. Chaque limite dans une échelle forme un hyperplan de dimension k-1 qui divise l’espace en deux sous-espaces. Les limites créent des rectangles de dimension k, présentés dans un tableau de dimension k, le grid directory. Une entrée dans ce tableau correspond à une cellule.

Grid File [56]

Chaque case du tableau contient l’adresse d’une page de données où sont indexés les objets. Une page de données peut référencer les objets de plusieurs cellules si elles sont adjacentes et forment un rectangle, une storage region. Le tableau est habituellement conservé en mémoire secondaire (du fait de sa taille). Les pages de données peuvent être en mémoire primaire.

L’insertion consiste à trouver la page de données et à insérer si elle n’est pas pleine, la subdiviser dans l'alternative. La suppression utilise le mécanisme inverse. Si le taux d’occupation d’une cellule tombe sous un seuil (70%), elle est combinée avec une autre cellule voisine.


Figure 10 : Découpage d'un objet et structure du DR-Tree correspondant [40]


Pour chercher des objets de dimension supérieure à zéro, la structure cherche à représenter l’espace de dimension k dans un espace de dimension n*k où les objets sont représentables comme des points. Ceci rend les divisions de cellule plus complexes.

Pour indexer un rectangle, il est possible d'utiliser les coordonnées de son centroïde et les extensions autour de celui-ci.

L'utilisation de grilles est une alternative intéressante aux R-Tree qui offre l'avantage d'être utilisée dans différents systèmes embarqués. Cependant, ces grilles demandent des mécanismes de mise à jour complexes et nécessitent généralement l'utilisation de la mémoire secondaire pour conserver le tableau des cellules, réduisant par-là même les performances temps-réel.

4.1.2.1.4 Ordonnancement des objets spatiauxDans un SGBD classique, les données de dimension une (les points) sont privilégiées. Pour les index spatiaux, une possibilité consiste à ramener la dimension des données à celle d'un point, afin de préserver la proximité spatiale. Pour ce faire, plusieurs techniques sont possibles, en utilisant des fonctions de Peano, de Hilbert,… [56]Dans le Quadtree, l'espace est ainsi divisé en quatre quadrants égaux. Pour chaque quadrant, une clef en base quatre (1 pour le Nord-Est, 2 pour le Nord-Ouest,… par exemple) est assignée. Tous les objets compris dans le quadrant prennent sa clef. Chaque quadrant est redivisé récursivement.

Un objet dans un rectangle peut être sur plusieurs quadrants. Il peut prendre jusqu’à 4 valeurs de quadrants adjacents. Les références peuvent ensuite être organisées dans un arbre B+. Il existe cependant des difficultés de mise en place de telles structures.

Quadtree et Linear Regional Quadtree (LRQ) [20][66]

Cette seconde technique est utilisée pour indexer des images (rasters). Une image est décomposée en quadrants, numérotés de 1 à 4. Si l’image d’un quadrant n’est pas entièrement blanche ou noire, elle est à nouveau divisée. Si l’image est trop grande, les blocs noirs sont insérés dans un arbre B+.

Le Quadtree ( cf. figure 11) est gardé en mémoire principale. Chaque nœud noir du Quadtree comporte une paire de nombres : C & L. C représente la localisation du nœud (depuis la racine), et L le niveau où est placé le nœud.



Figure 11 : Image, Quadtree et Linear Regional Quadtree correspondants[66]

4.1.2.2 Bases de données temporelles

Une requête peut s’effectuer pour déterminer une intersection, une inclusion, ou encore pour rechercher un point. Il a été tenté de classer les différentes requêtes que l’on pouvait rencontrer dans une base de données temporelles.

• Requêtes sur une tranche de temps (time-slice). Les versions valides dans un intervalle donné ([Td,Tf]) sont alors conservées.

• Requêtes sur la valeur de clef et la tranche de temps (key range – time slice). Les versions valides dans un intervalle donné sont cherchées, grâce une clef donnée (« voitures en circulation entre 1996 et 1998 ayant une couleur bleue »).

• Requêtes sur la valeur de clef. Les tuples vrais en fonction de la clef sont cherchés.

• Requêtes bitemporales sur une tranche de temps. Les versions valides dans un intervalle [Td,Tf] au moment Tt sont ici visées.

• Requêtes bitemporales sur une tranche de temps avec une valeur de clef. Idem, mais avec en plus des restrictions sur la valeur de la clef.

Les problèmes liés aux particularités temporelles sont plus délicats à régler que les problèmes purement spatiaux. Les systèmes d’indexations les plus répandus ne permettent pas de répondre à tous les types de requêtes. Pour cela, un index bitemporal est requis.



Tout comme il existe plusieurs familles pour classer les index spatiaux, plusieurs solutions permettent de différencier les index temporels. D’une manière générale, il est possible d’indexer sur les temps de départ / fin (ce qui revient à une forme de B+ Tree, peu propice aux requêtes time-slice), sur des intervalles,…

L’idée d’utiliser des B+ Tree classiques découle de certains aspects propres à ces derniers, notamment les liens entre les nœuds feuille. Pour chercher selon un intervalle, il est nécessaire de parcourir de larges portions de nœuds feuilles. Il est possible de dupliquer les données dans les nœuds s’ils s’intersectent (stockage lourd, lecture ralentie,…). Il est également possible de modéliser selon un ensemble de points ou par segment de lignes, ce qui revient à combiner R-Tree et B+ Tree.

4.1.2.2.1 Index basés sur les B+ Tree

Append-Only Tree [56]

Cet arbre permet d’indexer les temps valides.

Les nœuds feuille conservent les temps de début des relations temporelles. Les nœuds non-feuille conservent des pointeurs vers des valeurs temporelles pointant vers des enfants où cette valeur est la plus petite. Cette règle n’est pas valable pour les premiers enfants.

Tous les ajouts s'effectuent à droite de l’arbre (ajouts incrémentaux). Tous les sous-arbres sont remplis, à l'exception du dernier. Un split amène un nouveau nœud à se remplir. L’arbre n’est cependant pas équilibré : le nouveau nœud est inséré « à la fortune du pôt »…

La recherche peut être assez longue. Pour trouver un intervalle, une première recherche localise la fin de celui-ci avant de remonter vers la gauche de la structure (remontée dans le temps).

Les ajouts sont monotones, avec des valeurs temporelles incrémentales, ce qui peut limiter les capacités de mises à jour. Or les mises à jours revêtent une importance première dans les systèmes de collecte de mesures.

B+ Tree avec ordre linéaire [56]

Cette solution a pour but de linéariser les données temporelles pour utiliser un B+ Tree.

L'indexation se déroule en trois phases :

• transposition dans un espace 2D

• linéarisation des points

• indexation B+ Tree

La transposition s'effectue dans un espace triangulaire à deux dimensions. Un intervalle de temps [Td ;Tf] devient un point de coordonnées (Td ;Tf-d).



La linéarisation peut s'effectuer de trois façons : horizontale, verticale ou diagonale. Elle revient à diviser l’espace 2D et à classer cet espace selon une fonction horizontale, verticale ou diagonale. Chaque classement possède ses propres particularités et sera plus ou moins bien approprié à une requête.

Le principal avantage de cette méthode est sa réutilisabilité dans des SGDB classiques. Cependant, pour des données sur des intervalles ouverts, il est nécessaire d’avoir recours à une réorganisation lourde.

Multi Version B Tree (MVBT) [5] [76]

Il s’agit d’une extension des B-Tree pour indexer les « transactions fines » de données à une dimension. Les insertions et suppression n’ont lieu qu’au moment courant (temps de transaction). Les enregistrements sont de la forme <clef, Td, Tf, pointeur>

Il est possible d’avoir plusieurs racines, chacune possède alors son intervalle de juridiction. Pour chaque temps t, un nœud doit avoir 0 ou bien au moins m entrées ‘en vie’. Cette structure est à la base des index spatio-temporels dits « multiversion » (qui conservent des informations quant à la validité des enregistrements).

Ces index basés sur les B+Tree considèrent la dimension temporelle comme étant indépendante de la dimension spatiale. Ils sont basés sur la linéarité temporelle. Cependant, pour certaines requêtes plus complexes et certaines applications nécessitant des rétro-mises à jours fréquentes, l'utilisation d'index basés sur une approche spatiale lui est souvent préférée.

4.1.2.2.2 Méthode basées sur l’indexation spatialeDans ces index, la dimension temporelle est considérée comme une dimension spatiale supplémentaire. En d'autre termes : temps, espace, même approche. Il est dès lors possible d'utiliser les index mis en place pour l'indexation spatiale.

Index Time-Polygon [56]

Cet index a pour but d’indexer les temps valides. Pour gérer des clefs indépendantes du temps, la 3D est utilisée. Les axes représentent alors :

• X : point temporel

• Y : durée

• Z : valeur de la clef

Pour des cas plus simples, un espace triangulaire en 2D suffit. 5 polygones utilisables ont été définis pour participer à l’espace. En cas de dépassement de capacité, les points sont regroupés dans des pages de donnée.

Trois types de partitions sont définis :



• partition Y (parallèle au plan X-Z)

• partition temporelle (parallèle à la frontière temporelle définissant l’instant présent)

• partition par clef (parallèle au plan X-Y)

Dès lors, pour effectuer des requêtes, il est nécessaire de transformer ces requêtes en régions de requête. Cette transformation peut entraîner une utilisation accrue des ressources processeur.

R-Tree [22]

Les données temporelles sont ici stockées avec des données invariantes. Le temps peut être considéré comme une dimension dans un espace. Les méthodes spatiales peuvent dès lors être utilisées. Cependant, les particularités propres à la dimension temporelle ne peuvent pas être prises en compte (monotonicité).

Des problèmes persistent pour les intervalles ouverts et les actions non terminées (définition du rectangle englobant plus complexe). En termes généraux, les recherches ne sont pas optimisées puisqu’il est souvent nécessaire d’abstraire en fonction des données, des algorithmes ou de l’espace de recherche.

De plus, puisque les données temporelles sont conservées, la base de données grossit perpétuellement, de même que l’index. Et ces requêtes utilisant l’ensemble des données indexées, les performances se dégradent rapidement. De fait, il est peu pratique d’utiliser les R-Tree pour une indexation temps-réel, du fait des coûts de recherche / mise à jour.

4.1.2.2.3 Bases de données bitemporellesTravailler avec des données temporelles imposent certaines contraintes. Les bases de données bitemporelles doivent pouvoir conserver les données mais également un historique rappelant la validité de celles-ci.

GR-Tree [9]

Cet arbre cherche à indexer les données bitemporelles pouvant grandir. Un nœud feuille contient des entrées référençant les temps de création / suppression d’un tuple dans le monde réel et dans la base de données (4 dates en tout donc), et un pointeur vers les données. Un marqueur différencie les données encore en vie. Par comparaison avec les R*Tree, la recherche est jusqu’à 3 fois plus rapide avec les GR-Tree.

En somme, les index temporels se distinguent en fonction de la temporalité à indexer : temps de validité, de transaction ou bitemporel. Les index les plus complets, bitemporels, sont également ceux nécessitant le plus de ressources, ce qui limitent leurs performances temps-réel. Les différentes solutions d'indexation peuvent tirer parti des spécificités temporelles ou bien prendre le parti de l'analogie



avec l'indexation spatiale. Il devient dès lors plus aisé de mêler les deux approches pour s'orienter vers l'indexation spatio-temporelle.

4.1.2.2.4 Base de données spatio-temporellesUtiliser une base de données spatiale à laquelle sont rajoutées des contraintes de temps revient à en oublier les particularités de ce dernier. Le temps n’est pas une dimension parfaitement assimilable à une dimension spatiale. Cependant, ce domaine a été l’un des précurseurs pour les bases de données spatio-temporelles. Les index spatiaux étant déjà bien développés, il semblait naturel de poursuivre dans cette voie. Le R-Tree a connu plusieurs variantes orientées vers le spatio-temporel.

Utiliser une base de données temporelles à laquelle est rajoutée une dimension spatiale (pour les attributs) n’est pas beaucoup plus efficace. En effet, dans un tel cas de figure une requête sur un mouvement, impliquant autant la dimension spatiale que temporelle, n’est pas optimisée.

De ces deux constats découlent le besoin d’une approche purement spatio-temporelle. Gérer la monotonicité du temps revient à choisir entre utiliser des méthodes basées sur le recouvrement, ou bien des méthodes basées sur les multiversions [2] [76].

Dans l’optique de recouvrement, un index 2D spécifique est maintenu à chaque instant t. Il existe généralement un partage des branches communes, invariantes entre t et t+x

Dans l’optique des index multiversions, un index 2D avec stockage linéaire en fonction du nombre de changement est conservé. On conserve les différentes versions des données ainsi que l'intervalle de validité de celles-ci.

On pourra noter l’apparition des notions de temps réels dans divers travaux (comme ceux de [34], décrits par la suite). Dans ce cas, il s’agit le plus souvent de mises à jours effectuées par des applications ou des systèmes temps réel.

3DR-Tree [78]

Il s'agit d'une adaptation du R-Tree pour gérer les dimensions temporelles et spatiales. (cf. figure 12)

Les intervalles de temps et les clefs forment un point dans un espace en 3D (clef ;Td ;Tf). Ceci permet de gérer les requêtes de temps, de clef spatiale et temps, et de clef spatiale.

Les requêtes peuvent être 2D, pour rechercher des intersections, ou 3D. L'étape suivante consiste à transposer dans un espace triangulaire la requête Q (avec Q.clef ; Q.Td ; Q.Tf) pour délimiter une zone. Cette approche pose cependant de nombreux problèmes. En effet, elle n’est pas optimale pour des données ayant toujours cours (Tf non défini). De plus, il est possible qu’une requête fasse ressortir un rectangle qui ne soit plus à jour, ou bien un rectangle trop imposant (problème de la persistance des données et des intervalles).



La méthode n’est également pas optimale pour indexer les objets en mouvement (création de boites trop grande dans les approches continues, perte d’information dans les approches discrètes).

Enfin, les recherches prennent en compte l’intégralité des entrées et sont d’autant plus longues que le nombre de données croît. D’une manière globale, si cet index reste efficace pour les requêtes d’intervalle, il ne l’est pas pour les requêtes de timestamp, d'instants temporels.

Figure 12 : Structure du 3DR-Tree [78]

HR Tree, MR Tree [49]

Cet index (cf. figure 13) est supérieur au 3D R-Tree pour les recherches de timestamp et les petits intervalles. Cependant, il implique la duplication d’objets, et a de relativement mauvaises performances dans les requêtes d’intervalle. De plus, il n'est pas recommandé de l'utiliser dans des cas de mises à jour importantes. Son principe repose sur la création de R-Tree correspondant à l'état du système à des instants donnés. Les parties qui n'ont pas évolué entre deux arbres mitoyens sont partagées. Il suffit cependant qu'un point change pour que toute une branche doive être recrée, d'où une perte d'espace et de temps calcul.



Figure 13 : Structure du HR-tree [49]

MV3R-Tree [74]

Le MV3R est issu des MVB-Tree et des 3DR-Tree (cf. figure 14). Il a été conçu pour répondre à des requêtes d'instants temporels et d'intervalles, et pour récupérer les localisations ‘passées’ d’objets en mouvement.

Il contient un MVR Tree (MVB-Tree appliqué aux R-Tree, avec une finalité comparable à celle d'un HR Tree) et un petit auxiliary 3DR Tree dans les nœuds feuille.

Les entrées du MVR-Tree sont de la forme <MBR, Td, Tf, pointeur>. Cet arbre supporte la condition de version faible.

La suppression s’applique comme pour un R*Tree s’il n’y a pas de changement de structure. Il existe potentiellement moins de feuilles dans le MVR-Tree que d’objets réels.

L’auxiliary 3DR-Tree, utilisé pour les requêtes d’intervalle, est plus petit que le 3DR-Tree classique. Dès qu’il y a mise à jour du MVR-Tree, ce sous-index est aussi mis à jour.

Le processus de requête élimine les racines non intéressantes avant de commencer une recherche dans les 3DR Tree.

Les différents index spatio-temporels existants sont généralement basés sur des variantes de R-Tree. Par là-même, ils sont en mesure de gérer des données


Figure 14 : Structure du MV3R-Tree [74]


ponctuelles tout comme des zones particulières. Cependant, ces structures souffrent des limites communes aux R-Tree, à savoir une dégradation importante des performance en cas d'augmentation de la masse de données.

4.1.2.3 Indexation et Temps-Réel

La généralisation des données spatiales et spatialisées a été la source d'un certain renouveau en matière d'indexation. Les masses de données à traiter s'accroissant, les limites des R-Tree en matière d'indexation sont apparues. Aussi, certaines équipes de recherche, principalement coréennes se sont attaché à proposer des solutions prenant en compte l'utilisation des mémoires caches. L'héritage des CSB+Tree [60] a conduit au développement de nouvelles solutions.

CR-Tree [34]

Le CR-Tree est une solution d'indexation visant à améliorer l'utilisation des mémoires caches afin d'obtenir des performances optimales. Basé sur le R-Tree, le CR-Tree compresse les rectangles englobants, les MBRs, en quantifiant les valeurs de coordonnées sur un nombre déterminé de bits. Les coordonnées des nœuds fils ne sont pas notées entièrement dans tous les enregistrements. Chaque MBR est subdivisé pour former un quadrillage. Les enregistrements du CR-Tree comportent les coordonnées du MBR global, ainsi que les coordonnées du quadrillage correspondant aux enregistrements. Les performances du CR-Tree sont notoirement supérieures à celles d'un R-Tree classique, principalement lorsque le nombre de données croît. Cependant cette structure est principalement spatiale, et ne prend pas en compte toutes les particularités spatio-temporelles.

PR-Tree [70]

Le PR-Tree vise également à améliorer les performances du R-Tree. Pour ce faire, il réduit l'espace occupé par les enregistrements de MBRs en n'enregistrant que les cotés des MBRs différents de ceux du MBR parent. Les résultats affichés par le PR-Tree sont optimaux pour un nombre restreint d'entrées. Une fois de plus, cette structure offre des performances supérieures à celles du R-Tree, mais n'est directement applicable qu'à des données spatiales.

PCR-Tree [69]

Le PCR-Tree est, comme son nom peut l'indiquer, un compromis entre PR et CR-Tree. Il applique le principe du PR-Tree à un CR-Tree afin de permettre un élargissement de celui-ci, sans diminuer la précision pour autant. Les nœuds du PCR-Tree comportent différents champs : le nombre d'entrées dans le nœud, un pointeur vers le groupe de nœuds fils / enregistrements, un MBR global du nœud, un champ de bits de données et finalement les données elles-même. Le principe de



fonctionnement du PCR-Tree consiste à trouver quelle technique, du CR ou du PR-Tree permet les meilleures performances. De fait, la mise à jour et la recherche dans un PCR-Tree offre des résultats supérieurs à ses deux parents.

Les systèmes d'indexation prenant en compte les particularités de la mémoire cache restent rares, et issues d'un groupe restreint de chercheurs. Ces techniques se basent principalement sur des R-Tree modifiés. De fait, ces index sont mieux adaptés à l'indexation de masses de données spatiales. Ces structures restent cependant limitées sur un point : elles sont principalement spatiales, et ne prennent pas en compte les particularités spatio-temporelles.

4.1.3 Critique des index disponiblesLes différents index disponibles pour l'indexation spatiale, temporelle ou spatio-temporelle ne prennent que rarement en paramètre les spécificités relatives aux sources d'information. Centrées sur les données, elles écartent la possibilité d'indexer des données émises par des sources d'informations spécifiques. Ainsi les mécanismes d'accès et de mises à jour des données doivent-ils généralement prendre en compte l'ensemble des données pré-existantes afin de répondre aux requêtes reçues. De ce fait, les performances temps-réel de ces index sont généralement limitées. L'indexation spatio-temporelles des données issues d'un réseau de capteurs fixes est une tâche qui reste limitée aux réseaux les plus simples. Les systèmes de surveillances de phénomènes utilisant de nombreux capteurs sont généralement contraints de se passer de l'indexation spatio-temporelle, au grand dam des spécialistes, gestionnaires du risque et autres scientifiques.

Le tableau récapitule les différentes particularités des index présentés et montre qu'aucun de ceux-ci ne répond entièrement aux spécificités des bases de données capteurs.. Cependant, certains mécanismes de ces index peuvent être repris dans le but de créer une nouvelle solution.



Nom TypeValorisation des mises à

jours

Gestion de l'aspect

temps-réel

Conservation de

l'historique des valeurs

passées

Mise à jour en ligne

Kd-Tree spatial non non non ++

R-Tree spatial non non non -

R*Tree spatial non non non --

DR-Tree spatial non non non --

Grid File spatial non non non +

QuadTree spatial non non non -

Append-Only Tree

temporel oui non oui ++

MVBT temporel non non oui +

Index TP temporel non non oui -

GR-Tree bitemporel non non oui --

3DR-Tree ST non non oui ---

HR-Tree ST non non oui -

MV3R ST non non oui --

CR-Tree spatial non oui non +

PR-Tree spatial non oui non +

PCR-Tree spatial non oui non +

Tableau 2: Comparatif entre les index spatio-temporels

Les différents index déjà existants ne correspondent pas aux besoins rencontrés dans le cadre de la surveillance de phénomènes basée sur l'utilisation d'un réseau de capteurs en temps-réel. Une base de données centralisée doit pouvoir répondre à certains impératifs :

● Elle permet une indexation par rapport à des éléments spatiaux et temporels.

● Elle permet la gestion de masses de données

● Elle valorise la mise à jour de nouvelles données

● Elle peut répondre à des contraintes temporelles (mise à jour)

● Elle peut être mise à jours « en ligne »



4.2 Le PoTree

Le PoTree est un système d'indexation pour bases de données spatio-temporelles centralisées en mémoire vive, travaillant sur des données issues d'un réseau de capteurs fixes [51][52]. Cette définition dense est relative à un index conçu afin de répondre aux besoins exprimés dans le cadre de la surveillance de phénomènes à partir de réseaux de capteurs. La présentation du PoTree se décompose en une description du contexte d'utilisation, suivi d'une description de la structure elle-même. A cette présentation viennent s'ajouter des exemples de résolution de requêtes avant de finalement aborder la partie implémentation de l'index.

4.2.1 Contexte d'utilisationL'utilisation de l'outil informatique afin d'aider à la surveillance de phénomènes (naturels, urbains,...) est une réalité presque aussi vieille et répandue que l'outil informatique lui-même. Cependant, le développements des technologies capteurs aussi bien que des technologies informatiques ont apporté tour à tour des changements dans la manière d'aborder cette utilisation.

Un système d'indexation pour base de données capteurs fixes devra prendre en compte un certain nombre de spécificités :

● Utilisation des aspects spatio-temporels pour les requêtes / mises à jour

● Regroupement des données en fonction des capteurs


● Valorisation des mises à jours en temps-réel

● Travail en mémoire vive

● Possibilité d'utilisation conjointe avec un entrepôt de données

● Requêtes diverses (principalement point spatial / intervalle temporel)

4.2.1.1 Rappels sur les aspects spatiaux et temporels

Les données spatiales sont de plus en plus courantes et leur utilisation de plus en plus fréquente. La généralisation de l'outil GPS ou d'autres systèmes permettant une localisation précise a ainsi permis une présence de plus en plus prégnante du domaine spatial dans les systèmes de surveillance de phénomènes. A l'heure où les médias se font fort de présenter cartes et autres représentation du monde réel, les utilisateurs de systèmes de surveillance sont enclin à vouloir à leur tour utiliser des



aspects spatiaux pour leurs travaux. Cependant, ces aspects ne supplantent pas les aspects les plus classiques de l'utilisation de réseaux de capteurs.

Historiquement, les capteurs utilisés pour les systèmes de surveillance étaient fixes. Souvent trop lourds ou encombrants pour être déplacés (par exemple des pluviomètres), ils pouvaient être placés dans des stations de surveillance choisies en fonction de différents critères (proximité avec un élément à surveiller, possibilité d'accès,...). Dès lors, les utilisateurs des systèmes de surveillance, scientifiques, gestionnaires du risque ou simples curieux, pouvaient se référer à une carte sur laquelle étaient reportés les différents capteurs référencés en fonction d'un identifiant.

L'utilisation classique des systèmes de surveillance se fonde sur les identifiants de capteurs et sur l'aspect temporel pour identifier les différentes données. En effet, les utilisateurs ont pour habitude de consulter des tables de localisation de capteurs (cf. tableau 3). De là, après avoir déterminé les capteurs qu'ils désirent interroger, ils peuvent commencer la partie consultation en elle-même, lançant une requête pour accéder aux données collectées durant la période de temps désirée à partir des identifiants de capteurs. L'habitude aidant, le besoin de recourir aux tables diminue, mais il n'en demeure pas moins que les données sont représentées par le système de surveillance en fonction de l'identifiant d'origine et de l'aspect temporel.

Comme explicité plus tôt, les utilisateurs désirent désormais pouvoir utiliser directement les aspects spatiaux (des points correspondant à la position des capteurs) pour obtenir les données recherchées. Il est pour eux bien plus intuitif de désigner sur une carte les zones pour lesquelles ils veulent accéder aux données plutôt que de devoir se référer à des tables de conversion.

Les utilisateurs travaillent sur des regroupements de données en fonction des capteurs. En effet, lors de leurs études, les utilisateurs ont pour habitude d'étudier d'abord et en premier lieu des données issues d'intervalles temporels. La mesure brute et unitaire peut être porteuse d'information. Cependant, c'est généralement l'évolution des mesures d'un même capteur qui sera préférée. En effet, de par la nature même des capteurs et leurs conditions d'utilisation parfois extrêmes, une mesure unitaire peut être faussée. Cependant, l'évolution de données à plus long terme (quelques minutes, heures ou semaines) peut apporter un aperçu plus précis de l'état du système à étudier. De nombreux systèmes évoluent lentement, même s'ils peuvent connaître des phases d'activités hautes en couleur et dangereuses (volcanisme,...). L'étude des données sur des intervalles temporels permet donc de prévenir de l'imminence d'une phase d'activité dangereuse, de lancer des alertes et des processus permettant de prévenir, ou de limiter l'impact d'un phénomène.


Tableau 3 : Exemple de table de localisation de capteurs [33]

Lat Long Alt PrefectureOKN003 GUSHIKAWA 26,38 127,86 10 OKINAWAKENOKN002 NAGO 26,59 127,98 3 OKINAWAKENOKN001 KUNIGAMI 26,74 128,18 7 OKINAWAKENKGS035 YORON 27,05 128,43 44 KAGOSHIMAKENKGS034 CHINA 27,33 128,58 24 KAGOSHIMAKENNGS018 TAMANOURA 32,63 128,62 6 NAGASAKIKENNGS017 FUKUE 32,66 128,85 127 NAGASAKIKEN

Ident ifiant No m


4.2.1.2 Représentation des données et temps-réel

La structuration des données recherchées par les utilisateurs est de type <Position; Instant; Identifiant de capteur; Mesure>. La position est liée au capteur, de même que l'identifiant. Ils font tous deux partie des méta-données utiles à certains processus d'extrapolation de données ou d'identification de phénomènes. La date est liée à la mesure. Lorsque les utilisateurs envoient une requête d'accès à une donnée à l'instant T1 le système doit fournir la réponse la plus proche. Dans le cas idéal le capteur a pu fournir une donnée au même instant. Cependant dans la majorité des cas, une donnée plus ancienne sera disponible. Le système devra donc répondre à la requête utilisateur tout en lui précisant la date de la mesure réelle. Il appartient au processus utilisateur de juger de la validité de la donnée. Si l'écart temporel est trop élevé entre l'instant souhaité et la réponse, la donnée peut être écartée.

Les données les plus récentes sont généralement plus importantes et plus souvent accédées. Pour de nombreux spécialistes, le but de leur travaux vise à prévoir l'état futur du système étudié, que ce soit un système urbain ou naturel. Pour cela, des modèles sont établis prenant en compte l'évolution récente du système. Ainsi, pour ces spécialistes, les données les plus récentes sont porteuses d'informations cruciales. En d'autres termes, savoir comment se comportait le système trois jours auparavant est intéressant, mais savoir comment il se comportait trois minutes plus tôt l'est davantage. Il est cependant nécessaire de modérer cette affirmation. En effet, certaines phases d'activités spécifiques peuvent généralement être extrapolées. Par comparaison des données récentes avec les enregistrements correspondant à ces phases d'activité particulières il devient possible de graduer la probabilité d'occurrence d'un phénomène particulier dans un avenir proche. Ainsi donc serait-il plus convenable d'affirmer que les données les plus récentes sont généralement porteuse de données cruciales au travail des spécialistes chargés de l'analyse, mais que des données plus anciennes, caractéristiques de phases d'activités particulières sont porteuses de tout autant d'information.

Les travaux sur les données récentes recquièrent des résultats dans des délais plus courts que les travaux sur des données plus anciennes. L'analyse en continu de données se fonde généralement sur l'analyse des données valides au moment de l'analyse. Ceci présuppose des capacités de calcul en conséquence, mais aussi des capacités d'accès rapide aux données. Ainsi, le système chargé de collecter les données se doit de pouvoir fournir les données les plus récentes dans des temps limités. Plus encore lors de phases d'activités à risque. Il est en effet crucial que les centres de gestion du risque et des catastrophes soient à même d'obtenir les données les plus précises et les plus pertinentes. Le nombre de requêtes d'accès au système croît pour les données récentes, et les délais accordés pour l'exécution diminuent. A contrario, les études se fondant sur des mesures plus anciennes sont généralement moins pressées et les utilisateurs acceptent aisément des temps de réponses plus importants. Les données pouvant être âgées de plusieurs années, et couvrant des intervalles temporels importants, les utilisateurs n'ont instinctivement pas l'espoir d'obtenir des réponses à leurs requêtes dans des temps courts. En cas de crise, l'accès aux données plus anciennes peut être une fois de plus sollicité, afin d'établir des scénarii d'évolution du système en fonction de crises passées ou autre, mais ces



accès restent généralement d'une priorité moindre vis à vis des données les plus récentes.

Les accès aux données peuvent être temps-réel ou non. Comme l'indique le paragraphe précédent, en cas de crise, l'accès aux mesures récentes collectées devient prioritaire. Les gestionnaires du risque ont besoin de données récentes dans des temps brefs et limités afin de pouvoir tenter de limiter l'impact d'une catastrophe. La notion de contrainte temporelle apparaît ici. Plus encore que le besoin d'accéder aux données dans des délais brefs, il s'agit surtout d'y accéder avant la fin d'intervalles spécifiés, généralement courts. Dans cette optique, l'accès aux données devient temps-réel, et il convient d'établir des politiques de « prioritisation » des accès. Une simple consultation par « ouèbe » issue d'un simple curieux ne doit pas bloquer l'accès aux même données par les experts internationaux, qui ne doivent eux-même pas bloquer l'accès des experts reconnus ayant autorité sur la gestion du système concerné. En contrepartie, en dehors de ces phases d'activité spécifiques, l'accès aux données n'est pas nécessairement soumis aux contraintes temps-réel. En effet, lors de phases d'activités calme, les spécialistes acceptent généralement de bonne grâce d'attendre quelque peu avant d'accéder aux mesures qui les intéressent. Et si les mesures n'arrivent pas, ils sont généralement prêts « à re-cliquer sur le bouton et attendre que ça arrive, » d'après les termes employés par un vulcanologue.

4.2.1.3 Lien avec la base de données

La mise à jour des données collectées doit être effectuée en temps-réel. Comme précisé dans la partie sur les capteurs, la collecte des mesures concerne généralement des masses de données. Un sismographe peut avoir une fréquence de mesure de l'ordre de 100 ou 200 Hz. L'arrivée des données dans le système ne s'effectue pas nécessairement unitairement, les mesures peuvent être agrégées, mais la masse de données à traiter n'en reste pas moins imposante. Ainsi, les méthodes de gestion des données dans le système doivent pouvoir prendre en compte cet afflux constant de masses de données. Au niveau d'une base de données, cela se traduit par le besoin de pouvoir indexer et stocker une donnée issue d'un capteur avant qu'une mesure plus récente ne soit disponible. Différentes techniques permettent d'ordonnancer les transactions afin de limiter les risques de perte de donnée. Dans le cas de mises à jour purement périodiques, des ordonnancement se basant sur Rate Monotonic permettent une mise à jour en temps-réel.

Certaines données peuvent être perdues. La définition de temps-réel implique la possible perte de données. Il est souvent préférable qu'une transaction soit abandonnée plutôt qu'elle n'entraîne des retards en cascade dans un système temps-réel. Ainsi certaines mises à jour risquent de ne pas pouvoir être effectuées à temps par le système et peuvent ainsi être écartées. Il s'agit d'une hypothèse possible lors d'une phase d'activité particulière où des capteurs périodiques et des capteurs envoyant leurs données lors de la suppression d'évènements particuliers cherchent à accéder au système de surveillance. Par là-même les enregistrements de données de capteurs peuvent comporter des enregistrements manquants.



Les mesures sont d'abord enregistrées dans une base de données centralisée en mémoire vive. Bien que des travaux actuels tendent à accentuer l'intérêt d'utiliser des technologies distribuées directement au niveau des capteurs, le risque de panne lié à ces derniers limite la possibilité de conservation des données au niveau de ceux-ci. Les systèmes historiques de surveillance ont été développés alors que les technologies distribuées étaient à leurs balbutiements. Ainsi a-t-il généralement été décidé d'utiliser des bases de données centralisées pour conserver les mesures effectuées par les capteurs. De plus, du fait du coût d'accès aux mémoires de masse, l'approche mémoire vive est valorisée pour les données les plus récentes, qui concentrent la majorité des accès.

La base de données est généralement liée à un entrepôt de données pour les mesures les plus anciennes. En effet, la base de donnée est limitée en taille par la quantité de mémoire disponible. Il est donc nécessaire de pouvoir en vider le contenu le plus ancien vers d'autres supports. Ceux-ci sont généralement gérés par un entrepôt de données. Ainsi, alors que la base de données stocke des données les plus récentes, les données plus anciennes sont sous la gestion de l'entrepôt. Les deux systèmes doivent collaborer pour résoudre des requêtes portant sur un intervalle temporel couvrant les périodes gérées par la base et l'entrepôt. L'utilisation d'un entrepôt de donnée offre un avantage double puisqu'il permet de vider une partie de la base, et ainsi de diminuer le temps de réponse aux requêtes. En effet, les index utilisés dans les bases de donnée voient leurs performances se dégrader lorsque le nombre d'enregistrements croît.

On voit apparaître ici le contexte dans lequel devra fonctionner le nouvel indexe que nous dénommons PoTree. Index pour base de données, il doit permettre un regroupement des mesures collectées en fonction de critères spatiaux liés capteur, et temporels. De plus, il doit valoriser les mises à jours ainsi que l'accès aux données les plus récentes. Les mises à jours, temps-réel, peuvent concerner des données périodiques ou non. Le PoTree doit également être en mesure de gérer des masses de données. Le PoTree doit pouvoir opérer sur une base de donnée en mémoire vive, liée à un entrepôt de données qui collecte les enregistrement les plus anciens. Ces différentes particularités ont permis la création du PoTree, qui possède une structure d'arborescence pour indexer les données.

4.2.2 Structure du PoTreeLe PoTree est structuré selon un ensemble d'arbres, chacun ayant une fonction propre. Un arbre spatial est utilisé pour déterminer les différents arbres de capteurs, temporels, concernés par la résolution d'une requête. Une analogie simplifiée serait de présenter le sous-arbre spatial comme un plan sur lequel sont nommés les différentes essences des arbres composant le jardin botanique baptisé "PoTree." Le plan (figure 15) se trouve à l'entrée du jardin, et à chacun des arbres composant celui-ci, tous différents, sont rattachés toutes les informations relatives à cette essence particulière.



D'une manière plus formelle, le PoTree se compose de deux types de sous-arbres (cf. figure 16). Les requêtes sont envoyées à la racine du sous-arbre spatial qui prend en charge l'interrogation des différents sous-arbres temporels et fournit les résultats demandés. Le sous-arbre spatial est utilisé pour déterminer les positions des différents capteurs fixes. A chacun des capteurs est associé un sous-arbre temporel dédié, indexant les données en fonction de la date de la prise de la mesure.


Figure 15: Plan du jardin botanique PoTree

Fiche d'arbre

NomDate

...

Plan Spatial

Point d'entrée

Fiche d'arbre

NomDate

...

Fiche d'arbre

NomDate

...

Fiche d'arbre

NomDate

...

Figure 16 : Structure générale du PoTree

Temporel

Spatial

DonnéeArbre Spatial

Kd-tree

Arbre Temporel

B+-tree


Le PoTree est un système d'indexation spatio-temporel qui présuppose des critères spatiaux et temporels afin de répondre à des requêtes précises. Une requête commence nécessairement par l'interrogation de la sous-structure spatiale.

La séparation effectuée entre les dimensions spatiales et temporelles signifie qu'aucun des sous-arbres ne possède l'intégralité des données collectées. Par conséquent, il est nécessaire de consulter au moins deux sous-structures à chaque requête. Cependant, le coût supplémentaire engendré par ce double accès est plus que compensé par l'économie résultant de la séparation des données en plusieurs sous-arbres. Il est certes nécessaire d'accéder à au moins deux sous-structures, mais une requête ne doit plus être résolue en prenant en compte l'ensemble des données, comme c'est le cas pour les R-trees. Le système ne ne considère que les données relatives au capteur interrogé (cf. figure 17).

L'exploitation de plusieurs sous-structures permet enfin d'essayer de limiter les inconvénients liées à chacune, tout en essayant de tirer profit des avantages de chacune. Le sous-arbre spatial et les sous-arbres temporels sont ici complémentaires.

De plus, cette approche regroupant les données d'un même capteur dans une structure particulière permet le développement de systèmes tirant parti de cette politique. Dans des systèmes où les contraintes temps-réel se font moindres, il devient possible de développer une architecture distribuée. Plusieurs nœuds collaborent ainsi à la collecte d'informations. Chacun de ces nœuds est alors responsable d'un capteur en particulier. En reprenant une approche GHT [62] pour identifier la localisation des données, il devient par là-même possible de mettre en place les prémisses d'un index distribué. Certains nœuds devant conserver les données relatives au sous-arbre spatial tandis que d'autres conservent les mesures dans des sous-arbres capteurs dédiés.


Figure 17 : Différence structurelle entre R-Tree et PoTree

Temps

Position

Données

Temps

Position

Temps

Position

R0R1

R3R4

R5

R6R2R7

R-TreePoTree


4.2.2.1 Le sous-arbre spatial

Le sous-arbre spatial est le point central du PoTree. Cette sous-structure est consultée pour chaque requête afin de déterminer les sous-structures de capteur concernées. Par la suite, il leur transfère les requêtes modifiées, ne comportant plus que la dimension temporelle, et collecte les résultats avant de les présenter à l'utilisateur. Ainsi, l'accès à cette sous-structure conditionne grandement les performances du PoTree.

De plus, le sous-arbre spatial sert à la fois d'interface avec le système de gestion de la base de données et d'arbre spatial à proprement parler. C'est en effet ce sous-arbre qui reçoit les requêtes spatio-temporelles émises par les différents processus utilisateurs.

4.2.2.1.1 Lien avec les capteursLes capteurs qui forment le réseau sont fixes. Il n'est donc pas nécessaire de conserver des indicateurs temporels dans le sous-arbre spatial. De tels indicateurs ne seraient utiles que pour aider à garder la trace d'un mouvement. Si un capteur venait à disparaître, il serait conservé dans cette structure jusqu'à ce que l'ensemble de son sous-arbre capteur soit transféré vers l'entrepôt de données ou soit purement et simplement effacé.

L'ajout de nouveaux capteurs doit être possible, mais ce processus reste cependant rare. En effet, les capteurs ont des durées de fonctionnement généralement importante, même si les risques de pannes sont réels. Par conséquent, la structure doit être en mesure d'effectuer des mises à jour en ligne. Il convient de noter que le nombre de capteurs reste minime au regard de la masse de données collectées.

4.2.2.1.2 La structure du sous-arbre et l'accès aux donnéesEn conséquence de ces particularités le sous-arbre spatial du PoTree que nous proposons est un kd-tree modifié. Cette structure offre des possibilités de mise à jour en ligne, tout en offrant des performances acceptables lors de requêtes nécessitant un accès aux données. Comme décrit précédemment, le kd-tree est un arbre d'indexation qui découpe l'espace à traiter en fonction de points de références et des différentes dimensions utilisées.


Figure 19 : Explication de la notation des schémas d'enregistrements

Champs d'enregistrement

Tableau ou pile de données

Lien, pointeur ou référence

Figure 18 : Structure d'un nœud du sous-arbre spatial

Noeud Gauche Noeud Droit Arbre capteurPosition


Chaque nœud de la sous-structure spatiale comporte une référence spatiale, correspondant à la position d'un capteur, ainsi que deux pointeurs vers des nœuds fils (cf. figure 18 pour le nœuds et figure 19 pour le symbolisme utilisé). Un dernier pointeur lie cette sous-structure avec un sous-arbre temporel, de capteur.

La référence spatiale concerne une position à deux ou trois dimensions, selon le cas d'application. Elle prend la forme d'un tableau de données numériques au format fixe (cf. tableau 4). Chaque colonne correspond alors à une dimension spatiale. Cette référence présuppose que la position d'un capteur sera déterminée à sa création.

Tableau 4 : Représentation des positions de plusieurs capteurs

A chaque niveau de l'arbre correspond une dimension de référence. En descendant dans la structure, les dimensions de référence sont alternées, la « colonne » du tableau des données spatiales précédent est changée. La figure 20 présente le processus de descente dans l'arbre pour renvoyer un lien vers un arbre capteur.

Toute requête de mise à jour ou de suppression de données suit le même principe. En premier lieu chercher s'il existe un ou plusieurs points spatiaux existant et répondant aux paramètres de la requête. Une fois cette phase de détermination des sous-arbres capteurs concernés achevée, la partie temporelle de la requête est dupliquée et transmise aux différents sous-arbres capteurs pour être exécutée. Le sous-arbre spatial collecte finalement les résultats, et les compile avant de les transmettre à l'utilisateur.


Lat Long Alt26,38 127,86 1026,59 127,98 326,74 128,18 727,05 128,43 4427,33 128,58 2432,63 128,62 632,66 128,85 127


4.2.2.1.3 Insertion et suppression de donnéesLors de l'ajout d'une nouvelle mesure, décrit dans la figure 21, une vérification de la pré-existence d'un point spatial (capteur) associé à cette mesure est effectuée. Pour cela la sous-structure spatiale est parcourue depuis la racine (algorithme basé sur celui présenté en figure 20). A chaque niveau la valeur associée à la dimension de référence du point à ajouter et celle du point de référence du nœud sont comparées. Si cette dernière valeur est supérieure, le pointeur fils droit du nœud est utilisé pour descendre dans la structure d'un niveau. Sinon, si la valeur à ajouter n'est pas supérieure, la position du nouveau nœud et celle du point lié à la donnée à insérer sont comparées entièrement. Si elles sont identiques, le capteur a déjà été défini et la requête de mise à jour est transmise au sous arbre capteur correspondant. Dans le cas inverse, où les positions sont différentes, la descente dans l'arbre spatial se poursuit à l'aide du pointeur fils gauche du nœud. Lorsqu'un des pointeurs fils pointe sur la valeur nulle, un nouveau nœud est créé à ce niveau. Le point à insérer devenant le point de référence de ce nœud. Un nouvel arbre de capteur est à son tour créé et directement mis à jour à l'aide de la donnée à insérer.

De par la nature fixe des capteurs et leur espérance de vie importante, la quasi-totalité des mises à jours portent sur des capteurs déjà définis. Le processus d'ajout de nouveaux capteurs est rarement utilisé.


Figure 20 : Recherche dans l'arbre spatial à partir d'un point


La méthode de mise à jour de la partie spatiale, reprenant l'algorithme du kd-Tree, n'est pas optimale. En effet, de par son algorithme l'ajout de nouveaux points s'effectue sans égards quant à l'équilibre global de la structure. Dans le pire des cas il est possible de n'observer que les ajouts à droite ou à gauche du point de référence. Dès lors, la consultation des données souffre de ce déséquilibre, davantage de nœuds devant être parcourus avant d'atteindre les données.

Plusieurs solutions peuvent être envisagées. La première suppose une connaissance au préalable des différents points spatiaux. Dès lors il devient possible de créer une fonction permettant d'organiser l'ordre d'insertion des données afin d'obtenir un arbre équilibré. Ceci induit une création au préalable de la structure de l'arbre spatial. Un autre procédé consiste à effectuer des suppressions et réinsertions des nœuds aux niveaux supérieurs afin de tenter de ré-équilibrer la structure globale. Cette solution impose toutefois une réorganisation de la structure globale. Elle ne permet cependant pas d'obtenir un équilibrage parfait.

Une fois les données ajoutées à la structure globale, il convient de pouvoir les effacer, ne serait-ce que pour libérer de l'espace mémoire. La méthode d'effacement des données suit un processus proche de celui de toute autre requête. En premier lieu, il s'agit de déterminer les sous-arbres capteurs concernés par la suppression. Ceci s'effectue par un parcours récursif du sous-arbre spatial. Une fois le ou les sous-arbres capteurs impliqués déterminés, une sous-requête de suppression leur est envoyée. Le sous-arbre spatial attend en réponse une information sur l'état de la structure capteur concernée. S'il existe encore des données dans la structure, la requête s'interrompt. Si au contraire la suppression a complètement vidé la structure de capteur, le sous-arbre spatial peut libérer la mémoire associée à celle-ci, éliminer le nœud et réinsérer les points anciennement pointés par les branches de ce nœud.


Figure 21 : Mise à jour du PoTree via l'arbre spatial


4.2.2.1.4 Accès aux données : quelques requêtes moins fréquentesSuppressions comme interrogation de données peuvent porter sur des points, mais aussi sur des régions entières. Le principe de parcours de l'arbre spatial pour un point a déjà été détaillé lors de l'insertion de données. Pour le parcours de la structure sur des zones de données, le principe reste proche. Il consiste à déterminer la position du point relatif au nœud par rapport aux deux points marquant l'angle supérieur droit (maximum des coordonnées de la zone à rechercher) et l'angle inférieur gauche (minimum des coordonnées). A chaque niveau de l'arborescence, pour chaque dimension de référence, la procédure commence par vérifier si le point du nœud se trouve à droite (est plus grand) du point minimum de la zone de recherche. Si c'est le cas, la recherche pourra être relancée dans le nœud fils gauche. La seconde partie de la procédure consiste à vérifier si le nœud se trouve à gauche (est plus petit) du point maximum. Si c'est le cas, la requête pourra être relancée également dans le fils droit. Après ce premier test, une vérification de la présence du nœud dans la zone de recherche est effectuée. Si c'est le cas, la partie temporelle de la requête est transmise au sous-arbre capteur.

Jusqu'à ce point, les processus d'ajout et de suppression de données ont été abordés. Il en a été de même pour les méthodes d'accès à des points particuliers et pour l'accès aux points inclus dans des zones données. Cependant, d'autres types de requêtes peuvent être utiles aux utilisateurs finaux. Le kd-tree ayant été le sujet de nombreuses études, différents algorithmes ont été élaborés afin de permettre des accès divers et variés aux données. Outre les recherches d'égalité permettant de reconnaître des points, les recherches d'inclusion pour les points contenus dans une zone particulière, un dernier type de requêtes peut être utilisé : les requêtes de recherche de voisin le plus proche. En effet, un spécialiste ne bénéficiant pas d'une liste précise des capteurs. Une recherche spatiale peut alors permettre de spécifier le capteur le plus proche d'un point spécifié. L'algorithme proposé par A. Moore dans sa thèse [48] peut être exploitée dans ce cas.

4.2.2.1.5 Performances théoriquesLes performances du sous-arbre spatial s'apparentent à celles du kd-tree. Le coût de construction de la structure est fonction du nombre de données entrées et du nombre de dimensions utiles (deux ou trois). Le coût de construction pour n capteurs est alors de

O n∗log nL'espace mémoire utilisé est quant à lui linéaire.

Finalement, le coût d'exécution d'une requête de fenêtre spatiale (zone) est de

O d∗n1−1/dt Avec d le nombre de dimensions de l'espace indexé et t le nombre de liens vers des sous-arbres capteurs.

En somme, le sous-arbre spatial a pour but de référencer spatialement les différentes positions occupées par les capteurs. Les requêtes adressées au PoTree passent d'abord par ce sous-arbre. Celui-ci a pour tâche de repérer les différents sous-arbres capteurs concernés par la résolution des requêtes et leur envoie la partie temporelle des requêtes. Il collecte par la suite les résultats et les agrège avant de les présenter



à l'utilisateur. Il se base sur un kd-tree modifié et offre des performances proches de celui-ci. Cette sous-structure agit en premier lieu comme un répartiteur de requêtes. Point de passage obligé, possible goulot d'étranglement, il a pour but premier d'organiser la répartition des données en fonction des différents capteurs dont ils sont issus, ce qui permet de diminuer le coût d'accès au données. En effet, les sous-arbres capteurs offrent la possibilité de résoudre des requêtes en parallèle et le PoTree peut ainsi réduire le nombre de données utilisées pour la résolution de requêtes.

4.2.2.2 Les sous-arbres capteur

A chaque capteur, un sous-arbre temporel lui est dédié (cf. figure 22). Il s'agit du principe de fonctionnement du PoTree, permettant de limiter le nombre de données devant être accédées lors de la résolution de requêtes. Chacun de ces sous-arbres agit comme un « lac de rétention », collectant toutes les données relatives à un capteur particulier. De plus, ils limitent les risques d'inondation (saturation processeurs voire mémoire) en divisant les données en sous-ensembles d'accès plus aisé. Chacun de ces lacs de rétention est géré de manière semi-autonome, et est relié que par une seule route, le sous-arbre spatial.

Chacun des sous-arbres capteur est un arbre d'indexation temporel (cf. figures 23) référençant les dates des mesures. Ce sont les dates de prise de mesure qui servent à classer les données. De plus, le contexte d'utilisation du PoTree induit que les requêtes émises concernent généralement des intervalles temporels. La structure retenue pour indexer les données capteurs doit donc permettre un accès à des blocs de données séquentielles.

La racine de l'arbre capteur comporte un champ identificateur qui référence le capteur. Deux liens sont également accessibles depuis la racine. Le premier pointe le noeud racine du B+Tree qui indexe effectivement les données temporelles. Le second pointe vers le dernier nœud de cette structure, où se situent les données les plus récentes.

Les nœuds internes du B+Tree comportent des enregistrements de dates liées à des nœuds fils. Un lien vers le nœud parent permet un rééquilibrage de la structure suite à des insertions / suppressions de données.


Figure 22 : Sous-arbre Capteur

T6T3 T7 T8T5T4T2T1T0

Mesures


Les nœuds feuilles comportent des enregistrements de date associées à des liens vers les mesures collectées. Ils conservent également des liens vers les nœuds précédents et suivant afin de faciliter les accès aux données. Un lien vers le nœud parent permet un rééquilibrage de la structure.

La sous-structure capteur valorise l'utilisation des données les plus récentes. En effet, les mises à jour s'effectuent normalement de manière incrémentale, des mises à jour rétroactives pouvant éventuellement être réalisées en cas de défaillance d'éléments du réseau induisant des délais de transmission de l'information. De même, les accès aux données concernent en premier lieu les données les plus récentes. Seules les phases d'analyses sur plus long terme demandent un accès à des intervalles temporels passés.

En raison de ces particularités la sous-structure utilisée exploite des caractéristiques du B+tree. Ce dernier permet en effet une indexation de données temporelles tout en facilitant les recherches sur des intervalles temporels grâce aux liens entre les nœud feuilles adjacents. Ces liens permettent une remontée des données dans le temps, sans avoir à re-parcourir l'ensemble de la structure. Puisque le B+Tree est utilisé pour indexer les mesures collectées en fonction du temps, les données les plus récentes se situent à droite de la structure, où se trouvent les marqueurs temporels les plus grands, donc les données les plus récentes. Le remplissage du sous-arbre capteur s'effectue donc de manière incrémentale vers la droite.

4.2.2.2.1 Amélioration de l'accès en mémoireDe plus, du fait des coûts d'accès à la mémoire, différents travaux sur le CSB+Tree [60] sont arrivés à la conclusion qu'il était souvent préférable d'utiliser des tailles de nœud plus important et de valoriser l'utilisation de tableaux de données plutôt que de multiplier l'usage de pointeurs d'accès plus lents. Les données stockées au sein de tableaux de données sont ainsi représentées dans des zones contiguës en mémoire, ce qui facilite la gestion de la mémoire cache. Alors que les premières études et que le « sens commun » tendaient à supposer que des structures de données calquées sur la taille des lignes de mémoire cache doivent offrir des performances supérieures, d'autres travaux ont montré des résultats différents [34].


Figure 23 : Structure des composants du sous-arbre capteurs

Identificateur Noeud Racine Dernier Noeud

Structure de la racine du sous-arbre temporel

Structure des noeuds internes du sous-arbre temporel

Temps Noeud

DonnéesTemps

Noeud Préc. Noeud Suiv.

Structure des noeuds feuille et des enregistrements du sous-arbre temporel

Lien ParentDonnées

Liens Enfants Liens Parent


Une structure de données de la taille d'une ligne de mémoire cache peut en effet être chargée dans son intégralité, épargnant ainsi la nécessité d'accéder une nouvelle fois à la mémoire vive. Cependant il est apparu que l'utilisation de structures dont la taille est multiple de la ligne de mémoire cache offraient des résultats supérieurs. Les systèmes de gestion de mémoire cache tirant généralement parti de la pré-sélection (pre-fetching) des données pour rapidement échanger les parties non utilisées de la mémoire cache.

Des nœuds plus grands entraînent une hauteur de la sous-structure moindre. La majorité des accès à la sous-structure concerne des données récentes, situées dans le dernier nœud, d'accès rapide. Cependant d'autres requêtes peuvent imposer l'accès à des données plus anciennes, situées dans des nœuds plus anciens. La résolution de telles requêtes impose par conséquent le parcours de la structure de l'arbre B+. En augmentant la taille des nœuds il est possible de diminuer le nombre de nœuds en proportion. Or c'est principalement la détermination du nœud et son accès qui augmentent le coût d'accès à la structure.

Certains systèmes actuels offrent parfois de simples piles de données brutes pour conserver les enregistrements, utilisant un calcul d'offset pour déterminer la position d'une donnée précise dans la pile. Une telle solution n'est cependant pas acceptable pour le PoTree. En effet, bien que de nombreux capteurs soient effectivement purement périodiques, envoyant une quantité prévisible de données à intervalles réguliers, d'autres capteurs n'émettent des données qu'en cas de dépassement de seuils d'alerte. Dès lors, il devient impossible de générer une fonction permettant un lien direct entre un instant donné et une position dans la pile. Dans le cas où des capteurs périodiques seraient utilisés, les particularités des systèmes temps-réels préviendraient l'utilisation d'une pile. En effet, le consensus du temps-réel pose en règle première qu'une transaction effectuée en dehors du délai qui lui est imparti peut engendrer des conséquences plus néfastes qu'un abandon pur et simple de cette transaction. Par conséquent, si toutes les mises à jours atteignaient la base de donnée (ce qui suppose un réseau exempt de pannes fonctionnant avec des communications isochrones), l'ordonanceur de la base pourraît être amené à rejeter certaines transactions de mise à jour afin de prévenir une saturation mémoire ou processeur du système. Des vides apparaîtraient alors dans la pile de données, rendant à terme l'adoption d'une fonction de conversion instant / position difficile, voire impossible.

4.2.2.2.2 Mise en avant des données les plus récentesLa structure retenue, basée sur le B+Tree ajoute à ce dernier un lien direct entre la racine du sous-arbre et le dernier nœud feuille de celui-ci. Rappelons que c'est ce nœud qui abrite les mesures les plus récentes. Dès lors, l'accès aux mesures, ainsi que les mises à jours peuvent exploiter ce lien pour limiter le coût d'exécution d'une requête. La racine contient également l'identificateur du capteur d'origine.



La figure 24 décrit le processus d'accès à une donnée dans l'arbre capteur. Lorsqu'une requête arrive au niveau d'un sous-arbre capteur, un premier test est effectué afin de déterminer si la date liée à la requête est postérieure ou simultanée au premier enregistrement temporel du dernier nœud feuille de la structure. Si ce test est positif, la requête concerne le dernier nœud de la structure et l'on utilise dès lors ce lien direct afin d'accéder au nœud idoine. Dans le cas contraire, la requête concernant des données antérieures, la structure de l'arbre capteur est traversée verticalement (algorithmes B+Tree classique) afin d'atteindre le nœud recherché. Une fois le nœud atteint, la liste des enregistrements est parcourue afin de déterminer les mesures à retourner.

La résolution de requêtes portant sur des intervalles impose de déterminer le nœud dans lequel se trouve la fin de l'intervalle recherché. Dans le cas optimum il s'agira du dernier nœud de la structure. Dès lors, la résolution de la requête pourra exploiter les liens entre les nœuds feuilles afin de limiter le coût d'accès aux


Figure 24 : Processus de recherche d'une mesure dans l'arbre capteur à partir d'une date donnée


données. Les requêtes sont résolues en remontant dans le temps, en se déplaçant vers la gauche dans la structure.

Notons que les requêtes peuvent porter sur des dates sans enregistrement. Si la structure contient des enregistrements pour les instants T1 et T2, avec T1<T2 mais qu'une requête porte sur T3 avec T3⊂ ]T1 ;T2 [ le résultat retourné sera celui valide à l'instant T3, en l'occurrence T1. Cependant ceci pose le problème de la durée de validité des données. Le résultat retourné doit présenter à la fois la mesure et l'instant T1. Il revient dès lors à l'utilisateur d'estimer la validité de la mesure.

Lorsqu'une mise à jour arrive, le test d'appartenance au dernier nœud permet de limiter le coût d'accès à celui-ci. Cependant, à partir de ce point, l'insertion de données suit la procédure d'insertion habituelle dans les B+Tree. Si le nœud est plein, un nouveau nœud est créé, la structure interne du sous-arbre capteur est mise à jour, ainsi que le lien entre la racine et le dernier nœud feuille si l'insertion de données a porté sur celui-ci.

4.2.2.2.3 Performances théoriquesD'un point de vue mathématique, les fonctions de coût associées au sous-arbre capteur prennent en compte la probabilité qu'une transaction concerne les données les plus récentes.

Le coût de construction de l'arbre capteur peut se représenter à partir de la formule utilisée pour le B+Tree, On log n modifiée pour prendre en compte les particularités du lien entre la racine et le dernier nœud. La formule finale prend la

forme suivante : O n11− p 1s1

log np ss1

avec n le nombre de données, p la probabilité pour que la mesure concerne les données les plus récentes et s le nombre de données pouvant tenir dans un nœud.

A chaque insertion le processus commence par vérifier si la mise à jour a lieu dans le dernier nœud. Ceci se traduit par le premier facteur n. Si la donnée ne concerne pas des données récentes, ce qui arrive avec une probabilité de (1-p), la mise à jour est similaire à celle d'un B+Tree normal, donc de coût log(n). Ceci se traduit dans la formule par n 1− p log n Lorsque la mise à jour concerne les données les plus récentes, avec une probabilité p, la mise à jour s'effectue directement en ajoutant la

donnée, ce qui est traduit par le p ss1 . Cependant, lorsqu'un nœud est rempli et

qu'un split a lieu, il convient de mettre à jour toute la structure interne du sous-arbre de capteur.

Le coût d'accès à des plages de données doit prendre en compte les même paramètres.

O 1−p log ns pt

Ici, on a p la probabilité pour que les données cherchées concernent les données les plus récentes, n le nombre de données contenues dans le sous-arbre, s le nombre de données pouvant tenir dans un nœud et t le nombre de données à retourner. Une fois de plus, le processus commence par vérifier si la donnée se trouve dans le dernier



nœud. De là, à une probabilité de (1-p), l'accès s'effectue selon la règle habituelle du B+Tree. Avec une probabilité p, l'accès s'effectue directement au dernier nœud, d'où le facteur p. Il faut alors rajouter le coup d'accès aux différentes données de la plage recherchée, t.

Ces formules mettent en avant l'impact de la probabilité selon laquelle la requête fait référence à des données du dernier nœud.

En résumé, le sous-arbre capteur est un B+Tree modifié. Un lien direct entre la racine de l'arbre et le dernier nœud feuille est ajouté, nœud dans lequel se trouvent les données les plus récentes. La taille des nœuds est augmentée afin de diminuer le coût d'accès à la structure. Elle offre par la même des résultats optimum pour des requêtes basées sur les données les plus récentes. Ce type de requête est le plus fréquemment rencontré dans les applications de surveillance de phénomènes.

4.2.3 Exemples de requêtesLe PoTree est chargé de répondre à différents types de requêtes. Dans chacun de ces cas, le requête initiale est décomposée en deux sous-parties. Une partie spatiale est résolue par le sous-arbre spatial. Il duplique alors la partie temporelle et l'envoie aux différents sous-arbres capteurs concernés. Chacun de ces sous-arbres travaille en semi-autonomie, renvoyant les mesures prises, accompagnées des marqueurs temporels qui leur sont associées et l'identifiant du capteur lié au sous-arbre.

Les requêtes les plus courantes dans un système de surveillance de phénomènes sont les mises à jours. Ces mises à jours prennent la forme <position; identifiant de capteur; temps de la mesure; valeur mesurée>. Le champ identifiant de capteur peut être omis dans le cas d'observations ponctuelles. Le sous-arbre capteur commence par déterminer si un arbre capteur existe à la position indiquée. Si ce n'est pas le cas, il lance la création d'un nouvel arbre capteur. Par la suite, il envoie une requête de mise à jour au sous-arbre capteur de forme <temps de mesure; valeur mesurée>.


Figure 25 : Processus de résolution d'une requête sur un point spatial et un intervalle temporel

Temporel

Spatial

Donnée

Requête Point / Intervalle

Recherche Spatiale

Chaînage à la source d'information

Recherche de la finde l'intervalle

Chaînage temporel

Arbre

Spatial

Kd-tree

Arbre Temporel

B+-tree


Si les mises à jours sont les plus courantes, les demandes d'accès aux données peuvent se révéler tout aussi importantes lors de la détection de phases d'activités spécifiques (cf. figure 25). Plusieurs types de requêtes d'accès peuvent être définies. Du point de vue spatial, trois types de sous-requêtes sont différentiables : accès par rapport à un point, recherche de point le plus proche ou inclusion dans une zone. Du point de vue temporel, deux types de sous-requêtes peuvent être distinguées : basées sur un instant précis ou sur un intervalle de temps. Une sous catégorisation permet de différencier les intervalles strictement délimités et les intervalles ouverts. Ces derniers se terminent à l'instant présent.

« Trouver les données issues du point <X;Y> entre les instants T1 et T2. »

« Trouver les données issues du point <X;Y> depuis l'instant T. »

« Trouver les données issues du capteur le plus proche du point <X;Y> à l'instant T. »

« Trouver les données issues des capteurs dans la zone définie par les points <X0;Y0> et <X1;Y1> entre les instants T1 et T2. »

4.2.4 Implémentation et testsDifférents essais ont été effectués entre le PoTree et le R*-tree, l'arbre d'indexation le plus fréquemment rencontré dans les bases de données disponibles. Étant devenu de facto le standard en matière d’indexation, le R*-tree s’est imposé comme index de comparaison. Pour ce dernier, le R*-tree, nous avons repris l'implémentation de [23]. Des données aléatoires ont été produites et séquentiellement attribuées à un nombre fixe de points spatiaux agissant en tant que sources d'informations. Des séries de tests ont été effectuées en changeant le nombre de données à indexer (de 1000 à 200000), le nombre de sources d'informations (10-100) employées et la partie de la base à balayer pour les requêtes d'intervalle. Les tests ont été effectués sur un ordinateur Athlon XP cadencé à 1,3 G Hz avec 256 Mo de RAM, sous Linux. Le langage de programmation utilisé était Java.

Le R*-tree ne différencie pas les dimensions spatiales et temporelles, et comme les requêtes de mises à jour doivent tenir compte de l'ensemble de données, le coût de construction pour un tel arbre peut mener à une situation où il devient impossible de répondre aux contraintes en temps réel. De son coté, le PoTree subdivise cet ensemble de données. Il emploie différents arbres temporels pour classer les données, selon les capteurs dont ils dépendent. La figure 26 montre les temps de construction pour les deux structures. Ces résultats ont été obtenus à partir de données simulées concernant 100 capteurs fixes. Il s'avère que le temps de construction de PoTree est bien inférieur car le nombre de points spatiaux est limité et les sous-arbres temporels doivent seulement accéder à la racine et aux derniers nœuds, excepté lorsque l'arbre B+ se restructure quand un nœud est rempli.



D'autres essais ont montré que la durée de construction du PoTree a augmenté logarithmiquement avec le nombre de stations, le nombre de localisations spatiales différentes. Le temps de mise à jour de l'arbre, hors ajout de nouveau capteur, étant alors égal au temps de parcours de l'arbre spatial ajouté au temps de mise à jour du dernier nœud de l'arbre temporel; et en cas de débordement de ce nœud de la mise à jour de cette partie de l'arbre (selon les techniques des B+-tree). En utilisant des requêtes de mise à jour, nous avons pu classer des données venant de 1200 sondes simulées (sismographes à 100 hertz), comme l'indique la figure 27.


Figure 27 : Influence du nombre de capteurs fixes sur le temps de création de l’arbre (indexation de une seconde de données à 100 Hz)

25 150275

400525

650775

9001050

12001350

15001650

1800

0

200

400

600

800

1000

1200

1400

1600

Temps d'indexationSeuil

Nombre de capteurs

Tem

ps (m

s)

Figure 26 : Évolution du temps de construction des structures en fonction du nombre de données à indexer.

1 5 9 13 18 23 28 33 38 43 48 53 58 63 68 73 78 83

0

500

10001500

2000

25003000

35004000

4500

50005500

6000

6500

PoTreeR*Tree

Nombre de données (x1000)

Tem

ps (s

)


Cette même figure permet d'apporter quelques calculs pratiques concernant l'écroulement des capacités de la structure. Dans un système réel, les ressources disponibles peuvent être fortement sollicitées, principalement lors de phases d'activités particulièrement importantes. De plus, différents services peuvent être en fonction sur le même serveur, chacun devant gérer sa propre liste de transaction possédant des contraintes temps réel ou non. Finalement, Il est à noter qu'un système complexe doit être à même de prendre en compte plusieurs types de requêtes concurrentes (mise à jour et accès aux données). De fait, les performances globales tendent à diminuer lorsque le nombre de transactions croît. Le phénomène d'étouffement a alors lieu, illustré dans la figure 28. Les différentes transactions qui demandent accès aux différentes ressources, doivent attendre la libération de certaines données, forcent l'abandon des verrous ou apposent leurs propres verrous sur certaines ressources. Ceci génère un important nombre d'instruction à traîter par le système déjà fortement chargé. Plus le nombre de transaction croît, et plus le nombre d'instructions à traiter croît, amenant à un étouffement progressif du système.

La figure 27 montre que le système est capable de gérer les mises à jours de près de 1200 capteurs (valeurs expérimentales) si les capacités mémoire du serveur sont suffisantes. De fait, ce nombre devrait être révisé à la baisse dans un système réel, afin de prendre en compte l'impact des différents services fonctionnant en parallèle sur le serveur, l'impact d'une zone mémoire limitée et afin de prendre en compte différents accès aux données concourants aux mises à jours.

D'autres requêtes ont montré des propriétés intéressantes. Les requêtes d'intervalle ont profité de l'enchaînement des nœuds temporels du PoTree. Pour des requêtes de point spatial / intervalle temporel, le PoTree peut être jusqu'à 8 fois plus rapide que le R*-tree. Pour des requêtes de fenêtre spatiale / intervalle temporel la différence s'est montrée moindre; elle demeure cependant toujours légèrement en faveur de notre solution, comme le montre la figure 29. Sur cette figure, les 10 derniers pourcents des données saisies furent cherchés; la fenêtre spatiale couvrant l'ensemble de l'espace. Pour un faible nombre de données le R*-tree offre de meilleures performances, pourtant quand la quantité de données dépasse 6000, c'est le PoTree qui se montre le plus rapide. Ces résultats peuvent être expliqués par le fait que les R*-tree doivent considérer l'ensemble des données afin d'exécuter une


Figure 28: Exemple de courbe d'étouffement du système

0 10 20 30 40 50 60 70 80 90 100

0

10

20

30

40

50

60

70

80

90

100

Taux de charge du système

Taux

de

réus

site

des

tran

sact

ions


requête. Par conséquent, plus il existe de données, plus les requêtes sont lentes. Il est cependant à noter que le PoTree vise en premier lieu à valoriser les mises à jours, ainsi les performances de l'accès aux données ont été reléguées à un plan secondaire.

Un deuxième ensemble de tests a été effectué, en utilisant des données venant des sismographes du K-Net, institut de recherche en science de la terre et pour la prévention de désastre (K-Net, 2005). Les données ont été indexées par le PoTree avec des résultats semblables aux autres obtenus avec des données aléatoires.

4.2.5 Résumé sur le PoTreeLe Potree est un index pour bases de données spatio-temporelles en mémoire vive lié à un réseau de capteurs temps-réel fixes. Il permet en outre de valoriser les données les plus récentes et les transactions de mises à jours.

Cette structure regroupe les données issues d'un capteur particulier au sein d'une sous-structure temporelle qui lui est dédiée. Les différentes sous-structures temporelles sont à leur tour reliées via un arbre spatial.

Les sous-arbres temporels, arbres de capteurs, sont assimilables à des B+tree auxquels ont été ajoutés un lien direct entre la racine et le dernier nœud de la structure, dans le but avoué d'accélérer l'accès aux données les plus récentes, contenues dans ce dernier nœud. Ils indexent les dates liées aux mesures. L'arbre spatial est basé sur un kd-tree et indexe les positions des capteurs.

Le regroupement des données en fonction du capteur d'origine permet de limiter la zone de recherche lors de la résolution de requêtes et d'utiliser la localité séquentielle des données (les requêtes concernent généralement les données collectées durant certains intervalles temporels). Le PoTree offre des performances d'accès aux données et de mise à jour qui lui permettent de se comparer favorablement avec d'autres structures.


Figure 29 : Temps de résolution d’une requête de Fenêtre spatiale / Intervalle temporel en fonction du nombre de données présentes dans la base (68 capteurs)

1 5 9 14 19 24 29 34 39 44 49 54 59 64 69 74 79 84

0255075

100125150175200225250275300325350

PoTreeR*Tree

Nombre de données (x1000)

Tem

ps (m

s)


4.3 Conclusion sur l'indexation spatio-temporelle de données issues d'un réseau de capteurs fixes

Pour clore ce chapitre, il est possible de noter l'importance historique de la recherche spatiale dans le domaine du spatio-temporel.

Les réseaux historiques de surveillance de phénomènes utilisent des capteurs fixes. Fors de ce constat les systèmes utilisant les données collectées ont été bâtis autour de l'utilisation des identifiants des capteurs. L'apport des outils de géolocalisation a permis d'apporter de nouvelles possibilités de requêtage. Les outils existants étant peu adaptés à une gestion fine de ces caractéristiques, la recherche dans le domaine spatio-temporel a ainsi pu élargir son champ d'action. Les bases de données utilisées dans ces systèmes de surveillance doivent désormais être en mesure de répondre aux requêtes spatio-temporelles des utilisateurs.

Du fait de la masse de données à indexer, la base de données centralisée chargée de répondre aux requêtes sur le court terme doit être maintenue en mémoire vive. Elle doit également permettre des mises à jours rapides et valoriser l'accès aux données les plus récentes.

Les solutions d'indexation spatio-temporelles classiques se divisent en différentes familles. Une première division permet de différencier les index représentant la dimension temporelle comme étant indépendante des dimensions spatiales et les index n'offrant pas une telle différenciation. Une autre division permet de différencier les index optimisés pour la gestion de points et ceux optimisés pour la gestion d'objets aux formes plus complexes.

Les index les plus répandus dans les bases de données existante sont le R-Tree et ses dérivés les plus directs. Ils utilisent une hiérarchisation de rectangles d'encombrement minimaux pour hiérarchiser l'espace considéré. Alors que ces index offrent de vastes possibilités d'indexation, ils souffrent de difficultés de mise à jour. Les requêtes doivent prendre en considération l'ensemble des données collectées.

Le PoTree est une solution d'indexation basée sur le regroupement des données issues d'un même capteur au sein de sous-structures dédiées. Il différencie ainsi les dimensions spatiales et temporelles. Cet arbre offre des performances supérieures à celles du R*Tree dès lors qu'il s'agit d'indexer les données issues d'un réseau de capteurs fixes dans une base de données en mémoire vive.

Cependant, la principale limitation du PoTree vient de l'a priori imposé par sa structure. Les capteurs sont ici supposés fixes. Les développements technologiques permettent à présent d'utiliser des capteurs pouvant être déplacés. De plus, cette structure ne permet qu'une indexation spatio-temporelle. Or, des années



d'utilisations des anciens systèmes basés sur les identifiants de capteurs ont profondément marqué les modes d'utilisation des réseaux de surveillance.

Un système de surveillance pourra exploiter au mieux le PoTree dans le cas de l'utilisation de capteurs fixes. Cependant, si l'agilité des capteurs ou la volonté d'utiliser conjointement les identifiants de capteur pour l'accès aux données se font ressentir, de nouvelles solutions d'indexation doivent être considérées.




De cape et de crocs - L'archipel du danger - © Delcourt

Indexation spatio-temporelle de données issues d'un réseau de capteurs agiles

5 Indexation spatio-temporelle de données issues d'un réseau de capteurs agiles

Le PoTree offre une solution d'indexation pour base de données spatio-temporelles centralisée. Cependant, il suppose l'utilisation de données issues de capteurs ponctuels fixes. Ces capteurs constituent encore à l'heure actuelle l'immense majorité des capteurs utilisés dans le cadre de systèmes de surveillance de phénomènes naturels aussi bien qu'urbains.

Les améliorations apportées aux technologies réseaux et à l'électronique ont permis d'accroître le potentiel d'utilisation des capteurs, et en premier lieu, d'accroître leur agilité et leur mobilité. Le terme d'agilité suppose que les capteurs peuvent être déplacés entre deux séquences de prises de mesures. Le terme de mobilité lui sera préféré lorsque le déplacement du capteur est continu entre les mesures et devient la règle et non pas l'exception.

Une analogie permet de différencier agilité et mobilité. Les capteurs les plus anciens sont fixes. Installés à l'emplacement où ils doivent effectuer des mesures, ils n'en bougeront pas. Le cas du capteur agile peut être représenté par un capteur pouvant être transporté dans une valise. Ce capteur est installé, prend des séries de mesures pendant quelques jours ou quelques semaines puis est démonté, déplacé, et remonté. Le capteur mobile est constamment en mouvement. Il peut s'agir d'un flotteur sur une rivière qui prend des relevés de sa position. Dans ce dernier cas, la position est souvent aussi sinon plus importante que la mesure effectuée.

Les réseaux de surveillance de phénomènes utilisent de plus en plus régulièrement des capteurs agiles, installés un jour puis démontés quelques temps plus tard. Ils permettent d'ajouter des relevés spécifiques à certaines zones spatiales, d'affiner les résultats obtenus par l'intermédiaire de capteurs fixes, de palier les pannes de capteurs,...

Dans un tel contexte d'utilisation, le PoTree n'offre pas une solution viable. Il convient par conséquent d'étudier les index spatio-temporels prenant en charge l'agilité et éventuellement la mobilité des capteurs.



5.1 Agilité, mobilité et index spatio-temporel

Pouvoir retrouver des données selon leurs positions géographiques et une date ou un intervalle temporel précis représente un pas intéressant qui a été franchi depuis déjà quelques années. Tout naturellement, avec le développement des réseaux sans-fils, de nouvelles possibilités ont donné naissance à de nouveaux besoins. De fait, l'indexation d'objets agiles et mobiles mérite une étude plus approfondie.

5.1.1 Concepts

Un premier constat peut être formulé : plusieurs grandes familles d'index peuvent être énumérées. Une première réunit les différents index qui visent à travailler sur des flottes de capteurs, pour lesquels le terme de mobilité fait référence à la mobilité liée aux capteurs. Il est à noter que l'information sauvegardée ne provient pas des mouvements intrinsèques des capteurs mais des données que ceux-ci mesurent lors de leurs déplacements. Un anémomètre placé sur un navire fournira des données sur la vitesse des vents à différentes positions. Ces relevés ne sont pas destinés à suivre le navire en lui-même.

Un autre type de mobilité considère les trajectoires des objets comme étant l'information de prime importance. Les exemples les plus typiques seraient liés à la gestion de flotte de véhicules, ou encore aux services basés sur la localisation des utilisateurs. Les systèmes de localisation de véhicules volés par GPS rentrent dans cette catégorie.

La représentation des données diffère en fonction de l'intérêt porté au changement de positions. Bien qu'intrinsèquement spatio-temporelle, la mobilité se traduira de manières différentes. Ainsi, dans le cas des trajectoires (donnant naissances aux Mobile Objects Database, MOD), un identifiant de trajectoire est généralement utilisé afin de suivre le déplacement d'un objet de bout en bout. Les approches qui dans ce cas se fondent sur la division de l'espace en sous-espaces doivent alors conserver cet identifiant de trajectoire et la manière dont elle traverse le sous-espace.

Un point important à remarquer : il n'est pas possible d'enregistrer en continu les mouvements des objets dans une base de données. Des techniques d'échantillonnage (à des moments déterminés, ou lorsqu'un objet passe par certaines limites spatiales) sont utilisées, couplées à des méthodes d'interpolation pour obtenir les valeurs entre deux échantillonnages.

Lorsqu'un objet (capteur, véhicule,...) crée un fichier batch contenant un certain nombre de mises à jour spatiales qui devront être reportées dans une base de données, trois facteurs rentrent en compte :



● la taille du fichier,

● l'intervalle de mise à jour,

● le nombre de mises à jour à effectuer.

Si un des seuils établis pour ces facteurs est dépassé, une mise à jour doit avoir lieu. Les systèmes qui ne prennent pas en compte tous ces aspects peuvent, selon les circonstances (nombre de mises à jour, rapidité,...) subir des imprécisions sur la position des objets ou des performances détériorées. Plus les mises à jour sont fréquentes, et plus le besoin de communication entre l'objet / capteur et la base transparaît. De même, la taille de l'en-tête de mise à jour croît en conséquence. Plus les mises à jours sont rares et plus les imprécisions quant aux positions réelles des objets augmentent. Il est nécessaire de trouver le bon équilibre, qui dépend de la quantité de mises à jour et de la qualité de celles-ci.

D'autres études proposent d'agréger certaines données spatiales afin de limiter le nombre d'entrées à effectuer. Ceci a été suggéré pour les index utilisant les trajectoires et les divisions de l'espace. Les mises à jour au sein d'une même sous-division de l'espace originel sont moins importantes que les mises à jour concernant le passage d'un sous-espace à un autre (franchissement de frontières) [3]. A noter cependant l'exception des surpressions de données, qui doivent être répercutées sans délai pour signifier la disparition d'un objet...

Une autre distinction dans la mobilité est liée à l'existence de trois familles de bases de données spatio-temporelles [46]. La première conserve les traces d'évènements passés. Il n'est alors pas question d'interroger les évènements présents. La seconde famille indexe jusqu'à l'instant présent. Cependant, du fait des particularités de cet instant, il n'est dans ce cas pas possible d'obtenir de résultats sur celui-ci (« l'image que me renvoie le miroir n'est que mon passé »). La dernière famille prend en compte les méthodes prédictives et les méthodes permettant de travailler sur l'instant présent et sur des estimations futures.

5.1.2 Indexer le passé

Pour ce qui est de l'indexation avec les données passées, il est possible de diviser les approches en différentes familles. En premier lieu, certains index valorisent l'aspect spatial, reléguant l'aspect temporel au second plan. D'autres arbres utilisent des techniques d'overlap5 et de multiversion6. Cette dernière approche suppose d'importantes capacités de stockage.

5Overlap : A chaque instant T donné correspond un arbre d'indexation spatial. Les branches qui n'ont pas changé entre Tn et Tn+1 sont alors partagées pour réduire l'espace nécessaire.

6multiversion : un arbre d'indexation spatial conserve les données ainsi que les intervalles de validité de celles-ci.



3DR-Tree [78]

Cette structure a déjà été décrite dans le chapitre précédent. Le temps et la clef spatiale forment un point dans un espace en 3D. Le temps est considéré comme une dimension spatiale supplémentaire. Cette méthode n’est pas optimale pour indexer les objets en mouvement (création de rectangles englobants trop grands dans les approches continues, perte d’information dans les approches discrètes).

HR-Tree, MR-Tree [49]

Cette structure a également été décrite dans le chapitre précédent sur les index spatio-temporels. Cet index, issu des techniques d'overlapping est supérieur au 3DR-Tree pour les recherches de timestamp et les petits intervalles.

HR+Tree [74]

Basé sur le HR-Tree, il permet à plusieurs versions d’une même donnée d'être présentes dans un nœud. Les temps de début et de fin de validité d'un enregistrement sont ainsi conservés. Ceci a pour but d'améliorer les performances de l'index en matière d'intervalles. Il n’y a de création d'un nouveau nœud que si l’ancien n’a plus assez d’espace pour de nouvelles données. Cet index supporte la condition de version faible. Celle-ci suppose que si trop peu de transactions sont vivantes (actives, la date de fin de validité n'étant pas encore enregistrée) dans un nœud, ce dernier est divisé.

Cette politique induit une plus faible utilisation d'espace de stockage que pour un HR-Tree, avec des résultats comparables pour ce qui est des requêtes sur des timestamp (dates), et supérieurs pour les intervalles. Les résultats sont d’autant meilleurs que la taille de la mémoire tampon est importante. Le HR+Tree peut être utilisée en ligne, pour indexer des données jusqu'à l'instant présent.

MV3R-Tree [75]

Cet index est issu de multiversion de B-Tree et de 3DR-Tree. Il a également été décrit précédemment. Il a été conçu pour répondre à des requêtes de timestamp et d'intervalle, et pour récupérer les localisations ‘passées’ d’objets en mouvement.



Multiversion Linear Quadtree (MVLQ) [81]

Cette technique a été mise au point pour l’indexation de données photographiques. D’un point de vue temporel, elle travaille sur le temps de transaction. Cette technique est issue des MV B-Tree et des Linear Region Quadtree (cf. figure 30).

Des codewords sont conservés dans un MV B-Tree. Un Linear Quadtree est ainsi transformé en structure persistante. Des intervalles de temps sont couplés avec des objets spatiaux dans chaque nœud. Les nœuds feuilles comportent les positions et niveaux dans le Quadtree (profondeur dans l'arborescence), ainsi qu'une date (début de validité de l'enregistrement).

Dans tous ces nœuds, les différents Td (instants de création de l'enregistrement) sont conservés. Dans les nœuds feuille, Tf (instant de fin de validité de l'enregistrement) est ajouté.

Les MVLQ gèrent les requêtes classiques pour les MVBT et les Quadtree : jointures spatiales, recherche de voisins, de similarité, sélection spatiale,… La principale limite de cette structure est liée aux accès disques qu’implique cette technique.

Partially persistent R Tree (PPR) [35]

Ce type d’arbre, originellement créé pour des applications bitemporelles, conserve l’évolution des données d'un R-Tree (2D, 3D). C’est en cela qu’il devient partiellement persistant. Pour cela, il ne conserve pas les instances, mais l’évolution du R-Tree, et ce de manière linéaire afin accélérer les recherches.

Il peut posséder plusieurs racines, responsables de l’enregistrement des évolutions des parties consécutives du R-Tree originel. Les différentes racines sont accessibles via un tableau root*, dont chaque entrée contient un intervalle temporel et un pointeur vers une racine de R-Tree.

Chaque nœud possède un Td, Tf. Chaque nœud est considéré comme « en vie » s’il n’a pas été divisé au préalable. Hormis la racine, tout nœud en vie doit avoir au moins m enregistrements actifs. Le PPR-Tree supporte la condition de version faible, et les overflow (dépassement de capacités du nœud). Les nœuds de l’index conservent les intervalles de validité des objets. Un nœud peut être accessible par plusieurs racines.


Figure 30 : Image d'origine, Quadtree et enregistrement multiversion [81]


Scalable and Efficient Trajectory Index (SETI) [14]

Le but est ici l'indexation de trajectoires. De plus, le SETI gère les insertions rapides et les requêtes spatio-temporelles sur des fenêtres et des dates dans de grandes bases de données. Pour cela, une partition statique de l'espace est utilisée et les identifiants des trajectoires dans chacune de ces zones sont indexés.

SETI divise l'espace en zones, appelées cellules, qui ne se recoupent pas. Une cellule contient les segments des trajectoires qui sont complètement inclus dedans. Si un segment dépasse les frontières d'une zone, il est coupé et inséré dans les deux cellules concomitantes.

Des tests ont permis de montrer que cet arbre était bien plus rapide que le 3DR-Tree, tant pour la création que pour des requêtes classiques. Cependant le mode de gestion des cellules peut engendrer des duplicata des données.

Start/End timestamp B-tree (SEB) [72]

Cet arbre est relativement similaire au SETI. L'espace est partitionné en zones qui peuvent se recouper. Chaque zone est indexée en utilisant un SEB-Tree (cf. figure 31). Celui-ci prend en compte les Td et Tf des objets en mouvement. Ceci permet de les transposer dans une surface 2D, avec en abscisse Td et en ordonnée Tf (l'espace « utile » est donc triangulaire). Quand le seuil de contenance d'un nœud est atteint, cet espace 2D est partitionné d'un trait vertical au niveau du point le plus récent (Td le plus grand, donc le plus à droite) et d'un trait horizontal au niveau du point ayant le Tf le plus important (donc le plus en haut).

Les recherches s'effectuent par la suite en définissant des partitions de recherches sur notre espace 2D. Les nœuds complètement dans la zone sont reportés tels quels, les nœuds à cheval sont examinés plus attentivement.

Des tests ont montré que cet arbre était plus rapide que les R-tree à hauteur de 30% [72]. Une fois de plus, cette structure est plus indiquée pour la gestion des mouvements que de mesures collectées.


Figure 31 : Construction du SEB-Tree [72]


2+3 R-tree [50]

Deux structures sont ici utilisées : une pour indexer les données les plus récentes, et l'autre pour les données les plus anciennes. Cet index est utilisé pour des données dans un espace 2D.

Le premier arbre, un 2D R-tree spatial est utilisé pour les mises à jour les plus récentes. Le second est utilisé pour conserver l'historique, avec l'ajout de la dimension temporelle.

Lorsqu'un objet est mis à jour, la trajectoire de celui-ci est construite en 3D et est insérée dans le 3D R-tree tandis que l'ancien enregistrement est supprimé du 2D R-tree. Ceci entraîne la création de grands MBRs presque vides lorsque les déplacements sont importants. De plus, lors des recherches, selon les marqueurs temporels accédés, il peut être nécessaire de parcourir les deux arbres...

5.1.3 Indexer la position couranteDans les approches précédentes, la connaissance a priori des positions des objets était supposée. La présente partie traite de l'indexation de données au temps présent. Les différentes approches proposées n'offrent que peu d'intérêt pour la conservation d'historiques de mesures. Cependant, elles mettent en oeuvre des techniques qui peuvent être réutilisées, telles la gestion de zones.

Lazy Update R-tree (LUR) [36]

Dans ce cas, seule compte la position actuelle des objets. Aucun historique des données n'est conservé, ce qui limite de facto son utilité pour la conservation d'historiques de mesures. La structure du LUR-tree se base sur celle du R-tree. Un des buts visés par cette structure est de limiter la perte de performance des R-tree du fait de la conservation de données passées.

Tant que la mise à jour d'un objet concerne des positions localisées dans le même MBR, l'algorithme se contente de mettre à jour les données. Lorsqu'il y a changement de MBR, deux possibilités existent. L'ancien objet peut être éliminé et ré-introduit à la nouvelle position, ce qui cause des splits / merges. Il est aussi possible de se contenter d'augmenter la taille de ce dernier si la nouvelle position se trouve suffisamment près de l'ancien MBR.

Hashing

Dans ce type d'approche, qui ne vise qu'à conserver les données les plus récentes, l'espace est divisé en zones qui peuvent se recouper. Un objet ne force pas une mise pas à jour de sa position tant qu'il reste dans la même zone. Pour résoudre les problèmes d'incertitudes sur sa position précise qui en résulte, une couche de filtre est introduite. Cette couche contient précisément les positions réelles des objets.



Une requête est représentée sous la forme d'une partition. Toutes les zones qui sont complètement englobées dans la partition sont renvoyées en résultat. Pour celles qui intersectent la partition, la couche de filtre est consultée pour trouver les points constitutifs du jeu de données résultat. Cette technique n'est pas sans rappeler le fonctionnement du SEB-tree.

5.1.4 Indexer les positions courante et futuresAlors que la partie précédente concernait des méthodes permettant d'indexer les données jusqu'à l'instant présent, cette nouvelle partie s'intéresse aux méthodes proposant d'indexer les positions futures, voire courantes. Des estimations sur les positions futures peuvent être générées par des interpolations. Plusieurs approches co-existent.

L'espace spatio-temporel d'origine peut être mis à contribution pour l'indexation. Avec l'équation x=a∗tb , avec x la position et t le temps, le principe consiste alors à indexer des segments dans un espace. La principale source de problèmes découle de la taille des MBRs ou autres partitions de mouvement. Elles sont généralement trop grandes et presque vides. De même tous les segments actifs partagent la même date de fin de validité. Cette constatation a entre autre donné naissances à des index tels le SEB-tree évoqué précédemment [72].

Une autre approche, basée sur les transformations d'espace vise à transformer le domaine espace-temps en un autre espace plus facile à représenter. Ce type de méthodes présente certaines limites. Toutes les données de l'espace original ne sont pas conservées. Des objets qui sont proches dans la réalité ne le sont pas nécessairement dans cet espace. Il faut utiliser des algorithmes parfois complexes pour transformer les zones de requêtes en polygones de recherches.

Une dernière famille d'arbre propose d'indexer l'espace d'origine en utilisant des rectangles paramétriques. Au cours de leur évolution, les objets restent ainsi dans les même rectangles...

PMR Quadtree pour objets mobiles [77]

Le PMR Quadtree vise l'obtention d'une structure permettant de déterminer la position future d'un objet. L'équation x=a∗tb permet de transformer les positions futures estimées en des séries de lignes. Les techniques spatiales classiques peuvent dès lors être utilisées.

A chaque mise à jour, l'index est reconstruit. Pour limiter le surcoût occasionné, un ∆T (variation de temps) entre deux mises à jour est fixé. La dimension temporelle est donc partitionnée en des intervalles de durée ∆T. Pour chaque intervalle, un nouveau PMR est construit. Du fait de la limitation de l'espace disponible, seul le plus récent d'entre eux est conservé en mémoire.



Cette technique induit le risque d'obtenir une structure comportant de nombreux espaces vides. De même, les trajectoires des objets ne sont pas très précises car elles partagent la même date de fin de validité...

Time Parametrized R-Tree (TPR) [65]

Le TPR-Tree (cf. figure 32), de plus en plus répandu dans les milieux scientifiques, référence les objets en mouvements. Il permet de répondre à des requêtes d'intervalle temporels pour estimer la position future d'un objet.

Pour cela, la position de l'objet ainsi que les vecteurs de vitesse sont enregistrés via un MBR. Il devient ainsi possible de déterminer la croissance d'un MBR, en considérant les vitesses d'évolution. Chaque MBR (appelé ici Conservative BR) possède une borne supérieure évoluant au rythme du maximum de la vitesse des objets internes, et une borne inférieure égale à la vitesse minimale. De ce fait, les CBR ne peuvent que s'accroître.

La structure de cet arbre reste difficile à implémenter. De plus il n'est pas aisé de mettre à jour cet arbre, puisqu'il faut d'abord supprimer une référence avant de la recréer. Ceci limite fortement les performances du TPR-Tree lorsque le nombre d'objets croît.

5.1.5 Synthèse et critique des index disponiblesLes différentes solutions d'indexation disponibles permettent de prendre en charge différents niveaux de mobilité. Les différents index existants peuvent en outre être divisés selon le types de données à indexer : données passées, présentes ou futures. Le tableau 5 offre un récapitulatif de différents index existants.

L'héritage du R-Tree est sensible. Le R-Tree permet en effet de représenter des objets complexes par le biais de rectangles englobants. Un grand nombre de structures assimilent la dimension temporelle à une dimension spatiale pour assurer une conservation de données de mouvement.

La gestion de l'agilité reste marginale. En effet, le principal effort des travaux de recherches existants a porté sur la gestion de la mobilité et des trajectoires. L'héritage de l'indexation d'objets statiques s'est ainsi vu complété de nouvelles


Figure 32 : TPR-Tree [65]


solutions permettant de prendre en compte les spécificités de la gestion de la mobilité. Le cas intermédiaire de l'agilité, rencontré dans le domaine de la surveillance par capteurs reste peu exploré.

Nom TypeValorisation des mises à

jours

Gestion de l'aspect

temps-réel

Conservation de

l'historique des valeurs passées en mémoire

Mise à jour en ligne

3DR-Tree passé non non oui ---

HR-Tree passé non non oui -

MV3R-Tree passé non non oui --

MVLQ passé non non oui -

PPR-Tree passé non non oui -

SETIpassé

trajectoiresnon non oui +

SEB-Treepassé


2+3 R-Treepassé


LUR-Tree présent non non non +

PMR Quadfutur

trajectoiresnon non non +

TPR-Treefutur

trajectoiresnon non non +

Tableau 5: Récapitulatif des index couvrant l'agilité ou la mobilité

En tout état de cause, seules quelques structures permettent d'accéder aux données via différents types de critères, tel le MV3R-Tree. Aucune ne permet cependant un véritable accès multicritère prenant en compte aussi bien des aspects spatio-temporels que les identifiants de capteurs.

Il convient donc d'apporter une solution permettant de prendre en compte la gestion de l'agilité des capteurs d'un réseau de surveillance, ainsi que la nécessité d'assurer une certaine compatibilité avec des modes d'interrogation basés sur des identifiants.



5.2 Le PasTree

Le PasTree est un système d'indexation pour bases de données spatio-temporelles centralisées en mémoire vive, travaillant sur des données issues d'un réseau de capteurs agiles [53] [54]. Cet index offre en outre un accès multidimensionnel aux données : à la fois spatio-temporel mais également basé sur les identifiants de capteurs.

5.2.1 Contexte d'utilisationLe PoTree a mis en avant les besoins liés à l'utilisation d'une système d'indexation pour bases de données liées à un système de surveillance de phénomènes naturels ou urbains. Alors que les systèmes les plus anciens se contentaient d'utiliser des capteurs volumineux et fixes, les développements des technologies électroniques et informatiques ont permis l'utilisation de capteurs agiles, pouvant être déplacés en des lieux particuliers pour y effectuer des mesures. Par là-même les spécificités des systèmes de surveillance ont évolué de concert. A contrario, des années d'utilisation de processus basés sur des identifiants de capteurs ont laissé un important passif, de nombreuses habitudes liées directement à cette politique d'accès aux données. Ainsi, un système d'indexation pour base de données liée à une telle architecture doit prendre en considération ces nouvelles spécificités :

● Utilisation d'aspects spatio-temporels ou d'identificateurs pour les requêtes / mises à jours




● Fonctionnement en mémoire vive


● Conservation de la trace des anciennes positions prises par les capteurs

● Requêtes variées : critères spatiaux ou identifiants pour désigner un capteur ou une zone et intervalle ou instant pour l'aspect temporel



5.2.1.1 Des nouveautés, mais également des points communs avec le

PoTree

Les technologies liées aux réseaux de capteurs sont en évolution constante. Les avancées dans le domaine de la communication réseau ont permis l'envoi massif et fréquent de données. La miniaturisation des capteurs a permis une généralisation de leur emploi, y compris dans des applications qui sortent désormais du cadre de la recherche scientifique. Une voiture sortie d'usine au début du vingt-et-unième siècle comporte plus de capteurs et d'informatique embarquée que les engins utilisés lors des missions lunaires Apollo. L'amélioration des techniques de génération et de stockage d'énergie (cellules photovoltaiques, piles,...) liée à la recherche sur les technologies sans-fil ont également permis le déploiement de réseaux dans des milieux difficilement atteignables au début des années quatre-vingt. Et avec l'évolution de ces techniques sont apparues de nouveaux concepts.

Bien que ces améliorations aient permis le franchissement d'étapes importantes vers une informatique ambiante, les conditions d'utilisation des réseaux de capteurs limitent toujours l'utilisation de systèmes de stockage des données répartis au sein même des capteurs. En effet, les gains d'autonomie des capteurs (temps de fonctionnement, amélioration des capacités mémoire et de calcul) ne permettent cependant pas d'annuler les risques de pannes liés aux conditions naturelles. Par conséquent les systèmes de surveillance actuels restent basés sur une architecture centrée autour de files, de bases de données en mémoire vive (données à court terme) et d'entrepôts de données (long terme). Ces bases et ces entrepôts nécessitent l'utilisation d'index spécifiques.

Les systèmes de surveillance restent basés sur l'analyse de mesures collectées à court aussi bien qu'à long terme. Alors que les analyses à long terme utilisent principalement les ressources des entrepôts de données, les analyses à court terme prennent principalement en compte les mesures de bases de données en mémoire vive. Cependant ces analyses peuvent elles-même générer des données. Ainsi, dans le cadre du volcanisme, des processus particuliers sont chargés de déterminer la position d'épicentres de séismes. Ces processus génèrent des informations qui peuvent alors être considérées comme issues de capteurs agiles, voire dans certains cas, comme celui des épicentres, mobiles. Ces données peuvent être conservées dans la base, puisqu'elles peuvent à leur tour être réutilisées par d'autres processus d'analyse.

Les systèmes de surveillance de phénomènes utilisent des bases de données en mémoire vive pour les données les plus récentes. Les accès aux données, les mises à jour nécessitent des temps de réponses courts, le plus souvent contraints par des limites temporelles. Ainsi réapparaît la notion de temps-réel. Les progrès techniques ont permis de faciliter la résolution des tâches passées, grâce à des améliorations des architectures de communication au sein du systèmes. Le même constat peut être émis quant aux améliorations des capacités de traitement et de conservation en mémoire. Cependant, les besoins des utilisateurs restent soumis à des impératifs temporels et par conséquent restent temps-réel. L'utilisation d'une base de donnée en mémoire vive permet donc de limiter le coût d'accès aux données et aide au respect de ces contraintes.



De même, les données les plus récentes sont considérées comme prioritaires. Les accès aux données tirent profit des nouvelles possibilités offertes mais l'accès reste centrés sur les données les plus récentes. La raison d'être de ces systèmes reste la surveillance de phénomènes. Dans cette optique, les spécialistes s'évertuent à déterminer l'état actuel du système observé, et pour cela requièrent un accès aux mesures les plus récentes.

5.2.1.2 L'agilité des capteurs

Les réseaux de surveillance de phénomènes emploient de plus en plus régulièrement des capteurs agiles. En effet, avec la réduction d'encombrement et de poids des capteurs il devient possible d'envisager un déplacement périodique de certains capteurs. Un tel déplacement permet de suivre l'évolution de phénomènes selon des points d'observations optimums. L'image du scientifique sortant d'une valise un ensemble d'appareils de mesures et les connectant pour quelques heures prend alors tout son sens. Dans un contexte plus urbain, des balises de mesure du trafic, mobiles, peuvent remplir une fonction analogue si elles sont équipées d'un système de transmission des mesures prises. Le besoin de mesurer en temps-réel l'impact d'une manifestation particulière se fait jour afin de pouvoir mettre en oeuvre les moyens de régulation du trafic. L'utilisation de balises agiles couplées au système de surveillance se justifie. Les réseaux de surveillance utilisent désormais des capteurs pouvant être déplacés pour des observations sur des durées plus ou moins brèves. Il convient donc d'adapter le système de surveillance afin de prendre en compte cette agilité des capteurs.

L'agilité des capteurs entraîne un besoin de conservation des positions passées occupées par les capteurs et les intervalles temporels de validité associés. En effet, les mesures collectées doivent être mises en rapport avec la position du capteur au moment de la prise de mesure. Par conséquent le système de stockage de données doit conserver une trace de l'évolution de la position de ces capteurs. Cependant, il convient de rappeler le caractère prioritaire de la donnée elle-même et de la rareté des changements de positions des capteurs.

5.2.1.3 Accès aux données

Du fait de l'ajout de la notion d'agilité, et du fait du passif d'utilisation des systèmes de surveillance, les utilisateurs peuvent demander l'accès aux données selon des critères spatiaux mais aussi selon les identifiants de capteurs. Depuis la naissance des systèmes de surveillance, les utilisateurs ont pris l'habitude d'utiliser des tables de conversions identifiant / position afin de générer leurs requêtes d'accès aux données collectées. Le développement des systèmes d'information géographiques et la re-découverte de l'importance des aspects spatiaux ne peuvent effacer des décennies d'expériences. Ainsi, alors que de plus en plus de processus automatisés utilisent les coordonnées spatiales des capteurs pour accéder aux données, des processus plus anciens continuent d'utiliser les identifiants de capteurs. De même, certains utilisateurs de longue date ont pris pour habitude de se référencer par



rapport aux identifiants de capteurs. L'utilisation de critères purement spatiaux constituerait un changement majeur dans leur appropriation du système.

L'ajout de la notion d'agilité permet l'adoption de nouvelles requêtes. En effet, les capteurs peuvent être amenés à changer de position. Par conséquent les utilisateurs peuvent désormais tirer parti de ces changements dans leurs requêtes. Alors que la mobilité des capteurs reste hors de contexte, la gestion de l'agilité offre de nouvelles possibilités. Ainsi l'utilisateur se voit offrir un panel de requêtes hybrides entre les requêtes classiques associées aux capteurs fixes et aux requêtes sur la mobilité. Les requêtes basées sur la recherche de voisins le plus proches deviennent ainsi plus communes, afin entre autre de déterminer le capteur le plus proche d'un point ou d'un autre capteur. Une autre possibilité consiste à récolter les mesures fournies par un capteur en un point spatial pendant la période pendant laquelle il s'y trouvait. Il également possible de requérir des informations quant à la durée de présence d'un capteur en ce même point.

L'adoption d'une approche duale spatio-temporelle / identifiant de capteurs permet à son tour l'utilisation de nouvelles requêtes. Ainsi devient-il possible de se référer à l'identifiant afin d'obtenir des données relatives à la position spatiale d'un capteur. Il est également possible de se baser sur cette même position pour déterminer l'identifiant du capteur. Dans les cas de forte agilité, où la distinction entre agilité et mobilité se montre plus ténue, les possibilités d'accès aux données via ce double référencement accroissent les modes d'utilisation disponibles.

En somme, alors que le PoTree visait à indexer les données issues d'un réseau de capteurs fixes, le PasTree vise un domaine quelque peu différent. L'ajout de la notion d'agilité ainsi que l'adoption d'une approche multicritères (spatiaux / identifiants) offrent de nouvelles possibilités d'accès aux données. Elles nécessitent une gestion des changements de position des capteurs. Les impératifs liés aux systèmes de surveillance restent d'actualité, ainsi la gestion des données les plus récentes ou encore la priorité des mises à jours sur les autres types de requêtes figurent-elles parmi les critères de définition de l'architecture du système d'indexation. Le PasTree est une solution offrant des réponses à ces impératifs.

5.2.2 La structure du PasTreeLe PasTree hérite du PoTree plusieurs de ses concepts clefs. Ainsi conserve-t-il une approche combinant plusieurs sous-arbres. Le sous-arbre de capteur est repris dans ses grandes lignes. Les mesures collectées par un même capteur sont conservées au sein d'une même sous-structure afin de limiter la zone de donnée concernées par la résolution d'une requête. De même, cette approche permet une évolution vers une architecture d'index distribué, où certains nœuds sont en charge des données de certains capteurs. Parallèlement à ces sous-structures de capteurs il convient d'utiliser des sous-arbres permettant de déterminer l'ensemble des capteurs concernés par des requêtes particulières. Dès lors, les caractéristiques induites par la gestion de l'agilité et par un accès multicritères apparaissent, entraînant certaines différences entre PoTree et PasTree (cf. figure 33).



Lors de l'introduction du PoTree, une analogie avec un jardin botanique avait permis de comparer le fonctionnement de la structure avec un exemple facilement assimilable. Dans le cas du PasTree, notre jardin botanique s'est doté de nouveaux panneaux indicateurs. A l'entrée du jardin, les visiteurs peuvent consulter un plan sur une borne informatisée. Sur cette borne se trouvent des plans du jardin en plusieurs langues (français, champenois, lyonnais d'Ainay, mais aussi des langues plus exotiques comme l'anglais par exemple). Sur cette borne se trouve également un index alphabétique des noms des arbres du jardin. Le visiteur peut alors demander à voir la carte des lieux ou peut demander le chemin pour aller voir une essence particulière. Lorsqu'il visite le jardin, il peut remarquer qu'à coté de chaque arbre se trouve un panneau explicatif qui, en plus du nom de l'arbre et d'un rappel sur la position du végétal renseigne sur les anciennes positions occupées par l'arbre dans le jardin (le jardinier ayant l'habitude de déplacer certains de ses arbres de temps à autre).

On remarquera que le jardin botanique « PasTree » a été construit en suivant le modèle de base de celui du « PoTree. » Cependant le concepteur a également été influencé par les spécificités induites par un jardinier aimant jouer de la pelle et par une clientèle plus exigeante sur les possibilités d'accès aux arbres. Il lui a donc été nécessaire de modifier les détails du PoTree.

5.2.2.1 Les principales modifications

Le PoTree est conçu pour des systèmes de surveillance basés sur des capteurs fixes et un accès purement spatial. Le PasTree ajoute la notion d'agilité des capteurs (mobilité restreinte), et l'accès multicritères aux données (par des critères spatiaux


Figure 33 : Structure globale du PasTree

NOSOSENE NOSOSENE 'C''B''A' ...

T3T2T1 T4

Arbre Multiversion Arbre d'Identifiants

Arbre Capteur 'B'

T3'T2'T1' T4'

Arbre Capteur 'C'


ou par les identifiants de capteurs). Ces ajouts impliquent différentes modifications de la structure de l'index.

Le sous-arbre spatial utilisé dans le PoTree ne permet pas la résolution de requêtes basées sur des identifiants de capteurs. Ainsi, une seconde structure d'accès vient compléter le PasTree. Cette seconde structure indexe les identifiants de capteurs et pointe à son tour vers les sous-arbres capteurs correspondant. Il existe donc désormais deux sous-structures d'accès, chargées du passage des requêtes vers les sous-structures concernées.

Une interface située au dessus des sous-arbres d'accès permet de centraliser la gestion des requêtes. L'utilisateur ne doit pas avoir à choisir quelle sous-structures doit être interrogée pour résoudre une requête particulière. Une interface est ainsi disponible et centralise l'arrivée des requêtes. Cette interface re-dirige ces requêtes en fonction du type d'accès demandé. Si une requête porte sur des critères spatiaux ou sur des identifiants de capteurs, elle la re-dirige vers la structure d'accès idoine. Cette interface permet de rendre invisible la gestion de l'accès multicritère aux yeux de l'utilisateur.

5.2.2.1.1 La gestion multicritèreComme précisé ci-dessus, la gestion multicritère impose l'adoption d'une nouvelle sous-structure : le sous-arbre d'identifiants. En effet, alors que le sous-arbre spatial permet la résolution de requêtes basées sur des critères spatiaux, il ne permet pas directement de répondre à des demandes d'accès basées sur des identifiants. Tirant parti du regroupement des données dans des sous-structures liées aux capteurs, le nouvel arbre d'identifiants permet d'accéder aux données sans avoir recours aux caractéristiques spatiales. Ceci permet en outre d'indexer des données liées à des capteurs non-référencés spatialement (positions inconnues au moment de la requête ou bien indéterminables par les capteurs eux-mêmes). Il existe désormais deux sous-structures d'accès, permettant d'atteindre les sous-arbres de capteurs.

La gestion multicritère impose également des changements au sein de l'arbre capteur : les mesures mais aussi l'ensemble des données relatives au capteur sont consignées dans celui-ci. Le sous-arbre d'identifiants tout comme le sous-arbre spatial pointent vers des sous-structures capteurs. Cependant, pour limiter le coût d'accès aux données, un arbre capteur ne peut remonter directement vers un arbre spatial pour une simple consultation. Lorsqu'un utilisateur cherche à atteindre les mesures du capteur, le lien unidirectionnel fonctionne correctement. « Quel est l'identifiant du capteur actuellement situé à la position <X;Y>? » « Quelle est la position actuelle du capteur 'RJ 49'? » Dans ces deux exemples, l'utilisateur cherche à obtenir des informations normalement réparties entre les deux sous-structures d'accès. L'adoption d'un lien bidirectionnel entre les différentes sous-structures est possible mais impose le besoin d'accéder à l'ensemble des sous-structures, induisant une latence plus importante. Il a été décidé de poursuivre le regroupement des données capteurs au sein d'une même sous-structure et d'y inclure des informations spatiales ainsi que l'identifiant du capteur.

Les sous-structures d'accès deviennent dès lors les goulets d'étranglement du PasTree. Toute requête nécessite un accès à l'une de ces deux structures. Afin de limiter le surcoût induit par la multiplication des requêtes à des structures différentes et plus particulièrement à des structures souvent au cœur des demandes



d'accès parallèles, le PasTree préfère sacrifier à une utilisation plus volumineuse de la mémoire du système et ainsi réunir l'ensemble des données capteurs au sein d'une sous-structure dédiée.

Cet ajout au sein de la sous-structure capteur induit une redondance des informations relatives au capteur. Ainsi, les données purement spatiales sont conservées au sein de la sous-structure spatiale mais également au sein de la sous-structure de capteur. Il en va de même pour les identifiants et l'arbre qui leur est dédié. Cependant le PasTree se fonde sur l'idée de regroupement des données au sein de sous-arbres capteur. Il a ainsi été choisi de limiter le nombre d'accès à des arbres différents pour diminuer le coût d'accès mémoire. De fait, les sous-arbres capteurs gagnent en indépendance vis à vis des sous-structures d'accès. Ils peuvent dès lors bénéficier d'une gestion semi-autonome. Il est possible d'obtenir l'ensemble des informations relatives à un capteur ou à ses mesures à partir de la sous-structure qui lui est dédiée. En cela on se rapproche du paradigme de programmation objet et d'une architecture distribuée.

En somme, la gestion de l'aspect multicritère impose l'adoption d'une nouvelle structure d'accès basée sur les identifiants de capteurs ainsi que l'ajout d'informations relatives au capteur au sein de la sous-structure de capteur. Par là-même la distinction entre arbre spatial et arbre temporel est effacée au profit du regroupement de l'ensemble des informations relatives à un capteur au sein d'une même sous-structure de capteur. Cependant, d'autres facteurs contribuent à l'affaiblissement de cette différenciation, telle la gestion de l'agilité.

5.2.2.1.2 La gestion de l'agilitéLa gestion de l'agilité efface également la différenciation dimensionnelle. Pour le PoTree, il était possible de parler d'arbre spatial pur, dont le seul rôle était d'enregistrer les données spatiales relatives à un capteur, et d'arbres capteurs analogues à des arbres temporels purs. La distinction entre ces structures se fait plus floue pour le PasTree. En effet, la gestion de l'agilité impose que le sous-arbre spatial puisse conserver une trace des durées de validité de ses enregistrements. En d'autres termes, il conserve la position du capteur, mais également l'intervalle de temps pendant lequel cette position est valide. Une requête utilisant des critères spatio-temporels ne peut se permettre d'interroger tous les capteurs inclus dans la fenêtre spatiale concernée. Pour des raisons de coût d'accès aux structures il est plus économique de limiter au plus tôt le nombre de sous-arbres capteurs accédés. Ceci impose l'enregistrement d'informations temporelles au sein du sous-arbre « spatial ». Pour simplifier les références aux structures, on continuera à utiliser le terme de sous-arbre spatial par la suite. Une approche multiversion est retenue pour celui-ci [76]. Les enregistrements au sein de la structure spatiale conservent les temps de validités, à savoir les intervalles temporels de présence des capteurs en ces points.

La gestion de l'agilité impose des changements dans l'approche spatiale. Alors que le kd-tree offrait des performances intéressantes pour des réseaux de capteurs fixes, avec des capacités limitées de mises à jour en ligne, l'adoption du paradigme de l'agilité des capteurs permet de l'écarter. En effet, les risques de déséquilibre de la structure spatiale imposent l'adoption d'une autre approche, permettant une gestion multiversion. Les capteurs restent représentés sous la forme de points dans un



espace. Le Quadtree a été retenu (octree en trois dimensions) pour remplacer le kd-tree. Compatible avec l'approche multiversion, il permet une gestion des positions des capteurs en fonction de l'espace étudié.

La gestion des positions de capteurs ne se contente pas de ce simple artifice. En effet, comme exposé précédemment, les sous-structures de capteurs recueillent désormais l'ensemble des données relatives aux capteurs. Par conséquent il convient également d'ajouter la gestion de changement de position au sous-arbre capteur.

5.2.2.1.3 Ajout d'un niveau d'abstraction au sous-arbre capteurLe changement de position peut être considéré comme une forme de donnée particulière. Deux types de données peuvent alors être distinguées : les mesures effectuées et les changements de positions. L'ajout d'un niveau d'abstraction permet de distinguer les deux. De cette manière le sous-arbre de capteur conserve l'ensemble des données relatives à un capteur.

En somme, la structure globale du PasTree (cf. figure 34), empruntée à celle du PoTree, se compose de deux sous-arbres d'accès dont le but est de référencer des sous-arbres de capteurs qui contiennent l'intégralité des données relatives aux capteurs et aux mesures collectées par ceux-ci. La première sous-structure d'accès


Figure 34 : Structure du PasTree

MvtPosition

Arbre Capteur

OID position

Temps Temps Temps

Temps Temps Temps

Val Val

Arbre Capteur

OID position

Arbre Capteur

OID position

QuadtreeMult iversion

S-Oposition

N-Oposition

N-Eposition

S-Eposition

Tdébut /TfinOID

Arbre spatial quadtree multiversionIdentifiants

OID OID OID

OID OID OID

Arbre des identifiants de capteur

Arbre capteur: index des données issues d'un capteur particulier


est un sous-arbre spatial multiversion tandis que la seconde est un sous-arbre référençant les identifiants de capteurs. L'utilisation de ces sous-structures est rendue invisible pour l'utilisateur par l'adoption d'une interface chargée de collecter les requêtes et de les transférer à la sous-structure d'accès adéquate. Le PasTree est donc similaire à un jardin botanique dans lequel les visiteurs peuvent choisir leur méthode de visite : selon un plan ou selon un ordre alphabétique des arbres.

5.2.2.1.4 Gestion des accès concurrentielsAlors que le PoTree offrait un point central pour l'accès aux données (le sous-arbre spatial), le PasTree demande une gestion plus fine. Il convient de distinguer plusieurs types d'accès aux données et aux différents sous-arbres du PasTree (cf tableau 6). Une mise à jour sur un capteur fixe par exemple demande un accès en lecture à une des sous-structures d'accès puis un accès en écriture au sous-arbre capteur correspondant.

Type d'accès Arbre spatial Arbre d'identifiants

Arbre capteur

Accès aux données Lecture Lecture Lecture

MàJ sans mouvement (MàJ

spatial)

Lecture - Écriture

MàJ sans mouvement (MàJ

identifiant)

- Lecture Écriture

MàJ avec mouvement (MàJ

spatial)

Lecture, puis Écriture

Lecture Écriture

MàJ avec mouvement (MàJ

identifiant)

Écriture Lecture Lecture/Écriture

Suppression de donnée (spatial)

Lecture - Lecture/Écriture

Suppression de donnée

(identifiant)

- Lecture Lecture/Écriture

Suppression de capteur

Lecture/Écriture Lecture/Écriture Lecture/Écriture

Tableau 6 : Types d'accès en fonction des requêtes

A chacune de ces sous-structures, un verrou particulier peut être attaché, limitant les autres types d'accès possibles. Une transaction demandant un accès en écriture empêche un autre accès à la structure tandis que plusieurs accès en lecture peuvent avoir lieu. Plusieurs processus de mise à jour peuvent ainsi se partager l'accès à la sous-structure spatiale.



Il est à noter qu'une suppression de donnée n'entraîne pas nécessairement une suppression de capteur. En effet, bien que les données d'un capteur ne soient plus disponibles, le capteur en lui-même peut toujours être physiquement présent, et peut ainsi être sujet à certaines requêtes. L'utilisateur peut alors contacter l'interface centrale pour émettre des requêtes le concernant.

5.2.2.2 L'interface centrale

La partie interface qui sert de point central de réception des requêtes utilisateurs sert également à la communication entre les différents sous-arbres d'accès, comme indiqué dans la figure 35.

Il s'agit principalement d'une passerelle permettant une répartition des requêtes vers les sous-arbres d'accès concernés. L'interface reçoit les requêtes utilisateurs. Celles qui ne comportent qu'une partie spatiale ou un identifiant de capteur sont envoyés vers les sous-arbres respectifs. Les requêtes comportant l'ensemble de ces données mais portant sur des intervalles temporels sont envoyés vers le sous-arbre spatial par défaut. Celui-ci, multiversion, permet une première sélection sur des aspects temporels. Les mises à jours sont prioritairement confiées au sous-arbre spatial afin de vérifier un éventuel changement de position du capteur.

L'interface est également utilisée afin de permettre une communication entre les différentes sous-structures d'accès, l'arbre d'identifiants et l'arbre spatial. Une telle communication est nécessaire lors de l'ajout et le la suppression de capteurs, ou lors de la détection d'un mouvement de capteur.

La figure 36 décrit le processus de mise à jour inter-arbres. Un ajout de capteur a lieu lorsqu'une mise à jour passée à l'une des sous-structure d'accès porte sur un capteur non existant. Dès lors, le sous-arbre concerné lance une procédure de création de sous-arbre capteur et envoie par le biais de l'interface un message permettant la mise à jour de l'autre sous-arbre d'accès. Le sous-arbre spatial enverra une message de mise à jour comportant le lien vers le nouvel arbre et son identifiant de capteur tandis que son homologue, dans une situation similaire enverra un message comportant des informations spatiales. Ces messages sont transmis avec une priorité maximale. Contrairement aux autres index utilisés dans les bases de


Figure 35 : Rôle de l'interface

Interface

Arbre spatial Arbre d'identifiants

Requêtes Utilisateurs

Transfert d'uneRequête

Communication entre arbres d'accès


Figure 36 : Processus d'échanges via l'Interface lors d'une mise à jour

données, la gestion des priorités des transactions peut être ici subdivisée en plusieurs sous-éléments, relatifs aux différents sous-arbres du PasTree. Un accès à une sous-structure n'entraîne pas un blocage de l'ensemble du PasTree. Plusieurs politiques d'accès sont possibles, empruntées au domaine des index répartis. Ainsi un verrou est lié à chacun des sous-arbres limitant l'accès à ceux-ci. De cette manière, plusieurs transactions peuvent avoir un accès concurrent à l'arbre d'identifiants tandis qu'une autre effectue une mise à jour, et bloque l'accès à un sous-arbre capteur.

5.2.2.3 Le sous-arbre d'identifiants

Le sous-arbre d'identifiants est désormais l'une des deux sous-structure d'accès aux données. Il indexe les capteurs en fonction de leurs identifiants et pointe vers les sous-arbres de capteurs correspondants (cf. figure 37). Cette structure, qui pourrait être adaptée au PoTree est basée sur un B+Tree. Le seul ajout à cette structure consiste en l'addition d'un lien vers la partie interface centrale du PasTree. C'est ce lien qui est utilisé pour permettre la création de nouveaux capteurs. La création de nouveaux capteurs devant ici s'accompagner d'un identifiant répondant aux critères imposés par la politique de nommage du système de surveillance.



5.2.2.3.1 Politique de nommage des capteursLa politique de nommage des capteurs dans les réseaux de surveillance n'est pas aléatoire. Plusieurs grandes politiques co-existent. Dans des réseaux couvrant de vastes zones géographiques, la politique de nommage des capteurs porte souvent trace de la localisation de ceux-ci. Ainsi les capteurs du K-net nippon [33] sont-ils nommés selon un schéma AAA111. Les trois premières lettres correspondant à l'identifiant de la zone géographique à laquelle est rattachée le capteur, les trois chiffres suivants identifient de manière incrémentale le capteur au sein de cette zone. Ainsi le capteur ISK011 correspond à un capteur de la région d'IShiKawaken. Le tableau 3, page 89, donne un exemple de plusieurs capteurs.

Une autre politique de nommage consiste à référencer le type de capteurs utilisé. CLI001 pourra correspondre au premier clinomètre d'un réseau de surveillance volcanique. Il est alors aisé d'identifier le type de capteurs à interroger.

Les requêtes tendent à interroger des capteurs selon des zones ou selon des types définis. Une requête devant interroger plusieurs capteurs porte généralement sur des données issues de capteurs spatialement proches, ou de types similaires. La probabilité d'interroger consécutivement les capteurs ISK 011 et ISK012, situés à peu de distance, n'est pas négligeable.

Les liens entre les nœuds feuilles du B+Tree peuvent être mis à profit pour diminuer le coût d'accès à des ensembles de capteurs. En effet, les capteurs possédant des identifiants proches, marquant une similitude géographique ou de type sont classés dans le même nœud ou dans des nœuds proches au sein du B+Tree. Par là-même il devient possible de limiter le besoin de parcours de la structure pour répondre à des requêtes portant sur plusieurs capteurs.

5.2.2.3.2 Accès aux données, les arbres de capteurLe sous-arbre d'identifiants est utilisé pour transférer une requête au sous-arbre de capteur correspondant. Les sous-structures d'accès du PasTree sont toutes deux utilisées pour identifier les sous-arbres capteurs devant répondre à des requêtes spécifiques. Dans le cas du sous-arbre d'identifiants, la requête originelle porte une référence à un ou plusieurs identifiants de capteurs. Les sous-arbres correspondant n'ont pas utilité de cette partie de la requête. Par conséquent, le sous-arbre capteur


Figure 37 : Structuration de l'arbre d'identifiants

Liens Fils Liens Parent

Structure des noeuds internes du sous-arbre d'identifiant

Identifiants Noeuds

Liens ID

Identifiants Arbre capteur


Structure des noeuds feuille du sous-arbre d'identifiant

Parent.


supprime cette partie de la requête d'origine, et si besoin duplique les requêtes pour les transférer aux différents sous-arbres capteurs correspondants. Il compilera par la suite les résultats retournés par ceux-ci avant de les présenter à l'utilisateur.

5.2.2.3.3 Mise à jour de la structureLes mises à jours suivent une procédure en plusieurs étapes. Les mises à jour de la structure sont possibles aussi bien par le biais du sous-arbre spatial que par l'arbre d'identifiants. Il est ainsi possible à la partie interface d'alterner les sous-arbres d'accès lorsque cela est nécessaire. Il est également possible que certains capteurs n'utilisent pas de références spatiales. Dans ce cas, la mise à jour passe obligatoirement par ce sous-arbre. Comme pour tout accès aux données, la mise à jour commence par une recherche au sein de cette sous-structure afin d'identifier le sous-arbre capteur concerné. Si le sous-arbre est identifié, la mise à jour est transférée à celui-ci. Si cette recherche aboutit à un résultat nul, cela signifie que la mise à jour concerne un capteur non encore définit, un nouveau capteur. Le sous-arbre lance alors la création d'un nouveau sous-arbre de capteur, l'initialisant grâce à son identifiant. Il peut alors le mettre à jours. Si une information spatiale fait partie de la mise à jour, le sous-arbre d'identifiants contacte alors l'interface globale pour qu'elle force la création d'un nouveau point dans le sous-arbre spatial (cf. figure 38). Pour cela il transmet la position, le marqueur temporel reçu avec la mise à jour et un lien vers le nouvel arbre capteur. Une mise à jour à partir d'un identifiant peut ainsi provoquer une mise à jour du sous-arbre spatial.

En contre-partie une mise à jour du sous-arbre spatial peut entraîner une mise à jour du sous-arbre d'identifiants. Ainsi la partie interface centrale peut envoyer une demande de mise à jour comportant l'identifiant du nouveau capteur et un lien vers celui-ci. Il ne reste alors qu'à ajouter cette nouvelle référence à la structure d'identifiants. Les mises à jour à partir de données spatiales peuvent également entraîner un autre type de communication entre les structures. En effet, si le sous-arbre spatial ne réussit pas à localiser le capteur à l'origine de la mesure à la position indiquée par la mise à jour, deux cas de figure sont possibles. Le capteur peut être nouveau ou il peut avoir changé de position. Il est alors nécessaire de contacter l'arbre d'identifiants pour résoudre cette inconnue. En utilisant l'identifiant du capteur il est possible de déterminer si celui-ci est déjà défini. Le cas échéant, le


Figure 38 : Mise à jour via l'arbre d'identificateur


sous-arbre d'identifiants renvoie un lien vers le sous-arbre capteur correspondant. Si aucun capteur n'existe, il est créé et sa référence est ajoutée au B+Tree avant d'être renvoyée vers le sous-arbre spatial pour que la position soit ajoutée.

5.2.2.3.4 Suppression de données et de capteurLors de la réception d'une requête de suppression de données, le processus est analogue. L'arbre capteur correspondant est accédé avant de lui transmettre la requête de suppression. Le risque d'une tentative d'accès pour mise à jour via l'arbre spatial tandis qu'une autre transaction tente d'éliminer les données via cet arbre est minimisé par les différentes politiques d'accès aux données. En effet, les capteurs sont généralement accédés par le même sous-arbre d'accès. Cependant ce risque n'est pas nul mais peut-être adressé par les gestionnaires de requête utilisés dans les bases de données temps-réel (contrôle d'accès concurrents). Ces gestionnaires doivent en effet prendre en considération la possibilité de perte d'une transaction. Le principe du temps-réel étant la possible élimination de requêtes infaisables pour ne pas bloquer l'ensemble du système.

Une requête de suppression de capteurs peut être reçue et traitée, comme illustré dans la figure 39. La suppression commence par une recherche du lien vers le sous-arbre capteur correspondant. Celui-ci est alors verrouillé tandis que la liste des positions occupées par le capteur est renvoyée au sous-arbre spatial via l'interface


Figure 39 : Suppression de capteur à partir de l'arbre d'Indentifiants


pour suppression des références. Une fois cette phase achevée, le sous-arbre capteur est éliminé et sa référence enlevée de la structure d'identifiants.

5.2.2.3.5 Coût de fonctionnement de la structureD'un point de vue mathématique, cette sous-structure est similaire au B+Tree. L'accès à la structure s'effectue en O log n L'accès aux données enregistrées par les capteurs, ainsi que les mises à jour de ces données commencent par un accès en lecture de l'arbre d'identifiants. Dans le cas de la mise à jour, ce n'est que si ce premier accès s'est révélé infructueux que le système lance la procédure de mise à jour du sous-arbre d'identifiants (création d'un nouvel arbre capteur).

La construction est ainsi plus complexe que la consultation. La construction en elle-même suit les mêmes règles que celles édictées pour le B+Tree, majorées par une tentative d'accès aux données avant la mise à jour en elle-même. Un premier accès est chargé de déterminer si une mise à jour concerne un nouveau capteur ou un capteur préexistant. Ce n'est que si le capteur n'a pas été précédemment défini dans l'arbre qu'il est ajouté. Ainsi ce coût global de construction de cet arbre seul (hormis le surcoût lié à la mise à jour du sous-arbre spatial) s'évalue à O n log n avec n le nombre d'identifiants, de capteurs. A ce coût lié à la construction de la structure est également associé un surcoût dû à la transmission de l'ajout d'un capteur à l'interface, puis à l'arbre spatial. En effet, les ajouts de capteur s'effectuent sur les deux structures d'accès, l'arbre d'identifiants, mais aussi l'arbre spatial.

En somme, le sous-arbre d'identifiants utilise un B+Tree afin de référencer les différents capteurs selon leurs identifiants, tout en exploitant la politique de nommage pour diminuer le coût de consultation des données. Il permet un accès direct aux sous-arbres capteurs mais doit passer par la partie interface centrale pour communiquer avec le sous-arbre spatial.

5.2.2.4 Le sous-arbre spatial

Cette structure d'accès spatial est basée sur un Quadtree multiversion (figure 40). multiversion signifie ici qu'un intervalle de validité est conservé pour chaque entrée dans le Quadtree. Pour chaque quadrant de la structure, une liste d'enregistrements est conservée. Ces enregistrements se composent d'un lien vers le sous-arbre capteur correspondant, ainsi que des dates de début et de fin de validité (de présence du capteur en ce point).


Figure 40 : Structure du Quadtree multiversion

Racine

NOT1-T3

NET1-T4

SOT1-T5

SET1-T3


5.2.2.4.1 Un Quadtree multiversionLe Quadtree permet de subdiviser l'espace d'étude en quatre quadrants de taille égale. En subdivisant de manière récursive les quadrants, il devient possible d'affiner la représentation de l'espace. A chaque quadrant fils est lié une position particulière, occupée par un capteur. Cette solution permet de référencer les différentes positions occupées par les capteurs. A chaque quadrant de notre structure est lié un point de référence ainsi qu'à des quadrants fils (cf. figure 41). Le point de référence correspond à la position du capteur référencé dans le quadrant ou à la position du centre de la zone couverte s'il s'agit d'un quadrant intermédiaire (interne à la structure). Les liens vers les arbres capteurs se situent aux niveaux inférieurs du Quadtree. Dans ces quadrants se trouve également un lien vers une liste d'enregistrements. Ces enregistrements comportent une date de début de validité, une date de fin de validité et un lien vers un arbre capteur, qui permet d'accéder à son identifiant. L'identifiant est dupliqué afin de limiter le coût d'accès au sous-arbre capteur correspondant lors des requêtes de mise à jour, les plus fréquentes. Ce sont les indicateurs temporels qui permettent une gestion multiversion.

L'agilité des capteurs peut ainsi être gérée par le Quadtree. Un capteur peut passer par un point particulier (entre les instant T1 et T2) et collecter des mesures avant d'être déplacé à un autre endroit. Plus complexe encore, ce même capteur pourra par la suite repasser par le même point (entre T3 et T4) pour y collecter de nouvelles mesures. Dans la structure du Quadtree, cela se traduit par deux enregistrements liés au même quadrant spatial : le premier pour la période [T1;T2[ et le second pour la période [T3;T4[. Tous deux pointent vers le même sous-arbre capteur. De même, cette utilisation d'aspects multiversion permet de prendre en compte le passage successif de plusieurs capteurs au même point. En effet, à chaque capteur correspond un enregistrement particulier.

Notons que l'intervalle de validité correspondant à la position actuelle d'un capteur n'est pas fermé. Il est encore valide à l'instant présent. En termes informatiques, cela se traduit par l'adoption d'un champ utilisant le maximum de la valeur temporelle autorisée.

L'arbre spatial est accédé pour résoudre les requêtes fondées sur des critères spatiaux. Il permet de résoudre des requêtes prenant en compte l'agilité des capteurs grâce à sa gestion multiversion. Par là-même le terme d'arbre spatial constitue un abus puisqu'il conserve également des informations temporelles. L'accès aux données collectées par l'intermédiaire de l'arbre spatial subira deux analyses


Figure 41 : Structuration du Quadtree multiversion

Parent Position Mini Position Maxi Point courant EnfantsDonnéesv

Temps Début Temps Fin Identifiant Arbre capteur

Noeud du QuadTree

Enregistrement de donnée


temporelles : au niveau de l'arbre spatial pour déterminer les sous-structures de capteur concernées par une requête et au niveau de ces dernières pour déterminer les données à retourner à l'utilisateur.

5.2.2.4.2 L'accès aux arbres capteurL'accès aux arbres capteurs par le biais d'une coordonnée commence par un parcours du Quadtree, comme décrit dans la figure 42. Le Quadtree est parcouru de manière récursive, selon les algorithmes de ce type de structure. A chaque niveau de l'arbre, le quadrant fils englobant le point concerné par la requête est déterminé. Lorsqu'il n'est plus possible de descendre dans la structure (lorsque le dernier quadrant fils est atteint), une comparaison est effectuée entre le point de référence du quadrant (la position du capteur lié à ce quadrant) et le point défini par la requête. Si les points ne correspondent pas, la requête retourne un résultat nul. Dans le cas contraire, il est possible de passer à la phase suivante de la résolution.

Figure 42 : Recherche de capteur via l'arbre spatial (point spatial, instant temporel)

Une fois la recherche spatiale terminée, la liste des enregistrements temporels est parcourue à son tour. Cette liste est classée de telle sorte à favoriser l'accès aux données les plus récentes (insertion en tête de nouveaux enregistrements). Cette liste est ordonnée pour présenter les entrées « en vie, » dont l'intervalle de validité n'est pas terminé. La requête est donc comparée à cet intervalle afin de déterminer



le ou les enregistrements répondants aux critères aussi bien spatiaux que temporels de la requête. Un facteur restrictif sur l'identifiant de capteur peut être ajouté à ce niveau. Les arbres capteurs concernés sont ajoutés à une liste d'arbres à interroger.

En cas d'existence de limitations quant aux identifiants des capteurs, un contrôle est effectué sur cette liste afin d'en éliminer les éléments non compatibles.

Une fois la liste des arbres capteurs concernés établie, la requête originale est dupliquée et envoyée à chacun de ceux-ci. Plus précisément, pour une requête de demande d'accès, la requête est reformulée. Les aspects spatiaux sont éliminés. La gestion de l'intervalle temporel est un peu plus complexe, comme illustré dans la figure 43 :

● Si l'intervalle de la requête est inclus dans l'intervalle de validité, il est utilisé tel quel.

● Si l'intervalle temporel original n'est pas recouvert par l'intervalle de présence du capteur, la requête transmise aura un intervalle temporel tronqué (intersection des deux intervalles).

● Si l'intervalle est couvert par plusieurs intervalles de présence, deux sous-requêtes distinctes sont envoyées aux arbres capteurs. Les résultats renvoyés par ceux-ci sont compilés avant d'être retournés à l'utilisateur.

Figure 43 : Modification des intervalles des requêtes en fonction de la présence du capteur C au point P

Les requêtes sur des intervalles temporels peuvent générer plusieurs requêtes d'accès aux données des arbres capteurs (cf. figure 44). Soit un capteur C effectuant des mesures à une position P déterminée. C effectue une première série de mesure dans l'intervalle [T0;T2[. Puis C est déplacé entre [T2;T3[ avant d'effectuer de nouvelles mesures en P entre [T3;T5[. Une requête arrive au système pour obtenir les relevés effectués entre les instants T1 et T4 tels que T0<T1<T2 et T3<T4<T5. Le système de résolution de requêtes devra donc transférer à l'arbre de capteur de C une requête portant sur l'intervalle [T1;T2[ et une requête portant sur l'intervalle [T3;T4[. Le parcours de la liste d'enregistrement doit donc prendre en considération aussi bien les intervalles sur la fin de validité que ceux pour le début de validité des enregistrements. A partir de ce point, deux requêtes d'accès peuvent être envoyées au sous-arbre capteur.

Les zones spatiales peuvent également être utilisées comme paramètres de requêtes. En effet, le Quadtree permet la résolution de requêtes sur des points mais également


T0 T1 T2 T3 T4 T5 Intervalle de validité dans le Quadtree

Intervalle de Recherche Global

Intervalles de Recherches envoyées au sous-arbre Capteur


Figure 44 : modification des intervalles de recherche en fonction des enregistrements

sur des zones. Le principe de fonctionnement du Quadtree repose sur une linéarisation de l'espace, celui-ci étant récursivement subdivisé en quadrants. Par là même il devient possible de résoudre des requêtes portant sur des zones spatiales. Le principe de parcours du Quadtree reste similaire à celui proposé ci-dessus. Il s'agit de déterminer les différents quadrants concernés par la zone de recherche. On distingue trois cas correspondant au résultat d'un test de recouvrement (d'intersection entre la zone de recherche et la zone couverte par le quadrant) :

● Le quadrant n'est pas couvert par la zone de recherche. Dans ce cas, inutile de continuer à recherche dans les branches inférieures du Quadtree.

● Le quadrant est entièrement recouvert par la zone de recherche. Dans ce cas, tous les quadrants fils de celui-ci sont également concerné par la requête. Il devient inutile d'effectuer des tests de recouvrement pour ceux-ci, ils le sont par définition. Il suffit dès lors d'atteindre les quadrants fils, les arbres capteurs correspondant et de leur transmettre la requête d'accès aux données.

● Le quadrant est partiellement recouvert par la zone de recherche. Ce cas de figure présuppose qu'un test de recouvrement sera à nouveau effectué au



niveau inférieur du Quadtree. Les quadrants fils peuvent en effet être totalement couverts, mais il existe au moins un quadrant non couvert ou partiellement couvert.

Plusieurs sous-requêtes peuvent être envoyées à un même arbre capteur. Dans le cas de requêtes sur des intervalles longs, cette possibilité n'est pas à négliger. Le PasTree différencie ces sous-requêtes lors de la résolution. La définition d'agilité suppose que les changements de positions des capteurs restent limités, rares. Le processus de division d'une requête originale en deux sous-requêtes n'est principalement utilisé que pour des requêtes sur des intervalles temporels long. Le coût d'accès aux données favorise la création de deux sous-requêtes distinctes. Une requête unique décomposée en deux sous-parties, tirant parti des liens entre les nœuds fils de l'arbre capteur (proche de celui utilisé pour le PoTree) se fait moins attractive lorsque le nombre de données à rejeter croît.

Du fait de son agilité, un même capteur peut être sujet à plusieurs sous-requêtes si la zone de recherche et l'intervalle temporel originel recouvrent plusieurs positions occupées par ce capteur à des dates différentes. Là encore, du fait de la faible probabilité d'occurrence, il a été choisi de ne pas pousser l'analyse et l'optimisation des sous-requête plus avant. Le surcoût engendré par une analyse systématique des sous-requêtes ne compense que le gain potentiel de la fusion de sous-requêtes distinctes que dans des cas d'utilisation précis.

L'accès aux données passe donc par plusieurs phases. En premier lieu, une recherche purement spatiale permet de restreindre le nombre de capteurs concernés par une requête. Par la suite, une analyse au niveau des intervalles de validité de la requête et de la présence du capteur dans la zone recherchée permet de lancer des sous-requêtes aux différents arbres capteurs concernés. Les résultats sont compilés avant d'être retournés à l'utilisateur.

5.2.2.4.3 La mise à jourLa mise à jour des mesures effectuées par un capteur, décrite dans la figure 45, passe par deux phases distinctes. La première consiste à s'assurer que le capteur existe et si besoin est à lancer le processus de création de capteur. La seconde phase lance la mise à jour dans le sous-arbre capteur correspondant. Les mises à jour sont effectuées indépendamment pour chaque capteur. Elles portent sur des points spatiaux.

La phase de vérification de l'existence d'un capteur commence par une tentative d'accès au quadrant concerné par la mise à jour. En arrivant au dernier quadrant du Quadtree, on vérifie l'adéquation entre le point de référence du nœud et la position du capteur. Si ces points ne sont pas analogues, le capteur n'était pas à cet endroit lors de la précédente mise à jour ou bien n'était pas encore déclaré. Si les points correspondent, on accède à la liste des enregistrements en vie (dont la fin de l'intervalle de validité est ouvert). On recherche l'identifiant du capteur à mettre à jour. Si l'identifiant est trouvé, on lance alors la mise à jour sur ce sous-arbre en lui transférant le marqueur temporel de la mesure ainsi que la valeur mesurée. Si, au contraire, l'identifiant n'est pas dans la liste des enregistrements en vie, alors celui-ci vient de se déplacer ou n'a pas encore été déclaré. Il convient alors de déterminer s'il s'agit d'un nouveau capteur.



Figure 45 : Processus de mise à jour de données via l'arbre spatial

Un capteur qui vient de se déplacer est déjà défini dans la structure, notamment au niveau de la sous-structure d'identifiants. Par conséquent, un accès à cet arbre permet d'obtenir un lien vers le sous-arbre capteur associé. Cet accès s'effectue via l'interface centrale. L'interface retourne un lien vers le sous-arbre capteur approprié s'il existe.

A partir de ce point, la mise à jour d'un capteur ayant changé de position s'effectue en deux phases. Tout d'abord, un nouvel enregistrement dans le quadrant courant est créé si les positions du capteur et du point de référence du quadrant sont similaires.



S'ils sont différents, le quadrant est subdivisé en quatre nouveaux quadrants fils. L'ancien point de référence deviendra le point de référence du quadrant fils contenant ce point. Le point de référence du quadrant parent est réinitialisé pour prendre la valeur centrale de la zone couverte par celui-ci tandis que sa liste d'enregistrements est transférée au quadrant fils correspondant. Le nouveau point est réinséré dans le quadrant dont il dépend. Ce processus est récursif et peut entraîner des subdivisions multiples si les deux points sont proches. Un enregistrement est créé pour le nouveau point dans lequel sont conservés l'identifiant du capteur, un lien vers celui-ci, la date de début de validité (la date de prise de mesure), et pour lequel on place la fin de l'intervalle à la valeur maximale admissible (intervalle « ouvert »). Un nouvel enregistrement « en vie » vient d'être créé.

Par la suite, un accès au sous-arbre capteur via le lien retourné par l'interface permet de déterminer son ancienne position. Le Quadtree est alors parcouru jusqu'à atteindre le quadrant conservant l'enregistrement du capteur. Cet enregistrement est recherché dans la liste des capteurs en vie. Son intervalle de fin de validité est alors fixé à l'instant de la mesure moins un temps epsilon. Le capteur était supposé lié à cette position jusqu'à l'arrivée de la nouvelle mesure. Une fois cet intervalle fermé, l'enregistrement est alors replacé dans la liste dans l'ordre décroissant des fins de validité. De cette sorte, les enregistrements en vie et les plus récents sont en début de liste. L'ancien enregistrement « en vie » du capteur vient de s'éteindre. Puisse-t-il se reposer jusqu'à la prochaine requête d'accès aux données.

La structure du Quadtree est alors à jour. L'arbre capteur est contacté pour l'informer du changement de position. La date de la mesure lui est transmise, ainsi que la valeur mesurée et la nouvelle position du capteur.

Lorsque la procédure de mise à jour ne peut obtenir de lien vers un arbre capteur via l'interface, il est nécessaire d'en créer un nouveau. Le nouvel arbre est alors généré à l'aide de son identifiant de capteur et de sa position. L'arbre capteur une fois créé, le Quadtree vérifie la similitude entre le point de référence du Quadtree et la position du nouveau capteur. S'ils sont identiques, il crée un enregistrement contenant un lien vers celui-ci, son identifiant, un début d'intervalle correspondant à la date de mesure et une fin d'intervalle ouvert. Si les positions sont différentes, un nouveau quadrant est créé, les données redistribuées avant que l'enregistrement soit créé, comme décrit précédemment pour la mise à jour suivant un changement de position. Finalement, l'interface est contactée afin de lancer une mise à jour de l'arbre d'identifiants.

La procédure de mise à jour consiste en une vérification de la préexistence du capteur au point donné par la requête. Trois cas se présentent :

● Le capteur était déjà présent. Dans ce cas, la mise à jour à la structure de capteur correspondant est transférée.

● Le capteur vient de changer de position. Dans ce cas, l'ancien enregistrement du capteur dans le Quadtree est éteint, un nouvel enregistrement est créé et la mise à jour de la structure de capteur est lancée.

● Le capteur n'était pas défini auparavant et doit être ajouté. Dans ce cas, un nouvel arbre de capteur est créé puis le Quadtree et l'arbre d'identifiants ont mis à jour.



5.2.2.4.4 La suppression de donnéesAjouter des données (mesures des capteurs) ne peut se concevoir que s'il existe une méthode permettant de les soustraire.

Lors de la réception d'une requête de suppression de données, le Quadtree commence par déterminer l'arbre capteur correspondant. La structure du Quadtree est parcourue jusqu'à atteindre le quadrant correspondant. Le requête de suppression de données est alors transférée au sous-arbre correspondant en fonction de son identifiant.

De son coté, le quadrant du Quadtree met à jour sa liste d'enregistrements (cf. figure 46). L'enregistrement correspondant au capteur et à l'intervalle à enlever sont recherchés. L'intervalle de validité de l'enregistrement est alors tronqué de l'intervalle à ôter. Le processus utilisé est proche de celui décrit pour l'accès aux données via des intervalles. Si l'intervalle à ôter est inclus dans l'intervalle de validité de l'enregistrement, celui-ci peut être subdivisé en deux. Un enregistrement pour le capteur C est définit entre les instants T0 et T3. Une requête de suppression des données de C est reçu concernant l'intervalle [T1;T2[ avec T0<T1<T2<T3. On détruit l'ancien enregistrement pour introduire dans la liste un premier enregistrement sur [T0;T1[ et un second sur [T2;T3[. Les enregistrements restant classés dans l'ordre de fin d'intervalle, les plus récents en tête de liste.

Si l'intervalle entier est éliminé, la liste est parcourue afin de vérifier l'existence d'autres enregistrements. S'il n'existe aucun autre enregistrement, le quadrant n'a plus de raison d'exister et est éliminé. Le quadrant parent est alors interrogé. S'il existe un seul autre quadrant enfant en vie, celui-ci est récursivement remonté d'un niveau dans la structure du Quadtree, sinon la situation est laissée inchangée.

La suppression de capteur suit un schéma similaire à celui présenté pour l'arbre d'identifiants. Après un accès au sous-arbre capteur correspondant, le Quadtree récupère les différents positions occupées par celui-ci et enlève ces enregistrements. Ceci pouvant être à l'origine de mises à jour de la structure interne du Quadtree. L'identifiant du capteur est alors transféré au sous-arbre d'identifiants pour qu'il enlève la référence. Le sous-arbre capteur peut alors être détruit.


Figure 46 : Modification d'enregistrement multiversion lors d'une suppression

T0 T1 T2 T3

<[T0;T3[;IDC;Liens

C>

<[T0;T1[;IDC;Liens

C>

<[T2;T3[;IDC;Liens

C>

Enregistrement d'origine

Supression données sur [T1;T2[

Enregistrements finaux


5.2.2.4.5 Coût de la structureLes coûts de construction et d'accès du PasTree multiversion sont fonction de plusieurs éléments. En premier lieu, le taux d'agilité des capteurs influe sur le nombre d'enregistrements. En effet, plus ce taux croît, plus le nombre d'enregistrements maintenus par les différents quadrants croît.

Le coût de construction d'un Quadtree, pour N données (positions spatiales) à indexer, est de l'ordre de O N∗profondeur maximale du quadtree Dans le cas d'une distribution uniforme, cela devient O N log N

Dans notre cas, il convient d'introduire l'impact de l'agilité. Ainsi, le nombre de données à indexer, P (le nombre de positions différentes prises par les capteurs) est-

il de l'ordre de P=∑i=0

C Di

a iavec C le nombre de capteurs, Di le nombre de

mesures collectées par le capteur i et ai le taux de mobilité du capteur i. Dans le cas d'une distribution uniforme de ces points, et en introduisant un facteur d'attractivité b représentant la propension à utiliser des points déjà définis (repassage au même endroit, capteurs qui se suivent à la même position), on obtient un coût de construction du Quadtree seul de l'ordre de OP log 1−b∗P avec b tendant vers 1 lorsque l'attractivité des points croît (le nombre de points utiles est faible et les capteurs tendent à circuler entre ces positions spatiales). L'aspect multiversion ajoute un surcoût. Ainsi la mise à jour doit aussi prendre en compte le nombre d'enregistrements des chacun des quadrants du Quadtree. Dans le cas d'utilisation le plus courant cependant, l'accès concerne le premier enregistrement de la liste (enregistrement en vie). La taille de la liste est fonction de l'attractivité des différents points définis et du taux d'agilité des capteurs. Lorsque b tend vers 0, le nombre d'enregistrements tend vers 1. Lorsque b tend vers 1, c'est à dire lorsque les capteurs ont tendance à simplement échanger leurs places, le nombre d'enregistrements tend vers D∗a , avec D le nombre total de données et a l'agilité moyenne des capteurs.

L'accès aux données s'effectue de manière plus simple. Le coût d'accès à une donnée est alors, dans le cas d'une répartition uniforme de l'ordre de O log Pauquel s'ajoute le coût de parcours de la liste des enregistrements.

En somme, le sous-arbre spatial est un Quadtree multiversion qui permet la gestion de l'aspect agilité grâce à l'ajout d'enregistrements marquant les intervalles de validités d'un point dans un quadrant. Comme son homologue le sous-arbre d'identifiants, sa principale tâche est de permettre l'accès aux sous-arbres capteurs qui contiennent effectivement les mesures collectées par les capteurs.

5.2.2.5 Le sous-arbre capteur

Le sous arbre capteur (cf. figure 47) est chargé d'indexer et de conserver toutes les données relatives à un capteur particulier. Il conserve aussi bien les mesures prises que d'autres informations, tel son identifiant ou la liste des positions prises.



5.2.2.5.1 Réutilisation du sous-arbre capteur du PoTree, avec quelques ajouts

Le sous arbre capteur est basé sur celui développé pour le PoTree auquel une gestion des positions des capteurs a été ajoutée. Ainsi, sa structure reprend l'utilisation d'un B+Tree pour une indexation temporelle des données collectées. Un niveau d'abstraction de données supplémentaire complète la structure afin de différencier les mesures des changements de positions.

La racine du sous-arbre capteur (cf. figure 48) est composée d'une racine d'arbre B+Tree à laquelle ont été adjoints quelques champs supplémentaires. Comme pour le PoTree, un lien avec le dernier nœud permet de diminuer le coût d'accès aux données les plus récentes, également celles les plus souvent requises. La conservation de l'identifiant du capteur entre dans la politique de conservation de l'ensemble des données relatives à un capteur dans la structure de celui-ci. Dans la même optique, un lien vers la dernière position connue permet de rapidement déterminer la position actuelle à partir d'une interrogation basée sur l'identifiant du capteur. Ces différents ajouts permettent de gérer des requêtes issues d'une des deux structures d'accès portant sur des informations concernant l'activité ou l'état immédiat du capteur. Ils ne permettent pas en soi la gestion de la mobilité. Celle-ci est permise grâce au niveau d'abstraction des données.

5.2.2.5.2 Niveau d'abstraction au niveau des données : mesure / mouvement

Les données du PasTree portent sur les mesures collectées mais également sur les différentes positions occupées par le capteur. Dans le PoTree, les données collectées dans le B+Tree portaient uniquement sur les mesures. Un capteur fixe ne conservait pas sa position au sein du sous-arbre capteur. Pour le PasTree, la gestion de l'agilité


Figure 48 : Structuration de la racine de l'arbre capteur

Identificateur Noeud Racine Dernier Noeud Position

Figure 47 : Structure du sous-arbre capteur

T1-T27 Position

T13-T14

Position

T10-T18

T19-T27

T1-T3 Position

T4-T6Position

T7-T9Position

T10-T12

Position

T1-T9

T15-T18

Position

T19-T21

Position

T22-T24

Position

T25-T27

Position

DonnéeMvt Pos.DonnéeDonnée Mvt

Pos.Donnée


des capteurs implique que les capteurs sont potentiellement appelés à changer de position. Dès lors la nécessité de conserver un historique des positions antérieures impose certaines modifications au niveau de l'arbre capteur du PasTree.

Un niveau d'abstraction permet de différencier mesures et positions. Ainsi, les deux types de données conservées peuvent être stockées dans la même structure, le B+Tree modifié. Une mesure de capteur peut être représentée sous la forme d'un marqueur temporel servant à l'indexation et d'un lien vers la donnée elle-même. Un changement de position doit comporter plus d'éléments. Il doit conserver la date de ce changement de position mais également un lien vers un enregistrement contenant la nouvelle position ainsi qu'un lien vers l'ancienne position.

Une mise à jour de la position du capteur est dans notre cas accompagnée d'une mise à jour de données. Cependant quelques cas rares peuvent ne concerner que le changement de position, par exemple lors d'une mise à jour manuelle via l'identifiant du capteur.

Deux enregistrements peuvent avoir la même date. Puisque la date associé à une donnée est utilisée pour l'indexation (dans l'ordre temporel croissant), et puisqu'une différenciation entre changement de position et mesures est effectuée, il est possible qu'une même date soit liée à deux données de type différent. Une donnée sera de type mesure tandis que l'autre sera de type changement de position. Le mode de mise à jour de la structure fait en sorte de placer la mise à jour spatiale avant la mesure collectée dans le B+Tree.

Les deux types de données doivent être différenciés au niveau du B+Tree (cf. figure 49). Ainsi, la taille des nœuds étant fixe et le formalisme prédéterminé, il est possible de tirer profit des différences entre les types. La taille d'une entrée est fixe et correspond à la taille d'une date et d'un pointeur vers les données. Cette taille peut varier en fonction des systèmes utilisés. Une date peut être considérée comme un type double sur 8 octets. Un pointeur, ou une référence java ont généralement des tailles inférieures ou égales (4 octets sur un système 32 bits). Un changement de position peut alors être conservé comme un enregistrement de date suivi directement complété d'octets de « bourrages » remplis à 1. Cette référence particulière servant à marquer la présence d'un changement de position et à assurer une compatibilité de taille entre les deux types d'enregistrements. Par la suite sont introduits le lien vers la position actuelle et les liens vers les enregistrements


Figure 49 : Structuration des nœuds de l'arbre capteur

Liens Fils Liens Parent

Structure des noeuds internes du sous-arbre temporel

Temps Noeuds


Structure des noeuds feuille du sous-arbre temporel

Lien Parent PositionDonnées

Temps Mesure

Temps Position Précédent Suivant

Enregistrement de mesureChangement de positionBourrage


changement de position précédent et suivant. De cette manière, un enregistrement de mesure occupe moitié moins de place qu'un enregistrement de position. Cependant, la définition d'agilité suppose que le nombre de changements de positions soit inférieure à celui de mesures. Ainsi la perte d'espace mémoire occasionnée par ce processus est contrebalancée par le fait qu'une seule structure puisse conserver les mesures et les positions.

En somme, une donnée dans la structure de l'arbre peut être une mesure ou un enregistrement vers un changement de position. Les mesures sont les plus nombreuses aussi la structure de l'arbre capteur tend à accélérer l'accès à celles-ci. Les changements de positions occupent plus d'espace, notamment du fait de liens vers les enregistrement de même type précédent et suivant, créant ainsi une liste chaînée. Le surcoût induit permet cependant une gestion de l'agilité des capteurs au sein de l'arbre de capteur.

5.2.2.5.3 La gestion de la position au sein du B+TreeLa position du capteur est un élément clef de l'arbre capteur. Bien que les requêtes basées sur l'évolution des positions occupées par celui-ci ne composent qu'une infime partie des requêtes adressées à cet arbre, il doit être capable d'y répondre. De plus, ce type de requêtes peut aussi bien porter sur des mouvements récents que sur des mouvements plus anciens. La gestion du suivi de ces changements de position se divise en deux niveaux : une liste chaînée des mouvements et l'enregistrement de la dernière position valide à l'intérieur d'un nœud feuille.

Les enregistrements de mouvement sont chaînés entre eux pour permettre un suivi des positions occupées par le capteur. Ce chaînage permet de répondre à des requêtes de type « Suivre le capteur entre l'instant T1 et l'instant T2. » Mais ce chaînage ne permet pas de repérer directement l'intervalle recherché. Une fois de plus, on parcourt la structure ou on utilise le lien avec le denier nœud feuille de la structure (celui contenant les données les plus récentes) afin de repérer la fin de l'intervalle considéré. Une autre particularité des nœuds feuilles pour repérer la position est alors utilisée.

Chaque nœud feuille contient un lien vers l'enregistrement de changement de position marquant la position du capteur à la date de fin de nœud (cf. figure 50). En d'autre termes, pour connaître la position du capteur à la fin de l'intervalle temporel couvert par un nœud feuille, il suffit de suivre le lien proposé. Pour connaître la position du capteur à un instant précis, il suffit de trouver le nœud correspondant, l'enregistrement de changement de position adéquat et de comparer avec la date recherchée. Si besoin, il est possible de remonter dans l'ordre des changements de


Figure 50 : Lien entre le nœud et la position du capteur

Changement de position

Noeud

Lien entre différentes positions

Temps

Lien vers la position valide du noeud


positions afin de trouver la position valide à la date recherchée. Les liens entre les enregistrements sont ainsi mis à contribution pour remonter dans la liste temporelle des positions occupées. Le mécanisme est décrit plus précisément dans le chapitre qui suit.

En somme, la gestion des positions repose sur deux éléments : une liste chaînée d'enregistrements de changements de positions et un lien au niveau des nœuds permettant d'accéder à l'enregistrement marquant la position du capteur en fin de nœud. A partir de ces deux éléments il devient possible de suivre un capteur particulier, de déterminer sa position à un instant précis, ou d'une manière plus globale, d'accéder aux informations spatiales relatives au capteur.

5.2.2.5.4 Accès aux donnéesLes processus permettant d'accéder aux données sont calqués sur ceux décrits pour le PoTree. Il s'agit d'utiliser dès que possible le lien entre la racine et le dernier nœud feuille de la structure afin de diminuer le coût d'accès aux structures. Lors des requêtes d'accès, un premier test permet de vérifier si les données recherchées se situent dans le dernier nœud. Si tel est le cas, celui-ci est directement accédé. Pour les requêtes portant sur des intervalles temporels, la fin de celui-ci est recherchée en premier lieu. Cependant, les modifications effectuées sur la structure de l'arbre imposent quelques changements à la résolution de ces requêtes.

La différenciation des types de données introduit une phase de vérification supplémentaire. En effet, à chaque accès aux données, il convient de vérifier si la donnée est de type mesure ou bien changement de position. Cette vérification s'effectue en comparant le champ suivant directement la date servant à l'index. Si ce champ est composé de bits de bourrages, l'enregistrement porte sur un mouvement. Les octets suivants sont mis de coté puisqu'ils référencent les positions précédentes. La lecture du nœud reprend à l'enregistrement suivant.

Les enregistrements recherchées (de type <capteur;date;mesure>) sont reconstruits directement à partir de cet arbre. Dans le PasTree, l'arbre capteur comporte toutes les informations relatives au capteur et aux mesures qu'il a effectuées. Alors que dans le PoTree l'arbre capteur ne comportait qu'une dimension temporelle et les mesures collectées, le PasTree ajoute également l'enregistrement de la position du capteur. Il devient ainsi possible de reconstruire un enregistrement <temps;capteur;mesure> directement à partir de cette structure si besoin est.

L'accès aux données relatives à la position du capteur s'effectue en suivant un processus proche de celui observé pour les mesures. Le mécanisme est illustré par la figure 51. Une première comparaison permet de vérifier l'appartenance temporelle de l'enregistrement recherché au dernier nœud de la structure. Si tel est le cas, ce nœud est directement accédé. Dans le cas contraire, l'arbre est parcouru en suivant les techniques utilisées dans le parcours d'un B+Tree.



Lorsque le nœud est atteint, le lien vers la dernière position connue est utilisé (cf. figure 52). Il permet d'obtenir l'enregistrement du dernier mouvement précédent la fin du nœud. En comparant la date de cet enregistrement avec la date ou avec la fin


Figure 51 : Accès à la position d'un capteur pour une date déterminée

Figure 52 : Accès à la position du capteur à une date déterminé à partir d'un nœud

Changement de position

Noeud

Lien entre différentes positions

Temps

Lien vers la position valide du noeud

Date de recherche de position

1: Accès à la position en fin de noeud

2: Comparaison Date de requête / Date d'enregistrement3: Remontée récursive dans

les enregistrements


de l'intervalle temporel recherché il est possible de s'assurer de la validité de cette position. Le liens vers l'enregistrement de position précédent peut être utilisé si le premier est postérieur à la date recherchée. Il devient dès lors possible d'utiliser ces liens pour remonter dans la liste temporelle des positions occupées par le capteur.

Ainsi, l'accès aux données tire toujours profit de l'utilisation du lien direct entre la racine et le dernier nœud feuille. Les ajouts effectués à l'arbre capteur du PasTree n'ont eu qu'une influence limitée sur celui-ci. Il en va différemment pour la politique de mise à jour.

5.2.2.5.5 Les mises à jourIl existe deux types de mises à jour, illustrées dans la figure 53. Celles concernant les mesures sont similaires à celles du PoTree en tout point. Une comparaison permet de vérifier l'appartenance de la donnée à ajouter au dernier nœud feuille afin de limiter le coût d'accès au nœud à mettre à jours. L'arbre global du B+Tree n'est parcouru que si cette mise à jour concerne un autre nœud.

Les mises à jour concernant les changements de positions nécessitent un processus plus complexe. Elle commence une fois encore par rechercher le nœud dans lequel se trouve la donnée à insérer. Puis une comparaison des dates est effectuée à l'aide du lien entre la racine et le dernier nœud. Lorsque le nœud dans lequel est réalisée la mise à jour est déterminé, le processus utilise le lien vers la position en fin de nœud. On obtient alors l'enregistrement contenant le pointeur vers la dernière position reconnue dans le nœud. En utilisant les liens vers les positions précédentes et suivantes, le processus détermine les enregistrements de changement de position encadrant l'instant correspondant à la mise à jour. En cas de mise à jour incrémentale, le processus n'utilise que l'enregistrement antérieur. Le processus crée le nouvel enregistrement en exploitant ces différents liens vers les positions antérieures et postérieures, le lien vers la position actuelle et la date correspondant à la mise à jour. L'enregistrement est inséré dans le B+Tree. En cas de mise à jour rétroactives, il est nécessaire de créer un second enregistrement de changement de position lié à la date de mesure suivante pour rétablir le positionnement correct du capteur. De fait, ce sous-processus n'est normalement jamais mise en œuvre dans la mesure où les changements de positions, tout comme les mesures sont indexées de manière incrémentale.

En raison de la double taille de l'enregistrement de changement de position, le processus de mise à jour doit être modifié. Ainsi le processus de séparation du nœud, split, doit conserver l'unité de cet enregistrement. Sa taille est double, il compte donc pour deux dans le calcul de la taille du nœud, mais la mise à jour conserve l'unité de ce type d'enregistrement.

Le processus de mise à jour de la position du capteur est généralement accompagné d'un enregistrement de mesure à la même date. Les deux mises à jours s'enchaînent. En premier lieu la mise à jour spatiale, puis celle de mesure. Ainsi, en cas de split du nœud, si celui-ci a lieu de telle sorte à séparer les enregistrements de changement de position et de mesure, l'enregistrement spatial est transféré dans le nœud gauche tandis que la mesure est transférée dans le nœud droit. Les liens entre les nœuds et la dernière position valide sont mis à jour le cas échéant.



La mise à jour s'effectue en cherchant le nœud dans lequel doit être réalisée


Figure 53 : Processus de mise à jour de l'arbre capteur


5.2.2.5.6 Suppression de donnéesLa suppression de données s'effectue en cherchant le nœud correspondant à la fin de l'intervalle de suppression, comme pour une recherche de donnée classique. Une fois cet intervalle déterminé, les mesures sont éliminées les unes après les autres en remontant dans le nœud et en utilisant les liens entre les nœuds feuilles. Le processus utilise la politique de suppression de données utilisée avec un B+Tree. La gestion des changements de positions impose quelques particularités.

Lorsque des données sont éliminées, le processus prend note des changements de position. Un changement de position n'est éliminé que si l'enregistrement qui le suit est également un changement de position. Si un regroupement de nœuds feuille est effectuée, les liens de position active en fin de nœud sont mis à jour le cas échéant.

En somme, le processus de suppression distingue les mesures des changements de positions. La suppression de données concerne en premier lieu les mesures. Les positions sont modifiées si aucune mesure ne subsiste entre cet enregistrement et le changement de position suivant. Ce processus alourdit la gestion de la structure mais permet la gestion de l'agilité des capteurs et la résolution de requêtes selon des aspects multicritères.

5.2.2.5.7 Aspect mathématiqueD'un point de vue mathématique, les coûts d'utilisation de la structure de capteur du PasTree hérite de celle du PoTree. Il convient cependant d'y ajouter l'impact de l'agilité des capteurs.

Le coût de construction de l'arbre de capteur reprend celui du PoTree. Dans le cas général, en prenant en compte le fait qu'une mise à jour de position est suivie d'une mise à jour de donnée, le coût de construction est de :

On1a11− p 1s1

log np ss1

avec a le taux d'agilité des capteurs, n le nombre de données, p la probabilité pour que la mesure concerne les données les plus récentes et s le nombre de données pouvant tenir dans un nœud. (1+a) symbolise le surcoût lié à la gestion du changement de position. A chaque insertion le processus commence par vérifier si la mise à jour est réalisée dans le dernier nœud (1 de la seconde parenthèse). Si la donnée ne concerne pas des données récentes, ce qui arrive avec une probabilité de (1-p), la mise à jour est similaire à celle d'un B+Tree normal, donc de coût log(n). Lorsque la mise à jour concerne les données les plus récentes, avec une probabilité

p, la mise à jour s'effectue directement en ajoutant la donnée s

s1 . Cependant,

lorsqu'un nœud est rempli et qu'un split a lieu, il convient de mettre à jour la

structure interne du sous-arbre de capteur 1s1

log n .

Le coût d'accès aux données reprend également le même calcul lié à celui du PoTree. Le coût d'accès à des plages de données doit prendre en compte les même paramètres.



O 1−p log ns pt

On a ici p la probabilité pour que les données cherchées concernent les données les plus récentes, n le nombre de données contenues dans le sous-arbre, s le nombre de données pouvant tenir dans un nœud et t le nombre de données à retourner. Une fois de plus, le processus commence par vérifier si la donnée se trouve dans le dernier nœud. De là, à une probabilité de (1-p), l'accès s'effectue selon la règle habituelle du B+Tree. Avec une probabilité p, l'accès s'effectue directement au dernier nœud. Il faut alors rajouter le coup d'accès aux différentes données de la plage recherchée.

5.2.3 Exemples de requêtesLe PasTree permet la résolution de requêtes telles que celles définies pour le PoTree, des requêtes spatio-temporelles. En outre, il prend en charge l'agilité des capteurs ainsi qu'un accès multicritères. Les données peuvent être accédées aussi bien en fonction de critères spatiaux qu'en fonction des identifiants de capteurs.

Les requêtes les plus courantes sont une fois de plus les mises à jour. Celles-ci peuvent s'effectuer en utilisant l'un des deux arbres d'accès : spatial ou d'identifiants. Dans le premier cas, elles prennent la forme <Position du capteur; identifiant de capteur; date de la mesure; valeur de la mesure> Dans le cas d'une mise à jour par l'arbre d'identifiants, la partie position du capteur peut être omise.

Dans le cas d'une mise à jour par identifiant, le processus commence par rechercher une référence afin de déterminer le sous-arbre capteur correspondant. Si aucune référence n'est obtenue, la création d'un nouveau capteur est lancée. Dans le cas d'une mise à jour spatiale, un premier parcours de l'arbre spatial permet de vérifier si le capteur est déjà défini au point de la mise à jour. Si tel est le cas, le sous-arbre capteur correspondant est à son tour mis à jour. Dans le cas contraire, une requête sur le sous-arbre d'identifiants permet d'atteindre ce sous-arbre pour une mise à jour de la position et de la mesure. Si l'identifiant n'est pas encore référencé, un nouveau sous-arbre capteur lui est dédié. Le sous-arbre spatial est alors mis à jour pour prendre en compte la position du capteur.

Les mises à jour sont courantes mais leur formalisme est relativement limité. Les accès aux données sont plus variés. Ils peuvent porter sur les mesures (cas général) mais également sur les capteurs eux-mêmes.

● Les requêtes spatiales peuvent porter sur des positions précises ou sur des zones spatiales.

● La partie temporelle des requêtes porte sur des instants précis ou sur des intervalles temporels.

● L'ajout du critère d'identifiant permet d'accroître les possibilités d'interrogation de la structure en se fondant sur les identifiants de capteurs dont la position reste à déterminer.

Les requêtes peuvent porter sur les mesures effectuées, sur les positions ou les identifiants des capteurs, mais peuvent également permettre de suivre les positions



d'un capteur. De plus, l'utilisation d'un Quadtree permet également d'effectuer des requêtes concernant les voisins les plus proches.

Parmi les types de requêtes possible, on peut distinguer :





« Trouver les données issues du capteur 'RI001' entre les instants T1 et T2. »

« Trouver les identifiants des capteurs situés dans la zone définie entre les points <X0;Y0> et <X1;Y1> entre les instants T1 et T2. »

« Trouver l'identifiant du capteur le plus proche du capteur 'RI001' au temps T. »

« Trouver la position du capteur 'RI001' à l'instant T. »

« Suivre le capteur 'RI001' entre les instants T1 et T2. »

« Suivre le capteur situé au point <X;Y> à l'instant T entre les instants T1 et T2. »

« Calculer la valeur en <X;Y> à l'instant T, par interpolation depuis les capteurs et les mesures les plus proches spatialement et temporellement. »

5.2.4 Implémentation et testsDifférentes séries de tests ont été effectuées sur la structure du PasTree. La première série de tests portait principalement sur des données générées aléatoirement tandis que la seconde série reprenait des données batch de sismographes du réseau de surveillance japonais K-Net [33].

Le langage Java (VM Sun 1.4.2) a été utilisé pour coder la structure de l'arbre, fonctionnant sur un PC disposant de 256 Mo de RAM et d'un processeur Athlon XP de 1,3 GHz.

Parmi les facteurs testés, on a pu s'intéresser plus particulièrement à l'influence du nombre total de capteurs ainsi qu'à leur agilité, le taux de changements de positions entre deux prises de mesures. L'influence du nombre de positions différentes utilisées a également été étudiée.

Des comparatifs ont été effectués avec d'un coté le PasTree et de l'autre le PoTree et le R*-Tree. Le code source de [23] a été utilisé pour le R*-Tree.

Plusieurs séries de tests ont été menées. La première utilisait des données générées aléatoirement afin de correspondre à différents cas d'utilisation. On y a fait varier le nombre de capteurs, leurs positions et leur agilité. La seconde série de tests utilisait des données issues des sismographes du K-Net, correspondant à différents séismes enregistrés par ces capteurs. Dans ce cas particulier, l'agilité des sismographes était



nulle; ils ne bougeaient pas. Les résultats obtenus avec les données réelles ont confirmé ceux issus de données aléatoires.

La figure 54 nous montre l'influence du nombre de points à indexer sur le temps de construction de la structure. Le test a été effectué avec les données sismographiques réelles provenant de 68 capteurs fixes. On peut remarquer une augmentation pratiquement linéaire du temps de construction. Dans cet exemple, il n'y a pas de changement de position des capteurs. Par conséquent les capteurs sont placés dans le sous-arbre spatial basé sur un Quadtree. Par la suite, lorsque le Quadtree est créé, l'ajout de données à indexer ne fait que traverser cette sous-structure pour vérifier qu'il n'y a pas eu de changement de position. Au niveau des sous-structures de capteurs, la première opération effectuée consiste à vérifier si la mise à jour concerne les données les plus récentes. C'est ici toujours le cas. On obtient donc un temps de traitement linéaire correspondant au test avec les dernières données de l'arbre et à la mise à jour de la dernière feuille. Il n'y a que lorsque la feuille est remplie que la mise à jour doit procéder à une étape de partage de nœud et de réagencement de la sous-structure.


Figure 54 : Temps de construction du PasTree en fonction du nombre de données à indexer pour 68 stations fixes

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41

0

50

100

150

200

250

300

350

400

450

500

550

Nombre de points (x1000)

Tem

ps (m

s)


Des tests complémentaires ont été effectués pour connaître l'influence des changements de positions sur le temps de construction (figure 55). Ces tests ont été effectués sur des données générées aléatoirement. 100 capteurs et 10000 données en tout ont été exploitées, soit l'équivalent de une seconde de mesure pour un réseau de capteurs à 100 Hz. On remarque que plus l'agilité des capteurs augmente, plus le temps de construction de l'index augmente également. L'agilité s'évalue sur une échelle de 0 à 1. Ce facteur est donc à prendre en compte pour déterminer le nombre maximal de capteurs indexables dans le système. On a ainsi pu constater que le PasTree peut indexer jusqu'à 600 capteurs immobiles et 300 capteurs avec une mobilité supérieure à 50%. Par comparaison, le PoTree pouvait gérer dans des conditions analogues 1200 capteurs immobiles. Cependant cette structure ne permettait pas la gestion des changements de position des capteurs.

Tout comme pour le PoTree, notons que le PasTree peut être victime d'un phénomène d'étouffement du système. Alors que le nombre de requêtes à résoudre croît et que les ressources disponibles (données, mais également cycles processeur et espace mémoire) diminue, les différentes transactions concurrentes participent à l'étouffement du système. Les ressources sollicitées par de nombreux processus sont à l'origine de nombreuses demandes de verrous, libération de verrous, redémarrage de transactions. Toutes ces activités génèrent à leur tour de nouveaux sous-processus qui finiront à terme par étouffer le système dans son ensemble. La figure 28, page 108 illustre ce phénomène. Ainsi, alors que notre système était capable de gérer les mises à jour de quelques 600 capteurs fixes, il convient de diminuer ce nombre dans un système réel subissant des contraintes supplémentaires (différents types de transactions, autres services ou « daemons » actifs,...).


Figure 55 : Influence du taux d'agilité sur le temps de construction du PasTree, avec un nombre de capteurs et de données fixes.

0.0 0.050.1 0.15

0.2 0.250.3 0.35

0.400.45

0.5 0.550.6 0.65

0.7 0.750.8 0.85

0.9

0

50

100

150

200

250

300

350

400

450

500

550

Taux d'agilité des capteurs

Tem

ps d

e cr

éatio

n (m

s)


En poursuivant la comparaison entre le PoTree et le PasTree, nous étudions à présent le temps de construction. Comme l'indique la figure 56, le PoTree est 3 à 4 fois plus rapide à construire que le PasTree. Cependant il est notable que les fonctionnalités du PoTree sont très limitées par rapport à celles du PasTree. Le PasTree prend en charge la gestion d'un certain niveau de mobilité des capteurs, les requêtes spatio-temporelles ou basées sur les identifiants de capteurs, etc. La structure du PasTree offre plus de variété au niveau de son mode d'utilisation. Le coût est donc augmenté au niveau de la création et de la mise à jour de la structure. Cependant le temps de construction du PasTree reste largement inférieur à celui du R*Tree. En effet, le PasTree utilise la notion de source d'information, réunissant les données issues d'un même capteur dans une sous-structure commune. Contrairement au R*Tree, les données ne sont pas ici considérées comme indépendantes les unes des autres mais liées par leurs sources. Il ne devient donc plus nécessaire de devoir placer les données dans un espace à 4 dimensions (3 spatiales et 1 temporelle). Il suffit de placer d'un coté les données spatiales, puis de l'autre les données temporelles dans des sous-structures différentes, sans avoir à reconstruire l'arbre global.


Figure 56 : Temps de construction PoTree / PasTree en fonction du nombre de points à indexer pour 68 capteurs fixes

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39

0

50

100

150

200

250

300

350

400

450

500

550

PasPo

Nombre de points X1000

Tem

ps (m

s)


La figure 57 présente le temps de recherche pour une requête de type fenêtre / intervalle. On a pris ici des données réelles issues de 68 capteurs fixes. La requête récupère les derniers 10% des données entrées sur l'ensemble du domaine spatial. On notera que le PoTree et le PasTree offrent des performances assez proches et plus intéressantes que le R*Tree. Une fois de plus ceci peut s'expliquer par l'utilisation qui est faite des sous-structures de capteurs, réunissant les données issues d'une même source au sein d'un même arbre. Alors qu'un R*Tree doit prendre en compte l'ensemble des données pour répondre à une requête, le PasTree se contente de sélectionner les sous-arbres correspondant et d'interroger ceux-ci. De plus, puisque les données recherchées étaient les plus récentes, le PasTree a pu tirer profit du lien direct entre la racine et la dernière feuille de ses sous-arbres, économisant ainsi du temps. La différence d'accès entre PoTree et PasTree ne prend que partiellement en compte les différences entre les structures. En effet, le test a porté sur des capteurs fixes. Le surcoût lié à la gestion de l'agilité des capteurs du PasTree est gommé. En contrepartie, les performances d'accès supérieures du PasTree tendent à lui donner un avantage sur le PoTree. Le Quadtree multiversion se montre en effet légèrement plus rapide que le kd-tree.

En somme, le PasTree offre une solution d’indexation de données permettant la gestion de critères spatio-temporels. Il permet également une compatibilité avec les modes d’utilisation de la base reposant sur des identifiants de capteurs. Le PasTree gère un certain niveau d’agilité des capteurs. Tous ces apports au PoTree ont cependant un coût. Bien que cette structure soit encore plus rapide que le R*-tree, le PasTree est dans l’ensemble plus lent que le PoTree, du fait de sa structure plus imposante, en raison d'une certaine redondance d’informations.


Figure 57 : Temps de résolution d’une requête de recherche sur une fenêtre spatiale / intervalle temporel en fonction du nombre de données contenues dans la base.

1 3 5 7 9 11 15 19 23 27 31 35 39

0102030405060708090

100110120130140150160

PoTreeR* TreePasTree

Nombre de données (X1000)

tem

ps (m

s)


5.2.5 PasTree : conclusionLe PasTree est un arbre d'indexation pour bases de données spatio-temporelles centralisées liées à un réseau de capteurs agiles. Il permet d'indexer les mesures collectées en fonction des capteurs émetteurs et des dates de mesures. Il permet en outre de conserver un historique des positions occupées par les capteurs. Il offre un accès multicritère aux données tout en valorisant les mises à jours et l'accès aux données les plus récentes. Il permet également un vaste panel de requêtes.

Le PasTree utilise plusieurs sous-structures collaborant entre elles. Deux sous-structures d'accès permettent de déterminer le capteur concerné par la résolution d'une requête. Chaque capteur est lié à un sous-arbre capteur qui lui est propre.

La première sous-structure d'accès est un arbre d'identifiants, assimilable à un B+Tree, dont la tâche première est de permettre un accès aux données par l'intermédiaire de l'identifiant de capteur. La compatibilité avec les anciens modes d'utilisation des systèmes de surveillance est ainsi maintenue.

La seconde sous-structure d'accès est un arbre spatial multiversion, basé sur un Quadtree. Il permet un accès aux données par l'intermédiaire de critères spatiaux.

Les différents arbres capteurs sont des versions améliorées des arbres du même nom utilisé dans le PoTree. Il s'agit d'arbres basés sur des B+Tree indexant les données d'un capteur en particulier en fonction de l'instant de la prise de mesure. Un lien direct entre racine et dernier nœud feuille permet la valorisation des données les plus récentes.

Cet arbre a été enrichi par l'ajout de différents champs qui permettent de garder l'ensemble des données relatives aux mesures mais aussi au capteur. Identifiant et position sont ainsi conservés.

La gestion de l'agilité des capteurs est assurée par l'introduction d'une couche d'abstraction supplémentaire. Les données sont ainsi divisées en mesures prises et données de changements de positions. Ces dernières sont conservées et forment une liste chaînée permettant d'établir la position occupée par un capteur à un instant donné.

Les tests effectués ont permis de montrer l'efficacité du PasTree pour la gestion de capteurs temps-réels agiles. Plus lourd que le PoTree, tant en temps de construction qu'en espace mémoire, il offre cependant des temps d'accès aux données du même ordre de grandeur. Tous deux montrent des résultats supérieurs aux R*Tree auquel ils ont été comparés.

En somme, le PasTree est une solution permettant l'indexation de données issues d'un réseau de capteurs agiles et offrant un accès multicritères aux données. Lorsque ces facteurs doivent être retenus lors de la mise en place d'un système de surveillance de phénomènes, le PasTree se distingue de ses autres concurrents. Le PoTree sera choisi dans l'indexation de mesures issues de capteurs fixes et avec un accès aux données strictement spatio-temporel. Le PasTree le sera lorsque la versatilité, le nombre de types de requêtes et la nature des données incluent certaines spécificités propres aux capteurs agiles.



5.3 Conclusion sur l'indexation de données issues de capteurs agiles

Ce chapitre a permis de mettre en avant les caractéristiques de l'utilisation d'un réseau de capteurs agiles pour la surveillance de phénomènes. Alors que la majorité des systèmes d'indexation actuels se centre sur des définitions spatiales et sur l'utilisation de R-Tree, la réalité des réseaux de capteurs impose l'utilisation d'autres solutions.

Les systèmes d'indexation existants peuvent se diviser en plusieurs catégories. Alors que certains index portent presque uniquement sur la gestion de trajectoires, d'autres permettent la gestion d'un espace par zones d'activité. Une autre division permet de distinguer les index permettant un travail sur les données passées ou présentes voire futures.

La majorité de ces systèmes reposent sur l'utilisation de R-Tree. Ceux-ci souffrent des mêmes déboires que leurs parents gérant des données fixes : besoin de prendre en compte l'ensemble des données pour la résolution d'une requête, difficultés à réagir aux contraintes temps-réelles d'un réseau de capteurs, valorisation des données les plus récentes. Bien que certaines solutions permettent une subdivision par zones, seules quelques tentatives liées à la gestion des trajectoires permettent un rapprochement des données en fonction du capteurs d'origine.

Quand bien même l'utilisation de ces index serait retenue, leur nature purement spatio-temporelle est source de difficultés. En effet, suite à de nombreuses années d'utilisation de systèmes basés sur les identifiants de capteurs, certains chercheurs peuvent éprouver certaines difficultés à intégrer un mode de recherche de données purement spatio-temporel. De plus, l'emploi de capteurs pouvant se déplacer peut amener à de nouveaux mode d'accès aux données mêlant identifiants et position occupées (suivit de déplacement,...) Dès lors, les solutions actuellement proposées se révèlent insuffisantes.

Le PasTree pallie ces manques en apportant une approche multicritères et un niveau d'abstraction supplémentaire entre mesures et changements de positions. A l'instar du PoTree, il regroupe les données issues d'un même capteur au sein d'une sous-structure dédiée. D'autres sous-structures d'accès permettant de déterminer quel capteur est concerné par la résolution d'une requête.

Cette structure répond aux critères de l'indexation en mémoire vive de données issues d'un réseaux de capteurs temps-réel. Cependant il ne permet pas de prendre en compte un autre critère lié cette fois ci à l'architecture même de la base de données : la gestion de la saturation mémoire. En effet, alors que le système est appelé à gérer des masses importantes de données, il convient d'utiliser des mécanismes particuliers quant à la gestion de la mémoire disponible au niveau de la base de données gérant les requêtes sur le court-terme.



Bien que les systèmes actuels disposent de méthodes de duplication de données ou de transfert vers des entrepôts de données, un gain d'efficacité notable pourrait être obtenu par l'intégration de ces problématiques de gestion de mémoire dès la conception de l'index de la base.




De cape et de crocs - L'archipel du danger - © Delcourt

La gestion de la saturation

6 La gestion de la saturation

Alors que les PoTree et PasTree offrent tous deux des solutions d'indexation pour des bases de données en mémoire vive, liées à des réseaux de capteurs temps-réel respectivement fixes et mobiles, aucune ne permet une prise en charge de la saturation de la base de données dès la définition de l'index.

Dès lors, l'objectif de ce chapitre est de présenter les particularités de la gestion de la saturation d'une base de données au niveau de son index. Plus particulièrement, ce chapitre présente le StH (SpatioTemporal / Heat), une structure d'indexation visant à combiner les particularités de l'indexation de données issues d'un réseau de capteurs avec la gestion de la saturation de la base.

Une brève introduction présente le contexte général avant d'aborder le StH, son contexte d'utilisation, la notion de chaleur de données que celui-ci utilise, sa structure et son fonctionnement.



6.1 Contexte général

Une base de données liée à un réseau de surveillance doit assurer une prise en charge d'une masse importante de données. Si certains capteurs n'envoient des mesures que de manière très sporadique, d'autres peuvent fonctionner avec des fréquences de l'ordre de la centaine de hertz ou davantage. Dès lors, la masse de données à indexer entraîne un risque réel de saturation de la base de donnée.

Les systèmes de gestion de base de données tendent à laisser la gestion de la saturation aux bons soins d'un processus annexe. Cette gestion apparaît dès lors comme une couche supplémentaire de la base.

Le transfert d'une partie des mesures contenues dans la base de données vers un entrepôt, pour la résolution de requêtes à plus long terme, implique le besoin de gérer certains cas particuliers.

Les requêtes sur les données peuvent porter sur un ensemble de données partagées entre la base et l'entrepôt. Dès lors, plusieurs modes de résolution des requêtes sont possibles.

Il convient en premier lieu de déterminer si la résolution des requêtes implique l'utilisation d'un sous-processus particulier, collectant les résultats relatifs aux données de la base et de l'entrepôt avant de les transmettre au client ou bien si ces résultats sont directement envoyés au client. La première alternative implique un temps de latence, du fait de transferts réseaux supplémentaires mais permet la gestion de multiples sources d'informations et un filtrage des résultats en doublon. En effet, si les résultats sont directement envoyés à l'utilisateur, le risque d'envoi des doublons n'est pas nul. Si un processus de réplication des données n'efface pas celles-ci de la base dès la fin du transfert, la donnée originelle est dédoublée.

Ce dédoublement de données est parfois recherché, comme c'est généralement le cas dans les systèmes distribués. Des algorithmes basés sur les cordes7, tels GHT [62] permettent alors une localisation de mesures dupliquées et ainsi une interrogation des sources de données en fonction des positions géographiques et de la disponibilité des différents systèmes impliqués.

Le transfert des données en lui-même peut être problématique. La principale difficulté liée à la gestion de la base correspond à trouver le bon compromis entre le vidage la base et la conservation des données collectées...

En premier lieu, lors du vidage, il convient de déterminer s'il est préférable de vider la base, donnée par donnée ou bien bloc par bloc. Ceci peut également s'exprimer comme étant le choix du compromis du coût de la transmission des données vers

7Une corde peut être créée par la linéarisation de données : les données sont plaquées sur un espace à une dimension, une corde. Ceci peut être obtenu grâce à une fonction de hachage. Par la suite, il est possible de définir sur la même corde la position de différents centre de stockage des données (via le hachage de leurs adresses IP par exemple). En fermant la corde de manière à former un cercle, il devient possible d'établir des règles imposant par exemple que les mesures doivent être stockées dans le centre de stockage dont la position sur la corde (la valeur de hachage) est la plus proche de la position de la mesure.



l'entrepôt de données. Pour limiter ce coût, il est préférable de vider par bloc. De même, il convient de pouvoir paramétrer le taux de vidage et la taille des blocs émis. Un taux trop élevé de vidage et les requêtes reçues risquent de porter sur des données non présentes dans la base. De même un taux mal adapté et le système risque de perdre trop de ressource en gestion de vidages successifs.

Il est ainsi nécessaire de pouvoir déterminer l'instant auquel vider la structure. Trois politiques émergent :

● Un vidage à intervalles réguliers est aisé à mettre en œuvre, cependant en cas de pic d'activité, il ne prévient pas un blocage de la structure.

● Un vidage après contrôle de la taille de mémoire système qui peut encore être allouée permet d'obtenir un réglage plus fin du transfert, mais nécessite un accès à des fonctions du système.

● Un vidage en fonction du nombre de données entrées permet de limiter le coût d'interrogation du système. Cependant, si d'autres processus sont en activité il demeure un risque de blocage du système.

Une fois les données vidées, le problème de la résolution des requêtes gagne en importance. Si celles-ci recouvrent des données contenues partiellement par l'entrepôt, les deux structures (base et entrepôt) doivent alors collaborer pour fournir une réponse. La base de données peut être utilisée pour fournir une réponse partielle dans des temps courts, l'entrepôt fournissant des données plus complètes, avec un temps de réponse plus important. On retrouve donc la notion de réponse partielle, répondant à des critères de « meilleur effort » pour des requêtes temps-réel.

La résolution de requêtes est liée à l'utilisation de l'index de la base. Le paragraphe suivante comporte un aperçu a priori exhaustif des solutions d'indexation de bases de données spatio-temporelles prenant nativement en compte la gestion de la saturation de la base.

Il semblerait en effet que bien que la plupart des bases de données commerciales proposent des solution de transfert de données vers différents entrepôts ou vers d'autres bases, aucune ne prenne en compte la gestion de la saturation de la base de données dès la mise en place de l'index. Le problème, bel et bien réel, doit pour l'heure se contenter de solutions basées sur des architectures distribuées ou sur la réplication classique de bases de données. Le StH propose d'ouvrir la voie dans le domaine.



6.2 Le StH

Le StH, SpatioTemporal / Heat, est un système d'indexation pour bases de données spatio-temporelles centralisées en mémoire vive, travaillant sur des données issues d'un réseau de capteurs agiles et prenant en compte la saturation de la base [55]. Les mesures sont référencées en fonction du capteur (position / identifiant) dont elles sont issues, de la date de la mesure, et du résultat d'une fonction de chaleur qui permet de déterminer l'importance de la mesure. Cet index offre un accès multi-critère aux données : à la fois spatio-temporel mais également basé sur les identifiants de capteurs. De plus, il utilise la notion de chaleur de données, relative à leur importance, pour établir une liste des mesures à transférer en priorité vers un entrepôt de données.

6.2.1 Contexte d'utilisationLe PoTree permet d'indexer des mesures issues d'un réseau de capteurs fixes, ponctuels. Les données collectées sont ainsi référencées en fonction de la position fixe du capteur dont elles sont issues ainsi que de la date de la mesure. Le PoTree permet donc un accès spatio-temporel aux données collectées. Le PasTree introduit la notion d'agilité des capteurs, ainsi que la possibilité d'accéder aux données selon différents critères. Ces deux approches, centrées sur les capteurs rassemblent les données dans des sous-structures capteurs dédiées et favorisent aussi bien les requêtes de mise à jour que l'accès aux mesures les plus récentes. Elles répondent ainsi aux attentes classiques des systèmes de surveillance de phénomènes basés sur des capteurs. Cependant ces deux index ne prennent pas en charge la gestion de la saturation de la base de données.

6.2.1.1 Rappels sur les besoins liés aux bases de données capteurs

Les PoTree et PasTree ont mis en avant les besoins liés à l'utilisation d'un système d'indexation pour bases de données liées à un système de surveillance de phénomènes naturels ou urbains. A des années d'utilisation de systèmes basés sur des identifiants de capteurs sont venus s'ajouter une utilisation de plus en plus fréquente de capteurs agiles référencés spatio-temporellement. Ainsi, un système d'indexation pour base de données liée à une telle architecture doit prendre en considération ces nouvelles spécificités :

● Travail dans une base de données en mémoire vive

● Utilisation des aspects spatio-temporels ou sur des identifiants capteurs pour les requêtes / mises à jours







● Conservation de la trace des anciennes positions prises par les capteurs.

Ajout de la notion d'observations

Les PoTree et PasTree visaient à l'indexation de données issues de capteurs. Cependant, certains systèmes de surveillance ont recours à des observations de terrain, ces observations portant sur des zones et non plus des points spatiaux. Lors d'un glissement de terrain, des géologues peuvent établir une carte rapportant les zones sensibles. Il s'agit de séries d'observations non-issues de capteurs. Cependant, dans l'optique d'une centralisation des données, ces observations doivent également être conservées au sein de la base / entrepôt de données. Un capteur fictif peut être associé à certains types d'observations. La position liée à ce capteur fictif devient alors la zone concernée par l'observation. La gestion des observations s'ajoute ainsi aux spécificités définies pour la PasTree et à la gestion de la saturation de la base de données.

6.2.1.2 Les spécificités de la gestion de la saturation

Les capteurs peuvent collecter des mesures avec des fréquences pouvant atteindre les 200 Hz ou plus. Outre le besoin d'une collecte et d'une indexation rapide de ces données, il est également nécessaire de prendre en compte l'espace mémoire occupé. Le risque d'écroulement, d'étouffement du système est réel. Les performances d'un systèmes se dégradent de manière exponentielles lorsque la quantité de ressources systèmes disponibles passe sous un certain seuil. Ce seuil dépend de l'architecture de la machine, de son système d'exploitation, des différentes services, daemons actifs,...

Les bases de données collectant des mesures d'un réseau de capteurs travaillent généralement en mémoire vive afin de limiter le coût d'accès aux informations et ainsi améliorer les performances temps-réel du système. Ces bases sont en outre couplées à des systèmes de stockage de masse, des entrepôts de données, utilisés pour les analyses de données sur long terme. Il existe des procédures de transfert de données entre la base et l'entrepôt. Ces procédures sont généralement lancées à intervalle temporels réguliers. Elles permettent ainsi de limiter les risques de saturation de la base de données. Elles forment généralement un sous-système venant s'accoler à la base originelle. Les processus mis en œuvre pour ce basculement de données ne sont que rarement intégrés à la mécanique interne de la base et génèrent un surcoût d'utilisation non négligeable. Le StH pose comme a priori une intégration des besoins liés au transfert de données entre la base et l'entrepôt de données dès la construction de l'index. Ceci permet une gestion de la saturation efficace de la base. Le but fixé pour l'utilisation d'une base de données



pour la gestion des données à court terme demeure de permettre une mise à jour et un accès aux données pertinentes dans des délais limités.

6.2.1.3 Considérations sur l'importance de données

Toutes les mesures collectées ne sont pas d'égale importance. Il est possible de considérer une fonction d'importance des données (fonction C, aussi appelée « fonction de Chaleur ») dont la valeur croît lorsque la valeur informative de la donnée croît (donnée plus « chaude »), comme montré en figure 58. Le but premier de la base de données est alors de conserver les données possédant la plus forte valeur de C. Il ne s'agit pas nécessairement des données les plus récentes, mais plutôt des données jugées plus informatives, celles que l'utilisateur doit pouvoir accéder en priorité. Les autres données sont tour à tour transférées vers un entrepôt de données.

Certaines mesures sont fortement porteuse d'information tandis que d'autres se contentent, au mieux de rappeler ces premières mesures. Les scientifiques qui utilisent les données collectées s'accordent généralement pour reconnaître que leur intérêt premier va à l'étude de l'évolution des mesures, ou à la comparaison des évolutions de différentes mesures. Ainsi, la perte d'une mesure est acceptable si cela n'influe pas sur l'évolution globale des autres données. De même, un classement de l'importance des données peut être effectué, généralement sur le taux d'évolution entre deux mesures. Plus cette évolution est importante (plus la probabilité pour laquelle la donnée soit porteuse d'information intéressante croît) et plus il convient de la conserver dans la base de donnée pour des analyses. La détermination de la valeur de C associée à une mesure particulière doit donc prendre en compte les mesures précédentes. Il s'agit là d'un facteur de prime importance à la détermination de C.

Un autre facteur de l'importance des données provient du délai écoulé depuis la dernière donnée jugée « chaude. » En effet, du fait des possibilités de panne de capteur ou bien encore de par la possibilité d'un lent dérèglement de certains capteurs, la valeur de la fonction C croît lorsqu'aucun pic de valeur n'est détecté


Figure 58 : Exemple de chaleur de données liée à un signal continu

Temps

Temps

Signal

Chaleur Associée

Mesure

Chaleur


pour cette fonction. Deux mesures d'un capteur à 100 Hz sont temporellement séparées d'un centième de seconde. Si les deux mesures sont du même ordre de grandeur, la perte de la seconde, bien que potentiellement dommageable est généralement considérée comme acceptable par les utilisateurs, à la condition qu'ils puissent accéder à la première. Deux mesures issues d'un capteur n'effectuant qu'une mesure par semaine ont des charges informatives supérieures, quand bien même la seconde mesure est similaire à la première. En effet la valeur informative associée à la valeur collectée s'associe à l'information sur l'état de fonctionnement du capteur.

Alors que le phénomène précédent permet un accroissement de la valeur de C, un autre phénomène provoque un décroissement. Lorsque le temps s'écoule, la valeur informative associée à une valeur décroît. Une donnée importante hier l'est un peu moins aujourd'hui et le sera moins encore demain. Cette logique s'applique pour les systèmes de surveillance, et pour les données liées à la base de données en mémoire vive. En effet celle-ci est utilisée pour des analyses à court terme. Par conséquent, au niveau de cette base, ce sont les données les plus récentes qui sont prépondérantes. En reprenant l'étude de la fonction F, on observe une propension à une perte de valeur d'une donnée avec l'écoulement du temps.

L'étude d'un signal discret peut donner un exemple de fonctionnement (cf. figure 59). Soit S un signal carré. Les valeurs mesurées alternent entre les valeurs +V et -V toutes les T secondes. A l'instant d'origine, 0, le signal est à +V. Toutes les mesures collectées dans l'intervalle [0;T[ indiqueront cette même valeur. La première mesure effectuée est porteuse d'une information forte dans la mesure où elle informe l'utilisateur de la valeur associée au signal étudié. Les valeurs suivantes indiquent que le signale n'évolue pas. Le première mesure possède une charge informative importante. Les suivantes ont des charges moindres. Cependant, avec le temps qui s'écoule, et en supposant un intervalle entre les mises à jour long, la possibilité d'une panne du capteur doit être prise en compte. Ainsi les mesures collectées indique l'état du système mesuré, mais également l'état du système mesurant. La valeur informative de la mesure croît alors quelque peu du fait de


Figure 59 : Exemple de chaleur associée à un signal carré

Temps

Temps

Signal

Chaleur Associée

Mesure

Chaleur


l'écoulement du temps. A cette croissance vient s'ajouter la perte progressive d'information liée à l'écoulement du temps. Savoir qu'à un instant 0+ε la mesure valait +V devient lentement de moins en moins intéressant pour une analyse sur l'état actuel du système. En somme, à T- ε , la valeur informative de la mesure a atteint un équilibre, la chaleur associée prend une valeur basse signifiant que la valeur n'a pas évolué depuis longtemps. Puis d'un coup, à T, le signal passe de la valeur +V à la valeur -V. La valeur informative de la première mesure suivant ce passage est importante puisqu'elle dénote une évolution forte. On observe un pic dans le graphe de fonction de chaleur de la valeur. Puis, lorsque les mesures suivantes indiquent chacune -V, la valeur d'importance décroît rapidement, reprenant le schéma développé dans l'intervalle de temps [0;T[.

Dernier cas pouvant influer sur la valeur de C : la présence de données caractéristiques. Un système de surveillance de phénomène permet dans de nombreux cas d'utilisation de reconnaître certaines phases d'activités spécifiques à des phases d'activités particulières. La phase précédent une éruption volcanique, bien que spécifique à chaque volcan, est parfois plus ou moins aisément reconnaissable. Le vulcanologue, dans son analyse du système peut être amené à comparer les mesures collectées avec celles spécifiques à une phase d'activité particulière. Plus le nombre de ces comparaison croît, et plus l'importance associée à ces données croît. Ces données spécifiques peuvent ne pas porter une charge informative individuelle forte, mais sur une évolution des mesures.

On notera que s'il est possible d'automatiser l'association entre une charge informative et une donnée particulière en fonction des autres données collectées précédemment ou du temps écoulé, la classification par rapport à des données caractéristiques d'une activité doit généralement s'effectuer manuellement. Bien que certains systèmes simples permettent une découverte de telles mesures type dans des jeux de données, la nature des systèmes étudiés (tectonique des plaques, climatologie, flux humain à la sortie des écoles...) est généralement complexe et demande une intervention humaine pour reconnaître des phases d'activités spécifiques.

En résumé, il est donc possible de représenter l'importance d'une mesure selon une fonction de valeur informationnelle. Cette fonction prend en compte l'écoulement temporel et l'évolution des données pour déterminer les mesures qui sont les plus intéressantes pour des systèmes de traitement et d'analyse. Il convient donc de faciliter l'accès à ces données, en prenant en compte la base de données.

6.2.1.4 La structure du StH

Le StH est un index pour base de données capteurs centralisée, en mémoire vive, gérant l'agilité des capteurs et la saturation de la base. Le StH permet en outre un accès multi-critère aux données. Il indexe les positions des différents capteurs et les temps des mesures effectuées. Cette définition du StH rapproche cet index du PasTree. Les ajouts de la gestion de la saturation et la gestion de zones spatiales influent cependant sur la définition de la structure du StH.

Le StH utilise plusieurs sous-structures (figure 60). A chaque capteur est lié une sous-structure capteur dédiée. Celle-ci, appelée par la suite sous le nom



Figure 60 : Structure globale du StH

« d'escalier » en raison de sa forme, conserve toutes les informations relatives à un capteur (identifiant, historique des positions et liens vers les mesures prises). A cette structure s'ajoutent deux sous-structures d'accès dont le rôle est d'identifier les escaliers concernés par la résolution d'une requête. Elles permettent une résolution des requêtes selon des critères spatiaux ou selon les identifiants des capteurs.

La première structure d'accès est similaire à l'arbre d'identifiants utilisé dans le PasTree. Des rôles similaires, des modes d'utilisation analogues ont conduit à une réutilisation de la structure.

La seconde sous-structure réutilise le concept du multi-version déjà présent dans l'arbre spatial du PasTree. Le besoin de gestion de zones impose cependant des modifications dans la structure. Le Quadtree brille dans la gestion de données issues de points, mais un accroissement des dimensions, pour couvrir des zones, suppose l'utilisation d'une structure plus adaptée. Un R-Tree multi-version est par conséquent utilisé pour le StH.

La gestion de la saturation choisie suppose l'utilisation de fonctions de chaleur. Une fonction est liée à chaque capteur, à chaque escalier. Plusieurs fonctions peuvent ainsi coexister dans un StH. En effet, certains types de capteurs peuvent être liés à une fonction particulière tandis que d'autres utilisent des fonctions différentes. Une même fonction ne sera pas utilisée pour des données provenant de sismographes et d'autres provenant d'anémomètres. De la pertinence de la fonction dépend en grande partie l'efficacité de la gestion de la saturation.


Escalier CapteurOID position

Escalier CapteurOID position

R-treeMult iversion

T début / T finOID

Arbre spatial R-tree multiversion

Ident ifiants

OID OID OID

OID OID OID

Arbre des identifiants de capteur

Escalier Capteur: index des données issues d'un capteur particulier

MBR 3MBR 2MBR 1

MBR 3.1 MBR 3.2 MBR 3.3

Temps

Chaleur de la Donnée

Data DataMvt


La gestion de cette saturation implique le transfert des données les plus froides vers l'entrepôt de données. Les données sont ainsi régulièrement transférées depuis les escaliers capteurs vers l'entrepôt. Plusieurs critères peuvent être utilisés pour déclencher ce processus. Celui retenu est un simple compte de données entrées. A chaque capteur est associé un nombre de données maximum. Ce choix implique une connaissance a priori de la taille des données, ainsi que l'attribution d'une zone de mémoire réservée. Si plusieurs services utilisent la même machine que la base de données, la zone de mémoire occupée par celle-ci doit lui être réservée sous peine de saturation.

Cette structure centrée sur les capteurs offre une plus grande versatilité dans la définition de ceux-ci. Ainsi, à chaque escalier peut correspondre une fonction de chaleur particulière ainsi qu'une taille maximale et une hauteur d'escalier propres. Certains escaliers peuvent comporter un petit nombre de liens vers des données tandis que d'autres peuvent atteindre des hauteurs bien plus conséquentes.

6.2.1.4.1 Métaphore du jardinL'analogie du jardin botanique a été suivie pour le PoTree et le PasTree. Les anciens adages impose la poursuite de cette pratique pour le StH, la troisième structure proposée. Le jardinier en chef du jardin « PoTree » avait dessiné un plan à l'entrée et laissait les visiteurs se promener librement. Celui du « PasTree », plus industrieux avait ajouté un index alphabétique des essences présentées dans le jardin. Il avait également pris l'habitude de mettre à jour le plan (tout en conservant les anciens) lorsque l'envie lui prenait de déplacer une plante à grand coup de pelle.

Le « StH » est le dernier jardin à la mode, où aiment se rassembler les étudiants en hydrographie sélénitique, histoire de la dentisterie gallinacée, théorie des séparés (en complément de la théorie des ensembles) et autres matières liées à la tétrapilectomie.

Le jardinier en chef du « StH » est ambitieux. Après une visite à son voisin du « PasTree, » il a décidé de viser une clientèle quelque peu différente : plus pressée, voulant voir les essences les plus intéressantes sans s'extasier devant un brin d'agropyron repens (chiendent). Il a également décidé de présenter des plantes qui tallent (couvrent une zone de terrain plus grande, exemple : un bosquet). Mais surtout il a pris contact avec un membre de l'Office national des eaux et forêts afin d'organiser un roulement dans les essences présentées.

A l'entrée du jardin, on retrouve le même index alphabétique que chez son homologue du « PasTree. » Cependant la carte des lieux est ici différent. Puisque certaines plantes tallent, la carte porte à présent des points pour des plantes isolées, mais aussi des zones pour les talles. Bien sûr, un historique des plans passés est toujours disponible. Le jardinier aime lui-aussi changer l'emplacement de ses essences dans son jardin à coups de pelle.

Lorsqu'une plante arrive, elle est identifiée selon son essence et une cote marquant l'intérêt supposé qu'auront les utilisateurs pour celle-ci. La détermination de la fonction permettant de déterminer cette cote est confiée à un tiers, spécialiste de l'essence en question. La plante peut dès lors être présentée au public.

Après un temps plus ou moins long en fonction de l'essence, de la place disponible dans le jardin et de la cote de la plante, celle-ci est retirée par le jardinier et



expédiée à son associé de l'office des eaux et forêts. Dans les parcs « PoTree » et « PasTree » cette tâche était déléguée à un tiers qui n'avait pas toujours la politesse d'informer à l'avance de son arrivée, et qui risquait de ne pas passer au moment adéquat.

Armée de sa nouvelle recette, le parc « StH » peut ouvrir ses portes.

En somme, le StH s'appuie sur l'utilisation conjointe de trois types de structures : deux sous-structures d'accès assurant un accès multi-critère et multi-version aux données collectées et une sous-structure capteur collectant toutes les informations liées à un capteur particulier. L'utilisation de ces sous-structure est rendue transparente pour l'utilisateur par le biais d'une interface.

6.2.1.4.2 L'interfaceL'interface a pour but de rendre transparent l'utilisation du StH, à l'instar de celle du PasTree (cf. figure 61). L'utilisateur (humain ou processus) ne doit pas avoir à se soucier de la structure interne de l'index. L'interface du StH reprend en cela les principes de celle du PasTree. De facto, cette interface en est une copie à laquelle ont été rajoutées différentes primitives permettant une gestion des spécificités propres au StH.

Les nouvelles primitives concernent la gestion de la saturation. Une série de primitives permet une définition plus précise des éléments servant à la création de l'escalier capteur (hauteur de l'escalier, nombre de données, fonction de chaleur). D'autres primitives permettent d'intervenir directement sur ces escaliers. Certaines données peuvent explicitement être déclarées comme intéressantes (« chaudes ») par l'utilisateur. Il s'agit alors de primitives permettant la déclaration et la suppression de ces données, ainsi que l'accès à celles-ci. Les autres modification apportées aux primitives ont pour but de permettre l'utilisation de données liées à des zones et non plus simplement à des points particuliers.

La structure de l'interface n'agit cependant pas directement sur les escaliers capteurs. Elle utilise le biais des sous-structures d'accès.

6.2.1.4.3 La sous-structure d'accès d'identifiantsL'arbre d'identifiants du StH doit répondre aux mêmes impératifs que son homonyme du PasTree. Pour rappel, il est utilisé pour permettre un accès aux


Figure 61 : Rôle de l'Interface

Interface

Arbre spatial Arbre d'identifiants

Requêtes Utilisateurs

Transfert d'uneRequête

Communication entre arbres d'accès


données à partir d'un critère en particulier : l'identifiant du capteur ayant effectué la prise de mesure.

● Cet arbre indexe les différentes sous-structures capteurs en fonction de leurs identifiants. Tout capteur est doté d'un identifiant et toute mesure est liée à un capteur. Ainsi, toutes les mises à jours du StH sont susceptibles d'utiliser les spécificités de l'arbre d'identifiants.

● Cette sous-structure indexe les identifiants des capteurs pour permettre un accès rapide aux données relatives à ceux-ci.

● On suppose l'existence d'un plan d'attribution des identifiants basés sur des critères géographiques ou selon le type de capteur référencé. En effet, des réseaux de capteur tel celui du K-Net inclus des références relatives à la zone géographique où se trouve le capteur. Il devient ainsi possible de déterminer la position a priori d'un capteur, où tout du moins la région dans laquelle il collecte des mesures. Il est ainsi possible d'interroger des capteurs en fonction de cette dénomination afin d'accéder aux données relatives à une région particulière. Pour des interrogations plus précises, l'utilisation de listes de capteurs (liant un identifiant et des coordonnées géographiques) plus précises reste possible.

● On suppose que les requêtes sur des ensembles de capteurs peuvent tirer parti du plan d'attribution des identifiants. En effet, ces requêtes peuvent porter sur un ensemble de capteurs issus d'une zone géographique particulière ou bien d'un type particulier de capteurs (séismographes, clinomètres,...).

La sous-structure capteur du StH répond aux mêmes impératifs que celle du PasTree et utilise les mêmes à priori. Ainsi, il a été choisit de réutiliser la même structure d'accès par identifiants. L'arbre d'identifiants prend la forme d'un B+Tree qui indexe les identifiants de capteurs et pointe vers les sous-structures de données correspondantes. Plus de détails sur cette structure sont disponibles dans le chapitre correspondant à son homologue du PasTree.

En somme, le sous-arbre d'identifiants du StH doit répondre aux mêmes impératifs que celui du PasTree. Il utilise la même représentation d'un capteur et les mêmes a priori. Par conséquent la structure utilisée pour le StH est similaire à celle du PasTree. Cette sous-structure d'accès est un des principaux legs du PasTree au StH. L'autre sous-structure d'accès a également été marquée par l'impact du PasTree mais l'ajout de nouvelles contraintes a demandé une révision de son mode de fonctionnement.

6.2.1.4.4 La sous-structure d'accès spatialLa structure d'accès spatial est la seconde des deux sous-structures d'accès du StH. Son rôle est d'identifier les escaliers liés à la résolution d'une requête et de transférer à ceux-ci les requêtes utilisateurs.

La sous-structure d'accès spatial du StH s'appuie sur les techniques multi-version décrites avec le PasTree. Cependant, le besoin de gérer des zones spatiales a mis en évidence les avantages liés aux R-Tree. Ces structures sont en effet mieux adaptées à la gestion de zones et d'espaces spatiaux.



Pour rappel, un R-Tree est assimilable à un un ensemble de boîtes. Les objets, capteurs ou zones, sont définis en fonction de leur zones d'encombrement minimal (MBR : la plus petite boite dans laquelle peut rentrer l'objet). Ces MBRs sont regroupés dans des MBRs plus grands, à l'instar de poupées russes. Celles-ci peuvent contenir un certain nombre d'objets. Au delà, le MBR est subdivisé en deux MBRs fils, dans lesquelles sont réparties les données internes.

Lors de l'ajout d'une donnée, la politique de création du R-Tree consiste à trouver le MBR pouvant inclure le nouvel objet en minimisant l'accroissement de taille du MBR père. Si le nombre de données dépasse le seuil admissible, le MBR est alors subdivisée en deux MBRs fils, dans lesquels sont répartis les objets englobés.

La suppression de données peut amener à supprimer des MBRs intermédiaires si le nombre de données qu'ils contiennent passe sous un seuil de regroupement de MBRs. Dans ce cas, le processus de suppression de données tente de réduire la taille du R-Tree en enlevant les MBRs superflus.

Les algorithmes utilisés pour coder le sous-arbre spatial du StH correspondent à un R*Tree. Cette structure tente d'utiliser des MBRs de forme approximativement carrées. De fait, la mise à jour du R*Tree est plus complexe mais l'accès aux données s'en trouve facilité.

Le nombre de mises à jour spatiales reste généralement limité dans les réseaux de surveillance de phénomènes. Bien que les mises à jours émises par capteurs soient nombreuses, les déplacements demeurent moins fréquents. Alors que les R*Tree connaissent des baisses de performances lorsque le nombre de données s'accroît, cette séparation mise à jour spatial / mesure effectuée permet de limiter cet impact.

L'aspect multi-version est géré via une série d'enregistrements liés aux MBRs de données (cf. figure 62). Les MBRs normalement attachés aux objets comportent un niveau d'abstraction supplémentaire, sous la forme d'une liste d'enregistrement. Chacun de ceux-ci est de la forme <Tdébut; Tfin; Identifiant; Capteur> où Tdébut indique le début de l'intervalle pendant lequel le capteur est référencé à la position du MBR, Tfin la fin de cet intervalle. Identifiant et Capteur correspondent à l'identifiant du capteur et à un lien vers la sous-structure capteur appropriée.

En somme, ce R-Tree multi-version permet de gérer les spécificités liées aux capteurs agiles ainsi que les spécificités liées à l'enregistrement d'observations sur des zones. Il reprend les principes exposés pour son homonyme du PasTree en y ajoutant la spécificités de la gestion de zones. Le nombre relativement restreint de données spatiales, en rapport au nombre total de données à traiter, assure des performances de mise à jour et d'accès logarithmiques, en fonction du nombre de positions définies.

Les deux sous-structures d'accès utilisées permettent de restreindre la portée de la résolution d'une requête en restreignant celles-ci à un sous-ensemble de structures capteur. La gestion de la saturation de la base de données prend réellement son essence au niveau de ces derniers.


Figure 62 : Structure d'un enregistrement multi-version

IdentifiantTemps FinTemps Début Arbre Capteur


6.2.1.4.5 La sous-structure capteurLes deux sous-structure d'accès du StH arborent des liens de parenté avec leurs homologues du PasTree. Il n'en est pas de même avec la structure capteur, parfois appelée escalier. Cette structure originale permet de prendre en compte les particularités liées à la gestion de la saturation de la mémoire.

Une analogie entre cette structure et un escalier mécanique permet de mieux comprendre le principe de gestion de données capteur (cf. figure 63). A leur arrivée dans la structure, une « chaleur » leur est attribuée. Celle-ci correspond à l'intérêt porté pour la donnée. Plusieurs politiques peuvent être utilisées mais toutes partagent un point commun : les données les plus intéressantes se voient attribuer des chaleurs plus importantes. Une fois la température attribuée, la donnée est placée dans la marche la plus haute (« la plus grande de l'escalier »), qui correspond à la marche où sont conservées les données les plus récentes. Chaque marche est composée d'un empilement d'écailles. Chaque écaille correspond à une classe de chaleur de données : toutes les données possédant une chaleur proche sont classées dans la même écaille. Les données les plus intéressantes (les plus chaudes) se situent en haut de cet empilement. Lorsqu'un nombre de données par marche est atteint, le processus de déplacement de l'escalier est effectué. La plus basse écaille de chaque marche est transférée vers un entrepôt de données, les écailles restantes sont décalées d'un cran vers le bas et une nouvelle marche complète est ajoutée, dans laquelle les nouvelles données seront insérées. Le StH ressemble donc à un escalier mécanique, vidant progressivement ses données les moins intéressantes vers un entrepôt de données. Une fois cette analogie explicitée, il convient cependant de détailler plus précisément l'escalier du StH.

La structure de l'escalier du StH (cf. figure 64) comporte plus d'éléments que ceux cités dans l'analogie avec un escalier mécanique. Il se compose d'un ensemble de marches, elles-même représentées par des piles d'écailles, mais il convient d'ajouter une écaille spéciale pour la gestion des données à conserver « au chaud, » dans la structure, ainsi qu'une liste de positions afin de conserver un historique des déplacements du capteur. En effet, à l'instar de son homonyme du PasTree, la sous-structure capteur du StH vise à conserver toutes les données relatives à un capteur. Les données sont indexées dans cet escalier tandis que les différentes positions,


Figure 63 : Représentation de l'escalier capteur

Température de la Donnée

Temps

T1…………T2 T3….………T4 T5…………T6 T7…………T8

Froid

Chaud

Ecaille

Marche


l'identifiant et autres éléments primordiaux sont également conservés. De fait, il est possible de découper l'escalier en plusieurs sous-éléments liés.

Figure 64 : Structure de l'escalier capteur

Le nombre d'écailles et la taille de celles-ci sont spécifiées à la création de l'escalier, de même que la fonction de chaleur à utiliser. Tous les escaliers d'un même StH ne disposent pas nécessairement du même type d'escalier. Des valeurs par défaut peuvent cependant être utilisées pour les cas plus génériques. A la création, la racine de l'escalier est créée et l'espace mémoire des différentes marches est réservé.

La racine de l'escalier

La racine du StH (cf. figure 65) comporte différents champs permettant une résolution des requêtes les plus courantes. Outre l'identifiant du capteur associé à l'escalier, le champ suivant, change position est un bitmap d'une longueur égale au nombre de marches. Il sert à indiquer si un changement de position a eu lieu dans une marche donnée. Ces champs sont complétés par le nombre de données conservées, la taille globale de la structure en mémoire, un lien vers la liste des dates de début de chacune des marches puis un lien vers la liste des marches elles-même. Enfin, un dernier lien permet d'atteindre un tableau de marqueurs temporels et son écaille propre, l'écaille spéciale « chaude » où sont conservées les données à maintenir dans l'escalier.

On remarque une différenciation entre le nombre de données et la taille en mémoire. Il convient de différencier les mesures issues d'un capteur temporairement fixe des mesures collectées suite à un déplacement du capteur. Le StH visant à conserver l'historique des déplacements, les notifications des déplacements sont intégrées à l'escalier, augmentant ainsi la taille de celui-ci. La taille globale de la structure peut s'estimer à : CrNm∗CmCeCeNdNdc ∗CdNp∗Cp avec Cr le coût de création de la racine, Nm le nombre de marches (également le nombre


Figure 65 : Structure de la racine de l'escalier

Identif iant Liste des Marches

Ecaille spécialechaude

Débuts Temps des Marches

NombreDonnées TailleChange

PositionTemps ecaille

chaudeEcaille chaude

Structure de la racine de l’Escalier Capteur

Identif iant Liste des Marches

Ecaille spécialechaude

Débuts Temps des Marches

NombreDonnées TailleChange

Position

Données

Structure d’une marche de l’Escalier

Structure d’une écaille de l’Escalier

Dif férentiel Temps

Numéro Ecaille

Bitmap Mouvement

Liste Ecailles

TailleDonnées

ListeMouvements

Temps ecaillechaude

Ecaille chaude

NombreDonnées

CompteurEcailles


d'écailles), Cm et Ce les coûts mémoire de conservation d'une structure de marche et d'écaille (le +Ce de la formule provient de l'écaille spéciale chaude), Nd le nombre de mesures, Ndc le nombre de mesures explicitement chaudes, Cd le coût de maintient d'une mesure (le coût d'utilisation d'un lien), Np le nombre de positions et Cp le coût de maintient d'une position (variant selon qu'il s'agisse d'une position 2D ou 3D). En somme, les performances du StH sont liées en partie au taux d'agilité des capteurs.

Le champ pointant vers la liste des temps de début de marche est utilisé lors de la résolution de requêtes afin de déterminer quelle marche interroger. Les données sont insérées de manière incrémentale mais portent toutes un marqueur temporel. Tous les capteurs n'étant pas périodiques, et certaines mesures pouvant être éliminées du fait d'erreur de transmission ou pour respecter des contraintes temps-réel, la conservation de ces informations temporelles est donc nécessaire. Les données d'une marche sont toutes incluses dans un intervalle temporel déterminé. Un tableau de longueur Nm est utilisé pour conserver les marqueurs temporels de début de marche. Ces données peuvent prendre plusieurs formats selon le système d'exploitation utilisé. Une mesure temporelle peut généralement être représentée sous le type long (64 bits). C'est le lien vers ce tableau qui figure dans la structure de l'enregistrement central de la racine de l'escalier. L'utilisation d'un tableau se justifie par le constat suivant : l'accès à des données contiguës d'un tableau est plus rapide que via une liste chaînée de valeur. Ceci se conçoit simplement en se représentant le tableau comme une entité monobloc en mémoire. Ainsi, l'accès à des données du tableau peut s'effectuer en lisant les différents secteurs contigus de la mémoire (localité séquentielle). Les politiques de pré-fetching [37], de pré-chargement des données peuvent ainsi permettre des économies de temps d'accès. A contratio, l'utilisation de pointeurs implique que les données puissent se situer en des localisations diverses. Les données ne sont pas nécessairement contiguës en mémoire. Les technique de pré-chargement des données ne peuvent fournir de résultats suffisants.

De même que le champ de 'Début Temps Marches' initiales des marches correspond à un lien vers un tableau, le champ 'Liste de Marche' correspond à un lien vers un tableau contenant des liens vers les différentes marches. Là encore, le nombre de pointeurs a été minimisé pour tirer profit de l'exploitation de tableaux. Le tableau en question est utilisé pour accéder aux différentes marches, puis aux écailles que celles-ci contiennent; à l'exception de l'écaille contenant les données explicitement chaudes.

Cette dernière écaille « artificiellement chauffée » est en effet référencée à partir de la racine de l'escalier. Chaque écaille est assimilable à une liste de données sans référence temporelle, c'est pourquoi il est nécessaire d'inclure un tableau de marqueurs temporels permettant l'accès aux données.

Les données situées dans les écailles des différentes marches vont progressivement refroidir et être transférées à l'entrepôt de données. Il est cependant parfois nécessaire de conserver certaines données sur un intervalle temporel plus long. Il s'agit alors de données dont l'accès doit avoir lieu de manière prioritaire, utilisées pour des comparaisons avec des données récentes par exemple. Ces données sont explicitement copiées dans l'écaille chaude accessible à partir de la racine de



l'escalier. Les données spécifiques d'un type d'activité du système surveillé peuvent ainsi être conservées sur de longs intervalles temporaires via cette écaille.

On notera que les données sont placées / accédées / enlevées de cette écaille de manière explicite par l'utilisateur. Ceci impose un nouveau type de requêtes de type « CONSERVER données entre les instants T1 et T2. » De même, les données ne sont pas déplacées depuis leurs marches d'origine mais recopiées depuis celles-ci. Cette redondance d'information augmente momentanément la taille de la structure (jusqu'au transfert des données originelles) mais n'induit pas le besoin de rechercher au sein de cette écaille spéciale pour les résolution de requêtes banales. Cette marche particulière n'est accédée que pour la résolution de requêtes concernant des intervalles temporels en dehors de celui recouvert par l'escalier ou par le biais de requêtes explicites « CHERCHER_DONNEES_CHAUFFEES les mesures entre les instants T1 et T2. » Cette écaille explicitement chauffée est la seule à ne pas appartenir à une marche mais à être directement liée par un lien (pointeur ou référence java) à la racine de la structure.

L'utilisation alternée de pointeurs et de tableaux dans l'enregistrement de la racine permet d'accélérer l'accès aux données. Les tableaux ne sont pas directement inclus dans l'enregistrement racine mais sont accédés via des liens. Ceci a pour but de limiter le coût d'accès à l'intégralité de l'enregistrement racine. En fractionnant celui-ci, le système de gestion de mémoire cache du système d'exploitation ou du système de gestion de la base de données peut se contenter de charger uniquement les parties effectivement accédées. Les études sur le CSB+Tree [60] et ses descendants [34] [70] [69] ont montré l'intérêt d'utiliser des données de taille similaires ou multiple de la taille des lignes de mémoire du système.

En somme, la partie racine de l'escalier capteur comporte différents champs permettant d'identifier le capteur et d'accéder aux différentes mesures collectées par celui-ci. L'utilisation de tableaux permet de référencer les différentes marches où les données sont indexées de manière incrémentales, en fonction de leurs chaleurs et des dates de mesures. Une écaille particulière est référencée au niveau de la racine. Celle-ci peut comporter des données explicitement marquées comme intéressantes par les utilisateurs. Ces données sont des copies des mesures contenues dans les marches et ne peuvent être supprimées de la structure que par un appel explicite de l'utilisateur. Cette écaille permet de conserver des données sur de plus long termes et reste en dehors de la politique de gestion des marches.

Les marches de l'escalier et les écailles

Les marches sont composées d'un empilement d'écailles (cf. figure 66) . Chaque écaille correspondant à une classe de chaleur de mesure. Plus la mesure est intéressante, chaude, plus elle se trouve en hauteur dans la pile. La marche représente plus qu'un simple empilement de sous-structures. La gestion de l'agilité des capteurs repose sur les marches pour conserver un historique des positions passées du capteur. De fait, l'enregistrement central d'une marche comporte plusieurs champs. Le premier est un lien (pointeur ou référence java) vers un tableau de différentiel de temps, le second et troisième correspondent à la taille et au nombre de données contenues dans la structure. Le champ suivant, compteur écailles indique le nombre d'écailles actives dans l'écaille. Puis viennent des liens



vers un tableau de bitmaps, numéro écaille (un par écaille, utilisé pour localiser une donnée dans une écaille), ainsi lien vers un bitmap de mouvements (indiquant si un mouvement a eu lieu à un instant donné par différentiel temps). Suivent deux liens vers alternativement un tableau de liens vers les écailles et la liste des mouvements.

Les écailles sont constituées d'une liste de liens vers les données (cf. figure 67). Toutes les références temporelles se situent au niveau de la marche et de la racine de l'escalier. Les écailles couvrent toutes une classe de chaleur. Par analogie, si on permet à la température d'atteindre 100°C, et si 10 écailles sont disponibles, chaque écaille couvre une classe de chaleur de 10°C. Il n'y a pas de recouvrement entre les différentes classes de chaleur.

Chaque marche (cf. figure 66) est liée à un tableau de temps différentiels permettant de déterminer la date d'une mesure. Dans la racine de l'escalier se trouve un tableau de temps de référence pour chaque marche. Au niveau de chaque marche, le tableau de différentiels enregistre la différence temporelle entre l'instant correspondant à la première mesure de la marche et les suivantes. L'utilisation de ce tableau est assimilable à une transformation locale de l'échelle et de la référence temporelle. L'échelle temporelle est changée afin de minimiser le coût mémoire. Alors qu'une date peut être représentée sous la forme d'un long (64 bits), les enregistrements différentiels peuvent se contenter d'entiers (32 bits). La probabilité d'un écart temporel supérieur à 232 unités temporelles (généralement la milliseconde) reste négligeable dans le cas des systèmes de surveillance. L'espace économisé pour la marche est quant à lui plus conséquent.

Suite à ce tableau de différentiels temporels se trouve un compteur d'écailles dans la marche. Il permet de déterminer la « hauteur » de la marche. Lorsqu'une marche ne contient plus d'écaille, son espace mémoire peut être libéré.

Un compteur de taille de données enregistrées est conservé dans la marche. Comme pour la racine, il convient de compter aussi bien les mesures que les notifications de mouvement, avec des coûts en conséquence. Si la taille d'un lien équivaut à 32 bits et qu'une position en trois dimensions utilise trois entiers sur 32 bits, le coût mémoire d'une mesure est de 32 bits (lien vers la donnée) tandis que celui d'un mouvement est de 128 bits (3*32 pour la position, et 32 bits pour le lien entre le tableau de positions et celle-ci). Le calcul du nombre d'unités de remplissage utilisées doit donc pondérer en conséquence le coût d'une mesure et une notification de changement de position. Lorsque Tdm unités de remplissages (la taille d'un lien dans l'exemple précédent) sont entrées, le processus de transfert de données en escalier et entrepôt de données est lancé. Une fois les données transférées (l'écaille la plus basse de chaque marche), le nombre d'unités de stockage utilisées par la marche est mis à jour.


Figure 66 : Structure d'une marche de l'escalier

Figure 67 : Structure d'une écaille de l'escalier

Dif férentiel Temps

Numéro Ecaille

Bitmap Mouvement

Liste Ecailles

TailleDonnées

ListeMouvements

NombreDonnées

CompteurEcailles

Données


Le champ suivant comporte le nombre de données enregistrées (mesures et changement de positions). Ce champ est également utilisé pour déterminer l'index courant dans les différents tableaux de la sous-structure de marche. Lorsque Ndm données sont entrées (Nombre de données maximum par marches), le processus de transfert de données entre l'escalier et l'entrepôt de données est lancé. Une fois les données transférées (l'écaille la plus basse de chaque marche), le nombre de données de la marche est mis à jour. Ndm et Tdm sont liés entre eux de telle sorte à ce que Tdm = Ndm si le capteur n'a pas changé de position durant l'intervalle temporel couvert par la marche.

Le champ suivant contient un lien vers un tableau de bitmaps. Ces bitmaps servent à déterminer dans quelle écaille particulière se trouve une donnée. Chaque bitmap comporte Ndm bits initialement placés à 0. Chacun de ces bitmaps est lié à une écaille particulière. Lorsqu'une donnée est ajoutée à la marche, la fonction d'attribution de chaleur est appelée pour déterminer l'écaille dans laquelle doit être ajoutée la mesure. Le bit Nombre de données du bitmap correspondant est placé à 1 avant que ce nombre ne soit incrémenté. Par la suite, retrouver une donnée particulière dans une écaille (assimilée à une pile de données) passe par le décompte de bits à 1 entre le début du bitmap de l'écaille et l'instant concerné. Ceci donne l'offset de décalage pour atteindre la données recherchée dans l'écaille. Les bitmaps permettent de réorganiser l'ordre des données collectées dans différentes écailles.

Ce tableau de bitmap est suivi d'un lien vers un autre bitmap, relatif aux notifications de mouvement. Lorsqu'un mouvement est détecté, le bit correspondant au nombre de données est placé à 1 dans ce bitmap. Son utilisation est similaire aux bitmaps d'écaille précédents, à une exception près. Le bitmap n'est pas lié à une écaille mais à une liste de positions.

Ces positions sont référencées dans une liste liée à la marche. Il s'agit d'une liste des différentes positions occupées par le capteur. Cette liste ne comporte pas de références temporelles propre. La résolution d'une requête sur des critères spatiaux suppose un accès au bitmap change_position de la racine pour déterminer si un déplacement de capteur a eu lieu. La dernière marche de l'escalier conserve une copie de la position courante au début de celle-ci. Ceci permet de limiter les accès inter-marches pour déterminer la position courante.

Les écailles sont assimilables à des piles de liens vers les données (cf. figure 67). Ces piles ne comportent pas d'informations temporelles. Il est nécessaire d'avoir recours aux informations relatives à la racine (temps de début de marche) et à la marche (temps différentiel) pour obtenir un appariement entre une date précise et une mesure. Notons que le processus de remplissage d'une marche place la première mesure collectée dans l'écaille la plus haute de celle-ci. La marche supérieure de chaque marche de l'escalier contient donc au moins une mesure.

En somme, la structure de marche collecte toutes les mesures et tous les changements de position d'un capteur pendant un intervalle de temps. Les données sont ordonnées par classe de « chaleur » liées à des écailles. Les marches utilisent des bitmaps pour distinguer les différents enregistrements et les lier à des informations spatio-temporelles. Le nombre de données collectées et la taille de la structure sont des critères pouvant déclencher le transfert de données vers un entrepôt. Lors de ce processus, les données les plus froides, dans les écailles les plus basses de chaque marche sont progressivement transférées vers l'entrepôt. Dans



un cas d'utilisation normal, la fonction permettant de déterminer la classe de chaleur d'une donnée permet une répartition homogène des mesures entre les différentes écailles. Cette fonction joue donc un rôle prépondérant dans l'estimation des capacités de la structure.

La fonction de chaleur

La fonction d'attribution de chaleur à une donnée doit permettre une répartition homogène des données entre les différentes écailles lors d'une fonctionnement normal du système. De fait, lors d'une phase d'activité spécifique, il est souhaitable qu'un plus grand nombre de données se voit attribuer une chaleur plus importante. Cette spécificité induit le développement de fonction de chaleurs spécifiques aux phénomènes étudiés. Une fonction générique peut cependant être envisagée.

Les évolutions de données sont généralement aussi voire plus importantes que les données elles-mêmes. Une fonction de chaleur simplifiée permet de classer les données en fonction de ce taux de variation entre deux données. Le taux de variation est ainsi mesuré. La valeur absolue de celui-ci permet de distinguer différentes classes. On pourra alors établir une corrélation pour laquelle chaque 'niveau' de chaleur équivaut à Tm /Ne où Tm correspond au taux de variation maximum attendu entre deux mesures et Ne le nombre d'écailles d'une marche à sa création.

L'attribution de la chaleur nécessite une connaissance des mesures précédentes. Le processus lié à la fonction doit donc pouvoir conserver un historique des mesures. Les fonctions pouvant prendre différentes formes, prenant en compte l'impact de plusieurs données antérieures, c'est au processus de détermination de la chaleur de conserver les mesures, indépendamment de la structure centrale de l'escalier.

Les performances de la structure capteur sont intrinsèquement liées à la fonction de chaleur. Le principe du StH est de transférer les données les moins intéressantes vers un entrepôt de données afin de permettre un accès pertinent aux mesures. Une fonction de chaleur mal conçue risque de mal évaluer l'importance d'une donnée.

Une donnée dont la chaleur est mal estimée peut avoir reçu une chaleur trop importante / faible. Dans le premier cas, elle sera stockée dans une écaille 'haute', de la partie supérieure de la marche. Les transfert de données s'effectuant en éliminant les écailles les plus basses, cette donnée sera conservée en mémoire vive durant une durée trop longue et agira ainsi comme un facteur d'étouffement de la structure. Elle contribuera à forcer de nouveaux transfert indus. En multipliant le nombre de transferts, les performances temps-réel du système décroissent.

Une donnée recevant une chaleur trop faible sera liée à une écaille trop basse dans la pile. Par conséquent cette donnée sera à son tour transférée trop tôt à l'entrepôt de données. Des requêtes spécifiques à cette donnée devront alors avoir recours à l'entrepôt, au temps de réponse notoirement plus lent. De même, les systèmes ayant spécifiquement recours aux données de la base devront utiliser des informations parcellaires dont les marqueurs principaux risquent de disparaître prématurément. Une analogie avec l'analyse du signal indique que certaines harmoniques principales du signal 'disparaissent' du processus d'analyse, conduisant à des résultats erronés quant à l'information véhiculée par le signal.



Un autre risque d'une fonction mal calibrée implique un regroupement des données dans un petit ensemble d'écailles. Ces écailles font alors office de « bande passante » rassemblant un ensemble de mesures. Outre la surcharge de l'écaille et des temps de parcours plus important, ce regroupement induit des transferts « par à-coup » de données entre base et entrepôt de données.

Il convient de trouver un compromis entre la précision de la fonction de chaleur et son coût d'utilisation. Des fonctions de chaleur plus élaborées peuvent tirer parti des travaux effectués en cryptologie et compression de données [57] afin d'adapter ses paramètres pour assurer une répartition homogène des données, mais le coût d'utilisation d'une telle solution augmenterait en conséquence.

En synthèse, la fonction d'attribution de chaleur doit permettre une répartition homogène des données lors d'une activité normale du système étudié. Ceci suppose l'utilisation de fonctions spécifiques à chaque cas d'utilisation. Une fonction mal adaptée risque d'attribuer une chaleur erronée à une donnée particulière ou bien de ne pas assurer une répartition homogène des données, ce qui peut conduire à des baisses de performances du StH. La détermination de la fonction de chaleur se détermine donc ad-hoc, en fonction du capteur ou encore des caractéristiques de la base de données. Les mises à jour étant fréquentes dans les systèmes de surveillance, il convient d'adapter cette fonction au système de surveillance du mieux possible.

La mise à jour de l'escalier

Les mises à jour de la sous-structure capteur s'effectuent de manière séquentielle et concernent des données ajoutées de manière incrémentale. La figure 68 présente le processus de mise à jour associé à une mesure tandis que la figure 69 présente celui associé à un mouvement.

Dans un premier temps, la racine identifie le type de mise à jour (nouvelle mesure, mesure et changement de position ou changement de position seul) et transfert la mise à jour à la marche en cours de remplissage. La racine sert principalement à la résolution de requêtes d'accès aux données, les mises à jours concernent des mesures ajoutées en temps-réel, dans la marche la plus récente.

Une fois arrivé au niveau de la marche, l'étape suivante vérifie que la taille actuelle de la marche est suffisante pour accueillir un nouvel enregistrement (en prenant en compte les besoins accrus de mémoire en cas de mise à jour de mouvement). Si tel n'est pas le cas, le processus de transfert de données est lancé, ce qui amènera au décalage des marches, à l'élimination de la marche la plus basse de chacune de celles-ci et à l'insertion d'une nouvelle marche qui deviendra la marche en cours de remplissage. La donnée est alors insérée dans l'écaille la plus haute.

En parallèle à la vérification précédente, un appel à la fonction de chaleur permet de déterminer l'écaille dans laquelle la donnée doit être insérée. Les données, lors d'une phase d'activité normale du système sont réparties de manière homogène entre les différentes écailles. Une fois l'écaille d'accueil déterminée, elle peut être mise à jour.



Figure 68 : Processus de mise à jour mesure de l'escalier

La mise à jour de l'écaille s'effectue en deux étapes. Dans un premier temps, la donnée est effectivement ajoutée à la liste de données de l'écaille, en fin de liste. En parallèle, cet ajout est référencé dans la marche. Pour cela, on ajoute le temps entre le différentiel de temps entre le début de la marche (enregistré dans la racine et passé en argument à la procédure de mise à jour) et l'instant de la mesure. Ce différentiel est noté à la position Nombre de données du tableau de différentiels temporels. Puis le bitmap correspondant à l'écaille d'ajout dans le tableau de bitmaps de marche est mis à jour. Dans ce bitmap, le bit numéro Nombre de données est placé à 1. Les champs nombre de données et taille des données sont incrémentés.



Figure 69 : Processus de mise à jour de mouvement de l'escalier

En cas de déplacement du capteur, la liste de mouvements est mise à jour (ajout en fin de liste) tandis que le bitmap de changement de position de la marche et de la racine sont actualisés (le bit à l'index Nombre de données de la marche et celui identifiant cette dernière dans la racine sont placés à 1). Ce nombre de données et la taille des données contenues sont alors incrémentés.

En fin de processus, la racine de l'escalier est mise à jour en fonction du nombre de données contenues, en cas de déplacement en fonction de la nouvelle position valide et en cas de transfert en fonction du résultat de celui-ci.



Le processus de transfert

Le processus de transfert est lancé lorsque le nombre de données dans une marche dépasse un seuil prédéterminé. La prédétermination de ce seuil est relative à la structure du système informatique et au capteur utilisés. Il est spécifié à la création la sous-structure capteur. Des valeurs par défaut peuvent être utilisées en cas d'absence de paramètres plus précis.

● Un seuil trop important risque de provoquer une situation de saturation de la base de données.

● Un seuil trop faible peut entraîner un étouffement de la structure : le nombre de transferts vers l'entrepôt de données croît, augmentant le coût total de transmission des données. De plus, la probabilité de demandes d'accès à des données non contenues dans l'escalier augmente en conséquence.

L'estimation du seuil nécessite une estimation a priori du nombre de mises à jour à traiter et du besoin d'accès aux données en mémoire vive, pour limiter le nombre de requêtes envoyées vers l'entrepôt. La structure actuelle du StH ne permet pas une adaptation en ligne du seuil. Des transformations sur la structure originale peuvent cependant le permettre.

Le transfert commence par parcourir chaque marche de l'escalier, comme illustré dans la figure 70. Le bitmap numéro écaille de l'écaille la plus basse est parcouru pour déterminer le nombre de données contenue par celle-ci. L'écaille est alors écartée de la structure principale et est préparée à être transférée. Le nombre et la taille des données de la marche sont alors mis à jours. L'ensemble des données à transférer (l'écaille la plus basse, la plus « froide » de la marche) est ainsi regroupé. Le compteur d'écaille (nombre d'écailles actives dans la marche) de chaque marche est décrémenté tandis que le bitmap correspondant à l'écaille transférée est réinitialisé à zéro.

Si la marche à transférer est la plus récente, une copie du tableau des temps différentiels de la marche en cours de remplissage ainsi qu'une copie du temps de départ lié à cette marche sont ajoutées aux données à transférer (afin de reconstituer les dates de prises de mesure dans l'entrepôt).

Dans chaque marche comportant encore des écailles, celles-ci sont décalées d'un cran vers le bas. Les données vieillissantes deviennent progressivement de moins en moins intéressantes, aussi au fur et à mesure des transferts, les écailles restantes dans la marche sont décalées vers le bas, vers le secteur le plus « froid » de la marche. Le nombre de données de l'escalier peut également être mis à jour. A ce point, chaque marche vient de perdre son écaille la plus basse, ses données les moins intéressantes.

Le transfert utilise les interfaces réseaux du système. Le système d'indexation présuppose que le réseau le liant à l'entrepôt de données ou au Storage Area Network utilise un transfert relativement sûr, avec reprises sur erreur si besoin est.

A ce point de la procédure de transfert, les données les plus froides, donc les moins intéressantes de chaque marche ont été envoyées vers l'entrepôt et écartées de la base. De même, les écailles restantes ont été décalées d'un cran vers le bas, pour signifier la perte progressive de chaleur des données. La dernière marche ne



Figure 70 : Processus de transfert de données de l'escalier

contient dès lors plus d'écaille. Le dernier enregistrement de position connue de la dernière marche est copié en fin de liste de position de la marche précédente. On notera qu'il existe donc un enregistrement de plus dans la liste des positions de cette marche que de bits placés à 1 dans le bitmap de mouvement. Cette méthode assure une sauvegarde de la position du capteur.

Les positions sont également mises à jour dans le sous-arbre spatial, par l'intermédiaire de l'interface. Le R-Tree multi-version reçoit des requêtes de suppression pour les différents déplacements du capteurs enregistrés dans la



dernière marche, à l'exception de la dernière position enregistrée, recopiée dans la pénultième marche. La dernière marche est alors libérée de la mémoire.

Au niveau de la racine du StH, les champs change position, début temps marche et liste marche sont mis à jour par un décalage des valeurs enregistrées. De même le nombre et la taille des données sont mis à jour en sommant les valeurs associées aux différentes marches.

Une nouvelle marche contenant Ne = Nm (Nombre d'écailles = Nombre de marches) écailles vides est créée. Les marches déjà existantes, à présent diminuées d'une écaille sont décalées et la nouvelle marche est insérée à la place réservée à la marche en cours de remplissage. Ceci permet de conserver la forme en escalier de la structure. L'insertion des nouvelles données pourra s'effectuer dans cette nouvelle marche.

En conclusion, le processus de transfert en lui même consiste à envoyer la ligne d'écailles la plus basse de l'escalier (l'écaille la plus basse de chaque marche) à l'entrepôt de données. La marche la plus ancienne est ainsi vidée de sa dernière écaille et peut être éliminée. Les autres sont décalées d'un cran tandis qu'un nouvelle marche complète est insérée en bout de structure (marche la plus récente) et devient la marche en cours de remplissage.

L'accès aux données

Le transfert des données vers l'entrepôt de données implique qu'en dehors de la marche en cours de remplissage certaines données plus anciennes ne figurent plus dans la base de données. Une fois transférées, leur accès n'est désormais possible que par l'intermédiaire de l'entrepôt. La politique d'attribution de chaleur limite l'impact de ces disparitions de données plus « froide », et par définition moins porteuses d'information.

L'accès aux données via la base s'effectue en plusieurs phases, illustrées dans la figure 71. La première passe par un accès à la racine de l'escalier. Le tableau de début temps des marches permet de déterminer quelles marches sont concernées par une requête d'accès. On conserve en mémoire les dates de début de marche qui seront utilisés pour la phase suivante de résolution de requêtes. On conserve également l'index Imd, le numéro de marche contenant le début de l'intervalle de recherche.

La phase suivante consiste à vérifier, via le champ change-position de la racine si un changement de position a eu lieu entre le début de l'intervalle de recherche et le début de l'escalier (les données les plus anciennes). Le but est ici de rechercher la position valide en début de l'intervalle de recherche.

Par la suite, les différentes marches sont parcourues. Une comparaison entre les paramètres temporels de la requête et la date des différentes mesures (date de début de marche augmenté du différentiel temporel) permet de déterminer si un enregistrement doit figurer dans l'ensemble des réponses à renvoyer. Le début et la fin du sous-intervalle à renvoyer sont recherchés. Si la marche est entièrement incluse dans l'intervalle de recherche, toutes les données seront renvoyées. De



Figure 71 : Résolution d'une requête d'accès aux données via un instant temporel

même, un parcours du bitmap de changement de position dans les marches permet de mettre à jours la position occupée par le capteur à l'instant de la mesure.

Par la suite, chacun des bitmaps d'écaille est parcouru. Ce parcours permet d'obtenir le nombre de données à écarter avant d'entrer dans l'intervalle temporel recouvert par la requête. L'offset ainsi obtenu servira à l'étape suivante. Il est dès lors possible d'atteindre les données recherchées via les écailles (piles de liens vers les mesures).

Les informations sur les changements de position et sur les instants de mesure peuvent être utilisés pour renvoyer le jeu de données à l'utilisateur en reconstituant des enregistrements complets : <Temps; Position; Mesure>



La suppression de données

La suppression de données est possible via la structure d'escalier. La première étape consiste à déterminer la marche concernée par cette requête. Ceci s'effectue via une comparaison entre les différentes dates de début de marche.

Par la suite, au sein de la marche, via le tableau de différentiels temporels, le numéro d'enregistrement de la donnée est déterminé. Un parcours des différents bitmaps d'écaille permet l'identification de l'écaille à modifier. Un décompte des bits à 1 de ce bitmap permet de déterminer la position de la donnée dans l'écaille. Le bit de celle-ci est alors réinitialisé à 0 dans le bitmap.

Dans l'écaille, la donnée est enlevée puis la pile est décalée. La suppression peut alors s'achever.

Du fait du risque encouru par un accès aux données lors de la suppression, l'accès à la marche est temporairement bloqué jusqu'à la fin de la suppression; ceci afin d'éviter des incohérences dans les résultats retournés.

6.2.2 Exemple de requêtesLe StH permet la résolution de requêtes telles que celles définies pour le PasTree, des requêtes spatio-temporelles, prenant en charge l'agilité des capteurs et un accès multi-version. La fonctionnalité de la gestion de la saturation de la base de données est ajoutée.

6.2.2.1 Mises à jour du StH

Les requêtes les plus courantes sont une fois de plus les mises à jour. Celles-ci peuvent s'effectuer en utilisant l'un des deux arbres d'accès : spatial ou d'identifiants. Dans le premier cas, elles prennent la forme <Position du capteur; identifiant de capteur; date de la mesure; valeur de la mesure> Dans le cas d'une mise à jour par l'arbre d'identifiants, la partie position du capteur peut être omise.

Dans le cas d'une mise à jour par identifiant, le processus commence par rechercher une référence afin de déterminer le sous-arbre capteur correspondant. Si aucune référence n'est obtenue, la création d'un nouveau capteur est lancée. Dans le cas d'une mise à jour spatiale, un premier parcours de l'arbre spatial permet de vérifier si le capteur est déjà défini au point de la mise à jour. Si c'est le cas, l'escalier capteur correspondant est à son tour mis à jour. Dans le cas contraire, une requête sur le sous-arbre d'identifiants permet d'atteindre l'escalier capteur pour une mise à jour de la position et de la mesure. Si l'identifiant n'est pas encore référencé, un nouvel escalier lui est dédié. Le sous-arbre spatial est alors mis à jour pour prendre en compte la position du capteur.



6.2.2.2 Accès aux données du StH

Les mises à jour sont courantes mais leur formalisme est relativement limité. Les accès aux données sont plus variés. Ils peuvent porter sur les mesures mais également sur les capteurs eux-même.

● Les requêtes spatiales peuvent porter sur des positions précises ou sur des zones spatiales.

● La partie temporelle des requêtes porte de son côté sur des instants précis ou sur des intervalles temporels.

● L'ajout du critère d'identifiant permet d'accroître les possibilités d'interrogation de la structure en se fondant sur les identifiants de capteurs dont la position reste à déterminer.

Les requêtes peuvent porter sur les mesures effectuées, sur les positions ou les identifiants des capteurs, mais peuvent également permettre de suivre les positions successives occupées par un capteur. De plus, l'utilisation d'un R-Tree permet également d'effectuer des requêtes concernant les voisins les plus proches de points ou de zones déterminées.

Parmi les types de requêtes possibles, on peut distinguer :





« Trouver les données issues du capteur 'RI001' entre les instants T1 et T2. »

« Trouver les identifiants des capteurs situés dans la zone définie entre les points <X0;Y0> et <X1;Y1> entre les instants T1 et T2. »

« Trouver l'identifiant du capteur le plus proche du capteur 'RI001' au temps T. »

« Trouver la position du capteur 'RI001' à l'instant T. »

« Suivre le capteur 'RI001' entre les instants T1 et T2. »

« Suivre le capteur situé au point <X;Y> à l'instant T entre les instants T1 et T2. »

« Insérer une donnée dans la zone définie par les points <X1;Y1>;<X2;Y2> à l'instant T. »

« Sauver les données issues par le capteur 'RI001' entre les instants T1 et T2. »

« Trouver la mesure au point <X;Y> à l'instant T par interpolation spatio-temporelle des mesures déjà collectées. »

Le nombre de requêtes possibles est vaste. Cependant, il convient de noter qu'ici plus encore que pour le PasTree les requêtes effectivement utilisées par les utilisateurs sont fortement liées au type de système utilisé. Il semble évident qu'un



système conçu pour la surveillance volcanique ne sera pas sujet aux mêmes requêtes qu'un système de surveillance d'incendies ou qu'un système météorologique. La nature du système impose des choix quant aux paramètres permettant la définition de différents éléments liés au StH (tailles des escaliers, fonctions de chaleurs utilisées), rendant la généralisation de tests menés sur cette structure quasi-impossible.

6.2.3 Implémentation et test du StHLe StH a été implémenté et des séries de tests ont été effectuées en faisant varier le nombre de données à indexer (de 1000 à 200000), le nombre de sources d'informations (10-100) employées et la partie de la base à balayer pour les requêtes d'intervalle. Les tests ont été effectués sur un ordinateur Athlon XP cadencé à 1,3 G Hz avec 256 Mo de RAM, sous Linux. Le langage de programmation utilisé était Java.

Le PoTree et le PasTree ont tous deux été comparés avec des R*Tree, structure d'indexation existante et presque omniprésente dans les bases de données actuelles. Le StH ne peut être comparé efficacement de la même manière. En effet, ces index supposent le maintient des données au sein de la base, qui délègue la gestion de la saturation à un processus secondaire. Le StH intègre directement les outils de cette gestion. Sa structure mais aussi et surtout sa fonction première sont toutes deux spécifiques à la définition de cette structure. Dans la mesure où il n'existe a priori aucune autre structure possédant ces caractéristiques, des comparaisons avec d'autre types d'index semblerait peu probant.

Les tests effectués ont porté sur les différents éléments composant le StH, principalement la validité du choix du R*Tree multi-version ainsi que l'impact du choix de la fonction de chaleur.

La gestion de l'aspect multi-version est analogue entre le QuadTree du PasTree et le R*Tree du StH. Tous deux utilisent des enregistrements comparables. La seule véritable différence est liée à la nature de l'arbre sous-jacent.

Les données de test utilisées étaient par défaut au format numérique (entiers), les escalier se composant de marches pouvant accueillir 16 mesures de ce format. Les données utilisées ont été générées aléatoirement.

Les données théoriques posent un coût de création de chacun de ces arbres, QuadTree et R*Tree, de l'ordre de On log n avec n le nombre de données à indexer. Ces calculs théoriques ne prennent cependant pas en compte un élément. Alors que le QuadTree tel que défini dans le PasTree est orienté gestion de points, le R*Tree est de part sa nature même orienté vers la gestion d'objets de dimensions plus importantes. En d'autres termes, alors que le QuadTree peut directement intégrer les données issues de capteurs ponctuels, le R*Tree doit dans un premier temps prendre en considération la nature des données, ce qui alourdit considérablement la gestion des données.



La figure 72 permet de comparer les temps de création d'un R-Tree multi-version et celui d'un QuadTree multi-version. On remarque que le QuadTree est construit plus rapidement. Ceci s'explique par la gestion de données complexes par le R-Tree. Cette gestion pénalise le R-Tree lors de l'indexation de points spatiaux. On remarque également que la courbe obtenue pour le R-Tree possède une forme en escalier. Cette forme peut s'expliquer par la taille des rectangles englobants utilisés.

La figure 73 présente le temps de construction d'un escalier en fonction de la fonction de chaleur choisie. Trois fonctions de chaleur ont été étudiées. La première utilise le taux de variation entre deux mesures pour déterminer la marche dans laquelle doit être introduite une donnée. Elle est représentée dans le graphique sous le terme d'epsilon. La seconde utilise un générateur de nombres pseudo-aléatoires pour choisir une marche et la troisième propose une répartition homogène et


Figure 73 : temps de construction de l'escalier en fonction de la fonction de chaleur

10002000

30004000

50006000

70008000

900010000

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

EpsilonAléatoireSequentiel

Nombre de données

Tem

ps (m

s)

Figure 72 : Temps de création du R-Tree et du QuadTree selon le nombre de capteurs

40 60 80 100120

140160

180200

220240

260280

300320

340360

380400

0100200300400500600700800900

10001100120013001400

QuadTreeR-Tree

Nombre de capteurs

tem

ps (m

s)


séquentielle des données (une donnée à chaque marche). Elle sont nommées respectivement aléatoire et séquentielle dans le graphique. On notera une certaine disparité entre les temps de création des escaliers en fonction de la fonction de chaleur choisie. Ceci confirme une fois de plus l'importance première du choix de la fonction de chaleur optimale.

Des tests complémentaires ont testé l'impact du nombre d'écailles dans la structure. Ces tests ont été effectués avec un nombre fixe de données par écailles et une fonction de chaleur assurant une répartition séquentielle des données. Par conséquent l'augmentation du nombre d'écailles induit également une augmentation du nombre de données référencées par la structure. En ramenant ce nombre afin d'établir une base commune entre les différents arbres testés, il est apparu une influence minime du nombre d'écailles. Une augmentation du nombre d'écailles induit une augmentation du temps de création et d'interrogation de l'arbre, comme montré dans la figure 74. Cette figure montre le temps de création réel d'un escalier pour 10 000 données fixes en fonction du nombre d'écailles. Le nombre d'écailles correspond au nombre de marches. Une seconde courbe sur ce même graphe montre le temps de création ramené à un nombre fixe de données dans la structure (temps compensé).

D'autres tests ont porté sur l'influence du nombre de données par écaille, comme montré dans la figure 75. A l'inverse du test précédent, le nombre d'écailles est fixe (16), tandis que le nombre de données dans chaque écaille varie. Par conséquent, le nombre total de données référencées varie également. La figure 75 présente donc le temps de création effectif (temps réel) ainsi qu'un temps de création ramené à un nombre de données dans la structure commun entre les différentes versions de l'arbre (temps compensé). Il apparaît que ce temps diminue avec l'augmentation du nombre de données dans chaque écaille. Ceci peut s'expliquer par l'utilisation de différents tableaux et bitmaps. Ceux-ci tirent parti de la localité séquentielle des données, accélérant le processus de collecte. Les résultats d'interrogation se sont montrés similaires.


Figure 74 : Temps de création de l'escalier en fonction du nombre d'écailles dans la structure

8 16 24 32 40 48 56 64

0

25

50

75

100

125

150

175

200

225

250

275

300

325

Temps réelTemps compensé

Nombre de données par écailles

tem

ps (m

s)


Les performances du StH dépendent de différents facteurs : architecture système et ressources disponibles, types de capteurs, fonctions de chaleur utilisées, taille des escaliers,... De fait, un calcul de l'impact de l'étouffement du système est difficilement généralisable. Dans le cas idéal, le concepteur de la base a une connaissance précise de la masse et et du type de données que devra gérer la base. Il devient alors possible de déterminer les paramètres de création des différents escaliers (nombre et taille des marches,...) afin d'assurer un taux minimum de ressources systèmes disponibles. Le StH n'est cependant pas immunisé contre l'étouffement du système. Son fonctionnement met fortement à contribution les routines d'entrée / sortie du système (réception et transfert de données), ce qui contribue à cet étouffement. Le principal objectif de cette structure reste cependant de limiter les risques de bloquage complet du système du fait de la saturation, à condition que ses paramètres soient fixés correctement.

En somme, les différents tests proposés ont montré l'importance première du choix d'une fonction de chaleur appropriée, ainsi que l'utilisation de paramètres de création des escaliers adapté à la situation. Il n'existe pas de paramétrage parfait, et chaque système doit être configuré en fonction des ressources disponibles et des politiques d'accès et de mise à jour des données. Le choix du R-Tree pour la sous-structure d'accès spatial s'avère plus coûteux qu'un simple Quadtree, mais offre l'avantage de pouvoir prendre en compte des objets complexes.

6.2.4 Conclusion sur le StHLe StH est une structure d'indexation pour bases de données en mémoire vive liée à un réseau de capteurs. Il permet de prendre en compte la gestion de la saturation de la base de données en proposant un mécanisme de transfert des données les moins intéressantes vers un un entrepôt de données.

Les mesures sont référencées au sein d'une structure en escalier relative au capteur émetteur. L'escalier se compose d'un ensemble de marches temporelles, divisées en


Figure 75 : Temps de construction de l'escalier selon le nombre de données par écaille

16 32 48 64

0

25

50

75

100

125

150

175

200

225

250

Temps réelTemps compensé

Nombre de données par écaille

Tem

ps (m

s)


écailles de chaleur. La date de la mesure est alors utilisée comme référence pour cette dernière. Les changements de positions sont conservés, de même que toutes les informations relatives au capteur (position actuelle, identifiant). Une marche spéciale de l'escalier est réservée pour une conserver de manière explicite certaines mesures. A l'arrivée dans la structure, toutes les mesures sont classées en fonction de leur chaleur, leur intérêt, et son liées à une écaille de la dernière marche. Plus l'écaille est élevée dans la structure, plus la mesure est jugée importante. Lorsqu'un nombre d'enregistrements est atteint dans la marche, le processus de transfert de données vers l'entrepôt peut être lancé. L'écaille la plus basse de chaque marche est expédiée. Les marches ainsi amputées sont décalées d'un cran, vers les données les plus anciennes (à gauche). Une nouvelle marche complète est insérée à droite de la structure pour recevoir les mesures les plus récentes.

Chacun de ces escaliers peut être accédé par l'intermédiaire de deux sous-structures. La première, la sous-structure d'identifiants reprend le fonctionnement de son homonyme du PasTree et permet d'interroger les escaliers en fonction de l'identifiant d'un capteur. La seconde sous-structure d'accès, un R-Tree multi-version permet un accès aux escaliers de fonction de la position géographique des capteurs.

Les tests effectués ont montré l'importance de l'utilisation d'une fonction de chaleur adaptée au système et au capteur. La définition des différents paramètres de configuration des escalier sont relatifs à chaque capteur. La configuration s'effectue donc ad-hoc.

Les différentes particularités du StH permettent une gestion de l'agilité des capteurs, une valorisation des données les plus récentes tout en conservant les données jugées les plus intéressantes. Il permet en outre la résolution de requêtes en fonction de critères spatio-temporels et de critères basés sur l'identifiant des capteurs. En cela, le StH répond aux même critères que le PasTree. La gestion de zones d'observation a été rajoutée, ainsi qu'une approche vers la gestion de la saturation dès la création de l'index.



6.3 Conclusion générale sur la gestion de la saturation dès la construction de l'index

A l'heure actuelle, les processus en charge de la gestion de la saturation des bases de données sont distincts du processus de création de l'index des données. La gestion de la saturation est considérée comme une couche supplémentaire qui vient généralement alourdir le système.

Les besoins des systèmes de surveillance de phénomènes implique l'utilisation de bases de données spatio-temporelles liées à des capteurs. La gestion de la saturation est d'autant plus importante que le nombre de capteurs croît, et que leurs fréquences de mises à jour augmentent.

L'idée première des travaux exposés dans ce chapitre consiste à intégrer dès la conception de l'index des mécanismes facilitant la gestion de la saturation de la base de données. L'intégration de ce processus a conduit à la création du StH, une structure d'accès reprenant l'héritage du PasTree. Le StH enrichit celui-ci par l'adjonction de la gestion d'observations sur des zones géographiques.

Le StH, bien que prometteur n'est pour l'heure que le premier pas dans la direction de la gestion de la saturation. La voie est loin d'être tracée, et les travaux à venir devront encore répondre à de nombreux problèmes liés à la structure de la base de données, ainsi qu'aux avancées technologiques. Les travaux futurs apporteront leurs lots de nouvelles solutions. Le StH pourra cependant se prévaloir d'avoir ouvert, ou tout du moins entrebâillé la porte de la gestion de la saturation.




De cape et de crocs - Jean sans Lune - ©Delcourt

Conclusion

7 Conclusion

Depuis leur origine, les réseaux de capteurs sont utilisés dans le cadre de la surveillance de phénomènes environnementaux, naturels ou non. De nombreux chercheurs dépendent de l'accès aux données récoltées par ces capteurs pour confirmer leurs modèles, déterminer les prémisses d'une activité particulière ou bien encore prévenir de l'imminence d'une catastrophe. Alors que les réseaux et la variété des capteurs s'accroissent, il devient nécessaire de mettre à disposition des spécialistes les outils leur garantissant un accès aux données récoltées notamment par l’exploitation d'une base de données en mémoire vive.

L'objectif de cette thèse est d’offrir aux spécialistes de ces systèmes de surveillance une méthode de structuration, de recherche et d'accès rapide aux informations spatio-temporelles en temps-réel et sur différents critères, notamment spatiaux et temporels. Plus précisément, le problème qui nous concerne est celui de l'indexation d'une masse de données référencées spatio-temporellement avec des contraintes de temps pour la construction de l’index et pour l'exécution des requêtes. Les mesures collectées par le réseau de capteurs doivent être indexées en fonction du capteur dont elles sont issues et de la date de la mesure. De plus, on cherche également à valoriser les données les plus récentes, ce qui n'est actuellement pas le cas pour les index existants.

Le cas d'étude visé, la surveillance de phénomènes naturels, pose également le problème d’exportation vers un entrepôt de données et la gestion automatique de la saturation mémoire de la base de données. Ces problématiques sont d’ailleurs communes à l’ensemble des systèmes de surveillance de catastrophes naturelles (inondations, tremblements de terre,…).

La première proposition présentée dans cette thèse, le PoTree, vise à indexer en mémoire vive les données spatio-temporelles issues d'un réseau de capteurs temps-réel fixes.

Il sépare les aspects temporels et spatiaux pour indexer des données spatio-temporelles, en minimisant la taille de la structure, et en valorisant les recherches de points spatiaux et d'intervalles temporels. L’objectif est également de faciliter les mises à jour de données concernant des points spatiaux déjà connus (capteurs fixes). Ainsi, le PoTree réponds à des requêtes du type : « trouver les données issues du capteur situé à la position <X;Y> émises entre T1 et T2. » Ou bien encore : «Trouver les données situées dans la zone définie par les points <X1;Y1>, <X2;Y2> à l’instant T.». En utilisant d'abord des paramètres spatiaux pour restreindre le nombre d'accès à la structure, le PoTree se distingue des autres index. En effet, contrairement aux approches basées sur les R-tree, le PoTree se fonde sur une différenciation des dimensions spatiales et temporelles. A un sous-arbre spatial sont associés plusieurs sous-arbres temporels. Chaque capteur est lié à un sous-arbre temporel qui lui est propre. L'approche ainsi retenue est basé sur un kd-tree pour la gestion de l'aspect spatial et des dérivés de B+trees pour la gestion de l'aspect temporel. L'ajout


Conclusion

d'un lien direct entre la racine du B+tree et le dernier nœud feuille permet de réduire fortement le coût de mise à jour et d'accès aux données les plus récentes.

Les feuilles du kd-tree spatial pointent vers des B+trees temporels, les feuilles des B-trees pointant vers les mesures. Les nœuds du kd-tree ne comportent que des données relatives à la position spatiale des objets. Ils ne portent pas d'informations relatives au temps. Parallèlement, les nœuds des B+trees ne portent pas d'informations relatives à la position géographique des objets, mais uniquement les informations relatives au temps, l’agilité n'étant pas encore assurée. Ainsi, le PoTree, par une différenciation stricte des dimensions spatiales et temporelles et une mise en évidence du rôle des capteurs, permet d'indexer les données temps-réel issues d'un réseau de capteurs fixes dans une base de données en mémoire vive et permet également d’accéder aux données sur des critères spatio-temporels.

La seconde proposition de cette thèse, le PasTree, vise à indexer en mémoire vive les données spatio-temporelles issues d'un réseau de capteurs temps-réels agiles. Il permet en outre un accès multicritère aux données : selon des facteurs spatiaux ainsi que selon l'identifiant du capteur dont elles sont issues.

Cet arbre d'indexation pour base de données spatio-temporelles temps-réel en mémoire vive cherche à conserver la possibilité d'accéder aux données par les identifiants de capteurs tout en ajoutant la possibilité d’accès par des critères spatio-temporels afin de respecter les processus métiers habituels de l’utilisateur, traditionnellement plus familier des identifiants que des positions des capteurs. Par ailleurs, l’index doit permettre aux utilisateurs la gestion de données spatiales calculées à partir de mesures effectuées. Ainsi, par exemple, lors d’une surveillance volcanique, les épicentres, dérivés des mesures sismographiques, pouvant être assimilés à des données spatiales mobiles, sont difficilement représentables dans un PoTree. Tout comme le PoTree, l'accent doit être mis sur les données les plus récentes et sur les mises à jour. Enfin, au sein des systèmes chargés de la gestion des risques naturels, l’index doit faciliter l’accès aux informations recherchées en phase critique ou lors de la prise de décisions. Le PasTree offre ainsi la possibilité d'utiliser plusieurs sous-structures combinées entres-elles; la redondance occasionnée se justifiant par les besoins d'accès variés aux données.

Concernant la structure de l’index, les informations provenant d'un capteur donné sont regroupées au sein d'une même sous-structure temporelle, valorisant les données les plus récentes. Cette structure, reprise des sous-arbres temporels du PoTree, permet un chaînage rapide des données issues d'une même source. Un niveau d'abstraction supplémentaire a été ajouté afin de différencier les données collectées des changements de positions.

Les enregistrements d’un sous-arbre capteur relatifs aux changements de position (<temps; lien vers la donnée; lien vers la nouvelle position; lien vers la position précédente>, soit un enregistrement deux fois plus long que pour un enregistrement de mesure <temps; lien vers la donnée>) comportent un chaînage afin de permettre un suivi du capteur au cours du temps. De plus, en fin de nœud feuille, un lien est également ajouté vers la dernière position valide, relative au


Conclusion

nœud permettant de déterminer la position d'un capteur sans devoir remonter le chaînage des positions depuis le dernier enregistrement effectué.

Grâce à ces ajouts, la sous-structure capteur devient l'élément central dans lequel toutes les données relatives à une source d'information particulière sont collectées. Dès lors, les autres sous-structures ont pour but de déterminer lequel de ces sous-arbres temporels doit être interrogé. La première de ces sous-structures, un B+tree classique indexant les identifiants de capteurs, détermine le sous-arbre temporel lié à un capteur qui doit être interrogé par le biais d'un identifiant d'objet. La seconde sous-structure, établie en parallèle gère les données spatiales. Via cet index, un Quadtree les utilisateurs peuvent émettre des requêtes en fonction des zones spatiales, et non plus en fonction des capteurs.

L'utilisation d'une structure spatiale ne permet pas la prise en compte de tous les cas de figure. En effet, certaines stations peuvent comporter plusieurs capteurs différents ou encore, un capteur se déplaçant peut passer plusieurs fois par une même position, pendant des intervalles de temps différents. Une approche multiversion des Quadtrees a donc été retenue. En conservant au niveau des feuilles les intervalles de validité au même titre que les liens vers les sous-arbres capteurs il devient possible de limiter le nombre d'arbres capteurs interrogés lors de la résolution d'une requête.

La dernière proposition de cette thèse se nomme le StH et vise à indexer en mémoire vive les données issues d'un réseau de capteurs temps-réel agiles, en permettant un accès multicritère. Il permet également de prendre en compte des données d'observation, sur des zones. La principale innovation de cette structure est son ambition d'intégrer des outils de gestion de la saturation de la base de données en offrant un mécanisme permettant un transfert progressif des données vers un entrepôt de données.

Le StH reprend la structure générale du PasTree, avec deux sous-structure d'accès spatial et d'identifiants permettant de référencer les sous-structures de capteurs concernées par la résolution d'une requête.

Les mesures sont référencées au sein d'une structure en escalier relative au capteur émetteur. La date de la mesure est alors utilisée comme référence pour la mesure. Les changements de positions sont conservés, de même que toutes les informations relatives au capteur (position actuelle, identifiant). Une marche spéciale de l'escalier est réservée pour une conserver de manière explicite certaines données. A l'arrivée dans la structure, toutes les mesures sont classées en fonction de leur chaleur, leur intérêt, et son liées à une écaille, une composante de la dernière marche. C'est cette marche qui contient les données les plus récentes. Plus l'écaille est élevée dans la structure, plus la mesure est jugée importante. Lorsqu'un nombre d'enregistrements est atteint dans la marche, le processus de transfert de données vers l'entrepôt de données peut être lancé. L'écaille la plus basse de chacune des marches est expédiée. Les marches ainsi amputées sont décalées d'un cran vers la gauche, vers les données les plus anciennes. Une nouvelle marche complète est insérée à droite de la structure pour recevoir les mesures les plus récentes.


Conclusion

Chacun de ces escaliers peut être accédé par l'intermédiaire de deux sous-structures. La première, la sous-structure d'identifiants reprend son homonyme du PasTree et permet d'interroger les escaliers en fonction de l'identifiant du capteur. La seconde sous-structure d'accès, un R-Tree multiversion permet un accès aux escaliers de fonction de la position géographique des capteurs.

Les tests effectués ont montré l'importance de l'utilisation d'une fonction de chaleur adaptée au système et au capteur. Plus généralement, les différents paramètres de configuration des escaliers sont relatifs à chaque capteur. La configuration s'effectue donc ad-hoc.

Les différentes propositions formulées permettent de gérer différents cas d'utilisation des réseaux de capteurs. En terme de performances, le PasTree est notoirement plus complexe que le PoTree, principalement pour ce qui est de la mise à jour. Alors que des tests ont permis d'indexer les données de quelques 1200 capteurs fixes avec le PoTree sur un ordinateur de bureau, le PasTree ne peut indexer les données que de 600 capteurs. Cependant, le PasTree est capable de prendre en charge l'agilité des capteurs ainsi que l'accès aux données selon les identifiants des capteurs. Ainsi, dès lors que la gestion de la saturation de la base de données n'est pas prise en compte, le PoTree est recommandé pour des réseaux de capteurs fixes où seules les requêtes spatio-temporelles sont permises. Le PasTree est exploitable lorsque les capteurs deviennent agiles, ou lorsque l'accès aux données doit prendre en compte les identifiants des capteurs. Finalement, le StH est recommandé pour permettre une gestion de la saturation de la base de données.

Les évolutions possibles de ces recherches devraient se concentrer sur les nouveautés introduites par le StH. La gestion de la saturation de la base reste un objectif premier. Alors que le StH ouvre la voie dans le domaine, il est souhaitable que les recherches futures puissent continuer en ce sens.

Les travaux introduits dans cette thèse répondent à différentes caractéristiques liées à la surveillance de phénomènes naturels ou urbains. Certains problèmes restent cependant à résoudre, avec en premier lieu :

● La solution apportée par le StH suppose une connaissance à priori des caractéristiques des différents capteurs. De fait, une mauvaise configuration du StH peut nuire aux performances de celui-ci. Des travaux sur les configurations auto-adaptatives pourront être menés afin d'assurer un fonctionnement encore plus robuste.

● Les solutions proposées couvrent les spécificités des capteurs fixes et agiles. Ils laissent délibérément de coté les capteurs mobiles. Des solutions spécifiques pourront être développées afin de répondre aux attentes des utilisateurs de capteurs mobiles.

Le PoTree et le PasTree ont planté des arbres, le StH apporte l'escalier pour aller chercher les fruits les plus élevés. Et comme chacun sait : les meilleurs fruits sont les plus difficiles à atteindre...


Conclusion


De cape et de crocs - Jean sans Lune - © Delcourt


Bibliographie

[1] ABBOTT R., GARCIA-MOLINA H., Scheduling Real-Time Transactions: A Performance Evaluation, In : proceedings of 14th Conference on Very Large Database Systems, 1988, Etats-Unis

[2] ABRAHAM T., RODDICK J.F., Survey of Spatio-TemporalDatabases, Geoinformatica, 1999, Vol 3 (1), pp 61-99

[3] ALMEIDA V.T., GÜTING R.H., Indexing the Trajectories of Moving Objects in Networks, Fachbereich Informatik, Fernuniverstiat Hagen, TR 309, 2004

[4] ANDLER S.F., HANSSON J., MELLIN J., ERIKSSON J., EFTRING B., An Overview of the DeeDS Real-Time Database Architecture, In : proceedings of Joint Workshop on Parallel and Distributed Systems, 1998, Etats Unis

[5] BECKER B., GSCHWIND S., OHLER T., SEEGER B., WIDMAYER P., An Asymptotically Optimal Multiversion B-tree, The VLDB Journal, 1996, Vol 5 (4), pp 264-275

[6] BECKMAN N., KRIEGEL H.P., SCHNEIDER R., SEEGER B., The R*-tree: an efficient and robust access method for points and rectangles, In : proceedings of ACM SIGMOD, 1990, pp 322-331

[7] BENTLEY J.L., Multidimensional binary search-trees used for associative searching, Communication of ACM, 1975, Vol 18, pp 509-517

[8] BERCHTOLD S., KEIM D.A., High Dimensional Index Structure:database support for next decade's applications, ACM Computing Survey, 2001, Vol 33 (3), pp 322-373

[9] BLIUJUTE R., JENSEN C.S., SALTENIS S., ET AL., Light-Weight Indexing of Bitemporal Data, In : proceedings of 12th Int. Conf. on Scientific and Statistical Database Management, 2000, Allemagne, pp 125-138

[10] BLUETOOTH SIG, Bluetooth Core Specifications v1.2 [en ligne], 2005, disponible sur : http://www.bluetooth.org/foundry/adopters/documents/Bluetooth_Core_Specification_v1.2, dernière visite le 01/07/06

[11] BLUETOOTH SIG, Bluetooth Special Interest Group [en ligne], 2006, disponible sur : http://www.bluetooth.org, dernière visite le 01/07/06

[12] BUFFENOIR C., Petite introduction théorique au temps réel, Linux Magazine France, 2006, Vol 82, pp 76-79

[13] CENAPRED, Centro Nacional de Prevencion de Desastres [en ligne], 2006, disponible sur : http://tornado.cenapred.unam.mx/mvolcan.html, dernère visite le 01/06/06


[14] CHAKKA V.P., EVERSPAUGH A., PATEL J.M., Indexing large Data sets with SETI, In : proceedings of Conference on Innovative Data Systems Research (CIDR 2003), 2003

[15] CHIP W., Kryder's Law, Scientific American, 2005

[16] DERTOUZOS M., Control robotics : the procedural controlof physical processors, In : proceedings of IFIPCongress, 1974, pp 807-813

[17] DUVALLET C., MAMMERI Z., SADEG B., Analyse des protocoles de contrôle de concurrence et des propriétés ACID dans les Bases de Données Temps-Réel, In : proceedings of Real Time Systems and Embedded Systems, 1999, Paris, pp 123-139

[18] ECOS, ecos Homepage [en ligne], 2006, disponible sur : http://ecos.sourceware.org, dernière visite le 01/07/06

[19] EIMAN E., Directions in Sensor Data Streams: Solutions and Challenges, Rutgers University, DCIS-TR-527, 2003

[20] GARGANTINI I., An Eective Way to Represent Quadtrees, Communications of the ACM, 1982, Vol 25 (12), pp 905-910

[21] GOODENOUGH J., SHA L., the Priority Ceiling Protocol: A Method for Minimizing the Blocking of High-Priority Ada Tasks, In : proceedings of 2nd Int. Workshop on Real-Time ADA

[22] GUTTMAN A., R-trees: A dynamic index structure for spatial searching, In : proceedings of ACM SIGMOD Int. Conf. on Management of data, 1984, pp 47-57

[23] HADJIELEFTHERIOU M., Spatial Index Library [en ligne], 2006, disponible sur : http://u-foria.org/marioh/spatialindex, dernière visite le 01/07/06

[24] HARITSA J.R., SESHADRI S., Real-Time Index Concurrency Control, IEEE Transactions on Knowledge and Data Engineerin, 2000, Vol 13 (3), pp 429-447

[25] HARITSA J.R., SESHADRI S.,Real- time index concurrency control In : Real Time Databases System, Kluwer Academic Publishers, Boston, 2001, 0-7923-7218-2

[26] IEEE, IEEE 802.3 CSMA/CD [en ligne], 2006, disponible sur : http://grouper.ieee.org/groups/802/3, dernière visite le 01/07/06

[27] IEEE, 802.11 Wireless Local Area Networks [en ligne], 2006, disponible sur : http://grouper.ieee.org/groups/802/11, dernière visite le 01/07/06

[28] INTANAGONWIWAT C., ESTRIN D., GOVINDAM R. ET AL, Impact of Network Density on Data Aggregation in Wireless Sensors Networks, In :


proceedings of International Conference on Distributed Computings, 2001, Vienna

[29] IDAHO MUSEUM OF NATURAL HISTORYVISIBILITY & DAY/NIGHT SENSOR, Visibility & Day Night Sensor [en ligne], 2005, disponible sur : http://imnh.isu.edu/digitalatlas/clima/tour/vsensor.htm,

[30] JIANG S., ZHANG X., LIRS: an efficient low inter-reference recency set replacement to improve buffer cache performance, In : proceedings of ACM SIGMETRICS Conference on Measurement and Modeling of 2002 Computer Systems, 2002, Etats-Unis

[31] JIANG S., DING X., CHEN F., TAN E., ZHANG X., DULO: an effective buffer cache management scheme to exploit both temporal and spatial localities, In : proceedings of 4th USENIX conference on File and Storage Technologies, 2005, Etats-Unis

[32] JURDAK R., BALDI P., LOPES V., Energy-aware adaptive low power listening for sensor networks, In : proceedings of 2nd Int. Workshop on Networked Sensing Systems, 2005, Etats-Unis

[33] K-NET, Kyoshin Network [en ligne], disponible sur : http://www.k-net.bosai.co.jp/k-net/index_en.shtml, dernère visite le 01/06/06

[34] KIM K., CHA S.K., KWON K., Optimizing Multidimensional Index Trees for Main Memory Access, In : proceedings of ACM-SIGMOD Int. Conf. On Management of Data, 2001, Etats-Unis

[35] KOLLIOS G., TSOTRAS V.J., GUNOPULOS D., DELIS A., HADJIELEFTHERIOU M., Indexing Animated Objects UsingSpatiotemporal Access Methods, IEEE Trans. on Knowledge and Data Engineering, 2001, Vol 13 (5), pp 757-777

[36] KWON D., LEE S., LEE S., Indexing the Current Positions of Moving Objects Using the Lazy Update R-tree, In : proceedings of Mobile Data Management, MDM, 2002, pp 113-120

[37] LAM K.Y., KUO T.W., Real-Time Database Systems: Architecture and Techniques, Kluwer Academic publishers, , London, 2001, ISBN: 0-7923-7218-2

[38] LAM K.Y., KUO T.W., KAO B., LEE T, CHENG R, Evaluation of Concurrency Control Strategies for Mixed Soft Real-Time DBMS, Information Systems, 2002, Vol 27 (2), pp 123-149

[39] LAURINI R., SERVIGNE S., NOËL G., Soft Real-time GIS for Disaster Management, In : proceedings of Geo-Information for Disaster Management, 2005, Pays-Bas


[40] LEE Y.J., CHUNG C.W., The DR-tree: A Main Memory Data Structure for Complex Multi-dimensional Objects, Geoinformatica, 2001, Vol 5 (2), pp 181-207

[41] LIU C.L., LAYLAND J.W., SchedulingAlgorithms for Multiprogramming in aHard Real-Time Environment, Journal of ACM, 1973 (20), pp 40-61

[42] LONG M., MURPHY R., PARKER L., Distributed Multi-Agent Diagnosis and Recovery from Sensor Failures, In : proceedings of IEEE/RSJ Int. Conf. on Intelligent Robots and Systems(IROS), 2003, pp 2506-2513

[43] LYNUWORKS, Lynuworks [en ligne], disponible sur : http://www.lynuworks.com, dernière visite le 01/07/06

[44] MENASCE D., NAKANISHI T., Optimistic versus pessimistic concurrency control mechanismsin database management systems, Information Systems, 1982, Vol 7 (1)

[45] MOK A.K., Fundamental Design Problems of Dis-tributed Systems for The Hard-Real-Time Environment, Informatique, , Massachusetts Institute of Technology, 1983

[46] MOKBEL M., GHANEM T.M., AREF W.G., Spatio-temporal Access Methods, IEEE Data Engineering Bulletin, 2003, Vol 26 (2), pp 40-49

[47] INTEL, Moore's Law 40th Anniversary [en ligne], 2005, disponible sur : http://www.intel.com/technology/mooreslaw/index.htm, dernière visite le 01/07/06

[48] MOORE A.W., Efficient Memory-based learning for Robot Control, Informatique, , University of Cambridge, 1991

[49] NASCIMENTO M. , SILVA J., Towards Historical R-trees., In : proceedings of ACM Symposium on Applied Computing (ACM-SAC), 1998, pp 235-240

[50] NASCIMENTO M.A., SILVA J.R.O., THEODORIDIS Y., Evaluation of Access Structures for Discretely Moving Points, In : proceedings of Intl. Workshop on Spatio-Temporal Database Management, pp 171-188

[51] NOËL G., SERVIGNE S., LAURINI R., The Po-Tree: a soft real-time Spatiotemporal Data Indexing Structure, In : proceedings of 11th Conf. on Spatial Data Handling (SDH), 2004, Angleterre

[52] NOËL G., SERVIGNE S., LAURINI R., Real-Time Spatiotemporal Data Indexing Structure, In : proceedings of 7th AGILE conf. on Geographic Information Science, 2004, Crète, pp 261-268

[53] NOËL G., SERVIGNE S., Indexation multidimensionnelle de bases de données capteur temps-réel et spatiotemporelles, Ingénierie des Systèmes d'Information, 2005, Vol 10 (4), pp 59-88


[54] NOËL G., SERVIGNE S., Spatial and Temporal information structuring for natural risk monitoring, In : proceedings of GIS Planet 2005, 2005, Portugal

[55] NOËL G., SERVIGNE S., Structuration de données spatio-temporelles temps-réelles: vers la gestion de la saturation, In : proceedings of INFORSID 2006, 2006, Tunisie

[56] OOI B.C., TAN K.L.,Spatial Databases In : , Indexing Techniques for Advanced Database Systems, , Kluwer Academic Publishers, , , Boston, , 1997, , 0-7923-9985-4

[57] PU C., SINGARAVELU L., Fine Grain Adaptive Compression in Dynamically Variable Networks, In : proceedings of 25th Int. Conf. on Distributed Computing Systems ICDCS 2005, 2005, Etats-Unis

[58] RAATIKKA V., Cache-Conscious Index Structures for Main-Memory Databases, Informatique, , University of Helsinki, 2004

[59] RAMAMRITHAN K., SON S. H., CINGISER DIPIPPO L, Real-time Databases and Data Services, Journal of Real-Time Systems, 2004, Vol 28, pp 179-215

[60] RAO J., ROSS K., Making B+ trees Cache Conscious in Main Memory, In : proceedings of ACM SIGMOD 2000, 2000, pp 475-486

[61] RATNASAMY S., ESTRIN D., GOVINDAN R., ET AL, Data-Centric Storage in Sensornets, In : proceedings of ACM Int. Workshop on Wireless Sensor Networks, 2002, Atlanta

[62] RATNASAMY S., YIN L., ESTRIN D., GOVINDAN R., KARP B., SHENKER S., GHT: a Geographical Hash Table for Data-Centric Storage, In : proceedings of 1st ACM Int. Workshop on Wireless Sensor Networks and Applications, 2002, pp 53-63

[63] RTAI, The RealTime Application Interface for Linux from DIAPM [en ligne], 2006, disponible sur : http://www.rtai.org, dernière visite le 01/07/06

[64] RTEMS, RTEMS Homepage [en ligne], 2006, disponible sur : http://www.rtems.com, dernière visite le 01/07/06

[65] SALTENIS S., JENSEN C.S., LEUTENEGGER S.T., LOPEZ A., Indexing the Positions of Continuously Moving Objects, In : proceedings of ACM SIGMOD Symposium on the Management of Data, 2000

[66] SAMET H., The Quadtree and Related Hierarchical Data Structures, ACM Computer Survey, 1984, Vol 16 (2), pp 187-260

[67] SATNAM A., AGOGINO A.M., MORJARIA M, A Methodology for Intelligent Sensor Measurement, Validation, Fuzion and Fault Detection for Equipment Monitoring and Diagnosticst, Journal of AI for Engineering Design, Analysis, 2001, Vol 15 (4), pp 307-320


[68] SERVIGNE S., NOËL G., Base de données spatio-temporelles temps réel: SETHLANS, In : proceedings of colloque de bilan de programme interdisciplinaire "société de l'information", , 2005, , France, pp 270-273

[69] SHIM J.M., SONG S.I., MIN Y.S., YOO J.S., PCR-tree : An Enhanced Cache Conscious MultidimensionalIndex Structures, In : proceedings of 15th Int. Conf. on Database and Expert Systems Applications, 2004, Espagne, pp 212-221

[70] SITZMAN I., STUCKEY P.J., Compacting discriminator information for spatial trees, In : proceedings of 13th Australasian Database Conference, 2002, Australie, pp 167-176

[71] SMC, Service météorologique du Canada [en ligne], 2006, disponible sur : http://meteo.ec.gc.ca/, dernière visite le 01/07/06

[72] SONG Z., ROUSSOPOULOS N., SEB-tree: An Approach to Index Continuously Moving Objects, In : proceedings of Mobile Data Management 2003, 2003, pp 340-344

[73] TAINA J., RAATIKAINEN K, RODAIN: a Real-Time Object Oriented DB System for Telecommunications, In : proceedings of workshop on Databases: active and real-time, 1996, Etats-Unis, pp 10-14

[74] TAO Y., PAPADIAS D., Efficient Historical R-trees., In : proceedings of 13th IEEE Conference on Scientific and Statistical Database Management (SSDBM), 2001, Etats-Unis, pp 223-232

[75] TAO Y., PAPADIAS D., MV3R-tree: A Spatiotemporal Access Method for Timestamp and Interval Queries, Very Large DataBase Journal, 2001, pp 431-440

[76] TAO Y., PAPADIAS D., ZHANG J., Cost Models for Overlapping and Multi-Version Structures, In : proceedings of 18th International Conference on Data Engineering (ICDE'02), 2002, Californie, pp 191-200

[77] TAYEB J., ULUSOY O., WOLFSON O., A Quadtree-Based Dynamic Attribute Indexing Method, The Computer Journal, 1998, Vol 41 (3), pp 185-200

[78] THEODORIDIS Y., VAZIRGIANNIS M. & SELLIS T., Spatio-temporal indexing for large multimedia application, In : proceedings of 3rd IEEE conference on multimedia computing and systems (ICMCS), 1996

[79] THEODORIDIS Y. SELLIS T., PAPADOPOULOS A., ET AL, Specifications for Efficient Indexing in SpatiotemporalDatabases, In : proceedings of 10th Int. Conf. on Scientific and Statistical Database Management, 1998, Italy

[80] TINYOS, TinyOS [en ligne], 2006, disponible sur : http://www.tinyos.net, dernière visite le 01/07/06


[81] TZOURAMANIS T., VASSILAKOPOULOS M., AND MANOLOPOULOS Y., Multiversion Linear Quadtree for Spatio-temporal Data, In : proceedings of ADBIS 2000, 2000, pp 279-292

[82] USGS, Geological Survey Volcano Hazards Program [en ligne], disponible sur : http://volcanoes.usgs.gov/, dernère visite le 01/06/06

[83] WANG X., ZHOU X., LU S., Spatiotemporal Data Modeling and Management: A Survey, In : proceedings of 36th International Conference on Technology of Object-Oriented languages and Systems, China, pp 202-221

[84] WIND RIVER, Wind River Portal [en ligne], 2006, disponible sur : http://www.windriver.com, dernière visite le 01/07/06


Documents

Indexation dans les bases de données capteurs temps réel.csidoc.insa-lyon.fr/these/2006/noel/these.pdf · Indexation dans les bases de données capteurs temps réel. Application