Architecture Logicielle pour des Applications Hétérogènes...
Transcript of Architecture Logicielle pour des Applications Hétérogènes...
Architecture Logicielle pour des Applications Hétérogènes,
Distribuées et ReconfigurablesEquipe-projet ALCooL
Christine Louberry, Emmanuel Bouix, Marc Dalmau, Sophie Laplace,
Philippe Roose
19/02/2008 ADAPT 2008 2
Exemple d’application
• Surveillance :– Capteurs : infrarouge, température, etc.– Caméras– Composants logiciels de traitement : analyse d’images, etc.
Logiciel de détection de mouvement
Détecte et localise la présence d’intrus
• Approche zone dangereuse : Caméra + logiciel capture vidéo� affiche la vidéo et suit l’intrus
• Anticipation du mouvement pour activer les caméras d’une zone
19/02/2008 ADAPT 2008 3
Introduction
• Emergence des capteurs sans-fil ces dernières années
• Nombreux défis dans les domaines des réseaux et des architectures logicielles
• Optimisation des ressources :– Matérielles : énergie (batterie), capacité de
calcul, etc.– Réseaux : congestion, agrégation de données,
etc.
19/02/2008 ADAPT 2008 4
Introduction
• Utilisation des capteurs principalement pour leurs fonctions propres de mesures de l’environnement
• Peu de travaux sur l’intégration des capteurs dans des environnements hétérogènes
� Collaboration directe entre capteurs et composants logiciels
19/02/2008 ADAPT 2008 5
Problématique
• Capteurs : dispositifs effectuant des mesures de l’environnement et transmettant de l’information, dotés d’une capacité de calcul et de mémoire
� Peuvent héberger des composants logiciels en relation ou non avec leur fonction
19/02/2008 ADAPT 2008 6
Nouvelles possibilités
�Proposition de nouvelles configurations�Accroissement de l’offre de QdS
Transmission coûteuse en énergie
Cas des Kamikaze
Logiciel de compression
Pré-traitement : Réduction des données àtransmettre
Mesure 1
Mesure 2
Variation Interprétation des données
19/02/2008 ADAPT 2008 7
Proposition
• Utiliser les capteurs comme support de composants logiciels�Possibilité de minimiser les informations transmises
(traitement local)�Possibilité de gestion de ressources (délocaliser un
composant sur un périphérique moins limité)�Possibilité de prise en compte de la mobilité (fonction
relais avec traitement sur le chemin)
Tout cela est vu comme de la gestion de QdS
�gestion par reconfiguration dynamique : PF de supervision (travaux antérieurs)
19/02/2008 ADAPT 2008 8
Objectif
• Proposer une architecture logicielle pour la reconfiguration dynamique d’applications constituées de composants hétérogènes (capteurs et composants logiciels)
• Comment :Paradigme service : outils et caractéristiques adaptés à de telles applications
19/02/2008 ADAPT 2008 9
Paradigme service
Objectifs :�Favoriser la réutilisation et la maintenance
d’applications évolutives�Offrir des mécanismes de description, publication et
découverte des servicesDéfinition :�Un service est une entité autonome indépendante
de la plateforme d’exécutionIntérêt :�Dialogue (connexion) entre les services sans
connaissance a priori
19/02/2008 ADAPT 2008 10
Composants
• Application basée sur le modèle de composant unifié Osagaia
�Modèle permettant de faire abstraction de la nature logicielle ou matérielle des composants
• Trois entités– Composant Métier (CM)– Processeur Élémentaire (PE)– Conduit
19/02/2008 ADAPT 2008 11
Composant Métier
• Implémente un traitement particulier de données (implémentation fonctionnelle)
• Encapsulé dans un Conteneur (PE)• Capteur :
– fonctionnalités particulières de mesure de l’environnement : température, luminosité, déplacement, etc
– fonctionnalités hébergées selon besoins
19/02/2008 ADAPT 2008 12
Conteneur pour le Composant Métier (partie non-fonctionnelle)
Processeur Élémentaire
19/02/2008 ADAPT 2008 13
Processeur Élémentaire
Fonctions :�Échanges de données avec les autres
composants grâce aux unités d’échange– Unité d’Entrée (UE)
19/02/2008 ADAPT 2008 14
Processeur Élémentaire
Fonctions :�Échanges de données avec les autres
composants grâce aux unités d’échange– Unité d’Entrée (UE)– Unité de Sortie (US)
19/02/2008 ADAPT 2008 15
Processeur Élémentaire
�Contrôle du fonctionnement du CM (cycle de vie, états, etc.) grâce à l’Unité de Contrôle (UC) (lien avec la plateforme)
19/02/2008 ADAPT 2008 16
Conduit
Fonctions :�Transport de l’information
– Gestion du transport par réseau– Proposition de politiques de communication
• Ex : synchronisation inter-flux
�Connexion/Déconnexion entre les PE– ports d’entrée/sortie
• Port de sortie d’un conduit se connecte à des ports d’entrée de Conteneurs et inversement
19/02/2008 ADAPT 2008 17
Conduit
Composition :– Unités d’échange (UE et US)
– UC pour superviser le transport (lien avec la PF)
19/02/2008 ADAPT 2008 18
Plateforme
Composition :– Supervision– Usine à Conteneur– Usine à Conduit– Routage
Distribution de la PF sur les différents hôtes de l’application
19/02/2008 ADAPT 2008 19
Service Supervision
Service principal : • Évaluation QdS de l’application• Reconfiguration : Transmission requêtes :
�Déploiement des CM (Usine à Conteneur)
�Politique de communication (déploiement, connexion /déconnexion) des Conduits (Usine àConduit)
19/02/2008 ADAPT 2008 20
Service Usine à Conteneur
• Création de PE adaptés :– Au CM– À l’hôte
• Actions :�Réception requête service Supervision�Téléchargement du CM�Encapsulation�Déploiement selon l’hôte�Lancement
19/02/2008 ADAPT 2008 21
Service Usine à Conduit
• Création des Conduits�Implémentation de la politique de communication
choisie
• Actions :�Réception requêtes service Supervision�Déploiement selon l’hôte�Connexion/Déconnexion PE (service
Routage)�Suppression
19/02/2008 ADAPT 2008 22
Service Routage
• Création et mise à jour d’une table des routes disponibles pour atteindre les composants de l’application
• Détection des changements de topologie – Disparition de capteurs :
• Panne• Déplacement hors zone de couverture
� Information au service Supervision
19/02/2008 ADAPT 2008 23
Scénarii de déploiement
• Déploiement différent selon l’hôte– Hôte fixe : contraintes négligeables. Ex : PC
alimenté.– Hôte léger : contraintes de ressources :
• CDC : téléphone portable, PDA, etc.• CLDC : capteurs, etc.
• Cas des hôtes légers : certains services et certaines parties de composants seront déportés sur un hôte plus performant.
19/02/2008 ADAPT 2008 24
Scénario Hôte fixeHôte fixe
ConduitPE + CM
Supervision
Plateforme
Usine àConteneur
Routage
Usine àConduit
état
état
dem
ande
état
requête requête
crée/
dét
ruit
crée/détruit
Dépôt de
CM
Déploiement total de la plateforme et des composants (PE + CM, Conduit)
19/02/2008 ADAPT 2008 25
Scénario Hôte légerHôte fixe
Supervision
Plateforme
Usine àConteneur
RoutageUsine àConduit
Dépôt de CM
US
UE
CapteurA (CLDC)
UC de
PE1éta
tConduit 2
Conduit 3
Conduit 1
UC de
Conduit3
CMétat
PE1
Sup
état
• Déploiement partiel de la plateforme
• Déploiement partiel des PE et Conduits
19/02/2008 ADAPT 2008 26
Travaux Apparentés
Russo and al.
• Combinaison de deux architectures (matérielle et logicielle) pour l’échange d’information entre capteurs et applications
+ Ajout/suppression de services pour gérer la mobilitéphysique et fonctionnelle des capteurs� Utilisation d’un framework OSGi sur serveur
- Centralisation des informations de mesures sur un serveur
19/02/2008 ADAPT 2008 27
Travaux Apparentés
Grace and al.• Intergiciel évolutif selon l’environnement• Deux niveaux de reconfiguration : capteur
(structure) et réseau (calibrage)+ Architecture distribuée- Pas d’ajout, suppression ou modification des
fonctionnalités d’un capteur spécifique (tout ou rien)
19/02/2008 ADAPT 2008 28
Travaux Apparentés
Kogekar and al.• Architecture réactive au contexte (environnemental et
applicatif)�Modification des fonctionnalités des nœuds
• Entrepôt de configurations possibles a priori• Collaboration de composants dédiés
�Mesure de la QdS�Reconfiguration
+ Distribution sur tous les noeuds+ Semblable à la collaboration de services de notre PF- Evaluation QdS du fonctionnement des nœuds
+ PF : évaluation QdS échanges d’information (UC Conduit)- Composition des applications : capteurs uniquement- Dynamicité réduite par les configurations a priori
19/02/2008 ADAPT 2008 29
Conclusion
• Intégration des périphériques contraints dans les applications
• Gestion et reconfiguration des applications hétérogènes• Capteur : nouveau support pour les fonctionnalités � traiter
les informations et minimiser les transferts• PF : Collaboration de services� Évaluation QdS et changement de contexte
– Assurer le service– Améliorer la QdS– Anticiper des dégradations
� Ajout/suppression de composants/connexions� Déploiement selon contraintes (CDC/CLDC) et contexte
fonctionnel
19/02/2008 ADAPT 2008 30
Perspectives
• Développement et déploiement de la PF sur capteurs, téléphones mobiles et PDA.– Prototypage avec différents périphériques : capteurs,
PDA, téléphones mobiles (différents modes de communication)
– Valider la PF– Tester les scénarii de déploiements– Mesures de performance
• Étude de nouvelles politiques de communication : temps-réel, tolérance aux pertes, etc.
19/02/2008 ADAPT 2008 31
Références• Dalmau, M., Roose, P. , Bouix, E. , Luthon, F. A Multimedia Oriented Component Model,
The IEEE 19th International Conference on Advanced Information Networkgin et Applications, AINA 2005, 2005.
• Elfatatry, A. Dealing with change: components versus services, Communications of the ACM, August 2007, Volume 50, No. 8.
• Grace, P., Coulson, G., Blair, G., Porter, B., and Hughues, D. Dynamic recongifuration in sensor middleware, MidSens’06, (Melbourne, Australia, November 27-December 1), 2006.
• Kogekar, S., Neema, S., and Koutsoukos, X. Dynamic software reconfiguration in sensor networks, Systems Communications 2005 (ICW / ICHSN / ICMCS / SENET 2005), IEEE Computer Society, (14-17 August 2005, Montreal, Canada), 2005.
• Laplace, S. , Dalmau, M. , Roose, P. Kalinahia: Considering quality of service to design and execute distributed multimedia applications, IEEE/IFIP Int'l Conference on Network Management and Management Symposium, NOMS 2008, (Salvador de Bahia, Brésil, Avril, 2008), 2008.
• Louberry, C., Roose, P., and Dalmau, M. Heterogeneous component interactions: Sensors integration into multimedia applications, Journal of Networks, Academy Publisher, 2007, Volume 3, No. 2.
• Russo, J., Helal, A., King, J., and Bose, R. Self-describing sensor networks using a surrogate architecture, Internal Report, Mobile&Pervasive computing research, University of Florida, June, 2005.
19/02/2008 ADAPT 2008 32
Questions