l Université de Bretagne Occidentale

Transcription

1 THÈSE présentée devant l Université de Bretagne Occidentale pour obtenir le grade de : DOCTEUR DE L UNIVERSITÉ DE BRETAGNE OCCIDENTALE Mention INFORMATIQUE par Valéry RAULET Équipe d accueil 2215 (UBO, ENIB) Laboratoire d Ingénierie Informatique (LI2/ENIB) Titre de la thèse : Prototypage interactif et collaboratif. Vers une architecture de communication pour une interactivité coopérante dynamique dans les environnements virtuels distribués. Soutenue le 18 juin 2003 devant la commission d examen : M. : Marcel LE FLOCH Président MM. : François BOURDON Rapporteurs Jean-Pierre JESSEL MM. : Gilles BUREL Examinateurs Alexis NÉDÉLEC Jacques TISSEAU M. : Vincent RODIN Membre invité

2

3 Prototypage interactif et collaboratif. Vers une architecture de communication pour une interactivité coopérante dynamique dans les environnements virtuels distribués. Mémoire de thèse VALÉRY RAULET EA2215 (UBO, ENIB) Juin 2003

4 Mémoire de thèse Équipe d Accueil 2215 Valéry RAULET [email protected] url : raulet/ tel : +33 (0) fax : +33 (0) École Nationale d Ingénieurs de Brest Laboratoire d Ingénierie Informatique Technopôle Brest-Iroise Site de la Pointe du Diable Parvis Blaise PASCAL Plouzané, Finistère Adresse postale : C.S , Brest CEDEX 3, France ii

5 Remerciements Je tiens, par l intermédiaire de cette thèse, à remercier tous ceux qui ont, de près ou de loin, participé à la réalisation de cette thèse. Je remercie tout d abord Jacques TISSEAU, professeur à l École Nationale d Ingénieurs de Brest et responsable du Laboratoire d Ingénierie Informatique, pour m avoir accepté au sein de son équipe de recherche. Je remercie également Alexis NÉDÉLEC et Vincent RODIN pour m avoir guidé et encadré pendant la réalisation de cette thèse. Je tiens également à remercier Monsieur François BOURDON, responsable de l équipe de recherche MAD (Modèles, Agents et Décision) du laboratoire GREYC de l Université de Caen et Monsieur Jean-Pierre JESSEL de l Équipe Synthèse d Images de l Institut de Recherche en Informatique de Toulouse (IRIT), qui ont accepté d être les rapporteurs de cette thèse. Ces remerciements vont également à Messieurs Marcel LE FLOCH et Gilles BUREL qui ont bien voulu participer à mon jury de thèse. Je désire également remercier toute l équipe du Laboratoire d Ingénierie Informatique pour m avoir soutenu et conseillé tout au long de ces années de recherche, et tout particulièrement Pascal BALLET, Fabrice HARROUET, Elyes LAMINE et Ronan QUERREC qui ont croisé mon chemin dans ce laboratoire et dont je garderai un souvenir inoubliable. Enfin, je remercie ma famille et mes amis qui m ont supporté pendant tant d années. Je remercie plus particulièrement Mademoiselle Blandine LE CARLUER pour m avoir suivi dans cette dure épreuve et qui continuera, je l espère, à m apporter soutien et réconfort dans les moments difficiles. iii

6 Remerciements iv

7 Table des Matières Remerciements Table des Matières Liste des Figures iii v xi Introduction 1 Partie I Le contexte 5 Introduction 7 1 La Réalité Virtuelle Introduction Définition Tromper l utilisateur Échange naturel entre l utilisateur et l ordinateur Présence Autonomie Historique Les outils La partie matérielle La partie logicielle Les applications La simulation militaire Les jeux La formation Le prototypage Conclusion v

8 Table des Matières 2 Les Systèmes Multi-Agents Introduction Les systèmes multi-agents Historique Les objectifs Les fonctionnalités des SMA Agent intelligent Agents purement réactifs Agents cognitifs Les domaines d application La résolution de problèmes La simulation multi-agents Conclusion Conclusion 31 Partie II État de l art l architecture de communication 33 Introduction 35 1 Les réseaux : support de la communication Introduction Les données échangées dans un environnement virtuel Le réseau physique et logique La bande passante La latence La fiabilité La topologie du réseau physique Les protocoles de communication Les protocoles de l Internet La qualité de service La diffusion La diffusion restreinte La diffusion restreinte fiable Les protocoles spécialisés Conclusion Les architectures de communication Introduction La communication par messages Message Passing Interface (MPI) Parallel Virtual Machine (PVM) Communication par mémoire partagée Les espaces partagés vi

9 Table des Matières Linda JavaSpaces La plate-forme EQUIP Les services de CORBA Conclusion Le bus logiciel Remote Procedure Call (RPC) CORBA CORBA temps réel Les critères de choix Conclusion 87 Partie III État de l art Les environnements virtuels distribués 89 Introduction 91 1 Les architectures pour la simulation distribuée Introduction Historique Distributed Interactive Simulation (DIS) L architecture Protocol Data Unit (PDU) La technologie et ses limites Conclusion High Level Architecture (HLA) L architecture Les services du RTI Gestion de la fédération Gestion de la déclaration : publication/souscription Gestion des objets Comparaison entre HLA et DIS Comparaison entre HLA et CORBA Conclusion Les plates-formes de réalité virtuelle distribuée Introduction Les techniques de la réalité virtuelle distribuée Le dead reckoning Le filtrage Consistance de la base de données Gestion du temps Répartition de la charge Discussion vii

10 Table des Matières 2.3 Taxonomie des environnements virtuels collaboratifs Classification suivant des critères de fidélité Classification technique Les plates-formes existantes Conclusion Conclusion 151 Partie IV Le prototypage interactif et collaboratif 153 Introduction Le prototypage interactif et collaboratif La plate-forme oris Le prototypage Notre approche Le langage oris Simulation participative distribuée en oris L architecture Modèle réel / fantôme Modification dynamique de l environnement Protocole de gestion des instances Communication entre agents Génération automatique de code Conclusion Gestion dynamique de modèles sous HLA Le CERTI L architecture Le modèle objet du CERTI Extension de l API pour un modèle objet dynamique Description du modèle objet Modification du modèle objet par l API existante Modification de l arbre du modèle objet Modification de l espace de routage Conclusion Exemple en orisdis Existence de l agent et mise à jour de ses états Génération automatique de code Interaction sur le réel Interaction sur le fantôme Interaction sur un état dynamique Ajout dynamique de fonctionnalités à l agent viii

11 Table des Matières 3.3 Conclusion Conclusion et perspectives 213 Annexes 217 Liste des acronymes 265 Liste des sites Internet 269 Références bibliographiques 271 Résumé / Abstract 283 Index 285 ix

12 Table des Matières x

13 Liste des Figures Le contexte Traitement de l information selon [Grumbach 01] Interaction, Immersion, Imagination [Burdea et al. 93] Les trois médiations du modèle en réalité virtuelle [Tisseau 01] SécuRévi [Querrec 02] Différence entre objet et agent [Ferber 97] Caractéristiques d un agent autonome [Richard 01] Organisations et structures organisationnelles (d après [Ferber 95]) Architecture typique d un agent hybride (d après [Richard 01]) État de l art l architecture de communication Le modèle OSI Différentes topologies de réseaux Synchronisation par échange de messages NTP [Fujimoto 00] Les 4 composants vrtp : client, serveur, pair à pair et surveillance Les différents démons du protocole DWTP [Broll 98] Différentes approches de communication, évaluations [Waters et al. 97] Le partage d information avec ISTP Les différents protocoles de ISTP L architecture de Virtual Society [Honda et al. 96] L architecture de Gaia [Ko et al. 99] Architecture de ViSTA Javaspaces Le service d évènement de CORBA Les modèles de communication du service d évènement Appels et messages des RPC [Tanenbaum 94] xi

14 Liste des Figures 2.6 Étapes d exécution de RPC [Tanenbaum 94] Les différents services de CORBA Les différents services de CORBA (vue détaillée) Les composants de l échange client/serveur de CORBA Interopérabilité via IIOP L architecture de Nomad [Wilson et al. 01] État de l art Les environnements virtuels distribués 89 1 Classification des systèmes de CSCW [Ellis et al. 91] CVW, exemple d outil de travail collaboratif Les différentes parties de l architecture de DIS La liste des PDU du protocole DIS Le PDU Entity State [Hofer et al. 95] La stratégie d ensemble M&S du DMSO [Department of Defense 95] L architecture HLA Le cycle de vie d une simulation HLA Publication des objets Spécialisation des classes d objets HLA Généralisation des attributs d une classe Comparaison du cycle de vie de HLA et DIS [Calvin et al. 95] Structure EBI [Barrett et al. 96] Comparaison entre CORBA et HLA Échange d informations entre les entités sources (d après [Singhal 96]) Échange d informations entre l hôte source et l hôte distant Estimation de la trajectoire d une entité (ordre 0) Estimation de la trajectoire d une entité Algorithme PHBDR [Singhal 96] Estimation basée sur l intention [Szwarcman et al. 01] Interactions possibles Conscience suivant le nimbus et le focus Activation des objets tiers Problème simple d ordonnancement causal Relation happens-before à l aide d un vecteur temps Les types de simulateurs suivant le mécanisme de régulation temporel Utilisation du lookahead dans HLA Classification des algorithmes de répartition de la charge Granularité et performance de la répartition de la charge, d après [Jensen 96] Différentes topologies de communication pour les bases de données Modularité de Bamboo [Liles 98] interface HLA à Bamboo [Liles 98] Modèle objet utilisé dans Bamboo [Liles 98] xii

15 Liste des Figures 2.20 Architecture répliquée de DIVE Mécanisme de communication de VIPER [Torguet 98] Le prototypage interactif et collaboratif Démarche de prototypage classique (d après [Harrouet 00]) Démarche de prototypage interactif (d après [Harrouet 00]) Double infrastructure Communication entre l API oris et l API du RTI Composants du gestionnaire orisrti Interaction entre réel et fantômes Évolution d un attribut dynamique avec mise à jour du réel Exemple de l interaction de deux utilisateurs Dynamicité de l application Exemple de classe du fichier FED (syntaxe à la LISP) Exemple d instances créées après la modification de la classe Classe générique pour le transport d attributs dynamiquement ajoutés Relations entre classes, instances et attributs dans une simulation HLA Relation entre les éléments dans une simulation HLA / oris Contraintes appliquées sur les instances de classes et d attributs oris Interactions entre les agents réels et l orisrti Interactions entre l orisrti et les agents fantômes Espace de routage de réception des interactions par le fédéré Communication entre les agents Génération automatique de code Exemple de code XML pour la génération automatique de code L architecture du CERTI, d après [Bréholée et al. 02] Exemple de scénario de transfert de données (d après [Bréholée et al. 02]) La gestion du modèle objet dans le CERTI Le nouveau modèle objet du CERTI Description du modèle objet Ajout au modèle d interaction Ajout au modèle d objet Modification de l espace de routage Diagramme de classe entre les classes générées et les classes de base Fichier de description en XML Fichier FED généré automatiquement et servant à initialiser le RTI Exemple de code généré pour la classe du réel Cheminement d appels de méthodes à partir d une requête sur le réel Exemple de code généré pour la classe du fantôme Cheminement d appels de méthodes à partir d une requête sur le fantôme Blocage de la boucle à l aide d un attribut xiii

16 Liste des Figures 3.9 Ajout de fonctionnalités à la classe Code dynamiquement ajouté à la classe xiv

17 Introduction 1 La recherche perpétuelle de nouveaux produits répondant aux besoins des consommateurs a rendu leur conception beaucoup plus complexe. Cette complexification met en œuvre une profusion et une hétérogénéité de points de vue, de compétences, de disciplines et de technologies [Lamine 01]. Meinadier fait remarquer que l on peut distinguer deux principaux types de complexité dans un système [Meinadier 98] : La complexité statique qui est liée à l architecture du système, c est-à-dire le nombre de fonctions, de composantes, de relations, etc, la complexité dynamique qui est liée à la dynamique des interactions entre les soussystèmes et les composants ainsi qu à l existence de relations bouclées entre les fonctions. Faisant appel à des domaines de recherche différents, le recours à des modélisations est devenu nécessaire afin d analyser le comportement du système. Difficile à déterminer, la complexité dynamique nécessite une étape de prototypage afin de paramétrer au mieux le modèle et ainsi correspondre aux besoins des concepteurs. Les travaux menés sur oris [Harrouet 00] ont permis d offrir un outil de prototypage interactif permettant à l utilisateur de prototyper le modèle suivant son comportement dynamique sans recourir à des phases d aller/retour permanentes entre conception et simulation. 1 Même un chemin de mille lieues commence par un pas. Proverbe Japonais 1

18 Introduction Nos travaux portent sur la mise en œuvre d une architecture orisdis permettant la réalisation d applications de prototypage interactif et collaboratif. Ainsi, nous rendons possible l élaboration d un modèle de manière collaborative en permettant aux différents acteurs de préciser l objectif du modèle. De l agent à la réalité virtuelle distribuée Créer un système, c est rassembler différents éléments dotés d un comportement simple. L agent est un moyen informatique permettant de construire un objet autonome doté de son propre comportement, qui répond à un modèle défini par son concepteur. Simple à mettre en œuvre, l agent capte son environnement proche, effectue un traitement plus ou moins complexe ou plus ou moins intelligent. En réponse à cette perception et suivant son intelligence, il réagit ou agit et modifie l environnement suivant les besoins de son modèle. Complexifier le système, c est composer ou agréger différents agents. On obtient un système multi-agents qui permet de modéliser la complexité statique dans chacun de ses agents ainsi que la complexité dynamique, à travers les interactions entre ces différents agents. Difficile à prévoir, cette dynamique fait souvent l objet d un prototype afin de constater l émergence d un comportement désiré ou une auto-organisation menant vers le même but que son concepteur. Seulement, cette étape de composition de différents modèles simples nécessite souvent le recours à des modifications d un ou de l ensemble des modèles. Introduire l homme dans la boucle et lui permettre d agir directement sur le modèle offre la possibilité de réduire le temps de conception en évaluant interactivement les modifications apportées. Cette simulation participative rend l homme pleinement actif dans ce processus de mise au point. La réalité virtuelle a révolutionné la vision de l ordinateur vis à vis de l homme. Elle permet un couplage très fort entre les deux éléments et ouvre la voie à de nouvelles applications offrant un haut niveau de créativité à l utilisateur. L homme, non seulement dans la boucle, se place lui même, à travers son avatar, au même niveau conceptuel. Cette relation d égal à égal autorise une plus grande autonomie des modèles et par voie de conséquence, une plus grande autonomie de l utilisateur [Tisseau 01]. Comme la conception d un modèle complexe est de plus en plus le fruit du travail de nombreux experts, il devient nécessaire d offrir un outil permettant de confronter les différentes idées de chacun. La réalité virtuelle distribuée propose de lever les barrières des distances géographiques en permettant aux différents acteurs d être présents en un même endroit virtuel et surtout au même instant. Notre approche est basée sur l utilisation des systèmes multi-agents au sein d un environnement virtuel. Ce choix offre à l utilisateur un moyen d observer, d expérimenter et de fa conner un modèle numérique d une manière similaire aux investigations qu il peut mener autour d un système du monde réel [Harrouet 00]. 2

19 Introduction Organisation de ce mémoire Ce document est organisé en quatre parties. Le contexte présente deux des trois domaines ayant trait à notre problématique. Tout d abord, un premier chapitre qui présente la réalité virtuelle et montre comment l immersion de l utilisateur est réalisée, à travers différents capteurs et effecteurs et aussi, à travers le monde simulé. La réalité virtuelle a pour objectif de fournir une représentation réaliste et interactive de l environnement commun et partagé par tous les utilisateurs. Il est suivi d un deuxième chapitre qui offre un aperçu des systèmes multi-agents permettant de rendre un environnement virtuel beaucoup plus interactif. Les systèmes multi-agents viennent en complément de la réalité virtuelle. Ils permettent de doter les entités virtuelles de comportements réalistes qui peuvent être modifiés par les utilisateurs. Ces comportements sont plus ou moins développés en fonction de la capacité de décision de ces entités. Le reste du mémoire concerne les aspects distribués de notre problématique. La deuxième partie concerne essentiellement l étude des différentes couches intervenant dans l échange d informations entre les différents ordinateurs participant à cette immersion collective. Un premier chapitre aborde les propriétés offertes par le réseau et étudie comment ce système de transport peut gérer au mieux les données à véhiculer. Le second chapitre s intéresse aux paradigmes qui ont été élaborés dans le but de réaliser des applications coopérantes. D un niveau conceptuel supérieur, ces paradigmes offrent des facilités de programmation non négligeables et apportent tous une réponse au partage de données. La troisième partie s attache aux aspects distribués dans un contexte de réalité virtuelle. Elle présente cet aspect particulier des systèmes coopératifs qui requièrent une synchronisation temporelle. Le premier chapitre s attache à présenter les résultats des recherches menées par le ministère américain de la défense dans le but de promouvoir une architecture la mieux adaptée au développement d une telle application tout en permettant sa réutilisation. DIS 2 et HLA 3 constituent les deux principales architectures retenues. Le second chapitre s intéresse aux technologies adaptées au contexte de la réalité virtuelle distribuée. Nous présentons toutes les optimisations effectuées tant au niveau architectural qu au niveau de la transformation des données afin d améliorer la qualité du rendu, l extensibilité de l application et bien d autres aspects. Une taxonomie est réalisée afin de confronter les différentes plates-formes développées à ce jour. La dernière partie présente notre modèle destiné à créer une application de prototypage interactif, collaboratif et coopératif. Le premier chapitre présente une partie sur l intégration de l architecture de simulation militaire HLA à notre plate-forme multi-agents oris. Nous y détaillons les différentes technologies nécessaires à la réalisation d une plate-forme de prototypage distribuée et, plus précisément, certains aspects sur l évolution des modèles 2 DIS : Distributed Interactive Simulation 3 HLA : High Level Architecture 3

20 Introduction durant la simulation. La seconde partie intéresse plus particulièrement le concepteur d une application puisqu il offre un formalisme de spécification simple permettant de faciliter le développement de l application et surtout, de générer automatiquement le code nécessaire à la distribution de l application. Le second chapitre présente les modifications apportées à l interface du CERTI un RTI compatible HLA pour permettre une évolution dynamique de l application durant la simulation. Enfin, nous conclurons en présentant quels avantages nous pouvons retirer de cette architecture. Cette conclusion permet de faire le point sur la norme HLA par rapport aux applications de réalité virtuelle distribuées et de proposer des évolutions. Remarques complémentaires Le développement actuel d Internet en fait une source primordiale pour se documenter et approfondir certains sujets. Nous avons donc ajouté une annexe contenant une liste de sites Internet en relation avec les sujets traités. À chaque fois que nous parlons d un sujet et qu une référence Internet est disponible, elle est annoté par un arobase ). Par ailleurs, lorsque nous faisons référence à des méthodes relatives à certaines interfaces de programmation, nous adoptons l écriture utilisée dans les documentations de l architecture HLA. Par exemple, la méthode updateattributevalues() sera notée Update Attribute Values. Enfin, ces travaux ont fait l objet de plusieurs publications scientifiques : [Rodin et al. 00] [Raulet et al. 02a] [Raulet et al. 02b] [Raulet et al. 03b] [Raulet et al. 03a]. Les quatre dernières publications sont fournies en annexe. 4

21 Partie I Le contexte 5

22 Le contexte 6

23 Introduction À la charnière de différentes disciplines, la réalité virtuelle se propose de synthétiser les résultats de recherches en simulation, en informatique graphique, en audiovisuel et en de nombreuses autres disciplines. Chaque avancée dans l une de ces disciplines profite à la réalité virtuelle et permet à l ordinateur d être encore plus en adéquation avec les idées de l utilisateur. En effet, le résultat présenté par l ordinateur correspond aux conséquences des différentes interactions de l homme sur l ordinateur et réciproquement. Le premier chapitre de cette partie a pour objectif de montrer comment cette collaboration est effectuée et a abouti aux différentes applications que nous connaissons aujourd hui. Le second chapitre aborde les systèmes multi-agents ou SMA 1 et présente comment chaque entité l agent participe dans un processus global. L interaction entre l agent et l environnement ainsi que le processus inverse produit l émergence d un système plus complexe. Dans cette partie, nous présentons succinctement quelques aspects de la réalité virtuelle et des systèmes multi-agents afin de mieux comprendre les points forts à retenir pour notre problématique. 1 en anglais, MAS pour MultiAgent System. 7

24 Introduction 8

25 Chapitre 1 La Réalité Virtuelle...Nous pouvons modeler votre vision pour lui fournir tout ce que votre imagination peut concevoir. Nous contrôlerons tout ce que vous allez voir et entendre. Nous partagerons les angoisses et les mystères qui gisent dans les plus profonds abysses... au-delà du réel. Au-delà du réel ( ), Leslie Stevens & Joseph Stephano 1.1 Introduction Bien que le terme virtuel ait pris, aujourd hui, un autre sens que celui d origine, il est souvent utilisé pour exprimer l existence d une chose uniquement dans sa réalisation informatique. La réalité virtuelle offre cette apparence en plaçant l utilisateur au centre du système. Trois points particuliers permettent de rendre cette immersion parfaite. Tout d abord, l utilisateur est immergé dans un monde graphique en trois dimensions. Ce monde peut simuler un monde réel ou imaginaire. Ensuite, l utilisateur se trouve dans l application et navigue généralement dans cet environnement via un avatar, un représentant informatique de luimême. Enfin, cet utilisateur peut examiner, interagir et manipuler les objets virtuels composant l environnement [Wilson et al. 01]. Le rendu graphique, le retour sensoriel et les moyens d interactions offerts à l utilisateur permettent une profonde osmose entre cet utilisateur et l ordinateur. La réalité virtuelle est un domaine pluridisciplinaire tirant parti de l informatique graphique, de la simulation, de la conception assistée par ordinateur, de la téléopération, ainsi que de beaucoup d autres lui permettant de remplir son rôle. 9

26 La Réalité Virtuelle 1.2 Définition Trouver une seule définition relève de la gageure. On peut cependant retenir la définition proposée par le groupe de travail du : Réalité Virtuelle : ensemble d outils logiciels et matériels permettant de simuler de manière réaliste une interaction avec des objets virtuels qui sont des modélisations informatiques d objets réels. On peut ajouter que la réalité virtuelle cherche à reproduire certaines caractéristiques de la réalité et de ce fait, elle doit être capable de tromper l utilisateur tout en lui laissant son autonomie d action Tromper l utilisateur Le terme anglais virtual reality introduit par Jaron Lanier en 1989 a soulevé de nombreuses interrogations sur les objectifs de cette nouvelle discipline. Maladroitement traduite en français par réalité virtuelle, cette antonymie ne reflète pas le message véhiculé dans ce terme anglais. En effet, virtuel signifie possible, potentiel alors que le terme anglais signifie pratiquement. Donc, cette réalité virtuelle se veut une quasi-réalité. Oui, dans un sens, puisque l on cherche à reproduire, de manière la plus fidèle, la réalité telle qu elle est perçue par l homme. Non, vous répondrai-je, car elle n est pas si réelle que ça. Nous ne cherchons pas, dans la réalité virtuelle, à être le plus réel possible mais plutôt à créer un réel fictif. C est-à-dire que nous mettons l homme en présence d un dispositif qui va provoquer son imagination. Le résultat de cette imagination sera peut-être, et nous le souhaitons, une impression de réalisme. Mais est-ce suffisant pour définir ce qu est la réalité virtuelle? Non, nous devons aller encore un peu plus loin. En effet, reproduire la sensation de réel est un des objectifs de cette discipline mais parfois nous souhaitons aller au delà. Pouvoir montrer des choses irréalisables dans la réalité est aussi un but de la réalité virtuelle. Ceci peut être la possibilité de voir une scène sous un angle spécifique. Par exemple, voir la vue aérienne d un accident afin qu un apprenant puisse juger de son erreur par rapport à des distances de sécurité, ou même pouvoir visualiser l intérieur d un robinet en rendant certaines pièces transparentes 2 [Mellet d Huart 01]. À la fois quasi-réalité et réalité fictive, la réalité virtuelle doit pouvoir tromper l utilisateur et lui permettre d aller au-delà du réel. 1 GTRV : Groupe de Travail Réalité Virtuelle 2 Simulateur d un projet d EDF 10

27 Définition Échange naturel entre l utilisateur et l ordinateur Pour permettre à l utilisateur de vivre au mieux cette expérience, les interactions bidirectionnelles entre l ordinateur et l utilisateur doivent se faire de la manière la plus naturelle possible. Cette cognition virtuelle, comme l appelle A. Grumbach [Grumbach 01], est une transformation des perceptions de l homme en un imaginaire, une représentation, qui va appeler une réponse de la part de l utilisateur. Il modélise l utilisateur et l environnement à travers trois éléments. L opérateur O est l utilisateur du système qui agit sur un monde M. Les échanges entre ces deux intervenants s effectuent à travers un dispositif matériel d interaction I. On peut voir ces échanges comme une boucle où l effecteur d un élément interagit avec le récepteur d un autre élément comme sur la figure 1.1. O I M traiteur effecteur recepteur Figure 1.1 : Traitement de l information selon [Grumbach 01] Cette dualité entre l opérateur et le monde exprime à la fois une volonté de rapprochement de recherche d une présence forte et un besoin d autonomie. Le système de réalité virtuelle doit prendre en compte ces deux caractéristiques Présence Ce qui distingue un outil de réalité virtuelle de toute autre application, c est réellement cette sensation d être dans le monde virtuel et d y agir. Pour le grand public, la réalité virtuelle n est vue que comme un moyen permettant une immersion partielle ou totale de l utilisateur en oubliant qu il ne s agit pas seulement de cela. Dans la description faite par Burdea et Coiffet [Burdea et al. 93], la réalité virtuelle n est pas seulement un outil d interaction et d immersion mais aussi un outil très dépendant de l imagination de l opérateur. Le triangle 11

28 La Réalité Virtuelle I 3 présenté à la figure 1.2, place la réalité virtuelle au centre des trois concepts : interaction : l utilisateur peut agir sur l environnement simulé pendant son déroulement, immersion : la représentation de l environnement est suffisamment réaliste afin que l utilisateur agisse dans le monde virtuel comme s il était réel, imagination : l utilisateur se représente le monde d une certaine manière et y agit en conséquence. IMMERSION I 3 INTERACTION IMAGINATION Figure 1.2 : Interaction, Immersion, Imagination [Burdea et al. 93] La réalité virtuelle n est pas seulement une science palpable comme la chimie ou la physique mais un mélange entre psychologie et outils d immersion Autonomie J. Tisseau [Tisseau 01] considère que la présence n est pas suffisante pour représenter un environnement virtuel. En considérant l évaluation faite par D. Zelter en 1992, un univers virtuel est évalué par l autonomie des objets, l interaction avec ces objets et la sensation de présence au sein du monde virtuel. On considère alors qu un objet a un comportement autonome s il est capable de s adapter aux modifications non connues de l environnement au sein duquel il évolue. Ceci implique que les objets doivent être dotés de moyens de perception, d action et de coordination entre la perception et l action. Ainsi, J. Tisseau propose le modèle décrit à la figure 1.3. Les trois médiations proposées sont : 1. médiation des sens : permet la perception du modèle par l observation de son activité, 2. médiation de l action : permet de mener des expérimentations sur le modèle, et ainsi de tester sa réactivité, 3. médiation de l esprit : l utilisateur se façonne une représentation mentale du modèle. Dans ce modèle, l utilisateur y joue un rôle actif. Cette participation permet d ouvrir la 12

29 Historique activité Perception Sens réactivité Expérimentation Action Modèle Esprit Représentation proactivité Figure 1.3 : Les trois médiations du modèle en réalité virtuelle [Tisseau 01] voie à une véritable expérimentation des modèles ainsi qu à une meilleure appréhension de leur complexité. 1.3 Historique Historiquement, la réalité virtuelle se trouve au carrefour de plusieurs disciplines. L informatique graphique y joue un rôle important car elle s est attachée à rendre de plus en plus réalistes les images qui se présentent à nous. Ainsi, l image est d abord apparue en deux dimensions (segments, courbes, polylignes,... ) puis les bureaux d études s approprièrent les techniques et les améliorèrent pour donner naissance à la Conception Assistée par Ordinateur (CAO). Ce mode de rendu s est développé dans l amélioration des formes via la modélisation surfacique et volumique. Ensuite, c est le rendu des textures et des ombres ainsi que les techniques d éclairage qui se sont améliorés à travers les techniques de lancer de rayons et de radiosité. Comme nous vivons dans un monde en perpétuel mouvement, cette immobilité des images nous trouble. C est donc, tout naturellement, que l étape suivante a été d apporter une dimension temporelle aux images. L animation des images s est faite par interpolation entre des images-clés puis à travers des animations réalistes des mouvements (cinématique inverse, acquisition du mouvement). Maintenant que le rendu animé est possible, l humain souhaite y participer. C est ainsi que l animation temps réel naît. Elle permet un rendu adapté aux interactions de l homme. Pour cela, il faut simplifier le nombre d éléments à rendre (faces hors du champ de la caméra, faces mal orientées, objets occultés,... ). Pour participer pleinement à l animation, l utilisateur doit alors se doter de moyens matériels lui offrant un retour multi-sensoriels et d interacteurs adaptés. Ces outils matériels ainsi que les aspects logiciels offrant le rendu visuel et le comportement autonome des entités sont présentés dans la section suivante. 13

30 La Réalité Virtuelle 1.4 Les outils Les outils de la réalité virtuelle sont les dispositifs d interaction permettant à l utilisateur de dialoguer avec le monde et vice versa. Ces dispositifs sont le matériel d interaction présenté à la figure 1.1 et, l ordinateur qui simule le monde. Nous avons donc une partie matérielle qui offre l interaction physique avec l utilisateur et une partie logicielle qui offre le rendu multisensoriel. C est-à-dire, l application qui simule le monde La partie matérielle Nous ne parlerons pas de l ordinateur chargé d exécuter l application gérant le monde car nous sortons du cadre du sujet de cette thèse. Par contre, il est nécessaire d approfondir un peu les aspects matériels pour bien cerner la problématique qui gravite autour de cette discipline. Généralement, quand les médias montrent des images du domaine de la réalité virtuelle, le public perçoit cette dernière comme un environnement dans lequel l opérateur est immergé à l aide d un casque stéréoscopique et d un gant de données. Peut-être est-ce le rêve de nombre d entre nous de s évader en dehors de la réalité quotidienne en toute légalité à l opposé des drogues et de percevoir un nouvel environnement moins hostile mais cette image réductrice affiche les deux catégories de matériels nécessaires à un meilleur contact entre l humain et l ordinateur. Il s agit du I de Interactivité de I 3 (figure 1.2). Le casque stéréoscopique symbolise les effecteurs d interaction qui permettent à l ordinateur de communiquer, voire communier, avec l homme et réciproquement. Le gant de données, quant à lui, symbolise les récepteurs d interaction qui permettent un retour sensoriel vers l ordinateur. On peut voir ces effecteurs et récepteurs comme des Interfaces Homme Machine (IHM) 3 immersives. Ces effecteurs et récepteurs concernent la partie gauche du dispositif d interaction de la figure 1.1. Les effecteurs et récepteurs de la partie droite du dispositif d interaction représentent les ports de communication de l ordinateur Les effecteurs d interaction Les effecteurs d interaction représentent une sortie du dispositif d interaction qui vient en entrée des récepteurs de l opérateur. Leur finalité est de s adresser aux canaux sensoriels de l homme (odorat, goût, vision, ouïe, toucher et sens kinesthésique) pour le détourner du réel et lui faire percevoir une autre réalité. La vue représente 90 % de notre activité cérébrale et est l élément principal de notre cognition. Ceci explique certainement pourquoi la recherche sur la visualisation est prépondérante. Malgré tout, trois sens sont mis en avant, la vue, le toucher 3 En Anglais HCI pour Human Computer Interface. 14

31 Les outils et l ouïe. Les recherches menées sur l odorat et le goût sont à l heure actuelle encore difficiles à simuler et ne représentent pas autant d intérêts que les autres sens [Fuchs et al. 01]. La visualisation La visualisation procure une largeur de bande très vaste pour le traitement des informations. C est-à-dire qu elle permet une acquisition d une grande quantité d informations sans effort. C est pourquoi, le seul effecteur disponible dans tous les ordinateurs est l écran d affichage. Les quatre principaux équipements permettant de reproduire des images sont l écran, le casque immersif appelé aussi casque stéréoscopique, les lunettes stéréoscopiques et les salles immersives. L écran d affichage est un outil classique et n est pas spécifique à la réalité virtuelle. Les trois autres équipements, visiocasques, lunettes polarisantes et salles immersives, apportent une immersion plus prononcée de l opérateur en lui permettant une reconstitution stéréoscopique des images générées par l ordinateur. Le casque de réalité virtuelle permet de produire une image distincte pour chaque œil en plaçant un écran d affichage (LCD 4 ou CRT 5 ) devant chaque œil. L ordinateur doit donc générer simultanément deux images. Associée à un capteur de position, l immersion est profonde car le mouvement du corps modifie l image perçue par l utilisateur. De plus, les cartes graphiques sont maintenant dotées de deux sorties vidéos distinctes et permettent donc de réaliser facilement ces deux images. Les lunettes de stéréovision sont des afficheurs à cristaux liquides à polarisation opposée pour chaque œil. Pendant ce temps, l ordinateur génère alternativement l image pour l œil gauche puis l image pour l œil droit et les affichent sur le même écran. Cette alternance d affichage fait que l œil gauche ne perçoit que l image qui lui est destinée et il en est de même pour l œil droit. Enfin, la salle immersive est une salle dans laquelle les images de l environnement virtuel sont projetées sur les quatre murs. Cet équipement procure l avantage de pouvoir placer plusieurs utilisateurs simultanément dans des conditions immersives. Le toucher et le sens kinesthésique Les systèmes à retour d effort et/ou à retour tactile sont les deux types d équipements les plus utilisés pour ces sens. Il existe de nombreux modèles 6 afin de s adapter à chaque type d application. Le retour tactile est généralement réalisé par un gant de données (dataglove) et donne des indications sur l objet manipulé. Il s agit d un gant disposant d actionneurs qui sont pilotés suivant l action de l utilisateur. Les actionneurs peuvent être des micro-ballons ou des 4 LCD : Liquid Crystal Display, afficheur à cristaux liquides 5 CRT : Cathod Ray Tube, tube à électron 6 Par exemple, le de la société Sensable existe en cinq modèles suivant le besoin associé (volume couvert, nombre de degrés de liberté, précision,... ). 15

32 La Réalité Virtuelle micro-tiges qui effectuent une pression sur les doigts, un retour vibro-tactile,... L objectif est de ressentir les objets en contact avec la main. Cette information est nécessaire si l utilisateur veut savoir s il a bien saisi un objet virtuel. Suivant le système, il peut également ressentir la rugosité de la surface en contact, la température ou le glissement d un objet. Le retour d effort s oppose à un mouvement de l utilisateur. C est-à-dire qu il peut empêcher voire déplacer le bras dans une direction opposée à celle désirée. Les systèmes à retour d effort sont soit à réaction externe le dispositif est déporté, soit à réaction interne le dispositif est porté. Dans le premier cas, l utilisateur ne supporte pas le poids du mécanisme mais dispose d une faible autonomie alors que le second offre l inverse. Par contre, si des efforts très importants doivent être générés, le premier est plus approprié. L ouïe L ouïe participe pleinement dans notre vie quotidienne car elle permet de replacer les objets lorsqu il se trouve hors du champ de notre vue. La stéréophonie est un moyen très simple de replacer les objets à gauche ou à droite de notre position mais dans un environnement virtuel, une représentation spatiale du son c est-à-dire dans toutes les directions est nécessaire. On peut reproduire un son situé n importe où dans l espace en prenant en compte les modifications spectrales dues à la fonction de transfert de la tête de l utilisateur (HRTF 7 en anglais) Par exemple, OpenAL 8@ est une librairie offrant la possibilité de générer un son spatial en tenant compte de la directivité du son, de l atténuation due à la distance, de l effet Doppler et des différentes influences de l environnement (réflexion, obstruction, transmission et réverbération) Les récepteurs d interaction Après avoir perçu l environnement virtuel, l opérateur s en fait une représentation personnelle et, à partir de sa connaissance, va agir sur cet environnement. Les récepteurs d interaction vont lui permettre de dialoguer avec l ordinateur en essayant de lui procurer une interaction la plus naturelle possible. Ce dialogue, généralement effectué via la main par l intermédiaire du clavier et de la souris, doit être enrichi pour permettre une interaction en trois dimensions et permettre à d autres parties du corps d interagir. Nous distinguons trois types d équipements, les capteurs, la reconnaissance vocale et les interacteurs, pour agir dans l environnement. Les capteurs permettent de détecter les mouvements du corps et d adapter le déplacement de l avatar en conséquence. La reconnaissance vocale permet d effectuer des actions tout en laissant les mains libres pour 7 HRTF : Head-Related Transfer Function 8 OpenAL : Open Audio Library 16

33 Les outils d autres tâches. Enfin, les interacteurs sont manipulés par la main et permettent d effectuer des interactions souvent moins naturelles mais plus spécifiques. Les capteurs Magnétiques, à ultrasons ou optiques, les capteurs permettent de détecter les mouvements du corps et autorisent une interaction très naturelle comme la saisie d un objet à l aide d un gant de données. Les différences entre les différents types de capteurs se caractérisent par leur sensibilité plus ou moins grande (différence entre deux positions), leur champ d action (distances maximales) et leur environnement (présence de structure métallique). Ils permettent de détecter leur position suivant les trois axes (x, y et z) et les trois angles (tangage, roulis et lacet). Ils peuvent être montés sur un casque stéréoscopique. Dans ce cas, le mouvement de la tête est détecté et l image représentée est modifiée en conséquence. La main peut être dotée d un gant de données qui permet de connaître sa position ainsi que la forme de la main (ouverte, fermée,... ). L utilisateur peut alors saisir des objets. La reconnaissance vocale Les récents progrès dans la reconnaissance vocale permettent d intégrer cette technologie au sein de la réalité virtuelle. En effet, la main est l organe le plus sollicité pour les interactions avec l environnement. Pouvoir dicter d autres actions avec la voix offre de nouvelles possibilités. Les interacteurs Il existe toute une pléthore d équipements permettant de tirer profit des trois dimensions de la réalité virtuelle. La souris 3D ou trackball permet de rajouter la dimension manquante aux souris classiques et ainsi de profiter des 6 degrés de liberté. D autres périphériques offrent des outils adaptés aux besoins plus spécifiques de certaines applications de réalité virtuelle. Par exemple, le est un périphérique à retour d effort à six degrés de liberté se présentant comme un stylo et permettant de toucher voire de modeler des objets 3D. Il offre également un retour d effort permettant de ressentir la rugosité de la surface en interaction La partie logicielle La partie logicielle représente la simulation de l environnement virtuel. Il s agit de reproduire tous les éléments immersifs (image, son, retour d effort,... ) de manière la plus réaliste possible. Deux parties distinctes permettent de réaliser cet objectif : le rendu visuel et le 17

34 La Réalité Virtuelle comportement des modèles Le rendu visuel Le rendu visuel consiste à définir de la manière la plus précise possible, la position des objets, leur forme, leur couleur, etc. L image de synthèse offre des avancées sans pareille dans le domaine de la modélisation. Ainsi, il est possible de définir des objets aux formes complexes tout en leur associant des textures transparentes, réfléchissant la lumière et d autres artifices du même acabit. En réalité virtuelle, le temps de calcul est un point délicat mais il faut que le rendu soit le plus réaliste possible afin que l utilisateur ait l impression d évoluer dans un environnement réel. Pour permettre de modéliser une scène 3D, différents langages ont été développés. Aujourd hui, VRML 9@ et ses successeurs, VRML97 et X3D 10@, offrent un puissant langage portable permettant de modéliser une scène 3D Le comportement Disposer d une scène en trois dimensions et permettre à l utilisateur de naviguer au sein de cet environnement offre un certain degré d immersion. Cependant, l immobilité de la scène trouble sa perception. Il devient alors nécessaire d animer le monde à l aide d entités et de leur donner vie. Ce comportement peut être purement réactif et résulte d une action de l utilisateur ou de ses conséquences. Mais ce comportement peut aussi être beaucoup plus complexe afin de le rendre très réaliste. La surveillance d un troupeau de moutons par un berger et son chien est le résultat d un ensemble de comportements individuels [Parenthoën et al. 01]. L intelligence artificielle y joue un rôle important dans cette réalisation. Les cartes cognitives floues [Kosko 86], les réseaux de neurones [Rumelhart et al. 86] ainsi que d autres outils permettent de réaliser ces comportements. 1.5 Les applications Cet interfaçage, entre l opérateur et l ordinateur, proposée par la réalité virtuelle en fait un outil de qualité pour de nombreux domaines (militaire, loisirs, médecine,... ). Les utilisations possibles sont étendues par les progrès permanents dans les domaines du rendu graphique, des réseaux informatiques et de l évolution de la puissance de calcul des ordinateurs. Les applications se justifient souvent par l économie qu elles engrangent (argent, temps, prototypes,... ) ou par les nouvelles possibilités offertes en devenant indispensables 9 VRML : Virtual Reality Modeling Language 10 X3D : extensible 3D 18

35 Les applications (visualisation de données) La simulation militaire L évolution des technologies a provoqué un besoin plus important en formation dans les équipements militaires. De plus, les restrictions budgétaires, l écologie et d autres facteurs ont fait que l armée s est orientée vers les simulateurs pour former ses troupes. Ce besoin a débuté en 1929 avec le First Link Trailer [U.S. Congress 94] qui était le premier simulateur de combat aérien. Depuis, l armée américaine (DoD) a déployé d énormes moyens pour améliorer la technologie. Ces développements ont évolué vers la simulation répartie dont les technologies SIMNET 11, DIS, ALSP et HLA en sont les représentants. Les deux principales évolutions des simulations militaires représentées par DIS et HLA seront étudiées au chapitre 1 de la partie III Les jeux Le premier a avoir été rendu célèbre par l utilisation de la 3D au sein d un monde virtuel est certainement Wolfenstein sorti en Aujourd hui, il a ouvert la porte à un véritable marché représenté par Doom, Quake et tous les descendants de ces jeux. Armé d un joystick, cette immersion graphique plonge l utilisateur dans un monde de débauche où les ennemis sont des entités virtuelles dotées d un comportement devenant de nos jours très évolué La formation La réalité virtuelle pour la formation est aujourd hui un marché en pleine croissance et dispose même d un sigle : VET 12. De nombreux domaines peuvent être représentés par ce type d application : la formation militaire (SIMNET, NPSNET), la formation au pilotage d avions ou de véhicules (découpe de bois, ARVESTER 13 ), la formation à la sécurité civile, la formation médicale et bien d autres encore. La figure 1.4 présente SécuRévi [Querrec 02], un outil de simulation pour la formation des sapeurs-pompiers. Il a été développé au sein du laboratoire du LI 2 et offre à l apprenant une immersion au sein d un site à risque de type Seveso. L apprenant peut acquérir les procédures d intervention permettant de combattre un incendie. Ce type de manœuvre ne peut, malheureusement, être testé qu une seule fois par an sur le site réel. 11 SIMNET : SIMulator NETwork 12 VET : Virtual Environment for Training 13 ARVESTER : Abattage Reconstitué Virtuellement En Synthèse TEmps Réel 19

36 La Réalité Virtuelle Le prototypage Figure 1.4 : SécuRévi [Querrec 02] L étude et la conception de nouveaux produits passe pratiquement systématiquement par un outil de prototypage (maquette numérique, CAO 14 ). Cette étape offre l avantage de réduire les temps de développement et permet de valider partiellement la viabilité d un nouveau produit. Aujourd hui, la gestion du cycle de vie d un produit ou PLM 15 tend à se réduire. Les nouveaux outils offrent maintenant la possibilité de réaliser un prototype numérique permettant de s abstraire de la réalisation d un prototype réel. 1.6 Conclusion La réalité virtuelle est l application informatique actuellement la plus complète dans le sens où elle se propose d intégrer l utilisateur au centre de l application. Acteur et non spectateur, l opérateur est le sujet et l objectif de l application. C est-à-dire que tout ce qui peut être mis en œuvre, doit l être avec l intention que l utilisateur se sente encore plus à l aise, avec l intention qu il ait encore plus l impression d évoluer dans un environnement réel. 14 CAO : Conception Assistée par Ordinateur 15 PLM : Product Lifecycle Management 20

37 Chapitre 2 Les Systèmes Multi-Agents Objects do it for free; agents do it for money. Michael Wooldridge [Wooldridge 99] 2.1 Introduction Modéliser analytiquement des systèmes complexes devient de plus en plus difficile de par le nombre de paramètres à maîtriser et de par le temps de calcul nécessaire voire l explosion combinatoire. Les systèmes multi-agents proposent de décomposer un système complexe en éléments simples interagissant les uns avec les autres. La dynamique du système, c est-àdire le comportement global du système pendant son fonctionnement, correspond à l objectif final. Cette méthode de conception a donné de très bons résultats en robotique distribuée [Overgaard et al. 94]. D autres domaines tels que l éthologie et la cytologie emploient les systèmes multi-agents dans le but d étudier le comportement des espèces [Drogoul et al. 95] ou l évolution des cellules. Après un bref rappel historique, nous présentons brièvement quelles sont les applications cibles des systèmes multi-agents. Nous présentons ensuite le modèle Vowels de Demazeau [Demazeau 95] qui nous permet d aborder les quatre concepts clés de l approche multi-agents : Agent, Environnement, Interaction et Organisation. Puis, nous expliquons quels sont les aspects intelligents d un agent. Dans la dernière partie, nous présentons quelques applications réalisées à l aide des systèmes multi-agents. 21

38 Les Systèmes Multi-Agents 2.2 Les systèmes multi-agents Les systèmes multi-agents trouvent leurs origines dans l intelligence artificielle et la vie artificielle. Mais à la différence de celles-ci, les systèmes multi-agents ne sont pas dotés d un contrôle central. Leur intelligence est le résultat de l ensemble des interactions entre les agents. Cette discipline trouve des domaines d application divers tels que la gestion du trafic aérien, la réalisation de tâches complexes comme le pilotage d un robot ou encore la recherche sur Internet en délégant ce travail de recherche à un agent. Nous présentons les systèmes multi-agents en se servant du modèle Vowels conçu par Demazeau Historique À l intersection de nombreuses disciplines, les systèmes multi-agents sont surtout le résultat de deux disciplines que sont l intelligence artificielle distribuée (IAD) 1 et la vie artificielle (VA) [Dupont et al. 02]. L intelligence artificielle distribuée étudie la résolution de problèmes complexes en organisant des systèmes divisés en éléments simples. La vie artificielle cherche à comprendre les systèmes doués de vie (éthologie, cytologie,... ) et à les modéliser dans le but de reproduire le comportement naturel des organismes doués de vie. L approche multi-agents a débuté à la fin des années 70. Les tableaux noirs (blackboards) [Nii 86] furent les premiers types de systèmes implémentés. Il s agit d une zone de travail commune où des objets peuvent être déposés, modifiés ou retirés. Ces modifications sont réalisées par des spécialistes, les Knowledge Sources (KS), et un dispositif de contrôle gère les conflits d accès. Un peu plus tard, les travaux de C. Hewitt mirent en évidence la notion d envoi de message comme concept fondamental des agents ainsi que les notions de représentation [Hewitt 77]. L influence de la vie artificielle apparaît à la fin des années 80 avec comme promoteur C. Langton [Langton 89]. Pour lui, il s agit d abstraire les principes sous-jacents à l organisation du vivant et de les implémenter dans un ordinateur afin de pouvoir les étudier et les tester Les objectifs La complexité croissante des systèmes nécessite de plus en plus à décomposer le problème en petits éléments en interaction et non suivant une approche systémique. Plusieurs raisons, selon J. Ferber, concourent à cette division [Ferber 95] : 1 DAI : Distributed Artificial Intelligence 22

39 Les systèmes multi-agents 1. Les problèmes sont physiquement distribués (e.g. trafic aérien), 2. Les problèmes sont fonctionnellement très distribués et hétérogènes (e.g. conception d une Formule 1), 3. Les réseaux imposent une vision distribuée, 4. La complexité des problèmes impose une vision locale, 5. Les systèmes doivent pouvoir s adapter aux modifications (évolutivité). Cette évolution des problèmes impose une évolution des modèles et ce développement est rendu possible par l accroissement des capacités informatiques tant au niveau de la puissance des machines que des communications distantes entre ordinateurs. Les modèles classiques à base d équations différentielles, de matrices de transition et autres posent des problèmes quant à leur élaboration. En effet, la difficulté à modéliser différents niveaux d interactions (macro/microscopique), l estimation et le nombre de paramètres à prendre en compte, la difficulté à modéliser l action (individualité des actions) et l impossibilité de prendre en compte des paramètres qualitatifs limitent fortement l enrichissement de ces modèles. À l inverse, les SMA se prêtent bien à cette complexification en traitant les interactions individuelles, la kénétique comme l appelle J. Ferber [Ferber 95], au cœur du modèle Les fonctionnalités des SMA Le modèle multi-agents s organise autour de différents concepts. Demazeau définit un système multi-agents comme étant composé de quatre concepts clés que sont les Agents, l Environnement, les Interactions et l Organisation. C est l approche Vowels ou AEIO [Demazeau 95] Agent Un agent est une entité qui se retrouve au sein d un environnement avec lequel il interagit. L agent est l élément de base d un système multi-agents. Il est doté d une certaine autonomie lui permettant de créer et de supprimer des interactions. Il peut être intelligent et, dans ce cas, effectue un raisonnement sur ce qu il a perçu de son environnement afin de réaliser une action cohérente et adaptée. Enfin, il peut avoir un comportement social qui lui permette de dialoguer avec d autres agents à l aide d actes de langage. Autonomie Comme l explique J. Ferber [Ferber 97], la différence essentielle entre un objet et un agent est l autonomie de décision, et donc d exécution, introduite par un ensemble d objectifs que l agent doit réaliser. Ceci est illustré à la figure

40 Les Systèmes Multi-Agents Methodes Objectifs Requete Reponse Services Acte de langage Acte de langage Objet Agent Figure 2.1 : Différence entre objet et agent [Ferber 97] Ainsi, l agent, libre de choisir ses actions, doit être capable de résoudre les conflits entre ses propres intérêts, les intérêts des autres agents et son environnement actuel. L objectif est alors de choisir le meilleur cheminement permettant de résoudre la problématique suivant des critères prépondérants. Plusieurs types de motivations entrent en jeu : les motivations personnelles, tendent à satisfaire les besoins et objectifs internes de l agent, les motivations environnementales, sont apportées à l agent par sa perception, les motivations sociales, organisent les agents suivant la conception du système. Intelligence L intelligence d un agent va être caractérisée par la partie décision du cycle de fonctionnement de l agent. Ainsi, un agent peut avoir un comportement purement réactif ou, au contraire, baser son action sur un historique des actions antérieures, une modélisation particulière du monde et d autres objectifs. L agent est alors capable de produire deux actions différentes sur une même perception. Son état interne fait la différence. Sociabilité La partie droite de la figure 2.2 décrit la capacité d un agent à produire des interactions de haut niveau avec les autres agents. Cette conversation, par actes de langage, entre agents cognitifs permet d effectuer des requêtes, d y répondre et d évoluer socialement. Des langages spécifiques appelés ACL 2 tels que KQML 3 et ont été développés à cette fin. 2 ACL : Agent Communication Language 3 KQML : Knowledge Query and Manipulation Language 4 FIPA : Foundation for Intelligent Physical Agents 24

41 Les systèmes multi-agents Environnement Figure 2.2 : Caractéristiques d un agent autonome [Richard 01] Selon O. Boissier 5, l environnement peut être divisé en deux parties, l environnement du système multi-agents et l environnement de l agent. Le premier est le support des actions des agents. Le second, contient à la fois l environnement du système multi-agents et les autres agents de l environnement. Par extension, c est l ensemble des conditions extérieures susceptibles d agir sur le fonctionnement de l agent. L environnement opère une interaction avec l agent à travers un processus de stimuli/réponses. C est-à-dire qu un cycle perpétuel va se créer entre l agent et l environnement dans lequel l agent va effectuer trois actions : perception : ses capteurs lui fournissent une vision (parmi d autres) de l environnement local, décision : suivant ses intentions, son état interne et sa perception, l agent choisit une action à effectuer, action : il modifie l environnement par son action. Ceci est illustré par la partie gauche de la figure Interaction Cet environnement est peuplé d autres agents qui, eux aussi, vont interagir. Nous avons donc des interactions agent-agent et agent-environnement. N. Richard [Richard 01] sépare ces deux formes d interaction (figure 2.2) et justifie cette séparation en rappelant que, selon Ferber, la communication entre agents (agent-agent) a pour but de modifier l état mental d un autre agent et de provoquer un comportement spécifique. Le second type d interaction (agent-environnement), par contre, ne provoque qu une modification de l environnement. Bien sûr, cette modification peut, indirectement, modifier la perception et donc l état interne des autres agents. La notion d interaction correspond donc à la mise en relation de deux ou plusieurs 5 Cours sur les systèmes multi-agents : boissier/enseignement/sma/ 25

42 Les Systèmes Multi-Agents agents à travers une série d actions. Ces actions peuvent être directes ou indirectes. C està-dire que l interaction peut se produire soit directement entre deux agents, soit par l intermédiaire d un autre agent ou de l environnement. C est cette dynamique des interactions entre composants qui permet l émergence de nouvelles fonctionnalités plus complexes. Pour qu il y ait interaction, il faut disposer d agents capables d agir et/ou de communiquer. Cette interaction ne deviendra effective qu à partir du moment où une situation d interaction se présente. Elle peut se traduire à travers une collaboration entre agents, le besoin de partager des ressources, une collision entre agents et autres. Enfin, l agent doit être capable de créer et de rompre l interaction à tout moment. Il doit disposer d une certaine autonomie Organisation Pour satisfaire leurs objectifs, les agents vont se comporter de manière à former un regroupement. Ce regroupement sera réalisé en tenant compte des contraintes provenant des ressources plus ou moins limitées mais aussi de leurs compétences individuelles. Pour cela, trois critères sont à prendre en compte : les objectifs ou intentions des agents, les relations qu ils entretiennent vis à vis des ressources et les compétences dont ils disposent. L interaction est le composant de base de toute organisation. L organisation est l agencement qui se produit entre les agents pour former un système. Les agents vont créer un réseau d interaction qui va former un tout qui sera capable de résister dans une certaine mesure à des perturbations du système. Elle est nécessairement dynamique. Deux parties sont à distinguer : la structure organisationnelle et l entité organisationnelle. La structure organisationnelle définit l ensemble des classes d agents (les rôles) intervenant dans l organisation ainsi que l ensemble des relations abstraites qui existent entre ces classes d agents. L entité organisationnelle représente l instanciation de la structure. Elle peut alors répartir un rôle entre plusieurs agents et, dans ce cas, une relation entre deux rôles correspondra aux interactions entre les agents appartenant aux deux rôles en relation. La figure 2.3 illustre ces propos. La structure organisationnelle O est définie par trois rôles A, B et C. Des liens existent entre ces rôles (g, h,... ). Les organisations concrètes O1 et O2 créées à partir de cette structure reproduisent ces rôles à travers plusieurs entités (rôle de A par A1 et A2). Les liens entre rôles deviennent alors le résultat des interactions produites par les différentes entités. Ainsi, le lien g est le résultat de g1 et g Agent intelligent Un agent intelligent, selon M. Wooldridge, est un agent capable d agir de manière autonome et flexible [Wooldridge 99]. Ces deux points doivent lui permettre d atteindre ses objectifs. 26

43 Agent intelligent Légende Entité abstraite Entité concrète A u g f h v C Structure organisationnelle B O u1 A2 g1 f1 h1 C1 v1 v3 v2 v4 C3 u1 A1 g1 g2 f1 h1 h2 C1 v1 v2 A1 g2 B1 h2 C2 O1 B2 C2 O2 Organisations concrètes Figure 2.3 : Organisations et structures organisationnelles (d après [Ferber 95]) Cette flexibilité se traduit en trois points : réactivité : il doit être capable de percevoir son environnement et d y agir afin d effectuer des changements allant dans le même sens que ses objectifs, pro-activité : il est capable de prendre des initiatives en ayant un comportement qui satisfait ses objectifs, capacité sociale : il peut interagir avec d autres agents (et des humains) pour satisfaire ses objectifs. L agent doit donc être capable de poursuivre ses objectifs tout en sachant profiter des situations. Un agent intelligent est, selon P. Maes, décomposé en deux parties : un mécanisme de sélection de l action et un mécanisme d apprentissage par l expérience [Maes 95]. En l absence de tout raisonnement, un agent ne sait que réagir à des stimuli extérieurs de manière réactive Agents purement réactifs Les agents purement réactifs n ont aucune mémoire. Leurs décisions ne proviennent que du présent, c est-à-dire ce qu ils constatent. Leur comportement est donc basé sur deux états que sont la perception et l action. Il observe son environnement et agit en conséquence. Tel que présentée à la figure 2.4, l architecture d un agent purement réactif ne dispose que du système de perception et d action. Il perçoit des stimuli qu il transforme en percepts. Ces percepts donnent alors lieu à des actions à travers son système d action. Si pendant sa vie, un agent reçoit deux fois les mêmes percepts, il ne sera pas capable de faire la différence du fait de la non mémorisation de son historique. 27

44 Les Systèmes Multi-Agents Modélisation du monde stimuli Système de perception Planification Système d action actions Niveau réactif Figure 2.4 : Architecture typique d un agent hybride (d après [Richard 01]) Agents cognitifs Un agent intelligent a la capacité de maintenir un historique de ses actions. Ses actions futures peuvent donc être influencées par son passé. Il maintient une structure interne lui permettant de raisonner sur son état, ses percepts et ainsi effectuer une action adaptée. L architecture de l agent hybride présentée à la figure 2.4 donne lieu à un agent à la fois cognitif et réactif. Il peut planifier ses actions en fonction de buts à atteindre. Trois classes d agents peuvent être distingués : les agents basés sur la logique (les décisions sont prises par déduction logique), les BDI 6 (la décision dépend de structures représentant les croyances, les désirs et les intentions) et les architectures en couches (chaque couche a un niveau de raisonnement plus ou moins abstrait pouvant inhiber d autres couches). 2.4 Les domaines d application Ferber [Ferber 97] considère deux grandes catégories d applications des systèmes multiagents : la résolution de problèmes et la simulation multi-agents La résolution de problèmes Les systèmes multi-agents peuvent servir à la résolution distribuée de problèmes. Il s agit de doter chaque agent de compétences propres à un domaine particulier. La résolution du problème provient de la coopération entre les agents à différents instants dans le but d apporter leur expertise et ainsi améliorer la mise en œuvre d une solution. Il peut s agir de 6 BDI : Believe, Desire, Intention ou croyance, désir et intention. 28

45 Conclusion problèmes distribués dont la résolution peut être distribuée. Dans ce cas, la vision du système est totalement décentralisée. La surveillance d un réseau informatique est un exemple de résolution distribuée. Les systèmes multi-agents peuvent aussi être utilisés pour résoudre des problèmes tels que l affectation de tâches pour des machines-outils, la définition d emploi du temps, le traitement d images [Guillaud et al. 02], La simulation multi-agents La simulation multi-agents a pour objectif de reproduire des modèles de la réalité et de les valider par l expérience. Il s agit d exprimer un problème complexe défini par des équations différentielles, des transformations de matrices sous la forme d un système multiagents en interaction. L étude de la coagulation du sang [Nicolas et al. 01] ou de l apoptose [Ballet et al. 98] en sont des exemples d utilisation en biologie. Les mondes synthétiques Les systèmes multi-agents peuvent rendre le comportement des entités plus réaliste. Doté d un système de perception, décision, action, l entité peut effectuer des actions intelligemment choisies et ainsi peupler l environnement. De nombreuses applications de la réalité virtuelle font usage de ces systèmes. Les agents du modèle MASCARET 7 [Querrec 02] se voient affecter des rôles avec des objectifs à réaliser. Ils définissent des plans d actions leur permettant de collaborer et d atteindre leur objectif (arroser une citerne de gaz, par exemple). 2.5 Conclusion Un agent est une entité autonome pouvant agir sur, et réagir à, son environnement. Cette immersion de l agent au sein de l environnement d interaction offre une plus grande liberté 8. Libéré dans l environnement, son comportement doit rester logique. Il est réactif s il ne sait que répondre à des stimuli ou, intelligent s il est capable, comme l homme, d effectuer un raisonnement basé sur son passé, ses percepts, ses croyances, etc. Peuplé d agents, le système multi-agents offre un outil permettant de réaliser des systèmes complexes à partir de composantes simples. 7 Multi-Agent System for Collaborative and Adaptive Realistic Environment for Training 8 Ce qui le différencie d autres outils de l Intelligence Artificielle. Les réseaux de neurones, par exemple, n ont aucun contact avec l environnement. C est l utilisateur qui fournit des faits et reçoit en retour une proposition qu il peut accepter ou non. 29

46 Les Systèmes Multi-Agents 30

47 Conclusion La réalité virtuelle offre, à l utilisateur, une interface qui lui permet de tirer parti au mieux de l interaction entre lui et les modèles qui peuplent l environnement. L application doit permettre à l utilisateur de profiter de toute son autonomie d action et lui permettre de modifier l environnement à sa guise. Cette dynamicité applicative peut être mise en œuvre à l aide d un système multiagents. En effet, l autonomie de décision et d action d un agent lui permettent de s adapter à la situation au fur et à mesure de son évolution. De plus, sa facilité de mise en œuvre rend possible la modélisation de systèmes relativement complexes en temps réel. Ce qui est nécessaire si nous voulons que l utilisateur soit immergé dans son modèle. Pour cela, J. Tisseau a révisé le modèle Vowels de Y. Demazeau en lui apportant la dernière voyelle qui manque. La lettre U représente alors l Utilisateur [Tisseau 01]. La simulation multi-agents devient alors participative. L avatar devient un agent dont le raisonnement est délégué à l utilisateur. Ainsi, à tout moment, l utilisateur peut se substituer à l agent et prendre le contrôle de son module de décision. Dans un outil de prototypage interactif et collaboratif, cette autonomie de modification du modèle doit rester présente afin que l utilisateur profite pleinement de la phase de conception. 31

48 Conclusion 32

49 Partie II État de l art l architecture de communication 33

50 État de l art l architecture de communication 34

51 Introduction The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point. Claude Shannon, 1948, Théorie de l information Dans la partie précédente, nous avons présenté les deux domaines qui cadrent notre contexte de travail, c est-à-dire, la réalité virtuelle et les systèmes multi-agents. Les applications en réseau font l objet ici d une réflexion plus approfondie. Notre problématique concerne essentiellement l échange d informations dans le but de préserver au mieux la cohérence de l application et d atteindre le but recherché, c est-à-dire une application de prototypage interactive et dynamique. Dans cette partie, nous abordons les différents aspects des applications distribuées. L approche prise est la même que H. Guyennet a choisi pour décrire son système CALIF [Guyennet 97]. Il avait défini quatre niveaux, chacun représentant un niveau d abstraction successif. Cette approche est aussi très similaire à la description faite pour les réseaux à travers le modèle OSI. Nous avons donc divisé notre étude en quatre chapitres répartis sur deux parties qui doivent refléter trois niveaux distincts (en tout cas, nous l aborderons comme cela). Le premier chapitre présente les différentes techniques et différents mécanismes permettant de partager des informations. Tout d abord, nous présentons les différents aspects des réseaux dans leur globalité, les différences existantes entre les différents réseaux disponibles ainsi que les algorithmes permettant d optimiser les temps de communication et de synchronisation. Le second chapitre s attache à montrer l intérêt d abstraire les couches de communication de bas niveau. L évolution effectuée depuis quelques années montre que cette abstraction est de plus en plus nécessaire du fait de l augmentation de la complexité des applications. 35

52 Introduction La programmation au niveau des pilotes de cartes réseaux a évolué vers la programmation par les sockets. Cette première évolution a rendu les applications plus indépendantes des évolutions des noyaux des systèmes d exploitation. De plus, cela a amélioré la portabilité des applications. Encore insuffisant, Sun a développé les appels de procédures à distance ou RPC 1, ce qui a ouvert des possibilités beaucoup plus grandes. En effet, grâce à l utilisation d un protocole appelé XDR 2, l utilisateur se libérait du codage des données pour les échanger entre des machines aussi hétérogènes que Sun Sparc, IBM PC, Silicon Graphics Irix, Apple Mac et autres. Enfin, CORBA 3 a apporté tout un panel de services (service de nommage, de sécurité,... ) ainsi qu une transparence totale sur la localisation des autres objets participants à l application. Nous conclurons ce second chapitre par une synthèse des différentes technologies passées en revue afin de déterminer quels critères nous semblent importants dans le cadre du prototypage interactif et collaboratif. 1 RPC : Remote Procedure Call 2 XDR : external Data Representation 3 CORBA : Common Object Request Broker Architecture 36

53 Chapitre 1 Les réseaux : support de la communication Il ne faut pas sous-estimer la capacité de transport d un véhicule rempli de bandes magnétiques A. Tanenbaum [Tanenbaum 96] 1.1 Introduction Apparues au début du XXème siècle, les télécommunications s imposent dans les domaines industriels et publics mais son introduction dans celui de l informatique ne se produit qu à partir des années 70. Depuis l arrivée du protocole IP [Cerf et al. 74], une pléthore d autres protocoles sont apparus. Il en est de même pour les réseaux physiques. L épaisseur des livres d introduction sur les réseaux informatiques 1 souligne la diversité des réseaux physiques et des protocoles associés. Cette diversité des réseaux (ATM, Ethernet, X.25,... ) et des protocoles associés (IP, TCP, AAL,... ) rendent difficile la mise en œuvre d applications spécifiques comme celle que nous souhaitons développer. Le présent chapitre a pour objectif d analyser les différentes couches 2 disponibles dans les réseaux actuels et de mettre en avant les points particuliers qui offrent des caractéristiques adaptées à la problématique qui nous concerne. 1 Les plus connus en France sont ceux de A. Tanenbaum [Tanenbaum 96] et de G. Pujolle [Pujolle 95]. 2 Les réseaux sont toujours présentés sous forme de couches depuis que IBM a décrit son modèle SNA (Systems Network Architecture). Ensuite, il a été repris par l organisation ISO afin de définir un modèle standard à sept couches dénommé OSI. 37

54 Les réseaux : support de la communication Application Presentation Session Transport Reseau Liaison Physique Figure 1.1 : Le modèle OSI Le modèle OSI 3 de l a défini le modèle présenté sur la figure 1.1 et se décompose en sept couches : 7. Application : protocoles de haut niveau, applicatifs (e.g. HTTP), 6. Présentation : présentation et format des données (e.g. ASN.1), 5. Session : service évolué de la couche 4, synchronisation, reprise, 4. Transport : services de fiabilité, segmentation/réassemblage,... (e.g. TCP), 3. Réseau : routage des paquets (e.g. IP), 2. Liaison : regroupement des bits en trames et vérification, 1. Physique : définition de la taille, forme des connecteurs, tensions (e.g. RS232C). Les deux couches de plus bas niveau (couche physique et couche liaison de données) concernent la partie matérielle, l électronique, et nous les aborderons de manière unique comme une seule couche. Les autres couches seront vues dans des cas particuliers tels que les protocoles IP, TCP et UDP. 1.2 Les données échangées dans un environnement virtuel Avant d étudier les différents aspects des réseaux, il est nécessaire d appréhender les différents types de données qui peuvent être échangés au cours du fonctionnement d une application de réalité virtuelle distribuée. En effet, plusieurs types d informations circulent car, en dehors des données, il est nécessaire d effectuer des synchronisations et diverses opérations de maintenance. Ces informations peuvent être des données de très faible taille mais avec un besoin 3 OSI : Open Systems Interconnection. Le modèle OSI est une décomposition de l architecture d un réseau en sept couches de protocoles indépendantes les unes avec les autres. 4 ISO : International Standard Organization, organisme chargé de définir des normes internationales. 38

55 Les données échangées dans un environnement virtuel temps réel fort, comme par exemple pour les mises à jour (changement de position d un objet dans une scène virtuelle). À l inverse, il peut s agir d informations de grande taille mais dont les délais importent peu, par exemple les fichiers de forme 3D des objets. G. Kessler a analysé ces différents types d informations et les a séparés en trois parties distinctes [Kessler et al. 96] : mises à jour : elles transportent l état d une sous-partie de l environnement. Ce sont des messages qui, en cas de perte, ne peuvent être retransmis car la durée de validité des données est courte. Elles sont dites volatiles [Ko et al. 99], évènements : ce sont des informations qui ne peuvent être annulées et dont la non délivrance risque d altérer le bon fonctionnement de l application, commandes : comme les évènements, elles sont importantes mais, en plus, elles requièrent une réponse de la part du destinataire. On constate qu il y a des informations nécessitant d être transmises de manière très fiable, ce sont les évènements et les commandes. Quant aux mises à jour, elles peuvent être perdues ou erronées mais leur transmission doit être effectuée dans un délai très court pour rester utile. Les mises à jour peuvent être vues comme des flux vidéo (tel que le format MPEG 4 [Fert et al. 00]). C est-à-dire que ces informations sont émises en permanence sur le réseau. Si des pertes se produisent, d autres paquets sont réémis dans les millisecondes qui suivent et vont venir remplacer invalider les données défectueuses. D. Brutzman a approfondi cette classification en définissant quatre types d information transférée dans les environnements virtuels [Brutzman et al. 97] : interactions légères : similaires aux mise à jour de la classification précédente (taille très faible), pointeurs réseaux : ce sont des données très petites sous forme d URL 5 et qui indiquent l endroit, sur un serveur, où des données de tailles plus conséquentes sont disponibles, objets lourds : ce sont les données pointées par les pointeurs réseaux et sont disponibles sur des serveurs. Il peut s agir de fichiers de description de la forme 3D des objets, flots temps réel : ils permettent d échanger de la voix ou de la vidéo. Cette taxonomie introduite par D. Brutzman s explique par l initialisation de l application qui n est pas la même suivant les plates-formes. En effet, certaines platesformes, comme celles basées sur DIS ou SIMNET, considèrent que les différents hôtes disposent déjà de toutes les informations nécessaires et que, dès le lancement de l exécution, seules des mises à jours et des commandes sont à échanger. Dans les autres cas, les pointeurs et objets lourds sont utilisés dans des plates-formes qui peuvent, en cours d exécution, découvrir de nouveaux objets non disponibles lors du lancement (ou non connus avant le lancement) de l application. J. Pullen précise, en appliquant le principe d obsolescence, que seule la dernière valeur 5 URL : Uniform Resource Locator 39

56 Les réseaux : support de la communication d une variable d un objet (mise à jour) est nécessaire [Pullen 99]. De plus, il est plus efficace d envoyer les données évoluant rarement de manière fiable et les données changeantes de manière best-effort Le réseau physique et logique Sur une autoroute, en certains endroits, il se trouve des rétrécissements qui ne posent pas de problèmes en temps normal. Dès que le trafic commence à augmenter, les voitures s accumulent en ces points et provoquent des bouchons. Ce trafic ne peut alors se résorber que si le nombre de voitures arrivant sur ces points critiques diminue. De la même manière, dans les réseaux, le débit, la latence et tout autre paramètre déterminant le flux de données échangées entre deux points est déterminé par des points critiques. Ainsi, si en un point du réseau, le débit maximal est de 1 Mb/s alors le débit maximal sur tout le trajet ne pourra être que de 1 Mb/s au maximum. Dans une application temps réel répartie, le trajet parcouru par les données depuis la source jusqu à la destination doit répondre aux critères désirés 7 par les développeurs sous peine de ne pas pouvoir fonctionner correctement. Le réseau, logique ou physique, ainsi que les bibliothèques de communication et de traitement qui jalonnent le trajet sont critiques. Dans les réseaux informatiques qui se sont développés jusqu à récemment, les aspects temps réel n ont jamais vraiment été pris en compte, ou que très rarement et avec des coûts exorbitants. Ceci peut se justifier, dans un premier temps, par le fait que le but initial d un réseau informatique était de transporter des données de traitement entre plusieurs systèmes. Ce transport devait être réalisé de manière fiable mais sans réel critère de temps. Mais depuis l arrivée de l Internet, le type de données transportées a fortement évolué. Le développement du web, avec ses pages hypertextes, a ouvert la voie à l échange de différents types de médias : texte, voix et vidéo. Avec la voix et la vidéo, la notion de temps prend toute son importance. Il devient nécessaire de transmettre les données (le flux de données) à un rythme régulier car l homme a besoin d une animation régulière des images, c est-à-dire en temps réel et avec un débit régulier. Malheureusement pour nous, les réseaux les plus utilisés sont souvent les plus économiques et donc ceux qui n implémentent pas beaucoup de fonctionnalités nécessaires aux applications temps réel. Les applications distribuées temps réel ont des contraintes telles qu il serait souhaitable qu elles puissent négocier, avec le réseau, les caractéristiques des 6 Le best-effort est un mode de transfert où le réseau fait de son mieux pour transmettre les informations au destinataire. Ce mode a l avantage d être généralement rapide mais aucune garantie ne peut être associée aux données 7 voire imposés, mais peu de réseaux permettent une telle spécification des contraintes. 40

57 Le réseau physique et logique échanges. Sauf, bien sûr, si le réseau est conçu à la base pour n effectuer que des échanges temps réel comme, par exemple, le réseau Les caractéristiques des réseaux qui nous intéressent plus particulièrement sont la bande passante, la latence et la fiabilité. Toutes ces caractéristiques sont généralement regroupées sous le vocable de la qualité de service 9. D autres aspects plus spécifiques sont à ajouter à la qualité de service tels que le taux de perte en moyenne, le taux de perte de n paquets consécutifs, etc. La qualité de service sera vue de manière plus détaillée à la section La bande passante La première chose que l on apprend d un réseau est que ses ressources sont limitées et qu elles doivent être partagées par un certain nombre d utilisateurs. La bande passante représente le volume de données qui peut transiter sur une partie du réseau en une seconde. Cette bande passante varie suivant le type de réseau utilisé. Ainsi, avec un modem, les performances théoriques ne sont que de 56 kbaud/s. Cette limitation fait l objet de nombreuses recherches 10 car elle peut avoir un impact non négligeable sur les nouveaux services pouvant être offerts à l utilisateur. Cet aspect est spécifique aux réseaux car la bande passante généralement disponible dans les ordinateurs est largement supérieure. À titre comparatif, le bus système actuel dans un ordinateur personnel est de 533 MHz 4 octets = 2033 Mo/s tandis que les réseaux ont des débits qui oscillent entre 10 Mb/s (1,33 Mo/s) et 1000 Mb/s (133 Mo/s). La bande passante représente la quantité d information qui peut être échangée en un temps donné. Donc, plus la bande passante est grande, plus les informations peuvent être détaillées et précises. Malheureusement, la bande passante disponible sur un réseau est limitée. Bien que les fibres optiques aient des performances supérieures aux débits actuels, la bande passante est limitée par les équipements de commutation mis en place par les opérateurs. Bien sûr, c est le coût de ces équipements qui détermine le débit offert La latence La latence est un problème pour les applications temps réel (aussi bien locales que distribuées géographiquement). Une latence trop grande risque d avoir des effets néfastes sur 8 CAN : Controller Area Network. C est un protocole de communication série qui supporte efficacement le contrôle en temps réel de systèmes distribués. Il est utilisé dans le domaine automobile et est normalisé ISO ou QoS pour Quality of Service. 10 dont l xdsl (ADSL, HDSL,... ) en est un des résultats. 41

58 Les réseaux : support de la communication l immersion de l utilisateur. Ainsi, si l information arrive trop longtemps après son émission, sa valeur risque de ne plus présenter d intérêt. A moins d être gérée par le réseau, la latence est une partie intrinsèque de l infrastructure du réseau. Mais ce paramètre n affecte pas seulement la performance globale de l interaction, elle peut aussi être un élément clé de la cohérence globale du système. Si, par exemple, un utilisateur saisit un objet alors le processus associé transmet un évènement vers les autres utilisateurs les informant de l occurrence de cet évènement. Pendant cette interaction, si un autre utilisateur décide de saisir ce même objet, ceci est normalement rendu impossible en vertu du principe d exclusion mutuelle. Par contre, si le paquet transportant l information associée à l interaction est retardé, alors un état incohérent peut être obtenu. En effet, dans ce cas, les deux utilisateurs auront saisi le même objet et recevront tous les deux un message les informant que l autre utilisateur a saisi cet objet [De Oliveira et al. 98]. Un nouvel échange doit intervenir pour restaurer la cohérence et risque d augmenter encore un peu plus la latence dans l interaction de saisie. Au delà d une latence de 250 millisecondes, l utilisateur est découragé par l utilisation de l application [Lea et al. 95]. Ainsi, dans DIS, les valeurs limites de la latence pour les échanges de messages sont fixées à 100 ms pour les évènements fortement couplés (réaction à un évènement) et à 300 ms maximum pour les évènements faiblement couplés (évènements ayant une interdépendance) [Locke 94]. Une des techniques les plus utilisées pour résoudre ces problèmes de latence est le dead reckoning 11 que nous détaillerons à la section de la troisième partie La fiabilité Un autre problème concernant la cohérence de l ensemble de l application est la fiabilité des échanges. Comme l information temps réel est très dépendante du temps, choisir un protocole utilisant un acquittement pour chaque message et effectuant un recouvrement d erreur en cas de défaillance n est pas envisageable. Il s agit d un compromis à définir entre la bande passante et la latence. Il est donc nécessaire de recourir à l utilisation de protocoles fiables et non fiables. Les échanges non fiables sont effectués pour fournir des informations à temps, c est-à-dire fournir en permanence des informations sur l évolution de l environnement simulé et des interactions des autres participants. De toute façon, dans une application temps réel, il n est pas possible de revenir en arrière. Les échanges fiables sont, par contre, transmis pour mettre à jour les bases de données d informations sur l environnement afin que la consistance de l ensemble des processus formant l application soit effective. 11 Le dead reckoning est une technique permettant de ne transmettre la position des objets mobiles qu à des instants définis et évite la transmission trop fréquente de la position. 42

59 Les protocoles de communication Hôte Hôte Hôte Hôte Hôte Hôte Hôte Hôte Hôte Hôte Hôte a) bus b) anneau c) maillage complet Figure 1.2 : Différentes topologies de réseaux La topologie du réseau physique Dans un réseau local, la topologie du réseau physique représente un aspect non négligeable de la performance globale. En bus, en anneau, en étoile ou d autres topologies (c.f. figure 1.2), le réseau offre des caractéristiques parfois intéressantes, parfois gênantes. Les applications de réalité virtuelle, dont la base de données est répliquée sur chaque hôte, nécessitent d échanger en permanence des informations sur les évènements qui se produisent. Tous les hôtes doivent donc être capables de recevoir ces informations sous peine de se retrouver avec des informations incohérentes. Ainsi, le réseau Ethernet 10Base2 semble bien adapté à ce type d application puisqu il offre une topologie en bus. C est-à-dire que lorsqu un hôte émet des données sur le réseau, tous les autres hôtes peuvent recevoir ces données sans aucune action de leur part. Bien que propice à ce genre d application, les topologies en bus ou en anneau tendent à disparaître et à laisser place à des topologies du type étoile. En effet, le bus ou l anneau ne sont pas bien adaptés à la plupart des applications car leur diffusion intrinsèque pose des problèmes au niveau de la sécurité (tous les hôtes voient toutes les données), du débit (pendant que quelqu un émet, les autres ne peuvent qu écouter) et de la fiabilité (une défaillance à un endroit du réseau rend la communication impossible pour le reste des hôtes). C est pour ces raisons que cette fonctionnalité n est plus proposée par le réseau physique mais plutôt par la partie logique. Nous verrons, aux sections et 1.4.4, que les protocoles proposent la diffusion généralisée et la diffusion restreinte afin de couvrir ce type de besoin. 1.4 Les protocoles de communication Au dessus du réseau physique, c est-à-dire les couches 1 et 2 du modèle OSI, on retrouve de nombreux protocoles qui vont permettre d utiliser au mieux les fonctionnalités du réseau voire de créer de nouvelles fonctionnalités. L évolution qui s est produite avec le protocole 43

60 Les réseaux : support de la communication IP montre bien ce qui est en train de se produire de manière plus générale. Cette évolution d IPv4 à IPv6 ne cherche pas seulement à résoudre les problèmes d adressage 12 mais cherche également à apporter de nouveaux services. Cette évolution montre bien qu il y a quelques années, le seul besoin des utilisateurs était de transférer des données de manière fiable entre deux ordinateurs en un temps fini alors qu aujourd hui, l évolution de l Internet et l apparition de l hypertextualisation ouvre l accès à tous les médias, texte, image, voix et vidéo. Ces deux derniers points sont très sensibles à une variation temporelle pendant leur transfert et requièrent une attention particulière. De la même manière, les applications de réalité virtuelle tiennent compte des aspects temporels et ne pourront vraiment s imposer sur des réseaux longues distances qu à partir du moment où le paramétrage des besoins pourra être spécifié et pourra être satisfait de bout en bout. La pléthore de réseaux qui existe est due aux différentes utilisations possibles de ces derniers ainsi que par les différences dans les services proposés. Les réseaux de télécommunications sont adaptés au transport de la voix, les réseaux de terrain 13 respectent des contraintes de temps, etc. Les réseaux informatiques sont aussi très nombreux : TCP/IP, Novell Netware 14, ATM, Token Ring et bien d autres encore. Dans cette section, nous allons détailler des protocoles de communications. Tout d abord, le protocole TCP/IP et ses dérivés car c est le réseau le plus étendu et surtout, le plus utilisé. Nous nous pencherons ensuite sur le multicast, une technique permettant de transmettre des données en émettant moins de paquets. TCP/IP implémente une technique de multicast mais son inconvénient est qu elle est non fiable. De nombreux travaux [Pullen 99] [Yavatkar et al. 95] se sont donc développés pour trouver des solutions à un multicast fiable. Enfin, nous terminerons en abordant le protocole IPv6 et ATM. En effet, ces deux réseaux ont la particularité d être étudiés pour convenir au maximum d applications. Nous parlerons de la qualité de service (QoS) qui est présente de manière native dans ATM mais qui n existe dans TCP/IP que par le biais de protocoles spécialisés. 12 IPv4 autorise moins de d adresses différentes possibles. Bien qu un certain gaspillage se produit, le réseau Internet est arrivé à saturation. Une solution temporaire, avec l adressage CIDR, a été trouvée mais le développement des mobiles et de l Internet dans les pays en voie de développement nécessitent le nouvel adressage IPv6 (2 16 adresses possibles). 13 Les réseaux de terrain (CAN, FIP, ModBus,... ) permettent et garantissent des échanges en temps réel mais ont des débits plutôt faibles. 14 Novell Netware est une pile protocolaire similaire à TCP/IP et fonctionne en réseau local (Ethernet, ARCnet ou Token Ring). IPX, SPX et NCP sont les couches 3 et 4 propres à ce réseau et proposent de nombreux services facilitant la découverte des serveurs sur le réseau ainsi que leurs services associés. 44

61 Les protocoles de communication Les protocoles de l Internet À l origine, l évolution des réseaux informatiques est fortement liée au ministère de la défense américaine, le DoD 15. En effet, le DARPA 16 a cautionné différents projets de recherche dont certains concernaient le développement d un réseau à commutation de paquets. Un des projets a abouti au réseau ARPANet qui a évolué vers le réseau que nous connaissons aujourd hui, l Internet. Ce réseau est basé sur les célèbres protocoles IP, TCP et UDP. IP ou Internet Protocol joue le rôle de la couche 3 du modèle OSI. C est-à-dire qu il permet de router les données à travers le réseau et d effectuer l acheminement jusqu au destinataire. IP est un protocole non fiable et sans connexion. C est le rôle des couches supérieures de proposer ces services supplémentaires. Ainsi, au niveau de la couche 4 du modèle OSI, on retrouve deux protocoles distincts, TCP 17 et UDP 18. Ces deux protocoles sont complémentaires car ils ne couvrent pas les mêmes besoins. TCP est orienté connexion et assure la fiabilité des communications. Il permet de garantir le bon acheminement des données ainsi que leur réassemblage au niveau du destinataire. En se reportant à la section 1.2, on peut tout de suite imaginer qu il corresponde bien aux envois de commandes et aux évènements de G. Kessler et, aux objets lourds de D. Brutzman. UDP est l opposé de TCP dans le sens où il est sans connexion et non fiable. Par contre, ses défauts font qu il est beaucoup plus rapide que TCP. Il est donc bien adapté aux données du type mises à jour de G. Kessler et aux interactions légères de D. Brutzman. En suivant la classification de D. Brutzman, on s aperçoit que les pointeurs réseaux et les flots temps réel ne rentrent pas vraiment dans l une des deux catégories sus-citées. Les pointeurs réseaux sont des données de petite taille mais devant être transmises de manière fiable et les flots temps réel sont des données transmises en continu en suivant un rythme régulier. Ces différences de caractéristiques ont provoqué l émergence de nouveaux protocoles censés apporter une réponse à ces besoins Network Time Protocol (NTP) Dans un environnement distribué, chaque processeur dispose de sa propre horloge interne censée représenter le temps qui s écoule (wallclock time). Ce temps est utilisé dans les 15 DoD : Department of Defense 16 DARPA : Defense Advanced Research Projects Agency 17 TCP : Transmission Control Protocol 18 UDP : User Datagram Protocol 45

62 Les réseaux : support de la communication Serveur T 1 T 3 δ T 4 = T 3 δ+ L Hôte T 1 + δ T 2 = T 1 + δ+ L T 3 L L Wallclock Time Figure 1.3 : Synchronisation par échange de messages NTP [Fujimoto 00] applications pour ordonner et synchroniser les évènements. Malheureusement, les horloges des ordinateurs utilisent des oscillateurs à base de quartz peu précis dérivant fortement avec le temps. Un protocole tel que NTP permet de résoudre ce problème en synchronisant le wallclock time de chaque ordinateur participant à l application. Construit au dessus du protocole UDP, NTP [RFC958 85] fournit les mécanismes nécessaires afin de synchroniser les horloges à une précision allant jusqu à l ordre de la nanoseconde. Le temps est codé sur une taille de 64 bits et permet de synchroniser un (mode client/serveur) ou deux hôtes (mode symétrique). L organisation des serveurs est hiérarchique. Les serveurs primaires (niveau 1) représentent des hôtes synchronisés par un équipement matériel (horloge atomique, par exemple) tandis que les serveurs secondaires (niveau 2 et plus) sont synchronisés par un ou plusieurs serveurs primaires. Le calcul du décalage est effectué suivant la figure 1.3. T 1 représente l horodatage de l envoi du message, T 2 l horodatage de sa réception par le destinataire, T 3 l horodatage de l envoi du message de retour et T 4 l horodatage de la réception du message par l émetteur initial. δ correspond au décalage entre les deux wallclock time des deux hôtes. Ainsi, le temps mis par le message pour aller au serveur vaut L et le temps mis pour le retour vaut L. On peut en déduire le délai d aller / retour d et le décalage moyen de l horloge δ e : d = L + L = T 2 T 1 + T 4 T 3 et δ e = T 2 T 1 + T 3 T 4 2 On considère que la valeur de δ e estimée correspond à une moyenne entre le δ à l aller et le δ au retour. Cet échange régulier de messages permet alors de connaître le temps d horloge du serveur distant et permet également d ajuster le décalage des deux horloges dans une échelle suffisamment faible pour ne pas gêner l application distribuée. 46

63 Les protocoles de communication RTP, Real-time Transport Protocol Le protocole RTP [RFC ] propose de fournir les services associés au transport de flots de données temps réel. Il est implémenté au dessus du protocole UDP mais peut être utilisé au dessus de n importe quel protocole. Les services proposés sont l identification du type de données (payload type), le séquençage des paquets, l horodatage des paquets ainsi qu une surveillance des échanges. L horodatage est effectué à l aide d une valeur non signée codée sur 64 bits identique au format NTP précédent. Le protocole est destiné à fonctionner aussi bien en point à point que dans un échange multipoint. Dans le cas de flots intégrant la voix et la vidéo, deux flots séparés sont émis et synchronisés par l application réceptrice. Par contre, il ne garantit pas la livraison dans les temps ni la garantie de la qualité de service. C est aux couches supérieures que revient le rôle d assurer ces caractéristiques. Le protocole RTP est en fait scindé en deux protocoles. RTP assure le transport des données tandis qu un autre protocole, RTCP 19 fournit les services de surveillance. RTCP offre un retour d information sur la qualité des échanges entre l émetteur et les destinataires, il transporte le CNAME (Canonical NAME), c est-à-dire le nom associé à l utilisateur, afin de rétablir l état de la connexion en cas d erreur et permet également d échanger des informations entre les participants (surtout utilisé dans les applications faiblement couplées) La qualité de service Longtemps délaissée par les réseaux informatiques, la qualité de service est dorénavant prise en compte. En effet, pendant longtemps, de nombreux réseaux existaient les uns à côté des autres et chacun était spécialisé dans un type d application (téléphonie, haut débit, échange de fichiers). La généralisation des réseaux à très haut débit et l apparition d applications multimédias (voix, vidéo, image, son et texte) ont fait apparaître de nouveaux besoins. Afin d optimiser l utilisation des connexions du réseau, les opérateurs autorisent généralement un trafic supérieur à la capacité maximale. Ils jouent sur des analyses statistiques qui font que le réseau ne sera, dans la plus grande partie de son temps, jamais saturé. Malheureusement, agir de cette manière, laisse toujours une possibilité pour qu une congestion se produise. Certains réseaux, comme ATM 20, utilisent un contrôle à l admission, ce qui permet de pallier à ces trafics surestimés. Lors de l établissement d une connexion, l utilisateur spécifie les caractéristiques de qualité de service requises et le réseau détermine si cette requête peut être acceptée. Si le nouveau flot risque de briser les contrats déjà établis, alors 19 RTCP : RTP Control Protocol 20 ATM : Asynchronous Transfer Mode 47

64 Les réseaux : support de la communication l établissement de la connexion est refusé et l utilisateur doit reformuler un nouveau contrat moins contraignant. Pour optimiser l allocation des ressources, ATM propose quatre catégories de services pour classer les flots de données [Dutton et al. 95] : Constant Bit Rate (CBR) pour les flots de données dont le débit est constant (voix, émulation de circuits, vidéo), les délais de transfert courts et la gigue 21 très faible, Variable Bit Rate (VBR) pour les flots de même type que CBR mais dont le débit est variable. Deux sous-catégories existent, temps réel ou non temps réel, Unspecified Bit Rate (UBR) pour le trafic de type best-effort. En cas de congestion, cette catégorie peut être touchée, Available Bit Rate (ABR) permet un trafic garanti mais avec des variations de débit très grandes. C est-à-dire que l application doit adapter en permanence son débit en fonction de la disponibilité du réseau Le réseau ATM Au début des années 1980, le réseau ATM 22 a franchi un grand pas en fournissant un réseau capable de supporter tous les types de trafic que ce soit de la vidéo, du son ou des données. Cette performance technologique a été rendu possible par l utilisation de la commutation de cellules réalisant ainsi une fusion entre les réseaux à commutation de circuits (réseau téléphonique) et les réseaux à commutation de paquets (réseau informatique). Relativement coûteux, le réseau ATM est orienté vers l utilisateur en proposant de larges possibilités dans la spécification de la qualité de service requise pour les flots de données. Ainsi, ATM permet de spécifier la qualité de service à l aide de 10 paramètres [Black 99] : Peak Cell Rate (PCR). Ce paramètre correspond au débit maximum de la transmission, Sustained Cell Rate (SCR). C est la valeur moyenne du transfert, Minimum Cell Rate (MCR). Le débit minimum acceptable par l application avant un risque de détérioration, Cell Variation Delay Tolerance (CVDT). Cette valeur représente la gigue maximale acceptable. Cell Loss Ratio (CLR). Il correspond au taux de cellules arrivées trop tardivement ou perdues en cours de transfert, Cell Transfer Delay (CTD). Il définit le délai maximum de transfert des cellules, Cell Delay Variation (CDV). C est la gigue maximum autorisée sur le flot de cellules, Cell Error Ratio (CER). C est le taux d erreurs moyen pendant le transfert, 21 La gigue est la variation de temps qui se produit entre les envois réguliers de données synchrones. 22 Pour plus d informations sur le réseau ATM, on pourra consulter l excellent ouvrage de la série RedBooks IBM [Dutton et al. 95] ou, pour une présentation rapide des possibilités d ATM, mon cours à l adresse raulet/enseignements/reseaux/ 48

65 Les protocoles de communication Severely Errored Cell Block Ratio (SECBR). Cette valeur représente le taux d erreurs par bloc (suite de plusieurs cellules), Cell Misinsertion Rate (CMR). Ce paramètre correspond au taux de cellules envoyées vers le mauvais destinataire. De plus, lorsque la congestion est telle que même les cellules marquées supprimables ne résolvent pas le problème, le réseau peut alors décider de supprimer d autres cellules suivant les caractéristiques de qualité de service qui lui sont appliquées. Certains travaux de réalité virtuelle s appuient sur le réseau ATM pour développer des applications capables de communiquer avec de bonnes performances tant en débit qu en qualité de service. Le projet Visinet [Lamotte et al. 97] lancé en 1994 s est servi d un réseau ATM pilote pour démontrer la viabilité d un réseau large bande et montrer son impact sur le développement d applications La réservation de ressources dans l Internet D un autre côté, le développement rapide d IP a été rendu possible de par son faible coût mais au détriment de ses capacités d adaptation. Aujourd hui, les instances de l Internet cherchent à corriger ces défauts en définissant de nouveaux protocoles. Le protocole RSVP 23 [RFC ] et depuis peu, la nouvelle norme IPv6 [Cizault 98], montrent que le réseau Internet se diversifie et que le multimédia représente le prochain challenge. Le nouvel Internet [Braden et al. 94] se propose de définir différentes classes permettant de séparer le trafic requérant des échanges temps réel et les autres trafics, plus souples. Cette gestion n est réalisable que si les liens intermédiaires (les commutateurs) peuvent être contrôlés. Pour minimiser l impact de ce changement, le protocole a été conçu de manière à ne pas modifier ce qui a déjà été défini. Il ne propose que des extensions pouvant être ignorées par les nœuds ne les supportant pas. Le contrôle est réalisé en réservant des ressources et en effectuant un contrôle à l admission par le destinataire 24. C est ici que RSVP intervient. Son rôle est de proposer un protocole permettant de réserver des ressources. Deux modules de décision déterminent si la réservation peut être effectuée. Le contrôle à l admission vérifie que les ressources demandées sont disponibles et la politique de contrôle vérifie que l utilisateur a le droit d effectuer ce type de réservation (sécurité). Ensuite, un classifieur détermine la route et la classe des paquets. Enfin, un ordonnanceur de paquets détermine quand envoyer les données. Trois styles de réservation sont 23 RSVP : Resource reservation Protocol 24 Cette manière de procéder est déjà implémentée dans ATM mais par l émetteur. Les VBR et CBR permettent de réserver les ressources et l établissement du contrat n est établi que si le réseau l a accepté (contrôle à l admission). 49

66 Les réseaux : support de la communication possibles afin de s adapter au mieux aux besoins des applications, la réservation wildcard, le filtre fixe et le filtre dynamique. Chacun permet de définir comment la réservation s effectue par la source, le destinataire ou l ensemble des destinataires La diffusion La diffusion ou broadcast peut représenter d énormes avantages dans certaines applications. Ainsi, plutôt que de transmettre n paquets sur un réseau local vers n hôtes, la diffusion limite l utilisation du réseau en ne transmettant qu un seul paquet qui sera reçu par tous les hôtes. Cette possibilité n est pas offerte par tous les types de réseaux. Le réseau local Ethernet est un des plus utilisé et permet cette technique. Le principe consiste à transmettre le paquet, non pas vers un destinataire déterminé, mais à l adresse du réseau avec tous les bits de l adresse machine à 1. Par exemple, le réseau a une adresse de diffusion de Les inconvénients de ce principe sont que l utilisation de la diffusion est limitée au réseau local et que les hôtes inintéressés doivent traiter le paquet pour déterminer si l information les concerne ou non. En effet, pour éviter un phénomène de cascade qui saturerait le réseau Internet, les paquets en diffusion ne sont pas routables. Ainsi, le paquet ne peut sortir du réseau dans lequel il est émis. D autre part, la diffusion ne permet pas de cibler quels hôtes vont recevoir l information. Si de nombreux paquets sont transmis de cette manière, les hôtes risquent de passer énormément de temps à traiter des paquets qui ne les intéressent pas La diffusion restreinte Afin de pallier aux inconvénients de la diffusion générale, la diffusion restreinte ou multicast permet de cibler les destinataires des différents messages émis. Le multicast permet d atteindre m hôtes sur un réseau comportant n hôtes. Ce type d échange est idéal pour les flots de données. Afin de permettre un échange entre l émetteur et les récepteurs, il est nécessaire de définir les différents récepteurs des informations émises sur un canal multicast. Le multicast définit des groupes dans lesquels les utilisateurs vont s abonner pour recevoir les informations associées. Dans TCP/IP, les données multicast sont transmises à travers des paquets dont l adresse de destination est une adresse multicast ou adresse de classe D. TCP/IP définit une adresse multicast comme une adresse commençant par les bits Ainsi, il existe 2 28 adresses multicast soit autant de groupes possibles. Limité initialement au réseau local, le multicast restreint peut être diffusé au-delà de cette limite, à travers le réseau longue distance, en ayant recours à des routeurs appelés 50

67 Les protocoles de communication mrouter. Ces routeurs créent des tunnels permettant d échanger des informations entre plusieurs réseaux locaux comme si les hôtes étaient tous présents sur le réseau local. De plus, une dorsale spécifique au multicast, MBone ou Multicast backbone, a été créée. Elle permet d interconnecter différents LAN multicast ensemble à travers l Internet. Il s agit d un réseau virtuel puisqu il emprunte le même réseau que le trafic Internet classique, et utilise des routeurs spécifiques (mrouter) La diffusion restreinte fiable Le multicast usuel de l Internet est basé sur le protocole UDP, par conséquent, il est non fiable. Ce choix technologique convient bien à des trafics de données concernant la vidéo et la voix. En effet, la perte d une partie des données n a que peu d impact sur la reproduction de l image ou du son. Le seul risque est de perdre certains détails. De plus, la retransmission des données perdues n est pas réalisable car elles deviennent aussitôt obsolètes dues aux délais de transfert. L inconsistance d un environnement virtuel distribué est tolérable jusqu à un certain point mais il est quand même nécessaire de disposer d un multicast fiable pour distribuer certaines informations et ainsi éviter de trop grandes dérives. Dans [Szwarcman et al. 01], Szwarcman indique que les applications simulant un monde virtuel nécessitent quatre modes de communication : point à point non fiable : mise à jour entre deux hôtes, point à point fiable : échange d informations de synchronisation, de cohérence,..., point à multipoint non fiable : diffusion de mises à jour, point à multipoint fiable : échange de données pour rendre les informations consistantes. Bien évidemment, si les performances entre la version non fiable et la version fiable étaient les mêmes, on ne privilègerait que les communications fiables. Cependant, la communication fiable est sûre mais lente tandis que la communication non fiable est rapide mais non sûre, c est-à-dire qu il n y a pas de certitudes quant à la délivrance des données. Dans la communication point à point, il existe deux modes de transfert, chacun ayant ses avantages et inconvénients. Dans le modèle TCP/IP, la communication point à point non fiable est gérée via le protocole UDP et la communication point à point fiable est gérée par le protocole TCP. Dans la même idée, de nombreux travaux se sont intéressés à l élaboration d un protocole multicast fiable. 51

68 Les réseaux : support de la communication Ainsi, SRTP [Pullen 99] 25, RMTP 26, RMT 27@, RAMP, RMP, TMTP 28 [Yavatkar et al. 95], MTP-2 et ALP/SRM 29 sont tous des protocoles multicast pour le modèle TCP/IP. Le développement d un multicast fiable est plus complexe. En effet, l émetteur doit être assuré que tous les destinataires ont bien reçu le message. Pour cela, dans la communication point à point, le destinataire renvoie un acquittement (ACK, acknowledge) pour informer de la bonne réception des données. Dans un envoi multicast, si tous les destinataires renvoient un acquittement, il se produit une cascade d acquittements (flooding acknowledge) qui engorgent le réseau. Comme on suppose qu un réseau a plus de chance de transmettre des paquets que d en perdre, on utilise une approche orientée récepteur. C est-à-dire qu on utilise un acquittement négatif (NACK ou NAK, Negative ACKnowledgement). Dans ce cas, les destinataires renvoient un message que s ils n ont rien reçu. Ceci nécessite toutefois de disposer d un flot continu de données. En cas de défaillance, on peut utiliser le même genre de principe que CSMA/CD 30, chacun attend un temps aléatoire et si aucun n a émis un NACK, alors l hôte en émet un (ceci évite les Storm-NACK). Par contre, ce principe requiert un flot continu sinon, il ne peut différencier si le flot s est interrompu volontairement ou si le message est perdu. Parmi toutes ces solutions, certaines essaient de correspondre à une solution générique tandis que d autres essaient de s adapter à des cas particuliers. Pullen indique qu il n y a pas de solutions générales au multicast mais plutôt des solutions plus adaptées à certaines applications [Pullen 99] Les protocoles spécialisés Les applications de Réalité Virtuelle nécessite une bonne immersion de l utilisateur et ceci est rendu possible en permettant l échange des données dans les temps impartis et avec la fiabilité requise. Les protocoles développés spécifiquement pour ce type d applications offrent le support nécessaire pour échanger des données en temps réel, permettre l échange de tous les types de données requises et aussi permettre une bonne extensibilité de la plateforme. 25 SRTP : Selectively Reliable Transport Protocol 26 RMTP : Reliable Multicast Transport Protocol 27 RMT : Reliable Multicast Transport (IETF) 28 TMTP : Tree based Multicast Transport Protocol 29 SRM : Scalable Reliable Multicast 30 CSMA/CD : Carrier Sense Multiple Access/Collision Detect. Ethernet utilise ce mode qui se divise en trois étapes. Tout d abord écouter le réseau et attendre qu il soit libre. Lorsqu il est libre, émettre le paquet puis écouter à nouveau le réseau. Si les données reviennent non modifiées alors il n y a pas eu de collisions. 52

69 Les protocoles de communication Carte acceleratrice & Moniteur Composant client Les composants VRTP Graphe de scene 3D et rendu VRML, Java3D, OpenGL, autres API Composants VRTP en detail composant de flot (streaming) Composant de services Composant surveillance de reseau Couche d abstraction du graphe de scene evenements geometrie Flot point a point (comportement transitoire) Dispatch evenements protocole dial a behavior buffer flot de comportement RTP, RTCP. RTSP Gestionnaire AOI Services du monde (contenu statique) Chargement graphe de scene QuICk (Quality, Interest, Complexity) Modele du monde Persistance Detection de collision Apache Surveillance du reseau Surveillance LAN & WAN bridge log report SNMP NTP synchronisation du temps Plate forme universelle UDP TCP IP Plate forme universelle API reseau bas niveau, JVM, plugins Bamboo, ACE Systeme d exploitation & pile de protocoles IP Materiel & NIC Reseau (couche physique) Figure 1.4 : Les 4 composants vrtp : client, serveur, pair à pair et surveillance VRTP VRTP 31@ [Brutzman et al. 97] est le plus connu des protocoles de communication pour la réalité virtuelle. Ses concepteurs partent de l idée que s il existe un protocole HTTP adapté au format de fichier HTML alors il peut être intéressant de définir un protocole, appelé VRTP, adapté au format de fichier VRML VRTP doit apporter des fonctionnalités au niveau du client, du serveur, des échanges multicast et de la surveillance du réseau. Les quatre composants de l architecture VRTP sont présentés sur la partie gauche de la figure 1.4 et s intègrent au dessus de la plate-forme universelle : client. Il s agit du navigateur. Il doit fournir les capacités nécessaires à la réalisation de plugins spécialisés ainsi qu une machine virtuelle Java. Ce dernier est nécessaire pour utiliser l API VRML de Java ainsi que le protocole de mise à jour du comportement, dial-a-protocol. composant de services ou serveurs. Le serveur Internet (Apache), doit fournir un accès aux ressources de la machine (fichiers de données) et permettre son extensibilité via CGI VRTP : Virtual Reality Transfer Protocol 32 VRML : Virtual Reality Modeling Language, format de fichier permettant de décrire des scènes 3D ainsi que les objets contenus dans la scène. De plus, le comportement des entités peut être décrit à l aide d un langage supplémentaire, JavaScript par exemple. 33 CGI : Common Gateway Interface 53

70 Les réseaux : support de la communication composant de flot. Ce composant doit proposer un support multicast efficace. De plus, les différents types d échanges, audio, vidéo, tableaux blancs, DIS, protocoles de comportement, doivent pouvoir tirer parti de ces possibilités. surveillance. L extensibilité de l application n est envisageable que si l infrastructure du réseau est suffisamment robuste et que les différents indices (latence, gigue,... ) soient mesurables. La surveillance doit permettre d adapter l application au réseau et d optimiser son utilisation. SNTP 34 permet d effectuer des mesures précises et SNMP 35 permet la surveillance du réseau. Les quatre composants ainsi que la plate-forme universelle sont détaillés sur la partie droite de la figure 1.4. La plate-forme universelle doit représenter une base de communication avec le reste de l application et doit proposer tous les services attendus dans les environnements virtuels. Une implémentation appelée [Watsen et al. 98a] [Watsen et al. 98b] existe et sera discutée dans la troisième partie de ce mémoire. Le composant de flot est intéressant car il intègre le protocole dial-a-behavior. Les auteurs sont partis du constat que l extension et les modifications des PDU 36 de DIS ont mis deux années pour être standardisées. Afin de permettre une évolution aisée des protocoles, dial-a-behavior définit un format de PDU avec une syntaxe abstraite. Ainsi, un nouveau protocole peut être inséré et une applet Java permet alors d interpréter le nouveau protocole. L approche de VRTP est intéressante en plusieurs points. Tout d abord, la séparation de l architecture en différents composants rend son évolution plus aisée. Ainsi, il est possible de changer les mécanismes de communication 37 sans pour autant modifier les couches supérieures. Ensuite, le protocole dial-a-behavior offre une extensibilité dynamique à la plate-forme. Il devient possible de faire évoluer le comportement des entités pendant l exécution. Enfin, la surveillance du réseau est une fonctionnalité qui n existe généralement pas sur les autres architectures. Elle permet de surveiller la qualité du réseau et adapte automatiquement les échanges par rapport à ce dernier DWTP DWTP 38 [Broll et al. 98] [Broll 98] se place au-dessus de TCP et UDP. Il permet à un environnement virtuel de transférer et de recevoir différents types de données : évènements, messages, fichiers et flots de données. Les évènements peuvent être transmis de manière fiable (ouverture d une porte) ou non fiable (position, orientation). Le protocole permet de le 34 Simple Network Time Protocol 35 Simple Network Management Protocol 36 PDU : Protocol Data Unit. DIS et les PDU sont étudiés plus loin dans ce mémoire. Le lecteur peut trouver de plus amples informations à la section 1.3 du chapitre 1 de la partie III 37 L auteur parle d intégrer HLA dans l architecture. 38 DWTP : Distributed Worlds Transfer and communication Protocol 54

71 Les protocoles de communication spécifier. Les messages sont des évènements prédéfinis. Les fichiers permettent de transférer le contenu de l environnement virtuel (représentation 3D). DWTP supporte l approche client/serveur ainsi que la transmission un vers plusieurs. participant paquets restaurés requête démon de recouvrement démon du monde démon unicast groupe multicast démon unicast démon de fiabilité participant unicast participant unicast Figure 1.5 : Les différents démons du protocole DWTP [Broll 98] Il utilise différents démons pour remplir les différentes tâches et la communication entre les démons se fait par multicast. Cette décomposition permet une extensibilité et une adaptabilité du protocole. Présentés sur la figure 1.5, les démons sont : démon du monde : pour joindre un monde partagé et transmettre son contenu vers de nouveaux participants, démon de fiabilité : pour détecter les défauts de transmission pour les données émises de manière non fiable, démon de recouvrement : pour fournir une connexion point à point et recouvrer les données perdues, démon unicast : pour permettre l accès aux participants ne pouvant pas faire du multicast. Tous les échanges entre les participants et entre les démons s effectuent à l aide d un protocole multicast. Dans le cas où l hôte ne supporte pas le multicast, un démon unicast offre la possibilité à ce dernier de participer. Lorsqu il rejoint le monde, il établit une communication avec un démon unicast. Toutes les requêtes ultérieures passent par ce démon qui joue un rôle de proxy. Un démon unicast peut gérer plusieurs utilisateurs unicast. De plus, plusieurs démons multicast peuvent être associés à un utilisateur si, par exemple, on veut séparer les canaux de communication (voix, mises à jour). Enfin, le démon peut participer à plusieurs canaux multicast. En cas de défaillance du réseau, le démon de recouvrement permet de récupérer les données perdues. Ce démon cache les données échangées pendant un certain temps. Lors d une demande de recouvrement, les mises à jour ayant eu lieu entre la défaillance et la demande sont transmises par le démon. Si la défaillance dure trop longtemps, il se peut que le démon de recouvrement n ait pas conservé les informations. Dans ce cas, l utilisateur se 55

72 Les réseaux : support de la communication connecte à un démon du monde et transmet son horodatage. Le démon lui envoie en retour toutes les modifications ayant eu lieu ISTP ISTP 39 [Waters et al. 97] est un protocole utilisé dans la plate-forme développée par le laboratoire Il est basé sur un mélange de protocoles : HTTP, RTP, TCP/IP et UDP multicast. HTTP est utilisé pour le transfert de grosses données. RTP lui sert à transmettre des flux de données tels que l audio, les messages courts sont transmis via le multicast non fiable et des connexions TCP entre les clients et les serveurs permettent l échange de messages fiables. Présentation Le protocole ISTP a été défini pour fournir une couche de transport satisfaisant les buts suivants : 1. proche temps réel : les changements d état doivent être transmis aussi vite que possible, 2. égalité de l état : l état partagé par différents processus doit être pratiquement le même, 3. extensibilité : il doit pouvoir supporter plusieurs centaines d utilisateurs et plusieurs centaines d objets, 4. malléabilité : l extension de l application en cours d exécution doit pouvoir se faire, 5. type WWW : l ajout de contributions permet d étendre les fonctionnalités pour ajouter de nouveaux formats,..., 6. bande passante faible : les ordinateurs connectés par modem doivent pouvoir participer. Bien sûr, ces besoins ne sont pas forcément les mêmes avec toutes les applications de réalité virtuelle distribuée mais définir un protocole apportant ces fonctionnalités facilite la mise en œuvre d une telle application. ISTP ne peut faire disparaître les problèmes que nous avons rencontrés, précédemment dans ce chapitre, et qui existent dans les couches standardisées. Ainsi, obtenir un protocole temps réel, consistant et extensible revêt plus d un rêve que d une réalité du fait de l opposition qui existe entre ces souhaits. La malléabilité est nécessaire dans les applications dites non stop car cela permet d étendre les possibilités en cours d exécution. Le dernier point, une faible bande passante, est nécessaire si l on souhaite faire collaborer des participants ne disposant pas de grandes ressources réseau. 39 ISTP : Interactive Sharing Transfer Protocol 40 Spline : Scalable Platform for Large Interactive Networked Environments 41 MERL : Mitsubishi Electric Research Laboratory 56

73 Les protocoles de communication Ainsi, comparé avec d autres approches, R. Waters a évalué, sur une échelle allant de A à E, ISTP vis à vis de l architecture centralisée et vis à vis de DIS. Le résultat est présenté sur la figure 1.6. Serveur DIS ISTP proche temps réel B A A égalité de l état A A- A extensibilité n/a C A- malléabilité C n/a A type WWW n/a n/a A bande passante faible A C A Figure 1.6 : Différentes approches de communication, évaluations [Waters et al. 97] Bien que l évaluation ait été faite par l auteur lui même, le tableau montre une nette différence entre l utilisation d un échange client/serveur ou l utilisation de DIS vis à vis d un protocole spécialisé. Un protocole spécialisé a donc toutes les chances d apporter une amélioration dans le fonctionnement d une application temps réel distribuée. Techniquement, le modèle sous-jacent pour le partage des données est une mémoire partagée distribuée. Pour éviter les conflits entre écrivains, la propriété de l objet est dédiée à un processus qui peut la transférer à un autre processus. Le modèle du monde est divisé en locales qui définit une zone du monde (voir section de la partie III). Chaque processus maintient l état d une partie du monde, c est-à-dire seulement les locales qui l intéressent. UDP est utilisé en point à point lorsque le temps réel importe plus, sinon c est le multicast qui est utilisé et chaque locale est associé à un canal multicast. En plus des locales, ISTP utilise des link et des beacon. Le link est un petit objet contenant une URL pointant vers des données volumineuses. Il s agit des pointeurs réseaux vus à la section 1.2. Les données volumineuses peuvent alors être téléchargées à l aide du protocole HTTP. Le beacon dispose aussi d URL correspondant à des marqueurs sur des objets d autres modèles du monde. Comme présenté à la figure 1.7, chaque processus maintient une copie de la base de données (le modèle du monde). Dans le cas où le client n a pas d énormes capacités réseau, une méthode hybride est employée. Un serveur utilisateur ou proxy est utilisé pour effectuer des transformations sur les données et ainsi réduire la quantité de données à transmettre au client final. Par exemple, plusieurs sources audio peuvent être émises à destination d un même processus. Le serveur réceptionne les différentes sources et génère une nouvelle source audio correspondant à la combinaison des différentes sources audio reçues. Cette dernière, plus petite, est alors transmise au client. 57

74 Les réseaux : support de la communication application application application Modèle du monde Modèle du monde Modèle du monde serveur Réseau Modèle du monde Modèle du monde application Figure 1.7 : Le partage d information avec ISTP Architecture L architecture dispose de neuf classes qui communiquent avec les protocoles d ISTP. Elle est présentée sur la figure 1.8. Les lignes pointillées représentent les héritages entre classes. Toute classe hérite de sp. splinking, spbeaconing et splocale correspondent aux objets link, beacon et locale. spbeaconingmonitor permet d obtenir des informations sur les beacon. spmultilinking est un objet link spécial qui sert d index pour des données en plusieurs morceaux volumineux. spclass décrit les classes définies par l utilisateur. spobserving permet au processus de spécifier quels locales il souhaite obtenir des informations. spaudiosource spécifie les sources de flots audios temps-réel. spbeaconmonitor spbeaconing Content Based Comm. 1 1 Connection Etat de la connexion HTTP: Get, OK, Redirected, Not Found sp splinking splocale spclass spmultilinking Object State Transmission Etat des Objets spobserving Locale Based Comm. Locale Com Status Résumé Etat Objets Suppression de plus. objets spaudiosource Streaming Audio RTP Figure 1.8 : Les différents protocoles de ISTP Toutes les communications entre l application et le protocole ISTP s effectuent par l interface définie par les neuf classes. Ces communications permettent de créer, modifier et supprimer des objets de ces neuf classes. Les sous-protocoles sont représentés dans des ovales et ont un rôle bien défini : Object State Transmission : il permet de communiquer l état des objets d un processus ISTP vers un autre. L échange peut être effectué via un 1 1 Connection ou via le protocole UDP multicast, 58

75 Les protocoles de communication Locale-Based Communication : ce sous-protocole est au cœur du protocole ISTP. Il supporte le partage d informations sur les objets dans le modèle du monde (la base de données), Content-Based Communication : il permet la communication des informations sur les beacon, 1 1 Connection : il permet d établir et de maintenir une connexion TCP entre deux processus ISTP, Streaming Audio : les données audio sont échangées entre les processus ISTP à l aide de ce protocole. Il est basé sur RTP. Les deux sous-protocoles Locale-Based et Content-Based Communication sont des protocoles de plus haut niveau que les trois autres. Le sous-protocole Object State Transmission permet de transmettre l état d un objet. À réception d un tel message, le processus utilise le message pour créer, mettre à jour ou détruire la copie de l objet concerné. Trois transferts sont possibles : complète, différentielle et link différentielle. La description complète permet de décrire tous les objets partagés. La description différentielle minimise le volume des échanges en ne transmettant que les modifications des attributs. Par contre, elle dépend de la réception au préalable d une description complète. La description link différentielle décrit les modifications effectuées aux données associées à un link. Le sous-protocole Locale-Based Communication transmet les informations concernant les changements du modèle du monde. Il utilise le multicast UDP et TCP lorsque des messages UDP ont été perdus. Cette approche offre une latence minimale. Les objets locale permettent de définir la localité des objets entre eux. Ainsi, chaque objet se trouve dans un locale et définit quels locales sont dans son voisinage. Un processus indique quels locales l intéresse en créant des objets spobserving spécifiant le point de vue du processus. Chaque processus dispose d un serveur et la correspondance entre ce serveur et les locales se fait par rapport aux adresses IP. Conclusion Initialement destiné à Spline, ISTP a l avantage de fournir un sous-ensemble de protocoles complets permettant de remplir les besoins d une application de réalité virtuelle distribuée. De plus, il est entièrement découplé de l application à travers neuf classes. Il intègre des fonctionnalités couramment employées dans ce type d application. Les locales offrent une réduction dans la quantité de messages échangés et une plus grande extensibilité. Les link permettent de récupérer des données en cours de fonctionnement. L utilisation du multicast offre une utilisation optimale du réseau. 59

76 Les réseaux : support de la communication VSCP Le projet Virtual Society [Lea et al. 95] regroupe différents projets au sein de Sony CSL 42@. Il a pour objectif de définir de nouvelles technologies destinées à la création de communautés virtuelles et a abouti à la plate-forme Community Place. VSCP 43 [Honda et al. 96] est un protocole d échange entre les clients et les serveurs destiné à ce type d application. Comme pour ISTP, les problèmes à résoudre sont similaires, principalement l extensibilité et le support de communications à différents débits (9600 bauds à 150 Mb/s). Le protocole VSCP coexiste avec le protocole HTTP tel que présenté à la figure 1.9. Application Serveur WWW Serveur VS VSCP HTTP HTTP VSCP VSCP Browser Browser WWW Viewer VS WWW Viewer VS Client Client Figure 1.9 : L architecture de Virtual Society [Honda et al. 96] Le début de la session commence par la connexion de l utilisateur, à l aide du navigateur, sur un serveur WWW. Il va permettre le chargement de la scène initiale ainsi que l adresse et le port d un serveur d application. Cet échange est standardisé par le protocole VSEP 44. À partir de ce moment, tous les échanges sont effectués entre le client et le serveur VS à l aide du protocole VSCP. Chaque modification d une entité locale est transmise au serveur qui a ensuite la charge de redistribuer les modifications vers les autres clients connectés. Pour limiter les échanges, un script local permet de simuler un déplacement de manière similaire au dead reckoning et chaque utilisateur dispose d une aura 45. Chaque message dispose d un format simple comportant l identifiant de l objet à modifier, l identifiant de l action à effectuer ainsi que les paramètres associés à cette commande. Pour permettre l extension du protocole, de nouvelles commandes peuvent être 42 Sony Computer Science Laboratories Inc. 43 VSCP : Virtual Society Client/Server Communication Protocol 44 VSEP : Virtual Society Entry Protocol 45 L aura représente le champ de perception de l objet. L objet ne perçoit pas les modifications apportées aux autres objets en dehors de cette zone. Plus de détails sont fournis à la section du chapitre 2 de la partie III. 60

77 Les protocoles de communication ajoutées via les identifiants. Si le client ne connaît pas l identifiant, il ignore le message sinon, il exécute un script défini pour traiter ce type de message GAIA D. Ko [Ko et al. 99] propose une architecture appelée GAIA 46 fournissant plusieurs protocoles adaptés aux environnements virtuels distribués. Elle est présentée à la figure ARM AEM ARM AEM Event Application AEM: Action Execution Module ARM: Action Request Module RES: Reliable Entity Storage AOIM: Area Of Interest Manager ES: Entity Storage AASQ: Augmented Action Sync. Queue Application Session Server AEM AASQ RES AOIM ARM ARM ARM Action Broker AEM Action Broker ES ARM 1. Architecture globale 2. Architecture interne (AEM, ARM) Figure 1.10 : L architecture de Gaia [Ko et al. 99] L architecture générale, figure 1.10 partie 1, se compose d un serveur de session qui gère la création, la connexion et la déconnexion de l application. Une entité est divisée en deux parties, l AEM et l ARM. L ARM représente une action qui va modifier l environnement et cette action est effectuée par l AEM. Plusieurs ARM peuvent être connectés à un AEM et les AEM sont interconnectés par un réseau à haut débit. L architecture interne est détaillée sur la partie droite de la figure. L exécution de l action par l AEM produit la modification de la base de données de l entité RES. L extensibilité est rendue possible par l AOIM. La synchronisation et l ordonnancement des paquets sont assurés par l AASQ qui permet d ordonner les paquets suivant leur horodatage. de : Les protocoles utilisés dans GAIA sont implémentés au dessus de RTP et se composent GAP ou GAIA Action Protocol transporte les informations des actions, GCP ou GAIA Control Protocol est utilisé pour gérer les informations de la session, les informations initiales, les mesures de performance du réseau et la synchronisation des participants, GDP ou GAIA Data Protocol permet le transfert de données à gros volumes. Le choix de ces différents protocoles a été effectué suivant la proposition faite par D. 46 GAIA : Giga-object Architecture for Internet Applications 61

78 Les réseaux : support de la communication Brutzman, dont nous avons discuté à la section 1.2, qui propose quatre types de communication (interactions légères, pointeurs réseaux, objets lourds et flots temps réel). 1.5 Conclusion Originellement destiné à transporter des données non contraintes, les réseaux informatiques subissent aujourd hui l arrivée de nouveaux besoins représentés par les données multimédia. Cette émergence des besoins va certainement s accentuer d ici quelques années avec la télévision et les stations de radio par Internet, le développement de la visioconférence, la vidéo à la demande et bien d autres applications encore non imaginées. L étude réalisée dans ce chapitre montre que le réseau tel qu il existe aujourd hui sait transporter des données multimédia s il n est pas saturé. Malheureusement, son débit varie en permanence et la prise en compte de ces flux de données spécifiques est nécessaire. Ceci ne peut être réalisé que si les différentes couches qui jalonnent le trajet des données implémentent des algorithmes de traitement rapides. Cette garantie est effectuée par un contrat qui va spécifier la qualité de service que l application souhaite obtenir. TCP/IP se trouve bien dépourvu dans ce domaine mais de nombreuses recherches sont actuellement en cours et cela ne pourra que s améliorer. ATM, par contre, est un réseau tout à fait adapté à cette mission. Il a d ailleurs été conçu pour cela. Ces améliorations ne sont généralement pas suffisantes. En effet, les applications de réalité virtuelle ont des besoins très divers comme nous avons pu le constater dans la section 1.2. Courtes données émises en permanence devant être diffusées, données de grande taille et commandes devant être transmises de manière fiable, tout cela nécessite une prise en compte spécifique pour chacun. Le multicast fiable est un problème pour toutes les applications actuelles quelles soient temps réel ou non temps réel. Les travaux de recherche ont déjà bien avancé et la pléthore de protocoles disponibles actuellement montre que nous n avons probablement pas encore trouvé la solution idéale. Les protocoles spécialisés que nous avons passés en revue utilisent tous des protocoles standards (IP, TCP, UDP, NTP, RTP et autres) ainsi que des protocoles spécifiques pour le multicast fiable. L approche prise par ces protocoles est de fournir n protocoles, spécifiques à chaque besoin de l application, qui correspondent bien à la taxinomie décrite à la section 1.2. De plus, ils implémentent, au dessus de ces protocoles standards, toutes les subtilités nécessaires aux applications de réalité virtuelle. Enfin, la gestion sous-jacente du réseau est masquée à travers une API commune. Cette voie semble prometteuse et la définition d une norme ne pourra que jouer dans le bon sens. Après cette analyse des différents aspects du réseau entrant en jeu dans le fonctionnement d une application de réalité virtuelle distribuée, nous nous intéressons à la manière 62

79 Conclusion de simplifier cette complexité du réseau. Les paradigmes disponibles sont nombreux et nous en étudions seulement quelques uns afin de voir comment un paradigme simplifie la réflexion menée sur la distribution des données. 63

80 Les réseaux : support de la communication 64

81 Chapitre 2 Les architectures de communication 2.1 Introduction Le chapitre précédent a présenté la communication au niveau physique ainsi que toutes les couches permettant de fournir différents services. L abondance de ces protocoles et de ces réseaux permet de choisir au mieux un ensemble de fonctionnalités répondant aux besoins de l application dans le cadre d une mise en œuvre sur un réseau local. Par contre, dans le cas où l application est mise en œuvre à travers un échange longue distance, il devient nécessaire de choisir un réseau offrant le plus grand support de services. Toutes les fonctionnalités vues dans le chapitre précédent tirent parti des capacités des réseaux sous-jacents (possibilité de diffusion large ou restreinte, qualité de service). Toutes ces techniques apportent des avantages non négligeables mais ne facilitent pas le développement d applications distribuées ou réparties. La complexité des réseaux rend leur programmation très difficile et la mise en œuvre d une application distribuée n est pas une chose aisée. Il faut donc tenir compte de la complexité introduite par cette répartition. La synchronisation [Raynal 92b], l échange de données [Raynal 92a], la détection de pannes [Attiya et al. 98] sont autant de facteurs qui nécessitent une attention particulière. Les architectures, telles que celles proposées dans ce chapitre, apportent des paradigmes faciles à comprendre facilitant la réflexion et la mise en œuvre de telles applications. Elles déchargent le programmeur qui peut ainsi se concentrer sur l application elle-même plutôt que de s interroger sur les moyens d accéder aux informations de manière fiable et sûre (accès concurrentiel, par exemple). 65

82 Les architectures de communication Les deux paradigmes utilisés dans la programmation parallèle 1 sont les processus communicants (comme PVM ou MPI) et les espaces de mémoire partagée (par exemple, Linda) [Méhaut et al. 96]. Ces paradigmes de programmation seront détaillés dans les sections 2.2 et 2.3. Un autre paradigme, les tuple spaces [Gelernter 85] sont basés sur les espaces partagés que nous étudierons à la section 2.4. Similaire à la mémoire partagée, il est néanmoins de plus haut niveau car l entité manipulée est l objet. La dernière partie de ce chapitre (section 2.5) présente le bus logiciel. Il s agit de définir un bus virtuel sur lequel vient se greffer un ensemble d objets qui pourront communiquer à travers ce dernier. 2.2 La communication par messages Le paradigme de communication par messages existe depuis de nombreuses années et est implémenté sur de nombreux calculateurs parallèles tels que l Intel Paragon, le Cray T3D,... Il a, en plus, été popularisé avec le développement des réseaux de stations tels que les clusters C est un paradigme d assez bas niveau. Deux modèles sont couramment utilisés, ce sont les librairies [Geist et al. 94] et [MPI Forum 95b]. Les deux modèles coexistent car leurs fonctionnalités ne sont pas forcément implémentées dans les deux types de librairies. Les principales différences sont décrites dans [Geist et al. 96]. Certaines de ces différences tendent à se réduire. Chaque librairie essaie d intégrer les fonctionnalités les plus intéressantes de l autre tout en conservant certaines différences car leurs objectifs ne sont pas les mêmes [Gropp et al. 97]. La communication par messages est basée sur deux primitives de communication : send et receive, d où son nom. Ces primitives peuvent être bloquantes, non bloquantes, asynchrones ou synchrones. En plus de ces primitives, un ensemble de facilités est ajouté tels que les groupes, la communication collective, les réductions, la diffusion, les barrières de synchronisation, etc... [Papadopoulos et al. 98] est un exemple d application permettant le 1 Nous n effectuons pas vraiment de distinctions entre parallèle et distribué. Une architecture parallèle est généralement destinée à des systèmes multi-processeurs où le dialogue s effectue par un bus spécifique très rapide. À l inverse, une architecture distribuée est destinée à faire communiquer plusieurs systèmes mono-processeurs à travers un réseau. Cependant la barrière entre les deux mondes est difficile à cerner. 2 PVM : Parallel Virtual Machine 3 MPI : Message Passing Interface 4 CUMULVS : Collaborative User Migration, User Library for Visualization and Steering 66

83 La communication par messages développement d environnements collaboratifs. Basé sur PVM, il supporte la visualisation interactive et utilise le paradigme de passage de messages à travers un réseau ATM Message Passing Interface (MPI) L API 5 développée pour MPI a été définie par un comité composé de spécialistes dans le but de définir un standard afin d éviter que chaque vendeur de machines parallèles (ou MPP 6 ) ne développe leur propre API propriétaire. Les API comme Express, PARMACS ou NX/2 sont définies par chaque constructeur et sont ininteropérables, ce qui rend le portage d une application difficile. Le développement de cette API a toujours été orienté vers la performance, principalement les architectures à mémoire distribuée, et comporte actuellement (MPI-2 [MPI Forum 95a]) 248 fonctions. MPI fournit une API standardisée pour les langages C, C++ et Fortran. Une évolution importante est la prise en compte des aspects temps réel de certaines applications. MPI/RT est une nouvelle version de la librairie tenant compte de ces aspects. Mais même sans ces fonctionnalités, des applications de réalité virtuelle se sont développées avec MPI, comme c est le cas pour ViSTA 7@ [van Reimersdahl et al. 00]. L utilisation d une telle librairie est souvent effectuée dans le but de créer rapidement un prototype de l application. Ensuite, d autres librairies ou une implémentation directe avec les sockets est effectuée MPI/RT Une version de MPI orientée vers le temps réel, [MPI/RT Forum 01], et financée par le DARPA est normalisée. L objectif est de définir une API permettant au programmeur de gérer le temps réel en terme de performance, prédiction et qualité de service. Des contraintes de temps peuvent ainsi être placées sur les interactions des messages de contrôle et des passages de données. Cette solution essaie de combler l absence d un middleware par message pouvant être temps réel et portable. Deux types de paradigmes sont offerts par MPI/RT afin de spécifier au mieux les besoins des programmeurs : le passage de messages et la programmation temps-réel [Kanevsky et al. 98]. Les paradigmes de passage de messages offerts sont : two-sided communication : c est le mode usuel du rendez-vous des systèmes de passage par messages où chaque interlocuteur doit exécuter des instructions (des deux côtés) pour que l échange se produise correctement. Il est également appelé send and receive. 5 API : Application Program Interface 6 MPP : Massively Parallel Processor 7 ViSTA : Virtual Reality Software University of Technology Aachen 67

84 Les architectures de communication one-sided communication : ce mode provoque l échange à l initiative de l émetteur seul. Le destinataire ne se synchronise pas sur l échange. Aussi appelé put and get. zero-sided communication : dans ce mode, ni l émetteur ni le récepteur ne provoque explicitement l échange de messages. Un ordonnanceur provoque automatiquement le transfert périodique de données. Ce mode de transfert est synchronisé par une période de transfert et est réalisé en définissant des canaux préalablement à l exécution. Le temps réel est permis, dans MPI/RT, par l utilisation des canaux. En effet, MPI/RT ne peut tirer correctement parti des délais de transfert que si les canaux ont été établis au préalable (la performance potentielle est plus grande). Chaque canal est défini par des paramètres de qualité de service, des tampons de messages et un gestionnaire d erreur de qualité de service. Ce dernier peut être soit un des paradigmes temps réel explicité dans le paragraphe suivant, soit des contraintes de qualité de service plus souples. Le gestionnaire d erreur doit permettre d informer l utilisateur de l impossibilité de réaliser l initialisation du canal avec la qualité de service requise. Le second type de paradigme, la programmation temps-réel, a trois sous-paradigmes supportés par MPI/RT. L objectif de ces sous-paradigmes est de permettre à l application un contrôle suffisant de l environnement d exécution et peut donc explicitement ou implicitement ordonnancer ses activités et ses ressources. time-driven et event-driven peuvent être explicitement ordonnancés tandis que priority-driven offre un ordonnancement implicite. Ces paradigmes sont décrits ci-dessous : time-driven : ce paradigme spécifie des intervalles de temps définissant le début et la fin du transfert des messages à travers un canal. Ces spécifications ne sont utilisées que pour la qualité de service du canal. Une périodicité du transfert des messages peut être incluse. La mise en œuvre nécessite de nombreuses étapes mais son utilisation est ensuite très simple : il suffit de mettre les données dans le tampon (pour plus de détails, voir [Kanevsky et al. 98]). event-driven : ce paradigme propose une version bas niveau où l ordonnancement ne se produit qu après l opération de transfert et, une version haut niveau où l activité d une application est contrôlée par un évènement du système, de l application ou de MPI/RT. Ce paradigme ne dispose pas de qualité de service explicite et est donc souvent utilisé de manière conjuguée avec le paradigme time-driven ou le paradigme priority-driven. priority-driven : les priorités sont spécifiées et fixées pour chaque canal à la création. La priorité d un canal doit être identique entre les deux processus communicants. Il est à noter que la valeur de la priorité est spécifique à l implémentation ViSTA Basé sur MPI, [van Reimersdahl et al. 00] est une extension pour la boîte à outils de réalité virtuelle WorldToolKit permettant d effectuer entre autre de la visualisation scientifique et du prototypage. Les ensembles de données et les algorithmes complexes demandent du temps de 68

85 La communication par messages calcul relativement long pour une machine seule. Une des particularités de cette extension est qu elle permet l utilisation de machines parallèles pour accélérer les traitements. La figure 2.1 montre l architecture de ViSTA. Une machine de visualisation est à la disposition de l utilisateur et permet d exécuter l application. L utilisateur peut envoyer des commandes à l application (1) qui va transmettre les requêtes au Gestionnaire de requḙtes (2). Ce gestionnaire de requêtes choisit un Hˆote de travail et transmet la requête à l Ordonnanceur (3). Cet ordonnanceur choisit un ensemble de nœuds pour effectuer le travail, l exécute puis le résultat du travail est transmis au Récepteur (4) de la machine de visualisation. Ce dernier transmet le résultat à l application (1). Hôte de visualisation Mémoire Vis. Data Hôte de travail Ordonnanceur Calc Algo Commandes Application ViSTA 1 Gestionnaire de requêtes 2 4Récepteur 3 Sim. Data Mémoire Calc Algo Calc Algo Calc Data Canal de commandes Canal de données Figure 2.1 : Architecture de ViSTA Deux types d échanges s effectuent, l un à travers le canal de commande et l autre à travers le canal de données. Le canal de commande ne nécessite pas un réseau performant puisqu il s agit de messages de petite taille mais la réponse peut engendrer un gros volume de données et doit donc être mis en œuvre à travers un réseau à haut débit. L implémentation de cette architecture a été réalisée, pour le prototype à l aide de la librairie de communication MPI. Une mise en œuvre à l aide d un protocole spécialisé est envisagée Parallel Virtual Machine (PVM) est un environnement de programmation parallèle conçu à l à partir de Il s agissait d un standard ipso facto car il n existait pas d autres implémentations ouvertes. PVM met en avant le concept de machine virtuelle. Il s agit d un ensemble de machines hétérogènes connectées à travers un réseau et qui apparaît à l utilisateur comme une seule et même machine parallèle. La gestion du routage des messages, de la conversion des données et de l ordonnancement des tâches sont assurées de manière transparente. Cette manière d agir permet de développer des outils (e.g. xpvm) qui peuvent contrôler la machine virtuelle et fournir une certaine dynamicité pendant l exécution. 8 ORNL : Oak Ridge National Laboratory 69

86 Les architectures de communication Les principales différences entre MPI et PVM sont dues à la machine virtuelle et à une meilleure interopérabilité de PVM : 1. interopérabilité : bien que les deux librairies PVM et MPI soient portables (recompilables et réutilisables sur différentes architectures), seul PVM est vraiment interopérable. C est-à-dire que l on peut utiliser des architectures de machines différentes au sein de la même application. De plus, on peut faire interopérer différents langages (e.g. Fortran et C). Cette interopérabilité a un surcoût lié à la transformation des données. Cependant, cette transformation peut être désactivée dans le cas où toutes les machines utilisent la même architecture. 2. la machine virtuelle : disponible avec PVM, elle offre un contrôle beaucoup plus complet et dynamique sur l application et ses ressources pendant l exécution. Elle offre des possibilités de répartition de tâches, de migration et permet de définir un service de nommage, etc. MPI, étant orienté vers la performance, n apporte pas de fonctionnalités dynamiques. 3. tolérance aux fautes : une application distribuée peut avoir à fonctionner pendant des jours, ce qui implique qu une défaillance d un hôte ne doit pas provoquer l arrêt de son exécution. Pour réaliser cela, PVM propose des fonctionnalités (messages de surveillance) permettant de surveiller le fonctionnement de la machine virtuelle et, en cas de défaillance, de réagir en corrigeant le problème. Bien que MPI-2 apporte certaines de ces fonctionnalités, il reste encore en deçà de PVM. 2.3 Communication par mémoire partagée La communication par mémoire partagée est un paradigme qui n exclut pas la communication par messages car la mémoire partagée peut être implémentée de cette manière 9. La mémoire partagée répartie (MPR) ou DSM 10 consiste à détourner les appels mémoire et à définir un certain nombre de pages comme étant partagées par plusieurs hôtes. Les accès possibles sont la lecture ou l écriture. En cas d écriture, le système provoque un défaut de page qui va nécessiter la modification de toutes les copies de la page. Comme l explique [Margery 01], le plus gros problème en terme de performance est de répartir les données partagées dans différentes pages de manière judicieuse. En effet, le défaut de page ajoute une latence très importante qui peut faire perdre tous les avantages de cette solution. Son utilisation est simple et transparente car l utilisateur n a pas à utiliser de mécanismes spécifiques. [Macedonia 95] considère qu une telle architecture ne peut être viable dans le cas d un système composé d un très grand nombre de participants (joueurs). En effet, les besoins 9 La librairie SHMEM de SGI est implémentée par dessus les implémentations de MPI et PVM. Voir 10 DSM : Distributed Shared Memory 70

87 Les espaces partagés en communications fiables entre les différents hôtes introduisent une latence beaucoup trop grande et risque de faire perdre la sensation d immersion de l utilisateur. Différentes versions d implémentations de mémoires partagées existent et permettent de réduire la latence dans les échanges. Par contre, cet assouplissement se fait au détriment des contraintes de fiabilité de la base de données. OpenMP OpenMP 11@ [OpenMP 02] est une spécification récente (1997), développée par un consortium, pour implémenter un système multi-processus. Il est destiné à la programmation parallèle sur des architectures SMP 12 à mémoire partagée. Le code est implanté dans le programme à l aide de commentaires ou de directives dans divers langages (Fortran, C, C++), ce qui permet d être transparent dans le cas où le compilateur ne supporte pas OpenMP. À la différence de MPI ou PVM, OpenMP apporte une approche incrémentale à la parallélisation de programmes séquentiels. C est-à-dire, que le programmeur peut ajouter des directives de parallélisation à l intérieur même d un programme séquentiel. De plus, comparativement aux thread POSIX (pthread), OpenMP apporte une programmation de plus haut niveau [Dagum 97]. OpenMP semble dédié aux architectures parallèles. Cependant, il existe quelques implémentations, telles que TreadMarks [Hu et al. 00], qui permettent d utiliser OpenMP sur des réseaux de stations Les espaces partagés Les espaces partagés qu on appelle tuple spaces ou repositories ont été développés pour la première fois dans le système Linda. Cette idée resurgit actuellement dans de nombreuses implémentations telle que JavaSpaces 14@ [Sun Microsystems 00]. Il s agit d un mécanisme permettant de créer un espace virtuel réparti et partagé par différentes applications. Les applications coopérantes peuvent venir y ajouter ou retirer des objets de l espace partagé. 11 OpenMP : Open MultiProcessing 12 SMP : Symmetric MultiProcessing 13 ou NOW pour Network of Workstations. 14 anciennement JSDA (Java Shared Data API) 71

88 Les architectures de communication Linda Proposée en 1985, [Gelernter 85] est le premier langage de coordination à avoir proposé un espace partagé. La communication entre les processus s effectue par l échange de tuples. Cet espace fonctionne comme une mémoire partagée. Un tuple est une séquence de couples [variable, valeur] qui forment une donnée échangeable et un nom logique qui permet de les classer. Les processus peuvent modifier cet espace en introduisant un tuple (out) ou en sortant un tuple (in) 15. Une opération de lecture (read) est aussi disponible. Elle correspond à in mis à part que le tuple n est pas retiré de l espace partagé. Les problèmes de cohérence sont résolus de manière très simple. Pour éviter la concurrence des accès, le processus qui souhaite modifier un tuple doit d abord le sortir de l espace, le modifier puis le réintroduire dans l espace. L exclusion mutuelle est ainsi respectée. Ce paradigme est utilisé dans des applications de type SPMD JavaSpaces est un outil développé par Sun et écrit en Java. Il implémente le mécanisme d espace partagé et permet aussi la persistance distribuée. Ainsi, il est possible de stocker un groupe d objets et de les rapatrier plus tard. JavaSpaces est implémenté au dessus du bus logiciel Java RMI, permettant la sérialisation et désérialisation des objets. Trois types d opérations, la lecture, l écriture et la prise, sont possibles sur l espace partagé et sont résumées sur la figure 2.2. Figure 2.2 : Javaspaces 15 Bien que troublant, out correspond au fait que le tuple sort du processus vers l espace partagée et inversement pour in. 16 SPMD : Single Program Multiple Data 17 Javaspaces est devenu un composant de Jini. IBM fournit également son propre espace partagé qui offre plus de possibilités. 72

89 Les espaces partagés Deux opérations de lecture sont disponibles pour examiner des objets dans l espace. L opération read permet de lire un objet suivant un template donné. Le template consiste en un ensemble de contraintes permettant de rechercher un objet particulier dans l espace. Les wildcards permettent d assouplir ces contraintes en définissant des attributs pouvant prendre une valeur quelconque. L opération read (waiting) permet d attendre un futur objet qui remplira les critères définis par son template. L application est alors automatiquement notifiée (push) dès l apparition d un tel objet. L opération d écriture (write) permet d ajouter des objets dans l espace partagé. Enfin, la dernière opération, take, fonctionne comme l opération read mais, en plus, retire l objet de l espace La plate-forme EQUIP [Greenhalgh et al. 01] est une plate-forme de réalité virtuelle utilisant le principe de l espace partagé. Le partage est réalisé à travers des espaces de données nommés sous forme d URL et reprend le principe des tuplespaces. Lorsqu un processus décide de partager ses données, elles sont déposées dans l espace en les sérialisant. Les opérations disponibles sont l ajout (add), la modification (update) et la suppression (delete) d un item (entité élémentaire d échange). L échange d informations se fait en définissant des pattern (critères de sélection). Le consommateur décrit l information qui l intéresse et l espace route les données. Ainsi, toute communication entre les différents processus est effectuée indirectement en ayant recours à l espace. Cette technique a l avantage de rendre les processus faiblement couplés entre eux et facilite ainsi le développement de l application Les services de CORBA Un autre paradigme, similaire à l espace partagé, est le service d évènement (CosEvent) de CORBA 19. En effet, les serveurs et clients ont la possibilité de s échanger des informations par le biais d un canal d évènements ou event channel (figure 2.3). Différents fournisseurs ou suppliers produisent des évènements vers un canal donné. Les consommateurs ou consumers reçoivent ces évènements et peuvent les traiter. Les différents intervenants doivent s enregistrer au préalable. Ensuite, les évènements sont échangés de manière asynchrone. De plus, deux grands modes de fonctionnement sont définis : le mode push et le mode 18 EQUIP : EQuator UnIversal Platform 19 CORBA : Common Object Request Broker Architecture 73

90 Les architectures de communication Consommateur Canal d évènements Fournisseur Consommateur Consommateur Fournisseur Sens des évènements Figure 2.3 : Le service d évènement de CORBA pull. Les fournisseurs push produisent des données vers le canal tandis que les fournisseurs pull sont interrogés par le canal. De la même manière, le consommateur push est notifié, par le canal, de la présence des données tandis que le consommateur pull contrôle la réception des données en effectuant des appels au canal. Les quatre possibilités sont présentées sur la figure 2.4. Figure 2.4 : Les modèles de communication du service d évènement (d après [Schmidt et al. 97]) a) modèle push : les fournisseurs initient le transfert. Le canal joue le rôle de notificateur. b) modèle pull : les consommateurs initient le transfert. Le canal joue le rôle de procureur. c) modèle hybride push/pull : les producteurs et les consommateurs sont actifs. Le canal joue le rôle de file. d) modèle hybride pull/push : les producteurs et les consommateurs sont passifs. Le canal est actif et joue le rôle d agent intelligent. L extensibilité de l architecture peut être réalisée en divisant un canal d évènements en 74

91 Les espaces partagés deux canaux. Ainsi, l un des canaux devient le producteur de l autre. Un des problèmes du service d évènement est que le consommateur ne peut pas connaître l émetteur de l évènement. Le service de notification de CORBA Une extension du service d évènements de CORBA a été apportée par le service de notification (CosNotification). Les nouvelles fonctionnalités apportées par cette extension sont : La structuration des évènements : en plus des types de base de CORBA, il est possible de définir des types complexes, Le filtrage : les clients peuvent spécifier exactement quels évènements les intéressent. Un langage de contraintes permet de spécifier au mieux les besoins, L intéressement : les évènements non demandés ne sont pas transmis sur le canal, La Qualité de Service : des propriétés de qualité de service peuvent être définies sur le canal. La dernière extension est particulièrement intéressante puisqu elle prend en compte les besoins des applications contraintes en terme de temps. Les propriétés disponibles sont la fiabilité des évènements et de la connexion, la priorité des évènements, la définition d une date d expiration et d une date d attente d émission, un nombre maximal d évènements en attente par consommateur, une valeur maximum d agrégation des évènements et enfin un intervalle d agrégation. L agrégation est la possibilité de recevoir plusieurs évènements dans un même paquet, ce qui limite le nombre de paquets à envoyer Conclusion Les espaces partagés tels que Linda, JavaSpaces ou TSpaces offrent un découplage spatial (du nommage) et temporel. Le nommage est découplé puisqu il n y pas de connaissances mutuelles pas de contraintes fortes sur les connaissances nécessaires grâce aux templates ou pattern. Le temps est découplé puisque chaque participant peut déposer ou prendre des éléments à n importe quel moment. Il n y a pas d activités de synchronisation. Cependant, cette décorrélation du temps risque de poser un problème dans l établissement d un environnement distribué. La communication des éléments doit pouvoir s effectuer de manière très rapide (à la mode push), ce qui n est pas le cas de l espace partagé. D autres problèmes apparaissent tel que l action à effectuer lors de la modification d un attribut. Faut-il ajouter un nouveau tuple ou alors modifier l ancien. Dans ce dernier cas, on risque de perdre beaucoup de temps en retirant l élément, le modifiant et le réinsérant dans l espace partagé. Le service d évènement et de notification de CORBA ressemble à un espace partagé de part le fait que les éléments transitent par un dépôt. Toutefois, le mode push ou pull 75

92 Les architectures de communication peut complètement modifier le comportement (notification, file, procureur ou agent). Il offre beaucoup plus de possibilités que l espace partagé classique en offrant des propriétés de qualité de service, un intéressement et le filtrage. Les contraintes de temps sont prises en compte mais les propriétés sont définies pour le canal. Chaque type de données doit donc disposer de son propre canal afin d être transmis le plus judicieusement possible. 2.5 Le bus logiciel Avant d aborder les bus logiciels, nous allons d abord examiner le précurseur qu est le RPC 20. Partant d une idée que toute application distribuée doit ressembler à une application centralisée au niveau du code, les RPCs apportent une simplification dans la conception des applications distribuées. Le bus logiciel, souvent appelé middleware, bus objet ou ORB, est un paradigme permettant de créer un bus virtuel sur lequel différents objets peuvent dialoguer. Son implémentation est quelconque et ne dépend pas d une topologie en bus. À l inverse des espaces partagés, les échanges se font en point à point entre un client et un serveur. Des services supplémentaires permettent toutefois de recréer des échanges entre plusieurs entités. Polylith [Stotts et al. 94] [Purtilo 94], Microsoft DCOM 21 et CORBA sont les bus les plus connus. Bien que DCOM soit beaucoup utilisé sur les plates-formes Windows, il n offre pas du tout l hétérogénéité de Polylith ou de CORBA Remote Procedure Call (RPC) En 1984, Birrell et Nelson ont introduit une nouvelle façon d échanger des données entre deux hôtes [Birrel et al. 84]. Le dialogue en mode client/serveur s éloigne trop de la programmation de type centralisée, c est-à-dire que l écriture des programmes est très dépendante de sa localité (local ou distribué). L idée a été de reproduire l approche centralisée pour effectuer des échanges en réparti. Il s agit d effectuer un appel de procédure classique qui, au lieu d appeler une procédure locale, va effectuer un appel sur le réseau vers un autre hôte. La figure 2.5 présente les étapes dans l échange entre le client et le serveur. Ainsi, lorsque le client effectue un appel de fonction répartie, l appel est transmis au subrogé client qui se charge de récupérer les paramètres et de les assembler (marshalling). Le nom de la fonction (ou un numéro associé) et la liste des paramètres sont placés dans un paquet et 20 RPC : Remote Procedure Call. Le principe a été repris par Sun, RMI (RMI : Remote Method Invocation) qui est la version Java des RPC. 21 DCOM : Distributed Component Object Model 76

93 Le bus logiciel Subrogés Appel Assemblage Désassemblage Appel Client Retour Désassemblage Assemblage Retour Serveur Noyau Noyau Machine client Transfert des messages sur le réseau Machine serveur Figure 2.5 : Appels et messages des RPC [Tanenbaum 94] transmis sur le réseau. À la réception, le subrogé serveur désassemble (unmarshalling) le paquet, met en forme les paramètres et effectue l appel de fonction demandé. Les valeurs de retour sont ensuite retransmises jusqu au client en suivant le même cheminement. Pour permettre le fonctionnement des RPC quelle que soit l architecture matérielle (Little ou Big endian 22, complément à 1 ou à 2 23,... ) ou l encodage (ASCII, EBCDIC,... ) sur lesquels se repose le client ou le serveur, un encodage commun doit être défini. Ceci est réalisé par la couche présentation (couche 6 du modèle OSI) et la norme utilisée est XDR 24. Il est intéressant de voir comment le temps de traitement est réparti dans le système. La figure 2.6 issue de A. Tanenbaum [Tanenbaum 94] présente le résultat de l étude de Schroeder et Burrows [Schroeder et al. 90]. Elle a été effectuée sur une station multiprocesseur Firefly de DEC. Le résultat donné sur la figure est basé sur l échange d un RPC vide. Les différentes étapes sont indiquées en dessous du schéma et chaque barre correspond au temps passé dans une étape. On constate que le temps passé sur le réseau est relativement faible (environ 5 %) comparativement aux autres étapes. La même mesure a été effectuée avec un RPC de 1440 octets et donne environ 25 % du temps sur le réseau. Bien que ces mesures ne soient pas des valeurs à prendre telles quelles (le Firefly est un système multiprocesseurs), les rapports sont toutefois suffisamment explicites pour constater que la perte de temps dans le traitement des données est très importante, voire prépondérante, que ce soit à l émission ou à la réception. Ceci implique que malgré un réseau performant, les résultats peuvent être décevants si l on ne fait pas attention à la conception des différentes couches intervenant entre l application et le réseau sous-jacent. 22 petit ou grand boutiste : il s agit de la manière de stocker les octets dans la machine. Les processeurs Intel, par exemple, stockent les octets de poids fort à droite (little endian) tandis que les processeurs PowerPC stockent les octets de poids fort à gauche (big endian), c est-à-dire les adresses plus basses. 23 Le complément à 1 est une représentation des données où 0 a un codage 1111 tandis que dans le complément à 2, 1111 vaut 1. L avantage du complément à 1 est de faciliter les opérations de somme et de soustraction. 24 XDR : external Data Representation 77

94 Les architectures de communication 20% Subrogé client Noyau client Noyau serveur 15% 10% Ethernet Subrogé serveur 5% 0% Appel subrogé 2. Prendre le message en mémoire 3. Assemblage des paramètres 4. Remplissage des en-têtes 5. Calcul de la somme de contrôle UDP 6. Déroutement vers le noyau 7. Mise en file d attente du paquet avant transmission 8. Passer le paquet au contrôleur via le QBus 9. Temps de transmission sur Ethernet 10. Prendre le paquet dans le contrôleur 11. Routine d interruption 12. Calcul de la somme de contrôle UDP 13. Commutation vers le contexte utilisateur 14. Code du subrogé serveur Figure 2.6 : Étapes d exécution de RPC [Tanenbaum 94] RPC permet d exécuter une fonction ou procédure située dans un autre exécutable sur une machine distante. Il est standardisé par l Open Software sous le nom de Distributed Computing Environment (DCE) [Lockhart 94]. C est un premier pas vers l abstraction des sockets puisque la complexité des appels est masquée. Les systèmes client/serveur purs qui utilisent les RPC ne sont pas très extensibles pour diverses raisons. En effet, la communication est effectuée en envoyant un message et en attendant la réponse en retour. Le délai ajouté dans l attente devient coûteux CORBA Né des travaux de l OMG 25, un consortium composé d éditeurs et d industriels formé en 1989, CORBA est une norme définissant un bus logiciel pour objets distribués. Ce bus doit permettre l interopérabilité sur un très grand nombre de plates-formes. CORBA n est qu une norme ouverte où n importe quel éditeur de logiciels peut effectuer une implémentation [Acremann et al. 00]. C est une extension du mécanisme de RPC supportant les langages orientés objet et offrant des mécanismes plus flexibles pour la communication que les simples échanges requête/réponse des RPC. 25 OMG : Object Management Group 78

95 Le bus logiciel L architecture de CORBA L approche prise par CORBA est orientée composant. Cette approche permet de définir un certain nombre de services sous forme de composants pouvant ou non être implémentés. De plus, cette approche apporte un haut niveau d abstraction. Objets Applicatifs CORBAfacilities CORBAfacilities verticaux Santé Finance etc. CORBAfacilities horizontaux Interface Utilisateur Gestion Système Gestion Tâches Object Request Broker CORBAservices Figure 2.7 : Les différents services de CORBA Trois types de services sont définis (voir figure 2.7) : object services : il fournit les services pour les objets : services fondamentaux comme les services d évènement, de temps, d échange, de propriété et de cycle de vie, common facilities : il fournit les services pour les applications (e.g. mobile agent facility), domain interface : interfaces standards pour des domaines comme la finance, les télécommunications ou encore le domaine médical. L architecture des common facilities a deux types de composants : horizontal pour les composants pouvant être réutilisés dans différents domaines et l autre vertical permettant de standardiser la gestion des informations dans un domaine particulier. Les services objets proposés sont nombreux et visibles sur la figure 2.8. Ceux qui nous intéressent plus particulièrement sont : nommage : il permet d associer un nom à un objet de manière unique. évènement : il offre la possibilité à des fournisseurs d émettre des évènements qui seront reçus par les consommateurs. La communication est asynchrone (voir section 2.4.4). notification : c est une extension au service d évènement qui offre des possibilités plus grande surtout au niveau de la qualité de service associée aux évènements (voir section 94). persistance : ce service permet de sauvegarder des objets sur disque. propriétés : l IDL 26 définie pour un objet, déclare tous les attributs disponibles dans 26 IDL : Interface Definition Language 79

96 Les architectures de communication Applications distribuées Interfaces Métiers (Vertical CORBA Facilities) Utilitaires Communs (Horizontal CORBA Facilities) Objets applicatifs Télécom Interfaces Utilisateur Gestion Système Objets métiers Simulation Distribuée Santé Gestion d informations Gestion de tâches OBJECT REQUEST BROKER CORE Nommage Evènements Cycle de Vie Persistence Concurrence Transactions Sécurité Collections Vendeur Licences Associations Externalisation Propriétés Temps Interrogations Changements Figure 2.8 : Les différents services de CORBA (vue détaillée) l objet. Ce service offre la possibilité de rajouter des propriétés à un objet. Ces propriétés sont des attributs supplémentaires pour l objet. temps : ce service permet à l utilisateur d obtenir l heure courante avec une erreur estimée. En plus de cela, il permet d ordonner les évènements qui se produisent, de produire des évènements basés sur des horloges et des alarmes et de calculer l intervalle de temps entre deux évènements [OMG 02]. En dehors de ces services, le programmeur peut définir ses propres objets destinés à une application distribuée particulière. Ils pourront, en outre, être facilement réutilisés dans d autres applications Découplage langage/orb Afin de permettre la définition du rôle d un objet au sein de CORBA sans se préoccuper de son implémentation, un langage, l IDL, a été créé. Le langage IDL permet de définir l interface publique d un objet dans un langage indépendant sans jamais préciser de détails d implémentation. Ce n est qu ensuite, qu un mapping peut être réalisé vers d autres langages tels que le C++ ou Java. Ce langage permet de générer automatiquement la structure du client et du serveur ainsi que le talon et le squelette d interfaçage avec l ORB Le modèle client/serveur de CORBA Le modèle de bus de CORBA permet de mettre en interaction des clients et des serveurs d objets dans le but de former une application distribuée. Les objets peuvent être des services 80

97 Le bus logiciel fondamentaux (e.g. service de nommage), des fonctions communes ou encore des objets métiers définis spécifiquement pour l application. La figure 2.9 illustre les différents composants intervenant dans la mise en œuvre de la communication client/serveur et fournissant la portabilité, l interopérabilité ainsi que la transparence. Application Client Application Serveur DII Invocation dynamique SII Invocation statique Interface de l ORB SSI Squelette statique DSI Squelette dynamique Object Adapter Dépositaire d Interfaces Object Request Broker Core Dépositaire d Implémentations Figure 2.9 : Les composants de l échange client/serveur de CORBA Les rôles des différents composants sont : Client : cette entité obtient des références sur les objets et invoque les opérations associées. Ces objets peuvent être locaux ou distants mais leur accès est transparent. Servant : identifié de manière unique par une référence d objet, il est une instance de l interface IDL. ORB Core : il est responsable du transport des requêtes du client vers le serveur et vice-versa lors de la réponse. Il intègre aussi des protocoles de communication tels que IIOP 27 afin de communiquer avec les autres systèmes. Interface de l ORB : l implémentation de l interface peut être effectuée de différentes manières (librairies, n processus, mémoire partagée,... ). L interface de l ORB permet de découpler l application des détails d implémentation. Les opérations standards sont fournies (initialisation/arrêt de l ORB, conversions des références d objets et création de listes d arguments). SII 28 et SSI 29 : ils servent de liant entre respectivement le client et l ORB ainsi qu entre le serveur et l ORB. Le SII assemble les paramètres dans une représentation 27 IIOP : Internet Inter-ORB Protocol 28 SII : Static Invocation Interface ou souche (stub) 29 SSI : Static Skeleton Interface ou squelette (skeleton) 81

98 Les architectures de communication commune tandis que le SSI désassemble les données en paramètres compréhensibles pour le servant (marshalling, unmarshalling). DII 30 : cette interface permet au client de générer des requêtes à l exécution. Cette flexibilité est utile pour les applications ne connaissant pas l interface accédée lors de leur compilation. DSI 31 : c est l équivalent du DII pour le serveur. Il permet de délivrer des requêtes aux servants qui ne connaissent pas l interface IDL à laquelle ils sont associés lors de leur compilation. Object Adapter : ce composant permet, d associer un servant avec un objet, de démultiplexer les requêtes et de router les opérations aux servants. Le POA 32 est l adaptateur de la norme CORBA 2.2 et succède au BOA ou Basic Object Adapter dont la spécification n était pas suffisante pour rendre interopérable les BOA des différents ORB. Dépositaire d interfaces ou Interface Repository : il fournit les informations sur les interfaces IDL pendant l exécution. Ainsi, une application peut découvrir de nouveaux objets et invoquer des opérations sur ceux-ci. Dépositaire d implémentations ou Implementation Repository : ce référentiel contient les informations permettant de localiser et d activer des objets référencés dans le dépositaire d interfaces. Deux types de mises en œuvre permettent de mettre en relation un client avec un serveur. Premièrement, la méthode statique fournit la connexion entre le client et l ORB et, entre le serveur et l ORB. Ce sont le SII et le SSI qui permettent cette interconnexion. Le code du SII et le code du SSI sont générés automatiquement à partir du code IDL présenté plus loin. La seconde solution est de recourir à l appel dynamique des objets. Ceci permet d accéder soit à des objets dont l interface n est pas connue lors de la génération du client soit à des objets dont l interface peut évoluer comme dans le cas des scripts. Le référentiel Interface Repository est alors utilisé pour résoudre les appels car il contient entre autre les informations sur les types de paramètres. Cette transparence de la localisation des objets, en se servant de références sur des objets, permet de simplifier le développement des applications et fournit le maximum de flexibilité. De plus, elle rend possible la création de composants pouvant être dynamiquement insérés dans l application en cours d exécution. 30 DII : Dynamic Invocation Interface 31 DSI : Dynamic Skeleton Interface 32 POA : Portable Object Adapter 82

99 Le bus logiciel Interopérabilité à travers le réseau CORBA 1.0 avait défini un certain nombre de services mais n avait pas proposé de protocole de communication standard mis à part GIOP 33. Chacun a donc implémenté une version propriétaire de GIOP. Ceci a induit une incompatibilité entre les différents ORB du marché car ils ne pouvaient interopérer. C est pourquoi, la version 2.0 de CORBA a imposé l utilisation du protocole IIOP. IIOP doit permettre l interconnexion d un programme CORBA avec n importe quel autre programme CORBA quel que soit le langage, l ordinateur, le système d exploitation, le réseau ou l ORB (figure 2.10). Client Object Implement. STUB SKEL ORB ORB IIOP Figure 2.10 : Interopérabilité via IIOP CORBA est principalement utilisé pour effectuer des échanges en point à point et c est d ailleurs en mode client/serveur qu il est le plus utilisé. Pour permettre un échange en multipoint, par exemple pour le service de notification, le protocole doit être étendu. MIOP 34 [OMG 01] apporte une réponse car il fournit un mécanisme permettant de délivrer des requêtes GIOP à travers un échange multicast. Le transport spécifié par défaut est l IP multicast à travers UDP/IP (donc non fiable). Il s agit d une communication unidirectionnelle, ce qui signifie qu il ne peut y avoir de valeur de retour ou de paramètres de type out. S. L. Dit Picard propose, pour son environnement virtuel, un protocole RMIOP pour Reliable MIOP offrant une couche multicast fiable à CORBA [Dit Picard et al. 01]. Chaque message est découpé en paquets pour le transport. Pour assurer la réception, il utilise un protocole de type NACK (Negative ACKnowledgement) qui demande la réémission des paquets non reçus et est basé sur un identificateur. Par contre, ce type de protocole requiert un flot ininterrompu. Pour cela, le dernier paquet est spécial et définit le nombre de paquets émis. Ce dernier paquet est acquitté de manière traditionnelle. Cette approche impose donc la connaissance des autres utilisateurs connectés. Ceci est réalisé par le service de groupe. 33 GIOP : General Inter-ORB Protocol 34 MIOP : Unreliable Multicast Inter-ORB Protocol 83

100 Les architectures de communication L implémentation de ce protocole est réalisée via l ORB qui permet de développer de nouveaux protocoles à travers une structure appelée OCI (Open Communication Interface) CORBA temps réel Un groupe d intérêt spécial (SIG ou Special Interest Group) a été formé au sein de l OMG pour traiter les questions de temps réel pour CORBA. La future norme CORBA 3.0 a pour objectif d apporter, à travers ces changements, toutes les fonctionnalités requises pour supporter la qualité de service. Il sera possible de créer des implémentations de CORBA permettant le développement d applications temps réel [Schmidt et al. 00]. Les besoins en temps réel doivent être respectés à deux niveaux : au niveau de l environnement (système d exploitation et réseau) et au niveau du système exécutif de CORBA [Wolfe et al. 00]. Ceci implique donc le respect de certaines contraintes au niveau du sous-système de CORBA. Au niveau de l environnement, les besoins sont les suivants : horloges synchronisées : toutes les horloges doivent être synchronisées entre elles. délai borné de transmission des messages : le mécanisme de communication sousjacent doit pouvoir transmettre les messages en un temps borné. ordonnanceur de l OS avec des priorités : toutes les couches inférieures à CORBA doivent supporter l ordonnancement basé sur les priorités. Les files doivent également supporter les priorités. héritage de priorité : tous les composants pouvant synchroniser des tâches en les bloquant doivent implémenter l héritage de priorité. Sans le respect de ces contraintes, il n est pas possible de réaliser un middleware respectant les contraintes de qualité de service et donc de temps réel. C est ce qui a été réalisé dans TAO, un ORB temps réel compatible CORBA, qui présente des capacités d adaptation plus poussées que les autres ORB. L ORB TAO TAO 35@ est un ORB compatible CORBA orienté vers le temps réel et la performance. Il est basé sur la structure ACE 36 qui offre un support orienté objet pour les communications. De plus, cette structure supporte un grand nombre de plates-formes. Pour offrir le support nécessaire aux applications temps réel, TAO a enrichi CORBA en fournissant un langage IDL étendu, un support optimisé de la couche protocolaire (table de 35 TAO : The ACE ORB 36 ACE : Adaptive Communication Environment 84

101 Les critères de choix hachage, peu de recopies,... ). TAO a aussi défini son propre protocole RIOP 37. Il permet de transmettre les attributs caractérisant la qualité de service [Schmidt et al. 98]. [Wilson et al. 01] est une architecture basée sur TAO proposant une structure pour le développement d environnements virtuels. Il se propose de rajouter des services de haut niveau : rendu visuel, gestion des interactions client, gestion des objets de l environnement, gestion de l état de l environnement et gestion de la zone d intéressement. L architecture est présentée à la figure 2.11 Application (EVD) Rendu Visuel Gestionnaire Interactions Utilisateur Gestionnaire Objets Gestionnaire Etat de l env. Gestionnaire AOI Objets applicatifs Object Services Common Facilities ORB CORE Interfaces Domains CORBA Infrastructure de communication (GIOP/IIOP) Système d exploitation Matériel Figure 2.11 : L architecture de Nomad [Wilson et al. 01] L avantage de cette architecture réside dans la simplification du travail du programmeur. En effet, elle fournit à ce dernier des abstractions de haut niveau. Cette abstraction lui évite de manipuler les sous-niveaux et donc la complexité sous-jacente (communication, synchronisation, répartition de charge). Les auteurs ont effectués des tests afin de mesurer la latence du système et montrent que l utilisation de TAO comme infrastructure de communication est réalisable. 2.6 Les critères de choix Ce chapitre a présenté un grand nombre de paradigmes et d architectures les supportant. Ce chapitre a également montré l étendu des possibilités offertes au programmeur mais d autres paradigmes ont certainement été oubliés. La première partie a présenté la communication par messages à travers PVM et MPI. Originellement destinée à l écriture de programmes pour effectuer du calcul réparti, on 37 RIOP : Real-time Inter-ORB Protocol 85

102 Les architectures de communication s aperçoit que la communication par messages n est pas vraiment adaptée à notre application (pas de sémantique dans l API, pas temps réel,... ). Toutefois, des travaux ont été effectués dans ce sens comme CUMULVS. De plus, la version temps réel de MPI, MPI/RT, apporte des possibilités intéressantes au niveau du contrôle de la qualité de service au sein de l application. La mémoire partagée est un autre paradigme destiné aux applications parallèles. Bien que le concept soit très séduisant puisque le partage des données est implicitement effectué, l utilisation de ce type d architecture est très difficile à implémenter de manière efficace. Sa mise en œuvre pour le temps réel n est pas envisageable. D autres projets, comme dont nous n avons pas parlé, souffrent des mêmes problèmes. Les espaces partagés reprennent l idée de mémoire partagée de manière plus simple mais avec avec une implémentation explicite au sein de l application. Les fonctionnalités de ce paradigme limitent son utilisation à l échange d objets. Le service d évènements de CORBA et son successeur, le service de notification, offre un service équivalent en permettant l échange d évènements. Le dernier paradigme abordé dans ce chapitre concerne le bus logiciel. Le concept trouve ses origines dans les RPC. Il s agit de rendre transparent l appel d un serveur en faisant ressembler cet appel à un simple appel de méthode. Les RPC ont depuis été détrônés par CORBA. CORBA offre un support idéal pour le développement d applications distribués. Il offre tout un ensemble de services prêts à l emploi (temps, nommage, évènements,... ). La future version de CORBA, CORBA 3.0, apportera en plus la qualité de service et offrira des aspects temps réel. C est ce que propose déjà TAO. D ailleurs, plusieurs applications se servent de TAO pour mettre en œuvre leur infrastructure. Différents projets ont montré que la réalisation d une application temps réel est possible avec CORBA : Dit Picard [Dit Picard et al. 01] avec l ORB ORBACUS, Deriggi [Deriggi Jr. et al. 99] avec l ORB ORBIX et Wilson [Wilson et al. 01] avec l ORB TAO. 38 MOSIX : Multicomputer Operating System for UnIX. Cette solution permet de transférer des processus sur différents nœuds, d effectuer le traitement de manière distante et de rapatrier certains appels systèmes s ils ne peuvent pas être résolus à distance. Les échanges entre maître et esclaves afin de résoudre les appels systèmes ajoutent une latence importante, ce qui rend impossible la mise en œuvre d une application temps réel. 86

103 Conclusion Dans cette seconde partie, nous avons présenté le réseau de communication ainsi que les paradigmes utilisés pour simplifier la conception des applications. Dans le premier chapitre, nous avons exposé les différentes caractéristiques des réseaux permettant de les classer. La bande passante, la latence et la fiabilité sont les trois points importants retenus dans notre problématique. En effet, les applications temps réel sont généralement des applications avec des volumes importants de données à échanger. Certaines de ces données nécessitent des délais de transmission relativement courts afin que l immersion de l utilisateur reste fidèle à la réalité. Enfin, les évènements sont des données dont la perte risque d altérer la consistance de la base de données locale. La fiabilité joue un rôle prépondérant dans ce type de donnée. Chaque type de réseau (Ethernet, ATM, etc.) essaie de remplir ces rôles de manière plus ou moins efficace. La qualité de service offerte permet de garantir des caractéristiques sur les données pendant toute la communication et, la diffusion optimise l utilisation de la bande passante pour couvrir le maximum d hôtes destinataires à travers un seul envoi de message. Indispensables, ces protocoles sont à la base des échanges sur le réseau. Cependant, de nouveaux protocoles venant se positionner au dessus des protocoles usuels proposent d améliorer les échanges de données. Ces derniers sont beaucoup plus proche de l application cible, ce qui permet une meilleure connaissance sémantique des données échangées et donc une adaptabilité plus grande. VRTP, DWTP ou encore ISTP proposent des protocoles prêts à l emploi et adaptés aux différents types de données à échanger comme nous l avons constaté à la section 1.2. En terme de programmation, utiliser directement les protocoles de communication à travers des sockets n est pas très aisé. Ceci complique à la fois le code à créer et les algorithmes pour effectuer les synchronisations, gérer les inter-blocages, etc. En conséquence, nous avons étudié les différents paradigmes, les architectures logicielles permettant de répondre à ce besoin. 87

104 Conclusion Les trois paradigmes classiques sont la communication par messages, la communication par mémoire partagée et les espaces partagés. Le premier effectue des échanges en point à point en échangeant des messages. La mémoire partagée est une zone mémoire accessible par tous les hôtes qui peuvent extraire ou modifier des données. Le troisième paradigme, l espace partagé est un modèle hybride entre les deux premiers. Ils offrent des réponses simples au problème d échange de données. Malheureusement trop orientées vers la simulation analytique, ces solutions n offrent pas de solutions pour les applications temps réel. Ceci est en train d évoluer comme nous l avons constaté avec MPI/RT. Le bus logiciel, proposé en 1984, offre un style de programmation classique permettant l appel de procédures à distance (RPC). CORBA est devenu l architecture de référence des bus logiciels et a évolué dans de nombreux domaines d application. Cependant, comme toutes les architectures, CORBA n offrait pas de fonctionnalités spécifiques pour le développement d applications temps réel. Ce n est plus le cas depuis que CORBA 3.0 a été spécifié. Ce dernier offre des perspectives très intéressantes tant au niveau conceptuel qu au niveau de la programmation. Très modulaire, orienté objet et offrant des services horizontaux et verticaux, CORBA a déjà montré ses capacités dans des projets temps réel qui ne pourront que s améliorer avec les nouvelles spécifications. Cependant, cette partie n a présenté que des outils génériques pour le développement d applications distribuées. En conséquence, nous allons étudier, dans la partie suivante, quelles sont les architectures disponibles pour le développement d applications temps réel pour la réalité virtuelle. 88

105 Partie III État de l art Les environnements virtuels distribués 89

106 État de l art Les environnements virtuels distribués 90

107 Introduction De nos jours, la diminution du coût des réseaux et l augmentation de leur débit rendent le travail coopératif possible. Ainsi, nous nous tournons de plus en plus vers une décentralisation de l État, de l entreprise et de bien d autres domaines d activité encore. On peut le démontrer en regardant le nombre croissant de télé-travailleurs. Selon une étude effectuée par France Télécom en mai , 1,8 % de la population française effectue du télétravail et cette proportion a subi une augmentation de 67 % entre 1997 et Ce chiffre est encore plus important dans d autres pays européens tels que l Allemagne (5,1 %), la Finlande (10 %), le Danemark (11,6 %) ainsi que les États-Unis avec 12,9 % de la population active. France Télécom connaît bien le problème puisque 5,6 % des employés travaillent à distance et d entre eux utilisent un outil de collecticiel 2. Comme le montrent les chiffres, cette tendance va se renforcer dans les années qui viennent pour diverses raisons raisons technologiques avec les réseaux qui évoluent dans leur capacité en bande passante (arrivée de l ADSL et des réseaux câblés), raisons sociales avec le développement des technologies de l information afin de réduire la fracture sociale. Les récentes évolutions technologiques ouvrent la porte à la virtualisation de l entreprise. Ces dernières en tirent profit économiquement et surtout les projets nécessitent de plus en plus le recours à des spécialistes. Les outils de coopération évitent aux spécialistes de se déplacer (coût en temps et en argent) et permet de confronter les idées et les choix techniques collecticiel : groupware 91

108 Introduction Le travail collaboratif (CSCW) Discipline très récente, le CSCW 3 ou groupware concerne les applications permettant à différents utilisateurs de partager des données. En 1988, Johansen [Johansen 88] propose la définition du groupware suivante : groupware : des assistances informatisées conçues pour des groupes de travail L objectif est donc très simple. On regroupe sous ce nom toutes les applications destinées à faciliter ou plutôt à permettre le travail de groupe. On retrouve dans cette catégorie les whiteboards 4, les meeting places 5, les dossiers partagés, etc. Parmi les produits commerciaux, on peut citer Lotus Domino (anciennement Lotus Notes) qui est certainement le plus connu de tous. Dans cette définition, peu de contraintes sont indiquées. Toutefois, les applications de groupware peuvent être classées sous différentes catégories à travers les notions de temps et de lieu. Ainsi, C. Ellis classe les systèmes de CSCW suivant leur position dans le tableau de la figure 1 [Ellis et al. 91]. Même instant Instants différents Même lieu interaction face à face interaction asynchrone Lieux différents interaction synchrone dist. interaction async. dist. Figure 1 : Classification des systèmes de CSCW [Ellis et al. 91] Ce découpage, bien qu arbitraire, permet de classer les différentes applications suivant les objectifs à atteindre [Khoshafian et al. 98]. La première catégorie, mḙme lieu et mḙme instant, ne s éloigne pas des réunions habituelles d une entreprise. Seule l utilisation de la technologie marque une différence. Les outils peuvent être des tableaux blancs, des PCs à écrans partagés, etc. Le principal inconvénient de ce type de réunion est de privilégier l aspect personnel des participants. Ainsi, un bon orateur aura un poids décisif dans les réunions non pas par ses solutions mais par son éloquence. La seconde catégorie situe la coopération en un mḙme lieu mais à des instants différents. Ici, le lieu peut être vu comme un lieu virtuel (opposé à physique). C est-à-dire que les 3 CSCW : Computer-Supported Cooperative Work 4 C est un tableau blanc partagé par plusieurs utilisateurs qui peuvent dessiner et écrire dans cet espace. Chaque participant dispose généralement d une couleur différentes. Le tableau blanc permet également de visionner des images. 5 C est un lieu de rencontre virtuel où les utilisateurs peuvent dialoguer par visio-conférence. 92

109 Introduction données faisant l objet de la coopération sont situées en un même lieu électronique comme une base de données, un serveur d information électronique ou même une salle de réunion virtuelle. Ainsi, le logiciel Lotus Notes 6 se classe dans cette catégorie. La troisième catégorie, lieux différents et mḙme instant, regroupe les applications qui rassemblent à un même instant des utilisateurs dispersés géographiquement. Il s agit des outils de téléconférence, de visioconférence, des tableaux blancs électroniques. Enfin, la dernière catégorie, lieux différents et instants différents intègre les applications ne véhiculant que des flots de données entre utilisateurs. Nous nous en servons tous les jours à travers la messagerie, le fax, le workflow, etc. Figure 2 : CVW, exemple d outil de travail collaboratif La plupart des outils collaboratifs n intègrent pas ou très peu, les notions de temps réel. Par exemple, CVW 7@ est un environnement de travail collaboratif permettant de créer des équipes distribuées géographiquement. Cette application permet de présenter l ensemble des données de manière localisée dans un immeuble virtuel. On peut accéder aux différentes personnes participantes en les rejoignant dans leur bureau ou dans une salle de réunion. Les documents peuvent ensuite être échangés, modifiés et validés ensemble. L échange s effectue à l aide d applications dédiées comme le tableau blanc qui permet de visionner des images et de les annoter. Ce peut être une conférence audio ou vidéo ou 6 Aujourd hui racheté par IBM, la nouvelle version de Notes s appelle Lotus Domino ( Cette application représente un tiers du marché des collecticiels. 7 CVW : Collaborative Virtual Workspace. Ce travail a été réalisé, à l origine, par MITRE et est basé sur LambdaMOO, un moteur pour jeux de rôle en réseau orienté objet 93

110 Introduction encore un navigateur Internet. E. Swing montre que la barrière entre CSCW classique et environnement virtuel tend à s estomper. Il utilise CVW et y ajoute une interface 3D [Swing 00]. Des utilisateurs habituels de CVW ont évalué cette nouvelle interface. Elle apporte une immersion plus poussée de l utilisateur mais en retour, l utilisateur a besoin d un réalisme plus grand qu auparavant afin de ressentir un réel échange (par exemple, lors d une discussion, les deux avatars doivent se regarder face à face). Même instant et lieux différents Les environnements virtuels collaboratifs se placent dans la catégorie mḙme instant et lieux différents de la classification des CSCW car il s agit de faire collaborer des utilisateurs en même temps. Cette classification n est toutefois pas claire puisque l on peut considérer que les utilisateurs se trouvent au même endroit, virtuel bien sûr. Cette troisième partie du mémoire présente les architectures et plates-formes qui remplissent ces critères de situation et de temporalité. Ces architectures se placent au-dessus des architectures présentées dans la partie précédente et proposent des abstractions très fortes. En effet, l objectif de ces plates-formes est de développer des applications de simulation ou de réalité virtuelle or, les besoins de ces applications sont très spécifiques. Tout d abord, le chapitre suivant va décrire les deux architectures essentielles développées par l armée américaine, DIS et son successeur HLA, dans le cadre de simulations distribuées. L étude de ces deux architectures nous permet de prendre en compte les évolutions qui ont eu lieu entre ces deux architectures et pourquoi elles se sont produites. Le deuxième chapitre portera sur les plates-formes de réalité virtuelle distribuée et ses différentes technologies. Dans la première partie de ce second chapitre, nous allons étudier différentes techniques permettant de diminuer la bande passante, diminuer les problèmes de latence, résoudre des problèmes techniques de synchronisation, de gestion du temps, etc. La deuxième partie de ce second chapitre présentera une taxonomie des différentes platesformes et montrera quels sont les points importants à prendre en considération suivant le type d application de réalité virtuelle distribuée envisagé. 94

111 Chapitre 1 Les architectures pour la simulation distribuée 1.1 Introduction Historiquement, ce sont les simulations militaires qui se sont développées en premier. En effet, l évolution économique mondiale a provoqué une réduction des dépenses militaires pour favoriser d autres secteurs économiquement prometteurs. Afin de conserver un entraînement des troupes suffisant, l apparition des simulations distribuées a apporté de nombreux avantages tant économiques (coût, maintenance) qu écologiques. Ainsi, les deux architectures que nous allons présenter dans la deuxième et troisième section de ce chapitre sont d origine militaire. DIS, la première, s est développée pendant les années 80. L évolution des technologies et la recherche d économies supplémentaires a favorisé l évolution vers une seconde architecture, HLA. Nous effectuerons, par la suite, une comparaison entre HLA et CORBA pour montrer les différences entre ces deux approches. Bien que CORBA s oriente de plus en plus vers le temps réel en intégrant des notions de qualité de service dans les échanges, HLA a une orientation vers la simulation bien plus poussée. Ce dernier est donc plus adaptée pour ce type d application. 1.2 Historique Le besoin de simuler est apparu très tôt dans le domaine militaire. Ainsi, le système Link Trailer date de 1929 et permettait de s entraîner à voler en aveugle, en ne se servant que des instruments, sans affichage sur écran [U.S. Congress 94]. Bien sûr, à cette époque, on n envisageait pas encore d afficher des images. Pendant des années, les systèmes de 95

112 Les architectures pour la simulation distribuée simulation développés se sont cantonnés à une utilisation individuelle. Ce n est qu à partir de 1983 que l engouement pour les environnements en réseau s est réellement manifesté. En 1983, le projet SimNet 1 a débuté à Fort Knox (Kentucky, USA) sous les auspices de l ARPA 2. L objectif était de développer des simulateurs individuels (chars M1, hélicoptères AH-64,...) et de tester s il était viable de les mettre en réseau pour effectuer des entraînements en équipe. Développé et implémenté entre 1983 et 1990, ce projet a permis de définir un protocole de communication (types et formats des messages) à utiliser pour interopérer sur un réseau et partager le même environnement virtuel (champ de bataille) [U.S. Congress 94]. La première démonstration de SIMNET a eu lieu en décembre D autres démonstrations ont suivi et ont permis d affiner les protocoles. Ces travaux ont montré la viabilité du projet et, en mars 1993, ces recherches ont donné naissance au protocole standard DIS 3 que nous allons présenter dans la section 1.3. Pendant de nombreuses années, les simulateurs ont été développés afin de s interfacer avec le protocole DIS. Malgré son succès, DIS souffrait de nombreux manques d extensibilité et de réutilisation. Ainsi, l ARPA décida de développer une nouvelle architecture, HLA, afin de combler ce manque. 1.3 Distributed Interactive Simulation (DIS) Succédant à SIMNET et reprenant les idées et les technologies développées durant cette étude, DIS a été établi dans le but de définir une norme pour les simulations militaires. En effet, non imposé dans SIMNET, le format des paquets n était pas spécifié, ni documenté. Le protocole DIS devait reprendre SIMNET et lui apporter le formalisme nécessaire à son exploitation commerciale. Certains principes retenus pour DIS sont encore d actualité aujourd hui et représentent une avancée considérable dans la faisabilité de telles applications. Le premier choix considéré a été de modéliser le monde sous forme d objets entrant en interaction les uns avec les autres à travers des évènements L architecture DIS définit une architecture permettant de relier les simulations afin de créer un monde virtuel. Pour cela, des échanges de données s effectuent de manière asynchrone et permettent 1 SimNet : SIMulator NETworking, développé par BBN, Bolt Beranek et Newman 2 maintenant appelé DARPA 3 Distributed Interactive Simulation Standard Protocols, IEEE

113 Distributed Interactive Simulation (DIS) Operational Architecture Framework Connectivity Communication Services Data Interchange Environment Representation Support Environment Verification Validation Algorithms Data Software Re Use Configuration Management Synthetic Environment Components Computer Generated Forces Human Interfaces Simulators Embedded Instrumented Ranges Exercise Organization & Management Scenario Description Evaluation Plans Performance Measurement Data Collection & Analysis After Action Review System Operation Figure 1.1 : Les différentes parties de l architecture de DIS de conserver un environnement synthétique consistant. La figure 1.1 présente les différentes parties de l architecture DIS. Elle se décompose en quatre grandes parties qui sont explicitées ci-après. Connectivité La connectivité concerne les mécanismes permettant l interconnexion entre les différentes applications de simulation. Elle considère que les différentes simulations doivent disposer d une représentation commune de l environnement fixe. Les informations des activités dynamiques ainsi que les évènements sont échangés à travers des données standardisées appelées PDU 4. Quatre points précis sont étudiés pour développer ces standards : les protocoles d échange de données, l architecture de communication, la sécurité et la représentation de l environnement. Les protocoles d échange de données. Il s agit d identifier les données à échanger et de définir toutes les conditions de leurs utilisations, soit : Identification des données, Définition d une représentation commune, Formatage des données dans un PDU, Détermination des circonstances d utilisation (instants, fréquence,... ), Traitements devant être effectués lors de la réception, Algorithmes associés devant être implémentés (e.g. dead reckoning). 4 PDU : Protocol Data Unit 97

114 Les architectures pour la simulation distribuée La norme IEEE Standard for Distributed Interactive Simulation Application Protocols décrit les protocoles en détail. L architecture de communication. Les PDU sont indépendants du réseau sous-jacent. L architecture permet d identifier et de définir le média, les types de services et les protocoles permettant d atteindre les objectifs requis. Les points suivants sont abordés : Adressage (unicast, multicast, broadcast), Fiabilité (best-effort ou fiable), Choix des protocoles de communication, Besoins en bande passante, Contraintes techniques (e.g. taille maximale d un PDU), Contraintes en terme de performance (e.g. latence). La norme IEEE Standard for Distributed Interactive Simulation Communication Architecture Requirements décrit l architecture en détail. La sécurité. Elle permet de protéger les données sensibles. Il peut s agir de technologies propriétaires ou de données militaires sensibles. Les quatre points abordés sont : Politique de sécurité, Méthodologie de sécurisation, Accréditation, Performance en terme de sécurité. La représentation de l environnement. Le dernier point modélise l environnement. Il s agit d intégrer la représentation de la terre, de l air et de la mer. Il s agit de bien aborder les points de fidélité de la représentation de l environnement et la corrélation entre les représentations. Cette partie examine les points suivants : Identifier les sources de données, Définir un standard, Créer des bases de données, Distribuer les données vers les simulateurs, Identifier les besoins. Composants de l environnement synthétique Les simulations militaires permettent l entraînement des troupes mais la présence de nombreux objets de la simulation doivent être gérés par les ordinateurs afin de représenter un nombre suffisant de combattants. Ces entités gérées informatiquement sont appelées SAF 5 ou plus récemment CGF 6. Il s agit de modéliser correctement un comportement autonome tout en restant sous le contrôle d un opérateur qui définit des ordres et des actions à produire. 5 SAF : Semi-Automated Forces 6 CGF : Computer Generated Forces 98

115 Distributed Interactive Simulation (DIS) Organisation, gestion et support de l exercice de simulation Dans le but de permettre une parfaite interopérabilité des simulateurs, les pratiques et procédures d organisation doivent être standardisées. Les trois points importants sont : Gestion du système. Ceci concerne la planification, la mise en place et la surveillance de l exercice. Mesure des performances. La collecte et l analyse des mesures permet de rendre compte du comportement des participants ainsi que de leurs améliorations. Il s agit de déterminer les types de mesures, la manière de les collecter, de les présenter et de les analyser. Environnement support. Il s agit de définir un processus de vérification, validation et accréditation 7 des simulations Protocol Data Unit (PDU) Basé sur une architecture échangeant des évènements, le PDU représente le cœur de l architecture 8. DIS a défini 27 PDU (figure 1.2) différents dont seulement quatre (état de l entité, tir, détonation et collision) sont utilisés par les nœuds pour interagir. En fait, la plupart des simulations DIS n implémentent que ces quatre PDU et ne supportent pas les autres PDU [Singhal et al. 99]. Comme on peut le voir en regardant les objectifs des différents PDU, DIS a été défini dans un but purement militaire (tir, détonation, ravitaillement,... ). Cette orientation représente un inconvénient majeur dans son acceptation dans d autres domaines d application. Une démonstration lors de la conférence I/ITSEC 9 a montré la répartition du trafic suivante [Pullen et al. 95] : 96 % PDU état de l entité 4 % Autres PDU 4 % tir 4 % détonation 1 % collision 7 VV&A : Verification, validation and accreditation 8 Cette architecture fait confiance aux différents simulateurs participants. Ainsi, comme le cite [Singhal et al. 99] : Le PDU Detonation peut ḙtre mal utilisé afin de provoquer la mort en masse des autres joueurs de l environnement virtuel. Un tel exemple était le programme anecdotique Mega-Death qui a collecté les positions des joueurs ennemis et a ensuite émis, en mḙme temps, les PDU Detonation de munitions proches de chaque ennemi. Un tel scénario ne peut ḙtre fait qu une seule fois, tard le soir, et jamais lorsque le commandant de l armée est présent!. 9 I/ITSEC : Interservice/Industry Training, Simulation, and Education Conference 99

116 Les architectures pour la simulation distribuée Nom du PDU Acknowledge Action Request Action Response Collision Comment Create Entity Data Data Query Designator Detonation Electromagnetic Emission Entity State Event Report Fire Receiver Remove Entity Repair Complete Repair Response Resupply Cancel Resupply Offer Resupply Received Service Request Set Data Signal Start/Resume Stop/Freeze Transmitter Explication acquitte la réception des PDU Start/Resume, Stop/Freeze, Create Entity, et Remove Entity envoie une requête à une entité pour effectuer une action acquitte la réception d un PDU Action Request lorsqu une entité détecte une collision avec une autre entité, elle produit ce PDU permet de transmettre un message arbitraire l information de la création d une nouvelle entité est effectuée avec ce PDU la réponse d un PDU Data Query ou Set Data est transmise avec ce PDU effectue une requête à une entité pour obtenir des données opération désignant une opération à une entité transmet la détonation ou l impact d une munition véhicule l information sur l émission électronique et la contre-mesure comporte les informations concernant l état d une entité particulière permet à une entité gérée de rapporter l occurrence d un évènement important au gestionnaire de la simulation (dommage, mort, essence épuisée) communique le tir d une arme communique l état du récepteur (éteint, allumé et/ou en réception) informe du retrait d une entité de la simulation permet à l entité de réparation de notifier à l émetteur d un Service Request que la réparation est terminée acquitte la réception d un message Repair Complete annule un service, soit par le récepteur, soit par le fournisseur l offre de ravitaillement est transmise par ce PDU la réception d un ravitaillement est transmise par ce PDU permet d effectuer une requête pour obtenir de la logistique initialise ou change l information de l état interne transmet la voix, le son et d autres données communique le départ et la reprise d un exercice communique l arrêt et le gel d une entité ou de l exercice fournit des informations détaillées sur un émetteur radio Figure 1.2 : La liste des PDU du protocole DIS 100

117 Distributed Interactive Simulation (DIS) 0 % logistique 0 % gestion de la simulation 39 % émission 50 % transmetteur 0 % signal 2 % acoustique 1 % stealth 10 0 % autres Le PDU Entity State décrit en détail à la figure 1.3 page 102, fournit les changements en position, en orientation et en vitesse d une entité. L émission d un tel PDU est à la charge du simulateur qui doit réémettre un nouveau message lorsque les valeurs de positionnement, d orientation et de vitesse ne sont plus suffisamment exactes pour prédire correctement son déplacement à l aide du dead reckoning 11. De plus, ce PDU doit être réémis, au minimum, toutes les cinq secondes (ce qu on appelle le heartbeat ou battement de cœur). Majoritaire dans les communications, ce PDU est cependant très volumineux et contient de nombreuses données qui ne changent pas ou très peu. Cette information ne nécessiterait d être émise qu une seule fois. De plus, les coordonnées de positionnement des entités sont transmises sur 64 bits. Une telle résolution permet une précision inférieure au nanomètre! La technologie et ses limites DIS est basé sur le paradigme de passage par messages. Tous les échanges entre hôtes, l état des entités et les évènements, ne s effectuent que par messages. Il permet de relier des équipements faisant intervenir l homme (appelé human-in-the-loop ou HITL) et doit donc répondre à certaines exigences dites temps réel. Temps réel signifie que le délai de transmission doit être très court. En effet, des études ont montré que l homme commence à percevoir un retard à partir de 100 ms. Ainsi, la valeur limite de 100 ms a été définie pour les interactions fortement couplées et la valeur limite de 300 ms pour les interactions faiblement couplées [Pullen et al. 95]. Afin de rendre ces objets parfaitement autonomes, la décision a été prise de diffuser tous les évènements. Ainsi, tous les objets intéressés reçoivent l information et l émetteur n a pas besoin de conserver une trace de tous les destinataires intéressés par ces évènements. La détermination de l intérêt de l information est laissée au destinataire. Du fait de la méconnaissance des autres objets présents dans la simulation, l émetteur n est pas capable de savoir à quel point les destinataires sont intéressés. L émetteur doit donc transmettre l information complète. Seul le destinataire connaît ses capacités courantes et 10 stealth ou magic carpet correspond à un simulateur observateur de la scène. 11 Voir section du chapitre 2 de cette partie. 101

118 Les architectures pour la simulation distribuée Field Size (bits) Entity State PDU Fields Protocol Version 8-bit enumeration Exercise ID 8-bit unsigned integer 96 PDU Type 8-bit enumeration PDU Protocol Family 8-bit enumeration Header Time Stamp 32-bit unsigned integer Length 16-bit unsigned integer Padding 16 bit unused Site 16-bit unsigned integer 48 Entity ID Application 16-bit unsigned integer Entity 16-bit unsigned integer 8 Force ID 8-bit enumeration 8 # of Articulation Parameters (n) 8-bit unsigned integer Entity Kind 8-bit enumeration Domain 8-bit enumeration Country 16-bit enumeration 64 Entity Type Category 8-bit enumeration Subcategory 8-bit enumeration Specific 8-bit enumeration Extra 8-bit enumeration Entity Kind 8-bit enumeration Domain 8-bit enumeration 64 Country 16-bit enumeration Alternative Category 8-bit enumeration Entity Type Subcategory 8-bit enumeration Specific 8-bit enumeration Extra 8-bit enumeration Entity X-Component 32-bit floating point 96 Linear Y-Component 32-bit floating point Velocity Z-Component 32-bit floating point 192 X-Component 64-bit floating point Entity Y-Component 64-bit floating point Location Z-Component 64-bit floating point 96 Psi 32-bit floating point Entity Theta 32-bit floating point Orientation Phi 32-bit floating point 32 Entity Appearence 32-bit record of enumerations 320 Dead Reckoning algorithm 8-bit enumeration Dead Other Parameters 120 bits unused Reckoning Entity Linear Acceleration 3x32-bit floating point Parameters Entity Angular Velocity 3x32-bit floating point 96 Entity Character set 8-bit enumeration Marking String Record 11 8-bit unsigned integers 32 Capabilities 32 Boolean fields Parameter Type Designator 8-bit enumeration n*128 Change 8-bit unsigned integer Articulation ID-attached to 16-bit unsigned integer Parameters Parameter type 32-bit parameter type record Parameter value 64-bit Taille Totale Entity State PDU = ( n) bits, avec n = nombre de paramètres d articulations Figure 1.3 : Le PDU Entity State [Hofer et al. 95] 102

119 High Level Architecture (HLA) peut déterminer s il veut connaître l information, avec quelle dégradation il la reçoit et si cet évènement l affecte. Ces choix techniques génèrent beaucoup de trafic réseau. Afin de limiter les échanges, seul les changements de comportement des entités sont transmis. L utilisation du dead reckoning permet de réduire les échanges. Cependant, comme nous l avons fait remarquer précédemment, le PDU Entity State est le PDU principalement échangé. Il est très volumineux et seulement une partie de celui-ci varie et est utilisé. Un autre inconvénient de cette architecture est son orientation vers le militaire. L utilisation de cette technologie dans d autres domaines a restreint le nombre de PDU utilisables. Cependant, son utilisation s est étendue dans d autres domaines comme la médecine, les loisirs ou l entraînement au contrôle du trafic aérien Conclusion Le standard DIS fournit des spécifications pour les couches session, présentation et application (5 à 7 du modèle OSI). Basée sur un modèle asynchrone, la synchronisation entre les simulateurs est minimale et améliore l extensibilité de la simulation. Orienté messages, l échange se fait sans serveur et chaque hôte doit donc maintenir une description complète et locale de l environnement, des acteurs et des entités ainsi que leurs déplacements, afin d effectuer son propre rendu du monde simulé. Le standard DIS a apporté de nombreuses innovations technologiques telles que le dead reckoning, le heartbeat, un modèle totalement décentralisé et d autres aspects. Malheureusement, la spécification du protocole s est limitée au domaine militaire, ce qui contraint son utilisation. Malgré tout, d autres domaines ont réussi à s en servir avec plus ou moins de succès. Il est clair que normaliser un format de données est nécessaire pour permettre l interopérabilité. Cependant, ce format est spécifique au domaine applicatif. Il est donc nécessaire de proposer une architecture commune, indépendante du format des messages et apportant une base nécessaire à l interaction entre différents processus. Cette réflexion a conduit au développement d une nouvelle architecture, appelée HLA, que nous présentons dans la section suivante. 1.4 High Level Architecture Parallèlement au projet DIS, des travaux de recherche sont menés par l armée pour définir un autre protocole appelé ALSP 12@ [Weatherly et al. 96]. En effet, l armée mène deux types 12 ALSP : Aggregated Level Simulation Protocol 103

120 Les architectures pour la simulation distribuée Objectif 1 Objectif 2 Objectif 3 Objectif 4 Objectif 5 Objectif 6 Développer une infrastructure technique commune pour la M&S Fournir une représentation actuelle et correcte de l environnement naturel Fournir des représentations correctes des systèmes Fournir des représentations correctes du comportement humain Établir une infrastructure de M&S pour que les besoins des utilisateurs correspondent aux développements Partager les bénéfices de la M&S Sous objectifs Sous objectifs Sous objectifs Sous objectifs Sous objectifs 1 1 Architecture de simulation haut niveau 1 2 Modèles conceptuels de l espace de mission 1 3 Standardisation des données 2 1 Terrain 2 2 Océans 2 3 Atmosphère 2 4 Espace 4 1 Individuels 4 2 Groupes et organisations 5 1 Systèmes de domaines 5 2 VV&A 5 3 Entrepôts 5 4 Communications 5 5 Centre de coordination 6 1 Quantifier l impact 6 2 Éducation 6 3 Double usage Figure 1.4 : La stratégie d ensemble M&S du DMSO [Department of Defense 95] de simulations. D un côté, les simulations appelées constructive permettent d effectuer des simulations analytiques telles que l étude de scénarios. D un autre côté, les simulations dites live permettent de simuler des combats où l homme peut participer à la simulation comme c est le cas pour les simulations basées sur DIS. ALSP était donc un projet à part pour effectuer des simulations analytiques. L architecture employée dans ce projet était suffisamment intéressante pour tenter de fusionner ALSP et DIS. Ce projet a abouti à HLA 13 et a été choisi dans la stratégie du DMSO 14 pour le développement de nouvelles simulations. Cette stratégie est définie en six points (voir figure 1.4) : 1. Développer une structure technique commune à toutes les applications de simulation pour l armée. Il s agit de développer une architecture générique ainsi qu un format de données standardisé afin de permettre l interopérabilité, 2. Fournir une représentation de l environnement que ce soit sur terre, en mer, dans le ciel ou sous les eaux, 3. Donner une représentation des systèmes militaires intervenants dans la simulation, 4. Obtenir une représentation du comportement humain individuel ou en groupe afin de simuler les combattants ennemis, 5. Établir une infrastructure permettant de remplir les besoins des développeurs et utilisateurs. C est-à-dire, définir des entrepôts de modèles informatiques, des centres de coordination pour l établissement de simulations, un processus de vérification et de validation, etc, 6. Partager les bénéfices de la modélisation et la simulation en quantifiant l impact économique, écologique et autre, en appliquant la technologie dans le domaine civil. Premier sous-objectif de la stratégie du DMSO, HLA doit répondre au besoin suivant [Department of Defense 95] : Un modèle ou un système de simulation unique ne peut satisfaire tous les usages 13 HLA : High Level Architecture 14 DMSO : Defense Modeling and Simulation Office 104

121 High Level Architecture (HLA) et utilisateurs. Pour faciliter l interopérabilité des modèles et simulations ainsi que pour permettre la réutilisation de leurs composantes, le DoD requiert une architecture de haut niveau à laquelle les développements doivent se conformer.[... ] L architecture ne spécifiera que la définition minimum nécessaire à faciliter l interopérabilité et la réutilisabilité. Ceci a conduit à la définition de trois parties : Les règles de HLA. Ce sont les règles que toutes simulations, développées avec ce standard, doivent respecter. La spécification de l interface HLA [Department of Defense 98a]. Les spécifications définissent les différents services standards ainsi que les interfaces que doivent offrir l infrastructure. Quatre langages sont supportés : IDL CORBA, C++, Ada 95 et Java. Le modèle objet générique (OMT 15 ) de HLA [Department of Defense 98b]. L OMT permet de documenter les attributs et les interactions des modèles participant à la simulation globale. Il définit un format commun permettant leur interopérabilité. Depuis septembre 1996, HLA a été adopté comme standard pour les simulations du DoD. L OMG l a adopté comme Facility for Distributed Simulation Systems 1.0 en novembre 1998 et l IEEE l a adopté comme Standard 1516 for Modeling and Simulation (M&S). L AMG 16 est responsable de l évolution de HLA. L AMG est un sous-groupe de l EXCIMS 17. L EXCIMS est chargé d apporter conseils et assistance sur les problèmes de modélisation et simulation (M&S, Modeling and Simulation) [Kuhl et al. 99] L architecture HLA est une architecture permettant de fédérer plusieurs simulateurs au sein de la même simulation globale qu on appelle fédération. La figure 1.5 présente un exemple de fédération dans laquelle trois simulateurs participent. Ces entités participantes s appellent des fédérés. Un fédéré peut représenter une entité (une voiture), plusieurs entités (toutes les voitures d une ville) ou n être qu une partie d une entité (vue gauche d un cockpit d avion). Certains fédérés ne servent qu à observer le déroulement de la simulation et sont appelés stealth ou magic carpet. Le dernier élément constituant la fédération est le RTI 18. C est l élément central de la simulation. Il fournit tous les services nécessaires au bon fonctionnement de l exécution de la fédération. Il permet de faire communiquer les différents fédérés entre eux car les fédérés n ont aucune autre connaissance qu eux-mêmes et le RTI. 15 OMT : Object Model Template 16 AMG : Architecture Management Group 17 EXCIMS : EXecutive CouncIl for Modeling and Simulation 18 RTI : Run-Time Infrastructure 105

122 Les architectures pour la simulation distribuée fédéré 3 RTI RTI ambassador HLA/RTI fédéré 2 federate ambassador fédéré 1 fédération fédéré Figure 1.5 : L architecture HLA La communication se décompose en deux parties : le RTIambassador et le FederateAmbassador. Le RTIambassador est une interface permettant au fédéré d envoyer des messages au RTI (demandes ou transmissions d informations). Son API est entièrement définie dans différents langages et une spécification (IS 19 [Department of Defense 98a]) décrit comment l implémentation doit se comporter lorsqu un message est reçu. Le FederateAmbassador dispose d une interface définie et normalisée. Spécifique à l application, son implémentation est à la charge du développeur du fédéré Les services du RTI Afin de permettre la meilleure interopérabilité et réutilisabilité des composants de simulation développés, six services de gestion ont été définis : fédération. Ce service permet la création, le contrôle, la modification et la destruction de l exécution d une simulation, déclaration. Permet aux différents simulateurs de déclarer leurs intentions de générer de l information ou leur intéressement concernant certaines informations, objets. Il permet d enregistrer, de modifier et de supprimer des instances d objets et d interactions, propriété. Permet de connaître et de modifier la propriété des attributs des instances d objets, temps. Ce service définit la politique choisie pour gérer le temps (contraint, régulateur) ainsi que la négociation pour faire avancer le temps local (évènements, pas de temps), 19 IS : Interface Specification 106

123 High Level Architecture (HLA) Rien Destroy Federation Execution Create Federation Execution La fédération existe Resign Federation Execution (dernier) Join Federation Execution (premier) Les fédérés supportés Join Federation Execution Resign Federation Execution Figure 1.6 : Le cycle de vie d une simulation HLA distribution des données. Ce service permet un contrôle plus fin des échanges que le service de déclaration. Il permet de publier/souscrire à des objets suivant certaines valeurs de ses attributs. Les trois premiers services sont détaillés ci-après. Les trois derniers services seront détaillés dans des sections séparées (distribution des données à la section 2.2.2, propriété à la section et temps à la section 2.2.4) où ils seront expliqués de manière générale et de manière spécifique à HLA Gestion de la fédération Ce service gère la création, le contrôle, la modification et la suppression d une fédération. Il offre les mécanismes de base pour gérer les différents fédérés intervenant dans la simulation. Le cycle de vie d une fédération est présenté sur la figure 1.6. Le premier fédéré doit créer la fédération. À partir de là, chaque fédéré souhaitant participer à cette fédération s enregistre en invoquant le service Join Federation Execution. De la même manière, à la fin de l exécution, les différents fédérés se retirent de la simulation en invoquant Resign Federation Execution et le dernier fédéré peut détruire la fédération. C est un service fondamental car les autres services de HLA ne peuvent être utilisés par un fédéré que lorsque ce dernier a rejoint une fédération. De plus, des fonctions primaires telles que la synchronisation, la sauvegarde ou la restauration de la fédération peuvent être invoquées par ce service. 107

124 Les architectures pour la simulation distribuée e g h Le fédéré 1 publie Y avec les attributs suivants : {b,e,f,g,h} Le fédéré 2 publie et souscrit à X avec les attributs suivants : {a,b,c,d,e} a b d c f X Y Figure 1.7 : Publication des objets Gestion de la déclaration : publication/souscription Ce service fournit les moyens aux fédérés de produire (publish) et/ou de consommer (subscribe) des données. Le RTI se sert des déclarations faites par les fédérés pour gérer les flots de données. Il peut demander à un fédéré de publier des mises à jour concernant certaines instances d objets car d autres fédérés sont intéressés. À l inverse, il peut demander à un fédéré d arrêter d envoyer des mises à jour car il n y a plus aucun intéressé (consommateur). La figure 1.7 montre comment la déclaration va gérer les échanges. La classe d objet Y est une descendante de la classe d objet X. La classe d objet Y contient les attributs {a, b, c, d, e, f, g, h}. Un fédéré peut créer des instances de la classe d objet Y sans spécifier tous les attributs associés à Y. Ici, le fédéré 1 indique qu il peut publier les attributs {b, e, f, g, h} de la classe d objet Y. De la même manière, la classe d objet X contient les attributs {a, b, c, d, e, f, g}. Le fédéré 2 publie et souscrit à X avec les attributs {a, b, c, d, e}. Le RTI va donc promouvoir les instances de la classe d objet Y de telle manière que le fédéré 2 voit les instances comme des instances de X. Comme le fédéré 2 est souscripteur, le RTI va demander au fédéré 1 d enregistrer ses instances. Publication Chaque fédéré doit publier les classes d objets et d interactions qu il prévoit de produire. Il peut ainsi ne publier qu un sous-ensemble des attributs d une classe. De toute façon, il doit dire de manière explicite tous les attributs qu il publie. Un attribut spécifique privilegetodelete peut être inclus. Il donne la propriété de l instance au fédéré qui l a créée. Plus tard, il peut céder cette propriété à un autre fédéré via les fonctions de gestion de la propriété. Dans ce cas, il perd la possibilité de détruire l instance. 108

125 High Level Architecture (HLA) Souscription Les fédérés désirant obtenir des informations concernant certaines classes doivent l indiquer de manière explicite. Pour les classes, ils font appel à subscribe Object Class Attributes. À partir de ce moment, le fédéré sera averti de toutes les créations d instances (de cette classe) qui se produisent dans la fédération. En ce qui concerne les interactions, les fédérés ne peuvent souscrire à un sous-ensemble de paramètres. Ils souscrivent obligatoirement à tous les paramètres (tout ou rien) Gestion des objets Cet ensemble de services permet la gestion de l enregistrement, la modification et la suppression des instances d objets ainsi que l envoi et la réception des interactions. Pour utiliser ce service, le fédéré doit, au préalable, avoir souscrit à ces différents objets via le service de déclaration ou le service de distribution des données. Un fédéré peut disposer de e entités dans son simulateur. Chaque entité peut être composée de i instances d objets. Et chaque objet dispose de a attributs mais un fédéré n est pas obligé de supporter tous les attributs d une classe. Nous avons donc trois niveaux de granularité dans un simulateur. Les objets composant la simulation sont répertoriés dans le FOM 20 et la relation entre les objets suit un processus d héritage comme présenté à la figure 1.8. La relation entre les objets est un héritage simple depuis la classe de base ObjectRoot. Ainsi, les deux classes d objet Airbus A320 et Mirage F4 héritent tous les deux de la classe Avion. En effet, les deux avions partagent des attributs communs (x coord, y coord et z coord). Avion x_coord y_coord z_coord Airbus_A320 nb_passagers Mirage_F4 nb_cartouches nb_missile Figure 1.8 : Spécialisation des classes d objets HLA 20 FOM : Federation Object Model 109

126 Les architectures pour la simulation distribuée Ce processus de fonctionnement simplifie grandement le développement des simulateurs. Un simulateur de radar doit être capable de repérer les avions passant dans une zone définie de la simulation. Il doit donc mettre à jour en permanence la position des avions. Pour cela, les autres fédérés simulant des avions doivent lui envoyer leurs coordonnées. Dans notre cas, la tâche est simplifiée puisque le simulateur n a besoin de connaître qu une seule classe, la classe Avion. Peu importe, le type d avion puisque le rôle du radar n est que d afficher sa position. Techniquement, le fédéré propriétaire (fédéré 1) d une instance de la classe Airbus A320 envoie une mise à jour de son instance au RTI. Le RTI connaît la relation entre les classes Avion et Airbus A320. Ainsi, si un fédéré 2 a souscrit à la classe Avion, le RTI extrait les trois paramètres de coordonnées (x coord, y coord, z coord) de l instance et les transmet au fédéré 2 (figure 1.9). envoi d une mise à jour d une instance de Airbus_A320 (x, y, z_coord, nb_passagers) traitement de la relation d héritage Transmission d une mise à jour d une instance de Avion (x, y, z_coord) fédéré 1 RTI fédéré 2 Figure 1.9 : Généralisation des attributs d une classe Une relation d héritage identique existe aussi pour les interactions Comparaison entre HLA et DIS Il y a de nombreuses similitudes entre DIS et HLA. Si l on regarde le cycle de vie d une simulation DIS et d une simulation HLA, on obtient le tableau de la figure Deux grandes différences ressortent de ce tableau. Premièrement, lorsque la valeur d un attribut a évolué, DIS réémet un ESPDU 21 qui contient tout l état de l entité tel que décrit à la section Dans HLA, le fédéré ne transmet au RTI que l attribut qui a été modifié via un appel (Update Attribute Values). Deuxièmement, DIS gère beaucoup d évènements de manière implicite. Si un simulateur reçoit un ESPDU d une entité inconnue alors il a découvert une nouvelle entité. Si il ne reçoit plus de mises à jour sur une entité (plus de ESPDU associé) alors l objet a disparu de la simulation et ainsi de suite. Dans HLA, tout est spécifié de manière explicite. Ainsi, le fédéré destinataire est prévenu de l existence (la création) d une nouvelle entité avant de recevoir une mise à jour de celle-ci. Lors de la destruction d une entité, le fédéré destructeur avertit le RTI qui, à son tour, avertit le fédéré destinataire. 21 ESPDU : Entity State PDU 110

127 High Level Architecture (HLA) Action DIS HLA Commentaires Créer un exercice Joindre l exercice Obtenir l ID d un objet Créer un objet Découvrir des objets Le char se déplace Le char déplace la tourelle Le char tire Suppression d un objet Quitter l exercice Terminer l exercice Définir (ou utiliser) un ID d exercice Écouter et envoyer des PDU comme convenu L application crée un ID unique Commencer à émettre des ESPDU Recevoir des ESPDU d entités inconnues envoyer un ESPDU envoyer un ESPDU envoyer un Fire PDU Arrêter d envoyer des ES- PDU Arrêter de recevoir et d envoyer Toutes les simulations s arrêtent Create Federation Execution Join Federation Execution Demander l ID au RTI Instancier un objet Instancier les objets découverts Update Attribute Values (position) Update Attribute Values (orientation de la tourelle) Send Interaction Delete Object Resign Federation Execution Destroy Federation Execution Implicite vs explicite Appel du RTI vers le fédéré Le RTI ne transmet que la valeur modifiée Le RTI ne transmet que la valeur modifiée Implicite vs Explicite Implicite vs Explicite Implicite vs Explicite Figure 1.10 : Comparaison du cycle de vie de HLA et DIS [Calvin et al. 95] Un dernier point à préciser est la grande différence qui rend HLA plus facilement exploitable dans d autres simulations. En effet, DIS est une norme qui spécifie principalement un ensemble de messages (PDU) spécifiques au domaine militaire. Cette orientation le rend peu indépendant. À l inverse, HLA définit un ensemble de services qui sont partagés par tous les fédérés. Ces services ne sont pas spécifiques à la simulation militaire mais sont des services communs 22 à toute simulation. Ainsi, chaque domaine peut spécifier la hiérarchie de classes d objet et d interaction, les attributs et les paramètres propres à leur domaine d applications sans avoir à modifier l architecture. Il y a donc bien une séparation entre l architecture et les données. 22 de la même manière que les object services de CORBA. 111

128 Les architectures pour la simulation distribuée 1.5 Comparaison entre HLA et CORBA Les différentes architectures sont souvent difficiles à comparer car elles n utilisent pas les mêmes termes et il n existe pas de modèle adapté. La structure (framework) EBI 23 proposée par Barrett [Barrett et al. 96] permet de comparer des systèmes basés évènements. register registrar register (Participant) informer instruct (Participant) listener send router send MTFs DCs Figure 1.11 : Structure EBI [Barrett et al. 96] Présentée à la figure 1.11, la structure EBI se décompose en trois parties : participants : ce sont les programmes, clients, fédérés,..., qui transmettent et/ou reçoivent des morceaux d information, appelés messages, en réponse à des occurrences appelés évènements. Ils sont de deux types : informer : participant qui transmet des messages, listener : participant qui reçoit des messages. registrar : avant de pouvoir transmettre ou recevoir des informations, un participant doit enregistrer ses intentions auprès de ce composant, router : il se sert des informations du registrar pour délivrer les messages depuis les informers vers les listeners. Le rôle du router est important car le contenu et le routage des messages peuvent être modifiés entre l envoi et la réception. Il dispose de parties distinctes : le MTF 24 et le DC 25. Le MTF sert à modifier le contenu des messages envoyés aux listeners. Un type simple de MTF est le filtre qui sélectionne les messages à accepter ou rejeter suivant des critères définis. Un autre type est l assembleur (aggregator) qui rassemble plusieurs messages et les transmet, en un seul message, vers le listener afin de limiter le nombre de paquets transmis. Les règles de délivrance des messages sont gérées par le DC. Par exemple, une contrainte peut spécifier que tous les messages doivent être émis puis reçus exactement dans le même ordre ou qu ils doivent arriver dans un temps limite défini. Il s agit tout simplement de paramètres de qualité de service. 23 EBI : Event Based Integration 24 MTF : Message Transforming Function 25 DC : Delivery Constraint 112

129 Comparaison entre HLA et CORBA Le tableau présenté à la figure 1.12, page 115, analyse les différents points présentés par la structure EBI pour CORBA et HLA. CORBA est comparé à HLA à travers ses services d évènement et de notification. L enregistrement des intentions des participants est effectué par le service d évènement CORBA. Pour HLA, l enregistrement peut être effectué en deux étapes. La première étape, obligatoire, s effectue par le service de la déclaration et spécifie quels sont les classes, les attributs de classes et les interactions auxquels le fédéré s intéresse. La deuxième étape, optionnelle, s effectue par le service de distribution de données. Il permet de raffiner son intéressement en spécifiant des valeurs limites sur les attributs. C est au niveau du router que les différences apparaissent. En effet, au niveau du MTF, les possibilités offertes par CORBA sont limitées à l agrégation. Par contre, c est à différents niveaux que HLA exerce un contrôle des échanges. Tout d abord, ce contrôle s opère dans la structuration des données car la généralisation permet de réduire le nombre de paramètres transmis au destinataire comme cela est présenté à la section En cours de simulation, il s opère au niveau de trois services. Les services de déclaration et de distribution des données agissent indirectement via le registrar. Le service de temps, par contre, détermine comment le RTI délivre les évènements aux fédérés. Suivant les requêtes d avancement du temps demandé par un fédéré, le RTI ne délivre rien, délivre une partie ou tous les évènements si leurs horodatages sont compatibles avec la requête. À l inverse des éléments précédents, les appels Start/Stop Registration For Object Class et Attribute Scope Advisory ne diminuent pas le nombre de paquets émis mais en rajoutent. Ils permettent de prévenir le listener que des instances vont bientôt délivrer des évènements. Au niveau du DC, c est CORBA qui, cette fois, propose plus de fonctionnalités. Il permet de définir la qualité de service associée à un canal et aux évènements. Par exemple, on peut définir un délai maximum de délivrance d un évènement ou à l inverse définir un délai minimum d attente avant la délivrance de l évènement. Du côté du RTI, on peut spécifier deux modes de transport (best-effort et fiable) pour chaque attribut et chaque paramètre des différentes classes. Ceci est défini statiquement lors de l établissement des modèles FOM et SOM mais peut être changé dynamiquement en cours d exécution via les appels Change Attribute Transport Type et Change Parameter Transport Type. On peut aussi ajouter un paramètre de qualité de service sur les évènements en les horodatant. Ainsi, les évènements dits TSO 26 ne sont délivrés que lorsque le fédéré désire avancer, au minimum, au temps correspondant à l horodatage de cet évènement. On a donc des différences de considération entre le MTF et le DC du router. Ceci s explique par le fait que, malgré l absence de connaissance des informations véhiculées, HLA associe toute une sémantique (espaces de routage, classe / attributs) qui lui permet de correctement paramétrer ce routage. Ainsi, il propose beaucoup plus de contrôle au niveau du MTF. 26 TSO : Time-Stamp Order 113

130 Les architectures pour la simulation distribuée À l inverse, comme la sémantique est bien définie, il n est pas nécessaire de spécifier comment l on souhaite transporter les données. HLA connaît la requête de l utilisateur à travers une large API et peut donc spécifier la qualité de service suivant l appel effectué. De plus, CORBA est destiné à tous les types d applications distribuées qui ne requièrent pas forcément une garantie dans les délais et autres. Le programmeur doit donc pouvoir spécifier si oui ou non tel ou tel paramètre lui est indispensable. HLA étant destiné à une application temps réel, tout doit être orienté pour obtenir les meilleures performances. Seul le mode de transport et l horodatage est nécessaire dans ce type d application. Le mode de transport est intéressant car comme nous l avons vu au chapitre 1 de la partie II, ceci peut énormément influer sur la latence. L horodatage, par contre, permet de résoudre les problèmes de consistance (ordre causal). 1.6 Conclusion Depuis Link Trailer, de nombreux bouleversements se sont produits dans le domaine de la simulation militaire. Mais, ce n est qu à l arrivée de DIS que le marché a eu une très forte croissance. DIS a apporté une première normalisation pour le développement des simulations. Malheureusement, cette première technologie était trop confinée au domaine militaire de part son étroite relation avec la sémantique des données. Mais comme nous allons le voir dans le chapitre suivant, DIS a laissé de nombreuses innovations qui se sont depuis améliorées. Tirant la leçon de DIS et, de la même manière que CORBA, HLA a défini une architecture distinguant la partie service de la partie données. Beaucoup plus ouverte vers d autres domaines, elle semble proposer tous les services nécessaires au développement d applications pour la simulation distribuée. En concurrence avec CORBA, HLA se distingue par une complète orientation vers le temps réel et une très bonne connaissance de la sémantique des données sous-jacentes. Cependant, il ne faut pas oublier que la nouvelle spécification de CORBA s oriente vers le temps réel et le rendra bientôt, beaucoup plus apte à répondre à ce genre de problématique. D ailleurs, le RTI du DMSO repose sur un ORB temps réel compatible CORBA, TAO [Schmidt et al. 98]. 114

131 Figure 1.12 : Comparaison entre CORBA et HLA Action CORBA HLA participant informer producteur (supplier) fédéré (RTIambassador) listener consommateur (consumer) fédéré (federateambassador) registrar service d évènement (connect) services de déclaration / distribution des données agrégation généralisation (héritage) MTF service de temps (Event Request) Start/Stop Registration For Object Class Attribute Scope Advisory router fiabilité des évènements/connexion FOM/SOM mode de transport de l attribut priorité des évènements (best-effort, fiable) date d expiration évènements TSO (Time-Stamp Order) DC délai d attente d émission nombre maximum d évènements en attente par le consommateur. valeur maximale de l agrégation intervalle de temps d agrégation Conclusion 115

132 Les architectures pour la simulation distribuée 116

133 Chapitre 2 Les plates-formes de réalité virtuelle distribuée... il est impossible pour des simulations temps réel de reculer dans le temps. Michael R. Macedonia et Michael J. Zyda [Macedonia et al. 97] 2.1 Introduction Toutes les techniques que nous avons étudié dans la partie II sont destinées à tous les types d applications nécessitant de distribuer ou partager des informations de quelque nature que ce soit. Les techniques décrites dans ce chapitre s adressent plus particulièrement à la problématique des environnements virtuels en réseau. La connaissance du type des informations échangées permet aux techniques, que nous allons voir, de mieux tirer profit du réseau et de la puissance des machines. Au chapitre précédent, nous avons introduit les principales architectures de simulation que sont DIS et HLA. DIS a apporté de nombreuses fonctionnalités (dead reckoning, échange par messages,... ) qui seront développées dans ce chapitre. À l inverse, HLA est une architecture logicielle qui ne connaît pas la sémantique des données transportées. Or, pour être le plus efficace possible, il est nécessaire que le système ait une connaissance de la signification des informations pour effectuer des échanges réellement utiles. Diverses autres techniques seront exposées telles que la conscience qui n effectue une mise en relation entre deux entités que si certaines caractéristiques sont présentes, la gestion du temps qui offre un contrôle sur l ordre de délivrance des données ou encore la répartition de charge qui équilibre l utilisation des ressources de toutes les machines en interaction. 117

134 Les plates-formes de réalité virtuelle distribuée La connaissance des informations échangées permet de trouver un équilibre entre la quantité d informations nécessaire à l échange et la qualité des informations. On peut ainsi, en connaissant les déficiences humaines, négliger les informations qui ne seront pas perçues par l utilisateur. Il peut s agir de déplacements qui se trouvent hors du champ de vue de l utilisateur ou qui se trouveraient trop éloignés en distance. Dans ce cas, un déplacement de quelques centimètres ne serait pas visible de l utilisateur. La deuxième partie de ce chapitre tente d effectuer une taxonomie des différentes platesformes de réalité virtuelle afin de présenter les besoins spécifiques à certains domaines. De plus, il permet de montrer qu il est difficilement envisageable de réaliser une architecture universelle. 2.2 Les techniques de la réalité virtuelle distribuée L étude des architectures de communication de la seconde partie nous a montré que la bande passante, la fiabilité et la qualité de service sont des aspects importants. Il faut en tenir compte dans les architectures sus-jacentes sous peine de se retrouver limité dans l extensibilité en nombre d utilisateurs de la plate-forme. Les deux premières sections présentées ci-après s intéressent au premier point, il s agit de limiter le trafic sur le réseau. Le dead reckoning permet d émettre la trajectoire à un instant donné. À partir de cette trajectoire, chacun estime le déplacement au cours du temps. Lorsque l estimation dévie trop par rapport à la trajectoire réelle, une nouvelle trajectoire est émise. Le filtrage limite les transferts en imposant aux hôtes de souscrire ou de publier ses entités. Le filtrage le plus utilisé est le modèle spatial d interaction. Il diminue ou améliore la qualité et la quantité des informations proches d une entité suivant ses perceptions. La consistance de la base de données est une problématique connue des applications distribuées. De nombreux algorithmes ont été développés dans cette perspective. Mais nos contraintes temps réel nécessitent des solutions dont les échanges restent limités. La gestion de la propriété montre comment l architecture HLA a résolu ce problème. La gestion du temps cherche aussi à résoudre un problème de consistance visuel. Horodater les évènements permet d éviter qu un effet ne se produise avant une cause. La qualité de service apporte de meilleures performances dans l échange de messages en contraignant différents paramètres (latence, gigue,... ) mais la gestion du temps est nécessaire pour garantir le bon ordre de traitement des différents messages échangés. Le dernier point, la répartition de la charge propose aussi une solution pour diminuer le trafic entre deux hôtes. Si deux entités interagissent fortement et sont réparties à plusieurs milliers de kilomètres l une de l autre, il peut être plus judicieux de migrer l une des entités sur l hôte de l autre. 118

135 Les techniques de la réalité virtuelle distribuée Le dead reckoning Pour que l interaction entre les différents participants puisse se réaliser, il est nécessaire que chaque hôte maintienne un modèle de l entité ainsi que des informations sur son état. Ces informations évoluent au gré des interactions de l utilisateur et permettent de générer la position et l orientation de l entité à chaque image. Cette technique peut également être appliquée à n importe quelle variable qui évolue rapidement et pouvant être prédite suivant un algorithme simple. Le modèle de l hôte hébergeant l entité s appelle le réel 1 et représente l état le plus exact de l entité. Souvent, l entité est hébergée sur l hôte de l utilisateur qui interagit directement avec celle-ci afin de minimiser les délais. Les autres hôtes de la simulation disposent d un modèle appelé fantˆome 2. Afin de permettre une représentation exacte du déplacement des différentes entités peuplant l environnement, il est nécessaire d obtenir une fréquence de trame d au moins 24 images par seconde. Ceci permet à l homme d avoir la sensation d un déroulement fluide de l animation. Ainsi reproduite, l animation est dite temps réel. L hôte de l entité source doit donc régulièrement émettre des données vers les autres hôtes. Sur la figure 2.1, les hôtes disposant d une source (en noir) transmettent les informations aux autres hôtes qui maintiennent un modèle fantôme de l entité (en blanc). Hôte 1 Modèle d entité réelle (locale) Modèle d entité fantôme (distante) Hôte 2 Chemin de transmission des données Hôte 3 Figure 2.1 : Échange d informations entre les entités sources (d après [Singhal 96]) Selon Singhal, l hôte local doit maintenir une représentation distante des attributs de l entité (remote modeling) et l hôte distant doit intégrer le modèle de l entité distante avec 1 On dit aussi source, entité locale ou encore vraie entité. 2 ghost ou encore modèle distant et shadow. 119

136 Les plates-formes de réalité virtuelle distribuée ses propres modèles de manière transparente. Il définit trois types de fidélité permettant de masquer au mieux la non localité des entités [Singhal 96] : position : l erreur moyenne en position et en orientation de chaque modèle doit être faible. Deux voitures, côte à côte, faisant la course doivent avoir une position attendue exacte afin d éviter les collisions, comportement : la vitesse et l accélération du modèle fantôme doit exhiber un comportement réaliste de l entité réelle, structure : les entités réelles ne sont généralement pas rigides. Une méduse, par exemple, bouge ses tentacules tout en se déplaçant. Transmettre 24 paquets de données par seconde pour chacune des entités en mouvement risque de rapidement saturer le réseau. Prenons l exemple d un environnement comprenant entités en mouvement et dont les informations sont transmises sous forme de paquets UDP. La taille d un paquet contient un identifiant plus les informations de position de l entité sous forme de réel 32 bits soit 4 4 octets. Nous obtenons donc (16 + 4) 24 = 4800 ko pour les données utiles! La solution du dead reckoning ou estime 3 consiste à ne transmettre que les informations pertinentes au rendu de l entité représentée. Le dead reckoning réduit la bande passante utilisée en envoyant des mises à jour moins fréquemment. Pour maintenir la consistance, le manque d information doit être compensé entre deux mises à jour. Ceci est réalisé en approximant la position d une entité par rapport à la dernière mise à jour reçue et à l estimation de sa position à l instant donné. Hôte Source Hôte Distant Échantillonnage fréquence trame Échantillonnage fréquence trame Modèle de l entité réelle Génération de paquets de mise à jour Génération de paquets de mise à jour Modèle de l entité distante Mise à jour d un paquet de position Réseau Figure 2.2 : Échange d informations entre l hôte source et l hôte distant Le modèle de l entité réelle permet de générer des images à la fréquence de l affichage comme présenté sur la figure 2.2. Ce modèle est également utilisé pour définir une position à envoyer sur le réseau à destination des hôtes distants. Ces hôtes distants reçoivent les mises à jour à une certaine fréquence. Le modèle de l entité fantôme utilise ces données et régénère des images à la fréquence d affichage. 3 estime : calcul approximatif de la position d un navire en estimant le chemin parcouru d après les instruments de navigation. (Le Petit Robert, 2001) 120

137 Les techniques de la réalité virtuelle distribuée Les données généralement transmises sur le réseau sont la position, la vitesse et l accélération de l entité. Ces données déterminent la position future de l objet qui reste valide tant que celui-ci n a pas ou peu modifié sa trajectoire. De plus, cette prédiction limite le nombre de messages envoyés et évite les décalages temporels dus au temps passé à l échange du message. Estimations de la trajectoire Trajectoire réelle Figure 2.3 : Estimation de la trajectoire d une entité (ordre 0) Le premier système à implémenter le dead reckoning a été le jeu Amaze. La position était déterminée suivant l algorithme ci-dessous : x(t) = x 0 + x 0 t Seulement, il n intégrait pas d algorithme de convergence. La position des entités sautait immédiatement à la nouvelle position à l arrivée d une nouvelle mise à jour. La figure 2.3 présente le résultat d un tel algorithme. À chaque fois qu une mise à jour arrive, la position de l entité estimée saute du point estimé vers la nouvelle position qui correspond à la position exacte à l instant de réception à la latence du réseau près. Le dead reckoning a également été introduit dans le simulateur SIMNET mais le choix technique ne s est pas porté sur une mise à jour régulière (toutes les secondes) comme pour Amaze. Deux modèles sont introduits : le modèle réel et le modèle fantôme. L algorithme utilise la position x 0, la vitesse x 0 et l accélération x 0 : x(t) = x 0 + x 0 t x 0 t2 Diverses améliorations ont été apportées. Ainsi, la mise à jour de la position de l entité a été décomposée en deux parties : 1. un algorithme de prédiction : il permet de déterminer la position de l entité en fonction des mises à jour précédemment reçues, 2. un algorithme de convergence : il lisse le décalage entre la position réelle et la position estimée en effectuant une convergence vers la position future. Mettre en place un algorithme de convergence ajoute un pourcentage d erreur dans la position exacte de l entité. Cependant, il est nécessaire que l utilisateur ne soit pas troublé 121

138 Les plates-formes de réalité virtuelle distribuée par des comportements erratiques. Ainsi, voir un déplacement souple d une position à une autre même avec des erreurs dérange moins que de voir l entité sauter d une position à une autre. trajectoire estimée Figure 2.4 : Estimation de la trajectoire d une entité La figure 2.4 présente deux algorithmes de dead reckoning intégrant un algorithme de convergence simple (à gauche) et un autre plus complexe. Ce dernier adapte la trajectoire au fur et à mesure que les mises à jour sont transmises. Le premier, très simple, n a plus le problème des sauts d une position à une autre mais par contre, l entité saute d un angle de trajectoire à un autre angle. Ceci disparaît dans l algorithme de la figure de droite. Il existe même des algorithmes qui tiennent compte des capacités de l entité modélisée (avion, véhicule,... ) dans l algorithme de convergence Algorithme PHBDR PHBDR 4 est un algorithme de dead reckoning développé par Singhal dans le cadre de sa thèse [Singhal 96]. Modèle de l entité réelle Position de l entité réelle Suivi distant de la position de l entité Modèle de l entité distante Dead Reckoning Approximation de l erreur Étape 2 : Convergence (Adaptation progressive de la position affichée vers la position prédite) Test expiration Test décalage en position Étape 1 : Suivi (Prédiction distante de la position de l entité) Mise à jour d un paquet de position Réseau Figure 2.5 : Algorithme PHBDR [Singhal 96] 4 PHBDR : Position History-Based Dead Reckoning 122

139 Les techniques de la réalité virtuelle distribuée L hôte source transmet des paquets (figure 2.5) contenant les trois coordonnées scalaires (x, y et z) ainsi qu un horodatage. La fréquence de génération des paquets est déterminée par un écartement d erreur maximum spécifique à chaque entité. L hôte source dispose de la position réelle et de la position estimée pour déterminer cet écart. De plus, une horloge détermine un temps limite au delà duquel, un paquet est automatiquement émis si aucun n a été émis depuis. Ceci permet de transmettre une mise à jour aux hôtes arrivant dans la simulation en cours de route et permet également de résoudre le problème de paquets perdus (transfert en best-effort). À la réception, l hôte distant effectue deux étapes. La première étape utilise l historique des positions reçues pour prédire la position, la vitesse et l accélération future de l entité. La seconde étape ajuste l estimation de vitesse et d accélération afin que la position de l entité converge doucement vers le point de convergence. Seules les trois coordonnées de l objet nécessitent d être échangées pour cet algorithme. L historique de ses déplacements permet d estimer sa trajectoire sans recourir à la vitesse et à l accélération Le dead reckoning basé sur l intention D. Szwarcman propose une variante intéressante de dead reckoning [Szwarcman et al. 01]. L auteur propose de définir le dead reckoning d entités artificielles (A-Life) non plus par rapport à sa trajectoire (orientation, vitesse et accélération) mais par rapport à son intention. Le but est de reproduire un comportement social tel que se diriger vers une porte, s approcher ou fuir un personnage voire tout simplement lui sourire. Pour cela, il n est pas nécessaire de passer exactement par les mêmes endroits que l entité source. Ainsi, l entité reproduisant le comportement de son entité source doit seulement atteindre son objectif même si son déplacement est complètement différent de sa source. L auteur illustre ce principe (voir figure 2.6, page 124) en utilisant deux personnages M. et Mme Blue qui doivent remplir un objectif appelé l état Very Happy. Ainsi, quelle que soit la porte que le réel ou le fantôme (ici, appelé clone) emprunte, l état Very Happy est résolu lorsque les deux personnages se rencontrent. Ici, l entité source est passée par la porte de gauche tandis que l entité représentante est passée par la porte de droite. Malgré ces énormes différences de consistance, l objectif est atteint puisque les deux utilisateurs se rencontrent. Si la porte de passage importe, l utilisateur peut affiner ses intentions par un message du type rencontrer Mme Blue en passant par la porte de gauche. Ainsi, l entité représentante sera plus contrainte dans ses déplacements tout en conservant une grande partie de son autonomie sa trajectoire entre autre. 123

140 Les plates-formes de réalité virtuelle distribuée Figure 2.6 : Estimation basée sur l intention [Szwarcman et al. 01] 124

141 Les techniques de la réalité virtuelle distribuée Discussion Le dead reckoning est une technique devenue indispensable à tout environnement virtuel distribué. Il libère le réseau de nombreux messages qui auraient été nécessaires en son absence. Une évolution récente est le dead reckoning basé sur l intention. Il s agit, non plus, de reproduire le déplacement estimé de manière le plus proche du déplacement réel mais de reproduire l intention de l entité de la manière la plus fidèle. Cependant, l inconvénient du dead reckoning est que le paramétrage de l algorithme doit être effectué de manière judicieuse. Le risque est d avoir des mises à jour soit trop fréquentes soit trop peu fréquentes. Si la fréquence est trop importante, on perd une partie des avantages liés à l algorithme. Si la fréquence est trop peu importante, l utilisateur risque de ressentir l absence de mises à jour par des sauts répétés de l entité simulée. De plus, un algorithme est adapté à un type d entité. Un char, un hélicoptère ou une baguette de batterie n est pas géré par le même type d algorithme Le filtrage Le filtrage consiste à déterminer le type d information auquel l hôte s intéresse. Afin de sélectionner le type d information qui intéresse l hôte, le récepteur va déclarer son intéressement suivant certains critères. Il peut s agir, d une région dans laquelle l utilisateur se trouve ou observe, d objets ayant une taille minimum, ou d autres dépendant de l état de l utilisateur (vision de nuit, surdité,... ). Par analogie, c est le rôle du MTF de la structure EBI présentée à la section 1.5 du chapitre 1 de cette partie. Tout envoi de message est filtré suivant des critères prédéfinis puis sont transmis aux hôtes sélectionnés. Le message peut alors être transformé différemment suivant les hôtes destinataires Mode push et pull Deux modes de transferts sont généralement possibles afin de recevoir les informations pertinentes pour l application. Il s agit du mode push et du mode pull 5. Dans le mode push, l information est transmise à l hôte sans qu il ait à la requérir. Cette information peut être transmise parce que le récepteur a manifesté son intéressement pour ce type d information. A l inverse, le mode pull nécessite une demande explicite de la part du récepteur. Le récepteur intéressé par certaines informations va explicitement les requérir auprès de l émetteur. 5 Voir également la section du chapitre 2 de la deuxième partie. 125

142 Les plates-formes de réalité virtuelle distribuée Par analogie, on peut représenter le mode push comme le journal que l on reçoit tous les matins en ayant pris soin de s abonner auparavant. Le mode pull consisterait à demander le rapport de Monsieur X La déclaration La déclaration est un moyen simple de filtrer les messages qui intéressent un hôte. HLA propose un service de déclaration qui permet de préciser quelles classes d objet et quelles classes d interaction sont pertinentes pour l hôte concerné. Ceci peut être déterminé par la situation géographique de l entité. Un hôte simulant le déplacement d un individu n a pas à connaître la position des satellites dans l espace puisqu il ne pourra pas les observer ni entrer en interaction avec eux. Il est possible, de la même manière, de définir le niveau de détails voulu dans le simulateur. Par exemple, un environnement virtuel de formation permet de simuler des situations d urgence. Lors d une fuite de gaz, on peut mettre l apprenant en situation exacte, c est-à-dire avec les mêmes données que dans la réalité. Mais on peut aussi, lui fournir des indications supplémentaires telles que la force du vent sous forme de graphique ou une représentation du nuage de gaz en trois dimensions. Dans ce cas, le filtrage détermine le raffinement (quantité) des informations voulues. Les sections suivantes détaillent divers raffinements permettant de prendre en compte la situation géographique des entités Le modèle spatial d interaction Les choix techniques effectués par DIS [Hofer et al. 95] ne tiennent pas compte de l intérêt des utilisateurs. Dans DIS, chaque évènement produit l envoi d un message reçu par tous. Ainsi, le tir d un char, le déplacement d un missile et l explosion associée font transiter de nombreux messages. Dans DIS, le traitement de l intérêt est effectué au niveau des destinataires. Si le destinataire reçoit le message d une explosion située cent kilomètres derrière l entité simulée, alors ce message est tout simplement ignoré. Bien sûr, avec ce choix technique, on constate qu une grande quantité de bande passante est perdue à transmettre des messages inutilisés, et même inintéressants pour le destinataire. De nombreuses plates-formes (MASSIVE, HLA,... ) ont donc choisi d intégrer un ou plusieurs moyens permettant aux entités d indiquer leur intéressement. On peut distinguer deux catégories de moyens, l une centrée sur l entité et l autre sur un partitionnement spatial. 126

143 Les techniques de la réalité virtuelle distribuée Conscience L intéressement d une entité envers une autre entité peut être motivé par un besoin fort de préserver les interactions sociales de la plate-forme. En outre, cette manière d agir facilite l extensibilité de la plate-forme en limitant le nombre d interactions entre hôtes. Le modèle décrit par C. Greenhalgh est composé de sept éléments [Greenhalgh 99] : média. Les échanges ne peuvent s effectuer que si les deux médias (audio, vidéo, image, texte) en interaction sont compatibles. conscience. Unidirectionnelle, elle marque l intensité, la nature et la qualité de l interaction entre deux objets. Elle est caractérisée par l aura et varie suivant le focus et le nimbus. aura. Chaque média dispose d une aura. Elle définit la zone d intérêt d une entité. Ainsi, pour qu une interaction se produise, les auras des deux objets concernés doivent entrer en collision. L aura est attachée à l entité et se déplace en même temps. focus. Le focus traduit l intérêt porté par une entité. C est la direction portée par le regard dans le cas où le médium est l image. Plus l objet se trouve dans la zone du focus, plus l entité a conscience de sa présence. nimbus. Il s agit de la zone d intérêt de l autre entité en présence. Ainsi, plus l objet se trouve dans la zone du nimbus, plus il est conscient de la présence de l entité. adaptateur. Introduit par Benford et Fahlén, l adaptateur est un objet qui modifie l aura, le focus et le nimbus d un autre objet [Benford et al. 93]. Cet objet a pour but de représenter l influence sur ces paramètres. Par exemple, un avatar se trouvant sur un podium ou utilisant un objet tel qu un mégaphone voit son nimbus élargi. délimitations. Les délimitations (boundaries) permettent de définir des espaces limités où les paramètres sont modifiés. Ceci permet de modifier la perception lorsque l entité se trouve dans une pièce, par exemple. Objet Aura Interaction possible Figure 2.7 : Interactions possibles On peut donc résumer l aura à la potentialité d une interaction. Ainsi sur la figure 2.7, 127

144 Les plates-formes de réalité virtuelle distribuée six entités sont présentes mais, seulement quatre interactions sont possibles du fait de l intersection des auras. En ne considérant pas l aura, nous aurions eu (n (n 1))/2 = 15 relations. À partir de la collision de deux auras, on peut définir la conscience entre les deux entités suivant le focus de l un et le nimbus de l autre. La figure 2.8 présente quatre consciences possibles suivant l orientation du nimbus et du focus de deux entités. La conscience est complète dans le cas où les deux entités se font face à face. Dans ce cas, le focus de l un et le nimbus de l autre sont en étroite relation, d où la conscience duale de leur présence. conscience complète conscience partielle pas de conscience Tx Tx Rx Rx Tx Tx Rx Rx Tx Emetteur et son nimbus Rx Récepteur et son focus Figure 2.8 : Conscience suivant le nimbus et le focus La conscience partielle se produit lorsque seulement l une des deux entités a conscience de l autre. Par exemple, si deux avatars se trouvent dos à dos et que l un des deux crie (avatar 1). L autre avatar (avatar 2) aura conscience du premier en l entendant crier. L avatar 1, par contre, n a pas conscience de l avatar 2 puisqu il n a aucun canal sensoriel (visuel, auditif,... ) affecté par sa présence. L absence de conscience se traduit simplement par l absence de recouvrement entre le focus et le nimbus des deux entités. Les objets tiers a introduit le concept d objets tiers. Il s agit d objets permettant de négocier l interaction entre deux autres objets. La conscience peut être considérée comme une mesure de la qualité de service dans une communication. Ainsi, un objet tiers peut jouer le rôle d adaptateur ou de source secondaire. L adaptateur permet d augmenter, conserver, diminuer ou supprimer la conscience. La source secondaire, quant à elle, permet de créer une conscience indirecte. C est-à-dire que l objet n aura conscience d un autre objet qu à travers l objet tiers. On peut ainsi filtrer ou combiner des informations. L activation des objets tiers dépend de la relation établie avec les deux autres objets. Trois cas se présentent et sont montrés sur la figure

145 Les techniques de la réalité virtuelle distribuée C C C A B A B A B a) membre b) partage c) hybride B prend conscience A B de A via l objet tiers A B B a conscience de A Figure 2.9 : Activation des objets tiers a) membre : cette relation peut être mise en place afin que deux entités prennent conscience l une de l autre. Par exemple, lorsqu une entité rentre dans la pièce, l objet tiers prend conscience de l entité. Toutes les entités s étant mise en relation avec l objet tiers ont conscience des autres entités présentes dans la pièce. b) partage : lorsque deux entités ont fortement conscience d un objet tiers, on peut considérer qu ils sont en relation, indirectement. c) hybride : l objet tiers joue un rôle d amplificateur unidirectionnel de la conscience. Par exemple, un mégaphone augmente la portée de la voix de l entité, ce qui permet à l auditeur de prendre conscience de l émetteur. Partitionnement spatial La solution de la zone d intéressement est de découper le monde en morceaux. Le découpage peut être géographique ou abstrait (comme des fréquences radios). Il peut être de forme unique ou variable et de taille fixe ou variable. Chaque entité peut alors s abonner à ces différentes portions du monde suivant qu elles y sont présentes ou qu elles sont capables de ressentir certains évènements provenant depuis ces portions. M. Macedonia a considéré le partitionnement comme un des éléments fondamentaux à l extensibilité des environnements [Macedonia 95]. Il a aussi défini trois types de partitionnements possibles : spatial : le partitionnement est effectué suivant la situation géographique des entités. temporel : les mises à jour sont effectuées à un rythme différent suivant l importance de l attribut. C est-à-dire qu une vision par satellite n aura pas besoin de 15 mises à jour par seconde par entité. fonctionnel : partitionnement en fonction des besoins entre entités. Comme, par exemple, les communications radios. La forme du partitionnement peut être quelconque. Une solution retenue est la forme hexagonale car elle s approche de la forme circulaire et permet d imbriquer les pavés pour 129

146 Les plates-formes de réalité virtuelle distribuée former un pavage complet. Le but est de partitionner l environnement virtuel en zones géographiques fonctionnelles et d affecter à chacune d elle une adresse multicast [Macedonia 95] Discussion Le filtrage est une technique utilisée dans de nombreuses plates-formes. La déclaration est surtout utilisée dans les simulations militaires car chaque hôte ne s intéresse qu à une souspartie des entités dans la simulation. Dans les environnements virtuels de type grand public, tout type d entité peut intéresser l utilisateur. Dans ce cas, la déclaration n a aucun intérêt. Le partitionnement spatial est sûrement le filtrage le plus utilisé. Chaque zone de l espace est divisée en parts (hexagonal, carré, rond,... ) et est assignée à différents hôtes. Deux hôtes interagissent à partir du moment où ces derniers sont associés dans au moins une zone. Cette technique est très efficace pour la plupart des cas sauf lorsqu un rassemblement s effectue. Si trop d entités sont rassemblées sur la même zone, tous les avantages du partitionnement sont perdus. La conscience est un modèle spatial peu utilisé. Elle est destinée aux environnements virtuels ayant une très forte interaction sociale, c est-à-dire que la relation entre les entités a un intérêt majeur. Comme le dead reckoning, elle peut fortement limiter le nombre de messages échangés et est de plus en plus implémenté dans les environnements virtuels Consistance de la base de données L utilisation d une base de données centralisée résout le problème de consistance mais pose de nombreux autres problèmes d extensibilité et de fiabilité. La solution généralement adoptée est l utilisation d une base de données partiellement ou totalement distribuée. C est le cas pour DIS, DIVE, BrickNet [Singh et al. 95] et de nombreuses autres platesformes. Bien évidemment, cette solution résout certains problèmes mais en pose d autres. Le principal problème qui découle de l utilisation de données répliquées est la consistance. Chaque hôte ne dispose que d une vue approchée de l environnement global de l application. Ses informations locales sont exactes c est lui qui les génèrent mais les copies des informations distantes sont souvent approchées et périmées (estimation des positions intermédiaires et délais de transmission). Si deux hôtes décident de modifier simultanément un objet, il est nécessaire de respecter certaines règles afin que l état final des différents hôtes soient identiques. W. Broll identifie sept moyens pour résoudre l accès aux attributs des entités dont les 130

147 Les techniques de la réalité virtuelle distribuée cinq plus importants sont résumés ci-après [Broll 95] : 1. verrouillage. Le système souhaitant modifier un attribut demande un verrou, modifie l attribut et libère le verrou. 2. protocoles de prise de tour. Chaque participant dispose à son tour de la possibilité de modifier des attributs. 3. contrˆoleur centralisé. Un contrôleur centralisé reçoit les requêtes et les applique dans l ordre de leur réception. Ainsi, tous les hôtes disposent de la même vue globale. 4. exécution réversible. En cas d accès simultané à un attribut, les systèmes sont capables de revenir en arrière pour annuler des transactions et les réappliquer dans un autre ordre. 5. entités maˆıtre. Le droit de modification d une entité appartient à un site à un instant donné. Si un hôte souhaite modifier un attribut de cette entité alors il envoie une requête au site responsable. Le verrouillage et les entités maître sont les deux mécanismes les plus utilisés dans les plates-formes de réalité virtuelle. La première solution est longue à réaliser car à chaque accès, un verrouillage et un déverrouillage sont nécessaires, ce qui se traduit par un temps de latence mais son implémentation est simple à réaliser à l aide d un serveur central. Le second mécanisme est également simple à mettre en œuvre en l absence de serveur. Seul le responsable a le droit de modifier l entité 6. Ainsi dans HLA, le mécanisme retenu pour maintenir la cohérence du système est celui de l entité maître. Ce mécanisme est fourni à travers le service de propriété 7. Pour chaque attribut d une instance d une classe d objet, un seul fédéré peut en être propriétaire. Un attribut spécifique appelé PrivilegeToDelete donne l autorisation à un fédéré de supprimer l objet de la simulation et peut être cédé à un autre fédéré. Deux types d échanges de la propriété peuvent être effectués. Le mode pull permet à un fédéré d acquérir la propriété d attributs si certains sont disponibles. Ce mode est à l initiative de l acquéreur. L autre mode, dit push, est à l initiative du fournisseur. Dans ce cas, il souhaite offrir la propriété de certains de ses attributs. Ce dernier mode peut être utilisé quand un fédéré souhaite quitter la simulation Gestion du temps Les environnements virtuels distribués se distinguent des autres applications par l existence de l utilisateur dans la boucle (human-in-the-loop) et donc par la nécessité de tenir compte 6 On voit immédiatement une similitude avec les espaces partagés (section 2.4 du chapitre 2 de la deuxième partie). Toute modification d un élément n est réalisable que si l hôte en devient propriétaire. La technique des entités maître va encore plus loin, puisqu il n y a pas besoin de définir d action atomique comme c est le cas pour les espaces partagés. 7 Ne pas confondre avec le service de propriété de CORBA qui permet l ajout dynamique de propriétés à un objet CORBA. 131

148 Les plates-formes de réalité virtuelle distribuée du temps physique qui s écoule pendant la simulation. Le terme temps réel provient du fait que l utilisateur doit être capable d agir sur le système et de pouvoir en ressentir les effets comme si ses actions étaient réelles. Le seul objectif de la gestion du temps dans un environnement virtuel est de contrôler les instants où les différents utilisateurs effectuent des actions et ainsi déterminer un ordre dans les différentes actions de ces utilisateurs. Le scénario le plus simple, présenté sur la figure 2.10, est celui où un évènement est généré en réponse à un autre évènement. Par exemple, l explosion d un char suite au tir d un missile. Du fait de la latence des réseaux, si aucun mécanisme de contrôle n est implémenté, alors il est possible qu un hôte reçoive les évènements dans le désordre. C est-à-dire que l utilisateur observera d abord l explosion du char puis verra ensuite arriver le missile! [Fujimoto 00] Simulateur A Simulateur B tir Simulateur A Simulateur B tir détruit détruit Simulateur C Simulateur C incohérence temporelle Wallclock Time retardement de la délivrance du message Wallclock Time Figure 2.10 : Problème simple d ordonnancement causal Une première solution a été proposée en 1978 par Leslie Lamport [Lamport 78]. Elle consiste tout simplement à donner un ordre causal dans le cas où deux évènements sont en relation, c est-à-dire que l un dépend de l autre. Il s agit de la relation happens-before. Cette solution résout certaines erreurs et est très simple à implémenter à l aide d un vecteur temps. Le problème présenté précédemment est résolu tel que présenté sur la figure L utilisation d un algorithme CATOCS 8 améliore la consistance en garantissant le même ordre pour deux évènements concurrents 9 quel que soit l hôte. Par contre, il ne garantit pas que l ordre choisi soit le véritable ordre des actions. L horodatage (time stamp) permet de dater les évènements. Ainsi, lorsqu un hôte reçoit des évènements, il est capable de les traiter dans l ordre de leur émission. Pour cela, il est nécessaire de s accorder sur une horloge globale 10. En utilisant un horodatage, on peut synchroniser l avancée de l ensemble de la simulation de deux manières. L algorithme mis en œuvre est soit conservatif, soit optimiste. 8 CATOCS : Causal And Totally Ordered Communication Service [Cheriton et al. 93] 9 Deux évènements sont concurrents lorsqu ils s exécutent en même temps et n ont pas de relation causale. Cela peut poser des problèmes lorsqu un utilisateur base ses actions sur des informations temporelles. Par exemple, j attaque le premier avion qui décolle. 10 GVT : Global Virtual Time 132

149 Les techniques de la réalité virtuelle distribuée Simulateur A [0,0,0] [1,0,0] Simulateur B [0,0,0] Simulateur C [0,0,0] tir (1,1,0) (1,0,0) [1,1,0] [1,0,0] détruit (1,0,0) (1,1,0) [1,0,0] [1,1,0] retardement du message Wallclock Time Figure 2.11 : Relation happens-before à l aide d un vecteur temps Régulateur OUI NON Contraint NON OUI Fédéré à synchronisation stricte Fédéré à synchronisation agressive Moniteur Fédéré synchronisé par horloge externe Figure 2.12 : Les types de simulateurs suivant le mécanisme de régulation temporel L algorithme conservatif s assure qu aucun évènement dans le passé 11 arriver. Il ne traite un évènement que s il est sûr de cette condition. ne peut lui À l inverse, un algorithme optimiste traite les évènements en avance. Dans le cas où un évènement dans le passé se produit avec un horodatage inférieur au dernier évènement traité, il doit utiliser un mécanisme de retour arrière permettant d annuler le traitement des évènements et des messages qui ont pu être émis. HLA propose les mécanismes de délivrance des messages pour les deux types d algorithmes [Carothers et al. 97]. Dans HLA, un fédéré peut être soit régulateur soit contraint. Le temps local d un fédéré régulateur permet d avancer l horloge globale tandis qu un fédéré contraint subit l horloge globale. Les requêtes d avancement reflètent les différentes possibilités offertes : 11 Un évènement dans le passé est un évènement dont l horodatage est inférieur à son temps local. 133

150 Les plates-formes de réalité virtuelle distribuée lookahead fédéré régulateur Time Stamped Ordered Events (TSO events) fédéré contraint Lower Bound Time Constraint (LBTS) Figure 2.13 : Utilisation du lookahead dans HLA Time Advance Request (TAR). Fédéré conservateur qui avance d un pas au temps logique suivant. Next Event Request (NER). Fédéré conservateur qui avance à l évènement suivant. Flush Queue Request (FQR). Fédéré optimiste qui demande tous les évènements reçus dans l ordre d horodatage. La figure 2.13 montre le fonctionnement du temps entre un fédéré régulateur et un fédéré contraint. Un fédéré régulateur peut générer des évènements horodatés 12 et un fédéré contraint peut recevoir des évènements horodatés. Comme l avancement du temps est régi par ces deux types de fédérés, il est nécessaire de disposer d un mécanisme permettant d avancer le temps. Le lookahead est un paramètre des fédérés régulateurs. Il détermine la vision dans le futur que peut avoir un fédéré et chaque fédéré régulateur dispose de sa propre valeur de lookahead. Le fédéré régulateur garantit qu il n émettra pas d évènements avec un horodatage inférieur à t courant + t lookahead. Le LBTS 13 définit, pour un fédéré contraint, l horodatage le plus petit des évènements que le fédéré peut recevoir. Il est déterminé en prenant le message le plus petit pouvant être généré par tous les fédérés contraints. Ainsi, un fédéré contraint ne peut avancer au-delà de son LBTS Répartition de la charge La répartition de charge est une technique permettant d améliorer la performance d un système distribué en replaçant des tâches exécutées sur des nœuds fortement chargés vers des 12 appelés évènements TSO (Time-Stamp Order). 13 LBTS : Lower Bound Time Stamp 134

151 Les techniques de la réalité virtuelle distribuée nœuds moins chargés. Développer un algorithme adapté aux plates-formes de réalité virtuelle est difficile du fait des contraintes temps réel et du temps limité alloué à la répartition de la charge. Il faut que l algorithme tienne compte du surcoût en communication pour le transfert et du temps inutilisé par l entité pendant ce transfert [Gaudrault 95] Présentation Dans la classification des algorithmes de répartition de la charge, R. Diekmann fait remarquer que le choix d un algorithme est très dépendant des caractéristiques de l application [Diekmann et al. 97]. De nombreux algorithmes classiques négligent les aspects concernant la structure du réseau. Mais ce choix n est pas judicieux car la structure et les capacités du réseau sont des aspects qui doivent être pris en compte dans l élaboration d un algorithme. La répartition de charge consiste à élaborer une correspondance entre un graphe représentant un système distribué (processeurs) H et un graphe représentant l application G devant se servir de ces processeurs. Le graphe des processeurs est souvent statique. Par contre, celui de l application est soit statique soit dynamique. La plupart des applications du domaine scientifique utilisent un graphe G statique. La répartition de charge se produit lorsque de nouveaux nœuds ou de nouvelles liaisons sont ajoutées ou supprimées. Figure 2.14 : Classification des algorithmes de répartition de la charge, d après [Diekmann et al. 97] La figure 2.14 présente une classification de quatre types de répartition de charge suivant les critères de migration et de communication : dynamic mapping : ce type est adapté aux applications n ayant que très peu de dépendances entre ses éléments et ne pouvant pas migrer. Un processus, une fois créé et placé, reste sur le même processeur jusqu à sa suppression. Le choix du placement se base sur la surcharge introduite sur un processeur et la qualité de l équilibrage. dynamic embedding : lorsque les communications entre les éléments sont importantes, le placement est difficile. Les applications de recherche dans des arbres utilisent ce type de répartition. 135

152 Les plates-formes de réalité virtuelle distribuée dynamic loadbalancing : c est le problème le plus classique et de nombreux algorithmes existent. Il s agit de migrer des entités à tout moment afin d obtenir une charge équilibrée entre tous les processeurs. La communication entre entité importe peu. re-embedding : ce dernier type est le plus difficile à mettre en œuvre. Il s agit d équilibrer l ensemble des nœuds en tenant compte des communications induites entre processus. Les simulations par la méthode des éléments finis (MEF) adaptatifs sont des exemples utilisant ce type d algorithme. Il s agit de raffiner certaines parties du maillage suivant la solution obtenue. Les problèmes de type re-embedding opèrent par phases. Dans le calcul scientifique, les raffinements les modifications du graphe G sont généralement effectués à des points précis de la simulation. Un autre point dont il faut tenir compte dans la répartition de la charge est la granularité de l application c est-à-dire la taille des processus à migrer. La figure 2.15 montre le problème qui peut se produire suivant différents types de granularité. En (a) est représenté un nœud dont la charge est totalement dédiée à l application. En (b), le choix est fait de migrer l application sur un autre nœud disposant du double des ressources du précédent nœud. La charge du processeur est supérieure à la moitié due au surcoût de migration du processus. La même migration est représentée en (c). La différence est qu il y a deux processus à faire migrer. Figure 2.15 : Granularité et performance de la répartition de la charge, d après [Jensen 96] Cette notion de performance est à prendre en compte lorsque des migrations s effectuent régulièrement. C. Jensen a montré dans [Jensen 96] qu agréger les processus à petite granularité améliore le speedup 14 de l application. Le surcoût du transfert est alors partagé entre plusieurs processus. De la même manière, il faut aussi tenir compte de la durée de vie d un processus. S il reste quelques microsecondes de vie à un processus situé sur un nœud surchargé, la migration risque de coûter largement plus que le gain espéré. La répartition de charge s effectue en deux points : combien de charge doit être déplacée et quelle charge doit être déplacée. combien peut être résolu facilement dans le cas où le 14 Le speedup correspond à l accélération obtenue par la répartition de l application sur plusieurs processeurs. Le speedup idéal est de tempsmonoprocesseur nombredep rocesseurs. 136

153 Les techniques de la réalité virtuelle distribuée système dispose d un élément central permettant de récupérer les informations des différents nœuds. C est l objet principal des recherches actuelles. Par contre, quelle consiste à choisir la tâche, le processus, à migrer. Ce point est très dépendant de l application et peu de recherches ont été menées sur le sujet Migration dans les applications temps réel L étude effectuée par A.M. Gaudrault [Gaudrault 95] a passé en revue plusieurs platesformes de réalité virtuelle distribuée (SIMNET, MR Toolkit, VERN, Bricks et AVIARY). Il en ressort que très peu d information sur le sujet est fourni dans les différentes publications et que le sujet n est généralement pas abordé. L architecture WAVES 15, développée entre autre par A.M. Gaudrault, tient compte de la répartition des entités sur les différents hôtes. L algorithme se décompose en deux phases : le calcul d une vue globale de l ensemble des hôtes et une répartition incrémentale de la charge. Le calcul de la vue globale s effectue suivant une variante de l algorithme MCA 16. Il est réalisé en groupant les hôtes les clusters suivant le trafic échangé. Différentes paires [M k et M l ] de clusters sont créées puis on détermine le trafic V kl entre ces deux clusters. Le nombre de clusters m est réduit jusqu à ce qu il soit compris dans un intervalle. La valeur minimale de cet intervalle correspond au nombre minimum d hôtes pouvant traiter la charge totale actuelle. Quant à la valeur maximale, elle correspond au nombre d hôtes disponibles. La répartition incrémentale est effectuée en déterminant la charge d un hôte tel que décrit dans le calcul suivant : hostload = W h n W t S h où W h est le poids des entités sur l hôte choisi, n est le nombre d hôtes, W t est le poids total des entités (tous les hôtes) et S h est la puissance de calcul de l hôte. Le poids d une entité est lié à la complexité de celle-ci Discussion La répartition de charge est une technique intéressante pour augmenter les capacités en délai, en quantité ou en complexité d une application. Cependant, mettre en œuvre un algorithme efficace est très difficile car il doit être capable d évaluer et de migrer les entités à 15 WAVES : WAterloo Virtual Environment System 16 MCA : Module Clustering Algorithm 137

154 Les plates-formes de réalité virtuelle distribuée chaque instant de la simulation. Comme le fait remarquer A.M. Gaudrault, peu de littérature sur le sujet est disponible. L évaluation est très difficile. Il a d ailleurs choisi d effectuer un ensemble de tests pour estimer la performance de son algorithme. On peut toutefois faire remarquer que les environnements virtuels n ont généralement pas de contraintes d ordre d exécution des évènements, ce qui évite les problèmes de synchronisation lors d une migration. De plus, les applications à base de langages interprétés n ont pas de problèmes liés à l architecture de l hôte. 2.3 Taxonomie des environnements virtuels collaboratifs Slater propose trois dimensions pour classer les différents environnements virtuels distribués [Slater et al. 93] : le nombre de participants et d entités agissant dans le monde virtuel, la complexité des objets et leurs comportements. Cela varie entre les données statiques et les objets pouvant évoluer dynamiquement, le degré d interaction : faible, les utilisateurs peuvent se voir, moyen, les utilisateurs peuvent effectuer des activités complexes et forte, des tâches communes et synchronisées peuvent être effectuées. Cette classification s intéresse à la complexité de l environnement et à son extensibilité. On peut dire qu elle se base sur les types d applications distribuées qui peuvent être développées. En effet, chaque application n a pas forcément les mêmes besoins en terme de graphisme, d échanges, de réalisme, d immersion,..., et même si les besoins se trouvent être de même type, ils varient en puissance. Pour illustrer ces propos, on imagine très facilement que l imprécision d un jeu immersif n a pas le même impact qu une opération de chirurgie à distance. Ces différences, valables pour les applications de réalité virtuelle, le reste dans les applications de réalité virtuelle distribuée. Outre le type d application, c est parfois la technologie qui limite les choix. Ainsi, un réseau local a un débit beaucoup plus grand qu un réseau longue distance. Une application de réalité virtuelle distribuée limitée à un réseau local peut donc profiter de cette bande passante. Stytz étudie tous les types de fidélité offerts par un environnement virtuel distribué [Stytz 96]. Cette manière d agir est présentée à la sous-section suivante. Elle permet de classer les environnements selon leurs applications cibles. À l inverse, M. Macedonia et M. Zyda s intéressent plus à la technique pour classifier les différents environnements [Macedonia et al. 97]. Leur classification est présentée plus loin. Toutes ces taxonomies, [Macedonia et al. 97], [Manninen et al. 97], [Gabbard 97], [Capin et al. 99] entre autres, sont intéressantes mais bien souvent difficilement utilisa- 138

155 Taxonomie des environnements virtuels collaboratifs bles. Les informations que nous obtenons sur les différentes plates-formes ciblent des points différents Classification suivant des critères de fidélité On peut prendre comme point de départ la fidélité comme le remarque Stytz : Comme dans tout environnement virtuel, dans un environnement virtuel distribué, la fidélité est un élément primordial. Cet aspect se concentre principalement sur le réalisme visuel, avec pour objectif de faire accepter l image par l utilisateur et que cet utilisateur agisse comme si c était réel. [Stytz 96] Les différentes fidélités qu il en ressort sont : sensitive : elle concerne l information visuelle, auditive, tactile et, de manière générale, tous les canaux sensoriels qui stimulent l utilisateur afin de répliquer le monde réel le plus fidèlement possible, physique : elle adresse la représentation des effets de la gravité, de la propagation des champs électromagnétiques, le mouvement, la conservation de l énergie, etc, modélisation : elle a deux objectifs, premièrement, s assurer des bonnes proportions de l objet vis à vis des autres objets et un mouvement relatif correct sur l hôte et, deuxièmement, maintenir ces relations correctes entre les participants distribués (transformations de coordonnées entre autre), comportement des acteurs : les environnements contenant un mélange d acteurs physiques et d acteurs virtuels 17 doivent doter ces derniers d un comportement ressemblant à celui de l humain, temps : elle tient compte de la quantité de temps latence, gigue qui s écoule entre l action d une entité et sa notification. Les temps relatifs entre l émission et la réception doivent être pris en compte, information : cette fidélité est fonction de la quantité générée, de la fréquence de génération et de l exactitude de l information. On peut diviser cette fidélité en deux sous-catégories : complexité : elle concerne le type, la quantité et la fréquence de l information, nuances : elle concerne la présentation de détails non nécessaires pour la prise de décision mais qui est essentielle pour une présentation réaliste, périphériques d entrée : cette fidélité présente deux aspects. Tout d abord, elle doit répliquer les mécanismes d interaction du système réel. Ainsi, un simulateur de conduite doit disposer de pédales, d un volant et d une boîte de vitesse. Ensuite, elle doit permettre les interactions supportées par le système, système : ce dernier point représente une synthèse de l ensemble. La fidélité du système exprime si le fonctionnement de l application et si la réponse aux interactions de ce 17 On dit également CGA pour Computer-Generated Actor 139

156 Les plates-formes de réalité virtuelle distribuée système sont représentées correctement vis à vis des objectifs de l application. La performance requise par chacune des fidélités est fonction de l application et la plate-forme associée sera développée en conséquence. Ainsi, un environnement virtuel d opérations chirurgicales doit posséder une fidélité très grande dans les catégories périphériques d entrée, temps et modélisation car le chirurgien doit disposer des mêmes sensations et retours visuels que dans le cas d une opération locale. À l inverse, un environnement virtuel de formation ne nécessite pas une fidélité aussi importante pour le temps, la modélisation mais la fidélité physique représentera un aspect beaucoup plus important dans l immersion de l apprenant Classification technique M. Macedonia et M. Zyda étudient quels sont les éléments importants pour effectuer une taxonomie orientée vers la distribution (voire sur l extensibilité) et donnent les points suivants [Macedonia et al. 97] : 1. communication réseau : les quatre points suivants influent fortement sur les choix conceptuels de la plate-forme ainsi que sur le public destinataire de l application (Voir chapitre 1 de la partie II). (a) bande passante : il détermine la taille et la richesse du monde. Si le nombre d utilisateurs augmente, la demande en bande passante suit. (b) distribution : certains schémas de distribution offrent une extensibilité plus facile que d autres. Trois modes existent, unicast, multicast et broadcast, et ont été étudiés dans la partie II, section (c) latence : sa prise en compte est importante lorsque la corrélation entre différents objets est nécessaire comme dans le cas d un vol aérien en formation. Deux points sont à surveiller, la latence et la gigue. Ce problème se situe dans le réseau et sur l hôte où les délais de traitement doivent être optimisés. Le dead reckoning est la méthode par excellence pour résorber ces difficultés. (d) fiabilité : c est un compromis entre la bande passante et la latence. Comme nous l avons vu au chapitre concernant les réseaux, pour garantir la fiabilité, nous devons sacrifier la latence. C est sur ce point que les protocoles spécialisés peuvent apporter de nombreuses améliorations. Le système doit être conçu pour recouvrer les données précédemment perdues plutôt que de retransmettre des données non reçues car il est impossible pour des simulations temps réel de reculer dans le temps. 2. vues : ce sont les fenêtres sur l environnement virtuel qui présentent la perspective de l utilisateur. (a) synchrone : le rendu de la vue de gauche et de droite d un cockpit peut être réalisé par des hôtes différents. L utilisateur dispose alors de plusieurs vues simultanément. Cette présentation de l environnement nécessite un synchronisme très fort car la fiabilité doit être très grande et la latence très faible sous peine 140

157 Taxonomie des environnements virtuels collaboratifs de gêner le pilote. Le simulateur RAVEN 18 [Cater et al. 95] de la NASA est un exemple de ce type de vue. (b) asynchrone : la vue asynchrone est la plus courante. En effet, comme les utilisateurs ne voient que leur écran, un décalage de quelques centièmes de secondes entre différents hôtes ne pose pas de problème particulier. Les environnements virtuels très larges utilisent ce mécanisme car la synchronisation coûte très cher en ressources réseau. 3. processus : la répartition des processus sur différents hôtes permet d augmenter la puissance de calcul d une simulation. La plupart des systèmes utilisent les mêmes types de processus avec les mêmes données, ce qui procure une bonne consistance mais pas de gains en performance. DIS, à l inverse, exécute différentes simulations, sur différents hôtes, qui coopèrent. Cependant, de nombreux systèmes proposent la répartition de charge ou la migration afin d équilibrer les échanges (voir section 2.2.5). 4. données : c est un choix technique qui détermine beaucoup de choses dans la conception, l extensibilité, la fiabilité et d autres paramètres de la plate-forme. (a) monde homogène répliqué : une méthode simple consiste à initialiser toutes les bases de données des participants avant de lancer la simulation. Ainsi, tout le monde dispose des mêmes données (terrain, géométrie, texture, comportement) dès le départ. L avantage de cette approche est la petite taille des messages. Par contre, cette approche est assez inflexible et nécessite des bases de données qui peuvent être conséquentes. C est ce type de plate-forme qui distingue la taxonomie introduite par G. Kessler et D. Brutzman (partie II, chapitre 1, section 1.2). (b) base de données centralisée, partagée : c est le modèle typiquement utilisé dans les MUD 19. Les hôtes disposent d une application cliente légère qui ne fait que transmettre les interactions au serveur et recevoir le nouvel état depuis celuici. Un seul utilisateur peut modifier la base de données (ou une partie de la base de données) à un instant donné. Par contre, cette architecture est limitée en nombre d utilisateurs car le serveur représente un goulot d étranglement. De plus, le défaut de fonctionnement du serveur arrête toute la simulation. (c) base de données distribuée et partagée avec mises à jour point à point : les environnements qui simulent une mémoire partagée pour échanger des données font partie de cette catégorie. L utilisation de protocoles multicast fiables pour répliquer les données font que cette architecture se prête mal à l extensibilité comme nous l avions fait remarquer auparavant (section 2.3 du chapitre 1 de la partie II). DIVE et les systèmes basés sur Linda utilisent ce paradigme. (d) base de données client/serveur distribuée et partagée : cette dernière technique est une variante du modèle client/serveur où la base de données est divisée sur les différents clients et la communication est gérée par un serveur central. BrickNet utilise cette solution en utilisant un ORB qui sait sur quel client se trouve les données à mettre à jour. La latence est cependant plus grande que dans d autres 18 RAVEN : Remote Access Virtual Environment Network 19 MUD : Multi-User Dungeon 141

158 Les plates-formes de réalité virtuelle distribuée a) Client / Serveur b) Point à point c) Hybride Client Serveur Communication Figure 2.16 : Différentes topologies de communication pour les bases de données systèmes du fait de l utilisation de serveurs et de la localisation des données. Le dernier point (données) classe les bases de données conservant l état du monde en quatre types. Ces quatre types sont présentés à la figure Les solutions monde homogène répliqué et base de données distribuée et partagée avec mises à jour point à point correspondent à la figure a). Les deux solutions restantes, base de données centralisée, partagée et base de données client/serveur distribuée et partagée, correspondent à la figure b). La dernière figure, c), correspond à une variante de la solution avec serveur (solution (b) et (d) de l énumération). Il s agit d éclater le serveur unique en n serveurs communiquant ensemble. L avantage de cette solution réside dans la possibilité d associer des filtres aux serveurs. Ces filtres permettent de s adapter et de servir les clients différemment suivant qu ils se trouvent sur un réseau à haut débit ou non. De plus, en cas de défaillance, seul une partie des utilisateurs est lésée. Par contre, cette solution rajoute une indirection supplémentaire et donc une latence plus importante Les plates-formes existantes Il existe de nombreuses plates-formes permettant de réaliser des applications de réalité virtuelle distribuée. Nous avons donc choisi d en retenir trois qui présentent chacune un intérêt pour notre problématique : Bamboo propose une approche très modulaire et dynamique, DIVE est une plate-forme très complète et fonctionnelle, et VIPER offre un mécanisme inter-entité à base de stimuli très similaires aux agents des systèmes multiagents. Nous n étudions que les aspects distribués de ces différentes plates-formes. 142

159 Taxonomie des environnements virtuels collaboratifs Bamboo Développé par le Naval Postgraduate School 20 (NPS), est une boîte à outil pour développer des environnements virtuels dynamiquement extensibles [Liles et al. 98]. L originalité de cette plate-forme est son extensibilité fonctionnelle dynamique. C est-à-dire que l application peut être étendue en ajoutant des modules à la manière de Netscape ou Photoshop. La figure 2.17 présente l architecture des modules. L exécutable Bamboo se voit ainsi greffer trois sous-modules (visuel, gestionnaire d évènements et utilisateur). Chaque ellipse représente un module qui vient se greffer sur un autre module. Cette hiérarchie sous forme d arbre montre les dépendances qui peuvent exister. Ainsi, si un nouveau module 1 souhaite se charger, il faut que le module 2 soit déjà chargé ou doit alors être chargé auparavant. Le cœur de Bamboo est construit autour de l architecture VRTP présentée à la section du chapitre 1 de la deuxième partie. Module visuel Exécutable Bamboo 1 2 Module gestionnaire d évènements Module utilisateur Figure 2.17 : Modularité de Bamboo [Liles 98] Aspects distribués Les aspects distribués de Bamboo ont été réalisés par S. Liles qui a implémenté une interface entre Bamboo et HLA [Liles 98]. Le module d administration HLA (amhlaadmin) gère la couche de communication du RTI, le chargement et le déchargement de modules ainsi que toutes les entités participantes. Chaque module entité gère le comportement et la représentation polygonale pour chaque entité. L intégration des modules au sein de Bamboo est illustrée sur la figure Le module d administration gère la communication avec les ambassadeurs du RTI (RTI ambassador et federate ambassador). Admin a pour rôle d extraire l information et de la 20 NPS développe également un autre environnement appelé NPSNET. 143

160 Les plates-formes de réalité virtuelle distribuée amentitymodule amhlaadmin Admin amobject Objet entité Federate Ambassador Bamboo Module Page Module HLAadmin A1 Exécutable Bamboo AK A2 Module visuel Module évènements clavier RTI Ambassador Réseau Module entité (B) Figure 2.18 : interface HLA à Bamboo [Liles 98] transmettre à l entité concernée (amobject). Si l entité n existe pas, un nouvel amobject est instancié. Sur la partie droite de la figure 2.18, trois modules A1, A2 et AK sont représentés et gérés pour contrôler HLA. A1 est appelé dans la boucle d évènement de Bamboo et permet d appeler la méthode tick du RTI. Cette méthode donne du temps au RTI pour effectuer des traitements. A2 est une callback pour faire appel à la fonction d affichage de chaque entité et AK est une callback pour traiter tous les évènements clavier se rapportant au module amhlaadmin. An niveau de l entité, chaque entité dispose du comportement global et peut ainsi simuler localement les interactions et les collisions avec les autres entités. Seule l interaction est échangée. Le résultat associé est traité localement. Modèle objet Le modèle objet utilisé est relativement simple. Une seule classe d objet EntityState et une seule classe d interaction Collision sont utilisées. Les attributs et paramètres de chacune de ces classes sont donnés dans le tableau Objet/Interaction EntityState Collision Attribut/Paramètre Position Orientation Velocity Ammunition Damage EntityID Figure 2.19 : Modèle objet utilisé dans Bamboo [Liles 98] 144

161 Taxonomie des environnements virtuels collaboratifs Discussion S. Liles propose une approche intéressante combinant un environnement virtuel et HLA pour distribuer les données. Le chargement et le déchargement dynamique des modules apportent une certaine souplesse et permettent d ajouter, retirer ou modifier des fonctionnalités pendant son fonctionnement. Cependant, en regardant le modèle objet utilisé, on observe très vite les limitations de cette implémentation puisque chaque entité est définie suivant cinq attributs et une seule interaction Collision est disponible. Bien sûr, cela peut être étendu mais pas pendant le fonctionnement de l application. Pour reprendre les propos de S. Liles : Le FOM est prédéfini et analysé par le RTI au démarrage. Si une API permettant de changer le FOM pendant la simulation était disponible, la fédération pourrait étendre ses capacités sans nécessiter le redémarrage de l exécution DIVE est un environnement virtuel interactif et multi-utilisateur développé par le SICS 22. L architecture est orientée vers des interactions très réactives (les interactions sont immédiatement répercutées localement et exécutées un peu plus tard sur les plates-formes distantes) [Frécon et al. 98]. L architecture est basée sur une réplication active de la base de données (figure 2.20). C est-à-dire que chaque processus maintient une copie locale de la base de données. Ainsi, les données sont disponibles directement en mémoire. Toute modification est effectuée localement puis répliquée sur les autres hôtes. DIVE tolère donc que les bases de données diffèrent mais considèrent qu elles se synchronisent à travers les mise à jour et le dead reckoning. La réplication est effectuée vers les hôtes ayant exprimé un intéressement. Les entités (classes) qui composent l application sont hiérarchisées sous la forme d un arbre. L intéressement correspond à une sous-branche de l arbre. Chaque sous-branche créée peut être associée avec un canal multicast (lightweight group selon leur terminologie). L architecture d exécution L architecture de DIVE est composée d un serveur de noms DIVESERVER, de serveurs proxy si nécessaire et de gestionnaires de persistance. Le serveur de noms sert à demander un canal multicast permettant à l hôte de participer dans l environnement. Toutes les communications ont lieu à travers ce canal sauf les 21 DIVE : Distributed Interactive Virtual Environment 22 SICS : Swedish Institute of Computer Science 145

162 Les plates-formes de réalité virtuelle distribuée Figure 2.20 : Architecture répliquée de DIVE communications définies à travers les lightweight group. Ce serveur ne sert donc qu à initier la communication avec les autres hôtes participants. Le serveur proxy joue le rôle du MBone 23 lorsque celui-ci n est pas fonctionnel. En effet, DIVE utilise la communication multicast pour échanger des messages. Mais celle-ci n est pas forcément opérationnelle dans tous les réseaux (vieux réseaux, non mise en place, IP sous ATM sans support multicast,... ). Le serveur joue alors le rôle d intermédiaire en effectuant des communications point à point avec certains hôtes et d autres serveurs proxy. De plus, ce dernier peut servir de filtre en adaptant les données aux réseaux à bas débit, la duplication pour prendre en charge une augmentation du trafic,... Il permet également de tracer les échanges et d effectuer une analyse du trafic en temps réel. La taille des paquets est alors réduite pour permettre une plus grande extensibilité en nombre d utilisateurs. Les gestionnaires de persistance permettent de sauvegarder l état de l environnement dans un fichier et de le restaurer ultérieurement. Cette opération de sauvegarde est effectuée à intervalles réguliers. Discussion DIVE est une plate-forme très utilisée car elle est relativement complète et fonctionnelle. De plus, elle est disponible en téléchargement gratuitement. Elle permet une certaine extensibilité via les serveurs proxy (filtrage) et les lightweight group (intéressement, partitionnement). L utilisation du multicast fiable SRM et non fiable correspond bien à ce type d application. 23 Voir la section du chapitre 1 de la partie II. 146

163 Taxonomie des environnements virtuels collaboratifs VIPER VIPER 24 est une plate-forme générique orientée objet permettant la gestion d environnements virtuels multi-utilisateurs [Torguet 98]. L architecture est générique et permet le développement d applications collecticielles de tout type. L originalité de la plate-forme réside dans ses deux niveaux de programmation. Un premier niveau masque totalement les aspects répartis de l application tandis que le second niveau offre la possibilité, au programmeur, de choisir et/ou redéfinir les mécanismes de répartition. Le système VIPER Le système VIPER décrit l application autour de trois éléments : l entité, le stimulus et l univers virtuel. Tout élément de l environnement est représenté par une entité 25. Cette entité est généralement autonome et possède un ensemble de propriétés et de comportements. Le stimulus est une interaction véhiculée par une entité. Enfin, l univers virtuel représente le milieu tridimensionnel dans lequel les entités évoluent et interagissent. Les interactions entre entités transitent à travers un média représenté par l espace de stimuli comme présenté à la figure Ces stimuli sont générés par les effecteurs des entités et sont perçus par les capteurs de ces derniers. Un stimulus est un évènement perceptible par des entités tel qu une forme graphique, un son ou encore une collision. Stimulus Capteur Capteurs Effecteurs Comportements Entité État interne (attributs) Espace de stimuli Effecteur Figure 2.21 : Mécanisme de communication de VIPER [Torguet 98] De plus, une entité est représentée par un état interne et un ensemble de comportements. L état interne est modifié par un certain nombre d évènements (stimuli) perçus par l entité après filtrage. Les comportements déterminent l évolution de l entité ainsi que l émission de stimuli via les effecteurs (voir partie droite de la figure 2.21). 24 VIPER : VIrtuality Programming EnviRonment 25 Il en est de même pour l utilisateur qui est représenté par un clone ou avatar. 147

164 Les plates-formes de réalité virtuelle distribuée Les aspects répartis VIPER utilise une architecture d égal à égal. C est-à-dire que chaque hôte dialogue directement avec un autre et la base de données est dupliquée sur les différents hôtes. Cependant, l échange se fait via le multicast lorsque cela est possible et un serveur est utilisé pour initialiser la connexion ainsi que pour requérir des identificateurs uniques. La communication multicast sert entre autre à associer une région géographique à un groupe multicast. Quatre couches composent la plate-forme VIPER. La plus basse se compose de PVM 26 et RMP 27. La couche supérieure propose un environnement de programmation parallèle de type SPMD. Les deux couches supérieures proposent une interface de programmation (API). Deux niveaux de programmation sont disponibles dont le premier masque totalement les aspects distribués. Le programmeur développe son application sans se soucier des aspects répartis qui sont gérés de manière automatique. Le second niveau offre une totale ouverture sur les fonctionnalités de l architecture. On peut ainsi redéfinir les différents mécanismes de distribution, ajouter des filtres et des algorithmes de dead-reckoning ainsi que de nouveaux espaces de stimuli. Des univers virtuels sont définis afin de distribuer l environnement virtuel. Trois types d univers sont possibles (passif, actif, dupliqué). Un univers virtuel passif gère un univers distribué mais dont les entités sont figées à l hôte de création. L univers virtuel actif offre la possibilité de faire migrer les entités (meilleure interactivité, diminution des échanges à travers le réseau). Enfin, l univers virtuel dupliqué permet de dupliquer tous les objets d un hôte sur tous les autres hôtes. VIPER n a alors qu un rôle de synchronisation des données entre tous les hôtes. Discussion VIPER est intéressant par l utilisation d entités communicantes via des stimuli. Cette approche ressemble fortement à une approche multi-agents. Ces stimuli sont véhiculés à travers des espaces de stimuli qui permettent de gérer un intéressement suivant les fonctionnalités de l hôte destinataire (son, vidéo, image, texte,... ) et permet donc une adaptabilité suivant la bande passante disponible. La séparation en deux couches permet de créer des applications soit simplement sans se soucier de la répartition, soit de manière approfondie en apportant les algorithmes adaptés. Ceci offre une grande malléabilité de la part du programmeur. Il faut également noter que VIPER permet de définir les comportements soit de manière figée et compilée au lancement de l application, de manière interprétée via le langage de script ObjectTcl ou alors de manière dynamique comme dans Bamboo. 26 Voir section du chapitre 2 de la deuxième partie 27 Voir section du chapitre 1 de la deuxième partie 148

165 Conclusion 2.4 Conclusion Ce chapitre conclut l état de l art en examinant différentes techniques offertes permettant un échange adapté aux besoins de la réalité virtuelle distribuée, un examen de différentes approches permettant de comparer les plates-formes ainsi que l étude rapide de trois platesformes. La première partie du chapitre montre comment on tient compte du type des données pour l adapter au réseau sous-jacent. La bande passante, la fiabilité et la qualité de service du réseau ne sont pas inconnus du développeur même dans les couches supérieures. Le dead reckoning et le filtrage tentent d organiser les échanges en tenant compte de la bande passante. La consistance résout les problèmes liés aux différences de points de vue différences dans les bases de données de chacun en synchronisant les échanges. La gestion du temps propose de classer les données afin que leurs relations temporelles soient respectées. C est bien sûr un rôle que le réseau ne peut généralement pas assumer dans l état actuel des technologies. Enfin, l équilibrage de la charge améliore l utilisation de la bande passante répartition au plus proche et de la puissance des machines. Nous avons ensuite analysé différentes taxonomies afin de faire apparaître les points singuliers des plates-formes de réalité virtuelle. Le grand choix disponible ([Capin et al. 99], [Gabbard 97], [Macedonia et al. 97], [Manninen et al. 97], [Stytz 96],... ) montre bien la difficulté que cela représente et nous en avons retenu deux qui nous ont particulièrement intéressé. La première, la classification de M. Stytz, présente la fidélité comme un élément primordial de tout environnement et la qualité d une plate-forme se juge aux nombres et à la qualité des fidélités offertes. Bien sûr, il conclut en indiquant que chaque plate-forme doit approfondir chaque fidélité différemment suivant l objectif fixé. La seconde classification, celle de M. Macedonia et M. Zyda, se base sur les aspects techniques. Cette dernière permet plutôt de montrer les points forts et les faiblesses de chacune des plates-formes suivant l utilisation voulue. Bien que permettant de mieux cerner la problématique, ces taxonomies ne sont pas vraiment utilisables. Les plates-formes sont très hétérogènes, adaptées à des applications précises et la littérature de chacune trop vague. C est pour cela, que nous avons fini notre analyse par l étude rapide de trois platesformes de réalité virtuelle distribuée : Bamboo, DIVE et VIPER. Ces trois plates-formes sont étudiées car elles présentent chacune des aspects particuliers. Bamboo propose une approche très modulaire, basée sur un protocole particulier (VRTP), et très dynamique. La dynamicité est réalisée en rechargeant des modules. DIVE, quant à elle, est certainement la plate-forme la plus connue car elle est très complète et fonctionnelle. Elle est également extensible grâce à l utilisation de serveurs proxy et de l intéressement (lightweight group). VIPER offre un mécanisme de communication inter-entité à base de stimuli. Ces entités ressemblent ainsi fortement aux agents des systèmes multi-agents. 149

166 Les plates-formes de réalité virtuelle distribuée 150

167 Conclusion Dans cette troisième partie, nous avons effectué un état de l art dans le domaine des applications temps réel appliquées à la simulation ou à la réalité virtuelle. Dans le premier chapitre, nous avons exposé les deux principales architectures pour la simulation distribuée que sont DIS et HLA. Cette étude nous a permis d étudier les approches prises par chacune de ces architectures et voir l évolution qui en a découlé. La première comparaison nous a clairement montré comment HLA offre une architecture bien plus générique que DIS en rendant explicite l implicite et en définissant six services distincts (fédération, déclaration, objets, propriété, temps et distribution des données). La seconde, nous a permis de différencier les architectures CORBA et HLA. Cette dernière se trouve être mieux adaptée grâce à ses services orientés vers ce type d application. Le second chapitre nous a présenté différentes techniques montrant un lien fort avec la seconde partie de cette thèse. Comme le disent M. Macedonia et M. Zyda, il est impossible pour des simulations temps réel de reculer dans le temps. Il faut donc tout mettre en œuvre pour échanger toute information pertinente dans les temps et ce, de manière optimale tout en conservant la même représentation globale quel que soit l utilisateur. Ces rôles sont alloués aux différentes techniques que nous avons étudiées : dead reckoning, filtrage, consistance de la base de données, gestion du temps, répartition de la charge. Deux taxonomies ont également été présentées afin de montrer les fortes disparités qui peuvent exister entre les différentes plates-formes. La première s est concentrée sur la sensibilisation de l utilisateur vis à vis du réalisme de l environnement. La seconde, plus technique, a de plus montré le lien entre les couches de haut niveau et les couches de bas niveau. Les disparités sont renforcées lorsque nous présentons trois plates-formes distinctes dont l architecture et les techniques mises en œuvre diffèrent totalement. Cette troisième partie nous a permis d insister sur la disparité des applications possibles et des plates-formes disponibles. Cela nous permet d introduire dans la dernière partie de ce mémoire, notre propre architecture, orisdis, qui offre un environnement multi-agents adapté 151

168 Conclusion à la réalisation d applications de prototypage collaboratif, interactif et dynamique. 152

169 Partie IV Le prototypage interactif et collaboratif 153

170 Le prototypage interactif et collaboratif 154

171 Introduction Dans la première partie de cette thèse, nous avons exposé la problématique apportée par l utilisation des systèmes multi-agents au sein d un environnement virtuel. Deux aspects en sont ressortis. Le premier point est qu un système de réalité virtuelle offre un pouvoir d expressivité, sans précédent, entre l utilisateur et l ordinateur. Ceci est réalisé par l utilisation d effecteurs adaptés ainsi que par une application offrant des points de vue divers et variés. Le second point est l évolutivité du système, offerte par l utilisation des agents. L autonomie de décision et d action de ces derniers offre une adaptation à l environnement à tout instant de la simulation. Dans une application de prototypage interactif, ces pouvoirs d expression doivent être, le plus possible, conservés. Nous avons ensuite étudié la problématique liée à la distribution d une application temps réel. Cette étude a été décomposée en deux parties. Une première partie a analysé la partie basse de la communication qu est le réseau de transport ainsi que les protocoles et les paradigmes utilisés pour offrir un support d échange. La seconde partie s est penchée sur l architecture de haut niveau offrant des fonctionnalités simples à utiliser ainsi que sur les technologies mises en œuvre pour tenir compte des lacunes des services de communications et ainsi améliorer le réalisme de l application. La première partie de l état de l art a montré l abondance des réseaux disponibles. Bien que certains d entre eux offrent un support idéal pour le type d application envisagé, nous ne pouvons pas nous arrêter à un choix unique. Nous devons donc être capable de nous adapter à n importe quel type de réseau au risque d obtenir des performances plus médiocres. En ce qui concerne les protocoles abordés, l état actuel des développements et évolutions nous conforte dans la disponibilité future à grande échelle de protocoles adaptés. Cantonnés à certains réseaux ou limités en fonctionnalités, ils ne sont, à l heure actuelle, pas encore adaptés aux besoins de notre application. Nous avons ensuite étudié, dans un second chapitre, différents paradigmes de communication. La communication par messages 155

172 Introduction se prête aux applications de type SIMD 1. La mémoire partagée est adaptée aux architectures parallèles et les espaces partagés offrent un paradigme idéal dans l échange de données mais moins lorsque ces données doivent être partagées. Le bus logiciel, bien qu offrant un service orienté point à point, promet d être très attractif avec la prise en compte du temps réel dans la future norme CORBA 3.0. La seconde partie de l état de l art a présenté les architectures pour la simulation distribuée et les fonctionnalités offertes par les plates-formes de réalité virtuelle distribuée. Dans le premier chapitre, nous avons exploré les deux architectures de simulation les plus utilisées que sont DIS et HLA. Trop proche de la sémantique, DIS est une architecture destinée à la simulation militaire et se prête mal à d autres domaines. De plus, elle ne propose pas vraiment de services mais plutôt une normalisation dans les données échangées. HLA a résolu ces inconvénients en proposant une architecture offrant six services. De plus, cette dernière est indépendante de la donnée échangée. La donnée n est qu une chaîne de caractères sans aucune signification pour l architecture. Nous avons alors exploré, dans le second chapitre, les différents mécanismes offerts par les plates-formes de réalité virtuelle pour permettre une utilisation optimale du réseau vis à vis de l information à échanger. Bien sûr, ces mécanismes connaissent parfaitement la sémantique des données et peuvent s adapter aux besoins de l application. Cela nous a permis de connaître les fonctionnalités que nous devons également proposer dans un environnement virtuel pour le prototypage. Cependant, les différentes architectures étudiées sont intéressantes mais pas adaptées au prototypage dynamique. Nous proposons donc une architecture qui tienne compte des remarques faites tout au long des parties précédentes et qui offre un support idéal pour le développement d applications de prototypage interactif et collaboratif dans un environnement virtuel. Dans le premier chapitre, nous présentons brièvement la plate-forme multi-agents retenue oris pour notre développement. Elle offre des aspects dynamiques fortement développés à travers l immersion par le langage. Ensuite, nous examinons l architecture proposée en étudiant comment interfacer la plate-forme oris et l architecture HLA dans le but d offrir un environnement collaboratif. Différents points importants sont approfondis afin de montrer les difficultés qui apparaissent dans cette mise en œuvre. Nous insistons également sur la manière dont nous avons procédé afin de conserver les aspects dynamiques de la plate-forme alors que HLA ne le permet pas vraiment. Le second chapitre se consacre à l étude et à la mise en œuvre d une extension de l API de l architecture HLA. Pour cela, nous nous sommes basé sur une implémentation du RTI, le CERTI. Nous présentons brièvement le fonctionnement du CERTI puis nous expliquons les améliorations apportées à l API afin d apporter les aspects dynamiques i.e. le modèle objet dynamique. 1 SIMD : Single Instruction stream Multiple Data stream. La même instruction est exécutée par tous les processeurs mais chacun traite une donnée différente. 156

173 Chapitre 1 Le prototypage interactif et collaboratif Ce chapitre présente l architecture mise en œuvre pour fournir un outil de prototypage interactif, collaboratif et dynamique. Dans une première section, nous présentons la plate-forme oris qui propose un langage de modélisation orienté agent ainsi qu un simulateur permettant d évaluer les modèles construits dans ce langage. Une des caractéristiques essentielles de cette plate-forme est qu il est possible d altérer le modèle en cours de simulation et de modifier ainsi dynamiquement l environnement. Nous présentons ensuite l architecture que nous avons retenue. La communication est réalisée par l architecture HLA. Cependant, l absence de dynamicité du modèle objet de l architecture interdit l évolution du modèle simulé. Nous présentons une solution originale permettant de contourner ce problème. Afin de permettre une meilleure agrégation avec la plate-forme oris, cette dernière a été enrichie d un RTI offrant des services basés sur la sémantique des données échangées. 1.1 La plate-forme oris [Harrouet 00] [Harrouet et al. 02] est une plate-forme de prototypage interactif développée par le Laboratoire d Ingénierie Informatique (LI 2 ) de Brest. Il dispose d un langage interprété éponyme permettant de modéliser des agents et de les faire évoluer au sein d un même environnement. 157

174 Le prototypage interactif et collaboratif Le prototypage Le prototypage consiste à la mise en place d un modèle correspondant aux attentes de ses concepteurs. Cette étape est progressive et nécessite une succession d étapes dites essai/erreur. La figure 1.1 présente le processus de mise en place d un modèle dans une démarche de prototypage classique. Générer le premier prototype Ajuster le prototype Tester le prototype Non Tests satisfaisants? Oui Prototype réalisé Conception Utilisation Figure 1.1 : Démarche de prototypage classique (d après [Harrouet 00]) Ce modèle de prototypage, classique il y a quelques années, tend à être supplanté par une nouvelle approche, le prototypage entièrement numérique. En effet, le prototypage classique est coûteux en terme de temps ainsi qu en terme de prix. Le secteur industriel, toujours à la recherche d économies, cherche à améliorer les temps de développement. Pour raccourcir les cycles de conception-validation, il faut éviter d interrompre leur réalisation par des essais physiques coûteux [Pollet 02]. Le concept de PLM 1 tente d éliminer le prototype physique à la faveur d une conception du produit entièrement numérique, jusqu à son prototype final. Nous souhaitons, en plus de la conception numérique, laisser l utilisateur intervenir aussi bien pendant cette phase de prototypage que dans la phase de test. Il faut même que ces deux phases soient confondues. Ainsi, le rôle de concepteur et le rôle d utilisateur du système se trouvent confondus pendant la mise au point. La figure 1.2 montre ce changement en déplaçant la phase d ajustement du prototype de l environnement, de la conception à l environnement d utilisation. L utilisateur peut maintenant directement voir le résultat de ses modifications. 1 PLM : Product Lifecycle Management 158

175 La plate-forme oris Générer le premier prototype Ajuster le Ajuster en ligne Tester le prototype le prototype prototype Non Tests satisfaisants? Oui Prototype réalisé Conception Utilisation / Mise au point Figure 1.2 : Démarche de prototypage interactif (d après [Harrouet 00]) Notre approche Pour que l utilisateur puisse pleinement se concentrer sur le problème qu il doit résoudre, il faut que le système proposé soit le moins contraignant possible, vis à vis de l utilisateur. Comme nous l avons vu au premier chapitre de la première partie, une application de réalité virtuelle doit s adapter à l utilisateur. Cette adaptation est réalisée à travers trois points que sont la modularité, l immersion par le langage 2 et la généricité Modularité La modularité, que nous appellerons dynamicité applicative par la suite, est rendue nécessaire par l idée de prototypage elle-même. C est-à-dire que lors de cette phase, le système peut subir des modifications substantielles de sa structure. Cela nécessite donc une certaine souplesse pour que l ajout, la suppression ou la modification des éléments composant le système soit possible. L approche multi-agents permet d atteindre cet objectif grâce à son approche modulaire. Un système est conçu à l aide d un ensemble d éléments plus simples appelés agents. Ces agents disposent d un fonctionnement individuel et sont dotés de moyens de perception et d action au sein de leur environnement. Le fonctionnement global résulte de l ensemble 2 Nous appelons immersion par le langage, le fait que l utilisateur peut interagir avec l environnement à travers le même pouvoir d expression que l ordinateur, c est-à-dire le langage de programmation. 159

176 Le prototypage interactif et collaboratif des interactions obtenues par chaque composant, y compris par celles de l utilisateur. Cette modularité offre en plus une grande adaptabilité Immersion par le langage Dans une simulation analytique ou militaire, toutes les interactions envisageables sont préalablement codées par un comportement approprié. En réalité virtuelle, et plus précisément dans une application de prototypage, toutes les interactions ne sont pas prévues lors de son lancement. Un utilisateur doit donc être capable de percevoir le monde tel qu il est à un instant donné mais en plus doit pouvoir lui apporter de nouvelles entités même si elles n étaient pas prévues préalablement par le concepteur. Cet aspect doit pouvoir être fourni sans arrêter ni reconfigurer le système. Une grande liberté de conception doit pouvoir être offerte à l utilisateur. L utilisateur doit disposer de la même expressivité que le concepteur de l application ou les agents eux-mêmes. Pour cela, l utilisateur doit pouvoir parler le même langage (immersion par le langage). Ce langage doit, en plus, être dynamique pour accepter des requêtes, des modifications, en cours de fonctionnement Généricité Comme nous l avons vu dans le premier chapitre de la première partie, les applications de réalité virtuelle sont nombreuses. Elles concernent de nombreuses activités toutes aussi différentes les unes que les autres : ergonomie de locaux, étude des mouvements de foule, environnement virtuel de formation,... Il est important que le système n intègre pas de contraintes sur le type d univers à simuler Le langage oris La plate-forme oris permet l exécution de programmes écrits dans le langage éponyme. La syntaxe du langage est très similaire à celle du C++ et de Java. Il reprend les points essentiels des langages objets tout en apportant quelques fonctionnalités supplémentaires destinées à faciliter son utilisation et aussi permettre une orientation agent Le parallélisme L objectif de la plate-forme est de simuler des comportements de systèmes. L introduction de biais dans le simulateur ne peut être tolérée sous peine de perdre tous les avantages d une telle simulation et ainsi obtenir des résultats complètement faussés. En conséquence, 160

177 La plate-forme oris une attention particulière a été apportée afin de pouvoir contrôler l ordonnancement des différents agents peuplant l environnement. La méthode main() et la primitive start permettent l exécution de code en parallèle, et le contrôle du procédé d activation est un point des plus soigné de la plate-forme. La méthode main() Chaque entité oris peut devenir un objet actif 3, c est-à-dire un objet qui va s exécuter en parallèle de la simulation. Les objets actifs, dans oris, sont caractérisés par le fait qu ils disposent d une méthode main(). Cette méthode correspond au point d entrée du comportement de l instance et est exécutée par l ordonnanceur. Lorsque cette méthode se termine, elle est immédiatement relancée à son début. Autres traitements D autres traitements peuvent être lancés en parallèle des comportements des entités. La primitive start ouvre cette voie en permettant d exécuter un code en parallèle d un autre. Ce procédé peut être utilisé par un agent afin d effectuer plusieurs activités en parallèle. Désignation des traitements Afin de ne pas biaiser la simulation, il faut que les traitements des comportements des différents agents soient exécutés dans un ordre aléatoire à chaque cycle de simulation. C est exactement le même problème qui se pose dans des simulations distribuées. Deux entités locales à la même machine ont plus de chance d interagir en premier en priorité par rapport à une autre entité distante, et ceci à cause de la latence introduite par le réseau. oris résout le problème de biais en utilisant deux vecteurs de flots d exécution. Chaque flot d exécution n est exécuté qu une seule fois par cycle de simulation et son tirage est effectué aléatoirement à la tête ou à la queue du premier vecteur. Au fur et à mesure, le premier vecteur se vide et le second se remplit avec les flots d exécution terminés. Cette méthode permet de mélanger les flots d exécution à chaque cycle. De plus, lorsqu une nouvelle activité est créée, elle est placée dans le second vecteur et n est exécutée qu à partir du cycle suivant. 3 Nous qualifions d objet actif, un objet doté d un comportement autonome. Un agent est un objet actif pouvant communiquer par messages. 161

178 Le prototypage interactif et collaboratif Les moyens de communications Quatre moyens de communication sont offerts par le langage oris : Les appels synchrones : cela correspond à un appel de méthodes des langages usuels. Il s agit d un simple détournement du pointeur programme et celui qui effectue l appel est aussi celui qui effectue le calcul des méthodes appelées. Un appel synchrone assure que le code a bien été exécuté avant de passer à la suite. Les liens réflexes : ils permettent d invoquer des méthodes lors de la modification d une variable. Avant la modification de celle-ci, la méthode before() est appelée et la méthode after() fait suite à la modification de la variable concernée. Les envois de messages en point à point : ils permettent d échanger des données entre deux agents de la simulation. Les données à échanger sont placées dans une instance de classe dérivée de la classe Message. L invocation de la méthode sendto() sur cette instance provoque l envoi du message. Le message est placé dans la file FIFO de réception de l agent destinataire. Celui-ci peut alors en effectuer la lecture à tout moment. La diffusion de messages : elle permet d envoyer un message à plusieurs agents destinataires. Ces derniers auront, au préalable, enregistré leur intéressement via la méthode setsensitivity(). L envoi du message (broadcast()) provoque la réception de celui-ci par tous les intéressés et déclenche l appel d une méthode associée à la réception d un tel message. Ce comportement peut être modifié pour être géré comme un envoi de message point à point. Les envois de messages et la diffusion de messages n ont aucun rapport avec une communication réseau. Il s agit de la mise en œuvre de la communication entre agents dans un paradigme agent. En effet, les agents sont déjà des mini-applications distribuées qui communiquent par l envoi de messages. De plus, aucune supposition n est faite sur le contenu des messages échangés entre agents. KQML 4 peut, par exemple, être utilisé afin d apporter un formalisme de très haut niveau de la connaissance des agents à travers des actes de langage [Nédélec et al. 00] Les aspects dynamiques Différents moyens techniques sont offerts à l utilisateur afin de lui permettre d intervenir en ligne sur le code de l application. Cependant, toutes ces techniques utilisent un unique point d entrée qui est représenté par la fonction parse(). Ces interventions permettent, soit de déclencher des traitements à des instants donnés afin d observer l évolution du système, soit pour intervenir sur le code actuel de l application. Les interventions possibles sur le code s effectuent à différents niveaux : 4 KQML : Knowledge Query and Manipulation Language 162

179 Simulation participative distribuée en oris fonctions. On peut créer une nouvelle fonction ou modifier une fonction existante. De plus, il est possible d annuler le code d une fonction en ne déclarant que son prototype sans aucun code. Enfin, les fonctions peuvent faire référence à une implémentation en C++, classes. De la même manière, les interventions sur les classes sont possibles. De nouvelles classes, méthodes ou attributs peuvent être ajoutés. De plus, si une classe dérivée sur-définit une méthode et qu une modification est effectuée sur une méthode de la classe parente, cela n impacte pas sur la classe dérivée. Ainsi, la spécialisation entre classes est conservée, instances. Dernier point, l intervention au niveau du code peut se faire directement sur les instances. En cours de simulation, il est possible d ajuster le comportement d une instance pour lui permettre une meilleure adaptabilité suivant l évolution des autres modèles. Ces différentes spécialisations sont ajustables à travers l opérateur de portée (::) qui permet de distinguer si le code introduit concerne une classe, une instance ou le contexte global de l application. 1.2 Simulation participative distribuée en oris orisdis, en tant qu extension d oris, doit garder la même démarche telle qu elle a été présentée précédemment. Nous présentons, dans le restant de ce chapitre, les résultats de nos travaux. Lorsque nous utilisons le terme agent, il s agit d une entité, capable ou non, d intelligence ou d autonomie L architecture L architecture orisdis propose de coupler la plate-forme oris avec l architecture HLA dans le but d offrir un environnement interactif, collaboratif et dynamique. Les aspects collaboratifs ne sont possible que si les agents créés sur un hôte sont visibles sur les autres hôtes. Par visible, nous entendons le fait que l apparence, le comportement, l influence de l agent soient reproduits sur tous les hôtes participants. L interactivité est renforcée si l utilisateur n est pas capable, a priori, de déterminer si l agent est l original ou un représentant. Enfin, les aspects dynamiques permettent à n importe quel utilisateur d apporter des modifications, des améliorations, pendant le fonctionnement de l application Présentation Notre architecture propose de coupler l architecture HLA à la plate-forme oris à travers un composant supplémentaire que nous avons appelé l orisrti. HLA, en tant qu architecture 163

180 Le prototypage interactif et collaboratif pour la simulation, apporte de nombreux services nécessaires à la distribution de la plateforme. Le couplage de ces composants apporte la distributivité nécessaire à une collaboration temps-réel. Malgré tout, certaines fonctionnalités manquent (modification des données échangées,... ) et la manière dont nous les avons résolues sera présentée plus tard dans ce chapitre. L architecture est présentée sur la figure 1.3. hôte oris / fédéré Agent Agent Agent orisrti hôte oris / fédéré hôte oris / fédéré HLA/RTI Figure 1.3 : Double infrastructure Le principe retenu, dans notre contexte de prototypage, est qu une plate-forme oris distribuée ne peut participer qu à une seule fédération à la fois. Une plate-forme oris représente donc un seul fédéré, dans la terminologie HLA. Ce choix simple ne nous permet pas de faire participer une plate-forme à plus d une simulation contrairement à d autres plates-formes telles que MASSIVE-2 ou DIVE. Cependant, un outil de prototypage ne nécessite pas ce genre de partage. Il est toutefois envisageable de le réaliser en dupliquant les structures de données et les envois vers les n RTI impliqués dans la collaboration. Une plate-forme oris héberge de nombreux agents qui collaborent dans l environnement. Certains de ces agents peuvent être locaux à la plate-forme, tel qu un agent chargé d effectuer des traitements. D autres agents, par contre, participent activement à la collaboration. La mise à jour de certains attributs (forme, position,... ) de l agent distribué est nécessaire. Dans ce cas, ces agents collaborent avec un agent spécifique, faisant partie de l orisrti, qui va collecter les modifications à échanger. Du côté du récepteur, tous les évènements reçus depuis le RTI vont être traités par l orisrti. Un autre agent se charge de transmettre les nouvelles valeurs aux agents distribués concernés. Tous les échanges entre le RTI et oris passent par l orisrti qui est un intermédiaire indispensable puisqu il apporte différents services que nous allons aborder. 164

181 Simulation participative distribuée en oris Première implémentation La première implémentation de l interface entre le langage oris et l API du RTI a été effectuée à l aide d une mémoire partagée IPC 5 System V. Nous avons retenu cette manière de réaliser l interconnexion entre oris et la bibliothèque HLA suite à un problème de segmentation. Ce problème se produisait lorsque la bibliothèque RTI du DMSO 6 était directement connectée à la plate-forme oris. Présentée à la figure 1.4, le découplage entre le RTI (RTIambassador et FederateAmbassador) et la plate-forme oris était réalisé à l aide d une mémoire partagée. L accès à cette mémoire partagée était contrôlé par un ensemble de sémaphores. L échange de données était réalisé par deux paires de canaux FIFO 7. Chaque paire permettait le transfert des données dans un sens. Le premier canal permettait de transmettre la requête à réaliser (la méthode à appeler) et le second véhiculait les données stockées dans une structure complète, c est-à-dire pouvant contenir tous les types de paramètres utilisés dans un appel de méthode. Régulièrement chacune des interfaces (interface HLA oris et RTIcommunicateur) scrutait la file en attente de travaux à effectuer. Lorsqu une nouvelle tâche arrivait, les données nécessaires étaient extraites de la structure et transmises à la méthode chargée du traitement. Application oris plate forme FIFO des données transmises (< RTI) Application RTIcommunicateur identificateur de l ordre < RTI FederateAmbassador FIFO des données transmises ( > RTI) identificateur de l ordre > RTI RTIambassador Réseau interface RTI Mémoire partagée IPC Figure 1.4 : Communication entre l API oris et l API du RTI Les versions suivantes n avaient pas ce problème et cette mise en œuvre a depuis été abandonnée. Une bibliothèque oris d interconnexion a été développée afin d enrichir le langage oris et offrir toutes les fonctionnalités du RTI. 5 IPC :Inter-Process Communication 6 Le DMSO fournissait, jusqu au 30 septembre 2002, un RTI via le SDC (Software Distribution Center). Depuis, le logiciel fait l objet d une commercialisation. De plus, le code source n était pas disponible et aucun opérateur de recopie des conteneurs n était disponible. 7 FIFO : First In First Out 165

182 Le prototypage interactif et collaboratif Vue de l orisrti L orisrti joue un rôle très important dans le couplage des plates-formes oris participantes. Tandis que le RTI effectue le transport des informations et assure certains services (gestion de la distribution des données, du temps,... ), l orisrti assure l interconnexion des platesformes oris ainsi que d autres services non fournis par le RTI car plus proche de la sémantique des données échangées. La figure 1.5 présente la partie de l orisrti chargée des échanges de mises à jour. Manager 1 request 4 Receiver RTIambassador 2 Specific Features Manager 3 8 Information Base 7 9 update Sender 6 Dispatcher 5 FederateAmbassador Figure 1.5 : Composants du gestionnaire orisrti L interface avec oris est effectuée par le Receiver et par le Sender tandis que l interface avec le RTI est réalisée par les classiques RTIambassador et FederateAmbassador. Chacun de ces composants a un rôle précis détaillé ci-après : Le RTIambassador permet de transmettre des informations vers le RTI en utilisant une API bien définie. Ce dernier effectue ensuite le traitement approprié puis transfère le message adapté vers les autres fédérés concernés par l interaction. Le FederateAmbassador effectue le traitement inverse. C est-à-dire qu il reçoit les messages provenant du RTI, extrait les données et effectue le transfert vers la plateforme oris et plus précisément vers le Dispatcher. L API du Federate Ambassador est définie par l Interface Specification de HLA mais son implémentation est spécifique à la plate-forme oris. Le Receiver est le pendant du RTIambassador pour oris. C est un agent chargé de recevoir les requêtes provenant des différents agents partagés peuplant la plate-forme locale. Il peut s agir d entités réelles comme d entités fantômes 8 puisque les deux types d entités doivent réagir aux interactions de l utilisateur. Le Sender est le pendant du FederateAmbassador. Cet agent reçoit un certain nombre de mises à jour provenant du FederateAmbassador via le Dispatcher. Il s applique à retrouver l agent concerné par rapport aux données reçues (identificateur,... ) et 8 Les notions de réel et fantôme sous orisdis sont détaillées dans la section suivante. 166

183 Simulation participative distribuée en oris effectue soit l appel de la méthode de l agent correspondant, soit l émission d un message. L Information Base est une base de données locale à la plate-forme. Elle stocke les dernières valeurs d attributs reçues depuis les agents de la plate-forme locale ou depuis le réseau (agents des plates-formes distantes). Un autre rôle primordial est d assurer la mise en correspondance de l agent local (instance locale) par rapport à une instance d objet HLA. Le Dispatcher a un rôle très simple. Il doit transmettre l information reçue depuis le FederateAmbassador vers le composant chargé du traitement de l information reçue. L identification est effectuée soit par le type de message reçu (e.g. Reflect Attribute Values), soit par l identificateur de la classe associée au message comme dans le cas de la réception d une interaction (Receive Interaction). Ce composant permet de rajouter simplement de nouveaux services. Une séquence d échange depuis oris vers le RTI se décompose de la manière suivante et correspond aux tracés rouges (traits pleins numérotés 1, 2, 3 et 4) du haut de la figure 1.5 : 1. Un agent envoie un message à distribuer. Il peut s agir d une mise à jour ou d une requête, 2. L agent Receiver reçoit l interaction et interroge la base de données locale, 3. La base de données retourne les identificateurs HLA correspondant à la classe, l instance et aux attributs du message, 4. Le Receiver dispose désormais des informations nécessaires pour effectuer la demande auprès du RTI. De la même manière, à la réception d un évènement, l échange entre le RTI et oris s effectue suivant les tracés verts (traits discontinus numérotés 5, 6, 7, 8 et 9) dans l ordre suivant : 5. Le FederateAmbassador reçoit un évènement depuis le RTI et le transmet au Dispatcher, 6. Ce dernier route l évènement vers l agent chargé de ce traitement, 7. Le Sender transmet les identificateurs de classe, d instance et d attributs à l Information Base, 8. En retour, l Information Base renvoie le nom de l instance concernée ainsi que les noms des attributs à modifier et les noms des méthodes à appeler, 9. Le Sender peut envoyer un message ou appeler la méthode de l entité concernée. De la même manière, d autres composants interviennent dans le transfert d informations et ne sont pas représentés sur la figure. Il s agit des Specific Features Manager. Ces derniers sont des services supplémentaires permettant de gérer d autres fonctionnalités telles que l échange de messages entre agents et toutes les fonctionnalités supplémentaires nécessitant le recours aux ambassadeurs. Nous verrons aussi que l Information Base a un rôle plus important que celui présenté dans cette section car il doit prendre en compte la dynamicité applicative de notre plateforme. 167

184 Le prototypage interactif et collaboratif Modèle réel / fantôme Notre plate-forme repose sur le modèle réel/fantôme afin de fournir une représentation approximativement identique sur les hôtes des différents participants. Le modèle réel définit l ensemble du comportement de l entité et fournit régulièrement des données aux fantômes. Ces derniers peuvent, à partir de ces données reçues, modéliser un comportement approximatif mais suffisamment proche de la réalité pour l utilisateur. Cependant, l interactivité de l application nécessite que tous les utilisateurs puissent opérer sur les entités qu elles soient locales ou distantes, réelles ou fantômes. La figure 1.6 illustre une telle interaction. orisdis 1 orisdis 2 (5) (5) (1) Ghost.1 (4) (4) Ghost.2 (2) orisdis 4 Real (3) (4) orisdis 3 (5) Ghost.3 Figure 1.6 : Interaction entre réel et fantômes L étape (1) est un peu particulière puisqu elle n est pas toujours prise en compte. Elle concerne la modification d une entité fantôme dont la plate-forme n est pas propriétaire de manière locale avant que l entité réelle n ait accordé cette modification 9. Cette étape est toutefois intégrée à la plate-forme pour deux raisons. La première est qu un agent dispose d une autonomie de décision et qu à l inverse d un appel de méthode, l agent peut refuser d effectuer le service. Par exemple, il est possible de demander à l agent de changer de couleur (cette couleur peut représenter la température de l entité) mais cette modification est refusée puisque l état de ses variables ne permet pas l évolution de sa couleur (la température ne correspond pas à la couleur). Ainsi, le choix de mettre à jour 9 Ce choix technique rejoint l idée choisie par A.N. Rodriguez pour présenter un résultat direct à l utilisateur sans attendre le résultat réel (Voir le chapitre 1 de la seconde partie de [Rodriguez 03]). En effet, simuler localement offre une latence très faible. Dans le meilleur des cas, le résultat est correct et immédiat. Dans le cas contraire, une mise à jour distante se produit un peu plus tard et permet de rétablir la bonne situation. 168

185 Simulation participative distribuée en oris localement l agent reste à la discrétion du concepteur sachant que l agent réel reste maître de la décision finale. La seconde est qu il est nécessaire de l implémenter dans le cas où il s agit d une mise à jour d un état dynamique. Nous reviendrons sur ce cas particulier à la section En dehors de cette première étape, la mise à jour réel/fantôme représentée sur la figure 1.6 se déroule de la manière suivante : 1. Le fantôme Ghost.1 de la plate-forme orisdis 1 tient compte de l interaction de l utilisateur afin que celle-ci soit immédiate, 2. Le fantôme envoie un message à l orisrti de sa plate-forme l informant qu une interaction vient d être effectuée. L orisrti effectue les traitements nécessaires et transmet l information au RTI qui traite l évènement et transmet le message au réel situé sur la plate-forme orisdis 4, Le FederateAmbassador de la plate-forme orisdis 4 transmet le message à l orisrti. Ce dernier traite le message et le transmet au réel Real. 3. L agent Real reçoit le message et accepte ou non l interaction ici, on considère que l interaction a été acceptée, sinon, le traitement de l interaction se terminerait à ce niveau. Le résultat de l interaction modifie l état interne de l agent et nécessite la mise à jour de ses fantômes. 4. En conséquence, il envoie un message à l orisrti qui effectue le traitement adéquat et transmet l information au RTI. Le RTI traite alors le message et envoie une mise à jour à chaque fantôme représentant du réel. 5. Chaque plate-forme orisdis disposant du représentant du réel (ici, orisdis 1, 2 et 3) reçoit l information via le FederateAmbassador. L orisrti traite cette information et la transmet au fantôme qui se charge de mettre à jour son état interne. Un seul fédéré peut être propriétaire d un attribut à un instant donné. Ainsi, seul le réel peut envoyer des mises à jour (Update Attribute Values). Les demandes provenant des fantômes sont alors effectuées par des interactions (Send Interaction) Attributs statiques et attributs dynamiques On peut distinguer deux types d attributs en fonction de leur évolution, les attributs statiques et les attributs dynamiques. Les attributs qui se classent dans la catégorie statique sont les attributs pour lesquels l évolution de leurs valeurs est rare et ponctuelle ils ne procèdent pas à des mises à jour successives. Par exemple, pour un véhicule, l état des feux de stop ont un état statique, c est-à-dire qu ils ne changent pas de valeur en permanence et que les variations ne sont pas continuelles. À l inverse, les attributs dynamiques sont des attributs associés aux variables d état d un agent dont l évolution est permanente ou peut l être et dont leur évolution est continuelle. Par exemple, l orientation et le déplacement d un véhicule sont des attributs dynamiques. 169

186 Le prototypage interactif et collaboratif Problématique Pour les attributs statiques, la demande effectuée par le fantôme au réel ne pose pas de problème. Comme nous l avons vu sur la figure 1.6, le fantôme peut même effectuer la modification lui-même. Ceci peut poser un problème si le réel refuse d effectuer la modification et, dans ce cas, on risque d obtenir une base de données inconsistante par rapport aux autres plates-formes participantes. Rappelons que quoi qu il arrive, l agent réel reste maître de la décision finale il dispose du comportement complet en provoquant régulièrement une mise à jour de recalage. Il est cependant intéressant de réaliser immédiatement la modification sur le fantôme car elle permet un gain de temps dans la réalisation de la modification. La latence est plus faible, ce qui améliore l immersion de l utilisateur. Pour les attributs dynamiques, il en va autrement. En effet, la modification apportée à une variable interne nécessite l envoi d une demande au réel. Ainsi, lorsqu on déplace le fantôme d une entité, sa position évolue et nécessite l envoi d évènements à son réel. Pendant ce temps, le réel peut avoir évolué vers une autre position, ce qui provoque l envoi d une mise à jour des fantômes. De plus, la mise à jour envoyée par ce fantôme peut être acceptée et, dans ce cas, ce dernier risque de recevoir un ordre de déplacement à une position où il était quelques instants auparavant. Réel x=0 Fantôme x=0 x=1 x=1 (1) trajectoire initiale du fantôme x=2 x=3 x=2 x=1 x=1 3 (2) trajectoire du fantôme x=1 x=2 x=2 x=3 x=2 x=2 x=3 x=2 x=3 position en x 2 1 x=2 mises à jour par le réel x=3 temps temps a) interactions entre fantôme et réel b) évolution de la position du fantôme dans le temps Figure 1.7 : Évolution d un attribut dynamique avec mise à jour du réel La figure 1.7 partie a) montre le type de problème qui peut se produire dans le cas de la modification d un attribut dynamique par un fantôme. Dans cet exemple, le fantôme, à gauche, envoie régulièrement des évènements au réel à droite. Lors de la réception d un évènement, le réel se met à jour et valide la nouvelle position vers tous les fantômes présents dans l exécution. Seulement, le temps de transfert des évènements, du fantôme vers le réel et du réel vers le fantôme, n est pas instantané et cette latence est telle que le fantôme a le temps d émettre plusieurs évènements avant de recevoir la confirmation depuis le réel. La partie b) de la figure présente le résultat tel que l observe l utilisateur sur la plate- 170

187 Simulation participative distribuée en oris forme disposant du fantôme. L utilisateur souhaitait effectuer la trajectoire (1) mais les mises à jour du réel ont, en permanence, modifié la position de l entité et le déplacement final correspond à la courbe (2). Solution proposée Lorsqu un fantôme modifie un attribut dynamique, deux types de mises à jour peuvent interférer dans son évolution. Le premier concerne ses propres mises à jour qui sont émises vers le réel et seront répercutées sur le fantôme lui-même. L exemple précédent a bien montré cette problématique puisqu à chaque fois qu il recevait une mise à jour de sa propre position précédente, cela provoquait un saut qui empêchait l utilisateur d atteindre l objectif désiré. Cet inconvénient est résolu simplement. Quand un fantôme émet un évènement, il joint à son évènement l identificateur du fédéré émetteur de cet évènement. Le fédéré hébergeant le réel reçoit l évènement ainsi que l identificateur. Si la modification de la variable provoque une mise à jour alors le réel émet l évènement en joignant l identificateur de la source qui l a provoqué. Ainsi, quand le fantôme à l origine de l évènement reçoit une mise à jour du réel, il sait si c est lui qui l a généré. Dans ce cas, il ignore tout simplement le message reçu. Le second, provient de la mise à jour du réel suite à son déplacement d une part (géré par exemple par le dead reckoning 10 ) et d autre part, des évènements générés par les autres fantômes situés sur les autres plates-formes. En clair, le problème se pose lorsque deux utilisateurs souhaitent agir sur la même entité au même instant. position Interactions de l utilisateur 1 position temps + Résultat des deux interactions position temps Interactions de l utilisateur 2 temps Figure 1.8 : Exemple de l interaction de deux utilisateurs C est un problème qui fait l objet de nombreuses études [Shirmohammadi et al. 00]. Nous avons souhaité apporter une réponse simple à cette problématique. Elle est résumée 10 Voir la section page 119 pour plus d informations sur le dead reckoning 171

188 Le prototypage interactif et collaboratif à la figure 1.8. Plutôt que de transmettre une nouvelle position à appliquer sur l entité, nous transmettons le delta du déplacement de l entité. Dans l exemple, l entité fantôme des deux utilisateurs se trouvent à la position 3.0 initialement. Chacun agit sur son fantôme et chaque déplacement provoque l envoi d un évènement vers le réel. Lorsque le réel reçoit les évènements, il applique le delta du déplacement reçu. Ainsi, lorsqu il reçoit la nouvelle position 2.5 et 3.5, il calcule la nouvelle position comme étant 3.0 (le déplacement de chacun s annule). Cette solution n est peut être pas optimale mais elle procure une interactivité proche de la réalité. Ce delta n est mis en œuvre que lorsque deux interactions se produisent de manière suffisamment proche (par exemple, 100 ms d écart). Pour cela, la mise à jour de la nouvelle position peut être retardée afin de correspondre au délai d attente défini (ici, 100 ms). Si l écart entre les deux interactions est trop important, ces dernières ne sont pas considérées comme simultanées et se produisent donc normalement sans aucune relation entre elles Dead Reckoning et heartbeat Les attributs dynamiques peuvent être associés à un algorithme de dead reckoning. Pour se faire, les instances ayant des attributs dynamiques gérés par le dead reckoning héritent d une classe qui fournit les fonctionnalités permettant de conserver l historique des valeurs. Cette classe dispose de toutes les fonctions qui permettent l envoi de mises à jour vers l orisrti lorsque l écart en position dépasse une valeur définie lors de la création de l entité. L évaluation de la position des fantômes est effectuée à chaque passage dans la méthode main(). De la même manière, le fantôme hérite d une classe fournissant l algorithme de dead reckoning. À chaque cycle de la fonction main(), une nouvelle valeur de l attribut est générée par rapport à l instant d évaluation. Le heartbeat permet, lorsqu une mise à jour a été perdue 11, de connaître quelles sont les valeurs des attributs d une entité. Émise régulièrement, elle permet en plus, la découverte des entités pour un fédéré venant de joindre la fédération. Cependant, cette fonctionnalité peut consommer beaucoup de bande passante inutilement quand de nombreuses entités se déplaçant peu sont distribuées. C est au concepteur de choisir d associer un heartbeat à une entité. Dans ce cas, une méthode permet d évaluer le temps et une mise à jour est automatiquement transmise à l orisrti lorsque le temps d attente est écoulé. Nous verrons plus loin, que lorsqu un nouveau fédéré rejoint la fédération, il peut demander l état du monde. 11 Le transport de certaines informations se fait de manière best-effort, ce qui implique que des pertes sont possibles. 172

189 Simulation participative distribuée en oris Modification dynamique de l environnement Notre plate-forme de prototypage est dynamique. Nous entendons par dynamique la possibilité de modifier en ligne le code du programme en cours d exécution. Ainsi, il est possible de rajouter de nouvelles classes ou instances de classes, de nouveaux attributs, de nouvelles méthodes et même, de modifier le code des méthodes utilisées. Cette dynamicité doit être préservée dans l application distribuée si nous voulons garder la même capacité de prototypage interactif qu oris. Avion Position Orientation Avion.1 Position Orientation classe originale instance temps Avion Position Orientation Eclairage Avion.2 Position Orientation Eclairage classe enrichie instance avec le nouvel attribut Figure 1.9 : Dynamicité de l application Ainsi, comme le présente la figure 1.9, nous avons une classe Avion dotée de deux attributs Position et Orientation. Une instance créée à partir de cette classe donne l instance appelée Avion.1. Si en cours de simulation, on décide d ajouter un nouvel attribut, par exemple Eclairage, alors toute instance construite à partir de cet instant doit disposer de la nouvelle propriété. De cette manière, la nouvelle instance Avion.2 est composée des trois attributs Position, Orientation et Eclairage. Comme nous l avons présenté à la section du chapitre 1 de la partie III, HLA utilise un modèle objet pour construire un arbre d héritage des classes et des attributs associés. Ces données sont stockées dans le fichier appelé FED 12 comme dans l exemple donné ci-après (figure 1.10). Ce fichier est lu par le fédéré puis transmis au RTI afin de prendre connaissance des données qui seront échangées en cours de simulation. À partir de ce moment, le RTI considère qu aucune autre donnée supplémentaire ne sera insérée dans la simulation. Or, comme nous l avons dit précédemment, nous devons conserver les propriétés de dynamicité si nous voulons permettre un prototypage interactif. Si nous voulons utiliser l architecture HLA et fournir la dynamicité, il est nécessaire de trouver une solution permettant d encapsuler les nouveaux attributs ou les nouvelles classes et instances qui pourraient être insérées en cours de simulation. 12 FED : Federation Execution Data 173

190 Le prototypage interactif et collaboratif ;; Exemple de fichier FED correspondant à la classe Avion. (class Avion (attribute Position best-effort timestamp geo) (attribute Orientation reliable timestamp) ) Figure 1.10 : Exemple de classe du fichier FED (syntaxe à la LISP) Plusieurs solutions sont envisageables mais comportent chacune leurs inconvénients. Une solution consisterait à définir une interaction qui contiendrait le nouvel attribut ainsi que ses données associées. Ainsi, au lieu de le transporter sous la forme d attributs de classe, les nouvelles variables seraient transportées sous la forme de paramètres d interactions. L inconvénient de cette solution est qu elle nécessite le développement d un protocole de communication qui serait véhiculé sous la forme de messages par instances de classes d interaction et surtout, de nombreux services liés aux attributs d instances de classes (gestion du temps, gestion de la distribution des données,... ) seraient perdus. Une autre solution, que nous avons envisagée, aurait été d utiliser une autre interface de communication pour échanger l état des attributs dynamiques. Cette solution n est pas très optimale puisqu il aurait fallu redéfinir tous les services spécifiquement à ce canal de communication. On peut quand même retenir que cette solution a un avantage, elle permettrait de séparer les données dans deux flots à qualité de service différente. Ainsi, lorsque le besoin s en ferait sentir, sur certains attributs, il serait possible de transmettre les données sensibles sur un canal mieux adapté Solution adoptée La solution que nous avons retenue permet de conserver les services du RTI fonctionnels. Elle met en œuvre une encapsulation des classes et attributs HLA dans une abstraction supérieure. Il faut noter que cette solution n est réalisable que parce que : 1. Un attribut n a pas de type. L OMT de HLA requiert la définition d un certain nombre de tableaux. Le tableau des attributs requiert un type et une cardinalité pour chaque attribut défini dans le modèle objet. Bien qu obligatoire sur le papier, le RTI ne gère pas de type 13. L encodage suit une norme d interopérabilité mais le RTI transporte les données sous une forme brute (raw). Ceci procure un avantage puisque le type de données transporté par un attribut peut être défini lors de l exécution. Il faut seulement que l émetteur et les récepteurs s accordent sur le type des données échangées. 13 La spécification de l OMT [Department of Defense 98b] a défini un certain nombre de types (annexe B) dont le type any qui correspond à n importe quel type de base. 174

191 Simulation participative distribuée en oris 2. Aucune limite sur le nombre d instances d une classe n est imposée 14. Ainsi, l instanciation d une classe d objet peut être répétée plusieurs centaines de fois sans poser de problèmes. La solution retenue se décompose en deux étapes : 1. Utiliser HLA quand les attributs des objets sont connus avant le début de la simulation, 2. Translater les nouveaux attributs créés à l exécution vers des objets connus et utiliser un protocole adapté permettant aux plates-formes participantes de connaître les associations créées. La figure présente un ensemble de composition. Initialement, la classe Avion ne dispose que de deux attributs distribués Position et Orientation. En cours de prototypage, nous décidons d ajouter un nouvel attribut distribué Eclairage. Avec la dynamicité de la plate-forme, les deux nouvelles instances créées doivent disposer de ces trois attributs. Ceci est réalisé en instanciant pour chaque instance de la classe oris Avion deux classes : une instance de la classe d objet de base Avion connue par le modèle objet avant le lancement de la simulation et une instance d une classe d objet générique qui jouera le rôle de l attribut dynamiquement ajouté. Avion Position Orientation Eclairage modèle object modifié instances Avion.1 Position Orientation DynamicClass.1 Attribute Avion.2 Position Orientation DynamicClass.3 Attribute Figure 1.11 : Exemple d instances créées après la modification de la classe Pour gérer cette solution, nous avons donc ajouté une nouvelle classe d objet DynamicClass (figure 1.12), dans le fichier FED, qui permet l ajout de nouveaux attributs en cours de simulation. Cette solution a l avantage d être très simple à mettre en œuvre car il suffit d associer un identifiant de classe à tout nouvel attribut. L attribut Eclairage dynamiquement ajouté de la figure 1.11 est géré par des instances de cette classe. Cette encapsulation est réalisée par l orisrti et plus précisément par le composant Information Base (voir figure 1.5, page 166). 14 Certaines implémentations de RTI risquent de disposer d une limitation sur le nombre d instances réalisables. On considère, dans ce cas, que la limitation est suffisamment grande pour qu elle ne puisse pas nous gêner. 15 L attribut Eclairage est associé à DynamicClass.1 et DynamicClass.3. La numérotation montre que l instance HLA qui va être associée au nouvel attribut est quelconque. 175

192 Le prototypage interactif et collaboratif (class ObjectRoot (class... ) (class DynamicClass (attribute Attribute reliable receive) ) ) Figure 1.12 : Classe générique pour le transport d attributs dynamiquement ajoutés Modèle UML Si l on regarde comment les relations entre classes, attributs, instances de classes et attributs d instances sont effectuées dans HLA, la figure 1.13 nous fournit une réponse simple en représentant les relations sous formes d un diagramme de classe UML 16 [Booch et al. 99]. Le fichier FED décrit la partie de gauche. C est-à-dire qu elle donne les différentes classes intervenant dans l application, les relations d héritage ainsi que les attributs de classe. Chaque classe et chaque attribut sont décrits dans le fichier FED par un nom. Ce nom est ensuite converti par le RTI en un identificateur permettant d identifier chaque élément de manière unique (couple identificateur de classe, identificateur d attribut). La partie droite de la figure 1.13 représente les différentes instances qui peuvent être produites à partir d une classe. Ainsi, lors de la création d une nouvelle instance (Register Object Instance), chaque instance reçoit un identificateur de type RTI::ObjectHandle permettant de l identifier de manière unique. Toutes ces informations vues jusqu ici sont connues du RTI. Par contre, la valeur associée à un attribut n est pas connue par le RTI. Seul le fédéré propriétaire de l attribut connaît sa valeur exacte. Cependant, les autres fédérés peuvent disposer d une valeur exacte à travers les mises à jour régulières ou approchée via le dead reckoning. Le problème majeur qui apparaît provient de l association d une instance de classe d objet HLA à une instance de classe oris. Il est impossible de rajouter de nouveaux attributs ou de nouvelles classes à la structure de données car cette dernière a été définie dans le fichier FED une fois pour toute avant l exécution de la simulation. La solution que nous avons retenue est présentée sur la figure 1.14 de la page 178. Elle se décompose en deux parties : une partie concerne les données statiques et l autre partie représente l extension dynamique apportée à HLA. Les données statiques représentent les informations connues avant le démarrage de l application. La partie représentée dans le cadre rouge (partie a)) correspond au fonctionnement d un fédéré classique. C est-à-dire que l instance oris a ses attributs, appelés Base Attribut oris Instance, associés par une association 1 1 avec les attributs de l instance HLA (Attribut Instance Classe Objet). Cette première partie correspond au fonctionnement d oris dans le cas où les aspects 16 UML : Unified Modeling Language 176

193 Simulation participative distribuée en oris ClasseObjet +nom +identificateur 1 * classe instances InstanceClasseObjet +identificateur classe 1 instance 1 attributs nattr attributs nattr AttributClasseObjet +nom +identificateur 1 * AttributInstanceClasseObjet +valeur Figure 1.13 : Relations entre classes, instances et attributs dans une simulation HLA dynamiques de la plate-forme ne sont pas mis en œuvre. La seconde partie (partie b) de la figure 1.14) intervient dans l extension dynamique des instances d oris. La classe générique que nous avons définie figure 1.12 remplit ce rôle. Cette classe est composée d un seul attribut qui représente l attribut dynamiquement ajouté. Toute instance oris distribuée est donc constituée de deux parties. Une partie représentant les informations connues avant le lancement de la simulation et représentée par zéro ou une instance de classe HLA (association base). Cette association binaire sur le nombre d instances de la classe de base est due au fait qu il est possible de créer une nouvelle classe non connue lors du lancement de l application. Ceci implique donc qu aucunes informations de la nouvelle classe n étaient connues avant l exécution. La seconde partie, aussi optionnelle, est l association generic qui représente autant d instances de la classe d objet HLA générique qu il y a de nouveaux attributs ajoutés dans l instance oris considérée. L instance oris possède un identificateur unique qui correspond à l identificateur fourni par le RTI lors de la création de l instance de la classe d objet de base. Dans le cas où il s agit d une classe entièrement nouvelle, la première instance de classe d objet HLA générique permettant de représenter le premier attribut de la classe oris devient aussi l identificateur de l instance oris. Les différentes relations sont représentées à la figure 1.15 dans le langage OCL 17 d UML Protocole de gestion des instances L ajout d une nouvelle instance inconnue ou d un nouvel attribut inconnu à une instance doit pouvoir être visible par toutes les plates-formes orisdis participantes. Il faut donc mettre à jour les différentes InformationBase des différentes plates-formes participantes afin de 17 OCL : Object Constraint Language 177

194 178 Figure 1.14 : Relation entre les éléments dans une simulation HLA / oris ClasseObjet +nom +identificateur classe attributs nattr AttributClasseObjet +nom +identificateur 1 données statiques 1 classe 1 * instances InstanceClasseObjet +identificateur instance attributs nattr AttributInstanceClasseObjet * +valeur base <<derive>> 0..1 orisinstance +nom +identificateur instance 1 attributs mattr AttributeoRisInstance 0;p generic statique nattr dynamique 0;p BaseAttributoRisInstance DynAttributoRisInstance +nom +nom 1 +valeur +valeur 1 * InstanceClasseObjet +identificateur instance attribut AttributInstanceClasseObjet +valeur 1 * instances a) b) <<derive>> 1 1 classe ClasseObjet +nom +identificateur classe 1 attribut AttributClasseObjet +nom +identificateur extension dynamique 1 Le prototypage interactif et collaboratif

195 Simulation participative distribuée en oris context orisinstance inv: self.attributs.statique->size = self.base.attributs->size inv: self.attributs.dynamique->size = self.generic->size inv: self.attributs.statique->forall( name=self.base.classe.attributes->exists(...)) inv: if (self.base->notempty) then self.identifier = self.base.identifier else self.generic->exists(identifier = self.identifier) endif Figure 1.15 : Contraintes appliquées sur les instances de classes et d attributs oris conserver une cohérence globale. Pour cela, nous avons défini un protocole d échange d informations afin de tenir compte de chaque modification apportée sur chacune des plates-formes. Les différents échanges sont résumés sur les deux diagrammes de séquence UML de la figure 1.16 de la page 182 et de la figure 1.17 de la page 184. Il s agit de fournir les moyens permettant de créer les fantômes correspondant aux réels, créés par les différents utilisateurs, et de permettre un échange bidirectionnel Interactions entre le réel et l orisrti Le cycle normal de vie d une instance réelle est représentée sur le diagramme de collaboration de la figure Il se décompose en cinq interactions. Les trois premières et la dernière sont à l initiative du réel et permettent d informer l orisrti des modifications apportées aux instances distribuées de la plate-forme locale. L avant dernière interaction de la figure, quant à elle, correspond à une interaction à l initiative d un utilisateur distant qui opère sur une représentation fantôme de l entité. L InformationBase joue le rôle des différents services annexes du RTIambassador, c est-à-dire que la base a été initialement remplie par les différentes informations (identificateurs de classes et d attributs) nécessaires en cours de simulation afin d établir les correspondances entre le nom et son identificateur associé. Les trois premières interactions (création, mise à jour et suppression) décrites ci-dessous procèdent d un fonctionnement normal d une application utilisant HLA. Création d une nouvelle instance d un réel La première interaction qui se produit entre un réel et l orisrti est la création de la nouvelle instance. L agent doit, lors de sa création, informer l orisrti qu il vient de se créer. Le 179

196 Le prototypage interactif et collaboratif Receiver est la partie de l orisrti chargée de recevoir les requêtes provenant des différentes entités de la plate-forme. Ce dernier peut alors interroger la base de données InformationBase afin de retrouver les différentes informations nécessaires à la déclaration de l entité au RTI HLA. À partir de ce moment, deux cas peuvent se produire : l instance provient soit d une classe connue avant le début de la simulation, soit d une classe inconnue. Dans les deux cas, l appel Get Class Id From Name retourne un identificateur de classe. Dans le premier cas, il s agit de l identificateur de la classe concernée et dans le second cas, il s agit de l identificateur de la classe générique. L étape Register Object Instance correspond à l enregistrement normal d une instance auprès du RTI et le Receiver peut alors enregistrer la nouvelle instance oris dans sa base de données (appel Create oris Instance). L appel à la création d une nouvelle instance retourne un identificateur qui est conservé au sein de l agent. Dorénavant, tous les appels de l agent feront référence à cet identificateur. Mise à jour de l état interne de l agent réel La mise à jour d un attribut s effectue très simplement. L agent effectue un appel oris Update Instance Attribute et transmet son identificateur ainsi que la liste des noms d attributs à mettre à jour et les valeurs associées. Le Receiver enregistre alors les nouvelles valeurs dans la base de données et récupère les identificateurs du RTI. Il peut ensuite effectuer l appel de mise à jour du RTI, Update Attribute Values. Suppression d un agent réel La suppression d une instance oris s effectue par l appel oris Remove Instance. Il est à noter que la suppression d une instance oris peut entraîner la suppression de plusieurs instances HLA. En effet, si des attributs ont été ajoutés dynamiquement alors, chacun de ces attributs s est vu attribuer une instance HLA. La suppression de l instance oris entraîne donc la suppression de tous ses attributs et de toutes les instances HLA qui leur sont associées. L appel du RTI Delete Object Instance permet d informer les autres fédérés de la suppression de l instance. Les deux interactions suivantes fournissent des services non usuels des applications basées sur HLA. 180

197 Simulation participative distribuée en oris Ajout d un attribut distribué à un agent réel L appel oris Add Instance Attribute permet d ajouter un attribut à l instance oris appelante. Deux cas sont envisagés : soit l appel Register Oris Instance Attribute dispose déjà de l attribut (déjà enregistré ou attribut déclaré dans le fichier FED) dans ce cas, aucune action n est effectuée, soit l appel ne trouve rien et la création d une nouvelle instance HLA est alors mise en œuvre (Register Object Instance). Cet appel renvoie un identificateur d instance de classe d objet HLA qui est ensuite utilisé pour enregistrer le nouvel attribut au sein de l instance (Create oris Instance Attribute). Enfin, la création du nouvel attribut est transmise aux autres plates-formes participantes à l aide d une interaction. Réception d une interaction d un agent fantôme distant L interaction d un utilisateur sur une entité fantôme peut provoquer l envoi d une interaction à son réel. La méthode Receive Interaction du FederateAmbassador est alors invoquée. Nous avons omis le Dispatcher pour plus de clarté mais la réception d une telle interaction génère l appel HLA Request Instance Attribute à l intention du Sender. Ce dernier reçoit l interaction, extrait les identificateurs et retrouve l instance oris ainsi que les attributs concernés par l interaction. À partir de ce moment, l appel de méthode ou l envoi du message vers l entité réelle concernée peut être effectué. Des mises à jour sont alors susceptibles d être générées si les modifications de l état interne du réel sont trop importantes Interactions entre l orisrti et le fantôme La figure 1.17 présente le pendant des interactions effectuées par le réel. Ces différentes interactions permettent de créer, modifier et supprimer l entité fantôme. De plus, le fantôme peut faire l objet d interactions de la part de l utilisateur, ce qui provoque l envoi d interactions vers l entité réelle. Toutes les interactions sont reçues par l intermédiaire du FederateAmbassador. Création du fantôme Lors de la réception d un appel Discover Object Instance, le Dispatcher appelle le Sender qui va créer la nouvelle instance fantôme. Cette instance reçoit en paramètre 181

198 Le prototypage interactif et collaboratif realagent Sender Receiver InformationBase RTIambassador FederateAmbassador oriscreateinstance():integer getclassidfromname() registerobjectinstance():integer createorisinstance() orisaddinstanceattribute() registerorisinstanceattribute() [result=1] registerobjectinstance() [result=1] createorisinstanceattribute() [result>=1] sendinteraction() orisupdateinstanceattribute() setorisinstanceattribute() gethlainstanceattribute() updateattributevalues() getorisinstanceattribute() hlarequestinstanceattribute() receiveinteraction() methodcall() orisremoveinstance() gethlaassociatedinstances() deleteobjectinstance() removeorisinstance() Figure 1.16 : Interactions entre les agents réels et l orisrti 182

199 Simulation participative distribuée en oris l identificateur du réel auquel il est associé, la base de données est alors mise à jour en conséquence. Mise à jour du fantôme L appel Reflect Attribute Values du FederateAmbassador est généré lorsque le RTI transmet une mise à jour d une instance réelle. Le Sender se charge de récupérer le nom de l instance, ainsi que le nom des différents attributs à mettre à jour, puis effectue l appel de méthode approprié. Ajout d un nouvel attribut à l instance réelle La fonction Receive Interaction permet aux différents fédérés de recevoir les modifications apportées à certaines instances d oris. Le Sender local va alors mettre à jour sa base de données en ajoutant le nouvel attribut ainsi que le nom de l instance associée. Enfin, il génère du code (via l appel parse()) permettant d enrichir le fantôme local à la machine. Suppression du fantôme La dernière interaction de la figure correspond à la suppression d une instance oris. La suppression du réel entraîne, bien sûr, la suppression de tous les fantômes. Le Sender effectue l appel explicite delete() sur l entité à supprimer puis ôte les informations de la base de données Remarques complémentaires Quelques remarques complémentaires sont à noter quant à la manière dont l ajout d attributs dynamiques est géré. En effet, lorsque l agent réel ajoute un nouvel attribut, le Receiver enregistre une nouvelle instance de la classe générique. Cet enregistrement provoque l appel d un Discover Object Instance sur les autres plates-formes. Dans le cas où l instance à créer correspond à une instance de la classe générique, cet appel est tout simplement ignoré. Toutes les manipulations de création de nouvelles entités génériques passent par l appel de la méthode Send Interaction. Une autre remarque est à formuler concernant la suppression des instances du côté de la plate-forme hébergeant le fantôme. Lorsque le fantôme est détruit, seules les informations du fantôme et non des attributs ajoutés sont supprimés. Ceci s explique par le fait que lorsque la plate-forme gérant le réel va supprimer l instance, elle va aussi supprimer toutes les instances génériques associées. Il y aura donc autant d appels à Remove Object Instance que d instances à supprimer. 183

200 Le prototypage interactif et collaboratif FederateAmbassador RTIambassador InformationBase Sender Receiver discoverobjectinstance() hlacreateinstance() <constructor> ghostagent createorisinstance() reflectattributevalues() hlaupdateinstanceattribute() getorisinstanceattribute() setorisinstanceattribute() methodcall() receiveinteraction() hlacreateinstanceattribute() [result=2] registerorisinstanceattribute() [result=1] createorisinstanceattribute() codetoparse() gethlainstanceattribute() sendinteraction() removeobjectinstance() hlaremoveinstance() getorisinstance() removeorisinstance() <destructor> Figure 1.17 : Interactions entre l orisrti et les agents fantômes 184

201 Simulation participative distribuée en oris La dernière remarque concerne les interactions depuis le fantôme vers le réel. En effet, un fédéré n a aucune connaissance des autres fédérés présents dans la simulation. Le fantôme ne peut donc pas savoir sur quel hôte se trouve le réel à interroger. Cependant, lorsqu un fédéré rejoint la fédération en effectuant l appel Join Federation Execution, un identificateur RTI::FederateHandle est retourné. Il correspond à l identificateur du fédéré et est unique dans toute la fédération. Cet identificateur est transmis en paramètre à chaque appel Register Object Instance et est enregistré dans la base de données. Un espace de routage particulier FederateRoutingSpace à une seule dimension federateid a été créé (figure 1.18). Chaque fédéré enregistre les souscriptions d interactions dans une région de cet espace de routage correspondant à l identificateur du fédéré. Ainsi, à chaque fois qu un fantôme envoie un message à un fédéré particulier, il l associe à la région du fédéré du réel qui devient alors le seul à le recevoir. (spaces (space FederateRoutingSpace (dimension federateid) )... ) Figure 1.18 : Espace de routage de réception des interactions par le fédéré Communication entre agents Nous avons présenté à la section de ce chapitre quels étaient les différents modes de communication offerts par la plate-forme oris pour le dialogue entre agents intelligents. Dans un modèle purement agent, les appels synchrones et les liens réflexes doivent être bannis dans toutes les communications entre agents autonomes. Par contre, les envois de messages en point à point ou par diffusion représentent des modes de communication tout à fait adaptés au paradigme agent. Le mode de communication point à point offert par oris peut facilement être reproduit sur l architecture distribuée puisque le destinataire est parfaitement connu. Le fantôme associé reçoit le message et le transmet à son réel qui peut alors le traiter. Le mode de communication par diffusion est plus difficile à gérer. En effet, l émetteur du message ne s adresse pas à un agent particulier mais à plusieurs destinataires qu il ne connaît pas forcément. Ces destinataires ne sont pas nommés explicitement et peuvent alors se trouver sur la plate-forme locale mais aussi sur d autres plates-formes distantes. Pour résoudre ce point, nous avons implémenté un agent spécifique dans l orisrti qui est sensible à tous les messages qui peuvent être diffusés sur sa plate-forme. La figure 1.19 présente l organisation des échanges de messages. 185

202 Le prototypage interactif et collaboratif agent 1 agent 2 agent récepteur agent 1S agent émetteur orisrti HLA/RTI agent fantôme agent orisdis émetteur/ récepteur agent 3 agent 4S orisrti Figure 1.19 : Communication entre les agents La partie supérieure de la figure présente la plate-forme émettrice du message. L agent 1 diffuse un message 18 à tous les agents rendus sensibles. Les agents réels sensibles présents sur cette plate-forme reçoivent le message (ici, l agent 1S, entouré d un cercle en pointillés, reçoit le message). Les agents fantômes ne sont, par contre, pas rendus sensibles aux messages mais un agent spécifique situé dans l orisrti reçoit également le message. Ce dernier a pour rôle de transmettre le message vers les autres plates-formes intéressées via une interaction (appel Send Interaction With Region). Du côté de la plate-forme réceptrice (partie inférieure de la figure), l agent 3 de l orisrti reçoit le message provenant du RTI (appel Receive Interaction), extrait les données, recrée le message et le diffuse localement. L agent réel 4S est également sensible à ce type de message et le reçoit. Détails techniques Une classe d interaction spécifique a été définie pour transmettre les messages diffusés par les agents. Chaque orisrti souscrit à cette classe d interaction et y associe une région (appel Subscribe Interaction Class With Region). Un espace de routage spécifique a également été défini. Sur chaque plate-forme, lorsqu un agent devient sensible (ou insensible) à un type de message, il informe un agent de l orisrti (l agent 2 ou 3 de la figure 1.19). Ce dernier 18 La diffusion est représentée par des arcs s éloignant de l émetteur. 186

203 Simulation participative distribuée en oris utilise cette information pour créer, modifier ou supprimer un extent à la région associée à cette interaction. La souscription est modifiée en conséquence. L extent associé au message est enregistré dans une table (couple type du message / extent). Cette information doit être définie de manière identique entre tous les participants. Puisque de nouveaux types de messages peuvent être créés en cours d exécution, la nouvelle valeur est déterminée en émettant une interaction avec une région spécifique. Cette région est connue et souscrite par tous. Elle est utilisée pour ajouter une nouvelle entrée à la table 19. La valeur associée au type de message est composée de deux parties. Une partie correspond au numéro du fédéré qui correspond à l identificateur renvoyé lors de l appel Join Federation Execution et un second nombre qui est incrémenté à chaque ajout d un nouveau type de message. En agissant de cette manière, on espère que deux platesformes n émettront pas le même type de message de maintenance simultanément car il n y a pas d algorithme de synchronisation. Cela ne pose aucun problème mis à part une redondance dans la liste des types de message (deux extent pour un type de message). Cette solution évite d émettre des interactions vers les plates-formes qui ne sont pas intéressées par certains types de messages Génération automatique de code Un autre point souvent délaissé par les programmeurs de plates-formes de réalité virtuelle concerne le code à produire pour distribuer une application. Aujourd hui, une application locale ne peut être distribuée sans programmation supplémentaire. Dans une application locale, les échanges de données entre le processeur et la mémoire s effectuent à un débit (bande passante et latence) sans aucune mesure avec un échange entre deux hôtes sur un réseau local. Dans une application répartie, les informations échangées ne circulent plus à très haut débit (réseau 10/100 Mb/s) et la latence est beaucoup plus importante (de 10 à plusieurs centaines de millisecondes). Il devient nécessaire de coder l application précisément vis à vis des échanges envisagés. Il ne sert à rien d envoyer les mises à jour mille fois par seconde si dix fois par seconde suffisent. Les concepteurs l ont généralement bien compris et comme nous l avons vu dans le second chapitre de la troisième partie, de nombreux mécanismes sont mis en œuvre pour adapter les échanges suivant le type de données à transférer. Par contre, le code à développer pour répartir une application peut s avérer très complexe à écrire. C est pourquoi nous avons établi un langage de script simple permettant de décrire comment échanger les données. Plutôt que de réécrire l application pour qu elle fonc- 19 Nous appelons cette interaction, une interaction de maintenance. Cette technique ressemble à ce qui est utilisé dans ATM pour effectuer des opérations de maintenance (OAM). Un canal spécifique (défini par un couple de valeur VPI et VCI) est utilisé pour véhiculer des informations de maintenance à travers le réseau. 187

204 Le prototypage interactif et collaboratif tionne de manière répartie, nous choisissons cette solution qui n est pas la plus efficace mais qui permet d obtenir un très bon compromis L architecture La partie de l architecture qui gère la génération de code est présentée sur la figure Cette dernière n est utilisée que lors du chargement de l application. Si de nouveaux éléments (de nouvelles classes, par exemple) doivent être apportés pendant l exécution, la création du code de répartition (appels de l orisrti, création des classes réel et fantôme) reste à la charge de l utilisateur. RTI HLA plate forme orisdis (4) orisrti (5) (5) Classe GhostObject (3) Générateur de code (3) orisdis.fed (1) (3) Classe Parseur XML (2) RealObject (1) Classe Object disclasseinfo.xml programme.ors Figure 1.20 : Génération automatique de code à partir de l application et du fichier de paramétrage Cette étape de génération de code est effectuée initialement lors du lancement de la plate-forme orisdis. Elle se décompose de la manière suivante : 1. Le parseur XML 20 lit le fichier de configuration (script) décrivant les choix de répartition choisis pour chaque méthode (disclassinfo.xml) et génère une structure interne utilisée par le générateur pour créer les classes réel et fantôme de chaque classe répartie, 2. Le générateur lit cette structure ainsi que le code source de l application (programme.ors), 20 XML : extensible Markup Language 188

205 Simulation participative distribuée en oris 3. En fonction de ces données, le générateur produit un fichier FED (orisdis.fed) décrivant le modèle objet initial utilisé par l application. Il génère également les classes dérivées (réel et fantôme) des classes partagées utilisées au sein de cette application 21, 4. L orisrti initialise le RTI en lui fournissant le fichier FED généré qui contient toutes les informations à échanger au moment du lancement du programme. Les différents services disponibles sont initialisés, 5. Les instances des classes réelles et fantômes peuvent dorénavant interagir avec l orisrti afin de répliquer les modifications aussi bien locales que distantes. Lors de l initialisation, le code de l application est analysé une première fois par le générateur de code pour transformer les appels de création d instances partagées et les appels de méthodes en des appels d instances de la classe réel associée. Le code est ensuite lu par la plate-forme oris qui crée véritablement l application. Cette modification automatique de l application ne peut être réalisée que si le programmeur respecte un certain nombre de règles 22 (pas d utilisation de callbacks, pas d utilisation directe des attributs d instance,... ) Sémantique pour la description du comportement L échange d information entre les fédérés ne se produit que lorsque l état interne d un réel évolue ou lorsqu un fantôme reçoit des interactions requérant une demande auprès du réel associé. Ces évènements résultent toujours de l appel d une méthode de l instance. L exemple de script XML présenté à la figure 1.21 explique au générateur de code comment les deux méthodes circle() et rotate() de la classe Object2d doivent être modifiées dans les classes dérivées du réel et du fantôme. <class name="object2d"> <module name="circle"> <parse /> </module> <module name="rotate"> <hla attribute="theta" transport="best-effort" /> <asynchronous /> </module> </class> Figure 1.21 : Exemple de code XML pour la génération automatique de code Le fichier est au format XML et décrit simplement, quelles actions, il faut entreprendre sur les différentes méthodes existantes. La description faite dans ce fichier est à la charge du concepteur de l application. La DTD 23 fournie en annexe décrit les règles à respecter pour 21 Les classes générées (réel et fantôme) héritent toutes les deux de la classe initiale. 22 On considère que le programmeur a correctement codé ses classes en fournissant des inspecteurs et des modificateurs. On peut ainsi être assuré qu un attribut d une instance ne sera pas directement modifié. Sinon, dans ce cas, il aurait fallu utiliser les liens réflexes d oris. 23 DTD : Document Type Definition 189

206 Le prototypage interactif et collaboratif que le fichier XML soit valide. Il permet également de valider le fichier à l aide d un outil approprié 24. Syntaxe Les différentes possibilités offertes par le script sont : parse : ce mot clé indique que la méthode du fantôme doit générer un appel vers l orisrti lui demandant de transmettre une interaction à destination du réel associé. Dans ce cas, on considère que le comportement du fantôme associé a été supprimé et que seul le réel peut répondre à une telle modification. duplicate : il signifie que le code de la méthode de la classe d origine doit être dupliqué pour le réel et le fantôme. Les deux instances réagissent de la même manière. Par exemple, une demande sur la position (getlocation()) du réel ou du fantôme peut se faire localement. Les valeurs sont approximatives lorsque la requête est effectuée sur le fantôme. asynchronous : le comportement de la méthode doit être le même que le réel. De plus, la modification doit générer un appel auprès du réel. Il s agit de la fusion de l appel parse et duplicate. Un changement d orientation d un agent (settheta()) peut être effectué localement pour accélérer le temps de réponse mais nécessite également que la modification soit répercutée sur le réel. hla : comme son nom l indique, il associe un attribut oris à un attribut du modèle objet de HLA. À l inverse de parse et asynchronous qui génèrent une interaction HLA, hla génère une mise à jour d attribut lorsqu il s agit d une méthode d un réel. Si l agent est un fantôme, cette option est ignorée 25 et seuls les trois mots-clefs précédents s appliquent. C est-à-dire que ses modifications ne sont pas systématiquement observées par tous puisqu un espace de routage peut lui être associé. Les différents attributs qui peuvent être associés à cet élément sont : attribute : donne le nom de l attribut HLA et oris concerné, transport : définit le mode de transport à utiliser (fiable ou non), ordering : définit si l attribut doit être associé à un horodatage, routingspace : précise si l attribut est associé à un espace de routage, deadreckon : associe un algorithme de dead reckoning à l attribut. La valeur associée précise l algorithme à utiliser, orisattr : si le nom de l attribut HLA diffère du nom oris, ce dernier permet de le préciser. 24 Nous avons utilisé l outil xmllint du projet XML pour valider nos fichiers XML à partir de la DTD. De plus, le parseur utilisé dans orisdis est un wrapper depuis la librairie libxml2, également de XML Gnome. 25 Nous rappelons qu un attribut HLA ne peut être la propriété que d un fédéré. Par conséquence, le fantôme ne peut générer d appel Update Attribute Values sur cet attribut. Il faudrait un mécanisme inverse plus spécifique qu une interaction. 190

207 Conclusion Ainsi, dans l exemple donné à la figure 1.21, la méthode circle dispose de la balise <parse>, ce qui signifie que l appel de la méthode est sérialisé. Si un fantôme effectue l appel, il le transmet au réel. Si c est un réel, il appelle la méthode de son parent puis envoie une interaction à l intention de tous les fantômes afin qu ils exécutent le même code. Pour la méthode rotate(), la balise <hla> indique que le réel associe son attribut oris theta à l attribut éponyme de l instance de classe associée. Son mode de transport est de type non fiable (best-effort). L utilisation du mot-clef <hla> dans au moins une des méthodes de la classe indique que l instance oris disposera d une instance de classe d objet HLA associée. Le second mot-clef <asynchronous> indique que l appel de méthode est sérialisé au niveau du fantôme et est transmis au réel. 1.3 Conclusion Dans ce chapitre, nous avons présenté notre plate-forme orisdis permettant de réaliser des applications de prototypage interactif à plusieurs utilisateurs. Cette architecture présente une double infrastructure composée de l architecture HLA et d une seconde architecture proposant l interface entre la plate-forme oris et le RTI HLA. Cette architecture, orisrti, se propose de fournir des services adaptés à la mise en œuvre d applications de prototypage interactif. Les différents services offerts sont la réplication de l état de l environnement, la prise en compte de la dynamicité de l évolution des états des attributs, l adaptation dynamique du modèle par l ajout de code en cours de fonctionnement et la communication entre agents. La réplication de l état de l environnement est établie par le modèle réel/fantôme. Il permet de définir une entité originale (le réel) qui dispose de toutes ses capacités réceptives et effectives, et des entités répliquas (les fantômes) qui reproduisent, avec plus ou moins de fidélité l état de l entité originale. Cette mise en œuvre permet de tenir compte des aspects temporels (latence) liés à l utilisation d un réseau de communication en autorisant le recours au dead reckoning. La dynamicité de l évolution des états des attributs apparaît lorsque l on souhaite offrir une totale interactivité avec des entités fantômes. L entité réelle dispose seule du pouvoir de décision de l évolution de son état. En cas de modification d un répliqua, il est donc nécessaire de recourir au réel. Cet aller-retour entre le réel et le fantôme pose des problèmes et nécessite une mise en œuvre spécifique. L évolution du modèle permet d éviter la phase de conception hors ligne. Offrir cette possibilité permet une totale maîtrise de l application en cours d exécution. Malheureusement, ces aspects n existent pas avec l architecture HLA. Nous avons donc mis au point une base de données associée à un protocole pour permettre de masquer cette déficience de HLA. La communication entre agents est rendue nécessaire par l utilisation de protocoles d échanges par messages simples ou évolués (actes de langage). Notre architecture masque 191

208 Le prototypage interactif et collaboratif totalement la répartition des agents réels vis à vis des échanges de messages. Notre technique est relativement optimale grâce à l association de régions à chaque type de messages pouvant être échangés. Une dernière partie est la génération automatique de code. En effet, développer une application distribuée n est pas forcément aisé et résulte généralement de la répartition d une application locale. Nous avons établi un langage de script simple, décrit suivant le format XML, permettant de modifier le code de l application et offrant une répartition optimale. Ainsi, différents mots-clefs permettent de préciser exactement le comportement désiré de chacune des méthodes de l agent. La disponibilité récente d une implémentation de RTI HLA nous a poussé à aller plus loin dans notre étude. En conséquence, nous proposons, dans le chapitre suivant, une extension à l API HLA permettant d offrir les aspects dynamiques recherchés. 192

209 Chapitre 2 Gestion dynamique de modèles sous HLA Dans le chapitre précédent, nous avons décrit comment l architecture d orisdis utilisait celle de HLA pour intégrer la distribution et la collaboration de différentes plates-formes oris. Nous avons noté que HLA se prêtait mal à nos objectifs du fait que le modèle objet était défini avant le début de l exécution de l environnement. De ce fait, ajouter ou modifier le modèle objet consistait à utiliser des artifices pour offrir ces fonctionnalités à la plate-forme et les masquer auprès du RTI. Fin octobre 2002, le prototype de RTI développé par l le a été fourni en open source. Nous avons alors décidé de nous baser sur cette implémentation du RTI afin d étendre l API officielle de HLA et intégrer de nouvelles fonctionnalités permettant de modifier le modèle objet pendant l exécution. La première partie de ce chapitre présente l architecture du CERTI et dans la seconde partie, nous présentons l API proposée pour permettre l ajout dynamique de propriétés au modèle objet. 2.1 Le CERTI Le développement du CERTI a débuté en 1996 et était destiné à l étude d une architecture de simulation fournissant des extensions sécuritaires [Bieber et al. 98]. 1 ONERA : Office National d Études et de Recherches Aérospatiales 2 CERTI : CERT (ONERA Centre de Toulouse) RTI 193

210 Gestion dynamique de modèles sous HLA L architecture L architecture du CERTI est divisée en trois composantes communicant à travers des sockets : Une librairie conforme à l Interface Specification de HLA qui est liée avec chaque fédéré (librti), Un processus local (RTIA), Un processus global (RTIG). La relation existant entre les différentes parties est résumée sur la figure 2.1. Fédéré 1 Fédéré 2 Fédéré 3 interface HLA librti librti librti socket UNIX RTIA 1 RTIA 2 RTIA 3 socket TCP RTIG WAN Figure 2.1 : L architecture du CERTI, d après [Bréholée et al. 02] La librairie La librairie librti est liée avec l application. Elle fournit toute l API de l interface specification de HLA. Son rôle est de transformer chaque appel au RTI ambassador en un appel de socket UNIX contenant la requête ainsi que tous les paramètres associés. Ce message est transmis au RTIA et attend la réponse en retour de l appel dans le cas où une exception est levée ou si la méthode dispose de paramètres de retour. À l inverse, les appels vers le federate ambassador sont reçus à travers la socket UNIX. Ces derniers sont extraits et traités lorsque l application laisse du temps via l appel tick() 3 pour effectuer la lecture. Le RTIA Le RTIA, RTI Ambassador, est un processus fonctionnant localement sur l hôte. Il reçoit les requêtes transmises par la librairie via la socket UNIX et les réponses transmises par le RTIG 3 Le service tick permet de laisser du temps au RTIA afin d exécuter les services reçus depuis le RTI. 194

211 Le CERTI via la socket TCP et/ou UDP. Il joue le rôle d intermédiaire entre le fédéré et le RTI. On peut le comparer au LRC 4 du RTI du DMSO. Le RTIA conserve un certain nombre d informations localement comme le modèle objet de la simulation. Le modèle objet conservé par le RTIA est identique à celui du RTIG. Les requêtes du type Get Attribute Handle ou Get Ordering Name peuvent alors être traitées par le RTIA sans avoir à recourir au RTIG. Cette manière d agir simplifie le nombre de requêtes et accélère le traitement de ces requêtes en évitant les échanges réseaux. Les autres requêtes plus complexes nécessitant des envois de messages vers d autres fédérés ou des traitements de la part du RTI doivent être transmises au RTIG. Le RTIG Le RTIG, RTI Gateway, est le serveur central jouant le rôle du RTI et vise deux objectifs. Premièrement, il permet l échange de données entre les différents fédérés en dialoguant avec les RTIA des différents fédérés participants. Deuxièmement, son architecture centralisée permet une implémentation simple des différents services du RTI. Tous les échanges effectués entre les fédérés sont reçus par le RTIG qui filtre les messages puis les route de manière appropriée. Par exemple, un appel à Update Attribute Values est transmis par le RTIA d un fédéré vers le RTIG. Ce dernier détermine quels fédérés sont impliqués par le message d après leur souscription. Il envoie alors un message Reflect Attribute Values à destination de tous les RTIA des fédérés retenus. Un scénario de transfert Un échange complexe de mise à jour d attributs est présenté à la figure 2.2. UAV représente l appel Update Attribute Values et RAV représente l appel Reflect Attribute Values. L appel de mise à jour est émis par l application (le fédéré 1). La librairie librti génère le message et le transmet au RTIA 1 du fédéré 1. Le RTIA reçoit le message et extrait les données. Si nécessaire, le RTIA 1 peut utiliser ces données pour mettre à jour des informations locales. Il génère un nouveau message réseau TCP et le transmet au RTIG. Ce dernier reçoit le message et renvoie un acquittement au RTIA 1 qui génère un autre acquittement à destination du fédéré 1. À partir de cet instant, l appel Update Attribute Values du fédéré 1 se termine. Il peut alors continuer l exécution de la simulation. Une fois le message reçu, le RTIG dispose de toutes les informations permettant de traiter le message et d émettre de nouveaux messages vers les destinataires. Il envoie alors 4 LRC : Local RTI Component 195

212 Gestion dynamique de modèles sous HLA Fédéré 1 RTIA RTIG RTIA Fédéré 2 UAV UAV ok RAV tick ok RAV ok Figure 2.2 : Exemple de scénario de transfert de données (d après [Bréholée et al. 02]) un message Reflect Attribute Values vers tous les fédérés concernés. Ce message peut être transmis soit par un échange multicast 5 soit par une socket TCP point à point. De plus, le message Update Attribute Values peut être personnalisé suivant les souscriptions effectuées par le fédéré demandeur. Le message du RTIG est reçu par le RTIA 2 du fédéré 2 et est conservé dans une file d attente 6. Lorsque le fédéré 2 fait appel à la méthode tick(), la librairie librti demande, au RTIA 2 du fédéré, à recevoir les messages en attente. L appel Reflect Attribute Values est effectué sur le Federate Ambassador du fédéré puis un acquittement est transmis au RTIA Le modèle objet du CERTI Le modèle objet du CERTI est commun au RTIA et au RTIG puisque les deux applications doivent connaître le modèle objet pour effectuer des lectures d informations. Le diagramme de classes décrit ci-après présente l ensemble de la création et de la gestion du modèle objet de l application. Une amélioration apportée à la gestion des interactions modèle objetinstances de classes d objets HLA est présentée ensuite. Une partie du diagramme de classes du CERTI est présentée sur la figure 2.3. Le modèle objet est stocké dans deux parties distinctes. Une partie gère les classes d objets et une autre partie gère les classes d interaction. Les classes ObjectClassSet, ObjectClass et 5 L échange multicast devait fonctionner auparavant mais de nombreuses modifications ont eu lieu dans la bibliothèque CERTI. Depuis, l échange multicast ne fonctionne plus mais sera certainement résolu dans une future version. 6 Deux files sont disponibles suivant que le message est horodaté ou non. 196

213 Le CERTI AuditLine ObjectAttribute 1 currentline 0..* attributestate SocketServer AuditFile SecurityLevel FederateLevelList <<list>> Object RTIG_SocketServer 1 1 Audit 1 FedLevelList <<list>> 0..* objectset <<list>> server 1 server SecurityServer 1 1 server 1 server 1 server ObjectClassSet <<list>> ObjectClass 0..* ObjStack 0..* <<uses>> CDiffusion InteractionSet <<list>> Interactions 1 Interaction RootObject IntStack 0..* RootObj 1 <<list>> objectclasses 1 FedParser <<list>> Publishers 0..* AttStack 0..* <<list>> attributeset ObjectClassAttribute <<list>> 0..* Subscribers Subscribers Publishers 0..* 0..* Subscriber Publisher Classes d objets <<list>> parameterset 0..* ParStack 0..* Parameter Classes d interactions Figure 2.3 : La gestion du modèle objet dans le CERTI ObjectClassAttribute permettent de conserver le modèle objet des classes d objet tel qu il a été décrit dans le fichier FED. De la même manière, les classes InteractionSet, Interaction et Parameter conservent le modèle objet des classes d interaction. Ces instances de classes sont créées lors de l initialisation de la fédération. C est-à-dire qu elles sont créées lorsque le fichier FED est lu. Une instance de la classe FedParser se charge de créer une instance de la classe RootObject et toutes les instances des classes d objets et d interactions. Le diagramme de classes présenté sur la figure 2.3 présente quelques inconvénients. En effet, les instances de classes d objet HLA sont gérés par la classe ObjectClass. Une amélioration que nous avons apporté est présentée à la figure 2.4. Les instances de classes sont gérées directement par la classe ObjectSet. Les relations existant entre les classes d objet HLA et les instances HLA sont répercutées par des relations directes (les associations source). 197

214 Gestion dynamique de modèles sous HLA ObjectSet 0..* Object 0..* ObjectAttribute RootObject instances 0..* ObjectClassSet sons 0..* parent 1 source ObjectClass 1 source 1 ObjectClassAttribute 0..* 0..* 0..* 0..* Subscriber Publisher Figure 2.4 : Le nouveau modèle objet du CERTI 2.2 Extension de l API pour un modèle objet dynamique HLA est une architecture très prometteuse pour la simulation mais son modèle objet statique pose des problèmes pour les applications nécessitant de modifier les données devant être échangées. orisdis ou Bamboo [Watsen et al. 98a] nécessitent de pouvoir ajouter de nouveaux attributs à échanger en cours de fonctionnement. Pour cela, nous avons étudié l API de HLA et avons proposé une nouvelle extension de l API afin de permettre un contrôle du modèle objet pendant l exécution de l application [Raulet et al. 03a]. Cette nouvelle API a été intégrée dans une version du CERTI afin de valider son fonctionnement Description du modèle objet Le modèle objet des classes d objet et d interaction qui est utilisé par la fédération est décrit dans le fichier FED. La figure 2.5 présente la structure du fichier. Une classe d objet est décrite par son nom et l ensemble des attributs qui la compose. Chaque attribut de cette classe est paramétré par son nom, son mode de transport (fiable ou best-effort), sa gestion temporelle (ordre de réception ou horodatage) ainsi qu un paramètre optionnel décrivant à quel espace de routage l attribut se rattache. La classe d interaction est décrite d une manière différente. En effet, un objet a une granularité au niveau de l attribut tandis qu une interaction a une granularité au niveau de la 198

215 Extension de l API pour un modèle objet dynamique ;; Description d une classe d objet. ;; (class <name> ;; (attribute <name> <transportation> <ordering> [<space>]) ;;... ;; ) (class entity (attribute location best_effort receive) ) ;; Description d une classe d interaction. ;; (class <name> <transportation> <ordering> [<space>] ;; (parameter <name>) ;;... ;; ) (class splat reliable timestamp (parameter target) ) Figure 2.5 : Description du modèle objet classe. Cette différence fait que la classe d interaction est décrite par son nom, son mode de transport, sa gestion temporelle, son espace de routage optionnel et une liste de paramètres décrits par leur nom. Les paramétrages s appliquent au niveau de la classe et non plus au niveau de chaque sous-élément Modification du modèle objet par l API existante HLA dispose de méthodes permettant de modifier le paramétrage des éléments du modèle objet mais pas le modèle objet en lui-même. Les méthodes de modification des classes d objet sont : Change Attribute Transportation Type : change le mode de transport d un ensemble d attributs, Change Attribute Order Type : change le mode d ordonnancement d un ensemble d attributs, Change Interaction Transportation Type : change le mode de transport d une classe d interaction, Change Interaction Order Type : change le mode d ordonnancement d une classe d interaction. Il est à noter que les méthodes modifiant le mode de transport et d ordonnancement d un ensemble d attributs agissent au niveau de l instance tandis que les méthodes de modification des modes d une classe d interaction agissent au niveau de la classe. Autre point à noter, aucune modification des informations optionnelles de l espace de routage n est possible. Celui-ci est figé dans le modèle objet et seules des régions associées aux espaces de routage peuvent être créées ou supprimées. 199

216 Gestion dynamique de modèles sous HLA Modification de l arbre du modèle objet Le modèle objet de HLA est simple puisqu il est décrit par un arbre d héritage simple 7. Pour permettre l ajout de nouvelles classes d objet ou attributs, nous avons ajouté deux méthodes (Add Object Class et Add Attribute) à l API existante. La même opération a été réalisée pour ajouter de nouvelles classes d interaction et de nouveaux paramètres Classe d interaction Nous souhaitons pouvoir modifier l arbre d héritage de la classe d interaction pour ajouter des éléments classes et paramètres en cours de fonctionnement. Les possibilités de réordonner les classes d interactions ou de supprimer des classes et/ou paramètres n ont pas été examinées puisqu elles ne présentent pas vraiment d intérêt de notre point de vue. Il en est de même vis à vis de notre application. Seules les fonctionnalités permettant l ajout de classes à l arbre existant ainsi que l ajout de paramètres à des classes existantes sont proposées. Les nouvelles méthodes disponibles sont présentées à la figure 2.6. addinteractionclass() discoverinteractionclass() subscribeinteractionclass() getinteractionclasshandle() addparameter() discoverparameter() getparameterhandle() fédéré 1 RTI fédéré 2 Figure 2.6 : Ajout au modèle d interaction Ajout d une classe d interaction L ajout d une classe d interaction s opère par l appel de la méthode Add Interaction Class. Cette méthode a pour objectif d ajouter une nouvelle classe vide à l arbre d héritage. 7 L héritage multiple n est pas permis du fait des complications qu il apporterait à la gestion des abonnements et souscriptions. D autres problèmes connus de la programmation orientée objet apparaîtraient tels que le même nommage d un attribut dans deux branches héritées. 200

217 Extension de l API pour un modèle objet dynamique Elle peut s insérer n importe où dans l arbre. Cette information est précisée par un identificateur d interaction donnant le nom du parent. Si celui-ci correspond à interactionroot alors il est rajouté à la racine. Cet appel est transmis au RTI qui transfère l information aux fédérés concernés. Le choix des destinataires est effectué par rapport à leur souscription. Le message Discover Interaction Class n est transmis au fédéré destinataire que s il a souscrit à la classe parente ou si la classe parente correspond à interactionroot. Ajout d un paramètre Pour ajouter un paramètre à une classe existante ou à une classe nouvellement créée, la méthode est la même. Il faut que le fédéré récupère un identificateur de la classe choisie (Get Interaction Class Handle). Il peut alors ajouter un nouveau paramètre via l appel Add Parameter. L appel est transmis au RTI qui ne transfère l information aux autres fédérés que s ils ont souscrit à la classe concernée. Ainsi, si une nouvelle classe a été créée auparavant, il faut que le fédéré fasse appel à Subscribe Interaction Class pour recevoir les modifications apportées aux paramètres de cette classe. Cependant, l ajout d un nouveau paramètre peut se produire alors que les autres fédérés n ont pas tous eu le temps de souscrire ou que le fédéré n a pas encore rejoint la fédération. Le RTI conserve donc toutes les modifications apportées à une classe et transmet ces informations lorsqu un fédéré souscrit à cette classe d interaction Classe d objet L ajout d une nouvelle classe d objet au modèle objet s effectue de la même manière que pour la classe d interaction. Le processus change du côté du récepteur lorsque celui souhaite recevoir des informations sur les attributs ajoutés. La figure 2.7 présente les échanges effectués lors de l ajout d un nouvel attribut à une nouvelle classe. Ajout d un attribut L ajout d un attribut (Add Attribute) s effectue de la même manière que l ajout d un paramètre pour le fédéré émetteur. Cependant, le fédéré récepteur ne peut pas forcément souscrire à la classe avant de recevoir des informations liées à la classe. Si la classe dispose déjà d attributs, cela ne pose aucun problème. Par contre, s il s agit d une classe nouvellement créée, elle ne dispose pas d attribut. Si le fédéré récepteur essaie de souscrire 201

218 Gestion dynamique de modèles sous HLA addobjectclass() discoverobjectclass() getobjectclasshandle() addattribute() discoverattribute() getattributehandle() Figure 2.7 : Ajout au modèle d objet à la classe sans préciser d attributs, cela revient à se désabonner de la classe 8. Le RTI envoie un message Discover Attribute si le fédéré a déjà souscrit à cette classe ou à la classe parente Erreurs levées et valeurs par défaut Le code correspondant aux prototypes des fonctions est fourni en annexe page 217. Les principales erreurs pouvant être levées lors de l appel de ces méthodes sont : Object Class Not Defined ou Interaction Class Not Defined : l identificateur du parent fourni en paramètre n existe pas, Object Class Already Defined ou Interaction Class Already Defined : le nom de classe à créer existe déjà, Attribute Already Defined ou Parameter Already Defined : le nom de l attribut / paramètre à créer existe déjà. De plus, lorsqu un nouvel attribut ou une nouvelle interaction est ajouté au modèle objet, les valeurs sont initialisées avec des caractéristiques par défaut. Ainsi, le mode de transport est placé à fiable (reliable) et l ordre de réception est non horodaté (receive). Ces valeurs peuvent être modifiées par les appels usuels vus précédemment. Par contre, si l on souhaite associer un espace de routage à un attribut ou à une interaction, l API n a pas prévu de méthodes. Nous examinons dans la section suivante comment nous pourrions offrir ces possibilités. 8 Selon la norme, faire un Subscribe Object Class Attributes sans attribut revient à faire un Unsubscribe Object Class [Department of Defense 98a]. Nous aurions pu modifier le comportement de la méthode dans le cas où la classe concernée ne contient pas d attribut mais nous n avons pas retenu une telle solution car cela nécessite de modifier le comportement de méthodes et crée ainsi des cas particuliers plus complexes à gérer. 202

219 Conclusion Modification de l espace de routage Les méthodes que nous avons proposé précédemment ne tiennent pas compte du routage. On pourrait réécrire les mêmes méthodes en ajoutant un paramètre permettant de déterminer quel espace de routage on souhaite associer à l attribut ou à l interaction. Nous proposons une autre solution qui offre la possibilité de modifier n importe quel attribut/interaction pendant la simulation. Ce sont les méthodes complémentaires à celles présentées à la section de ce chapitre. changeattributeroutingspace() notifyattributeroutingspacemodification() changeinteractionroutingspace() createroutingspace() notifyinteractionroutingspacemodification() discoverroutingspace() Figure 2.8 : Modification de l espace de routage Il est nécessaire de créer trois méthodes qui sont présentées à la figure 2.8. Les deux premières, Change Attribute Routing Space et Change Interaction Routing Space permettent de modifier l espace de routage associé à un attribut ou une interaction. La dernière, Create Routing Space permet de créer un espace de routage non défini dans le fichier FED. Les deux méthodes permettant de changer l attribut seraient à utiliser avec des attributs nouvellement créés. En effet, nous sommes conscients qu utiliser ces méthodes sur des attributs déjà fonctionnels pourrait poser quelques problèmes. De plus, ces méthodes provoquent les appels Notify Attribute Routing Space Modification et Notify Interaction Routing Space Modification afin de rendre compte aux autres fédérés de la modification apportée. Cela permet d effectuer les appels Register Object Class With Region et Send Interaction With Region correctement. 2.3 Conclusion Les aspects dynamiques recherchés par certaines plates-formes telles que Bamboo ou oris- Dis ne permettent pas l utilisation de l architecture HLA sans recourir à des artifices masquant les déficiences de l architecture. Nous avons étudié et mis en œuvre une extension 203

220 Gestion dynamique de modèles sous HLA de l API HLA afin d autoriser la modification du modèle objet en cours de fonctionnement. Ainsi doté, l API s ouvre vers de nouvelles applications non envisageables auparavant. Dans une première partie, nous avons présenté le CERTI et son architecture. Le modèle objet est conservé dans une hiérarchie de classes qui est facilement accessible. Quelques améliorations ont été apportées afin de mieux modéliser la hiérarchie inter-composants mais la grande évolution est l ajout de nouvelles méthodes permettant l accès à ce modèle objet interne. Le comportement de ces méthodes au niveau du RTI (RTIA) a été décrit en respectant les comportements déjà établis pour les autres services. Nous avons défini des méthodes permettant, d ajouter de nouvelles classes d objet et d interaction et autorisant également l ajout de nouveaux attributs et paramètres. La suppression de classes, d attributs ou de paramètres n a pas été envisagée car cela nous pose moins de problèmes il suffit d ignorer les ajouts. De plus, une proposition non implémentée d autres extensions, permettant la modification de l espace de routage, est présentée dans la dernière partie de ce chapitre. 204

221 Chapitre 3 Exemple en orisdis Ce chapitre fournit un exemple simple montrant le fonctionnement de l architecture orisdis. Il s agit de montrer l intégration de HLA au sein de la plate-forme oris ainsi que les aspects dynamiques. Il permet de valider certaines fonctionnalités de l architecture orisdis telles que décrites dans le premier chapitre de cette partie. On vérifie également que les aspects dynamiques sont restitués à travers les nouveaux services apportés à l implémentation du CERTI. 3.1 Existence de l agent et mise à jour de ses états Cet exemple est basé sur la classe de base oris Object2d. Cette classe propose des fonctionnalités basiques permettant de représenter, sur un plan, des objets à deux dimensions. On peut déplacer un objet (setlocation() 1, setx(), sety(),... ), lui donner une représentation (circle(), polygone(),... ), etc. La figure 3.1 représente le diagramme de classe représentant l héritage généré entre les classes. Les classes RealObject2d et GhostObject2d sont les deux classes permettant de communiquer avec l architecture orisdis. Ainsi, l application ne doit pas créer d instances de la classe Object2d sous peine de ne pas la voir répliquée sur les autres plates-formes. À l instar, seule la classe RealObject2d doit être employée, les instances GhostObject2d étant générées automatiquement. 1 Nous utilisons cette notation et non celle utilisée par HLA car certaines méthodes employées dans le code utilisent le caractère souligné ( ). 205

222 Exemple en orisdis Object2d setcolor() setx() sety() DeadReckon init2() update2() RealObject2d int _handle setcolor() setx() sety() GhostObject2d int _handle setcolor() setx() sety() Figure 3.1 : Diagramme de classe entre les classes générées et les classes de base Génération automatique de code Afin de simplifier le développement de l application, nous utilisons un fichier XML permettant à l orisrti de générer le fichier FED nécessaire au RTI ainsi que la génération du code des classes réel et fantôme de l application. La figure 3.2 présente la description de trois méthodes de la classe Object2d. Le fichier FED généré est présenté sur la figure 3.3 et le code généré est décrit dans les parties suivantes. <distributed> <class name="object2d"> <!-- This federate attribute is needed by orisrti.--> <hla attribute="federate" transport="reliable" ordering="timestamp" /> <function name="setx"> <hla attribute="x" transport="reliable" ordering="timestamp" deadreckon="deadreckon_2"/> </function> <function name="sety"> <hla attribute="y" transport="reliable" ordering="timestamp" deadreckon="deadreckon_2"/> </function> <function name="setcolor"> <hla attribute="color" transport="reliable" ordering="timestamp" /> </function> </class> </distributed> Figure 3.2 : Fichier de description en XML Interaction sur le réel La classe RealObject2d redéfinit toutes les méthodes décrites dans le fichier XML. À chacune d elle est associé un appel de méthode permettant d informer l orisrti en cas de 206

223 Existence de l agent et mise à jour de ses états ;; This file was generated by the orisrtiparser1 (fed (federate "fed" "Public") (objects (class "Object2d" (attribute "federate" FED_RELIABLE FED_TIMESTAMP) (attribute "x" FED_RELIABLE FED_TIMESTAMP) (attribute "y" FED_RELIABLE FED_TIMESTAMP) (attribute "color" FED_RELIABLE FED_TIMESTAMP) ) ) (interactions (class "GhostRequest" FED_RELIABLE FED_TIMESTAMP (sec_level "Public") (parameter "object") (parameter "name") (parameter "value") (parameter "federate") ) ) ) Figure 3.3 : Fichier FED généré automatiquement et servant à initialiser le RTI changement important 2. La première partie de la figure 3.4 montre l appel à l orisrti ainsi que l appel de la méthode du parent celle qui réalise réellement l action. Cela représente l interaction 4 du réel vers le fantôme comme décrit à la figure 1.6 de la page 168. void RealObject2d::setColor(string color) { // Inform orisrti from color change and update himself. RtiUpdMessage m = new RtiUpdMessage(_handle, "color", color, -1); m->broadcast(); Object2d::setColor(color); } // void GhostObject2d::_setColor(string value, int me) { Object2d::setColor(value); } Figure 3.4 : Exemple de code généré pour la classe du réel Du côté du fantôme, une méthode spécifique setcolor() est chargée de réceptionner la requête et d effectuer les traitements nécessaires pour appliquer les changements sur le fantôme. La figure 3.5 présente le cheminement effectué lors d une requête du réel. 2 Ici, l appel de méthode est remplacé par l envoi d un message par diffusion. Un composant de l orisrti est sensible à ce message et le traite conformément à la description faite dans le premier chapitre de cette partie. 207

224 Exemple en orisdis setcolor() Object2d::setColor() Object2d::setColor() _setcolor() RealObject2d GhostObject2d Figure 3.5 : Cheminement d appels de méthodes à partir d une requête sur le réel Interaction sur le fantôme Comme pour l interaction depuis le réel, la classe GhostObject2d redéfinit toutes les méthodes pouvant être employées. La première partie de la figure 3.6 montre le code de la méthode setcolor() du fantôme qui ne diffère que sur le type du message. Ce message est ensuite transmis à la méthode setcolor() du réel seconde partie de la figure qui, dans ce cas, effectue le même rôle qu une interaction originaire du réel. void GhostObject2d::setColor(string color) { // Inform orisrti from color change requirement. RtiReqMessage m = new RtiReqMessage(_handle, "color", color); m->broadcast(); } // void RealObject2d::_setColor(string value, int me) { setcolor(value); } Figure 3.6 : Exemple de code généré pour la classe du fantôme Le cheminement d une interaction originaire du fantôme est résumé sur la figure 3.7. Cette manière d agir évite les appels en boucle que pourrait provoquer le fantôme en effectuant sa requête. _setcolor() setcolor() setcolor() Object2d::setColor() Object2d::setColor() _setcolor() RealObject2d GhostObject2d Figure 3.7 : Cheminement d appels de méthodes à partir d une requête sur le fantôme Interaction sur un état dynamique En ce qui concerne les mises à jour des attributs des états dynamiques, le fonctionnement est très similaire. Comme le fantôme se met à jour puis envoie sa requête, il est important 208

225 Ajout dynamique de fonctionnalités à l agent qu il ne se mette pas à jour lorsque le réel renvoie la mise à jour. Pour cela, un attribut supplémentaire est transmis (me) l identifiant du fédéré 3 et permet de déterminer s il est l initiateur ou non du message. L exemple de la figure 3.8 montre le code pour la mise à jour de la position en y de l entité. void RealObject2d::sety(string value, int me) { int y; valueparse(y, value); // Convert string value to its true type. execute { sety(y); if ( deadreckon_update_2(location[0], location[1])!= 0 ) { RtiUpdMessage m = new RtiUpdMessage(_handle, "y", valuedump(location[1]), me); m->broadcast(); } } } // void GhostObject2d::sety(string value, int me) { if (!me) { int y; valueparse(y, value); // Convert string value to its true type. execute { sety(y); deadreckon_update_2(location[0], location[1]); // Delete update } } } Figure 3.8 : Blocage de la boucle à l aide d un attribut Le bloc execute permet de rendre le code atomique. La classe DeadReckon offre une méthode deadreckon update 2() qui met à jour l algorithme de dead reckoning et renvoie 0 si la modification n apporte pas de mise à jour. Ici, pour le fantôme, on annule l effet de la valeur sur le dead reckoning en effectuant l appel et en n exploitant pas le résultat de cet appel. 3.2 Ajout dynamique de fonctionnalités à l agent oris permet l ajout, la modification ou la suppression de code à tout moment durant le fonctionnement de l application. Pour conserver ces mécanismes, nécessaires à la réalisation d un outil de prototypage interactif et coopératif, nous avons dans un premier temps réalisé une encapsulation des identifiants 4. Afin de profiter au mieux des différents services offerts par l architecture HLA, nous avons ajouté des services au CERTI 5. 3 Cet identifiant est renvoyé par le RTI lorsque le fédéré rejoint la fédération via l appel Join Federation Execution. 4 Ceci est décrit dans le premier chapitre, section 1.2.3, de cette partie. 5 Ces services font l objet du deuxième chapitre de cette partie. 209

226 Exemple en orisdis Dans cet exemple, nous souhaitons offrir la possibilité de modifier l objet ici, un cercle en lui permettant de changer de taille. Pour cela, nous ajoutons les méthodes setsize() et setsize() à chacune des deux classes réel et fantôme (Figure 3.9). Object2d setcolor() setx() sety() DeadReckon init2() update2() RealObject2d int _handle setcolor() setx() sety() setsize() GhostObject2d int _handle setcolor() setx() sety() setsize() Figure 3.9 : Ajout de fonctionnalités à la classe Pour réaliser l ajout, le code doit être écrit et placé dans une chaîne de caractères. Ensuite, il suffit d envoyer un message contenant le nom de la classe HLA à modifier, le nom du nouvel attribut et la chaîne de caractères contenant le code à ajouter. Ce code est traité par chacune des plates-formes participant à l exécution. Le code correspondant à l exemple est présenté sur la figure Conclusion Nous avons, à travers cet exemple, testé le bon fonctionnement de l architecture orisdis. De plus, cet exemple nous montre qu il est possible de réaliser simplement une application distribuée en utilisant les fonctionnalités de génération de code. Enfin, cette application est rendue interactive grâce à la version modifiée du CERTI. 210

227 Conclusion // // This small code subset adds new features to existing testappli.ors. // Real/GhostObject can then grow in size. // execute { } string str = " void RealObject2d::setSize(float size) { RtiUpdMessage m = new RtiUpdMessage(_handle, \"size\", valuedump(size), -1); m->broadcast(); circle(size, true); } void RealObject2d::_setSize(string str, int me) { float size ; valueparse(size, str); // Convert string value to its true type. setsize(size); } void GhostObject2d::setSize(float size) { RtiReqMessage m = new RtiReqMessage(_handle, \"size\", valuedump(size)); m->broadcast(); } void GhostObject2d::_setSize(string str, int me) { float size ; valueparse(size, str); // Convert string value to its true type. circle(size, true); } "; RtiAddMessage m = new RtiAddMessage("Object2d", "size", str, 1); m->broadcast(); Figure 3.10 : Code dynamiquement ajouté à la classe 211

228 Exemple en orisdis 212

229 Conclusion et perspectives Nos travaux portent sur la définition d une architecture de communication permettant le développement d outils de prototypage interactif et collaboratif dans un cadre de réalité virtuelle. L objectif est d offrir aux utilisateurs tous les moyens leur permettant de collaborer et d interagir le plus naturellement possible avec l environnement. Notre approche a commencé par l étude du contexte. Elle a mis en avant le besoin d une forte interactivité offerte par la réalité virtuelle ainsi qu une grande autonomie à l image des agents qui peuplent l environnement. Ces deux points forment la base de notre approche. Tous nos développements doivent respecter ces principes afin d offrir à l utilisateur final, un outil de prototypage fortement malléable. Notre problématique concerne la répartition de cet outil de prototypage afin d offrir une application multi-utilisateurs. À partir de ces trois points-clefs, nous avons entamé un état de l art où nous analysons chaque couche intervenant dans le processus de communication distante entre les utilisateurs, et de mettre en avant les étapes délicates suivant le type d application ciblé. Dans la première partie, nous avons constaté la grande hétérogénéité des systèmes réseaux disponibles ainsi que les protocoles associés. Nous n avons pas mis en œuvre de mécanismes de bas niveau dans notre architecture mais cette partie nous a montré des points essentiels qui justifient les différentes approches prises dans les couches de plus haut niveau. Ainsi, la bande passante, la latence, la fiabilité et la qualité de service sont des notions maîtrisées et dont les problèmes sous-jacents sont dorénavant connus. Différents paradigmes possibles ont ensuite été analysés à travers les différentes implémentations disponibles (MPI, Linda, CORBA,... ). Nous retenons principalement que chaque paradigme s adapte à un type d architecture matériel et à un type d application logicielle. L architecture CORBA a retenu notre attention car elle apporte un grand nombre de services. Malheureusement, les aspects temps réel ne seront utilisables que lorsque les développeurs proposeront des implémentations compatibles avec la toute nouvelle norme 213

230 Conclusion et perspectives CORBA 3.0. Dans la seconde partie, nous avons étudié des architectures et des techniques de très haut niveau dédiées aux simulations distribuées. Dans ce contexte, l armée américaine propose principalement deux architectures, DIS et HLA, orientées vers la simulation militaire. Si DIS s avère trop spécifique au domaine militaire, HLA, quant à elle, est l architecture qui est le pendant de celle de CORBA pour les applications distribuées. L architecture CORBA propose un ensemble de services généraux pour tout type d applications distribuées tandis que HLA propose des services dédiés aux simulations distribuées. Pour finir l état de l art, nous avons détaillés les architectures et techniques liées à la réalité virtuelle distribuée. Il s agissait de reconnaître les réels besoins exprimés dans les différentes implémentations disponibles. Nous retrouvons, dans ce chapitre, des liens forts avec les différents aspects des réseaux et protocoles étudiés dans la première partie. Il apparaît qu une prise en compte du type de la donnée sa sémantique dans les échanges augmente l interactivité et l immersion des utilisateurs. Il apparaît très clairement qu on doit traiter les données différemment suivant leurs utilisations au sein du modèle de l entité associée. Ces constatations sont les motivations qui nous ont conduit à définir une nouvelle architecture de réalité virtuelle distribuée appelée orisdis. Cette architecture offre à la fois une grande interactivité et une haute dynamicité. L architecture est composée de deux couches, le RTI HLA et l orisrti. Le RTI HLA offre des services adaptés à l échange de données pour la simulation et la réalité virtuelle tandis que l orisrti adapte ces services aux besoins spécifiques du prototypage virtuel. L orisrti a donc été conçu pour permettre une représentation immersive identique ou très proche quel que soit l hôte sur lequel se trouve l utilisateur. Il s agit de pouvoir reproduire les interactions inter-entités ainsi que les interactions entités-utilisateurs de manière transparente quelle que soit la localisation de ces entités. Ces dernières doivent être envisageables quelle que soit la plate-forme qui simule le véritable comportement de l entité. Ainsi, notre modèle réel/fantôme tient compte de l état dynamique ou non de l attribut géré. Cependant, comme nous l avons introduit dans notre dernière partie, le prototypage du modèle doit pouvoir s effectuer complètement de façon numérique sans aller-retour avec la phase de conception. Des divergences se produisent dans notre architecture entre la couche RTI HLA et la couche orisrti. En effet, l architecture HLA est destinée à la simulation militaire et ne propose aucun mécanisme permettant de modifier le modèle objet de l application. Nous avons donc établi une correspondance entre le modèle objet dynamique de l outil de prototypage et le modèle objet du RTI HLA. Réalisée à partir d une base de données et d un protocole d échange, cette technique permet de masquer ce manque. La disponibilité récente en open source d une implémentation du RTI HLA le CERTI nous a incité à développer une extension de l API existante. C est pourquoi nous proposons, dans un dernier chapitre, une mise en œuvre d un modèle objet dynamique. Cet 214

231 Conclusion et perspectives API permet d ajouter de nouvelles classes ainsi que de nouveaux attributs et paramètres. Nous explorons également la possibilité d ajouter de nouveaux espaces de routage dans le modèle du RTI. Cette dernière n est qu une proposition puisqu à l heure actuelle, ce service n est pas implémenté dans le CERTI. En perspective de ce travail de thèse, nous envisageons de mieux intégrer le travail réalisé au sein de la plate-forme oris. Actuellement, cette architecture n est fournie que sous la forme d une bibliothèque et de code interprété par la plate-forme. Cette intégration permettrait une amélioration des performances de l architecture en évitant le code interprété et en autorisant un accès direct aux variables des entités. Enfin, il nous semble important de continuer à participer activement au développement du CERTI. Nous y avons déjà apporté de nombreuses améliorations (gestion mémoire, orientation objet, indépendance des modules, ajout de fonctionnalités) mais il reste beaucoup de fonctionnalités à ajouter (services non implémentés, MOM 1 ). Le CERTI nous semble très prometteur car, à notre connaissance, il s agit de la seule implémentation totalement libre et disponible à travers le monde. Cette ouverture permet à chacun d expérimenter de nouvelles solutions et ainsi offrir des améliorations pouvant profiter à tous. 1 MOM : Management Object Model. C est une partie du modèle objet permettant de surveiller et de contrôler le fonctionnement du RTI pendant son fonctionnement. 215

232 Conclusion et perspectives 216

233 Annexes Extensions ajoutées au RTI Ambassador class RTIambassador {... // Object class modifications void addobjectclass( ObjectClassHandle theparent, const char thename, const char thetag) throw ( ObjectClassNotDefined, ObjectClassAlreadyDefined, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError); void addattribute( ObjectClassHandle theclass, const char theattributename, const char thetag) throw ( ObjectClassNotDefined, AttributeAlreadyDefined, FederateNotExecutionMember, 217

234 Annexes ConcurrentAccessAttempted, RTIinternalError); // Interaction class modifications void addinteractionclass( InteractionClassHandle theparent, const char thename, const char thetag) throw ( InteractionClassNotDefined, InteractionClassAlreadyDefined, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError); void addparameter( InteractionClassHandle theclass, const char theparametername, const char thetag) throw ( InteractionClassNotDefined, ParameterAlreadyDefined, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError); // Routing space modifications void changeattributeroutingspace( ObjectHandle theobject, const AttributeHandleSet& theattributes, SpaceHandle thespace) throw ( ObjectNotKnown, AttributeNotDefined, InvalidSpaceHandle, RTIinternalError); void changeinteractionroutingspace( InteractionHandle theobject, SpaceHandle thespace) throw ( 218

235 Annexes InteractionClassNotDefined, InteractionClassNotPublished, InvalidSpaceHandle, RTIinternalError); void createroutingspace( const char thename, const char dimensionsname[]) throw ( RoutingSpaceAlreadyDefined, FederateNotExecutionMember, RTIinternalError); }; Extensions ajoutées au Federate Ambassador class FederateAmbassador {... virtual void discoverobjectclass( ObjectClassHandle theparent, const char thename, const char thetag) = 0; virtual void discoverattribute( ObjectClassHandle theclass, const char thename, const char thetag) = 0; virtual void discoverinteractionclass( InteractionClassHandle theparent, const char thename, const char thetag) = 0; virtual void discoverparameter( InteractionClassHandle theclass, const char thename, 219

236 Annexes const char thetag) = 0; // Routing space modifications virtual void notifyattributeroutingspacemodification( ObjectHandle theobject, const AttributeHandleSet& theattributes, SpaceHandle thespace) = 0; virtual void notifyinteractionroutingspacemodification( InteractionHandle theobject, SpaceHandle thespace) = 0; virtual void discoverroutingspace( const char thename, const char dimensionsname[]) = 0; }; 220

237 Annexes DTD utilisée par le parseur XML <?xml version="1.0" encoding="iso "?> <!-- DTD utilisée pour valider le script XML à utiliser par le parseur XML d orisdis. Version > <!-- xmllint - -noout - -loaddtd - -valid fichier.xml --> <!ENTITY %text "#PCDATA"> <!ELEMENT distributed (class+)> <!ELEMENT class (class* function+)> <!ATTLIST class name #REQUIRED> <!ELEMENT function (parse? duplicate? asynchronous? hla*)> <!ATTLIST function name #REQUIRED> <!ELEMENT parse EMPTY> <!ELEMENT duplicate EMPTY> <!ELEMENT asynchronous EMPTY> <!ELEMENT hla EMPTY> <!ATTLIST hla attribute CDATA #REQUIRED transport (reliable best-effort) #IMPLIED ordering (receive timestamp) #IMPLIED routingspace CDATA #IMPLIED deadreckon CDATA #IMPLIED orisattr CDATA #IMPLIED> 221

238 Annexes Spécifications techniques de l API pour un modèle objet dynamique Cette annexe présente chaque service ajouté à l API HLA afin de permettre la prise en compte d un modèle objet dynamique. Chaque service est présenté sur une page et est formalisé en suivant le schéma utilisé dans la norme IEEE P [Department of Defense 98a]. Chaque service appelé par le RTI vers le fédéré est suivi du symbole de la croix ( ). 222

239 Annexes Add Object Class Le service Add Object Class informe la fédération qu une nouvelle classe d objet vient d être créée. Il permet d ajouter de nouvelles classes d objet, non définies dans le fichier FED, pendant le fonctionnement de l application. L identificateur de la classe parente, fourni en paramètre, permet de placer la nouvelle classe dans l arbre d héritage du modèle objet. Arguments fournis Identificateur de la classe parente Nom de la nouvelle classe d objet Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. L identificateur de classe d objet spécifié existe dans le modèle objet de la fédération. Le nom de la nouvelle classe spécifiée n est pas une sous-classe de la classe parente. Le fédéré a publié la classe parente. Post-conditions La nouvelle classe d objet est ajoutée au modèle objet de la fédération. Exceptions La classe d objet parente n est pas connue. Le nom de la nouvelle classe d objet est déjà une sous-classe de la classe parente. Le fédéré n est pas membre de l exécution. Erreur interne du RTI. Services relatifs Discover Object Class 223

240 Annexes Discover Object Class Le service Discover Object Class informe le fédéré qu une nouvelle classe d objet vient d être ajoutée au modèle objet de la fédération. Ce service est transmis à tous les fédérés si la classe d objet parente correspond à objectroot. Ce service peut être utilisé en liaison avec un protocole défini par l utilisateur. Ce protocole peut être transmis en se servant de l étiquette fournie en paramètre. Arguments fournis Identificateur de la classe parente Nom de la nouvelle classe d objet Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. Le fédéré a souscrit à la classe parente. Post-conditions Le fédéré a reçu la notification de l ajout d une nouvelle classe d objet. Exceptions La classe d objet fournie n est pas connue. Le nom de la nouvelle classe d objet est déjà défini. Erreur interne du fédéré. Services relatifs Add Object Class 224

241 Annexes Add Attribute Le service Add Attribute informe la fédération de l ajout d un nouvel attribut à une classe d objet existante dans le fichier FED ou nouvellement créée par le service Add Object Class. Le fédéré n a pas nécessairement besoin de publier la classe d objet de l attribut pour ajouter un attribut. En effet, le service Publish Object Class ne fonctionne que s il y a au moins un attribut en paramètre, ce qui interdirait l ajout d un nouvel attribut à une nouvelle classe d objet. Arguments fournis Identificateur de la classe concernée Nom du nouvel attribut ajouté à la classe Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. L identificateur de la classe d objet fourni existe dans le modèle objet de la fédération. Le nom du nouvel attribut n est pas déjà défini dans la classe concernée. Le fédéré a publié la classe parente. Post-conditions Le nouvel attribut est ajouté au modèle objet de la fédération. Exceptions La classe d objet fournie n est pas connue. Le nom du nouvel attribut est déjà défini. Le fédéré n est pas membre de l exécution. Erreur interne du RTI. Services relatifs Discover Attribute 225

242 Annexes Discover Attribute Le service Discover Attribute informe le fédéré de la création d un nouvel attribut à la classe d objet fournie en paramètre. Ce service peut être utilisé en liaison avec un protocole défini par l utilisateur. Ce protocole peut être transmis en se servant de l étiquette fournie en paramètre. Arguments fournis Identificateur de la classe concernée Nom du nouvel attribut ajouté à la classe Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. Le fédéré a souscrit la classe parente. Post-conditions Le fédéré a reçu la notification de la création du nouvel attribut. Exceptions La classe d objet fournie n est pas connue. Le nom du nouvel attribut est déjà défini. Erreur interne du fédéré. Services relatifs Add Attribute 226

243 Annexes Add Interaction Class Le service Add Interaction Class informe le RTI de la création d une nouvelle classe d interaction au modèle objet de la fédération. Il permet d ajouter de nouvelles classes d interaction, non définies dans le fichier FED, pendant le fonctionnement de l application. L identificateur de la classe parente, fourni en paramètre, permet de placer la nouvelle classe dans l arbre d héritage du modèle objet. Arguments fournis Identificateur de la classe d interaction parente Nom de la nouvelle classe d interaction à ajouter Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. L identificateur de la classe d interaction spécifié existe dans le modèle objet de la fédération. Le nom de la nouvelle classe n est pas déjà une sous-classe de la classe parente. Le fédéré a publié la classe parente. Post-conditions La nouvelle classe d interaction est ajoutée au modèle objet de la fédération. Exceptions La classe d interaction fournie n est pas connue. Le nom de la nouvelle classe d interaction est déjà défini. Le fédéré n est pas membre de l exécution. Erreur interne du RTI. Services relatifs Discover Interaction Class 227

244 Annexes Discover Interaction Class Le service Discover Interaction Class informe le fédéré de l ajout d une nouvelle classe d interaction au modèle objet de la fédération. Ce service est transmis aux fédérés qui ont souscrit à la classe parente ou, à tous les fédérés si la classe parente correspond à interactionroot. Ce service peut être utilisé en liaison avec un protocole défini par l utilisateur. Ce protocole peut être transmis en se servant de l étiquette fournie en paramètre. Arguments fournis Identificateur de la classe parente Nom de la nouvelle classe d interaction ajoutée au modèle objet Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. Le fédéré a souscrit la classe parente. Post-conditions Le fédéré est informé de l ajout de la nouvelle classe d interaction au modèle objet de la fédération. Exceptions La classe d interaction fournie n est pas connue. Le nom de la nouvelle classe existe déjà. Erreur interne du fédéré. Services relatifs Add Interaction Class 228

245 Annexes Add Parameter Le service Add Parameter informe le RTI de la création d un nouveau paramètre à une classe d interaction fournie en paramètre. Le fédéré doit avoir publié la classe d interaction pour pouvoir ajouter de nouveaux paramètres. Arguments fournis Identificateur de la classe d interaction concernée Nom du nouveau paramètre ajouté à la classe d interaction Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. L identificateur de classe d interaction spécifiée existe dans le modèle objet de la fédération. Le nom du nouveau paramètre n est pas un paramètre déjà défini dans la classe concernée. Le fédéré a publié la classe concernée. Post-conditions Le nouveau paramètre est ajouté au modèle objet de la fédération. Exceptions La classe d interaction fournie n est pas définie. Le nom du nouveau paramètre est déjà défini. Le fédéré n est pas membre de l exécution. Le fédéré n a pas publié la classe d interaction. Erreur interne du RTI. Services relatifs Discover Parameter 229

246 Annexes Discover Parameter Le service Discover Parameter informe le fédéré de l ajout d un nouveau paramètre à la classe d interaction fournie en paramètre. Ce service peut être utilisé en liaison avec un protocole défini par l utilisateur. Ce protocole peut être transmis en se servant de l étiquette fournie en paramètre. Arguments fournis Identificateur de la classe d interaction concernée Nom du nouveau paramètre ajouté à la classe d interaction Étiquette fournie par l utilisateur Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. Le fédéré a souscrit à la classe d interaction concernée. Post-conditions Le fédéré est informé de la création du nouveau paramètre. Exceptions La classe d interaction fournie n est pas connue. Le nom du nouveau paramètre est déjà défini. Erreur interne du fédéré. Services relatifs Add Parameter 230

247 Annexes Change Attribute Routing Space L espace de routage de chaque attribut de chaque classe d objet a été initialisé dans le fichier FED de description du modèle objet. Un fédéré peut choisir de modifier ou associer un espace de routage pendant l exécution. L invocation du service Change Attribute Routing Space change l espace de routage associé aux attributs de l instance de classe d objet fournis en paramètre. Arguments fournis Identificateur de l instance de classe concernée Liste des identificateurs d attributs concernés par la modification Identificateur du nouvel espace de routage associé aux attributs Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. L instance de classe est connue. Les attributs de classe sont connus de la classe. L espace de routage est défini. Post-conditions Les attributs sont associés à l espace de routage. Exceptions L instance fournie n est pas connue. L attribut n est pas défini pour la classe d objet concernée. L espace de routage est invalide. Le fédéré n est pas membre de l exécution. Erreur interne du RTI. Services relatifs Notify Attribute Routing Space Modification 231

248 Annexes Notify Attribute Routing Space Modification Le service Notify Attribute Routing Space Modification informe le fédéré de la modification de l espace de routage d un ensemble d attributs d une instance d objet. Arguments fournis Identificateur de l instance concernée Liste des identificateurs d attributs concernés par la modification Identificateur de l espace de routage Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. La classe de l instance a été souscrite par le fédéré. Le fédéré a souscrit à, au moins, un attribut de la classe de l instance. Post-conditions Le fédéré est averti du changement de souscription des attributs concernés. Exceptions L instance n est pas connue. L attribut n est pas connu. Erreur interne du fédéré. Services relatifs Change Attribute Routing Space 232

249 Annexes Change Interaction Routing Space L espace de routage de chaque classe d interaction a été initialisé dans le fichier FED de description du modèle objet. Un fédéré peut choisir de modifier ou associer un espace de routage pendant l exécution. L invocation du service Change Interaction Routing Space change l espace de routage de la classe d interaction fournie en paramètre. Arguments fournis Identificateur de la classe d interaction concernée Nouvel espace de routage associé à la classe Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. L identificateur de classe d interaction spécifié existe dans le modèle objet de la fédération. Le fédéré a publié la classe d interaction. L espace de routage est défini. Post-conditions La classe d interaction est associée à un nouvel espace de routage. Exceptions La classe d interaction fournie n est pas définie. La classe d interaction n a pas été publiée. Le fédéré n est pas membre de l exécution. L espace de routage n est pas défini. Erreur interne du RTI. Services relatifs Notify Interaction Routing Space Modification 233

250 Annexes Notify Interaction Routing Space Modification Le service Notify Interaction Routing Space Modification informe le fédéré de la modification de l espace de routage d une classe d interaction. Arguments fournis Identificateur de la classe d interaction concernée Espace de routage à associer Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. Le fédéré a souscrit à la classe d interaction. Post-conditions Le fédéré est informé des nouvelles conditions de souscription de la classe d interaction. Exceptions La classe d interaction fournie n est pas connue. L espace de routage n est pas connu. Erreur interne du fédéré. Services relatifs Change Interaction Routing Space 234

251 Annexes Create Routing Space Le service Create Routing Space informe le RTI de la création d un nouvel espace de routage non défini préalablement dans le fichier FED. Ce nouvel espace de routage ne peut être associé à une classe d interaction ou à un attribut qu à travers les services Change Interaction Routing Space et Change Attribute Routing Space. Arguments fournis Nom du nouvel espace de routage Liste des noms des nouvelles dimensions ajoutées à l espace de routage Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. Le nom du nouvel espace de routage n est pas déjà défini. Post-conditions Le nouvel espace de routage est ajouté au modèle objet de la fédération. Exceptions L espace de routage est déjà défini. Le fédéré n est pas membre de l exécution. Erreur interne du RTI. Services relatifs Discover Routing Space 235

252 Annexes Discover Routing Space Le service Discover Routing Space informe le fédéré qu un nouvel espace de routage vient d être défini. Arguments fournis Nom du nouvel espace de routage Liste des noms des nouvelles dimensions ajoutées à l espace de routage Valeurs retournées Aucunes Pré-conditions L exécution de la fédération existe. Le fédéré a rejoint l exécution. Au moins un des services de gestion de la distribution des données a été utilisé. Post-conditions Le fédéré est informé de la création d un nouvel espace de routage. Exceptions Erreur interne du fédéré. Services relatifs Create Routing Space 236

253 Annexes Articles Cette annexe présente les quatre articles réalisés en tant qu auteur principal : [Raulet et al. 02a] [Raulet et al. 02b] [Raulet et al. 03a] [Raulet et al. 03b] Raulet, V., Nédélec, A., et Rodin, V. (2002a). Coupling HLA with a MAS based DVR environment. In IASTED International Conference Applied Informatics, pages , Innsbruck, Austria. Raulet, V., Rodin, V., et Nédélec, A. (2002b). orisdis: using HLA and dynamic features of oris multi-agent platform for cooperative prototyping in virtual environments. In European Simulation Interoperability Workshop 2002 (02E-SIW-022), London, UK. SISO. Raulet, V., Nédélec, A., et Rodin, V. (2003a). A new API to the HLA declaration and object management services for runtime modifications and autonomy. In European Simulation Interoperability Workshop 2003 (03E-SIW-092), pages , Stockholm, Sweden. SISO. Raulet, V., Rodin, V., and Nédélec, A. (2003b). Using HLA to provide a Collaborative Multi Agent Virtual Prototyping platform. In Spring Simulation Interoperability Workshop 2003 (03S-SIW-051), Florida, USA. SISO. 237

254 Annexes Coupling HLA with a MAS based DVR environment Valéry Raulet, Alexis Nédélec and Vincent Rodin Software Engineering Laboratory (LI 2 ) ENIB Parvis Blaise Pascal Brest, 29200, France {raulet, nedelec, rodin}@enib.fr ABSTRACT orisdis is a networked and real-time system providing functionalities for collaborative virtual environments. Based on oris, an multi-agent system, it allows dynamic prototyping. It means, new instances, attributes can be added at run-time providing enhanced immersion through the language. This paper presents a general view of orisdis and particularly details on how HLA, a military simulation architecture, is used. KEY WORDS DVE, HLA, oris, MAS 1. Introduction Collaborative Virtual Environment (CVE) applications requirements are generally the same : support multiple users (infinity if possible), allow multiple users to share the same environment through data duplication and provide efficient network communication to keep user immersion. Sharing the same environment is not only observing objects or actors but means also acting on them (adding, modifying or removing). So, CVEs should provide functionalities for dynamically modifying the environment. oris, the multi-agent platform, provides immersion through the language at run-time. It means that a user can, during execution, modify existing objects but also add new objects not designed previously. This flexibility is necessarily if we don t want to be stopped during prototyping. Thereby, keeping this flexibility in orisdis is required. Our first implementation, called AréViDis[7], was taking into account this wish but the architecture of the platform was our own. Communications was made on a local Ethernet network with TCP and UDP exchanges. Limitations rapidly occurred through scalability. Proprietary protocols such as ones used by MASSIVE[4] or DIVE[2] are one solution. The other solution actually explored is using CORBA like SPIN- 3D[6] or a one WTK based platform[3]. We are exploring another solution based on HLA[1], a military oriented simulation architecture. This paper presents work in progress of our new architecture using HLA. While traditional real/ghost interactions exists within orisdis, further exploration is made through HLA. Indeed, HLA is a static architecture, so adding classes or attributes is impossible. We used tricks to resolve the problem. 1.1 oris/arévi oris[5] is an original programming language designed in our laboratory. The main purpose of this language is to provide interactive prototyping of multi agents systems. Running an interactive prototyping session consists in putting the user inside the multi-agent system he is designing. The user is in immersion through the language. This means that he can use at run-time the same language the agents are made up with. Therefore, the language used to describe the multi-agent system before running is entirely available while the system is running. This property allows the user to dynamically change the agents behavior while they are running (to tune or mend them) and allows to design and introduce new kinds of objects or agents in the system at run-time. To ease theses changes, a browser can be used. More than being only a programming language, oris is also a simulator in charge of the active objects and agents activity. On the other hand, ARéVi is a toolkit for virtual reality applications. It can be used as a stand alone tool for rapid prototyping of applications. It can also be directly embedded inside an already existing system. The core of ARéVi is based on oris. Based on the notions of entities, scenes (group of entities) and viewers, it handles animations, level of details, lightning, collision detection, various peripherals (such as 3D mice, force feedback joysticks, flock of birds,...), VRML 2 and more. 1.2 HLA HLA or High Level Architecture is a software architecture designed by the DMSO to facilitate interoperability between simulations. The RTI (Run-Time Infrastructure) is the core of the architecture. It provides common services to simulation systems encouraging portability and interoperability. 238

255 Annexes orisdis4 orisdis2 MFederateAmb RTI RTIambassador RTIambassador HLAmanager Class GhostObject RTIambassador RTI oris.fed Generator Class RealObject federateambassador orisdis3 XMLParser orisdis1 orisdis1 dissimul.xml simul.ors Figure 1. General view Figure 2. Detailed view HLA provides services and consistency is granted by the RTI. Different participating hosts called federates can share attributes and the whole is forming the federation. Services provided by the RTI are : Federation : manages federation creation/resignation, synchronization and saving/restoration. Declaration : manages publishing and subscription of classes. Objects : manages instance implementations. Ownership : update ownership, and objects attributes ownership. Time : manages time between federates. Data distribution : manages Area Of Interest. Allows more selective interest in subscribed classes. Communications between federates are made up through the RTI. The RTIambassador allows federate to communicate with the RTI and answers are made through the federateambassador. Two types of messages can be exchanged : attribute values updates and interactions. An object can be a tank and their attributes are informations needed by others to update object representation such as position, velocity, damages, and so on. An interaction is similar to an object but time to live is relatively short. It can be shells thrown by the tank. 2. Architecture Our architecture, orisdis, have to take into account specificities from HLA and specificities from oris language. Keeping dynamic aspects from the language was one of our goal. This is problematic since HLA federates use a configuration file while starting and so, no changes can be made during execution. With such a static working, we re unable to create new classes, attributes, interactions or parameters. One of the considered solution is presented later. orisdis looks like any application developed with the HLA architecture (see figure 1). Each federate is an oris session and can participate only to one federation. Communications are made as usual through a RTI ambassador for sending and through a Federate ambassador for receiving and managing informations coming from the RTI. The detailed view of the architecture is presented on figure 2 and is made up of four parts which are detailed in the next subsections. First code generator allows generation of real and ghost classes as well as configuration file for HLA. Second part consists of a manager which process information exchanged between HLA and oris. Third comes interactions management through the ghost, and at last a mechanism for keeping dynamic aspects which are not considered by the HLA architecture. During design of our architecture, we kept in mind that real object location has to be transparent to the user, during the execution. 2.1 Code generation Two parts are distinguished : one part allowing fed file generation and a second part dedicated to generating each real and ghosts classes Configuration file generation Originally designed for a single computer execution, oris applications have to be modified to adapt them to the distributed architecture. The system can not guess what the 239

256 Annexes <distributed> <class> <name>object2d</name> <function> <name>circle</name> <parse /> </function> <function> <name>getcolor</name> <duplicate /> </function> </class> </distributed> XML file real ghost class robject2d { void new(void); void delete(void); void circle(int r, bool fill) { hlasend("parse", "circle("+valuedump... } string getcolor(void) { return _color }; class fobject2d { void new(void); void delete(void); void circle(int r, bool fill) {... } void HLAcircle(string data) {...; ::circle(r, fill); } string getcolor(void) { return _color; }; }; (2) (1) robject.1 >setcolor("yellow"); { ::setcolor("yellow"); HLAmanager >update(hlaid, "COLOR", "yellow"); } (3) Real (3) (1bis) (4) fobject.1 >_setcolor("yellow"); (4) Ghost1 fobject.1 >setcolor("yellow"); { HLAmanager >interact (hlaid, "COLOR", "yellow"); } fobject.1 >_setcolor("yellow"); Ghost2 Figure 3. Example of generated code user wants. So modifications are necessary if we don t want to get into trouble by problems such as too frequent updates, unused updates, ghosts with too detailed behavior, and so on. Instead of modifying source code or adding keywords to our language such as E[8], we choosed to provide another file describing how each class has to be distributed for attributes and methods. The file is described in XML as shown in the above example : <class name="object2d"> <module name="circle"> <parse /> </module> <module name="rotate"> <hla attribute="dtheta" transport= "best-effort" /> </module> </class> This file describes each module used and how class modules have to be modified. For example, the rotate module associates the DTHETA attribute with its first parameter and this association is made through a reliable transport mode. So the real class will define this module as updating a class attribute and the ghost class will be defined as being sensitive to updates coming from this class, especially from this attribute. We defined a list of keywords to meet our needs. The XMLParser instance loads the dissimul.xml file and the application file simul.ors. With these two files, the parser generates the corresponding file oris.fed. This file is then used by the HLAmanager instance to create, initialize and manage the federation Real and Ghosts generation The XML file also contains information specific to real and ghosts generation. The keyword duplicate for example is used to generate a ghost module which will duplicate original code. In this case, no network exchange will occur. An example of generated code is available on figure 3. Figure 4. Real and Ghosts interactions 2.2 HLA manager Previous subsection described how was generated initial files and classes necessary for the proper application running. This second part explains how is managed informations exchanged between federates. While creating real and ghost classes, generator added code that is used to call the HLA manager with attributes values. The HLA manager has to threat these datas and transmit them to the RTI. On the other side, the receiving manager receives updates through the ManagerFederateAmbassador and applies them to the ghosts associated. Ghosts and real association is made with an identifier (an integer). As seen on figure 3, the ghost uses a module called HLAcircle which is in charge of extracting informations coming from the network and applying them to the ghost. 2.3 Interactions through the ghost In a collaborative environment, it s not recommended to having only simplex interactions. Indeed, others users may need to interact with agents created by others. So, ghosts must be interactable. But, when interacting with ghost, many steps occurs (figure 4) : 1. Update request is sent to the real through a HLA interaction. (1bis, ghost can update himself). 2. Real receive interaction and update himself. 3. An update message is sent to the RTI. If applicable, the update is broadcasted to every concerned sessions. 4. Each ghost is updated. The 1bis step has to be discussed. Indeed, the requester would like to see immediately changes instead of waiting a few hundred milliseconds (transmission+computing). The problem is that the real can decide 240

257 Annexes not to update itself. As it is an agent, this choice has to remain available Keeping dynamic aspects As stated earlier, HLA uses a so-called fed file describing each class and their different attributes as well as interactions and their parameters. This file needs to be created before the beginning of the simulation. Thereby, HLA acts statically. There is no way to add, modify or remove classes or interactions during running. The same applies to attributes and parameters. This is really constraining regarding to the oris language. So, three solutions are thinkable: 1. Using a generic interaction which would be instantiated each time a new (dynamically added) attribute is updated. 2. Using a generic class containing a bunch of attributes offering services needed by the user (reliable or besteffort transport, time stamped updates,... ). 3. Using a generic attribute defined in base class (so, inherited by all classes). This attribute could contain application code that would be directly parsed on the receiving side. Though every solutions are workable, each solution has its own advantages and drawbacks. The first one is not advisable since we use interactions which are requested for ghost updates. We will also loose every advantages given by HLA services. The second solution is interesting but requires creating a new class each time a new attribute is added. Finally, the third one is really simple to implement. We only use an attribute, that is inherited by every class, that contain only code to be parsed. The two last solutions permit partial use of services. Some of them becomes unusable such as interest but only few attributes are concerned by these hacks as few changes are generally made during execution. [2] C. Carlsson and O. Hagsand. Dive - a platform for multi-user virtual environments. Computer and Graphics, 17(6): , [3] Felicio Vanderlei Deriggi, Mario Massakuni Kubo, Antônio Carlos Sementille, and al. Corba platform as support for distributed virtual environments. In IEEE Virtual Reality, pages 8 13, March [4] C. Greenhalgh and al. Massive : A distributed virtual reality system incorporating spatial trading. Proceedings of IEEE 15th International Conference on Distributed Computing Systems (DCS 95), IEEE Computer Society, Vancouver (Canada), June [5] F. Harrouet. oris : in immersion through the language for virtual prototyping based on multi agents (in French). PhD thesis, Université de Bretagne Occidentale, December [6] Stéphane Louis Dit Picard, Samuel Degrande, and Christophe Gransart. A corba based platform as communication support for synchronous collaborative virtual environment. In ACM Multimedia 2001, Ottawa, Ontario (Canada), September 30, October [7] V. Rodin and A. Nédélec. A multiagent architecture for distributed virtual reality. IEEE International Conference on Sytems, Man & Cybernetics (SMC 2000), Nashville (USA), 2: , October [8] Language E: the secure distributed pureobject platform and p2p scripting language [9] Kent Watsen and Mike Zyda. Bamboo - a portable system for dynamically extensible real-time, networked, virtual environments. VRAIS 98 Proceedings, IEEE Virtual Reality Annual International Symposium, Atlanta (USA), pages , March Conclusion Tests have not been done since work is in progress but compared to our first implementation, it seems more promising. More interesting is the availability of dynamicity that doesn t exists in other platforms. One platform which has similar functionalities is the Bamboo platform[9]. References [1] Dmso, high level architecture (hla),

258 Annexes orisdis : using HLA and dynamic features of oris multi agent platform for cooperative prototyping in virtual environments Valéry Raulet Vincent Rodin Alexis Nédélec Software Engineering Laboratory (LI 2 ) ENIB Parvis Blaise Pascal Brest, 29200, France [email protected], [email protected], [email protected] Keywords: High Level Architecture, Multi Agent System, Collaborative Prototyping, Distributed Virtual Environment, Virtual Reality ABSTRACT : HLA is a framework providing functionalities for distributed simulations. It allows creation and destruction of federations, synchronisations, sharing objects and so on, but a way to create objects dynamically is lacking. Our aim is to develop a distributed platform for Collaborative Virtual Environment called orisdis. This environment will be based on oris, an agent-oriented language and simulation engine which allows agents activity management. Dynamic prototyping is provided with oris by immersion through the language. This means that a user can modify or add agents while running. Of course, such a feature has to be kept in orisdis. In this paper, we present our architecture providing a framework for Distributed Collaborative applications. Its main specificity is the dynamic object management service. 1. Introduction For many years, the Department of Defense (DoD) strives to standardize network communications between simulations. DoD is certainly the most important client in simulation softwares and its main goal is to reduce cost in developments. The first normalization was the Distributed Interactive Simulation protocol (DIS) which implemented a number of Protocol Data Unit (PDU). Many distributed platforms used this protocol to implement communications between users but its main disadvantage was its orientation towards military simulations. Some of them implemented extensions to provide more general PDU. On the other side, Aggregate Level Simulation Protocol (ALSP) was available. Aimed at providing a support for parallel discrete event simulations, it supports interoperability[3]. These two architecture are now merged into a single one called the High Level Architecture (HLA). The HLA core is the Run-Time Infrastructure which can be seen as a middleware managing messages exchange between different users. This RTI provides six types of services (federation, object, declaration, data distribution, ownership and time management) which can be divided into two groups : a part which manages federation and a part managing the objects attributes. Management of objects information first needs to be described in a specific file.fed which describes the object model of the simulation. To interoperate, each federate needs to use the same object model which provides them knowledge of what objects will be available during federation execution. So each federate will be able to create or discover these objects, send or receive updates from objects attributes. Such an architecture is adequate for simulations since it simulates a scenario. It means all informations exchanged during execution are known before simulation begins. But this way of acting does not scale to every distributed environments. Imagine a net-ve participant bringing a new, previously unseen object into the environment and being able to see, hear, and interact with instantly and meaningfully as stated [9]. This is the Holy Grail that every net-ve would like to develop. In section 2., we present our platform based on two components called oris and ARéVi which provides a multi agent based prototyping tool for a single user. This section will highlight specific features provided by this environment. Next section 3. will discuss about dynamic incompatibilities between orisdis and HLA. Then section 4. will explain how we circumvent this limitation for providing full dynamicity into our distributed platform. 242

259 Annexes 2. oris/arévi platform The core of our architecture, oris[4], is a Multi Agent System (MAS) developed in our laboratory. Available on many platforms (i386 Linux, PPC Linux, SGI Irix and Windows), it allows the execution of applications developed with agents. oris is an agent language and also a simulation platform. oris is an object oriented language. This means that object oriented programming style is used. Thus, entities are described by attributes, methods and classes with multiple inheritance. Its syntax is close to Java and C++. Moreover, oris is also an agent oriented language. This is done by providing a special method : void main(void). Available in each agent, this method describes the agent s behavior. It s the entry point for agent execution. The scheduler infinitely reexecutes this method. By being interpreted, oris doesn t attain performance from compiled languages such as Java or C++. But low level code has been optimized through a deep coupling with the C++ language. Native classes in oris have been coded in C++ to speed up the application execution. But oris takes advantage of its interpretation by providing dynamicity. Dynamicity enable modifications into the application while executing. This mean that during execution, availability is given to modify the application behavior to the desired objective. This functionality is really important in prototyping since it allows modifications without recompiling or restarting the application. Extending the oris core, ARéVi[5] which stands for Atelier de Réalité Virtuelle or Virtual Reality Toolkit is a graphical environment which allow representation of entities into 3D. This toolkit can be used as a stand alone tool for rapid prototyping or can be embedded into an existing system. Based on the notions of entities, scenes (group of entities) and viewers, ARéVi handles various features such as animations, level of details, lightning or collision detection. Interactions is provided through usual peripherals or specialized peripherals like 3D mice, force feedback joysticks, flock of birds and so on. 3. HLA in DVR The HLA is an architecture developed to provide a common architecture for Modeling and Simulation (M&S). This architecture facilitate reuse of individual federates and interoperability between federates. When planning an execution, the designer needs to define a Federation Object Model (FOM) which describes the set of object classes and the set of object interactions that will be used during execution. Moreover, the attributes and parameters of these classes are also described. The designer prepares a scenario by describing what classes are going to be used for representating entities. For simulations, this way of acting is enough since no code or behavior changes aren t going to occur. Everything has been prepared before execution : what interactions are available and how do they react to these interactions. Except the shared database synchronized through RTI services, a federate application acts like any parameterized applications. For example : if (receivedinteraction = MissileImpact ) then if ( receivedinteraction.strength >= 10 ) then isdestroyed = true else damage += receivedinteraction.strength endif endif The Run-Time Infrastructure (RTI) is initialized by the Federation Execution Data (FED) file but after starting, no modifications can occur except attribute transportation scheme. In Distributed Virtual Reality (DVR) or Collaborative Virtual Prototyping applications, needs for code or entity modification is required. We must be able to add new entities coming from an external file or a network link. We need to : create new classes not conceived before starting, modify existing modules in a class, modify existing modules in an instance. These requirements lead us to consider the FED file as an initialization file that describes only a part of exchanged information. 3.1 Solutions with HLA If we want to use the HLA architecture and provide dynamicity, we need to encapsulate HLA into a broaden mechanism. Two solutions are thinkable : 1. Use HLA when objects are known before run-time and use another communication interface for other objects, 2. Translate objects designed at runtime into known objects and use a specific protocol. The first one is not really interesting since we need to redefine every RTI services for objects dynamically added. The way of acting would be thinkable for very specific needs like using a specialized network with high bandwidth or very low latency on only a small subset. The second one needs to define a protocol between federates to define how object instance attributes are going to be exchanged and how to associate the code with those attributes. This last solution is the one retained by us. 243

260 Annexes To attain this dynamicity, we must strive to find a solution using HLA feasibilities while maintaining the most services usable. Indeed, we could simply transmit each update coming from new unknown object attributes through RTI interactions but this way of acting wouldn t keep HLA services available for these attributes. Our solution keep part of services available by taking advantage of two points available in the HLA design : 1. No type has to be specified to an attribute. If we need to change data format, from real to string or any other conversion, HLA doesn t take care of this since every attribute exchanges are format independent. The designer is responsible to care of what is exchanged. 2. No limitations for object or interaction instances. If an object needs to be created hundred times, HLA does support it. Manager 1 request Receiver 4 RTIambassador 2 Specific Features Manager 3 3 Information Base 2 4 update Sender 1 Dispatcher FederateAmbassador Figure 1. Manager s internal components 4. orisdis architecture The main goal of the orisdis architecture is to provide, to every users participating into the execution, a common representation of the simulated world. On one side, we have the oris application built with agents. This means state variables and behaviour are embedded into the agent himself. Moreover, the application allow users to interact with the environment by using interaction devices. On the other side, we have the simulation executive which is in charge of managing information exchange. Exchanges between the application and the others simulation executives is done through sending, receiving and delivering the events. To enable sharing of the common world, requirements are made on agents. Firstly, agents have to be able to send their changes to the simulation executive. Secondly, simulation executive have to reflect changes coming from foreign agents. To meet these goals, we use the real/ghosts model[2]. In this model, real represent the local entities which have full capabilities (behaviour). These entities code is the one that the designer modeled. Conversely, the ghost represent the real in a simplified way. Based on state information exchanged, the ghost tries to meet the real entity behaviour (visual aspects, hearing, behavioural,... ). More than simply reflecting the real behaviour, the ghost has to be interactable. It means that if a user interacts on a ghost entity, the entity have to transmit these interactions to the real one. A full path from a ghost is shown on figure 2[7]. The steps are as follows : Session1 (3) Real (2) (4) (4) (5) (5) Ghost1 Ghost2 Figure 2. Real and ghosts interactions (1) Session 3 Session 2 1. A user on session 2 is interacting on its local ghost entity called Ghost1. 2. This interaction made modifications that need to be reported to the real entity. So, modifications are transmitted from the ghost to the simulation executive and sent to the real simulation executive. 3. On receipt, the simulation executive transmit information to the real entity. This entity applies the modifications locally. 4. As internal modifications have been made, the real 244

261 Annexes entity send updates to the simulation executive. Network transmission occurs. 5. On receipt, ghosts (Ghost1 and Ghost2) are locally updated. In HLA, these information exchanges between federates or sessions are made with the use of object class instances or interaction class instances. The shared internal state of an agent is represented by an HLA object class instance. So, every update on the state of an agent is transmitted to the other federates via the Update Attribute Values service. As an attribute can be owned by only one federate at a time, a ghost can only talk to its real via the Send Interaction service. All these exchanges are made through HLA. To simplify the prototyping tools development, exchanges between the ambassadors (RTIambassador and FederateAmbassador) are made through a more adapted interface called the Manager Executive. 4.1 orisdis Manager Executive Being the interface between the application and the simulation executive, the manager provides a set of higher level services. This element manages every exchanges made with the different sessions into the execution. It can be split into three parts. The first one consists of the HLA ambassadors. This is required for exchanging information between the federation executive and the RTI. The second part is the dynamic object management service (based on Sender, Receiver and Information Base). It provides the same functionnalities as the RTI object management service except that instance level dynamicity is taken into account. Last, the third part extend the manager capabilities by providing entry points (Dispatcher and Specific Features Manager). 4.2 Dynamic Object Management Main point in the architecture, the dynamic object management part extend the HLA object management service by allowing dynamic (while executing) adding of new classes or new attributes not previously declared in the object model. One solution envisaged by Naud [6] is to restart the RTI without stopping the federates. We don t think that this solution is viable since restarting the RTI may take a while for being ready. Instead of this, we are using an intermediate for hiding the real implementation of the object model. This is achieved by : 1. creating a generic class with an associated attribute which will carry the value associated to the new added attribute, 2. having a database which will keep information equivalence between oris and HLA, 3. adding components between the application and the ambassadors. It will act as an intermediary. 4. providing a protocol to synchronise the local database disseminated accross the different federates A class for a dynamic attribute The object model needs to be defined before execution into the Federation Execution Data (FED) file. While running, no modifications can occur. Thus, only existing attributes and classes can be used. To prevent dynamic adding, a particular class compound with only one attribute is defined : (class ObjectRoot... (class Dynamic (attribute Attribute reliable timestamp) ) ) AirPlane Position Orientation Lights modified object model instances AirPlane.1 Position Orientation DynamicClass.1 Attribute Figure 3. Dynamic Object Model AirPlane.2 Position Orientation DynamicClass.3 Attribute This class will be instanciated each time a new attribute is adding to an instance. The same process occurs when a new unknown class is added dynamically. For example, if the following class is defined in the Object Model : (class AirPlane (attribute Position best-effort receive) (attribute Orientation best-effort receive) ) it would be impossible in the normal case to add a new Lights attributes while running. But if we hide how is managed the object model, the modified object model will be as seen on figure 3. For oris, the object model looks like the one described on the left. But an instance of this model is done (on the HLA side) by creating two class instances (an AirPlane instance and a DynamicClass instance). 245

262 Annexes Keeping the object model consistent The Information Base component maintains the local database. Its objectives is to keep relationship between the oris pair attribute/instance and the HLA pair attribute / instance. The UML class diagram shown on figure 4 describes the relationship between the different elements. An oris instance consist of two parts. A static part represented by the class defined in the object model and a dynamic part added each time that a new unknown attribute is added to the instance. This database is filled at initialisation. When the object model is read, static part of the agent is filled. At runtime, when new attributes are added, a new GenericClass is added and the corresponding attribute is associated with. Moreover, the database have to be bidirectional. When an information is sent from oris to the RTI, the database must retrieve the desired pair HLA attribute and HLA class instance. And when an information is sent from the RTI to oris, the pair oris attribute name and oris instance name has to be retrieved. All these informations are then used by the agent s ambassadors. Figure 4. Information Base internals Higher level ambassadors For hiding internal management of information, the Information Base is surrounded by two components. One is designed for sending information (Sender) to the RTI and the other for receiving information (Receiver) for the RTI. Running of these two components is shown on the sequence diagrams[8] figure 5 and figure Extensions for the Manager Sharing the same environment representation between the different participants is only one subset of the required features. To allow extensions to the system, writing to the RTI and reading from the RTI accessibility must stay available. Writing is made through the RTIambassador via interactions and reading is routed by the Dispatcher to the concerned specific manager (Specific Features Manager). Indeed, many extensions are needed such as dynamic code parsing, agent migration (load balancing or session leaving) and message exchange between agents. Last point has a similar behavior as the JavaSpace usage made in [10]. 5. Conclusion In this article, we presented our architecture for building interactive and distributed prototyping applications. The HLA architecture has been integrated by providing two specific components which acts as intermediary between agents and the RTI. But, one of the trouble we encounter was the lack in instance dynamicity. By instance dynamicity, we means that the object model can t evolve during execution and is somewhat constraining for our applications. To prevent this, we created a simple database which is in charge of simulating this dynamicity. Though being functional, one improvement would be to develop a new component for the Object Management RTI 1.3NG service[1] which take into account dynamicity. References [1] S. T. BACHINSKY, J. R. NOSEWORTHY, AND F. J. HODUM, Implementation of the Next Generation RTI, Simulation Interoperability Workshop, Spring

263 Annexes [2] B. BLAU, C. E. HUGHES, J. M. MOSHELL, AND C. LISLE, Networked Virtual Environments, Computer Graphics, 1992 Symposium on Interactive 3D Graphics, March [3] R. M. FUJIMOTO, Parallel and Distributed Simulation Systems, John Wiley & Sons, [4] F. HARROUET, oris : in immersion through the language for virtual prototyping based on multi agents (in French), PhD thesis, Université de Bretagne Occidentale, December [5] F. HARROUET, P. REIGNIER, AND J. TISSEAU, Multiagent systems and virtual reality for interactive prototyping, vol. 3, ISAS 99, Orlando (USA), July 31 - August , pp [6] J.-M. NAUD, Simulation Models as Components in an HLA World, Simulation Interoperability Workshop, Spring [7] V. RAULET, A. NÉDÉLEC, AND V. RODIN, Coupling HLA with a MAS based DVR environment, IASTED, Applied Informatics (AI 2002), February , pp [8] J. RUMBAUGH, I. JACOBSON, AND G. BOOCH, The Unified Modeling Language Reference Manual (UML), Addison-Wesley, [9] S. SINGHAL AND M. ZYDA, Networked Virtual Environments - Design and Implementation, ACM Press, SIGGRAPH Series, [10] A. WANG, Using Javaspaces to Implement a Mobile Multi-Agent System, IASTED, Applied Informatics (AI 2002), February , pp Author Biographies VALÉRY RAULET is a PhD student in Computer Science at the École Nationale d ingénieurs de Brest (France). His work aims at providing a toolbox for building distributed and collaborative applications. VINCENT RODIN is born on February Lecturer at the École Nationale d Ingénieurs de Brest (France), he s currently working on image processing, virtual reality and computer simulation of biologic processes. ALEXIS NÉDÉLEC is born on June Lecturer at the École Nationale d Ingénieurs de Brest (France), he s currently working on Agent Communication Language (ACL) in Multi Agent System for collaborative applications development in virtual reality. 247

264 Annexes Figure 5. Sequence diagram for real interactions 248

265 Annexes Figure 6. Sequence diagram for ghost interactions 249

266 Annexes Using HLA to provide a Collaborative Multi Agent Virtual Prototyping platform Valéry Raulet Vincent Rodin Alexis Nédélec Software Engineering Laboratory (LI 2 ) École National d Ingénieurs de Brest (ENIB) Parvis Blaise Pascal Brest, 29200, France (033) [email protected], [email protected], [email protected] Keywords: High Level Architecture, Multi Agent System, Collaborative Prototyping, Distributed Virtual Environment, Virtual Reality ABSTRACT : In a previous paper[6], we presented how we provided a dynamic object model with the High Level Architecture (HLA). In this paper, we present how we incorporate the HLA framework into orisdis, our multi agent oriented simulation platform, and the dynamic object model. Our platform adds an additional Run-Time Infrastructure, called orisrti, which provides a framework between agents and the HLA RTI. While the HLA RTI provides necessary services for data exchanges between platforms, the orisrti provides services specific to multi agent collaboration and higher level services (dead-reckoning, static and dynamic state update management,...). We will also emphasize difficulties for integrating real/ghost agent model management into the HLA exchanges and how benefits could be gained into adding further functionalities to the HLA architecture. 1. Introduction Originally developed for single user applications, our platform called oris is being extended to provide collaborative prototyping. Lots of solutions exist for allowing sharing between hosts (PVM, MPI, Linda, CORBA,... ). We made the choice of the High Level Architecture (HLA) because of its design and its standardization for distributed simulations. Indeed, HLA uses an object-oriented model. Our platform is multi agent oriented and this coupling can be easily made according to object and agent similarities. This paper describes how we realized the interconnection between our multi agent platform and the HLA architecture. Firstly, we briefly present our platform, then needs for communicative platform are described and solutions retained are shown. 2. The orisdis platform orisdis, our distributed platform, consists of three main components. First, oris is the core architecture which provides a multi agent language and a simulation engine for agents described in this language. The second component, ARéVi, is a 3D rendering API plugged around the oris core. It provides many capabilities for rendering and external interactions. The last one, orisdis is our work in progress to provide distributed facilities to the oris/arévi environment. Based on HLA, it provides data sharing. This data sharing is done the most transparently as possible to avoid bothering the designer with distribution problems. 2.1 oris environment oris 1 [2], the core component, is a Multi Agent System (MAS) developed in our laboratory. Built for many platforms (IA32 Linux, PPC Linux, SGI Irix and Windows), oris provides an agent language and a simulation platform. oris provides a original prototyping tool. Indeed, instead of designing a prototype in phases between off-line and on-line design, oris provides enough flexibility to fully modify prototype during simulation Prototyping Prototyping consists in designing a model as expected. Classical prototyping is a round trip between off-line design and on-line tests. This way of acting tends to disappear in favor of complete numerical design. We want to go a step further by allowing its designer to modify its model while testing. Figure 1 shows interactive prototyping where adjustment are now done on-line. 1 harrouet 250

267 Annexes Generate first prototype The aim of the engine is to simulate each agent behavior without privileging one of them and to provide complete access to the agent code and the oris language. This allows an user to modify the application while running. Adjust prototype Adjust prototype online Test prototype ARéVi Toolkit Design No Satisfactory tests? Usage / perfecting Prototype realized Figure 1. Interactive prototyping approach (from [2]) An agent language Yes Based on oris core component, ARéVi[3] 5, our Virtual Reality Toolkit provides a 3D graphical environment. It allows entity representation in three dimensions and user interaction with adapted devices. It can be used as a stand-alone tool for rapid prototyping or can be embedded into an existing system. Based on notions of entities, scene (group of entities) and viewers, it handles various features such as animation, level of details, lightning, collision detection... Interaction is provided through usual or VR peripherals like 3D mice, force feedback joystick, flock of birds, Phantom and so on. Based on a syntax similar to C++ and Java, oris is a language very close to object oriented languages with few more features. Features provided by this language are agent behavior, the main() module, agent communication capabilities, and dynamic behavior evolving. In the main() module, we can describe the agent s behavior. At the simulation startup, this module is called and represent the agent s entry point. Then, this module is periodically called, boundlessly, by the simulation engine. Agent communication capabilities allows agents to share data. This can be simple data such as entity state or more complex information described in ACL 2 language. ACL is a formalized way for communicating between agents. FIPA 3 or KQML 4 are some of these ACL[4]. Dynamic evolving is a specificity of our platform. Indeed, during execution, agents can evolve in a way that was unpredicted by its designer. The whole language is available at runtime and is interpreted. We call this a dynamic language A simulation engine Designed for simulating systems behaviors, the platform provides a simulation engine for making live agents. A fine tuned scheduler has been designed to avoid bias and thus each agent lives with fairness to its neighbor. 2.2 orisdis Multiuser Platform orisdis is made of two parts: a plug-in C++ module for oris and some oris code. The module provides bindings between oris language and the C++ HLA API. The oris code, called orisrti, is another RTI designed specifically for our platform. Agents (real or ghost) living onto the platform can interact with this orisrti. This latter is in charge of translating agent calls into HLA calls. Conversely, it translates HLA calls into oris agent module calls. This is shown on figure 2 and is detailed in the next section. 3. Distributed agent platform needs HLA is designed for providing a useful generic API for distributed simulations. It provides different services which can be used for many purpose. Despite its genericity, we have already shown that HLA is not sufficiently opened for every uses[6]. The orisrti provides more specific services, based on HLA generic ones, to our platform. 3.1 Ghost/Real interaction paradigm Our platform is based on a real/ghost interaction paradigm. A real entity is the one living on its creator platform while ghost entities are representative from this real entity. Real 2 ACL : Agent Communication Language 3 FIPA : Foundation for Intelligent Physical Agents 4 KQML : Knowledge Query and Manipulation Language 5 ARéVi, Atelier de Réalité Virtuelle 251

268 Annexes entity does support a full realistic behavior which can be computer driven or user driven. On the over hand, the ghosts entities does embed a lighter behavior which mimics real behavior. oris / federate host Agent interact with it. Interactions can be really bothering due to latency[5]. Ghost agents can be modified locally while referring its action to its real entity. This is not problematic for single shot action but is more difficult to manage for dynamic state modification, as inserting new properties to agents. Agent Entity state update frequency Agent orisrti oris / federate host Entity state attributes doesn t evolve identically. Some of them have a static state evolving one shot while others have a really dynamic state evolving (entity movement, heating color,... ). This can be particularly embarrassing for our platform since interactions can occur in a two way fashion. oris / federate host HLA/RTI A typical interaction between a ghost and its real entity and between real and its ghosts representation is displayed on figure 3. (5) orisdis 1 (5) orisdis 2 Figure 2. Double RTI infrastructure (1) Ghost.1 Ghost.2 Dead reckoning[7] is an example of such a behavior. The ghost behavior is to reflect more simply its real movement. This is done by exchanging location, velocity and acceleration. Ghost tries to mimic its real entity, graphically, by moving on a near path. On the other hand, real entity can have a very complex behavior resulting in its move. Reasoning is done once but location is the same on different hosts. More than that, we also want to be able to interact with ghosts. While they do embed real behavior of its real entity, interactions must be reflected to its real entity which is in charge of taking the correct action. This two way action can be problematic in case of a dynamic entity state update. This is explained in next subsections Bidirectional vs unidirectional interaction In interactive distributed simulations, environment state is maintained by exchanging entity state attributes which reflect entity representation (principally visual and auditive). Interaction between entities or between users is done by exchanging interactions instances (in HLA terms). In distributed simulations, this is not problematic since entity is owned by one user. You can t move its entity without asking him to do so! In our prototyping platform, an entity is not specifically owned by its creator. Another user must be able to (2) (4) Real (3) orisdis 4 (4) (4) Ghost.3 Figure 3. Real and ghosts interactions (5) orisdis 3 A dynamic state interaction occurring on a ghost is typically done when someone uses a manipulator to interact and move a ghost entity. For example, the ghost entity has been designed to send an interaction to its real when a threshold (5 inches for example) is over-stepped. If a user is moving this ghost entity 40 inches farther, eight interactions are going to be sent to inform its real entity. But during this move, real entity is going to reflect interaction received. This results in a back and forth moving. Latency is going to introduce delays between action being taken and action been taken reflected by real. Figure 4 shows such a problem. In this example, a ghost is sending periodically updates to its real associated entity. Each time this real receives a message, it decides to update itself and to send an 252

269 Annexes update to its ghost entities. But latency is such that ghost has enough time to send many messages before receiving any update from real entity. On the bottom on figure 4, we display what may result in such a situation. (1) represents the initial behavior of the interactor and (2) represent the resultant behavior caused by real updates. choosed a simple solution to this problem. When real entity receives updates from different ghosts, an average is computed and the shift position is sent to all ghosts. In this case, ghosts displacement is hindered by other users actions. 3.2 Communication between agents x axis 3 2 Ghost x=0 x=1 x=2 x=3 x=1 x=2 x=2 x=3 time x=2 x=3 x=1 x=2 x=1 x=2 x=3 Real x=0 x=1 x=2 x=3 x=2 a) ghost and real interactions (1) initial ghost path (2) ghost path Participating agents can be intelligent agents[8]. This means that communication can occur between agents. This is modeled by point to point or broadcast communication between agents. Needs are different for each one. In unicast communication, the destination agent is known. This is not problematic since ghost representing entity can forward the message to its real entity. In broadcast communication, the problem is that emitter agent doesn t know who has to receive the message. To answer this point, we implemented a specific agent in the orisrti which is sensitive to every messages that can be broadcasted. Figure 5 display agent organization for messages exchange. On top of the figure, an agent broadcast a message (agent 1) to all the agent sensitive to this message. Real agent present on this platform receives the message (shown with a dashed circle around the agent). Ghost agents are not sensitive to any broadcast message but the specific agent (agent 2) in the orisrti also receives this message. Then, this message is sent to the HLA RTI through an interaction (Send Interaction With Region). agent 1 1 agent 2 real sending update time b) ghost path evolving in time orisrti HLA/RTI Figure 4. Dynamic state attribute evolving with real entity updates agent 3 Solution When a ghost modifies a dynamic attribute state, two types of updates can interfere. First one is caused by its own updates sent back by real entity. This problem is simply solved by transmitting its updates with an identifier specifying who is the originator of this update. When a ghost receives an update originating from it, it simply discards this update. Second one occurs when two (or more) users try to interact on ghost entities representing the same real one. We agent 4 orisrti Figure 5. Infrastructure for agent communication exchange On the other side, an agent (agent 3) receives a specific message originating from the HLA RTI (Receive Interaction). It extracts data and recreates the message. This message is then broadcasted by a local agent 253

270 Annexes onto this platform (agent 4 receives this message). Solution details A specific interaction class has been designed for messages broadcasted by agents. Each orisrti subscribes to this interaction class and associates a region with it (Subscribe Interaction Class With Region). A specific routing space exists for this interaction. On each platform, when an agent become sensitive or insensitive to a type of message, it informs the orisrri agent (agent 2 or 3 on figure 5). This latter uses this information to create, modify, or remove an extent for the region associated to this interaction. Subscription is modified accordingly. Extent associated with a message is maintained into a table (message name, extent). This information has to be agreed between each federate. Since new messages can be created during execution, this agreement is done by sending an interaction with a specific region that is used for adding a new entry into the table (maintenance interaction). By acting this way, we hope that two platforms will not send the same message creation simultaneously. This solution avoids to send interactions to federate that are not interested by this agent s message type. 3.3 Dynamic evolving of agents The oris platform is able to add, modify or remove an agent while executing. This feature is so important that it must remain available in the collaborative one. This mean that the object model can be altered while needed. HLA provides a fixed unmutable object model. Our retained solution was presented in a previous paper[6]. The orisrti is in charge of encapsulating the oris object model into the HLA object model. Initial oris and HLA object model are identical. But when new attributes or classes are added to the oris object model, this is hidden to HLA by using a generic attribute and a specific protocol. The generic attribute is associated with the new oris added attribute. A specific protocol is used for platform agreement. When a new attribute, for example foo, is added to an oris instance, each platform has to agree that it is related to the same attribute. This encapsulation realizes association between the attribute name (only relevant for orisdis) and the attribute handle 1 from instance handle 23 from the HLA. This solution keeps some services available but we are examinating a new solution which require to modify the HLA API to introduce method to allow object model 6 modifications. This is currently being done on the CERTI RTI 6 [1]. 4. Conclusion HLA is really an interesting infrastructure for a lot of projects. It provides a sufficiently generic API for targeting different applications. Our project shows how HLA can adapt to different needs as presented in this paper. HLA is a first layer for us and more functionalities have to be added to provide a more useful API. Each domain may have to provide a more specific layer adapted to their needs to improve interoperability. But, as always an API is never sufficiently open for every usage. This is also the case with our platform since static object model is not enough. We are working on adding new API methods for allowing HLA to modify its object model during execution. Acknowledgements We would like to thank the CERTI team who released their API to the GPL license. This allows small teams as us to use complex API in research projects. References [1] B. BRÉHOLÉE AND P. SIRON, CERTI: Evolutions of the ONERA RTI Prototype, in Fall Simulation Interoperability Workshop (02F-SIW-018), Orlando, USA, September [2] F. HARROUET, oris : in immersion through the language for virtual prototyping based on multi agents (in French), PhD thesis, Université de Bretagne Occidentale, Equipe d accueil 2215, Laboratoire d Informatique Industrielle, Décembre [3] F. HARROUET, P. REIGNIER, AND J. TISSEAU, Multiagent systems and virtual reality for interactive protot yping, vol. 3, ISAS 99, Orlando (USA), July 31 - August , pp [4] A. NÉDÉLEC, P. REIGNIER, AND V. RODIN, Collaborative Prototyping in Distributed Virtual Reality Using Agent Communication Language, in IEEE SMC 2000, Nashville, USA, Octobre [5] V. RAULET, A. NÉDÉLEC, AND V. RODIN, Coupling HLA with a MAS based DVR environment, in IASTED International Conference Applied Informatics, Innsbruck, Austria, February , pp [6] V. RAULET, V. RODIN, AND A. NÉDÉLEC, orisdis: using hla and dynamic features of oris multiagent platform for cooperative prototyping in virtual 254

271 Annexes environments, in European Simulation Interoperability Workshop 2002 (02E-SIW-022), London, UK, June 2002, SISO. [7] S. K. SINGHAL, Effective Remote Modeling in Large- Scale Distributed Simulation and Visualization Environments, PhD thesis, Thesis, Department of Computer Science, Stanford University, Août [8] M. WOOLDRIDGE, Multiagent Systems A modern Approach to Distributed Artificial Intelligence, Massachusetts Institute of Technology, 1999, ch. Intelligent Agents, pp Author Biographies (France). His work aims at providing a toolbox for building distributed and collaborative applications. VINCENT RODIN is born on February Lecturer at the École Nationale d Ingénieurs de Brest (France), he s currently working on image processing, virtual reality and computer simulation of biologic processes. ALEXIS NÉDÉLEC is born on June Lecturer at the École Nationale d Ingénieurs de Brest (France), he s currently working on Agent Communication Language (ACL) in Multi Agent System for collaborative applications development in virtual reality. VALÉRY RAULET is a PhD student in Computer Science at the École Nationale d Ingénieurs de Brest 255

272 Annexes A new API to the HLA declaration and object management services for runtime modifications Valéry Raulet Alexis Nédélec Vincent Rodin Software Engineering Laboratory (LI 2 ) École National d Ingénieurs de Brest (ENIB) Parvis Blaise Pascal Brest, 29200, France {raulet,nedelec,rodin}@enib.fr Keywords: High Level Architecture, Multi Agent System, Collaborative Prototyping, Distributed Virtual Environment, Virtual Reality ABSTRACT : This paper presents how the CERTI HLA API has been modified to include improvements needed for runtime dynamic applications. This means that some applications need to change data structuration while running to adapt to new behaviors as it was stated in a previous article[7]. Current HLA standard is turned away to military simulation which assumes requires? exchanged information is already known before starting. We want to propose a new API subset in order to provide more flexible interactions with internal data for the declaration and object management services. We details how this new API was added to a HLA implementation called CERTI. 1. Introduction The HLA architecture is aimed at providing distributed simulations but is also particularly interesting for distributed virtual reality applications. Its opening to other areas, the way interactions are done between federates,its available services and its standardized API are promising. These are the main reasons why it was choosen for our collaborative prototyping platform. But despite all these features, this architecture is not flexible enough for all usage and will certainly never. Our problem affects the unability to change the object model while running the application. Our prototyping platform offers the ability to redesign a prototype while executing, avoiding to stop the application to make changes. Other platforms such as Bamboo[8] are expecting this runtine modification availability. In this paper, we present the new HLA API features added to the CERTI RTI implementation. Only eight methods, four RTIambassador and four Federate Ambassador, were added to provide these on-the-fly modification capabilities. We first introduce our platform orisdis, a dynamic prototyping platform and the CERTI RTI implementation. 2. The orisdis platform orisdis, our distributed platform, consists of three main components. First, oris is the core architecture which provides a multi agent language and a simulation engine for agents described in this language. The second component, ARéVi, is a 3D rendering API plugged around the oris core. It provides many capabilities for rendering and external user interactions. The last one, orisdis is our work in progress to provide distributed facilities to the oris/arévi environment. Based on HLA, it provides data sharing. This data sharing is done the most transparently as possible to avoid bothering the designer with distribution problems. 2.1 oris environment oris 1 [4], the core component, is a Multi Agent System (MAS) developed in our laboratory. Built for many platforms (IA32 Linux, PPC Linux, SGI Irix and Windows), oris provides an agent language and a simulation platform. oris provides an original prototyping tool. Indeed, instead of designing a prototype in phases between off-line and on-line design, oris provides enough flexibility to fully modify prototype during simulation Prototyping Prototyping consists in designing a model as expected. Classical prototyping is a round trip between off-line design and on-line tests. This way of acting tends to disappear in favor of complete numerical design. We want to go 1 harrouet 256

273 Annexes a step further by allowing its designer to modify its model while testing. Figure 1 shows interactive prototyping where adjustment are now done on-line An agent language Based on a syntax similar to C++ and Java, oris is a language very close to object oriented languages with few more features. Features provided by this language are agent behavior, the main() module, agent communication capabilities, and dynamic behavior evolving. In the main() module, we can describe the agent s behavior. At the simulation startup, this module is called and represent the agent s entry point. Then, this module is periodically called, boundlessly, by the simulation engine. Generate first prototype Adjust prototype Adjust prototype online Test prototype A simulation engine Designed for simulating systems behaviors, the platform provides a simulation engine for making live agents. A fine tuned scheduler has been designed to avoid bias and thus each agent lives with fairness to its neighbor. The aim of the engine is to simulate each agent behavior without privileging one of them and to provide complete access to the agent code and the oris language. This allows an user to modify the application while running ARéVi toolkit Based on oris core component, ARéVi[5] 5, our Virtual Reality Toolkit provides a 3D graphical environment. It allows entity representation in three dimensions and user interaction with adapted devices. It can be used as a stand-alone tool for rapid prototyping or can be embedded into an existing system. Based on notions of entities, scene (group of entities) and viewers, it handles various features such as animations, level of details, lightning or collision detection. Interactions are provided through usual or VR peripherals like 3D mice, force feedback joystick, flock of birds, Phantom and so on. No Satisfactory tests? Prototype realized Yes 2.2 orisdis Multiuser Platform orisdis is made of two parts: a plug-in C++ module for oris and some oris code. The module provides bindings between oris language and the C++ HLA API. Design Usage / perfecting Figure 1. Interactive prototyping approach (from [4]) Agent communication capabilities allows agents to share data. This can be simple data such as entity state or more complex information described in ACL 2 language. ACL is a formalized way for communicating between agents. FIPA 3 or KQML 4 are some of these ACL[6]. Dynamic evolving is a specificity of our platform. Indeed, during execution, agents can evolve in a way that was unpredicted by its designer. The whole language is available at runtime and is interpreted. We call this a dynamic language. The oris code, called orisrti, is another RTI, designed specifically for our platform. Agents living onto the platform can interact with this orisrti. This latter is in charge of translating oris agent calls into HLA calls. Conversely, it translates HLA calls into agent module calls. This is shown on figure CERTI RunTime-Infrastructure The CERTI is a RTI prototype[2] originally developed at the ONERA 6 a french governmental laboratory involved in aeronautic and spatial studies and researches which provides security extensions[1]. This project started in 1996 and has been released as free software recently 7. Currently, only a subset of the HLA Interface Specification IEEE 1516 is implemented (federation management, 2 ACL : Agent Communication Language 3 FIPA : Foundation for Intelligent Physical Agents 4 KQML : Knowledge Query and Manipulation Language 5 ARéVi, Atelier de Réalité Virtuelle 6 Office National d Études et de Recherches Aérospatiales

274 Annexes synchronization, object management, some other services). But new capabilities are added each month. oris / federate host Agent Agent Agent orisrti The librti library This library is linked with the federate application. It is a small library which provides the HLA API. Each call to a RTI ambassador method is transformed into an UNIX socket call containing attributes information. It is sent to the RTIA and it then waits for an answer coming from the RTIA. Calls to federate ambassador are received when the tick method is called. They are extracted from the UNIX socket call and transmitted to the application federate ambassador. oris / federate host 3.1 Architecture oris / federate host Figure 2. Double RTI infrastructure The CERTI architecture is build around three components communicating each others by socket : a RTI library linked with each federate, a local process for the RTI Ambassador (RTIA), HLA/RTI The RTIA The RTIA RTI Ambassador receives data information coming from the librti through UNIX socket or from the RTIG through TCP (and/or UDP) socket. It acts as an intermediary between the federate and the RTI. It is comparable to the LRC 8 from the DMSO 9 (Defense Modeling Simulation Office) RTI. Some requests from support services such as Get Attribute Handle or Get Ordering Name can be retrieved from the RTIA without being transmitted up to the RTIG. This allows the RTIA to answer quickly to request from its federate. This can be done since the RTIA contains an identical copy of its RTIG object model. Other requests are sent to the RTIG and if accepted, some actions can be done locally. a global process for data exchanges and RTI services with the RTI Gateway (RTIG). The relations between each component is summarized on figure 3. They are detailed in the next three sections. Federate 1 librti librti librti RTIA 1 HLA Interface Federate 2 Federate 3 UNIX socket RTIA 2 RTIA The RTIG The RTIG RTI Gateway is a central server which serves two purposes. Firstly, it permits data exchange between the differents federate through dialog between RTIG and RTIAs. Secondly, its centralized model allows a simple implementation of the RTI services. All data exchange between federates are received by the RTIG. For example, a call to the service Update Attribute Values is received by the RTIG. Then the RTIG determines implied federates and send a call to the federate ambassador service Reflect Attribute Values. TCP socket RTIG WAN Data-Transfer scenario Figure 3. CERTI architecture (from [2]) 8 LRC : Local RTI Component 9 A typical data exchange is shown on figure 4. UAV is the acronym for Update Attribute Values and RAV 258

275 Annexes refers to Reflect Attribute Values. A message from federate is transmitted to its RTIA up to the RTIG. This message is processed and then forwarded to other RTIA up to the concerned federates. 4. Dynamic Object Model API Simulations using the HLA API are developed by enterprises that must respond to strict specifications. Established before the development and certainly certified by the american US army, the object model is fixed. We are developing a collaborative prototyping tool and as its name implies, the application needs refinements and improvements while designing. So does the object model. A fixed object model prevents us from doing online modifications. A first version of our prototyping tool circumvent this limitation by encapsulating the instances into another API providing extensions. This is quicly explained in the first section. Our second implementation is using the CERTI implementation. This implementation has been modified accordingly to include new functionnalities allowing us to modify the object model while executing and is detailled in the remainder of this paper. Federate 1 RTIA RTIG RTIA Federate 2 UAV ok UAV ok RAV tick RAV Position, Orientation and we want to extend this object model to be able to see light state. We can add a new attribute Lights to our application object model. Since HLA can t do so, it is hidden behing an instance from the Dynamic class. (class objectroot... (class Dynamic (attribute Attribute reliable timestamp) ) ) Figure 5. Class for an external dynamic object model A specialized protocol is used by exchanging HLA interactions which informs which instance from the Dynamic class is related to the application instance attribute. On figure 6, two instances from AirPlane are shown. AirPlane object model has been enriched by a new Light attribute and this is reflected on instances by a new DynamicClass which carries information on the HLA side (ellipses show added information). AirPlane Position Orientation Lights modified object model instances AirPlane.1 Position Orientation DynamicClass.1 Attribute AirPlane.2 Position Orientation DynamicClass.3 Attribute ok Figure 6. Dynamic Object Model Figure 4. Data transfer scenario (from [2]) This solution was a simple way to avoid this difficulty. But not all services where usable with this solution. The adding of new methods to the HLA API was the only way to take full advantage from HLA. 4.1 Encapsulating to provide a dynamic object model A first solution to provide a dynamic object model to our application was to encapsulate RTI calls into another API which hides the HLA static object model[7]. The implementation was introducing a class into the object model to provide capability to extend the application object model. This class has only one attribute such as presented on figure 5. If an AirPlane has only two parameters 4.2 Enrish the API for online modification The object model is built when lauching the application. The RTI receives a file to read which informs it what kind of data (objects and interactions) are going to be exchanged during the execution. In the CERTI implementation, these information are used to build class instances (ObjectClass, ObjectClassAttributes,... ) which are containing associations (parent and son classes, attributes), subscribers, publishers and instances. These information are maintained by the RTIG and each RTIA. 259

276 Annexes Developping new RTIambassador and federate ambassador methods needs to be able to twist the RTI instances to insert new object classes and/or new attributes. We only developped a new API for object classes since we are not yet interested in adding new interactions. However, the implementation done for object classes doesn t differ for interactions since interactions are simpler than objects The Object Model The object model is initially described in the FED 10 file. A FED file example is given below. Information described into this file are classes inheritance and class attributes. ;; (class <name> ;; (attribute <name> <transportation> <ordering> [<space>]) ;;... ;; ) (class entity (attribute location best_effort receive) ) Class attributes information are its name, transportation type, ordering and optionally associated space. Once set, inheritance and class attribute list (names) can t be changed. Transportation is modified by the method Change Attribute Transportation Type. Ordering can be changed by the method Change Attribute Order Type. Last parameter associates an attribute to a routing space defined previously in the FED file. This is an optional feature that can be omitted if spaces are not used. This space can t be changed during execution but any regions can be created for needs. Currently, no services are provided for enabling (or disabling) data distribution management. For interactions, the same process is developed. The Change Interaction Transportation Type is used for changing transportation, Change Interaction Order Type allows changes to the order. In the same manner, space is optional and cannot be changed during execution. Initially, all these information is set in the FED file : The API methods A first step to provide a dynamic object model is to allow adding of any element into the object model. Thus, new object or interactions classes can be added to the object model by setting its inheritance in the tree hierarchy. Also, new attributes or parameters have to be added to the object model. The appendix describes the RTI and federate ambassador methods added for providing these new services. Object Class To provide a dynamic object model, we create only two methods for the RTIambassador and two other methods for the federate ambassador. All the implied operations are shown on figure 7. The first method Add Object Class is used to add a new object class. Only information are its inheritance described by its first parameter and its name, the second parameter. The last parameter is used to transmit other data to other federates. This call is received by the RTI and if the parent doesn t exists or if the object class name has already been used, an exception is thrown. Otherwise, the RTI adds this new object class to its object model and informs the other federates to do so. This result in a call to Discover Object Class which will contain the same information. The federate receiving this call can process data locally to being able to treat this new added class. This is done by calling the usual method Get Object Class Handle. Likewise, an attribute can be added to an object class by the call to the method Add Attribute. If the owner class handle is correct and the attribute has not yet been used, this attribute is added to the RTI. A call Discover Attribute to the federates reflects the new added attribute. Then, the federate can retrieve the attribute handle by calling Get Attribute Handle. addobjectclass() getobjectclasshandle() discoverobjectclass() ;; (class <name> <transportation> <ordering> [<space>] ;; (parameter <name>) ;;... ;; ) (class splat reliable timestamp (parameter target) ) addattribute() discoverattribute() getattributehandle() Figure 7. The dynamic object model API sequence Interactions differs from object classes because transportation, ordering and space are applied to the whole interaction class while object class applies these specifications to attributes (attribute granularity). 10 FED : Federation Execution Data Interaction Class is shown on figure 8. For interactions, the process is similar and 260

277 Annexes Add Interaction Class is used to add a new interaction class in the object model tree. Inheritance is described by its parent handle parameter. This service is processed by the RTI and results in a Discover Interaction Class to the other federates. In the same manner, a new parameter can be added by calling Add Parameter. This results in a Discover Parameter method call. addinteractionclass() discoverinteractionclass() we added new fonctionnalities to the HLA API. This is described in the next section. 5. Routing space API extension Previous methods doesn t allow using routing spaces since no such parameter is available. Indeed, we chose not to provide two methods : one without and one with data distribution management. Instead of this, we added further methods for modifying routing spaces associated with attributes or interactions. These methods are shown on figure 9. subscribeinteractionclass() changeattributeroutingspace() getinteractionclasshandle() notifyattributeroutingspacemodification() changeinteractionroutingspace() addparameter() notifyinteractionroutingspacemodification() discoverparameter() createroutingspace() getparameterhandle() discoverroutingspace() Figure 8. The dynamic interaction object model API sequence Discovering Discovering of a new interaction or object class is done based on federate registration. Discover Object Class or Discover Interaction Class is sent to the federate only if it has subscribed to the parent class or if parent is objectroot or interactionroot. For parameters, federates are informed of any new created parameters when it subscribes to the interaction by calling Subscribe Interaction Class. This mean that every object model modifications are marked to be sent to a federate if it subscribes to such a class. For attributes, we cannot wait that federate subscribes to the object class. This way of acting is impossible since IEEE standard[3] says that any subscription to an object class (Subscribe Object Class Attributes) with an empty set of class attributes is equivalent to an Unsubscribe Object Class. Two solutions are thinkable. First one is to modify the Subscribe Object Class Attributes to accept subscription if object class designator is a dynamic one but this is a special behavior that we do not retained. The second one we used is to send a Discover Attribute to every federate that subscribed to the associated parent class Initial settings When a new attribute or a new interaction is registered, its values are defaulted. Transportation is set to reliable and ordering to receive. This can be changed by calling corresponding methods. For associating a routing space to an attribute or an interaction, Figure 9. Routing space modifications during execution Change Attribute Routing Space and Change Interaction Routing Space allows changing or setting the associated routing with a set of attributes and an interaction. We are conscious that modifying an existing used set of attributes cannot be done easily. Currently, these methods are intended only for setting the routing space with newly created attributes and interactions. These two methods results in calls to Notify Attribute Routing Space Modification and Notify Interaction Routing Space Modification. These federate ambassador calls are needed for correctly setting Register Object Class With Region and Send Interaction With Region. 6. Conclusion In this paper, we proposed a new API subset for managing evolving object model. These features are lacking in the HLA standard and may be needed by some networked applications such as prototyping tools or long lasting adaptive environments. We shown that implementing a dynamic object model is really a simple operation to do. Method behavior doesn t differ from usual ones, one call to Add Object Class results in n calls to Discover Object Class. The only trouble we encountered was keeping the object class handle counter since it was destroyed after the FED file was read. Further control over the object model by modifying the routing space set becomes more tricky to handle. More in depth should be done in this part of the API. This feature is essential for our application and we proved that some of these features could be added to the HLA API easily. 261

278 Annexes Acknowledgements We would like to thank the CERTI team who released their API to the GPL license. This allows small teams as us to use complex API in research projects. References [1] P. BIEBER, J. CAZIN, P. SIRON, AND G. ZANON, Security Extensions to ONERA HLA RTI Prototype, in Fall Simulation Interoperability Workshop (98F-SIW-086), Orlando, USA, September [2] B. BRÉHOLÉE AND P. SIRON, CERTI: Evolutions of the ONERA RTI Prototype, in Fall Simulation Interoperability Workshop (02F-SIW-018), Orlando, USA, September [3] DEPARTMENT OF DEFENSE, High Level Architecture Interface Specification Version 1.3, IEEE P1516.1, Standard for Modeling and Simulation (M&S), (1998). [4] F. HARROUET, oris : in immersion through the language for virtual prototyping based on multi agents (in French), PhD thesis, Université de Bretagne Occidentale, Equipe d accueil 2215, Laboratoire d Informatique Industrielle, Décembre [5] F. HARROUET, P. REIGNIER, AND J. TISSEAU, Multiagent systems and virtual reality for interactive protot yping, vol. 3, ISAS 99, Orlando (USA), July 31 - August , pp [6] A. NÉDÉLEC, P. REIGNIER, AND V. RODIN, Collaborative Prototyping in Distributed Virtual Reality Using Agent Communication Language, in IEEE SMC 2000, Nashville, USA, Octobre [7] V. RAULET, V. RODIN, AND A. NÉDÉLEC, orisdis: using HLA and dynamic features of oris multi-agent platform for cooperative prototyping in virtual environments, in European Simulation Interoperability Workshop 2002 (02E-SIW-022), London, UK, June 2002, SISO. [8] K. WATSEN AND M. ZYDA, Bamboo - A Portable System for Dynamically Extensible, Real-time, Networked, Virtual Environments, in Proceedings for the IEEE Virtual Reality Annual International Symposium (VRAIS 98), Atlanta, Georgia, USA, Mars 1998, IEEE Computer Society Press, pp Author Biographies VALÉRY RAULET is a PhD student in Computer Science at the École Nationale d ingénieurs de Brest (France). His work aims at providing a toolbox for building distributed and collaborative applications. VINCENT RODIN is born on February Lecturer at the École Nationale d Ingénieurs de Brest (France), he s currently working on image processing, virtual reality and computer simulation of biologic processes. ALEXIS NÉDÉLEC is born on June Lecturer at the École Nationale d Ingénieurs de Brest (France), he s currently working on Agent Communication Language (ACL) in Multi Agent System for collaborative applications development in virtual reality. Appendix RTIambassador API extension class RTIambassador {... // Object class modifications void addobjectclass( ObjectClassHandle theparent, const char * thename, const char * thetag) throw ( ObjectClassNotDefined, ObjectClassAlreadyDefined, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError); void addattribute( ObjectClassHandle theclass, const char * theattributename, const char * thetag) throw ( ObjectClassNotDefined, AttributeAlreadyDefined, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError) // Interaction class modifications void addinteractionclass( InteractionClassHandle theparent, const char * thename, const char * thetag) throw ( InteractionClassNotDefined, InteractionClassAlreadyDefined, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError); void addparameter( InteractionClassHandle theclass, const char * theparametername, const char * thetag) throw ( InteractionClassNotDefined, ParameterAlreadyDefined, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError); // Routing space modifications 262

279 Annexes void changeattributeroutingspace( ObjectHandle theobject, const AttributeHandleSet& theattributes, SpaceHandle thespace) throw ( ObjectNotKnown, AttributeNotDefined, InvalidSpaceHandle, RTIinternalError); }; void changeinteractionroutingspace( InteractionHandle theobject, SpaceHandle thespace) throw ( InteractionClassNotDefined, InteractionClassNotPublished, InvalidSpaceHandle, RTIinternalError); void createroutingspace( const char * thename, const char * dimensionsname[]) throw ( SpaceAlreadyDefined, FederateNotExecutionMember, RTIinternalError); Federate ambassador API extension class FederateAmbassador {... virtual void discoverobjectclass( ObjectClassHandle theparent, const char * thename, const char * thetag) = 0; virtual void discoverattribute( ObjectClassHandle theclass, const char * thename, const char * thetag) = 0; virtual void discoverinteractionclass( InteractionClassHandle theparent, const char * thename, const char * thetag) = 0; virtual void discoverparameter( InteractionClassHandle theclass, const char * thename, const char * thetag) = 0; }; // Routing space modifications virtual void notifyattributeroutingspacemodification( ObjectHandle theobject, const AttributeHandleSet& theattributes, SpaceHandle thespace) = 0; virtual void notifyinteractionroutingspacemodification( InteractionHandle theobject, SpaceHandle thespace) = 0; virtual void discoverroutingspace( const char * thename, const char * dimensionsname[]) = 0; 263

280 Annexes 264

281 Liste des acronymes ACE Adaptive Communication Environment ACL Agent Communication Language AI Artificial Intelligence A-Life Artificial Life ALSP Aggregated Level Simulation AMG Architecture Management Group API Application Program Interface ARPA Voir DARPA ARVESTER Abattage Reconstitué Virtuellement En Synthèse TEmps Réel ATM Asynchronous Transfer Mode BBN Bolt Beranek and Newman BDI Believe, Desire, Intention BOA Basic Object Adapter CAN Controller Area Network CAO Conception Assistée par Ordinateur CATOCS Causal And Totally Ordered Communication Service CBR Constant Bit Rate CERTI CERT (ONERA Centre de Toulouse) CGA Computer-Generated Actor, voir également SAF CGF Computer Generated Forces CGI Common Gateway Interface CNAME Canonical NAME CORBA Common Object Request Broker CRT Cathod Ray Tube CSCW Computer-Supported Cooperative Work CSMA/CD Carrier Sense Multiple Access/Collision Detect CUMULVS Collaborative User Migration, User Library for Visualization and Steering CVW Collaborative Virtual 265

282 Liste des acronymes DAI Distributed Artificial Intelligence DARPA Defense Advanced Research Projects Agency, Anciennement ARPA DC Delivery Constraint [Barrett et al. 96] DCOM Distributed Component Object Model DIS Distributed Interactive Simulation DIVE Distributed Interactive Virtual Environment DMSO Defense Modeling and Simulation DoD Department of Defense DSM Distributed Shared Memory DTD Document Type Definition DWTP Distributed Worlds Transfer and communication Protocol EBI Event Based Integration [Barrett et al. 96] EQUIP EQuator UnIversal Platform ESPDU Entity State PDU EXCIMS EXecutive CouncIl for Modeling and Simulation FED Federation Execution Data FIFO First In First Out FIPA Foundation for Intelligent Physical FOM Federation Object Model GAIA Giga-object Architecture for Internet Applications GIOP General Inter-ORB Protocol GTRV Groupe de Travail Réalité Virtuelle GVT Global Virtual Time HCI Human Computer Interface HITL Human-In-The-Loop HLA High Level HRTF Head-Related Transfer Function HTML HyperText Markup Language HTTP HyperText Transport Protocol IDL Interface Definition Language IEEE Institute of Electrical and Electronics Engineers IIOP Internet Inter-ORB Protocol I/ITSEC Interservice/Industry Training, Simulation, and Education Conference IP Internet Protocol IPC Inter-Process Communication IS Interface Specification [Department of Defense 98a] ISO International Standard Organization ISTP Interactive Sharing Transfer Protocol KQML Knowledge Query and Manipulation Language LBTS Lower Bound Time Stamp 266

283 Liste des acronymes LCD Liquid Crystal Display LRC Local RTI Component MAS MultiAgent System MASCARET Multi-Agent System for Collaborative and Adaptive Realistic Environment for Training [Querrec 02] MASSIVE Model, Architecture and System for Spatial Interaction in Virtual Environments MBone Multicast backbone MCA Module Clustering Algorithm MERL Mitsubishi Electric Research MIOP Unreliable Multicast Inter-ORB Protocol [OMG 01] MOM Management Object Model MOSIX Multicomputer Operating System for UnIX MPI Message Passing MPP Massively Parallel Processor MTF Message Transforming Function [Barrett et al. 96] MUD Multi-User Dungeon NOW Network of Workstation NPS Naval Postgraduate School NTP Network Time Protocol OCL Object Constraint Language OMG Object Management OMT Object Model Template ONERA Office National d Études et de Recherches Aérospatiales OpenAL Open Audio OpenMP Open ORB Object Request Broker ORNL Oak Ridge National OSI Open Systems Interconnection PDU Protocol Data Unit [Hofer et al. 95] PHBDR Position History-Based Dead Reckoning [Singhal 96] PLM Product Lifecycle Management POA Portable Object Adapter PVM Parallel Virtual QoS Quality of Service RAVEN Remote Access Virtual Environment Network [Cater et al. 95] RIOP Real-Time Inter-ORB Protocol [Schmidt et al. 98] RMI Remote Method Invocation RMT Reliable Multicast Transport RMTP Reliable Multicast Transport Protocol 267

284 Liste des acronymes RPC Remote Procedure Call RSVP Resource reservation Protocol RTCP RTP Control Protocol RTI Run-Time Infrastructure RTP Real-time Transport Protocol SAF Semi-Automated Forces, Voir également CGA SICS Swedish Institute of Computer Science SIMD Single Instruction stream Multiple Data stream SIMNET SIMulator NETworking SMP Symmetric MultiProcessing SNMP Simple Network Management Protocol SNTP Simple Network Time Protocol SOM Simulation Object Model SPLINE Scalable Platform for Large Interactive Network SPMD Single Program Multiple Data SRM Scalable Reliable Multicast SRTP Selectively Reliable Transport Protocol [Pullen 99] TAO The ACE TCP Transmission Control Protocol TMTP Tree based Multicast Transport Protocol TSO Time-Stamp Order UDP User Datagram Protocol UML Unified Modeling Language URL Uniform Resource Locator VBR Variable Bit Rate VET Virtual Environment for Training VIPER VIrtuality Programming EnviRonment ViSTA Virtual Reality Software University of Technology Aachen VRML Virtual Reality Modeling Language VRTP Virtual Reality Transfer Protocol VSCP Virtual Society Client/Server Communication Protocol VSEP Virtual Society Entry Protocol VV&A Verification, Validation and Accreditation WAVES WAterloo Virtual Environment System X3D extensible 3D XDR external Data Representation XML extensible Markup Language 268

285 Liste des sites Internet ALSP AVIARY dns/vr/aviary/ Bamboo Beowulf CAN CERTI CORBA CUMULVS CVW DIVE DMSO Equator EQUIP FIPA GTRV HLA ISO JavaSpaces Linda MASSIVE MERL 269

286 Liste des sites Internet MITRE Corporation MOSIX MPI MPI/RT NOMAD acgrg/ OMG ONERA Open Community OpenAL OpenMP OSF (The Open Group) ORBACUS home.htm oris harrouet/oris.html ORNL Phantom ghost/phantom.asp PVM RMT Sensable Technologies Sony CSL SPLINE TAO schmidt/tao.html TSpaces ViSTA VRML VRTP Wolfenstein 3D X3D XML Gnome 270

287 Références bibliographiques [Acremann et al. 00] Acremann, D., Rousset, L., et Moujeard, G. (2000). Développer avec CORBA en Java et C++, 2ème édition. CampusPress. 78 [Attiya et al. 98] Attiya, H. et Welch, J. (1998). Distributed Computing Fundamentals, Simulations and Advanced Topics. Alfred Waller. 65 [Ballet et al. 98] Ballet, P., Pers, J., Rodin, V., et Tisseau, J. (1998). A multi-agent system to simulate an apoptosis model of B-CD5 cells. In Proceedings IEEE SMC 98, pages 1 5, San Diego, USA. 29 [Barrett et al. 96] Barrett, D. J., Clarke, L. A., Tarr, P. L., et Wise, A. E. (1996). A Framework for Event-Based Software Integration. ACM Transactions on Software Engineering and Methodology, 5(4): xii, 112, 266, 267 [Benford et al. 93] Benford, S. et Fahlén, L. (1993). A spatial model of interaction in large virtual environments. In Proceedings Third European Conference on Computer Supported Cooperative Work (ECSCW 93), pages , Milan, Italie. Kluwer Academic Publishers. 127 [Bieber et al. 98] Bieber, P., Cazin, J., Siron, P., et Zanon, G. (1998). Security Extensions to ONERA HLA RTI Prototype. In Fall Simulation Interoperability Workshop (98F-SIW-086), Orlando, USA. 193 [Birrel et al. 84] Birrel, A. D. et Nelson, B. J. (1984). Implementing Remote Procedure Calls. ACM Transactions on Computer Systems, 2(1): [Black 99] Black, U. (1999). ATM foundation for broadband networks, Second edition. Advanced Communications Technologies Series. Prentice Hall PTR. 48 [Booch et al. 99] Booch, G., Rumbaugh, J., et Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley, New York

288 Références bibliographiques [Braden et al. 94] Braden, R., Clark, D., et Shenker, S. (1994). RFC 1633 Integrated Services in the Internet Architecture: an Overview. Network Working Group. 49 [Bréholée et al. 02] Bréholée, B. et Siron, P. (2002). CERTI: Evolutions of the ONERA RTI Prototype. In Fall Simulation Interoperability Workshop (02F-SIW-018), Orlando, USA. xiii, 194, 196 [Broll 95] [Broll 98] Broll, W. (1995). Interacting in Distributed Collaborative Virtual Environments. In Press, I. C. S., editor, Proceedings of the IEEE Virtual Reality Annual International Symposium (VRAIS 95), pages , Los Alamitos, California. 131 Broll, W. (1998). DWTP An Internet Protocol For Shared Virtual Environments. In Proceedings International Symposium on the Virtual Reality Modeling Language (VRML 98), pages xi, 54, 55 [Broll et al. 98] Broll, W. et Schick, D. (1998). DWTP a basis for networked VR on the Internet. In Proceedings of IS & TISPE s Symposium on Electronic Imaging Science & Technology (EI 98): Workshop on Stereoscopic Displays and Virtual Reality Systems V, pages , San Jose. 54 [Brutzman et al. 97] Brutzman, D., Zyda, M., Watsen, K., et Macedonia, M. (1997). Virtual Reality Transfer Protocol (VRTP) Design Rationale. In Workshops on Enabling Technology: Infrastructure for Collaborative Enterprises (WET ICE) : Sharing Distributed Virtual Reality, pages , Massachusetts Institute of Technology, Cambridge Massachusetts. 39, 53 [Burdea et al. 93] Burdea, G. et Coiffet, P. (1993). La Réalité Virtuelle. Hermès. xi, 11, 12 [Calvin et al. 95] Calvin, J. O. et Weatherly, R. (1995). An introduction to the High Level Architecture (HLA) RunTime Infrastructure (RTI). In Proceedings of 14th Workshop on Standards for the Interoperability of Distributed Interactive Simulation, Orlando, Florida. xii, 111 [Capin et al. 99] Capin, T. K. et Thalmann, D. (1999). A Taxonomy of Networked Virtual Environments. In International Workshop on Synthetic - Natural Hybrid Coding and three Dimensional Imaging (IWSNHC3DI 99), P.Nomikos Conference Centre, Fira, Santorini, Greece. 138, 149 [Carothers et al. 97] Carothers, C. D., Fujimoto, R. M., Weatherly, R. M., et Wilson, A. L. (1997). Design and Implementation of HLA Time Management in the RTI Version F.0. In Winter Simulation Conference, pages [Cater et al. 95] Cater, J. P. et Huffman, S. D. (1995). Use of the Remote Access Virtual Environment Network (RAVEN) for Coordinated IVA-EVA Astronaut Training and Evaluation. Presence, 4(2): ,

289 Références bibliographiques [Cerf et al. 74] Cerf, V. G. et Kahn, R. E. (1974). A Protocol for Packet Network Intercommunication. IEEE Transactions on communications, 22(5): [Cheriton et al. 93] Cheriton, D. et Skeen, D. (1993). Understanding the Limitations of Causally and Totally Ordered Communication. In Proceedings of the 14th Symposium on Operating Systems Principles, pages 44 57, Asheville, NC, USA. 132 [Cizault 98] Cizault, G. (1998). IPv6 Théorie et pratique. O Reilly, Paris. 49 [Dagum 97] Dagum, L. (1997). OpenMP: A Proposed Industry Standard API for Shared Memory Programming. 71 [De Oliveira et al. 98] De Oliveira, M. F. D. et Pereira, J. M. (1998). VIRTUAL WORLDS A Virtual Environment Architecture. In Computer Graphics International, pages , Hannover, Germany. 42 [Demazeau 95] Demazeau, Y. (1995). From interactions to collective behaviour in agentbased systems. In Proceedings of the First European Conference on Cognitive Science, pages , Saint Malo, France. 21, 23 [Department of Defense 95] Department of Defense (1995). (M&S) Master Plan. DoD P. xii, 104 Modeling and Simulation [Department of Defense 98a] Department of Defense (1998a). High Level Architecture Interface Specification Version 1.3. IEEE P1516.1, Standard for Modeling and Simulation (M&S). 105, 106, 202, 222, 266 [Department of Defense 98b] Department of Defense (1998b). High Level Architecture Object Model Template Specification Version 1.3. IEEE P1516.2, Standard for Modeling and Simulation (M&S). 105, 174 [Deriggi Jr. et al. 99] Deriggi Jr., F. V., Kubo, M. M., Sementille, A. C., Brega, J. R. F., dos Santos, S. G., et Kirner, C. (1999). CORBA Platform as Support for Distributed Virtual Environments. In Proceedings of the IEEE Virtual Reality, pages 8 13, Houston, Texas. 86 [Diekmann et al. 97] Diekmann, R., Monien, B., et Preis, R. (1997). strategies for distributed memory machines. 135 Load balancing [Dit Picard et al. 01] Dit Picard, S. L., Degrande, S., Gransart, C., Saugis, G., et Chaillou, C. (2001). A CORBA based platform as communication support for synchronous collaborative virtual environment. In ACM Multimedia 2001, International Multimedia Middleware Workshop, Ottawa, Canada. 83, 86 [Drogoul et al. 95] Drogoul, A., Corbara, B., et Lalande, S. (1995). MANTA: New experimental results on the emergence of (artificial) ant societies. In Gilbert, N. et Conte, R., editors, Artificial Societies: The Computer Simulation of Social Life, pages UCL Press: London

290 Références bibliographiques [Dupont et al. 02] Dupont, D., Kökösy, A., Biela, P., et Saadane, A. (2002). RE1 Vie Artificielle : application à la résolution de problèmes complexes. In Techniques de l ingénieur, volume RI. Techniques de l ingénieur. 22 [Dutton et al. 95] Dutton, H. J. et Lenhard, P. (1995). Asynchronous Transfer Mode (ATM) Technical Overview, Second Edition. IBM Redbooks. Prentice Hall PTR. 48 [Ellis et al. 91] Ellis, C., Gibbs, S., et Rein, G. (1991). Groupware: Some issues and experiences. Communications of the ACM, 34(1): xii, 92 [Ferber 95] Ferber, J. (1995). Les Systèmes Multi-Agents Vers une intelligence collective. InterÉditions. xi, 22, 23, 27 [Ferber 97] Ferber, J. (1997). Les systèmes multi-agents : un aperçu général. Technique et science informatiques, 16(8): xi, 23, 24, 28 [Fert et al. 00] Fert,. et Jeannin, S. (2000). TE5360 Compressions MPEG-1 à MPEG-4. In Techniques de l ingénieur. Techniques de l ingénieur. 39 [Frécon et al. 98] Frécon, E. et Stenius, M. (1998). DIVE: a scaleable network architecture for distributed virtual environments. Distributed Systems Engineering Journal (special issue on Distributed Virtual Environments), 5(3): [Fuchs et al. 01] Fuchs, P., Moreau, G., et Papin, J.-P. (2001). Virtuelle. Les Presses de l École des Mines, Paris. 15 Le Traité de la Réalité [Fujimoto 00] Fujimoto, R. M. (2000). Parallel and Distributed Simulation Systems. Wiley- Interscience. xi, 46, 132 [Gabbard 97] Gabbard, J. L. (1997). environments. 138, 149 A taxonomy of usability characteristics in virtual [Gaudrault 95] Gaudrault, A. M. (1995). Load Balancing in a Distributed Virtual Reality Environment. Thèse de doctorat, University of Waterloo, Computer Science, Thèse, Waterloo, Ontario, Canada. 135, 137 [Geist et al. 94] Geist, A., Beguelin, A., Dongarra, J., Jiang, W., Manchek, R., et Sunderam, V. (1994). PVM: Parallel Virtual Machine - A Users Guide and Tutorial for Networked Parallel Computing. The MIT Press. 66 [Geist et al. 96] Geist, G., Khol, J. A., et Papadopoulos, P. M. (1996). PVM and MPI : comparison of features. Calculateurs Parallèles, 8(2): [Gelernter 85] Gelernter, D. (1985). Generative Communication in Linda. ACM transactions in programming languages and systems, 7(1): ,

291 Références bibliographiques [Greenhalgh 99] Greenhalgh, C. (1999). Large Scale Collaborative Virtual Environments. Thèse de doctorat, Faculty of Science, School of Computer Science and Information Technology, University Park, University of Nottingham, CPHC/BCS Distinguished Dissertations in Computer Science competition 1998, Nottingham, NG7 2RD, UK. 127 [Greenhalgh et al. 01] Greenhalgh, C., Izadi, S., Rodden, T., et Benford, S. (2001). The EQUIP Platform: Bringing Together Physical and Virtual Worlds. Technical report, Department of Computer Science, Nottingham University, Angleterre. 73 [Gropp et al. 97] Gropp, W. et Lusk, E. (1997). Why Are PVM and MPI So Different. In Bubak, M., Dongarra, J., et Wasniewski, J., editors, PVM/MPI, volume 1332 of Lecture Notes in Computer Science, pages Springer. 66 [Grumbach 01] Grumbach, A. (2001). Cognition Virtuelle Réflexion sur le virtuel, ses implications cognitives, ses réalisations artistiques. ENST, Paris. xi, 11 [Guillaud et al. 02] Guillaud, A., Troadec, H., Benzinou, A., Le Bihan, J., et Rodin, V. (2002). A multiagent system for edge detection and continuity perception on fish otolith images. EURASIP Journal on Applied Signal Processing, 7: [Guyennet 97] Guyennet, H. (1997). Chapitre 18 : Travail coopératif et mémoire partagée répartie. In Conception et mise en œuvre d applications parallèles irrégulières de grande taille, ICaRE 97, Aussois, France. 35 [Harrouet 00] Harrouet, F. (2000). oris : s immerger par le langage pour le prototypage d univers virtuels à base d entités autonomes. Thèse de doctorat, Université de Bretagne Occidentale, Equipe d accueil 2215, Laboratoire d Informatique Industrielle. xiii, 1, 2, 157, 158, 159 [Harrouet et al. 02] Harrouet, F., Tisseau, J., Reignier, P., et Chevaillier, P. (2002). oris : un environnement de simulation interactive multi-agents. Revue des sciences et technologies de l information Technique et science informatiques, 21(4): [Hewitt 77] Hewitt, C. (1977). Viewing control structures as patterns of passing messages. Artificial Intelligence, 8(3): [Hofer et al. 95] Hofer, R. C. et Loper, M. L. (1995). DIS Today. Proceedings of the IEEE, Special issue on Distributed Interactive Simulation, 83(8): xii, 102, 126, 267 [Honda et al. 96] Honda, Y., Matsuda, K., Rekimoto, J., et Lea, R. (1996). Virtual Society: Extending the WWW to support a Multi-user Interactive Shared 3D Environment. In In Proceedings of Virtual Reality Modeling Language (VRML) Symposium 96, pages , New York, USA. xi,

292 Références bibliographiques [Hu et al. 00] Hu, Y. C., Lu, H., Cox, A. L., et Zwaenepoel, W. (2000). OpenMP for Networks of SMPs. Journal of Parallel and Distributed Computing, 60(12): [Jensen 96] Jensen, C. D. (1996). Fine-grained load distribution in object based systems. an experiment with grain sizes in guide-2. Calculateurs parallèles, 8(1). xii, 136 [Johansen 88] Johansen, R. (1988). Groupware Computer Support for Business Teams. The Free Press. 92 [Kanevsky et al. 98] Kanevsky, A., Skjellum, A., et Rounbehler, A. (1998). MPI/RT An Emerging Standard for High-Performance Real-Time Systems. In Thirty-First Annual Hawaii International Conference on System Sciences- Volume 3, pages , Kohala Coast, HI. 67, 68 [Kessler et al. 96] Kessler, G. D. et Hodges, L. F. (1996). A Network Communication Protocol for Distributed Virtual Environment Systems. In Virtual Reality Annual International Symposium, pages , Santa Clara, CA. 39 [Khoshafian et al. 98] Khoshafian, S. et Buckiewicz, M. (1998). Groupware & workflow. Masson. 92 [Ko et al. 99] Ko, D. et Choi, Y. (1999). Design of Network Protocols for Distributed Virtual Environments. In IEEE Multimedia Computing and Systems (ICMCS), volume 2, pages , Florence, Italie. xi, 39, 61 [Kosko 86] Kosko, B. (1986). Fuzzy cognitive maps. International Journal Man-Machine Studies, 24: [Kuhl et al. 99] Kuhl, F., Weatherly, R., et Dahmann, J. (1999). Creating Computer Simulation Systems: An Introduction to the High Level Architecture. Prentice-Hall. 105 [Lamine 01] Lamine, E. (2001). Définition d un modèle de propriété et proposition d un langage de spécification associé : LUSP. Thèse de doctorat, Université de Montpellier II, Sciences et techniques du Languedoc. 1 [Lamotte et al. 97] Lamotte, W., Flerackers, E., Reeth, F. V., Earnshaw, R., et de Matos, J. M. (1997). Visinet: Collaborative 3D Visualization and VR over ATM Networks. IEEE Computer Graphics and Applications, 17(2): [Lamport 78] Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7): [Langton 89] Langton, C. G., editor (1989). Artificial Life: the Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems, Redwood City, CA. Addison-Wesley. Workshop held September, 1987 in Los Alamos, New Mexico

293 Références bibliographiques [Lea et al. 95] Lea, R., Honda, Y., Matsuda, K., et Rekimoto, J. (1995). Technical issues in the design of a scalable shared virtual world. In Sony Research Forum (SRF 95), Tokyo. 42, 60 [Liles et al. 98] Liles, C. S., Watsen, K., et Zyda, M. (1998). Dynamic Discovery of Simulation Entities Using Bamboo and HLA. In Proceedings of the 1998 Fall Simulation Interoperability Workshop, Orlando, Florida, USA. 143 [Liles 98] Liles, S. W. (1998). Dynamically extending a networked virtual environment using Bamboo and the High Level Architecture. Master s thesis, Naval Postgraduate School, Monterey, Californie, USA. xii, 143, 144 [Locke 94] Locke, J. (1994). An Introduction to the Internet Networking Environment and SIMNET/DIS. Technical report, Computer Science Department, Naval Postgraduate School. 42 [Lockhart 94] Lockhart, H. W. (1994). OSF/DCE, Guide to Developing Distributed Applications. J. Ranade Workstation Series. McGraw-Hill. 78 [Macedonia 95] Macedonia, M. R. (1995). A network software architecture for large scale virtual environments. Thèse de doctorat, PhD thesis, Naval Postgraduate School, Monterey, California. 70, 129, 130 [Macedonia et al. 97] Macedonia, M. R. et Zyda, M. J. (1997). A Taxonomy for Networked Virtual Environments. IEEE Multimedia, 4(1): , 138, 140, 149 [Maes 95] Maes, P. (1995). Artificial Life An Overview, chapter Modeling Adaptive Autonomous Agents, pages the MIT Press, Cambridge. 27 [Manninen et al. 97] Manninen, T. et Pirkola, J. (1997). Comparative Classification of Multi-User Virtual Worlds. In VR-SIG seminaari - osa 3. Ryhmätyöt Raahesta ja Oulusta. 138, 149 [Margery 01] Margery, D. (2001). Environnement logiciel temps-réel distribué pour la simulation sur réseau de PC. Thèse de doctorat, Université de Rennes 1, Projet SIAMES, IRISA/INRIA. 70 [Meinadier 98] Meinadier, J. (1998). Ingénierie et intégration des systèmes. Collection Études et Logiciels Informatiques. Hermès. 1 [Mellet d Huart 01] Mellet d Huart, D. (2001). Training beyond reality: when the abstract becomes real. In Simon Richir, P. R. e. B. T., editor, Proceedings Virtual Reality International Conference (VRIC), pages 39 46, Laval, France. Laval Virtual. 10 [Méhaut et al. 96] Méhaut, J.-F. et Namyst, R. (1996). Deux approches pour la programmation parallèle: PVM et Linda. Actes de l école d été sur le Placement et la Régulation de Charge (PRC 96), pages

294 Références bibliographiques [MPI Forum 95a] MPI Forum (1995a). MPI-2: Extensions to the Message-Passing Interface, Version [MPI Forum 95b] MPI Forum (1995b). Version MPI: A Message-Passing Interface Standard, [MPI/RT Forum 01] MPI/RT Forum (2001). Document for the Real-Time Message Passing Interface (MPI / RT-1.1). Real-Time Message Passing Interface (MPI/RT) Forum. 67 [Nédélec et al. 00] Nédélec, A., Reignier, P., et Rodin, V. (2000). Collaborative Prototyping in Distributed Virtual Reality Using Agent Communication Language. In Proceedings IEEE SMC 2000, volume 2, pages , Nashville, USA. 162 [Nicolas et al. 01] Nicolas, M., Abgrall, J. F., Rodin, V., Ballet, P., et Tisseau, J. (2001). Multiagent simulation of blood coagulation. ISTH 01:P2139, Supplement to the journal Thrombosis and Hæmostasis. 29 [Nii 86] Nii, P. (1986). Blackboard systems: The blackboard model of problem solving and the evolution of blackboard architectures. The AI Magazine, 7(2): [OMG 01] OMG (2001). OMG Final Adopted Specification Unreliable Multicast Inter- ORB Protocol Specification. Object Management Group. 83, 267 [OMG 02] OMG (2002). Time Service Specification Version 1.1. Technical report, Object Management Group. 80 [OpenMP 02] OpenMP (2002). OpenMP C and C++ Application Program Interface Version 2.0. OpenMP Architecture Review Board. 71 [Overgaard et al. 94] Overgaard, L., Petersen, H., et Perram, J. W. (1994). Motion Planning for an Articulated Robot: a Multi-Agent Approach. In Y. Demazeau, J.-P. M. e. J. P., editor, 6th European Workshop on Modelling Autonomous Agents, MAAMAW 94, pages , Odense, Danemark. 21 [Papadopoulos et al. 98] Papadopoulos, P. M., Kohl, J. A., et Semeraro, B. D. (1998). CUMULVS: Extending a Generic Steering and Visualization Middleware for Application Fault-Tolerance of Parallel Applications. In Proceedings of the 31st Hawaii International Conference on System Sciences (HICSS-31), volume 8, pages , Kona, Hawaii. 66 [Parenthoën et al. 01] Parenthoën, M., Tisseau, J., Reignier, P., et Dory, F. (2001). Agent s Perception and Charactors in Virtual Worlds; Put Fuzzy Cognitive Maps to Work. In Virtual Reality International Conference (VRIC 01), pages 11 18, Laval, France. 18 [Pollet 02] Pollet, F. (2002). La fin des prototypes physiques? Revue Harvest. de la conception produit à l usine numérique, pages

295 Références bibliographiques [Pujolle 95] Pujolle, G. (1995). Les Réseaux, deuxième édition. Eyrolles. 37 [Pullen 99] Pullen, J. M. (1999). Reliable Multicast Network Transport for Distributed Virtual Simulation. In Proceedings of the IEEE Workshop on Distributed Interactive Simulation and Real-Time Systems (DIS-RT), pages , 44, 52, 268 [Pullen et al. 95] Pullen, J. M. et Wood, D. C. (1995). Networking Technology and DIS. Proceedings of the IEEE, Special issue on Distributed Interactive Simulation, 83(8): , 101 [Purtilo 94] Purtilo, J. M. (1994). The POLYLITH Software Bus. ACM Transactions on Programming Languages and Systems, 16(1): [Querrec 02] Querrec, R. (2002). Les systèmes Multi-Agents pour les Environnements Virtuels de Formation Application à la sécurité civile. Thèse de doctorat, Thèse, Université de Bretagne Occidentale. xi, 19, 20, 29, 267 [Raulet et al. 02a] Raulet, V., Nédélec, A., et Rodin, V. (2002a). Coupling HLA with a MAS based DVR environment. In IASTED International Conference Applied Informatics, pages , Innsbruck, Austria. 4 [Raulet et al. 03a] Raulet, V., Nédélec, A., et Rodin, V. (2003a). A new API to the HLA declaration and object management services for runtime modifications and autonomy. In European Simulation Interoperability Workshop 2003 (03E-SIW-092), pages , Stockholm, Sweden. SISO. 4, 198 [Raulet et al. 02b] Raulet, V., Rodin, V., et Nédélec, A. (2002b). orisdis: using HLA and dynamic features of oris multi-agent platform for cooperative prototyping in virtual environments. In European Simulation Interoperability Workshop 2002 (02E-SIW-022), London, UK. SISO. 4 [Raulet et al. 03b] Raulet, V., Rodin, V., et Nédélec, A. (2003b). Using HLA to provide a Collaborative Multi Agent Virtual Prototyping platform. In Spring Simulation Interoperability Workshop 2003 (03S-SIW-051), Florida, USA. SISO. 4 [Raynal 92a] Raynal, M. (1992a). Gestion des données réparties : problèmes et protocoles. Collection de la Direction des Études et Recherches d Électricité de France. Eyrolles. 65 [Raynal 92b] Raynal, M. (1992b). Synchronisation et état global dans les systèmes répartis. Collection de la Direction des Études et Recherches d Électricité de France. Eyrolles. 65 [RFC ] RFC1889 (1996). RTP: A Transport Protocol for Real-Time Applications. Network Working Group (Audio-Video Transport Working Group). 47 [RFC ] RFC2205 (1997). Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. Network Working Group

296 Références bibliographiques [RFC958 85] RFC958 (1985). Network Time Protocol (NTP). Network Working Group. 46 [Richard 01] Richard, N. (2001). Description de comportements d agents autonomes évoluant dans des mondes virtuels. Thèse de doctorat, Thèse, École Nationale Supérieure des Télécommunications, Paris. xi, 25, 28 [Rodin et al. 00] Rodin, V., Raulet, V., et Nédélec, A. (2000). Using a multiagent language for collaborative interactive prototyping. In Proceedings of the third international conference on Collaborative virtual environments, pages ACM Press New York, NY, USA. 4 [Rodriguez 03] Rodriguez, A. N. (2003). ASSET : Une architecture générale pour la télérobotique. Thèse de doctorat, Université Paul Sabatier, Thèse, Institut de Recherche en Informatique de Toulouse. 168 [Rumelhart et al. 86] Rumelhart, D. E., McClelland, J. L., et Group, P. R. (1986). Parallel Distributed Processing Explorations in the Microstructure of Cognition Volume 1 : Foundations. The MIT Press. 18 [Schmidt et al. 00] Schmidt, D. C. et Kuhns, F. (2000). An Overview of the Real-Time CORBA Specification. Computer, pages [Schmidt et al. 98] Schmidt, D. C., Levine, D. L., et Mungee, S. (1998). The Design of the TAO Real-Time Object Request Broker. Computer Communications, 21(4): , 114, 267 [Schmidt et al. 97] Schmidt, D. C. et Vinoski, S. (1997). Object Interconnections The OMG Events Service. SIGS C++ Report, 9(2):37 46, [Schroeder et al. 90] Schroeder, M. D. et Burrows, M. (1990). Performance of the Firefly RPC. ACM Transactions on Computer Systems, 8(1): [Shirmohammadi et al. 00] Shirmohammadi, S. et Georganas, N. D. (2000). Collaborating in 3D Virtual Environments: A Synchronous Architecture. In IEEE 9th International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 00), pages 35 42, Gaithersburg, Maryland. 171 [Singh et al. 95] Singh, G., Serra, L., Png, W., Wong, A., et Ng, H. (1995). BrickNet: Sharing Object Behaviors on the Net. In Proceedings of IEEE VRAIS 95, pages [Singhal et al. 99] Singhal, S. et Zyda, M. (1999). Networked Virtual Environments Design and Implementation. Addison-Wesley, ACM Press. 99 [Singhal 96] Singhal, S. K. (1996). Effective Remote Modeling in Large-Scale Distributed Simulation and Visualization Environments. Thèse de doctorat, Thèse, Department of Computer Science, Stanford University. xii, 119, 120, 122,

297 Références bibliographiques [Slater et al. 93] Slater, M. et Usoh, M. (1993). Presence in immersive virtual environments. In Proceedings of the IEEE Virtual Reality Annual International Symposium, pages 90 96, Seattle, WA, USA. 138 [Stotts et al. 94] Stotts, P. D. et Purtilo, J. M. (1994). Virtual Environment Architectures: interoperability through software interconnection technology. In IEEE Computer Society Press, Proceedings of the Third Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, pages , Morgantown, W.Va. 76 [Stytz 96] Stytz, M. R. (1996). Distributed Virtual environments. IEEE Computer Graphics and Applications, 16(3): , 139, 149 [Sun Microsystems 00] Sun Microsystems (2000). JavaSpaces Service Specification, Version San Antonio Road, Palo Alto, CA USA. 71 [Swing 00] Swing, E. (2000). Adding Immersion To Collaborative Tools. In VRML 2000, pages 63 68, Monterey, CA, USA. 94 [Szwarcman et al. 01] Szwarcman, D., Feijó, B., et Costa, M. (2001). Goal-oriented dead reckoning for autonomous characters. Computers and Graphics, 25: xii, 51, 123, 124 [Tanenbaum 94] Tanenbaum, A. (1994). Systèmes d exploitation Systèmes centralisés, systèmes distribués. InterÉditions. xi, xii, 77, 78 [Tanenbaum 96] Tanenbaum, A. (1996). Dunod. 37 Réseaux Cours et exercices, 3ème édition. [Tisseau 01] Tisseau, J. (2001). Réalité Virtuelle autonomie in virtuo. Habilitation à Diriger des Recherches, Université de Rennes I. xi, 2, 12, 13, 31 [Torguet 98] Torguet, P. (1998). VIPER : Un modèle de calcul réparti pour la gestion d environnements virtuels. Thèse de doctorat, Thèse, IRIT, Paul Sabatier University (2954). xiii, 147 [U.S. Congress 94] U.S. Congress (Septembre 1994). Virtual Reality and Technologies for Combat Simulation Background Paper. Technical report, Office of Technology Assessment, OTA-BP-ISS , 95, 96 [van Reimersdahl et al. 00] van Reimersdahl, T., Kuhlen, T., Gerndt, A., Henrichs, J., et Bischof, C. (2000). ViSTA: a multimodal, platform-independent VR-Toolkit based on WTK, VTK, and MPI. In Fourth International Immersive Projection Technology Workshop (IPT2000), Ames, Iowa. 67, 68 [Waters et al. 97] Waters, R. C., Anderson, D. B., et Schwenke, D. L. (1997). Design of the Interactive Sharing Transfer Protocol. In 6th Workshop on Enabling 281

298 Références bibliographiques Technologies (WET-ICE 97), Infrastructure for Collaborative Enterprises, June 1997, MIT, Cambridge, MA, USA, Proceedings, pages xi, 56, 57 [Watsen et al. 98a] Watsen, K. et Zyda, M. (1998a). Bamboo - A Portable System for Dynamically Extensible, Real-time, Networked, Virtual Environments. In Proceedings for the IEEE Virtual Reality Annual International Symposium (VRAIS 98), pages , Atlanta, Georgia, USA. IEEE Computer Society Press. 54, 198 [Watsen et al. 98b] Watsen, K. et Zyda, M. (1998b). Bamboo - Supporting dynamic protocols for virtual environments. In IMAGE Conference, pages KA 1 9, Scottsdale, Arizona, USA. 54 [Weatherly et al. 96] Weatherly, R. M. et Fischer, M. C. (1996). Advanced Distributed Simulation through the Aggregate Level Simulation Protocol. In 29th Hawaii International Conference on System Sciences, volume 1, pages , Wailea, Hawaii. 103 [Wilson et al. 01] Wilson, S., Sayers, H., et McNeill, M. D. (2001). Using CORBA Middleware to Support the Development of Distributed Virtual Environment Applications. In Skala, V., editor, Proceedings of 9th International Conference in Central Europe on Computer Graphics, Visualization and Computer Vision, pages , Plzen, Czech Republic. xii, 9, 85, 86 [Wolfe et al. 00] Wolfe, V. F., DiPippo, L. C., Cooper, G., Johnston, R., Kortmann, P., et Thuraisingham, B. M. (2000). Real-Time CORBA. IEEE Transactions on Parallel and Distributed Systems, 11(10): [Wooldridge 99] Wooldridge, M. (1999). Multiagent Systems A modern Approach to Distributed Artificial Intelligence, chapter Intelligent Agents, pages Massachusetts Institute of Technology. 21, 26 [Yavatkar et al. 95] Yavatkar, R., Griffioen, J., et Sudan, M. (1995). A Reliable Dissemination Protocol for Interactive Collaborative Applications. In ACM Multimedia, pages ,

299 Résumé / Abstract La pluridisciplinarité rendue nécessaire par la complexité croissante des modèles implique l interaction entre plusieurs spécialistes. De plus, les cycles de conception-validation d un modèle sont particulièrement coûteux et le recours à la gestion du cycle de vie d un produit de manière entièrement numérique procure un avantage indéniable. Ces besoins incitent au développement de nouveaux outils de prototypage permettant un échange collaboratif, coopératif et interactif. La mise en place d un outil de prototypage numérique requiert plusieurs domaines de compétence que sont la réalité virtuelle, les systèmes multi-agents et la distribution. Toutes ces considérations nous incitent à définir un support d interopérabilité permettant cette interactivité évolutive. Pour l établir, nous étudions les différentes possibilités offertes par les couches de communication dans un contexte de prototypage. Cette analyse ascendante des différentes couches est établie du réseau physique jusqu aux architectures de haut niveau offrant des services complexes. En outre, cette étude verticale nous permet de conserver les spécificités de chaque couche et d en tenir compte dans notre contexte de prototypage. Notre contribution tient dans la réalisation d une architecture offrant les aspects distribués pour un outil de prototypage permettant de modéliser des systèmes sous une forme extrêmement décentralisée. Ces aspects concernent, entre autres, l évolutivité du modèle en conservant les propriétés dynamiques du langage de programmation. L originalité de notre démarche repose sur l utilisation d une architecture de communication orientée vers la simulation interactive distribuée HLA ou High Level Architecture à laquelle nous apportons des propriétés dynamiques originellement inexistantes. Mots-clés : réalité virtuelle, systèmes multi-agents, prototypage interactif, langage dynamique, High Level Architecture. 283

300 Résumé / Abstract Multidisciplinary nature needed by growing complexity in models involves interactions between several specialists. Moreover, cycles between design and validation of models are particularly expensive. Resort to a completely numerical product life-cycle management provides an undeniable advantage. These needs are an incentive to developing new prototyping tools providing collaborative, cooperative and interactive exchange. Setting up a numerical prototyping tool requires several fields of competence in virtual reality, multi agent systems and distribution. All these considerations lead us to define an interoperable architecture allowing this evolving interactivity. To set this up, we study the different opportunities, available in current communication layers, oriented for numerical prototyping. This upward analysis of the various layers is made from the physical network up to high level architectures designed for providing complex services. Moreover, this vertical analysis allows us to keep specificities from each layer and take account of these in this context. Our contribution stands in the achievement of an architecture, which offers distributed aspects needed for a prototyping tool aimed at designing systems in a strongly decentralized fashion. These aspects concern, inter alia, model evolution by keeping the dynamic properties of the associated programming language. The originality of this approach is based on the use of a communication architecture for distributed interactive simulation HLA or High Level Architecture to which we provide the dynamic properties initially lacking. Keywords: virtual reality, multi agent systems, interactive prototyping, dynamic language, High Level Architecture. 284

301 Index ATM, 48 Bamboo, 143 Broadcast, 50 Communication par mémoire partagée, 70 Communication par messages, 66 MPI, 67 PVM, 69 CORBA, 78 Architecture, 79 Service d évènement, 73 Service de notification, 75 TAO, 84 temps réel, 84 Dead reckoning, 119 basé sur l intention, 123 PHBDR, 122 Diffusion, 50 Fiable, 51 Restreinte, 50 DIS, 96 PDU, 99 ESPDU, 101 DIVE, 145 DWTP, 54 EQUIP, 73 Filtrage, 125 Conscience, 127 Déclaration, 126 Modèle spatial, 126 Objets tiers, 128 GAIA, 61 Gestion du temps, 131 HLA, 103 Gestion de la déclaration, 108 Gestion de la fédération, 107 Gestion des objets, 109 Gestion du temps, 133 ISTP, 56 JavaSpaces, 72 Linda, 72 MPI, 67 MPI/RT, 67 Multicast, 50 fiable, 51 NTP, 45 OpenMP, 71 oris, 157 Plates-formes Bamboo, 143 DIVE, 145 EQUIP, 73 VIPER,

302 Index PVM, 69 Qualité de service, 47 Réalité Virtuelle, 9 les outils, 14 logiciel, 17 Répartition de la charge, 134 Réseau Bande Passante, 41 Fiabilité, 42 Latence, 41 Protocoles, 43 Topologie, 43 RPC, 76 RSVP, 49 RTP, 47 Systèmes multi-agents, SMA, 21 TAO, 84 VIPER, 147 ViSTA, 68 VRTP, 53 VSCP,