La plate-forme SensApp (http://sensapp.modelbased.net/) est développée en collaboration avec le laboratoire SINTEF (Oslo, Norvège). Cette plateforme permet la collecte d'informations en provenance de capteurs (humidité, température, présence, vitesse, …).

A l'heure actuelle, la plateforme ne dispose pas d'interface de recherche. Il est fastidieux pour un utilisateur de retrouver le capteur qui l'intéresse, car les recherche se font par nom. Par exemple: “osl/forsk/4/C/444/humidity” pour accéder au capteur d'humidité installé dans le bureau C444 situé au 4ème étage du bâtiment “Forskningsveien 1” à Oslo.

Ces capteurs peuvent être visualisés en utilisant différents composants graphiques en fonction du type d'informations remontées par les capteurs. Il existe aujourd'hui une interface graphique permettant d'associer un capteur à une visualisation, néanmoins nous aimerions améliorer …

Ce sujet présente donc plusieurs sous-projets exposés ci-après

Le projet intègre une part d'apprentissage de concepts, standards, et technologies. Cette part du travail sera planifiée et fera probablement l'objet de quelques productions pour faciliter l'accès à ces informations ultérieurement par d'autres développeurs.

Données sur les capteurs :

• Accès en ligne à la description des capteurs existants
• par exemple, Description d'un capteur existant
• Accès aux données issues d'un capteur
• SenML : standard de représentation des données des capteurs (actuellement la V8)

Les codes et les requêtes :

• Racine des codes sources ((Tous les services ne sont pas détaillés ici))

• Recherche de capteurs

  •  http://demo.sensapp.org/sensapp/registry/sensors?flatten=true 

    pour obtenir la liste des capteurs détaillée

  •  http://demo.sensapp.org/sensapp/registry/sensors/chicago/uic/shuttle/lambda 

    pour obtenir la description d'un capteur particulier d'identifiant chicago/uic/shuttle/lambda

• Accès aux données émises par les capteurs

•  http://demo.sensapp.org/sensapp/databases/raw/sensors 

  Returns the list of sensor databases

•  http://demo.sensapp.org/sensapp/databases/raw/sensors/chicago/uic/shuttle/lambda

  retourne une description de la base de données associée au capteur d'identifiant chicago/uic/shuttle/lambda, en utilisant un JSON format.

•  http://demo.sensapp.org/sensapp/databases/raw/data/chicago/uic/shuttle/lambda 

  Accès aux données d'un sensor donné

• point entrée pour les capteurs qui envoient du SenML

• enregistrement d'appli externe, disent ce qu'elles veulent écouter

• converter : en entree un CSV et un descripteur ⇒ SenML : ce service est utile parce que certains capteurs renvoient du CSV (torque : se branche sur le bus de la voiture)

Attention ces sous-projets ne sont pas complètement indépendants. Des rapprochements entre les sous-groupes seront envisagés dès que possible, en effet ils se complètent.

Un découpage dans le temps sera fourni ultérieurement qui stipulera les premières étapes, puis en fonction de vos avancés chacun des sujets pourra être réajusté pour mieux répondre aux besoins concrets du SINTEF.

SensApp supporte la possibilité d'ajouter des tags (paires clés-valeurs) aux capteurs. Le projet tutoré consistera en (i) la caractérisation des tags nécessaire à l'identification des capteurs en tenant compte de l'existant, (ii) l'implémentation d'un mécanisme de recherche sur ces tags et enfin (iii) en la mise en place d'une interface Web permettant d'exposer la fonctionnalité de recherche.

Ce projet inclut l'analyse de la notion de capteur et la caractérisation des informations pertinentes pour un capteur.

Vous prendrez également en compte les propriétés suivantes sur les capteurs

• Capteur one shot : toutes les données sont émises pendant une expérience, par exemple un capteur cardiaque pendant une course, dans ce cas on veut garder toutes les données….
  • La recherche de capteurs peut alors se faire sur les expériences menées : courses en vélo, promenade, période de l'année, …
• Capteur 24/7, ils produisent des données en continu, ce qui implique de très gros volumes de données avec une fréquence décidée par le concepteur du capteur. Ce type de capteurs implique l'utilisation de BD RRD.
  • La recherche du capteur pourra alors inclure la date à partir de laquelle il a commencé à émettre, sa fréquence, ….

Si vous avancez bien, vous vous intéresserez aux capteurs composites, qui correspondent à un assemblage de capteurs et exposent donc plusieurs informations simultanées.

Artefacts attendus :

1. Document faisant l'analyse du concept de capteurs et identification des caractéristiques retenues
2. Interface de saisie et recherche de capteurs
3. Réalisation d'une application qui aura pour rôle entre autre d'accéder à la base de donnée de “sensors” distantes et de compléter ces informations par vos propres informations stockées sur votre propre base de donnée. En fonction des avancées du projet, nous envisagerons ultérieurement la réalisation d'un service web REST en Java et l'utilisation de http://www.mongodb.org/ pour la base de données.

Il s'agit de permettre à un utilisateur d'enregistrer un nouveau capteur en fonction de son type (humidité, …) et de sa position dans un bâtiment, … Vous étudierez les solutions permettant de visualiser un bâtiment et de localiser un élément dans le bâtiment. Une autre version sera d'étudier la visualisation de capteurs sur des cartes comme par exemple les capteurs placés dans les rivières, …

Vous prévoirez la possibilité de créer de nouveaux types de capteurs (niveau d'eau, luminosité, son, …) et de leur associer des icones. Attention dans un même lieu un grand nombre de capteurs peuvent être présents.

Artefacts attendus :

1. Analyse des outils existants pour manipuler des plans (formalisation, représentation) et localiser des éléments sur les plans
2. Interface de visualisation d'un bâtiment/lieu avec ses capteurs
3. Interface d'ajout de capteurs dans un bâtiment

Vous étudierez les algorithmes de recherche existant et se basant sur les notions de thesaurus. Notre objectif sera de fournir une interface de recherche de sensor dans laquelle au lieu de nommer les caractéritiques, vous utiliserez des termes et aiderez l'utilisateur à affiner sa recherche, par exemple : “humidity & office & 4 floor” ou bien “C444 & humidity level”

Artefacts attendus :

1. Analyse des outils existants de recherche en utilisant des thesaurus au moins
2. Détermination des thésaurus utiles à notre problème aussi bien pour la partie sensors qu'afficheur
3. Interface d'aide à la recherche de sensors/Afficheur par saisie de mots
4. Définir une interface de recherche qui puisse être alimentée par des thésaurus.

Option : l'internationalisation de l'interface et du vocabulaire pourrait avantageusement être étudiée.

A partir des informations connues sur un capteur, et une base de composants d'affichage (Jauges, cartes, Courbes,….) vous proposerez automatiquement les afficheurs possibles pour un capteur donné. En particulier, vous prendrez en compte les échelles de mesure pour éliminer des composants mal adaptés…

Vous pourrez aussi traiter le flou dans la correspondance : par exemple pour une localisation, une jauge n'a pas de sens, peut être une courbe mais une carte de chaleur ou une carte ou une street view ont vraiment du sens.

Une évolution particulièrement intéressante serait de prévoir la visualisation de plusieurs capteurs sur un même afficheur, par exemple des courbes ou une carte.

Artefacts attendus :

1. Analyse des sensors et en particulier des types d'informations produites : type, fréquence, erreur, plage de valeurs, …
2. Analyse des afficheurs existants et des besoins : vous pourrez proposer de visualiser certaines des données fournies par les sensors.
3. Interface d'aide à la recherche d'Afficheurs correspondant à un capteur sélectionné, par exemple pour des relevés de température, des courbes ou des cartes de chaleur.