This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
2012_2013:projetstut:sensors [2012/10/12 17:43] blay [Sous-Projets] |
2012_2013:projetstut:sensors [2012/10/15 09:51] (current) blay [Technologies utilisées] |
||
---|---|---|---|
Line 8: | Line 8: | ||
Ce sujet présente donc plusieurs sous-projets exposés [[2012_2013:projetstut:sensors#sous-projets|ci-après]] | Ce sujet présente donc plusieurs sous-projets exposés [[2012_2013:projetstut:sensors#sous-projets|ci-après]] | ||
- | <note warning>EN COURS DE DEFINITION</note> | ||
- | ===== Technologies utilisées ===== | ||
- | Le choix des technologies.... | ||
- | - html/JS | + | Le projet intègre une part d'apprentissage de concepts, standards, et technologies. |
- | - pour la BD? MongoDB connecté à une BD existante avec des liens par URL | + | 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. |
- | - Ils doivent savoir utiliser des services REST et en écrire un en java. | + | |
+ | <note warning>EN COURS DE DEFINITION</note> | ||
+ | ===== Technologies utilisées ===== | ||
- | JERSEY : librairie pour faire des web services REST | ||
- | Comme serveur web on peut utiliser JETTY | ||
- | Données sur les capteurs : | + | **Données sur les capteurs :** |
* [[http://demo.sensapp.org/sensapp/registry/sensors |Accès en ligne à la description des capteurs existants]] | * [[http://demo.sensapp.org/sensapp/registry/sensors |Accès en ligne à la description des capteurs existants]] | ||
- | * [[http://demo.sensapp.org/sensapp/registry/sensors/Car1/Engine_C02 |Description d'un capteur existant]] | + | * 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://demo.sensapp.org:80/sensapp/databases/raw/data/Car1/Engine_C02|Accès aux données issues d'un capteur]] | ||
- | 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) | * **[[http://tools.ietf.org/html/draft-jennings-senml-08|SenML]]** : standard de représentation des données des capteurs (actuellement la V8) | ||
- | * [[http://demo.sensapp.org/sensapp/registry/sensors/Bike1/crs|Référence aux données issues d'un capteur]] | ||
- | * [[http://demo.sensapp.org/sensapp/databases/raw/data/Bike1/crs|Visualisation de données issues d'un capteur]] | ||
- | **Accès aux services :** | ||
- | * 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) | ||
- | * database.raw : pour sauver les données | ||
- | * 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. | ||
- | 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. | ||
- | https://github.com/SINTEF-9012/sensapp | + | ** 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))]] | ||
+ | |||
+ | * **[[https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.registry|Recherche de capteurs]]** | ||
+ | * <code> http://demo.sensapp.org/sensapp/registry/sensors?flatten=true </code> pour obtenir la liste des capteurs détaillée | ||
+ | * <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'' | ||
+ | |||
+ | |||
+ | * [[https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.database.raw|Accès aux données émises par les capteurs]] | ||
+ | |||
+ | * <code> http://demo.sensapp.org/sensapp/databases/raw/sensors </code> Returns the list of sensor databases | ||
+ | |||
+ | * <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. | ||
+ | |||
+ | * <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| 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) | ||
- | https://github.com/SINTEF-9012/sensapp/tree/master/net.modelbased.sensapp.service.database.raw | ||
- | 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 | + | |
===== Sous-Projets ===== | ===== 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. | 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. | ||
+ | |||
Line 65: | Line 72: | ||
Ce projet inclut l'analyse de la notion de capteur et la caractérisation des informations pertinentes pour un capteur. | Ce projet inclut l'analyse de la notion de capteur et la caractérisation des informations pertinentes pour un capteur. | ||
- | **Artefacts attendus :** | ||
- | * Document faisant l'analyse du concept de capteurs et identification des caractéristiques retenues | ||
- | * Interface de saisie et recherche de capteurs | ||
- | | ||
| | ||
Vous prendrez également en compte les propriétés suivantes sur les capteurs | Vous prendrez également en compte les propriétés suivantes sur les capteurs | ||
- | * Capteur 24/7, ils poussent 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 ..... | + | * 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.... |
- | * Travail sur les templates ? | + | * 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 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.... | + | * 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. |
- | * Gérer les notions d'expériences | + | * La recherche du capteur pourra alors inclure la date à partir de laquelle il a commencé à émettre, sa fréquence, .... |
- | Travail sur les templates ? | + | |
Si vous avancez bien, vous vous intéresserez aux capteurs composites, qui correspondent à un assemblage de capteurs et exposent donc plusieurs informations simultanées. | 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 | ||
+ | - 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. | ||
+ | | ||
+ | |||
- | === Visualisation et enregistrement de capteurs dans un bâtiment === | + | === Visualisation et enregistrement de capteurs dans un bâtiment et/ou un terrain === |
- | 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, ... | + | |
+ | 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. | 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. | Attention dans un même lieu un grand nombre de capteurs peuvent être présents. | ||
**Artefacts attendus :** | **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 === | === 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 :** | **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 === | === 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. | ||
+ |