Intelligence ambiante : étude d’une approche par auto ... · adaptatifs en intelligence ambiante en utilisant les concepts d’agents coopératifs et de mécanismes d’auto-organisation

Intelligence ambiante : étude d’une approche parauto-organisation coopérative et mise en œuvre d’une

plate-forme de conception générique

Rapport de Master 2 RechercheInteraction Coopération et Systèmes Complexes (ICSC)

à l’Université Paul Sabatier (UPS) – Toulouse III

9 juin 2008

Zied SELLAMI

Laboratoire d’accueil : Institut de Recherche en Informatique de Toulouse (IRIT)Directeur de recherche : Marie-Pierre GLEIZES

Responsable de stage : Jean-Pierre GEORGÉEquipe d’accueil : Systèmes Mutli-Agents Coopératifs (SMAC)

Mots-clés : Intelligence ambiante, systèmes multi-agents, plate-forme de conception, auto-organisation,coopération

Résumé : L’intelligence ambiante est un domaine en plein essor. Les progrès des technologies et du dé-veloppement nous entraînent à l’ère de la miniaturisation, des applications embarquées et réparties etdu réseau omniprésent. L’homme, conscient ou pas, est entouré d’un ensemble d’objets communicants.Cela dit, doter ces objets de "petits systèmes" dont le comportement les rend autonomes et intelligentsafin d’exploiter au mieux cet environnement et satisfaire les besoins des utilisateurs relève du défi. Unesolution particulièrement pertinente consiste à fournir à chaque "petit système" des comportements leurpermettant de s’auto-organiser pour créer des "systèmes de systèmes" et ainsi de s’adapter collective-ment à leur environnement.Dans cette étude nous proposons des solutions pour la conception de systèmes complexes adaptatifsen intelligence ambiante en se basant sur les concepts d’agents coopératifs et de mécanismes d’auto-organisation. Conjointement, une étude de faisabilité d’une plate-forme de conception d’applicationsen intelligence ambiante est réalisée.

Table des matières

Introduction 1

1 Définition et contexte 31.1 Intelligence ambiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Entre intelligence ambiante et informatique diffuse . . . . . . . . . . . . . . . . . . 31.1.2 Un premier domaine d’application : la domotique . . . . . . . . . . . . . . . . . . . 5

1.2 Systèmes multi-agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.2 Environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.3 Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.4 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Auto-organisation dans les SMA et émergence . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.1 Émergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.2 Auto-organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 La coopération comme critère d’auto-organisation : la théorie des AMAS . . . . . . . . . . 81.4.1 La notion de coopération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4.2 Adéquation fonctionnelle des AMAS . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4.3 Processus d’apprentissage par auto-organisation . . . . . . . . . . . . . . . . . . . . 81.4.4 Situations Non Coopératives (SNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.5 Méthode ADELFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5.1 JAVACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5.2 Make Agents Yourself (MAY) : un générateur d’API dédiés . . . . . . . . . . . . . . 121.5.3 µADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 État de l’art 152.1 Travaux SMA en intelligence ambiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Approche organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2 Approche interactionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3 Approche par coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.4 Approche par auto-adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Plates-formes de conception d’applications en intelligence ambiante . . . . . . . . . . . . 212.2.1 GadgetWare Architectural Style (GAS) . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.2 WComp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iii

Table des matières

3 E-AmI : agents ambiants, comportements et mécanisme d’auto-organisation 253.1 Agent ambiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Capacités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 Agent ambiant vs. agent coopératif traditionnel . . . . . . . . . . . . . . . . . . . . 28

3.2 Les comportements coopératifs d’un agent ambiant . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Comportement de présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.2 Comportement de survie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.3 Comportement coopératif terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.4 Comportement de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.5 Comportement d’aider le plus critique . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.6 Comportement de relais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Mécanisme d’auto-organisation : la résolution des situations non coopératives . . . . . . . 313.3.1 Difficulté de perception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2 Difficulté de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.3 Difficulté d’action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4 Modèle d’un agent ambiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.1 Niveau opératoire de l’agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.2 Niveau fonctionnel de l’agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 E-AmI : étude d’une plate-forme de conception générique 394.1 Fonctionnalités et outils de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1 Description du scénario envisagé pour l’application . . . . . . . . . . . . . . . . . . 404.1.2 Inventaire de l’équipement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.3 Modélisation des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1.4 Implémentation des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Notre apport à la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Analyse de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5 Application et analyse 475.1 Conception et réalisation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1.1 Description du scénario envisagé pour l’application . . . . . . . . . . . . . . . . . . 475.1.2 Inventaire de l’équipement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.1.3 Modélisation des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.1.4 Implémentation des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Conclusion 55

Bibliographie 57

iv

Introduction

Les progrès considérables des technologies de l’information et de la communication (systèmes em-

barqués, micro-électronique, réseaux de capteurs, réseaux ad-hoc, middleware, etc.) ont changé notre

vision de l’informatique et de l’information. Nous sommes aujourd’hui à l’ère de la miniaturisation

et du réseau omniprésent. L’homme, sans le savoir, est entouré d’un ensemble d’objets communicants.

Dans un futur proche, notre environnement (maison, lieu de travail, mais aussi en ville, en déplacement)

possédera un réseau distribué d’appareils électroniques nous fournissant des moyens d’informations,

de communication, de travail, de sécurité et de loisir. Les objets que nous manipulons ne seront plus

inertes, mais ils seront capables d’avoir des comportements appropriés et de s’adapter à chacun de

nous, à nos actes, à ce qui nous entoure et en particulier aux autres appareils à portée. Ces appareils

communicants, pourront également, au-delà de leurs savoir-faire locaux, compter sur ceux d’autres ap-

pareils formant ainsi un système appelé système ambiant. Bien entendu, cet environnement ne devrait pas

être perçu comme intrusif ou agressif, et devrait respecter les besoins de sécurité et de confidentialité de

l’individu. Ce type d’environnement est désigné sous le terme d’environnement d’intelligence ambiante.

Le défi principal résulte de la distribution des objets, de l’hétérogénéité des appareils électroniques,

de la dynamique de l’environnement et des changements fréquents des besoins de l’utilisateur. Conce-

voir et fournir un système capable de se construire à partir de petits systèmes autonomes ayant des

comportements leur permettant de s’auto-organiser et de s’adapter à leur environnement paraît donc

une solution particulièrement pertinente.

L’objectif de mon stage est la proposition de solutions pour la conception de systèmes complexes

adaptatifs en intelligence ambiante en utilisant les concepts d’agents coopératifs et de mécanismes

d’auto-organisation. Nous proposons ainsi, une définition et une modélisation d’agents ambiants et

une étude de faisabilité d’un premier prototype de plate-forme pour l’intelligence ambiante.

Ce rapport s’organise autour de 5 chapitres.

– Le premier chapitre présente le domaine de l’intelligence ambiante et le contexte de travail à savoir

les Systèmes Multi-Agents (SMA), la théorie des AMAS, ainsi que les outils manipulés.

– L’état de l’art est décrit dans le deuxième chapitre qui se divise en deux parties : dans la pre-

mière, une étude des travaux en SMA qui se sont intéressés à l’intelligence ambiante est survolée ;

dans la deuxième partie, sont exposées deux plates-formes de développement d’applications en

intelligence ambiante.

1

Introduction

– Le troisième chapitre présente une étude sur les agents ambiants et un premier modèle de l’agent

ambiant.

– Le quatrième chapitre propose une étude sur la réalisation d’une plate-forme de conception d’ap-

plications en intelligence ambiante.

– Enfin, dans le cinquième chapitre, une application réalisée avec les outils manipulés et le modèle

d’agent ambiant proposé est détaillée.

2

1 Définition et contexte

1.1 Intelligence ambiante

La recherche en intelligence ambiante (ambient intelligence ou AmI) est prospère. Elle se situe à la

jonction de plusieurs domaines tels que l’architecture (nanotechnologie, électronique, etc.), les aspects

logiciels (intelligence artificielle, intelligence artificielle distibuée, systèmes multi-agents, génie logiciel,

etc.), les réseaux et télécommunications, les Interactions Homme-Machine (Conception d’IHM, traite-

ment automatique de la langue, aspect sociologique, etc.). Afin de donner une vision plus concrète de

ce que nous appelons intelligence ambiante, nous exposons dans ce premier chapitre, certaines notions

relatives au domaine. Une définition de l’intelligence ambiante sera proposée ainsi qu’un exemple de

son utilisation.

1.1.1 Entre intelligence ambiante et informatique diffuse

Une grande variété d’expressions décrit l’ambiant en informatique. Nous pouvons ainsi rencontrer

dans la littérature les termes pervasive, ubiquitous, ambient computing, informatique diffuse et intelligence

ambiante (ou encore ambient intelligence). Nous allons donner une définition de chacun de ces termes

afin de souligner leurs différences.

Informatique diffuse

L’informatique diffuse est connue aussi sous le nom d’informatique pervasive, de pervasive compu-

ting, d’ubiquitous computing et ambient computing.

– Pervasive est synonyme de diffus et d’omniprésent ce qui signifie aller de toutes parts, s’insinuer,

se propager, s’étendre, se répandre, envahir ;

– Ubiquitous, ou encore ubiquitaire est la capacité d’être présent en plusieurs lieux simultanément ;

– Ambient, signifie ce qui constitue l’environnement où l’on vit, nous entoure de toutes parts. Il est

aussi synonyme d’environnant.

Le concept d’informatique diffuse a été établi en 1988 par Mark Weiser (centre de recherche Xerox).

Dans [Weiser, 1993b] [Weiser, 1993a], Weiser a rapporté les fondements de ce concept. Il a mis l’accent

sur l’aspect matériel et réseau nécessaire pour mettre en place l’informatique diffuse. Il a envisagé un

3

Chapitre 1. Définition et contexte

environnement dans lequel des ordinateurs sont embarqués dans les murs, dans les objets du quotidien,

etc. et pouvaient communiquer grâce à un réseau sans fil. Une personne présente dans cet environne-

ment pourrait interagir avec des centaines d’ordinateurs à la fois. De manière générale, les travaux du

domaine s’inscrivent dans une tendance vers l’informatisation, la connexion en réseau, la miniaturisa-

tion des dispositifs électroniques et leur intégration dans n’importe quel objet du quotidien. De ce fait,

l’accès aux informations devient facile.

Ainsi, nous pouvons définir l’informatique diffuse comme un ensemble d’objets électroniques (ou entités per-

vasives) intégrés dans l’environnement physique et qui, au travers des moyens de communication et de mise en

réseau, rendent un ensemble d’informations accessibles pour une ou plusieurs personnes quelque soit l’endroit où

elle(s) se trouve(nt).

Intelligence ambiante

Le concept d’intelligence ambiante, utilisé de façon éparse dans la littérature, a été pleinement décrit

et soutenu par l’ISTAG (Information Society Technologies Advisory Group) de l’Union Européenne [ISTAG,

2001] [ISTAG, 2003]. Il a supposé un déplacement d’une vision centrée sur des machines multi-fonctions

vers un ensemble d’appareils variés, distribués dans notre environnement et accessible par des inter-

faces intuitives et adaptatives. Ce concept repose sur un certain nombre de technologies clés 1 :

– Un matériel informatique non intrusif.

– Une infrastructure de communication mobile et fixe.

– Des réseaux dynamiques et massivement distribués d’appareils électroniques.

– Des interfaces homme-machine naturelles.

– Une technologie fiable et sécurisée.

L’intelligence ambiante, telle qu’elle a été décrite par l’ISTAG, signifie informatique diffuse. Le terme

"intelligent" est restreint à la capacité des appareils à s’adapter au type de service fourni dans leur envi-

ronnement. Parallèlement, le système ambiant continue à fournir le ou les services pour lequel il a été

conçu. Or, même dans un environnement aussi simple qu’une chambre dans une maison par exemple,

les besoins des utilisateurs ne peuvent pas être totalement définis [Georgé et al., 2007]. Ils peuvent même

changer et évoluer. Un environnement d’intelligence ambiante doit être, dans ce cas, capable de s’adap-

ter mais aussi de faire émerger de nouvelles fonctionnalités. L’intelligence ambiante est ainsi rendue

possible grâce, en premier lieu, à l’existence d’un environnement d’informatique diffuse intégrant des

systèmes ambiants. Mais l’intelligence ambiante est au final plus que de l’informatique diffuse. C’est

un résultat ou une réponse adéquate du système ambiant face à un changement de son environnement.

Ce changement peut être la disparition ou l’apparition d’un objet, la modification du comportement de

l’utilisateur ou même de ses besoins.

1. http : //en.wikipedia.org/wiki/Ambient_intelligence

4

1.2. Systèmes multi-agents

Ainsi, nous pouvons définir l’intelligence ambiante comme le résultat ou la réponse adéquate d’un système am-

biant réparti dans les objets et les appareils électroniques face à un changement de son environnement (apparition

ou disparition d’un objet, modification du comportement de l’utilisateur ou de ses besoins, etc.).

1.1.2 Un premier domaine d’application : la domotique

Présentation

La domotique peut être vue comme l’ensemble des techniques et technologies électroniques, informatiques

et des télécommunications permettant d’automatiser et d’améliorer les tâches au sein d’une maison. Elle est l’un

des domaines privilégiés de l’intelligence ambiante. Les nombreuses recherches effectuées donnent des

exemples de ce que seront nos maisons du futur. Nous citons ici trois exemples :

– HomeLab de Philips : la maison intelligente de Philips 2 contient plusieurs gadgets futuristes tels

qu’un jukebox capable de retrouver à partir d’un air chanté par une personne la chanson équiva-

lente. Ou encore, un miroir high-tech intégrant un écran capable de s’activer en présence d’une

personne.

– Aware Home de Georgia Tech : développée par l’institut américaine de technologie Georgia Tech en

1999 [Kidd et al., 1999]. Ce prototype de maison futuriste a été destiné à l’étude des technologies

de l’intelligence ambiante tels que le Digital Family Portrait (un cadre numérique qui change les

informations affichées en fonction des personnes présentes dans la maison) ou le Memory mirror

(un système qui permet de sauvegarder l’historique de l’activité dans la maison).

– PlaceLab du MIT : c’est à la fois une maison intelligente et un laboratoire de recherche qui étudie

l’intégration des nouvelles technologies et leurs acceptations par les personnes 3.

Analyse

La domotique s’intéresse en grande partie aux technologies nécessaires pour des environnements

d’intelligence ambiante à domicile. Les projets de maisons intelligentes offrent de nouveaux appareils

et gadgets sophistiqués. Dans ce cadre, les applications se résument en un ensemble de services ad-hoc

que les utilisateurs peuvent personnaliser selon leurs besoins tels que l’activation des volets, des fenêtres

ou l’allumage automatique des lumières.

1.2 Systèmes multi-agents

Les systèmes multi-agents sont nés à la fin des années 70 et au début des années 80, à partir de l’idée

de distribuer les connaissances et le contrôle dans les systèmes d’intelligence artificielle. Cette idée est

apparue d’une part devant le besoin de faire face à la complexité croissante de ces systèmes et d’autre

2. http : //www.research.philips.com/technologies/misc/homelab/downloads/homelab_365.pd f3. http : //architecture.mit.edu/house_n/documents/PlaceLab.pd f

5


part suite à l’apparition des modèles et des machines parallèles, rendant possible la mise en œuvre

opérationnelle de la distribution.

Un système multi-agent est vu comme un ensemble d’agents logiciels autonomes plongés au sein d’un

même environnement, qui interagissent dans le but de résoudre une tâche commune.

Les systèmes multi-agents peuvent être observés selon deux points de vue :

1. Le macro-niveau qui correspond au point de vue d’un observateur extérieur. Il considère le système

dans son ensemble et ignore tout mécanisme interne.

2. Le micro-niveau qui correspond au point de vue d’un observateur considérant le système au niveau

des agents. A ce niveau, on peut observer le comportement des agents ainsi que leurs interactions.

1.2.1 Agent

L’agent est le composant principal des systèmes multi-agents. Il s’agit d’une entité virtuelle ou réelle

qui est capable d’agir sur son environnement, qui possède des moyens de perception et de représentation partielle

de son environnement, qui est capable de communiquer avec d’autres agents et qui est autonome dans sa prise

de décision [Ferber, 1995]. Un agent logiciel fonctionne selon le cycle Perception, Décision, Action. Tout

d’abord, l’agent perçoit son environnement, ensuite il décide l’action qu’il va effectuer en fonction de

ses perceptions, de ses connaissances et de ses buts ; enfin il exécute l’action choisie pour atteindre son

objectif ou s’en rapprocher.

1.2.2 Environnement

La notion d’environnement est à considérer selon différents points de vue. Pour un système multi-

agent, c’est l’ensemble des entités extérieures au système. C’est aussi tout ce qui est extérieur à l’agent (not-

tament les autres agents du système), lorsqu’il s’agit d’un agent.

1.2.3 Interaction

L’interaction peut être définie comme la mise en relation dynamique de deux ou plusieurs agents

par le biais d’un ensemble d’actions réciproques. L’interaction peut être directe, via l’envoi de messages

à un ou plusieurs destinataires, ou indirecte, via un dépôt d’informations dans l’environnement.

1.2.4 Organisation

L’organisation désigne à la fois la manière dont un ensemble est constitué en vue de son fonctionne-

ment ainsi que l’action d’organiser. Dans le premier sens on se réfère à un ordre, à une structure ; dans

le second, il s’agit d’un processus, d’une dynamique. En général dans les systèmes multi-agents, l’or-

ganisation correspond à la structure organisationnelle du système ou à son architecture. Elle est définie

par les liens d’échanges d’information et de requêtes entre les agents du système.

6

1.3. Auto-organisation dans les SMA et émergence

1.3 Auto-organisation dans les SMA et émergence

1.3.1 Émergence

Le concept d’émergence est souvent invoqué lorsque qu’il y a apparition de nouveautés (propriétés,

structures, formes ou fonctions) et qu’il est difficile, voire impossible, de corréler ces phénomènes à par-

tir des éléments qui ont contribué à sa réalisation. Généralement, de tels phénomènes s’observent dans

les systèmes naturels complexes et ont fait l’objet de nombreuses réflexions (en physique, en chimie,

en biologie, etc.). Il reste cependant difficile de qualifier la caractéristique émergente d’un phénomène,

mais nous pouvons nous appuyer sur les critères suivants [Georgé, 2004] :

1. le phénomène est ostensible, c’est-à-dire qu’il s’impose à l’observateur au macro-niveau ;

2. le phénomène est radicalement nouveau, c’est-à-dire qu’il ne peut pas être expliqué par le micro-

niveau ;

3. le phénomène est cohérent et corrélé, c’est-à-dire qu’il a une identité propre mais liée aux parties du

micro-niveau ;

4. le phénomène crée une dynamique particulière, c’est-à-dire qu’il n’est pas prédéfini, il s’auto-crée et

s’auto-maintient.

L’émergence peut être constatée et donc utilisée dans les systèmes artificiels. En effet, nous avons

vu précédemment q’un système multi-agent est un ensemble d’agents en interaction situés dans un

même environnement. De ces interactions peuvent émerger différents phénomènes tel que l’émergence

de structure, l’émergence de comportements ou l’émergence de propriétés. En utilisant ce phénomène

d’émergence, il devient possible de faire face aux problèmes complexes. Ainsi, au lieu de penser en-

tièrement une solution (souvent compliquée, limitée ou même probablement impossible) pour de tels

problèmes, il "suffit" de se concentrer sur l’activité des parties constituantes du problème pour que cette

solution émerge.

1.3.2 Auto-organisation

Le mot "auto" dans auto-organisation fait référence à un mécanisme ou un processus qui permet

à un système de changer son organisation pendant son exécution et sans contrôle explicite externe

[Di Marzo Serugendo et al., 2005], c’est-à-dire qu’il est initié et réalisé par le système lui-même. Face

à un environnement dynamique, ouvert et changeant, un système multi-agent s’auto-organise pour s’y

adapter. Cela se traduit par un changement de l’organisation entre les agents au cours de l’exécution du

système. L’auto-organisation est un moyen qui permet à un système de faire émerger dynamiquement

sa fonctionnalité en s’adaptant aux changements de son environnement.

7


1.4 La coopération comme critère d’auto-organisation : la théorie des AMAS

Après avoir présenté les notions générales des systèmes multi-agents, nous allons présenter la théo-

rie des AMAS (AMAS pour Adaptative Multi-Agents Systems) [Glize, 2001]. Nous présentons aussi

dans cette partie, la méthodologie de conception ADELFE (ADELFE pour Atelier de DévELoppement

de Logiciels à Fonctionnalité Emergente)[Picard, 2004][Gleizes, 2004], guide dans l’utilisation de la

théorie AMAS pour la résolution de problèmes.

1.4.1 La notion de coopération

Afin d’atteindre un objectif local ou un objectif global, un agent est souvent amené à coopérer car il

n’a pas les compétences suffisantes ou manque de ressources. La coopération est une attitude sociale qui

consiste pour un individu à vouloir aider son proche. Par exemple, considérant un collectif de robots

qui essayent de déplacer un grand cube. Chaque robot doit se placer à un côté du cube. A chaque

instant, il doit s’assurer que son intervention contribue à faire avancer l’objet tout en vérifiant qu’il ne

contrevient pas aux contributions des autres. Selon la théorie des AMAS, si tous les agents d’un système

sont pleinement coopératifs (c’est-à-dire que toute situation pouvant être qualifiée de non-coopérative a

pu être résorbée), alors le système est fonctionnellement adéquat et donc adapté à son environnement.

1.4.2 Adéquation fonctionnelle des AMAS

L’adéquation fonctionnelle d’un système est un jugement effectué par un observateur sur la perti-

nence de son activité dans l’environnement. La théorie des AMAS se base sur le théorème suivant :

Théorème. Pour tout système fonctionnellement adéquat, il existe au moins un système à milieu intérieur

coopératif qui réalise une fonction équivalente dans le même environnement.

Ce théorème signifie que parmi l’ensemble des systèmes pouvant résoudre un problème donné, il en

existe au moins un à milieu intérieur coopératif, c’est-à-dire, dépourvu de situations non-coopératives (cf.

1.4.4 Situations Non Coopératives (SNC)) qui est capable de résoudre ce problème. Ce résultat permet

de ne s’intéresser qu’à des systèmes très particuliers (à milieu intérieur coopératif) pour obtenir des

systèmes fonctionnellement adéquats dans un environnement donné.

1.4.3 Processus d’apprentissage par auto-organisation

L’auto-organisation permet de faire émerger la fonction globale d’un système. Cette fonctionnalité

est donc dépendante de l’organisation des parties de ce système. Plus formellement, la fonction globale

fs d’un système S est obtenue par combinaison des fonctions partielles fpi assurées par les parties Pi de

S. Si l’on prend Θ comme opérateur de combinaison des fonctions partielles, on a alors : fs= fp1 Θ fp2

Θ ... Θ fpn. Comme généralement fp1 Θ fp2 6= fp2 Θ fp1, le fait de transformer l’organisation, conduit

à changer la combinaison des fonctions partielles et donc à modifier la fonction globale fs, devenant

8

1.4. La coopération comme critère d’auto-organisation : la théorie des AMAS

elle-même un moyen d’adapter le système à l’environnement. Sur la Figure 1.1, Θ est illustré par les

doubles flèches courbées.

FIGURE 1.1 — Adaptation par auto-organisation d’un système en interaction

dynamique avec l’environnement

Le processus d’apprentissage par auto-organisation consiste alors à donner à chaque partie du sys-

tème la faculté de modifier de façon autonome ses liens avec les autres parties de façon à faire tendre

la globalité du système vers l’adéquation fonctionnelle. Ce phénomène de modification se produit lors-

qu’un agent, en fonction de ses perceptions locales de son environnement, juge qu’il est dans une situa-

tion non-coopérative et opère donc pour revenir dans une situation coopérative.

1.4.4 Situations Non Coopératives (SNC)

Dans la théorie des AMAS, un agent autonome considère qu’il a trouvé la bonne place au sein de

l’organisation s’il interagit coopérativement avec autrui ; dans le cas contraire, on dit que l’agent est

dans une situation non-coopérative. Il devra ainsi agir pour chercher une place plus adaptée. Les condi-

tions de non coopération amenant au processus de réorganisation sont définies de la manière suivante

[Georgé, 2004] :

NON COOPERATION = NCPERCEPTION ∨ NCDECISION ∨ NCACTION

Un agent peut être dans trois SNC différentes, ayant chacune des interprétations différentes :

– Non Coopération de Perception (NCPERCEPTION) : cette situation survient si l’agent perçoit un

signal et ne le comprend pas, dans ce cas on parle d’incompréhension. L’agent peut aussi attribuer

plusieurs interprétations à un signal, on parle alors d’ambiguïté.

– Non Coopération de Décision (NCDECISION) : cette situation survient si l’agent est incapable d’ex-

ploiter l’information reçue, dans ce cas on parle d’incompétence. Dans le cas où le signal reçu est

connu ou inutile pour l’agent on parle d’improductivité.

– Non Coopération d’Action (NCACTION) : cette situation survient si l’agent croit que son action et

celle d’un autre agent vont aboutir au même résultat, c’est la concurrence. L’agent peut aussi croire

9


que son action et celle d’un autre agent sont incompatibles, dans ce cas c’est un conflit. Enfin,

l’agent peut croire que son action n’aura aucun nouvel effet sur son environnement, il s’agit là

d’une situation d’inutilité.

Pour être coopératif, un agent est spécifié de manière à ce qu’il essaye d’atteindre son objectif local

tout en gardant des interactions coopératives avec les autres. Avant chaque action, il cherche s’il existe

des SNC et tente de les éliminer pour revenir à un état coopératif. Un tel agent dans la théorie AMAS est

constitué de différents modules représentant ses capacités de perception, d’action et de raisonnement

[Picard, 2004] :

FIGURE 1.2 — Composant d’un agent AMAS

Les modules de Perception et d’Action permettent à l’agent de percevoir et d’agir sur son environne-

ment. Le module de Représentations permet à l’agent d’avoir une représentation de lui-même, des autres

agents et du monde. Le module de Compétences contient le savoir-faire de l’agent sur un domaine par-

ticulier lui permettant de réaliser sa fonction partielle. Le module Aptitudes correspond aux capacités

de l’agent pour raisonner sur ses représentations et ses compétences. Enfin, le module de Coopération

permet à l’agent de détecter et de traiter les SNC que l’agent pourrait rencontrer (voir Figure. 1.2).

1.4.5 Méthode ADELFE

Concevoir des logiciels capables de s’adapter à un environnement fortement dynamique impose

une méthode de conception rigoureuse qui se distingue de l’approche globale-descendante habituelle.

La méthode ADELFE 4 [Bernon et al., 2002][Picard, 2004][Gleizes, 2004] permet de guider le développeur

tout au long de la conception d’un système multi-agent adaptatif conforme à la théorie AMAS. Cette

méthode comporte les éléments suivants :

– Un processus de développement orienté agent qui regroupe cinq définitions de travaux : les besoins

préliminaires, les besoins finaux, l’analyse, la conception et le développement. Ces travaux s’in-

tègrent dans le RUP (Rational Unified Process). Chaque ensemble de travaux est défini en utilisant

la notation issue du SPEM (Software Process Engineering Metamodel) ;

4. http : //www.irit. f r/ADELFE/

10

1.5. Outils

– Des langages de modélisations : UML et AUML ;

– Un outil (OpenTool) qui met en œuvre les notations UML (Unified Modeling Language) et AUML

(Agent Unified Modeling Language) ;

– Un outil d’aide à la décision permettant de savoir si l’approche basée sur la théorie AMAS est

nécessaire pour concevoir une application particulière ;

– Un outil interactif pour appliquer le processus de conception à une application, en faisant appel

notamment aux outils précédents ;

– Une bibliothèque de composants.

1.5 Outils

Afin de concevoir et d’implémenter des agents d’intelligence ambiante, leurs mécanismes de coopé-

ration et d’adaptation nous avons manipulés les trois outils suivants :

– JAVACT : un intergiciel Java pour les agents mobiles adaptatifs ;

– MAY : un générateur d’API dédiée ;

– µADL : un langage de description de micro-architecture à base de micro-composants.

1.5.1 JAVACT

JAVACT [Arcangeli et Leriche, 2007] est un middleware Java dédié à la programmation d’appli-

cations concurrentes, réparties et mobiles à base d’agents. Il est disponible sous forme d’un Plugin 5

pour Eclipse. Une application JAVACT s’exécute sur un ensemble de places (des machines virtuelles

Java) connectées en réseau, via un middleware de plus bas niveau (de type Java RMI, CORBA, SOAP,

voire socket TCP/IP) dont l’utilisation est cachée au programmeur de l’application. Sur les places, un

ensemble d’agents répartis et mobiles coopèrent pour résoudre un problème commun. Pendant l’exé-

cution, un agent peut s’interrompre, changer de place, puis reprendre son exécution sur une nouvelle

place.

Les agents JAVACT sont des acteurs, entités logicielles autonomes qui communiquent par messages

asynchrones et traitent en série les messages reçus. Lorsqu’un acteur reçoit un message, il crée une co-

pie de lui-même à qui il délègue le traitement de ce message. Concrètement, l’adaptation des agents

sous JAVACT est possible grâce à une architecture à micro-composants. Un agent est composé d’un

assemblage de micro-composants autour d’un Connecteur (Mediator) (voir Figure 1.3). Une propriété

importante de cette architecture est la séparation entre le niveau opératoire et le niveau fonctionnel de

l’agent [Rougemaille et al., 2007]. Le niveau opératoire décrit les mécanismes internes de l’agent. C’est-à-

dire comment l’agent fonctionne. Le niveau fonctionnel décrit la fonctionnalité de l’agent ou encore son

comportement. C’est-à-dire le quoi de l’agent. Cette propriété permet à l’agent de s’adapter à son envi-

5. http : //www.irit. f r/PERSONNEL/SMAC/arcangeli/JavAct_ f r.html

11


ronnement tout en gardant une même fonctionnalité.

FIGURE 1.3 — Architecture des agents auto-adaptatifs

Chaque micro-composant correspond à un service opératoire pouvant être ajouté à l’agent tels que

l’envoi de messages (SendCt), la mobilité (MoveCt), la gestion de la boîte aux lettres (MailBoxCt), etc.

– Le Mediator joue le rôle de connecteur entre les micro-composants par lequel transitent leurs ap-

pels de méthodes. Il offre également les moyens de changements des micro-composants. Il rend

ainsi transparent le remplacement dynamique d’un composant pour les autres composants de

l’architecture.

– Le micro-composant de réception de messages (ReceiveCt) constitue le point d’entrée d’activation

d’un agent (sa référence). Il rend possible la communication entre agents.

– La partie comportement de l’agent (QuasiBehavior) est une interface entre le niveau fonctionnel

(les instructions codées par un programmeur) et le niveau opératoire. Il devient ainsi possible

d’utiliser les micro-composants d’un agent.

Programmer des agents revient à programmer des comportements. Pour cela, on étend la classe Qua-

siBehaviour permettant d’invoquer au niveau fonctionnel des services qui sont implémentés au niveau

opératoire (création d’agent, envoi de messages, changement de comportement, etc.).

1.5.2 Make Agents Yourself (MAY) : un générateur d’API dédiés

Afin de faciliter le développement et la génération des types d’agents conformes à l’architecture

des agents adaptatifs, Stéphane Dudouit 6 a proposé l’outil MAY. Il s’agit d’une version plus complète

d’un premier prototype appelé AgentPhi Designer [Leriche, 2006]. MAY permet de générer une API

dédiée à la programmation du niveau fonctionnel des agents. Il se compose d’une bibliothèque de

micro-composants opératoires prêts à l’emploi, d’un outil graphique permettant la sélection et l’assem-

blage des micro-composants autour d’un médiateur, d’un générateur d’architecture pour le langage Java

6. dudouit@irit. f r

12

1.6. Conclusion

(squelette de code). La phase de génération doit s’accompagner d’une phase de développement dans

laquelle le concepteur a en charge l’implémentation des services qu’il souhaite mettre en œuvre dans

l’API générée par MAY. Au final une archive Java est délivrée par l’outil.

Afin de garantir un certain nombre de propriétés structurelles avant que l’architecture ne soit réelle-

ment implémentée, MAY intègre aussi le langage de description de micro-architecture à base de micro-

composants µADL.

1.5.3 µADL

µADL [Rougemaille et al., 2007] est un langage de modélisation de micro-architecture basé sur les

concepts architecturaux présentés dans le premier paragraphe de cette partie. Il propose les concepts de

micro-architecture, de micro-composants et d’interfaces permettant de connecter ces derniers au média-

teur. La micro-architecture résultante est un assemblage de micro-composants par le biais des interfaces

qu’ils fournissent au médiateur. Elle délègue ses services au code fonctionnel de l’agent. µADL propose

pour chaque micro-composant un certain nombre de propriétés :

– Le nom ainsi qu’une courte description de son rôle au sein de la micro-architecture.

– Une référence sur l’interface qu’il fournit au médiateur (providedInterface).

– Un ensemble de services ou opérations (privateServices) associés à un niveau de visibilité :

– Interne ou Externe selon que le service est demandé au sein de l’agent ou en dehors.

– Base ou Méta selon qu’il est accessible depuis le niveau fonctionnel ou le niveau opératoire.

– Un ensemble de propriétés structurelles typées (properties).

– Une valeur booléenne spécifiant le fait que ce micro-composant peut être remplacé à l’exécution

(isChangeable).

– Une valeur booléenne spécifiant le fait que ce micro-composant possède un état rémanent dont il

faut tenir compte lors du remplacement dynamique (withState).

– Une liste des services qui lui sont nécessaires (requiredServices).

Chaque modèle µADL correspond à l’abstraction d’une micro-architecture, c’est-à-dire à un nouveau

type d’agent. Ce modèle constitue la source de la génération du code mis en œuvre dans MAY (voir

Figure 4.1).

1.6 Conclusion

Ce premier chapitre s’est articulé sur trois idées principales. Tout d’abord, nous avons présenté et

défini notre vision de l’intelligence ambiante ainsi que sa relation avec l’informatique diffuse. Nous

avons aussi exposé rapidement le domaine de la domotique qui s’intéresse aux maisons du futur. Il

s’agit d’un terrain favorable pour appliquer l’intelligence ambiante. Ensuite, nous avons parcouru les

concepts de base des systèmes multi-agents et plus particulièrement ceux spécifiques aux AMAS. Une

brève description de la méthode ADELFE a été présentée. Enfin, nous avons présenté le middleware

13


FIGURE 1.4 — Processus de transformation de modèle

JAVACT, le générateur d’API MAY et le langage de description de micro-architecture µADL. Ces concepts,

ces théories et ces outils sont manipulés pour produire les solutions qui contribuent au prototype de la

plate-forme de conception d’applications en intelligence ambiante. Ils servent ainsi à concevoir et im-

plémenter des agents ambiants offrant la capacité de s’auto-organiser par coopération pour produire un

système ambiant adaptatif.

14

2 État de l’art

La notion de domaine qui étudie exclusivement l’intelligence ambiante est assez difficile à retrouver

dans la littérature. En effet, au lieu d’être un domaine de recherche en soi, il se situe à la jonction de

plusieurs axes de recherche.

Les domaines tels que l’architecture (nanotechnologie, électronique,etc) s’intéressent aux aspects ma-

tériels nécessaires pour intégrer des composants électroniques (microprocesseurs, capteurs, mémoires,

etc.) miniaturisés dans les objets du quotidien. Les recherches dans les aspects logiciels (intelligence ar-

tificielle, systèmes multi-agents (SMA), génie logiciel, etc.) s’intéressent aux systèmes à intégrer dans les

appareils électroniques. Les recherches sur les réseaux et télécommunications se consacrent à fournir

la technologie permettant aux appareils de communiquer. Enfin, les recherches en Interaction Homme-

Machine (Conception d’IHM, traitement automatique de la langue, aspect sociologique, etc.) visent à

rendre l’interaction avec ces appareils plus intuitive (écran tactile, reconnaissance de geste, reconnais-

sance de voix, reconnaissance d’émotion, etc.).

Dans ce chapitre, nous nous intéressons aux aspects logiciels du domaine et plus particulièrement

aux systèmes multi-agents et aux plates-formes de conception de systèmes ambiants. Nous survolons

tout d’abord une analyse des travaux SMA dans ce domaine. Ensuite, nous présentons brièvement deux

plates-formes dédiées aux développements d’applications en intelligence ambiante.

2.1 Travaux SMA en intelligence ambiante

Pour concevoir et réaliser un système ambiant, utiliser les concepts d’agent et de système multi-

agent semble une solution évidente. Elle permet de prendre en compte et de répondre aux caractéris-

tiques d’un environnement d’intelligence ambiante (dynamique de l’environnement, hétérogénéité des

appareils électroniques et des informations, distribution et complexité du système à fournir, etc.).

2.1.1 Approche organisationnelle

Présentation

Juan M. Corchado et al. ont proposé un système multi-agent générique pour l’intelligence ambiante.

Pour cela ils ont défini dans [Dante I. Tapia, 2008], trois types d’agents (BDI Agent, CBR-BDI Agent et

15

Chapitre 2. État de l’art

CBP-BDI Agent), leurs fonctionnements et le SMA. Les agents sont modélisés selon l’architecture BDI

(Belief, Desire, Intention) de Bratman fondée sur les trois notions de croyances (les connaissances que

possède un agent sur son environnement), de désirs (les états de fait qu’il souhaite voir réalisés), et

d’intentions (les projets qu’il a l’intention de mener à bien). Les agents de type CBR-BDI Agent implé-

mentent le mécanisme de raisonnement CBR (Case-Based Reasoning). Ce dernier permet à un agent de

construire une solution pour un problème à résoudre à partir de "cas" similaires. Chaque cas est formé

d’un état initial (les croyances de l’agent) qui correspond à une description du problème, une solution

(plans ou intentions de l’agent) sous forme de séquences d’actions à exécuter par l’agent, et un état final

(croyance de l’agent) sous forme d’un ensemble de buts (voir Figure 2.1). Un agent en présence d’un

nouveau problème agit en quatre phases selon le mécanisme CBR :

1. Une phase de récupération (Retrieve) où il recherche et récupère les cas similaires au nouveau

problème.

2. Une phase de réutilisation (Reuse) où il combine toutes les solutions des problèmes similaires pour

en créer une nouvelle.

3. Une phase de révision (Revise) où la solution proposée est vérifiée.

4. Une phase de sauvegarde (Retain) où l’agent sauvegarde la nouvelle solution.

FIGURE 2.1 — Structure d’un BDI agent et du mécanisme CBR

Le CBP-BDI Agent fonctionne selon un mécanisme similaire au CBR. Dans le CBP (Case-Based Plan-

ning), la description du problème et la solution pour le résoudre sont sous forme de plans.

L’organisation du système multi-agent proposé par Juan M. Corchado et al. contient cinq agents

utilisant les trois types d’agents présentés (voir Figure 2.2). Cet SMA a été utilisé par les auteurs pour

développer une application de gestion des activités des infirmières et des médecins dans une maison de

retraite.

1. User Agent gère les données des personnes et leurs comportements (emplacement dans la maison

de retraite, leurs besoins quotidiens, leurs maladies...).

16

2.1. Travaux SMA en intelligence ambiante

2. SuperUser Agent communique au Manager Agent les nouvelles tâches à traiter par le mécanisme

CBR. Il peut imposer à User Agent des tâches, et vérifie l’évolution des plans du ScheduleUser

Agent.

3. ScheduleUser Agent planifie les activités quotidiennes du personnel soignant qui représente en te-

nant compte de son profil (compétences, rapidité de travail, charge de travail).

4. Manager Agent s’occupe de la sécurité du bâtiment (température, lumière, alarmes, portes.). Il gère

aussi l’assignation des tâches et la gestion des bases de données de la maison de retraite.

5. Devices Agent contrôle les périphériques de la maison de retraite. Aussi, il surveille l’emplacement

des personnes grâce aux capteurs RFID, contrôle l’éclairage, les serrures des portes...Ces informa-

tions sont par la suite transmises au Manager Agent.

FIGURE 2.2 — Les agents, leurs interactions et la technologie utilisée

Analyse

Le SMA proposé par Juan M. Corchado et al. est intéressant dans un environnement peu dynamique.

Un domaine tel que la santé exige beaucoup de sécurité, les agents doivent être peu autonomes. Nous

remarquons aussi que le Manager Agent est un élément central dans ce système. Les agents doivent

constamment interagir avec lui ce qui peut entraîner des goulots d’étranglements. De plus, l’organisa-

tion des agents est statique et manque donc de flexibilité. Enfin, il faut savoir que le fonctionnement

d’un mécanisme de raisonnement à base de cas s’arrête si celui-ci ne trouve aucun cas, ce qui le rend

vulnérable.

En intelligence ambiante de façon générale, nous avons besoin d’agents autonomes capables de

s’adapter à un environnement très dynamique. La formation d’une organisation ne peut pas être prévue

dès le départ. C’est en fonction du contexte et des objectifs de l’agent que cette dernière émerge.

17


2.1.2 Approche interactionnelle

Présentation

Dans [Charif et Sabouret, 2006b], les auteurs ont proposé un modèle de description d’agents am-

biants utilisant le modèle VDL (View Design Langage). Le VDL est un langage permettant de program-

mer des agents autonomes capables d’offrir des fonctionnalités spécifiques ou des services [Nicolas Sa-

bouret, 2003]. Il formalise des requêtes échangées lors d’interactions homme-agent ou inter-agents. Un

agent VDL est formé d’une couche de raisonnement et d’une couche abstraite de services [Charif et Sabouret,

2006a] (voir Figure 2.3).

FIGURE 2.3 — Le modèle d’agent VDL

1. La couche de raisonnement permet à l’agent d’exploiter ses services, de traiter la réception des mes-

sages, de composer des réponses aux requêtes reçues et de gérer la communication inter-agents.

2. La couche abstraite de services est sous forme de déclaration VDL-XML des services agent et de l’on-

tologie associée.

L’interaction entre des agents VDL est illustrée dans [Charif et Sabouret, 2006b] par un scénario de do-

motique impliquant un utilisateur, un téléphone, une télévision et un magnétoscope. Dans ce scénario,

l’utilisateur envoie un message à son téléphone de maison via son portable, lui demandant de trouver

dans le télétexte le programme dont le thème est la finale de la ligue des champions et de l’enregistrer.

Analyse

Doter un agent de capacités d’interaction à la fois avec l’utilisateur et avec d’autres agents est né-

cessaire en intelligence ambiante. L’approche présentée ci-dessus traite de ce problème. Pourtant, nous

remarquons que les agents VDL n’ont pas beaucoup d’initiatives. En effet, seul l’agent initiateur d’une

requête doit résoudre les problèmes de message incompris. Aussi, ces agents suspendent leurs traite-

ments jusqu’à ce qu’ils reçoivent la confirmation d’une demande émise.

Dans un environnement dynamique et ouvert d’intelligence ambiante, un agent doit être capable

de prendre des initiatives. Typiquement, il doit pouvoir trouver de nouveaux agents s’il n’arrive pas

18

2.1. Travaux SMA en intelligence ambiante

à réaliser une tâche. Il doit également être capable de retransmettre une requête incompréhensible à

d’autres agents.

2.1.3 Approche par coordination

Présentation

Le projet LAICA (Laboratorio di Ambient Intelligence per una Città Amica) [Cucchiara et al., 2005]

développé pour la région de Reggio Emilia en Italie, avait pour but de fournir un ensemble de services

pour les citoyens de la ville. Dans [Ferrari et al., 2006], les auteurs ont présenté deux types d’agents pour

l’intelligence ambiante en environnement urbain.

1. Sensor Agents : agents chargés de capter des informations du monde physique. Ce sont des agents

réactifs qui reçoivent les données de capteurs et les transforment en événements (Events) et/ou

en avertissements (Warnings). Pour que les agents se coordonnent, ils s’enregistrent sur des ca-

naux d’événements (Events Channels). Les événements sont par la suite notifiés par le canal associé

lorsqu’ils se produisent.

2. Effector Agents : sont destinés au contrôle d’objets dans leurs environnements (caméras, feux de

signalisations, etc.). En effet, les Sensor Agents émettent des événements qui sont interceptés par les

Effector Agents. En fonction de l’événement généré et de ses croyances, un Effector agent décide de

la prochaine action à réaliser. Par exemple, pour suivre une voiture volée, un Sensor agent analyse

les données transmises par une caméra. Lorsque la voiture est reconnue, un événement est émis

sur un canal d’événement. Celui-ci est intercepté par un Effector agent qui peut décider de suivre

la voiture en activant d’autres caméras ou en alertant la police en envoyant un SMS.

Analyse

Dans un environnement d’intelligence ambiante, des agents pouvant capter et utiliser des infor-

mations sur leur monde physique sont nécessaires. C’est ce qui a été proposé dans le projet LAICA.

Néanmoins, nous remarquons que les agents sont indépendants les uns des autres. La coordination et

l’organisation se fait exclusivement par l’intermédiaire d’évènements. De ce fait, un agent n’a pas besoin

de construire une connaissance sur les autres.

L’aspect collectif nous semble pourtant un point particulièrement important pour réaliser de l’intel-

ligence ambiante.

2.1.4 Approche par auto-adaptation

Présentation

Dans un environnement de communication ambiante, plusieurs objets hétérogènes et communicants

offrent différents services. Compte-tenu de la mobilité d’un utilisateur, les services disponibles varient.

19


Dans ce type d’environnement, les applications doivent être flexibles, capables d’exploiter les bons ser-

vices en fonction de leur contexte. Afin de permettre une adéquation entre les services disponibles et ce

que doit fournir une application, Vallée et al. ont proposé un système multi-agent capable de réaliser

une composition de services dynamique [Vallée et al., 2006]. Ce système joue le rôle de médiateur entre

les besoins d’un utilisateur, les fonctionnalités disponibles et les informations contextuelles pour com-

poser différents services. La figure 2.4 représente ce système gérant une composition simple impliquant

deux éléments (notés A et B).

FIGURE 2.4 — Système multi-agents pour la composition de services

Un agent assistant se charge de recueillir les besoins de l’utilisateur, soit directement sous forme

de commandes ou par le biais de règles de déclenchement contextuelles. Pour y répondre, il définit

un objectif de composition qu’il transmet à un agent compositeur. Ce dernier extrait de cet objectif les

caractéristiques des différentes fonctionnalités nécessaires et délègue la recherche des services corres-

pondants aux agents superviseurs. Lorsque ceux-ci l’ont renseigné, l’agent compositeur peut évaluer les

compositions possibles et les réaliser en mettant en relation les services appropriés. Le rôle d’un agent

superviseur est de proposer le service le plus approprié pour réaliser la fonctionnalité dont il est res-

ponsable. Pour cela, une infrastructure de services d’objets communicants (voir Figure 2.5) lui fournit

une première liste de services. Il évalue ensuite leur adéquation avec le contexte courant, ainsi que leur

interopérabilité avec les services proposés par les autres superviseurs.

FIGURE 2.5 — Architecture flexible pour les environnements ambiants

20

2.2. Plates-formes de conception d’applications en intelligence ambiante

Analyse

Réaliser une composition de services à partir de ceux qui sont disponibles, permet aux applications

de s’adapter en fonction du contexte. Dans cette approche, seule l’application assurant cette fonctionna-

lité est agentifiée.

Notre but est d’aller plus loin que cela. Nous voulons, que l’application de composition de services

soit une capacité de l’agent ambiant.

2.2 Plates-formes de conception d’applications en intelligence ambiante

Le développement logiciel dans le cadre de l’intelligence ambiante conduit à fournir des solutions

méthodologiques et techniques répondant à des fortes contraintes d’adaptation. L’un des défis majeurs

est de fournir une plate-forme capable de faciliter le processus de développement dans ce domaine et de

l’assister tout au long du processus de réalisation. Dans cette partie nous présentons deux plates-formes

de développement d’applications en intelligence ambiante.

2.2.1 GadgetWare Architectural Style (GAS)

Présentation

GAS [Markopoulos, 2004] est une plate-forme de création d’application d’intelligence ambiante. Elle

regroupe une ontologie, un modèle Plug (classe de logiciel qui permet de rendre visible les capacités,

les propriétés et les services d’un artefact egadget pour l’utilisateur et pour les autres egadgets), un mo-

dèle Synapse (association entre deux Plugs compatibles), un middleware GAS-OS, une méthodologie de

développement des artefacts et un ensemble d’outils permettant la création et la manipulation de ses

applications. Chaque application est construite par l’association d’un ensemble d’egadgets formant le

GadgetWorld.

A travers un éditeur graphique (egadgetWorld Editor) (voir Figure 2.6), un utilisateur ou un agent

intelligent construit et manipule des GadgetWorlds. Cet éditeur offre les fonctionnalités suivantes :

– la création et la modification des synapses en indiquant les deux Plugs à relier,

– la recherche d’egadgets et leurs Plugs,

– la collecte, l’affichage et la gestion d’informations concernant les egadgets découverts, de leurs

Plugs, et des Synapses créées.

Analyse

La plate-forme GAS permet à un programmeur de construire une application spécifique d’intelli-

gence ambiante en élaborant des schémas d’interactions entre artefacts. Cette solution nous semble limi-

tante voir irréalisable pour des applications complexes. En effet, pour ce genre d’application, la solution

ne peut être représentée par un ensemble d’interactions entre artefacts.

21


FIGURE 2.6 — egadgetWorld Editor

2.2.2 WComp

Présentation

WComp [Cheung et al., 2006] est un environnement de prototypage d’application sensible au contexte

(voir Figure 2.7). Une application est construite par un ensemble de composants assemblés d’une ma-

nière dynamique. WComp est organisé autour de Containers et de Designers. L’objectif des Containers

est de prendre en charge dynamiquement les services requis par les composants d’un assemblage. Les

Designers permettent la manipulation des assemblages de composants au travers des Containers qui

les gèrent. Un Designer graphique d’architecture nommé Bean4WComp permet de composer manuelle-

ment des assemblages de composants à partir d’une représentation graphique. Un Designer d’aspects

d’assemblage nommé ISL4WComp permet de décrire des schémas d’interactions entre composants.

Cet environnement est complété par une plate-forme pour l’étude des équipements informatiques

mobiles en environnement simulé nommée Ubiquarium Informatique [Hourdin et al., 2006]. Elle est desti-

née à simuler et à évaluer les applications de l’informatique mobile et ambiante.

Analyse

Un des points intéressant de WComp est qu’elle permet de tester le fonctionnement d’une applica-

tion d’intelligence ambiante dans un environnement virtuel. Par contre, leurs développements reposent

comme pour la plate-forme GAS, sur la définition de schémas d’interactions entre artefacts.

22

2.3. Conclusion

FIGURE 2.7 — Editeur graphique du WComp

2.3 Conclusion

La majeure partie des recherches actuelles en intelligence ambiante porte sur la réalisation des infra-

structures nécessaires, sur la conception d’artefacts...sur tout ce qui constitue les fondations "matérielles"

des systèmes ambiants. D’autres projets ont mis en place des prototypes grandeur nature. C’est le cas

dans le domaine de la santé, dans le monde urbain et principalement dans celui de la domotique.

Dans ce deuxième chapitre nous avons en premier lieu mis l’accent sur quatre approches SMA en

intelligence ambiante. Des solutions pour des systèmes ambiants sûrs et fiables, capables d’interagir à

la fois avec l’utilisateur et des agents, de se coordonner et de construire une composition de services ont

été proposées. Ces approches se sont révélées plutôt spécifiques.

Notre approche basée sur l’auto-organisation a pour but de concevoir des agents ambiants au-

tonomes plus génériques. Ces agents ayant des comportements adéquats leurs permettant de s’auto-

organiser et de s’adapter pourront faire face aux contraintes d’un environnement d’intelligence ambiante

(distribution, dynamicité et hétérogénéité, etc.), de répondre aux besoins des utilisateurs et de construire

ensemble des systèmes ambiants.

Dans un deuxième temps, nous avons présenté deux plates-formes de conception d’applications en

intelligence ambiante. Les deux plates-formes utilisent un même concept : celui de définir des sché-

mas d’interactions entre artefacts. Or cette solution est inexploitable lorsqu’il s’agit de développer des

applications où il n’existe pas de solution évidente.

Notre objectif est que chaque artefact soit autonome et que la solution d’un problème se construit par l’in-

termédiaire du mécanisme d’auto-organisation des agents embarqués sur ses artefacts. Pour cela, nous utilisons

les outils présentés dans le premier chapitre afin de réaliser les agents équipant ses artefacts et à terme

faciliter le développement d’applications en intelligence ambiante.

23

3 E-AmI : agents ambiants,comportements et mécanismed’auto-organisation

Le premier objectif de mon travail est de définir et de modéliser des agents d’intelligence ambiante,

c’est-à-dire des agents capables de s’intégrer à un environnement réel, d’interagir avec d’autres agents

s’y trouvant et de contribuer à l’existence de cette "intelligence ambiante". Dans notre approche, ces

agents doivent être coopératifs. Pour cela nous avons utilisé les notions de coopération, de comporte-

ment et de résolution de situations non-coopératives telles que décrites dans la théorie AMAS 1.

Nous présentons tout d’abord dans ce chapitre les concepts appropriés pour un agent ambiant. En-

suite, nous étudions les points qui le différencient des agents coopératifs rapportés dans les travaux

précédents de l’équipe SMAC. Nous définissons ensuite plusieurs comportements coopératifs pour un

agent ambiant lui permettant de répondre et contribuer à un environnement d’intelligence ambiante.

Après cela, nous analysons le mécanisme d’auto-organisation des agents ambiants. Enfin, nous expo-

sons un premier modèle d’un agent ambiant.

3.1 Agent ambiant

Un agent ambiant est conçu pour être embarqué sur un appareil électronique formant ainsi un Am-

bient Intelligence Device (AmID). Cet AmID est destiné à intégrer un environnement contenant des di-

zaines, voir des centaines d’autres AmIDs. Afin que cet ensemble interagisse et que ses constituants ne

restent pas inertes les uns par rapport aux autres, il est nécessaire qu’un ensemble de capacités et de

comportements soit fournit aux agents.

3.1.1 Capacités

Pour répondre à son environnement, un agent ambiant nécessite plusieurs capacités. Ici, nous nous

inspirons des travaux antérieurs du domaine et nous exposons les points clés.

1. Adaptative Multi-Agent Systems

25

Chapitre 3. E-AmI : agents ambiants, comportements et mécanisme d’auto-organisation

Un agent ambiant réalise et offre des services

Dans un AmID nous retrouvons deux aspects : l’agent d’une part et l’appareil d’autre part. Un agent

peut ainsi exploiter un sous-ensemble ou tous les services de cet appareil, tel que le stockage de données

s’il dispose d’une mémoire, le traitement de données s’il dispose d’un processeur, l’accès à Internet,

etc. Ces services sont directement liés aux ressources de l’appareil. L’agent peut avoir également ses

propres services. En effet, lorsque par exemple l’agent capte des données sur son environnement (une

température ambiante, la présence d’objets, etc.), il peut se faire une représentation du contexte qu’il

peut alors fournir aux autres agents.

Un agent ambiant réagit aux caractéristiques de l’appareil qui l’intègre

Lorsque nous concevons et implémentons des agents destinés à fonctionner sur des ordinateurs, les

contraintes liées aux caractéristiques de ces machines ne se posent pas. Or dans notre cas, les agents vont

fonctionner sur des appareils électroniques portables ayant peu d’autonomie d’énergie, des capacités

de calcul et de stockage réduites et d’autres ressources qui varient d’un appareil à un autre. De telles

limitations doivent par conséquent être prises en considération et nous pouvons envisager pour cela

deux solutions complémentaires :

1. Un agent ambiant doit prendre en compte les paramètres d’autonomie d’un appareil mobile. Pour

surmonter cette première contrainte, puisqu’il peut la percevoir, la solution consiste à adapter le

fonctionnement de son cycle de vie (perception, décision et action). Ce cycle se répète généralement à

l’infini et est "rythmé" par chaque nouvelle perception. A ce cycle nous intégrons un temporisateur

(Pause) qui suspend l’exécution de l’agent pendant une certaine durée de temps.

(a) Perception : l’agent perçoit son environnement.

(b) Décision : l’agent décide en fonction de ce qu’il perçoit, de ses connaissances et de ses compé-

tences de l’action à réaliser.

(c) Action : l’agent réalise l’action choisie.

(d) Pause : l’agent est suspendu pour une durée de temps t.

L’ajout de cette nouvelle phase permet d’adapter le fonctionnement de l’agent selon trois manières

différentes :

Pour t = 0 l’agent fonctionne selon un cycle de vie normal.

Pour t = SuspendDelay l’agent fonctionne selon un cycle de vie temporisé. Après chaque action, il

s’arrête pendant une durée de temps SuspendDelay, puis il reprend. Cette durée de temps dépend

bien sûr de l’appareil et peut même varier en fonction de l’énergie restante.

La troisième manière consiste à ajuster ce temporisateur en fonction de l’environnement de l’agent.

En effet, lorsque ce dernier perçoit beaucoup de variations autour de lui, l’idéal est que le tempo-

risateur soit nul pour que l’activité de l’agent soit bénéfique pour lui ainsi que pour les autres

agents. Dans le cas contraire où l’agent ne perçoit plus d’événements dans son environnement,

26

3.1. Agent ambiant

son activité intense n’est plus intéressante et il peut donc la temporiser. Il s’agit dans ce cas d’un

cycle de vie contrôlé.

2. La deuxième solution peut résoudre le problème de capacité de traitement et de mémorisation de

l’agent. Cette solution consiste à ce que l’agent délègue ses tâches à d’autres agents, par exemple

à un agent ambiant de plus forte capacité (PC portable, station de travail, etc.).

Un agent ambiant maintient une représentation de son environnement

La représentation de l’environnement permet à l’agent de décider. Dans un environnement d’intel-

ligence ambiante nous avons des agents capables de maintenir une représentation des autres agents.

C’est le cas des agents communicants. D’autres agents ont la capacité de maintenir une représentation

des objets du monde. C’est le cas des agents dotés de capteurs. Enfin, d’autres agents ont la capacité de

maintenir à la fois une représentation des autres agents et une représentation des objets présents dans

leurs environnements.

Un agent ambiant est capable d’interagir avec les autres agents

Un agent ambiant n’est pas un simple système embarqué. En effet, les systèmes embarqués sont des

systèmes électroniques et informatiques qui sont dédiés à une tâche bien précise (souvent au contrôle

du système électronique qui les embarque). Au-delà de cette fonction, un agent ambiant exploite les res-

sources du système électronique et interagit également avec les autres agents. Ce n’est pas un système

isolé ne réalisant qu’une seule tâche précise. En effet, il est doté de comportements, il peut commu-

niquer, maintenir une représentation de son environnement, s’intégrer dans un nouveau système, se

coordonner et coopérer avec d’autres appareils, etc. L’activité collective est certainement un des aspects les

plus importants en intelligence ambiante.

Un agent ambiant est soumis à des règles qu’il doit respecter

D’une façon générale, la conception d’un système social où l’utilisateur est un élément clé et des don-

nées personnelles peuvent être manipulées révèle des questions d’éthique, de sécurité et de vie privée.

Ces contraintes sont encore plus problématiques en intelligence ambiante. En effet, le facteur humain

est très important dans notre contexte car nous sommes potentiellement en présence d’un système com-

plexe, ouvert, fortement dynamique et avec des personnes aux intentions diverses pouvant y apparaître

à tout moment. Nous considérons que l’objectif principal de nos systèmes ambiants est la satisfaction

des besoins de l’utilisateur et donc du respect de leurs intérêts. Ainsi les agents se doivent d’y contribuer,

par exemple en gérant des confiances, des niveaux de priorités, des typologies d’environnement (tra-

vail, maison, rue, etc.). Sur le plan technique, la mise en place de systèmes de limitation d’accès et de

cryptage de données peut contribuer à la préservation de ce genre d’informations.

27


3.1.2 Agent ambiant vs. agent coopératif traditionnel

A la différence de la plupart des agents coopératifs étudiés dans les travaux antérieurs de l’équipe

SMAC, les agents ambiants doivent posséder des caractéristiques et des capacités indispensables au

domaine de l’intelligence ambiante. Très souvent, les agents classiques sont intégrés dès le départ dans

un même système. Ils communiquent avec un même langage et les mêmes protocoles de communi-

cation. Généralement ils ne sont pas destinés à fonctionner sur des appareils mobiles. Contrairement

aux agents classiques, les agents ambiants coopératifs n’ont généralement aucune connaissance initiale

sur leurs voisins, ni de leur existence, ni de leurs caractéristiques. Ils doivent donc avoir la capacité

de s’intégrer dans un système, lui-même en changement. Ces agents peuvent avoir différents langages

et protocoles de communication. Ils sont conçus pour fonctionner sur des appareils mobiles avec les

contraintes en découlant (vues dans 3.1.1 capacités). Nous détaillons ici les deux spécificités principales

des agents ambiants.

Un agent ambiant a la capacité de s’intégrer dans un nouveau système ambiant

Un agent ambiant est destiné à intégrer un appareil souvent mobile tel qu’un téléphone portable,

un assistant personnel (PDA), etc. Son environnement est soumis à des changements fréquents. Ces

changements sont perçus par l’agent car il perd ses liens de communication avec les autres agents. Par

exemple, si notre agent communique en BlueTooth, cette communication est interrompue au-delà de

dix mètres. Pour continuer à interagir, il doit rechercher de nouveaux partenaires et s’intégrer dans

un nouveau système. Pour réaliser cette fonction, l’agent peut diffuser un message de découverte et

attendre qu’un autre agent lui réponde.

L’un des protocoles qui peut assurer cette fonctionnalité est le Contract-Net. En effet, l’agent qui dif-

fuse un message de découverte (ou encore message de présentation ou de proposition) peut s’attendre

à plusieurs réponses en retour. Pour cela, il peut choisir un ou plusieurs partenaires en fonction de leurs

caractéristiques. Par exemple, le partenaire qui possède le plus de moyens de communication si l’agent

cherche à contacter d’autres agents.

Un agent ambiant possède la capacité de se présenter aux autres agents ambiants

L’intégration de l’agent dans un nouveau système passe par la communication de ses caractéris-

tiques. Une caractéristique permet de définir les propriétés intrinsèques ou physiques d’un agent. En

général, un agent ambiant a quatre caractéristiques importantes (voir Figure 3.1).

1. La capacité énergétique d’un agent fait référence à l’autonomie de l’appareil dans lequel il s’exécute.

Elle peut être illimitée si l’appareil ne fonctionne pas sur une batterie, sinon elle est limitée. Cette

information est importante car un agent ambiant contraint par une source d’énergie limitée doit

la prendre en compte dans son fonctionnement. Par exemple, au lieu d’interagir avec plusieurs

agents à la fois, il le fait uniquement avec un seul. Un agent n’effectue également pas les mêmes

28

3.2. Les comportements coopératifs d’un agent ambiant

requêtes à un autre agent s’il sait que celui-ci a des capacités énergétiques limitées.

2. Les moyens de communication de l’agent tel que WiFi, BlueTooth, ZigBee, TCP/IP, etc. C’est une in-

formation clé qui permet de faciliter la communication et l’intégration des agents dans un système,

donc la construction d’un système ambiant. Nous pouvons imaginer qu’un agent ambiant veut en-

voyer un mail et ne disposant que du BlueTooth pour communiquer. Pour cela, il aura besoin de

trouver un agent qui dispose du WiFi ou de tout autre moyen supportant le TCP/IP pour réaliser

cette action.

3. Les langages compris par l’agent constituent une caractéristique spécifique. En effet, nous avons

supposé que les agents ambiants peuvent communiquer avec différents langages. Afin de se faire

comprendre, un agent ambiant choisit d’envoyer un message dans un format compris par son des-

tinataire. Si les langages des deux agents ne sont pas compatibles, les agents tentent de résoudre

cette incompréhension dans la mesure du possible. Par exemple, par l’intermédiaire d’un autre

agent ayant la capacité de convertir les formats de messages.

4. Le type d’appareil sur lequel s’exécute l’agent à un moment donné. Il peut actuellement être un télé-

phone mobile, un assistant personnel, un PC portable voire même une télévision, un caméscope,

une chaîne Hi-Fi, etc. A terme, tout appareil électronique est un hôte potentiel (caméra, régulateur

de température, antenne WiFi, vidéo projecteur, etc.) Si l’agent ambiant est mobile (au sens qu’il

peut, par le réseau, se déporter sur un autre appareil), cette caractéristique est mise à jour (ainsi

que les autres caractéristiques) lorsque celui-ci se déplace.

FIGURE 3.1 — Caractéristiques d’un agent ambiant

3.2 Les comportements coopératifs d’un agent ambiant

Un agent ambiant a différents comportements coopératifs qui vont contribuer à faire de l’activité

collective une réelle intelligence ambiante. Dans cette partie nous présentons six comportements spéci-

fiques.

29


3.2.1 Comportement de présentation

L’intégration d’un agent ambiant dans un nouveau système passe par une phase de présentation.

Son comportement de présentation se manifeste lorsqu’il se retrouve dans un nouvel environnement.

L’agent agit pour intégrer ce nouveau système en diffusant ou en envoyant ses caractéristiques vers

d’autres agents.

3.2.2 Comportement de survie

Compte-tenu des contraintes que nous avons présentées dans la première partie de ce chapitre, un

agent ambiant doit survivre dans un environnement d’intelligence ambiante. Pour cela nous définissons

le comportement de survie. Il se manifeste lorsque l’agent contrôle son cycle de vie pour augmenter sa

durée de vie. Il choisit également de répondre raisonnablement aux requêtes qu’il reçoit. Egalement et

avec la notion d’agent mobile, celui-ci devient capable de changer d’environnement d’exécution pour

augmenter sa survie.

3.2.3 Comportement coopératif terminal

Le problème d’autonomie des appareils électroniques est souvent décisif pour les agents ambiants.

Pour cela, nous prévoyons un comportement que manifeste l’agent avant de s’arrêter. Celui-ci va consis-

ter à diffuser une dernière information aux autres agents (par exemple en les informant de sa disparition

ou en partageant une information critique).

3.2.4 Comportement de sécurité

Un comportement de sécurité pour un agent ambiant regroupe plusieurs autres comportements. On

peut retrouver ici le comportement de survie, le comportement coopératif terminal, etc. Dans ce cadre,

nous insistons sur le fait que ce comportement est destiné à contenir un ensemble de règles que l’agent

doit respecter dans son environnement. Par exemple, lorsqu’un agent envoie des données contenant

l’identité d’une personne, il doit tout d’abord les crypter.

3.2.5 Comportement d’aider le plus critique

Le comportement d’aider le plus critique est un comportement coopératif particulièrement néces-

saire pour un agent ambiant afin d’améliorer le fonctionnement global d’un système ambiant. La cri-

ticité peut varier d’une situation à une autre. Par exemple, un agent ambiant recevant un signal d’un

même agent plusieurs fois de suite peut le considérer comme étant dans une situation critique (l’agent

émetteur semble ne pas pouvoir arriver à ses fins). Dans un autre exemple où l’agent perçoit un message

d’alerte d’un autre agent, cette situation peut être directement considérée comme situation critique par

la force illocutoire du message.

30

3.3. Mécanisme d’auto-organisation : la résolution des situations non coopératives

3.2.6 Comportement de relais

Les moyens de communications dont disposent les agents ambiants ont une portée limitée et sont

variés. Pour cela, il est intéressant d’exploiter le mécanisme de relais entre agents pour pouvoir faire

passer une information d’un agent vers un autre. Lorsqu’un agent participe à un relais, il reçoit un

message et le retransmet au destinataire final s’il le connaît. Sinon, il l’envoie à un agent voisin en

choisissant celui qui possède le plus de moyens de communication ou qu’il considère le plus apte à

relayer au bon agent (un agent annuaire par exemple).

3.3 Mécanisme d’auto-organisation : la résolution des situations non coopé-

ratives

Comme nous l’avons présenté dans le premier chapitre, le critère d’auto-organisation des agents

ambiants sur lequel nous nous basons est la coopération. En raison du caractère dynamique et de l’hé-

térogénéité d’un environnement d’intelligence ambiante, les situations non-coopératives sont très fré-

quentes et ceci implique que l’agent sera très souvent en situation non-coopérative. Parmi les sept situa-

tions de non-coopération nous jugeons que l’incompréhension et l’ambiguïté dans la phase de perception,

l’incompétence dans la phase de décision et l’inutilité et le conflit dans la phase d’action sont les situa-

tions les plus rencontrées dans notre contexte. Dans cette partie, nous donnons pour chaque situation

non-coopérative la condition de son déclenchement et une solution pour la résoudre.

3.3.1 Difficulté de perception

Les agents ambiants peuvent avoir des langages et des protocoles de communication complètement

différents. La difficulté de perception constitue donc un problème majeur dans notre contexte. Les deux

situations de non-coopération qu’un agent peut rencontrer sont :

L’incompréhension : l’agent ne peut pas interpréter un signal qu’il perçoit ou alors ce dernier est

ambigu. L’incompréhension d’un signal peut être totale ou partielle.

Une situation d’incompréhension totale se déclenche si l’information est totalement incompréhensible

par l’agent. Dans ce cas l’agent la retransmet à un autre agent ou aux agents qu’il croit capable de la

comprendre. Ce choix est fait par l’agent en consultant les caractéristiques qu’il possède sur les autres

agents.

Une situation d’incompréhension partielle se déclenche si l’information est partiellement compréhen-

sible. Dans ce cas, l’agent traite la partie comprise et transmet la partie non comprise vers un agent qu’il

croit capable de la résoudre en se basant aussi sur les caractéristiques qu’il possède sur les autres agents.

L’ambiguïté : le contenu d’un signal perçu est incomplet ou l’information n’est pas assez précise et

peut par conséquent être interprétée de plusieurs manières par l’agent. Dans cette situation, un agent

ambiant coopératif retourne le message à l’expéditeur pour une demande de clarification. S’il ne reçoit

31


pas de réponse plus claire, il peut également entamer une action tout en notant qu’elle est potentielle-

ment fausse (et donc l’annuler le cas échéant).

On peut noter que pour tous ces cas, le comportement coopératif minimal est de prévenir l’agent

émetteur du message qui pose problème (certains agents simple n’ont pas la capacité de faire un traite-

ment plus complexe).

3.3.2 Difficulté de décision

Souvent les agents se retrouvent dans des environnements totalement inconnus où leurs activités

ne concordent pas avec celles des autres agents présents. Ce fait est dû à la mobilité de l’utilisateur

qui transporte son AmID. L’agent se retrouve donc dans une situation d’incompétence. Lorsque celui-ci

reçoit des demandes d’autres agents, il peut être incapable d’y répondre ou de maintenir une activité

correcte. Un agent ambiant coopératif renvoie à l’agent demandeur l’accointance (l’adresse et la compé-

tence) d’un agent qu’il croit capable de répondre à cette demande. Il peut également rechercher active-

ment des agents capables de répondre à ses besoins. Ceci est particulièrement nécessaire s’il reçoit une

requête d’un humain (l’utilisateur de l’AmID) à laquelle il n’arrive pas à répondre.

3.3.3 Difficulté d’action

La difficulté d’action pour un agent ambiant se manifeste si ce dernier est dans une situation d’inuti-

lité ou de conflit.

L’activité d’un agent ambiant et ses actions diffèrent lorsqu’il change d’environnement. En effet,

nous pouvons découper un environnement d’intelligence ambiante en plusieurs sphères. Par exemple :

le bureau, le bâtiment où se trouve ce bureau et l’environnement avoisinant ce bâtiment. Dans la pre-

mière sphère, un agent ambiant embarqué sur le PDA d’un utilisateur connaît cet environnement car

son activité principale pour laquelle il a été conçu est par exemple la gestion des rendez-vous, la syn-

chronisation avec d’autres appareils et la possibilité d’utiliser leurs fonctionnalités. L’agent maintient

une activité normale quasi-intense avec l’agent installé sur l’ordinateur, l’agent qui gère l’imprimante,

l’agent sur le téléphone portable de l’utilisateur, etc. Toutes les actions de l’agent sont ainsi utiles. Lorsque

l’utilisateur quitte le bureau avec son PDA celui-ci se retrouve dans la deuxième sphère : le bâtiment.

L’activité primaire de l’agent diminue et devient presque inutile car l’agent perd ses liens avec les autres

agents. Tout ce qu’il envoi n’a aucun retour. Dans ce cas l’agent change de comportement, son activité

devient moins intense et il essaye d’augmenter son autonomie de survie (en adoptant un comportement

de survie). Par ailleurs, l’agent essaye de découvrir ce nouvel environnement en adoptant un comporte-

ment de présentation. Tout en maintenant une activité primaire mais moins intense, l’agent intègre un

nouveau système est essaye de contribuer à son fonctionnement. Enfin, lorsque l’agent se retrouve dans

la troisième sphère, ce dernier change d’activité, par exemple en adoptant le comportement de relais d’in-

formation.

La deuxième situation de non-coopération au moment de l’action est le conflit. Généralement, elle

32

3.4. Modèle d’un agent ambiant

provient de l’accès multiple à des ressources communes limitées ou non partageables. Un conflit peut

aussi intervenir si l’action entreprise par un agent gêne ou annule celle d’un autre agent. C’est le fait

d’aider le plus critique qui se manifeste dans ce genre de situation.

3.4 Modèle d’un agent ambiant

Nous avons modélisé notre agent avec le langage de description de micro-architecture µADL. Le

modèle que nous proposons contient dix micro-composants(voir Figure 3.2). Il donne une représen-

tation d’un agent ambiant ayant la capacité de communiquer, de capturer des informations sur son

monde physique et d’exploiter les ressources fournies par l’appareil sur lequel il s’exécute. Il faut noter

que dans un environnement d’intelligence ambiante, nous pouvons retrouver différents styles d’agents.

Des agents communicants par messages, d’autres ayant des capacités de sonder leurs environnements

physiques, d’autres pouvant agir sur leur monde physique, etc. Compte-tenu de cette diversité, nous

ne pouvons pas lister tous les modèles d’agents ambiants possibles. De ce fait, nous présentons dans ce

chapitre un modèle initial que le concepteur affine selon ses besoins (en ajoutant, en supprimant et en

substituant des micro-composants par d’autres).

Dans un premier temps nous décortiquons le niveau opératoire de cet agent en donnant une expli-

cation pour chaque micro-composant. Ensuite, nous montrons son niveau fonctionnel.

3.4.1 Niveau opératoire de l’agent

Notre modèle d’agent ambiant de départ contient dix micro-composants présentés sur la figure sui-

vante :

FIGURE 3.2 — Modèle de départ d’agent ambiant selon l’architecture flexible

33


Micro-composant Receive

Le micro-composant Receive représente le point d’entrée ou d’activation de l’agent. Lorsqu’un agent

reçoit un message, celui-ci est mis dans sa boîte à lettres. Lorsqu’il s’agit d’un agent ambiant qui ne

communique pas par message ce micro-composant n’est plus utile. Par contre, un micro-composant qui

représente son identité lui est fourni automatiquement au moment de l’implémentation.

Micro-composant MailBox

Le micro-composant MailBox représente la boîte aux lettres de l’agent dans laquelle sont mis en file

les messages qui lui sont envoyés. Elle fournit au niveau fonctionnel le service getMessage() qui renvoie

le message reçu pour être traité.

Micro-composant Send

Le micro-composant Send permet à l’agent d’envoyer des messages. Pour cela, nous prévoyons le

service send(). L’implémentation finale du service s’associe avec l’utilisation d’autres micro-composants.

Par exemple, pour envoyer un message avec le BlueTooth, le programmeur utilisera un micro-composant

BlueTooth qui fournit un service sendWithBlueTooth().

Micro-composant DeviceService

Comme nous l’avons souligné, un agent ambiant est embarqué sur un appareil électronique et il

accède à ses différents services. Pour cela, nous prévoyons le micro-composant DeviceService qui assure

cette opération. Pour des raisons de simplification, les services fournis par ce micro-composant peuvent

être de nature différente (normalement, chaque micro-composant représente un service unitaire et de

même nature. Par contre, le micro-composant DeviceService contient tous les services d’un appareil,

ce qui permet à l’agent ambiant, lorsque ce micro-composant est substitué par un autre DeviceService

d’utiliser les ressources du nouvel appareil). En effet, nous avons voulu insister sur le fait qu’un agent

ambiant est embarqué sur un appareil électronique et qu’il peut exploiter ses services. C’est pour cela

que ce micro-composant peut contenir plusieurs services de nature différentes.

Micro-composant Sensor

Un agent plongé dans un monde physique aura besoin d’information sur ce monde. Le micro-

composant Sensor est destiné à recenser ce genre d’information. Pour cela, il fournit le service getSensor-

Information() qui renvoie une information sur le monde physique de l’agent. Typiquement, un SensorR-

FID pourra capter des objets tagués. Pour des raisons de simplicité, nous ne pouvons pas lister sur le

schéma tous les Sensors possibles. En fonction des besoins du concepteur, celui-ci peut ajouter d’autres

micro-composants du même type.

34

3.4. Modèle d’un agent ambiant

Micro-composant Actuator

Un agent ambiant peut agir sur les objets de son environnement. Pour cela nous prévoyons le micro-

composant Actuator. Celui-ci fournit au niveau fonctionnel le service activateActuator(). Comme pour

le micro-composant Sensor, il peut avoir plusieurs Actuators. En fonction des besoins du concepteur,

celui-ci peut ajouter d’autres micro-composants du même type.

Micro-composant Neighbours

Pour pouvoir interagir avec les autres agents, un agent ambiant a besoin de communiquer et donc

de connaître ses agents ambiants voisins. Pour cela, nous prévoyons le micro-composant Neighbours.

Selon les moyens de communications de l’agent (BlueTooth, WiFi, etc.), le nombre d’agents avoisinants

varie. Ce micro-composant fournit au niveau fonctionnel le service getNeighbours(). Les services add-

Neighbour() et removeNeighbour() sont utilisés au niveau opératoire. Lorsque l’agent demande le service

getNeighbours(), les références des agents indisponibles sont supprimées par le service removeNeighbour()

et les nouvelles références sont ajoutées par le service addNeighbour().

Micro-composant Acquaintances

Au cours de sa vie, un agent ambiant acquiert de nouvelles connaissances sur les systèmes qu’il in-

tègre. Particulièrement, les agents ambiants de ces systèmes avec qui il a interagi mais surtout avec qui

il peut interagir à nouveau. Cela lui sert à gérer des confiances, des contacts importants, des groupes

d’agents "amis", etc. Pour pouvoir sauvegarder ces informations, nous prévoyons le micro-composant

Acquaintances. Il fournit au niveau fonctionnel les services getAcquaintances(), addAcquaintance() et remo-

veAcquaintance().

Micro-composant Representations

La décision d’un agent ambiant nécessite un ensemble d’informations sur son environnement (sur

les objets qui l’entourent, sur l’utilisateur, etc.) et sur soi. Pour cela, nous prévoyons le micro-composant

Representations. En fonction du domaine d’application, celui-ci contiendra et fournira les services néces-

saires à l’agent pour décider.

Micro-composant LifeCycle

Le micro-composant LifeCycle active et gère le cycle de vie de l’agent : Perception, Decision et Action.

L’agent perçoit son environnement avec les services du ou des Micro-composants Sensor et les services

du micro-composant MailBox. Lorsque l’un de ces micro-composants renvoie une information, la dé-

cision active la partie fonctionnelle de l’agent qui traite les informations reçues. L’agent agit sur son

environnement en utilisant le service send() du micro-composant Send, le service activeActuator() du

micro-composant Actuator et les services du micro-composant DeviceService.

35


3.4.2 Niveau fonctionnel de l’agent

Pour être coopératif, un agent ambiant doit avoir plusieurs comportements. Dans notre cas, nous

reprenons les comportements que nous avons présentés dans la première partie du chapitre.

FIGURE 3.3 — Les différents comportements d’un agent ambiant

Le comportement global de notre agent ambiant peut être décomposé en six comportements (voir

Figure 3.3). Nous détaillons ici ces comportements.

PresentationBehaviour

Ce premier comportement participe à l’intégration de l’agent dans un nouveau système. En effet,

lorsqu’un agent se retrouve dans un nouvel environnement, il a besoin de se présenter aux autres agents.

Pour cela, il diffuse un signal de présentation aux agents voisins fournis par le service getNeighbours().

ResolveMisunderstoodMessageBehaviour

Pour être coopératif, un agent ambiant ne doit pas ignorer les messages qu’il ne comprend pas. Pour

cela, nous prévoyons le comportement ResolveMisunderstoodMessageBehaviour. La résolution du message

incompris se fait en deux niveaux. Un agent peut recevoir un message crypté, dans ce cas s’il possède

l’algorithme et la clé de décryptage du message mais que ce dernier ne lui est pas destiné, il doit le

renvoyer à un autre agent. Ce traitement est par conséquent réalisé au niveau opératoire de l’agent.

Dans les autres cas, le traitement est réalisé au niveau fonctionnel de l’agent en adoptant la méthode

déjà décrite dans la partie résolution de situations non-coopératives de ce chapitre.

36

3.5. Conclusion

RelayBehaviour

Les contraintes dues aux outils de communications imposent l’utilisation du comportement Relay-

Behaviour. En effet, pour permettre à un signal de parvenir à un destinataire final, les agents peuvent

participer au relais de celui-ci. Grâce à ce genre de comportement, une information transite à travers

un ensemble d’agents pour atteindre le destinataire final. Le destinataire peut d’ailleurs être identifié

nominalement ou par un descriptif de caractéristiques ou de service fourni.

AssistanceBehaviour

Un agent ambiant est un agent coopératif qui exhibe le comportement d’aider les autres agents (par

exemple aider le plus critique). C’est pour cela que nous prévoyons le comportement AssistanceBeha-

viour. A ce stade, ce comportement est très générique et nous ne pouvons pas donner une définition

spécifique de la nature de cette aide. C’est au moment du développement de l’agent où ce genre de

comportement est spécifié par le programmeur en fonction des appareils sur lequel l’agent va s’exécu-

ter, de ses capacités et de ses caractéristiques. Par exemple, un agent ambiant qui s’exécute sur un PC a

de grande capacité et pourra aider d’autres agents ambiants en allégeant leurs charges de travail.

TerminalBehaviour

Les appareils mobiles sont fortement limités par leur autonomie. Lorsqu’un agent perçoit cette in-

formation, il peut réaliser un dernier traitement avant de s’arrêter. Par exemple, il peut informer ses

voisins qu’il ne va plus être disponible.

NominalBehaviour

Un agent possède toujours une activité principale qu’il essaye d’atteindre. Elle correspond à son

comportement nominal. Par exemple, un agent climatiseur essaye de maintenir une température constante

à l’intérieur d’une maison. Pour cela, il actionne, arrête et règle le fonctionnement de l’appareil. Pour

parvenir à réaliser son comportement nominal au mieux et en accord avec les agents de son voisinage,

l’agent adopte aussi les autres comportements que nous avons définis.

3.5 Conclusion

Ce troisième chapitre a présenté quatre grandes idées. Tout d’abord, les agents ambiants en ana-

lysant leurs capacités et en les comparant aux autres agents coopératifs étudiés par l’équipe SMAC

ont été déduits. Ensuite, nous avons exploré les comportements de ces agents ambiants. Par la suite,

nous avons analysé le mécanisme d’auto-organisation des agents ambiants en explorant les situations

de non-coopération qui peuvent se présenter à ces agents et comment ils peuvent les résoudre. En-

fin, nous avons esquissé un premier modèle d’agent ambiant réalisé avec le langage de description de

37


micro-architecture µADL. Ce modèle comporte dix micro-composants au niveau opératoire. Son niveau

fonctionnel est constitué de six comportements.

38

4 E-AmI : étude d’une plate-forme deconception générique

Dans ce chapitre je présente l’étude d’un premier prototype de plate-forme de conception d’appli-

cations en intelligence ambiante. Nous avons constaté dans l’état de l’art que les plates-formes présen-

tées se focalisaient essentiellement sur la définition de schémas d’interactions entre objets. Cette vision

nous semble réductrice. En effet, cela implique que le concepteur doit penser entièrement une solution

souvent compliquée voire impossible. Mon objectif est que cette plate-forme conçue permet d’aider le

concepteur à se concentrer sur les parties constituant son application c’est-à-dire les agents ambiants.

Cette étude de la plate-forme s’inscrit dans la perspective du projet NeoComputing au sein du labo-

ratoire IRIT. Ce projet a pour but de fournir les outils d’ingénierie (modèles, méthodes, infrastructures,

middleware, etc.) nécessaires pour la conception et le développement de la partie logicielle des Ambient

Intelligent Devices : communication, interaction, comportement, profil utilisateur, gestion de données,

etc. La partie 4.1, présente les fonctionnalités et les outils de la plate-forme. Ensuite, la partie 4.2 expose

ma contribution à cette plate-forme.

4.1 Fonctionnalités et outils de la plate-forme

Notre plate-forme permet de créer des agents d’intelligence ambiante. Nous cherchons également

à ce que cette plate-forme aide et assiste au maximum le concepteur dans l’accomplissement de cette

activité.

Pour cela, nous prévoyons l’intégration d’un ensemble d’outils, de modèles, de middleware... néces-

saires au développement de la partie agent d’une application d’intelligence ambiante. Actuellement

nous avons intégré :

1. des modèles en µADL supportant la conception d’agents-AmID,

2. des guides pour la conception d’agents-AmID,

3. des micro-composants opératoires et des squelettes de comportements du niveau fonctionnel pour

les agents-AmID,

4. une API ainsi qu’un générateur du code pour l’architecture des agents-AmID,

5. un prototype d’outil de conception dirigé par les modèles regroupant les outils précédents.

39

Chapitre 4. E-AmI : étude d’une plate-forme de conception générique

Cette activité de réalisation d’agents ambiants est assurée en quatre étapes : une description du scénario

envisagé pour l’application, un inventaire de l’équipement, une modélisation des agents et une implémentation de

ces agents(voir Figure 4.1). Tout au long de cette activité, l’utilisateur est assisté par un ensemble de

guides pour réaliser au mieux ces agents.

FIGURE 4.1 — Processus de modélisation et de réalisation des agents ambiants

d’une application d’intelligence ambiante

4.1.1 Description du scénario envisagé pour l’application

La première étape à réaliser dans un projet de développement en intelligence ambiante est la des-

cription textuelle du scénario de l’application. En effet, la plupart des travaux de développement en ce

domaine commencent par cette étape, où les concepteurs présentent l’objectif de leurs applications et

décrivent rapidement l’enchaînement des interactions entre l’utilisateur et les appareils.

Notre but à travers cette étape est que d’une part, le concepteur établisse une première idée sur le

fonctionnement de son application et que d’autre part il commence à réfléchir à la nature de l’environ-

nement où son application va s’exécuter, ainsi qu’aux différents équipements dont il aura besoin pour

la faire marcher.

4.1.2 Inventaire de l’équipement

A partir de la description du scénario de l’application, le concepteur débute cette étape. L’objectif

est d’arriver à lister rapidement et sans détailler les informations sur chaque équipement sur lequel va

s’exécuter un agent ambiant. Cette étape consiste à répondre aux préoccupations suivantes :

40

4.1. Fonctionnalités et outils de la plate-forme

Quels sont les appareils utilisés ?

Le concepteur énumère les types d’appareils qu’il va probablement utiliser. Pour chaque type d’ap-

pareil, il donne une description rapide de son fonctionnement. Le concepteur pourra aussi choisir ces

différents types parmi un ensemble d’appareils prédéfinis dans la plate-forme.

Existe-t-il des capteurs dans l’environnement ?

Le concepteur énumère les types de capteurs embarqués dans les types d’appareils choisis et ceux

qui seront probablement présents dans l’environnement de ces appareils. Notamment, il pourra les

choisir parmi un ensemble de capteurs prédéfinis dans la plate-forme. Lorsque le concepteur a choisi

les types d’appareils qu’il va utiliser parmi ceux qui sont prédéfinis, un assistant affichera dans cette

étape un ensemble de capteurs associés.

Existe-t-il des effecteurs dans l’environnement ?

Comme pour les capteurs, le concepteur énumère les types d’effecteurs qui pourront être contrôlés

par ces agents ambiants. Il pourra également choisir ceux-ci parmi un ensemble d’effecteurs prédéfinis

dans la plate-forme.

Quels moyens de communication utilisés ?

Le concepteur dresse la liste des moyens de communication utilisés. Il pourra aussi choisir ceux-ci à

partir d’une catégorie de moyens de communication prédéfinis dans la plate-forme. Parallèlement, un

assistant permettra de lister tous les moyens de communications relatifs aux appareils qu’il a sélection-

nés.

4.1.3 Modélisation des agents

Dans cette étape, la modélisation des agents ambiants est réalisée avec le langage de description de

micro-architecture µADL (voir Figure 4.2).

Pour cela, un onglet par type d’appareil établi dans l’étape précédente est ouvert pour concevoir le

modèle d’agent correspondant. Lorsque ce type d’appareil est choisi de la liste prédéfinie dans la plate-

forme, un ensemble d’informations concernant cet appareil vient enrichir cet onglet (sa fonctionnalité,

ses moyens de communications disponibles, ses capteurs, ses effecteurs, etc.). De plus, le concepteur

retrouve une liste de micro-composants prédéfinis à intégrer dans son modèle (cf. 4.2 Notre apport à

la plate-forme). Le concepteur pourra aussi modifier et enrichir les modèles ou en créer de nouveaux.

Pour cela il charge une nouvelle fenêtre dans l’éditeur µADL.

41


FIGURE 4.2 — Interface graphique de l’éditeur de micro-architecture µADL

4.1.4 Implémentation des agents

L’implémentation des agents ambiants est réalisée grâce au générateur d’API MAY. Les différents

micro-composants sont générés à partir des modèles établis dans l’étape précédente. Lorsqu’un micro-

composant est choisi parmi la liste des micro-composants prédéfinis, l’implémentation de ce dernier

est effectuée automatiquement. Par contre, lorsque celui-ci est nouveau, seul le squelette de son code

ainsi que les interfaces qui permettent de le relier au mediator (le connecteur de micro-composants) sont

générées par l’outil MAY. Dans ce dernier cas, le concepteur devra compléter son implémentation. Dans

la figure 4.3 nous présentons le code du squelette du micro-composant Neighbours (la liste des voisins

de l’agent, le voisinage étant défini par les moyens de perception de l’agent) sous Eclipse que devra

générer l’outil MAY.

Dans cette étape l’utilisateur complète aussi le niveau fonctionnel de ses agents. Pour cela la plate-

forme permet aussi de le guider. En effet, nous prévoyons la génération des squelettes de code de com-

portements spécifiques à l’intelligence ambiante et que nous avons présentés dans le troisième chapitre.

Par exemple, pour le comportement terminalBehaviour le squelette de code correspondant est une boucle

qui permet d’envoyer un message vers tous les voisins connus par un agent (fournis par le service get-

42

4.2. Notre apport à la plate-forme

FIGURE 4.3 — Capture d’écran du code du micro-composant Neighbours

Neighbours() du micro-composant Neighbours).

Dans cette étape, l’utilisateur insère également dans la partie fonctionnelle de ses agents les compor-

tements spécifiques à ses fonctionnalités désirées ou à son domaine d’application. En effet et à notre

connaissance, il reste difficile de prévoir et de modéliser tous les types d’appareils qu’un agent ambiant

peut être amené à représenter.

4.2 Notre apport à la plate-forme

Afin de faciliter la tâche de modélisation des agents ambiants au concepteur, nous avons modélisé

un ensemble de micro-composants spécifiques à l’intelligence ambiante. Ces micro-composants sont

catégorisés dans quatre groupes. Le premier groupe nommé Devices contient des micro-composants

nécessaires pour intégrer un agent ambiant dans un type d’appareil mobile (téléphone ou assistant

personnel PDA). Le deuxième groupe nommé Sensors contient des micro-composants permettant à

l’agent ambiant de capter des informations sur son environnement physique (capteur RFID, capteur

de température, capteur de fumée, capteur de géolocalisation, etc.). Le troisième groupe nommé Ac-

tuators contient les micro-composants nécessaires à l’agent ambiant pour agir sur son environnement

physique (émission d’un son ou d’un signal lumineux). Enfin, le quatrième groupe nommé Communi-

43


cations contient des micro-composants permettant à l’agent ambiant de communiquer (par BlueTooth

ou par WiFi).

Afin d’introduire ces micro-composants dans un modèle d’agent µADL, nous avons réalisé un outil

nommé Mucomponents Assistant(voir Figure 4.4).

FIGURE 4.4 — Interface graphique de l’outil Mucomponents Assistant

La figure 4.4 présente l’interface graphique de l’outil. Elle est partagée en quatre onglets (Devices,

Sensors, Actuators et Communications). Chaque onglet contient dans sa partie gauche une liste de micro-

composants prédéfinis et dans sa partie droite une liste vide. Cette liste vide contiendra les micro-

composants que le concepteur désire insérer dans son modèle.

Le concepteur commence par sélectionner le modèle auquel il veut insérer des micro-composants en

le choisissant dans la liste déroulante. Ensuite et en utilisant les boutons dans le centre de l’interface,

il remplit la liste vide correspondant à une catégorie de micro-composants. L’insertion définitive des

micro-composants se fait lorsque le concepteur clique sur le bouton Save and Exit. Dans ce cas, le résul-

tat de l’insertion est affiché sur l’interface graphique de l’éditeur µADL après la mise à jour du modèle

en appuyant sur la commande Refresh (voir Figure 4.5).

4.3 Analyse de la plate-forme

A la base µADL et MAY sont des outils destinés à la modélisation et à la génération d’agents en

général selon le style d’architecture en étoile. Ils ne sont pas réservés uniquement aux développements

d’agents ambiants. Nous incluons ces outils dans la plate-forme finale car ils sont faciles à manipuler et

permettent aux concepteurs de réaliser des agents ambiants sans partir de zéro. En effet, la modélisation

de l’agent avec µADL est quasi-intuitive. La séparation du niveau opératoire du niveau fonctionnel

permet de dégager les éléments permettant à l’agent d’interagir avec son environnement. A partir du

44

4.3. Analyse de la plate-forme

FIGURE 4.5 — Mise à jour du modèle PDAAgent pour visualiser l’insertion des

micro-composants sélectionnés dans l’outil Mucomponents Assistant

modèle établi, la génération des squelettes de code des micro-composants est faite automatiquement

par MAY. Cela permet déjà d’alléger la programmation.

La plate-forme en elle-même peut être vue selon deux niveaux : un bas niveau et un haut niveau.

Dans le bas niveau, le concepteur conçoit ses agents sans utiliser de modèles, ni de micro-composants

prédéfinis. C’est le cas lorsqu’il s’agit de nouveaux appareils, capteurs, effecteurs, moyens de commu-

nication... tous ce qu’il doit utiliser dans son application d’intelligence ambiante. Le haut niveau est le

plus important. En effet, une plate-forme de conception d’applications en intelligence ambiante doit né-

cessairement inclure des outils permettant de réaliser rapidement des agents ambiants. Ce niveau doit

donc comporter des agents ambiants semi-achevés (c’est-à-dire qu’il reste seulement au développeur à

compléter le squelette du code fonctionnel généré par la plate-forme). Des micro-composants prédéfinis

de communication BlueTooth, WiFi, des micro-composants de type capteurs RFID, capteurs de géolo-

calisation GPS car ces technologies sont les plus répondues et utilisées. Il faudra aussi que ce niveau

de la plate-forme contienne des outils permettant d’installer des agents ambiants sur des appareils mo-

biles (téléphones portables et assistant personnels PDA). Notamment, il faudra prévoir pour cela des

micro-composants capables d’accéder aux services de ces appareils (par exemple pour récupérer des

informations sur leurs autonomies). Également et d’une façon générale, lorsqu’on souhaite dévelop-

per des systèmes embarqués, il faut concevoir l’interface graphique de l’application (ou autres moyens

permettant l’interaction homme-machine). La plate-forme devra répondre aussi à cette contrainte et per-

45


mettre au développeur d’utiliser ce type d’interface ou du moins la capacité d’afficher des informations

sur des appareils mobiles.

En ce qui concerne le développement de la partie fonctionnelle des agents ambiants, le concepteur

pourra les programmer en suivant un guide contenant des explications sur les comportements spéci-

fiques que nous avons définis dans le chapitre 3 et en complétant des squelettes de codes. A ce niveau

le concepteur utilise aussi la méthode ADELFE afin d’affiner la conception du comportement de chaque

agent. Il identifie d’autres comportements coopératifs pour ses agents ambiants, recense les situations

de non coopération et la façon de les traiter en suivant les étapes spécifiques définies dans ADELFE.

4.4 Conclusion

Dans ce chapitre, nous avons présenté une étude de faisabilité de la plate-forme de conception d’ap-

plications en intelligence ambiante. Notre objectif est que cette plate-forme facilite le développement de

ce nouveau type d’application. Pour cela, nous nous sommes basés sur la technologie agent, la concep-

tion dirigée par les modèles et les outils d’ingénierie développée par l’équipe SMAC à savoir µADL et

MAY. Notre première contribution à cette plate-forme consiste à enrichir l’éditeur µADL par un outil

permettant d’insérer dans un modèle d’agent un ensemble de micro-composants, et par des modèles

spécifiques à notre domaine.

Dans le chapitre suivant, nous allons mettre en œuvre notre démarche de réalisation d’applications

en intelligence ambiante sur un exemple. Nous allons montrer l’adéquation du modèle de départ d’un

agent ambiant ainsi que les comportements spécifiés dans le chapitre 3 à travers un exemple d’applica-

tion en domotique.

46

5 Application et analyse

Dans ce cinquième chapitre j’illustre l’adéquation de notre modèle d’agent ambiant et de notre dé-

marche par la réalisation d’une application d’intelligence ambiante. Pour cela, nous reprenons le travail

réalisé dans le projet de TER Agents et Domotique 1 dans lequel un simulateur d’une maison automatisée

a été réalisé afin de gérer automatiquement la température de cette maison. Á la base, ce simulateur de

maison intelligente contient un seul acteur mobile développé en JavAct qui se déplace dans les pièces

de la maison. Son comportement consiste à augmenter ou à baisser la température des pièces afin d’at-

teindre celles programmées par un utilisateur. Pour cela, l’acteur peut activer ou désactiver les appareils

de chauffage et de climatisation. Il peut aussi fermer ou ouvrir les portes, les fenêtres et les volets.

Notre objectif est de remplacer cet acteur par un ensemble d’agents ambiants réalisés selon les

concepts établis dans le chapitre 3. De même, nous allons suivre la démarche de développement établie

dans le chapitre 4 et utiliser les outils de la plate-forme pour créer l’application d’intelligence ambiante

souhaitée.

5.1 Conception et réalisation de l’application

Pour réaliser les agents ambiants du simulateur, nous reprenons les quatre étapes de développement

d’une application d’intelligence ambiante.

5.1.1 Description du scénario envisagé pour l’application

L’application de domotique a pour objectif d’automatiser la gestion de la température d’une maison.

Les climatiseurs et les radiateurs captent la température de la pièce où ils sont installés et la température

externe grâce à des capteurs de température. De même, les portes, les volets et les fenêtres sont automa-

tisés : ils sont équipés de contrôleurs d’ouverture activant leur ouverture et leur fermeture et peuvent

aussi capter la température. Chaque habitant de cette maison dispose de son propre assistant personnel

PDA avec lequel il gère ses préférences de température.

La gestion automatique de cette température se réalise par l’ajustement des différents AmIDs (cli-

matiseurs, radiateurs, portes, fenêtres et volets) face aux variations de la température extérieure, de la

1. http ://noman.flabelline.com/ter-2007.html

47

Chapitre 5. Application et analyse

température intérieure et des préférences de chaque habitant.

5.1.2 Inventaire de l’équipement

Quels sont les appareils utilisés ?

Pour notre application de domotique nous prévoyons l’installation des agents ambiants sur quatre

types d’équipements : climatiseur, chauffage, assistant personnel PDA et contrôleur d’ouverture.

– Climatiseur : sa fonctionnalité principale est de refroidir la maison. Pour cela, il se met en marche et

s’éteint. Il est équipé d’un thermostat pour réguler sa puissance.

– Radiateur : sa fonctionnalité principale est de réchauffer la maison. Pour cela, il se met en marche et

s’éteint. Il est aussi équipé d’un thermostat pour réguler sa puissance.

– Assistant personnel PDA : il gère les données personnelles de son utilisateur et contient également

ses préférences de température.

– Contrôleur d’ouverture : ce dispositif permet de contrôler l’ouverture et la fermeture d’une porte,

d’une fenêtre ou d’un volet.

Existe-t-il des capteurs dans l’environnement ?

Pour notre application de domotique, nous avons besoin de capteurs de température installés sur les

climatiseurs, les chauffages et équipant les contrôleurs d’ouverture situés dans les fenêtres, les volets et

les portes d’entrées de la maison.

Existe-t-il des effecteurs dans l’environnement ?

Les agents ambiants embarqués dans les climatiseurs et les chauffages contrôlent leur fonctionne-

ment. Un agent ambiant embarqué dans un climatiseur peut l’activer, l’arrêter ou ajuster son thermostat.

De même, un agent ambiant embarqué sur un chauffage peut l’activer, l’arrêter ou ajuster son thermo-

stat. Enfin, un agent ambiant embarqué sur un contrôleur d’ouverture peut ouvrir ou fermer une porte,

une fenêtre ou un volet.

Quels moyens de communication utilisés ?

Pour notre expérimentation nous supposons que les agents ambiants communiquent par BlueTooth.

En terme de simulation cela se traduit par le fait qu’un climatiseur, qu’un chauffage, qu’un PDA ou

qu’un contrôleur d’ouverture ne communique qu’avec les appareils qui sont dans la même pièce que

lui.

5.1.3 Modélisation des agents

Dans cette partie nous présentons les trois modèles d’agents ambiants en µADL. Pour cela, nous

sommes partis du modèle de départ d’un agent ambiant et nous l’avons affiné.

48

5.1. Conception et réalisation de l’application

Modèle de l’agent ambiant pour les climatiseurs et les chauffages

Cet agent ambiant comporte neuf micro-composants (voir Figure 5.1). Pour le réaliser, nous avons

utilisé les micro-composants MailBox, Send, Neighbours et LifeCycle du modèle de départ, nous avons

ajouté le micro-composant BlueTooth et TempSensor et affiné les micro-composants Acquaintances, Repre-

sentations, DeviceService (qui devient ThermicComponent) et Sensor (qui devient TempSensor). Nous dé-

taillons ici les nouveaux micro-composants et les micro-composants affinés.

FIGURE 5.1 — Modèle de l’agent ambiant pour les chauffages et les climatiseurs

Pour interagir avec les autres agents, l’agent ambiant utilise les services sendWithBlueTooth() et recei-

veWithBlueTooth() du micro-composant BlueTooth. Pour capter la température, l’agent dispose du micro-

composant TempSensor. Celui-ci fournit le service getCurrentTemp() qui permet à l’agent de capter la

température de la pièce où il se trouve et le service getExternTemp() pour capter la température externe.

Pour contrôler un climatiseur ou un chauffage, l’agent possède le micro-composant ThermicCom-

ponent. Celui-ci fournit le service open() et close() pour allumer et éteindre l’appareil, le service adjustTher-

mostat() pour ajuster le thermostat de l’appareil et getStateofDevice() pour récupérer l’état de l’appareil

(allumé ou éteint).

Le micro-composant Representations fournit à l’agent le service getThermostatValue() qui renvoie la

valeur du thermostat, le service getStateOfDevice() qui renseigne sur l’état actuel de l’appareil, le service

deviceDescription() qui renseigne l’agent sur le type de l’appareil (climatiseur ou chauffage). Les services

49


getPreferenceTemp() et setPreferenceTemp() permettent de gérer la température demandée par un utilisa-

teur.

Pour gérer ses connaissances sur les autres agents, l’agent ambiant dispose du micro-composant

Acquaintances et Neighbours. Le micro-composant Acquaintances fournit le service addCharacteristic() qui

permet d’ajouter une nouvelle connaissance à l’agent. Il fournit aussi le service getAgentHaveCompe-

tence() qui renvoie à l’agent une référence d’un deuxième agent ayant une compétence demandée par le

premier agent et updateCompetence() qui permet de mettre à jour la compétence de cet agent. Le service

getAllActiveAgent() fournit à l’agent les références des autres agents actifs qui sont parmi ses accoin-

tances (c’est-à-dire qu’ils sont des agents avoisinants et actifs dans son environnement). Enfin, le service

isActive() permet de vérifier si un agent parmi les accointances de l’agent est présent dans son environ-

nement avoisinant.

Modèle de l’agent ambiant pour les portes, les fenêtres et les volets

Comme pour le modèle précédent, nous avons proposé neuf micro-composants pour ce modèle

d’agent ambiant (voir Figure 5.2). Nous avons également utilisé les micro-composants MailBox, Send,

Neighbours et LifeCycle, ajouté le micro-composant BlueTooth et affiné les micro-composants Acquain-

tances, Representations, Sensor (qui devient TempSensor) et DeviseService (qui devient ControlerComponent).

Le micro-composant ControlerComponent permet à l’agent ambiant de contrôler une porte, une fe-

nêtre ou un volet. Il fournit le service open() et close() pour ouvrir et fermer le composant et le service

getStateofComponent() qui renvoie l’état du composant (ouvert ou fermé).

Le micro-composant Representations fournit à l’agent le service getStateOfComponent() qui renseigne

l’agent sur l’état actuel du composant, le service ComponentDescription() qui renseigne l’agent sur le

type du composant (porte, fenêtre, ou volet.). Les services getPreferenceTemp() et setPreferenceTemp() per-

mettent de gérer la température demandée par un utilisateur. Les micro-composants Acquaintances,

TempSensor et BlueTooth sont les mêmes que ceux du premier modèle.

Modèle de l’agent ambiant pour le PDA

Le modèle de l’agent PDA comporte huit micro-composants (voir Figure 5.3). Il contient les micro-

composants Neighbours, MailBox, Send et LifeCycle de notre modèle de départ. Les micro-composants

Representations, Acquaintances et DeviceService (qui devient PDA) sont affinés. Le micro-composant Blue-

Tooth est ajouté au modèle. L’agent ambiant accède au service de gestion des préférences de tempéra-

tures du PDA en utilisant le service getServiceOfPDA() du micro-composant PDA. Le micro-composant

Representations fournit le service getPreferenceTemp() qui retourne la température désirée par l’utilisateur,

celle-ci est récupérée grâce au service getServiceOfPDA(). De même et comme pour les deux premiers

modèles, les micro-composants Acquaintances et BlueTooth restent identiques.

50

5.1. Conception et réalisation de l’application

FIGURE 5.2 — Modèle de l’agent ambiant pour les portes, les fenêtres et les volets

5.1.4 Implémentation des agents

Dans cette étape nous avons réalisé l’implémentation des trois modèles avec l’outil MAY.

Les micro-composants MailBox, Send, LifeCycle et Receive sont déjà fournis par cet outil ce qui a permis

d’alléger la tâche de création des micro-composants. Pour les autres micro-composants à savoir : Neigh-

bours, Representations, Acquaintances, TempSensor, ThermicComponent, PDA, et ControlerComponent nous

avons réaliser leurs implémentations. Ensuite, MAY effectue la génération automatique du Mediator

c’est-à-dire la classe qui permet de rassembler les différents micro-composants et la classe QuasiBehavior

qui fournit au niveau fonctionnel de l’agent les services proposés par les micro-composants.

Dans cette étape nous avons aussi implémenté et testé quelques comportements coopératifs des

agents ambiants. En effet, nous avons doté ces agents du comportement de présentation, du comporte-

ment terminal, du comportement nominal et du comportement d’aide.

– Le comportement de présentation (PresentationBehavior()) permet à un agent d’envoyer à ses agents

avoisinants un message de présentation (MsgPresentation()) contenant ses caractéristiques (Charac-

teristic).

– Le comportement terminal (TerminalBehavior()) permet à un agent PDA d’envoyer un message

terminal (TerminalMessage) à ses agents avoisinants pour les prévenir de sa disparition.

– Le comportement nominal des agents ambiants climatiseur, chauffage et contrôleur de composant

consiste à maintenir une température constante dans une pièce. Pour cela, ils perçoivent la tempé-

rature actuelle d’une pièce en utilisant le service getCurrentTemp() et la température externe avec le

51


FIGURE 5.3 — Modèle de l’agent ambiant pour le PDA

service getExternTemp(). En fonction de la température désirée par un utilisateur et de la présence

ou pas de ce dernier dans une pièce, ils décident de l’action à effectuer.

– Le comportement nominal d’un agent PDA consiste à prévenir les autres agents avoisinants du

changement de la valeur de la température désirée par l’utilisateur.

– Le comportement d’aide des agents chauffage, climatiseur et contrôleur d’ouverture consiste à

accepter les demandes de changement de température reçues des agents PDA afin de satisfaire le

besoin de l’utilisateur.

5.2 Analyse

Ce premier test de notre modèle d’agent ambiant, de certains comportements d’un agent ambiant

et des outils de la plate-forme de conception d’applications d’intelligence ambiante, nous a permis de

réaliser une première application d’intelligence ambiante en environnement simulé (voir Figure 5.4).

Nous dégageons quelques résultats sur notre modèle, sur les comportements testés, ainsi que sur la

plate-forme et ses outils.

Sur le modèle de l’agent ambiant :

Nous avons utilisé notre modèle d’agent ambiant pour réaliser l’application de gestion automa-

tique de la température d’une maison. En affinant celui-ci (en ajoutant et en substituant des micro-

composants) nous avons dégagé trois modèles d’agents correspondant à notre besoin.

52

5.2. Analyse

FIGURE 5.4 — Interface graphique du simulateur de la maison intelligente

Cependant, la question de la séparation entre le niveau opératoire et le niveau fonctionnel de l’agent

reste ouverte. En effet, au moment de modéliser les agents nous nous sommes confrontés à cette ques-

tion. Les micro-composants Representations et Acquaintances par exemple contiennent des traitements à la

fois du niveau opératoire et du niveau fonctionnel. Des réfléxions devront être menées et la plate-forme

devra assister le concepteur dans ces choix.

La question du niveau de décomposition d’un micro-composant s’est également posée. Par exemple,

nous aurions pu décomposer le micro-composant BlueTooth en deux micro-composants : un contenant le

service d’envoi de message sendWithBlueTooth() et un autre contenant le service de réception de message

receiveWithBlueTooth(). Il en est de même pour le micro-composant DeviceService en affectant chaque ser-

vice fourni par un Device à un micro-composant unique. Cette vision a pour but de fournir des micro-

composants les plus atomiques possibles pour pouvoir les utiliser et les modifier le plus simplement

possible. Cependant, modéliser des agents d’une telle manière compliquerait la tâche du concepteur. En

effet et compte tenu de la richesse d’un environnement d’intelligence ambiante (en terme de capteurs,

effecteurs, appareillages, etc.) le concepteur sera amené à créer des modèles incompréhensibles conte-

nant des dizaines de micro-composants. Nous pensons ainsi qu’il est plus intéressant de regrouper à un

certain niveau des micro-composants afin d’alléger le modèle.

53


Sur les comportements de l’agent ambiant :

Dans cette expérience nous avons mis en valeur le développement de quatres comportements d’un

agent ambiant à savoir : le comportement nominal, le comportement de présentation, le comportement

d’aide et le comportement terminal. Ces comportements de base nous ont permis de faire fonction-

ner l’agent d’une manière acceptable (par exemple, lorsqu’il fait suffisamment froid à l’extérieur de la

maison le climatiseur ne doit pas s’allumer pour refroidir une pièce). Cependant, il reste encore à dé-

velopper les autres comportements afin de pouvoir tester les agents ambiants dans des situations plus

réalistes et plus compliquées et observer concrètement les mécanismes d’auto-organisation conduisant

à l’émergence de fonctionnalités collectives des agents ambiants.

Sur la plate-forme de conception d’application d’intelligence ambiante :

Il est incontestable que le développement des agents ambiants et à terme des applications d’intel-

ligence ambiante concrètes nécessite un ensemble d’outillages, de modèles, de guides, etc. Dans notre

exemple d’application, nous avons mis en valeur les outils µADL, MAY et notre processus de dévelop-

pement d’une application d’intelligence ambiante pour répondre à ce besoin. En utilisant ces outils et

en suivant les étapes de l’activité de développement des agents ambiants, nous avons implémenté en

peu de temps les trois modèles d’agents et testé l’application souhaitée. Par contre, nous n’avons pas

pu tester la communication par BlueTooth entre agents. Á l’heure actuelle la plate-forme n’offre pas ce

micro-composant et il faut donc le prévoir à l’avenir, ainsi que d’autres types de micro-composants pour

le domaine.

5.3 Conclusion

Dans ce chapitre nous avons mis en œuvre le processus de conception d’une application d’intelli-

gence ambiante à travers un exemple d’application en domotique. Nos objectifs étaient de concevoir

des agents ambiants en utilisant les outils de la plate-forme et de montrer la validité de notre modèle

d’agent ambiant ainsi que quelques comportements coopératifs des agents ambiants.

Il reste cependant plusieurs tests à réaliser. Il faut prévoir la réalisation concrète d’une application

d’intelligence ambiante en utilisant les outils de la plate-forme afin de tester d’avantage leur pertinence.

Actuellement, nous n’avons mis en œuvre que quatre comportements basiques d’un agent ambiant.

La prochaine étape consiste donc à implémenter les autres comportements et les mécanismes d’auto-

organisation pour étudier l’intelligence ambiante émergente.

54

Conclusion

Bilan

L’intelligence ambiante est certainement un domaine très ambitieux et prometteur où la technologie

des systèmes multi-agents en général et la théorie des AMAS en particulier permettent de contibuer aux

bases des systèmes ambiants de l’avenir.

Dans ce travail, mes objectifs principaux étaient doubles. D’une part, la proposition de solutions

pour concevoir des agents d’intelligence ambiante en se basant sur les concepts d’agents coopéra-

tifs, la résolution de situation non-coopératives et les mécanismes d’auto-organisation étudiés dans

l’équipe SMAC. D’autre part, l’étude d’une plate-forme de conception d’applications en intelligence

ambiante intégrant les outils développés par l’équipe SMAC, à savoir le langage de description de

micro-architecture µADL et le générateur d’API dédiés MAY.

Au cours de ce travail, il a été difficile de dégager des solutions génériques. En effet, j’ai montré dans

l’état de l’art l’étendue des domaines d’applications de l’intelligence ambiante. Il était donc nécessaire

pour nous de se référer aux travaux antérieurs du domaine afin de dégager des solutions intrinsèques.

Notre étude nous a permis de produire un premier modèle d’agent ambiant qui pourra conduire par

des études approfondies à un modèle plus épuré auquel peuvent se rajouter d’autres modèles plus

spécifiques. L’étude de la plate-forme nous a permis de valider le modèle de l’agent ambiant et quelques

comportements que nous avons établis à travers un exemple d’application de domotique. Cela nous a

également permis de tester les outils µADL et MAY afin de montrer leurs apports à cette plate-forme.

Perspectives

Il reste cependant certaines améliorations à apporter à ce travail. En effet, cette étude représente

une première étape vers la mise au point d’une plate-forme de conception d’applications en intelligence

ambiante. Pour des raisons de temps, nous nous sommes restreint à son analyse et à dégager ses outils

et un processus de développement associé. La prochaine étape serait de développer cette plate-forme.

Aussi, il est important d’approfondir encore plus l’étude sur les agents ambiants. Notamment, réfléchir

à d’autres situations de non-coopérations et d’autres comportements coopératifs.

Au final, notre but est que cette intelligence ambiante soit émergente. Ainsi la conception des agents

55

Conclusion

ambiants ne doit pas être guidée par une finalité trop applicative rendrant ses agents efficaces unique-

ment dans des situations trop restreintes. Pour ce challenge, des tests en situations réelles permettront

de valider un ensemble plus complet de mécanismes d’auto-organisations et de comportements coopé-

ratifs.

56

Bibliographie

Jean-Paul ARCANGELI et Sébastien LERICHE : Construction d’agents auto-adaptatifs à base de micro-composants opératoires. In Valérie CAMPS et Philippe MATHIEU, éditeurs : Journées Francophones desSystèmes Multi-Agents, Carcassonne, 17/10/2007-19/10/2007, pages 75–84. Cépaduès Editions, octobre2007.

Carole BERNON, Marie-Pierre GLEIZES, Gauthier PICARD et Pierre GLIZE : The Adelfe Methodology foran Intranet System Design. In P GIORGINI, Y LESPÉRANCE, G WAGNER et E YU, éditeurs : InternationalBi-Conferenystems (AOIS-2002) at CAice Workshop on Agent-Oriented Information SSE’02 (AOIS - SSE),Toronto, Ontario, Canada, 27/05/02-28/05/02. CEUR Workshop Proceedings, mai 2002.

Yasmine CHARIF et Nicolas SABOURET : An agent interaction protocol for ambient intelligence. In 2ndInternational Conference on Intelligent Environments Athens, Greece, pages 275–284. IET, 12 2006a.

Yasmine CHARIF et Nicolas SABOURET : Protocole d’interaction pour la composition de services dansl’intelligence ambiante. In 14es Journées Francophones sur les Systèmes Multi-Agents Annecy, France,pages 253–266. Hermès, 2006b.

Daniel CHEUNG, Jean-Yves TIGLI, Stéphane LAVIROTTE et Michel RIVEILL : Wcomp : a multi-designapproach for prototyping applications using heterogeneous resources. rsp, 0:119–125, 2006. ISSN1074-6005.

Rita CUCCHIARA, Andrea PRATI, Cesare OSTI et Stefano PAVANI : Ambient intelligence in urban envi-ronments. In Atti del Workshop on "Ambient Intelligence", Nono Convegno della Associazione Italiana perl’Intelligenza Artificiale, septembre 2005.

Juan M. Sánchez Juan M. Corchado DANTE I. TAPIA, Javier Bajo : An Ambient Intelligence Based Multi-Agent Architecture, chapitre 7, pages 68–78. Paris, 2008. ISBN 978-2-287-78543-6.

Giovanna DI MARZO SERUGENDO, Marie-Pierre GLEIZES et Anthony KARAGEORGOS : Self-Organisation in Multi-Agent System . Rapport de recherche IRIT/2005-18-R, IRIT, Université PaulSabatier, Toulouse, 2005.

J. FERBER : Les systèmes multi-agents : vers une intelligence collective. Informatique, Intelligence Artificielle.InterÉditions, 1995.

Luca FERRARI, Giacomo CABRI et Franco ZAMBONELLI : Agents and Ambient Intelligence : the LAICAExperience. In The 5th International Symposium From Agent Theory to Agent Implementation at the 18thEuropean Meeting on Cybernetics and Systems Research (EMCSR 2006),Wien, April 2006.

Jean-Pierre GEORGÉ : Résolution de problèmes par émergence, Etude d’un Environnement de Programmationémergente. Thèse de doctorat, Université Paul Sabatier, Toulouse, France, juillet 2004.

Jean-Pierre GEORGÉ, Valérie CAMPS, Marie-Pierre GLEIZES et Pierre GLIZE : Ambient Intelligence asa Never-Ending Self-Organizing Process : Analysis and Experiments. In Artificial and Ambient In-telligence convention (Artificial Societies for Ambient Intelligence) (AISB (ASAMi)), Newcastle University,

57

Bibliographie

Newcastle upon Tyne, UK, 02/04/07-04/04/07. The Society for the Study of Artificial Intelligence andSimulation of Behaviour, avril 2007.

Marie-Pierre GLEIZES : Vers la résolution de problèmes par émergence. Habilitation à diriger des recherches,Université Paul Sabatier, Toulouse, France, décembre 2004.

Pierre GLIZE : L’Adaptation des Systemes a Fonctionnalite Emergente par Auto-Organisation Cooperative.Habilitation à diriger des recherches, Université Paul Sabatier, Toulouse, France, juin 2001.

Vincent HOURDIN, Daniel CHEUNG-FOO-WO, Stéphane LAVIROTTE et Jean-Yves TIGLI : UbiquariumInformatique : Une plate-forme pour l’étude des équipements informatiques mobiles en environne-ment simulé. In Troisième Journées Francophones Mobilité et Ubiquité (UbiMob), Paris, France, septembre2006.

Ducatel ISTAG : Scenarios for ambient intelligence in 2010. Rapport technique, Institute for ProspectiveTechnological Studies (IPTS), Seville, 2001.

Ducatel ISTAG : Ambient intelligence : from vision to reality. Rapport technique, Information SocietyTechnologies Advisory Group (ISTAG), 2003.

Cory D. KIDD, Robert ORR, Gregory D. ABOWD, Christopher G. ATKESON, Irfan A. ESSA, Blair MA-CINTYRE, Elizabeth D. MYNATT, Thad STARNER et Wendy NEWSTETTER : The aware home : A livinglaboratory for ubiquitous computing research. In Cooperative Buildings, pages 191–198, 1999.

Sébastien LERICHE : Architectures à composants et agents pour la conception d’applications réparties adaptables.Thèse de doctorat, Université Paul Sabatier, Toulouse, France, décembre 2006.

Achilles Kameas ;Irene Mavrommati ;Panos MARKOPOULOS : Computing in tangible : using artifacts ascomponents of ambient intelligence environments, pages 121–142. IOS Press, 2004.

Jean-Paul Sansonnet NICOLAS SABOURET : Traitement de requêtes de bon sens sur les actions pourl’interaction homme-machine. In Philippe Mathieu ANDREAS HERZIG, Brahim Chaib-draa, éditeur :Modèles formels de l’interaction, Actes des Secondes Journées Francophones, pages 209–218. Cépaduès, 2003.ISBN 2-85428-622-7.

G. PICARD : Méthodologie de développement de systèmes multi-agents adaptatifs et conception de logiciels àfonctionnalité émergente. Thèse de doctorat, UPS Toulouse 3, Décembre 2004.

Sylvain ROUGEMAILLE, Frédéric MIGEON, Christine MAUREL et Marie-Pierre GLEIZES : Model DrivenEngineering for Designing Adaptive Multi-Agent Systems. In International Workshop on EngineeringSocieties in the Agents World (ESAW), Athens, Greece, 22/10/07-24/10/07. Springer, 2007.

Mathieu VALLÉE, Laurent VERCOUTER et Fano RAMPARANY : Composition flexible de services d’objetscommunicants pour la communication ambiante. In Journés Francophones sur les Systèmes Multi-Agents(JFSMA’06), Annecy, France, October 2006.

Mark WEISER : Hot Topics : Ubiquitous Computing. IEEE Computer, octobre 1993a.

Mark WEISER : Some computer science issues in ubiquitous computing. Commun. ACM, 36(7):75–84,1993b. ISSN 0001-0782.

58

Documents

Intelligence ambiante : étude d’une approche par auto ... · adaptatifs en intelligence ambiante en utilisant les concepts d’agents coopératifs et de mécanismes d’auto-organisation