Indexation dans les bases de données capteurs temps réel.

Transcription

1 N d'ordre 2006-ISAL-0091 Année 2006 Thèse Indexation dans les bases de données capteurs temps réel. Application à la surveillance de phénomènes environnementaux et de risques naturels. Présentée devant L'Institut National des Sciences Appliquées de Lyon pour obtenir Le grade de docteur École doctorale : École Doctorale Informatique et Information pour la Société par Guillaume Noël Jury MM. Rapporteur Rapporteur A. BOUJU MdC HDR (L3I La Rochelle) C. CLARAMUNT Professeur (IRENav Brest) R. LAURINI Professeur (LIRIS Lyon) J. LE MAITRE Professeur (LSIS Marseille) H. MARTIN Professeur (LSR IMAG Grenoble) S. SERVIGNE MdC (LIRIS Lyon) D. SOL MARTINEZ Professeur (ITESM Puebla) 1

2 2

3 SIGLE ECOLE DOCTORALE CHIMIE DE LYON Responsable : M. Denis SINOU E2MC ECONOMIE, ESPACE ET MODELISATION DES COMPORTEMENTS Responsable : M. Alain BONNAFOUS E.E.A. ELECTRONIQUE, ELECTROTECHNIQUE, AUTOMATIQUE M. Daniel BARBIER E2M2 EVOLUTION, ECOSYSTEME, MICROBIOLOGIE, MODELISATION M. Jean-Pierre FLANDROIS EDIIS INFORMATIQUE ET INFORMATION POUR LA SOCIETE M. Lionel BRUNIE EDISS INTERDISCIPLINAIRE SCIENCES-SANTE M. Alain Jean COZZONE MATERIAUX DE LYON M. Jacques JOSEPH Math IF MATHEMATIQUES ET INFORMATIQUE FONDAMENTALE M. Franck WAGNER MEGA MECANIQUE, ENERGETIQUE, GENIE CIVIL, ACOUSTIQUE M. François SIDOROFF NOM ET COORDONNEES DU RESPONSABLE M. Denis SINOU Université Claude Bernard Lyon 1 Lab Synthèse Asymétrique UMR UCB/CNRS 5622 Bât ème étage 43 bd du 11 novembre VILLEURBANNE Cedex Tél : Fax : sinou@univ-lyon1.fr M. Alain BONNAFOUS Université Lyon 2 14 avenue Berthelot MRASH M. Alain BONNAFOUS Laboratoire d Economie des Transports LYON Cedex 07 Tél : Alain.bonnafous ish-lyon.cnrs.fr M. Daniel BARBIER INSA DE LYON Laboratoire Physique de la Matière Bâtiment Blaise Pascal VILLEURBANNE Cedex Tél : Fax Daniel.Barbier@insa-lyon.fr M. Jean-Pierre FLANDROIS UMR 5558 Biométrie et Biologie Evolutive Equipe Dynamique des Populations Bactériennes Faculté de Médecine Lyon-Sud Laboratoire de Bactériologie BP OULLINS Tél : Fax E2m2 biomserv.univ-lyon1.fr M. Lionel BRUNIE INSA DE LYON EDIIS Bâtiment Blaise Pascal VILLEURBANNE Cedex Tél : Fax M. Alain Jean COZZONE IBCP (UCBL1) 7 passage du Vercors LYON Cedex 07 Tél : Fax : cozzone@ibcp.fr M. Jacques JOSEPH Ecole Centrale de Lyon Bât F7 Lab. Sciences et Techniques des Matériaux et des Surfaces 36 Avenue Guy de Collongue BP ECULLY Cedex Tél : Fax Jacques.Joseph@ec-lyon.fr M. Franck WAGNER Université Claude Bernard Lyon1 Institut Girard Desargues UMR 5028 MATHEMATIQUES Bâtiment Doyen Jean Braconnier Bureau 101 Bis, 1 er étage VILLEURBANNE Cedex Tél : Fax : wagner@desargues.univ-lyon1.fr M. François SIDOROFF Ecole Centrale de Lyon Lab. Tribologie et Dynamique des Systêmes Bât G8 36 avenue Guy de Collongue BP ECULLY Cedex Tél : Fax : Francois.Sidoroff@ec-lyon.fr 3

4 4

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

6 6

7 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 spatiotemporelles 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, spatiotemporel, multicritère, capteurs fixes / agiles, saturation de base de données 7

8 8

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

10 10

11 Table des matières 11

12 Introduction Présentation de la problématique Les réseaux de capteurs Application à la surveillance de phénomènes environnementaux Les mesures Types de mesures Localisation des mesures Les capteurs Les classes de capteurs Capteurs fixes, agiles, mobiles Fonctionnement des capteurs et gestion de l'énergie Considérations Réseau Routage Transmission Surveillance de l'état du réseau Les difficultés liées à l'utilisation de capteurs Conclusion sur l'utilisation des capteurs Cas d'utilisation d'un réseau de capteurs Du réseau de capteur au système de surveillance Les données collectées Spécification des besoins Conclusion sur les réseaux de capteurs pour la surveillance de phénomènes Contexte : définition de Temps Réel Une définition du temps réel Ordonnancement et assignation de priorité Earliest deadline first Rate Monotonic Gestion des transactions apériodiques

13 3.1.2 Méthodes répandues de contrôle de la concurrence Contrôle à verrou...56 Contrôle optimiste...56 Contrôle Multiversion...57 Résumé des contrôles de concurrence Restrictions imposées aux BDTR Fonctionnement d'une base de données temps réel Les bases de données temps réel existantes...60 RODAIN Évolution des systèmes temps réel liée aux avancées technologiques Systèmes d'indexation avec prise en compte de la mémoire cache Conclusion : temps réel et BDTR Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes Indexation spatio-temporelle Taxonomies spatio-temporelles Approche spatiale Approche temporelle Approche spatio-temporelle Indexation et requêtes Bases de données spatiales La famille des binary-tree...73 kd-tree [7] Techniques d indexation basées sur les B-Tree...74 R-Tree [22]...74 R* Tree [6]...75 DR-Tree [40] Méthodes de cellules basées sur le hachage dynamique...76 Grid File [56] Ordonnancement des objets spatiaux...77 Quadtree et Linear Regional Quadtree (LRQ) [20][66] Bases de données temporelles Index basés sur les B+ Tree...79 Append-Only Tree [56]...79 B+ Tree avec ordre linéaire [56]

14 Multi Version B Tree (MVBT) [5] [76] Méthode basées sur l indexation spatiale...80 Index Time-Polygon [56]...80 R-Tree [22] Bases de données bitemporelles...81 GR-Tree [9] Base de données spatio-temporelles DR-Tree [78]...82 HR Tree, MR Tree [49]...83 MV3R-Tree [74] Indexation et Temps-Réel...85 CR-Tree [34]...85 PR-Tree [70]...85 PCR-Tree [69] Critique des index disponibles Le PoTree Contexte d'utilisation Rappels sur les aspects spatiaux et temporels Représentation des données et temps-réel Lien avec la base de données Structure du PoTree Le sous-arbre spatial Lien avec les capteurs La structure du sous-arbre et l'accès aux données Insertion et suppression de données Accès aux données : quelques requêtes moins fréquentes Performances théoriques Les sous-arbres capteur Amélioration de l'accès en mémoire Mise en avant des données les plus récentes Performances théoriques Exemples de requêtes Implémentation et tests Résumé sur le PoTree Conclusion sur l'indexation spatio-temporelle de données issues d'un réseau de capteurs fixes Indexation spatio-temporelle de données issues d'un réseau de capteurs agiles

15 5.1 Agilité, mobilité et index spatio-temporel Concepts Indexer le passé DR-Tree [78] HR-Tree, MR-Tree [49] HR+Tree [74] MV3R-Tree [75] Multiversion Linear Quadtree (MVLQ) [81] Partially persistent R Tree (PPR) [35] Scalable and Efficient Trajectory Index (SETI) [14] Start/End timestamp B-tree (SEB) [72] R-tree [50] Indexer la position courante Lazy Update R-tree (LUR) [36] Hashing Indexer les positions courante et futures PMR Quadtree pour objets mobiles [77] Time Parametrized R-Tree (TPR) [65] Synthèse et critique des index disponibles Le PasTree Contexte d'utilisation Des nouveautés, mais également des points communs avec le PoTree L'agilité des capteurs Accès aux données La structure du PasTree Les principales modifications La gestion multicritère La gestion de l'agilité Ajout d'un niveau d'abstraction au sous-arbre capteur Gestion des accès concurrentiels L'interface centrale Le sous-arbre d'identifiants Politique de nommage des capteurs Accès aux données, les arbres de capteur Mise à jour de la structure Suppression de données et de capteur Coût de fonctionnement de la structure Le sous-arbre spatial Un Quadtree multiversion

16 L'accès aux arbres capteur La mise à jour La suppression de données Coût de la structure Le sous-arbre capteur Réutilisation du sous-arbre capteur du PoTree, avec quelques ajouts Niveau d'abstraction au niveau des données : mesure / mouvement La gestion de la position au sein du B+Tree Accès aux données Les mises à jour Suppression de données Aspect mathématique Exemples de requêtes Implémentation et tests PasTree : conclusion Conclusion sur l'indexation de données issues de capteurs agiles La gestion de la saturation Contexte général Le StH Contexte d'utilisation Rappels sur les besoins liés aux bases de données capteurs Ajout de la notion d'observations Les spécificités de la gestion de la saturation Considérations sur l'importance de données La structure du StH Métaphore du jardin L'interface La sous-structure d'accès d'identifiants La sous-structure d'accès spatial La sous-structure capteur La racine de l'escalier Les marches de l'escalier et les écailles La fonction de chaleur La mise à jour de l'escalier Le processus de transfert L'accès aux données La suppression de données

17 6.2.2 Exemple de requêtes Mises à jour du StH Accès aux données du StH Implémentation et test du StH Conclusion sur le StH Conclusion générale sur la gestion de la saturation dès la construction de l'index Conclusion

18 Index des illustrations Figure 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 Figure 23 : Structure des composants du sous-arbre capteurs Figure 24 : Processus de recherche d'une mesure dans l'arbre capteur à partir d'une date donnée Figure 25 : Processus de résolution d'une requête sur un point spatial et un intervalle temporel Figure 26 : Évolution du temps de construction des structures en fonction du nombre de données à indexer 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) Figure 28: Exemple de courbe d'étouffement du système 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) Figure 30 : Image d'origine, Quadtree et enregistrement multiversion [81] Figure 31 : Construction du SEB-Tree [72] Figure 32 : TPR-Tree [65]

19 Figure 33 : Structure globale du PasTree Figure 34 : Structure du PasTree Figure 35 : Rôle de l'interface Figure 36 : Processus d'échanges via l'interface lors d'une mise à jour Figure 37 : Structuration de l'arbre d'identifiants Figure 38 : Mise à jour via l'arbre d'identificateur Figure 39 : Suppression de capteur à partir de l'arbre d'indentifiants Figure 40 : Structure du Quadtree multiversion Figure 41 : Structuration du Quadtree multiversion Figure 42 : Recherche de capteur via l'arbre spatial (point spatial, instant temporel) Figure 43 : Modification des intervalles des requêtes en fonction de la présence du capteur C au point P Figure 44 : modification des intervalles de recherche en fonction des enregistrements Figure 45 : Processus de mise à jour de données via l'arbre spatial Figure 46 : Modification d'enregistrement multiversion lors d'une suppression Figure 47 : Structure du sous-arbre capteur Figure 48 : Structuration de la racine de l'arbre capteur Figure 49 : Structuration des nœuds de l'arbre capteur Figure 50 : Lien entre le nœud et la position du capteur 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 Figure 53 : Processus de mise à jour de l'arbre capteur Figure 54 : Temps de construction du PasTree en fonction du nombre de données à indexer pour 68 stations fixes Figure 55 : Influence du taux d'agilité sur le temps de construction du PasTree, avec un nombre de capteurs et de données fixes Figure 56 : Temps de construction PoTree / PasTree en fonction du nombre de points à indexer pour 68 capteurs fixes 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 Figure 58 : Exemple de chaleur de données liée à un signal continu Figure 59 : Exemple de chaleur associée à un signal carré Figure 60 : Structure globale du StH Figure 61 : Rôle de l'interface Figure 62 : Structure d'un enregistrement multi-version Figure 63 : Représentation de l'escalier capteur

20 Figure 64 : Structure de l'escalier capteur Figure 65 : Structure de la racine de l'escalier Figure 66 : Structure d'une marche de l'escalier Figure 67 : Structure d'une écaille de l'escalier Figure 68 : Processus de mise à jour mesure de l'escalier Figure 69 : Processus de mise à jour de mouvement de l'escalier Figure 70 : Processus de transfert de données de l'escalier Figure 71 : Résolution d'une requête d'accès aux données via un instant temporel Figure 72 : Temps de création du R-Tree et du QuadTree selon le nombre de capteurs Figure 73 : temps de construction de l'escalier en fonction de la fonction de chaleur Figure 74 : Temps de création de l'escalier en fonction du nombre d'écailles dans la structure Figure 75 : Temps de construction de l'escalier selon le nombre de données par écaille

21 Index des tables Tableau Tableau Tableau Tableau Tableau Tableau 1 : Représentation des évènements selon la dimension temporelle : Comparatif entre les index spatio-temporels : Exemple de table de localisation de capteurs [33] : Représentation des positions de plusieurs capteurs : Récapitulatif des index couvrant l'agilité ou la mobilité : Types d'accès en fonction des requêtes

22 22

23 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 spatiotemporelles, 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. 1 Un capteur est dit agile lorsque sa position change ponctuellement et non en continu dans le temps et l espace. 23

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

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

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

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

28 Présentation de la problématique 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 28

29 Présentation de la problématique 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. 29

30 Présentation de la problématique De cape et de crocs - Jean sans Lune - Delcourt 30

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

32 Les réseaux de capteurs 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. 32

33 Les réseaux de capteurs Les mesures 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 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 33

34 Les réseaux de capteurs 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. 34

35 Les réseaux de capteurs 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. Figure 1: Capteur de visibilité (jour/nuit) 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 Les classes de capteurs Plusieurs 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 35

36 Les réseaux de capteurs 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. Internet Portail d'entrée Capteurs puissants Station de supervision Capteur / Station de Base Station de supervision Capteur / Station de Base Station de supervision Capteur / Station de Base Capteurs légers mobiles Figure 2 : Exemple de réseau de capteur 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 36

37 Les réseaux de capteurs 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 Capteurs fixes, agiles, mobiles Le 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 37

38 Les réseaux de capteurs 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 Fonctionnement des capteurs et gestion de l'énergie Les 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. 38

39 Les réseaux de capteurs Considérations Réseau La 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 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 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é. 2 Duty-cycle : pourcentage de temps pendant lequel le capteur est à l'écoute du réseau ou transmet 39

40 Les réseaux de capteurs ΔT ΔT ΔT Temps Figure 3 : Division du temps TDMA entre 3 tâches 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 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 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 40

41 Les réseaux de capteurs 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 Les difficultés liées à l'utilisation de capteurs L'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 sousestimer 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... 41

42 Les réseaux de capteurs 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 Conclusion sur l'utilisation des capteurs Les 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é. 42

43 Les réseaux de capteurs 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 43

44 Les réseaux de capteurs 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é Du réseau de capteur au système de surveillance Lorsque 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 44

45 Les réseaux de capteurs 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 Les données collectées Les 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. Sensor System Sensor acquisition Central System DataWarehouse Sensors Management Communication Management RAM Based Database Communication Management Figure 5 : Système de surveillance de phénomène naturel 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 45

46 Les réseaux de capteurs 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 celleci qui le sont. Figure 6 : Formats des données 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). 46

47 Les réseaux de capteurs Spécification des besoins Le 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. 47

48 Les réseaux de capteurs 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. 48

49 Les réseaux de capteurs 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. 49

50 Les réseaux de capteurs De cape et de crocs Chasseurs de Chimères - Delcourt 50

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

52 Contexte : définition de Temps Réel 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 nonrespect d'une de ces contraintes est à éviter. S'il devait arriver, ce nonrespect 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 nonrespect 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. 52

53 Contexte : définition de Temps Réel Les contraintes dures (hard deadlines) sont les plus sévères. Leur nonrespect 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. 3 L'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é. 53

54 Contexte : définition de Temps Réel - 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 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] Earliest deadline first Dans cette approche en ligne 4, 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. 4 En 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. 54

55 Contexte : définition de Temps Réel 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 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 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 55

56 Contexte : définition de Temps Réel fonctionnement du système en respectant ces contraintes et en s'assurant que les données accédées respectent ces priorités 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é 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. 56

57 Contexte : définition de Temps Réel 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 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. 57

58 Contexte : définition de Temps Réel 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 Fonctionnement d'une base de données temps réel Le 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 58

59 Contexte : définition de Temps Réel 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 59

60 Contexte : définition de Temps Réel 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 Les bases de données temps réel existantes Là 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». 60

61 Contexte : définition de 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 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. 61

62 Contexte : définition de Temps Réel 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. 62

63 Contexte : définition de Temps Réel Temps d'accès Mémoire Disque Mémoire Vive Mémoire Cache Volume de mémoire Figure 7 : Différence entre différents types de 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. 63

64 Contexte : définition de Temps Réel 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 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]. 64

65 Contexte : définition de Temps Réel 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. 65

66 Contexte : définition de Temps Réel De cape et de crocs - Le Mystère de l'île Étrange - Delcourt 66

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

68 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 spatiotemporelle 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. 68

69 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 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 Taxonomies spatio-temporelles La 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] 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 69

70 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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. 70

71 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 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 71

72 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 Point Temporel Instantané (Snapshot) Intervalle Temporel Période Changement Mouvement Instantané Version Changement Mouvement Couche Instantané Temporel (Snapshot) Changement Mouvement Instantané Version Phénomène Changement 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 spatiotemporelle [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 Indexation et requêtes 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 72

73 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 celleci?»), 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 La famille des binary-tree La 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]) 73

74 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 Techniques d indexation basées sur les B-Tree Alors 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 RTree 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. Figure 9 : Structure d'un R-Tree (schéma de [56]) 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 74

75 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 75

76 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes des entrées de la forme <pointeur data, rectangle> Les DR Tree comportent, du par la division des objets, des enregistrements de taille variables. Figure 10 : Découpage d'un objet et structure du DR-Tree correspondant [40] 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 Méthodes de cellules basées sur le hachage dynamique On 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. 76

77 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 Ordonnancement des objets spatiaux Dans 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. 77

78 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes Figure 11 : Image, Quadtree et Linear Regional Quadtree correspondants[66] 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. 78

79 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 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 sousarbres 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). 79

80 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 Méthode basées sur l indexation spatiale Dans 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 : 80

81 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 Bases de données bitemporelles Travailler 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 81

82 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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 Base de données spatio-temporelles Utiliser 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 spatiotemporel. 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 spatiotemporelle. 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). 82

83 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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. 83

84 Indexation spatio-temporelle de données issues d'un réseau de capteurs fixes 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. Figure 14 : Structure du MV3R-Tree [74] 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 84