Description de comportements d agents autonomes évoluant dans des mondes virtuels

Transcription

1 Thèse présentée pour obtenir le grade de docteur de l École Nationale Supérieure des Télécommunications Spécialité : Informatique et Réseaux Description de comportements d agents autonomes évoluant dans des mondes virtuels Nadine Richard Composition du jury : Frédéric Boussinot, CMA (INRIA/EMP) - Président Marc Cavazza, University of Teesside - Rapporteur Jean-Pierre Jessel, IRIT - Rapporteur Alexis Drogoul, LIP6 - Examinateur Philippe Codognet, LIP6 - Directeur de thèse Alain Grumbach, ENST - Co-directeur de thèse

2 2

3 À Roger Blanc, mon grand-père adoré, homme attentionné, réservé et généreux, qui attendait avec impatience la fin de cette thèse mais qui n a pas eu la force de m accompagner jusqu au bout. 3

4 4

5 Remerciements Je tiens à remercier les personnes qui m ont offert l opportunité d effectuer cette thèse dans les meilleures conditions. En tout premier lieu, je remercie Philippe Codognet et Alain Grumbach, qui ont su me guider avec patience et gentillesse, qui m ont fait profiter de leur grande expérience, qui m ont fait partager leur passion pour l art numérique, et avec qui j ai eu de nombreuses discussions enrichissantes à tout point de vue. Je remercie également les différents laboratoires qui m ont accueillie chaleureusement : le Département Informatique et Réseaux de l ENST, au sein duquel j ai réalisé mes travaux dans des conditions particulièrement agréables, tant sur le plan logistique que sur le plan humain ; l INRIA, qui m a accordé un financement de trois ans pour effectuer ma thèse au sein du projet LOCO (devenu projet CONTRAINTES) ; le thème OASIS du LIP6, en particulier l équipe MIRIAD et l AnimatLab, qui m ont accueillie comme membre à part entière de leurs laboratoires. Je tiens également à remercier ceux qui m ont fait l honneur d accepter de participer au jury de soutenance : Marc Cavazza et Jean-Pierre Jessel, qui ont assumé la lourde tâche de rapporteur ; Frédéric Boussinot, dont les travaux ont en partie inspiré le langage MARVIN, et Alexis Drogoul, grâce à qui j ai un jour envisagé de faire une thèse. Je tiens ensuite à exprimer ma reconnaissance à tous ceux qui ont eu le courage et la patience de relire ce manuscrit, et grâce à qui il a pu être sensiblement amélioré : Pierre Beyssac (ENST), Jean-Jacques Bourdin (Paris VIII), Emmanuel Chailloux (Paris VII), Jean-Louis Dessalles (ENST), Guillaume Moreau (École des Mines de Paris), et tout particulièrement Samuel Tardieu (ENST). Merci aussi à ceux qui m ont aidée tout au long de cette aventure, et en particulier à Isabelle Demeure pour son aide précieuse et ses conseils avisés, à Olivier Hainque pour les cours particuliers d ESTEREL, à Olivier Hudry pour les cours particuliers d algorithmie des graphes, à Thomas Quinot alias L A TEX master, à Hayette Soussou toujours prête à rendre service (et avec le sourire, s il vous plaît). Un grand merci également à ceux qui m ont rendu la vie au bureau agréable, même dans les pires moments : Laleh et Jean-Louis pour les pauses thé rafraîchissantes et stimulantes à la fois, François qui a réponse à tout, Didier pour le soutien des premiers mois, Laurent pour le soutien (mutuel) des derniers mois, Jean-Philippe et Romain qui ont fait l intense expérience de la fin de thèse avant même de commencer la leur. 5

6 6 Enfin, je remercie ma famille pour leur confiance et pour leur soutien constant malgré notre éloignement, ainsi que mes amis (Lyonnais, Parisiens, Visiteurs du Mercredi et tous les autres) et ma «belle-famille» pour leur patience et leur compréhension face à mes absences répétées. Merci à Nicolas, Alexis et surtout, surtout à Sam.

7 Résumé Les mondes virtuels habités sont des applications de Réalité Virtuelle dans lesquelles interagissent des entités autonomes et des utilisateurs représentés par leur avatar. De nombreux outils sont maintenant disponibles pour créer des mondes virtuels multi-utilisateurs, centrés sur l interaction avec les autres utilisateurs. Peu de ces outils permettent cependant de décrire facilement les comportements des entités autonomes peuplant les mondes virtuels. Nous avons choisi de nous concentrer sur l aspect comportemental de la création de mondes virtuels, nous rapprochant en ce sens des travaux de F. Harrouet concernant l environnement de développement ORIS. Notre objectif, à terme, est de fournir des outils facilitant la description de comportements d agents virtuels. Ces outils formeront l atelier INVIWO (Intuitive Virtual Worlds), accessible à un public ne possédant pas obligatoirement des connaissances en programmation (artistes, scénaristes de jeux vidéos, biologistes, etc.). Le travail présenté dans ce mémoire pose les bases de cet atelier. Nous avons choisi de considérer un monde virtuel habité comme un système multiagents homogène, dans lequel certains agents (les avatars) peuvent être contrôlés par des opérateurs humains. Tout objet d un monde INVIWO est ainsi un agent, capable de percevoir tout ou partie du monde, puis de réagir aux événements en effectuant des actions sur le monde en fonction de son état interne et de ses motivations. Nous proposons une architecture générique d agent virtuel, la plus simple possible. Un agent est ainsi composé : d attributs qui le caractérisent ; de capteurs, associés à des filtres, permettant à l agent de percevoir les modifications de son environnement et de son état interne ; d un organe de décision proposant des actions à réaliser ; d effecteurs, associés à des arbitres, chargés de réaliser les actions choisies. Il est possible d ajouter ou de retirer chacun de ces composants au cours de la vie de l agent, la structure d un agent INVIWO est donc entièrement dynamique. Concernant l organe de décision d un agent INVIWO, nous avons défini une architecture de sélection de l action distribuée, basée sur des modules comportementaux réactifs et concurrents, et sur un mécanisme d arbitrage permettant de combiner les décisions prises par les différents modules. À chaque pas d exécution de l agent, les modules comportementaux réagissent aux événements internes et externes en proposant des actions aux arbitres. Chaque arbitre choisit ensuite parmi ou à partir des propositions reçues les actions que les effecteurs devront finalement réaliser à la fin du pas de temps. Les arbitres encapsulent des méthodes de sélection plus ou moins complexes (d une simple moyenne des valeurs proposées à un réseau de neurones par exemple). 7

8 8 Le réseau dynamique formé par les modules comportementaux fonctionne selon le modèle réactif synchrone, en s inspirant en particulier du langage ESTEREL. Pour décrire la partie réactive des modules comportementaux, nous avons défini le langage MARVIN, proche d ESTEREL. Nous y avons ajouté des caractéristiques orientées-objets et orientées-agents, permettant de décrire entièrement un agent IN- VIWO. Nous avons de plus introduit la notion de contraintes dans notre langage, notamment sous la forme de contraintes-buts, telles que définies par P. Codognet. Nous avons développé une plate-forme d exécution d agents INVIWO, puis testé ce prototype sur plusieurs exemples. Le comportement d un agent peut être spécifié en utilisant le langage MARVIN, mais nous n avons pas encore intégré d interpréteur à la plate-forme.

9 Table des matières I Introduction 17 1 Introduction Décrire des comportements d agents virtuels Motivations Contribution Mondes et agents INVIWO Architecture de sélection de l action MARVIN Contraintes et comportements d agents Organisation du mémoire II Définitions et état de l art 27 2 Agents autonomes et systèmes multi-agents Introduction Caractéristiques d un agent Autonomie Environnement Comportement adaptatif Intelligence Sociabilité Perception Perception interne et perception externe Modularité Niveau d abstraction Action et interaction Action Communication Actions sur l environnement Connaissances Catégories de connaissances Représentation de l environnement La conception de systèmes multi-agents ZEUS (H. Nwana et al.) AGENTBUILDER ORIS (F. Harrouet) MADKIT (O. Gutknecht)

10 10 TABLE DES MATIÈRES 2.7 Synthèse Le problème de la sélection de l action Introduction L approche «orientée-comportements» Architectures basées sur les comportements L animation comportementale L architecture de subsomption Les schèmes moteurs de R. Arkin L architecture ascendante de P. Maes DAMN L architecture de B. Blumberg Boucle SCA et PAT-NETS Le modèle HPTS Les systèmes dynamiques Synthèse Stratégies de coordination Mécanismes comportementaux Systèmes et langages réactifs synchrones Introduction Approche synchrone pour les systèmes réactifs Systèmes transformationnels, interactifs et réactifs Systèmes réactifs temps-réel Approches traditionnelles Approche réactive synchrone Langages et outils Le langage ESTEREL Principes du langage Modules Signaux Manipulation de données Signaux valués et capteurs Préemption Exceptions Composition de modules Tâches asynchrones Compilation d un programme ESTEREL Machine d exécution Réseaux de processus réactifs Objets synchrones et objets réactifs Objets synchrones Objets réactifs Synthèse III Le modèle INVIWO 89 5 Agents et mondes INVIWO Introduction

11 TABLE DES MATIÈRES Interaction et communication Composants d un agent InViWo Attributs Processus de décision Capteurs et effecteurs Le cas de la perception active Filtrage et arbitrage Capteurs et filtres Effecteurs et arbitres Synthèse Avatars INVIWO Introduction Définition classique de l avatar Le système d interaction L avatar L avatar INVIWO Incarner l utilisateur Assister et contraindre l utilisateur Interfaces utilisateurs Synthèse IV Décrire des comportements d agents virtuels Les modules comportementaux Introduction Structure d un module comportemental Interface et structure interne d un module Modules et sous-modules Signaux et canaux Manipulation de signaux en sortie Envoi unique et réception multiple Chaîne de réaction Interaction avec les autres composants Gestion du temps Arbitrage et gestion des priorités Ordonnancement de l exécution des modules Ordonnancement initial des modules comportementaux Ajout d un canal Ajout d un module comportemental Retrait d un canal Retrait d un module comportemental Circuits, retards et problèmes de causalité Synthèse

12 12 TABLE DES MATIÈRES 8 Le langage MARVIN Introduction Agents et objets Comparaison Objets prédéfinis Les modules comportementaux Les règles réactives Les blocs de règles réactives Les signaux valués Avortement Trappes Capteurs et effecteurs Protocoles d interaction Réception multiple de signaux Définition d un capteur Définition d un effecteur Définition de canaux Sous-modules Faire un pas Se déplacer jusqu à une position donnée Se déplacer aléatoirement Définition de mondes, d agents et d avatars Un agent autonome Un avatar semi-autonome Un monde INVIWO Synthèse Contraintes et comportements d agents Introduction Contraintes : résolution et programmation Contraintes-buts et recherche adaptative Contraintes et agents INVIWO Contraintes-buts Agents-contraintes Autres applications Synthèse V Résultats Implémentation et exemples Introduction MARVIN en JAVA Types et objets prédéfinis Instructions Composants comportementaux Les agents Expressions et instructions retardées Règles réactives Blocs de règles

13 TABLE DES MATIÈRES Couche de communication Un exemple complet Les protocoles d interaction L agent mobile L agent immobile L avatar Synthèse VI Conclusion et perspectives Conclusion Perspectives 199 VII Annexes 203 A Grammaire du langage MARVIN 205 B Traduction en Java d exemples en MARVIN 215 B.1 Factorielle B.2 Bizarre love triangle VIII Bibliographie 231

14 14 TABLE DES MATIÈRES

15 Table des figures 1.1 L aquarium du Diamond Park Le monde des lapins Architecture typique d agent hybride Principes du système perceptif d un agent La perception classique La perception modulaire La fusion de percepts Distinction entre la communication et l interaction avec l environnement Synthèse des caractéristiques d un agent autonome Exemple d architecture de subsomption sur 3 niveaux Exemple de schèmes moteurs et de schèmes de perception Exemple d architecture ascendante (tiré de [135]) Exemple d arbitre DAMN Exemple de comportement, selon l architecture de B. Blumberg Schéma général de la mise en œuvre de systèmes comportementaux Exécution d un système de type transformationnel Exécution d un système de type interactif Exécution d un système de type réactif Un exemple d exécution d un système synchrone Attente concurrente et émission de signaux De l importance des délimiteurs de blocs Représentation de l interface d un module ESTEREL Premier module et premières instructions réactives Manipulation des valeurs de signaux Combinaison de signaux de sortie Suspension sur réception de signal Avortement fort sur réception de signal Avortement faible sur réception de signal Levée d exception Exemple de composition de modules avec substitution de signaux Exemple de composition de modules utilisant un signal local Exemple de correspondance ESTEREL/C Principes d une machine d exécution pour ESTEREL Communication entre objets synchrones ou réactifs Interaction et communication, telles que présentées dans le chapitre

16 16 TABLE DES FIGURES 5.2 Interaction et communication pour un agent INVIWO Un monde INVIWO composé de trois agents Les composants d un agent INVIWO et leurs principales interactions Détail des interactions entre composants d un agent INVIWO Capteur couplé à un filtre Effecteur couplé à un arbitre Architecture synthétique d un agent INVIWO Le système d interaction Une discussion entre avatars au café du Diamond Park L avatar classique L avatar INVIWO Extension du modèle de capteur Extension du modèle d effecteur Avatar INVIWO et interface utilisateur Interface d un module comportemental Structure interne d un module comportemental Exemple d encapsulation d un réseau comportemental Communication entre un module-père et un module-fils Un exemple de chaîne de réaction Exemple d interaction avec un attribut Quatre solutions pour gérer les priorités Exemple d ordonnancement de modules comportementaux Exemple de graphe de dépendances à parcourir Ajout d un canal et repartitionnement du graphe Ajout d un module comportemental et repartitionnement du graphe Retrait d un canal et repartitionnement du graphe Retrait d un module comportemental et repartitionnement du graphe L agent comme machine d exécution d un réseau comportemental

17 Première partie Introduction 17

18

19 Chapitre 1 Introduction Un monde virtuel est un environnement synthétique, dans le sens d un univers réel ou imaginaire simulé par ordinateur ; dans cet univers, un utilisateur est représenté par son avatar. Dans le cadre d une application de Réalité Virtuelle 1, le monde virtuel correspond à l environnement simulé avec lequel un utilisateur peut interagir par l intermédiaire de divers périphériques d entrée (acquisition) et de sortie (rendu). Les mondes virtuels sont de plus en plus présentés à l utilisateur en trois dimensions, facilitant ainsi l interaction et tout particulièrement l exploration du monde de façon relativement naturelle ; les objets 3D qu ils contiennent sont généralement animés. Il existe également des mondes virtuels représentés en deux dimensions ou utilisant une interface uniquement textuelle. Par exemple, alors qu ils existent depuis plus de 20 ans, les MUD (Multi-User Dungeons) sont des environnements virtuels textuels encore très prisés, car ils permettent de dialoguer avec les autres joueurs tout en participant à un jeu (exploration du monde, énigmes, combats, etc.). Les MMORPG (Massively Multiplayer On-line Role Playing Game), tels qu EVERQUEST [4], sont les descendants directs de ces MUD : ces jeux de rôles en 3D massivement multi-utilisateurs accueillent un nombre toujours croissant de joueurs 2. Bien que certains mondes virtuels cantonnent l utilisateur au simple rôle d observateur, la plupart des environnements permettent à un ou plusieurs utilisateurs d agir sur le monde, non seulement par son exploration mais aussi par la manipulation des objets qu il contient et par l interaction avec des entités autonomes (créatures virtuelles, assistants artificiels, etc.). Parmi les principales utilisations des mondes virtuels 3D, nous pouvons citer : les outils pédagogiques utilisant la simulation interactive [119, 46], intégrant éventuellement des tuteurs personalisés artificiels comme STEVE [85] ou HER- MAN THE BUG [89] ; la téléopération, qui permet de contrôler un robot à distance : le monde virtuel est alors une reconstitution de l environnement réel ayant pour but de faciliter la manipulation du robot [136] ; la simulation scientifique, permettant principalement l observation de phénomènes physiques (tels que les collisions de particules) ou éthologiques (tels que les colonies de fourmis ou les sociétés de grands singes [60, 61, 64]), et par- 1 Voir par exemple l ouvrage de G. Burdea et P. Coiffet [45], celui de H. Rheingold [111] ou encore la thèse de D. Verna [136] pour une introduction aux concepts et aux applications de la Réalité Virtuelle. 2 Il y a aujourd hui près de utilisateurs connectés simultanément aux serveurs d EVERQUEST. 19

20 20 CHAPITRE 1. INTRODUCTION fois l interaction, par exemple dans le cas de la manipulation de composés chimiques ; le grand domaine du divertissement, comprenant entre autres : les jeux vidéos, en particulier les MMORPG et les jeux faisant intervenir des entités autonomes, telles que des «animaux de compagnie virtuels» comme dans CREATURES [3] ou des humains virtuels comme dans THE SIMS [8] ; la création dynamique d histoires dans des mondes virtuels (virtual storytelling) [14, 48, 80, 97, 107] ; les effets spéciaux pour le cinéma (mouvements de foules, fumée, etc.) [109, 110] ; ou encore le prototypage virtuel [86, 132], la création artistique [21, 82, 84] et la thérapie [105]. Le domaine de la représentation graphique des mondes virtuels progresse continuellement, en particulier lorsqu il s agit de réaliser des simulations les plus réalistes possible. Les jeux vidéos évoluent eux aussi très rapidement, avec une qualité graphique et une fluidité toujours plus surprenantes. Grâce aux nouveaux périphériques d entrée/sortie, l exploration d un monde et la manipulation des objets 3D se font de plus en plus naturellement. L utilisateur peut attraper un objet pour l examiner en utilisant un gant de données, puis modifier sa forme avec un stylet à retour d effort ; il peut également explorer le monde en manipulant un joystick 3D et visualiser le tout dans un casque qui prend en compte les mouvements de sa tête. Malgré ces progrès technologiques, il reste de gros efforts à faire au niveau des modalités d interaction avec le monde, en particulier en ce qui concerne l interaction avec des entités autonomes. Dans le domaine de la conception de mondes virtuels, il est de plus en plus important de pouvoir définir des entités artificielles autonomes, habituellement appelées agents virtuels, qui peuplent les mondes afin de les rendre plus attractifs auprès des utilisateurs. Ces agents virtuels sont plus ou moins réactifs et plus ou moins «intelligents». Nous nous sommes plus spécifiquement intéressés aux mondes virtuels habités, c est-à-dire aux environnements virtuels dans lesquels interagissent des agents virtuels et des utilisateurs. Le DIAMOND PARK [138] est un exemple particulièrement intéressant de monde virtuel habité. Il s agit d un parc de loisirs virtuel dans lequel divers agents divertissent ou assistent les utilisateurs. La figure 1.1 illustre une scène typique pouvant se dérouler dans ce parc, montrant à la fois des agents virtuels et des avatars. Les poissons de l aquarium et le conducteur de bus sont des agents autonomes. Les utilisateurs peuvent dialoguer entre eux et explorer le monde selon deux modes de déplacement (vélo et monocycle). De nombreux agents virtuels ont été conçus spécifiquement pour interagir avec les utilisateurs. Dans les MUD, ces agents sont habituellement appelés des bots ; comme JULIA [94], ils sont utilisés pour assister les utilisateurs et dialoguer avec eux. Dans d autres types de mondes virtuels, l utilisateur peut interagir avec des animaux artificiels comme dans le système ALIVE [95] ou encore avec des humains virtuels [15, 129, 138].

21 1.1. DÉCRIRE DES COMPORTEMENTS D AGENTS VIRTUELS 21 FIG. 1.1 L aquarium du Diamond Park. 1.1 Décrire des comportements d agents virtuels De nombreux outils permettent de créer des mondes virtuels 3D multi-utilisateurs, centrés sur l interaction entre les participants. Peu de ces outils permettent cependant de décrire facilement les comportements des entités autonomes peuplant les mondes virtuels. D autre part, de nombreux travaux en Intelligence Artificielle (IA) portent sur la description de comportements d agents autonomes. Il existe actuellement deux grandes tendances en IA : l approche cognitive (IA classique) et l approche réactive («nouvelle IA»). L IA classique s attache à réaliser des agents cognitifs, qui possèdent des capacités de raisonnement sur des représentations symboliques de leur environnement, ces capacités leur permettant de planifier des actions à long-terme. L approche réactive, fortement inspirée de la biologie et de l éthologie, s oppose à l approche cognitive depuis une quinzaine d années en proposant des modèles reliant fortement la perception et l action, sans passer par le raisonnement symbolique. Cette approche a été appliquée avec succès à l animation de créatures artificielles [72, 99, 123] et à la simulation étonnamment réaliste de comportements de groupes (navigation, évitement de collision, poursuites, etc.) [110]. En intégrant des capacités d apprentissage non-symbolique ou d évolution, l approche réactive a aussi permis de mettre en œuvre des animats, ces robots virtuels ou réels dont le comportement s inspire de celui des animaux. Dans le cadre de notre travail, nous nous intéressons cependant plus spécialement aux outils de description explicites de comportements, en laissant de côté les techniques permettant de faire émerger le comportement. Les automates à états finis ont beaucoup été utilisés pour décrire des comportements d agents. Les automates séquentiels sont difficiles à décrire manuellement pour exprimer des comportements complexes, la taille de l automate augmentant rapidement. Le

22 22 CHAPITRE 1. INTRODUCTION principal inconvénient des automates à états finis tient à leur faible maintenabilité : une petite modification de la spécification du comportement peut nécessiter la redéfinition d une partie importante de l automate. Les automates hiérarchiques parallèles, qui réduisent la complexité des automates définis et qui permettent de décrire des comportements concurrents, ont servi entre autres à décrire le comportement de personnages de jeux vidéos [87], de conducteurs et de piétons en milieu urbain [103, 131] ou encore d humains virtuels [17]. Leur utilisation reste cependant complexe pour un public non-informaticien. En parallèle, des langages spécifiques pour la description de comportements ont été définis, en particulier pour donner des capacités cognitives aux agents réactifs utilisés dans le domaine de l animation. Pour leur système IMPROV, K. Perlin et A. Goldberg ont proposé un langage proche de l anglais, permettant de scénariser l animation de plusieurs acteurs virtuels ; l introduction de probabilités explicites dans un script permet d obtenir des comportements moins prévisibles et donc plus réalistes [107]. De son côté, J. Funge a créé le langage CML (Cognitive Modeling Language) permettant de définir d une part des buts, et d autre part des actions à réaliser pour parvenir à ces buts ; les actions sont décrites par leurs préconditions d exécution et par leurs conséquences [65, 66]. L approche de J. Funge est adaptée à la description des connaissances permettant à un agent de raisonner sur une situation et de planifier ses actions en conséquence, mais la description de comportements réactifs en CML n est pas évidente. Enfin, B. Loyall a conçu un langage pour la description de comportements d «agents crédibles» (believable agents), capables de choisir des actions physiques ou mentales pour réaliser leurs buts [92]. Son langage, qui est une extension de LISP, permet d assembler des actions primitives physiques prédéfinies (animations) et des actions mentales quelconques qu il faut programmer en C. Outre les outils graphiques de conception de systèmes multi-agents que nous étudierons dans le chapitre 2, certains travaux portent sur la programmation graphique de comportements d agents virtuels. M. Travers propose par exemple un modèle permettant à des non-programmeurs de définir graphiquement des comportements d entités autonomes animées [133]. Il existe d autre part des outils commerciaux de création de mondes virtuels multi-utilisateurs, permettant de décrire graphiquement des comportements d objets animés. La société VIRTOOLS propose ainsi un atelier graphique, NEMO CREATION, réservé aux non-programmeurs [6]. Cet outil permet de combiner des blocs comportementaux prédéfinis et de les associer à des objets 3D. La programmation graphique manipule hélas des blocs de trop bas-niveau, ce qui rend la description de comportements d entités autonomes rapidement complexe. Pour pouvoir définir de nouveaux blocs comportementaux, il faut être capable de programmer en C++. De son côté, la société CRYO-NETWORKS a développé le SCS (Site Construction Set), un atelier graphique basé sur le langage SCOL (Standard Cryo Online Language) [7]. Cet atelier permet de décrire un monde multi-utilisateurs en interconnectant des modules, qui représentent des fonctionnalités du serveur et de l interface client. La définition de nouveaux modules nécessite l apprentissage du langage SCOL, certes plus abordable que C++ mais nécessitant de gérer des aspects réseau. Pour ces deux outils commerciaux, nous constatons qu il existe un fossé entre les possibilités données à l utilisateur au niveau de l atelier graphique et la maîtrise nécessaire d un langage de programmation sous-jacent dès qu il s agit de décrire plus que des animations prédéfinies.

23 1.2. MOTIVATIONS Motivations À notre connaissance, il n existe pas encore d outil qui possède à la fois les caractéristiques suivantes : accessible aux non-programmeurs, de façon similaire à la partie graphique du SCS ou de NEMO ; basé sur un modèle spécifique à la description de créatures virtuelles ; intégrant complètement les utilisateurs ; définissant une architecture de décision robuste et déterministe, adaptée à la description graphique de comportements par assemblage de composants et par programmation graphique de haut-niveau. D un autre côté, les langages dits synchrones s avèrent adaptés pour la description de comportements déterministes de systèmes réactifs modulaires. Le langage ESTE- REL présente en particulier une syntaxe pratique et concise pour décrire des comportements réactifs correspondant au déclenchement d actions sur l arrivée de certains événements. L objectif du projet INVIWO (Intuitive Virtual Worlds) est de donner les moyens de concevoir des mondes virtuels habités à un public ne possédant pas obligatoirement des compétences en programmation (grand public, artistes, biologistes, scénaristes de jeux vidéos, etc.). Nous nous intéressons plus particulièrement à la description du comportement de créatures virtuelles, dans le sens d agents crédibles mais pas forcément réalistes 3, correspondant en partie aux believable agents de K. Perlin. Les caractéristiques de ces entités sont les suivantes, ces caractéristiques étant fortement liées : réactivité : les créatures doivent réagir à leur environnement dans un temps raisonnable et doivent s adapter aux modifications de cet environnement; autonomie : les créatures ont le contrôle total de leur processus de décision et de leur état interne ; pertinence : les actions choisies par une créature ont un sens que l observateur peut appréhender, c est-à-dire qu elles doivent visiblement tendre à la réalisation d un objectif ou de plusieurs objectifs simultanés. La figure 1.2 illustre un exemple de monde INVIWO : les habitants de ce monde sont des lapins qui se déplacent sur un damier. Chaque lapin doit atteindre un certain nombre de points cibles. Lorsqu un lapin détecte un risque de collision, il essaie d éviter l obstacle tout en essayant de ne pas s éloigner trop de sa trajectoire. Les obstacles peuvent être statiques (cube immobile) ou mobiles (autres lapins, avatar). Notre objectif est, à terme, de fournir des outils de haut-niveau basés sur un langage spécifique de description de comportements d agents. Le modèle d agent sous-jacent a été conçu de façon à être une synthèse et une simplification des architectures d agents existantes, afin de présenter au concepteur non-programmeur un ensemble minimal de composants. 1.3 Contribution Notre travail a posé des bases solides pour le développement d outils graphiques permettant de décrire des comportements d agents autonomes, dans le contexte des 3 En particulier, nous ne nous préoccupons pas de la simulation des lois physiques.

24 24 CHAPITRE 1. INTRODUCTION FIG. 1.2 Le monde des lapins. mondes virtuels multi-utilisateurs. Nous proposons un modèle de mondes virtuels homogènes, considérés comme des systèmes multi-agents uniformes intégrant complètement les utilisateurs. Ce modèle permet de mettre en œuvre des mondes locaux aussi bien que répartis, sans modification de la description du monde et des agents le constituant 4. Notre modèle d agent est volontairement minimaliste, tout en permettant de représenter des créatures virtuelles, c est-à-dire des agents situés évolutifs Mondes et agents INVIWO Un monde INVIWO est simplement un ensemble d agents en interaction : toute entité, que ce soit un objet, un agent virtuel ou un avatar, est représenté dans le monde sous la forme d un agent. L environnement d un agent est donc composé uniquement de l ensemble des autres agents. Nos agents cohabitent dans un monde virtuel : ils n ont a priori pas de comportement collaboratif. L interaction et la communication entre agents INVIWO se fait par l intermédiaire de messages typés, appelés stimuli externes, pouvant contenir des informations structurées. Cela permet de définir différents niveaux d interaction, et donc de mettre en œuvre aussi bien des agents réactifs que cognitifs, voire des agents conversationnels. Une caractéristique importante d un agent est sa capacité à réagir à des stimuli de façon autonome, c est-à-dire selon ses propres motivations et ressources. Un agent IN- VIWO est composé d attributs, de capteurs, d effecteurs et d organes de décision appelés modules comportementaux. Les attributs de l agent correspondent à ses ressources 4 La répartition est gérée indépendamment par la plate-forme d exécution.

25 1.3. CONTRIBUTION 25 internes et à ses motivations. Les capteurs reçoivent les stimuli externes et internes, les traitent puis les redistribuent au processus de décision. Les effecteurs réalisent soit des actions internes, correspondant à la gestion des attributs et de la structure de l agent, soit à des actions externes, correspondant à l interaction avec les autres agents. Les agents INVIWO sont d abord réactifs, mais ils peuvent posséder une mémoire (en tant qu attribut), et donc une représentation interne de leur environnement, ce qui les rendra éventuellement capables de raisonnement spatio-temporel. Ce modèle d agent sera détaillé dans le chapitre 5. Enfin, notre modèle prend en compte les utilisateurs de façon homogène, car c est une spécificité importante des mondes virtuels. L avatar INVIWO est donc un agent, capable de communiquer avec un opérateur humain via une interface utilisateur. Notre modèle d avatar sera présenté dans le chapitre Architecture de sélection de l action Le processus de décision doit amener l agent à choisir les actions internes et externes à effectuer en fonction des stimuli perçus et de son état interne. Il existe deux grands types d architectures de sélection de l action : les architectures monolithiques, difficiles à étendre et à maintenir, fiables dans des environnements similaires mais assez peu robustes aux imprévus ; les architectures distribuées, dites «basées sur les comportements», plus robustes et plus faciles à maintenir car modulaires, mais nécessitant une phase supplémentaire d arbitrage. Dans une architecture distribuée, le mécanisme d arbitrage permet de sélectionner une seule action parmi plusieurs actions conflictuelles, et dans certains cas de combiner plusieurs actions. La décision se fait alors en deux phases : la proposition d actions par différents modules de décision, puis l arbitrage de ces propositions. L architecture de sélection de l action choisie pour le modèle INVIWO est distribuée et repose sur un mécanisme d arbitrage homogène, permettant aussi bien de sélectionner une action parmi plusieurs propositions que de combiner ces propositions. Les modules comportementaux concurrents proposent des actions à effectuer en fonction du contexte courant, puis les arbitres sélectionnent à partir de ces propositions une action qui sera réalisée. Notre architecture est de plus basée sur le modèle synchrone nous garantissant un comportement déterministe de l ensemble des modules comportementaux. Cette architecture sera étudiée en détail dans le chapitre MARVIN Nous proposons un langage de spécification dédié, appelé MARVIN et basé sur notre architecture de sélection de l action. La syntaxe de ce langage est fortement inspirée de celle d ESTEREL ; nous y avons ajouté des caractéristiques orientées-objets et orientées-agents. Il permet ainsi de décrire tous les composants d un agent INVIWO, ainsi que les données manipulées par l agent et les messages échangés entre agents. Les corps des modules comportementaux sont principalement constitué de règles réactives concurrentes, qui facilitent la description du comportement d un agent. Notre langage comporte un ensemble d instructions permettant de gérer simplement le temps et l attente d événements, à la façon des constructions réactives d ESTEREL. Ce langage sera décrit dans le chapitre 8.

26 26 CHAPITRE 1. INTRODUCTION Contraintes et comportements d agents Nous avons étudié diverses solutions d intégration de la notion de contraintes dans notre modèle, afin de faciliter la description de certains comportements de haut-niveau. Nous proposons en particulier d «agentifier» au besoin les contraintes multidirectionnelles entre agents, afin de centraliser la gestion de ces contraintes tout en conservant l autonomie et l encapsulation de nos agents. Par ailleurs, le modèle de contraintes-buts et la méthode de recherche adaptative proposés par P. Codognet [51, 116] s intègrent naturellement à notre architecture de sélection de l action ainsi qu au langage MAR- VIN. Nous détaillerons ces différentes solutions dans le chapitre Organisation du mémoire Ce mémoire se compose de quatre grandes parties : la première partie correspond à un état de l art nous permettant de définir le contexte dans lequel s insère notre travail ; la deuxième partie s attache à décrire le modèle INVIWO, constitué : d un modèle de mondes virtuels (chapitre 5) ; d un modèle d agent autonome (chapitre 5) ; d un modèle d avatar (chapitre 6). la troisième partie présente les outils de description de comportements que nous proposons, à savoir : une architecture de sélection de l action (chapitre 7) ; un langage dédié à la description de nos agents selon cette architecture (chapitre 8) ; l introduction de contraintes pour faciliter la description de certains comportements (chapitre 9). la quatrième partie est une description de l implémentation de la plate-forme d exécution. La première partie est composée de trois chapitres correspondant à un ensemble de définitions et à un état de l art concernant trois grandes influences de notre travail : 1. les travaux sur les agents autonomes, qui nous ont permis de dégager les caractéristiques et les besoins spécifiques aux agents virtuels (chapitre 2) ; 2. un état des lieux des architectures de sélection de l action basées sur une approche réactive, qui nous a guidé dans notre choix d une architecture de décision de l agent (chapitre 3) ; 3. un tour d horizon des systèmes réactifs et des langages dits synchrones, en particulier des caractéristiques du langage ESTEREL, des réseaux de processus réactifs et des objets synchrones, dont nous nous sommes largement inspirés pour proposer à la fois l architecture de sélection de l action et les bases du langage MARVIN (chapitre 4).

27 Deuxième partie Définitions et état de l art 27

28

29 Chapitre 2 Agents autonomes et systèmes multi-agents «- C est quoi l IM? - L intelligence machinique. Je trouve le terme artificielle à la fois méprisant et inexact. Mon intelligence n a rien d artificiel, mais je suis une machine.» Extrait du roman «Le problème de Turing», co-écrit par H. HARRISON et M. MINSKY (oui, le Marvin MINSKY). 2.1 Introduction Un agent est simplement une entité qui agit ou opère. Le terme agent pourrait donc s appliquer à n importe quel programme informatique qui produit des résultats. Il est d ailleurs utilisé pour désigner des concepts très différents, même dans le seul domaine de l Intelligence Artificielle, et il apparaît de plus en plus pour de discutables raisons de marketing 1. Puisqu il est difficile de donner une définition précise de ce qu est un agent, nous allons énoncer un certain nombre de caractéristiques qui nous paraissent importantes pour distinguer un agent d un programme informatique quelconque. Dans son mémoire de thèse, Z. Guessoum résume ainsi les caractéristiques qui émergent de différentes définitions données au terme agent depuis le début des années 90 : un agent est une entité active, autonome mais sociable, qui peut être intelligente et qui interagit avec un environnement dynamique, auquel elle doit s adapter [71]. Cette définition se place dans le contexte des systèmes multi-agents (SMA), elle implique donc que plusieurs agents peuvent coexister dans le même environnement. Elle implique également qu un agent est obligatoirement coopératif et capable de s adapter à son environnement; ces deux dernières caractéristiques correspondent effectivement aux qualités des agents de la plate-forme DIMA (Développement et Implémentation 1 Cette tendance à vouloir utiliser et vendre la notion d «agent» à tout bout de champ, parce que ce paradigme est à la mode, est entre autres vivement critiquée par M. Wooldridge et N. Jennings [139]. 29

30 30 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS de systèmes Multi-Agents) développée par l auteur, mais elles ne nous semblent cependant pas indispensables à tous les types d agents. Nous adopterons donc par la suite la définition personnelle suivante : Un agent est une entité active et autonome, qui interagit avec un environnement dynamique, et qui peut être intelligente, adaptative ou sociable. Après avoir détaillé ces différentes caractéristiques, nous préciserons en quoi consiste d une part la perception d un agent, d autre part l interaction d un agent avec son environnement. Notons au passage que les capacités de communication avec les autres agents sont généralement séparées des capacités d interaction avec l environnement : cette distinction sera détaillée dans la section 2.4. Nous nous intéresserons ensuite aux connaissances utilisées par un agent pour améliorer son comportement, puis nous terminerons sur une courte synthèse. 2.2 Caractéristiques d un agent Autonomie D après J. Ferber, un agent est une entité physique ou virtuelle 2 qui possède ses propres ressources, compétences et objectifs [64]. Son état interne et son processus de décision sont entièrement encapsulés. Son comportement tend à satisfaire les objectifs en fonction des ressources et des compétences, mais aussi de la perception et éventuellement de la représentation que l agent a de son environnement, ainsi que des communications réalisées avec d autres agents. Un agent autonome est capable d agir seul, c est-à-dire de prendre des décisions selon des critères qui lui sont propres et sans l intervention d un autre agent ou d un opérateur humain, voire sans stimulation environnementale. Les agents qui peuvent agir sans stimulation extérieure sont parfois qualifiés de «pro-actifs». Cette autonomie implique évidemment que l agent doit être capable de gérer les conflits éventuels entre ses objectifs et son état interne ou l état de son environnement. Les mécanismes permettant de sélectionner des actions et de résoudre les conflits font l objet de nombreuses recherches, dont une partie est présentée dans le chapitre 3. J. Ferber distingue par ailleurs cinq catégories de motivations, c est-à-dire de raisons qui poussent un agent à agir [64]. Nous en retiendrons trois : les motivations personnelles tendent à satisfaire les besoins et objectifs internes de l agent ; les motivations environnementales sont produites par ce que perçoit l agent de son environnement; les motivations sociales découlent de l organisation des agents imposée par le concepteur du système Environnement L environnement est l ensemble des conditions naturelles (physiques, chimiques, biologiques) et culturelles (sociologiques) susceptibles d agir sur les organismes vi- 2 Nous ne nous attarderons pas sur la distinction entre les agents physiques et les agents simulés : la réalisation d un agent physique doit prendre en compte des contraintes plus fortes, comme la perception bruitée ou les risques de panne, mais les caractéristiques générales d un agent s appliquent aussi bien à un robot réel qu à un robot simulé.

31 2.2. CARACTÉRISTIQUES D UN AGENT 31 vants et les activités humaines. Par extension, l environnement est l ensemble des conditions extérieures susceptibles d agir sur le fonctionnement d un système. Un agent autonome évolue de façon continue dans un environnement, dans lequel peuvent exister d autres agents. Puisqu un agent agit sur son environnement et que l environnement agit sur l agent, il existe une réelle interaction entre ces deux entités. Du point de vue d un agent, l environnement correspond à «tout ce qui lui est extérieur» : les autres agents font aussi a priori partie de l environnement. Cependant, l environnement est souvent considéré comme une structure centralisée dynamique mais non autonome, qui contient l ensemble des entités avec lesquelles interagissent les agents mais qui ne sont pas des agents. C est le cas dans la plate-forme DIMA par exemple [71]. Cette approche sépare nettement la communication directe entre agents et la manipulation des objets de l environnement. Cette décomposition facilite la mise en œuvre de systèmes basés sur des agents cognitifs qui travaillent sur des connaissances partagées. Elle simplifie par ailleurs le maintien de la cohérence du système, en centralisant à la fois les données que nous qualifierons de publiques (position, forme géométrique, etc.) et les règles appliquées à ces données publiques pour tous les agents (cf. section 2.4.3). Selon Z. Guessoum, la connexion entre un agent et son environnement peut être plus ou moins forte selon la façon dont l agent acquiert l information en provenance de l environnement [71]. À partir des informations obtenues, l agent peut créer et modifier sa propre représentation de l environnement (cf. section 2.5.2). La connexion agent-environnement est forte dans le cas d un agent situé, c est-à-dire lorsque l agent possède des capteurs et des effecteurs. Les capteurs sont capables de percevoir directement (mais souvent partiellement) les éléments de l environnement ou les modifications survenues dans cet environnement (cf. la section 2.3 consacrée à la perception). Les effecteurs permettent à l agent d agir sur son environnement (cf. la section 2.4 concernant l interaction d un agent avec son environnement). L environnement d un agent situé est habituellement un espace à deux ou trois dimensions constitué de cellules géométriques pouvant contenir des éléments perceptibles et modifiables par les agents [88]. La connexion agent-environnement est très forte dans le cas d agents qui ne communiquent pas directement avec les autres agents mais perçoivent leur présence et leur influence uniquement à travers les modifications de l environnement. Dans le cas extrême des agents tropiques, qui ne possèdent ni état interne ni représentation de leur environnement, les stimuli perçus à chaque instant suffisent aux agents pour agir, par exemple pour se guider à l odeur ou au son vers une cible. Pour L. Steels [128] ou R. Brooks [42], la connexion agent-environnement est faible quand l agent n est pas nettement «ancré» (grounded) dans son environnement, c est-à-dire s il ne perçoit pas uniquement des informations non symboliques en provenance de cet environnement par l intermédiaire de ses capteurs. La connexion agent-environnement est minimale si l agent ne peut prendre connaissance de l état de l environnement qu à partir des informations fournies par d autres agents. Dans le cas extrême d un ensemble d agents purement communicants, l environnement n existe tout simplement pas et les agents peuvent seulement communiquer entre eux Comportement adaptatif Un agent adaptatif est capable de modifier son comportement et ses objectifs en fonction de ses interactions avec son environnement et avec les autres agents. En par-

32 32 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS ticulier, il peut réagir différemment selon l agent avec lequel il interagit. Cette caractéristique nécessite des capacités d apprentissage, par exemple pour élaborer des cartes cognitives ou pour modifier ses préférences comportementales en fonction de son expérience. L adaptation peut également être collective : en utilisant des mécanismes d évolution, des populations d agents peuvent apprendre à s adapter à leur environnement Intelligence Un agent est habituellement qualifié d intelligent lorsqu il possède des capacités de représentation symbolique et de raisonnement, voire de réflexivité s il est capable de raisonner sur son propre comportement et ses propres objectifs. Pour désigner un tel agent, nous préférerons cependant le terme agent cognitif (ou encore agent délibératif), car un agent peut paraître avoir un comportement intelligent pour un humain sans pour autant posséder de capacités cognitives. L. Steels considère par exemple un comportement comme étant intelligent s il permet au système de survivre au mieux dans son environnement [128] ; l auteur se place en fait dans le contexte des agents situés. En psychologie cognitive, l idée fondamentale de la cognition située est que l environnement d un individu influence fortement ses processus cognitifs, et qu il est donc indispensable de prendre en compte cet environnement pour modéliser correctement le fonctionnement du cerveau (humain ou animal). Les agents situés possèdent une représentation souvent très limitée de leur environnement mais rarement des capacités de raisonnement sur cette représentation ; ils sont pour cela traditionnellement qualifiés de réactifs. Un agent est considéré par R. Arkin [13] et J. Ferber [64] comme réactif lorsqu il agit uniquement en fonction de stimuli (internes et externes), sans avoir besoin de représentation symbolique ou d historique. Un animat est un agent situé particulier ; c est un robot, simulé ou réel, dont le fonctionnement est inspiré du comportement animal et qui doit survivre dans un environnement souvent hostile [73, 74, 100]. Le terme animat est une contraction des mots animal et artefact proposée par J.-A. Meyer et S. Wilson [99]. Un animat a pour objectifs principaux de se nourrir, de boire, de dormir, d éviter les prédateurs et éventuellement de se reproduire. Les animats paraissent se comporter de façon intelligente alors qu ils font surtout preuve d adaptabilité à leur environnement. D autre part, dans les sociétés complexes comme les colonies de fourmis, l intelligence semble émerger du groupe alors que les fourmis prises individuellement n ont que des capacités limitées. Nous considérerons donc simplement un agent (ou un ensemble d agents) comme étant intelligent si son comportement nous semble pertinent par rapport à ses objectifs, dans un environnement où la réalisation de ces objectifs ne nous paraît pas évidente 3. Par exemple, un animat intelligent sera capable de survivre aux dangers de son environnement, et un agent joueur d échecs intelligent battra régulièrement un humain de niveau équivalent. La détermination du niveau d intelligence d un agent dépend de l observateur; elle est donc réalisée de façon tout à fait subjective. La distinction entre agents cognitifs, capables de raisonner, et agents réactifs, qui ne font que «réagir immédiatement» aux stimuli perçus, tend à disparaître, grâce aux nombreux travaux ayant démontré l intérêt des agents hybrides. Par exemple, R. Arkin a été l un des premiers à défendre l idée d agents à la fois réactifs et délibératifs, en concevant le système AURA [13]. Un agent hybride peut réagir rapidement aux 3 Si un agent n a pas de problème à résoudre, il ne nous paraîtra évidemment pas intelligent!

33 2.2. CARACTÉRISTIQUES D UN AGENT 33 événements se produisant dans son environnement, par exemple à l approche d un prédateur, tout en anticipant d autres événements en fonction de ses expériences passées, ou en planifiant sa navigation à partir d une carte élaborée au cours de son exploration de façon à optimiser son trajet par rapport à ses objectifs. La plupart des architectures hybrides proposées se composent de plusieurs couches correspondant à plusieurs «niveaux d intelligence» ; c est par exemple le cas d ATLANTIS [67], de DIMA [71], d INTERRAP [102] et de 3T [30]. La figure 2.1 illustre une architecture typique constituée de couches distinctes. Ces architectures sont principalement conçues pour permettre à des agents cognitifs d intégrer des capacités réactives. Modélisation du monde stimuli Système de perception Planification Système d action actions Niveau réactif FIG. 2.1 Architecture typique d agent hybride. Certaines architectures dites «basées sur les comportements» sont d abord réactives mais considèrent les modules de décision d un agent comme des boîtes noires plus ou moins réactives, mais aussi plus ou moins cognitives. C est par exemple le cas de DAMN [118], que nous décrirons en détail dans le chapitre 3 (cf. section 3.3.5). Un grand nombre de documents résument très bien l historique et les apports de la jonction entre agents réactifs et cognitifs, en particulier une excellente synthèse de J. Bryson [44] et un article de J. Müller, l un des concepteurs du système INTERRAP [101] Sociabilité Un système multi-agents est généralement composé d agents qui doivent coordonner leurs comportements et éventuellement partager leurs connaissances afin de résoudre un problème ou d effectuer conjointement une action. La coopération, ou collaboration, est la participation à une œuvre commune. Les agents dits sociables ou coopératifs peuvent soit poursuivre un objectif global, soit agir en fonction de leurs propres objectifs tout en acceptant de faire des compromis. De nombreux travaux portent sur la coordination d agents au sein d une société, c est-à-dire d un système organisé et collaboratif. La gestion des conflits et la coordination d actions, l échange de connaissances (résultats, objectifs, plans, compétences, etc.), ou encore la description du comportement global du système à partir des interactions entre agents sont autant de problèmes difficiles [31]. Ces problèmes concernent généralement les systèmes basés sur des agents cognitifs. Il existe d autre part des systèmes dans lesquels les agents ne sont pas particulièrement coopératifs. Ces agents évoluent uniquement en fonction de leurs objectifs propres, sans se préoccuper des conséquences de leurs actions sur les autres agents. Si leurs buts sont incompatibles, les agents peuvent être en compétition, comme dans un système constitué de proies et de prédateurs. Si leurs buts sont compatibles, les

34 34 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS agents peuvent s ignorer, ou bien interagir intentionnellement si cela leur est utile individuellement. Ils peuvent parfois même coopérer involontairement. Selon le modèle de J.L. Deneubourg [57] par exemple, les termites construisent leur nid uniquement en réagissant aux phéromones déposées par d autres termites sur des boulettes de terre : elles déposent leurs boulettes là où se trouvent déjà d autres boulettes, jusqu à ce qu une certaine densité de phéromones soit atteinte. La composante sociale est donc souvent importante dans un système multi-agents, en particulier dans le cadre de la résolution distribuée de problèmes [71] : le groupe peut être prioritaire par rapport à l individu. L organisation d une société n est pas pour autant en contradiction avec l autonomie des agents : de même que le comportement d un agent dépend de son environnement, il peut dépendre également de son milieu social. L intelligence collective peut émerger d un tel système par la collaboration soit de quelques agents intelligents mais spécialisés (société d experts), soit de nombreux agents à l intelligence limitée mais appliquant des règles sociales qui mèneront à la réalisation de l objectif global (société d agents réactifs). Les agents purement communicants, évoqués dans la section 2.2.2, sont par exemple principalement utilisés en Intelligence Artificielle Distribuée pour la résolution coopérative de problèmes entre agents experts [64]. 2.3 Perception La capacité de perception d un agent lui permet d acquérir des informations sur son environnement et sur lui-même. Dans le cadre de la robotique, la perception est principalement définie par rapport au sens de la vue (images provenant d une caméra, par exemple) ou à des sens équivalents (capteurs-émetteurs d ultra-sons, par exemple). Ces sens permettent de détecter la présence d objets à proximité de l agent, afin d éviter les obstacles ou de reconnaître des cibles à atteindre. Le système perceptif d un agent peut être considéré comme une fonction associant un ensemble de valeurs, appelées percepts, aux états du monde perceptibles par l agent à un instant donné. Un stimulus est une entité active externe ou interne capable de provoquer la réaction d un organisme excitable. Le système perceptif d un agent est donc excité par des stimuli, en provenance de l environnement ou de l intérieur de l agent. Il traduit les stimuli en percepts, en fonction des compétences de l agent, de ses objectifs et de ses connaissances (cf. figure 2.2) : un ver de terre n a par exemple pas les mêmes capacités ni les mêmes besoins de perception qu une souris Perception interne et perception externe L extéroception correspond à la perception des excitations en provenance de l environnement de l agent, c est-à-dire des stimuli externes. La perception des stimuli internes est généralement appelée proprioception, bien qu il existe deux types de perception interne : la proprioception correspond à la sensibilité propre aux muscles, aux ligaments, aux os, etc. Elle est plutôt associée au mouvement (étirement de la peau, équilibre, sensation de déplacement, etc.), et est en partie une conséquence des contraintes environnementales (gravité, résistance de l air, etc.) ;

35 2.3. PERCEPTION 35 Capteurs Stimuli perceptif Percepts Compétences Objectifs Connaissances FIG. 2.2 Principes du système perceptif d un agent. l intéroception est aussi appelée sensibilité viscérale. Elle est associée aux stimuli produits par l organisme lui-même, en particulier aux stimuli d origine chimique (faim, douleur viscérale, etc.). La distinction entre proprioception et intéroception étant donc plutôt délicate, nous utiliserons nous aussi par la suite le terme de proprioception pour désigner la perception interne Modularité Les agents cognitifs sont issus du domaine de l Intelligence Artificielle (IA) dite classique, qui considère la perception et l action en terme de traitement de données symboliques. La perception est dans ce cas généralement un processus qui opère une fusion des informations en provenance des capteurs pour élaborer et mettre à jour une représentation abstraite unique, complète et précise de l environnement et de ses propriétés ; ce processus est schématisé sur la figure 2.3. La représentation interne ainsi créée tient rarement compte des intentions ou des capacités comportementales de l agent [13] : elle peut être en partie inutile, alors que son élaboration (traduction des stimuli en données symboliques) et sa manipulation sont souvent coûteuses, en particulier en terme de temps de traitement et de place occupée en mémoire. perceptif percepts!" # $ %" de l environnement FIG. 2.3 La perception classique. De son côté, l approche «orientée-comportements» issue de la «nouvelle IA» (cf. chapitre 3) s inspire de la biologie, et insiste sur le besoin d une connexion agentenvironnement maximale, c est-à-dire de la prise en compte de données brutes en provenance des capteurs. D autre part, cette approche propose la notion de perception modulaire, ou perception «orientée-action», illustrée sur la figure 2.4 : le système perceptif est composé de différents sous-systèmes perceptifs spécialisés, qui extraient l information pertinente pour chacun des systèmes comportementaux actifs [13]. La perception est ainsi guidée par les besoins des comportements, c est-à-dire par les actions à réaliser. Cette approche sélective de la perception se base sur le principe

36 36 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS perceptif 1 perceptif 2 perceptif 3 percept 1 percept 2 percept 3 comportemental 1 comportemental 2 comportemental 3 FIG. 2.4 La perception modulaire. que le monde peut être vu de façons différentes, en fonction des intentions d un individu et des tâches qu il doit réaliser. Par exemple, le système visuel humain nous permet de reconnaître des objets ou des couleurs, car ce sont ces informations qui nous sont utiles. Les différents systèmes perceptifs peuvent être combinés, par exemple en fusionnant les percepts générés afin d obtenir des percepts de plus haut-niveau (cf. figure 2.5). percept 1 percept 2 percept 3 Fusion percept comportemental FIG. 2.5 La fusion de percepts. La perception active est le pendant de la perception orientée-action : tout comme la perception peut être guidée par les actions à réaliser, les actions peuvent être influencées par le système perceptif pour améliorer la perception. Par exemple, en contrôlant en partie le déplacement d un robot ou les commandes d une caméra, le système perceptif peut s approcher d un objet ou zoomer sur cet objet pour le reconnaître. Un système perceptif actif est donc un système capable de demander la réalisation de certaines actions de façon à extraire plus d informations pertinentes de l environnement Niveau d abstraction Comme nous l avons signalé précédemment, les travaux en robotique s intéressent surtout à la vision, en particulier à la reconnaissance des formes à partir d images animées ; un robot est plongé dans un environnement réel bruité, qu il perçoit de façon imparfaite. Dans le cas d agents purement logiciels 4, la vision artificielle permet de simuler ce processus afin de laisser à l agent la possibilité d interpréter des données brutes à sa façon, plutôt que de lui fournir des données abstraites possédant déjà une signification. Les données parfaites sont alors bruitées par le simulateur avant d être présentées au système perceptif. La vision artificielle est par exemple utilisée par l équipe de D. Thalmann pour la simulation d humains virtuels [129]. Il n est cependant pas indispensable que la perception d un agent simulé soit absolument réaliste : la perception simulée suffit généralement à obtenir des résultats 4 Les agents purement logiciels sont des agents simulés ne possédant pas de capteurs physiques, en particulier pas de caméra.

37 2.4. ACTION ET INTERACTION 37 intéressants, tout en s évitant le coût important de la vision artificielle 5. Par exemple, l équipe de N. Badler tire avantage de la connaissance parfaite du monde liée au contexte de la simulation, afin de fournir des données plus complètes aux humains virtuels comme la position, la couleur ou encore le type des objets qui les entourent [17]. Certains travaux ont par ailleurs montré qu il pouvait être avantageux de considérer l environnement comme un système de simulation à événements discrets [71] : la perception des agents se limite alors à la réception d informations datées correspondant uniquement aux modifications de l environnement. Ce type d approche est souvent critiqué par les ardents défenseurs d une connexion agent-environnement forte, qui considèrent, comme R. Brooks [42], que l abstraction des données brutes mène à une perte d information non négligeable. 2.4 Action et interaction Comme nous l avons déjà fait remarquer dans l introduction de ce chapitre, la communication est généralement séparée de l interaction avec l environnement. Cette séparation se traduit en pratique par la distinction entre les agents et l environnement composé d objets partagés par les agents. Selon J. Ferber par exemple, bien qu étant une forme d action, la communication entre agents a pour but de modifier l état mental d un autre agent et de provoquer un comportement spécifique, alors que l interaction avec l environnement mène simplement à la modification de l état de cet environnement [64]. En fait, il oppose les actions sur l environnement à la communication directe entre agents. La figure 2.6 ci-dessous résume cette approche. Environnement stimuli Interaction actions Perception percepts Action commandes Agent Processus Communication messages messages Émission Autres agents FIG. 2.6 Distinction entre la communication et l interaction avec l environnement. Nous allons d abord proposer une définition de l action, puis nous nous intéresserons à la communication directe et indirecte entre agents. Nous terminerons sur l interaction avec l environnement, qui pose en particulier le problème du rôle de l environnement dans cette interaction Action D après J. Ferber, l action est en premier lieu ce qui modifie l état global du monde, mais c est aussi une tentative d influer sur le monde qui peut échouer : son modèle d action comme réponse à des influences permet de prendre en compte les lois de l univers et les tentatives d action des autres agents [64]. Cependant, nous préférerons la définition plus informatique de X. Tu [134] : 5 Nous remarquerons que la vision artificielle est aussi une simulation de la perception, mais l expression «perception simulée» désigne généralement une simulation moins proche de l environnement réel.

38 38 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS L action est la plus petite unité décomposable du comportement, à partir de laquelle peuvent être décrits tous les comportements. Au besoin, le résultat de l action dans l environnement pourra être connu par l intermédiaire de la perception. Cette définition a l avantage de ne pas distinguer les actions internes des actions externes, c est-à-dire de ne pas réduire l action à l interaction avec l environnement. Elle ne distingue pas non plus les actions sur l environnement de la communication. Par la suite, nous nous intéresserons donc aux actions en tant que primitives permettant à un agent d agir sur lui-même et sur son environnement au sens large, c est-à-dire en y comprenant les autres agents. Le niveau d abstraction des actions dépend de l application : l unité comportementale d un robot lui permettant de «tourner à gauche» peut nécessiter l activation de plusieurs moteurs, c est-à-dire l utilisation de plusieurs commandes au sens cybernétique du terme, et pourtant être considérée comme une action atomique, c est-à-dire comme l une des plus petites unités manipulables par le mécanisme de sélection de l action Communication Communication directe La communication directe correspond à l envoi volontaire d un message à un ou plusieurs agents. Elle est généralement séparée des capacités d interaction avec l environnement. Il s agit d une conversation entre agents cognitifs, capables d interpréter des actes de langage et de raisonner sur des messages ambigus. Un acte de langage est une action intentionnelle effectuée au cours d une communication, par exemple une requête effectuée auprès d un agent avec l espoir d obtenir un service. Une conversation est un échange de messages, généralement structuré selon un protocole de communication. Les protocoles de communication, aussi appelés politiques de conversation, constituent un domaine de recherche important dans le cadre des systèmes multi-agents. De nombreux travaux portent sur la description de conversations par des réseaux de Petri [20, 55], sur le dialogue multi-modal entre agents et opérateurs humains [47, 49] ou encore sur la définition de langages «universels» de communication. Les langages de communication entre agents, ou ACL (Agent Communication Languages), définissent en particulier des types de messages indiquant l intention nuancée de l agent émetteur (requête, ordre, information spontanée, proposition de service, affirmation, croyance, etc.). C est le cas du langage KQML (Knowledge Query and Manipulation Language), du langage de la FIPA (Foundation of Intelligent Physical Agents) ou encore du langage défini par l équipe de Y. Demazeau [56]. Communication indirecte La communication indirecte se fait par l intermédiaire de l environnement. Elle correspond à l envoi d un signal dans l environnement ou à la modification de l environnement (création, destruction ou modification d objets). Un signal peut être soumis à des règles de propagation; par exemple, son intensité peut décroître en fonction de la distance entre l émetteur et le récepteur (pour du son) ou en fonction du temps (dans le cas de phéromones). Ce type de communication peut être involontaire, et ainsi participer à une coopération de type réactive, comme dans l exemple de la termitière évoqué en section

39 2.5. CONNAISSANCES Actions sur l environnement L environnement est généralement une simple structure de données dynamique et centralisée, contenant l ensemble des objets partagés en lecture et en écriture par les agents. Il peut ainsi servir de mémoire ou de structure de communication indirecte par exemple. Mais il est également possible de déporter une partie de «l intelligence» des agents au niveau de l environnement [96]. Prenons l exemple d un agent situé mobile, c est-à-dire capable de se déplacer dans un espace géométrique : un tel agent se déplace a priori différemment dans un espace continu et dans un espace constitué de cases carrées. Pourtant, si la gestion du déplacement des agents est laissée à l environnement, l agent demandera seulement à l environnement de le déplacer ; la capacité de déplacement de l agent ne dépend alors plus de la structure de son environnement car la méthode de déplacement est intégrée à l environnement. À l extrême, un banc de poissons peut être simulé entièrement à partir de règles d attraction et de répulsion gérées par l environnement : quelle autonomie reste-t-il aux agents? Il est donc parfois délicat de distinguer l intelligence d un agent de l intelligence de son environnement. Dans le modèle d action en tant que réponse à des influences, proposé par J. Ferber, l agent tente d effectuer une action, mais c est l environnement qui réagit à cette tentative et modifie son état en conséquence ; une action se distingue ainsi clairement de son résultat [64]. Cette approche implique qu une partie des calculs menant à la réalisation d une action soit gérée par l environnement. L environnement centralise donc d une part les lois de l univers, c est-à-dire les règles appliquées à tous les agents comme les lois physiques dans un monde à trois dimensions (gravité, collisions, etc.), et d autre part les informations correspondant à ces règles (données publiques) telles que la position de chacun des agents. Cette centralisation facilite le calcul de l état de l environnement par rapport aux différentes demandes d action des agents, et assure la cohérence des comportements observés des agents par rapport aux réactions attendues dans un monde donné. 2.5 Connaissances Catégories de connaissances Nous distinguerons deux catégories de connaissances utilisées par un agent : connaissance explicite : c est une connaissance symbolique et manipulable (typique de l Intelligence Artificielle traditionnelle) ; connaissance implicite : c est une connaissance intégrée au système, notamment au niveau des processus de décision et de perception (connaissance préprogrammée ou acquise dans un réseau de neurones par exemple). De plus, ces connaissances peuvent être catégorisées selon la durée de leur utilité : les connaissances permanentes correspondent aux connaissances innées implicites ou explicites, tandis que les connaissances temporaires sont créées par l agent au fur et à mesure de son expérience ; ces connaissances acquises sont généralement explicites 6 et sont stockées dans des mémoires à court- ou moyen-terme. R. Arkin propose une liste de connaissances typiquement utiles à un agent [13] : connaissances spatiales : comment naviguer dans le monde? 6 Si la mémorisation utilise des mécanismes tels que les réseaux neuronaux, les connaissances acquises peuvent être implicites et difficiles à manipuler.

40 40 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS connaissances sur les objets : quelles sont les catégories ou les instances d objets du monde? Comment reconnaître ces objets et comment interagir avec eux? connaissances de la perception : comment percevoir le monde? connaissances comportementales : comment réagir aux différentes situations rencontrées? connaissances de soi : quelles sont les limites et les compétences de l agent en termes de perception et d action? La connaissance a priori de l environnement permet entre autres de contraindre le système perceptif. Elle facilite en particulier l interprétation des stimuli, en sachant ce qu il faut s attendre à trouver, ainsi que la focalisation de l attention, en sachant où porter de préférence son attention. Elle pose cependant le problème de la distinction entre les connaissances acquises et les connaissances innées (préprogrammées) d un agent. La connaissance innée impose la signification des informations perçues et des résultats probables des actions choisies sur l environnement, et régit donc en partie le comportement d un agent Représentation de l environnement Les informations recueillies par le système perceptif peuvent soit être utilisées immédiatement puis oubliées, soit être conservées dans une ou plusieurs représentations internes du monde. Une telle représentation permet de conserver et d organiser les propriétés de l environnement jugées pertinentes par l agent, mais également certaines caractéristiques de l agent lui-même. La représentation interne d un agent permet de mieux prédire les réactions de l environnement en fonction de l expérience acquise. Elle est efficace si l agent est capable de générer des hypothèses à partir d une représentation, mais il faut pour cela que cette représentation soit à jour et que l environnement soit suffisamment structuré pour être prédictible. Un agent situé est généralement plongé dans un environnement bruité, et doit réagir à des situations similaires mais pas identiques. La difficulté est donc d une part de mémoriser des informations approximatives, et d autre part d être capable de reconnaître une situation semblable à une situation déjà rencontrée. Par exemple, pour faciliter la navigation, un agent peut mémoriser des points remarquables de l environnement qu il a exploré : zones dangereuses, sources de nourriture, obstacles pouvant le ralentir ou le protéger de ses prédateurs, etc. L élaboration et l utilisation de la représentation interne de l environnement posent le problème de la limite entre la perception d un stimulus en provenance de l environnement et sa traduction en une information permettant à l agent d agir. Ce problème a été abordé dans la section consacrée aux niveaux d abstraction de la perception. 2.6 La conception de systèmes multi-agents Nous laissons de côté les nombreuses bibliothèques de programmation d agents existantes, pour nous intéresser uniquement aux outils graphiques de conception de systèmes multi-agents.

41 2.6. LA CONCEPTION DE SYSTÈMES MULTI-AGENTS ZEUS (H. Nwana et al.) L atelier ZEUS permet de concevoir des systèmes multi-agents répartis [104]. Cet atelier, développé en JAVA, génère automatiquement le code JAVA des agents spécifiés graphiquement. Les hypothèses sur les agents ainsi créés sont fortes : ils doivent être cognitifs c est-à-dire dirigés par des buts et capables de planifier ; ils doivent être collaboratifs, en particulier en étant honnêtes envers les autres agents ; ils peuvent avoir plusieurs buts à satisfaire simultanément ; ils peuvent s engager sur plusieurs tâches à la fois. Le rôle des agents ZEUS est typiquement de raisonner sur quand et comment activer ou désactiver des systèmes externes, ils servent donc principalement à la planification de tâches. L atelier se compose de trois parties : une bibliothèque de composants d agents, un outil de création graphique d agents et un ensemble d agents spécialisés (serveurs de noms, agents de visualisation et de débogage, etc.). L agent générique ZEUS est composé de trois couches internes dédiées : à la définition de l agent, en tant qu entité autonome possédant ses compétences, ses croyances, etc. ; à l organisation, c est-à-dire aux relations de l agent avec les autres agents ; à la coordination (techniques de négociation par exemple). Cet agent générique possède deux couches supplémentaires, l une gérant la communication avec les autres agents, l autre chargée de l interaction avec l environnement (via des capteurs et des effecteurs), composé des systèmes externes à contrôler. Les comportements de haut-niveau, servant principalement à la résolution de problèmes de planification, sont décrits graphiquement par des graphes de réseaux récursifs de transitions, qui seront traduits en machines à états finis pour pouvoir être exécutés sur la plate-forme AGENTBUILDER AGENTBUILDER est un atelier commercial de conception d agents logiciels «intelligents», c est-à-dire là encore d agents cognitifs et collaboratifs [1]. Un agent créé avec cet outil est typiquement un agent d interface, chargé de faciliter la recherche d information ou la réalisation de certaines tâches à la place de son utilisateur. Un tel agent est par exemple capable de filtrer l information, de négocier des services avec d autres agents ou encore de dialoguer avec son utilisateur. L atelier, développé en JAVA, est composé d une interface graphique et d un langage «orienté-agent» de haut-niveau, permettant de définir des croyances, des engagements et des actions. Les documents publicitaires ne sont pas très clairs sur ce sujet, mais il semble que le comportement d un agent soit décrit en définissant des règles comportementales, réagissant à des messages reçus en envoyant d autres messages. L atelier permet de définir des ontologies et des protocoles de communication interagents ORIS (F. Harrouet) ORIS est à la fois un langage permettant de décrire le comportement d objets actifs et un environnement de développement pour ce langage [79]. L objectif de cet atelier

42 42 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS est de faciliter le prototypage dynamique d applications de simulation, en permettant la modification des comportements des objets pendant leur exécution afin d en visualiser immédiatement les conséquences. F. Harrouet, qui a conçu le langage et l environnement ORIS, souligne dans son mémoire de thèse l importance d un ordonnancement équitable de l exécution des entités autonomes manipulées, afin d éviter l introduction de biais dans la simulation au niveau de la plate-forme. Une grande place est donc donnée au contrôle de l ordonnancement : un concepteur définit des threads et doit gérer lui-même leur synchronisation lorsqu ils partagent des ressources. La plate-forme est clairement destinée à des informaticiens, la syntaxe du langage a d ailleurs été choisie de façon à être proche des langages C++ et JAVA pour faciliter l apprentissage d ORIS MADKIT (O. Gutknecht) MADKIT (Multi-Agent Development Kit) est une plate-forme générique de conception et d exécution de systèmes multi-agents, basée sur un modèle organisationnel plutôt que sur une architecture d agent ou sur un modèle d interaction [75]. Le modèle AALAADIN sous-jacent décompose un système multi-agents selon trois entités : l agent, le groupe et le rôle. Le rôle est une abstraction d une fonction, d un service ou d une identification d un agent dans un groupe ; un rôle est local à un groupe. Un agent est membre d un ou plusieurs groupes, dans lesquels il joue des rôles ; il peut entrer dans un groupe ou le quitter dynamiquement, de même qu il peut changer de rôle. Un agent peut jouer plusieurs rôles dans un même groupe, et un même rôle peut être tenu par plusieurs agents. Les groupes permettent de structurer le système multi-agents, en limitant entre autres la communication inter-agents au niveau de chaque groupe. Un agent est simplement une entité active et communicante, qui joue des rôles dans des groupes d agents. Le modèle est conçu pour des systèmes hétérogènes, c est pourquoi l architecture d un agent est aussi abstraite. En pratique, les modèles d agents sont définis dans des bibliothèques, implémentant par exemple plusieurs modèles d agents réactifs, un modèle d acteur ou encore une connexion avec le langage LISP. Le noyau de la plate-forme gère les fonctionnalités de base nécessaires au modèle indépendamment des modèles d agents. Cette gestion est faite au niveau local, c est-à-dire sur un micro-noyau en exécution sur une machine donnée ; elle concerne le contrôle des groupes et rôles locaux, la gestion du cycle de vie d un agent et la communication par message locale. Les fonctionnalités supplémentaires comme la répartition ou la migration des agents sur d autres micro-noyaux sont gérées par des agents spécialisés. Dans l atelier graphique, chaque agent en cours d exécution est chargé de gérer sa propre interface graphique de présentation de son état. L outil SEDIT (Structure Editor) est un éditeur graphique de formalismes, supportant les structures imbriquées, les formalismes étant définis sous la forme de descriptions XML. Cet éditeur a été réalisé avec MADKIT pour être ensuite intégré à la plate-forme. Il est constitué d un ensemble d agents, chaque éditeur étant un agent MADKIT configuré pour un formalisme donné ; il est possible de faire interagir ces éditeurs comme n importe quels agents, ce qui permet de mélanger plusieurs formalismes dans une même description.

43 2.7. SYNTHÈSE Synthèse Reprenons tout d abord la définition que nous avons choisie en introduction : un agent est une entité active et autonome, qui interagit avec un environnement dynamique, et qui peut être intelligente, adaptative ou sociable. Un agent réagit aux stimuli en provenance de son environnement ainsi qu aux messages en provenance des autres agents, par des actions sur l environnement et par l envoi de messages à destination des autres agents. Il est autonome dans le sens où son état interne et son processus de décision sont encapsulés. La figure 2.7 synthétise les principales notions abordées dans ce chapitre. Nous distinguons ici les composants d interaction avec l environnement (capteurs et effecteurs) et les composants de communication avec les autres agents (émetteurs et récepteurs) ; nous y intégrons de plus les connaissances de l agent. Interaction stimuli Capteurs Connaissances Communication messages Environnement actions Effecteurs Processus Agent messages Émetteurs Autres agents FIG. 2.7 Synthèse des caractéristiques d un agent autonome. Nous remarquerons que les variables internes de l agent n apparaissent pas : elles font implicitement partie des connaissances. La perception et l action internes ne sont pas non plus représentées : en fait, ces mécanismes sont en général à peine évoqués dans les articles et ouvrages auxquels nous faisons référence. Ces capacités de l agent sont souvent considérées comme implicites, car la perception et l action externes prévalent. Nous verrons dans les chapitres 5 et 7 pourquoi nous avons, au contraire, choisi de faire ressortir ces caractéristiques. La plupart des outils graphiques de conception de systèmes multi-agents que nous avons présentés concernent des agents cognitifs. Seul l environnement ORIS se rapproche de notre démarche, en s attachant à la description de comportements d entités autonomes a priori réactives. ORIS est cependant destiné aux programmeurs capables de gérer l ordonnancement et la synchronisation des objets actifs. La plateforme MADKIT s abstrait quant à elle complètement du modèle d agent, pour s intéresser uniquement à l organisation des agents. Bien que particulièrement élégante, à la fois dans le modèle organisationnel utilisé que dans sa mise en œuvre, cette plateforme ne correspond pas à notre objectif ; elle ne propose en effet pas de facilités pour décrire le comportement des agents, puisque les modèles d agents sont implémentés dans des bibliothèques indépendantes. Notons enfin que l interaction entre agents et opérateurs humains est un sujet très rarement abordé, car les travaux portent principalement sur les interactions entre agents ou entre un agent et son environnement. L opérateur humain est généralement relégué au rôle de simple observateur. Dans le cas d ORIS, l opérateur peut certes influencer le système dynamiquement, en modifiant le comportement des entités autonomes en cours d exécution; cependant, au niveau du système simulé, l utilisateur n a pas non plus sa

44 44 CHAPITRE 2. AGENTS AUTONOMES ET SYSTÈMES MULTI-AGENTS place. Nous nous intéresserons au problème de l intégration de l opérateur humain dans le chapitre 6 consacré à notre modèle d avatar.

45 Chapitre 3 Le problème de la sélection de l action 3.1 Introduction Un agent autonome doit, à chaque instant, choisir quelle action effectuer parmi un ensemble d actions possibles, en fonction de ses perceptions internes et externes, de son état interne et de ses objectifs 1. La mise en œuvre d un mécanisme de sélection de l action est un problème central dès lors qu il s agit de simuler une créature autonome évoluant dans un environnement dynamique et imprévisible, par exemple un animat. De nombreux travaux en psychologie cognitive et en neurophysiologie ont montré que les différentes facultés cognitives, humaines comme animales, telles que la capacité de reconnaître et catégoriser un objet du monde, de planifier ou même de réaliser des mouvements en apparence simples comme la marche ou la préhension, servent à générer et à contrôler l action suivante de façon à assurer la survie de l individu [26, 62, 127]. L Intelligence Artificielle classique s attache généralement à simuler les facultés humaines telles que le raisonnement logique ou la compréhension du langage naturel ; elle est basée sur la manipulation de connaissances symboliques, considérée comme nécessaire et suffisante pour obtenir des comportements intelligents [62]. Certains de ces systèmes symboliques se sont avérés très performants pour un domaine d expertise donné, mais complètement inefficaces pour des domaines connexes car le modèle de monde introduit par le programmeur n est souvent pas adaptable à un environnement légèrement différent [62] ; par exemple, un agent champion d échecs sera incapable de jouer aux dames. De nombreux travaux en IA classique portent en particulier sur la planification globale symbolique, c est-à-dire sur la sélection d une séquence d actions à réaliser en fonction d une unique représentation symbolique de l environnement et d un objectif global lui aussi unique. L élaboration d un plan est une opération coûteuse dans des environnements complexes, par exemple lorsqu il faut calculer le chemin optimal à suivre pour traverser une pièce contenant un grand nombre d obstacles. Lorsque la planification est le seul mécanisme de sélection de l action, l utilisation d un plan 1 Un agent cognitif peut également prendre en compte les conséquences possibles de ses actions [64]. Nous considérons que les connaissances nécessaires (explicites ou non) font partie de l état interne de l agent, et que les mécanismes de raisonnement sont intégrés au processus de décision au même titre que les comportements réactifs. 45

46 46 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION n est efficace que dans un environnement prévisible : il est évidemment impossible de prévoir tous les cas dans un environnement dynamique et partiellement connu. La planification traditionnelle n est généralement pas interruptible, et ne prend donc pas en compte l environnement courant. Le temps de calcul d un plan peut alors être fatal à un animat devant réagir rapidement à un environnement dangereux. De plus, la séquence d actions peut être produite à partir d hypothèses qui se révèlent invalides au moment de l exécution du plan. Enfin, si la réalisation de l une des actions se révèle impossible au moment de l exécution du plan, cette exécution doit être interrompue et le plan doit être recalculé en fonction du nouveau contexte. Il n est donc pas envisageable de considérer la planification comme seul mécanisme de sélection de l action dans le cadre qui nous intéresse. Devant le manque de réactivité, de robustesse et d adaptativité des agents purement cognitifs, des chercheurs ont posé les bases de ce qu ils ont appelé «la nouvelle IA» 2 à partir de leurs expériences dans les domaines de la robotique autonome et de la vie artificielle, en s inspirant de la biologie et de l éthologie (cf. section 2.2.4, page 32). D après R. Brooks [41], L. Steels [128] ou encore P. Maes [93], il n est pas indispensable d être capable de raisonner sur une représentation abstraite du monde pour présenter un comportement intelligent, c est-à-dire permettant de survivre au mieux dans son environnement (cf. section 2.2.4, page 32). En couplant les capteurs et les effecteurs d un agent situé, il est en effet possible de produire des comportements de survie correspondant à une certaine forme d intelligence ; la représentation symbolique n est pas nécessaire dans ce cas, puisqu il suffit à l agent de savoir interpréter les informations en fonction de sa perception de l environnement et du but poursuivi [62]. De nombreuses architectures réactives ont été proposées et testées avec succès sur des robots mobiles, mais il a été rapidement démontré que l approche purement réactive limitait considérablement les capacités des agents : un système purement réactif est robuste, mais manque d adaptativité puisqu il ne possède ni représentation dynamique de son environnement, ni capacité d apprentissage [13, 71, 11]. Comme nous l avons expliqué en section (page 32), les architectures hybrides permettent aux agents situés de réagir rapidement aux modifications de leur environnement tout en étant capables d anticiper et de planifier quand cela est possible. Pour obtenir des comportements de plus haut-niveau, il est donc indispensable d intégrer une représentation du monde, symbolique ou non (cf. section 2.5, page 39), et des capacités de planification à plus ou moins long terme. Ces capacités cognitives doivent prendre en compte les interactions continues avec l environnement dans lequel est plongé l agent. Deux besoins se font sentir concernant les plans à construire dans le cadre des agents hybrides : il faut réaliser une planification réactive, c est-à-dire être capable de replanifier rapidement ou de raffiner un plan en fonction du temps disponible (planification anytime), mais il faut également construire et manipuler des plans plus abstraits applicables à plusieurs types de configuration [13]. Nous avons choisi de nous intéresser plus particulièrement aux architectures «basées sur les comportements» (behavior-based architectures) appliquées à des agents hybrides, car ce type d architecture possède trois caractéristiques nécessaires, selon nous, à la description explicite de créatures virtuelles crédibles : 2 À force d être opposés à la «nouvelle IA» ( new AI ), les fervents adeptes de l IA classique ont fini par surnommer leur discipline la «bonne vieille IA» ou GOFAI ( Good Old-Fashioned AI )!

47 3.2. L APPROCHE «ORIENTÉE-COMPORTEMENTS» 47 la robustesse : les agents doivent être capables de réagir correctement dans un environnement dynamique et imprévisible, en particulier dans un environnement différent de celui pour lequel ils ont été conçus ; la modularité : les différents systèmes comportementaux réalisant le comportement global de l agent doivent être indépendants les uns des autres pour permettre la description par assemblage de composants, et ainsi faciliter la définition et la maintenance du comportement; l extensibilité : il doit être possible d ajouter des capacités cognitives à des agents d abord réactifs pour qu ils deviennent de plus en plus adaptatifs ; ces extensions doivent pouvoir se faire en modifiant le moins possible l architecture existante. Après avoir introduit le cadre des architectures «basées sur les comportements», nous présenterons des exemples représentatifs d architectures de sélection de l action appliquées à des agents réactifs et hybrides. Nous proposerons ensuite une synthèse faisant ressortir les principales caractéristiques de ces architectures ainsi que leurs différences. 3.2 L approche «orientée-comportements» En IA classique, les différents modules d un système intelligent sont organisés verticalement, par grandes fonctions telles que la vision, la perception, la construction de la représentation du monde ou encore la planification. Les flux de données circulent selon un unique cycle «perception-décision-action», qui ne garantit pas la rapidité de réponse du système. L approche «orientée-comportements» propose une organisation horizontale, dans laquelle chaque module correspond à un cycle perception-décisionaction spécialisé dans la réalisation d une fonctionnalité [42]. Ce type d architecture distribuée permet d organiser des modules qui réagissent indépendamment les uns des autres à des aspects précis de l environnement. Il ne repose pas sur un système centralisé de perception, chargé d interpréter les signaux en provenance de l environnement et de les traduire en données symboliques : chaque module perçoit uniquement les stimuli qui le concernent. De plus, les modules ne partagent pas de représentation centralisée de l environnement ou de l état de l agent : chaque module manipule exclusivement ses données propres. L. Steels définit un comportement d un système (individu ou groupe) comme une «régularité» observée dans la dynamique d interaction entre le système et son environnement. Le comportement est qualifié d intelligent s il permet au système de survivre au mieux dans son environnement [128]. L approche «orientée-comportements» tente de dégager des motifs représentatifs de l interaction d un agent avec son environnement et de les exprimer sous la forme de règles comportementales. Elle s applique essentiellement aux agents situés, qui sont en étroite connexion avec leur environnement. Le problème de la perception et de l action dans un environnement physique, ou tout au moins finement simulé, est important. Dans certains cas, le comportement peut émerger, c est-à-dire être observé sans pour autant avoir été décrit explicitement sous forme de règles. L adaptabilité et les capacités d apprentissage sont souvent mises en exergue, car elles améliorent l intelligence en permettant au système d évoluer dans un environnement dynamique qu il doit explorer.

48 48 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION Pour décrire les architectures basées sur les comportements, L. Steels distingue les comportements (définis précédemment), les systèmes comportementaux et les mécanismes comportementaux d un agent. Les systèmes comportementaux sont des modules capables d assurer une fonctionnalité 3 particulière pour l agent, comme la locomotion, l évitement d obstacle ou la recherche de nourriture. Pour être efficace, un système comportemental doit être adapté à l environnement et aux objectifs de l agent. Une fonctionnalité est réalisée par un ou plusieurs comportements, et un système comportemental peut contribuer à la réalisation de plusieurs fonctionnalités ; il n y a donc pas de relation directe entre un comportement et un système comportemental. Nous verrons cependant par la suite que les systèmes comportementaux sont souvent nommés «comportements» par les concepteurs d architectures. Un système comportemental est constitué d un ensemble de mécanismes comportementaux. Un mécanisme comportemental est un principe ou une technique permettant de créer un comportement particulier, par exemple en couplant des capteurs et des effecteurs ou en construisant une carte cognitive. Un tel mécanisme est implémenté en utilisant des structures et des processus (capteurs, effecteurs, programmes, structures de données, etc.). Les mécanismes comportementaux doivent être les plus simples possibles, afin que ce soient les interactions entre ces mécanismes qui fassent émerger le comportement attendu. Pour résumer, un comportement est ce qui est observé, alors qu un système comportemental est ce qui est implémenté dans l agent par des mécanismes comportementaux de façon à faire émerger le comportement. Enfin, les différents systèmes comportementaux d un agent interagissent, directement ou indirectement, et sont généralement en compétition : pour obtenir un comportement global cohérent, il faut les coordonner. Un ensemble de systèmes comportementaux est ainsi comparable à un système multi-agents constitué d experts autonomes en interaction. Le problème de la sélection de l action est alors généralement celui du choix des actions à réaliser en fonction d objectifs conflictuels. Il ne s agit pas seulement de choisir une séquence d actions nécessaires à la satisfaction d un objectif prioritaire : il faut fréquemment faire des compromis, ou encore combiner des actions indépendantes. T. Tyrrell a réalisé un excellent travail de comparaison des mécanismes de sélection de l action pour différentes architectures basées sur les comportements [135]. Selon lui, une bonne architecture de sélection de l action doit être capable de choisir un système comportemental possédant un certain nombre de caractéristiques, dont voici les principales : motivé : le système comportemental sélectionné correspond prioritairement à celui de plus forte motivation en fonction des objectifs et des ressources de l agent. Par exemple, la faim peut être provoquée par un niveau d énergie faible ; la faim peut déclencher la recherche de nourriture, à condition qu une activité prioritaire, telle que la fuite devant un prédateur, ne soit pas en cours ; interruptible : en cas d urgence, le système comportemental courant peut être interrompu au profit d un autre. Par exemple, la recherche de nourriture pourra être reportée le temps d échapper à un prédateur ; persistant : s il est pertinent, le système comportemental en cours doit continuer afin d éviter l oscillation entre plusieurs systèmes com- 3 Les fonctionnalités sont aussi appelées tâches, objectifs ou encore compétences.

49 3.3. ARCHITECTURES BASÉES SUR LES COMPORTEMENTS 49 portementaux éligibles. Par exemple, si l agent est à la recherche de nourriture, il doit continuer même s il a subitement autant soif que faim ; opportuniste : si l occasion se présente et si le système comportemental courant le permet, un système comportemental de moins forte motivation peut être sélectionné le temps de satisfaire un objectif secondaire. Par exemple, si l agent passe à côté d une source de boisson alors qu il cherche de la nourriture sans être trop affamé, il pourra faire un détour pour boire puis reprendre sa recherche ; direct : le système comportemental doit préférer les actions consommatoires aux actions appétitives, c est-à-dire favoriser les actions qui mènent directement à la satisfaction d un objectif (action finale) par rapport aux actions qui préparent une action consommatoire. Par exemple, l agent a intérêt à manger ce qui est disponible là où il se trouve plutôt que d aller vers une autre source de nourriture ; conciliant : les actions choisies doivent correspondre de préférence à un compromis entre plusieurs solutions, de façon à satisfaire un maximum d objectifs concurrents plutôt que de n en satisfaire qu un seul de façon optimale. 3.3 Architectures basées sur les comportements L animation comportementale C. Reynolds a popularisé l animation dite comportementale (behavioral animation), permettant de simuler des comportements de groupes d entités à partir d un petit nombre de règles appelées comportements et appliquées à chacune des entités [109]. Son modèle est une généralisation des systèmes de particules utilisés pour modéliser la fumée par exemple. Dans son modèle, le comportement des entités simulées est généralement plus complexe que celui de simples particules ; il a été utilisé pour simuler des bancs de poissons, des vols groupés d oiseaux ou encore des mouvements de foules. Comme dans les systèmes de particules, l objectif est de faire émerger le comportement du groupe à partir des réactions de chacun de ses éléments vis-à-vis de son environnement proche, et non pas de contrôler l animation globalement. Les règles choisies doivent donc correspondre à des «perceptions» locales à une entité, et les actions sont appliquées uniquement à cette entité. Dans son premier exemple, C. Reynolds a proposé la simulation d un groupe composé de ce qu il appelle des boids. Ces entités sont des tortues simplifiées, caractérisées par une position, une orientation et une vélocité 4. Elles sont capables d avancer ou de reculer en ligne droite, et de tourner à gauche ou à droite. Chaque boid a accès à la position, à l orientation et à la vélocité de tous les autres objets du système (boids et obstacles). Cette perception n est pas réaliste mais elle permet d obtenir des animations très fluides. Les voisins d un boid sont les boids présents dans une zone sphérique centrée sur le repère d origine du boid. 4 La vélocité est une combinaison de la direction de la tête et de la vitesse du boid.

50 50 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION Trois règles comportementales suffisent pour animer de façon remarquablement réaliste un groupe de boids : 1. l évitement de collision : il faut éviter les collisions avec les boids voisins ; 2. l alignement de la vélocité : il faut conserver une vélocité proche de celle de ses voisins ; 3. le centrage par rapport au groupe : il faut rester le plus près possible de ses voisins. L évitement de collision et l alignement par rapport à la vélocité des voisins sont des règles fortement liées : elles permettent de maintenir une distance raisonnable entre boids voisins. L attraction vers le centre de ses voisins permet d obtenir des groupes homogènes. De plus, lorsque le groupe doit se séparer pour éviter un obstacle, cette dernière règle permet de réunir à nouveau le groupe. Les obstacles environnementaux, statiques ou animés, sont évités grâce à une quatrième règle comportementale. Un obstacle est pris en compte seulement s il se trouve en face du boid, c est-à-dire lorsque l axe de la direction du boid est en intersection avec l obstacle. À chaque pas de simulation, chaque comportement propose une action sous la forme d un vecteur 3D d accélération. Chaque comportement est par ailleurs associé à un poids, compris entre 0 et 1, permettant d atténuer l influence de la proposition. Le boid doit ensuite combiner les différentes propositions afin d appliquer un seul vecteur d accélération. Une solution simple est de faire une moyenne des vecteurs proposés, pondérée par les poids de chaque comportement. Cette solution est efficace dans la plupart des cas mais donne des résultats irréalistes dans des conditions critiques, en particulier dans le cas de l évitement d obstacles : si deux comportements proposent de contourner différemment un obstacle, l un par la droite et l autre par la gauche, la combinaison des deux vecteurs peut amener le boid à aller tout droit et donc à entrer en collision avec l obstacle. Pour résoudre ce problème, C. Reynolds choisit d affecter des priorités strictes aux différentes règles comportementales. Les comportements moins prioritaires pourront être ignorés au profit des comportements devant réagir dans l urgence; par exemple, la règle de centrage par rapport au groupe sera ignorée le temps d éviter un obstacle. Dans [110], C. Reynolds présente un ensemble de règles comportementales supplémentaires, permettant de simuler des comportements plus évolués. Un boid peut alors fuir ou poursuivre un autre boid, ou encore suivre un boid considéré comme le chef du groupe L architecture de subsomption À la fin des années 1980, R. Brooks a proposé l une des premières architectures basées sur les comportements : l architecture de subsomption. Elle est présentée dans de nombreux articles, dont la plupart sont regroupés dans un ouvrage récent consacré aux débuts de l histoire de la «nouvelle IA» [43]. Les unités de base de cette architecture sont appelées comportements. Les comportements sont constitués d automates à états finis temporisés, qui fonctionnent de façon totalement asynchrone, qui peuvent être réinitialisés et qui manipulent des variables internes. Un comportement possède des entrées et des sorties lui permettant d interagir

51 3.3. ARCHITECTURES BASÉES SUR LES COMPORTEMENTS 51 avec les autres composants du système que sont les capteurs, les effecteurs et les autres comportements. Les composants sont reliés les uns aux autres par des connexions prédéfinies sur lesquelles transitent des messages. Chaque entrée est associée à un registre contenant le dernier message reçu sur cette entrée. Les comportements peuvent être regroupés en couches appelées niveaux de compétence, correspondant chacune à un système comportemental. Les niveaux de compétence sont hiérarchisés : les comportements de niveau peuvent contrôler les comportements de niveaux inférieurs. Ce contrôle se fait indirectement, c est-à-dire sans que les comportements contrôlés en soient informés, grâce à deux mécanismes dits de subsomption : l inhibition et la suppression. L inhibition consiste à empêcher la diffusion de messages sur la sortie d un comportement. La suppression permet d une part d empêcher l arrivée des messages envoyés sur une entrée par la source habituelle, et d autre part de propager les messages du comportement dominant sur cette entrée ; cela permet de modifier les données auxquelles doit réagir le comportement dominé. La synchronisation est explicite : il faut préciser la durée de chaque opération de subsomption au niveau de la connexion. Pour qu une opération de subsomption soit déclenchée, il suffit qu un message soit envoyé sur la sortie du comportement dominant. Les relations de dominance imposent des priorités strictes, qui sont censées résoudre les conflits entre les actions choisies par les différents modules. La sélection de l action repose donc uniquement sur les relations hiérarchiques entre comportements. La figure 3.1 présente un exemple tiré de [41] : les trois niveaux de compétence correspondent à l évitement de collisions (obstacles statiques ou non), au déplacement aléatoire (sans but précis), et à l exploration de l environnement par la sélection d une zone visiblement atteignable puis le déplacement vers cette zone. De nombreux robots ont été implémentés avec succès selon cette architecture ou ses variations [42]. Wandering whenlook startlook ROBOT stereo look init path candidate integrate integral pathplan status travel busy Exploring I wander 75 heading S 15 avoid heading Collision avoidance ROBOT sonar map feelforce force runaway heading S 20 collide halt ROBOT turn encoders busy heading ROBOT forward encoders FIG. 3.1 Exemple d architecture de subsomption sur 3 niveaux. La principale critique faite à cette architecture concerne la difficulté de concevoir et de maintenir un système comportemental cohérent [13]. Les niveaux de compétence sont censés être indépendants, mais en pratique les comportements ne peuvent pas être conçus complètement indépendamment les uns des autres, car l arbitrage est réalisé par

52 52 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION des opérations appliquées directement aux entrées et aux sorties des comportements des couches inférieures. De plus, il n est pas toujours possible de définir des priorités entre les comportements, et aucun autre mécanisme n est proposé pour gérer les actions conflictuelles. Nous ajouterons à cela que la gestion explicite de la temporisation, nécessaire pour chaque opération de subsomption, rend la conception du système encore plus délicate Les schèmes moteurs de R. Arkin La théorie des schèmes (schema theory) et les réseaux neuronaux sont les deux principaux modèles informatiques utilisés pour représenter le fonctionnement du cerveau. Le schème est défini comme étant l unité de base du comportement; il encapsule des connaissances lui permettant de réagir, ainsi qu un processus correspondant à la façon dont il lui faut réagir. Le comportement global émerge du contrôle des activités concurrentes des différents schèmes. Dès 1987, R. Arkin propose une approche basée sur les schèmes moteurs (motor schemas), appliquée à la navigation de robots autonomes [13]. La particularité de cette approche est la représentation des réponses des schèmes moteurs selon un unique format : un vecteur d action. Ce vecteur est généré selon des méthodes à base de champs de potentiels considérant les cibles comme des attracteurs et les obstacles comme des répulseurs 5. La coordination entre schèmes moteurs se fait alors simplement en additionnant l ensemble des vecteurs calculés par les schèmes actifs, après multiplication de chaque vecteur par le poids dynamique associé à chaque schème. Il en résulte un unique vecteur d action correspondant à la direction que le robot doit suivre. Ainsi, chaque unité comportementale participe à l émergence du comportement global. Un schème moteur génère un vecteur d action à partir des informations fournies par ses schèmes de perception (perceptual schemas). Selon les informations perçues dans l environnement, chaque schème de perception peut créer des stimuli utiles au schème moteur auquel il est attaché. Les schèmes de perception peuvent être définis récursivement, comme dans l exemple représenté par la figure 3.2, ce qui permet de composer des filtres. La principale critique faite à cette approche est celle qui a d abord été faite aux méthodes à base de champs de potentiels : elle est sujette au problème des minima locaux. De nombreuses méthodes permettent maintenant de limiter les risques de se retrouver dans une situation non optimale [13]. Notre critique concerne plutôt les données manipulées par les schèmes moteurs. Il est vrai que le vecteur d action est particulièrement adapté à la navigation de créatures autonomes et que la coordination par addition de vecteurs est simple et efficace. Cette solution ne peut cependant pas facilement être transposée à d autres schémas de comportements. Par exemple, il est impossible de représenter l utilisation d une pince de robot pour la manipulation d objets, ou l action correspondant au dépôt d une phéromone par une fourmi simulée. 5 Les méthodes traditionnelles basées sur les champs de potentiels sont coûteuses car elles nécessitent le calcul de l ensemble des vecteurs du champ. Utilisé dans un environnement statique, un champ de potentiels permet de planifier efficacement un chemin ; il devient par contre inefficace dans un environnement dynamique. Dans l approche de R. Arkin, seul le vecteur correspondant à l action choisie en fonction des stimuli courants est calculé, c est pourquoi l auteur précise qu il utilise des versions de ces méthodes adaptées aux systèmes réactifs.

53 3.3. ARCHITECTURES BASÉES SUR LES COMPORTEMENTS 53 Σ Moteurs capteur environnemental FIG. 3.2 Exemple de schèmes moteurs et de schèmes de perception L architecture ascendante de P. Maes En 1989, P. Maes a proposé une architecture de sélection de l action qualifiée d ascendante (bottom-up) [93]. Cette architecture repose sur un réseau non-hiérarchique de nœuds correspondant aux comportements appétitifs et consommatoires de base des agents (boire de l eau, s approcher d une source de nourriture, fuir une créature, etc.). Un seul nœud peut être exécuté à un moment donné : la sélection se fait sur le niveau d activation des nœuds, le nœud de niveau le plus élevé étant sélectionné. Le niveau d activation des nœuds décroît automatiquement à chaque pas de réaction de l agent. Un nœud perçoit l environnement de l agent sous la forme de préconditions, correspondant à la présence ou à l absence de caractéristiques de l environnement au moment de leur évaluation. Un nœud est éligible seulement si toutes ses préconditions sont satisfaites, mais tous les nœuds participent au choix du nœud à exécuter. Chaque nœud calcule son niveau d activation en fonction des motivations de l agent, par exemple la faim ou la curiosité, et de ses connexions avec d autres nœuds. Ces connexions permettent de propager une excitation ou une inhibition, c est-à-dire d augmenter ou de réduire le niveau d activation d autres nœuds. Cette approche originale, illustrée sur la figure 3.3, a été mise en œuvre et critiquée par T. Tyrrell [135]. D après lui, le mécanisme est efficace lorsqu il s agit d interrompre un comportement en cas d urgence ou pour profiter des opportunités. Par contre, il ne satisfait pas la caractéristique de persistance et de préférence des comportements consommatoires. De plus, il n est pas efficace avec un grand nombre nœuds et d objectifs conflictuels, en particulier parce qu aucun mécanisme ne permet de combiner les actions des comportements DAMN DAMN (Distributed Architecture for Mobile Navigation) est une architecture distribuée et hiérarchique développée par J. Rosenblatt pour la navigation de robots mobiles [118]. Elle découle de ses précédents travaux effectués en collaboration avec D. Payton, et dont l efficacité dans le cadre de la mise en œuvre d animats a été démontrée par T. Tyrrell. Les comportements de DAMN sont des processus asynchrones, correspondant à

54 54 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION peur agression se battre peur curiosité explorer nourriture perçue aller vers nourriture aller vers eau boire eau accessible manger dormir soif paresse faim motivations conditions de perception liens d excitation ou d inhibition FIG. 3.3 Exemple d architecture ascendante (tiré de [135]). des modules réactifs aussi bien que cognitifs. L originalité du modèle réside dans le mécanisme de vote utilisé pour sélectionner une action à réaliser. Chaque arbitre du système est responsable de la sélection de l action pour une variable caractéristique du robot, par exemple sa vitesse ou son angle de rotation. Les actions associées à une variable sont discrétisées, un arbitre possède donc autant d entrées que d actions élémentaires possibles sur cette variable. Les comportements votent pour ou contre chacune des actions de l arbitre, par exemple en donnant une valeur entre -1 et 1. L arbitre calcule ensuite une moyenne des votes pour chaque action, chaque vote étant pondéré par le poids du votant. L action comptabilisant le plus grand score est sélectionnée : elle correspond au meilleur compromis. L arbitre envoie alors aux effecteurs la commande correspondant à l action choisie. Les poids des comportements sont gérés globalement par un module spécifique (mode manager), et peuvent évoluer au cours de l exécution pour favoriser des comportements adaptés à la situation courante. La figure 3.4 donne un exemple d arbitre de rotation, avec une décomposition de l action correspondante en cinq actions élémentaires. La taille des cercles indiquent la valeur absolue des votes (de 0 à 1). Les cercles noirs correspondent à des valeurs négatives, et l épaisseur des flèches au poids des comportements. Un arbitre peut aussi encapsuler des actions abstraites, représentant par exemple le déplacement vers un ensemble de zones, relativement à la position et à l orientation courantes du robot. DAMN est une architecture qui permet de sélectionner une action prédéfinie en fonction des préférences des comportements impliqués. Cette solution est différente de la combinaison de propositions d actions, car elle ne résulte pas en une action véritablement construite à partir de propositions. La discrétisation des actions simplifie la définition des comportements et des arbitres, en déterminant une fois pour toutes les actions primitives possibles sur les variables. Cette approche est particulièrement pratique dans le cas d actions abstraites, pour lesquelles il n est pas toujours évident de

55 3.3. ARCHITECTURES BASÉES SUR LES COMPORTEMENTS 55 Arbitre de rotation à gauche un peu à gauche tout droit un peu à droite à droite Comportement Comportement de recherche d objectif FIG. 3.4 Exemple d arbitre DAMN. proposer directement une valeur à affecter à une variable du système. Il s agit cependant d une solution statique, qui nécessite de concevoir en même temps un arbitre et les comportements devant utiliser cet arbitre en lui envoyant autant de votes que d actions possibles L architecture de B. Blumberg B. Blumberg a conçu une architecture de sélection de l action améliorant les architectures critiquées par T. Tyrrell, en s inspirant de modèles éthologiques [27, 29, 28]. Il propose tout d abord de distinguer les comportements et les compétences motrices (motor skills). Un comportement est associé à des objectifs qu il cherche à atteindre, et il est activé en fonction des stimuli en provenance de l environnement : c est un système comportemental. Une compétence motrice correspond à une séquence d actions lancée par un comportement ; cette compétence manipule les caractéristiques géométriques de l agent et dépend uniquement de l évolution des variables internes de l agent. Les compétences motrices sont gérées par un contrôleur spécifique (motor controller) ; les comportements s adressent à ce contrôleur pour demander l exécution de séquences d actions. B. Blumberg se base ensuite sur un principe de l éthologie : un seul comportement peut être actif à la fois, même si les autres comportements peuvent influencer la sélection finale de l action. La sélection du comportement actif se fait sur les niveaux d activation, comme dans le modèle de P. Maes (cf. section 3.3.4). Le calcul du niveau d activation prend en compte les stimuli externes et l état des variables internes de l agent. Les stimuli externes sont générés par des modules spécifiques correspondant à des filtres (releasing mechanisms), qui extraient les événements et les objets pertinents des informations brutes en provenance de l environnement. La figure 3.5 illustre un exemple d utilisation de cette architecture. La sélection des compétences motrices se fait à deux niveaux : seul le comportement actif peut envoyer des commandes primaires, les autres comportements pouvant seulement proposer au contrôleur des commandes secondaires (actions souhaitables

56 56 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION perceptif Filtres Comportement Variable interne Variable interne Fatigue Inhibition Commandes motrices Contrôleur motrices FIG. 3.5 Exemple de comportement, selon l architecture de B. Blumberg. mais non indispensables) ou des méta-actions (recommandations concernant la façon de réaliser une action). Toutes les commandes primaires sont exécutées immédiatement ; les commandes secondaires et les méta-actions sont ensuite exécutées si cela est possible (s il reste assez de temps). B. Blumberg cherche enfin à équilibrer l opportunisme et la persistance des comportements en incorporant la fatigue et l inhibition mutuelle dans le calcul du niveau d activation des comportements. La fatigue est relative à un comportement souvent activé : grâce à ce mécanisme, les comportements moins prioritaires ont la possibilité de s exécuter de temps à autres. Un comportement peut inhiber un comportement, en lui associant un gain supérieur à 1 ; ce gain est multiplié au niveau d activation du comportement pour obtenir la valeur d inhibition pour le comportement. Le niveau d inhibition d un comportement correspond à la somme de toutes les valeurs d inhibition appliquées par les autres comportements. B. Blumberg a montré que ce mécanisme d inhibition mutuelle permettait de contrôler la persistance d un comportement. Les comportements sont par ailleurs organisés hiérarchiquement et en groupes. Les comportements de plus haut-niveau, comme la tendance à diminuer la faim, dépendent de comportements de plus bas-niveau, comme la recherche de nourriture ou la mastication. Les sous-comportements nécessaires à un comportement sont réunis en un groupe (behavior group), au sein duquel un seul comportement peut être actif à la fois. Comme un sous-comportement peut être nécessaire à plusieurs comportements de plus haut niveau, un comportement peut appartenir à plusieurs groupes. Lorsqu un comportement est activé dans un groupe, il peut soit envoyer des commandes primaires au contrôleur, soit initier la sélection d un comportement dans le groupe de ses sous-comportements. Un groupe est donc constitué de façon à représenter différentes stratégies menant à la réalisation de l objectif du comportement hiérarchiquement supérieur. Cette architecture est complexe, mais elle semble adaptée pour modéliser le com-

57 3.3. ARCHITECTURES BASÉES SUR LES COMPORTEMENTS 57 portement d animats. Étendue par un mécanisme d apprentissage, elle a démontré son efficacité sur des exemples variés : le chien SILAS, capable d interagir avec un opérateur humain ou un dresseur artificiel, ou encore un malheureux hamster qui doit apprendre à éviter les chocs électriques. C est une architecture efficace pour la simulation d animaux, en particulier en ce qui concerne leur animation. C est hélas une architecture à la fois trop statique et trop complexe, qui ne permet pas de décrire facilement d autres types de comportements, qu ils soient plus simples comme celui d une plante ou plus complexes comme celui d un agent capable de dialoguer avec l utilisateur Boucle SCA et PAT-NETS N. Badler et son équipe travaillent depuis de nombreuses années sur la simulation d humains virtuels [17, 18, 15, 19]. Ils ont développé le système JACK, qui rivalise avec les simulations du laboratoire de D. Thalmann évoquées précédemment (cf. section 2.3.3, page36). Comme dans le modèle de B. Blumberg (cf. section 3.3.6), les capacités motrices manipulant la géométrie d un agent sont nettement séparées des modules représentant les comportements de plus haut-niveau. Les capacités motrices sont gérées par une boucle réactive appelée SCA (Sense-Control-Action). Les comportements de plus haut-niveau sont constitués d automates appelés PAT-NETS (Parallel Transition Networks). Ces automates s exécutent en parallèle afin de simuler les activités humaines simultanées, comme le fait de parler tout en marchant. Les PAT-NETS permettent de contrôler une animation dans laquelle des mouvements peuvent être amorcés, interrompus ou modifiés en fonction d événements et de conditions, c est-à-dire au gré des transitions entre les états des automates. Dans son travail de thèse, B. Reich s est focalisé sur l application de la boucle SCA et des PAT-NETS à la locomotion d humains virtuels [108]. La boucle réactive est composée d un moteur d animation (locomotion engine) et d un ensemble de comportements de bas-niveau appelés comportements instantanés. Un comportement instantané est une fonction d évaluation, qui fait correspondre à un état donné du monde une valeur de stress, c est-à-dire une valeur maximale acceptable. À chaque pas de temps, le moteur d animation propose des états possibles du monde pour le pas de temps suivant, par exemple un ensemble de positions atteignables en fonction de l environnement et des capacités de l agent. Il ajoute ensuite pour chaque état possible l ensemble des valeurs de stress calculées par les comportements instantanés actifs. L état associé à la plus faible somme est sélectionné, et les actions menant à sa réalisation sont exécutées. Les comportements instantanés sont divisés en deux catégories : niveau 0 : les réflexes de survie, principalement l évitement de collision, et les comportements liés aux contraintes physiques, comme l inertie ou la gravité ; niveau 1 : les comportements associés à des buts qu ils cherchent à atteindre ; ils correspondent généralement à des comportements d attraction. Les comportements de niveau 0 sont toujours actifs. Les comportements de niveau 1 correspondent aux compétences motrices de B. Blumberg et sont activés par les comportements de plus haut-niveau. D après B. Reich, il suffit d un ensemble de comportements d évitement et d un unique comportement d attraction pour obtenir un comportement de locomotion réaliste. Un seul comportement de niveau 1 est donc actif

58 58 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION à un instant donné, ce qui facilite grandement l arbitrage au niveau du moteur d animation. Un comportement de haut-niveau est constitué d un PAT-NET, lui permettant en particulier de mémoriser des valeurs et d agir en fonction de cette mémoire. Plusieurs automates peuvent s exécuter en parallèle, ce qui devrait poser le problème de l arbitrage entre automates afin de n activer qu un seul comportement de niveau 1. Rien n est cependant précisé dans le mémoire de thèse à ce propos et tous les exemples présentés utilisent des automates qui n entrent jamais en conflit, il est donc difficile de connaître le fonctionnement du mécanisme d arbitrage choisi. Les PAT-NETS peuvent être implémentés en LISP ou en C++ dans la plate-forme JACK, mais la programmation et la maintenance d automates sont des opérations délicates : une petite modification des spécifications peut entraîner un bouleversement de la structure d un automate. Pour faciliter la conception d humains virtuels, N. Badler propose de représenter les actions sous la forme d actions abstraites paramétrées appelées PAR (Parameterized Action Representation) [19]. Ce modèle d actions abstraites se veut le plus proche possible du langage naturel, tout en restant compatible avec une implémentation utilisant les PAT-NETS. D autres extensions de JACK ont été réalisées pour rendre de plus en plus réaliste le comportement des humains virtuels : l architecture SODAJACK ajoute un mécanisme de planification pour la préhension et la manipulation d objets [68, 91], et un modèle a été récemment proposé pour modéliser l attention, c est-à-dire l animation du regard en fonction des motivations et des événements [16] Le modèle HPTS Le modèle HPTS (Hierarchical Parallel Transition Systems), défini par S. Donikian et É. Rutten, est basé sur une hiérarchie de modules constitués d automates parallèles. Il a été implémenté par ses auteurs dans le langage réactif synchrone SIGNALGTI sous la forme d un ensemble d équations dynamiques [59], puis par G. Moreau dans le cadre de la plate-forme GASP (General Animation and Simulation Platform) [103]. Ce modèle s inspire entre autres des PAT-NETS et des travaux réalisés sur le simulateur de conduite interactive complexe IDS (Iowa Driving Simulator). Une des particularités intéressantes de ce modèle est qu un automate permet de décrire aussi bien les comportements d un agent, que ses capteurs ou ses actions d animation internes et externes. L interface d un automate est constituée d un ensemble d entrées, de sorties et de paramètres de contrôle, ainsi que d une boîte aux lettres. Les entrées et les sorties transmettent des flots continus de données. Les paramètres de contrôle influencent le comportement de l automate ; ils peuvent être modifiés par l automate lui-même ou par une entité extérieure. La boîte aux lettres permet de recevoir des messages, provenant en particulier des sous-automates et de l automate hiérarchiquement supérieur. Des messages prédéfinis permettent de contrôler l activité d un automate (lancement, suspension, reprise ou terminaison) et d indiquer le statut courant de l automate (actif, inactif ou suspendu). Un automate encapsule par ailleurs des variables locales, une fonction d intégration et un ensemble de sous-automates. Si cet ensemble est vide, l automate est un état

59 3.3. ARCHITECTURES BASÉES SUR LES COMPORTEMENTS 59 atomique. Plusieurs sous-automates peuvent être actifs en même temps. Le rôle de la fonction d intégration d un automate dépend de sa constitution : si l automate est un état atomique, la fonction d intégration dépend uniquement des flots d entrées, des variables locales et des paramètres de contrôle ; sinon, la fonction d intégration réalise l arbitrage entre les propositions d action des sous-automates actifs. La fonction d intégration peut être : une fonction classique, comme les opérations de calcul ou de comparaison sur les types de base (entiers, réels et booléens) ; une fonction de filtrage, comme la saturation ou le seuillage ; une fonction de préemption, qui gère les actions conflictuelles selon des priorités strictes ; un opérateur de retard, permettant de temporiser la circulation des données dans le cas de dépendances cycliques ; une composition des fonctions précédentes. Les automates HPTS peuvent être implémentés directement en C++ dans la plateforme de simulation GASP, mais, comme nous l avons déjà évoqué pour les PAT-NETS, ce n est pas une solution confortable. G. Moreau propose donc un langage spécifique de description d automates HPTS, ainsi qu une interface graphique. Plusieurs exemples conséquents valident l utilisation du modèle HPTS dans le cadre de la simulation de conducteurs autonomes Les systèmes dynamiques Le principe de l architecture basée sur les systèmes dynamiques proposée par L. Steels est de relier les capteurs aux effecteurs d un robot par des processus continus [128]. Par exemple, pour que le robot avance en tournant légèrement sur sa gauche, un processus doit choisir des valeurs adaptées pour les vitesses des moteurs gauche et droit. Un processus modifie les variables du système selon des équations différentielles : il demande l ajout ou le retrait d une certaine «quantité» aux variables. À chaque pas d exécution, les opérations sur chaque variable sont additionnées pour obtenir la nouvelle valeur. Chaque variable est directement associée à une action sur un effecteur. Le langage PDL (Process Design Language) facilite la description des différents processus d un tel système. L exemple suivant, tiré de [128], montre comment exprimer la conservation de la vitesse par défaut à partir de deux processus : void downto_default_speed (void) { if (value(forward_speed) > 10) add_value (forward_speed, -1); } void upto_default_speed (void) { if (value(forward_speed) < 10) add_value (forward_speed, 1); } La combinaison d actions selon ce modèle pose les mêmes problèmes que ceux évoqués par C. Reynolds concernant les situations critiques (cf. section 3.3.1). Comme le suggère L. Steels dans [128], un mécanisme de contrôle est alors nécessaire, au niveau des effecteurs ou par l intermédiaire de variables supplémentaires pouvant in-

60 60 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION fluencer le comportement des processus impliqués. Ce mécanisme n est hélas pas détaillé dans cet article. 3.4 Synthèse Toutes les architectures basées sur des comportements que nous avons présentées dans ce chapitre respectent bien le principe énoncé par R. Brooks, R. Arkin et L. Steels : le comportement global d un agent doit émerger de l interaction entre des systèmes comportementaux concurrents et coordonnés, qui correspondent à des cycles perception-décision-action indépendants et qui sont chargés de réaliser les grandes fonctionnalités de l agent. Cette caractéristique est schématisée par la figure 3.6. Par contre, les mécanismes comportementaux et les stratégies de coordination mis en œuvre sont variés. perception décision action comportemental 1 comportemental 2 comportemental 3 de coordination FIG. 3.6 Schéma général de la mise en œuvre de systèmes comportementaux Stratégies de coordination Deux types d arbitrage sont utilisés : la sélection compétitive, qui active un seul système comportemental 6 ; la sélection coopérative basée sur la combinaison d actions, qui permet de prendre en compte les propositions de plusieurs systèmes comportementaux. Certaines architectures ne proposent qu un seul type de sélection. Les schèmes moteurs de R. Arkin utilisent seulement la combinaison d actions par l addition de vecteurs. L architecture de P. Maes quant à elle est purement compétitive, puisqu un seul système comportemental est sélectionné pour être exécuté. De même, l architecture de subsomption de R. Brooks est basée sur des priorités strictes entre les niveaux de compétences (par l intermédiaire des liens hiérarchiques d inhibition et de suppression) : un seul système comportemental peut envoyer une commande à un effecteur à un moment donné. La plupart des architectures proposent cependant à la fois des formes de sélection compétitives et coopératives. Les vecteurs d accélération calculés par les règles comportementales de C. Reynolds sont généralement combinés, mais les priorités strictes entre règles permettent de favoriser un comportement d urgence. Dans le modèle de B. Blumberg, un seul système comportemental a accès aux commandes primaires, mais 6 C est le principe du «gagnant rafle la mise», ou winner-take-all.

61 3.4. SYNTHÈSE 61 les autres comportements peuvent influencer le résultat final. Le cas de DAMN est difficile à catégoriser : selon R. Arkin, le mécanisme de vote est compétitif car il mène à la sélection d une seule action prédéfinie [13]. Pourtant, il combine les votes de plusieurs systèmes comportementaux, même s il ne construit pas une action à partir de propositions. Par le biais des fonctions d intégration, le modèle HPTS permet de décrire des mécanismes de sélection aussi bien compétitifs que coopératifs. De plus, grâce à la hiérarchisation des automates, cette sélection se fait au niveau de chaque automatepère : les mécanismes comportementaux sont définis de la même façon que le système comportemental qu ils constituent. Le schéma de la figure 3.6 peut être appliqué récursivement pour représenter des systèmes comportementaux eux-mêmes définis à partir de sous-systèmes comportementaux (réalisant les grandes fonctionnalités du systèmepère) et d un mécanisme d arbitrage. Cette architecture nous semble donc être la plus modulaire et la plus générique. L architecture basée sur les systèmes dynamiques de L. Steels est a priori coopérative, puisque les valeurs des variables sont directement modifiées par les processus sans discrimination, mais les mécanismes nécessaires pour coordonner des processus non-coopératifs ne sont pas détaillés. Par manque d information, il nous est aussi impossible de catégoriser l architecture des humains virtuels de N. Badler Mécanismes comportementaux Les mécanismes comportementaux définissent la façon dont les systèmes comportementaux fournissent des sorties en fonction de leurs entrées. La plupart des architectures présentées utilisent les trois types de mécanismes suivants pour réaliser des systèmes comportementaux : des fonctions classiques de calcul ou de filtrage ; des automates à états finis ; la programmation ad-hoc de corps exécutables dans le langage de la plate-forme. La première catégorie peut s appliquer au calcul de valeurs de stress, de vecteurs d accélération et de vecteur d action, respectivement utilisés par la boucle SCA définie par B. Reich, par les règles comportementales de C. Reynolds et par les schèmes moteurs. L architecture de subsomption, les PAT-NETS et le modèle HPTS entrent dans la deuxième catégorie. DAMN et les architectures de P. Maes et B. Blumberg font partie de la troisième catégorie. L. Steels considère que son architecture basée sur des processus dynamiques est un type de mécanisme à part entière [128]. D autres mécanismes comportementaux sont possibles, comme les réseaux neuronaux ou les systèmes de classifieurs ; ces derniers ont d ailleurs été récemment utilisés avec succès pour décrire des comportements d entités virtuelles adaptatives et coopératives [123]. Nous remarquerons que, bien que les systèmes comportementaux représentent toujours les grandes fonctionnalités d un agent (locomotion, recherche et absorption de nourriture, reproduction, etc.), le grain de définition de ces systèmes varie d une architecture à l autre. Certaines architectures, comme HPTS ou l architecture de subsomption, permettent de décomposer un système comportemental en sous-systèmes. Avec le modèle HPTS, les sous-automates sont définis de la même façon que l automatepère, alors que R. Brooks distingue les niveaux de compétence et les automates qui les

62 62 CHAPITRE 3. LE PROBLÈME DE LA SÉLECTION DE L ACTION constituent. Les autres modèles, comme DAMN ou l architecture de P. Maes, considèrent un système comportemental comme un module opaque. Dans le cadre de la description modulaire de comportements d agents autonomes, il nous paraît important d offrir la possibilité de définir de manière récursive un système comportemental à partir de sous-systèmes comportementaux décrits selon le même modèle.

63 Chapitre 4 Systèmes et langages réactifs synchrones 4.1 Introduction Selon D. Harel et A. Pnueli, les systèmes informatiques peuvent être catégorisés comment étant réactifs, interactifs ou transformationnels, en fonction de leur degré d interaction avec leur environnement [78]. Contrairement à un système transformationnel, correspondant à un unique calcul de fonction, un système interactif ou un système réactif doivent maintenir une interaction constante avec leur environnement. Nous verrons dans ce chapitre les différentes solutions actuellement proposées pour concevoir des systèmes réactifs, en particulier lorsque ceux-ci doivent respecter des contraintes de temps-réel. Nous présenterons à ce propos le modèle synchrone, basé sur la notion d instant et sur l hypothèse d un temps nul de réaction du système. Nous nous intéresserons tout particulièrement au langage impératif synchrone ESTEREL dont nous nous sommes fortement inspirés pour définir la syntaxe du langage MARVIN (cf. chapitre 8). Nous étudierons ensuite la mise en œuvre d un système synchrone, qui passe par la conception d une machine d exécution regroupant les mécanismes d interfaçage nécessaires entre le système et son environnement asynchrone. Avant de conclure, nous présenterons deux modèles, qui ont été des sources importantes d inspiration pour notre modèle de modules comportementaux (cf. chapitre 7), à savoir les réseaux de processus réactifs et les objets synchrones. 4.2 Approche synchrone pour les systèmes réactifs Systèmes transformationnels, interactifs et réactifs Historiquement, les systèmes transformationnels et interactifs proviennent de la programmation classique, à laquelle ont été ajoutés des mécanismes de gestion d événements, de synchronisation et de programmation concurrente, alors que les systèmes réactifs sont issus des domaines du génie électrique, de l automatique et des systèmes embarqués. Un système transformationnel effectue des calculs à partir des données fournies en entrée, pour produire des résultats en sortie avant de se terminer (cf. figure 4.1). L interaction avec l environnement se limite donc à l acquisition des données et à la production de résultats, comme dans le cas d un compilateur par exemple. 63

64 64 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES Un tel système n a pas d état interne, le résultat dépend ainsi uniquement des données en entrée (à moins d utiliser des fonctions aléatoires). lancement (données) terminaison (résultats) t t t FIG. 4.1 Exécution d un système de type transformationnel. Les systèmes interactifs et réactifs interagissent continuellement avec leur environnement, en produisant des résultats à chaque invocation. Ces résultats dépendent des données fournies par l environnement lors de l invocation, ainsi que de l état interne du système. La différence entre ces deux types de système réside dans l entité qui contrôle l interaction. Dans un système interactif comme une base de données, la prise en compte des requêtes et la production de réponses se font à l initiative du système, qui impose ainsi son propre rythme comme le montre la figure 4.2. e1 r1 e2 r2 t 1 t 1 t 2 t 2 t FIG. 4.2 Exécution d un système de type interactif. Un système réactif doit, quant à lui, être toujours en mesure de fournir une réponse immédiate quand l environnement le sollicite. L évolution d un système réactif est donc une suite de réactions provoquées par l environnement, chaque réaction étant considérée comme instantanée par rapport à l échelle de temps propre à l environnement (cf. figure 4.3). Les interfaces homme-machine et les programmes de contrôle de processus industriels sont des exemples typiques de systèmes réactifs. La notion de réactivité est bien sûr une représentation idéalisée de systèmes qui, vis-à-vis de leur environnement, doivent réagir de manière réflexe. En pratique, la plupart des systèmes réactifs sont implémentés par des systèmes interactifs suffisamment rapides pour prendre en compte tous les stimuli et y répondre à temps.!"#! e1 r1 e2 r2 e3 r3 t 1 t 2 t 3 t FIG. 4.3 Exécution d un système de type réactif. En pratique, rares sont les applications purement réactives : un grand nombre d applications sont constituées d un cœur réactif et de traitements transformationnels s exé-

65 4.2. APPROCHE SYNCHRONE POUR LES SYSTÈMES RÉACTIFS 65 cutant en parallèle. Le distributeur automatique de billets décrit dans [33] est un exemple représentatif de système composé de parties réactives, interactives et transformationnelles Systèmes réactifs temps-réel Les systèmes réactifs sont en particulier utilisés dans le cadre des systèmes tempsréel. Le terme temps-réel (real-time) est souvent utilisé sous sa forme galvaudée pour qualifier une application «qui réagit rapidement aux événements», c est-à-dire une application interactive avec un temps de réponse acceptable pour l utilisateur. Il est aussi utilisé dans le cadre de simulations ou d animations calculées pendant leur visualisation, c est-à-dire là encore pour des applications interactives à faible temps de réponse. Dans un véritable système temps-réel, les temps de réponse ne constituent pas seulement des mesures de performance, mais sont des contraintes fortes 1 : le système doit réagir aux événements dans des délais prédéfinis. Il fonctionne correctement s il fournit le résultat attendu et si ce résultat arrive «dans les temps» : un bon résultat produit trop tard est considéré comme inutile. Généralement, un système temps-réel possède par ailleurs deux caractéristiques fondamentales, en particulier s il joue un rôle critique c est-à-dire s il met en jeu des vies humaines (safety critical) ou si la réussite de sa mission est primordiale (mission critical) : la prévisibilité : il faut pouvoir prévoir le comportement du système, qui doit donc être parfaitement déterministe. Un système est dit déterministe s il produit toujours exactement la même séquence de résultats à partir d une même séquence de données ou d événements ; la sûreté de fonctionnement : le comportement du système doit pouvoir être garanti même dans des conditions extrêmes (fortes variations de température, vibrations, etc.), qui augmentent les risques de panne des composants. Les systèmes temps-réel dits embarqués, réactifs ou non, sont utilisés en particulier dans des véhicules, par exemple pour le pilotage automatique d avions : la prévisibilité et la sûreté de fonctionnement sont alors évidemment des priorités. Les systèmes réactifs se doivent d être déterministes et sûrs lorsqu ils sont utilisés pour des applications temps-réel critiques Approches traditionnelles Avant que le modèle synchrone soit proposé, les approches les plus couramment rencontrées pour implémenter des systèmes réactifs étaient les automates, les langages de haut-niveau associés à des exécutifs temps-réel multi-tâches et les langages parallèles asynchrones. Programmer un système directement sous la forme d un automate permet d obtenir un comportement déterministe et, en général, une exécution efficace ; de plus, de nombreux outils permettent de vérifier formellement le comportement de l automate. Comme nous l avons déjà signalé, les automates sont hélas difficiles à maintenir (cf. section 3.3.7, page 57). Cette maintenabilité est cependant améliorée par 1 Des contraintes temporelles strictes sont appliquées aux systèmes temps-réel dits «durs» (hard realtime) ; il s agit typiquement d un temps maximal entre l occurrence d un événement et la réponse du système. Ces contraintes sont assouplies pour les systèmes à contraintes temporelles relatives (soft real-time), qui doivent respecter des temps de réponse moyens.

66 66 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES les formalismes étendus de description d automates comme HPTS (cf. section du chapitre 3), qui intègrent le parallélisme et la hiérarchisation ; les automates ainsi décrits sont généralement traduits en automates séquentiels. Le système peut aussi être conçu comme un ensemble de tâches séquentielles coopérantes 2, qui communiquent de façon asynchrone. Dans le modèle de communication asynchrone, l appelant peut continuer de s exécuter après avoir envoyé une requête, en attendant que celle-ci soit traitée par l appelé. Bien qu efficace à l exécution, une solution à base de tâches séquentielles souffre de l asynchronisme entre les tâches, qui rend délicates l analyse et la mise au point d un comportement global déterministe. De plus, les inversions de priorités dûes au modèle coopératif favorise de manquement des échéances. Dans un langage comme ADA, le parallélisme et la synchronisation sont exprimées à l aide de primitives spécifiques (tâches et rendez-vous). Un tel langage est assurément un progrès en ce qui concerne le confort de programmation, mais le problème fondamental de l asynchronisme subsiste. Dans le cas des tâches coopérantes ou d un langage comme ADA, il est nécessaire de disposer d un exécutif multi-tâches, qui fournit les services nécessaires au parallélisme, à la communication et à la synchronisation entre les tâches. Cet exécutif peut par ailleurs lui-même utiliser les services d un système d exploitation temps-réel comme CHORUS ou ECOS. Le développement d une application temps-réel réactive doit être un processus rigoureux, nécessitant des outils adaptés, en particulier des langages pour la spécification et des outils fiables pour la vérification automatique. Selon H. Boufaïed [33], les solutions traditionnelles n apportant pas de solution satisfaisante à la programmation de systèmes réactifs temps-réel, il a été proposé de développer des langages dédiés plutôt que d adapter des langages existants. Cela devait permettre de prendre directement en compte les spécificités de ces systèmes à un haut niveau d abstraction, en particulier le déterminisme et le contrôle fin des processus réactifs, malgré la complexité des comportements décrits. Le modèle synchrone a alors été introduit et de nombreux langages sont maintenant basés sur cette approche Approche réactive synchrone L hypothèse synchrone définit une échelle de temps logique discret, constituée d instants correspondant à chacune des réactions du système. Les événements ayant déclenché la réaction sont considérés comme simultanés. De plus, les réactions se font en temps nul : les signaux émis pendant une réaction sont donc simultanés avec les signaux qui ont provoqué la réaction (la production de la réponse a lieu au même instant logique). Une réaction est donc par construction instantanée, ce qui évite les réactions concurrentes partielles d un système, sources d indéterminisme. La figure 4.4 illustre cette propriété : plusieurs événements sont pris en compte à chaque réaction, pour produire instantanément des résultats. Les hypothèses synchrones conduisent à une vision abstraite des interactions et permettent de simplifier l expression des comportements réactifs. Les fondements théoriques des langages synchrones garantissent par ailleurs des propriétés remarquables 2 Dans le modèle d ordonnancement coopératif, la tâche en cours d exécution peut choisir de donner la main à une autre tâche, quelle que soit sa priorité. Il s oppose au modèle préemptif, dans lequel une tâche plus prioritaire peut prendre la main sans tenir compte des besoins de la tâche courante.

67 4.2. APPROCHE SYNCHRONE POUR LES SYSTÈMES RÉACTIFS 67 I1 I2 I1 I t (instants) O1 O2 O1 O2 FIG. 4.4 Un exemple d exécution d un système synchrone. aux constructions de haut-niveau 3. La composition parallèle d ESTEREL est par exemple parfaitement déterministe, alors que la concurrence dans les langages asynchrones introduit généralement de l indéterminisme. Les compilateurs s appuient sur la sémantique des langages synchrones pour produire du code déterministe et efficace à l exécution, et pour vérifier certaines propriétés en détectant par exemple les situations d interblocage. Ces sémantiques mathématiques rigoureuses ont par ailleurs permis de construire des outils automatiques de vérification formelle, permettant de tester les programmes avant de les exécuter. De plus, les réactions se font en temps nul, ce qui signifie simplement que toute réaction commencée doit terminer avant qu une autre réaction soit déclenchée. La principale conséquence de ces hypothèses est la possibilité de composer des systèmes synchrones pour obtenir d autres systèmes synchrones, le comportement résultant étant parfaitement défini et déterministe. Nous verrons plus tard que cette hypothèse est tout à fait acceptable au niveau du modèle, mais qu elle pose des problèmes lors de l implémentation (cf. section 4.4, page 81) Langages et outils L hypothèse synchrone est à la base de plusieurs langages, tels que LUSTRE [77], ESTEREL [24, 23] et SIGNAL [37]. Les formalismes SYNCCHARTS [12] et HPTS (cf. section 3.3.8, page 58) constituent des outils expressifs pour la spécification explicite d automates selon le modèle synchrone. SYNCCHARTS repose sur une sémantique proche de celle d ESTEREL. SIGNALGTI est une extension de SIGNAL intégrant en particulier la préemption hiérarchique de tâches 4 ; il a été utilisé par S. Donikian pour implémenter les HPTS. Des langages synchrones comme LUSTRE ou SIGNAL, ainsi que le modèle HPTS, sont bien adaptés aux applications réactives manipulant essentiellement des flots de données (signaux continus) sous la forme de systèmes d équations. ESTEREL et le formalisme SYNCCHARTS sont pour leur part utilisés pour des applications réactives pour lesquelles le contrôle joue un rôle primordial, c est-à-dire qui doivent principalement réagir à des événements (signaux discrets). Nous nous intéressons à ce dernier type de langages synchrones et plus particulièrement à ESTEREL, qui est un langage de nature impérative adapté à la programmation événementielle. Basé sur les états et les transitions, le formalisme SYNCCHARTS intègre les caractéristiques principales d ESTEREL : la hiérarchie par l imbrication de macro-états, la 3 voir à ce propos l article de G. Berry sur les fondements d ESTEREL [22] 4 GTI signifie Gestion de Tâches et intervalles.

68 68 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES concurrence par la description de graphes d états indépendants dans le même macroétat, la communication par diffusion instantanée de signaux, ainsi que la préemption (avortement et suspension). Un SYNCCHART peut donc être traduit automatiquement en un programme ESTEREL. Un éditeur graphique de SYNCCHART a été développé par C. André, complétant ainsi l atelier de conception de systèmes réactifs dédié à ES- TEREL constitué d un compilateur et d outils de validation formelle [12]. 4.3 Le langage ESTEREL ESTEREL est un langage réactif synchrone de nature impérative, basé d une part sur des structures de contrôle comme l itération, la séquence et la composition parallèle déterministe, et d autre part sur un ensemble d instructions dites réactives faisant référence aux événements auxquels le système décrit doit réagir. La communication et la synchronisation entre les différentes composantes d un programme ESTEREL se fait par diffusion instantanée de signaux correspondant à ces événements. Le langage offre par ailleurs des facilités de manipulation de données, de programmation modulaire et de gestion de tâches asynchrones, ainsi que des mécanismes de gestion d exceptions et de préemption. Une présentation complète du langage est disponible dans [23] ; nous présenterons ici les notions et instructions caractéristiques d ESTEREL, qui nous permettront d introduire ensuite le langage MARVIN (cf. chapitre 8) Principes du langage Un signal est caractérisé par son statut, c est-à-dire par sa présence ou son absence au cours d un instant. Il peut être émis par l environnement si c est un signal en entrée, ou par le programme ESTEREL avec l instruction emit si c est un signal en sortie. Les signaux sont diffusés instantanément et sont visibles dans toutes les composantes parallèles du programme : un signal émis par une composante est reçu par toutes les autres composantes dans le même instant. Une instruction débute à un instant, appelé le «premier instant» pour cette instruction ; l instruction peut rester active pendant plusieurs instants avant de se terminer à un instant tel que. Une instruction est dite instantanée si. Une instruction se termine soit spontanément, soit suite à un avortement ; seule la boucle infinie ne se termine jamais spontanément. Nous considérons un temps logique découpé en instants successifs, donc si par exemple, l instant suit immédiatement l instant. Une instruction non-instantanée (qui «prend du temps») permet de suspendre l exécution d une composition et de la reprendre à un instant ultérieur, c est-à-dire de garder active une composition sur plusieurs instants. Cette suspension correspond soit à une pause jusqu à l instant suivant (instruction pause), soit à l attente d un signal donné. L instruction réactive await permet par exemple d attendre l arrivée d un signal, en «gelant» le fil d exécution (thread) dans lequel elle se trouve jusqu à la prochaine occurrence du signal. Voici un premier exemple de composition en ESTEREL, qui attend l arrivée des signaux I1 et I2 pour émettre le signal O (les instants grisés correspondent à la terminaison de la composition) :

69 4.3. LE LANGAGE ESTEREL 69 I1 I2 I1 I2 I2 I1 [ await I1 await I2 ] ; emit O 1 2 t t O O O t Cas 1 Cas 2 Cas 3 FIG. 4.5 Attente concurrente et émission de signaux. L opérateur de composition parallèle ( ) exprime une concurrence explicite déterministe entre deux threads d exécution : il sépare le fil d exécution courant en deux fils lancés instantanément et s exécutant en parallèle. Cette instruction se termine à l instant où les deux composantes concurrentes sont terminées, qu elles se terminent toutes les deux au même instant ou successivement. Comme le montrent les trois exemples de scénario, la composition parallèle se termine à l instant où les deux signaux I1 et I2 ont été reçus, mais il n est pas obligatoire que les deux signaux soient reçus simultanément. La séquence (indiquée par l opérateur ;) et l émission de signal sont des instructions instantanées, donc dans l instant où l instruction parallèle se termine, le signal O est émis et la séquence se termine. Nous remarquerons que les délimiteurs de bloc [ et ] sont nécessaires ici car la séquence est prioritaire sur la composition parallèle. Sans ces crochets, le bloc correspondrait à la composition suivante : I1 I2 I1 I2 I2 I1 await I1 [ await I2 ; emit O ] 1 2 t t O O O t Cas 1 Cas 2 Cas 3 FIG. 4.6 De l importance des délimiteurs de blocs. Le troisième scénario diffère considérablement de celui de la composition précédente, car le signal O est émis quand le signal I2 est présent, indépendamment du signal I Modules Un programme ESTEREL se présente sous la forme d un module, qui peut être récursivement composé de sous-modules. La communication entre un module et son environnement est réalisée par des signaux. Un module est constitué d une interface et d un corps. L interface décrit notamment les signaux d entrée et de sortie du module, c est-à-dire respectivement les signaux auxquels il doit réagir et les signaux qu il peut émettre en réponse. Le corps définit le comportement du module, sous la forme d une composition d instructions réactives ou impératives. Lorsqu il est activé, un module exécute son corps de façon à réagir instantanément à la présence et à l absence de signaux en entrée et en sortie. Cette exécution aura pour conséquence l émission de signaux en sortie et/ou la modification de l état interne du

70 70 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES module. La figure 4.7 représente un module ESTEREL sous la forme d une boîte noire possédant une interface constituée d entrées et de sorties pour la réception et l émission de signaux, et d une entrée particulière correspondant au déclenchement d une réaction. Cette dernière entrée sera par la suite considérée comme implicite. M I 1 O I n O p activation FIG. 4.7 Représentation de l interface d un module ESTEREL. Voici un exemple de module ESTEREL, qui émet le signal O1 quand le signal I est présent et le signal O2 sinon, puis attend l instant suivant. Le test de présence du signal I se fait grâce à l alternative réactive. L instruction pause ne fait rien et se termine à l instant suivant : module M : % Interface input I ; output O1, O2 ; I 1 2 I 3 4 t % Corps loop present I then emit O1 else emit O2 end present ; pause end loop end module O1 O2 O2 O1 FIG. 4.8 Premier module et premières instructions réactives. L instruction pause est indispensable pour éviter que la boucle infinie s exécute instantanément, c est-à-dire qu elle s exécute un nombre «infini» de fois au cours du même instant sans rendre la main. Le compilateur ESTEREL doit détecter une telle boucle instantanée et refuser le programme. L interface d un module permet également de déclarer les types, constantes, fonctions et procédures externes utilisés dans le corps du module. La définition d une donnée déclarée dans l interface doit être fournie en externe, lors d une instanciation par un autre module ESTEREL (cf. section 4.3.8) ou dans le langage cible (cf. section 4.4). La section présente plus en détail la manipulation des objets déclarés dans l interface d un module.

71 4.3. LE LANGAGE ESTEREL Signaux Un signal pur est un simple indicateur d événement, tandis qu un signal valué transmet de plus une information typée. Le signal tick est un signal pur prédéfini, toujours présent, qui correspond à l horloge d activation. Les deux boucles suivantes sont donc équivalentes 5 : loop emit O each tick loop emit O ; pause end loop Un signal est caractérisé par son statut, c est-à-dire par sa présence ou son absence au cours d un instant ; le signal est indéterminé jusqu à ce que son statut soit connu. Un signal en entrée est présent s il a été fourni par l environnement au début de l instant. Un signal en sortie est considéré comme absent au début d un instant et devient présent dès qu une émission explicite est réalisée (emit). La diffusion instantanée des signaux implique le partage du statut et de la valeur éventuelle de chaque signal à un instant donné entre toutes les composantes d un programme. Ce type de communication peut rendre la compréhension de certains programmes difficile, car la présence d un signal en sortie peut être testée même si le signal vient d être émis par le programme dans le même instant. Dans l exemple suivant, le signal O sera émis à chaque instant, car le signal S est émis à chaque activation du corps : loop present S then emit O end present emit S each tick En ESTEREL, le temps est parfois qualifié de «multiforme», car il est caractérisé par des signaux qui ne représentent que rarement le temps physique (par exemple des secondes). L utilisateur peut considérer que chaque signal définit sa propre unité de temps, la durée de chaque pas de temps pour ce signal pouvant de plus être variable puisque le signal peut être reçu de façon irrégulière. Expressions de signaux Il est possible d utiliser les opérateurs booléens not, and et or dans une expression testant la présence de signaux. L exemple suivant émet le signal O1 si les signaux I1 et I2 sont présents simultanément ou si le signal I3 est absent : present [I1 and I2] or [not I3] then emit O1 end present Les deux expressions suivantes, utilisant les deux formes abrégées de l instruction present, sont donc équivalentes : 5 La signification exacte de la construction loop each S est expliquée dans la section Considérons pour le moment qu elle correspond à une boucle qui exécute son corps à chaque réception du signal S, donc dans notre exemple à chaque instant.

72 72 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES present I else emit O end present present not I then emit O end present Il est aussi possible d indiquer qu il faut prendre en compte plusieurs réceptions du même signal. Voici un exemple, qui attend trois occurrences du signal I avant de se terminer : await 3 I Les expressions de signaux peuvent être utilisées dans les instructions de préemptions, que nous aborderons en section Prise en compte immédiate d un signal La plupart des instructions réactives sont «retardées», ce qui signifie que la condition de présence d un signal n est valable qu à partir de l instant suivant (retard d un instant) : dans le cas de l instruction await par exemple, si le signal est présent dans l instant où cette instruction est atteinte, cela n aura pas d effet. Le mot-clé immediate indique que l occurrence attendue peut appartenir à l instant courant, c està-dire qu un signal doit être pris en compte dès le premier instant d exécution d une instruction. La séquence suivante se termine donc instantanément : emit S ; await immediate S Manipulation de données Un module ESTEREL peut manipuler des valeurs de type quelconque, à condition que ce type soit prédéfini 6 ou qu il soit déclaré dans la partie interface du module. Les valeurs manipulées correspondent à des variables, à des constantes ou à l information transmise par un signal valué (cf. section 4.3.5). L alternative classique peut être utilisée pour tester ces valeurs et exécuter des sous-blocs en conséquence. Il est possible de manipuler des variables locales typées : la déclaration d une variable définit un bloc à l intérieur duquel la variable peut être utilisée, éventuellement avec une valeur initiale. L affectation d une variable se fait en utilisant l opérateur :=. Il n y a pas de notion de variable globale au module, contrairement aux constantes, qui sont définies dans l interface du module et dont la valeur est externe. L exemple suivant illustre la manipulation d une constante et de deux variables entières. Le signal Equal est émis lorsque les deux variables ont la même valeur : module M : output Equal ; constant C : integer ; 6 Les types prédéfinis disponibles sont les suivants : integer, float, double, boolean, string.

73 4.3. LE LANGAGE ESTEREL 73 var X := 0 : integer, Y : integer in Y := C ; loop if (X = Y) then emit Equal ; X := 0 ; Y := C else X := X + 1 end if each tick end var end module Dans le cas de composantes concurrentes, deux cas de figure seulement sont autorisés, les autres devant être refusés par le compilateur : la variable est utilisée en lecture seule dans les différents threads ; la variable est modifiée dans l un des threads, mais elle n est ni lue ni modifiée dans les autres. Ces limitations garantissent à la composition parallèle la propriété remarquable de conserver le déterminisme du système décrit. L exemple suivant est donc invalide, cette composition n ayant pas de sens dans un cadre déterministe : X := X + 1 X := 1 Il est possible d utiliser des fonctions et des procédures externes (par exemple pour manipuler des données de type externe), à condition qu elles aient été déclarées dans l interface du module et que leur instantanéité soit garantie. Une fonction est déclarée en précisant le type de ses paramètres et de sa valeur de retour. Pour déclarer une procédure, il faut d abord donner le type des paramètres en entrée-sortie (modifiables), puis le type des paramètres en entrée ; l appel de procédure se fait en utilisant l instruction call. L exemple suivant présente l utilisation d une constante de type externe T par une fonction et une procédure externes, ainsi que la manipulation de deux variables de type T : module M : input I ; type T ; procedure Increment (T) (int) ; function Init () : T ; function Test (T) : boolean ; var X := Init () : T in loop if (Test(X)) then call Increment (X) (1) end if each I end var end module

74 74 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES Signaux valués et capteurs Un signal valué est déclaré comme porteur d une donnée typée. Il est possible d initialiser la valeur d un signal lors de sa déclaration, en utilisant l opérateur :=. La valeur d un signal est toujours accessible en utilisant l opérateur?, même si le signal est absent. En fait, les instants de présence d un signal valué correspondent aux instants d affectation de la valeur du signal : si le signal S est absent,?s renvoie donc la valeur précédente de S. L exemple suivant, tiré de [76], est une bonne illustration de ce phénomène ; le module Observateur émet à chaque instant un signal O transportant la valeur courante du signal I : module Observateur : input I := 0 : integer ; output O : integer ; 1 I (3) 2 3 I (1) 4 t loop emit O (?I) each tick end module O (0) O (3) O (3) O (1) FIG. 4.9 Manipulation des valeurs de signaux. Il est cependant impossible d utiliser la valeur d un signal pour calculer une nouvelle valeur pour ce même signal. L exemple suivant est invalide : emit S (?S + 1) Il ne s agit en effet pas d une simple affectation prenant effet après la consultation de la valeur courante. Contrairement à une variable, un signal ne peut pas prendre plusieurs valeurs dans le même instant car, lors de l émission, la valeur du signal pour l instant courant est immédiatement modifiée et diffusée : il est évidemment impossible de satisfaire la relation. Un tel cycle de causalité doit être détecté à la compilation, et le programme doit être refusé. Un signal valué ne peut donc a priori pas être émis plusieurs fois dans le même instant, en particulier dans des composantes concurrentes 7. En utilisant le mot-clé combine lors de la déclaration d un signal valué en sortie, il est possible de définir une méthode de combinaison, qui sera utilisée dans le cas d une émission multiple de ce signal. L exemple suivant, composé de deux threads, émet à chaque pas de réaction un signal O et incrémente une variable X. Dans tous les cas, O est émis avec la valeur courante de X. Il est émis simultanément avec la valeur 10 lorsque le signal I est présent ; grâce à la méthode de combinaison +, la valeur du signal O sera dans ce cas augmentée de 10 : 7 L émission multiple d un signal pur ne pose pas de problème car le statut du signal n est pas modifié.

75 4.3. LE LANGAGE ESTEREL 75 module M : input I ; output O : combine integer with + ; var X := 0 : integer in loop emit O (X) ; X := X + 1 present I then emit O (10) end present each tick end var end module 1 O (0) 2 O (1) I 3 O (12) 4 O (3) t FIG Combinaison de signaux de sortie. Pour le type prédéfini boolean, la combinaison peut se faire avec les opérateurs and et or. Pour les types numériques prédéfinis, les opérateurs + et * sont utilisables. Dans le cas de types externes, c est à l utilisateur de fournir les fonctions externes appropriées, qui doivent être commutatives et associatives. Un capteur est un signal valué dégénéré, qui ne possède pas de statut de présence. Il s agit en pratique d une variable externe en lecture seule, dont la valeur peut être récupérée avec l opérateur?. L événement associé à un capteur n a pas de sens : tout se passe comme si ce signal était toujours présent. Les capteurs permettent d acquérir des informations non événementielles en provenance de l environnement, par exemple la valeur courante d un thermomètre. Il est donc inutile d initialiser la valeur d un capteur. L exemple suivant réagit au signal I en émettant le signal Fahrenheit transportant la traduction en degrés Fahrenheit de la valeur du capteur de température Celsius : module Thermometre : input I ; output Fahrenheit : float ; sensor Celsius : float ; function c2f (float) : float ; loop emit Fahrenheit (c2f(?celsius)) ; each I end module Préemption Un mécanisme de préemption permet d interrompre un traitement en présence d événements particuliers, en l avortant ou en le suspendant. Les instructions de préemption d ESTEREL permettent d exprimer de façon concise des comportements sophistiqués ; les opérations disponibles sont la suspension, l avortement fort et l avortement faible. Ces constructions, en particulier l avortement, sont souvent utilisées pour représenter des compositions qui doivent s exécuter dans un délai précis, écoulé lorsque

76 76 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES le signal de préemption est reçu. Le mécanisme d exceptions, détaillé dans la section suivante (4.3.7), permet lui aussi une forme de préemption. Une activité suspendue peut reprendre au point où elle a été préemptée dès que les conditions de suspension ont disparu. L instruction suspend est retardée, le bloc encapsulé sera donc exécuté au moins une fois, au cours du premier instant : suspend loop emit O each tick when S S 1 O S 2 S 3 4 O t FIG Suspension sur réception de signal. L instruction d avortement abort permet l abandon d un bloc dès réception d un signal donné. C est aussi une instruction retardée, donc le signal d avortement ne sera pas pris en compte lors du premier instant. Si le corps se termine naturellement avant la première occurrence du signal d avortement, l ensemble se termine instantanément. Sinon : dans le cas de l avortement fort (abort), l ensemble se termine à l instant de la réception du signal, sans transmettre le contrôle au corps ; dans le cas d un avortement faible (weak abort), le corps s exécute une dernière fois puis est avorté. Les deux exemples suivants illustrent l utilisation des instructions d avortement fort et faible. Les scénarios montrent la différence entre les deux types d avortement : abort loop emit O each tick when A ; emit Aborted A A O O Aborted t FIG Avortement fort sur réception de signal. weak abort loop emit O each tick when A ; emit Aborted A A t O O O Aborted FIG Avortement faible sur réception de signal. En ajoutant le mot-clé immediate aux instructions d avortement fort et faible, nous obtenons deux nouvelles constructions permettant de prendre en compte dès le

77 4.3. LE LANGAGE ESTEREL 77 premier instant le signal d avortement. En imbriquant des instructions de préemption, il est possible de définir des hiérarchies de priorités, l instruction englobante étant prioritaire. Il est aussi possible d ajouter une clause de traitement du cas où le signal d avortement a été reçu. Il existe par ailleurs deux formes de boucles étendues qui utilisent l avortement de façon masquée. L instruction loop each S a le comportement suivant : si termine, il faut attendre le signal S pour le relancer. Cela correspond au comportement intuitif que nous avions donné en section ; si le signal S est reçu avant que ne se termine, alors est avorté et relancé instantanément. La boucle every a presque le même comportement, mais elle attend une première occurrence du signal S pour lancer son corps Exceptions Le mécanisme d exceptions d ESTEREL permet de s échapper d un bloc d instructions en précisant le motif de sortie ; une exception levée dans un bloc peut être rattrapée si un traitement spécifique est nécessaire. L instruction trap définit une exception qui peut être levée dans son corps : si ce corps se termine, naturellement ou en levant l exception (instruction exit), l ensemble se termine instantanément. Dans l exemple suivant, le corps du bloc trap lève l exception T lorsque le signal I est présent, et émet le signal O sinon. Le bloc trap se termine ici seulement si l exception est levée, et le signal E est alors émis instantanément : trap T in loop present I then exit T end present ; emit O each tick end trap ; emit E I 1 t O E Cas 1 1 O I 2 3 O O E Cas 2 t FIG Levée d exception. La levée d une exception correspond à un avortement faible : si le corps du bloc trap contient des branches parallèles, dont l une a levé l exception, les autres s exécutent quand même une dernière fois. La branche ayant levé l exception se termine bien sûr immédiatement. Si un traitement est prévu pour l exception, il s exécutera après que les branches concurrentes se soient terminées, dans le même instant. Le mot-clé handle permet de spécifier un traitement à effectuer lorsqu une exception est levée. Il est aussi possible d utiliser des exceptions valuées, dont la valeur de retour peut être récupérée avec l opérateur??. Si plusieurs blocs trap sont imbriqués, le bloc trap englobant, qui lève une exception simultanément aux blocs encapsulés, est prioritaire (comme pour la préemption).

78 78 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES Composition de modules Un module ESTEREL peut instancier d autres modules en utilisant l instruction run et en spécifiant au besoin les correspondances (ou substitutions) entre les signaux. L exemple suivant montre comment créer, dans un module P, deux instances M1 et M2 d un module M, et comment faire correspondre les signaux I1 et I2 de P aux signaux I de M1 et M2. Il est inutile de préciser la substitution de deux signaux portant le même nom ; le signal O de P correspondra donc au signal O de M1 et de M2 : module M : input I ; output O ; % Corps... end module module P : input I1, I2 ; output O ; P I1 I2 M1 I M2 I O run M1/M [ signal I1/I ] run M2/M [ signal I2/I ] end module O O FIG Exemple de composition de modules avec substitution de signaux. Nous pouvons alors considérer une hiérarchie entre les modules : un module qui en instancie un autre peut être appelé module-père et un module instancié est un modulefils. L instanciation d un module correspond à la recopie exacte du corps de ce module, et à l ajout des déclarations de son interface à celles de l interface du module-père. La substitution ne se limite pas à la correspondance entre signaux : elle s applique à tout ce qui peut être déclaré dans une interface de module, c est-à-dire aux types, aux constantes, aux fonctions et aux procédures. Cela permet en particulier de définir des modules génériques, paramétrés lors de l instanciation. Les signaux locaux permettent la communication entre modules exécutés au sein d un même module englobant. Plusieurs signaux locaux peuvent être définis dans le même bloc ; il est également possible de déclarer à cet endroit une fonction de combinaison de signaux (cf. section 4.3.5). Dans l exemple suivant, le module Q instancie le module M en M1 et M2, et crée un signal local L permettant de faire correspondre le signal de sortie O de M1 et le signal d entrée I de M2 :

79 4.3. LE LANGAGE ESTEREL 79 module M : input I ; output O ; % Corps... end module module Q : input I ; output O ; signal L in run M1/M [ signal L/O ] run M2/M [ signal L/I ] end signal end module I Q I M1 O L I M2 O O FIG Exemple de composition de modules utilisant un signal local. La diffusion instantanée de signaux entre modules peut être bidirectionnelle, à condition qu elle n introduise pas de cycle de causalité. Cette propriété impose une limitation importante car les cycles sont détectés uniquement à la compilation : la création et la destruction dynamiques de modules sont impossibles. L architecture d un système réactif décrit en ESTEREL ne peut donc pas évoluer au cours de son exécution Tâches asynchrones Tous les traitements qui ont lieu au cours d une réaction d un programme ESTE- REL sont considérés comme instantanés, en particulier les appels de fonctions et de procédures externes. Il est cependant parfois nécessaire de faire appel à des traitements dont la durée ne peut pas être négligée, en particulier lorsqu il s agit de traitements transformationnels dont il faut attendre le résultat. Une tâche asynchrone permet de lancer, parallèlement à un programme ESTEREL, une opération dont la durée dépasse les bornes fixées pour garantir la réactivité du système, comme un calcul long ou le déplacement d un bras de robot. Une tâche est lancée avec l instruction exec, puis gérée de façon logique avec les instructions que nous avons introduites précédemment, en particulier à l aide les instructions de préemption. Les informations utiles pour manipuler une tâche sont ses instants de début et de fin (spontanée ou suite à un avortement). Il faut que le programme se synchronise avec l environnement, chargé d exécuter effectivement la tâche : il faut demander à l environnement de lancer la tâche, puis attendre qu elle se termine et éventuellement récupérer son résultat. Il faut également prévenir l environnement qu une tâche doit être suspendue ou avortée. La déclaration et le lancement d une tâche sont syntaxiquement similaires à la déclaration et à l appel d une procédure. Le thread qui lance la tâche est bloqué en attente de la terminaison de cette tâche. S il y a d autres threads, ils s exécutent en parallèle de la tâche ; le programme n est alors pas suspendu en attendant la fin de la tâche. Quand la tâche est terminée, les références passées en paramètres à la tâche sont mis à jour instantanément et l instruction exec se termine. Les signaux spécifiques aux événements de fin de tâche sont déclarés

80 80 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES à l aide du mot-clé return. Le signal de retour ne peut pas être émis par le programme lui-même, il est émis par l environnement à l instant où la tâche se termine ; ce signal pourra alors être testé afin de savoir si la tâche s est terminée spontanément dans l instant courant ou si elle a été avortée. L exemple suivant décrit une tâche chargée de calculer une trajectoire à partir de coordonnées : module M : type Coordinates, Trajectory ; input Current : Coordinates ; output NewTrajectory : Trajectory ; return R ; task ComputeTrajectory (Trajectory) (Coordinates) ; var T : Trajectory in [ loop await Current ; exec ComputeTrajectory (T) (?Current) return R ; emit NewTrajectory (T) end loop ] % Corps à exécuter en parallèle end var end module Une tâche peut être préemptée, c est-à-dire avortée ou suspendue. Dans l exemple suivant, la tâche est avortée et instantanément relancée lorsque le signal I est reçu, ce qui signifie que l environnement est prévenu qu il doit avorter et relancer cette tâche : loop exec T (X) () return R each I Les tâches asynchrones sont entre autres utilisées pour implémenter un mécanisme de rendez-vous entre modules réactifs, dans le cadre des CRP (Communicating Reactive Processes) : l envoi de messages (bloquant ou non) et la réception (rendez-vous) sont réalisés par des tâches spécifiques [25] Compilation d un programme ESTEREL Le compilateur ESTEREL produit entre autres un fichier C, représentant un automate à états finis ou un circuit booléen. Ce fichier contient en particulier une fonction d activation et une fonction de positionnement pour chaque signal d entrée. L utilisateur doit fournir une fonction de positionnement pour chaque signal de sortie, dans un fichier C séparé. L exécution d une réaction est obtenue en appelant d abord la fonction de positionnement de chaque signal d entrée présent, puis la fonction d activation. L émission d un signal en sortie provoque l appel de la fonction correspondante, définie par l utilisateur. L exemple de la figure 4.17, inspiré d un exemple de [76], montre la correspondance entre un module ESTEREL (fichier M.strl) et les interfaces des fonctions C utilisées, présentes dans les fichiers M.c (généré par le compilateur) et M_outputs.c (fourni par l utilisateur) :

81 4.4. MACHINE D EXÉCUTION 81 M.strl module M : input In : integer ; output Out ; % Corps M.c /* Fonction d activation */ void M (void) /* Signaux d entrée */ void M_I_In (int); M_outputs.c /* Signaux de sortie */ void M_O_Out (void); FIG Exemple de correspondance ESTEREL/C. 4.4 Machine d exécution L approche synchrone facilite considérablement la spécification de systèmes réactifs, mais un système décrit dans un langage synchrone comme ESTEREL n est pas directement exécutable. En particulier, la notion idéale de réaction s exécutant en temps nul n est évidemment pas réalisable car il n existe pas de machine infiniment rapide. Nous nous intéressons plus particulièrement aux caractéristiques propres à ESTEREL, il faut donc de plus pouvoir traduire, pour le module synchrone, les événements asynchrones en provenance du monde réel en signaux logiques pour lesquels la notion de simultanéité a un sens. La mise en œuvre d un système synchrone nécessite l utilisation de mécanismes d interfaçage entre ce système et son environnement; ces mécanismes sont regroupés dans ce qui est communément appelé une machine d exécution. Une machine d exécution pour ESTEREL est donc chargée de réaliser une approximation acceptable de l hypothèse synchrone, de faire la correspondance entre les événements externes et les signaux du module définissant le système synchrone, et de déclencher les réactions de ce module. Elle permet également de gérer les tâches asynchrones. La figure 4.18 schématise le fonctionnement d une machine d exécution pour module ES- TEREL. Environnement asynchrone Module synchrone Signaux Signaux en sortie FIG Principes d une machine d exécution pour ESTEREL. Le modèle synchrone définit des réactions de durée nulle, ce qui est en pratique irréalisable. Cette propriété est donc approximée en assurant l atomicité de chaque réaction. Il faut pour cela poser deux contraintes fortes sur les fréquences d activation du module et d arrivée des signaux : 1. l exécution de la réaction doit être complète, il ne faut donc pas activer à nouveau

82 82 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES le module s il est en cours de réaction ; 2. les signaux en entrée doivent être positionnés avant l activation du module et ne doivent pas être modifiés pendant la réaction. La perception que le module a de son environnement doit en effet être figée pendant toute la durée de la réaction. La machine d exécution peut déclencher la réaction d un module selon deux stratégies au choix : l activation se fait sur l arrivée de signaux. Cette stratégie «par interruption» est particulièrement adaptée aux systèmes à événements sporadiques, qui sont souvent «au repos» ; les réactions sont déclenchées régulièrement, indépendamment des occurrences de signaux. Cette stratégie d échantillonnage périodique s applique plutôt aux systèmes qui doivent réagir «de façon continue» à leur environnement. Pour que le système défini soit réactif vis-à-vis de son environnement, il faut garantir que l exécution des réactions sera assez rapide. La vérification de cette propriété se fait a posteriori, en exécutant le système. La machine d exécution et le système synchrone s exécutent en parallèle, car la machine d exécution doit prendre en compte les événements en provenance de l environnement asynchrone pendant que les modules synchrones exécutent un pas de réaction. La prise en compte des événements asynchrones est habituellement réalisée en les mémorisant jusqu au prochain instant, puis en les traduisant en signaux d entrée présents avant de déclencher la réaction suivante. Un module activé réagit ainsi à tous les événements observés depuis le début de la réaction précédente. Cette mémorisation, à la charge de la machine d exécution, garantit que les signaux d entrée ne seront pas modifiés pendant l exécution d une réaction 8. La machine d exécution sert par ailleurs d interface entre les modules et le langage cible implémentant les sous-programmes synchrones et les tâches asynchrones. En particulier, les modules ESTEREL n ont qu une vision logique des tâches asynchrones : leur implémentation est laissée au soin de l utilisateur. La machine d exécution permet d exécuter ces tâches et de les gérer, par exemple au moyen d un exécutif multi-tâches. La mise en œuvre effective d un système synchrone est souvent considérée comme un détail d implémentation, traité au cas par cas. Par exemple, une machine d exécution pour ESTEREL utilisant les services du système d exploitation multi-tâches tempsréel CHORUS a été développée par le CNET 9 pour décrire le comportement d objets multimédia et gérer la synchronisation de ces objets [81]. H. Boufaïed propose pour sa part une architecture générique de machine d exécution, indépendante de la cible d exécution [33]. Son modèle permet de définir différentes stratégies d acquisition et d émission de signaux, d enchaînement des phases de réaction et de traitement des anomalies observées. Il permet de décrire la plupart des mécanismes d exécution de processus synchrones et il intègre le traitement de tâches asynchrones. Les contrôleurs d entrée-sortie réalisent l interface entre le monde extérieur et le processus synchrone. 8 H. Boufaïed a montré que la mémorisation de l historique des événements permet en particulier de conserver une approximation satisfaisante malgré les réceptions multiples de signaux possibles dans le cas d un système temps-réel à contraintes temporelles relatives [33]. 9 Le CNET (Centre National d Études des Télécommunications) est maintenant appelé FT R&D (France Télécom, Recherche et Développement).

83 4.5. RÉSEAUX DE PROCESSUS RÉACTIFS Réseaux de processus réactifs Le modèle de réseaux de processus séquentiels a été défini afin d étendre la sémantique dénotationnelle. Selon F. Boussinot, cette solution est modulaire et élégante mais elle manque d expressivité ; il l a donc étendue en proposant le modèle de réseaux de processus réactifs. Ces deux modèles sont entre autres décrits en détail dans son ouvrage consacré à la programmation réactive [38]. Dans les deux cas, le comportement d un réseau de processus est parfaitement déterministe. Un processus séquentiel est un programme possédant une mémoire et des ports de communication. Il peut recevoir des messages sur ses ports d entrée et envoyer des messages par l intermédiaire de ses ports de sortie. Un réseau de processus séquentiels est formé en connectant les ports des processus par des canaux. Un canal est une file FIFO 10 de taille infinie. Un processus communique de façon asynchrone avec les autres processus tout au long de son exécution, en déposant des messages sur les canaux connectés à ses ports de sortie et en récupérant les messages dans les canaux connectés à ses entrées. Cette récupération est bloquante : un processus qui tente de prendre un message dans un canal vide est bloqué jusqu à ce qu un message soit déposé sur le canal, auquel cas il peut reprendre son exécution. L envoi et la réception de messages sont les seuls mécanismes de synchronisation disponibles ; il n y a en particulier aucun partage de variables globales. Un canal a au plus un processus producteur, capable de déposer des messages, et un processus consommateur, capable de récupérer ces messages. Les canaux sans producteurs constituent les entrées du réseau de processus et les canaux sans consommateurs correspondent aux sorties du réseau ; ces entrées et ces sorties permettent l interfaçage avec l environnement. La structure d un réseau peut être modifiée dynamiquement, au cours de l exécution des processus : le nombre de processus et de canaux peut évoluer, et les interconnexions peuvent être modifiées. Le déterminisme d un réseau de processus séquentiels est garanti si les hypothèses suivantes sont respectées : un processus ne peut pas tester si un canal est vide, afin que le comportement du réseau ne dépende pas des différentes vitesses d exécution des processus (ce qui le rendrait indéterministe) ; un processus ne peut pas tenter de récupérer un message sur plusieurs canaux à la fois. Ces deux contraintes limitent l expressivité du modèle. Il n est par exemple pas possible de gérer des canaux avec des priorités différentes, car il n est possible ni d attendre sur plusieurs canaux, ni de tester que les canaux les plus prioritaires contiennent effectivement des messages. En ajoutant la notion d instant au modèle précédent, il devient possible de tester si un canal est vide, sans pour autant perdre le déterminisme du réseau de processus. Grâce à l introduction de cette notion, le modèle de réseaux de processus réactifs est plus expressif tout en préservant le déterminisme. Tous les processus partagent la même notion d instant et sont exécutés à chaque instant. Un processus a fini de réagir lorsqu il se termine, lorsqu il est explicitement suspendu jusqu à l instant suivant ou lorsqu il est bloqué en attente d un message sur un canal vide. Un instant du réseau se termine lorsque tous les processus ont fini de réagir, c est-àdire quand le système s est stabilisé. Le problème des différentes vitesses d exécution des processus disparaît, puisque tous les processus s exécutent maintenant au même 10 FIFO : First In, First Out (premier entré, premier sorti).

84 84 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES rythme. Pour éviter les problèmes de cohérence vis-à-vis de la primitive de test d un canal vide, ce test est systématiquement différé au début de l instant suivant. Il est en effet plus simple de garantir qu un message n a pas été reçu pendant l instant courant si ce test est réalisé à la fin de l instant ; la réaction à l absence de message peut alors se faire au tout début de l instant suivant. La primitive de test d un canal vide fonctionne comme suit : si un message a été reçu, alors la primitive retourne «vrai» et termine dans l instant ; sinon, l exécution est bloquée jusqu à l instant suivant et la primitive retournera «faux» seulement à cet instant. 4.6 Objets synchrones et objets réactifs Les objets synchrones [34, 36, 35] et les objets réactifs [40, 38] sont des modèles très différents visant tous deux à concilier l approche synchrone et l approche objet. L intégration de modules synchrones dans un langage orienté-objets permet de faire coopérer des programmes synchrones et non-synchrones au sein d une même application, et de profiter à la fois de la rigueur du modèle synchrone et de la souplesse d un langage orienté-objets. En particulier, il devient possible de créer et de détruire dynamiquement des objets correspondant aux modules synchrones, alors que cette dynamicité manque cruellement aux langages synchrones classiques. En contrepartie, il n est pas possible d utiliser les outils de vérification formelle des langages synchrones pour valider statiquement le comportement global d un ensemble d objets synchrones ou réactifs. Les deux modèles décomposent les applications en zones réactives, dont les objets partagent la même notion d instant. Ces zones utilisent des mécanismes synchrones pour la communication interne et des mécanismes asynchrones pour communiquer entre elles, comme l illustre l exemple de la figure Zone réactive 1 Zone réactive 2 Communication synchrone Communication asynchrone Communication synchrone FIG Communication entre objets synchrones ou réactifs. Les objets synchrones, définis par F. Boulanger, sont des objets qui encapsulent des modules synchrones compilés ; ils sont explicitement interconnectés pour former des réseaux d objets synchrones, qui partagent la même notion d instant global. Les objets réactifs, définis par F. Boussinot, sont pour leur part constitués de méthodes

85 4.6. OBJETS SYNCHRONES ET OBJETS RÉACTIFS 85 réactives correspondant à des modules synchrones ; ces méthodes s exécutent en parallèle et leur comportement est décrit en REACTIVE-C, langage basé sur le langage C et développé par F. Boussinot [39, 38] ; les comportements des programmes sont définis en termes de réactions à des activations. REACTIVE-C est considéré comme un langage d assemblage permettant d implémenter des formalismes de plus haut niveau basés sur la même notion d instant. Nous nous intéressons plus particulièrement au modèle d objets synchrones, c est pourquoi nous décrirons plus succinctement le modèle d objets réactifs Objets synchrones Un objet synchrone est la traduction dans un langage à objets d un module synchrone. Son comportement est produit par le compilateur de langage synchrone à partir du code du module, pour être ensuite encapsulé dans un objet doté d une unique méthode d activation et d une méthode d accès pour chaque signal d entrée et de sortie. Les mécanismes de communication entre objets synchrones doivent respecter la sémantique synchrone. Le comportement d un réseau d objets synchrones interconnectés est identique à celui d un programme synchrone constitué des modules synchrones correspondants ; un tel réseau peut donc être considéré comme un système synchrone à interfacer avec l environnement asynchrone, lui-même composé des autres objets du langage. F. Boulanger propose de plus un ensemble d outils pour la définition d objets synchrones, en particulier le langage MDL permettant la composition de modules synchrones. Communication et séquencement synchrone Les signaux d entrée et de sortie sont des attributs de l objet synchrone. Tout signal d entrée possède une méthode de connexion prenant comme argument un signal de sortie ; cette méthode permet de déclarer explicitement des connexions point-à-point unidirectionnelles entre objets synchrones. Des mécanismes de vérification assurent qu un signal d entrée est bien connecté à un signal de sortie du même type. Les objets synchrones d un même réseau ont une notion d instant commune ; cela signifie que les valeurs des signaux échangés ne sont pas modifiées au cours d un instant. Avant de pouvoir utiliser les signaux de sortie d un objet synchrone, il faut que ces signaux aient été positionnés ; il faut donc que l objet en question ait réagi. Si le graphe de dépendances entre objets synchrones interconnectés est acyclique, il est possible de déterminer un ordre d activation des objets synchrones. Cette opération, appelée séquencement synchrone, est confiée à un ordonnanceur, qui doit ensuite faire réagir les objets synchrones dans l ordre choisi. Le graphe peut contenir des cycles à condition qu ils ne soient pas instantanés, c est-à-dire qu ils contiennent des «retards». Un retard est un objet particulier, qui conserve le signal reçu à l instant courant pour le délivrer à l instant suivant ; il possède un seul signal d entrée et un seul signal de sortie. Les dépendances entre objets synchrones peuvent être modifiées au cours d un instant, par l ajout, la destruction, la connexion et la déconnexion des objets. Les requêtes de modification de la topologie du graphe de dépendances sont mémorisées dans l instant courant, afin de reconstruire le graphe et déterminer un nouvel ordre d activation à la fin de la réaction. Une nouvelle connexion peut être refusée si elle engendre un cycle de dépendance.

86 86 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES Communication asynchrone La communication entre les objets synchrones et les autres objets du langage se fait au travers d une interface permettant de traduire les signaux synchrones en événements asynchrones et vice-versa. Les objets constituant cette interface, appelés objets d interface, peuvent servir d échantillonneurs ou peuvent déclencher une réaction sur l arrivée de certains événements asynchrones, selon la stratégie choisie. Définition et composition de modules À partir de la description en OC 11 d un module synchrone, le compilateur OCC++ génère soit une description MDL du module, soit une classe C++ synchrone encapsulant le comportement du module. MDL est un langage de description de modules synchrones par composition et héritage de modules existants. L héritage de modules permet principalement de ne pas avoir à redéfinir les signaux d entrée/sortie. Le compilateur MDLC produit une classe C++ synchrone à partir de la description MDL, en détectant les cycles de causalité. La machine d exécution d un réseau d objets synchrones se présente sous la forme d une bibliothèque de classes (libsync) qui fournit l environnement nécessaire aux classes synchrones produites par OCC++ ou MDLC. Un module composite est construit à partir d autre modules connectés de manière statique. Voici un exemple, tiré de [36], qui définit en MDL un module à partir de deux sous-modules interconnectés : compo : { input: integer e; // Signaux du module compo output: s; } A mod1, mod2; // Sous-modules utilisés mod1.i = e; // e est l entrée i de mod1 s = mod2.o; // s est la sortie o de mod2 mod2.i << mod1.o; // L entrée i de mod2 est connectée // à la sortie o de mod Objets réactifs Dans le modèle ROM (Reactive Object Model), une application est constituée d objets qui exécutent en parallèle des comportements réactifs et communiquent par des appels de méthodes traités instantanément. Un objet réactif encapsule des données, partagées par ses méthodes. Le corps d une méthode est décrit en REACTIVE-C. Il existe un objet dit initial, possédant une unique méthode chargée de contrôler le déroulement des cycles du système d objets. Les objets peuvent être clonés et les méthodes peuvent être ajoutées dynamiquement. Une méthode correspond à un module ESTEREL : elle ne peut être activée qu une seule fois dans un même instant et elle peut être suspendue jusqu à un instant ultérieur. Un objet correspond donc à un système composé de modules synchrones. L exécution d un objet pour un instant se termine quand toutes les méthodes sont terminées ou suspendues, c est-à-dire quand le système de modules synchrones est devenu stable. Un 11 OC (object code) est une syntaxe compilée commune à ESTEREL et LUSTRE.

87 4.7. SYNTHÈSE 87 instant du système d objets réactifs se termine lorsque tous les objets ont terminé leur réaction. Dans une même zone réactive, les méthodes sont appelées de façon asynchrone. Ces appels sont traités instantanément et les méthodes s exécutent en parallèle. Les paramètres d appel de méthode peuvent être de n importe quel type, éventuellement des objets ou d autres méthodes. À chaque cycle d activation, les méthodes en attente sont exécutées et les appels asynchrones instantanés sont réalisés. Comme le modèle de réseaux de processus réactifs, la programmation par objets réactifs introduit une contrainte supplémentaire par rapport à ESTEREL : pour éviter les cycles de causalité liés à la réaction à l absence de signaux, il est interdit de réagir instantanément à l absence d un événement. Cette réaction est reportée nécessairement à l instant suivant. 4.7 Synthèse D. Harel et A. Pnueli ont donné des systèmes réactifs l image de boîtes noires qui réagissent de manière réflexe aux stimuli de l environnement en changeant d état et en produisant à leur tour des stimuli. Le modèle synchrone facilite considérablement la description de ce type de systèmes, en considérant des éléments s exécutant en parallèle et partageant la même notion d instant ; ces éléments s exécutent naturellement au même rythme, sans avoir besoin de mettre en place un ordonnanceur de processus concurrents. ESTEREL est un langage synchrone de nature impérative, adapté à la description de systèmes temps-réel critiques ; il est par exemple utilisé chez DASSAULT-AVIATION pour concevoir des systèmes avioniques. Ce langage permet de définir un système réactif sous la forme d un module, constitué de composantes parallèles communiquant par diffusion instantanée de signaux. La description du comportement d un module est réalisée à l aide d instructions réactives explicites, comme la pause ou l attente retardée d un signal. ESTEREL offre une remarquable puissance d expression, tout en garantissant le déterminisme du système décrit. En pratique, ce langage nécessite la mise en œuvre d une machine d exécution, réalisant l interface entre le système synchrone et son environnement asynchrone. Des outils de vérification formelle sont disponibles, permettant de concevoir et de valider des comportements complexes s exécutant en parallèle. L architecture d un système réactif décrit en ESTEREL est statique, ce qui permet de garantir la validité du système pendant toute la durée de son exécution ; par contre, cette caractéristique ne correspond pas à nos besoins. Le modèle d objets synchrones fournit une solution plus dynamique de description de systèmes réactifs. Des objets encapsulant des modules synchrones sont interconnectés pour former des réseaux d objets synchrones. Plusieurs objets synchrones peuvent être connectés à une même entrée d un autre objet synchrone. Les objets et les connexions peuvent être ajoutés et retirés du réseau à tout moment de l exécution du système, et les connexions peuvent être modifiées. Le séquencement synchrone assure le respect du modèle synchrone et les boucles de causalité sont évitées par l introduction d objets retard. La communication asynchrone est possible avec les objets non synchrones du système, constituant l environnement du réseau d objets synchrones ; cette communication se fait par l intermédiaire d objets d interface. Les réseaux de processus réactifs constituent également une solution dynamique et déterministe, connectant

88 88 CHAPITRE 4. SYSTÈMES ET LANGAGES RÉACTIFS SYNCHRONES par des canaux FIFO des processus s exécutant en parallèle. Un processus peut tester qu un canal est vide pour l instant courant, ce qui correspond au test d absence de signal en ESTEREL. Bien qu ils ne fournissent pas explicitement de mécanisme d arbitrage, les modèles de réseaux d objets synchrones et de processus réactifs ressemblent étrangement aux architectures de sélection de l action basées sur les comportements. Ces modèles, ainsi que le langage ESTEREL, permettent de plus de décrire des systèmes qui doivent réagir à un environnement asynchrone de façon déterministe ; la communication entre les éléments d un tel système est synchrone car la présence des signaux ou des messages est bornée par la notion d instant. Il semble que l association des travaux concernant d une part les architectures d agents distribuées et d autre part les systèmes réactifs synchrones pourrait se révéler fructueuse. C est pourquoi nous nous avons choisi de définir notre propre architecture de sélection de l action, basée sur le modèle synchrone (cf. chapitre 7). Nous nous sommes ensuite inspirés de la syntaxe d ESTEREL pour définir la partie réactive du langage MARVIN (cf. chapitre 8).

89 Troisième partie Le modèle INVIWO 89

90

91 Chapitre 5 Agents et mondes INVIWO 5.1 Introduction Reprenons le schéma de synthèse que nous avons proposé à la fin du chapitre 2 (figure 2.7, page 43), sans tenir compte de la structure interne de l agent, pour obtenir la figure 5.1. Notre principale remarque portait alors sur le fait que la communication entre agents et l interaction avec l environnement sont des fonctionnalités nettement séparées. L environnement est généralement considéré comme une structure centralisée de partage d objets passifs et de données publiques. Il encapsule éventuellement des règles «universelles», qu il applique de lui-même lorsqu un agent tente d effectuer une action. Nous avons choisi une approche différente, complètement répartie, qui sera présentée dans la section 5.2. Interaction Communication stimuli Capteurs messages Environnement actions Effecteurs Agent Émetteurs messages Autres agents FIG. 5.1 Interaction et communication, telles que présentées dans le chapitre 2. Dans la synthèse du chapitre 2, nous avions par ailleurs formulé une critique importante : dans les modèles d agents que nous avons étudiés, il est rare qu apparaissent clairement les variables internes, ainsi que les capacités de perception et d action internes. Nous nous plaçons dans le cadre de la description de comportements d agents accessible à des non-spécialistes, il nous semble donc particulièrement important de présenter distinctement d une part la provenance des événements auxquels doit réagir un agent, d autre part le type d actions qu il est capable de réaliser, sur son environnement comme sur lui-même. Les différents composants d un agent INVIWO doivent lui permettre de gérer aussi bien l interaction avec son environnement que son propre état, et cela de manière homogène. Ces composants et leurs interactions seront détaillés dans la section 5.3. Nous présenterons ensuite les capacités de filtrage et d arbitrage, associées respectivement aux capteurs et aux effecteurs. Nous terminerons ce chapitre par une synthèse, qui nous permettra de comparer les caractéristiques d un agent INVIWO aux caractéristiques d agents décrites dans le chapitre 2. 91

92 92 CHAPITRE 5. AGENTS ET MONDES INVIWO 5.2 Interaction et communication Comme nous l avons évoqué dans l introduction générale (chapitre 1), nous avons choisi de ne pas distinguer les agents et les objets qu ils manipulent : dans notre modèle, «tout est agent». L environnement d un agent INVIWO est alors simplement l ensemble des autres agents. Nous ne distinguons pas l interaction avec l environnement de la communication entre agents : ces deux types d interaction n en forment plus qu une, réalisée par l envoi de messages appelés stimuli externes. La figure 5.2 illustre cette fusion de deux types d interaction. La notion de «stimulus envoyé» est bien sûr discutable car il s agit d un abus de langage : ce que nous appelons l envoi d un stimulus externe correspond en fait à l envoi d un message dont la réception constituera, pour l agent destinataire, un stimulus en provenance de l environnement. Environnement stimuli externes Interaction stimuli externes Capteurs Effecteurs Agent InViWo FIG. 5.2 Interaction et communication pour un agent INVIWO. Du point de vue des autres agents, un agent est une boîte noire capable d échanger des stimuli externes 1. La figure 5.3 représente un monde INVIWO, composé de trois agents interagissant conformément à notre approche distribuée. Monde InViWo Agent A Agent B stimuli externes Agent C FIG. 5.3 Un monde INVIWO composé de trois agents. Les messages échangés sont typés et peuvent contenir des paramètres structurés de complexité quelconque : un stimulus peut aussi bien indiquer une simple modification de la position d un agent que correspondre à un message KQML (cf. section 2.4.2, page 38). Un stimulus sans paramètre est qualifié de pur, en référence aux signaux purs d ESTEREL. Tout stimulus externe contient l identifiant de l agent qui l a envoyé. Les stimuli peuvent être envoyés à un agent précis (unicast) ou à l ensemble des autres 1 Puisqu il suffit que l agent soit capable de recevoir et d émettre des stimuli, il est tout à fait envisageable de définir des mondes INVIWO hétérogènes dans lesquels certains agents ne sont pas définis selon le modèle d agent INVIWO, tel que défini dans la section suivante.

93 5.3. COMPOSANTS D UN AGENT INVIWO 93 agents (broadcast). Nous ne gérons pas encore la diffusion restreinte (multicast) ; ce mode de communication nécessite en effet de mettre en œuvre la gestion de groupes de communication, à laquelle nous n avons pas encore eu le temps de nous intéresser. Les protocoles d interaction sont pour le moment réduits à la définition des types de stimuli externes échangés. La définition d un protocole est partagée par tous les agents susceptibles d interagir selon ce protocole. Il est bien sûr possible qu un agent utilise plusieurs protocoles d interaction, afin interagir avec différents groupes d agents. Cela permet entre autres de structurer les protocoles, par exemple en plusieurs niveaux de complexité des interactions ou en fonction des types d interactions possibles. 5.3 Composants d un agent InViWo Un agent peut être considéré comme un ensemble de composants lui permettant de percevoir, décider et agir. Comme l illustre la figure 5.4, un agent INVIWO est constitué d un ensemble d attributs, de capteurs, d effecteurs et d un processus de décision. La modification de la valeur d un attribut déclenche l envoi d un stimulus interne. Les capteurs, internes comme externes, génèrent des percepts à partir des stimuli perçus. Ces percepts peuvent déclencher le processus de décision, qui envoie alors des commandes aux effecteurs internes et externes. Les capteurs et les effecteurs externes sont chargés de l interaction avec l environnement. Les capteurs et les effecteurs internes gèrent en particulier la modification des attributs de l agent. L état interne d un agent à un instant donné est constitué de l état de chacun de ses composants, en particulier des valeurs courantes de ses attributs. Attributs Capteurs externes Capteurs internes Effecteurs internes Effecteurs externes Percepts Commandes Processus stimuli externes stimuli internes modifications de valeurs FIG. 5.4 Les composants d un agent INVIWO et leurs principales interactions. Les capteurs et effecteurs internes et externes sont ici présentés comme étant séparés, afin de faire apparaître clairement les principales interactions entre les différents

94 94 CHAPITRE 5. AGENTS ET MONDES INVIWO composants d un agent. Nous verrons dans la section pourquoi nous avons par la suite réuni d une part les capteurs internes et externes, et d autre part les effecteurs internes et externes Attributs Un attribut est une variable typée, représentant une caractéristique ou une connaissance de l agent, telles que la position de son centre de gravité, sa forme géométrique, son niveau d énergie ou encore une mémoire structurée ; une telle mémoire permet par exemple à l agent d élaborer une représentation de son environnement au fur et à mesure de son exploration. La valeur d un attribut est accessible en lecture à tous les composants de l agent mais elle ne peut être modifiée que par un effecteur Processus de décision Le processus de décision est composé de modules comportementaux réactifs et concurrents, chargés de proposer des actions à effectuer en fonction des percepts qui leur sont fournis. Le fonctionnement de ces modules sera détaillé dans le chapitre Capteurs et effecteurs Un effecteur est un composant chargé de réaliser les actions demandées par le processus de décision. Il encapsule des actions pouvant correspondre à plusieurs niveaux d abstraction ; ces actions abstraites sont construites à partir de quatre types d actions primitives. La seule action primitive externe possible est l envoi d un stimulus externe, selon l un des deux modes de communication disponibles (unicast, broadcast). Les trois autres types de primitives correspondent à des actions internes : modification de la structure par ajout d un composant ; modification de la structure par retrait d un composant ; modification des paramètres d un composant, en particulier de la valeur d un attribut. Un capteur est un composant chargé de réceptionner certains types de stimuli, puis de les traduire en percepts et distribuer ces percepts au processus de décision. Un capteur peut recevoir des stimuli externes, ainsi que trois types de stimuli internes correspondant aux trois types d actions primitives internes disponibles : un composant a été ajouté ; un composant a été retiré ; un composant a été modifié, en particulier un attribut a changé de valeur. Chacun des composants pouvant être ajouté ou retiré pendant l exécution de l agent, la structure de l agent est complètement dynamique. Le processus de décision est informé de ces modifications et peut ainsi éventuellement réagir à une évolution de la structure. La figure 5.5 présente l architecture complète d un agent INVIWO, en détaillant l ensemble des opérations internes et des émissions de stimuli internes possibles. Cette figure est complexe, c est pourquoi nous considérerons par la suite les capacités d évolution de la structure comme étant implicites.

95 5.3. COMPOSANTS D UN AGENT INVIWO 95 Attributs Capteurs externes Capteurs internes Effecteurs internes Effecteurs externes Percepts Commandes Processus stimuli externes stimuli internes stimuli internes modifications de valeurs modifications de structure FIG. 5.5 Détail des interactions entre composants d un agent INVIWO Le cas de la perception active La perception active implique que le système perceptif d un agent puisse influer sur les effecteurs de l agent afin d améliorer la perception, en particulier en contrôlant les moteurs rattachés aux capteurs physiques (cf. section 2.3.2, page 35). Le cycle «perception-décision-action» de notre modèle est figé et ne permet pas aux capteurs de contrôler directement des attributs correspondant à leur propre orientation ou à leur niveau de zoom par exemple. Cette contrainte a été choisie précisément afin d empêcher ce type de court-circuits pouvant entraîner une rupture du modèle. Dans le modèle INVIWO, la perception active peut se faire selon deux modes : modifier un ou plusieurs attributs concernant un capteur du système actif, par exemple son propre niveau de zoom ou l orientation globale de l agent ; interroger un ou plusieurs agents pour obtenir des informations complémentaires concernant l environnement. Cela permet de simuler entre autres la focalisation sur des zones de l environnement ou la recherche d informations dans la structure constituant l environnement. Pour définir un système perceptif actif, il est possible soit de faire intervenir uniquement les composants de l agent, soit de créer un nouvel agent pour gérer ce système actif. Avec la première solution, un capteur doit envoyer une demande d action à un effecteur. L action aura pour conséquence la modification d un ou plusieurs attributs, ou l envoi d un stimulus externe correspondant à une requête à un ou plusieurs autres agents. Le capteur attendra ensuite de recevoir soit le stimulus interne correspondant à la modification demandée, soit le stimulus externe correspondant à la réponse à sa

96 96 CHAPITRE 5. AGENTS ET MONDES INVIWO requête, pour produire des percepts. La deuxième solution nécessite la création d un agent spécialisé dans la perception active, qui fournira des stimuli externes (correspondant aux percepts générés) à l agent auquel il est rattaché. 5.4 Filtrage et arbitrage Capteurs et filtres Le rôle du système perceptif d un agent est de transformer les stimuli perçus en percepts, c est-à-dire en informations de niveau généralement supérieur (cf. section 2.3, page 34). Le système perceptif d un agent INVIWO est obtenu en ajoutant un mécanisme de filtrage aux capteurs. Chaque capteur est ainsi couplé à un filtre chargé d une part d éliminer les stimuli jugés inutiles, d autre part de créer des percepts à partir des stimuli pertinents. Un filtre peut par ailleurs générer des percepts en fonction de tests effectués sur les valeurs des attributs de l agent ou sur les valeurs des variables internes du capteur. Par exemple, un capteur pourra construire un percept indiquant que l agent a faim, lorsque le niveau d énergie de l agent passe sous un seuil donné. Il est bien sûr possible d utiliser à la fois les informations événementielles (stimuli) et les tests de valeurs pour construire un percept : par exemple, il est plus efficace de tester le niveau d énergie de l agent seulement s il vient d être modifié, donc si le stimulus interne correspondant vient d être généré. De plus, il est souvent utile de pouvoir créer un percept à partir de stimuli à la fois internes et externes : par exemple, l agent a faim parce que son niveau d énergie est très bas, ou parce que son niveau d énergie est plutôt bas et qu il perçoit une odeur de nourriture. C est pourquoi nous avons finalement choisi de ne pas différencier les capteurs internes et externes : un capteur peut recevoir aussi bien des stimuli internes qu externes. La figure 5.6 schématise le fonctionnement d un capteur couplé à un filtre. stimuli externes Capteur Filtre percepts stimuli internes FIG. 5.6 Capteur couplé à un filtre. Les percepts sont structurés de la même façon que les stimuli : ce sont des messages typés pouvant contenir des données structurées. Nous aurions pu n utiliser que des stimuli, mais nous avons préféré distinguer clairement les événements primitifs (stimuli en provenance de l environnement ou correspondant à une modification interne) des événements construits par les filtres couplés aux capteurs et pouvant provoquer une réaction du processus de décision (percepts). Notons que l utilisation d un filtre permet en particulier de construire un percept valué à partir d un stimulus interne indiquant la modification d un attribut. Ce stimulus prédéfini ne contient pas la nouvelle valeur de l attribut, mais celle-ci peut être récupérée par le filtre du capteur pour être transmise comme paramètre du percept.

97 5.4. FILTRAGE ET ARBITRAGE Effecteurs et arbitres Comme nous l avons déjà évoqué, le processus de décision d un agent est constitué de modules comportementaux s exécutant en parallèle. Le problème inhérent à ce type d architecture a été abordé dans le chapitre 3 : les actions souhaitées par les différents modules concurrents peuvent être conflictuelles, il est alors nécessaire d ajouter un mécanisme d arbitrage. Dans notre modèle, un arbitre est chargé de réceptionner des propositions d actions en provenance des modules comportementaux, puis de choisir une action à effectuer parmi ces propositions ou à partir de ces propositions. Cette sélection effective d une action peut être réalisée par différents types de fonctions d arbitrage, des plus simples telles que l utilisation d une fonction aléatoire, aux plus complexes faisant par exemple intervenir des priorités dynamiques entre modules. L arbitre demande ensuite à l effecteur auquel il est rattaché de réaliser cette action. De façon similaire à l architecture DAMN où un arbitre correspond à une seule variable du robot, nous associons un arbitre à un unique effecteur et un effecteur ne possède qu un seul arbitre : nous assurons ainsi que les arbitres n entrent pas en concurrence en choisissant des commandes conflictuelles pour le même effecteur. La figure 5.7 schématise le fonctionnement d un effecteur couplé à un arbitre. envois de stimuli externes propositions d actions Arbitre commandes Effecteur modifications de structure modifications d attributs FIG. 5.7 Effecteur couplé à un arbitre. Le regroupement des effecteurs internes et externes permet de rendre atomiques certaines opérations internes ayant des répercussions sur l environnement. Par exemple, dans le monde réel, l action de lever un bras aura deux effets distincts : la personne qui a levé le bras subit une modification interne, et le changement d état de cette personne est visible par les autres personnes présentes dans son environnement proche. Il s agit bien d une action interne d un agent qui induit une modification de l environnement des autres agents. Dans le monde réel, une créature vivante perçoit ce type de modification de son environnement en fonction de ses capteurs, en particulier grâce à la vision. Ce type de perception est encore possible pour un robot physique mais il doit être simulé dans le cas d agents purement logiciels, pour lesquels il est habituellement pris en charge par le moteur d animation ou par la structure constituant l environnement. La structure représentant l environnement est centralisée ; elle gère les données publiques des agents, telles que la position de leurs bras, et réalise ces actions à la place des agents, voire informe les autres agents de ces modifications comme dans le cas d un simulateur à événements discrets (cf. section 2.4.3, page 39). Nous avons choisi un modèle de système multi-agents complètement réparti : chaque agent d un monde INVIWO doit donc faire connaître de lui-même les conséquences de ses actions internes aux autres agents pour que ces actions soient effectives dans le monde. Un effecteur associé à un attribut de l agent est alors naturellement responsable à la fois de la modification de la valeur de l attribut et de l émission d un stimulus externe indiquant la nouvelle valeur de cet attribut.

98 98 CHAPITRE 5. AGENTS ET MONDES INVIWO Notons que le fonctionnement de l arbitre dépend en grande partie des types de données qui lui sont fournies en entrée. Les propositions d actions peuvent en effet être données sous la forme classique de valeurs à affecter à un attribut, mais aussi sous la forme d un domaine de valeurs souhaitables, sous la forme de votes associés à des actions discrétisées à la façon de l architecture DAMN (cf. section 3.3.5, page 53), sous la forme de différentiels à appliquer à un attribut comme ce qui est proposé par L. Steels dans son modèle de systèmes dynamiques (cf. section 3.3.9, page 59), etc. 5.5 Synthèse La figure 5.8 représente l architecture finale d un agent INVIWO, en considérant les capacités d évolution de la structure comme implicites. Elle présente l ensemble des composants d un agent INVIWO : les attributs, le processus de décision, les capteurs et leurs filtres, les effecteurs et leurs arbitres. L architecture du processus de décision sera détaillée dans le chapitre 7. Attributs Capteurs Filtres Effecteurs Arbitres Percepts Propositions Processus stimuli externes stimuli internes modifications de valeurs FIG. 5.8 Architecture synthétique d un agent INVIWO. Nous pouvons maintenant essayer d appliquer aux agents INVIWO les caractéristiques des agents autonomes définies dans le chapitre 2 : autonomie : un agent INVIWO est complètement autonome car son état et son processus de décision sont entièrement encapsulés. De plus, les actions sont gérées uniquement par les agents et non pas par une structure centralisée représentant l environnement; environnement : «tout est agent», donc l environnement d un agent INVIWO est constitué uniquement de l ensemble des autres agents. Toute l interaction entre agents se fait par envoi de messages, appelés stimuli externes ;

99 5.5. SYNTHÈSE 99 intelligence : les agents INVIWO sont des agents hybrides d abord réactifs ; comportement adaptatif : un agent INVIWO n est pas a priori adaptatif, mais l apprentissage peut être réalisé par des modules comportementaux et des attributs de mémorisation spécifiques ; sociabilité : les agents INVIWO ne sont pas particulièrement coopératifs, mais les lois sociales tout comme les lois physiques peuvent par exemple être distribuées dans chaque agent. Notre modèle d agent INVIWO est une simplification extrême des architectures d agents que nous avons étudiées : les composants ont été choisis car ils nous semblent à la fois indispensables et suffisants pour décrire de façon modulaire des agents réactifs et hybrides. De plus, la structure dynamique que nous proposons permet de facilement décrire des agents évolutifs. Le «niveau d intelligence» de l agent ne dépend pas d une architecture prédéfinie, comme dans le cas des architectures hybrides en couches, mais du type des attributs choisis par le concepteur et de la complexité du processus de décision. Des couches peuvent évidemment être définies par-dessus notre modèle, nous avons simplement choisi une architecture d agent minimale. Le cycle perceptiondécision-action apparaît clairement, ainsi que les flux d information entre composants et les rôles de chacun de ces composants. Les types d actions primitives sont limités au nombre de quatre, mais se combinent facilement pour construire des actions abstraites. Les actions internes provoquent automatiquement la génération de stimuli internes, pouvant être réinjectés dans le processus global de décision. Les capacités de filtrage et d arbitrage, se trouvant respectivement en début et en fin de la chaîne de décision, facilitent d autant plus la conception modulaire ; leur rôle sera encore plus clair dans le chapitre 7 consacré à la sélection de l action pour les agents INVIWO.

100 100 CHAPITRE 5. AGENTS ET MONDES INVIWO

101 Chapitre 6 Avatars INVIWO 6.1 Introduction Un avatar est le représentant d un utilisateur dans un monde virtuel. Le terme avatar provient d avatara, le mot sanskrit désignant chacune des différentes incarnations du dieu hindou Visnu sur terre. Ce terme est parfois utilisé à tort pour désigner des acteurs virtuels ou des humains virtuels, qui sont en fait des agents autonomes humanoïdes et nullement des représentations d opérateurs humains. Comme nous l avons indiqué dans l introduction générale, l utilisateur est rarement uniquement un observateur dans un monde virtuel : il est généralement «plongé» dans le monde virtuel, le faisant évoluer par ses propres actions. La perception du monde et l action sur les objets du monde se font par l intermédiaire de systèmes matériels et logiciels, regroupés sous le nom de système d interaction. Dans ce chapitre, nous allons tout d abord présenter ce système d interaction, puis le rôle qui est donné habituellement aux avatars vis-à-vis du système d interaction. Nous détaillerons ensuite notre modèle d avatar, qui permet d intégrer l utilisateur dans un monde INVIWO de façon homogène et avec une extension minimale de notre modèle d agent. 6.2 Définition classique de l avatar Le système d interaction Le système d interaction est l interface matérielle et logicielle entre l opérateur et le monde virtuel. Les moyens d interaction sont les éléments présents à l intérieur du monde virtuel, chargés de percevoir le monde et d agir sur ce monde. Les moyens d action, comme les organes de préhension ou de pointage d objets, possèdent souvent une représentation graphique. Les moyens de perception, tels que le point de vue de l utilisateur ou le détecteur de collision, ne sont généralement pas représentés. Le système d interaction intègre et contrôle l ensemble des moyens d interaction. Il est constitué : de périphériques d entrée, tels qu un clavier, un joystick ou des capteurs 3D ; de périphériques de sortie, tels qu un écran, un mécanisme de retour d effort ou un dispositif audio ; de modules logiciels de présentation de la perception du monde virtuel à l opérateur. Ces modules interprètent les percepts fournis par les moyens de percep- 101

102 102 CHAPITRE 6. AVATARS INVIWO tion et contrôlent les périphériques de sortie. Ils gèrent par exemple la représentation 3D du monde virtuel, la liste des utilisateurs présents ou la restitution du son ; de modules logiciels d interprétation des actions demandées par l utilisateur. Ces modules reçoivent des commandes en provenance des périphériques d entrée et contrôlent les moyens d action pour réaliser les commandes. Ils gèrent par exemple le déplacement du point de vue, la préhension ou le pointage d un objet. La figure 6.1 schématise le fonctionnement du système d interaction. Le logiciel d interaction permet éventuellement d assister l opérateur dans la réalisation de tâches répétitives, telles que la marche ou la détection de collision, ou délicates comme la préhension [136]. Monde virtuel d interaction point de vue objet organe de FIG. 6.1 Le système d interaction L avatar Nous pouvons préciser la définition d avatar en distinguant deux rôles : 1. la représentation visuelle (texte, 2D ou 3D) de l opérateur dans un environnement multi-utilisateurs ; 2. le contrôle de l ensemble des moyens d interaction à la disposition de l utilisateur. Dans le premier cas, l avatar est le support de communication entre les différents utilisateurs présents dans le monde virtuel. Dans un monde SCOL [7] par exemple, un utilisateur est perçu par les autres sous la forme d une image 2D ou d un objet 3D mobile. La figure 6.2 montre des avatars représentés dans le DIAMOND PARK sous la forme de monocyclistes ou de personnes assises à la terrasse d un café. Dans le cas extrême de la visio-conférence, la reproduction de l interlocuteur se doit d être la plus fidèle possible. Dans le deuxième cas, l avatar perçoit et agit pour l opérateur dans le monde virtuel. Il permet ainsi par exemple de manipuler une vue subjective de la scène (principalement pour la déplacer), de détecter les collisions et de dialoguer avec les autres utilisateurs. L avatar correspond alors à une partie des modules logiciels du système

103 6.2. DÉFINITION CLASSIQUE DE L AVATAR 103 FIG. 6.2 Une discussion entre avatars au café du Diamond Park. d interaction. Le visiteur d un monde SCOL a une vue subjective de la scène et peut s y déplacer en utilisant le clavier ou la souris. Dans le DIAMOND PARK, les opérateurs utilisent deux types de périphériques d entrée : un vélo d appartement contrôlé par ordinateur ou une trackball. Le vélo d appartement commande un avatar représenté sous la forme d un cycliste, alors que la trackball contrôle un monocycliste virtuel semblable à ceux de la figure 6.2. L avatar remplit donc généralement à la fois les fonctions de communication vis-à-vis des autres utilisateurs, et de perception et d action en tant que partie du système d interaction. L utilisateur peut éventuellement manipuler des points de vue non subjectifs et ainsi visualiser sa propre représentation graphique. La figure 6.3 illustre le rôle de l avatar vis-à-vis du système d interaction. Monde virtuel d interaction objet graphique de point de vue organe de avatar FIG. 6.3 L avatar classique.

104 104 CHAPITRE 6. AVATARS INVIWO 6.3 L avatar INVIWO Incarner l utilisateur L avatar agit sur deux plans distincts de l interface entre l opérateur et le monde virtuel : d une part, il interagit avec le monde virtuel à la place de l opérateur, c est-à-dire qu il perçoit l environnement et effectue des actions ; d autre part, par l intermédiaire du système d interaction, il présente les perceptions sous une forme compréhensible par l opérateur et réceptionne les commandes utilisateur à effectuer. Pour interagir avec les habitants d un monde INVIWO, un avatar doit être capable de communiquer avec son opérateur, mais aussi avec les agents autonomes et les autres avatars. Une manière simple de réaliser la communication avec les autres entités présentes est de considérer l avatar comme un agent à part entière : l interaction entre toutes les entités se fait alors de façon homogène, par l intermédiaire des stimuli externes. Vis-à-vis des autres habitants d un monde INVIWO, l avatar est un agent comme les autres ; il a cependant la particularité d être contrôlé par un opérateur humain. Les capteurs et les effecteurs d un avatar correspondent à l ensemble des moyens d interaction mis à la disposition de l utilisateur. Puisque l avatar possède et contrôle directement ces moyens, il devient l interface unique entre le système d interaction et le monde virtuel. La figure 6.4 illustre le rôle de l avatar INVIWO vis-à-vis du système d interaction. Monde virtuel d interaction avatar agent capteur effecteur stimulus FIG. 6.4 L avatar INVIWO. En plus de conserver l homogénéité de notre modèle de mondes virtuels, constitués uniquement d agents, le choix de considérer l avatar comme un agent apporte un autre avantage considérable : selon le niveau de contrôle donné à l opérateur, l avatar peut bénéficier d une semi-autonomie. Il peut ainsi intégrer des capacités d assistance à l utilisateur, en gérant lui-même une partie de l interaction avec les autres agents, par exemple l évitement de collision. Une partie des modules logiciels du système d interaction peut ainsi être déporté au niveau de l avatar INVIWO.

105 6.3. L AVATAR INVIWO 105 Intéressons nous maintenant à la communication entre un utilisateur et son avatar. Il serait possible d étendre le modèle d agent INVIWO de façon à ajouter des types de composants supplémentaires, spécifiquement chargés de l interaction avec l opérateur. Il faudrait pour cela introduire l équivalent des capteurs, des effecteurs et du processus de décision, afin de prendre en compte les actions et la caractéristique de semi-autonomie de l avatar. Cette solution aurait l inconvénient évident de traiter indépendamment le comportement propre à l avatar (en partie autonome) et le comportement contrôlé par l utilisateur. Il faut donc que les composants supplémentaires soient connectés à un unique processus de décision, chargé de combiner le comportement de l avatar et les attentes de l utilisateur. En proposant l ajout de capteurs et d effecteurs spéciaux, éventuellement reliés directement au système d interaction, nous retomberions dans la distinction entre capteurs et effecteurs internes et externes, que nous avons critiquée dans le chapitre 5 : le filtrage et l arbitrage correspondant à l opérateur seraient alors séparées des autres capacités de filtrage et d arbitrage. Nous avons donc simplement défini un nouveau type de stimuli, appelés stimuli utilisateurs, permettant la communication avec l opérateur. Ces stimuli peuvent être reçus par n importe quel capteur et être envoyés par n importe quel effecteur. Les figures 6.5 et 6.6 présentent l extension de nos modèles de capteur et d effecteur. Dorénavant, tout agent est a priori capable de recevoir et envoyer des stimuli utilisateurs ; s il réalise ces capacités, il devient un avatar. stimuli externes stimuli utilisateurs Capteur Filtre percepts stimuli internes FIG. 6.5 Extension du modèle de capteur. envois de stimuli externes propositions d actions Arbitre commandes Effecteur envois de stimuli utilisateurs modifications de structure modifications d attributs FIG. 6.6 Extension du modèle d effecteur. La communication avec le système d interaction se fait donc par l échange de stimuli utilisateurs. Les stimuli envoyés par l avatar correspondent à ce que le système de perception doit présenter à l utilisateur. Les stimuli reçus par l avatar correspondent aux commandes utilisateurs données au système d action. Nous appellerons interface utilisateur la partie du système d interaction ne concernant pas l avatar INVIWO. La figure 6.7 illustre la communication entre un avatar et une interface utilisateur, qui doit

106 106 CHAPITRE 6. AVATARS INVIWO pouvoir envoyer et recevoir des stimuli utilisateurs. Attributs Capteurs Filtres Effecteurs Arbitres Percepts Processus Propositions stimuli externes stimuli internes stimuli utilisateurs modifications d attributs FIG. 6.7 Avatar INVIWO et interface utilisateur Assister et contraindre l utilisateur Étant donné qu un avatar INVIWO est un agent, il peut posséder son propre comportement, bien que l opérateur puisse par ailleurs le contrôler. Dans ce cas, le comportement global de l avatar est composé des décisions de l opérateur et des choix de l agent. Cette semi-autonomie permet en particulier d assister l opérateur. Par exemple, le monde INVIWO présenté dans l introduction générale a été conçu de façon à ce que l avatar possède le même comportement d évitement de collisions que les lapins autonomes : l avatar évite ainsi automatiquement les obstacles, statiques et dynamiques, ce qui facilite l exploration du monde. L avatar ne se retrouve en particulier pas bloqué par un obstacle. Il serait aussi envisageable de donner à l utilisateur la possibilité d indiquer une position, laissant à l avatar semi-autonome le soin d atteindre cette cible sans encombre. Cette caractéristique de semi-autonomie de l avatar lui permet aussi de contraindre l utilisateur à jouer un rôle, par exemple en se pliant aux contraintes du monde virtuel ou aux conséquences de la personnalité de son avatar. L avatar peut posséder sa propre personnalité ou être contraint par le monde et ses règles sociales d agir selon certaines conditions. Par exemple, un avatar ivre ne marchera pas droit, quoi que puisse faire l opérateur.

107 6.4. INTERFACES UTILISATEURS Interfaces utilisateurs Remarquons que la conception de l interface utilisateur est complètement indépendante de la conception de l avatar lui-même. La seule obligation pour l interface utilisateur est d être capable de recevoir et d envoyer des stimuli utilisateurs. L interface utilisateur est chargée de traduire les stimuli utilisateurs en informations compréhensibles par l utilisateur, et de transformer les commandes de l utilisateur en stimuli utilisateurs. L interface peut ensuite utiliser une représentation en mode texte, en 2D ou en 3D du monde virtuel, intégrer des périphériques d entrée et de sortie quelconques, interagir avec l utilisateur en langage naturel, etc. Les stimuli utilisateurs sont gérés par l avatar exactement comme les stimuli externes. En particulier, ces stimuli contiennent systématiquement l identifiant de l émetteur, c est-à-dire soit de l avatar lui-même, soit de l interface utilisateur, de la même façon que les stimuli externes contiennent toujours l identifiant de l agent émetteur. Rien n empêche donc une interface utilisateur de contrôler plusieurs avatars, représentant différents points de vue de la scène ou différents types de représentation par exemple. Rien n empêche non plus un avatar d interagir avec plusieurs interfaces utilisateurs, représentant un ou plusieurs utilisateurs différents. L avatar peut donc devenir «multi-utilisateur», bien que cette utilisation de l avatar soit plutôt inhabituelle. 6.5 Synthèse S il est largement accepté qu un utilisateur est représenté dans un monde virtuel par un avatar, il est moins classique d intégrer réellement un utilisateur dans un système multi-agents. En effet, l utilisateur est généralement simple observateur d une simulation multi-agents, avec éventuellement la possibilité de modifier quelques paramètres pendant l exécution du système. L utilisateur est ainsi rarement mis au même niveau que les entités autonomes qu il observe ; il ne peut pas manipuler les objets du monde comme s il était lui-même une des entités observées. Notre modèle d avatar permet d intégrer complètement l utilisateur dans un système multi-agents particulier, sans pour autant modifier l architecture de nos agents autonomes ni le mode de communication entre ces agents. De plus, nous proposons un modèle dans lequel l interface utilisateur est conçue de façon entièrement indépendante de l avatar lui-même. Les capacités de l avatar dans le monde virtuel ainsi que son niveau d autonomie sont définis au niveau de l agent, alors que l interface utilisateur doit seulement être capable d interpréter et envoyer des stimuli utilisateurs. Quelle que soit la complexité de cette interface, l avatar restera inchangé. Cette indépendance permet en particulier deux utilisations originales des avatars : une même interface peut contrôler plusieurs avatars et un même avatar peut interagir avec plusieurs interfaces utilisateurs, donc éventuellement avec plusieurs utilisateurs différents.

108 108 CHAPITRE 6. AVATARS INVIWO

109 Quatrième partie Décrire des comportements d agents virtuels 109

110

111 Chapitre 7 Les modules comportementaux 7.1 Introduction Comme nous l avons évoqué dans le chapitre 5 consacré aux agents INVIWO, le processus d un agent est composé d un ensemble de modules comportementaux concurrents, chargés de proposer des actions à effectuer en fonction des stimuli perçus et de l état courant de l agent ; dans un deuxième temps, les arbitres choisissent les actions à réaliser à partir des propositions qui leur ont été faites. Nous avons donc choisi une architecture distribuée pour la sélection de l action, associée à un modèle générique d arbitrage. Nous cherchons à exprimer des comportements d agents réactifs, c est pourquoi il nous a semblé naturel que les modules comportementaux soient euxmêmes des entités réactives. Nous nous sommes pour cela inspirés du modèle réactif synchrone (cf. chapitre 4), en particulier du langage ESTEREL, des objets synchrones et des réseaux de processus réactifs, afin de proposer une architecture de sélection de l action basée sur des modules synchrones concurrents. Nous avons repris les grandes caractéristiques du modèle réactif synchrone, à savoir les notions d instant et de signal, tout en faisant quelques simplifications par rapport au langage ESTEREL. Nous avons conservé une notion d instant partagée par un ensemble de modules comportementaux : un instant correspond donc à un pas de réaction de l agent, c est-à-dire à la réaction de l ensemble des modules comportementaux constituant son processus de décision. Notre notion de signal est plus proche de celle définie pour les objets synchrones ou de la notion de messages échangés entre processus réactifs, puisque nous manipulons des canaux de communication unidirectionnels. Nous expliquerons ce choix en détail dans la section 7.3. Ce chapitre est organisé comme suit : nous introduirons tout d abord la structure d un module comportemental ; nous verrons en particulier que les modules peuvent être composés de sous-modules. Un ensemble de modules comportementaux interconnectés forment un réseau comportemental ; un réseau comportemental connecté à des filtres et à des arbitres constitue une chaîne de réaction. Nous expliciterons la nature des connexions entre les composants d une chaîne de réaction, puis nous préciserons les interactions possibles entre les modules comportementaux et les autres composants de l agent, ainsi que le rôle des arbitres dans la gestion des priorités entre modules. Nous aborderons ensuite le problème de l ordonnancement de l exécution des modules 111

112 112 CHAPITRE 7. LES MODULES COMPORTEMENTAUX comportementaux, similaire au séquencement des objets synchrones. Nous terminerons sur une synthèse, qui nous permettra en particulier de comparer un agent INVIWO d une part à un module comportemental et d autre part à une machine d exécution ESTEREL. 7.2 Structure d un module comportemental Interface et structure interne d un module Considérons tout d abord les modules comportementaux comme de simples boîtes noires communicantes. La figure 7.1 présente l interface d un tel module, composée d entrées et de sorties correspondant aux signaux qu il accepte en entrée et à ceux qu il peut émettre en sortie. Comme dans le cas d ESTEREL, un signal peut être pur ou valué, un signal valué pouvant transporter n importe quelle valeur typée. { signaux... sorties s_in 1 s_out 1 s_in 2 s_out 2 module comportemental... signaux }en sortie s_in n s_out m FIG. 7.1 Interface d un module comportemental. Un module comportemental encapsule des variables globales 1 et un corps, correspondant au corps d un module ESTEREL. Ce corps réagit aux signaux reçus en entrée en modifiant les variables globales du module ou en émettant des signaux en sortie, comme l illustre la figure 7.2. Les valeurs des variables du module et des attributs de l agent peuvent être prises en compte dans la réaction. Le fonctionnement du corps d un module sera décrit plus en détail dans le chapitre 8 dédié au langage MARVIN. Variables globales activation Corps action FIG. 7.2 Structure interne d un module comportemental. 1 Contrairement à ESTEREL, qui ne permet de manipuler que des variables locales, les variables peuvent ici être globales à un module comportemental.

113 7.3. SIGNAUX ET CANAUX 113 L interface et la structure d un module comportemental ne peuvent pas être modifiées dynamiquement, contrairement à la structure d un agent. En particulier, le nombre d entrées et de sorties est fixé à la définition du module. Il est par contre possible de remplacer le corps d un module comportemental Modules et sous-modules Dans la synthèse du chapitre 3 (section 3.4, page 60), nous avons insisté sur l importance de pouvoir décrire récursivement un système comportemental à partir de soussystèmes définis de la même manière. Un module comportemental INVIWO peut donc être composé de sous-modules. Un module-fils peut communiquer avec son père, qui l a instancié, ainsi qu avec ses frères, c est-à-dire avec les autres modules que son père a pu instancier. Il ne peut par contre pas communiquer avec les modules comportementaux extérieurs. Tout un réseau comportemental peut ainsi être encapsulé dans un unique module, lui-même intégré dans un réseau de niveau supérieur. Cette modularité s avère pratique pour la description aussi bien textuelle que graphique du comportement d un agent. La figure 7.3 présente un exemple de réseau comportemental encapsulé dans un module, ce module étant lui-même connecté à d autres modules comportementaux. CA C B C 1 C 3 C 4 C D C 2 C 5 C E FIG. 7.3 Exemple d encapsulation d un réseau comportemental. Cette figure montre par ailleurs qu il est possible de relier directement les entrées et sorties des sous-modules aux entrées et sorties du module-père. Il est aussi possible de définir des entrées et des sorties purement locales, qui permettent une communication père-fils spécifique. La figure 7.4 présente un exemple de module comportemental contenant un sous-module, ainsi qu une entrée et une sortie locales. Un sous-module ne peut pas avoir accès aux variables de son père et réciproquement. Un module-fils est partiellement contrôlable par son père, qui peut le déclencher et le faire avorter. Si le module-père se termine suite à un avortement, tous ses fils seront instantanément avortés. Si le module-père se termine de façon normale, ses fils peuvent continuer de s exécuter. 7.3 Signaux et canaux En ESTEREL, un signal est à la fois l entrée (ou la sortie) d un module et l événement reçu (ou envoyé), éventuellement valué. Les communications synchrones s effectuent par partage de nom : tous les signaux portant le même nom ont la même valeur. Dans le cas de l instanciation de sous-modules, il est possible de renommer les signaux,

114 114 CHAPITRE 7. LES MODULES COMPORTEMENTAUX Variables locales Corps sortie locale locale Variables locales Corps FIG. 7.4 Communication entre un module-père et un module-fils. afin de profiter pleinement de la modularité du langage. Le principal avantage de cette solution est de simplifier la gestion des communications entre modules. L inconvénient évident est la staticité du système : l architecture de l application, et en particulier la configuration des communications, ne pourront pas évoluer pendant l exécution du programme. Cette caractéristique est bien sûr un avantage dans le contexte des applications temps-réel critiques, mais c est un inconvénient pour nous. Nous avons choisi de considérer un signal uniquement comme l événement (éventuellement valué) transmis d un module à l autre. Les entrées et les sorties d un module reçoivent et émettent les signaux, nous distinguons donc nettement les signaux des entrées/sorties d un module. Nous nous sommes inspirés à la fois des canaux reliant les processus réactifs et des communications point à point entre objets synchrones, ces deux modèles permettant de considérer des entités communicantes formant des réseaux dynamiques. Dans notre modèle, il faut créer explicitement un canal reliant une sortie d un module à une entrée d un autre module. L entrée et la sortie ainsi connectées doivent être du même type : elles doivent correspondre toutes deux soit à des signaux purs, soit à des signaux transportant le même type de valeurs. Il est interdit de connecter plusieurs canaux d une même entrée à une même sortie. Un canal possède exactement un producteur et un consommateur. Le producteur peut être un capteur et le consommateur peut être un effecteur. Ces deux cas correspondent respectivement aux canaux sans producteur (entrées) et sans consommateur (sorties) des réseaux de processus réactifs, ou aux objets d interface d entrée et de sortie utilisés par les objets synchrones pour communiquer avec leur environnement asynchrone. Les capteurs et les effecteurs permettent donc l interaction avec le système qui accueille le réseau de modules comportementaux, c est-à-dire avec l environnement asynchrone dans lequel est plongé l agent.

115 7.3. SIGNAUX ET CANAUX 115 C est par l interconnexion définie par l utilisateur que se fait l interaction entre modules, elle conditionne donc l émergence du comportement global de l agent. Bien que la mise en œuvre de notre solution semble plus complexe que celle adoptée pour le langage ESTEREL, elle correspond à notre souhait de proposer un modèle d agent évolutif, c est-à-dire capable de se modifier au fur et à mesure de son exécution (cf. section 5.3.3, page 94). Il faut de plus garder à l esprit qu une grande partie de la description d un agent sera à terme réalisée à l aide d une interface graphique et que la description textuelle sera générée automatiquement, ce qui rendra moins pénible la création des canaux Manipulation de signaux en sortie La notion de signal en ESTEREL correspond à une approche que nous qualifierons d «orientée électronique» : les signaux sont diffusés instantanément dans toutes les composantes parallèles d un module ; le statut et la valeur d un signal en sortie sont accessibles en lecture. Ces deux caractéristiques correspondent à l «instantanéité» de la diffusion du courant dans un composant électronique et à la possibilité pour un tel composant de connaître l état de ses pattes de sortie. Cette approche est certainement utile dans le cadre des applications typiques d ESTEREL, mais elle nous semble peu intuitive. Reprenons l exemple donné en section (page 71), qui émet continuellement le signal O : loop present S then emit O end present emit S each tick Un tel programme est difficile à interpréter ou à concevoir, même pour un informaticien confirmé, parce qu il utilise la possibilité de tester la présence d un signal émis dans le même instant par une composante du même module. Dans le cadre qui nous intéresse, une telle fonctionnalité nous paraît complexifier inutilement la description du comportement d un agent. Elle pourrait mener un concepteur à définir des comportements erronés, en particulier s il n est pas informaticien. Pour limiter ce risque d erreur, nous préférons contraindre l utilisateur en proposant un modèle plus simple, dans lequel un signal en sortie d un module est considéré comme un message à destination d un arbitre ou d un autre module. Ce signal ne peut être qu émis ; son statut et son éventuelle valeur ne peuvent pas être consultés au sein du corps de module qui l a envoyé. Seul le module destinataire pourra manipuler ce signal, lorsqu il l aura reçu. Contrairement à ESTEREL, nos signaux ne sont donc pas des structures de données partagées par les composantes parallèles d un module, mais seulement des messages échangés entre des modules comportementaux concurrents Envoi unique et réception multiple Un signal émis par un module comportemental sur un canal en sortie est stocké sur le canal en attendant d être consommé par le module destinataire. Cette description pourrait correspondre à une communication asynchrone, mais nous restons fidèles

116 116 CHAPITRE 7. LES MODULES COMPORTEMENTAUX au modèle synchrone dans le sens où le signal émis sera reçu dans le même instant. Si plusieurs canaux sont connectés à une même sortie, ils contiendront bien sûr tous la même valeur de signal. Un module ne peut générer qu un seul signal sur une même sortie au cours d un instant ; en particulier, il n est pas possible d émettre simultanément des signaux valués transportant des valeurs différentes. Un module risquant d émettre simultanément plusieurs valeurs pour un même signal doit posséder une méthode de combinaison des valeurs de ce signal afin de n émettre qu une seule occurrence. Cette méthode est associée à une sortie, il est donc possible de prendre aussi en compte les signaux simultanés en provenance des sous-modules connectés à cette sortie. Nous verrons dans le chapitre 8 comment définir une telle fonction en MARVIN. Si cette méthode de combinaison n est pas définie, le comportement du canal devient indéterministe : un seul signal sera transmis, mais la stratégie de sélection dépendra uniquement de l implémentation. Il est possible de connecter plusieurs canaux à une même entrée, un module comportemental peut donc recevoir plusieurs occurrences du même type de signal à un instant donné. Le module concerné doit être capable d assurer cette réception multiple. Nous verrons dans le chapitre 8 comment gérer une réception multiple de signaux en entrée au niveau du langage MARVIN. Cette caractéristique permet en particulier de rendre flexible la proposition d actions aux arbitres. Nous nous inspirons donc à la fois des réseaux de processus réactifs, des réseaux d objets synchrones et du modèle d ESTEREL, avec des différences importantes provenant du mélange de ces trois modèles et de leur adaptation à nos besoins. Comme un canal reliant deux processus réactifs, un canal INVIWO permet à deux modules comportementaux de communiquer de façon synchrone. Par contre, les canaux reliant les processus réactifs sont des files, alors que nos canaux contiennent au plus un signal à un instant donné : un module comportemental, comme un module ESTEREL, ne peut en effet envoyer qu une seule occurrence d un signal dans un même instant. Cette contrainte est respectée en définissant au besoin une fonction de combinaison, comme en ESTEREL. Un signal émis par un module comportemental peut être reçu par plusieurs autres modules. La diffusion instantanée d ESTEREL permet aussi à plusieurs modules de recevoir le même signal mais la connexion statique entre modules, réalisée par le nommage des signaux, interdit la modification de la liste des destinataires. Dans notre modèle au contraire, les interconnexions peuvent être modifiées dynamiquement, comme dans le modèle d objets synchrones. Un module comportemental peut enfin recevoir simultanément plusieurs occurrences d un même type de signal, en provenance d émetteurs différents ; cette caractéristique ne semble être présente dans aucun des trois autres modèles. 7.4 Chaîne de réaction Une chaîne de réaction se constitue en interconnectant des modules comportementaux, des capteurs et des effecteurs. Bien qu il soit possible de relier la sortie d un capteur directement à l entrée d un effecteur, une chaîne de réaction typique part des capteurs pour arriver aux effecteurs, en passant par un nombre quelconque de modules comportementaux. Dans l exemple de la figure 7.5, il faudra ainsi définir le canal permettant la transmission d un signal depuis la sortie du premier effecteur à l entrée du premier module comportemental, et ainsi de suite. Comme pour ESTEREL et les

117 7.4. CHAÎNE DE RÉACTION 117 réseaux d objets synchrones, un ensemble de modules comportementaux est un système synchrone, dont la réaction globale correspond à celle d un unique module. capteur 1 module 1 module 3 effecteur 1 filtre s1 s1 s2 s3 s1 s2 s3 s1 arbitre capteur 2 module 2 effecteur 2 filtre s1 s2 s1 s2 s1 s2 arbitre FIG. 7.5 Un exemple de chaîne de réaction. Comme l interface d un module comportemental, l interface d un capteur ou d un effecteur est statique. Seuls les composants comportementaux eux-mêmes (modules, capteurs et effecteurs) et leurs interconnexions peuvent être ajoutés ou retirés du réseau pendant l exécution de l agent. Un capteur ne possède pas d entrées, puisqu il reçoit uniquement des stimuli. Le filtre d un capteur doit sélectionner les signaux à distribuer aux modules comportementaux en fonction des stimuli perçus par le capteur. Un effecteur ne possède pas de sorties, puisqu il réalise directement les actions primitives. L arbitre d un effecteur doit choisir une action à réaliser en fonction des requêtes en provenance de modules comportementaux. Nous verrons dans le chapitre 8 que les capteurs et les effecteur sont décrits en MARVIN de façon similaire aux modules comportementaux Interaction avec les autres composants Puisqu il doit entre autres réagir en fonction de l état courant de l agent auquel il est rattaché, un module comportemental peut consulter les valeurs des attributs de son propriétaire. Cependant, il ne modifie pas directement ces attributs puisque son rôle consiste à proposer des actions aux effecteurs et non pas à réaliser ces actions. attribut "position" capteur de position filtre stimulus interne lecture module de gestion de la position effecteur de position arbitre FIG. 7.6 Exemple d interaction avec un attribut.

118 118 CHAPITRE 7. LES MODULES COMPORTEMENTAUX La figure 7.6 illustre un exemple simple d interaction entre les différents composants d un agent : le module comportemental gère l attribut correspondant à la position de l agent. Il peut consulter la valeur de l attribut mais doit demander à un effecteur dédié de modifier la valeur de cet attribut, en lui envoyant une proposition. L attribut génère un stimulus interne lorsque sa valeur est modifiée ; ce stimulus est réceptionné par le capteur de position. Ce capteur et son arbitre sont activés au début de l instant suivant ; le capteur délivre alors au module comportemental un signal correspondant au stimulus interne envoyé. Le module peut alors de nouveau proposer une modification de la position Gestion du temps Le lancement d une phase de réaction de l agent déclenche une cascade de réactions au niveau des modules comportementaux. Ce déclenchement peut se faire selon trois stratégies : dès que l ensemble des actions de l instant courant ont été réalisées ; seulement lorsque des stimuli, internes ou externes, sont reçus ; selon un pas de temps de durée fixe. Dans le premier cas, la durée d un pas de réaction dépendra alors uniquement du temps nécessaire pour proposer et réaliser les actions. C est la stratégie qui permet de réagir continuellement et le plus rapidement à l environnement, avec une fréquence d échantillonnage irrégulière. Le deuxième cas correspond à une stratégie d activation par interruption (cf. section 4.4 du chapitre 4). Le dernier cas correspond a priori à une stratégie basée sur un échantillonnage périodique. Nous avons cependant choisi de le considérer plutôt comme un cas particulier d activation par interruption : il suffit d ajouter à l agent un attribut spécifique correspondant à une horloge interne, qui génère régulièrement des stimuli internes. Nous préférons une horloge locale à une horloge globale à tous les agents du monde, car nous souhaitons que chaque agent soit indépendant des autres et possède sa propre notion du temps. Comme dans le modèle réactif synchrone, nous supposons que la réaction d un module comportemental prend un temps négligeable par rapport à nos besoins. Quelle que soit la stratégie choisie, c est au concepteur de dimensionner correctement les temps d exécution des modules comportementaux afin de proposer une fréquence de déclenchement acceptable. Nous faisons l hypothèse que ce dimensionnement a été fait, nous ne proposons donc pas d introduire une entité chargée de la surveillance et de la préemption éventuelle des modules : nous privilégions le déterminisme par rapport au temps de réponse. Nous ne proposons pas pour le moment de gérer les tâches asynchrones. Comme pour ESTEREL, la gestion des tâches asynchrones devra de toute façon être laissée à la machine d exécution. En attendant, un module devant se dérouler sur le long terme devra être capable de réagir lorsque le système le demande. Soit les calculs nécessaires sont effectués suffisamment rapidement, soit le module en question propose des résultats approximatifs, affinés au cours des réactions suivantes. Le deuxième cas correspond à un fonctionnement dit anytime, c est-à-dire capable de donner des résultats à tout moment, même si ce ne sont pas les réponses ultimes au problème posé.

119 7.4. CHAÎNE DE RÉACTION Arbitrage et gestion des priorités Pour obtenir une fonction d arbitrage prenant en compte des préférences, il nous faut gérer des priorités entre les modules comportementaux. Nous avons choisi de distribuer la gestion des priorités au niveau des arbitres, plutôt que de la réaliser de façon globale à l agent. Un module comportemental pourra ainsi être prioritaire par rapport à un autre pour une action particulière, tout en étant moins prioritaire pour une autre action. Voici les quatre cas de figure de gestion des priorités à appliquer aux propositions faites à un capteur : 1. le capteur possède autant d entrées que de valeurs de priorité disponibles ; 2. le capteur possède autant d entrées qu il y a de modules autorisés à proposer des actions ; 3. la priorité du module est passée en paramètre des propositions ; 4. l identité du module est passée en paramètre des propositions. La figure 7.7 présente les chaînes de réaction correspondant à ces quatre cas pour un même exemple, dans lequel trois modules comportementaux (, et ) peuvent proposer des actions à un même effecteur. et ont la même valeur de priorité et est le module le plus prioritaire. C 1 C 1 C 2 p=1 p=2 E C 2 mc1 mc2 mc3 E C 3 C C 1 C 1 C 2 E action C 2 E action C 3 C 3 FIG. 7.7 Quatre solutions pour gérer les priorités. Dans les deux premiers cas, le nombre de valeurs de priorités ou le nombre de modules pouvant faire des propositions est figé à la conception du capteur. Ce type de solution ne profite évidemment pas des avantages de la dynamicité structurelle des agents INVIWO. La première solution rend en outre la manipulation des priorités relativement complexe, en particulier si l utilisateur a par ailleurs choisi un arbitrage à base de choix discrétisés comme dans l architecture DAMN : il faudra alors prévoir pour le capteur autant d entrées que de choix disponibles par valeur de priorité! Pour

120 120 CHAPITRE 7. LES MODULES COMPORTEMENTAUX les deux dernières solutions, il faut ajouter un paramètre à la proposition d une action, afin de n avoir plus qu une seule entrée nécessaire au capteur pour réceptionner les propositions. Avec les trois premières solutions, les modules eux-mêmes peuvent influer sur la gestion des priorités dynamiques, c est-à-dire des priorités dont les valeurs évoluent pour chaque module au cours de l exécution du réseau comportemental. Les modules peuvent influer soit par la possibilité de modifier les connexions avec le capteur, soit par le passage de paramètres, ce qui peut dans tous les cas entraîner des incohérences vis-à-vis du comportement global de l agent. Si l identité de chaque module est passée en paramètre, seul l arbitre gère les priorités entre modules, en fonction de leur identité. Dans ce cas, qu elles soient statiques ou dynamiques, absolues ou relatives, ces priorités ne risquent pas d introduire d incohérence, car l arbitre joue le rôle de superviseur des priorités pour l ensemble des modules comportementaux pouvant lui proposer des actions. Si cet arbitre possède des capacités d apprentissage, il pourra moduler ces priorités en observant les résultats de tous ces modules. Nous remarquerons que pour cette dernière solution, l identité du module émetteur peut devenir un paramètre «caché» des signaux, accessible en lecture seule, de la même façon qu un stimulus externe contient toujours l identifiant de l agent émetteur. Puisque les trois autres solutions ne nous semblent pas acceptables, nous proposons de forcer le format des signaux en ajoutant un paramètre contenant l identité du module émetteur. Cela nous permet de simplifier le type des valeurs transportées par les signaux, et la gestion des priorités devient ainsi transparente vis-à-vis des modules comportementaux qui proposent des actions. 7.5 Ordonnancement de l exécution des modules À chaque instant, il faut assurer une exécution cohérente des modules comportementaux d un agent. Il est pour cela nécessaire de définir une politique d ordonnancement de ces modules, de façon similaire au séquencement synchrone introduit par F. Boulanger dans le cadre des objets synchrones (cf. section 4.6.1, page 85). Cet ordonnancement garantit qu un module ne sera déclenché que lorsque toutes ses entrées ont été déterminées pour l instant donné, c est-à-dire après que tous les modules dont il dépend ont réagi. Cela nous permet de garantir le déterminisme d un réseau comportemental. Une fois l ordre d exécution déterminé, le gestionnaire des modules comportementaux peut déclencher la réaction de chacun des modules selon cet ordre. Nous proposons un algorithme permettant de déterminer une relation d ordre entre les modules par le parcours de leur graphe de dépendances. La figure 7.8 présente un exemple de système de modules, pour lequel cet algorithme d ordonnancement a défini trois phases d exécution. La figure 7.9 schématise le graphe de dépendances manipulé pour l exemple de la figure 7.8. Chaque module comportemental constitue un nœud du graphe de dépendances ; les arcs orientés correspondent aux canaux reliant les modules. Le graphe sur lequel travaille notre algorithme ne tient pas compte des capteurs et des effecteurs ; ils sont en effet inutiles pour le calcul de l ordre d exécution des modules, puisqu ils seront déclenchés respectivement avant et après l exécution de l ensemble des modules comportementaux.

121 7.5. ORDONNANCEMENT DE L EXÉCUTION DES MODULES 121 Capteurs rang = 0 rang = 1 rang = 2 Effecteurs C 1 C 2 C 3 C 4 C 5 C 6 FIG. 7.8 Exemple d ordonnancement de modules comportementaux. C 1 C 2 C 6 C 5 C 3 C 4 FIG. 7.9 Exemple de graphe de dépendances à parcourir. Le graphe construit à la création de l agent peut ensuite être modifié par l ajout ou le retrait d un nœud ou d un arc, c est-à-dire lorsqu un module ou un canal est ajouté ou retiré. Pour des raisons évidentes d efficacité, nous ne relançons pas l algorithme de calcul sur l ensemble du graphe à chaque modification ; nous proposons pour cela des algorithmes complémentaires en fonction du type d opération effectuée sur le graphe. L algorithme principal et les algorithmes complémentaires sont par ailleurs utilisés pour ordonnancer les sous-modules au niveau de chaque module-père Ordonnancement initial des modules comportementaux Notre algorithme d ordonnancement initial des modules est basé sur l algorithme de calcul de la fonction rang d un graphe orienté supposé sans circuit 2, présenté dans [70]. Cet algorithme est lui-même inspiré de l algorithme de R. Bellman consistant à calculer, pour chacun des nœuds du graphe, la longueur du plus court chemin depuis une source unique, connaissant l ensemble des prédécesseurs de chaque nœud. Pour calculer le plus long chemin, il suffit de prendre la longueur maximale calculée pour les prédécesseurs plutôt que la longueur minimale ; le rang d un nœud correspond à ce chemin le plus long, en considérant des arcs de poids 1. L algorithme donné pour le calcul des rangs est le suivant : 2 Un graphe orienté sans circuit ne contient aucun chemin orienté passant plus d une fois par un même nœud. Un cas particulier de circuit est la boucle, qui fait intervenir un seul nœud.

122 : : 122 CHAPITRE 7. LES MODULES COMPORTEMENTAUX. -. (a) - Poser (b) - Soit l ensemble des sommets tel que. - Pour tout, faire -! #" - pour tout $ %'& %)(+*. (c) - & ( et & -, *. Si. / 0, FIN, sinon aller en (b). L ensemble 1 correspond au graphe initial, et est l ensemble des sommets à traiter. L ensemble des successeurs d un nœud 2 est noté 354, l ensemble de ses prédécesseurs La cardinalité d un ensemble est noté 7 7 ; correspond donc au nombre de prédécesseurs du nœud 2. La notation 9 46 désigne normalement le degré inférieur du nœud 2, c est-à-dire le nombre de ses prédécesseurs. À partir de la séquence (b), qui va se répéter jusqu à ce qu il n y ait plus de nœuds à visiter, l algorithme travaille sur l ensemble.: des sommets qui n ont pas de prédécesseur. En fait, l algorithme modifie alors à chaque pas de boucle le degré inférieur de certains sommets, pour signifier que les prédécesseurs de ces sommets ont été traités : 9 46 correspond donc au degré inférieur du nœud 2 à l initialisation, mais il devient ensuite un compteur du nombre de prédécesseurs de 2 non encore visités. Grâce à ce compteur, il est possible de définir à chaque pas de boucle un ensemble de sommets dont tous les prédécesseurs ont été traités. Pour chaque élément de cet ensemble, il suffit de décrémenter d une unité les compteurs de tous ses successeurs, afin d obtenir un nouvel ensemble de nœuds de degré inférieur nul. Cet algorithme permet de calculer pour chaque sommet 2<; son rang, noté =?>#2A@. Nous obtenons alors des ensembles appelés niveaux, contenant tous les nœuds de même rang B. Cet algorithme s applique à des graphes orientés sans circuit. Si la représentation permet de connaître efficacement l ensemble des successeurs et des prédécesseurs de chaque nœud, la complexité de l algorithme est en C>D@, avec le nombre d arcs du graphe. Dans notre cas, le parcours du graphe permet de calculer un rang pour chaque module afin d obtenir l ordre de déclenchement des modules. Les modules qui ne possèdent pas d entrée 3 ou qui sont seulement connectés à des capteurs sont de rang nul, ils seront donc les premiers à être déclenchés. Dans le cas des sous-modules, un module a un rang nul s il ne possède pas d entrée ou s il est uniquement connecté à des entrées (non locales) du module-père. Le graphe de dépendances ne doit pas contenir de circuit, car un module ne peut pas nécessiter d être exécuté à la fois avant et après un module donné au cours d un même instant 4. Nous ne pouvons pas simplement supposer que le graphe est sans circuit, car un circuit non détecté pourrait se révéler problématique à l exécution. Nous avons donc adapté l algorithme de calcul des rangs à nos besoins, afin de détecter d éventuels circuits pendant le parcours du graphe. Voici notre version de l algorithme de calcul initial des rangs, étant l ensemble des modules de rang B : 3 Un module qui ne possède pas d entrée réagit uniquement au signal prédéfini Tick, correspondant à l horloge de réaction. 4 Nous verrons en section (page 127) comment nous avons choisi de gérer les cas où les circuits avec retards sont indispensables (cf. la section concernant les réseaux d objets synchrones, page 85).

123 & 7.5. ORDONNANCEMENT DE L EXÉCUTION DES MODULES 123 Lancement du calcul des rangs : - = ensemble des modules comportementaux - = ensemble des modules comportementaux sans prédécesseur - calcul des rangs (0, ) Calcul des rangs (, ) : - & - Pour tout : -! " - Pour tout : // Successeurs de m - & ( * - Si Alors, - Si Alors - Si Alors ERREUR : circuit détecté Sinon FIN Sinon - & ( - calcul des rangs (, *, : Un circuit est détecté dans le cas où l ensemble construit est vide, alors qu il reste des nœuds à visiter. En effet, un nœud appartenant à un circuit possède toujours au moins un prédécesseur, ce qui rend impossible la réduction à 0 du degré inférieur de ce nœud 5. L algorithme ne permet pas de déterminer directement quels nœuds appartiennent au circuit détecté, mais nous pouvons au moins en déduire que ces nœuds sont successeurs du nœud en cours de traitement. Un algorithme spécifique pourra être utilisé au besoin pour extraire rapidement le circuit à partir de 3 6. Cela ne nous semble pas indispensable pour le moment, car la détection de circuit n est pour nous qu une sécurité qui n aura d effet que dans de rares cas d erreur de la part du concepteur. La complexité de cet algorithme est aussi en C>D@, à condition que la structure de données représentant un module comportemental contienne les champs suivants : le rang, le compteur de prédécesseurs non visités, la liste des successeurs : et la liste des prédécesseurs du module. La construction de l ensemble est faite dès que possible, ce qui rend cet algorithme un peu plus efficace en pratique Ajout d un canal L ajout d un canal entre un module et un module est susceptible de faire augmenter le rang du module, ainsi que le rang de ses descendants. Dans ce cas, les rangs doivent absolument être recalculés, afin que le système de modules conserve un comportement déterministe. Pour obtenir la figure 7.10, nous avons ajouté à l exemple de la figure 7.8 un canal reliant le module au module!. Les zones grisées entourent les modules pour lesquels les rangs doivent être recalculés. Le calcul des rangs pour ces modules a pour conséquence l ajout d une quatrième phase d exécution à l ordonnancement précédemment défini. 5 Pour qu un nœud soit visité, il faut que tous ses prédécesseurs aient été visités, et ceci récursivement. Dans un circuit, les nœuds interdépendants ne pourront jamais être visités ; dans le cas d une boucle en particulier, le nœud concerné ne pourra jamais être traité puisqu il est à la fois son propre successeur et son propre prédécesseur. )

124 124 CHAPITRE 7. LES MODULES COMPORTEMENTAUX Capteurs Effecteurs Capteurs rang = 0 rang = 1 rang = 2 rang = 3 Effecteurs C 1 C 2 C 1 C 2 C 3 C 4 C 3 C 4 C 5 C 6 C 5 C 6 FIG Ajout d un canal et repartitionnement du graphe. L ajout du canal modifie le rang de uniquement si ce rang était auparavant inférieur ou égal à celui de. Puisque nous savons que dépend maintenant directement de, il suffit d ajouter 1 au rang de pour obtenir le rang de. Il faudra mettre à jour selon la même méthode les rangs de tous les descendants de, c est-à-dire les rangs de tous les modules dépendant directement ou indirectement de. Voici l algorithme que nous proposons pour réaliser cette mise à jour, étant le module à partir duquel il faut récursivement calculer les rangs et 4 2 étant le module à partir duquel l algorithme à été lancé initialement : Lancement de la mise à jour : - Si! "! " Alors - affecter le rang (! ", *, ) - recalculer les rangs (, ) Affecter le rang (, ) : - & ( // Retrait de l ancien niveau -! " & - &, // Ajout au nouveau niveau Recalculer les rangs (, ) : - Pour tout : - Si Alors ERREUR : circuit détecté Sinon - affecter le rang (! ", *, ) - recalculer les rangs (, ) Un circuit peut être introduit à l ajout d un canal, nous avons donc choisi de comparer systématiquement les successeurs d un nœud à afin de détecter un nouveau circuit. La complexité de cet algorithme est en étant le nombre de nœuds descendants du module. Notons que nous ne tenons pas compte du fait que plusieurs arcs peuvent relier les mêmes nœuds, dans la même direction 6, car nous pensons que ce type de connexions multiples est minoritaire. Il serait probablement globalement moins efficace de travailler sur des listes de prédécesseurs sans doublon, car l ajout dans une liste sans doublon (non triée) de taille est de complexité en 6 Un module peut posséder plusieurs canaux de communication en sortie aboutissant à un même module.

125 7.5. ORDONNANCEMENT DE L EXÉCUTION DES MODULES Ajout d un module comportemental Comme l ajout d un canal, l ajout d un module au graphe nécessite de recalculer les rangs de chaque module lié en sortie au module. Nous considérons ici l ajout d un module comportemental, ainsi que de l ensemble de ses canaux d entrée et de sortie. Il serait en effet complètement inefficace d utiliser l algorithme précédent pour chaque nouveau canal introduit. Dans l exemple de la figure 7.11, nous avons ajouté un module comportemental, avec un canal en entrée relié au module et un canal en sortie relié au module. Capteurs C7 Effecteurs Capteurs rang = 0 rang = 1 rang = 2 rang = 3 Effecteurs C 1 C 2 C 2 C 1 C 7 C 3 C 4 C 3 C 4 C 5 C 6 C 5 C 6 FIG Ajout d un module comportemental et repartitionnement du graphe. Le rang du nouveau module est calculé à partir du rang maximal de ses prédécesseurs. Il faut ensuite appliquer l algorithme de calcul des rangs à tous les descendants de. Nous réutilisons donc l algorithme précédent comme suit : Lancement de la mise à jour : -! " &! ", * - &, - recalculer les rangs (, ) Retrait d un canal La destruction d un canal peut nécessiter de recalculer le rang du module, ainsi que les rangs de tous ses descendants. Dans l exemple de la figure 7.12, nous avons retiré le canal reliant le module! au module. Nous utilisons pratiquement la même méthode de mise à jour des rangs que pour l ajout d un canal. Il devient cependant inutile de vérifier l apparition d un éventuel circuit, mais il sera parfois nécessaire d insérer de nouveaux modules dans l ensemble des modules de rang nul. Voici la mise à jour des rangs, étant le module auparavant connecté à la sortie du canal retiré du graphe :

126 126 CHAPITRE 7. LES MODULES COMPORTEMENTAUX Capteurs Effecteurs Capteurs Effecteurs rang = 0 rang = 1 rang = 2 rang = 3 C2 C2 C1 C 7 C1 C 7 C3 C4 C3 C4 C 5 C 6 C 5 C 6 FIG Retrait d un canal et repartitionnement du graphe. Lancement de la mise à jour : - mise à jour ( ) Mise à jour ( ): - Si Alors & Sinon &! ", *! " Alors - affecter le rang (, ) - recalculer les rangs ( ) - Si Recalculer les rangs ( ) : - Pour tout : - affecter le rang (! ", *, ) - recalculer les rangs ( ) Il est en particulier utile de recalculer les rangs du module et de ses descendants dans le cas d un graphe fortement dynamique, afin d optimiser les calculs à venir. Il est tout à fait envisageable de ne lancer un tel calcul que de temps à autres, plutôt qu à chaque retrait de canal ou de module Retrait d un module comportemental Dans l exemple de la figure 7.13, nous avons retiré le module, ainsi que son canal en entrée relié à et ses canaux en sortie reliés à et. Cette opération a pour conséquence de retirer à son unique entrée reliée à un module comportemental, son rang passe donc à 0. re- Le calcul des rangs utilise la mise à jour précédente, appliquée au module tiré : Lancement de la mise à jour : - Pour tout : - mise à jour ( )

127 7.5. ORDONNANCEMENT DE L EXÉCUTION DES MODULES 127 Capteurs Effecteurs Capteurs rang = 0 rang = 1 rang = 2 Effecteurs C 2 C 2 C 1 C 7 C 1 C 7 C 3 C 4 C 4 C 5 C 6 C 5 C 6 FIG Retrait d un module comportemental et repartitionnement du graphe Circuits, retards et problèmes de causalité Cas d un circuit dans une chaîne de réaction Un utilisateur peut avoir besoin de définir un système de modules comportementaux contenant des circuits. Par exemple, le module reçoit un signal du module ; il doit effectuer instantanément un calcul, puis fournir le résultat au module. Dans le cadre des objets synchrones, ce type d application nécessite d insérer un objet retard dans le circuit. Nous avons d abord pensé reprendre cette idée en introduisant un module spécifique qui se comporterait comme un objet retard en conservant le signal reçu jusqu à l instant suivant. Cette solution pose cependant le problème évident du typage de l entrée et de la sortie du module retard. Il ne nous semble pas acceptable d avoir à demander à l utilisateur de définir lui-même systématiquement un module en fonction du type de signal à retarder. Nous proposons plutôt d introduire un type de canal particulier, appelé canal retard, qui conserve n importe quel type de signal jusqu à l instant suivant. Ce canal ne sera pas pris en compte dans le calcul de l ordonnancement car il ne crée pas de nouvelle dépendance instantanée. Gestion de la communication père-fils Au cours d un instant, un père est théoriquement exécuté en parallèle avec le sousréseau de ses fils, ce qui signifie que les sous-modules ne dépendent pas du père pour le calcul de l ordonnancement. Cette caractéristique pose un problème lorsque le modulepère définit des entrées et des sorties locales afin de communiquer avec ses fils. Avant que la réaction d un module puisse être déclenchée, il faut en effet que les entrées de ce module soient complètement instanciées. Or une entrée locale crée une dépendance entre le module-fils émetteur et le module-père (destinataire) et une sortie locale crée une dépendance entre le père (émetteur) et le fils destinataire. Il faudrait donc prendre en compte ces nouvelles dépendances pour l ordonnancement. Il devient par ailleurs facile de créer des circuits instantanés en connectant un père et ses fils par des entrées et des sorties locales. Il ne nous paraît pas raisonnable de demander au concepteur de penser à introduire au besoin des canaux retards. Nous avons donc choisi d imposer que le module-père s exécute avant ses fils. Cette solution paraît naturelle, puisque c est le père qui contrôle l exécution de ses fils : en laissant le père s exécuter en premier au cours d un instant,

128 128 CHAPITRE 7. LES MODULES COMPORTEMENTAUX il devient plus facile de gérer correctement les cascades de déclenchements et d avortements instantanés de sous-modules. Dans ce cas, la communication père-fils devient instantanée. Par contre, la communication d un fils vers son père doit être systématiquement retardée, puisque le père a déjà réagi lorsque le fils émet un signal à son attention. La façon la plus simple d intégrer cette contrainte est d imposer qu une entrée locale soit retardée. Cette solution simplifie par ailleurs le séquencement synchrone, puisqu il suffit d ordonnancer le réseau de sous-modules indépendamment du père. Éviter les problèmes de causalité Voici un exemple classique de cycle de causalité en ESTEREL, utilisant un signal en entrée/sortie : present I else emit I end present Cet exemple signifie que si le signal I est absent, alors il faut l émettre ; puisque le signal est présent dès son émission, il sera à la fois absent et présent au cours du même instant, ce qui est évidemment incorrect. Notre modèle distingue nettement les entrées des sorties, et un module ne peut réagir qu une seule fois par instant, en fonction de l état de ses entrées au début de l instant ; il n est donc pas possible de définir l exemple ci-dessus tel quel. Par contre, une version équivalente consisterait à relier une sortie d un module à une entrée de ce même module ; un tel circuit serait alors détecté au moment de l ordonnancement des modules comportementaux, c est-à-dire juste avant de relancer une vague de réactions. Les interconnexions d un réseau comportemental pouvant être modifiées dynamiquement, la détection des problèmes de causalité doit être faite à l exécution. Nous n avons par ailleurs pas de problème de causalité avec les signaux locaux, puisque nous imposons que le père soit déclenché avant ses fils au cours de l instant : la communication père-fils est instantanée, et la communication fils-père est systématiquement retardée grâce au statut particulier d une entrée locale au père. 7.6 Synthèse Nous avons défini une architecture de sélection de l action distribuée, basée sur le modèle synchrone. Cette architecture nous semble adaptée à la description graphique de comportements, dans le cadre d un outil manipulant des boîtes noires avec une interface figée, interconnectées par des liens typés et orientés (des sorties vers les entrées des boîtes). Les boîtes représentant des capteurs n ont pas d entrée et celles représentant les effecteurs n ont pas de sortie. Il est de plus possible de décrire récursivement un module à partir de sous-modules ; cela permet en particulier d encapsuler un réseau comportemental complet dans un module sans introduire de retard, ce qui facilite à la fois la construction d un comportement d agent et sa maintenance. La distribution des décisions nécessite de concevoir proprement un agent, en suivant quelques règles élémentaires : il ne faut pas que plusieurs effecteurs puissent agir sur un même composant de l agent (ou sur un même ensemble de composants pour les effecteurs chargés de la structure dynamique), car cela risquerait de rendre l état interne de l agent incohérent ;

129 7.6. SYNTHÈSE 129 de même, il ne faut pas laisser plusieurs capteurs mettre à jour les mêmes attributs pendant la phase de perception, afin de conserver la cohérence des valeurs mémorisées ; il ne faut pas que plusieurs effecteurs puissent émettre les mêmes types de stimuli externes ou utilisateurs, car cela pourrait rendre incohérentes les communications entre agents ou entre un avatar et son utilisateur ; il faut être particulièrement attentif aux problèmes d émission et de réception multiples ; il faut sérieusement étudier l opportunité de l utilisation de sous-modules communiquant avec leur père, lorsque le retard imposé par la communication d un fils vers son père est indésirable. Un agent et un module comportemental réagissent tous deux à des événements en générant d autres événements ; il existe cependant entre ces deux types d entités des différences importantes, dont voici les principales : la structure d un agent est dynamique alors que la structure d un module comportemental est statique : son corps peut être remplacé mais son interface est figée ; un module comportemental a accès (en lecture) aux attributs de l agent auquel il appartient. Il n existe par contre pas d attributs propres à l environnement, qui seraient partagés par les agents d un même monde ; un module comportemental peut être créé à partir d un ensemble de sous-modules interconnectés, alors qu un agent ne peut pas être construit à partir d autres agents. En fait, la piste d agents composés de sous-agents a été évoquée puis rapidement abandonnée à cause de la complexité de mise en œuvre de la communication entre un agent-père et des agents-fils ; un agent évolue à son rythme dans un environnement asynchrone sans horloge globale, alors qu un module comportemental est intégré dans un réseau de modules synchrones partageant la même notion d instant ; les agents communiquent par des messages qui peuvent être envoyés à un destinataire précis ou à l ensemble des agents présents dans le monde. Un module comportemental ne fait qu émettre un signal sur une sortie, seuls les modules connectés explicitement à cette sortie pouvant recevoir ce signal. Bien que nous ayons choisi de nous différencier sur certains points du modèle d ESTEREL, nous respectons les hypothèses du modèle synchrone. Un instant est global à l ensemble des modules comportementaux, donc l émission d un signal est instantanée. Il s agit bien de communication synchrone entre les modules, comme dans le cas des réseaux d objets synchrones par exemple. Grâce au séquencement synchrone, les signaux en entrée sont correctement initialisés pour chaque module avant le déclenchement de sa réaction. Pour que les réactions soient atomiques, le gestionnaire de modules n interrompt jamais une réaction en cours. Bien que nos signaux ne correspondent pas exactement à la notion de signaux en ESTEREL, nous avons choisi de conserver ce terme afin distinguer clairement la communication synchrone entre les modules comportementaux d un agent et la communication asynchrone entre agents, réalisée par les stimuli externes. Comparons maintenant un agent avec un système synchrone s exécutant dans un environnement asynchrone. Les capteurs reçoivent des stimuli externes en provenance

130 130 CHAPITRE 7. LES MODULES COMPORTEMENTAUX de l environnement asynchrone de l agent. Ces stimuli sont traduits en signaux pour être transmis aux modules comportementaux formant un système synchrone. Les propositions d actions sont reçues sous la forme de signaux par les capteurs, dont les arbitres sélectionnent les actions à réaliser dans l environnement asynchrone de l agent. Les capteurs avec leurs filtres et les effecteurs avec leurs arbitres correspondent donc aux objets d interface des réseaux d objets synchrones, aux entrées et sorties des réseaux de processus réactifs ou, tout simplement, aux mécanismes d interfaçage d un module ESTEREL avec son environnement. Nous pouvons donc considérer un agent comme étant la machine d exécution d un réseau comportemental, cette machine prenant de plus en compte les événements internes à l agent. En mélangeant notre modèle d agent INVIWO (figure 5.8 page 98) avec le schéma général d une machine d exécution pour module ESTEREL (figure 4.18 page 81), nous obtenons la figure Agent Stimuli internes Environnement de l agent Attributs Stimuli externes lecture modification Stimuli externes Capteurs Filtres Arbitres Effecteurs Signaux Signaux en sortie FIG L agent comme machine d exécution d un réseau comportemental. À la différence des processus réactifs, des objets synchrones et des modules ES- TEREL, nos modules comportementaux ont par ailleurs accès à une mémoire partagée, constituée des attributs de l agent. Ces attributs ne leur sont accessibles qu en lecture et la modification est faite uniquement à la fin d un instant. D autre part, les stimuli internes, générés en fin de réaction, sont traités exactement comme les stimuli externes par les capteurs et les filtres. L environnement complet d un module, composé des valeurs de ses entrées et des attributs de l agent, n est ainsi jamais modifié au cours d un instant, ce qui nous permet de respecter le modèle synchrone et donc de garantir le déterminisme du comportement de l agent. Il est probable qu un agent reçoive des stimuli du même type en provenance de plusieurs autres agents, il faut donc que les capteurs soient capables de prendre en compte la réception multiple de stimuli, comparable à la réception multiple de signaux. Les agents d un monde INVIWO évoluent à leur propre rythme (de façon asynchrone), il est donc aussi possible qu un agent reçoive plusieurs stimuli du même type en provenance d un même agent plus rapide que lui, ces stimuli n étant pris en compte qu à

131 7.6. SYNTHÈSE 131 partir du début de la réaction suivante. Il faut donc en plus que les capteurs puissent traiter correctement l arrivée «simultanée» de stimuli du même type en provenance du même agent. Nous verrons dans le chapitre suivant comment gérer ces différents cas de réception multiple de stimuli dans le langage MARVIN.

132 132 CHAPITRE 7. LES MODULES COMPORTEMENTAUX

133 Chapitre 8 Le langage MARVIN «La vie, observa lugubrement Marvin, qu on la déteste ou qu on l ignore : oui. Mais on ne peut pas l aimer.» Extrait du premier tome de la trilogie en cinq volumes (sic) du «Guide du Routard Galactique», formidable œuvre du regretté Douglas N. ADAMS ( ) grâce à qui nous savons maintenant que la réponse est Introduction Le langage MARVIN a été défini pour faciliter la description de comportements d agents virtuels autonomes. Nous avons comme objectif que ce langage soit accessible à un large public tout en permettant de décrire des comportements variés et déterministes. Il nous paraît naturel de définir le comportement d un agent réactif à partir de règles associant une attente d événement à une séquence d actions. Une simple base de règles n est pas suffisante pour décrire un comportement complexe, ni acceptable en terme de maintenance. Il nous semble en effet souhaitable de pouvoir regrouper les règles dans des blocs, mais aussi de pouvoir utiliser des structures de contrôle de haut-niveau pour activer et désactiver les règles à volonté, ou encore de pouvoir définir des règles pouvant se déclencher simultanément. Nous proposons pour cela un langage complet, fortement inspiré d ESTEREL mais adapté à nos besoins, permettant en particulier de décrire aisément des blocs de règles réactives parallèles. Pour décrire des agents et leur comportement, il convient tout d abord de distinguer deux aspects : il faut d une part définir les structures de données manipulées par les agents et d autre part décrire la façon dont les agents devront réagir aux événements internes et externes. Nous avons pour cela défini un langage à la fois orienté-objets et «orienté-agents» : la partie orientée-objets du langage permet de définir les objets manipulés par un agent et ses composants, ainsi que les données échangées par les agents ; la partie orientée-agents du langage permet de décrire un agent et ses composants, en particulier les modules comportementaux. 133

134 134 CHAPITRE 8. LE LANGAGE MARVIN Dans ce chapitre, nous nous intéresserons plus spécifiquement à la partie orientéeagents du langage MARVIN, nous décrirons donc seulement quelques caractéristiques orientées-objets nécessaires à la compréhension des mécanismes d instanciation et d héritage. Nous étudierons en détail la description des modules comportementaux, des capteurs et des effecteurs ; nous verrons que ces trois types de composants sont définis de façon homogène, principalement à partir de règles réactives. Puis nous nous intéresserons à la définition et à la gestion des sous-modules comportementaux. Nous montrerons ensuite comment décrire un agent et un avatar partir de composants déjà définis ; nous montrerons enfin comment décrire un monde INVIWO, avant de terminer sur une synthèse nous permettant de récapituler les caractéristiques du langage. 8.2 Agents et objets Comparaison Dans les langages orientés-objets, un objet est traditionnellement une entité passive, qui n effectue un traitement que lorsqu une de ses méthodes est invoquée. Le traitement en question a pour conséquence de modifier l état de l objet c est-à-dire les valeurs de ses champs, d invoquer d autres méthodes de l objet ou encore d invoquer des méthodes d autres objets. Bien qu historiquement considérée comme un envoi de message, l invocation de méthode correspond à une communication synchrone, dans le sens où l appelant est bloqué en attente du retour de la méthode. Contrairement à un objet, un agent est une entité active et autonome, qui s exécute indépendamment (en parallèle) des autres agents. Un envoi de message correspond à une communication asynchrone : après avoir envoyé le message, l émetteur peut continuer de s exécuter en attendant le résultat de la requête ; du côté du destinataire, le message peut être stocké en attendant de pouvoir être traité, il peut également être ignoré. Un objet en MARVIN est un objet classique. Un agent INVIWO est un objet MAR- VIN spécial, possédant des méthodes protégées qu il est le seul à pouvoir invoquer ; seuls les constructeurs, qui sont des méthodes particulières, peuvent être appelées par d autres objets. Cette limitation de la visibilité des méthodes permet de conserver une véritable autonomie des agents. Les méthodes d un agent, en particulier les méthodes prédéfinies de manipulation des composants, ne peuvent ainsi pas être invoquées par les autres agents, le seul mode de communication autorisé entre agents étant l échange de stimuli externes. Ces méthodes ne peuvent pas non plus être invoquées par les composants de l agent, de façon à centraliser les capacités de modification de la structure et de l état interne au niveau de l agent ; les primitives d action des effecteurs font implicitement appel à ces capacités. Les agents décrits en MARVIN ne sont pas seulement des objets possédant une méthode particulière s exécutant en permanence, comme c est le cas dans la plupart des bibliothèques de programmation d agents basés sur des langages orientés-objets. Les agents sont pour nous des entités spécifiques, en partie manipulables comme des objets mais possédant des propriétés supplémentaires : un agent est constitué de composants, en particulier d un ensemble de modules comportementaux formant un système réactif synchrone. La partie orientée-objets de MARVIN n est pas encore clairement définie car nous

135 8.2. AGENTS ET OBJETS 135 nous sommes concentrés sur la description des modules comportementaux. Il reste donc à faire des choix, concernant en particulier les mécanismes d héritage et de clonage, les règles de visibilité des éléments constitutifs des objets et des agents, la politique de portée et de masquage des variables ou encore la mise en œuvre des constructeurs d objets. Cette partie du langage est actuellement inspirée de PYTHON, un langage de script orienté-objets basé sur des classes [121, 120]. C est un langage de hautniveau, modulaire, dynamique et interprété (ou compilé dans un byte-code spécifique) ; il est facile à utiliser et à apprendre, en partie grâce aux types de haut-niveau prédéfinis tels que les listes et les dictionnaires. Il permet de réaliser efficacement du prototypage d applications, entre autres grâce aux nombreuses bibliothèques disponibles et aux multiples connexions (bindings) réalisées avec d autres langages comme C ou JAVA Objets prédéfinis Objets de base Toutes les données sont représentées par des objets, comme en PYTHON. Un objet (de classe object) est défini par un ensemble de champs et de méthodes, une méthode (method) étant elle-même un objet. Les types de base manipulés sont les entiers (int), les réels à virgule flottante (float), les booléens (bool), les chaînes de caractères (string) et les fonctions (function). Les conteneurs prédéfinis sont les listes (list), les dictionnaires (dict) et les n-uplets (tuple). Les listes et les dictionnaires sont des objets mutables ; les n-uplets des objets non-mutables, très utiles pour renvoyer plusieurs valeurs en résultat d une fonction. De nombreux types d identifiants sont prédéfinis, dérivant tous de id. Citons notamment les identifiants d agents (agent_id) et d utilisateurs (user_id), ainsi que les identifiants d objets (object_id). D autres objets prédéfinis permettent de manipuler les canaux (channel) et les canaux-retards (delayed_channel), ainsi que les différentes catégories de stimuli (stim), à savoir les stimuli internes (istim), externes (estim) et utilisateurs (ustim). Agents et composants Les mondes (world), les agents (agent), les attributs (attribute), les modules comportementaux (behaviour), les capteurs (sensor) et les effecteurs (effector) sont des objets prédéfinis particuliers, détaillés dans la suite de ce chapitre. Les capteurs et les effecteurs contiennent respectivement des objets filtres (filter) et arbitres (arbiter), définis de façon similaire aux corps des modules comportementaux (body). L agent gère un ensemble de dictionnaires, regroupant les différents composants étiquetés par leur identifiant. Il est possible d accéder en lecture aux dictionnaires correspondant à tous les composants (components), aux attributs (attributes), aux capteurs (sensors), aux effecteurs (effectors) et aux modules comportementaux (behaviours). Par contre, seul l agent peut effectuer les modifications de ces données (ajout, retrait ou modification d un composant).

136 136 CHAPITRE 8. LE LANGAGE MARVIN Méthodes classiques et réactives Les méthodes sont des fonctions attachées à un objet ; l objet propriétaire est désigné par le mot-clé self. Dans le cas d une dérivation, il est possible d utiliser les méthodes de la super-classe grâce au mot-clé super. Les méthodes classiques ne peuvent pas utiliser les primitives réactives ; ces primitives correspondent par exemple à l émission ou à l attente d un signal, à l envoi ou à la réception d un stimulus, ou encore à une modification de la valeur d un attribut. Dans le cas des modules comportementaux, des capteurs et des effecteurs, nous proposons d utiliser des méthodes réactives (rmethod), capables d utiliser ces primitives réactives. Les méthodes réactives permettent de décrire de façon modulaire les composantes réactives d un agent ; elles sont héritées lors d une dérivation et peuvent être surchargées ou redéfinies, comme n importe quelle autre méthode. 8.3 Les modules comportementaux La définition d un module comportemental en MARVIN ressemble à la définition d un module ESTEREL, composé d une interface et d un corps. Le corps d un module comportemental est délimité par la construction body...end body. L interface permet de définir les signaux en entrée et en sortie. Entre l interface et le corps, il est possible de définir les variables globales au module et les méthodes classiques ou réactives nécessaires, ainsi que les constructeurs. Les méthodes et les variables sont protégées, c est-à-dire inaccessibles en dehors du module. Voici un premier exemple de module comportemental émettant les signaux O1 et O2 à chaque instant : behaviour b out O1, O2 ; body loop wait Tick -> [ emit O1 ; emit O2 ] end wait end loop end body end behaviour Ce module définit une unique règle réactive incluse dans une boucle infinie 1. Cette règle attend le signal prédéfini Tick, correspondant au tick d ESTEREL, pour émettre les signaux O1 et O2. Contrairement à ESTEREL, MARVIN permet de modifier dynamiquement certains éléments du programme, en particulier le corps d un module comportemental. Les lignes de code MARVIN suivantes montrent comment remplacer le corps du module b par un autre bloc réactif, qui n a pas la même sémantique mais qui produira exactement le même effet dans ce cas précis : 1 Pour éviter qu une boucle instantanée non détectée à la compilation ou à l interprétation ne bloque le comportement de l agent, il faudra la détecter à l exécution, par exemple en remarquant qu il est anormal de rencontrer plus d une fois le end loop au cours d un même instant.

137 8.3. LES MODULES COMPORTEMENTAUX 137 b.body <- loop wait Tick -> [ emit O1 ] end wait ; emit O2 end loop La syntaxe de MARVIN est visiblement proche de celle d ESTEREL. Nous utilisons en particulier le point-virgule ( ;) de la même façon, pour marquer à la fois la séquence et la fin d une déclaration de variable globale ou de signal. Dans notre modèle, la déclaration de variable (globale au module ou locale au corps de ce module) se fait en utilisant le mot-clé var et ne nécessite pas de préciser le type de la variable. Le pointvirgule est inutile après la fin d une section ; par exemple, si un point-virgule est placé après end behaviour, il sera simplement ignoré. Notons que les crochets entourant l émission du signal O1 ne sont pas indispensables, mais ils facilitent la lecture en délimitant l action associée à la règle réactive. MARVIN permet aussi d hériter des caractéristiques d un module comportemental, d étendre la définition et de redéfinir certaines caractéristiques, comme cela est possible pour n importe quel autre objet. L exemple suivant présente le module comportemental b2, dérivant de b défini précédemment ; b2 hérite de l interface et du corps de b, ajoute les signaux I1 et I2 en entrée et redéfinit le corps : behaviour b2 inherits b in I1, I2 ; body loop wait I1 -> [ emit O1 ] end wait ; wait I2 -> [ emit O2 ] end wait end loop end body end behaviour Les règles réactives Les règles réactives sont composées d une partie déclencheur (partie gauche) et d une partie action (partie droite). La partie action est constituée d une séquence d actions élémentaires, réactives ou non (émission de signal, affectation de variable, appel de méthode, etc.) : wait I -> [ emit O ] end wait L instruction wait de MARVIN correspond à l instruction await d ESTEREL. Les règles réactives sont donc systématiquement retardées et ne pourront être déclenchées qu à l instant suivant leur rencontre. Il est cependant possible de tester la présence d un signal avec l alternative réactive (construction present), équivalente à celle d ESTEREL mais réservée au test du statut d un signal en entrée. Nous pouvons ainsi reproduire le comportement de la composition await immediate d ESTEREL sur la règle définie précédemment, de façon à prendre en compte le signal I dès le premier instant :

138 138 CHAPITRE 8. LE LANGAGE MARVIN present I then emit O else wait I -> [ emit O ] end wait end present La partie action d une règle réactive peut éventuellement contenir à son tour une ou plusieurs règles, comme dans l exemple suivant : wait I -> emit O1 ; wait I -> [ emit O2 ] end wait end wait L obligation de terminer la règle par un end wait peut paraître lourde à utiliser, mais elle permet d une part de décrire une séquence dans la partie action sans avoir à l entourer de crochets, d autre part de rester homogène avec la définition d un bloc de règles que nous verrons dans la section suivante. Si aucune action n est associée à l attente d un signal, il faut utiliser une version abrégée de l instruction wait : wait I end wait La partie déclencheur d une règle est soit une expression de signaux, soit une expression de signaux associée à une garde. Comme en ESTEREL, une expression de signaux correspond à une expression booléenne portant sur le statut des signaux attendus pour déclencher la règle. Cette expression peut utiliser les opérations booléennes prédéfinies not, and, or et xor, l opérateur not permettant de tester l absence d un signal en entrée. Une garde correspond à une expression booléenne portant sur des valeurs. Le test du déclencheur d une règle se fait uniquement au début de l instant, puisque le statut des signaux est déterminé dès le début de la réaction et ne changera pas au cours de l instant. Cela signifie en particulier que le test de la garde d une règle se fait sur les valeurs au début de l instant des variables concernées ; il faut donc utiliser avec précaution les variables, locales comme globales, dans les gardes. L exemple suivant fait intervenir une variable n (globale au module ou locale à la séquence) et définit une garde portant sur cette variable : var n <- 0 ;... wait I with [ n < 10 ] -> [ emit O ] end wait ;... L équivalent en ESTEREL nécessite l utilisation d une boucle infinie, incluse dans un bloc d exception :

139 8.3. LES MODULES COMPORTEMENTAUX 139 % Équivalent Esterel var n := 0 : integer in... trap T in loop await I ; if n < 10 then [ emit O ; exit T ] end if end loop end trap... end var De la même façon que le mot-clé self désigne l objet propriétaire d une méthode, le mot-clé owner désigne l agent propriétaire d un module comportemental. Ce motclé est utilisé dans le corps ou dans les méthodes réactives d un module, principalement pour lire la valeur d un attribut de l agent. Notons que pour des objets classiques, l opérateur point (.) sert à récupérer la référence de l objet, afin de manipuler directement cet objet. Nous ne pouvons pas laisser n importe quel composant modifier les attributs de l agent, c est pourquoi le point, lorsqu il est utilisé avec le mot-clé owner, permet de récupérer une copie de la valeur courante d un attribut ; cette copie est modifiable à volonté, mais cette manipulation n aura aucun effet sur l attribut lui-même. Puisqu il est possible de lire la valeur d un attribut, une garde peut faire intervenir cette valeur : wait I with [ n < owner.threshold ] -> [ emit O ] end wait À la différence d ESTEREL, nous ne proposons pas la possibilité de manipuler directement les signaux à partir de leur nom. Pour connaître l identifiant de l émetteur, que ce soit un module comportemental ou un capteur, il faut utiliser le mot-clé from définissant une variable qui sera automatiquement affectée à la valeur de l identifiant. L exemple suivant montre comment récupérer l identifiant de l émetteur du signal I : wait I from id -> [ emit Received (id) ] end wait Le mot-clé from peut aussi être utilisé dans un filtre pour des stimuli ou dans un arbitre pour des signaux, mais cette solution est fortement déconseillée à cause du risque de réception multiple. Dans le cas de réception multiple, nous verrons en section comment récupérer les identifiants de tous les émetteurs Les blocs de règles réactives Un bloc de règles réactives permet d attendre plusieurs signaux en même temps, ces signaux étant associés à des actions différentes. Si plusieurs règles sont sélectionnées au même instant, toutes les actions associées sont exécutées. Bien que les séquences d actions associées aux règles soient exécutées de façon atomique, il faut manipuler avec prudence les données partagées par des règles parallèles (variables globales à un module, variables locales à un bloc, attributs modifiés dans un effecteur). Le bloc de règles se termine instantanément dès que toutes les actions déclenchées sont terminées (ce qui peut durer plusieurs instants). Voici un premier exemple de module comportant un bloc de règles :

140 140 CHAPITRE 8. LE LANGAGE MARVIN behaviour b3 in I1, I2 ; out O1, O2 ; body wait I1 -> emit O1 I2 -> emit O2 end wait end body end behaviour Dans cet exemple, le module comportemental attend à la fois les signaux I1 et I2. Tant qu aucun de ces signaux n est reçu, le bloc reste actif. Dès que l une des deux règles est activée, l action associée est réalisée et le bloc se termine. Si les deux règles sont déclenchées simultanément, les deux signaux O1 et O2 sont émis instantanément puis le bloc se termine. Le corps du module ne comportant pas de boucle, il se termine à son tour instantanément et le module comportemental devient inactif. Voici le module ESTEREL équivalent à notre exemple en MARVIN : % Équivalent Esterel module b3 input I1, I2 ; output O1, O2 ; abort await I1 ; emit O1 when [ I2 and not I1 ] abort await I2 ; emit O2 when [ I1 and not I2 ] end module Il est possible d utiliser la version raccourcie du wait dans le cas où aucune action n est associée à la règle : wait I1 I2 -> emit O end wait Dans l exemple ci-dessus, le bloc se termine sans effectuer aucune action si seul I1 est reçu ; si I2 est reçu, avec ou sans I1, le signal O est émis. Notons que ce bloc est sensiblement différent du bloc décrit ci-dessous, utilisant une expression de signaux disjonctive et signifiant qu il faut émettre O si au moins l un des signaux I1 et I2 est reçu : wait I1 or I2 -> [ emit O ] end wait Priorités entre règles La définition de priorités entre des règles réactives d un même bloc est malaisée car elle nécessite l utilisation de nombreuses expressions de signaux décrivant les dif-

141 8.3. LES MODULES COMPORTEMENTAUX 141 férents cas d exclusion. Voici un exemple montrant qu il devient rapidement difficile de décrire et de maintenir un cas pourtant simple : wait I1 -> emit O1 I2 and not I1 -> emit O2 I3 and not I1 -> emit O3 I4 and not [ I1 or I2 or I3 ] -> emit O4 end wait Ce bloc verbeux signifie qu il faut d abord vérifier que le signal I1 est présent. Si c est le cas, les autres règles ne sont pas activées et le signal O1 est émis. Sinon il faut vérifier que I2 ou I3 (voire les deux) sont présents, auquel cas la ou les actions associées sont réalisées et la dernière règle n est pas activée. Enfin, si aucun des trois signaux I1, I2 et I3 n est reçu alors que le signal I4 est présent, alors O4 est émis. Pour simplifier la description de ce genre de cas, nous proposons d étendre la construction définissant un bloc de règles, en lui ajoutant des clauses else comme suit : wait I1 -> emit O1 else I2 -> emit O2 I3 -> emit O3 else I4 -> emit O4 end wait Les priorités sont définies entre les différents sous-blocs d un même bloc de règles, le premier sous-bloc étant le plus prioritaire. Imbrication de règles Comme nous l avons indiqué précédemment, il est possible qu une action associée à une règle réactive corresponde à une attente de signaux, en particulier à une nouvelle règle réactive (cf. section 8.3.1). Cette caractéristique s applique bien sûr aussi aux règles d un bloc. Voici un exemple de bloc contenant des règles imbriquées : wait I1 -> [ wait I2 -> [ emit O1 ] end wait ] I2 -> [ wait I1 -> [ emit O2 ] end wait ] end wait Si I1 seulement est présent, la deuxième règle est désactivée, ce qui signifie qu elle ne pourra plus être déclenchée par la suite ; il faut attendre la prochaine occurrence du signal I2 pour émettre O1 et terminer le bloc. Réciproquement, si I2 seulement est reçu, la première règle est désactivée et il faut attendre la prochaine occurrence de I1 pour émettre O2 et terminer le bloc. Les signaux I1 et I2 pouvant être reçus simultanément, les règles imbriquées peuvent être prises en compte en même temps ; dans ce cas, le bloc ne se terminera que lorsque ces deux nouvelles règles seront terminées. Voici le module ESTEREL équivalent :

142 142 CHAPITRE 8. LE LANGAGE MARVIN % Équivalent Esterel var activated1 := false : boolean in abort await I1 ; activated1 := true when [ I2 and not I1 ] ; if activated1 then [ await I2 ; emit O1 ] end if end var var activated2 := false : boolean in abort await I2 ; activated2 := true when [ I1 and not I2 ] ; if activated2 then [ await I1 ; emit O2 ] end if end var Les signaux valués Les signaux valués en entrée et en sortie sont déclarés comme en ESTEREL. Les types des paramètres de ces signaux doivent avoir été définis auparavant, en dehors du module puisque les émetteurs et les destinataires des signaux doivent pouvoir manipuler les valeurs de ces signaux. Un signal en sortie est émis en MARVIN de la même façon qu en ESTEREL. Rappelons que le statut et la valeur d un signal en sortie n est pas accessible au corps du module, en lecture comme en écriture. Il n existe pas d opérateur de lecture de la valeur d un signal en entrée, équivalent à l opérateur? d ESTEREL, mais il est possible de nommer les valeurs en paramètre d un signal dans un déclencheur. Ce nommage crée une variable locale à la règle pouvant être utilisée dans la partie action de la règle, ainsi que dans une garde 2. L exemple suivant récupère dans la variable v la valeur entière du signal I et vérifie que cette valeur est supérieure à 10 avant de déclencher la règle ; l action correspond à l émission du signal valué O : wait I (v) with [ v > 10 ] -> emit O (v) end wait Ambiguïtés L utilisation des opérations booléennes dans un déclencheur de règle peut se révéler problématique lorsque le comportement est mal spécifié. Dans l exemple suivant, si les deux signaux valués I1 et I2 sont reçus simultanément, la valeur de la variable v ne peut pas être déterminée : wait I1 (v) or I2 (v) -> [ emit O (v + 10) ] end wait Cette règle n a en fait aucun sens! Il est probable que le concepteur voulait utiliser l opérateur xor (ou exclusif) à la place du or, pour indiquer que l action doit être réalisée si l un ou bien l autre des signaux est reçu. Il est aussi possible que le concepteur 2 Il est fortement déconseillé de choisir un nom de variable déjà utilisé (variable globale ou locale), en espérant que la valeur de cette variable sera modifiée : le nommage ne fait que masquer temporairement l ancienne variable, pour définir une variable du même nom mais purement locale à la règle.

143 8.3. LES MODULES COMPORTEMENTAUX 143 ait souhaité exprimer que le signal O doit être émis si le signal I1 est reçu, ou bien si I1 est absent et I2 est présent ; cette deuxième solution se décrirait avec un bloc de règles contenant une clause else. Combinaison de signaux Comme nous l avons dit dans le chapitre 7 consacré aux modules comportementaux (cf. section 7.3.2, page 115), il est nécessaire d associer des fonctions de combinaison de signaux en sortie lorsque plusieurs règles peuvent émettre un même signal valué au cours d un instant. À la différence d ESTEREL, les méthodes de combinaison ne sont pas des fonctions associatives et commutatives mais des fonctions prenant en paramètre une liste de valeurs et renvoyant une unique valeur du même type que celui du paramètre du signal concerné 3. De cette façon, le concepteur est libre de définir n importe quel traitement sur un ensemble de valeurs à émettre, à condition qu il donne un unique résultat correctement typé. L exemple suivant montre comment définir un module comportemental chargé de gérer les pertes d énergie. La perte continuelle se traduit par la diminution de l attribut energy d une certaine quantité d énergie à chaque instant ; cette quantité est déterminée par la valeur courante de l attribut energy_step. Il est d autre part possible de perdre occasionnellement une quantité d énergie supplémentaire, donnée en paramètre du signal Loose. Nous avons déclaré le signal en sortie Reduce, dont la valeur est entière. La fonction de combinaison pour ce signal correspond à l addition de toutes les valeurs émises, cette fonction étant supposée définie auparavant : behaviour loose_energy in Loose (int) ; out Reduce (int) combine with addelements ; body loop wait Tick -> emit Reduce (owner.energy_step) Loose (a) -> emit Reduce (a) end wait end loop end body end behaviour Il est possible que les deux règles du bloc réactif soient déclenchées au même instant, les valeurs de Reduce étant alors additionnées pour qu un seul signal valué soit finalement émis. Si le niveau d énergie doit diminuer à chaque instant sauf lorsqu une demande explicite est reçue, il faut alors utiliser soit une clause else, soit l opérateur not. Avec l opérateur not, nous obtenons la description suivante : wait Loose (a) -> emit Reduce (a) Tick and not Loose (?) -> emit Reduce (owner.energy_step) end wait Notons l utilisation du point d interrogation (?), désignant une variable anonyme. Nous souhaitons en effet que le signal Loose soit absent pour déclencher cette règle, 3 Si le signal comporte plusieurs paramètres, la liste contiendra des n-uplets de même type.

144 144 CHAPITRE 8. LE LANGAGE MARVIN la valeur de son paramètre ne nous intéresse donc pas. Cette valeur sera de toute façon indéfinie Avortement Comme en ESTEREL, l avortement est décrit par la construction abort. Notons que nous ne proposons que le cas de l avortement fort, le mécanisme d exceptions décrit dans la section suivante nous semblant pour le moment suffisant pour simuler l avortement faible. Dans les deux exemples suivants, le signal O est émis à chaque réception de I jusqu à ce que le signal Stop soit reçu, auquel cas le bloc d avortement se termine sans laisser la boucle s exécuter une dernière fois : abort loop wait I -> emit O end wait end loop when Stop end abort abort when Stop loop wait I -> emit O end wait end loop end abort Ces deux blocs ne sont pas exactement équivalents. Ils illustrent en effet les deux formes que nous proposons pour l avortement, la première étant retardée et la deuxième immédiate. La deuxième forme permet de ne pas exécuter le bloc inclus si la condition d avortement est réalisée dès le premier instant ; c est en fait un raccourci du bloc suivant : present Stop else abort loop wait I -> emit O end wait end loop when Stop end abort end present Il existe deux façons de sortir d un bloc d avortement : soit le corps se termine naturellement, soit il est avorté lorsque la condition est satisfaite. Il est possible d associer un traitement spécifique en cas d avortement, en ajoutant une clause rescue : abort wait Tick -> [ emit O ] end wait when Stop rescue [ emit Aborted ] end abort La condition d avortement est similaire à la partie déclencheur d une règle réactive, il est donc possible d utiliser une expression de signaux complexe ou de définir une garde. Dans l exemple suivant, le module émet continuellement le signal O, jusqu à ce qu un compteur local n soit supérieur à un seuil donné :

145 8.4. CAPTEURS ET EFFECTEURS 145 var n <- 10 ; abort loop n <- n + 1 ; wait Tick -> [ emit O ] end wait end loop when Tick with [ n > owner.threshold ] rescue [ emit Done ] end abort ; emit Counter (n) Notons que dans ce cas, la condition d avortement ne sera prise en compte qu à l instant suivant le lancement de ce module, car il faut attendre de recevoir au prochain instant le signal Tick pour tester la garde. La valeur émise pour le signal Counter sera donc au moins égale à Trappes Les trappes sont définies et déclenchées en MARVIN exactement comme le sont les exceptions en ESTEREL. Nous avons choisi de ne pas appeler ces points de sortie des exceptions, car il ne s agit pas d un véritable mécanisme d exceptions tel que ceux mis en œuvre dans la plupart des langages récents. Un mécanisme d exceptions permet de lever une exception dans une fonction ou une méthode, et de ne traiter cette exception qu après avoir remonté la succession d appels jusqu à trouver une instruction capable de la gérer. Comme les exceptions d ESTEREL, nos trappes permettent de sortir d un bloc et sont traités immédiatement à la fin du bloc. Les trappes sont généralement utilisées pour sortir instantanément d une boucle infinie, après avoir effectué des actions. Dans l exemple suivant, la trappe T est levée quand le signal I2 est reçu ; avant de sortir de la boucle englobant le bloc de règles, le signal O2 est émis : trap T in loop wait I1 -> emit O1 I2 -> [ emit O2 ; exit T ] end wait end loop end trap Comme en ESTEREL, si les branches parallèles ne terminent pas instantanément lorsque la trappe est levée, elles sont alors avortées et le bloc se termine. De la même façon que pour le bloc d avortement, il est possible d utiliser une clause rescue pour traiter en particulier le cas où le bloc se termine à cause d une trappe. 8.4 Capteurs et effecteurs Avant de présenter la définition de capteurs et d effecteurs en MARVIN, nous allons nous intéresser à la description de protocoles d interaction, ainsi qu aux moyens mis en œuvre pour gérer la réception multiple de signaux. Bien qu utilisable dans les modules comportementaux, cette dernière caractéristique est particulièrement importante dans les effecteurs ; appliquée aux capteurs, elle permet de prendre en compte la réception

146 146 CHAPITRE 8. LE LANGAGE MARVIN multiple de stimuli Protocoles d interaction Comme nous l avons évoqué dans le chapitre 5, la description d un protocole d interaction se réduit pour le moment à la définition des types de stimuli externes (cf. section 5.2, page 92). Elle ne concerne pas les stimuli internes, définis localement à un agent. Il est aussi possible de définir des protocoles permettant l interaction entre un avatar et une interface utilisateur, en décrivant les types des stimuli utilisateurs échangés. Un type de stimulus est défini en donnant son nom et les types de ses paramètres. L identifiant de l entité émettrice (agent ou interface utilisateur) est implicite ; il est stocké automatiquement dans un champ supplémentaire du stimulus lors de l envoi. Voici un exemple de définition de types de stimuli externes : estim S_orientation (position_3d) ; estim S_position (orientation_3d) ; Les types donnés en paramètres doivent évidemment être définis et connus des agents devant utiliser le protocole. Les agents ayant pris connaissance de ces définitions, par exemple par l inclusion du fichier les contenant, peuvent échanger leurs positions et leurs orientations respectives. L exemple suivant définit des types de stimuli utilisateurs : ustim U_clicked (agent_id) ; ustim U_moveto (float, float) ; // Deux degrés de liberté ustim U_turnof (float) ; // Un seul degré de liberté Le stimulus U_clicked correspond ici à un clic de l utilisateur, permettant de désigner directement un agent. Les deux autres stimuli correspondent aux commandes de déplacement et de rotation de l avatar. Le déplacement se fait ici sur le plan du sol uniquement ; l angle de rotation est associé à l axe perpendiculaire au sol, ce qui permet seulement à l utilisateur de tourner la tête de l agent à gauche et à droite Réception multiple de signaux La machine d exécution doit garantir qu un canal ne transporte qu un seul signal à un instant donné, afin d assurer qu un module comportemental n envoie pas plusieurs fois un même type de signal valué à un autre module (cf. section 7.3.2, page 115). Cette hypothèse étant posée, le concepteur doit être conscient qu il est tout de même possible de recevoir plusieurs signaux du même type à un instant donné, à condition qu ils proviennent de sources différentes. Cela ne sera possible que si plusieurs canaux sont connectés à une même entrée, ce cas de figure étant fréquent pour les arbitres pouvant recevoir simultanément plusieurs propositions de modules comportementaux différents. Les règles réactives, qu elles soient indépendantes ou regroupées dans un bloc, ne sont déclenchables qu une seule fois dans un instant ; elles permettent donc de réagir à une seule occurrence d un même type de signal. Pour gérer plusieurs occurrences, il faut utiliser la construction all...as, qui permet de récupérer les informations concernant les signaux soit dans une liste pour un signal pur, soit dans un dictionnaire

147 8.4. CAPTEURS ET EFFECTEURS 147 pour un signal valué. La liste associée à un signal pur contient l ensemble des identifiants des émetteurs : wait all I as l -> emit NewIds (l) end wait Dans le cas d un signal valué, le dictionnaire récupéré contient l ensemble des valeurs des signaux reçus, étiquetées par l identifiant de l émetteur (module comportemental ou capteur). Il est inutile de nommer les paramètres comme pour une réception unique, puisque les valeurs sont directement stockées dans le dictionnaire : var sum ; wait all SetValue as vals -> sum <- 0 ; foreach v in vals.values() do sum <- sum + v end foreach end wait Notons l utilisation de l itérateur foreach, qui, contrairement à une boucle réactive définie avec la construction loop, peut exécuter son corps plusieurs fois dans le même instant. Cet itérateur permet ici de parcourir l ensemble des valeurs reçues afin de les additionner. Comme nous le verrons au cours de la section suivante, la construction all...as peut être utilisée au niveau des capteurs pour traiter les stimuli externes ou utilisateurs, un agent pouvant évidemment recevoir plusieurs stimuli du même type au cours du même pas de temps. Cette construction est inutile pour les stimuli internes, générés automatiquement par l agent à chaque phase d action en un seul exemplaire Définition d un capteur Un capteur est semblable à un module comportemental ne possédant que des sorties, le corps du capteur étant un filtre. La construction waitstim permet de préciser que ce sont des stimuli qui sont traités en entrée, et non pas des signaux. Pour faciliter la compréhension, nous avons choisi de séparer les exemples de capteurs en fonction des trois catégories de stimuli pouvant être reçus (internes, externes et utilisateurs). Malgré ce découpage, il est bien sûr tout à fait possible qu un même capteur reçoive et traite plusieurs catégories de stimuli. Capteur interne Dans ce premier exemple, nous définissons un capteur chargé de surveiller les modifications concernant la position et l orientation de l agent :

148 148 CHAPITRE 8. LE LANGAGE MARVIN sensor internal_move_sensor out I_moved, I_turned ; filter loop waitstim _position -> emit I_moved _orientation -> emit I_turned end waitstim end loop end filter end sensor Les stimuli internes purs indiquent la modification d un composant ; ils sont représentés par le nom du composant modifié, précédé du caractère souligné (_). Lorsqu il s agit d informer de l ajout ou du retrait d un composant, seule l opération effectuée est indiquée 4 (_add ou _remove) ; le paramètre du stimulus est alors l identifiant du composant concerné. Cette normalisation évite à l utilisateur d avoir à définir un protocole d interaction interne à l agent. Un capteur sert essentiellement à filtrer les stimuli. Il permet cependant aussi de créer de nouveaux événements, sous forme de signaux, en fonction de l état de l agent ou de son propre état (variables locales). Dans l exemple suivant, nous définissons un capteur qui, lorsque le niveau d énergie de l agent passe en-dessous d un certain seuil, indique que cet agent est censé mourir instantanément ; il mourra effectivement si le signal Dead est pris en compte en aval : sensor energy_sensor out Dead ; filter waitstim _energy with [ owner.energy < owner.min_energy ] -> emit Dead end waitstim end filter end sensor Notons que, dans ce cas, il est inutile d avoir une boucle englobant l attente de la condition : l agent est censé mourir dès que cette condition est satisfaite, le module peut alors se terminer. Un filtre peut permettre de la même façon d observer des événements en fonction du temps propre à l agent, afin de détecter des situations anormales ou des comportements qui pourraient être améliorés. L exemple suivant permet de surveiller que l agent n est pas bloqué dans une impasse. Pour cela, le module vérifie au bout de huit fois que la nouvelle position est suffisamment éloignée de la position sauvegardée. En prévenant dans le cas contraire les modules comportementaux en aval, le capteur pourra déclencher une stratégie permettant à l agent de se sortir de l impasse : 4 Il serait peut-être judicieux de préciser le type de composant ajouté ou détruit dans le nom du stimulus interne. Nous n avons pas suffisamment d exemples d utilisation de cette caractéristique du modèle pour valider notre choix actuel.

149 8.4. CAPTEURS ET EFFECTEURS 149 sensor deadend_sensor out DeadendDetected ; var max_distance <- 0.5 ; filter loop var counter <- 0 ; var last_position <- owner.position ; trap T in loop waitstim _position -> counter <- counter + 1 ; if counter > 8 then [ exit T ] end if end waitstim end loop end trap ; if around (last_position, owner.position, max_distance) then emit DeadendDetected end if end loop end filter end sensor La fonction around, supposée définie auparavant, vérifie qu un point se trouve dans une sphère définie par son centre et son rayon. Nous avons choisi pour cet exemple un algorithme simpliste qui ne conserve qu une position sur huit, ce qui peut l amener à s exécuter jusqu à 15 fois avant de détecter une anomalie ou bien à détecter une impasse alors que l agent est justement repassé par une zone afin de sortir d une impasse. Capteur externe Comme nous l avons indiqué dans la synthèse du chapitre 7, il est possible qu un agent reçoive «simultanément» des stimuli du même type en provenance de plusieurs agents ou de plusieurs interfaces utilisateurs, mais aussi éventuellement en provenance des mêmes entités (cf. section 7.6, page 128). Il est donc conseillé de prendre systématiquement en compte ces possibilités au niveau des capteurs. Nous sommes dans un cas légèrement différent de celui de la réception multiple de signaux, mais nous proposons une méthode de traitement de la réception multiple de stimuli (externes ou utilisateurs) proche, utilisant la même construction all...as. Dans le cas de stimuli purs, les identifiants des émetteurs sont stockés dans une liste ; cette liste est bien sûr sans doublons car l information utile correspond au fait d avoir reçu au moins une occurrence du stimulus de la part d un émetteur particulier. Dans le cas de stimuli valués, le dictionnaire récupéré contient les dernières valeurs de stimuli reçues, étiquetées par les identifiants des émetteurs. Ce choix correspond à ce qui nous semble la stratégie la plus courante de sélection des doublons dans le cadre d agents mobiles réactifs ; cette stratégie permet par exemple de ne prendre en compte que la dernière position reçue pour un agent, et non pas l ensemble de toutes les positions envoyées depuis le début du pas de temps précédent. Il peut cependant être utile de récupérer l ensemble des valeurs de stimuli reçues, c est pourquoi nous proposons une construction all...aslists supplémentaire. Cette construction est légèrement différente du all...as car elle permet de récupérer un dictionnaire contenant des listes de valeurs, rangées dans l ordre chronologique de leur émission ; ces listes sont

150 150 CHAPITRE 8. LE LANGAGE MARVIN étiquetées sur les identifiants des émetteurs : waitstim all S_positions aslists positions -> if positions.haskey(owner.predator) then emit PredatorTrajectory (positions[owner.predator]) end waitstim Intéressons-nous maintenant au problème de la mémorisation des valeurs de stimuli. Les deux exemples suivants décrivent deux versions d un capteur dédié à la surveillance des positions et des orientations des autres agents présents dans le monde virtuel. Dans le premier cas, les valeurs reçues sont passées en paramètre des signaux et ne sont pas mémorisées : sensor naive_external_move_sensor out Moved (agent_id list, position_3d list) ; out Turned (agent_id list, orientation_3d list) ; filter loop waitstim all S_position as positions -> emit Moved (positions.keys(), positions.values()) all S_orientation as orientations -> emit Turned (orientations.keys(), orientations.values()) end waitstim end loop end filter end sensor Sans une mémorisation minimale, il faut passer soit un dictionnaire soit deux listes en paramètre des signaux de sortie, afin que toutes les valeurs reçues puissent être prises en compte avec l identifiant de chaque émetteur par les modules comportementaux en aval. Un autre inconvénient de cette solution purement réactive est que les modules comportementaux sont rapidement limités dans leur prise de décision. Ce sera en particulier le cas si l envoi d un stimulus externe est réalisé seulement après une modification de l état : un agent immobile n émettant pas régulièrement sa position ne sera pas détecté comme un obstacle potentiel. Dans le deuxième exemple, nous choisissons donc de gérer une structure de mémorisation de certains stimuli reçus. Nous supposons la classe memorized_agent définie auparavant ; cette structure permet de mémoriser la position et l orientation courante d un agent, ou plus exactement les dernières valeurs connues de ces caractéristiques. L agent possède un attribut memory, dictionnaire contenant pour chaque agent connu une instance de memorized_agent étiquetée sur l identifiant de l agent. La gestion de cette mémoire est délicate : pour être utile, elle doit être mise à jour avant que les modules comportementaux ne soient déclenchés, c est-à-dire au cours de la phase de perception. La solution la plus simple et la plus efficace consiste à rendre les capteurs capables de mettre à jour directement les attributs servant à la mémorisation. Nous proposons pour cela une primitive update réservée aux filtres, permettant de modifier un attribut sans générer de stimulus interne. Il est évident que cette primitive doit être utilisée avec précaution, puisqu elle permet de modifier n importe quel attri-

151 8.4. CAPTEURS ET EFFECTEURS 151 but sans passer par un effecteur. Voici donc la description d une deuxième version de notre capteur, pour laquelle seuls les identifiants des émetteurs doivent être transmis ; il devient en effet inutile de passer les valeurs des stimuli en paramètre des signaux, ces valeurs étant directement disponibles dans l attribut memory : sensor external_move_sensor out Moved (agent_id list) ; out Turned (agent_id list) ; method create_if_needed (memory, id) if memory[id] = None then memory[id] <- new memorized_agent() end if end method filter loop waitstim all S_position as positions -> var memory <- owner.memory ; var ids <- positions.keys() ; foreach a in ids do self.create_if_needed (memory, a) ; memory[a].position <- positions[a] end foreach ; update (owner#memory, memory) ; emit Moved (ids) all S_orientation as orientations -> var memory <- owner.memory ; var ids <- orientations.keys() ; foreach a in ids do self.create_if_needed (memory, a) ; memory[a].orientation <- orientations[a] end foreach ; update (owner#memory, memory) ; emit Turned (ids) end waitstim end loop end filter end sensor Le caractère dièse (#) est un opérateur servant de raccourci à l invocation de la méthode id() de récupération de l identifiant d un composant. La primitive de modification d attribut prend en effet comme premier argument l identifiant de l attribut à affecter avec la valeur donnée en deuxième argument. Il n est pas possible de mettre à jour directement un champ d un objet contenu dans un attribut, c est pourquoi, dans l exemple ci-dessus, nous récupérons d abord une copie de l attribut que nous modifions successivement pour tous les émetteurs, puis que nous affectons à l attribut. Notons que la modification «en parallèle» au cours d un instant de l attribut de mémorisation ne posera ici pas de problème, puisque l exécution de chaque règle est atomique et qu une copie de la valeur courante de l attribut est récupérée au début de la séquence d action.

152 152 CHAPITRE 8. LE LANGAGE MARVIN Capteur utilisateur Dans l exemple suivant, le capteur attend que l utilisateur clique sur un agent pour le désigner directement : sensor click_sensor out Target (agent_id) ; filter loop waitstim U_clicked (a) -> emit Target (a) end waitstim end loop end filter end sensor Il n y a pas de différence de traitement entre un stimulus externe et un stimulus utilisateur, à part que l identifiant de l émetteur est de type user_id et non pas agent_id. Puisqu un avatar peut être associé à plusieurs interfaces utilisateur, l identifiant de l émetteur peut permettre de traiter différemment les interfaces se partageant l avatar. Dans notre exemple cependant, l absence du mot-clé all implique que cet avatar n est pas censé être associé à plus d une interface utilisateur Définition d un effecteur Un effecteur est semblable à un module comportemental ne possédant que des entrées, le corps de l effecteur étant un arbitre. Les principales actions primitives qu un effecteur peut réaliser sont les suivantes : set : la modification d un attribut ; add : l ajout d un composant ; remove : le retrait d un composant ; esend : l envoi d un stimulus externe ; usend : l envoi d un stimulus utilisateur. Il est aussi possible de modifier le corps d un module comportemental (setbody), le filtre d un capteur (setfilter) ou l arbitre d un effecteur (setarbiter). Pour des raisons de lisibilité, nous avons préféré présenter des exemples séparés d effecteurs en fonction des types d action réalisée : action purement interne, action interne ayant une influence sur l environnement, action interne ayant une influence sur l environnement et sur l utilisateur d un avatar. Effecteur interne Dans l exemple suivant, le niveau d énergie n est pas un attribut connu des autres agents, c est pourquoi l arbitre n effectue qu une modification de la valeur de cet attribut, sans envoyer de stimulus externe : effector energy_effector in Add (int), Subtract (int) ;

153 8.4. CAPTEURS ET EFFECTEURS 153 // Somme de quantités d énergie method sum (l) q <- 0 ; foreach p in l do q <- q + p end foreach ; return q end method arbiter loop var add <- 0 ; var sub <- 0 ; wait all Add as propositions -> add <- self.sum (propositions.values()) all Subtract as propositions -> sub <- self.sum (propositions.values()) end wait ; set (owner#energy, add - sub) end loop end arbiter end effector Notons qu il est inutile de vérifier que la liste des valeurs proposées n est pas vide : si la règle est déclenchée, c est qu au moins une valeur a été proposée. Cet effecteur permet de gérer quatre caractéristiques éventuelles du comportement de l agent : la perte continuelle d énergie pendant la période d éveil ; la perte occasionnelle d énergie, par exemple si l agent est temporairement blessé ; le gain continuel d énergie pendant la période de repos ; le gain occasionnel d énergie, par exemple après l absorption de nourriture. Effecteur interne et externe Définissons maintenant un nouvel effecteur, chargé de gérer la position de l agent. Les actions qu il réalise concernent la position, la direction et l orientation de l agent. Dans cet exemple, nous considérons en effet la direction et l orientation comme des attributs fortement liés au changement de position mais sur lesquels les modules comportementaux ne peuvent pas influer directement. La position et l orientation doivent être transmises aux autres agents, il faut donc envoyer deux stimuli externes. La valeur de la direction reste privée, elle n est donc pas émise : effector position_effector in Set (position_3d) ; // Calcul d une moyenne des positions 3D method average (l) var length <- l.length ; var (x, y, z) <- (0.0, 0.0, 0.0) ; foreach p in l do (x, y, z) <- (x + p.x, y + p.y, z + p.z) end foreach ; (x, y, z) <- (x / length, y / length, z / length) ; return new position_3d (x, y, z) end method

154 154 CHAPITRE 8. LE LANGAGE MARVIN rmethod process_action (p) var (o, d) <- calculate_orientation_and_direction (owner.direction, p) ; set (owner#position, p) ; set (owner#orientation, o) ; set (owner#direction, d) ; esend S_position (p) ; esend S_orientation (o) end rmethod arbiter loop wait all Set as propositions -> self.process_action (self.average (propositions.values())) end wait end loop end arbiter end effector Nous supposons la fonction calculate_orientation_and_direction déjà définie ; cette fonction calcule les nouvelles valeurs d orientation et de direction, à partir de la direction courante et de la nouvelle position. L effecteur ne permet de proposer que des modifications de la position de l agent, masquant ainsi la gestion des attributs concernant la direction et l orientation. Les valeurs de ces attributs restent cependant accessibles en lecture. Il existe pour le moment deux formes de la primitive esend, permettant l envoi d un stimulus externe selon les deux modes de communication disponibles : la diffusion (broadcast), utilisée dans l exemple précédent, et l envoi à un agent particulier (unicast) qui nécessite de fournir l identifiant du destinataire. Nous avons factorisé le code correspondant aux actions de l effecteur dans la méthode réactive process_action(), en prévision de l exemple suivant, afin qu il hérite au mieux des propriétés de position_effector. Effecteur interne et utilisateur Les effecteurs précédents peuvent être étendus pour être adaptés à un avatar. Si nous envisageons que l information concernant le niveau d énergie n est pas disponible pour l utilisateur, l effecteur correspondant n est pas modifié pour l avatar. Nous pouvons par contre étendre la définition de l effecteur chargé de la position, en considérant que la seule différence réside dans notre exemple à envoyer deux stimuli supplémentaires à l utilisateur : effector avatar_position_effector inherits position_effector rmethod process_action (v) super.process_action (v) ; usend U_position (v) ; usend U_orientation (owner.orientation) end rmethod end effector Grâce au mécanisme d héritage, nous pouvons réutiliser la plus grande partie de la définition précédente : seule la méthode de réalisation des actions a besoin d être spécialisée. Comme pour la primitive esend, la primitive usend peut actuellement

155 8.5. DÉFINITION DE CANAUX 155 s utiliser selon deux modes : soit pour une diffusion à toutes les interfaces utilisateurs associées à l avatar, soit pour l envoi à une interface en particulier. 8.5 Définition de canaux Les canaux relient une sortie d un module comportemental ou d un capteur à une entrée d un autre module comportemental ou d un effecteur, l entrée et la sortie devant être du même type. Un canal se définit en utilisant la primitive link ; la primitive delayed_link permet quant à elle de définir un canal-retard. Voici un exemple connectant le module de gestion d énergie à l effecteur chargé de l attribut energy, en utilisant un canal normal (sans retard) : link (loose_energy.set, energy_effector.set) Il est par ailleurs possible de détruire un canal, par exemple pour retirer le canal défini précédemment : unlink (loose_energy.set, energy_effector.set) La primitive unlink s applique aussi bien aux canaux retardés qu aux canaux normaux. Lorsqu elles sont appliquées à des modules comportementaux indépendants, les primitives link et unlink ne peuvent être utilisées que par un effecteur ou par l agent lui-même. Nous verrons dans la section suivante qu un module comportemental peut toutefois créer et détruire localement des canaux reliés à des sous-modules avec les mêmes primitives, sans avoir à passer par un effecteur. 8.6 Sous-modules Dans cette section, nous allons présenter un exemple d utilisation de sous-modules. Nous définirons tout d abord un module permettant d avancer d un pas. Ce module est ensuite utilisé comme sous-module pour définir un module de déplacement vers une position donnée. Enfin, ce deuxième module est inclus dans un dernier module permettant le déplacement aléatoire de l agent. Le premier et le deuxième module peuvent par ailleurs être utilisés comme des modules indépendants Faire un pas Notre premier exemple définit un module permettant de se déplacer d un pas dans une direction donnée : behaviour step_to in Direction (vector_3d) ; out Set (position_3d) ;

156 156 CHAPITRE 8. LE LANGAGE MARVIN method calculate_trajectory (p, d) var trajectory <- [] ; var end_position <- calculate_position (p, d, owner.step_length) ; foreach i in range (1, 3) do var step <- i * 0.25 ; var x <- ((end_position.x - p.x) * step) + p.x ; var y <- ((end_position.y - p.y) * step) + p.y ; var z <- ((end_position.z - p.z) * step) + p.z ; trajectory.add(new position_3d (x, y, z)) end foreach ; return (trajectory, end_position) end method body loop wait Direction (d) -> var (trajectory, end_position) <- self.calculate_trajectory (owner.position, d) ; foreach p in trajectory do emit Set (p) ; wait Tick end wait end foreach ; emit Set (end_position) ; emit Done end wait end loop end body end behaviour La fonction calculate_position, supposée définie, permet de déterminer une position à atteindre à partir d une position initiale, d un vecteur 3D définissant une direction et d une distance. Une fois que l action associée à la réception du signal Direction est déclenchée, le comportement de ce module ne peut plus être interrompu, jusqu à ce que la trajectoire choisie soit épuisée. En particulier, le signal Direction est ignoré, il n est donc pas possible d influer sur la trajectoire au cours d un pas de déplacement. De ce point de vue, un tel module comportemental de bas-niveau se rapproche des compétences motrices définies par B. Blumberg (cf. section 3.3.6, page 55). Ce module pourrait correspondre à une animation complexe, faisant par exemple intervenir une déformation des membres de l agent. L inconvénient de ce module est qu il ne tient absolument pas compte du comportement de l arbitre chargé de gérer la position de l agent. Le pas est découpé en quatre déplacements élémentaires, chacun de ces déplacements pouvant être ignoré par l arbitre, ou combiné à d autres propositions. Il faudra prendre en compte cette caractéristique au moment de la conception globale de l agent ; au besoin, il faudra redéfinir ce module pour le rendre plus robuste et plus souple Se déplacer jusqu à une position donnée Le module suivant permet de se déplacer jusqu à une position donnée, cette destination étant modifiable au cours de l exécution. Ce module est composé d un sousmodule, instance du module step_to défini précédemment. Son comportement consiste à se déplacer pas à pas jusqu à arriver à destination :

157 8.6. SOUS-MODULES 157 behaviour move_to in Target (position_3d) ; out Set (position_3d); local out Direction (vector_3d) ; local in Done ; body var target <- None ; var step_to <- new step_to () ; link (Direction, step_to.direction) ; link (step_to.done, Done) ; link (step_to.set, Set) ; loop wait Target (p) -> [ target <- p ] end wait ; trap Arrived loop if around (owner.position, target, owner.step_length) then exit Arrived else emit Direction (new vector_3d (owner.position, target)) ; trap StepDone in loop wait Target (p) -> [ target <- p ] Done -> [ exit StepDone ] end wait end loop end trap end if end loop end trap end loop end body end behaviour Ce module permet à l agent de se déplacer pas à pas jusqu à être suffisamment proche du point cible, à une longueur de pas près. Le bloc de règles inclus dans le deuxième bloc d exceptions permet de prendre en compte la mise à jour de la cible pendant qu un pas de déplacement est effectué. Notons que la combinaison de signaux n est pas utile ici, puisque seul le sous-module émet le signal Set. Un sous-module peut être instancié soit lors de sa déclaration en tant que variable globale au module, soit à n importe quel moment dans le corps du module. Cette instanciation prépare automatiquement le nouveau module à réagir instantanément, dès qu il en recevra l ordre (de la part de l ordonnanceur). Cela signifie qu un sous-module pourra s exécuter juste après son père à l instant même de sa création. Dans notre exemple, le sous-module est opérationnel dès le tout premier instant du père. Les entrées et les sorties locales, permettant la communication avec le sous-module, sont introduites à l aide du mot-clé local en dehors du corps du module-père. Les deux premiers canaux locaux définis dans le corps du module concernent la communication père-fils. Le troisième canal relie directement la sortie du sous-module à la sortie du module-père, permettant ainsi au sous-module de fournir instantanément le résultat de sa réaction aux modules comportementaux connectés en sortie à son père.

158 158 CHAPITRE 8. LE LANGAGE MARVIN Se déplacer aléatoirement Notre dernier module permet de se déplacer continuellement de façon aléatoire. Il active pour cela cycliquement son sous-module move_to, instance du module du même nom défini précédemment, afin de se déplacer jusqu à une position choisie au hasard ; nous supposons pour cela que la fonction random_position a déjà été définie. Ce module comportemental peut être déclenché et arrêté, en lui envoyant respectivement les signaux Start et Stop : behaviour random_move in Start, Stop ; out Set (position_3d); local out Target (position_3d) ; local in Done ; body var move_to <- new move_to() ; link (Target, move_to.target) ; link (move_to.done, Done) ; link (move_to.set, Set) ; loop wait Start end wait ; abort loop emit Target (random_position ()) ; wait Done end wait end loop when Stop rescue [ move_to.reset() ] end loop end body end behaviour Cet exemple nous permet d introduire les méthodes de contrôle direct de sousmodule. Le module move_to a en effet été défini comme un module comportemental indépendant. Lorsqu il est intégré comme sous-module, son père peut avoir besoin de contrôler son exécution : si le module random_move reçoit le signal Stop, son sousmodule doit absolument arrêter de s exécuter instantanément. Le contrôle de l exécution se fait en utilisant deux méthodes spécifiques d un sous-module, abort() et run(), permettant respectivement d avorter et de lancer instantanément le sousmodule. Ces deux méthodes sont combinées pour constituer la méthode reset(), qui avorte puis relance instantanément le sous-module. Notons que les fils sont avortés si et seulement si le père demande leur avortement explicitement ou s il est lui-même avorté ; si le père termine naturellement, les fils peuvent continuer de s exécuter. Les méthodes de contrôle direct doivent être utilisées avec précaution, sous peine d obtenir des comportements inattendus. L exemple du module random_move nous permet de voir en pratique les conséquences des choix que nous avons fait à propos de la communication père-fils. Rappelons qu un signal émis par le père sur une sortie locale est reçu instantanément par ses fils, mais qu un signal émis par un fils sur une entrée locale est retardé et sera donc reçu à l instant suivant par son père (cf. section 7.5.6, page 127). Dans notre exemple, nous avons encapsulé le module step_to dans le module move_to, lui-même en-

159 8.7. DÉFINITION DE MONDES, D AGENTS ET D AVATARS 159 capsulé dans le module random_move. Il peut donc y avoir une cascade d émissions, à l instant où le module random_move émet le signal Target, ce signal étant reçu instantanément par le sous-module move_to. Si ce sous-module attend lui-même un signal Target pour émettre le signal Direction à destination de son propre sousmodule step_to, alors ce signal Direction sera lui aussi reçu instantanément et le pas de déplacement sera initié. Le signal Set est émis par step_to, pour être propagé jusqu à la sortie Set de random_move instantanément. Par contre, le signal Done émis par le sous-module step_to sera reçu à l instant suivant par move_to, qui pourra alors émettre lui-même un signal Done, reçu à l instant suivant par random_move. Si un tel retard est gênant pour l application, il faudra éviter d encapsuler autant de modules les uns dans les autres mais plutôt les rendre indépendants, au risque d avoir un contrôle moins fin sur leur exécution. 8.7 Définition de mondes, d agents et d avatars Un agent autonome Définissons maintenant un agent complet, en combinant certains des composants décrits précédemment. Nous supposons défini le module comportemental gérant l évitement de collision (avoid_collisions), ainsi que la fonction parse_vrml permettant de créer une forme à partir d une description en VRML 5 : agent rabbit // Attributs attribute position <- None ; attribute orientation <- new orientation_3d () ; attribute shape <- parse_vrml ("rabbit.wrl") ; attribute memory <- {:} ; // Dictionnaire vide attribute energy <- 50 ; attribute energy_step <- 1 ; attribute min_energy <- 0 ; // Constructeur method initialize (initial_position) position <- new attribute (initial_position) end method // Structure de mémorisation object memorized_agent position <- None ; orientation <- None ; end object 5 VRML (Virtual Reality Modeling Language) est un langage standardisé de description de scènes 3D destinées au WWW, qui est une norme ISO depuis 1997.

160 160 CHAPITRE 8. LE LANGAGE MARVIN // Capteurs sensor imove_sensor <- new internal_move_sensor () ; sensor emove_sensor <- new external_move_sensor () ; // Effecteurs effector position_effector <- new position_effector () ; effector energy_effector <- new energy_effector () ; // Modules comportementaux behaviour move <- new random_move () ; behaviour avoid <- new avoid_collisions () ; behaviour energy_manager <- new loose_energy () ; // Définition interne d un module comportemental behaviour Default out Start ; body wait Tick -> [ emit Start ] end wait end body end behaviour behaviour default <- new Default () ; body // Mise en place des canaux link (default.start, move.start) ; link (move.set, position_effector.set) ; link (imove_sensor.i_moved, avoid.i_moved) ; link (emove_sensor.moved, avoid.moved) ; link (avoid.set, position_effector.set) ; link (energy_manager.set, energy_effector.set) ; // Émission de l état initial esend S_position (position) ; esend S_orientation (orientation) end body end agent L ordonnanceur de l agent, qui gère l exécution des modules comportementaux et déclenche les trois phases d une réaction de l agent (perception, décision et action), n est lancé que lorsque l agent est entièrement défini et instancié. Juste avant que l ordonnanceur ne soit lancé, deux stimuli externes sont envoyés directement par l agent pour indiquer aux autres agents son état initial. Dès le premier instant d exécution de l agent, c est-à-dire dès le lancement de l ordonnanceur, de nouveaux stimuli pourront être envoyés. Le module default permet de déclencher le déplacement aléatoire de l agent à partir du deuxième instant de son existence. Au moment de l instanciation, les modules comportementaux, les capteurs et les effecteurs sont prêts à être déclenchés pour la première fois dès l instant suivant ; c est en particulier vrai pour le tout premier instant de l agent. Si le corps d un de ces modules ne contient aucune attente de signal, il se terminera instantanément dès le premier pas de temps de l agent. Si l une des instructions rencontrées est une règle ou un bloc de règles, le module réagira aux signaux attendus seulement lors de son deuxième instant d existence, donc lors du deuxième pas de temps de l agent. C est pour cela que le module default attend le deuxième tic d horloge de l agent avant de déclencher le module move. Pour éviter de perdre ce

161 8.7. DÉFINITION DE MONDES, D AGENTS ET D AVATARS 161 tout premier instant, il aurait fallu utiliser la construction present dans le module move_random pour qu il réagisse immédiatement au signal Start ; il faudrait dans ce cas aussi modifier son sous-module move_to pour qu il prenne en compte immédiatement le signal Target, ainsi que le sous-module step_to de move_to pour qu il réagisse également dès le premier instant au signal Direction Un avatar semi-autonome Pour définir un avatar se comportant en partie comme notre lapin, il suffit d étendre la définition précédente. Nous remplaçons le module de déplacement aléatoire par un module de type move_to piloté par un capteur supplémentaire de type user_sensor, ce qui permet à l utilisateur de diriger le déplacement de son avatar : agent rabbit_avatar inherits rabbit attribute shape <- parse_vrml ("rabbit-avatar.wrl") ; attribute energy <- 100 ; // Capteur supplémentaire sensor umove_sensor <- new user_sensor () ; // Définition interne d un module comportemental behaviour Go_toward in Agent_target (agent_id) ; out Position_target (position_3d) ; body loop wait Agent_target (a) -> emit Position_target (owner.memory[a].position) end wait end loop end body end behaviour behaviour go_toward <- new Go_toward () ; body // Redéfinition d un effecteur position_effector <- new avatar_position_effector () ; // Retrait du module initial // (les canaux associés sont détruits automatiquement) remove (default) ; // Redéfinition d un module comportemental move <- new move_to () ; // Canaux supplémentaires link (umove_sensor.target, go_toward.agent_target) ; link (go_toward.position_target, move.target) ; // Initialisation supplémentaire de l agent usend U_position (position) ; usend U_orientation (orientation) end body end agent La redéfinition d un module, d un capteur ou d un effecteur conserve les canaux

162 162 CHAPITRE 8. LE LANGAGE MARVIN compatibles avec la nouvelle valeur du composant, c est pourquoi nous n avons pas besoin par exemple de recréer le canal reliant le module d évitement de collision et le nouvel effecteur chargé de la position de l avatar. Pour se débarrasser complètement d un module et de ses canaux, il faut retirer le composant (remove) et non pas seulement le redéfinir Un monde INVIWO Nous pouvons ensuite décrire un monde INVIWO contenant comme habitants deux lapins, l un étant complètement autonome et l autre étant un avatar. Nous y ajoutons une dizaine de carottes, disposées aléatoirement : world rabbits_world r <- new rabbit (new position_3d (0.0, 0.0, 0.0)) ; a <- new rabbit_avatar (new position_3d (10.0, 10.0, 0.0)) ; inhabitants <- { r, a } ; // Liste des habitants foreach i in range (1, 10) do c <- new Carott (random_position()) ; self.addinhabitant (c) end foreach end world 8.8 Synthèse Nous avons proposé un langage de description de comportements d agents, principalement basé sur la définition de règles réactives. Ce langage permet de décrire distinctement chacun des composants d un agent INVIWO, avec une syntaxe adaptée à la mise en œuvre de comportements réactifs. Les réactions à des événements, que ce soient à des stimuli au niveau des capteurs ou à des signaux au niveau des modules comportementaux ou des effecteurs, sont décrites de façon homogène. Comme nous l avons dit dans le chapitre 7 consacré aux modules comportementaux, nous avons choisi de ne pas permettre à l utilisateur d accéder au statut et à la valeur d un signal en sortie (cf. section 7.3.1, page 115). Cette solution simplifie beaucoup l utilisation du langage MARVIN par rapport à ESTEREL, en limitant les risques d erreur de conception. Il est possible d accéder à la valeur d un signal en entrée mais ceci est valable uniquement pendant l instant courant : la valeur d un signal absent est indéfinie (Undefined) et ne correspond donc pas à sa dernière valeur connue comme c est le cas en ESTEREL. Si l ancienne valeur d un signal est nécessaire, il faudra la sauvegarder explicitement. Nous n avons pas la notion de composantes parallèles en MARVIN, car il nous semble suffisant de considérer les modules et les sous-modules comme s exécutant en parallèle. Nous proposons le bloc de règles réactives pour l attente concurrente de signaux, qui nous paraît le seul cas vraiment utile de parallélisme explicite dans notre contexte. Pour définir des composantes comportementales parallèles, il faut donc définir plusieurs modules ou sous-modules comportementaux. D autres caractéristiques d ESTEREL n apparaissent pas dans le langage MARVIN : il n y a pas de gestion des tâches asynchrones par exemple, ni de capteur au sens ESTEREL. Nous ne proposons pas non plus d équivalent au mot-clé immediate d ESTEREL, permettant de prendre

163 8.8. SYNTHÈSE 163 en compte un signal dès le premier instant d une composition normalement retardée. Nous avons introduit une version immédiate de l avortement et nous disposons de la construction present afin de simuler au besoin une attente de signal immédiate. Nous pouvons remarquer que la préemption se fait soit comme en ESTEREL au niveau d un module (bloc abort), soit d un module-père vers un module-fils (méthode abort() du sous-module), mais qu il n est pas possible de demander l avortement d un autre module comportemental indépendant. Il nous paraît en effet risqué de laisser les modules interférer avec le rôle de l ordonnanceur. Il n y a pas non plus de primitive permettant de demander le déclenchement d un autre module, car l instanciation mène automatiquement à un déclenchement dès l instant suivant. Nous pourrons toutefois réviser ces choix par la suite, s il s avère que ces fonctionnalités sont finalement plus utiles que dangereuses. Étant donné le public que nous visons, le langage MARVIN possède un avantage important par rapport à ESTEREL et aux réseaux d objets synchrones : tout ce qui concerne un agent peut être programmé directement en MARVIN (composants, types et données manipulés, description des parties réactives, etc.), alors que les autres systèmes imposent un langage différent pour décrire les parties réactives et pour définir les données et leur manipulation. Pour ESTEREL, le comportement réactif d un module est décrit en ESTEREL mais il faut maîtriser le langage de la machine d exécution pour définir de nouveaux types ou les fonctions et procédures de manipulation des données. Les objets synchrones encapsulent pour leur part une description faite en ESTEREL ou en LUSTRE, mais il faut ensuite utiliser le langage C++ pour faire communiquer les objets synchrones avec les objets non synchrones. Les deux principales difficultés de notre langage proviennent d une part de l approche réactive, qui nécessite de définir des comportements basés sur la notion d instant, d autre part de notre architecture de sélection de l action. Pour pouvoir intégrer un mécanisme souple d arbitrage, il nous faut en effet permettre la gestion explicite de la réception multiple de signaux ; la construction all...as se comporte différemment selon que les signaux sont purs ou valués. Cette construction s applique facilement à la réception multiple de stimuli, en imposant que les valeurs récupérées soient les dernières reçues. Pour récupérer les doublons de stimuli provenant d une même source, nous avons introduit la construction all...aslists. Nous avons essayé de proposer des constructions similaires pour traiter de façon homogène l ensemble de ces cas de réception multiple, tout en laissant au concepteur toute liberté concernant ce traitement. Nous sommes cependant conscients que cette partie du langage est loin d être intuitive. Le fait que la partie orientée-objets ne soit pas encore définie proprement accentue parfois la difficulté de compréhension, en particulier lorsqu il s agit d hériter des propriétés d un module comportemental ou d un agent. Enfin, MARVIN est un langage qui nécessite beaucoup de vérifications, à l interprétation comme à l exécution, car il permet de décrire rapidement des comportements d agents en utilisant au maximum le polymorphisme introduit naturellement par le typage dynamique. De plus, les comportements décrits sont entièrement dynamiques : la structure de l agent est complètement évolutive et les réseaux comportementaux peuvent se reconfigurer à volonté.

164 164 CHAPITRE 8. LE LANGAGE MARVIN

165 Chapitre 9 Contraintes et comportements d agents 9.1 Introduction Une contrainte est une relation forte portant sur une ou plusieurs variables, qui se doit d être maintenue. La connexion entre le domaine des agents et le domaine des contraintes peut se faire selon deux axes, consistant d une part à améliorer les résolveurs de contraintes en utilisant des approches multi-agents, d autre part à introduire la notion de contraintes dans les agents pour faciliter en particulier la description et la mise en œuvre de la planification [63]. Nous allons montrer dans ce chapitre comment les contraintes peuvent être utilisées pour spécifier de façon déclarative le comportement d un agent INVIWO. Nous pouvons d ores et déjà distinguer trois types de contraintes pouvant être intégrées à notre modèle, en fonction de leur portée vis-à-vis des agents contraints : une contrainte interne est une contrainte multidirectionnelle, qui concerne uniquement les attributs d un agent. Ce type de contraintes permet typiquement de définir des domaines de valeurs pour un attribut ; une contrainte externe est une contrainte multidirectionnelle, qui porte sur les attributs de plusieurs agents et qui n appartient à aucun agent ; une contrainte semi-externe est une contrainte unidirectionnelle, qui influe sur des attributs de son propriétaire en prenant en compte des attributs d autres agents. Nous avons choisi un modèle de mondes virtuels complètement réparti dans lequel un agent est autonome, ce qui signifie en particulier que son état et son comportement sont encapsulés. Nous ne souhaitons pas introduire dans ce modèle un gestionnaire global de contraintes, qui maintiendrait de façon centralisée l ensemble des contraintes externes reliant les agents et qui manipulerait pour cela directement les attributs des agents. Nous avons donc choisi de n autoriser entre agents que la mise en place de contraintes unidirectionnelles correspondant aux contraintes semi-externes ; les contraintes sont donc définies uniquement au niveau d un agent INVIWO. Au besoin, une contrainte externe peut être simulée à partir de plusieurs contraintes semiexternes. Par ailleurs, une contrainte semi-externe ne porte pas réellement sur un attribut d un autre agent mais plutôt sur la dernière valeur mémorisée correspondant à cet 165

166 166 CHAPITRE 9. CONTRAINTES ET COMPORTEMENTS D AGENTS attribut ; le contrôle sur ce type de contraintes n est pas aussi fin que celui concernant les contraintes purement internes, puisque les variables externes impliquées ne sont pas modifiables et sont mises à jour à la réception des stimuli associés. Après avoir rapidement présenté les principes de la résolution de contraintes et de la programmation par contraintes, nous étudierons en détail une utilisation originale de la notion de contrainte proposée par P. Codognet : la résolution pas à pas de contraintesbuts. Nous montrerons ensuite comment intégrer les contraintes dans notre modèle, en particulier sous la forme de contraintes-buts et de contraintes agentifiées. 9.2 Contraintes : résolution et programmation La principale qualité des contraintes réside dans leur déclarativité : il suffit de définir un problème sous la forme de relations entre des variables. Le système de résolution de contraintes, aussi appelé résolveur de contraintes, se charge de trouver au moins une solution à ce problème (si elle existe), une solution correspondant à une configuration dans laquelle toutes les variables sont instanciées et aucune contrainte n est violée. Les algorithmes de résolution de contraintes sont spécialisés en fonction du type de problème à résoudre ; ils s inspirent au besoin de techniques de recherche opérationnelle et d analyse numérique [125]. Les résolveurs de contraintes sur les domaines finis permettent de résoudre efficacement des problèmes d ordonnancement de tâches ou d optimisation combinatoire. Une contrainte représente dans ce cas une information partielle sur laquelle le système de résolution peut raisonner. Les algorithmes associés sont généralement basés sur la vérification de l «arc-consistance» des contraintes (arc consistency) : ils consistent à réduire successivement les domaines des variables jusqu à satisfaire l ensemble des contraintes [122]. Cette réduction ne suffit généralement pas pour trouver une solution au problème, il faut alors énumérer les solutions possibles en sélectionnant une variable à instancier puis en choisissant dans son domaine une valeur à lui affecter. Il faut alors vérifier que les contraintes associées à la variable nouvellement instanciée sont satisfaites, et propager au besoin la réduction des domaines des autres variables concernées par ces contraintes. Si l un des domaines modifiés est réduit à un ensemble vide au cours de la propagation, la variable correspondante ne pourra plus être instanciée : la solution proposée n est pas acceptable. Le système de résolution doit alors reprendre son exploration de l espace de recherche depuis un état précédemment sauvegardé, selon un mécanisme de retour arrière (backtracking). Si l un des domaines modifiés est réduit à un singleton, la variable peut être instanciée immédiatement à cette valeur. S il reste des variables non-instanciées quand la propagation se termine, il faut de nouveau sélectionner une variable à instancier. La programmation par contraintes allie la puissance d un langage de programmation à l expressivité des contraintes déclaratives, tout en profitant de l efficacité des algorithmes de résolution. De nombreux travaux portent sur la programmation logique avec contraintes, profitant en particulier de l expressivité du langage PROLOG et des mécanismes fournit pour l exploration d arbres de recherche [50]. Par exemple, le langage GNU PROLOG intègre complètement les contraintes sur les domaines finis selon une version ISO de PROLOG [58].

167 9.2. CONTRAINTES : RÉSOLUTION ET PROGRAMMATION 167 Les résolveurs classiques sont capables de gérer des contraintes non-contradictoires, c est-à-dire pour lesquelles le problème est résolu s il existe au moins une solution pour laquelle aucune contrainte n est violée. Les résolveurs basés sur des contraintes souples (soft constraints) permettent de prendre en compte des contraintes contradictoires, qui peuvent être «plus ou moins satisfaites» en fonction de préférences. Par exemple, le système clp(fd, ) considère des contraintes qui prennent leur valeur dans une structure de demi-anneau; une instance de ce système concerne les contraintes floues, qui prennent leur valeur de satisfaction dans l ensemble. Ce système s est révélé efficace pour résoudre des problèmes sur-contraints, pour lesquels il n existe pas de solution ne violant aucune contrainte ; il est par ailleurs adapté à la résolution de problèmes dynamiques, dans lesquels sont réalisés de nombreux ajouts et retraits de contraintes [69] Contraintes-buts et recherche adaptative Les contraintes-buts, proposées récemment par P. Codognet, représentent des objectifs à atteindre associés à une méthode de résolution dynamique. Un objectif est défini sous la forme d une contrainte à satisfaire du mieux possible en utilisant une méthode de réparation (repair method) pas à pas, remplaçant le traditionnel mécanisme de résolution complète et immédiate du problème [52, 116]. La méthode proposée pour résoudre globalement un ensemble de contraintes-buts est appelée recherche adaptative (adaptive search). Cette méthode, inspirée des méthodes de recherche locale telles que le recuit simulé ou les algorithmes génétiques, sélectionne successivement des actions de façon à satisfaire au maximum les contraintes à chaque itération. Définition de contraintes-buts Une contrainte-but permet de décrire un comportement d agent en terme de besoin à satisfaire. Elle peut par exemple correspondre à la surveillance du niveau d énergie de l agent (ne pas passer en-dessous d un certain seuil) ou à un comportement d évitement des prédateurs (rester à une certaine distance d un prédateur). Les variables contraintes sont des caractéristiques de l agent, tels que son niveau d énergie ou sa position. Les contraintes primitives proposées pour la navigation sont les suivantes : in(region) : rester dans la zone définie par le paramètre region ; out(region) : rester en dehors de la zone ; go(object) : se diriger vers l endroit où se trouve un objet donné ; away(object) : s éloigner de l endroit où se trouve l objet ; attraction(stimulus) : se diriger vers l endroit où se trouve la source d un stimulus donné ; repulsion(stimulus) : s éloigner de l endroit où se trouve la source du stimulus. Ces primitives peuvent être définies à partir de quelques contraintes arithmétiques de base. La combinaison de ces primitives permet de décrire des comportements complexes de façon déclarative. Par exemple, un comportement de poursuite d un agent peut être obtenu en combinant les contraintes go et out de façon à se diriger vers un objet, tout en restant à une distance raisonnable. Les primitives ont été choisies car les méthodes de réparation associées peuvent être implémentées de façon très efficace. Le mécanisme de réparation doit proposer une action qui réduit petit à petit le degré de violation de la contrainte jusqu à ce qu elle soit satisfaite, à la façon des algorithmes

168 168 CHAPITRE 9. CONTRAINTES ET COMPORTEMENTS D AGENTS anytime. Résolution de contraintes-buts Les méthodes de recherche locale partent d une configuration choisie aléatoirement, puis explorent le voisinage de cette configuration pour s orienter vers la meilleure candidate ; ce processus est répété jusqu à ce qu une solution au problème soit trouvée. Dans le cadre des contraintes-buts, l action sélectionnée est celle qui satisfait au mieux l ensemble des contraintes ; la méthode de résolution est répétée tant qu il reste des contraintes non satisfaites. Les données en entrée de la méthode de recherche adaptative sont : un ensemble de variables ; un ensemble de contraintes-buts sur ; une fonction de coût à minimiser, typiquement le nombre de contraintes violées ; pour chaque contrainte, une fonction de calcul d erreur correspondant à une évaluation du degré de violation de la contrainte (score de la contrainte). La recherche adaptative va chercher à réduire l erreur sur la variable la moins satisfaite, dont le score est le plus élevé. Pour ne pas rester bloquée dans des minima locaux, cette méthode utilise le principe de la méthode de recherche taboue (Tabu search) : une variable menant à un minimum local est marquée de façon à ne plus être sélectionnée dans les itérations suivantes. L algorithme part d une configuration choisie aléatoirement (instanciation au hasard des variables de ), puis répète les phases suivantes, jusqu à ce qu une solution soit trouvée ou que le nombre maximal d itérations fixé soit atteint : 1. calculer les scores pour chaque contrainte de en combinant les scores de chaque variable contrainte ; 2. sélectionner la variable 1 ayant le score le plus élevé et calculer le coût de chacune des nouvelles instanciations possibles de 1 ; 3. s il n y a pas de meilleure valeur pour 1 alors marquer 1 comme étant taboue, sinon sélectionner la meilleure valeur et l affecter à la variable. Cette méthode très simple est naturellement compatible avec les problèmes surcontraints et les problèmes dynamiques ; elle se révèle de plus étonnamment efficace pour résoudre certains problèmes combinatoires complexes, tels que le carré magique. Cette méthode ne fait aucune planification a priori, puisque seules les valeurs possibles pour le pas de temps suivant sont prises en compte pour évaluer le coût d une solution (voisins immédiats). Une extension évidente de cette méthode consiste à considérer tous les voisins pour une distance donnée, de façon à prendre en compte les conséquences des actions successives dans le choix de l action à réaliser. La recherche adaptative permet ainsi de planifier une trajectoire, plus ou moins bonne en fonction du temps dont dispose la méthode pour résoudre le système de contraintes. 9.3 Contraintes et agents INVIWO Contraintes-buts Nous pouvons intégrer dans notre modèle la notion de contraintes-buts, ce type de contrainte se mêlant particulièrement bien avec notre approche réactive. Une contraintebut peut être décrite sous la forme d un module comportemental spécifique, possédant

169 9.3. CONTRAINTES ET AGENTS INVIWO 169 sa propre méthode de réparation ; nous avons donc défini un module facilitant la description des contraintes-buts en MARVIN. Lorsque la contrainte n est pas satisfaite, ce module émet le signal Error transportant une valeur comprise entre et ; cette valeur correspond à une évaluation du degré d insatisfaction de la contrainte. Le module possède par ailleurs trois méthodes sans paramètre, que l utilisateur doit redéfinir en fonction du comportement souhaité : la méthode satisfied() définit le but à satisfaire et retourne un booléen indiquant si ce but est satisfait ou non ; la méthode error() calcule le degré de violation de la contrainte ; la méthode réactive solver() définit la méthode de réparation itérative. Voici le corps du module goal_constraint prédéfini : body loop wait Tick with [ not self.satisfied () ] end wait ; abort loop self.solver () ; emit Error (self.error()) end loop when Tick with [ self.satisfied () ] end abort end loop end body Ce module attend tout d abord que la contrainte soit violée, en testant à chaque instant la garde correspondant à la négation du but. Dès que la contrainte est violée, la méthode de réparation est activée. Cette méthode est répétée à chaque instant jusqu à ce que la contrainte soit à nouveau satisfaite, ce qui est vérifié par la condition d avortement (dont la garde correspond au but). Pour que la contrainte définie soit respectée, il faut bien sûr que l action proposée par le module comportemental soit prise en compte en aval. À partir de ce module prédéfini, nous pouvons par exemple définir une contraintebut permettant de rester au-dessus d un agent donné : behaviour higher inherits goal_constraint out Add (float) ; id <- None ; method initialize (i) id <- i end method method goal () return [ owner.memory[id].position.z < owner.position.z ] end method

170 170 CHAPITRE 9. CONTRAINTES ET COMPORTEMENTS D AGENTS method error () return exp (-1.0 / (owner.memory[id].position.z - owner.position.z)) end method rmethod solver () emit Add (0.1) end rmethod end behaviour Notons que si l autre agent possède la contrainte-but lower opposée, consistant à essayer de rester toujours en-dessous d un agent donné, nous pouvons simuler une contrainte bidirectionnelle entre les deux agents. Une fois définies, les contraintes-buts peuvent par exemple être utilisées comme des sous-modules. Considérons une contrainte-but avoid_obstacle, dont la sortie Set lui permet d émettre une position à atteindre lorsque l obstacle qu elle surveille doit être évité. Le module défini ci-dessous permet d éviter un ensemble d obstacles détectés en utilisant plusieurs instances de cette contrainte : behaviour avoid_obstacles in Add (agent_id list), Remove (agent_id list) ; out Set (position_3d) combine with averagepositions ; constraints <- {:} ; body loop wait Add (obs) -> foreach o in obs do c <- new avoid_obstacle(o) ; link (c.set, Set) ; constraints.add(o, c) end foreach Remove (obs) -> foreach o in obs do constraints[o].abort() ; constraints.remove(o) end foreach end wait end loop end body end behaviour Les obstacles sont ajoutés et retirés dynamiquement; à chaque ajout, une contraintebut est créée pour se charger de l évitement de l obstacle. La fonction de combinaison définie pour le signal de sortie du module-père est indispensable, puisque plusieurs contraintes peuvent émettre une position au même instant. Ce module peut être utilisé de deux façons : à court-terme, pour gérer les évitements au fur et à mesure de la détection des obstacles, les contraintes étant retirées dès que l obstacle a été évité ; à long-terme, pour gérer l évitement d un agent à partir de la première rencontre et jusqu à ce que cet agent disparaisse du monde virtuel. Un obstacle rencontré auparavant sera déjà associé à une contrainte lorsqu il sera rencontré de nouveau.

171 9.3. CONTRAINTES ET AGENTS INVIWO 171 Notons que nous n utilisons pas la valeur du signal Error dans cet exemple ; les signaux en provenance des sous-modules arriveraient de toute façon avec un instant retard, ils ne pourraient donc pas être pris en compte pour la combinaison des signaux Set en sortie. Dans le cas de contraintes-buts indépendantes, le signal Error pourrait être utilisé par un effecteur pour combiner les actions de plusieurs contraintes en privilégiant par exemple la contrainte la moins satisfaite. La recherche adaptative ne peut pas être appliquée au modèle de contrainte-but défini précédemment car cette méthode nécessite de connaître pour chaque variable l ensemble des futures valeurs possibles ainsi que les erreurs associées. Il faudrait donc redéfinir les contraintes-buts de façon à ce qu elles puissent fournir une liste de valeurs possibles plutôt qu une unique valeur, ainsi que les erreurs associées à chacune de ces valeurs. La méthode de recherche adaptative pourrait alors être réalisée dans un module comportemental ou un effecteur particulier, qui récupérerait par exemple les propositions des contraintes-buts sous la forme de listes de couples > = = = Il est par ailleurs envisageable de reproduire le schéma de l architecture DAMN, en envoyant au module de recherche adaptative des propositions sous la forme de votes sur des actions discrétisées. Bien qu elle soit moins souple que l approche précédente, cette solution pourrait se révéler moins coûteuse en temps de calcul : les contraintes-buts n auraient plus à calculer l ensemble des valeurs possibles pour l instant suivant, mais seulement à envoyer pour chaque action définie leur degré d insatisfaction. Pour permettre à la méthode de faire un peu de planification, il faudrait encore une fois modifier la définition d une contrainte-but de façon à envoyer une liste de listes de couples > = = = ; la taille de cette liste correspondrait à la distance à prendre en compte pour calculer les voisins possibles. Pour que cette solution soit vraiment générique, il faut que la distance soit modifiable dynamiquement. Les signaux sont les seuls moyens disponibles pour communiquer avec un module comportemental, il faut donc que la contrainte-but puisse recevoir un signal correspondant à la nouvelle distance à prendre en compte. Un effecteur ne peut pas émettre de signal, il faut donc que la méthode de recherche adaptative soit réalisée dans un module comportemental utilisant un canal-retard pour émettre la prochaine distance à considérer Agents-contraintes Nous avons expliqué dans l introduction que les contraintes externes, influençant le comportement de plusieurs agents, peuvent être simulées en définissant dans chaque agent une contrainte semi-externe adaptée. Par exemple, les conséquences des contraintes-buts higher et lower définies précédemment se combinent naturellement de façon à ce que les deux agents contraints restent l un au-dessus de l autre. Il n est cependant pas toujours facile de décomposer une contrainte multidirectionnelle en plusieurs contraintes unidirectionnelles gérées indépendamment les unes des autres. Nous proposons une solution simple permettant de centraliser la gestion d une contrainte multidirectionnelle : il suffit de définir la contrainte sous la forme d un agent à part entière. Cette solution est intéressante en particulier lorsque la contrainte correspond à un objet graphique ; par exemple, dans le cas d une laisse entre un chien et son maître, la laisse représente une contrainte bidirectionnelle imposant une distance maximale entre les deux agents. Un agent-contrainte est chargé de gérer une contrainte externe, il vérifie donc que

172 172 CHAPITRE 9. CONTRAINTES ET COMPORTEMENTS D AGENTS cette contrainte est satisfaite à chaque fois qu il reçoit une mise à jour des attributs contraints. Si la contrainte n est pas satisfaite, il demande aux agents concernés de modifier leurs attributs conformément aux valeurs qu il a choisies, de façon à réduire le degré d insatisfaction de la contrainte. Un agent-contrainte peut bien sûr gérer plusieurs contraintes externes simultanément et ainsi centraliser la résolution d un système de contraintes Autres applications Contraintes structurelles Contrairement aux contraintes-buts, les contraintes structurelles sont des contraintes statiques fortes, qui ne doivent pas être violées. Ce sont des contraintes classiques, typiquement des domaines de valeurs définis pour les attributs de l agent. Un domaine de valeurs est une contrainte qui ne porte que sur une seule variable, il est donc possible d intégrer la gestion de ce type de contrainte au niveau de l effecteur chargé de mettre à jour l attribut concerné. Dans le cas de contraintes mettant en jeu plusieurs attributs, il n est par contre pas conseillé de regrouper leur gestion au sein d un même effecteur. Notre architecture de sélection de l action est volontairement distribuée, nous ne souhaitons pas obliger le concepteur à définir de gros arbitres spécialisés, regroupant la mise à jour d ensembles importants d attributs. De plus, à chaque nouvelle définition de contrainte structurelle, il faudrait vérifier que les attributs contraints sont bien manipulés par le même effecteur et, dans le cas contraire, modifier en conséquence la description de l agent. Pour cette raison, nous n avons pas poursuivi nos recherches dans ce sens. Il serait cependant intéressant d étudier à nouveau cette piste par la suite, car la définition de contraintes structurelles devrait faciliter la description de certains comportements, concernant par exemple la gestion des articulations d un corps animé. Cette étude pourrait mener à étendre le modèle d agent de façon à ajouter une couche de décision au-dessus du mécanisme d arbitrage. Contraintes pour l arbitrage Des systèmes de résolution de contraintes classiques (booléennes) et de contraintes souples pourraient être intégrés au niveau des arbitres, afin de faciliter la sélection d une action à partir de propositions et de préférences. Les contraintes floues permettraient en particulier de gérer les actions contradictoires, tandis que les contraintes booléennes permettraient de combiner des actions compatibles. Les propositions des modules comportementaux pourraient être des valeurs ou des domaines de valeurs, voire des ajouts et des retraits de contraintes. Il est possible de programmer un gestionnaire simpliste de contraintes en MARVIN pour l utiliser dans les arbitres. Cette solution serait acceptable pour gérer des domaines de valeurs sur un ensemble réduit d attributs, mais elle serait probablement peu efficace pour résoudre des contraintes plus complexes ou pour gérer un grand nombre de variables contraintes. Il serait plus intéressant d utiliser un résolveur de contraintes existant, comme GNU Prolog ou clp(fd, ). Cette intégration pourrait aussi se faire au-dessus du mécanisme d arbitrage, comme nous l avons indiqué précédemment.

173 9.4. SYNTHÈSE Synthèse Nous avons montré que la définition de contraintes peut faciliter la description de certains comportements, en particulier lorsqu il s agit de réaliser l arbitrage de propositions. Nous avons d autre part présenté le modèle de contraintes-buts et la méthode de résolution associée proposés par P. Codognet. Nous avons montré que ce modèle se marie fort bien avec notre architecture de sélection de l action et avec le langage MAR- VIN. En introduisant des contraintes-buts génériques sous la forme de modules comportementaux prédéfinis, nous facilitons la description de comportements en termes d objectifs à atteindre en utilisant une méthode de réparation itérative. Nous avons par ailleurs proposé d agentifier au besoin une contrainte externe, plutôt que de la décomposer en plusieurs contraintes semi-externes à répartir dans les agents concernés. Pour qu un agent-contrainte puisse effectivement influencer le comportement des agents contraints, il faut que ceux-ci acceptent de collaborer avec l agentcontrainte en lui fournissant les informations nécessaires et en suivant ses conseils. Enfin, il est intéressant de constater que l approche synchrone a été appliquée aux systèmes de résolution de contraintes, menant en particulier V. Saraswat et ses collègues à définir le langage TCC (Timed Concurrent Contraints) [124]. P. Codognet s est d ailleurs inspiré de ces travaux pour proposer le langage VRCC, introduisant les concepts de TCC au modèle d animation de VRML [51, 53].

174 174 CHAPITRE 9. CONTRAINTES ET COMPORTEMENTS D AGENTS

175 Cinquième partie Résultats 175

176

177 Chapitre 10 Implémentation et exemples 10.1 Introduction Avant de proposer le modèle décrit dans ce mémoire, nous avions conçu un premier modèle, qui a fait l objet d un prototype de plate-forme d exécution développé en JAVA, et grâce auquel nous avons réalisé l exemple de monde INVIWO présenté dans l introduction générale (le «monde des lapins»). Le noyau de cette première plateforme correspond à environ 5000 lignes de code pour une trentaine de classes définies. Le modèle actuel est moins complexe, plus générique et bien plus robuste que la version précédente, en particulier en ce qui concerne l architecture de sélection de l action. Notre second prototype implémente une grande partie du modèle présenté dans ce mémoire ; les paquetages principaux de ce prototype sont les suivants : InViWo.Basics : le noyau de la plate-forme, permettant de décrire des comportements d agents et de les exécuter ; InViWo.Communication : les classes liées à la communication entre agents et avec les interfaces utilisateurs ; InViWo.Examples : quelques exemples validant les choix d implémentation au fur et à mesure, et formant une suite de tests de non-régression. Le noyau de cette plate-forme, constitué d environ 150 classes pour lignes de JAVA, permet de décrire un agent à l aide des principales constructions disponibles dans le langage MARVIN. Le comportement d un agent est défini, au niveau de chaque composant comportemental, sous la forme d un arbre d instructions et d expressions à évaluer. La plate-forme est basée sur un modèle hybride, mêlant compilation et interprétation. L interface utilisateur du premier prototype a été implémentée à l aide de la bibliothèque JAVA AWT (Abstract Window Toolkit) pour la partie 2D de manipulation de l avatar, et de la bibliothèque JAVA3D pour la représentation 3D du monde virtuel. JAVA3D facilite la création d une scène 3D et la manipulation du point de vue de l utilisateur, le tout étant intégré au modèle événementiel d AWT. Bien que l utilisation de cette bibliothèque alourdisse considérablement l exécution du système, nous obtenons une réactivité tout à fait acceptable de la part des agents et de l avatar. Dans ce premier exemple, l avatar gérait directement l interface graphique, le modèle d avatar n étant pas entièrement défini au moment de la réalisation du prototype. Nous avons ensuite 177

178 178 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES repris et simplifié la partie 2D et 3D de l interface graphique pour obtenir un deuxième exemple complet présenté en section 10.4, dans lequel l avatar dialogue réellement par échange de stimuli avec l interface utilisateur. Dans l état actuel de la plate-forme, un monde INVIWO peut uniquement être constitué d agents s exécutant localement, cette configuration étant suffisante pour valider notre approche, c est-à-dire à la fois notre modèle d agents et d avatars INVIWO, notre architecture de sélection de l action, et les principales caractéristiques du langage MARVIN. Dans la suite de ce chapitre, nous nous intéresserons uniquement au prototype actuel. La documentation des classes de la plate-forme est disponible à l adresse suivante : MARVIN en JAVA Les constructions MARVIN, ainsi que les types prédéfinis et leurs opérations associées, sont implémentés sous la forme de classes spécifiques, à instancier successivement de façon à créer un arbre d instructions et d expressions formant un programme MARVIN exécutable en JAVA. Cette solution hybride (compilation vers JAVA puis interprétation de l arbre obtenu) nous permet de poser les bases d un compilateur et d un interpréteur du langage MARVIN ne nécessitant pas l utilisation du compilateur JAVA pour obtenir des agents exécutables. Si nous avions choisi de faire dériver les agents et leurs composants de classes abstraites, nous aurions par la suite eu besoin de deux compilateurs : le premier pour transformer le code MARVIN en description équivalente en JAVA, le deuxième afin d obtenir le byte-code JAVA correspondant aux nouvelles classes représentant les agents. Chaque expression ou instruction décrite en JAVA peut être traduite en MARVIN, afin de vérifier que l arbre défini manuellement correspond bien au programme MAR- VIN souhaité. Cet utilitaire permet par ailleurs de visualiser les éventuelles transformations appliquées au programme MARVIN (cf. sections et ). Nous avons par ailleurs utilisé le traducteur-générateur ANTLR [2], développé en JAVA, pour vérifier que le langage MARVIN ne comportait pas d ambiguïté lors de l analyse lexicale et syntaxique d un programme. La grammaire de la partie du langage définie grâce à cette application est reproduite en annexe A (page 205). Il est donc possible de parser un fichier contenant une description en MARVIN, et de créer l arbre de syntaxe abstraite associé ; en particulier, l exemple présenté en section 10.4 est entièrement parsable. Il n est cependant pas encore possible d obtenir automatiquement l instanciation des classes de la plate-forme correspondant à un programme MARVIN complet Types et objets prédéfinis Les types de valeurs prédéfinis disponibles sont : les types de base : entiers, réels à virgule flottante, booléens, chaînes de caractères et fonctions ; les conteneurs : listes, dictionnaires et n-uplets ; les identifiants d objets, d agents et d interfaces utilisateurs.

179 10.2. MARVIN EN JAVA 179 Les valeurs correspondant à ces types constituent les feuilles d un arbre d expressions, l évaluation de l une de ces valeurs retourne donc la valeur elle-même (par exemple, l évaluation de l entier 1 retourne l entier 1). Les principales opérations sur ces types sont également disponibles, en particulier les opérations arithmétiques sur les types numériques et les fonctions de manipulation des listes et des dictionnaires. Ces opérations sont implémentées sous la forme de fonctions prédéfinies. Une fonction est une valeur particulière, qui comporte un certain nombre de variables locales et de paramètres manipulés par le corps de la fonction, lui-même constitué d une séquence d instructions. Une fonction peut être évaluée de deux façons : en tant que valeur de base, l évaluation d une fonction retourne alors la fonction elle-même ; par un appel de fonction, en lui passant des arguments évalués et en exécutant le corps de la fonction. Nous avons nettement séparé l instruction effectuant un appel de fonction de l entité correspondant à la fonction elle-même ; cette solution nous permet d une part d éviter la recopie du corps de la fonction au niveau de chaque appel, et d autre part d effectuer des appels récursifs ou concurrents de fonctions 1. Voici par exemple le code MARVIN de la fonction factorielle (le code JAVA correspondant se trouve en annexe B, page 215) : function f (n) if n < 2 then return 1 else return f (n - 1) * n end if end function Cet exemple fait intervenir quelques instructions et mécanismes disponibles dans la plate-forme : la définition et l appel de fonction, la gestion des arguments d une fonction dans le cas d un appel récursif ou concurrent, le retour de résultat d une fonction, les opérations sur les entiers et l alternative classique. La partie orientée-objets du langage n étant pas clairement définie, il n est pas encore possible de décrire de nouvelles classes d objets, ni de définir ou de faire appel à des méthodes. Les conteneurs, les agents et les composants comportementaux sont des objets prédéfinis. La classe abstraite correspondant aux objets regroupe pour le moment des champs et des opérations communes aux objets prédéfinis, en particulier l identifiant de la valeur en tant qu objet MARVIN (object_id) et la gestion de variables locales à l entité (correspondant en quelque sorte à des champs d objets MARVIN). Le mécanisme de clonage d objets actuellement mis en place permet de proposer un langage orienté-objet basé aussi bien sur des classes, comme JAVA, SMALLTALK ou PYTHON, que sur des prototypes, comme LUA [83], JAVASCRIPT [9] ou SELF [10] (cf. section ). Pour les besoins des premiers exemples, nous fournissont de plus les types vector_3d et position_3d ainsi que certaines opérations associées à ces 1 Plusieurs composants comportementaux, éventuellement attachés à des agents différents, peuvent en effet utiliser la même fonction, ce qui devient délicat à gérer lorsque la fonction peut être retardée (cf. section ).

180 180 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES types, en attendant de pouvoir en faire de véritables objets MARVIN prédéfinis Instructions Pratiquement toutes les instructions MARVIN sont disponibles dans le prototype actuel : la séquence, c est-à-dire une suite d instructions séparées par un point-virgule; la boucle réactive (loop) ; l itérateur (foreach) ; la conditionnelle classique (if-then-else) et la conditionnelle réactive (present-then-else), qui doivent contenir au moins une conséquence ou une alternative ; la pause d un instant (pause) ; le bloc de règles (cf. sections et ) ; l affectation de variable (construction <-) ; la trappe nommée (trap-in), dont le corps contient une ou plusieurs instructions de sortie (exit) ; le bloc d avortement, immédiat ou retardé (when-abort et abort-when). La section rescue d un bloc d avortement n est cependant pas encore disponible ; l appel de fonction ; le retour de résultat dans une fonction (return) ; l émission de signal, pur ou valué (emit) ; les principales primitives d action utilisées dans un effecteur (set, esend et usend). Les corps d instructions telles que la boucle réactive ou le bloc d avortement sont des séquences d instructions. Notons que l itérateur foreach est construit à partir d une séquence d instructions MARVIN et d une boucle infinie particulière (définie seulement en interne), proche de la boucle réactive loop mais qui ne détecte pas les boucles instantanées. Voici le code MARVIN qui correspondrait à cette construction, avec l la liste sur laquelle se fait l itération, elt la variable d itération et <seq> le corps du foreach à insérer : trap T in var i <- 1 ; foreachloop if i > l.length then exit T end if ; elt <- l[i] ; <seq> ; i <- i + 1 end foreachloop end trap Par cette transformation du code MARVIN au niveau de l arbre sémantique, nous avons montré qu il était possible de décrire des constructions MARVIN de haut-niveau à partir de constructions plus simples. Une telle phase d expansion pourrait être généralisée pour ajouter facilement de nouvelles constructions de haut-niveau, par exemple pour décrire des contraintes-buts. L intérêt de ce type de transformation a entre autres

181 10.2. MARVIN EN JAVA 181 été démontré pour le compilateur ADA95 [54] Composants comportementaux Les trois types de composants comportementaux (capteurs, modules comportementaux et effecteurs) sont implémentés et la communication par signaux entre ces composants est entièrement réalisée. Chaque composant possède un ensemble de points de communication (slots), qui correspondent à des entrées et/ou à des sorties selon le type de composant. Une sortie peut être reliée à une entrée par un canal, contenant au plus un signal à un instant donné. Deux vérifications sont faites lors de la création d un canal : les types de la sortie et de l entrée doivent être compatibles, et il ne doit pas exister de canal reliant déjà cette sortie à cette entrée. Une entrée est utilisée par les déclencheurs de règles pour tester la présence d un signal, et au besoin pour récupérer la valeur d un signal valué présent pour l affecter à une variable locale (cf. section ) ; l entrée récupère alors les signaux émis sur tous les canaux connectés. Une sortie est utilisée par l instruction d émission de signal pur ou de signal valué, afin d envoyer le signal sur l ensemble des canaux connectés à la sortie. Il est possible de mettre en place des fonctions de combinaison de signaux en sortie pour un composant comportemental. Comme nous l avons évoqué en section , nous avons mis en place un mécanisme de clonage d objets, qui permettra au langage MARVIN d évoluer vers un langage orienté-objets basé soit sur des classes, soit sur des prototypes. Bien que nous séparions nettement la définition d un objet (en particulier d un composant comportemental) de son instanciation, le prototype (ou la classe) d un objet MARVIN et les instances de ce prototype sont représentés par le même objet JAVA, instance de la classe correspondant à la catégorie d objet (composant comportemental, agent, objet défini par l utilisateur). Par exemple, un prototype d effecteur est une instance de la classe JAVA MEffector, et une instance d effecteur est créée en appelant la méthode mclone() sur l objet JAVA représentant le prototype de l effecteur. Un composant comportemental est exécutable dès lors qu il est rattaché à une instance d agent ; le prototype lui-même peut devenir exécutable lorsqu il est associé à un agent, ce qui permet de s orienter vers un langage basé sur les prototypes. Il est aussi possible de considérer ce prototype comme une classe, auquel cas il ne peut pas être rattaché à un agent et la méthode mclone() devient le constructeur de la classe. Seul le corps du prototype d un composant est partagé entre les instances de ce composant. L instanciation d un composant correspond à un clonage en profondeur : les entrées et les sorties sont dupliquées, de façon à pouvoir être reliées dynamiquement à des canaux associés à l instance de composant. Les valeurs des variables globales à une instance de composant, ainsi que les valeurs des variables locales manipulées dans le corps partagé par les instances, sont conservées dans une pile gérée par l agent auquel l instance concernée est rattachée. En effet, au moment de la définition d une instruction utilisant une variable globale ou locale au niveau du corps d un composant, seul le prototype du composant est connu (ni l agent propriétaire ni l instance ne sont définis) ; c est donc à ce prototype que s adressent les variables pour accéder à leur valeur courante pendant l exécution. Afin de récupérer ou de modifier la valeur d une variable, le prototype peut alors retrouver

182 182 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES le composant en cours d exécution (lui-même ou l une de ses instances) en interrogeant l agent en cours d exécution, qui est obligatoirement le propriétaire du composant concerné. L agent en cours d exécution peut être connu en s adressant à la classe GlobalContext, capable de retrouver l agent associé au thread d exécution courant. Les variables globales à un composant comportemental sont initialisées en insérant des affectations au début du corps du composant ; une variable globale non initialisée lors de sa déclaration est automatiquement initialisée à None. Cette transformation permet en particulier de pouvoir relancer un composant dont l exécution est terminée, en s assurant que les variables seront correctement initialisées. L utilisation de variables anonymes, dont l identifiant commence par un point d interrogation, n est pas encore disponible. Nous n avons pas non plus implémenté la gestion de sous-modules comportementaux, ni les objets représentant des contraintes-buts correspondant à des modules comportementaux spécifiques. Cela ne remet toutefois pas en cause la base de notre modèle de modules comportementaux, d ores et déjà validée Les agents Un agent est composé d un ensemble d attributs, d un ensemble de composants comportementaux (capteurs, effecteurs et modules comportementaux) et d un gestionnaire de modules comportementaux. L agent centralise d une part la réalisation des primitives d actions concernant la modification de la structure et l envoi de stimuli, d autre part la réception des stimuli internes, externes et utilisateurs. Un attribut est une variable locale particulière d un agent, qui émet un stimulus interne (portant son nom) lorsqu elle est modifiée ; la modification d un attribut est réalisée par l instruction générique d affectation de variable, présente dans l arbitre d un effecteur. L agent gère par ailleurs le déclenchement des trois phases d une réaction complète : 1. la perception, c est-à-dire le déclenchement de la réaction de chaque capteur ; 2. la décision, c est-à-dire l appel au gestionnaire de modules comportementaux chargé d ordonnancer les modules avant de déclencher leur réaction ; 3. l action, c est-à-dire le déclenchement de la réaction de chaque effecteur. La communication entre agents est complètement réalisée, de même que la communication entre un avatar et une interface utilisateur. Les protocoles d interaction sont décrits en définissant des types de stimuli à partir d un nom de type (par exemple "S_position") et d un type de message, les types de valeurs étant pour le moment représentés sous la forme de chaînes de caractères (par exemple "tuple(float, float, float)"). Les agents sont exécutés dans des threads JAVA distincts de façon à simuler au mieux la répartition du monde virtuel. Chaque agent possède une horloge interne gérant le thread d exécution de l agent, et déclenchant les réactions successives selon un pas de temps de durée fixe. Les deux autres stratégies que nous avons proposées, à savoir le déclenchement par interruption (sur l arrivée d un stimulus) et en continu (dès que la phase d action est terminée), pourront être facilement introduites au niveau de cette horloge.

183 10.2. MARVIN EN JAVA 183 Les mécanismes d évolution de la structure d un agent sont implémentés au niveau de l agent et des composants, mais les primitives appelables depuis un effecteur pour ajouter, retirer ou modifier un composant ne sont pas encore disponibles. Ces mécanismes ne sont pas indispensables dans l état actuel, mais ils seront intéressants à mettre en œuvre lorsqu un générateur de code complet sera disponible, afin de tester en particulier les capacités de modification dynamique de code. La structure world correspondant à un monde contenant des agents et des avatars n est pas non plus implémentée. Toutefois, cela simplifie la création manuelle d un monde, en allégeant le programme JAVA à écrire : il suffit actuellement d enregistrer les couches de communication pour chaque agent, puis de lancer les agents instanciés pour qu ils commencent à interagir Expressions et instructions retardées Une expression ou une instruction contenant une pause ou un bloc de règles peut être retardée. Reprenons la fonction factorielle définie précédemment, et ajoutons lui une pause avant l appel récursif : function f (n) if n < 2 then return 1 else pause ; return f (n - 1) * n end if end function Il est par exemple possible d appeler cette fonction pour calculer une valeur de signal à émettre, dans le corps d un module comportemental ou dans le filtre d un capteur : emit O (f (5)) Le calcul de la valeur à émettre sera ainsi retardé. Pour pouvoir reprendre au même endroit et dans les mêmes conditions lors de la réaction suivante, il faut conserver l état de la fonction, c est-à-dire les valeurs courantes de ses variables locales et de ses arguments, ainsi qu un pointeur sur l instruction ayant causé le retard dans le corps de la fonction. L émission de signal est par ailleurs elle-même retardée, il faut donc aussi sauvegarder les états des instructions englobant l appel de la fonction, jusqu à remonter au composant comportemental. Pour cela, nous sauvegardons systématiquement le contexte des instructions qui le nécessitent, en particulier la séquence, le bloc de règles, l alternative, ou encore les opérations sur les types prédéfinis (pouvant faire appel à des fonctions retardées pour évaluer leurs arguments). Pour gérer les instructions et les expressions retardées, nous avons besoin de connaître l état d une instruction ou d une expression suite à son évaluation. Nous récupérons pour cela un code de retour d évaluation, signifiant que l instruction est terminée (Terminated) ou retardée (Delayed), qu elle a provoqué une erreur (ErrorStatus) ou qu elle a reçu l ordre de se terminer suite à une sortie de trappe (Exited).

184 184 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES Le code de retour indiquant la terminaison normale (sans erreur et sans sortie de trappe) transmet par ailleurs une valeur de retour, permettant de récupérer le résultat de l évaluation d une expression ou d un appel de fonction ; la valeur de retour par défaut d une instruction est None. Le code de retour indiquant un retard est accompagné du contexte à conserver puis à repasser à l instruction à la réaction suivante, de façon à pouvoir reprendre correctement l exécution. Le code correspondant à une sortie de trappe est accompagné de la liste des trappes levées simultanément, car plusieurs règles réactives parallèles peuvent demander à sortir au même instant de trappes imbriquées ; la trappe levée la plus englobante récupère ainsi l indication de sortie la concernant, et la transforme en un code de terminaison normale. Enfin, le code indiquant une erreur contient la référence de l instruction ou de l expression à l origine de l erreur, ainsi qu un message d explication (chaîne de caractères) Règles réactives Une règle se compose d un déclencheur et d une séquence d instructions ; le déclencheur est constitué d une expression de signaux et éventuellement d une garde. Notons qu une garde ne doit pas être retardée, car le rôle d un déclencheur est en premier lieu de tester la présence d un ou plusieurs signaux afin de lancer instantanément une séquence d actions associées. L expression booléenne d une garde ne doit donc pas faire appel à une fonction pouvant être retardée ; cette erreur est détectée et signalée à l exécution. L ensemble des expressions de signaux présentées dans le chapitre 8 sont disponibles, sous la forme d expressions simples et d opérations booléennes unaires et binaires portant sur des expressions de signaux (not, and, or, xor). Une expression de signal simple correspond au test de présence d un signal. Un test de signal est rattaché à une entrée, ce qui lui permet d une part de tester effectivement la présence du signal attendu sur cette entrée, d autre part de récupérer au besoin la valeur transportée par le signal s il est présent. Les quatre types de test de signal sont disponibles : la réception unique d un signal pur ou d un signal valué, ainsi que les deux cas de réception multiple. Une entrée permet de récupérer les valeurs des signaux reçus sous deux formes : 1. un dictionnaire de n-uplets, étiquetés sur les identifiants des émetteurs et contenant une ou plusieurs valeurs MARVIN simples ; 2. un dictionnaire de listes de n-uplets, étiquetées sur les identifiants des émetteurs. Le premier dictionnaire est utilisé aussi bien pour la réception unique que pour la réception multiple de type all...as ; dans le cas de la réception unique, seul le premier élément de ce dictionnaire sera affecté à la variable locale de la règle. Le deuxième dictionnaire correspond à la réception multiple de type all...aslists. Les règles réactives fonctionnent de la même façon pour un capteur, qui reçoit des stimuli, que pour un module comportemental ou un effecteur, qui reçoivent des signaux. Nous avons choisi d unifier les blocs de règles de type waitstim, associés aux capteurs, et les blocs de type wait, associés aux modules comportementaux et aux effecteurs. Nous considérons les stimuli comme des signaux particuliers, transmis par

185 10.3. COUCHE DE COMMUNICATION 185 les entrées cachées d un capteur. Une entrée cachée correspond à un type de stimulus, de la même façon qu une entrée normale (de module comportemental ou d effecteur) correspond à un type de signal. Une entrée cachée peut récupérer les stimuli reçus (du type attendu) en interrogeant le capteur. Une telle entrée possède exactement la même interface qu une entrée normale, ce qui permet d utiliser de façon transparente une expression de signaux portant sur des stimuli. Les étiquettes des dictionnaires récupérés sont soit des identifiants d agents ou d interfaces utilisateurs, soit des identifiants d objets MARVIN correspondant à des capteurs ou à des modules comportementaux Blocs de règles Les blocs de règles sont fonctionnels, y compris les blocs contenant des sous-blocs séparés par else et définissant des priorités entre ensembles de règles parallèles. Une règle réactive est toujours comprise dans un sous-bloc, lui-même inclus dans un bloc pouvant contenir d autres sous-blocs. Cette solution facilite grandement la réalisation, en particulier lorsqu il s agit de désactiver des règles et des sous-blocs suite au déclenchement de règles et de sous-blocs concurrents. Le bloc englobant (de type wait ou waistim) est retardé dès le premier instant, et, à partir du deuxième instant, jusqu à ce qu une règle (au moins) soit déclenchée dans l un des sous-blocs, auquel cas les autres sous-blocs sont désactivés. Dans un sous-bloc actif mais non encore déclenché, l évaluation d une règle retourne un code particulier (NotTriggered) si la règle n est toujours pas déclenchée ; si la règle est déclenchée, elle renvoie l un des codes décrits précédemment, en particulier pour indiquer que l action associée est retardée. Si aucune règle du sous-bloc n est déclenchée, le sous-bloc renvoie à son tour le code NotTriggered. Si aucun sous-bloc n est déclenché, le bloc indique qu il est toujours retardé et il devra évaluer à nouveau l ensemble de ses sous-blocs à l instant suivant. Si au moins une règle est déclenchée dans un sous-bloc, alors le sous-bloc doit fusionner les codes de retour de toutes les règles déclenchées afin de ne faire remonter qu un seul code au niveau du bloc englobant. Si une règle produit une erreur, alors cette erreur est propagée immédiatement (sans même attendre l évaluation des autres règles). Si une règle retourne un code Exited, alors les autres règles doivent être évaluées (avortement faible), et, quel que soit leur code de retour, seul le code Exited sera retourné 2. Si plusieurs règles ont fait appel à l instruction exit, alors le sous-bloc doit ajouter chaque référence de trappe levée à la liste transmise par le code Exited qu il doit retourner. Si au moins une règle est retardée et qu il n y a eu ni erreur ni sortie de trappe, alors le sous-bloc est retardé. Enfin, si toutes les règles déclenchées se sont terminées naturellement, alors le sous-bloc se termine également. Quel que soit le code renvoyé par le sous-bloc déclenché, le bloc transmettra ce code à l instruction englobante Couche de communication Notre modèle se veut complètement réparti, les agents INVIWO peuvent donc théoriquement être exécutés sur des machines ou des processeurs distincts, voire sur des 2 sauf si une erreur se produit lors de l évaluation de l une des règles restantes

186 186 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES plates-formes développées dans des langages ou sur des systèmes différents. Cette répartition et cette diversité doivent être gérées de façon transparente, afin de ne pas avoir à les prendre en compte au niveau de la description du comportement d un agent. Pour que le modèle abstrait d agents communiquant par échange de stimuli externes soit conservé, il faut en pratique que les capteurs et les effecteurs puissent s adresser à une entité abstraite capable effectivement de réceptionner et de transmettre des messages. Cette entité est appelée couche de communication de l agent ; elle est implémentée sous la forme d une classe abstraite (CommunicationLayer) figeant l interface entre le modèle d agent et le «monde réel». Les méthodes de cette classe permettent à un agent d une part d envoyer un stimulus en unicast ou en broadcast, d autre part de récupérer les stimuli reçus depuis le début de la réaction précédente afin de déclencher un nouveau cycle perception-décision-action. La méthode abstraite sendto(stimulus s, Id to) est appelée par les deux méthodes d envoi de stimulus ; elle doit être concrétisée dans les sous-classes de CommunicationLayer afin de réaliser l envoi de stimulus à un agent ou à une interface utilisateur en fonction du type de communication choisi. Il est possible de définir n importe quel type de communication bas-niveau (transmission des messages contenant ou représentant les stimuli émis), à condition de respecter l interface de la couche de communication abstraite. Puisque les mondes IN- VIWO sont pas encore véritablement répartis, nous fournissons pour l instant uniquement une couche de communication basée sur des appels locaux de méthodes. La classe ByMethodCall, dérivée de CommunicationLayer, implémente la méthode sendto de façon à ce qu elle appelle la méthode receive(stimulus s) de la couche destinataire. La communication entre un avatar et une interface utilisateur est réalisée de la même façon, par l intermédiaire d une couche de communication distincte ; il n y a en effet pas de raison d imposer que les communications de bas-niveau entre agents et avec les utilisateurs utilisent les mêmes mécanismes. Un agent possède donc au moins une couche de communication, lui permettant d interagir avec les autres agents, et il peut en posséder une deuxième permettant la communication avec l interface utilisateur Un exemple complet L exemple suivant, surnommé Bizarre Love Triangle, fait intervenir trois agents : un agent mobile (attracted_agent), un agent immobile (target_agent) et un avatar (avatar). L agent mobile est attiré par l agent immobile, il essaie donc de se rapprocher de sa position, pendant que l avatar espionne la scène sans se faire remarquer. Nous supposons que l avatar est associé à une seule interface utilisateur. Cet exemple très simple fait partie de la suite de tests de non-régression. Il nous permet de valider la plupart des fonctionalités orientées-agents du langage MARVIN : la description de protocoles d interaction, la description et l instanciation de composants comportementaux, la description d agents et d avatars, la création de canaux de communication et la définition de blocs de règles réactives. Le programme JAVA correspondant à cet exemple est donné en annexe B, page 215.

187 10.4. UN EXEMPLE COMPLET Les protocoles d interaction Pour que nos trois agents puissent communiquer entre eux, il faut tout d abord définir le protocole d interaction entre agents. Les deux caractéristiques d agents utiles dans notre exemple sont : la forme d un agent, pour que l interface utilisateur affiche une représentation 3D adéquate ; la position d un agent, afin d une part que l agent mobile connaisse la position à atteindre, d autre part que l avatar transmette les positions des agents espionnés pour que l interface utilisateur puisse les placer correctement dans sa représentation 3D. L avatar voulant rester invisible, il n envoie jamais sa position aux autres agents. La forme d un agent est simplement une chaîne de caractères, interprétée par l interface utilisateur pour choisir une représentation 3D. La position d un agent est du type prédéfini position_3d : estim S_shape (string) ; estim S_position (position_3d) ; Il faut aussi définir le protocole d interaction entre l avatar et l interface utilisateur. L avatar doit transmettre la position et la forme des autres agents, pour que l interface puisse les représenter. L avatar doit aussi indiquer sa propre position, de façon à positionner correctement la vue subjective sur la scène 3D. Enfin, l utilisateur peut demander à déplacer cette vue pour suivre le trajet de l agent mobile, l interface utilisateur peut donc envoyer un stimulus demandant à l avatar de modifier sa position : ustim U_other_position (agent_id, position_3d) ; ustim U_other_shape (agent_id, position_3d) ; ustim U_avatar_position (position_3d) ; ustim U_set_position (position_3d) ; L agent mobile L agent mobile possède trois attributs : sa forme (une chaîne de caractères), sa position et son pas de déplacement. Il possède également les instances de chacun des composants comportementaux suivants : un capteur lui permettant de surveiller la position à atteindre, un module comportemental qui tente d atteindre cette position en choisissant la prochaine valeur de sa propre position, et un effecteur modifiant sa position. Au tout premier instant de l agent (à son lancement), les canaux reliant les composants comportementaux sont créés, et deux stimuli transmettant la forme et la position initiale sont envoyés en broadcast : agent attracted_agent attribute shape <- "cube" ; attribute position <- new position_3d (0.0, 0.0, 0.0) ; attribute step <- 0.2 ; sensor ts <- new target_sensor () ; behaviour rt <- new reach_target () ; effector pe <- new position_effector () ;

188 188 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES body link (ts.targetposition, rt.target) ; link (rt.setposition, pe.set) ; esend S_shape (shape) ; esend S_position (position) end body end agent Le capteur de l agent mobile attend simplement le stimulus indiquant la position de l agent cible, en supposant qu aucun autre agent n envoie sa position. Quand ce stimulus est reçu, un signal est émis pour indiquer la nouvelle position de la cible : sensor target_sensor out TargetPosition (position_3d) ; filter loop waitstim S_position (position) -> emit TargetPosition (position) end waitstim end loop end filter end sensor Le module comportemental doit proposer une nouvelle position pour l agent mobile, en fonction de la position courante de la cible. Il faut donc conserver cette position, et prendre en compte un éventuel signal indiquant qu elle a été modifiée. Pour plus de lisibilité, nous encapsulons le choix de la prochaine position dans une fonction locale au module, qui prend en paramètre la position courante, la position à atteindre et un pas de déplacement : behaviour reach_target in Target (position_3d) ; out SetPosition (position_3d) ; var target ; function choose (pos1, pos2, step) var displacement <- new vector_3d (pos1, pos2) ; displacement <- displacement.normalize () ; displacement <- displacement.multiply (step) ; return pos1.add (displacement) end function body loop wait Target (position) -> [ target <- position ] else Tick end wait ; if target /= None then emit SetPosition (choose (owner.position, target, owner.step)) end if end loop end body end behaviour

189 10.4. UN EXEMPLE COMPLET 189 Lorsqu il en reçoit la demande, par l intermédiaire du signal Set, l effecteur de l agent mobile modifie la position de l agent et indique cette modification à l ensemble des autres agents : effector position_effector in Set (position_3d) ; arbiter loop wait Set (position) -> set (owner#position, position) ; esend S_position (position) end wait end loop end arbiter end effector L agent immobile L agent cible envoie son état initial, puis ne réagit à aucun stimulus, interne ou externe. Il ne possède donc pas de capteur, d effecteur ou de module comportemental ; nous l avons doté de deux attributs, mais il était aussi possible d envoyer directement les valeurs initiales : agent target_agent attribute shape <- "light" ; attribute position <- new position_3d (10.0, 0.0, 10.0) ; body esend S_shape (shape) ; esend S_position (position) end body end agent L avatar L avatar transmet à l interface utilisateur les informations obtenues en espionnant les deux autres agents. Il doit de plus modifier sa position quand l utilisateur le demande, et il doit enfin indiquer à cet utilisateur sa position initiale et toute modification de cette position. Ces opérations très simples peuvent être réalisées en définissant seulement un capteur et un effecteur. Les identifiants des agents à espionner sont donnés à l avatar à sa création, par l intermédiaire d un constructeur spécifique. Cet avatar possède un capteur et un effecteur, ainsi que trois attributs : sa position et les identifiants des deux agents à surveiller. Au moment de son lancement, l avatar crée les canaux nécessaires entre son capteur et son effecteur, et envoie sa position initiale à l interface utilisateur :

190 190 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES agent avatar attribute position <- new position_3d (5.0, 5.0, 5.0) ; attribute attracted_id ; attribute target_id ; sensor avsens <- new avatar_sensor () ; effector aveff <- new avatar_effector () ; method initialize (id1, id2) attracted_id <- id1 ; target_id <- id2 end method body link (avsens.setposition, aveff.setposition) ; link (avsens.gotposition1, aveff.forwardposition1) ; link (avsens.gotshape1, aveff.forwardshape1) ; link (avsens.gotposition2, aveff.forwardposition2) ; link (avsens.gotshape2, aveff.forwardshape2) ; usend U_avatar_position (position) end body end agent Nous avons regroupé l ensemble des attentes de stimuli, externes et utilisateurs, dans un seul capteur. Nous avons fait la supposition que l avatar ne communiquait qu avec une seule interface utilisateur, un seul ordre de déplacement peut donc être reçu à un instant donné. Si l interface émet des stimuli plus rapidement que l avatar n est capable de les traiter, seul le dernier stimulus reçu sera pris en compte. Par contre, les stimuli externes en provenance des deux autres agents doivent être traités en prenant en compte la réception multiple ; le dictionnaire récupéré lorsqu un stimulus de type S_position ou S_shape est présent contient les dernières valeurs reçues pour chaque émetteur : sensor avatar_sensor out SetPosition (position_3d) ; out GotPosition1 (position_3d), GotShape1 (string) ; out GotPosition2 (position_3d), GotShape2 (string) ; filter loop waitstim U_set_position (position) -> emit SetPosition (position) all S_position as positions -> foreach id in positions.keys() do if id = owner.attracted_id then emit GotPosition1 (positions[id]) end if ; if id = owner.target_id then emit GotPosition2 (positions[id]) end if end foreach

191 10.5. SYNTHÈSE 191 all S_shape as shapes -> foreach id in shapes.keys() do if id = owner.attracted_id then emit GotShape1 (shapes[id]) end if ; if id = owner.target_id then emit GotShape2 (shapes[id]) end if end foreach end waitstim end loop end filter end sensor L effecteur modifie la position de l avatar en fonction des demandes de l utilisateur, et transmet à l interface utilisateur les positions et les formes des autres agents lorsqu elles sont mises à jour : effector avatar_effector in SetPosition (position_3d) ; in ForwardShape1 (string), ForwardPosition1 (position_3d) ; in ForwardShape2 (string), ForwardPosition2 (position_3d) ; arbiter loop wait SetPosition (position) -> set (owner#position, position) ; usend U_avatar_position (position) ForwardShape1 (shape) -> usend U_other_shape (owner.attracted_id, shape) ForwardPosition1 (position) -> usend U_other_position (owner.attracted_id, position) ForwardShape2 (shape) -> usend U_other_shape (owner.target_id, shape) ForwardPosition2 (position) -> usend U_other_position (owner.target_id, position) end wait end loop end arbiter end effector 10.5 Synthèse Nous avons validé notre approche par l implémentation de deux prototypes. Le premier prototype a permis de montrer la viabilité de notre modèle d agents communiquant par envoi de stimuli, ainsi que l intérêt de pouvoir décrire un avatar semiautonome de la même façon qu un agent purement autonome. Le deuxième prototype nous a permis de réaliser complètement notre modèle d avatar, et de valider une partie de notre architecture de sélection de l action (hormis les sous-modules) ainsi que la plupart des caractéristiques originales du langage MARVIN. Nous avons de plus prouvé

192 192 CHAPITRE 10. IMPLÉMENTATION ET EXEMPLES que le langage MARVIN est parsable, nous avons donc démontré que le modèle et le langage que nous proposons sont réalisables. À travers des exemples, nous avons pu montrer l intérêt de la généricité et de l homogénéité de notre modèle, ainsi que la facilité de description de comportements en MARVIN.

193 Sixième partie Conclusion et perspectives 193

194

195 Chapitre 11 Conclusion Nous pensons que le modèle INVIWO et le langage MARVIN constituent des bases solides pour la mise en œuvre d outils graphiques dédiés à la conception de mondes virtuels habités, axés sur la description de comportements des créatures virtuelles et des avatars peuplant ces mondes. Nos sources d inspiration proviennent de deux domaines de l informatique pourtant éloignés mais ayant pour intersection le besoin et la volonté de décrire des systèmes autonomes devant réagir à leur environnement : l Intelligence Artificielle et le domaine des systèmes temps-réels. Nous nous sommes donc intéressés aux travaux concernant : les agents autonomes et les systèmes multi-agents ; l approche réactive de l IA et les architectures de sélection de l action basées sur les comportements ; les langages et les systèmes réactifs synchrones. À partir de cet état de l art, nous avons proposé le modèle INVIWO, ainsi que le langage MARVIN pour la description de mondes et d agents conformes à ce modèle. Le modèle INVIWO se compose de trois sous-modèles : un modèle d agent autonome, basé sur un ensemble minimal de composants constituant une structure entièrement dynamique ; un modèle d avatar, considérant un avatar comme un agent à part entière, plus ou moins contrôlé par un opérateur humain via une interface utilisateur quelconque ; un modèle de monde virtuel habité constitué uniquement d agents communicants 1 (agents autonomes et avatars), c est-à-dire considéré comme un système multi-agents uniforme. Notre modèle d agent n est pas aussi généraliste que celui de la plate-forme MAD- KIT par exemple, qui manipule des agents communicants sans se préoccuper de l architecture de ces agents. Le modèle d agent INVIWO reste cependant simple ; il a été conçu pour représenter clairement les différents composants nécessaires et suffisants pour décrire le comportement réactif d un agent (capteurs, effecteurs, attributs et modules comportementaux), de façon à faciliter la compréhension et la conception d un agent. 1 Ils sont purement communicants dans le sens où ils interagissent uniquement par échange de messages. Au niveau de la description du comportement, cette caractéristique peut être ignorée pour ne conserver que l aspect situé des créatures définies. 195

196 196 CHAPITRE 11. CONCLUSION Les capteurs internes et externes sont fusionnés, afin de traiter indistinctement les événements internes et externes et de fournir des percepts combinant ces événements. De même, nous ne distinguons pas les effecteurs internes des effecteurs externes, afin de regrouper les actions liées à un même composant au niveau d un même effecteur, que ces actions soient internes ou externes, présentant ainsi une interface unique de proposition d actions abstraites concernant ce composant. Pour les mêmes raisons, les capteurs et les effecteurs chargés de l interaction avec l utilisateur sont fusionnés aux capteurs et effecteurs de l agent INVIWO, intégrant ainsi complètement et naturellement cette interaction au sein de l avatar INVIWO. Concernant la description de comportements proprement dite, nous proposons d une part une architecture de sélection de l action et d autre part le langage MARVIN : notre architecture de sélection de l action, basée sur les comportements et intégrant un mécanisme d arbitrage, est inspirée des réseaux de processus réactifs et du modèle d objets synchrones ; MARVIN est un langage dédié à la description d agents INVIWO. Il est fortement inspiré de la syntaxe du langage ESTEREL, à laquelle nous avons ajouté des caractéristiques orientées-objets et orientées-agents permettant de décrire à la fois la structure et le comportement d agents INVIWO et les données manipulées par ces agents. Le mécanisme d arbitrage est souple et générique. En particulier, un arbitre, associé à un effecteur, peut encapsuler n importe quelle fonction de sélection, contrairement à des architectures spécifiques comme les schèmes moteurs de R. Arkin ou l architecture DAMN. Un tel arbitre permet aussi bien de sélectionner une action parmi plusieurs propositions, selon la technique du winner-take-all, que de combiner les propositions pour créer une action ad-hoc. Le processus de décision d un agent est un système synchrone, formé d un ensemble de modules comportementaux concurrents, de capteurs et d effecteurs interconnectés, communiquant par signaux et partageant la même notion d instant. Cette approche permet en particulier de garantir le déterminisme du comportement décrit. Les modules comportementaux, quelle que soit leur complexité interne, sont considérés de façon homogène au niveau de la description du comportement. Comme dans le modèle HPTS, il est possible de définir récursivement des modules à partir d autres modules (définis de la même façon), tout en conservant les propriétés synchrones du système. Cette caractéristique présente l avantage de faciliter considérablement la description graphique et la maintenance, par l encapsulation de réseaux comportementaux dans des modules de plus haut-niveau, sans introduire de retard. Enfin, le langage MARVIN permet de décrire des agents INVIWO selon notre architecture de sélection de l action, c est-à-dire sous la forme de modules comportementaux concurrents, de capteurs associés à des filtres et d effecteurs contenant des arbitres chargés de résoudre les éventuels conflits. La description des comportements est elle aussi homogène, en particulier la description d un capteur ou d un effecteur est fortement similaire à la description d un module comportemental. Les règles réactives parallèles permettent de décrire l attente simultanée d événements déclenchant des réactions distinctes.

197 197 Les langages synchrones comme ESTEREL ont introduit une nouvelle façon de programmer des systèmes temps-réel ; avec le langage MARVIN, nous proposons d utiliser la programmation réactive pour décrire des comportements d agents autonomes, en particulier des comportements de créatures virtuelles. Le parallélisme est manipulé de manière simple, sous la forme de règles réactives parallèles et de modules comportementaux concurrents. Les modules comportementaux s exécutent naturellement au même rythme, de façon déterministe, sans que le concepteur ait à contrôler lui-même l ordonnancement de ces modules. Le langage MARVIN incite le concepteur à penser en termes de boucles comportementales permettant de réagir de façon continue à des événements, selon des échelles temporelles différentes. Il incite aussi à décomposer le comportement de l agent en pas de réaction successifs, pour lesquels il faut programmer des séquences d actions courtes, éventuellement selon un algorithme anytime. Ces caractéristiques nous semblent particulièrement adaptées à la description de comportements d agents autonomes devant réagir continuellement à un environnement changeant et imprévisible. Les qualités principales du modèle INVIWO et du langage MARVIN sont les suivantes : 1. la solidité et la simplicité de leurs fondements ; 2. l homogénéité, conservée volontairement à tous les niveaux ; 3. la dynamicité de l architecture d un agent, tant du point de vue de sa structure (ajout, retrait et modification des composants) que de son architecture de sélection de l action (modifications des connexions entre les modules comportementaux, les capteurs et les effecteurs) ; 4. l expressivité du langage MARVIN, provenant d une part de l expressivité du langage ESTEREL et d autre part de la simplicité de définition des règles réactives parallèles ; 5. l introduction d une nouvelle façon de décrire des comportements d agents autonomes, selon une approche réactive synchrone. Malheureusement, le langage MARVIN n est pas encore entièrement défini, ce qui empêche pour le moment d une part le développement d un compilateur ou d un interpréteur complets, d autre part la conception de l atelier graphique, basé sur le langage pour la partie concernant la programmation graphique de comportements. En l état, MARVIN permet d ores et déjà de spécifier le comportement d un agent INVIWO, en décrivant des modules comportementaux basés sur des règles réactives. Un interpréteur permettrait de valider l utilisation de ce langage pour la conception complète de mondes INVIWO, ou pour le prototypage de systèmes multi-agents basés sur des agents communicants réactifs. Les principales limites de notre modèle sont les suivantes : 1. les agents INVIWO sont parfaitement autonomes, dans le sens où aucune entité ne peut modifier l état interne d un agent ou influencer son comportement sans son accord. Cela nous permet de décrire des mondes complètement répartis, dans lesquels les décisions sont prises localement au niveau de chaque agent. En contrepartie, la cohérence globale d un monde INVIWO n est pas garantie ; 2. nous avons choisi une approche impérative, car il nous semble plus pertinent de décrire des réactions à des événements plutôt qu à des flux de données pour définir le comportement d un agent. Rien n est prévu pour gérer des flux comme

198 198 CHAPITRE 11. CONCLUSION le son ou la vidéo, ce qui peut être un frein à l utilisation de nos outils lorsqu il s agira de traiter des conversations orales ou les informations en provenance d une caméra sur un robot ; 3. notre architecture d agent ne présente pas de capacités cognitives explicites. Ces capacités doivent être introduites au niveau d une chaîne comportementale d un agent, par exemple en définissant un attribut correspond à une carte cognitive et des capteurs, effecteurs et modules comportementaux chargés de mettre à jour cette carte ; 4. nous ne nous sommes pas préoccupés de l animation complexe d un agent, par exemple de l animation de différentes parties de son corps ou des déformations de sa géométrie. L extrême simplicité de notre modèle d agent pourrait alourdir énormément la description de ce type d animations. La première limite citée implique en particulier que nous ne prenons absolument pas en compte les contraintes fortes qui peuvent influencer le comportement des agents. Nous ne gérons en particulier pas les conséquences des lois physiques gouvernant le monde réel telles que la gravité ou la détection précise de collisions. Ces lois peuvent être gérées individuellement par chaque agent, mais rien ne garantit a priori qu elles seront respectées par tous les agents. Les agents INVIWO doivent donc être conçus de façon à s intégrer dans un monde en particulier, soumis à certaines contraintes qu il doit prendre en compte lui-même. Nous proposons dans le chapitre suivant quelques pistes qui permettraient de résoudre en partie les inconvénients que nous avons énoncés.

199 Chapitre 12 Perspectives L atelier INVIWO L objectif final de notre travail reste la mise en œuvre d un atelier graphique de conception de mondes virtuels habités, permettant en particulier la programmation graphique de comportements d agents INVIWO. Il faut donc en priorité terminer la spécification du langage MARVIN (partie orientée-objets), afin de pouvoir finir le développement de l interpréteur. Il sera alors possible de concevoir un premier prototype d atelier graphique, basé sur le langage MARVIN. À partir de modules comportementaux prédéfinis, nous pourrons valider la description de comportement par assemblage de composants INVIWO. La plupart des outils de création de SMA actuels permettent au concepteur de visualiser immédiatement le résultat de son travail ; cette fonctionnalité devra évidemment être intégrée à l atelier INVIWO, en particulier pour espionner les agents, par exemple en affichant leur état et en archivant les stimuli échangés. Pour aller plus loin et faciliter le débogage, il nous semble intéressant de suivre la trace de la plate-forme ORIS, avec laquelle le concepteur peut faire du prototypage dynamique en modifiant le comportement des entités pendant leur exécution. Cette fonctionnalité pourrait être mise en œuvre en intégrant l interpréteur MARVIN au niveau des agents, permettant ainsi le chargement dynamique de code. Les agents doivent donc pouvoir s exécuter et être modifiés dynamiquement pendant leur conception, créant ainsi une instance particulière et temporaire de monde INVIWO. Ce monde pourrait être une simulation de monde INVIWO dans laquelle la structure et le comportement des agents seraient manipulés directement par le concepteur à partir de l atelier. Il nous semble cependant beaucoup plus intéressant de considérer l atelier INVIWO comme l ultime exemple de monde INVIWO, dans lequel l utilisateur est le concepteur, représenté par son avatar. Les agents participant au débogage et au prototypage dynamique doivent posséder les capacités nécessaires, c est-à-dire les composants leur permettant de recevoir et de traiter des ordres spécifiques à l espionnage et au chargement dynamique de code, sous la forme de stimuli externes. Il est également possible de considérer les agents en cours de conception comme des avatars, dont l interface utilisateur est intégrée à l atelier ; cette approche se rapproche de celle de la plate-forme MADKIT. Un monde INVIWO étant par essence multi-utilisateurs, 199

200 200 CHAPITRE 12. PERSPECTIVES il est parfaitement envisageable de proposer un atelier INVIWO multi-utilisateurs, permettant le prototypage collaboratif de mondes virtuels habités. Une extension intéressante de l architecture de sélection de l action consisterait en la mise en œuvre de chaînes comportementales hétérogènes, c est-à-dire contenant des modules comportementaux, des capteurs et des effecteurs non décrits en MARVIN. Ces composants comportementaux pourraient être programmés directement dans le langage de la plate-forme, sous la forme de «modules natifs». L intégration serait possible à condition que ces modules possèdent une interface compatible avec notre modèle et qu ils garantissent un temps de réponse raisonnable, en accord avec la réactivité de l agent. Pour lever cette contrainte et ainsi faciliter l introduction de bibliothèques classiques existantes (non réactives), il faudrait étudier la mise en œuvre de tâches asynchrones en MARVIN et au sein de notre architecture de sélection de l action. L inconvénient de cette extension est évidemment de rendre les agents ainsi définis dépendants d une plate-forme d exécution et de son langage d implémentation; ils deviendraient ainsi moins portables que s ils étaient uniquement décrits en MARVIN. L avantage est principalement d intégrer des modules difficiles à décrire en MARVIN ou peu efficaces sous cette forme (réseaux neuronaux, systèmes de classeurs, recherche adaptative, etc.). Malgré le manque de portabilité, cela permettrait d augmenter les capacités des agents pour des applications spécifiques. Il est aussi tout à fait envisageable que ces modules fassent l objet d une connexion avec un autre langage, afin d intégrer des bibliothèques existantes. Cela permettrait en particulier d intégrer un véritable résolveur de contraintes au niveau des arbitres, par exemple en réalisant binding avec GNU PROLOG ou clp(fd, ). Étendre le modèle INVIWO et le langage MARVIN Dans la conclusion générale, nous avons cité quatre limites du modèle INVIWO : 1. le manque d organisation des agents et le manque de contrôle sur leur exécution, dûs à une autonomie extrême ; 2. l absence de traitement des flux de données ; 3. l absence de capacités cognitives explicites ; 4. la difficulté de mettre en œuvre des animations complexes. En ce qui concerne le premier point, il faut évidemment que le concepteur développe des agents à la fois honnêtes et obéissants. Les agents doivent donc être programmés de façon à : fournir régulièrement des informations correctes les concernant afin de garantir la cohérence globale du monde vis-à-vis des informations publiques, nécessaires aux autres agents ; accepter de prendre en compte des ordres et des demandes de service, correspondant par exemple au respect de la loi de la gravité. Une fois ces caractéristiques garanties, il est envisageable de mettre en place une organisation des agents, en concevant des agents chargés des tâches administratives, telles que la gestion de la base des données publiques ou l optimisation des communications par le pré-filtrage des stimuli. Cette organisation pourrait amener à simuler une sorte d entité «environnement», éventuellement répartie dans plusieurs agents, dont

201 201 le rôle serait de garantir le respect des lois physiques et sociales du monde. Il serait très intéressant d étudier une telle organisation en utilisant le modèle AALAADIN, par exemple en intégrant notre modèle d agent INVIWO dans la plate-forme MADKIT. Cette solution faciliterait par ailleurs la mise en œuvre de la communication par diffusion restreinte (multicast), puisque, dans le modèle AALAADIN, la communication entre agents est limitée au sein des groupes. Pour aller plus loin dans l étude de ce problème d organisation, il serait intéressant d étudier à nouveau la mise en œuvre de sous-agents, contrôlés par un agent-père ; cela permettrait par exemple de contrôler séparément plusieurs parties du corps d une créature et faciliterait éventuellement la description d animations complexes. Notons que la communication asynchrone entre agents, dûe à l autonomie voulue des agents INVIWO, pourrait constituer une difficulté importante à la mise en œuvre efficace de sous-agents ; cette difficulté n apparaît pas au niveau la communication entre modules et sous-modules, puisque cette communication synchrone est à la fois déterministe et bornée au cours d un instant. Deux problèmes sont à distinguer concernant la gestion des flux de données dans notre modèle : le problème de la présentation d informations provenant d un flux de données à l utilisateur ; le problème du traitement de flux de données par un agent. Le premier problème dépend uniquement des fonctionnalités de l interface utilisateur, il doit donc être résolu par le concepteur de l interface. Une solution envisageable serait d introduire des URL (Uniform Resource Locators) dans un protocole d interaction entre un avatar et une interface utilisateur, ces URL pouvant pointer en particulier sur des sources de type flux audio ou vidéo que l interface est capable de présenter à l utilisateur. Le deuxième problème remet en cause le choix que nous avons fait d un modèle basé sur la prédominance du flot de contrôle. Pour intégrer le traitement de la parole ou le traitement d images animées en provenance d une caméra, il faut étudier l opportunité d étendre notre modèle, en s inspirant de travaux mêlant le traitement par flots de contrôle et flots de données tels que le modèle d agent MALEVA 1 [98] et le modèle multi-formalismes LEA 2 pour la conception de systèmes synchrones [32]. Notre architecture d agent INVIWO, plutôt prévue pour des agents réactifs, pourrait rendre délicate la mise en œuvre de capacités cognitives. Il est envisageable d une part d étendre le modèle d agent INVIWO, d autre part d étendre le langage MARVIN ou de concevoir un langage de plus haut niveau. Ces deux solutions sont éventuellement combinables, de façon à permettre au concepteur de décrire les composants supplémentaires des agents dans le nouveau langage ou dans la version étendue de MARVIN. L extension du modèle d agent INVIWO pourrait se faire par l ajout de couches, de façon similaire à la plupart des architectures d agents hybrides. Il faudrait dans ce cas étudier la possibilité de définir les composants supplémentaires en fonction des composants actuels. De même, dans le cas de la définition d un nouveau langage, il faudrait 1 La plate-forme MALEVA est basée sur une approche componentielle de la conception d agents, fondée sur la séparation entre le flot de contrôle et le flot de données entre composants constituant le comportement de l agent. 2 Le modèle LEA repose sur les formalismes de LUSTRE, ESTEREL et ARGOS, ce qui explique l acronyme.

202 202 CHAPITRE 12. PERSPECTIVES étudier la possibilité de traduire les descriptions de niveau supérieur en MARVIN. Il serait en particulier intéressant d étudier de façon plus approfondie la description de comportements cognitifs par des contraintes de haut-niveau, facilitant la planification et le raisonnement sur des informations partielles. L extension de MARVIN comme la définition d un langage au-dessus de MARVIN pourraient par ailleurs s inspirer du langage proposé par K. Perlin pour le système IM- PROV [107] ou du langage CML de modélisation cognitive de J. Funge [66]. Le langage CML facilite la description de connaissances et de méthodes de raisonnement sur ces connaissances ; il n est cependant pas adapté à la description de comportements réactifs. En s inspirant de ce langage, la description de comportements cognitifs d agent INVIWO serait probablement facilitée ; il s agirait alors d une extension directe de MARVIN, couplée au besoin de l extension du modèle d agents pour séparer la base de connaissances et les modules cognitifs des composants actuels. De son côté, le langage proposé par K. Perlin permet de scénariser l animation de plusieurs personnages, sous une forme proche de l anglais courant. Les acteurs virtuels sont dirigés par un même script, contenant entre autres des règles de décision portant sur des attributs caractéristiques des acteurs. Contrairement au modèle INVIWO, il n y donc pas d encapsulation de l état interne et du comportement des agents. La définition sous cette forme du comportement des agents correspond pour nous d une part à la définition d un protocole d interaction de haut-niveau, d autre part à une organisation particulière d un monde donnée à partir d une description globale. Il est aussi envisageable d étendre l utilisation des contraintes pour la description de comportements globaux, en introduisant des contraintes multidirectionnelles fortes entre agents. Pour traiter le problème de la description d animations complexes, il faudrait se pencher sur les raisons qui ont amené certains auteurs à distinguer les actions motrices des autres actions possibles dans leurs systèmes. Par exemple, B. Loyall propose des actions physiques (animations) prédéfinies dans son système alors que les actions mentales sont à définir en C [92]. De même, B. Blumberg et K. Perlin séparent nettement le moteur d animation (capacités motrices) des autres capacités. Dans notre modèle, les animations sont définies comme n importe quel autre comportement, à travers une chaîne comportementale; pour intégrer un moteur d animation à ce modèle, il faudrait de nouveau s intéresser à la mise en œuvre de tâches asynchrones. Cette intégration posera le problème du choix des primitives d animation et de leur réalisation. Si le niveau de finesse des primitives est trop bas, le moteur n aura pas beaucoup d intérêt ; d un autre côté, le concepteur pourra être gêné par un grain trop grossier. Dans les deux cas, il faudra étudier l opportunité de rendre opaque ce moteur d animation ou de permettre la description d animations complexes accessible aux concepteurs INVIWO. Autres applications Bien que nous nous soyons intéressés plus spécifiquement aux agents virtuels, nous avons défini un modèle et un langage génériques pour la description de comportements d agents autonomes. Notre travail peut donc s appliquer à d autres types d agents, par exemple à des robots mobiles ou à des objets physiques communicants, tels que les PDA (Personal Digital Assistants). Notre modèle d avatar facilite en particulier l intégration de l utilisateur dans ce type d applications, par exemple pour commander à distance un robot semi-autonome ou dialoguer avec un PDA.

203 Septième partie Annexes 203

204

205 Annexe A Grammaire du langage MARVIN Cette annexe présente la grammaire du langage MARVIN en utilisant la syntaxe BNF étendue définie dans [106]. Cette grammaire est utilisée comme entrée pour le compilateur de grammaires ANTLR [2] et produit du code JAVA [126]. Les mots en caractères majuscules représentent des atomes (tokens) en provenance de l analyseur lexical. program : ( topleveldecl ( SEMI ) )+ EOF ; topleveldecl : behaviourdecl agentdecl fundecl effectordecl sensordecl estimdecl ustimdecl ; behaviourdecl : BEHAVIOUR IDENT ( ( globdecl signaldecl ) ( SEMI ) )* body END BEHAVIOUR ; 205

206 206 ANNEXE A. GRAMMAIRE DU LANGAGE MARVIN agentdecl : AGENT IDENT ( agenttop ( SEMI ) )* ( agentbody ) END AGENT ; fundecl : FUNCTION IDENT LPAREN ( argslist ) RPAREN sequence END FUNCTION ; effectordecl : EFFECTOR IDENT ( ( insignaldecl globdecl ) ( SEMI ) )* ARBITER sequence END ARBITER ( SEMI ) END EFFECTOR ; sensordecl : SENSOR IDENT ( ( outsignaldecl globdecl ) ( SEMI ) )* FILTER sequence END FILTER ( SEMI ) END SENSOR ; estimdecl : ESTIM IDENT ( LPAREN exprlist RPAREN ) ; ustimdecl : USTIM IDENT ( LPAREN exprlist RPAREN ) ;

207 207 list_or_dict : ( LBRACE ( expr ) COLUMN ) => dict list ; expr : ( multexpr ) => multexpr ( addexpr ) => addexpr ( boolexpr ) => boolexpr MINUS expr ( LPAREN expr RPAREN ) => LPAREN expr RPAREN simpleexpr NEW ATTRIBUTE LPAREN expr RPAREN NEW funcall ; dict : LBRACE COLUMN RBRACE LBRACE dictcontent RBRACE ; list : LBRACE ( exprlist ) RBRACE ; exprlist : expr ( COMMA exprlist ) ; dictcontent : dictelement ( COMMA dictelement )* ; dictelement : expr COLUMN expr ; multexpr : ( simpleexpr STAR ) => simpleexpr STAR expr ( simpleexpr SLASH ) => simpleexpr SLASH expr ;

208 208 ANNEXE A. GRAMMAIRE DU LANGAGE MARVIN addexpr : ( simpleexpr PLUS ) => simpleexpr PLUS expr ( simpleexpr MINUS ) => simpleexpr MINUS expr ; boolexpr : ( simpleexpr EQUAL ) => simpleexpr EQUAL expr ( simpleexpr NOT_EQUAL ) => simpleexpr NOT_EQUAL expr ( simpleexpr LT ) => simpleexpr LT expr ( simpleexpr LE ) => simpleexpr LE expr ( simpleexpr GT ) => simpleexpr GT expr ( simpleexpr GE ) => simpleexpr GE expr ( simpleexpr AND ) => simpleexpr AND expr ( simpleexpr OR ) => simpleexpr OR expr ( LPAREN expr RPAREN OR ) => LPAREN expr RPAREN OR expr ( simpleexpr XOR ) => simpleexpr XOR expr ; simpleexpr : ( basicexpr ) => basicexpr constantexpr list_or_dict slotfield attributefield fetch ; funcall : functor LPAREN ( exprlist ) RPAREN ; tuple : LPAREN RPAREN ( LPAREN expr COMMA RPAREN ) => LPAREN expr COMMA RPAREN LPAREN exprlist RPAREN ; mtuple : expr ( COMMA expr )+ ; basicexpr : ( funcall ) => funcall ( LPAREN expr COMMA ) => tuple ( LPAREN RPAREN ) => tuple IDENT ;

209 209 constantexpr : NONE TRUE FALSE INT FLOAT STRING ; slotfield : IDENT DOT IDENT ; attributefield : IDENT DASH IDENT ; fetch : IDENT LBRACK expr RBRACK ; functor : slotfield IDENT ; sequence : statements ; statements : statement ( SEMI statements ) ; statement : assign pause ifthenelse trap returnstmt exit vardecl funcall foreach emit usend esend waitelse waitstim loop LBRACK sequence RBRACK ;

210 210 ANNEXE A. GRAMMAIRE DU LANGAGE MARVIN assign : IDENT ASSIGN expr ; pause : PAUSE ; ifthenelse : IF expr ifcsq END IF ; trap : TRAP IDENT IN sequence END TRAP ; returnstmt : ( RETURN expr ) => RETURN expr RETURN ; exit : EXIT IDENT ; vardecl : ( VAR IDENT ASSIGN ) => VAR IDENT ASSIGN expr VAR IDENT ; foreach : FOREACH IDENT IN expr DO sequence END FOREACH ; emit : EMIT IDENT ( LPAREN exprlist RPAREN ) ; usend : USEND IDENT ( LPAREN exprlist RPAREN ) ; esend : ESEND IDENT ( LPAREN exprlist RPAREN ) ;

211 211 waitelse : WAIT waitblock ( ELSE waitblock )* END WAIT ; waitstim : WAITSTIM waitblock ( ELSE waitblock )* END WAITSTIM ; loop : LOOP sequence END LOOP ; argslist : IDENT ( COMMA IDENT )* ; methoddecl : METHOD IDENT LPAREN ( argslist ) RPAREN sequence END METHOD ; ifcsq : thencsq ( elsecsq ) elsecsq ; thencsq : THEN sequence ; elsecsq : ELSE sequence ; globdecl : fundecl vardecl methoddecl ; signaldecl : insignaldecl outsignaldecl ;

212 212 ANNEXE A. GRAMMAIRE DU LANGAGE MARVIN insignaldecl : IN signalsig ( COMMA signalsig )* ; outsignaldecl : OUT signalsig ( COMMA signalsig )* ; signalsig : IDENT ( LPAREN typelist RPAREN ) ; typelist : IDENT ( COMMA IDENT )* ; sensorinst : SENSOR IDENT ASSIGN expr ; effectorinst : EFFECTOR IDENT ASSIGN expr ; behaviourinst : BEHAVIOUR IDENT ASSIGN expr ; body : BODY sequence END BODY ; agenttop : attributeinst globdecl sensorinst sensordecl effectorinst effectordecl behaviourinst behaviourdecl ; agentbody : BODY sequence END BODY ;

213 213 attributeinst : ATTRIBUTE IDENT ( ASSIGN expr ) ; waitblock : rule ( PIPE rule )* ; rule : trigger ( RULE sequence ) ; trigger : sigexpr ( WITH expr ) ; sigexpr : LPAREN sigexpr RPAREN NOT basicsigexpr ( ( AND OR XOR ) sigexpr ) NOT LPAREN sigexpr RPAREN basicsigexpr ( ( AND OR XOR ) sigexpr ) ; basicsigexpr : IDENT ( LPAREN argslist RPAREN ) ALL IDENT ( AS ASLISTS ) IDENT ;

214 214 ANNEXE A. GRAMMAIRE DU LANGAGE MARVIN

215 Annexe B Traduction en Java d exemples en MARVIN Cette annexe présente le code JAVA correspondant aux exemples en MARVIN décrits dans les sections page 178 et 10.4 page 186. B.1 Factorielle // La fonction f et son unique argument n. MFunction fact = new MFunction("f"); Argument n = new Argument("n", fact); // La condition: n < 2. Expression [] lt_args = {n, new MInt(2)}; FunctionCall condition = new FunctionCall(MNumerical.less_than, lt_args); // La conséquence: retourner 1. Sequence consequence = new Sequence(); consequence.addinstruction(new Return(new MInt(1))); // L alternative: retourner f(n - 1) * n. // Soustraction: n - 1. Expression [] sub_args = {n, new MInt(1)}; FunctionCall sub = new FunctionCall(MNumerical.subtract, sub_args); // Appel récursif: f(n - 1). Expression [] fc_args = {sub}; FunctionCall fc = new FunctionCall(fact, fc_args); // Multiplication: f(n - 1) * n. Expression [] mult_args = {fc, n}; FunctionCall mult = new FunctionCall(MNumerical.multiply, mult_args); // L alternative. Sequence alternative = new Sequence(); alternative.addinstruction(new Return(mult)); 215

216 216 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN // Création de la conditionnelle. IfThenElse ite = new IfThenElse(condition, consequence, alternative); // Création du corps de la fonction f. Sequence s = new Sequence(); s.addinstruction(ite); fact.setsequence(s); // Appel de la fonction: f(5). Expression [] f5_args = {new MInt(5)}; FunctionCall f5 = new FunctionCall(fact, f5_args); System.out.println("Calling 5!"); Status status = f5.evaluate(); System.out.println ("5! => " + ((MInt) ((Terminated) status).getvalue()).intvalue());

217 B.2. BIZARRE LOVE TRIANGLE 217 B.2 Bizarre love triangle package InViWo.Examples; import InViWo.Basics.*; import InViWo.Basics.Marvin.*; import InViWo.Communication.*; import InViWo.Communication.ByMethodCall.*; import InViWo.Debug.Dump; /** * Three communicating agents, including one avatar. * The first agent tries to reach the position of the * second agent, while the avatar just forwards the * stimuli so the user interface can display the 3D scene. */ public class TwoAgentsAndOneAvatar extends Example { protected static MAttribute agent1_shape; protected static MAttribute agent1_position; protected static MAttribute agent1_step; protected static MAttribute agent2_shape; protected static MAttribute agent2_position; protected static MAttribute avatar_position; protected static MAttribute avatar_attracted_id; protected static MAttribute avatar_target_id; // Interaction protocol. protected static StimulusType position_stype; protected static StimulusType shape_stype; protected static StimulusType avatar_position_stype; protected static StimulusType other_position_stype; protected static StimulusType other_shape_stype; protected static StimulusType set_position_stype; public static void main (String [] argv) { position_stype = new StimulusType("S_position", "tuple(position_3d)"); shape_stype = new StimulusType("S_shape", "tuple(string)"); avatar_position_stype = new StimulusType("U_avatar_position", "tuple(position_3d)"); other_position_stype = new StimulusType("U_other_position", "tuple(agent_id, position_3d)"); other_shape_stype = new StimulusType("U_other_shape", "tuple(agent_id, string)"); set_position_stype = new StimulusType("U_set_position", "tuple(position_3d)");

218 218 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN } MAgent agent1 = create_agent1(); MAgent agent2 = create_agent2(); MAgent avatar = create_avatar(agent1.getagentid(), agent2.getagentid()); // Register communication layers of agents. MAgent [] agents = {agent1, agent2, avatar}; for (int i=0; i < agents.length - 1; i++) { MAgent ai = agents[i]; for (int j = i + 1; j < agents.length; j++) { MAgent aj = agents[j]; CommunicationLayer cli = ai.getenvlayer(); CommunicationLayer clj = aj.getenvlayer(); cli.register(clj.getid(), clj); clj.register(cli.getid(), cli); } } // Create and launch avatar interface. AvatarInterface avi = new AvatarInterface3D(new ByMethodCall(), new MUserId(new UserId())); CommunicationLayer avatar_cl = avatar.getuserlayer(); CommunicationLayer user_cl = avi.getlayer(); avatar_cl.register(user_cl.getid(), user_cl); user_cl.register(avatar_cl.getid(), avatar_cl); avi.launch(); // Launch agents. Dump.debug_ln("Main thread=" + Thread.currentThread()); avatar.launch(250); agent1.launch(250); Dump.debug_off ("attracted_agent"); Dump.debug_off ("target_agent"); Dump.debug_off (); agent2.launch(1000); protected static MAgent create_agent1 () { MAgent agent = new MAgent("attracted_agent"); agent.setagentid(new MAgentId(new AgentId())); ByMethodCall bmc = new ByMethodCall(); agent.setenvlayer(bmc); agent1_shape = new MAttribute("shape", agent); agent1_position = new MAttribute("position", agent); agent1_step = new MAttribute("step", agent); Affectation init_shape = new Affectation(agent1_shape, new MString("cube")); Affectation init_position = new Affectation(agent1_position, new MPosition3D(new MFloat(0.0f), new MFloat(0.0f), new MFloat(0.0f))); Affectation init_step = new Affectation(agent1_step, new MFloat(0.2f)); Instruction [] init_args = {init_position, init_step}; agent.setbody(new Sequence(init_args));

219 B.2. BIZARRE LOVE TRIANGLE 219 MSensor target_sensor = (MSensor) create_agent1_sensor().mclone(); agent.addsensor(target_sensor); MBehaviour reach_target = (MBehaviour) create_agent1_behaviour().mclone(); agent.addbehaviour(reach_target); MEffector position_effector = (MEffector) create_agent1_effector().mclone(); agent.addeffector(position_effector); try { agent.connect(target_sensor, "TargetPosition", reach_target, "Target"); agent.connect(reach_target, "SetPosition", position_effector, "Set"); } catch (BadChannelException e) { Dump.debug_ln("Error while creating channels."); System.exit(1); } dump(agent); Dump.debug_ln(); } return agent; protected static MSensor create_agent1_sensor () { MSensor sensorproto = new MSensor("target_sensor"); SensorInput input = new SensorInput(position_stype, sensorproto); sensorproto.register(position_stype); MOutput sensoroutput = new MOutput("TargetPosition", "tuple(position_3d)", sensorproto); // Rule trigger. MSensorLocalVariable position = new MSensorLocalVariable("position", sensorproto); int [] vars = {position.getindex()}; SignalExpression sigexp = new TestValuedSignal(sensorProto, input.getindex(), vars); RuleTrigger trigger = new RuleTrigger(sigexp); // Rule action. Debug dbg = new Debug("*** Start sensor action! ***"); Expression [] emit_exp = {position}; Emit emit_position = new Emit(sensorProto, sensoroutput.getindex(), emit_exp); Instruction [] instr = {dbg, emit_position}; Sequence action = new Sequence(instr);

220 220 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN // Rule. Rule rule = new Rule(trigger, action); // Rule block. Rule [] rules = {rule}; RuleSubblock rsb = new RuleSubblock(rules); RuleSubblock [] sblocks = {rsb}; RuleBlock rule_block = new RuleBlock(sblocks); // Loop. Instruction [] loop_instr = {rule_block}; Loop loop = new Loop(new Sequence(loop_instr)); // Sequence. Instruction [] seq_instr = {loop}; Sequence filter = new Sequence(seq_instr); sensorproto.setfilter(filter); dump(sensorproto); Dump.debug_ln(); } return sensorproto; protected static MBehaviour create_agent1_behaviour () { // The internal function. MFunction choose = new MFunction("choose"); Argument pos1 = new Argument("pos1", choose); Argument pos2 = new Argument("pos2", choose); Argument step = new Argument("step", choose); MFunctionLocalVariable displacement = new MFunctionLocalVariable("displacement", choose); Expression [] create_args = {pos1, pos2}; FunctionCall create = new FunctionCall(MVector3D.create, create_args); Affectation aff1 = new Affectation(displacement, create); Expression [] normalize_args = {displacement}; FunctionCall normalize = new FunctionCall(MVector3D.normalize, normalize_args); Affectation aff2 = new Affectation(displacement, normalize); Expression [] multiply_args = {displacement, step}; FunctionCall multiply = new FunctionCall(MVector3D.multiply, multiply_args); Affectation aff3 = new Affectation(displacement, multiply); Expression [] add_args = {pos1, displacement}; FunctionCall add = new FunctionCall(MPosition3D.add, add_args); Return choose_return = new Return(add); Instruction [] choose_args = {aff1, aff2, aff3, choose_return}; choose.setsequence(new Sequence(choose_args));

221 B.2. BIZARRE LOVE TRIANGLE 221 // The behavioural module. MBehaviour behaviourproto = new MBehaviour("reach_target"); // Create input and output. MInput input = new MInput ("Target", "tuple(position_3d)", behaviourproto); MOutput output = new MOutput ("SetPosition", "tuple(position_3d)", behaviourproto); // Rule trigger. MBehaviourLocalVariable position = new MBehaviourLocalVariable("position", behaviourproto); int [] vars = {position.getindex()}; SignalExpression sigexp = new TestValuedSignal (behaviourproto, input.getindex(), vars); RuleTrigger trigger = new RuleTrigger(sigexp); MBehaviourLocalVariable target = new MBehaviourLocalVariable("target", behaviourproto); Affectation init_target = new Affectation (target, MValue.none); // Rule action. Debug dbg = new Debug("*** Start behaviour action! (Target) ***"); Affectation do_assign = new Affectation (target, position); Instruction [] instr = {dbg, do_assign}; Sequence action = new Sequence(instr); // Rule. Rule rule = new Rule(trigger, action); // Else rule. Rule else_rule = new Rule(new RuleTrigger(new Tick()), null); Rule [] else_rules = {else_rule}; // Rule block. Rule [] rules = {rule}; RuleSubblock rsb = new RuleSubblock(rules); RuleSubblock rsbe = new RuleSubblock(else_rules); RuleSubblock [] sblocks = {rsb, rsbe}; RuleBlock rule_block = new RuleBlock(sblocks); // After rule block. Expression [] diff_args = {target, MValue.none}; FunctionCall diff = new FunctionCall(MValue.not_equal, diff_args); Expression [] do_choose_args = {agent1_position, target, agent1_step}; FunctionCall do_choose = new FunctionCall(choose, do_choose_args);

222 222 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN Expression [] emit_exp = {do_choose}; Emit emit_position = new Emit(behaviourProto, output.getindex(), emit_exp); Instruction [] consequence_args = {emit_position}; IfThenElse ite = new IfThenElse(diff, new Sequence(consequence_args), null); // Loop. Instruction [] loop_instr = {rule_block, ite}; Loop loop = new Loop(new Sequence(loop_instr)); // Body. Instruction [] body_instr = {init_target, loop}; behaviourproto.setbody(new Sequence(body_instr)); dump(behaviourproto); Dump.debug_ln(); } return behaviourproto; protected static MEffector create_agent1_effector () { MEffector effectorproto = new MEffector("position_effector"); // Create input. MInput input = new MInput("Set", "tuple(position_3d)", effectorproto); // Rule trigger. MEffectorLocalVariable position = new MEffectorLocalVariable("position", effectorproto); int [] vars = {position.getindex()}; SignalExpression sigexp = new TestValuedSignal(effectorProto, input.getindex(), vars); RuleTrigger trigger = new RuleTrigger(sigexp); // Rule action. Debug dbg = new Debug("*** Start effector action! ***"); Affectation assign_position = new Affectation(agent1_position, position); Expression [] send_args = {position}; Send send_position = new Send(position_stype, false, send_args); Instruction [] instr = {dbg, assign_position, send_position}; Sequence action = new Sequence(instr); // Rule. Rule rule = new Rule(trigger, action); // Rule block. Rule [] rules = {rule}; RuleSubblock rsb = new RuleSubblock(rules); RuleSubblock [] sblocks = {rsb}; RuleBlock rule_block = new RuleBlock(sblocks);

223 B.2. BIZARRE LOVE TRIANGLE 223 // Loop. Instruction [] loop_instr = {rule_block}; Loop loop = new Loop(new Sequence(loop_instr)); // Sequence. Instruction [] seq_instr = {loop}; Sequence arbiter = new Sequence(seq_instr); effectorproto.setarbiter(arbiter); dump(effectorproto); Dump.debug_ln(); } return effectorproto; protected static MAgent create_agent2 () { MAgent agent = new MAgent("target_agent"); agent.setagentid(new MAgentId(new AgentId())); ByMethodCall bmc = new ByMethodCall(); agent.setenvlayer(bmc); agent2_shape = new MAttribute("shape", agent); agent2_position = new MAttribute("position", agent); Affectation init_shape = new Affectation(agent2_shape, new MString("light")); Affectation init_position = new Affectation(agent2_position, new MPosition3D(new MFloat(10.0f), new MFloat(0.0f), new MFloat(10.0f))); Expression [] send_position_args = {agent2_position}; Send send_position = new Send(position_stype, false, send_position_args); Expression [] send_shape_args = {agent2_shape}; Send send_shape = new Send(shape_stype, false, send_shape_args); Instruction [] body_args = {init_shape, init_position, send_shape, send_position}; agent.setbody(new Sequence(body_args)); dump(agent); Dump.debug_ln(); } return agent; protected static MSensor create_avatar_sensor () { MSensor sensorproto = new MSensor("avatar_sensor"); SensorInput input1 = new SensorInput(set_position_stype, sensorproto); sensorproto.register(set_position_stype);

224 224 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN SensorInput input2 = new SensorInput(other_position_stype, sensorproto); sensorproto.register(other_position_stype); SensorInput input3 = new SensorInput(other_shape_stype, sensorproto); sensorproto.register(other_shape_stype); MOutput output1 = new MOutput("SetPosition", "tuple(position_3d)", sensorproto); MOutput output2 = new MOutput("GotPosition1", "tuple(position_3d)", sensorproto); MOutput output3 = new MOutput("GotShape1", "tuple(string)", sensorproto); MOutput output4 = new MOutput("GotPosition2", "tuple(position_3d)", sensorproto); MOutput output5 = new MOutput("GotShape2", "tuple(string)", sensorproto); // Rule triggers. MSensorLocalVariable position = new MSensorLocalVariable("position", sensorproto); int [] rule_vars1 = {position.getindex()}; SignalExpression sigexp1 = new TestValuedSignal(sensorProto, input1.getindex(), rule_vars1); RuleTrigger trigger1 = new RuleTrigger(sigexp1); MSensorLocalVariable positions = new MSensorLocalVariable("positions", sensorproto); SignalExpression sigexp2 = new AllAsTestValuedSignal(sensorProto, input2.getindex(), positions.getindex()); RuleTrigger trigger2 = new RuleTrigger(sigexp2); MSensorLocalVariable shapes = new MSensorLocalVariable("shapes", sensorproto); SignalExpression sigexp3 = new AllAsTestValuedSignal(sensorProto, input3.getindex(), shapes.getindex()); RuleTrigger trigger3 = new RuleTrigger(sigexp3); // Rule actions. // First rule. Debug dbg1 = new Debug("*** Start avatar sensor action 1! ***"); Expression [] emit_exp1 = {position}; Emit emit_my_position = new Emit(sensorProto, output1.getindex(), emit_exp1); Instruction [] instr1 = {dbg1, emit_my_position}; Sequence action1 = new Sequence(instr1);

225 B.2. BIZARRE LOVE TRIANGLE 225 // Second rule. Debug dbg2 = new Debug("*** Start avatar sensor action 2! ***"); MSensorLocalVariable iterator2 = new MSensorLocalVariable("iterator", sensorproto); // Get the position for the identifier // affected to the iterator. Expression [] get_position_args = {positions, iterator2}; FunctionCall get_position = new FunctionCall(MDict.dict_get, get_position_args); Expression [] emit_exp2 = {get_position}; // First conditional. Expression [] cond1_1_args = {iterator2, avatar_attracted_id}; FunctionCall cond1_1 = new FunctionCall(MValue.equals, cond1_1_args); Emit emit_position1 = new Emit(sensorProto, output2.getindex(), emit_exp2); Instruction [] consequence1_1 = {emit_position1}; IfThenElse ite1_1 = new IfThenElse(cond1_1, new Sequence(consequence1_1), null); // Second conditional. Expression [] cond1_2_args = {iterator2, avatar_target_id}; FunctionCall cond1_2 = new FunctionCall(MValue.equals, cond1_2_args); Emit emit_position2 = new Emit(sensorProto, output4.getindex(), emit_exp2); Instruction [] consequence1_2 = {emit_position2}; IfThenElse ite1_2 = new IfThenElse(cond1_2, new Sequence(consequence1_2), null); Expression [] pk_args = {positions}; FunctionCall positions_keys = new FunctionCall(MDict.dict_keys, pk_args); Instruction [] foreach2_args = {ite1_1, ite1_2}; Foreach foreach2 = new Foreach(iterator2, positions_keys, new Sequence(foreach2_args), null); Instruction [] instr2 = {dbg2, foreach2}; Sequence action2 = new Sequence(instr2); // Third rule. Debug dbg3 = new Debug("*** Start avatar sensor action 3! ***"); MSensorLocalVariable iterator3 = new MSensorLocalVariable("iterator", sensorproto); // Get the shape for the identifier // affected to the iterator. Expression [] get_shape_args = {shapes, iterator3}; FunctionCall get_shape = new FunctionCall(MDict.dict_get, get_shape_args); Expression [] emit_exp3 = {get_shape};

226 226 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN // First conditional. Expression [] cond2_1_args = {iterator3, avatar_attracted_id}; FunctionCall cond2_1 = new FunctionCall(MValue.equals, cond2_1_args); Emit emit_shape1 = new Emit(sensorProto, output3.getindex(), emit_exp3); Instruction [] consequence2_1 = {emit_shape1}; IfThenElse ite2_1 = new IfThenElse(cond2_1, new Sequence(consequence2_1), null); // Second conditional. Expression [] cond2_2_args = {iterator3, avatar_target_id}; FunctionCall cond2_2 = new FunctionCall(MValue.equals, cond2_2_args); Emit emit_shape2 = new Emit(sensorProto, output5.getindex(), emit_exp3); Instruction [] consequence2_2 = {emit_shape2}; IfThenElse ite2_2 = new IfThenElse(cond2_2, new Sequence(consequence2_2), null); Expression [] sk_args = {shapes}; FunctionCall shapes_keys = new FunctionCall(MDict.dict_keys, sk_args); Instruction [] foreach3_args = {ite2_1, ite2_2}; Foreach foreach3 = new Foreach(iterator3, shapes_keys, new Sequence(foreach3_args), null); Instruction [] instr3 = {dbg3, foreach3}; Sequence action3 = new Sequence(instr3); // Rules. Rule rule1 = new Rule(trigger1, action1); Rule rule2 = new Rule(trigger2, action2); Rule rule3 = new Rule(trigger3, action3); // Rule block. Rule [] rules = {rule1, rule2, rule3}; RuleSubblock rsb = new RuleSubblock(rules); RuleSubblock [] sblocks = {rsb}; RuleBlock rule_block = new RuleBlock(sblocks); // Loop. Instruction [] loop_instr = {rule_block}; Loop loop = new Loop(new Sequence(loop_instr)); // Sequence. Instruction [] seq_instr = {loop}; Sequence filter = new Sequence(seq_instr); sensorproto.setfilter(filter); dump(sensorproto); Dump.debug_ln(); return sensorproto; }

227 B.2. BIZARRE LOVE TRIANGLE 227 protected static MEffector create_avatar_effector () { MEffector effectorproto = new MEffector("avatar_effector"); // Create inputs. MInput input1 = new MInput("SetPosition", "tuple(position_3d)", effectorproto); MInput input2 = new MInput("ForwardPosition1", "tuple(position_3d)", effectorproto); MInput input3 = new MInput("ForwardShape1", "tuple(string)", effectorproto); MInput input4 = new MInput("ForwardPosition2", "tuple(position_3d)", effectorproto); MInput input5 = new MInput("ForwardShape2", "tuple(string)", effectorproto); // Rule local variables. MEffectorLocalVariable position = new MEffectorLocalVariable("position", effectorproto); MEffectorLocalVariable other_position1 = new MEffectorLocalVariable("position", effectorproto); MEffectorLocalVariable other_shape1 = new MEffectorLocalVariable("shape", effectorproto); MEffectorLocalVariable other_position2 = new MEffectorLocalVariable("position", effectorproto); MEffectorLocalVariable other_shape2 = new MEffectorLocalVariable("shape", effectorproto); // Rule triggers. int [] rule_vars1 = {position.getindex()}; SignalExpression sigexp1 = new TestValuedSignal(effectorProto, input1.getindex(), rule_vars1); RuleTrigger trigger1 = new RuleTrigger(sigexp1); int [] rule_vars2 = {other_position1.getindex()}; SignalExpression sigexp2 = new TestValuedSignal(effectorProto, input2.getindex(), rule_vars2); RuleTrigger trigger2 = new RuleTrigger(sigexp2); int [] rule_vars3 = {other_shape1.getindex()}; SignalExpression sigexp3 = new TestValuedSignal(effectorProto, input3.getindex(), rule_vars3); RuleTrigger trigger3 = new RuleTrigger(sigexp3); int [] rule_vars4 = {other_position2.getindex()}; SignalExpression sigexp4 = new TestValuedSignal(effectorProto, input4.getindex(), rule_vars4); RuleTrigger trigger4 = new RuleTrigger(sigexp4); int [] rule_vars5 = {other_shape2.getindex()}; SignalExpression sigexp5 = new TestValuedSignal(effectorProto, input5.getindex(), rule_vars5); RuleTrigger trigger5 = new RuleTrigger(sigexp5);

228 228 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN // Rule actions. Debug dbg1 = new Debug("*** Start avatar effector action 1! ***"); Affectation set_position = new Affectation(avatar_position, position); Expression [] usend_my_position_args = {position}; Send usend_my_position = new Send(avatar_position_stype, true, usend_my_position_args); Instruction [] instr1 = {dbg1, set_position, usend_my_position}; Sequence action1 = new Sequence(instr1); Debug dbg2 = new Debug("*** Start avatar effector action 2! ***"); Expression [] usend_position1_args = {avatar_attracted_id, other_position1}; Send usend_position1 = new Send(other_position_stype, true, usend_position1_args); Instruction [] instr2 = {dbg2, usend_position1}; Sequence action2 = new Sequence(instr2); Debug dbg3 = new Debug("*** Start avatar effector action 3! ***"); Expression [] usend_shape1_args = {avatar_attracted_id, other_shape1}; Send usend_shape1 = new Send(other_shape_stype, true, usend_shape1_args); Instruction [] instr3 = {dbg3, usend_shape1}; Sequence action3 = new Sequence(instr3); Debug dbg4 = new Debug("*** Start avatar effector action 4! ***"); Expression [] usend_position2_args = {avatar_target_id, other_position2}; Send usend_position2 = new Send(other_position_stype, true, usend_position2_args); Instruction [] instr4 = {dbg4, usend_position2}; Sequence action4 = new Sequence(instr4); Debug dbg5 = new Debug("*** Start avatar effector action 5! ***"); Expression [] usend_shape2_args = {avatar_target_id, other_shape2}; Send usend_shape2 = new Send(other_shape_stype, true, usend_shape2_args); Instruction [] instr5 = {dbg5, usend_shape2}; Sequence action5 = new Sequence(instr5); // Rules. Rule rule1 = new Rule(trigger1, action1); Rule rule2 = new Rule(trigger2, action2); Rule rule3 = new Rule(trigger3, action3); Rule rule4 = new Rule(trigger4, action4); Rule rule5 = new Rule(trigger5, action5); // Rule block. Rule [] rules = {rule1, rule2, rule3, rule4, rule5}; RuleSubblock rsb = new RuleSubblock(rules); RuleSubblock [] sblocks = {rsb}; RuleBlock rule_block = new RuleBlock(sblocks);

229 B.2. BIZARRE LOVE TRIANGLE 229 // Loop. Instruction [] loop_instr = {rule_block}; Loop loop = new Loop(new Sequence(loop_instr)); // Sequence. Instruction [] seq_instr = {loop}; Sequence arbiter = new Sequence(seq_instr); effectorproto.setarbiter(arbiter); dump(effectorproto); Dump.debug_ln(); } return effectorproto; protected static MAgent create_avatar (MAgentId id1, MAgentId id2) { MAgent agent = new MAgent("avatar"); agent.setagentid(new MAgentId(new AgentId())); ByMethodCall bmc = new ByMethodCall(); agent.setenvlayer(bmc); ByMethodCall usr_bmc = new ByMethodCall(); agent.setuserlayer(usr_bmc); avatar_position = new MAttribute("position", agent); avatar_attracted_id = new MAttribute("attracted_id", agent); avatar_target_id = new MAttribute("target_id", agent); Affectation init_position = new Affectation(avatar_position, new MPosition3D(new MFloat(5.0f), new MFloat(5.0f), new MFloat(5.0f))); Affectation init_id1 = new Affectation(avatar_attracted_id, id1); Affectation init_id2 = new Affectation(avatar_target_id, id2); MSensor avatar_sensor = (MSensor) create_avatar_sensor().mclone(); agent.addsensor(avatar_sensor); MEffector avatar_effector = (MEffector) create_avatar_effector().mclone(); agent.addeffector(avatar_effector); try { agent.connect(avatar_sensor, "SetPosition", avatar_effector, "SetPosition"); agent.connect(avatar_sensor, "GotPosition1", avatar_effector, "ForwardPosition1"); agent.connect(avatar_sensor, "GotShape1", avatar_effector, "ForwardShape1"); agent.connect(avatar_sensor, "GotPosition2", avatar_effector, "ForwardPosition2"); agent.connect(avatar_sensor, "GotShape2", avatar_effector, "ForwardShape2"); } catch (BadChannelException e) { Dump.debug_ln("Error while creating channels."); System.exit(1); }

230 230 ANNEXE B. TRADUCTION EN JAVA D EXEMPLES EN MARVIN Expression [] usend_args = {avatar_position}; Send usend_position = new Send(avatar_position_stype, true, usend_args); Instruction [] body_args = {init_position, init_id1, init_id2, usend_position}; agent.setbody(new Sequence(body_args)); dump(agent); Dump.debug_ln(); } } return agent;

231 Huitième partie Bibliographie 231

232

233 Bibliographie [1] AGENTBUILDER. URL : [2] ANTLR. URL : [3] CREATURES. URL : [4] EVERQUEST. URL : [5] INVIWO home page. URL : [6] NEMO. URL : [7] SCOL. URL : [8] THE SIMS. URL : [9] Core JavaScript Guide 1.5, URL : core/jsguide15/contents.html [10] AGESEN O. et al.. The SELF 4.0 Programmer s Reference Manual. Manuel de référence, Sun Microsystems, Inc., [11] AGRE P.E. et CHAPMAN D. What are plans for? Robotics and Autonomous Systems, Vol. 6(1-2) (1990) [12] ANDRÉ C. Representation and analysis of reactive behaviors : a synchronous approach. in (CESA 96), pp IEEE-SMC, Lille (France). [13] ARKIN R.C. Behavior-based robotics. MIT Press, [14] AYLETT R. Narrative in virtual environments - towards emergent narrative. in AAAI 1999 Fall Symposium on Narrative Intelligence. AAAI Press, Cape Cod (USA). [15] BADLER N.I. Virtual Humans for animation, ergonomics and simulation. in IEEE Workshop on Non-Rigid and Articulated Motion Puerto Rico. [16] BADLER N.I., CHI D. et CHOPRA S. Virtual human animation based on movement observation and cognitive behavior models. in Computer Animation 99. IEEE Computer Society Press, Genève (Suisse). 233

234 234 BIBLIOGRAPHIE [17] BADLER N.I., PHILLIPS C.B. et WEBBER B.L. Simulating humans : computer graphics animation and control. Oxford University Press, [18] BADLER N.I., REICH B.D. et WEBBER B.L. Towards personalities for animated agents with reactive and planning behaviors. in R. Trappl et P. Petta (éds), Creating personalities for synthetic actors : towards autonomous personality agents. Springer-Verlag, [19] BADLER N.I. et al.. Real-time virtual humans. in International Conference on Digital Media Futures Bradford (Royaume-Uni). [20] BARBUCEANU M. et LO W.K. Conversation oriented programming in COOL : current state and future directions. in Agents 99 : Working Notes of the Workshop on Specifying and Implementing Conversation Policies Seattle (USA). [21] BATES J. Virtual Reality, art, and entertainment. in Presence : the Journal of Teleoperators and Virtual Environments, Vol. 1(1), pp MIT Press, [22] BERRY G. The foundations of Esterel. in G. Plotkin, C. Stirling et M. Tofte (éds), Proof, language and interaction : essays in honour of Robin Milner. MIT Press, [23] BERRY G. The Esterel v5 language primer. Manuel de référence, Centre de Mathématiques Appliquées (INRIA et École des Mines de Paris), [24] BERRY G., COURONNÉ P. et GONTHIER G. Programmation synchrone des systèmes réactifs : le langage Esterel. in Technique et Science Informatiques (TSI), Vol. 6(4), pp Hermès, [25] BERRY G., RAMESH S. et SHYAMSUNDER R.K. Communicating reactive processes. in Twentieth ACM Symposium on Principles of Programming Languages (POPL 93), pp Charleston (USA). [26] BERTHOZ A. Le sens du mouvement. Odile Jacob, [27] BLUMBERG B.M. Action-selection in Hamsterdam : lessons from ethology. in D. Cliff et al. (éds), Third International Conference on Simulation of Adaptive Behavior (SAB-94) [28] BLUMBERG B.M. et GALYEAN T. Multi-level control for animated autonomous agents : do the right thing... oh, not that... in R. Trappl et P. Petta (éds), Creating personalities for synthetic actors : towards autonomous personality agents, Lecture Notes in Artificial Intelligence (LNCS), pp Springer- Verlag, [29] BLUMBERG B.M., TODD P.M. et MAES P. No bad dogs : ethological lessons for learning in Hamsterdam. in P. Maes et al. (éds), Fourth International Conference on Simulation of Adaptive Behavior (SAB-96) [30] BONASSO P.R., FIRBY J.R., GAT E., KORTENKAMP D., MILLER D.P. et SLACK M.G. Experiences with an architecture for intelligent, reactive agents. Journal of Experimental and Theoretical Artificial Intelligence, Vol. 9(1) (1997) [31] BOND A. et GASSER L. Readings in Distributed Artificial Intelligence. Morgan Kaufmann Publishers, [32] BONIOL F. Une approche synchrone multi-formalismes pour la conception de systèmes temps-réel distribués. in Technique et Science Informatiques (TSI), Vol. 17(9), pp Hermès, 1998.

235 BIBLIOGRAPHIE 235 [33] BOUFAÏED H. Machines d exécution pour langages synchrones. Thèse de doctorat, Université de Nice-Sophia Antipolis, novembre [34] BOULANGER F. Intégration de modules synchrones dans la programmation par objets. Thèse de doctorat, Université de Paris XI, Orsay, décembre [35] BOULANGER F., ANDRÉ C., PÉRALDI M.A., RIGAULT J.P. et VIDAL- NAQUET G. Objets et programmation synchrone. in Modélisation des Systèmes Réactifs, pp Brest (France). [36] BOULANGER F., DELEBECQUE H. et VIDAL-NAQUET G. Intégration de modules synchrones dans un langage à objets. in Real-Time Systems Conference, pp Paris (France). [37] BOURNAI P., CHÉRON B., GAUTIER T., HOUSSAIS B. et LE GUERNIC P. SI- GNAL manual. Manuel de référence, IRISA (Rennes), juillet [38] BOUSSINOT F. La programmation réactive : application aux systèmes communicants. Collection technique et scientifique des télécommunications (CNET/ENST). Masson, [39] BOUSSINOT F. et DOUMENC G. Manuel de référence de RC. Manuel de référence, Centre de Mathématiques Appliquées (École des Mines de Paris), [40] BOUSSINOT F., DOUMENC G. et STEFANI J.B. Reactive objects. Rapport de recherche 2664, INRIA, [41] BROOKS R.A. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation (1986), pp [42] BROOKS R.A. How to build complete creatures rather than isolated cognitive simulators. in K. VanLehn (éd.), Architectures for Intelligence, pp Lawrence Erlbaum Associates, [43] BROOKS R.A. Cambrian Intelligence : the early history of the new AI. MIT Press, [44] BRYSON J. Cross-paradigm analysis of autonomous agent architecture. Journal of Experimental and Theoretical Artificial Intelligence, Vol. 12(2) (2000) [45] BURDEA G. et COIFFET P. La Réalité Virtuelle. Hermès, [46] BURKHARDT J.M., LOURDEAUX D. et FUCHS P. Conception d un système de RV pour la formation des agents de conduite aux opérations en milieu ferroviaire. in Journées Réalité Virtuelle et Cognition (ReViCo 99), pp Paris (France). [47] CASSELL J. et al.. An architecture for embodied conversational characters. in Proceedings of the First Workshop on Embodied Conversational Characters Tahoe City (USA). [48] CAVAZZA M., CHARLES F. et MEAD S.J. Agents Interaction in Virtual Storytelling. in Intelligent Virtual Agents Workshop (IVA 01), Lecture Notes in Artificial Intelligence (LNAI). Springer-Verlag, Madrid (Espagne). [49] CHICOISNE G. et PESTY S. The puppeteer behind the avatar. in SIGGRAPH Sketches and Applications. ACM Press, Nouvelle-Orléans (USA). [50] CODOGNET P. Programmation logique avec contraintes : une introduction. in Technique et Science Informatiques (TSI), Vol. 14(6). Hermès, 1995.

236 236 BIBLIOGRAPHIE [51] CODOGNET P. Declarative behaviors for virtual creatures. in Eighth International Conference on Augmented Reality and Tele-existence (ICAT 99). IOS Press, Tokyo (Japon). [52] CODOGNET P. Animating virtual creatures by constraint-based adaptive search. in Fourth International Conference on Virtual Systems and Multimedia (VSMM2000). IOS Press, Gifu (Japon). [53] CODOGNET P. A constraint-based language for virtual agents. in New Trends in Constraints, Lecture Notes in Artificial Intelligence (LNAI). Springer-Verlag, [54] COMAR C., GASPERONI F. et SCHONBERG E. The GNAT project : a GNU-Ada 9X compiler. Rapport technique, New-York University, [55] COST S.R., CHEN Y., FININ T., LABROU Y. et PENG Y. Modeling agent conversations with colored Petri nets. in Agents 99 : Working Notes of the Workshop on Specifying and Implementing Conversation Policies Seattle (USA). [56] DEMAZEAU Y. From interactions to collective behaviour in agent-based systems. in V. Lesser (éd.), First International Conference on Multi-Agent Systems (ICMAS 95), pp AAAI Press, San Francisco (USA). [57] DENEUBOURG J.L. Application de l ordre par fluctuations à la description de certaines étapes de la construction du nid chez les termites. Ins. Soc., Vol. 24 (1977) [58] DIAZ D. Étude de la compilation des langages logiques de programmation par contraintes sur les domaines finis : le système clp(fd). Thèse de doctorat, Université d Orléans / INRIA Rocquencourt, [59] DONIKIAN S. et RUTTEN R. Reactivity, concurrency, data-flow and hierarchical preemption for behavioural animation. in Fifth Eurographics Workshop on Programming Paradigms in Graphics. Springer-Verlag, Maastricht (Pays- Bas). [60] DROGOUL A. De la simulation multi-agent à la résolution collective de problèmes : une étude de l émergence de structures d organisation dans les systèmes multi-agents. Thèse de doctorat, Université de Paris VI, novembre [61] DROGOUL A. Systèmes multi-agents situés. Mémoire d habilitation, mars [62] DROGOUL A. et MEYER J.A. (éds). Intelligence artificielle située : cerveau, corps et environnement. Hermès, [63] EATON P.S., FREUDER E.C. et WALLACE R.J. Constraints and agents : confronting ignorance. in AI magazine, Vol. 19(2). American Association for Artificial Intelligence, [64] FERBER J. Vers une intelligence collective. InterEditions, [65] FUNGE J. Making them behave : cognitive models for computer animation. Thèse de doctorat, University of Toronto, [66] FUNGE J., TU X. et TERZOPOULOS D. Cognitive modeling : knowledge, reasoning and planning for intelligent characters. in SIGGRAPH 99, pp ACM Press, Los Angeles (USA). [67] GAT E. Reliable goal-directed reactive control for real-world autonomous mobile robots. Thèse de doctorat, Virginia Polytechnic Institute and State University, 1991.

237 BIBLIOGRAPHIE 237 [68] GEIB C., LEVISON L. et MOORE M.B. Sodajack : an architecture for agents that search and manipulate objects. Rapport technique, Department of Computer and Information Science, University of Pennsylvania (USA), [69] GEORGET Y. Extensions réactives de la programmation par contraintes. Thèse de doctorat, École Polytechnique / INRIA Rocquencourt, octobre [70] GONDRAN M. et MINOUX M. Graphes et algorithmes. Eyrolles, Collection de la Direction des Études et Recherches d Électricité de France. [71] GUESSOUM Z. Un environnement opérationnel de conception et de réalisation de systèmes multi-agents. Thèse de doctorat, LAFORIA, Université Paris VI, mai [72] GUILLOT A. et MEYER J.A. Synthetic animals in synthetic worlds. in T.L. Kunii et A. Luciani (éds), Cyberworlds. Springer-Verlag, [73] GUILLOT A. et MEYER J.A. From SAB94 to SAB2000 : what s new, animat? in J.A. Meyer et S.W. Wilson (éds), From Animals to Animats 6 : proceedings of the Sixth International Conference on Simulation of Adaptive Behaviour. MIT Press, Paris (France). [74] GUILLOT A. et MEYER J.A. The animat contribution to cognitive systems research. Journal of Cognitive Systems Research, (2001). À paraître. [75] GUTKNECHT O. et FERBER J. MadKit : une architecture de plate-forme multiagent générique. Rapport technique, Laboratoire d Informatique, de Robotique et de Microélectronique de Montpellier (LIRM), mai [76] HAINQUE O. Compilation séparée et exécution distribuée d applications synchrones modulaires programmées en Esterel. Thèse de doctorat, École Nationale Supérieure des Télécommunications, juin [77] HALBWACHS N., CASPI P., RAYMOND P. et PILAUD D. The synchronous data-flow programming language LUSTRE. in Special issue on Another Look at Real-time Systems, Proceedings of the IEEE, Vol. 79, pp [78] HAREL D. et PNUELI A. On the development of reactive systems. in K.R. Apt (éd.), Logics and Models of Concurrent Systems (NATO ASI Series), Vol. 13, pp Springer-Verlag, [79] HARROUET F. oris : s immerger par le langage pour le prototypage d univers à base d entités autonomes. Thèse de doctorat, Laboratoire d Informatique Industrielle (LI2/ENIB) / Université de Bretagne Occidentale, décembre [80] HAYES-ROTH B. et VAN GENT R. Story-making with improvisational puppets. in W.L. Johnson (éd.), First International Conference on Autonomous Agents (Agents 97), pp ACM Press, Marina del Rey (USA). [81] HORN F. et STEFANI J.B. On programming and supporting multimedia object synchronization. The Computer Journal, Vol. 36(1) (1993) [82] HUTZLER G. Du jardin des hasards aux jardins de données : une approche artistique et multi-agent des interfaces homme/systèmes complexes. Thèse de doctorat, Université de Paris VI, janvier [83] IEROSALIMSCHY R., DE FIGUEIREDO L.H. et CELES W. Reference manual of the programming language Lua 3.2. Manuel de référence, TeCGraf, PUC-Rio, mai 1999.

238 238 BIBLIOGRAPHIE [84] JESSEL J.P., JASPART C., FLORES J.J. et JOSSEAU A. Animation de synthèse et concepts de réalité virtuelle pour l art du spectacle et l art plastique numérique. in Journées Réalité Virtuelle et Cognition (ReViCo 99), pp Paris (France). [85] JOHNSON W.L., RICKEL J., STILES R. et MUNRO A. Integrating pedagogical agents into virtual environments. in Presence : the Journal of Teleoperators and Virtual Environments, Vol. 7(6), pp MIT Press, [86] KALAWSKY R.S. The future of Virtual Reality and prototyping. in Colloque Scientifique International des Premières Rencontres Internationales de Réalité Virtuelle de Laval, pp Laval (France). [87] KOGA Y. et al.. On intelligent digital actors. in Imagina Monte-Carlo (Monaco). [88] LE PAGE C. et GINOT V. Vers un simulateur générique de la dynamique des peuplements piscicoles. in JFIADSMA 97, pp Hermès, La Colle sur Loup (France). [89] LESTER J.C. et STONE B.A. Increasing believability in animated pedagogical agents. in W.L. Johnson (éd.), First International Conference on Autonomous Agents (Agents 97), pp ACM Press, Marina del Rey (USA). [90] LEVESQUE H.J. et al.. Golog : a logic programming language for dynamic domains. Journal of Logic Programming (1994), pp [91] LEVISON L. et BADLER N.I. How animated agents perform tasks : connecting planning and manipulation through object-specific reasoning. in Towards Physical Interaction and Manipulation (AAAI 1994 Spring Symposium). AAAI Press, Stanford (USA). [92] LOYALL B.A. Believable agents : building interactive personalities. Thèse de doctorat, Computer Science Department, Carnegie Mellon University, mai [93] MAES P. How to do the right thing. Connection Science Journal, Vol. 1(3) (1989) [94] MAES P. Artificial Life meets entertainment : lifelike autonomous agents. in Special Issue on New Horizons of Commercial and Industrial AI, Vol. 38(11) of Communications of the ACM, pp ACM Press, [95] MAES P. et al.. The ALIVE system : wireless, full-body interaction with autonomous agents. Rapport technique, MIT Media Laboratory Perceptual Computing, novembre [96] MAGNIN L. Modélisation et simulation de l environnement dans les systèmes multi-agents. Thèse de doctorat, LAFORIA, Université Paris VI, novembre [97] MATEAS M. An Oz-centric view of interactive drama and believable agents. Rapport technique, School of Computer Science, Carnegie Mellon University, [98] MEURISSE T. et BRIOT J.P. Une approche à base de composants pour la conception d agents. in M. Dao et C. Dony (éds), Technique et Science Informatiques (TSI), Vol. 20(4), pp Hermès, [99] MEYER J.A. et GUILLOT A. Simulation of adaptive behavior in animats : review and prospect. in J.A. Meyer et S.W. Wilson (éds), From Animals to Animats : proceedings of the First International Conference on Simulation of Adaptive Behaviour, pp MIT Press, Paris (France).

239 BIBLIOGRAPHIE 239 [100] MEYER J.A. et GUILLOT A. From SAB90 to SAB94 : four years of animat research. in Cliff et al. (éds), From Animals to Animats 3 : proceedings of the Third International Conference on Simulation of Adaptive Behavior. MIT Press, Brighton (Royaume-Uni). [101] MÜLLER J.P. Control architectures for autonomous and interacting agents : a survey. in L. Cavedon et al. (éds), Intelligent Agent Systems : Theoretical and Practical Issues, Vol of Lecture Notes in Computer Science (LNCS), pp Springer-Verlag, [102] MÜLLER J.P. et PISCHEL M. The agent architecture InteRRaP : concept and application. Rapport de recherche, DFKI Saarbrücken (Allemagne), [103] MOREAU G. Modélisation du comportement pour la simulation interactive : application au trafic routier multimodal. Thèse de doctorat, IFSIC / IRISA, novembre [104] NWANA H.S. et al.. ZEUS : a toolkit for building distributed multi-agent systems. in Third International Conference on Autonomous Agents (Agents 99) Seattle (USA). [105] OOKITA S.Y. et TOKUDA H. Psychotherapy with virtual pet agents : the PSY- AAAT prototype system. in Third Asian Pacific Computer and Human Interaction. IEEE Computer Society, Kangawa (Japon). [106] PARR T. et QUONG R. ANTLR : A Predicated-LL(k) Parser Generator. Journal of Software Practice and Experience, Vol. 25(7) (1995) [107] PERLIN K. et GOLDBERG A. Improv : a system for scripting interactive actors in virtual worlds. in SIGGRAPH 96, pp ACM Press, Nouvelle- Orléans (USA). [108] REICH B.D. An architecture for behavioral locomotion. Thèse de doctorat, Department of Computer and Information Science, University of Pennsylvania, [109] REYNOLDS C.W. Flocks, herds and schools : a distributed behavioral model. in SIGGRAPH 87, Vol. 21(4) of Computer Graphics, pp ACM Press, Anaheim (USA). [110] REYNOLDS C.W. Steering behaviors for autonomous characters. in Game Developers Conference San Jose (USA). [111] RHEINGOLD H. La réalité virtuelle : quand l illusion a toutes les apparences de la réalité. Dunod, [112] RICHARD N. Description de comportements d agents autonomes évoluant dans des mondes virtuels. Thèse de doctorat, ENST, octobre [113] RICHARD N. et CODOGNET P. Multi-way constraints for describing high-level object behaviours in VRML. in Interaction Agents Workshop - Advanced Visual Interfaces Conference (AVI 98) L Aquila (Italie). [114] RICHARD N., CODOGNET P. et GRUMBACH A. Using constraints to describe high-level behaviours in virtual worlds. in Eurographics 98 - Short paper session Lisbonne (Portugal). [115] RICHARD N., CODOGNET P. et GRUMBACH A. The InViWo virtual agents. in Eurographics 99 - Short paper session Milan (Italie).

240 240 BIBLIOGRAPHIE [116] RICHARD N., CODOGNET P. et GRUMBACH A. The InViWo toolkit : describing autonomous virtual agents and avatars. in Intelligent Virtual Agents Workshop (IVA 01), Lecture Notes in Artificial Intelligence (LNAI). Springer-Verlag, Madrid (Espagne). [117] RICHARD N. et GRUMBACH A. Préciser et étendre le concept d avatar. in Journées Réalité Virtuelle et Cognition (ReViCo 99), pp Paris (France). [118] ROSENBLATT J.K. DAMN : a Distributed Architecture for Mobile Navigation. Thèse de doctorat, Robotics Institute, Carnegie Mellon University, janvier [119] ROSENBLOOM P.S. et al.. Intelligent automated agents for tactical air simulation : a progress report. in Fourth Conference on Computer Generated Forces and Behavioral Representation, pp Orlando (USA). [120] VAN ROSSUM G. Python Reference Manual (release 2.1). Manuel de référence, PythonLabs, avril URL : [121] VAN ROSSUM G. Python Tutorial (release 2.1). Tutoriel, PythonLabs, avril URL : [122] ROY P., LIRET A. et PACHET F. A framework for constraint satisfaction. Rapport de recherche, Laboratoire d Informatique de Paris 6 (LIP6), février [123] SANZA C. Évolution d entités virtuelles coopératives par système de classifieurs. Thèse de doctorat, Université Paul Sabatier (Toulouse), juin [124] SARASWAT V.A., JAGADEESAN R. et GUPTA V. Foundations of timed concurrent constraint programming. in S. Abramsky (éd.), Ninth IEEE Symposium on Logic in Computer Science. IEEE Press, Paris (France). [125] SARASWAT V.A., VAN HENTENRYCK P., CODOGNET P. et al. (éds). Constraint Programming, Vol. 28(4). ACM Computing Surveys, [126] SCHAPS G.L. Compiler Construction with ANTLR and Java. Dr Dobb s Journal, (1999). [127] SMYTH M.M., COLLINS A.F., MORRIS P.E. et LEVY P. Cognition in action. Lawrence Erlbaum Associates, [128] STEELS L. The artificial life roots of artificial intelligence. in Artificial Life Journal, Vol. 1(1), pp MIT Press, [129] THALMANN D., MUSSE S.R. et KALLMANN M. Virtual humans behaviour : individuals, groups and crowds. in Proceedings of Digital Media Futures International Conference Bradford (Royaume-Uni). [130] THALMANN D., NOSER H. et HUANG Z. Autonomous virtual actors based on virtual sensors. Lecture Notes in Artificial Intelligence (LNCS). Springer- Verlag, [131] THOMAS G. Environnements virtuels urbains : modélisation des informations nécessaires à la simulation de piétons. Thèse de doctorat, Université de Rennes I, décembre [132] TORGUET P. et al.. CAVALCADE : a system for collaborative virtual prototyping. Journal of Design and Innovation Research, Vol. 2(1) (2000). [133] TRAVERS M.D. Programming with Agents : new metaphors for thinking about computation. Thèse de doctorat, Media Arts and Sciences, MIT, juin 1996.

241 BIBLIOGRAPHIE 241 [134] TU X. Artificial animals for computer animation : biomechanics, locomotion, perception and behavior. Thèse de doctorat, University of Toronto, [135] TYRRELL T. Computational mechanisms for action selection. Thèse de doctorat, University of Edinburgh, [136] VERNA D. Télé-opération et réalité virtuelle : assistance à l opérateur par modélisation cognitive de ses intentions. Thèse de doctorat, École Nationale Supérieure des Télécommunications, février [137] VOYER R. Implémentation d architectures efficaces pour la représentakation des connaissances : application aux langages Loopsiris et OKS. Thèse de doctorat, Université de Paris VI, février [138] WATERS R.C. et al.. Diamond Park and Spline : a social Virtual Reality system with 3D animation, spoken interaction, and runtime modifiability. Rapport technique, Mitsubishi Electric Research Laboratory (MERL), novembre [139] WOOLDRIDGE M. et JENNINGS N.R. Pitfalls of agent-oriented development. in Second International Conference on Autonomous Agents (Agents 98), Vol. 144(1), pp IEEE Transactions on Software Engineering, Minneapolis/St Paul (USA). [140] ZIEMKE T. Adaptive behavior in autonomous agents. in Presence : the Journal of Teleoperators and Virtual Environments, Vol. 7(6), pp MIT Press, 1998.