Differences

This shows you the differences between two versions of the page.

--- 2012_2013:projetstut:sensors [2012/10/08 11:26]
blay [Sous-Projets]
+++ 2012_2013:projetstut:sensors [2012/10/15 09:51] (current)
blay [Technologies utilisées]
@@ Line 1: / Line 1: @@
 ====== Interface de recherche pour des capteurs. ======
-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'information en provenance de capteurs (humidité, température, présence, vitesse, …).
+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).
+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 [[2012_2013:projetstut:sensors#sous-projets|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.
 <note warning>EN COURS DE DEFINITION</note>
 ===== Technologies utilisées =====
-Le choix des technologies....
-- html/JS
-- pour la BD? MongoDB connecté à une BD existante avec des liens par URL
-- Ils doivent savoir utiliser des services REST et en écrire un en java.
-JERSEY : librairie pour faire des web services REST
+**Données sur les capteurs :**
+  * [[http://demo.sensapp.org/sensapp/registry/sensors |Accès en ligne à la description des capteurs existants]]
+  * par exemple, [[http://demo.sensapp.org/sensapp/registry/sensors/Car1/Engine_C02 |Description d'un capteur existant]]
+  * [[http://demo.sensapp.org:80/sensapp/databases/raw/data/Car1/Engine_C02|Accès aux données issues d'un capteur]]
+  * **[[http://tools.ietf.org/html/draft-jennings-senml-08|SenML]]** : standard de représentation des données des capteurs (actuellement la V8)
-Comme serveur web on peut utiliser JETTY
-Accès en ligne à la description des capteurs existants :
-http://demo.sensapp.org/sensapp/registry/sensors
-Vous réaliserez un service web REST en Java 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. A priori nous utiliserons, si vous en avez les capacités et le voulez, http://www.mongodb.org/.
-  * **[[http://tools.ietf.org/html/draft-jennings-senml-08|SenML]]** : standard de représentation des données des capteurs (actuellement la V8)
+** Les codes et les requêtes :**
+  * [[https://github.com/SINTEF-9012/sensapp|Racine des codes sources ((Tous les services ne sont pas détaillés ici))]]
-**Accès aux services :**
+  * **[[https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.registry|Recherche de capteurs]]**
-   * 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)
+       * <code> http://demo.sensapp.org/sensapp/registry/sensors?flatten=true </code> pour obtenir la liste des capteurs détaillée
-  * database.raw : pour sauver les données
+       * <code> http://demo.sensapp.org/sensapp/registry/sensors/chicago/uic/shuttle/lambda </code> pour obtenir la description d'un capteur particulier d'identifiant ''chicago/uic/shuttle/lambda''
-  * dispatcher : point entrée pour les capteurs qui envoie du SenML
-  * Notifyer : enregistrement d'appli externe, disent ce qu'elles veulent écouter
-  * registry : comment enregistrer des capteurs, voir ceux qui sont présents
-  * RRD : Bases ….
-Le projet intègre une part d'apprentissage de concepts, standards, et technologies.
+   * [[https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.database.raw|Accès aux données émises par les capteurs]]
-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.
+       * <code> http://demo.sensapp.org/sensapp/databases/raw/sensors </code>  Returns the list of sensor databases
-https://github.com/SINTEF-9012/sensapp
+       * <code> http://demo.sensapp.org/sensapp/databases/raw/sensors/chicago/uic/shuttle/lambda</code> retourne une description de la base de données associée au capteur d'identifiant ''chicago/uic/shuttle/lambda'', en utilisant un JSON format.
-https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.database.raw
+       * <code> http://demo.sensapp.org/sensapp/databases/raw/data/chicago/uic/shuttle/lambda </code> Accès aux données d'un sensor donné
-https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.dispatch
-https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.notifier
-https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.registry
+   * [[https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.dispatch| point entrée pour les capteurs qui envoient du SenML]]
+   * [[https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.notifier|
+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)
 ===== Sous-Projets =====
-Attention ces sous-projets ne sont pas complètement indépendants. Des rapprochements entre les sous-groupes seront un plus.
+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.
 === Recherche de capteurs par caractéristiques ===
-SensApp supporte la possibilité d'ajouter des tags (paires clés-valeurs) aux capteurs. Le projet tutoré consistera en (i) l'identification des tags nécessaire à l'identification des capteurs, (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.
+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 :**
-   * Document faisant l'analyse du concept de capteurs et identification des caractéristiques retenues
+   -  Document faisant l'analyse du concept de capteurs et identification des caractéristiques retenues
-   * Interface de saisie et recherche de capteurs
+   -  Interface de saisie et recherche de capteurs
+   -  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.
-  Capteurs composites ?
-     * Capteur 24/7 : poussent en continu => tres gros volume de données RRD, pour cette donnée: 1 données toutes les secondes, .....
+=== Visualisation et enregistrement de capteurs dans un bâtiment et/ou un terrain ===
-           * Travail sur les templates ?
-     * Capteur one shot : toutes les données pendant une expérience, par exemple un capteur cardiaque pendant une course, dans ce cas on veut tout garder....
+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, ...
-          * Gérer les notions d'expériences
-  Travail sur les templates ?
-=== Visualisation et enregistrement de capteurs dans un bâtiment ===
-Il s'agit de permettre à un utilisateur d'enregistrer un nouveau capteur en fonction de son type (humidité, ...), 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.
-Vous prévoirez la possibilité de créer de nouveaux types de capteurs et de leur associer des icones.
+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 :**
-   * Analyse des outils existants pour manipuler des plans (formalisation, représentation) et localiser des éléments sur les plans
+   - Analyse des outils existants pour manipuler des plans (formalisation, représentation) et localiser des éléments sur les plans
-   * Interface de visualisation d'un bâtiment avec ses capteurs
+   - Interface de visualisation d'un bâtiment/lieu avec ses capteurs
-   * Interface d'ajout de capteurs dans un bâtiment
+   - Interface d'ajout de capteurs dans un bâtiment
 === Recherche de capteurs par caractéristiques et Thésaurus ===
-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.
+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 :**
-   * Analyse des outils existants de recherche en utilisant des thesaurus au moins
+   - Analyse des outils existants de recherche en utilisant des thesaurus au moins
-   * Détermination des thésaurus utiles à notre problème aussi bien pour la partie sensors qu'afficheur
+   - Détermination des thésaurus utiles à notre problème aussi bien pour la partie sensors qu'afficheur
-   * Interface d'aide à la recherche de sensors/Afficheur par saisie de mots successifs
+   - Interface d'aide à la recherche de sensors/Afficheur par saisie de mots
-   * Définir une interface de recherche qui puisse être alimentée par des thésaurus.
+   - 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.
 === Association capteurs et affichage ===
-A partir des informations connues sur un capteur, et une base de composants d'affichage (Jauges, Camembert, ....) vous proposerez automatiquement les afficheurs possible pour un capteru donné. En particulier, vous prendrez en compte les échelles de mesure pour éliminer des composants mal adaptés...
+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...
-**Artefacts attendus :**
+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.
-   * Analyse des sensors et en particulier des types d'informations produites : type, fréquence, erreur, plage de valeurs, ...
-   * Analyse des afficheurs existants et des besoins
-   * Interface d'aide à la recherche d'Afficheurs correspondant à un capteur sélectionné.
-Vous pourrez aussi traiter le flou dans la correspondance : par exemple pour la localisation vars console jauge n'ont pas de sens, peut etre graphique mais une carte de chaleur ou une sarte ou 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.
-Evolution avec plusieurs sensors sur un afficheur.
+**Artefacts attendus :**
+   - Analyse des sensors et en particulier des types d'informations produites : type, fréquence, erreur, plage de valeurs, ...
+   - Analyse des afficheurs existants et des besoins : vous pourrez proposer de visualiser certaines des données fournies par les sensors.
+   - 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.

Cours au département INFO - IUT - UNS

User Tools

Site Tools

Differences

Page Tools