Architecture des RCSFs

Les réseaux de capteurs 

Les réseaux de capteurs sans fil (RCSF) sont composés d’un large nombre de nœuds capteurs déployés d’une façon dense dans un environnement cible.

Architecture des RCSFs 

L’architecture classique des RCSFs est illustrée dans la figure 1-1. Les nœuds capteurs sont dispersés dans le domaine dans lequel la capture est souhaitée. Les nœuds capteurs possèdent une portée de transmission faible et communiquent avec les nœuds adjacents pour acheminer les captures vers la passerelle. La passerelle est connectée à un médium longue distance et sert de lien entre les nœuds capteurs et les clients. Le nœud capteur est l’entité de base des RCSFs et sont déployés en grand nombre. Un nœud capteur comporte au moins ces quatre composants :

• Unité de détection : cette unité peut comporter plusieurs capteurs pour détecter différents types de phénomènes et d’un convertisseur qui convertiront les différents signaux analogiques en signaux numériques pour les envoyer à l’unité de traitement;
• Unité de traitement : cette unité gère en collaboration avec les autres unités de traitement la mission de mener à bien les tâches de détection. Cette unité contient en général un composant qui permet le stockage des données;
• Unité de transmission : ce composant est responsable de connecter le nœud capteur au réseau;
• Unité d’alimentation : ce composant assure les besoins énergétiques des différentes unités du nœud capteur.

D’autres unités facultatives peuvent aussi être présentes dans un nœud capteur par exemple un générateur de courant qui transforme une énergie non électrique en courant utilisable par l’unité d’alimentation.

Pour concevoir et déployer un RCSF, plusieurs facteurs doivent être pris en considération. Dans cette partie, nous essayerons de citer les plus importants :
• La fiabilité : c’est la capacité du réseau à réussir la tache de détection sans interruption malgré la défaillance de certains nœuds capteurs au sein du réseau. On désigne par défaillance toute mesure ou capture considérée fausse et non pas seulement l’arrêt du fonctionnement du nœud capteur;
• L’évolutivité : c’est la capacité du système à subvenir de manière dynamique aux besoins évolutifs en termes de ressources;
• Les coûts de production : puisque les RCSFs exigent par leur nature un large nombre de nœuds capteurs alors le prix unitaire de ces nœuds doit être justifiable. Un coût élevé aura systématiquement comme résultat l’abandon d’une solution RCSF;
• La consommation d’énergie : les nœuds de capteurs possèdent des ressources limitées en termes d’énergie. Certains scénarios d’applications peuvent trop utiliser les ressources du nœud capteur et se montrent très gourmant vis-à-vis la consommation d’énergie au point que la batterie ne puisse plus maintenir les besoins de l’application;
• L’environnement de déploiement : les RCSFs ont un large domaine d’applicabilité ce qui confère une grande variété d’environnement de déploiements. Le choix de nœuds capteurs adaptés à l’environnement de déploiement est donc primordial;
• Les médias de transmission : les différents médiums utilisés doivent être fiables dans le sens où la probabilité d’acheminer des informations fausses à partir de données correctes est faible, résistants aux différents types d’environnements (les médiums hertziens sont très sensibles aux détériorations climatiques) et efficaces dans la consommation d’énergie.

Les systèmes CA

Les systèmes CA (SAC) sont des systèmes qui possèdent la capacité de changer de comportement dépendamment de la situation qui entoure l’environnement d’exécution. Ces systèmes donnent naissance à un nouveau type d’applications : plus intelligentes, plus intuitives et tendent à comprendre les intentions de l’utilisateur et agissent en fonction de ces intentions. La situation ou le contexte n’est pas limité seulement à l’utilisateur final, son profil et ses préférences, mais aussi à d’autres éléments par exemple le lieu dans lequel il se trouve, un facteur de temps, l’état du matériel, etc.

Exemples d’application 

Dans cette partie, nous essayerons de donner deux scénarios qui illustrent les avantages des systèmes CA.

Dans le domaine de la santé, on peut considérer une application SAC qui permet de surveiller à distance l’état des patients. Les capteurs envoient régulièrement des informations sur l’état du patient par exemple la fréquence cardiaque, la vitesse de déplacement, la localisation. L’application se chargera en temps normal à l’aide d’un pilulier intelligent de rappeler la personne responsable du patient par SMS ou autre type de média (e-mail, alarme…) des médicaments qu’il doit prendre. En cas de comportement jugé anormal comme par exemple une crise cardiaque, l’application se chargera de contacter l’entité la plus proche de lui qui peut lui venir en aide. Une autre application intéressante est dans le domaine social. Un assistant de vie intelligent inspiré de l’application lancée par Nike nommée Nike+ training App. Les chaussures sportives de la nouvelle génération comportent des capteurs et fournissent différents types de données : saut vertical, la vitesse, le nombre de sauts effectués lors d’un entraînement, la durée en l’air durant les sauts, la fréquence cardiaque et le taux de glucose dans le sang. Toutes ces informations sont envoyées à un mobile intelligent dans lequel l’utilisateur peut visionner ses performances, les partager dans un réseau et rivaliser et se comparer à d’autres utilisateurs. L’application peut aussi fournir des indications et des conseils pour améliorer les performances et elle peut aussi proposer des programmes d’entraînements pour atteindre des objectifs fixés.

Fonctionnalités 

Les systèmes SAC sont des systèmes complexes et leur compréhension est essentielle pour le bon déroulement du projet. Dans ce qui suit, nous essayerons d’éclaircir les principales fonctionnalités des systèmes SaC.

Acquisition du contexte
L’acquisition du contexte est une fonctionnalité initiale et de base. Dans cette phase nous collectons de l’information contextuelle depuis les différentes sources de contexte. Nous définissons le contexte par « toute information qui peut être utilisée pour caractériser la situation d’une entité. Une entité peut être une personne, une place, ou un objet qui s’avère pertinent à l’interaction entre l’utilisateur et l’application» (Devajaru, Hoh et Hartle, 2007). L’information qui constitue le contexte peut provenir de deux types de sources :
• Sources physiques : ce sont les mesures qui proviennent des différents nœuds capteurs des RCSFs. Ils représentent des mesures associées à des phénomènes physiques par exemple la température, la pression, l’humidité…
• Sources logiques : ce sont des mesures qui représentent des états logiques d’entités contextuelles. Par exemple : la bande passante du réseau, la fiabilité des mesures des nœuds capteurs…

Il existe trois méthodes d’acquisition de contexte : soit par accès directs aux ressources physiques. Dans ce cas les capteurs et le module d’acquisition se trouvent sur le même appareil. Cette méthode est pratique, mais le contexte collecté est limité et n’est pas adapté aux systèmes distribués. Soit à travers un intergiciel ou bien à travers une base de données. L’acquisition du contexte est une grande fonctionnalité et peut être composée de plusieurs sous-fonctionnalités :
• La détection des données : c’est la capacité du module à recevoir les mesures des nœuds capteurs et aussi envoyer des commandes vers ces nœuds;
• Le balayage : cette fonctionnalité permet la découverte dynamique des ressources du réseau et permet aussi d’identifier l’ensemble de nœuds capteurs optimaux pour effectuer une tâche de détection;
• L’agrégation : consiste à fusionner un grand nombre de mesures pour en tirer des valeurs significatives par exemple une moyenne de valeurs ou une variance. Cette opération a pour effet d’alléger l’effort de traitement et de stockage. Et donc, optimise l’utilisation des ressources;
• L’adaptation : on désigne par l’adaptation l’obtention de l’information que lorsque l’on a vraiment besoin de celle-ci.

À cause de l’aspect propriétaire et la diversité des technologies des RCSFs, les développeurs de systèmes SaC développent leurs propres modules d’acquisition de contexte dépendamment de la technologie implémentée dans le RCSF. Dans ce sens, plusieurs travaux de recherches ont été réalisés proposant des solutions qui effectuent l’acquisition du contexte indépendamment de la technologie utilisée dans les RCSFs. On cite par exemple les travaux de Devajaru, Hoh et Hartle (2007) et de Gigan et Atkinson (2007). La solution proposée par Gigan et Atkinson est particulièrement intéressante, car elle introduit une couche d’abstraction qui cache les détails et les spécifications matérielles des nœuds capteurs.

La couche agent supérieure est responsable de communiquer avec les clients de la solution. Elle reçoit les paquets, les analyse puis fait appel aux méthodes appropriées de la couche inférieure et envoie les réponses de requêtes aux clients. La couche suivante est la couche de communication. Cette couche fournit des APIs et des fonctions génériques qui permettent le contrôle et la gestion des différents capteurs indépendamment de la technologie des RCSFs. Cette couche a aussi pour rôle d’identifier le réseau et les capteurs cibles des requêtes des clients. La couche inférieure est responsable de traduire la requête générique envoyée par la couche de communication en requêtes natives compréhensibles par le RCSF correspondant. Cette couche est étroitement liée à la partie matérielle du RCSF et son implémentation varie suivant le protocole de communication et l’encodage des données du RCSF.

Table des matières

INTRODUCTION
CHAPITRE 1 REVUE DE LA LITTÉRATURE
1.1 Les réseaux de capteurs
1.1.1 Architecture des RCSFs
1.2 Les systèmes CA
1.2.1 Exemples d’application
1.2.2 Fonctionnalités
1.2.2.1 Acquisition du contexte
1.2.2.2 Modélisation du contexte
1.2.2.3 Autres fonctionnalités
1.3 Le Cloud computing
1.3.1 Les caractéristiques du Cloud
1.3.2 Les services du Cloud
1.3.3 Les modèles de déploiement du Cloud
1.4 Les plateformes de gestion de contexte
1.5 Conclusion
CHAPITRE 2 ARCHITECTURE PROPOSÉE
2.1 Scénarios motivants
2.2 Présentation des substrates reliées aux systèmes CA
2.3 La vue globale
2.4 Architecture logicielle
2.4.1 La couche de plateforme
2.4.2 La couche d’infrastructure
2.4.3 Le dépôt de données (Broker)
2.5 Diagrammes de séquences
2.5.1 La séquence de découverte
2.5.2 Séquence d’instanciation
2.5.3 Séquence d’exécution
2.6 Conclusion
CHAPITRE 3 IMPLÉMENTATION DE LA PLATEFORME DE GESTION DE CONTEXTE
3.1 Diagramme de classe
3.1.1 Le fournisseur de plateforme
3.1.2 Le fournisseur d’infrastructure
3.2 Les substrates
3.2.1 Acquisition
3.2.2 Modélisation
3.2.3 Dissemination
3.2.4 Stockage
3.2.5 Inférence
CHAPITRE 4 ANALYSE DES PERFORMANCES DE LA PLATEFORME DE GESTION DE CONTEXTE
4.1 Technologies et outils de développement
4.2 Environnement de test
4.3 Tests de la plateforme
4.3.1 Validité et fiabilité des outils de mesure
4.3.2 Temps de réponse
4.3.3 Tests de changement de données
4.3.4 Tests de stress
4.4 Dimensionnement de la plateforme de gestion de contexte
4.4.1 Régression linéaire
4.4.2 Méthodologie de dimensionnement
4.5 Conclusion
CONCLUSION

Télécharger le rapport complet