Limites et contraintes de SensorScript

SensorScript permet, pour les cas d’utilisation étudiés dans ce scénario, de proposer des requêtes plus concises et qui, outre la syntaxe opérationnelle du langage, ne réclament pas aux acteurs de connaître plus

que ce qui a été défini comme leurs contextes d’utilisation lors de la modélisation du multiarbre. Si le langage permet cela en s’appuyant sur la gestion du multiarbre par SensorScript, notamment en ce qui concerne le parcours implicite entre les nœuds à partir de l’expression d’une requête, il n’en demeure pas moins que le langage est également contraint pas ces choix de conception.

De fait, un point non abordé reste la gestion d’un historique des données. Si les conditions temporelles permettent le suivi, pendant une période de temps, des attributs issus du flux de données, ces données sont oubliées dès que possible par le framework. De fait, en dehors du cadre d’une condition temporelle, rien dans le langage ne permet de raisonner, pour chaque attribut, sur autre chose que la dernière valeur remontée. Ainsi récupérer une valeur vieille d’une heure d’un attribut a posteriori n’est pas possible dans le langage, contrairement à ce que proposent par définition les langages basés sur le paradigme objet-relationnel, tel que CQL.

Concernant la composition d’événements, notamment la construction de flux composites, l’on vient de voir qu’elle ne peut prendre place que dans la spécification de nouveaux attributs des nœuds. Si c’est bel et bien une contrainte de SensorScript, nous considérons néanmoins ce point comme un point fort de la solution, puisqu’il s’inscrit naturellement dans la modélisation du réseau de capteurs en multiarbre et cadre de fait la composition des événements dans les contextes d’utilisation pré-établis.

8

Conclusions et travaux futurs

Sommaire

8.1 Synthèse et bilan . . . 98 8.2 Perspectives de recherche . . . 99 8.2.1 Historisation des données . . . 99 8.2.2 Traitement distribué . . . 99

8.1 Synthèse et bilan

Le succès grandissant des réseaux de capteurs conduit à un accroissement des domaines d’application des capteurs et une multiplication des usages qui en sont faits. Dans ce contexte, la taille des réseaux de cap- teurs devient de plus en plus problématique quant à l’identification, au niveau des points de collecte, de la localisation et des mesures effectuées par tel ou tel capteur. Cette problématique devient d’autant plus prégnante que les profils d’utilisateur tendent à se diversifier avec les domaines d’expertise qu’adressent ces capteurs. Le besoin devient alors de permettre à tout un chacun d’identifier aisément les données qui l’intéressent sans que ces données ne lui paraissent noyées dans le flux de données incessant issu du réseau de capteurs.

Dans cette optique, nous avons établi par une étude de la littérature les différentes pistes permettant l’adaptation des structures de données aux besoins des utilisateurs. Au terme de cette étude il nous est apparu que l’inscription des capteurs et données au sein de contextes, définis comme la localisation des capteurs dans des environnements maîtrisés par l’utilisateur, offrent une solution à même de répondre au besoin exprimé. Deux autres points restent cependant en suspens.

D’une part, il est nécessaire non seulement de proposer une contextualisation des données en fonction des besoins utilisateur, mais de le faire pour chaque utilisateur final de la solution. En effet, les besoins exprimés par chacun de ces utilisateurs seront différents d’un profil d’utilisateur à un autre. Naturellement, certains de ces contextes peuvent être communs à plusieurs utilisateurs, de la même manière qu’un seul utilisateur peut être amené à maîtriser plusieurs contextes.

D’autre part, il est crucial de ne pas perdre de vue le fait que certains de ces utilisateurs, si ce n’est la majorité, ne sont pas des utilisateurs intensifs. Il est alors indispensable de proposer à cette gestion multi- contextes et multi-utilisateurs du réseau de capteurs une interface permettant un usage brassant le moins possible de concepts externes aux contextes concernant un utilisateur, ce pour chaque utilisateur. Dans cette optique, nous avons fait le choix de la conception d’un langage dédié.

La gestion multi-contextes du réseau de capteurs fait l’objet d’une modélisation prenant la forme d’un multiarbre. Chaque arbre constitutif du multiarbre correspond alors à un contexte d’utilisation, tels que défi- nis par une étude préalable des besoins de chaque utilisateur vis-à-vis du réseau de capteurs. Le choix d’une telle modélisation s’appuie sur les facilités de parcours qu’elle permet : en s’appuyant sur les propriétés propres au multiarbre, on assure pour la suite un parcours implicite à même de simplifier l’interface et ce faisant l’expérience utilisateur.

À cette modélisation du réseau de capteurs s’adosse un complex event processor. La tâche du traitement des événements complexes est alors d’intégrer la notion de contextes dans la définition des événements, qu’ils soient atomiques ou composites. Cela passe par la définition d’un traitement selon trois points :

• la sélection de nœuds du multiarbre, sélection qui peut être filtrée en fonction d’autre nœuds ;

• l’expression de conditions sur ces sélections, permettant d’étendre le fitrage des nœuds aux données ; • l’accès aux attributs et méthodes des nœuds, correspondant pour partie aux données brutes et aux

événements composites.

Ces trois éléments constitutifs du traitement des événements complexes par SensorScript se reflètent dans les requêtes du langage dédié. C’est à ce stade que la sélection tire parti du parcours implicite dans le multiarbre puisque le filtrage des nœuds par sous-sélection s’exprime indépendamment de la distance, dans le modèle, entre les nœuds des deux sous-sélections. L’expression des conditions introduit également la notion de gestion du temps, avec la possibilité de suivre la vérification d’un prédicat durant un temps minimal.

Les réseaux de capteurs sont constitués non seulement de capteurs, mais également d’actuateurs, per- mettant une interaction avec l’environnement. Une contribution de cette thèse porte sur la possibilité d’adres- ser, directement depuis le langage dédié, ces fonctionnalités d’actuation. Cette possibilité passe par l’implé-

8.2. PERSPECTIVES DE RECHERCHE 99