KALIMUCHO : Adaptation au Contexte pour la Gestion de la Qualité de Service

HAL Id: tel-00537846

https://tel.archives-ouvertes.fr/tel-00537846

Submitted on 20 Nov 2010

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Christine Louberry

To cite this version:

Christine Louberry. KALIMUCHO : Adaptation au Contexte pour la Gestion de la Qualité de Ser-

vice. Génie logiciel [cs.SE]. Université de Pau et des Pays de l’Adour, 2010. Français. �NNT :

2010PAUU3006�. �tel-00537846�

TH` ESE

PR´ ESENT´ EE ` A

L’Universit´ e de Pau et des Pays de l’Adour

ECOLE DOCTORALE DES SCIENCES EXACTES ET DE ´ LEURS APPLICATIONS

Par Christine Louberry POUR OBTENIR LE GRADE DE

DOCTEUR

SP´ ECIALIT´ E : INFORMATIQUE

KALIMUCHO : Adaptation au Contexte pour la Gestion de la Qualit´ e de Service

Soutenue le : 10 Septembre 2010 Apr` es avis des rapporteurs :

Claudia Roncancio Professeur, LIG, Grenoble Jean-Marc Pierson Professeur, IRIT, Toulouse Devant la commission d’examen compos´ ee de :

Isabelle Deumeure Professeur, ParisTech, Paris Pr´ esident Congduc Pham Professeur, LIUPPA, Pau Directeur Marc Dalmau Maˆıtre de conf´ erences HDR, LIUPPA, Anglet Encadrant Philippe Roose Maˆıtre de conf´ erences HDR, LIUPPA, Anglet Encadrant David Bromberg Maˆıtre de conf´ erences, Labri, Bordeaux Examinateur

2010

Les r´ ecentes avanc´ ees technologiques de ces derni` eres ann´ ees ont mis l’accent sur la d´ emocratisation des r´ eseaux sans-fil et sur la miniaturisation des appareils de communica- tion. Actuellement nous pouvons trouver sur le march´ e une multitude d’appareils de plus en plus l´ egers, compacts, mobiles et dot´ es de divers moyens de communication sans-fil tels que les t´ el´ ephones portables, les smart-phones, les PDA, les ordinateurs portables ou encore les capteurs.

De plus nous devons faire face aujourd’hui ` a une demande grandissante pour des ser- vices de plus en plus riches et personnalis´ es. Le d´ efi est de pouvoir proposer des applications qui s’adaptent tant aux souhaits des utilisateurs qu’` a l’environnement physique. Ce type d’appareils mobiles a la capacit´ e de pouvoir rendre compte de son environnement mat´ eriel et logiciel mais ´ egalement, avec l’arriv´ ee de p´ eriph´ eriques tels que les capteurs, ils disposent de dispositifs pouvant mesurer des grandeurs physiques comme la temp´ erature, la pres- sion, la vitesse de d´ eplacement ou encore l’humidit´ e. L’int´ egration de tels appareils dans les applications peut permettre de proposer aux utilisateurs des services mieux adapt´ es ` a leur situation courante. Cependant, ces appareils poss` edent des caract´ eristiques (autono- mie ´ energ´ etique, mobilit´ e, ressources limit´ ees) qui n´ ecessitent l’adaptation des applications afin que les services rendus par celles-ci fonctionnent bien et pendant une dur´ ee suffisante.

Dans cette th` ese, nous avons choisi d’aborder l’adaptation dynamique au contexte comme un outil de gestion de la qualit´ e de service. nous pr´ esentons une plate-forme pour la reconfiguration et le d´ eploiement contextuel d’applications en environnement contraint appel´ ee Kalimucho, (Kalitate Mucho <sup>1</sup> ). Kalimucho est une plate-forme distribu´ ee qui dis- pose d’une repr´ esentation globale de l’application. Elle permet des reconfigurations des applications bas´ ees composants grˆ ace ` a cinq actions de base : ajouter, supprimer, migrer, connecter et d´ econnecter. L’originalit´ e de cette plate-forme est qu’elle exploite le plus possible les ressources de l’application en permettant d’utiliser tous les p´ eriph´ eriques dis- ponibles comme supports des composants logiciels de l’application, qu’ils soient ou non en relation avec les fonctionnalit´ es du p´ eriph´ erique.

Pour cela, elle se base sur une classification du contexte et une d´ efinition de la qualit´ e de service permettant de prendre en compte les diff´ erentes propri´ et´ es des applications pervasives : les p´ eriph´ eriques, la mobilit´ e, l’environnement ainsi que les sp´ ecifications de l’application elle-mˆ eme. La d´ efinition de la qualit´ e de service propos´ ee permet de r´ eunir deux notions fortement correl´ ees dans le cadre des applications pervasives : l’utilit´ e de l’application et la disponibilit´ e des ressources. Chacune de ces d´ efinitions est associ´ ee ` a un

1. Qualit´ e en langue basque et Beaucoup en langue espagnole

i

est inform´ ee des changements de contexte grˆ ace ` a des composants sp´ ecifiques d’´ ecoute du contexte et g´ en` ere les actions ad´ equates. Le choix de l’action ` a mener est aid´ e par une m´ ethode de conception qui guide le concepteur dans la mod´ elisation du contexte.

Elle permet d’identifier tous les ´ ev` enements pouvant engendrer des reconfigurations et de les associer ` a une action. Enfin, elle permet de d´ ecomposer l’application en diff´ erentes configurations qui servent de base au choix de reconfiguration. Puis, lorsque la d´ ecision de reconfiguration est prise, le mod` ele de qualit´ e de service permet d’´ evaluer la qualit´ e de service de l’application ` a deux niveaux : l’ad´ equation du service rendu par rapport au service souhait´ e et la dur´ ee de vie de l’application. La particularit´ e de ce mod` ele de qualit´ e de service est qu’il permet de prendre en compte ` a la fois la disponibilit´ e des ressources mat´ erielles et celle des ressources r´ eseau. Il est associ´ e ` a une heuristique de choix de la configuration ` a d´ eployer qui permet de trouver une configuration, et le d´ eploiement associ´ e, qui respectent les crit` eres de qualit´ e de service. Cette heuristique se base sur deux concepts : le poids d’un composant et le poids d’un p´ eriph´ erique, ainsi que sur un classement des p´ eriph´ eriques, afin d’´ etablir un ordre d’´ evaluation permettant de trouver une solution rapidement.

Nous avons valid´ e cette heuristique par un prototype au travers de tests r´ ealis´ es dans

des contextes de variation des ressources des p´ eriph´ eriques, de mobilit´ e des p´ eriph´ eriques

et de fortes contraintes de d´ ebit r´ eseau.

The recent technological overhangs have focused on the democratization of wireless networks and the miniaturization of communication devices. Nowadays we can find a lot of devices increasingly lightweight, tiny, mobile and to be equipped of one or several wireless communication medium such as mobile phones, smart-phones, PDA, laptops and sensors.

Moreover, we face with the growing request of rich and customized services. The chal- lenge is to offer applications which suit both the users’needs and the physical environment.

This type of mobile devices is able to be aware of its hardware and software environ- ment but also, with the arrival of device such as sensors, they can measure temperature, moisture, move speed or pressure. Integration of such devices in applications can provide services better adapted to their current situation. However, theses devices have features (energy independence, mobility, limited resources) which require adaptations in order to provide services that well function and during a satisfaying time.

In this thesis, we chose to address the dynamic context adaptation as a tool for quality of service management. We present a platform for reconfiguration and contextual deploy- ment of applications in constrained environments called Kalimucho (Kalitate Mucho ² ).

Kalimucho is a distributed platform that has a global representation of the application.

It adapts component-based applications through five basic actions : add, delete, move, connect and disconnect. The original idea of this platform is that it exploits the resources of the application as better as possible to use all available devices to support components.

For this, it is based on a context categorization and a quality of service definition which take into account the different properties of pervasive applications : devices, mobility, en- vironment and specifications of the application. The definition of quality of service we provide matches two concepts of pervasive applications : the utility of an application and availability of resources. Each of these definitions is associated with a model : a context model and a QoS model. The context model is a simple model based on a knowledge of components and devices but also, the data-gathering during the execution. The platform is informed of context changes about specific context components and generates the ap- propriate actions. The choice of the action is guided by a design method that assists the designer in modeling the context. It identifies all the events implying reconfiguration and their associated actions. Then, it models all the configurations of an application which aided the decision process. When the decision is taken, the QoS model evaluates quality of service of the application on two levels : the adequacy between the service offered and the

2. Quality in Basque and Much in Spanish

iii

criteria. This heuristic is based on two concepts : the weight of a component and the weight of a device, and a classification of devices, to establish an evaluation order to quickly find a solution.

We implemented a prototype to prove this heuristic. We study the choose process

through tests in several contexts : resources changes, mobility and network constraints.

Je tiens tout ` a d’abord ` a remercier Marc Dalmau et Philippe Roose, mes encadrants, qui ont ´ et´ e de v´ eritables guides durant ces quatre ann´ ees de th` ese. Je les remercie pour m’avoir donn´ e la chance d’effectuer cette th` ese au sein de Laboratoire d’Informatique de l’UPPA, pour leurs pr´ ecieux conseils tant au niveau de la recheche que de l’enseignement.

Je leur adresse toute ma reconnaissance pour toute la confiance qu’ils m’ont accord´ e, leur investissement et leurs encouragements qui m’ont permis de mener ` a bien ce projet.

Je tiens ´ egalement ` a remercier Congduc Pham pour avoir accept´ e de diriger cette th` ese et pour ses conseils et son suivi durant toutes ces ann´ ees.

Je remercie particuli` erement Claudia Roncancio et Jean-Marc Pierson pour m’avoir fait l’honneur d’accepter d’ˆ etre les rapporteurs de ce travail. Je n’oublie pas Isabelle Demeure qui a accept´ e de pr´ esider la commission d’examen et ainsi manifest´ e son int´ erˆ et pour ces travaux.

Un grand merci ` a Sophie Laplace pour son aide et son soutien pendant les bons comme les moins bons moments que j’ai travers´ e durant cette th` ese. J’ai beaucoup appr´ eci´ e de partager nos id´ ees sur ce projet et j’esp` ere que nous continuerons ` a travailler ensemble ces prochaines ann´ ees.

J’adresse ma gratitude ` a tous mes coll` egues de l’IUT de Bayonne pour avoir fait de l’IUT un lieu de convivialit´ e et de partage : Patrick, Pierre, Yon, Christophe, Gilles, Jean- Marc, L´ eo, Kevin, Lopis, Thierry pour avoir goˆ uter avec le sourire ` a mes gˆ ateaux et autres patisseries pas toujours r´ eussies, Ginette, Ghislaine, Val´ erie, Pantxika pour leur bonne humeur, Simone, Peio, Corine, Agnes, Jean-Michel, Bruno, Laurent, Estelle, Benoit et les autres. Une pens´ ee pour ceux qui sont pass´ es ` a l’IUT : J´ erome et Denis pour leurs conseils de r´ edaction et Cyril pour sa contribution technique sur le projet sans oublier nos parties de Yam’s du midi.

Merci ` a tous mes camarades doctorants Eric, Natacha, Damien et particuli` erement Julien et Cyril pour avoir partag´ e les mˆ emes difficult´ es, les mˆ emes motivations et pour leur soutien.

Merci ` a Christophe et Benjamin que j’ai eu l’occasion de rencontrer lors de d´ eplacements en conf´ erence.

Merci ` a mes amis, Seb, S´ everine, Julien, Guillaume, Laurie, Yves, Aurel, Christophe pour leur joie de vivre ` a toutes ´ epreuves, pour les soir´ ees bayonnaises improvis´ ees et les week-end toulousains, S´ ebastien, Mathieu, Guillaume pour les vir´ ees shopping, rock et roller, tous ceux que je n’ai pas cit´ e.

v

Merci ` a vous tous.

1 Introduction 1

1.1 Probl´ ematique . . . . 2

1.2 Exemple d’application . . . . 4

1.3 Objectif . . . . 7

1.4 Conclusion . . . . 9

2 Adaptation dynamique et Qualit´ e de Service 11 2.1 Introduction . . . . 12

2.2 Contexte . . . . 12

2.2.1 Contexte d’utilisateur . . . . 13

2.2.2 Contexte d’utilisation . . . . 14

2.2.3 Contexte d’ex´ ecution . . . . 14

2.3 Gestion de la qualit´ e de service . . . . 15

2.4 Qualit´ e de service . . . . 17

2.4.1 D´ efinition de la Qualit´ e de Service . . . . 17

2.4.2 Qualit´ e de Service et Contexte . . . . 18

2.5 Synth` ese . . . . 21

2.6 Syst` emes sensibles au contexte . . . . 23

2.6.1 Intergiciel pour l’adaptation contextuelle d’applications . . . . 23

2.6.1.1 Aura . . . . 24

2.6.1.2 WComp . . . . 25

2.6.1.3 MUSIC . . . . 27

2.6.2 D´ eploiement contextuel d’applications . . . . 29

2.6.2.1 CADeComp . . . . 29

2.6.2.2 AxSel . . . . 30

2.6.3 Architectures logicielles pour la qualit´ e de service . . . . 31

2.6.3.1 Qinna . . . . 31

2.6.3.2 QuA . . . . 33

vii

2.7 La gestion du contexte dans les applications pervasives . . . . 39

2.7.1 Context Toolkit . . . . 39

2.7.2 SECAS . . . . 40

2.7.3 Le Contexteur . . . . 43

2.7.4 COSMOS . . . . 44

2.7.5 Synth` ese . . . . 45

2.8 Conclusion . . . . 47

3 M´ ethode de conception 49 3.1 Introduction . . . . 49

3.2 Mod` ele de contexte . . . . 50

3.2.1 Les informations mesurables . . . . 50

3.2.1.1 Capture par l’application . . . . 50

3.2.1.2 Capture par la plate-forme . . . . 52

3.2.2 Les informations abstraites . . . . 52

3.2.2.1 Capture par l’application . . . . 53

3.2.2.2 Capture par la plate-forme . . . . 53

3.3 Mod` ele de Qualit´ e de Service . . . . 59

3.3.1 Caract´ eristiques de Qualit´ e de Service . . . . 60

3.3.1.1 QdS Utilit´ e . . . . 61

3.3.1.2 QdS P´ erennit´ e . . . . 64

3.3.2 Repr´ esentation et ´ evaluation de la QdS . . . . 67

3.4 Mod` ele des applications . . . . 69

3.4.1 Service . . . . 70

3.4.2 Composant . . . . 71

3.4.3 Structure des applications . . . . 72

3.5 M´ ethode de conception . . . . 73

3.5.1 Etape 1 : Identification des services de l’application . . . . 73

3.5.2 Etape 2 : Cas d’utilisation . . . . 74

3.5.3 Etape 3 : D´ ecomposition des services . . . . 77

3.5.4 Etape 4 : Classement des configurations . . . . 79

3.5.5 Etape 5 : Identification des ´ ev` enements de l’application . . . . 79

3.5.6 Etape 6 : Cartes d’identit´ e des composants et des p´ eriph´ eriques . . . 81

3.6 Conclusion . . . . 83

4.1 Introduction . . . . 86

4.1.1 Adaptation aux besoins . . . . 88

4.1.2 Adaptation au mat´ eriel . . . . 89

4.2 Objectifs . . . . 90

4.2.1 Gestion de la QdS P´ erennit´ e . . . . 90

4.2.2 Gestion de la QdS Utilit´ e . . . . 91

4.2.3 Principes de fonctionnement . . . . 92

4.3 Les moyens d’action . . . . 93

4.3.1 Migration de service . . . . 95

4.3.2 Ajustement de composant . . . . 95

4.3.3 D´ eploiement de service . . . . 95

4.3.4 Synth` ese . . . . 99

4.4 Interactions plate-forme / application . . . 100

4.4.1 OSAGAIA : conteneur de composants m´ etier . . . 100

4.4.2 KORRONTEA : conteneur de connecteur . . . 100

4.5 Architecture de la plate-forme Kalimucho . . . 102

4.5.1 Superviseur . . . 103

4.5.1.1 Gestionnaire de Contexte . . . 105

4.5.1.2 Gestionnaire d’Ev` enement . . . 107

4.5.1.3 D´ eployeur et Contrˆ ole UC . . . 110

4.5.2 G´ en´ erateur de reconfiguration . . . 112

4.5.2.1 EvaluerConfiguration . . . 112

4.5.2.2 CalculerConfiguration . . . 114

4.5.3 Usine ` a Conteneur . . . 115

4.5.4 Usine ` a Connecteur . . . 115

4.5.5 Routage . . . 115

4.5.6 Registre de Composants et Registre de Configurations . . . 116

4.6 Principe de d´ eploiement de Kalimucho . . . 116

4.7 Mod` ele d’ex´ ecution de Kalimucho . . . 119

4.7.1 Heuristique de choix d’une configuration a deployer . . . 119

4.7.1.1 S´ election d’une configuration . . . 121

4.7.1.2 Evaluation d’un deploiement . . . 122

4.8 Conclusion . . . 136

5.1.1 Ajouter, modifier et consulter un composant . . . 140

5.1.2 Ajouter, modifier et consulter un p´ eriph´ erique . . . 143

5.1.3 Ajouter, modifier et consulter une configuration . . . 144

5.1.4 Modifier une topologie r´ eseau . . . 145

5.1.5 Lancer une simulation et afficher le r´ esultat . . . 145

5.2 Exp´ erimentation . . . 147

5.2.1 Test 1 : Conditions normales d’ex´ ecution . . . 149

5.2.2 Test 2 : Ev` enement de ressource sur H 2 . . . 151

5.2.3 Test 3 : Ev` enement de ressource sur H 1 . . . 153

5.2.4 Test 4 : Ev` enement de mobilit´ e sur H 3 . . . 156

5.2.5 Test 5 : Cas d’un environnement tr` es contraint . . . 156

5.3 Conclusion . . . 161

5.4 Prototype n

2 : impl´ ementation de Kalimucho . . . 161

5.5 Exp´ erimentations . . . 166

5.5.1 Test d’ex´ ecution d’une commande de reconfiguration sur un capteur 166 5.5.2 Test de transfert de donn´ ees entre capteurs . . . 167

5.6 Conclusion . . . 169

6 Conclusion 171

Publications 177

Bibliographie. 185

1.1 Scenario d’utilisation de l’application de visite d’un mus´ ee . . . . 5

2.1 Architecture en couche des applications sensibles au contexte . . . . 13

2.2 plate-forme de supervision . . . . 17

2.3 Niveaux de qualit´ e de service . . . . 19

2.4 Interactions entre contexte et QdS . . . . 22

2.5 Architecture g´ en´ erale d’Aura . . . . 24

2.6 Structure du gestionnaire d’adaptation de MUSIC . . . . 28

2.7 Architecture de Qinna . . . . 32

2.8 Exemple d’une table de mapping pour l’utilisation du composant Video . . 32

2.9 Principe de choix d’une configuration par Kalinahia . . . . 35

2.10 Architecture du Context Toolkit . . . . 40

2.11 Architecture g´ en´ erale de SECAS . . . . 41

2.12 Architecture d’un Contexteur . . . . 43

2.13 Exemple d’une composition de nœuds de cocntexte par COSMOS . . . . 44

3.1 Mod` ele des informations contextuelles . . . . 55

3.2 Composition du contexte et interactions . . . . 57

3.3 Sch´ ema d’interactions entre les contextes et les QdS . . . . 61

3.4 Variation du classement des configurations selon leur note de QdS Utilit´ e . 63 3.5 Repr´ esentation de l’ensemble des configurations de QdS suffisante . . . . 68

3.6 Repr´ esentation de la QdS d’une configuration ` a un instant t0 . . . . 69

3.7 Illustration de la d´ efinition d’un service selon la d´ efinition 3.1 . . . . 70

3.8 Illustration de la d´ efinition d’un service selon la d´ efinition 3.2 . . . . 71

3.9 Diagramme de classe d’une application . . . . 73

3.10 Identification des services fournis par l’application de visite d’un mus´ ee . . 74

3.11 Repr´ esentation du cas d’utilisation de la conf´ erence . . . . 75

3.12 R´ eaction suite ` a l’´ ev` enement Conference . . . . 76

3.13 Repr´ esentation du cas d’utilisation de l’incendie . . . . 76

xi

3.16 Carte d’identit´ e d’un p´ eriph´ erique . . . . 83

4.1 Interactions dans les applications auto-adaptables . . . . 87

4.2 Interactions dans les applications supervis´ ees . . . . 88

4.3 Sch´ ema de la plate-forme Kalimucho . . . . 93

4.4 Exemple d’une migration d’un service S . . . . 94

4.5 Exemple d’un d´ eploiement d’une nouvelle configuration d’un service S . . . 94

4.6 Migration du service S sur les p´ eriph´ eriques support de S . . . . 96

4.7 Migration du service S en utilisant des p´ eriph´ eriques voisins . . . . 96

4.8 D´ eploiement suite ` a la r´ eception d’une information de contexte d’utilisation 98 4.9 Structure d’un conteneur de composant . . . 101

4.10 Structure d’un conteneur de connecteur . . . 102

4.11 sch´ ema g´ en´ eral de la plate-forme Kalimucho . . . 103

4.12 Sch´ ema g´ en´ eral du service Superviseur . . . 104

4.13 ´ Ev` enements de contexte capt´ e par le service Gestionnaire de Contexte . . . 106

4.14 Le service Gestionnaire de Contexte effectue un pr´ e-traitement des ´ ev` enements de contexte . . . 107

4.15 Sch´ ema des interactions du service Gestionnaire d’Ev` enement . . . 108

4.16 Sch´ ema des interactions des services D´ eployeur et Contrˆ ole UC . . . 111

4.17 Sch´ ema des interactions du service G´ en´ erateur de Reconfiguration . . . 112

4.18 sch´ ema de d´ eploiement de la plate-forme Kalimucho . . . 118

4.19 Configurations du service Description . . . 122

4.20 Exemple du r´ eseau du mus´ ee ` a un instant donn´ e . . . 123

4.21 Exemple d’une configuration . . . 124

4.22 Exemple d’un placement sans solution si le graphe de r´ eseau est consid´ er´ e orient´ e . . . 126

4.23 Exemple d’une topologie comportant plusieurs choix de placements des com- posants . . . 127

5.1 Interface principale du simulateur . . . 141

5.2 Interface d’ajout, de modification et de consultation d’un composant . . . . 143

5.3 Interface d’ajout, de modification et de consultation d’un p´ eriph´ erique . . . 144

5.4 Interface d’ajout, de modification et de consultation d’une configuration . . 145

5.5 Interface d’ajout, de modification et de consultation d’une topologie de r´ eseau146

5.6 Interface de consultation des connecteurs r´ eseau . . . 147

5.9 Visualisation du r´ esultat du test 1 . . . 150

5.10 R´ esultat du placement des composants de la configuration ”Texte” dans les conditions d’ex´ ecution favorables . . . 150

5.11 R´ esultat du d´ eploiement du test 1 . . . 151

5.12 Interface du r´ esultat du d´ eploiement du test 2 : Ev` enement de ressource sur H ₂ . . . 152

5.13 R´ esultat du d´ eploiement du test 2 . . . 152

5.14 Interface du r´ esultat du d´ eploiement du test 3 : Ev` enement de ressource sur H 1 . . . 155

5.15 R´ esultat du d´ eploiement du test 3 . . . 155

5.16 Interface du r´ esultat du d´ eploiement du test 4 : Ev` enement de mobilit´ e sur H 3 . . . 156

5.17 Interface du r´ esultat du d´ eploiement du test 5 : Environnement tr` es contraint157 5.18 R´ esultat du test 5 . . . 158

5.19 Graphe d’une configuration complexe . . . 158

5.20 Graphe d’un r´ eseau constraint . . . 159

5.21 Interface du r´ esultat du d´ eploiement d’une configuration complexe en envi- ronnement tr` es contraint . . . 160

5.22 R´ esultat du d´ eploiement d’une configuration complexe en environnement tr` es contraint . . . 160

5.23 D´ eploiement de Kalimucho dans un environnement h´ et´ erog` ene . . . 163

5.24 Sc´ enario de reconfiguration d’un service d’affichage . . . 164

5.25 Proc´ edure de test de transfert de donn´ ees . . . 167

5.26 Analyse du test de transfert d’un objet de 52Ko . . . 168

5.27 Analyse du test de transfert d’un objet de 294 Ko . . . 168

1 Synth` ese des approches de reconfiguration des applications distribu´ ees . . . 38 2 Synth` ese des approches de gestion du contexte . . . . 46 3 Origine des informations contextuelles . . . . 59 4 Tableau r´ ecapitulatif des ´ ev` enements trait´ es par la plate-forme . . . . 99 5 Liste class´ ee par poids des p´ eriph´ eriques candidats ` a la tentative de place-

ment de C ₂ . . . 130 6 Types des p´ eriph´ eriques de la table 5 . . . 130 7 Classement des p´ eriph´ eriques voisins selon leur type . . . 130 8 Exemple de valeur d’´ energie disponible pour les p´ eriph´ eriques ex aequo . . . 131 9 Classement selon l’´ energie disponible . . . 131 10 Exemple de valeur de CPU disponible pour les p´ eriph´ eriques ex aequo . . . 131 11 Classement selon le CPU disponible . . . 132 12 Caract´ eristiques des p´ eriph´ eriques de la simulation . . . 148 13 Temps d’ex´ ecution d’une commande de d´ eploiement/reconfiguration sur un

capteur SunSpot . . . 166

xv

2.1 Exemple d’un profil de contexte dans SECAS . . . . 40

3.1 Exemple d’une r` egle ECA pour la reconfiguration d’un composant . . . . . 58

4.1 Exemple de carte d’identit´ e : le composant C 1 . . . 124

4.2 Exemple d’une carte d’identit´ e : le p´ eriph´ erique H 1 . . . 125

5.1 Carte d’identit´ e d’un composant . . . 142

5.2 Carte d’identit´ e d’un p´ eriph´ erique . . . 143

5.3 Exemple de commandes de reconfiguration . . . 165

xvii

Introduction

Sommaire

1.1 Probl´ ematique . . . . 2 1.2 Exemple d’application . . . . 4 1.3 Objectif . . . . 7 1.4 Conclusion . . . . 9 Depuis une quinzaine d’ann´ ees, nous assistons ` a une ´ evolution consid´ erable des tech- nologies et des habitudes d’utilisation de l’informatique. La d´ emocratisation des moyens de communication sans-fil coupl´ ee aux avanc´ ees technologiques mat´ erielles permettent ` a pr´ esent de proposer des dispositifs portables qui tiennent dans la main, dot´ es d’une capa- cit´ e de calcul et de moyens de communication sans-fil tels que les mini PC, les PDA, les t´ el´ ephones portables et mˆ eme les capteurs sans-fil. L’informatique devient alors disponible partout : c’est l’informatique diffuse.

Ces constats convergent vers la vision de l’informatique du futur que donnait Mark Weiser en 1991 dans son article intitul´ e ”The Computer for the 21st Century” [84] :

The most profound technologies are those that disappear. They weave them- selves into the fabric of everyday life until they are indistinguishable from it.

Les syst` emes pervasifs d´ esignent d´ esormais l’informatique nouvelle o` u l’environnement est naturellement dot´ e de capacit´ es de traitement et de communication, int´ egr´ ees de fa¸ con ` a devenir invisibles et omnipr´ esents. La finalit´ e de tels syst` emes tourn´ es vers l’utilisateur est de fournir un environnement personnalis´ e qui facilite l’acc` es aux services et am´ eliore leur utilisation de fa¸con transparente.

La miniaturisation des p´ eriph´ eriques et leur mobilit´ e en font des objets personnels ` a part enti` ere. Les utilisateurs montrent alors un int´ erˆ et particulier ` a pouvoir acc´ eder ` a une multitude de services et de fonctionnalit´ es depuis n’importe o` u et n’importe quel dispositif.

Ils sont ´ egalement de plus en plus sensibles ` a la personnalisation des applications qu’ils utilisent sur leur p´ eriph´ erique comme par exemple l’adaptation de l’interface graphique en fonction des capacit´ es du p´ eriph´ erique, l’adaptation de l’application en fonction de leurs pr´ ef´ erences comme la langue ou bien l’adaptation en fonction de leurs d´ eplacements ou de leur environnement physique (luminosit´ e, temp´ erature, etc).

Cette personnalisation des applications n´ ecessite une sensiblit´ e au contexte telle que

1

la d´ efinissent Schilit et Theimer d` es 1994 [67] : la sensibilit´ e au contexte est la capacit´ e d’une application et/ou d’un utilisateur mobile, de d´ ecouvrir et r´ eagir aux changements de sa situation”.

Enfin la sensibilit´ e des utilisateurs quant ` a la perception du service rendu r´ ef` ere ` a la qualit´ e de service de l’application telle que la d´ ecrit [42] : l’ad´ equation entre le service souhait´ e par l’utilisateur et le service qui lui est fourni.

Ces deux notions sont fortement corr´ el´ ees. En effet, afin de pouvoir garder cette ad´ equation entre le service souhait´ e et le service fourni malgr´ e les changements de l’envi- ronnement, il est n´ ecessaire d’adapter les services. La sensibilit´ e au contexte va permettre de fournir les informations n´ ecessaires pour adapter les services et permetre la continuit´ e de son ex´ ecution. Conform´ ement ` a la finalit´ e des syst` emes pervasifs, cette adaptation doit rester transparente ` a l’utilisateur.

1.1 Probl´ ematique

L’objectif est de r´ epondre aux besoins des utilisateurs et aux changements de l’en- vironnement par des adaptations des services avec pour principal crit` ere la qualit´ e de service de l’application. Nous nous attachons particuli` erement ` a la gestion de la qualit´ e de service des applications distribu´ ees face aux contraintes mat´ erielles de leur support, aux exigences de l’utilisateur et aux circonstances courantes d’utilisation. En effet, bien que les caract´ eristiques propos´ ees par ces p´ eriph´ eriques tendent ` a am´ eliorer la qualit´ e du service rendu ` a l’utilisateur, leur int´ egration dans les syst` emes traditionnels implique de relever plusieurs d´ efis :

Limitation des ressources Le fonctionnement des syst` emes pervasifs r´ eside en partie sur la collaboration de dispositifs petits et mobiles. Cependant l’atout que pr´ esente la petite taille et la mobilit´ e de ces dispositifs est ´ egalement une contrainte. En effet, la mobilit´ e implique une autonomie ´ energ´ etique. Or, des ´ etudes ont montr´ e que les transmissions sans-fil ont une consommation ´ energ´ etique 10 ` a 100 fois plus ´ elev´ ee qu’un calcul [2]. L’autonomie ´ energ´ etique est une contrainte critique ` a prendre en compte dans le d´ eveloppement des applications. En effet, lorsqu’un dispositif n’a plus d’´ energie, tous les services qu’il h´ ebergeait deviennent inutilisables et l’application ou la partie d’application qui en d´ ependait ne peut plus fonctionner. En terme de qualit´ e de service, cette situation doit ˆ etre ´ evit´ ee ou anticip´ ee. De plus, la petite taille des dispositifs implique des capacit´ es de calcul et des capacit´ es de m´ emoire r´ eduites qui doivent ´ egalement ˆ etre prises en compte.

Le d´ eveloppement des syst` emes devra prendre en compte les capacit´ es restreintes des p´ eriph´ eriques notamment lors du d´ eploiement.

H´ et´ erog´ en´ eit´ e Bien qu’offrant des propri´ et´ es similaires, les dispositifs que nous rencon- trons dans les syst` emes pervasifs tels que les ordinateurs portables, les t´ el´ ephones, les PDA, les capteurs, sont diff´ erents ` a tous niveaux : mat´ eriel, logiciel et communi- cation.

Le d´ eveloppement des syst` emes devra proposer des solutions d’interop´ erabilit´ e.

Mobilit´ e La mobilit´ e est un atout pour les syst` emes pervasifs mais elle soul` eve n´ eanmoins des probl` emes. Le principe des syst` emes pervasifs r´ eside sur la collaboration des services et donc des p´ eriph´ eriques qui les herbergent. La mobilit´ e des p´ eriph´ eriques entraine des variations de connexion qui peuvent avoir de lourdes cons´ equences sur le fonctionnement des services : faible d´ ebit qui entraine la lenteur des transmissions et parfois la d´ econnexion. Tout comme l’´ epuisement d’une batterie, les d´ econnexions provoquent, au moins de mani` ere temporaire, l’indisponibilit´ e des services et par cons´ equent d´ egradent la qualit´ e de service de l’application.

Le d´ eveloppement des syst` emes devra proposer des solutions pour la gestion de la mobilit´ e et la continuit´ e des services de l’application.

Variation du contexte L’utilisateur et son p´ eriph´ erique ´ evoluent dans un environne- ment sans cesse changeant. L’utilisateur modifie ses pr´ ef´ erences, les ressources du p´ eriph´ erique ´ evoluent tout comme l’environnement physique. Le fonctionnement des applications peut ˆ etre perturb´ e par des modifications du contexte. Par exemple, dans une application de visio-conf´ erence, la luminosit´ e et le bruit ambiant peuvent per- turber son fonctionnement et se r´ epercuter sur la satisfaction de l’utilisateur et sur l’utilisabilit´ e de l’application, c’est-` a-dire modifier la qualit´ e de service per¸ cue par ce dernier.

Il faut alors pouvoir prendre en compte ces ´ evolutions du contexte pour pouvoir agir de mani` ere ` a maintenir la qualit´ e du service rendu. Cette contrainte est ` a l’origine de la sensibilit´ e au contexte.

Afin de faire face ` a ces probl` emes et ` a la complexit´ e des applications, la r´ eponse la plus r´ epandue est la virtualisation. [17] fait un ´ etat de l’art des approches par virtualisation et en donne la d´ efinition suivante :

Les approches par virtualisation consistent donc ` a cr´ eer des environnements de d´ eveloppement et d’ex´ ecution des applications. Il est alors possible de concevoir les applications en manipulant des objets complexes cr´ e´ es par des couches logi- cielles de virtualisation (APIs, langages, biblioth` eques, services de l’intergiciel). De mˆ eme ces applications s’ex´ ecutent sur des plates-formes qui cachent les supports sous-jacents (syst` emes d’exploitation, machines virtuelles, serveurs d’applications).

. Concernant les dispositifs contraints, [17] soul` eve la question suivante : Comment continuer ` a r´ epondre ` a la complexit´ e croissante des logiciels et d´ evelopper des applications sur des p´ eriph´ eriques contraints tout en proposant des solutions r´ epondant aux demandes des utilisateurs ? Les solutions existantes dans la litt´ erature proposent des plate-formes d’ex´ ecution telle que J2ME. Ces plates-formes, outre qu’elles permettent de cacher l’h´ et´ erog´ en´ eit´ e des mat´ eriels, facilitent le dialogue entre ces p´ eriph´ eriques et des applications plus traditionnelles.

De plus, bien que de nombreux travaux utilisent le contexte pour l’adaptation des

applications, il n’existe aucun consensus autour de sa d´ efinition. En effet, chaque appli-

cation ayant un objectif sp´ ecifique, les informations auxquelles elle va r´ eagir sont ´ egalement

sp´ ecifiques. C’est pourquoi nous devons proposer une classification des informations contex-

tuelles sp´ ecifiques ` a notre objectif de qualit´ e de service. Il en est de mˆ eme pour la d´ efinition

de la qualit´ e de service puisque celle-ci n’utilisent pas les mˆ emes crit` eres selon le type d’ap-

plication vis´ e. Tout comme pour le contexte, nous devons proposer une d´ efinition de la

qualit´ e de service sp´ ecifiques aux applications distribu´ ees en environnement contraint.

Dans ce chapitre nous pr´ esentons les objectifs de cette th` ese que nous illustrons ` a l’aide d’un exemple : une application de visite d’un mus´ ee. Puis nous pr´ esentons ce qu’est le contexte accompagn´ e d’une classification permettant la prise en compte des informations contextuelles ` a trois niveaux : utilisateur, application, infrastructure. Nous pr´ esentons ensuite la d´ efinition de la qualit´ e de service que nous avons retenu pour ces travaux. Enfin, nous pr´ esentons un ´ etat de l’art des approches propos´ ees pour l’adaptation dynamique des applications utilisant des plate-formes de reconfiguration.

1.2 Exemple d’application

Tout au long de ce m´ emoire, nous allons illustrer notre approche par un exemple d’application : la visite d’un mus´ ee. Elle s’adresse ` a deux types d’utilisateurs : d’une part les visiteurs du mus´ ee et d’autre part le personnel en charge du mus´ ee. Cette application est destin´ ee ` a ˆ etre utilis´ ee avec diff´ erents appareils mobiles tels que des PDA, des Mobile PC ou des smart-phones. Tout d’abord rescensons les besoins de chaque utilisateur.

Lorsqu’un visiteur est dans le mus´ ee, il souhaite, pour chacune des œuvres pr´ esent´ ees, pouvoir disposer d’informations sur sa cr´ eation, son auteur, son histoire, etc. Il souhaite

´ egalement pouvoir visiter librement, avec ou sans l’aide d’un plan du mus´ ee, ou au contraire ˆ etre guid´ e de son entr´ ee jusqu’` a la sortie du mus´ ee pour ne pas perdre de temps et ne pas rater les œuvres incontournables.

Le personnel veut connaˆıtre en temps r´ eel le nombre de visiteurs ` a l’int´ erieur du mus´ ee mais ´ egalement disposer de statistiques sur le nombre de personnes ayant visit´ e le mus´ ee dans la journ´ ee ou le mois afin d’´ evaluer les taux de fr´ equentation. Il souhaite ´ egalement connaˆıtre le nombre de visiteurs qui ont demand´ e des informations sur chaque oeuvre afin de mettre ` a jour les parcours de visites guid´ ees par exemple. Enfin il souhaite pouvoir guider les visiteurs vers la sortie lors de la fermeture du mus´ ee ou lors d’un incident.

Afin de r´ epondre ` a l’ensemble des besoins ´ enonc´ es pr´ ec´ edemment, nous proposons que cette application de visite de mus´ ee fournisse trois services :

– un service de description. Ce service fournit ` a la demande du visiteur des informa- tions sur l’œuvre devant laquelle il est arrˆ et´ e.

– un service de guidage. Ce service propose deux versions. La premi` ere est un service de guidage simple qui fournit un plan du mus´ ee ` a l’utilisateur. La deuxi` eme est un service de visite guid´ ee qui fournit un parcours correspondant ` a une dur´ ee donn´ ee et ` a une th´ ematique choisie par l’utilisateur.

– un service de statistiques. Ce service permet de recueillir et traiter les donn´ ees rela- tives ` a l’utilisation du mus´ ee.

Les services ne sont pas tous visibles par tous les utilisateurs. Les visiteurs ont uni- quement acc` es au service de description et au service de guidage alors que le personnel a acc` es au service de statistiques ainsi qu’au service de guidage.

L’objectif est que chaque service s’adapte ` a la fois aux souhaits de l’utilisateur, aux capacit´ es du p´ eriph´ erique qu’il utilise ainsi qu’aux ´ ev` enements ext´ erieurs qui peuvent influer sur le rendu final des services comme par exemple :

– lorqu’un utilisateur demande un service, celui-ci doit lui ˆ etre fourni en fonction des

Description

Conversion Noir et Blanc

Déplacement Visiteur 1

Visiteur 2

Visiteur 3

Visiteur 3

Figure 1.1 – Scenario d’utilisation de l’application de visite d’un mus´ ee

capacit´ es du p´ eriph´ erique (vid´ eo, audio, texte), et des ressources physiques dispo- nibles (´ energie, m´ emoire).

– lorsque les ressources physiques d’un p´ eriph´ erique atteignent un seuil critique, il faut pouvoir ´ evaluer la qualit´ e du service rendu et proposer une nouvelle solution.

– lorsqu’un ´ ev` enement survient comme une demande de la part de l’utilisateur, la fermeture du mus´ ee ou encore une conf´ erence, il faut pouvoir le traiter afin d’adapter les services en cons´ equence et de proposer une application qui fonctionne le mieux possible.

– enfin lorsque l’utilisateur se d´ eplace, il faut pouvoir assurer la continuit´ e du service tout en respectant les souhaits de l’utilisateur et les limitations de ressources du p´ eriph´ erique.

D´ ecrivons un sc´ enario possible d’utilisation de l’application afin d’illustrer les adapta- tions que nous souhaitons traiter dans cette th` ese. Trois visiteurs sont dans le mus´ ee et utilisent le service de description. La figure 1.1 d´ ecrit la situation spaciale des visiteurs dans le mus´ ee.

Parmi les diff´ erents choix pour le service de description, nous estimons que dans le contexte de l’application de visite d’un mus´ ee, la meilleure qualit´ e est de fournir le service sous sa forme vid´ eo en couleurs. Lorsque le visiteur 3 se d´ eplace dans le mus´ ee, trois cas de figure se pr´ esentent. Premi` erement, bien qu’il se soit d´ eplac´ e, le p´ eriph´ erique du visiteur 3 est toujours ` a port´ ee du serveur de vid´ eo et le d´ ebit permet toujours de transmettre une vid´ eo en couleur. Deuxi` emement, le d´ ebit est faible mais le p´ eriph´ erique est toujours

`

a port´ ee. Afin d’assurer la continuit´ e du service, une solution est de r´ eduire le nombre de

donn´ ees ` a transmettre. R´ eduire le nombre de donn´ ees consiste ` a effectuer des traitements sur ces donn´ ees afin de transmettre moins, ou moins souvent. Une solution est d’effectuer un traitement sur une vid´ eo telle qu’une conversion en noir et blanc, une r´ eduction du nombre de couleurs ou encore une r´ eduction de la r´ esolution des images. Ceci implique de proposer une nouvelle structure incluant un traitement suppl´ ementaire. Dans le cas de la transmission de la vid´ eo, nous pouvons ajuster un traitement de conversion en noir et blanc sur le serveur. Le serveur ne transmet plus de couleurs au p´ eriph´ erique 3 mais du noir et blanc. Troisi` emement, le p´ eriph´ erique n’est plus ` a port´ ee du serveur, nous devons donc chercher une nouvelle route afin d’atteindre le p´ eriph´ erique 3 et d’assurer la continuit´ e du service. Une solution peut ˆ etre d’utiliser le p´ eriph´ erique du visiteur 2, qui utilise ´ egalement le service de description, afin de lui faire jouer le rˆ ole de relais pour le p´ eriph´ erique 3.

D´ ecouvrir une nouvelle route pour transmettre une information est un probl` eme clas- sique que les protocoles r´ eseau savent r´ esoudre. Il existe des protocoles r´ eseau d´ edi´ es aux p´ eriph´ eriques contraints. Un exemple est le protocole AODV de [60]. AODV propose des solutions de routage rapides en r´ eponse ` a la mobilit´ e des p´ eriph´ eriques et ` a leurs faibles ressources de traitement et de m´ emoire. Toutefois, nous souhaitons proposer des solutions diff´ erentes plus int´ eressantes et non uniquement bas´ ees sur des crit` eres techniques de fai- sabilit´ e. En effet puisque la vid´ eo en couleurs est d’ores et d´ ej` a diffus´ ee aux utilisateurs 1 et 2, il est tout ` a fait envisageable que l’un de ces deux utilisateurs puisse assurer un rˆ ole de relais vers l’utilisateur 3 qui n’est plus directement ` a port´ ee du service vid´ eo.

Toutefois si l’´ energie disponible sur le p´ eriph´ erique servant de relais est trop faible, la diffusion d’une vid´ eo en couleurs n’est pas envisageable. Il est alors possible de proposer l’installation un composant de conversion couleur/noir et blanc sur le p´ eriph´ erique ser- vant de relais afin qu’il ne diffuse qu’une version en noir et blanc compatible avec l’´ energie disponible. Ainsi, par exemple, dans le souci d’assurer la continuit´ e du service, avant de retransmettre la vid´ eo au p´ eriph´ erique 3, une conversion en noir et blanc est effectu´ ee au niveau du p´ eriph´ erique 2. En effet, il faut pr´ eciser que pour de tels p´ eriph´ eriques, les transmissions de donn´ ees sont d´ emesur´ ement plus coˆ uteuses en ´ energie que le calcul.

Selon le p´ eriph´ erique, une transmission coˆ ute entre dix ` a cent fois plus qu’un calcul de mˆ eme dur´ ee. De mˆ eme, plus les p´ eriph´ eriques communicants sont distants l’un de l’autre, plus ils consommeront d’´ energie afin de maintenir un signal r´ eseau assez puissant pour transmettre des donn´ ees. La consommation d’´ energie est fonction du nombre de donn´ ees transmises ainsi que de la distance avec le r´ ecepteur. Afin de limiter la consommation d’´ energie et par cons´ equent d’allonger la dur´ ee de vie de l’application, il est g´ en´ eralement pr´ ef´ erable de traiter les donn´ ees pour en transmettre moins. Ainsi la conversion de la vid´ eo en noir et blanc permet de r´ eduire le nombre de donn´ ees ` a transmettre au p´ eriph´ erique 3 et donc de pr´ eserver son ´ energie ainsi que celle de l’´ emetteur. D´ elocaliser une partie des services permet un ´ equilibrage des charges au niveau du r´ eseau et des p´ eriph´ eriques.

Rapprocher un traitement de la source peut ´ eviter des transmissions ce qui, comme nous

l’avons mentionn´ e, permet de pr´ eserver l’´ energie des p´ eriph´ eriques. Lorsque le r´ eseau sa-

ture, que la bande passante est faible ` a la sortie d’un p´ eriph´ erique, il est pr´ ef´ erable de

d´ elocaliser un service vers un p´ eriph´ erique o` u la bande passante est plus ´ elev´ ee. Enfin,

en raison de leurs faibles ressources, les p´ eriph´ eriques peuvent voir leur m´ emoire ou leur

capacit´ e de traitement satur´ ees. Il faut alors les soulager. Pour cela, nous pouvons choisir

de d´ eplacer un ou plusieurs services vers d’autres p´ eriph´ eriques plus disponibles. On peut

remarquer qu’une telle solution fait appel ` a une connaissance de l’application en termes de services que les protocoles r´ eseau ne peuvent pas avoir. Dans une situation identique, les protocoles r´ eseaux comme AODV [60] n’auraient pu proposer que des solutions per- mettant de continuer ` a transmettre la vid´ eo en couleurs ` a l’utilisateur 3. Ceci aurait ´ et´ e fait au d´ etriment de la p´ erennit´ e de l’application puisque cette solution aurait abouti ` a un

´

epuisement rapide de la batterie du p´ eriph´ erique assurant le relais. Par sa connaissance des services demand´ es par les utilisateurs, de ceux actuellement disponibles et surtout par la possibilit´ e qu’elle offre de substituer ` a un service d´ efaillant un service de qualit´ e diff´ erente mais de mˆ eme rˆ ole, notre approche par reconfiguration permet de proposer des solutions viables du point de vue de l’infrastructure et acceptables du point de vue de la qualit´ e de service.

1.3 Objectif

Le principal objectif de cette th` ese se focalise autour de la qualit´ e de service des applications. Les applications que nous visons sont soumises ` a trois contraintes.

D’une part elles s’ex´ ecutent sur des p´ eriph´ eriques contraints, c’est-` a-dire dont les res- sources sont limit´ ees et particuli` erement l’´ energie. Lorsqu’un p´ eriph´ erique cesse de fonc- tionner, tous les services dont il est le support d’ex´ ecution cessent de fonctionner ` a leur tour. L’application subit alors une rupture de service. L’un des objectifs de cette th` ese est d’´ eviter ce type de situation et de proposer des solutions qui permettent aux p´ eriph´ eriques de fonctionner le plus longtemps possible afin de p´ erenniser l’ex´ ecution de l’application.

Il s’agit ´ egalement d’anticiper certaines situations comme la fin de vie de la batterie d’un p´ eriph´ erique. La pr´ eoccupation de la consommation d’´ energie est une probl´ ematique abord´ ee jusque l` a en termes de protocoles de routage essentiellement. Nous souhaitons y r´ epondre en int´ egrant les pr´ eoccupations de QdS de l’informatique ambiante. R´ eduire la consommation d’´ energie d’un p´ eriph´ erique par l’application peut se faire en r´ epartissant la charge de l’application sur les p´ eriph´ eriques voisins. Dans ce cas, il faut pouvoir proposer des solutions telles que la d´ elocalisation de services en cours d’ex´ ecution afin d’anticiper les d´ econnexions dues au d´ echargement complet de la batterie.

D’autre part le contexte dans lequel elles ´ evoluent varie constamment au cours du temps. Comme nous l’avons d´ ecrit dans l’introduction, une application qui fonctionne bien ` a un instant t peut ne plus fonctionner ou mal fonctionner ` a l’instant t+1. A chaque modification du contexte, l’objectif est d’assurer que l’application puisse fonctionner le mieux possible. Dans le sc´ enario que nous avons d´ ecrit (figure 1.1), un utilisateur souhaite utiliser le service de description. Dans un premier temps, le service lui est propos´ e sous sa forme vid´ eo en couleurs. Cependant, au cours de l’ex´ ecution, le niveau d’´ energie du p´ eriph´ erique a fortement diminu´ e. Continuer d’utiliser la forme vid´ eo en couleurs devient critique ` a ce niveau de batterie, le service n’est plus adapt´ e aux ressources du p´ eriph´ eriques.

Une solution est de modifier le service afin, par exemple, qu’il fournisse une vid´ eo en noir et blanc ou un nombre d’images par seconde r´ eduit.

Enfin, nous devons ´ egalement g´ erer la mobilit´ e des p´ eriph´ eriques. Comme nous l’avons

d´ ecrit dans le sc´ enario, des situations de mobilit´ e peuvent mettre en p´ eril la continuit´ e de

l’application d’une part et la dur´ ee de vie des p´ eriph´ eriques d’autre part. L’objectif est de

pouvoir d´ etecter la mobilit´ e et de r´ eagir en cons´ equence.

Pour r´ epondre ` a ces objectifs nous proposons de raisonner en termes de qualit´ e de service. Le but est de fournir ` a l’utilisateur une application de la meilleure qualit´ e possible.

Ceci implique de raisonner dans la globalit´ e car une am´ elioration partielle en un point de l’application peut se r´ ev´ eler catastrophique en un autre point.

Si nous r´ esumons, l’objectif de nos travaux est de faire en sorte que les applications fonctionnent le mieux possible et le plus longtemps possible quels que soient les chan- gements de contexte. Le principe est de reconfigurer l’application lorsque la qualit´ e du service en cours d’ex´ ecution n’est plus adapt´ ee aux exigences des diff´ erents acteurs, des utilisateurs, du mat´ eriel et de l’application elle-mˆ eme. Pour cela, nous avons besoin d’avoir une vue globale du fonctionnement de l’application ainsi qu’une grande flexbilit´ e.

C’est pourquoi nous avons choisi d’utiliser des applications compos´ ees qui, grˆ ace ` a leur modularit´ e, offrent un grand choix de solution pour garantir une application continue et de qualit´ e et de les superviser par une plate-forme. Cette plate-forme doit fournir des m´ ecanismes permettant de fournir des applications offrant la meilleure QdS en fonction du contexte :

1. en proposant une classification du contexte et une d´ efinition de la qualit´ e de service associ´ ee ` a des mod` eles d’´ evaluation permettant de refl´ eter l’influence de la totalit´ e des participants, utilisateur, environnement, composants, mat´ eriel et r´ eseau, sur la qualit´ e de service de l’application.

2. en proposant d’accroˆıtre les possibilit´ es de garantir la meilleure QdS en consid´ erant l’ensemble des p´ eriph´ eriques disponibles comme des supports potentiels de d´ eploiement de l’application.

3. le tout supppose de prendre en compte les propri´ et´ es des composants et des connexions dans le choix de d´ eploiement.

Pour pouvoir s’adapter dynamiquement, l’application doit avoir une connaissance d’elle- mˆ eme (r´ eflexivit´ e) afin de pouvoir substituer un service pratiquement ´ equivalent ` a un ser- vice d´ efectueux ou inadapt´ e au contexte. Dans ce but nous avons choisi d’utiliser une plate-forme d’ex´ ecution qui connait l’application en cours et son contexte.

Cette plate-forme peut alors prendre des d´ ecisions de reconfiguration dynamique en toutes connaissances de cause. Elle assure ainsi la continuit´ e des services tout en prenant en compte la p´ erennit´ e globale de l’application. Une telle solution permet au concepteur de d´ efinir un ensemble de services dont certains sont substituables et ` a l’utilisateur de dispo- ser de ces services selon ses besoins. Les probl` emes non fontionnels induits par la mobilit´ e, l’´ energie et, de fa¸ con plus g´ en´ erale, le contexte, sont alors pris en compte par la plate- forme qui modifie, remplace et d´ eplace des services dans une optique globale de QdS de l’application.

Nous devons tout d’abord capturer tous les changements de contexte qu’ils soient li´ es ` a l’utilisateur, aux ressources ou ` a la mobilit´ e. Ensuite nous devons interpr´ eter ces changements afin de r´ eagir de la meilleure fa¸ con. Nous proposons d’´ etablir un mod` ele de contexte permettant de le d´ ecrire, le capturer et l’interpr´ eter.

C’est pourquoi nous devons pr´ evoir la prise en compte de l’´ evolution du contexte le

plus tˆ ot possible dans la conception de l’application. La section suivante propose un ´ etat

de l’art des d´ efinitions du contexte et propose une classification de ce dernier permettant

d’inclure un large spectre d’informations auquel les applications doivent ˆ etre adapt´ ees.

1.4 Conclusion

Face aux d´ efis qu’engendre le probl` eme de l’adaptation des applications pervasives, nous proposons Kalimucho, Kalitate ¹ Mucho ² , une plateforme de reconfiguration et de d´ eploiement contextuel et dynamique d’applications bas´ ees composants. Kalimucho prend en charge la reconfiguration et le d´ eploiement des applications sur les diff´ erents p´ eriph´ eriques en les adaptant aux contraintes. L’originalit´ e de cette plateforme est qu’elle exploite le plus possible les ressources de l’application en permettant d’utiliser tous les p´ eriph´ eriques dis- ponibles, y compris les capteurs, comme support des composants logiciels de l’application.

Les contributions de ses travaux r´ esident en ces ´ el´ ements :

1. Une classification du contexte et une d´ efinition de la qualit´ e de service permettant de prendre en compte les diff´ erentes propri´ et´ es des applications pervasives. La clas- sification du contexte propos´ ee permet d’inclure un large spectre des informations disponibles dans l’environnement de l’application. Elle permet d’introduire la prise en compte des sp´ ecifications de l’application elle-mˆ eme alors que les d´ efinitions les plus courantes sont centr´ ees sur une entit´ e comme l’utilisateur ou le p´ eriph´ erique. La d´ efinition de la qualit´ e de service propos´ ee permet de r´ eunir deux notions fortement correl´ ees dans le cadre des applications pervasives : l’utilit´ e de l’application et la disponibilit´ e des ressources.

2. Un mod` ele de contexte simple bas´ e sur une connaissance des composants et des p´ eriph´ eriques a priori mais ´ egalement sur la collecte d’information pendant l’ex´ ecution.

La plateforme est inform´ ee des changements de contexte grˆ ace ` a un m´ ecanisme constitu´ e de composants sp´ ecifiques d’´ ecoute du contexte et g´ en` ere les actions ad´ equates.

Le mod` ele de context est associ´ e ` a une m´ ethode de conception permettant d’aider le concepteur de l’application dans sa d´ emarche de mod´ elisation du contexte. Cette m´ ethode permet d’identifier les sp´ ecifications de l’application, des composants et des p´ eriph´ eriques. Elle permet ´ egalement d’identifier tous les ´ ev` enements pouvant engendrer des reconfigurations. Enfin, elle permet de d´ ecomposer l’application en diff´ erentes configurations qui servent de base au choix de reconfiguration.

3. Un mod` ele de qualit´ e de service associ´ e ` a des heuristiques d’´ evaluation de d´ eploiement qui permettent d’´ evaluer la qualit´ e de service d’une application ` a deux niveaux : l’ad´ equation du service rendu par rapport au service souhait´ e et la dur´ ee de vie de l’application. La particularit´ e de ce mod` ele de qualit´ e de service est qu’il permet de prendre en compte ` a la fois la disponibilit´ e des ressources mat´ erielles et la disponi- bilit´ e des ressources r´ eseaux. Le but de ce mod` ele est de fournir une application qui propose le meilleur compromis entre une application utile et une dur´ ee de vie la plus longue possible.

4. Une architecture logicielle distribu´ ee de la plateforme Kalimucho qui permet d’avoir une repr´ esentation globale de l’application. La distribution de la plateforme prend en compte les contraintes des p´ eriph´ eriques. Les composants et les connecteurs des

1. qualit´ e en langue basque

2. plus en langue espagnole

applications sont construits selon un mˆ eme mod` ele permettant une vue et une ma- nipulation unifi´ ee des applications grˆ ace ` a des trois actions : ajouter, supprimer et migrer.

Le manuscrit est organis´ e de la fa¸ con suivante :

Le chapitre 2 pr´ esente un ´ etat de l’art des d´ efis ` a relever dans le domaine de la sensibilit´ e au contexte et des p´ eriph´ eriques contraints et mobiles. Il inclut une classification du contexte et une d´ efinition de la qualit´ e de service permettant de conclure que la gestion de la QdS d’une application peut se faire par une adaptation au contexte. Nous ´ etudions les diff´ erentes approches propos´ ees pour r´ epondre ` a ces probl` emes tels que les intergiciels de reconfiguration, les intergiciels de d´ eploiement contextuel et les architectures logicielles pour la gestion de la qualit´ e de service. Nous ´ etudions ´ egalement les diff´ erents m´ ecanismes propos´ es pour la gestion du contexte. Nous concluons ce chapitre par une classification des approches ´ etudi´ ees permettant de mettre en exergue leurs points communs et leurs diff´ erences. Nous nous basons sur cette classification pour donner les propri´ et´ es que doit offrir la plateforme Kalimucho.

Le chapitre 3 pr´ esente le mod` ele de contexte retenu et le mod` ele de qualit´ e de service pour l’´ evaluation des applications. Ce chapitre d´ etaille les deux fonctions d’´ evaluation de la qualit´ e de service : la premi` ere ´ etudie le coˆ ut de d´ eploiement mat´ eriel d’une configuration sur les p´ eriph´ eriques et la seconde ´ etudie le coˆ ut de d´ eploiement r´ eseau d’une configuration.

Enfin, nous d´ etaillons la m´ ethode de conception associ´ ee au mod` ele de contexte permettant au concepteur d’identifier tous les ´ ev` enements de reconfiguration et de produire les cartes d’identit´ e des composants et des p´ eriph´ eriques.

Le chapitre 4 pr´ esente l’architecture de Kalimucho avec ses mod` eles de composants et de connecteurs et ses services de supervision. Dans ce chapitre nous d´ etaillons les diff´ erents moyens d’action dont dispose la plateforme pour r´ ealiser les reconfigurations.

Nous d´ etaillons ´ egalement l’heuristique de choix de reconfiguration et du d´ eploiement associ´ e aux ´ ev` enements re¸cus par Kalimucho.

Le chapitre 5 propose un prototype impl´ ement´ e dans le cadre de ces travaux afin de valider le fonctionnement de l’heuristique inclut dans Kalimucho. Nous pr´ esentons le fonctionnement le l’heuristique de choix de reconfiguration face ` a diff´ erents ´ ev` enements de reconfiguration tel que l’´ evolution des ressources et la mobilit´ e d’un p´ eriph´ erique et face

`

a un environnement tr` es contraint.

Enfin, nous concluons par une synth` ese des travaux pr´ esent´ es et nous donnons les

percpectives et les directions de recherches possibles ` a ce travail.

Adaptation dynamique et Qualit´ e de Service

Sommaire

2.1 Introduction . . . . 12 2.2 Contexte . . . . 12 2.2.1 Contexte d’utilisateur . . . . 13 2.2.2 Contexte d’utilisation . . . . 14 2.2.3 Contexte d’ex´ ecution . . . . 14 2.3 Gestion de la qualit´ e de service . . . . 15 2.4 Qualit´ e de service . . . . 17 2.4.1 D´ efinition de la Qualit´ e de Service . . . . 17 2.4.2 Qualit´ e de Service et Contexte . . . . 18 2.5 Synth` ese . . . . 21 2.6 Syst` emes sensibles au contexte . . . . 23 2.6.1 Intergiciel pour l’adaptation contextuelle d’applications . . . . . 23 2.6.1.1 Aura . . . . 24 2.6.1.2 WComp . . . . 25 2.6.1.3 MUSIC . . . . 27 2.6.2 D´ eploiement contextuel d’applications . . . . 29 2.6.2.1 CADeComp . . . . 29 2.6.2.2 AxSel . . . . 30 2.6.3 Architectures logicielles pour la qualit´ e de service . . . . 31 2.6.3.1 Qinna . . . . 31 2.6.3.2 QuA . . . . 33 2.6.3.3 Kalinahia . . . . 33 2.6.4 Synth` ese . . . . 35 2.7 La gestion du contexte dans les applications pervasives . . . . 39 2.7.1 Context Toolkit . . . . 39 2.7.2 SECAS . . . . 40 2.7.3 Le Contexteur . . . . 43 2.7.4 COSMOS . . . . 44

11

2.7.5 Synth` ese . . . . 45 2.8 Conclusion . . . . 47

2.1 Introduction

Les solutions les plus r´ epandues pour r´ esoudre le probl` eme de l’adaptation dynamique au contexte et ` a celui de la gestion de la qualit´ e de service, sont bas´ ees sur des plate-formes d’ex´ ecution (section 1.1). De la mˆ eme fa¸ con, nous proposons d’adapter les applications par des reconfigurations. Dans la section suivante, nous pr´ esentons un ´ etat de l’art des approches relevant les d´ efis des environnements contraints, de la gestion de la qualit´ e de service et de la gestion du contexte.

2.2 Contexte

Il existe de multiples d´ efinitions du contexte. Elles sont pour la plupart une ´ enum´ eration de param` etres qui les rendent tr` es abstraites, difficile ` a exploiter ou au contraire tr` es sp´ ecifiques ` a un domaine. A partir de plusieurs d´ efinitions que nous trouvons dans la litt´ erature, nous allons exposer notre propre classification du contexte. Plusieurs ten- tatives de d´ efinition du contexte ont ´ et´ e men´ ees dans plusieurs domaines ces derni` eres ann´ ees et plus particuli` erement en informatique ubiquitaire et pervasive avec l’´ emergence des syst` emes sensibles au contexte. [22] fait un parall` ele int´ eressant avec le discours hu- main :

Quand les humains parlent avec d’autres humains, ils sont capables d’utiliser des informations implicites de la situation, ou contexte, pour augmenter la bande passante de la conversation [22].

En effet, pour enrichir la conversation et am´ eliorer notre discours, nous y int´ egrons des informations sur la situation courante ` a l’instant o` u nous parlons. De la mˆ eme fa¸ con, une application pourrait int´ egrer des informations sur sa situation afin d’enrichir, adapter et am´ eliorer le service fourni. Les personnes ` a l’origine du terme

sensible au contexte

(context- awareness) sont Schilit et Theimer [67] qu’ils d´ efinissent comme

la capacit´ e d’une appli- cation et/ou d’un utilisateur mobile de d´ ecouvrir et r´ eagir aux changements de sa situa- tion

. De tr` es nombreuses autres d´ efinitions ont ´ et´ e donn´ ees [58] [22] mais aucune ne fait pour l’instant autorit´ e.

Depuis quelques ann´ ees, les avanc´ ees sur la mobilit´ e des p´ eriph´ eriques et sur la techno- logie sans-fil ont ouvert de nouvelles perspectives dans divers domaines de recherche li´ es

`

a la communication. Cette ´ evolution de l’utilisation de l’informatique a mis en ´ evidence,

pour les applications ainsi distribu´ ees, le besoin d’informations suppl´ ementaires ` a celles

habituellement n´ ecessaires aux traitements. Alors que traditionnellement, les applications

se contentaient de produire de nouvelles donn´ ees en sortie ` a partir de donn´ ees en entr´ ee,

aujourd’hui les traitements peuvent d´ ependre ´ egalement de la situation g´ eographique de

l’utilisateur, de ses souhaits ou encore des donn´ ees physiques telles que la temp´ erature

ext´ erieure ou le taux de luminosit´ e. Ces donn´ ees annexes font partie d’un ensemble appel´ e

Figure 2.1 – Architecture en couche des applications sensibles au contexte [74]

donn´ ees contextuelles ou contexte de l’application. [19] donnent une d´ efinition informelle mais assez repr´ esentative :

Le contexte d’ex´ ecution d’une application regroupe toutes les entit´ es et situa- tions externes qui influent sur la Qualit´ e de service/Performances (qualitative et quantitative) telle que per¸ cue par les utilisateurs.

L’utilisateur n’est pas le seul ` a percevoir l’influence du contexte sur le service rendu, nous pouvons ´ etendre cette d´ efinition au syst` eme si nous lui donnons les moyens de prendre conscience de ces influences. Ces d´ efinitions montrent qu’` a pr´ esent les applications doivent int´ egrer des m´ ecanismes d’acquisition du contexte permettant de le prendre en compte afin de s’adapter par des reconfigurations pour r´ epondre au mieux aux besoins du service rendu.

Cependant le contexte regroupe une multitude de donn´ ees que nous devons organiser afin d’´ evaluer comme il se doit les besoins d’adaptation.

Le principe architectural de la figure 2.1 permettant la prise en compte du contexte dans les applications est assez classique. On en trouvera un exemple dans [74]. Il se

r´ esume

` a une superposition de couches correspondant ` a l’acquisition des informations contextuelles, la gestion du contexte puis l’application (et/ou son adaptation).

Ces informations contextuelles proviennent le plus souvent de diff´ erentes sources. Tout comme [12] nous distinguons les informations de contexte des informations de l’application.

En aucun cas une information contextuelle ne peut ˆ etre fournie en entr´ ee d’un service de l’application. L’application ne traite pas les informations contextuelles. Ces informations sont recueillies et utilis´ ees par la plate-forme afin d’adapter le comportement et la structure des services. [74] va plus loin en distinguant plusieurs types d’informations contextuelles.

Chacune des informations de contexte a un impact diff´ erent sur la QdS et donc sur l’adaptation ` a mener. Nous distinguons les informations re¸ cues de l’utilisateur, de l’envi- ronnement, des p´ eriph´ eriques et du r´ eseau.

2.2.1 Contexte d’utilisateur

Ce sont toutes les informations qui concernent ce que l’utilisateur veut pouvoir faire avec l’application. L’utilisateur est tr` es souvent int´ egr´ e dans le contexte puisqu’il est, la plupart du temps, le seul ` a percevoir le rendu final de l’application.

Une application destin´ ee ` a un utilisateur doit lui fournir des services. L’utilisateur veut

pouvoir ´ emettre des souhaits quant ` a l’utilisation de l’application. L’application pourra

alors ˆ etre modifi´ ee en cons´ equence afin de lui fournir un service le mieux adapt´ e possible.

Nous d´ efinissons le contexte comme ´ etant l’ensemble des entit´ es caract´ erisant les sou- haits de l’utilisateur comme par exemple :

– la demande d’un service. Par exemple, dans l’application de visite du mus´ ee, un visiteur demande ` a pouvoir utiliser le service de guidage.

– l’arrˆ et d’un service. Dans notre exemple de visite du mus´ ee, un visiteur ne souhaite plus utiliser le service de guidage.

– la demande d’une adaptation de service. Un visiteur utilise le service de description.

Cependant la langue dans laquelle la description est donn´ ee ne lui convient pas, il demande alors une traduction dans la langue de son choix.

2.2.2 Contexte d’utilisation

Alors que pour l’utilisateur nous identifions ce qu’il souhaite pouvoir faire avec l’ap- plication, nous nous int´ eressons ici aux sp´ ecifications de l’application.

Nous entendons par sp´ ecifications tout ce qu’elle doit permettre et ce qu’elle ne doit pas permettre dans son utilisation. Ce sont toutes les situations o` u ni l’utilisateur, ni son appareil n’interviennent mais qui demandent tout de mˆ eme une adaptation comme par exemple quand une alarme se d´ eclenche, quand un niveau sonore est trop ´ elev´ e, etc.

Il s’agit de modifications de l’environnement qui entrainent, ` a chaque occurence, la mˆ eme adaptation. Chaque fois qu’une situation ainsi d´ ecrite est rencontr´ ee, il faudra ap- pliquer une r` egle bien d´ efinie.

Nous d´ efinissons le contexte d’utilisation comme l’ensemble des entit´ es intervenant dans les pr´ erequis de toutes les obligations et restrictions sur le fonctionnement des services propos´ es par l’application. Ces entit´ es ne font en aucun cas partie d’un autre contexte.

Elles sont ind´ ependantes de l’utilisateur et des p´ eriph´ eriques.

2.2.3 Contexte d’ex´ ecution

Dans la plupart des travaux sur la prise en compte du contexte, c’est le contexte d’ex´ ecution qui est le plus souvent cit´ e. Comme le dit [74], lorsqu’on parle de contexte d’ex´ ecution, il s’agit tr` es souvent d’adapter l’application ` a l’´ evolution de l’´ etat des res- sources du syst` eme sur lequel elle s’ex´ ecute. Dans ces ressources nous incluons toutes les propri´ et´ es li´ ees au r´ eseau. Tout comme pour des propri´ et´ es mat´ erielles comme la m´ emoire ou l’´ energie, nous pouvons mesurer le d´ ebit d’un composant ou d’un p´ eriph´ erique et nous pouvons d´ etecter la mobilit´ e. Prenons l’exemple de deux composants A et B reli´ es entre eux par la relation suivante : A produit des donn´ ees consomm´ ees par B. Lorsqu’il n’y a aucun probl` eme r´ eseau, A produit r´ eguli` erement des donn´ ees que B consomme de fa¸con r´ eguli` ere ´ egalement. A un instant donn´ e, B ne re¸ coit plus de donn´ ees de la part de A, il d´ etecte une p´ enurie dont il va informer la plate-forme. S’il y a p´ enurie cela veut dire que le composant A s’est d´ eplac´ e ou qu’il a cess´ e de fonctionner. La plate-forme va alors chercher

`

a joindre le composant A et en cas de r´ eponse, proposer une solution afin de continuer le

service. De la mˆ eme mani` ere, A d´ etecte une saturation de donn´ ees ` a sa sortie, B ne les