Contextualisation multi-utilisateurs d’un réseau de capteurs 

Diffusion scientifique

Les travaux présentés dans ce document ont fait l’objet de publications présentées dans des conférences francophone et internationales avec comité de lecture : [1] Alexandre Garnier, Jean Marc Menaud, and Rémy Pottier. Sensorscript : un langage de requête dédié, orienté métiers, pour les réseaux de capteurs. In Conférence d’informatique en Parallélisme, Architecture et Système, 2015.
[2] Alexandre Garnier, Jean-Marc Menaud, and Rémy Pottier. Sensorscript : a business-oriented domainspecific language for sensor networks. In Future Internet of Things and Cloud (FiCloud), 2015 3rd International Conference on, pages 44–49. IEEE, 2015.
[3] Alexandre Garnier, Jean-Marc Menaud, and Nicolas Montavont. Bringing complex event  processing into multitree modelling of sensors. In Distributed Applications and Interoperable Systems, pages 196– 210. Springer, 2016.

Organisation du document

Ce document se décompose en trois parties. La partie I introduit le contexte de la thèse. Le chapitre 2 définit les concepts constituant la base de ce document que sont l’internet des objets, les réseaux de capteurs, les langages dédiés et le CEP. Le chapitre 3 inscrit les travaux de cette thèse dans l’état de l’art de la recherche, au travers d’une revue de la littérature scientifique autour des problématiques présentées auparavant.
La partie II se concentre sur les contributions de la thèse. Le chapitre 4 présente plus en détail la modélisation en multiarbre d’un réseau de capteurs. Le chapitre 5 est consacré au traitement des événements complexes s’appuyant sur une telle modélisation.
La partie III aborde l’implémentation de ces contributions. Le chapitre 6 présente SensorScript, le fruit des travaux de la thèse. Le chapitre 7 propose plusieurs évaluations expérimentales de cette implémentation.
Enfin, le chapitre 8 apporte une conclusion au document et ouvre la voie à d’autres perspectives.

Internet des objets

Depuis l’invention du transistor au milieu du XX ème siècle, son usage s’est démocratisé dans une multitude de secteurs, amenant au fil des décennies des circuits électroniques, plus ou moins complexes, presque omniprésents dans tout appareil électrique. Au tournant du XXI ème siècle, la miniaturisation et la baisse des coûts dans l’informatique a mené à l’émergence de ce qu’on appelle l’informatique embarquée. Il s’agit d’une évolution presque naturelle de l’électronique déjà présente dans les matériels concernés, mais d’une évolution majeure, puisqu’elle a permis l’introduction de standards, pré-existants dans l’informatique, notamment en ce qui concerne les réseaux. Les domaines d’applications de ces innovations gravitent autour de la domotique pour le public amateur, d’outils de mesure à grande échelle dans des cadre plus professionnels, pour tout ce qui va concerner l’étude des reliefs ou de la sismologie, mais également des mesures énergétiques plus précises au sein des entreprises et centres de données. Cette mise en réseau, dans des domaines variés, de matériels non spécifiques à l’informatique constitue de fait l’Internet des objets [Ash09].
En parallèle, des évolutions technologiques récentes participent de l’expansion de l’Internet des objets.
Les technologies de communication sans fil, des standards GSM et WiFi au 6LoWPAN [Mul07] ont permis une réduction de la complexité et du coût dans la mise en place des infrastructures sous jacentes. L’émergence récente du matériel libre (open-source hardware) invite à une standardisation de la couche logicielle des objets connectés.
L’engouement autour de l’Internet des objets se confronte cependant à deux principaux problèmes.
D’une part, l’absence de standard a priori a amené à de multiples solutions partiellement ou totalement incompatibles ; en outre, les solutions industrielles s’appuient encore trop souvent sur des firmware et protocoles fermés, du fait d’intérêts bien éloignés de telles considérations. D’autre part, les besoins autour de l’Internet des objets a un impact sur la taille des réseaux mis en jeu, et très vite apparaît le risque d’interférences dans les communications entre les objets, surtout quand les protocoles réseau entre en conflit avec les standards WiFi ou GSM. À ce sujet, Gartner [Gar14] estime une évolution au triple du nombre d’objets connectés d’aujourd’hui à 2020, comme le montre la figure 2.1.

Réseaux de capteurs sans fil

La solution à la seconde problématique d’encombrement matériel des systèmes de communication filaires consiste en l’introduction de systèmes de radiocommunication dans les réseaux de capteurs. On parle alors de réseaux de capteurs sans fil [ASSC02b].
S’appuyant sur les standards de communication issus de l’Internet des objets, ces réseaux deviennent chaque jour plus incontournables dès qu’il s’agit de faire interagir système informatique et monde réel.
Ils sont toutefois sujet à de nouvelles problématiques. La largeur de bande, ou l’encombrement spectral.
Des protocoles réseau, tels IEEE 802.15.4 [MBC+ 04], LoRa [All16] ou Sigfox [Dav15] ont été développés afin d’y répondre. En revanche, une seconde problématique, toujours prégnante celle-ci, concerne les risques d’interférences lors du passage à l’échelle. Il s’agit là d’une problématique inhérente au support physique des communications sans fil : les ondes électromagnétiques. Avec un nombre grandissant d’ondes en circulation, le risque d’interaction entre deux ondes s’accroît. Or l’interaction entre deux ondes électromagnétiques chacune porteuse d’un signal peut-être source de perte de l’information des dits signaux.
Enfin, un enjeu dont l’importance ne cesse de grandir avec l’adoption des capteurs, encore accélérée par l’émergence des réseaux de capteurs sans fil, concerne la gestion du parc de capteurs et actuateurs, qu’il s’agisse du traitement des données mesurées par les capteurs ou l’intégration des actuateurs dans des processus d’automatisation. La standardisation des réseaux de capteurs a avant tout porté sur les couches basses des protocoles de communication. Reste à la charge de l’utilisateur de savoir quoi communiquer aux capteurs et actuateurs et d’en interpréter les données, avec potentiellement autant de langages de communication qu’il existe de matériels différents. S’attaquant à cette problématique, des protocoles plus haut niveau existent, sans pour autant qu’un réel standard ne se soit encore imposé. Parmi ces CoAP [SHB14], qui propose l’accès en UDP aux mesures d’un capteur dans une arborescence, ce via des URI.

Interfaces homme-machine

Le réseaux de capteurs font partie des systèmes informatique destinés à des utilisateurs. Une question primordiale concerne alors la façon de permettre leur utilisation. Le domaine consacré à cette considération concerne les interfaces homme-machine [LM90] (IHM). L’objectif premier d’une IHM est de répondre aux besoins des utilisateurs. Le travail effectué dans sa conception porte avant tout sur l’établissement d’une liste exhaustive de ces besoins et leur rationalisation en ce qu’on appelle des cas d’utilisation. Cette rationalisation porte sur le découpage en étapes des besoins utilisateurs, la factorisation de certaines de ces étapes. L’objectif est d’inscrire les besoins dans un nombre fini et raisonnable d’algorithmes.
La seconde étape consiste alors à trouver une solution pratique à même de répondre de façon satisfaisante à ces cas d’utilisation. Nous allons ici distinguer deux directions possibles sur un point de comparaison précis : la flexibilité de l’outil qu’est l’IHM. En étudiant les étapes en commun parmi les besoins identifiés, différentes manières d’aborder la conception de l’IHM sont envisageables. On peut considérer qu’à chaque besoin, à chaque séquence d’événements pré-identifiés correspondra un outil particulier. Dès lors l’interface, qu’elle soit graphique ou non, proposera pour chacun de ces besoins un scénario précis. L’utilisateur n’aura qu’à suivre les rails pré-établis pour arriver au résultat escompté. Cette solution est particulièrement adaptée aux applications dont les besoins sont restreints en nombre et clairement identifiés. La factorisation de ceux-ci ne sert alors qu’à l’optimisation du traitement des besoins, optimisation invisible à l’utilisateur, pour qui les cas d’utilisation restent bien distincts.
Dans le cas où les besoins sont autrement plus nombreux, voire s’entremêlent, une telle solution ne convient pas et il semble alors pertinent de proposer une solution à même de permettre directement à l’utilisateur de tirer partie de la factorisation des cas d’utilisation. Les langages dédiés font partie des implémentations d’une telle solution.

Langages dédiés

La communication avec les ordinateurs se fait, de manière ou non cachée, par le biais de langages. Que ce soit le langage machine tel que décrit dans la machine de Turing [Tur48] ou les langages de programmation, à différents niveaux d’abstraction vis-à-vis du fonctionnement logique de la machine, visant à offrir aux utilisateurs un accès plus intuitif aux capacités de calcul, tout passe par un langage informatique, réductible à une grammaire de Chomsky [Cho56]. L’intérêt premier d’un langage informatique, quel que soit son niveau d’abstraction, est de permettre, via l’accès à un nombre fini d’opérations simples, l’expression d’une infinité de calculs et d’algorithmes.
À considérer un cadre d’application plus restreint, tel que l’ensemble des cas d’utilisation évoqués plus haut, on constate que la mise à disposition d’un langage de haut niveau s’avère être un excellent choix en terme d’IHM, dès lors qu’on retrouve des contraintes similaires : un grand nombre de besoins, potentiellement infinis, mais dans un cadre bien défini, constitués d’étapes, d’opérations, clairement identifiées et en nombre beaucoup plus raisonnable. C’est ce qu’on appelle les langages dédiés [Hud97].
Du fait d’un cadre applicatif plus restreint, circonscrit aux seuls besoins pré-établis, ils ne sont pas nécessairement Turing-complets (pas plus qu’ils ne sont nécessairement non-Turing-complets). L’objectif est avant tout, comme pour toute IHM, d’adresser tous les besoins utilisateurs pré-établis, idéalement de manière également efficace pour tous les besoins. En pratique, des contraintes diverses (incompatibilités entre les besoins, restrictions du langage de programmation sous-jacent, etc.) entrent en jeux et il s’agit surtout d’assurer au minimum pour chaque cas d’utilisation une accessibilité en proportion de la fréquence du besoin utilisateur lié. Outre la flexibilité, un autre intérêt des langages dédiés en tant qu’IHM porte sur l’extensibilité. Exprimés via une grammaire de Chomsky, l’ajout de fonctionnalités consiste assez naturellement en l’ajout de règles de développement afférentes. En outre, pour chacune de ces fonctionnalités, ce que l’étude des nouveaux cas d’utilisation associés aura révélé comme faisant déjà partie du langage pourra être réutilisé de manière transparente dès l’expression de la grammaire.depuis des séries chronologiques. En s’inspirant de la discrimination dite soi – non soi des systèmes immunitaires, ils proposent, pour chaque série chronologique, une collection de séquence de données, qui correspondent au soi de la série. La détection du non soi est assurée par des détecteurs, conçus de telle sorte qu’ils ne reconnaissent aucune des séquence du soi. Ainsi, toute séquence détectée sera identifiée comme non soi. La forme des séquence ainsi que l’algorithme d’un détecteur peuvent prendre de multiples formes, depuis une simple comparaison de chaîne à l’utilisation de tranformées de Fourier, parmi les exemples évoqués. On retrouve donc ici les méthodes statistiques, rendues applicables à un flux de données.
Toutefois, considérer les flux de données issues d’un réseau de capteurs comme des séries chronologiques, qui pis est dans les SGBD, pose rapidement un problème de passage à l’échelle : leur taille grandissant sans cesse par définition, on finit par atteindre, pour tout SGBD, un seuil critique. Des solutions s’attellent à cette problématique. Lazaridis et Mehrotra [LM03] proposent ainsi une compression des séries temporelles, par les capteurs eux-mêmes, afin de réduire la taille des paquets transitant entre capteurs et nœud-puits. Dans un soucis de satisfaire au mieux au besoin de traitement en temps réel des applications clientes du réseau de capteurs, ils proposent également un mécanisme de prédiction des données, ce en fonction des données déjà connues. Ces prédictions, pour être valable, s’appuient sur un prédicat qu’on retrouvait dans les travaux de Dasgupta et Forrest, à savoir que le flux de données montre un comportement identifié ou identifiable. Notons également que ce mécanisme de prédiction peut prendre place tant au niveaux des capteurs que du nœud-puits. L’étude proposée permet de montrer que compression et prédiction peuvent fonctionner de concert tout en gardant des performances satisfaisantes pour l’une et l’autre.
Dans l’optique d’adresser les séries chronologiques au sein des requêtes d’un SGBD, COUGAR [BGS01] se propose d’intégrer l’accès, en pull plutôt qu’en push, aux données des capteurs via les Abstract Data Types [GNT91], en charge de la construction de séries chronologiques, considérées comme des relations virtuelles, depuis le flux de données. En pratique, la représentation des séries temporelles est basée sur le modèle de séquence pour les bases de données de Seshadri et al. [SLR95]. Une distinction conceptuelle est donc faite entre relations, format traditionnel des données stockées en base, et séquences, format utilisé pour représenter les séries chronologiques représentant les flux de données issues des capteurs. Afin d’adresser les deux au sein d’une même requête, trois opérateurs sont mis à disposition, permettant la projection d’une séquence en une relation, le produit en croix d’une relation et d’une séquence, et l’aggrégation d’une séquence. Néanmoins, aucun de ces trois opérateurs ne permet l’expression d’aggrégation temporelle d’une séquence, c’est à dire l’aggrégation a posteriori d’un nombre donné des dernières valeurs d’une série chronologique.
Dans un contexte plus précis, Hammad et al. [HAE03] envisagent la détection du mouvement d’objetselon la définition de jointures « fenêtrées. » Une fenêtre établit ici une limite haute à l’intervalle de temps séparant la détection d’un même objet par deux capteurs différents. La définition de ces intervalles se fait au moyen d’un opérateur dédié intégré au langage de requêtes du SGBD.
Le point commun à ces solutions est qu’elles visent à adapter le flux de données, via sa gestion sous forme de série chronologique à un SGBD. Si cet aspect peut permettre de récupérer les données des capteurs à la demande plutôt que de crouler sous le flux de données, il restreint également la modélisation du réseau de capteurs et d’actuateurs, ainsi que l’expression de requêtes permettant d’en traiter les données, au modèle objet-relationnel. Nous verrons dans la suite en quoi cette restriction à de telles requêtes pose problème visà-vis d’une expérience simplifiée des utilisateurs.

Traitement des événements complexes

L’accroissement en taille des réseaux de capteurs a fait du traitement des données qui en sont issues une problématique de plus en plus prépondérante. Gaber et al. proposent une réflexion sur cette problèmatique et les pistes de recherche qui s’y consacrent [GZK05]. Les solutions abordant le passage à l’échelle du traitement des données sont alors catégorisées en deux groupes, que sont les solutions basées sur les données — des solutions visant à réduire le nombre de données à traiter par transformation statistique ou partitionnement du jeu de données — et les solutions basées sur les tâches, sur le traitement lui-même — qui introduisent notamment la notion de temps et de taux des flux de données, avec le traitement sur une fenêtre glissante des plus récentes données et l’adaptation des algorithmes à la quantité de données produites dans cette fenêtre.
Le traitement des événements complexes fait partie de cette seconde catégorie de solutions et se concentre sur le traitement en temps réel des données. Comme on l’a vu, l’inscription des données dans des événements, composables et composés, permet alors une gestion flexible du flux de données qui permet l’identification de comportements au fur et à mesure que se construisent les événements qui les constituent.
L’une des toutes premières solutions s’inscrivant dans le traitement des événements complexes est STREAM [ABB + 04]. L’objectif de STREAM est d’étendre le modèle objet-relationnel afin de permettre l’expression de requêtes dites continues. Plutôt que d’être exécutée à un instant donné sur l’état d’un jeu de données à cet instant, le fonctionnement d’une requête continue consiste en le traitement systématique de toute nouvelle donnée correspondant à son expression. D’un point de vue conceptuel, l’évolution du modèle se fait par la catégorisation de la représentation des données sous forme de relations et de streams (flux).
Une relation représente l’état d’un jeu de données à l’instant considéré et correspond aux tables des SGBD.
De fait, les relations supportent toutes les opérations habituelles sur les tables, qu’il s’agisse d’inscription, de mise à jour ou de suppression des données. Quant au stream, il représente en quelque sorte l’émission de nouvelles données, de nouvelles entrées des tables. Un stream ne permet donc de gérer que la production de nouvelles données et consistue de fait les événements atomiques dans le traitement des événements complexes.
La composition des événements consiste alors en la génération de nouveau streams en fonction des streams atomiques et des relations. Dans cette optique, des transformations entre relations et streams sont mises à disposition. En effet, la base objet-relationnel de STREAM ne permet des opérations qu’entre relations. Cette restriction est contournée par la possibilité de spécifier des fenêtres — de temps ou à taille fixe — sur les streams pour en faire des relations volatiles, au sens où leur existence est limitée au traitement au sein duquel elles sont créées, permettant alors la composition de nouvelles relations. Il est alors possible, à l’inverse, de traduire ces relations composites en streams composites. Dans ce cas, chaque nouvelle donnée de la relation composite constitue de fait le stream correspondant. La notion de fenêtres de temps se retrouvait dans TelegraphCQ [CCD + ] dès 2003. TelegraphCQ se présente comme un moteur de traitement des données pourPostgreSQL permettant une gestion en temps réel et non-bloquante d’un flux de données, ce qui le distingue d’un moteur de SGBD classique. La problématique première à laquelle se consacre TelegraphCQ est d’adapter la gestion du flux de données à un traitement des données de type relationnel et c’est à cette fin qu’est introduite la notion de fenêtre de temps, puisqu’elles permettent la construction en temps réel de tables volatiles que PostgreSQL est alors en mesure de traiter.
Dans un contexte consacré aux réseaux de capteurs, Saleh [Sal13] propose une conception du traitement des événements complexes sous forme d’automates à états finis. L’idée directrice est de considérer la description d’un événement composite comme un automate dont chacun des états correspond à un événement atomique. Un événement complexe consiste alors en la séquence des événements qui le constituent. Cette conception du traitement des événements complexes fait l’objet d’une implémentation pour le système d’exploitation embarqué TinyOS [LMP + 05] et est une première étape vers la distribution du traitement des événements complexes au sein des capteurs.

Table des matières
Contexte 
1 Introduction 
1.1 Problématique
1.2 Objectifs
1.3 Contributions
1.4 Diffusion scientifique
1.5 Organisation du document
2 Définitions et enjeux 
2.1 Internet des objets
2.2 Capteurs et actuateurs
2.2.1 Réseaux de capteurs
2.2.2 Réseaux de capteurs sans fil
2.3 Interfaces homme-machine
2.4 Traitement des événements complexes
2.5 Résumé
3 État de l’art 
3.1 Analyse des données issues d’un réseau de capteurs
3.1.1 Exploration de données
3.1.2 Bases de données de séries chronologiques
3.1.3 Traitement des événements complexes
3.1.4 Langages dédiés au traitement des événements complexes
3.2 Identification des données
3.2.1 Contextualisation
3.2.2 Enrichissement sémantique
3.3 Synthèse
II Modélisation et conception
Introduction
Rappel des enjeux
Solution proposée
Existant
4 Contextualisation multi-utilisateurs d’un réseau de capteurs 
4.1 Problématique
4.1.1 Contextes utilisateurs
4.2 Le multiarbre
4.2.1 Définitions
4.2.2 Contextes et multiarbre
4.2.3 Données et fonctionnalités du réseau de capteurs
5 Traitement des événements complexes dans un réseau de capteurs 
5.1 Traitement des événements complexes et multiarbre
5.1.1 Sélection de nœuds
5.1.2 Expressions conditionnelles
5.1.3 Accès aux attributs et méthodes
5.2 Langage dédié
5.2.1 Requêtes
5.2.2 Sélections
5.2.3 Conditions
5.2.4 Accès
III Implémentation et résultats
Introduction
6 SensorScript 
6.1 Cycle de vie d’une requête
6.1.1 Destructuration d’une requête
6.1.2 Conditions temporelles
6.2 Traitement du flux de données
6.2.1 Gestion dynamique des données
6.2.2 SensorScript en fonctionnement
7 Évaluations 
7.1 Protocole d’évaluation
7.2 Scénario de comparaison
7.3 Modélisation des contextes utilisateurs d’un réseau de capteurs
7.4 Expressivité du langage
7.4.1 Comparaison avec CQL
7.4.2 Méthodes d’actuation
7.4.3 Limites et contraintes de SensorScript
8 Conclusions et travaux futurs 
8.1 Synthèse et bilan
8.2 Perspectives de recherche
8.2.1 Historisation des données
8.2.2 Traitement distribué
Annexes

Lire le rapport complet