Adaptations dynamiques au contexte en informatique ambiante

Adaptations dynamiques au contexte en informatique ambiante

Les défis de l’informatique ambiante

Un système ambiant se trouve dans un environnement et repose sur un ensemble d’entités qui peuvent interagir les unes avec les autres. Une entité peut être un « êtres vivant » comme un utilisateur par exemple, ou un système informatisé. Ces systèmes reposent sur des objets informatisés hétérogènes [46, 44] qui ont une existence physique, par exemple un PDA ou encore un réfrigérateur intelligent. Nous appellerons ces derniers des dispositifs. Ils sont fournis par des constructeurs et, pour la plus grande majorité d’entre eux, ne sont pas prévus pour être modifiables ni physiquement, ni logiciellement. A partir de l’ensemble des dispositifs accessibles il est possible pour une entité de créer de nouvelles applications en faisant interagir les dispositifs les uns avec les autres [48]. Nous appellerons cet ensemble des dispositifs et entités logicielles auxquels un système peut accéder son infrastructure. Ces dispositifs peuvent être mobiles [51, 46], ils peuvent entrer ou quitter à tout instant cette infrastructure. Lorsque c’est le cas, les applications doivent alors s’adapter à ces variations [48]. Cette infrastructure impose alors les contraintes suivantes aux systèmes ambiants : Hétérogénéité : l’ensemble des dispositifs qui compose l’infrastructure d’un système ambiant peut être hétérogène aussi bien en terme de matériel que de communications. Il faut être capable de les faire interagir les uns avec les autres. Multiplicité des entités se trouvant dans l’environnement : Un grand nombre et de nombreuses variantes d’entités et de phénomènes peuvent se trouver dans l’environnement d’un système ambiant et doivent être considérés. Le système ambiant peut alors lui-même prendre de nombreuses formes. Briques logicielles de base non-éditables : les dispositifs fabriqués et commercialisés par des constructeurs ne sont généralement pas prévus pour être modifiés physiquement ni logiciellement. La création de nouvelles fonctionnalités dans un système ambiant ne peut donc pas passer par la modification de ces dispositifs. Mobilité : avec l’apparition des dispositifs et logiciels mobiles, les déconnexions ne sont plus considérées comme des pannes mais comme un mode de fonctionnement normal [94]. En raison de cette mobilité des dispositifs qui composent l’infrastructure d’un système, la topologie de cette dernière est fortement variable. Ajouté au besoin de s’adapter aux variations de leur infrastructure, les systèmes ambiants, dans l’optique de s’insérer de manière transparente dans leur environnement, doivent également prendre en compte ses évolutions et s’y adapter [51]. L’adaptation se définit dans le dictionnaire comme le fait d’« ajuster une chose à une autre » 1 . Dans le domaine du logiciel, on la définit comme : « le processus de modification du système, nécessaire pour permettre un fonctionnement adéquat dans un contexte donné » [145]. On considère qu’une adaptation est nécessaire quand il n’y a plus de correspondance entre l’offre et la demande à une ressource [51]. Dans le cadre de l’informatique ambiante, comme nous l’avons vu précédemment, la forte variabilité de l’environnement et de l’infrastructure d’un système ambiant ont pour conséquence le besoin d’adaptation. Cela peut être pour garantir une bonne continuité de service, ou encore pour faire correspondre au mieux le comportement du système à son environnement. Pour cela, le système doit être sensible aux variations de son environnement, aux variations de son contexte, afin de modifier la façon dont il s’exécute. Il s’agit du moyen pour le système de s’adapter à une situation en restant le moins intrusif possible pour l’utilisateur. La notion de contexte fut utilisée  en informatique, en premier lieu, dans des domaines comme l’intelligence artificielle ou encore la théorie des langages avant de connaître un regain d’intérêt avec l’essor de l’informatique ambiante. Le contexte devient alors une notion centrale pour la plupart des travaux d’informatique ambiante et de nombreuses définitions émergent sans que cela n’aboutisse réellement à un consensus. En 2001, Dey pose la définition du contexte la plus couramment utilisée : « Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves. » [37]. S’adapter au contexte nécessite alors la mise en place d’un cycle de collecte puis d’évaluation de ces informations contextuelles pour la mise en place de réponse à ces changements de contexte. Une autre caractéristique des systèmes ambiants vient alors s’ajouter aux précédentes : Sensibilité au contexte : Un système ambiant se trouve dans un environnement qui est en perpétuelle évolution. Les ressources disponibles, qui peuvent être mobiles, ou encore les phénomènes physiques observés, changent sans cesse et, chacun avec sa propre dynamique. Ces caractéristiques, lorsqu’elles sont combinées les unes avec les autres, sont à l’origine d’un ensemble de challenges et soulèvent les questions que nous aborderons dans cette thèse. Le premier challenge est relatif à la variabilité et l’imprévisibilité du contexte d’un système ambiant. Les multiples dispositifs potentiellement hétérogènes et mobiles qui composent l’infrastructure d’un système ambiant, ainsi que les divers phénomènes perpétuellement changeant pris en compte dans l’environnement, mènent à la conception de systèmes qui doivent être capables de gérer trois axes de variabilité. 

Trois grands axes de variabilité

L’environnement d’un espace ambiant est caractérisé par une grande variabilité [100]. Ces variations s’expriment en particulier selon trois axes. 1. Le premier axe de variabilité concerne les variations de l’ensemble des dispositifs disponibles dans l’infrastructure du système. Nous avons vu, en effet, que les applications d’informatique ambiante reposent sur une infrastructure susceptible d’englober une multitude de dispositifs. Ces derniers peuvent subir des pannes, ne plus être accessibles, ou encore être mobiles. Ils sont alors en mesure d’apparaître ou de disparaître dans cette infrastructure. Il ne s’agit plus d’événements exceptionnels mais normaux dans la vie d’un système ambiant [48]. Par conséquent, l’application qui sera construite au dessus de celle-ci devra varier en fonction des opportunités offertes. 2. Le second axe de variabilité qu’il est nécessaire de prendre en compte pour un système ambiant concerne la haute variabilité de l’environnement d’une application. Par nature, l’environnement est en perpétuel changement [45] ; il est un espace continu dans lequel des phénomènes physiques interviennent et évoluent continuellement. La prise en compte de ces changements se fera via son observation. Les variations s’expriment alors sous la forme de changements de valeurs ou d’états, associées à des modèles physiques ou encore informatiques (par exemple modèle et seuils pour des températures). Afin de mesurer et de raisonner sur ces phénomènes, le système doit posséder ces modèles [38]. 3. Le troisième axe de variabilité porte sur l’ensemble des adaptations, pour des préoccupations diverses, qui doivent être mises en œuvre. En fonction des deux premiers axes de variabilité, c’est-à-dire en fonction de son environnement et de son infrastructure, une application pourra prendre plusieurs configurations. Le mécanisme d’adaptation est l’outil permettant de passer  d’une configuration à une autre. Différentes adaptations peuvent être décrites pour diverses préoccupations et peuvent être réalisées ensembles lorsqu’une nouvelle situation l’exige. Ce dernier axe est fortement dépendant des deux autres, puisqu’il consiste en la réaction à leurs variations. En effet, l’ensemble des configurations atteignables par une application dépendra en parti de l’étendue de la gestion des variations de l’environnement et de l’infrastructure. Plus le système peut gérer de variantes, plus il est susceptible d’avoir à gérer de nombreuses configurations de l’application. L’ensemble des adaptations qui peuvent être mises en œuvre pour passer d’une configuration à une autre peut alors rapidement devenir conséquent et ainsi faire exploser le nombre de combinaisons d’adaptations [49]. Ces trois axes de variabilité soulève une question que nous nous poserons dans ce manuscrit : Comment définir un mécanisme d’adaptation permettant d’exprimer la grande variabilité du système, de son infrastructure, de son environnement, tout en minimisant le nombre d’entités d’adaptation à écrire ? Dans le cycle de sensibilité au contexte, la prise en compte de ces variabilités se fait lors de l’évaluation des informations contextuelles par un mécanisme de décision en vue de mettre en œuvre les réponses adaptées. Ce mécanisme de décision peut alors spécifier, pour l’ensemble de variantes des deux premiers axes, l’ensemble des adaptations qui doivent être réalisées et de quelle manière. Lorsque l’on se trouve dans un environnement dit borné [45], c’est-à-dire impliquant un ensemble limité, parfois même fixe, de dispositifs, et par conséquent permettant une perception limitée du contexte, il peut être envisagé de concevoir un système ambiant en spécifiant toutes les variantes des trois axes précédemment évoqués. L’environnement peut être considéré comme connu a priori. Spécifier toutes ces variantes permet de concevoir des systèmes avec une fiabilité maximale. Malheureusement dans des environnements non bornés [49], qui sont a priori non connus, cela n’est plus possible. En effet, l’ensemble des dispositifs gravitant autour d’un système n’étant alors ni fixe, ni limité, la combinatoire des trois axes de variabilité est susceptible de devenir trop grande pour être spécifiée [49] ou ne peut tout simplement pas l’être. Il est impossible d’en prédire l’ensemble des variations, et, parfois, des variantes peuvent ne pas avoir été anticipées. De la même manière, plusieurs acteurs peuvent déployer de nouvelles adaptations sans se connaître. 1.2.2 Imprévisibilité et combinatoire dans des environnements non bornés A la notion de variabilité vient donc s’ajouter celle d’imprévisibilité. Pour chacun de ces éléments variables, de nombreuses informations peuvent ne pas être prévues à la conception et doivent être gérées de manière non-anticipée. La notion d’imprévisibilité vient donc étendre celle de variabilité sur ces trois axes précédemment définis. 1. En raison de la mobilité ou de pannes, il n’est pas possible de connaître, parmi les dispositifs que l’on sait utiliser, lesquels sont disponibles à un instant donné. Si nous souhaitons utiliser des dispositifs dans un but particulier il faut connaître les capacités qu’ils offrent ; ce point ne peut pas être sujet à imprévisibilité. Par contre, on ne peut pas formuler l’hypothèse de leur disponibilité. 2. On doit connaître les phénomènes que l’on mesure dans l’environnement et comment les analyser, mais on ne sait pas a priori comment ces derniers vont évoluer. Par exemple, il est possible d’observer le comportement humain mais il est impossible de le prédire avec certitude. D’autre part, le système peut accéder aux données sur son environnement grâce à son infrastructure, sa perception en est donc limitée aux capacités offertes par cette infrastructure, ces données ne sont alors que partiellement accessible [45]. Cette perception évolue en fonction de la disponibilité des dispositifs et donc de manière imprévisible. Enfin, l’imprévisibilité de l’environnement peut parfois mener à des situations dans lesquelles, le résultat de l’interprétation d’informations contextuelles est incertain. 3. Le système de prise en compte du contexte connaît donc des reconfigurations pour un but mais ne sait pas, quand et avec qui elles doivent être composées. Dans les deux cas précédents, l’imprévisibilité vient pour partie du fait que le système n’a pas le contrôle sur les variations ; elles lui sont imposées. Ce n’est pas le cas de l’imprévisibilité dans le cadre du troisième axe de variabilité, c’est-à-dire par rapport à l’ensemble des adaptations à mettre en œuvre à un instant donné. L’imprévisibilité, ici, est héritée de celle des deux autres axes. Le passage d’une configuration du système à une autre est réalisé par des adaptations. Une adaptation étant réalisée pour un but particulier, plusieurs adaptations peuvent potentiellement intervenir lors d’une même reconfiguration. Ainsi, toutes les configurations ne peuvent pas être prévues a priori puisque reposant sur des niveaux imprévisibles, la réaction à des événements imprévus est elle-même par définition imprévue. Nous avons vu que pour chacun de ces axes, différentes informations doivent être connues à l’avance. Cependant l’ensemble de ces informations ne peut être exhaustivement anticipé à la conception. Lorsque l’on souhaite modifier cet ensemble d’informations (ajouter des modèles de phénomènes physiques, des descriptions de dispositifs, des adaptations), cela doit pouvoir être réalisé à l’exécution sans interrompre l’application. On parle d’extensibilité. Mais en raison de la combinatoire ainsi que de la variabilité de ces éléments connus, il faut être capable de rajouter ou de supprimer ces informations sans tenir compte de celles existantes. Des mécanismes de décision plus ou moins aptes à prendre en compte ces trois axes d’imprévisibilité existent et sont adaptés aux différents types de systèmes ambiants et d’environnements. Les environnements les plus bornés ne nécessitent pas de prendre en compte l’imprévisibilité contrairement aux environnements ouverts. Les questions que nous nous posons sont alors : Comment associer aux différents mécanismes de décision un mécanisme d’adaptation que tous peuvent utiliser, c’est-à-dire permettant de déployer des adaptations sans se préoccuper de celles existantes ou de les combiner explicitement ? Comment permettre le déclenchement des adaptations indépendamment les unes des autres ? Nous avons vu que l’environnement et l’infrastructure d’un système ambiant varient fortement et d’une manière qui ne peut pas être anticipée à la conception. Ces variations évoluent en respectant des dynamiques qui leurs sont propres. Les mécanismes de sensibilité au contexte, qui prennent en considération ces variations, doivent être capables de respecter au mieux les dynamiques d’évolution des phénomènes variables auxquels ils s’intéressent.

Dynamicité et multi-dynamicité

Les mécanismes de sensibilité au contexte jouent un rôle de médiateur entre les applications et leur environnement [100]. Par conséquent, lorsqu’ils mettent en œuvre une adaptation, ils doivent respecter deux grandes dynamiques d’évolution : celle de l’application à adapter et celle de leur environnement. En effet, l’environnement évolue perpétuellement et le système doit répondre à ces sollicitations mais aussi à celles de l’application (et bien entendu de l’utilisateur). Si l’environnement peut être vu comme une unique entité évoluant suivant une dynamique, il apparaît en réalité que celui-ci peut varier selon divers axes, qu’il s’agisse de phénomènes physiques ou de l’infrastructure sur laquelle repose l’application. Ainsi des phénomènes physiques comme la luminosité d’une pièce ou encore le nombre d’utilisateurs qui se trouvent à l’intérieur, évoluent selon leurs propres dynamiques. Un système ambiant doit donc être capable de respecter du mieux qu’il peut plusieurs dynamiques d’évolution. Ainsi, en raison du besoin de sensibilité au contexte et de la mobilité des dispositifs composant l’infrastructure d’une application, le mécanisme de prise en compte de l’environnement, externe à l’application, doit respecter les dynamiques présentées précédemment. Plus particulièrement, il doit, a minima, respecter une dynamique d’évolution : celle de l’infrastructure de l’application. C’est seulement grâce aux dispositifs se trouvant dans cette infrastructure que l’application peut être construite et intégrer de nouvelles fonctionnalités. Il faudra alors s’adapter à toutes ces différentes variations du contexte et de l’infrastructure. Pour ce faire, plusieurs mécanismes de sensibilité au contexte et par conséquent de mécanismes de décision peuvent être utilisés. Les questions que nous nous posons sont alors : Comment organiser ces mécanismes de décision ? Comment prendre en compte les multiples dynamiques d’évolution de l’environnement ? Comment prendre en compte ces multiples évolutions en interrompant le moins possible le système ambiant ? Afin de pouvoir respecter ces dynamiques, la fréquence des adaptations autorisées par le système doit être adaptée. L’application doit fournir des fonctionnalités qui sont cohérentes avec son environnement et ne pas se trouver dans un état instable ou stoppé en permanence à cause de réadaptations continues. 

Des temps de réponse adaptés et maîtrisés

Dans ce cadre, la fréquence à laquelle un mécanisme d’adaptation peut enchaîner les adaptations est une préoccupation majeure en informatique ambiante. En effet, les contraintes précédemment évoquées mènent à la mise en place de systèmes complexes. Nous allons voir que la pertinence de l’adaptation ne doit pas seulement être logique mais aussi temporelle. Considérons que les applications adaptables sont toujours dans un des trois états présentés en FIGURE 2.12. FIGURE 1.1 – Les trois états d’une application adaptable. L’état (1) est l’état d’exécution normale de l’application pour lequel l’application est censée être consistante avec son environnement. Cela signifie que le comportement de l’application repose sur ce qui est pertinent dans son environnement et qu’il s’agit bien du comportement souhaité pour cette situation. Lorsqu’un changement intervient dans le contexte de l’application et avant d’être adaptée, celle-ci se trouve alors dans un état (2) dans lequel elle n’est plus consistante avec l’environnement. 

SYNTHÈSE ET OBJECTIF 

Une fois l’adaptation démarrée, elle se trouve dans un état instable (3) et peut être tout ou en partie indisponible. Elle n’est également plus consistante avec son environnement. Pendant que l’application est dans l’état (2) plusieurs nouvelles modifications de l’environnement peuvent avoir lieu. Si un de ces changements intervient pendant que l’application est dans l’état (3), alors celle-ci retombe dans l’état (2). Le temps passé dans les états (2) et (3) doit être géré de manière à correspondre au mieux aux deux types de dynamiques : (a) celle de l’environnement et (b) celle de l’application. Dans le premier cas, la dynamique de l’adaptation doit être compatible avec celle des changements intervenants dans l’environnement (a). Pour cela, il est essentiel de considérer les cas suivants : • Il ne faut pas laisser l’application trop longtemps indisponible (3) ou dans l’état qui ne convient plus (2). Par exemple, si des dispositifs deviennent indisponibles, il ne faut pas que l’application continue à utiliser les fonctionnalités qu’ils proposent ou encore que l’utilisateur pense encore pouvoir les utiliser. La latence entre deux adaptations doit être suffisamment faible pour permettre d’adapter l’application avec une fréquence au plus proche de celle de l’environnement. • D’autre part, une trop forte latence entraînerait le risque de sombrer dans un système instable qui consisterait à ne jamais atteindre l’état suivant (1) avant une nouvelle évolution de l’environnement. L’application sombrerait alors dans une forme d’indéterminisme dont elle ne saurait sortir, c’est-à-dire ne plus connaître l’état de l’application et comment elle va être adaptée, ceci est mis en avant par le cycle entre les états (2) et (3). Dans le second cas (b), la dynamique de l’adaptation doit être compatible avec les opérations de l’application et/ou de l’utilisateur. Pour cela, il est essentiel de prendre en compte les points suivants : • Le système ne doit pas passer de l’état (1) à (3) trop fréquemment et produire une application instable. L’utilisateur serait alors dans l’incapacité d’utiliser l’application, et celle-ci pourrait alors passer plus de temps dans l’état (3) que dans des états stables. • La latence du système ne doit pas être trop grande au risque de détourner l’utilisateur, ou qu’il n’utilise pas le système de façon prévue [146]. Le déclenchement de l’adaptation dépend du mécanisme d’observation du contexte, il est donc également nécessaire que ce dernier offre une faible latence. Pour ce faire, ces mécanismes peuvent s’exprimer en parallèle et, pour que l’environnement impose son rythme, ils peuvent reposer sur une approche de type push, c’est-à-dire ne pas requérir des informations sur l’environnement mais recevoir les informations de l’environnement. La problématique des temps de réponse, qui doivent être maitrisés et adaptés, sera présente tout au long de ce manuscrit. A partir de l’ensemble des caractéristiques, défis et questions que venons de soulever et qui seront synthétisés dans la section suivante, nous définirons les objectifs de cette thèse.