Systèmes répartis pour le prototypage virtuel coopératif et le contrôle des procédés industriels

Document de synthèse de l'activité scientifique pour l Habilitation à Diriger les Recherches Université de Bordeaux 1 Spécialité Informatique Christian TOINARD Systèmes répartis pour le prototypage virtuel coopératif et le contrôle des procédés industriels

Résumé L'industrie manufacturière présente deux grandes composantes qui sont la conception du produit et sa fabrication. Dans ces deux domaines, l'informatique répartie et les réseaux font évoluer fortement les méthodes de conception et de fabrication. Le travail qui est présenté ici s'est déroulé en quasi-totalité sous forme de contrats de recherche dans le cadre d'une coopération scientifique industrielle. Cette coopération a abouti à différents prototypes mais aussi à des outils informatiques réellement déployés et utilisés notamment pour la conception des systèmes Aéronautiques. Elle a donné lieu a plusieurs publications internationales. Cette activité scientifique a aussi conduit à participer à un projet européen IST. Pour la conception manufacturière, l'ingénierie concourante permet à plusieurs sites et sociétés de coopérer à la conception d'un produit manufacturier. Les besoins sont variés. Nous considérons les méthodes et les outils informatiques qui permettent à un groupe de concepteurs de coopérer pour spécifier un prototype virtuel initial du produit. On parlera donc de prototypage virtuel coopératif. Ce domaine est assez neuf et les concepts émergent petit à petit pour définir de nouvelles méthodes de coopération pour le prototypage virtuel. Pour que les solutions définies soient réellement applicables d'un point de vue industriel, nous avons concentré notre travail sur la conception initiale d'un produit. Par exemple, lors du premier prototypage d'un avion il s'agit d'allouer l'espace des différentes pièces de l'avion tout en vérifiant certaines règles de bon fonctionnement et de sécurité telles qu'une distance minimale entre les circuits d'alimentation en combustible et les circuits électriques. Cette première phase de prototypage permet donc de définir au plus vite les contours et les principaux composants du produit. Elle doit comporter une phase de validation afin d'éviter au plus-tôt les défauts de conception. Les principaux objectifs sont donc la réduction des temps de conception et l'amélioration de la qualité des produits. Notre travail a donc porté sur ces deux objectifs. Les gains de temps sont obtenus principalement grâce à une coopération efficace entre les concepteurs. Deux facteurs essentiels permettent d'accroître la qualité. D'une part, la solution offre plusieurs modes de coopération qui peuvent être utilisés aisément dans une entreprise étendue. D'autre part des simulateurs peuvent être intégrés au prototype virtuel durant le processus de conception réparti ce qui permet de valider à la fois partiellement puis globalement la spécification. Notre apport consiste à définir une nouvelle méthode de coopération et de simulation qui puisse être déployée sur l'internet pour partager une spécification du produit. Cette méthode permet de faire du prototypage virtuel rapide. Elle comporte deux composantes qui sont la conception coopérative et la simulation répartie. La partie conception coopérative repose sur une technique de répartition de la scène 3D qui supporte le travail mobile et permet aisément de passer d'un mode de travail à un autre. Les concepteurs peuvent travailler en parallèle et le système garantit la progression de leurs travaux. Les modes de travail autorisés vont de la revue de maquette, à la conciliation des travaux en passant par la conception répartie. La solution est entièrement répartie et aisément utilisable sur l'internet standard tout en procurant un niveau de sécurité qui assure l'authentification et la confidentialité des données transmises entre les participants. La partie simulation répartie utilise une technique de couplage et de synchronisation des simulateurs. Elle repose sur une méthode d'ordonnancement qui peut être déployée sur l'internet et permet de synchroniser les différents simulateurs. La solution retenue est efficace car elle permet à la fois des validations partielles et une validation globale de la spécification. Elle est originale à plusieurs titres. Tout d'abord, elle ne demande pas aux applications de contrôler la progression d'un temps logique. De plus, l'architecture du système réparti repose sur une nouvelle technique qui permet de simplifier le système de communication et de relier aisément les différents simulateurs d'une entreprise étendue. 2

En ce qui concerne la fabrication manufacturière, les systèmes répartis sont présents depuis plus longtemps. Le domaine est plus ancien et repose sur l'architecture CIM ("Computer Integrated Manufacturing"). L'objectif est alors de permettre à différents calculateurs de communiquer et de se synchroniser pour d'une part gérer les différentes étapes de production et d'autre part contrôler et superviser en temps réel le processus de fabrication. Notre contribution concerne l'aspect contrôle et commande temps réel. L'apport est de définir comment utiliser des composants sur étagères tels que les réseaux de terrains, les réseaux TCP/IP ("Transmission Control Protocol/Internet Protocol) et CORBA ("Common Object Request Broker Architecture") pour obtenir des propriétés temporelles, d'ordonnancement et de tolérance aux fautes. La solution définit permet d'utiliser un réseau de terrain standard de type FIP ("Factory Instrumentation Protocol") et de montrer que ce réseau peut aussi garantir des propriétés d'ordonnancement pour certaines vitesses de mise à jour. D'autre part, un second système de communication utilisant CORBA complète les propriétés du réseau de terrain en offrant une redondance de communication. Enfin, une méthode utilisant une station de supervision CORBA et les deux réseaux permet de tolérer les pannes franches des calculateurs de procédé. Notre travail relève d'une démarche où les solutions définies doivent être réellement utilisables en permettant aux industriels d'avoir une avance technologique. Cette démarche demande d'une part de connaître au mieux les solutions industrielles existantes ainsi que les projets de recherches. Elle impose aussi d'innover de façon significative pour que l'avance technologique soit réelle et durable. Notre méthode de travail repose sur une implication directe vis à vis des besoins industriels, une connaissance approfondie de l'état de l'art et des solutions permettant un gain réel tout en restant utilisable en grandeur réelle. L'exposé se déroule de la façon suivante. Une introduction permet de motiver le travail, de définir les objectifs et de justifier les orientations prises. Deux parties distinctes sont ensuite développées. Une première partie traite du prototypage virtuel coopératif. Ce domaine constituant l essentielle de notre activité depuis 1997, nous avons choisi de détailler les résultats. Nous présentons les solutions mises en œuvre pour la conception coopérative et la simulation en environnement de réalité virtuelle. Dans cette partie, on trouve la motivation de l'étude, un état de l'art, une justification et une présentation des solutions. La seconde partie expose les résultats pour le contrôle réparti des procédés. Etant donné qu il s agit de sujets sur lesquels nous nous ne travaillons plus depuis 1993, nous avons volontairement résumé ces travaux. Nous présentons simplement les principes de la solution et la justifions brièvement par rapport à des propositions de référence. 3

PLAN 1. Introduction...5 1.1 Motivation et démarche...5 1.2 Prototypage virtuel coopératif...6 1.2.1 Objectifs et besoins...6 1.2.2 Travaux existants...9 1.2.3 Apports...12 1.3 Contrôle réparti de procédés industriels...15 1.3.1 Objectifs et besoins...15 1.3.2 Travaux existants...16 1.3.3 Apports...17 1.4 Déroulement, encadrements, contrats, projet européen, publications...20 2. Prototypage virtuel coopératif...22 2.1 Motivation...22 2.2 Principe et justification de notre solution...24 2.2.1 Conception coopérative...24 2.2.2 Services pour la simulation répartie...26 2.3 Conception coopérative...28 2.3.1 Etat de l art...28 2.3.1.1 Environnements industriels de CAO coopératifs...28 2.3.1.2 Réalité virtuelle répartie...30 2.3.1.3 Discussion...36 2.3.2 La solution de la métaphore du chantier réparti...37 2.3.2.2 Présentation de la métaphore...40 2.3.2.3 Implantation de la solution...56 2.3.3 Travaux comparables et discussion...62 2.4 Simulation répartie...64 2.4.1 Etat de l art...65 2.4.1.1 Simulation à évènements discrets...65 2.4.1.2 Systèmes à diffusion ordonnée...70 2.4.2 La solution CTOP...73 2.4.2.1 Résultats formels obtenus...73 2.4.2.2 Description de la solution CTOP...76 2.4.3 Comparaisons et discussions...83 2.4.3.1 Simulation discrète versus systèmes à diffusion ordonnée...83 2.4.3.2 Comparaisons avec d autres systèmes à diffusion ordonnée...83 2.5 Résultats, intervenants et perspectives...85 2.4 Publications...87 3. Contrôle réparti des procédés industriels...89 3.1 Motivation...89 3.2 Principe et justification de notre solution...92 3.3 Résultats, intervenants et perspectives...98 3.4 Publications...99 Bibliographie...101 4

1. Introduction 1.1 Motivation et démarche Les techniques de systèmes répartis sont nombreuses et commencent à être bien établies. D'une part, on trouve des services pour assurer la désignation, la cohérence, l'atomicité, la persistance, la synchronisation et la tolérance aux fautes. D'autre part, des environnements normalisés et des systèmes opérationnels tels que les protocoles TCP/IP, CORBA, Java, le Web ou pour deux domaines différents des réseaux de terrains industriels et des systèmes transactionnels répartis. Ces normes et implantations couvrent plus ou moins les services nécessaires pour la mise en œuvre des systèmes répartis. Par exemple, CORBA traite bien la désignation client-serveur et la synchronisation dans ce contexte. Les systèmes transactionnels répartis tels que Oracle ou Microsoft SQL Server permettent d'exécuter des transactions qui sont répartis sur plusieurs bases tout en garantissant la cohérence et l'atomicité des données. Malgré l'étendue des solutions tant universitaires qu'industrielles, les besoins des utilisateurs et des développeurs se trouvent cependant souvent mal couverts. Les concepts universitaires et les implantations proposées se focalisent sur des études assez fondamentales. Par exemple, ils étudient des problèmes difficiles de synchronisation, de cohérence ou de tolérance aux pannes. D'un autre côté, les besoins réels des industriels requièrent souvent des solutions plus tournées vers des gains réels en termes de facilité d'usage, de coûts financiers et d'avancée technologique opérationnelle. Ainsi, les solutions de répartition pour le contrôle des procédés sont souvent complexes et ne répondent pas complètement aux exigences des utilisateurs. Par exemple, un mécanisme de tolérances aux pannes peut traiter de nombreuses situations de pannes mais nécessite une synchronisation précise des horloges des différents calculateurs. Il se trouve alors difficile et coûteux à mettre en œuvre. Ou bien en cas de partition du réseau, deux sous-ensembles continuent les traitements ce qui risque de conduire à deux opérations contradictoires qui rendent une pièce défectueuse. Dans le domaine de la coopération pour la prototypage virtuel, les solutions se concentrent sur la revue de maquette et ne permettent pas à des concepteurs de coopérer efficacement et librement à la définition de la maquette. D'un autre côté, les environnements de réalité virtuelle distribuée traitent le cas d'un grand nombre d'objets mobiles et limitent la consommation en bande passante par des techniques d'estimation et en considérant la fraîcheur des objets. Cependant, ces méthodes ne permettent pas de répartir la scène entre des concepteurs mobiles et ne garantissent pas la progression du travail pour des concepteurs partageant et travaillant en parallèle sur le même prototype virtuel. Pour la simulation et la validation répartie des spécifications premières d'un produit manufacturier, les solutions sont le plus souvent inexistantes. Les principales propositions reposent sur des techniques de simulation à événements discrets qui laissent une grande responsabilité aux applications et restent d'un usage difficile. Elles demandent aux personnes chargées de la simulation de décrire explicitement les interactions et de contrôler le temps logique des événements échangés. Par ailleurs, les techniques de diffusion des messages vers les différents simulateurs sont peu utilisées dans ce contexte car reposant sur des solutions complexes, peu ouvertes, peu efficaces sur l'internet et intégrant généralement des propriétés de tolérances aux pannes qui ne sont pas utiles pour la simulation. 5

Les environnements industriels se concentrent sur des solutions qui bien souvent reprennent des techniques déjà éprouvées dans d'autres systèmes. Ils travaillent alors sur une implantation plus facile d'usage, couvrant mieux certains problèmes techniques. Par exemple, CORBA propose une spécification plus large et plus ouverte des appels de procédures à distance qui ont été développés dans les systèmes Unix. CORBA vise une intégration des systèmes existants via un bus logiciel. Ainsi, des systèmes transactionnels variés peuvent par exemple s'intégrer via le service transactionnel CORBA. Mais les besoins utilisateurs peuvent être là aussi mal couverts. Par exemple, CORBA n'offre pas de solution pour partager une scène graphique 3D et coopérer de façon mobile et efficace à la définition d'un prototype virtuel. Même des environnements plus spécialisés à un domaine d'application, tels qu'un outil de CAO comme CATIA de Dassault Systèmes ne traite qu'une partie des besoins utilisateurs. Ils permettent principalement la revue d'une maquette par un groupe de participants et ne permettent pas d'activités de conception coopérative sophistiquées. Les raisons de ces manques en terme de couverture des besoins et d'avancées technologiques pour les utilisateurs finaux sont souvent les mêmes. Les concepteurs et les chercheurs sont souvent peu en prise avec les utilisateurs finaux. Ils ne peuvent donc pas prendre en compte l'ensemble des exigences. D'un autre côté, les utilisateurs finaux ont bien souvent des difficultés à exprimer des besoins précis pour des techniques émergeantes. Par exemple, le prototypage coopératif reste un domaine assez neuf où les utilisateurs ne peuvent donc pas connaître l'étendue des possibilités et ne peuvent donc exprimer des besoins clairs. Enfin, l'intégration des besoins utilisateurs peut entraîner de nouvelles difficultés qui ne sont pas toujours résolues par les solutions existantes. Pour éviter ces inconvénients, chaque domaine de travail que nous abordons repose sur un problème réel défini par un industriel. Sur ces bases, nous établissons un état de l'art et regardons l'adéquation des solutions existantes au problème posé. Ensuite, nous définissons comment traiter chaque besoin et comment définir de nouveaux services. Il peut s'agir simplement d'utiliser un environnement existant. Ou bien on peut être amené à la définition d'une technique entièrement nouvelle. Dans tous les cas de figure, l'ensemble des techniques mises en œuvre conduit à une solution originale et une avancée technologique en terme de concept, d'outils, d'architecture logicielle et d'intégration. 1.2 Prototypage virtuel coopératif 1.2.1 Objectifs et besoins Conception coopérative La plus grande partie des coûts d'un produit proviennent de la phase de conception initiale. Cette phase a lieu en début du cycle de vie d'un produit et elle permet d'en définir les spécifications générales. Par ailleurs, cette phase consomme seulement une faible partie du plan d'investissement d'une entreprise. On peut expliquer cette situation par trois éléments. Tout d'abord, la phase de conception est consommatrice de ressources humaines et les temps de conception initiale sont longs. Ensuite, la qualité du produit découle de cette phase, ce qui signifie qu'on ne peut pas facilement réduire sa durée sans diminuer la qualité finale. Enfin, la 6

faible part d'investissement traduit le manque de solutions logicielles pour aider les concepteurs durant cette phase de spécification initiale. En effet, il faut pouvoir spécifier de nombreuses maquettes pour décrire les différentes alternatives du produit et les outils de CAO classiques sont inadaptés car ils demandent trop d'effort pour réaliser une maquette. La CAO est généralement utilisée plus tard dans le cycle de vie du produit lorsque tous les principaux choix et arbitrages ont été effectués. Afin de pouvoir valider la qualité d'un produit et le respect des exigences, il faut souvent avoir recourt à la simulation de certaines fonctionnalités. Par exemple, il faut pouvoir simuler un écoulement de fluide pour calculer l'efficacité d'un système de conditionnement d'air. On trouve sur le marché des simulateurs qui peuvent effectuer un certain nombre de calcul mais généralement il est difficile de relier différents simulateurs pour réaliser une validation croisée de plusieurs fonctionnalités voir de l'ensemble de la spécification. De plus, les solutions pour réaliser une simulation répartie sont quasiment inexistantes d'un point de vue industriel. Prototypage rapide La première méthode pour réduire les temps de conception et augmenter le nombre de solutions examinées est de permettre à plusieurs concepteurs de coopérer pour faire rapidement un premier prototype. L'objectif principal est donc de définir des méthodes et des outils logiciels qui permettent de faire très vite et à plusieurs une maquette virtuelle du produit. Pour cela, il faut que les différents concepteurs puissent coopérer en définissant le rôle de chacun, en se partageant les tâches et en travaillant simultanément de façon variée. Les principaux besoins sont les suivants. Tout d'abord les concepteurs doivent pouvoir initialiser un projet de coopération et se répartir les rôles. Ensuite, ils doivent se répartir les tâches et partager la spécification. Chaque concepteur doit pouvoir travailler de façon isolée sur une partie de la spécification. Ensuite, les différents concepteurs doivent consolider et valider les différents travaux en une scène graphique globale. Ce travail de consolidation et de validation doit se faire de façon interactive au cours de différentes réunions de travail. Le processus de spécification peut continuer avec de nouvelles étapes de travail individuel, de partage, de consolidation et de conciliation. Un besoin non fonctionnel consiste à imposer que la solution puisse fonctionner sur l'internet actuel avec un faible coût de déploiement et de maintenance. Tout concepteur doit pouvoir travailler avec une connaissance suffisante des autres travaux. Ce travail en contexte ne doit pas se faire au détriment de la capacité à travailler en parallèle et de façon mobile. Le travail en contexte ne doit pas limiter la créativité et la productivité des concepteurs. Le système doit malgré tout permettre de respecter les responsabilités de chacun. Simulation répartie La seconde méthode pour augmenter la qualité d'une spécification et permettre aux concepteurs de coopérer efficacement consiste à utiliser des simulateurs au cours du processus de conception. L'objectif est alors de pouvoir intégrer différents simulateurs et de les faire communiquer pour valider de façon globale les différentes fonctionnalités du produit. Pour cela, il faut que chaque concepteur puisse mettre en œuvre indépendamment un ou plusieurs simulateur. Les concepteurs doivent ensuite pouvoir relier aisément les différents simulateurs mis en place de façon répartie afin de faire une validation plus globale du prototype. On peut distinguer différents besoins. Premièrement, un concepteur doit pouvoir intégrer aisément un simulateur avec la spécification existante. Deuxièmement, chaque simulateur doit 7

pouvoir échanger ses informations avec d'autres simulateurs de façon cohérente. Troisièmement, la technique de simulation répartie doit venir s'insérer de façon naturelle dans le processus de conception et de coopération en respectant les phases de préparation, partage, consolidation et conciliation. Quatrièmement, la méthode de simulation doit pouvoir être déployée sur une entreprise étendue qui comporte différents sites, partenaires et entreprises sans nécessiter d'infrastructure réseau particulière en se reposant sur l'architecture Internet existante. Ainsi, la méthode de conception coopérative se trouve enrichie par une méthode de validation qui s'intègre efficacement dans les différentes étapes de la conception. La conception se trouve alors augmentée par une facilité à simuler le comportement et les caractéristiques globales du produit. Réalité virtuelle Afin de montrer l'efficacité des solutions de répartition et de les intégrer à des applications de prototypage rapide, nous avons été amenés à nous intéresser et à développer les aspects graphiques qui sont au centre des applications de prototypage virtuel. En effet, les services de répartition doivent pouvoir s'intégrer efficacement et simplement aux applications de réalité virtuelle pour offrir les fonctionnalités requises de coopération et de simulation. Au départ notre implication dans les aspects réalité virtuelle s'est limitée à une intégration des services de répartition dans une application existante. Ensuite un travail s'est développé pour offrir des d'outils adaptés pour le prototypage rapide. Les besoins traitent du prototypage rapide. Nous nous sommes essentiellement intéressés au besoin de routage et d'allocation d'espace permettant à un concepteur d'implanter rapidement des routes électriques, hydrauliques tout en respectant des contraintes d'allocation d'espace. Services de répartition De façon transversale aux besoins utilisateurs, des objectifs ressortent pour les services de communication, de coopération et de répartition. La nécessité principale est de définir les services de répartition qui pourront être utilisés par une application de prototypage et de simulation pour offrir des fonctionnalités de coopération et de simulation répartie. Ces services doivent permettre d'étendre aisément et efficacement une application monoutilisateur de prototypage virtuel. Une première étape d'analyse de besoins utilisateurs nous a permis de définir la liste des services de répartition qui sont nécessaires. Ces services doivent pouvoir s'intégrer simplement sous forme d'une librairie au sein d'une application mono-utilisateur afin d offrir des capacités de coopération. Le document montrera au cours de son développement que ces services permettent bien de répondre aux besoins utilisateurs. Les principaux services de répartition permettent de gérer l'établissement d'un projet, la gestion des membres, la planification et la participation aux réunions de travail, le partage d'une scène graphique, la répartition de la scène parmi des concepteurs mobiles, la réunification de la scène, la progression des opérations concurrentes, le respect des rôles et des permissions, le travail simultané (ou parallèle) en réunion et hors réunion, la persistance, l'insertion d'un simulateur, la connexion de simulateurs existants, l'ordonnancement entre les simulateurs et enfin le déploiement sécurisé sur l'internet. Ils doivent présenter une solution efficace non seulement en terme de services rendus aux utilisateurs mais aussi en terme d'architecture de systèmes répartis. 8

Architecture orientée objet Afin de pouvoir fournir des solutions réutilisables d'un point de vue industriel, nous avons été amenés à concevoir une architecture en utilisant des techniques de conception orientée objet. Ainsi, les services de répartition peuvent être utilisés selon un canevas orienté objet. Plus récemment nous avons défini des techniques de couplage entre l'application et les services de répartition qui utilisent les "design patterns". Ces techniques nous permettent de simplifier l'intégration des services de répartition aux applications. Enfin, les design patterns ont dû être utilisés dans une application de prototypage virtuelle afin de rendre les solutions plus réutilisables et faciliter les évolutions. 1.2.2 Travaux existants Conception coopérative D'un côté, on trouve des systèmes coopératifs ("GroupWare") tels que [GRE 98] ou Microsoft NetMeeting. Les systèmes coopératifs sont centrés sur des interactions de nature sociales qui permettent aisément d'échanger des informations et de passer d'un mode de travail à un autre. Dans [GRE 98] on trouve la métaphore de la pièce d'habitation qui permet aux habitants de passer aisément d'un mode de travail à un autre (réunion, entrepôt de documents, échanges informels, etc ). Dans ce cas, la pièce d'une habitation est considérée comme un containeur pour des documents et des personnes. Ainsi, les personnes passent aisément d'une pièce à une autre et peuvent déposer des documents dans les différentes pièces. Mais, ces environnements de travail coopératifs n'adressent pas comment des concepteurs peuvent coopérer au prototypage d'un produit complexe au sein d'une entreprise étendue. Ils sont souvent constitués d'outils (tableau blanc, transmission vocale) qui ne permettent pas de partager un monde virtuel. Des solutions industrielles comme [DAS 98] utilise une représentation en 3 dimensions du produit. Elles permettent essentiellement une revue de conception qui offre un style limité de coopération puisqu'il ne permet pas de concevoir une scène graphique mais plutôt de naviguer à plusieurs au sein d'une scène existante. D'autres, comme [HP 99] offrent la possibilité de concevoir une scène à plusieurs. Pour cela, ils utilisent un serveur qui maintient la scène et transmet les mises à jour aux différents participants. Enfin certaines [ENOA 2000] augmente la capacité de conception en contexte en fournissant des alertes lorsque des changements apparaissent dans les spécifications. Les techniques de répartition sous-jacentes relèvent essentiellement des bases de données. Mais par essence, le système vise principalement la revue de maquette où les concepteurs peuvent inspecter la maquette et ajouter des annotations. Ces solutions ne sont pas complètes. Par exemple, elles ne définissent pas comment des concepteurs mobiles peuvent réunir leurs travaux. Elles sont souvent peu étudiées pour permettre une consolidation de différents travaux, une validation et une conciliation itérative de la spécification. Les plus avancées présentent des architectures lourdes à mettre en œuvre qui reposent sur des techniques de bases de données. 9

Généralement ces solutions utilisent un serveur. Une telle solution n'est pas ouverte puisqu'elle impose qu'une unique entreprise collecte le monde partagé. Ainsi, les entreprises distantes doivent déléguer les droits d'administration et de gestion du contenu à l'entreprise qui héberge le serveur. De plus, ces solutions ne supportent généralement pas le travail mobile. Par exemple, il n'est pas simple pour des travailleurs de préparer des propositions lors d'un déplacement avant de joindre une réunion pour unifier et consolider les différentes propositions. Généralement, seule la réunion est supportée et les travaux ne peuvent être aisément préparés en dehors de la réunion. De plus, le déploiement sur l'internet peut se trouver complexifié et demander des infrastructures spéciales pour assurer la répartition, les performances, la sécurité ou la disponibilité. Réalité virtuelle distribuée Les environnements de réalité virtuelle distribuée sont guidés par les besoins historiques provenant des simulations de champ de bataille. En effet, les applications militaires furent les premières à utiliser conjointement la réalité virtuelle et des techniques de répartition permettant de relier différents simulateurs dispersés sur l'internet. Ainsi, [BAR 96] [IEEEa 2000] [BRO 98] [HAG 96] [MAC 95] considèrent principalement comment réduire le trafic réseau dû à un grand nombre d'objets mobiles (tels que des fantassins, des chars ou des avions). Généralement, une méthode pour diviser la scène statiquement ou dynamiquement est proposée. Elle permet de ne traiter que les événements qui concernent la portion de scène en cours d'observation. Ces systèmes ne supportent pas bien le travail parallèle [BAR 96] ou ne garantissent pas la progression du travail [IEEEa 2000] [BRO 98] [HAG 96]. De plus, les écueils des architectures client-serveur [BRO 98] [HAG 96] ou la nécessité de qualités de service spécifiques de la part du réseau sous-jacent [IEEEa 2000] limitent ces solutions. Ainsi, les environnements de réalité virtuelle distribuée adaptés pour la conception coopérative manquent. Premièrement et contrairement à leurs revendications, ils adressent mal les besoins d'ingénierie concurrente car ils ne préservent pas de progresser de façon cohérente ou présentent une capacité de travail parallèle limitée. Deuxièmement, ils ne permettent pas de passer aisément d'un mode de travail à un autre afin de permettre différents types de coopération et de conciliation. Troisièmement, l'existence d'un serveur introduit un goulot d'étranglement et un point de défaillance dans le système. Quatrièmement, une qualité de service de la part du réseau sous-jacent (réservation de ressources, priorité des flux, etc ) n'est pas garantie sur l'internet actuel, impose une architecture commune de réseau et limite donc la facilité de déploiement et l'ouverture de la solution. Enfin, ces solutions ne fournissent pas de mécanisme de sécurité afin de déployer la solution sur l'internet standard. Simulation répartie Historiquement les techniques de simulation répartie proviennent de la simulation à événements discrets [MIS 86]. Ces techniques ont été utilisées à l'origine pour réduire les temps de simulation sur les machines parallèles. Plus récemment, elles ont été utilisées pour permettre l exécution de modèles de grande taille nécessitant beaucoup de mémoire et d entités d exécution. Ainsi en considérant un "modèle objet" où chaque entité (processus) simule un ou plusieurs objets du monde réel, il devient possible de simuler de très grands modèles de façon répartie sur différentes machines. 10

L'intérêt principal de ces techniques de simulation est d'offrir une simulation correcte et une bonne reproductibilité. En effet, le séquencement et l'avancement des processus logiques est sous le contrôle du simulateur au moyen d'un temps logique. Le temps logique avance toujours de la même façon et permet de garantir le respect des relations de causalité entre les événements. Les performances de la simulation peuvent être très variables en fonction par exemple de la possibilité pour le programme de régler efficacement l'avancement (lookhead) du temps logique ou la capacité mémoire. High Level Architecture (HLA) [IEEEa 2000] est une solution définie par les militaires américains et qui utilise les mécanismes de la simulation à événements discrets. Cette norme a été intégrée à CORBA par le "Manufacturing Domain Task Force" de l'omg [OMG 99]. HLA ajoute plusieurs services au bus CORBA pour établir un canevas technique commun facilitant l'interopérabilité de tous types de modèles et de simulations. Les différentes classes d'objets partagés par les différents simulateurs sont définies au moyen d'un langage de description de ces classes d'objet appelé Object Management Template (OMT). En fait, OMT vise essentiellement à définir les noms des classes et les attributs qu'elles contiennent. A l'inverse du langage IDL permettant de décrire les interfaces d'objets CORBA, OMT ne permet pas de définir des méthodes accessibles sur les objets mais uniquement les attributs gérés par ces objets. Les principes et les objectifs d'hla sont donc très différents et complémentaires du bus CORBA. Le bus CORBA peut être utilisé pour implanter HLA afin de pouvoir traiter l'hétérogénéité des machines et des langages. Par ailleurs, HLA propose des services pour garantir l'exactitude et la reproductibilité de la simulation répartie. Ainsi, HLA résout des problèmes qui ne sont pas adressés par le bus CORBA. Les mécanismes utilisés de façon interne par HLA pour garantir ces propriétés sont les techniques de simulation à événements discrets. Elles permettent de préserver les relations de causalité entre les événements et réduisent les indéterminismes. Cependant ces techniques de synchronisation sont complexes et peuvent demander de nombreux ajustements de la part des applications qui les utilisent. Les exemples d'intégration de HLA à des simulateurs existants montrent différents problèmes. D une part, OMT est un mécanisme d assez bas niveau pour traiter l hétérogénéité des simulateurs. D autre part, l'utilisation d'un temps logique n est pas aisée et elle ne garantit pas forcément l exactitude et la reproductibilité. D'un autre côté, les systèmes répartis ont mis en œuvre des solutions pour respecter les relations de causalité et plus largement ordonner les événements. Un grand nombre de protocoles ont été défini qui reposent à peu près tous sur le même principe d'architecture logicielle. An niveau le plus bas, on trouve un protocole qui garantit un ordonnancement causal des événements. Au-dessus, on construit généralement un protocole qui ordonne totalement les événements ne présentant pas de relation de causalité. Ainsi au moyen de ces deux couches de protocoles, le système garantit un ordre causal et total. Ces solutions présentent un net avantage par rapport à la simulation à événement discret. D'une part, le programmeur n'a pas à se préoccuper de faire avancer une date logique. D autre part, les relations de causalité peuvent être respectées de façon automatique. Enfin, l'ordre total améliore la cohérence de la simulation répartie. Il permet d éviter des incohérences pour les événements indépendants c'est-à-dire ne présentant pas de relations causales de communication [LAM 78]. La difficulté majeure pour utiliser ces solutions réside dans l'absence de standard et la difficulté à mettre en œuvre ces solutions sur l'internet. Certaines solutions [HULE 96] [MOS 96] présentent des problèmes de performances liés au parcourt d une arborescence de diffusion. D'autres solutions [REN 95] peuvent nécessiter des techniques de séquencement centralisées pour garantir l'ordre total. La solution est alors difficilement extensible. Enfin, ces 11

solutions ne définissent pas comment résoudre l'interconnexion de simulateurs hétérogènes existants. En résumé Différentes lacunes des solutions actuelles vis à vis de la conception répartie ressortent: - la difficulté à travailler de façon mobile et répartie au sein d'une entreprise étendue - le manque de méthodes et d'outils pour supporter le prototypage rapide - le faible support du travail coopératif de la part des environnements de réalité virtuelle distribué - les difficultés de mise en œuvre et de déploiement sur l'internet standard tout en assurant un bon niveau de sécurité et une ouverture des solutions - la difficulté de mise en œuvre de techniques de simulation sur l'internet permettant d'intégrer aisément des simulateurs sur étagère 1.2.3 Apports Conception coopérative Les solutions industrielles ne traitent pas complètement les besoins nécessaires lors des premières étapes de la conception d'un produit. Nous avons été donc amenés à définir une nouvelle méthode de travail et une métaphore associée. La solution permet de couvrir les besoins de conception rapide des systèmes aéronautiques en nous basant sur un cas industriel réel. Nous proposons une méthode permettant différents styles de travaux. Les éléments principaux de la méthode sont les suivants. Un schéma utilise le courrier électronique pour initier un projet de conception au sein d'une équipe dispersée. Il permet de gérer différentes équipes de conception de façon sécurisée via Internet. Après cette étape, les différentes équipes joignent une réunion de démarrage pour coopérer à la définition de la spécification initiale. Par la suite, chaque équipe travaille à la conception de façon répartie et coopérative. Ainsi, des travaux isolés et réalisés par des concepteurs mobiles sont unifiés et consolidés aisément. Des séances de travail permettent de résoudre les interdépendances fonctionnelles et de consolider différentes parties de la spécification. La conciliation de différentes alternatives permet de définir une spécification globale qui respecte l'ensemble des contraintes fonctionnelles. La solution présente différents avantages : - Elle offre la capacité à faire de la conception en contexte. - Elle permet le travail mobile afin que les concepteurs puissent travailler sans connexion réseau. - Elle fournit un moyen de répartir la complexité du système spécifié en plusieurs équipes travaillant sur différents sous-systèmes. - Elle permet de consolider un prototype conçu de façon répartie. - Elle permet de concilier différentes propositions et alternatives. - Elle réduit le temps de spécification et augmente la qualité grâce au travaux mobiles simultanés et à une consolidation en contexte 12

Métaphore du chantier réparti Nous proposons une nouvelle métaphore permettant de faire la conception répartie d'un prototype virtuel. Cette métaphore donne les principes d'une nouvelle solution qui couvrent nos besoins de conception répartie. Elle permet une conception coopérative interactive via le travail en parallèle sur une scène 3D partagée tout en garantissant la progression du travail. Elle offre différents styles de coopération tels que le travail mobile, la réunion, la conception interactive, la revue interactive, la conciliation et la validation interactive. Cette métaphore sert à la fois à des concepteurs co-localisés dans la même pièce ou à des concepteurs distants. C'est une solution entièrement répartie sans aucun serveur. Elle ne nécessite aucune qualité de service spécifique de la part du réseau sous-jacent. Elle peut être déployée sur l'internet courant tout en fournissant authentification et confidentialité des données échangées. Comme la solution nécessite peut de bande passante, elle peut fonctionner sur des lignes téléphoniques bas débit. La métaphore DBSM ("Distributed Building Site Metaphor") constitue les spécifications d'une plate-forme ouverte qui permet aux concepteurs de se déplacer aisément d'un espace de travail déconnecté à un chantier virtuel afin de coopérer de façon interactive et de partager la scène graphique qui constitue le chantier. La scène graphique est ensuite répartie parmi les espaces privés (pour les travaux déconnectés) des différents concepteurs afin d'apporter des améliorations aux parties de la scène qui les concernent. Ainsi, les concepteurs peuvent continuer à travailler en dehors du chantier pour préparer différentes alternatives de conception. Le travail hors du chantier ne nécessite pas d'accès réseau. Il se fait malgré tout en contexte puisque chaque participant a pu récupérer une copie de tout ou partie du chantier afin d'avoir le contexte de travail qui lui est nécessaire. Lorsque au cours d'une prochaine réunion un concepteur entre à nouveau sur le chantier, il choisit la proposition qu'il souhaite introduire et partager avec les autres participants. Ainsi, une mise à jour du chantier partagé est réalisée par une réunification automatique des différentes propositions. Bibliothèque de répartition Nous proposons une implantation de DBSM qui offre une solution entièrement répartie en utilisant les services "moindre effort" (best-effort) de l'internet. Ainsi, elle peut être déployée aisément sur n'importe quelle infrastructure IP (Internet Protocol). Elle ne nécessite pas de qualité de service telle que la réservation de bande passante. A l'inverse de [BRO 98] [HAG 96], la solution n'utilise ni diffusion fiable ni une diffusion ordonnée (ex: un ordre causal et total) [TOI 99]. En effet, ces techniques sont connues pour ajouter un surcoût important. De plus, une diffusion fiable ou ordonnée ne garantit pas la cohérence de travaux mobiles et des protocoles sociaux peuvent être adoptés pour résoudre certaines incohérences. Avec notre implantation, le travail parallèle n'est pas limité et la progression des travaux est garantie au moyen d'un protocole léger qui est exécuté uniquement lorsque c'est nécessaire. Chaque participant possède une copie de la scène. Il n'est pas nécessaire pour un participant d'observer tous les états d'un objet distant car le propriétaire de l objet conserve un état cohérent. Les incohérences sont récupérées lorsque c'est nécessaire lors du transfert de propriété de l'objet. Ce transfert nécessite une diffusion et deux messages point-à-point. A l'inverse d'une diffusion fiable, ce protocole est léger car il ne cherche pas à récupérer les erreurs de façon continue et garantit la progression du travail. Par ailleurs, une entité du système peut re-synchroniser sa copie de la scène au moyen d'un protocole qui récupère un état frais pour les objets distants. 13

Enfin, notre solution garantit un déploiement sécurisé sur l'internet. Elle utilise les techniques d'échange de courrier sécurisé pour authentifier et distribuer une clé de session. Les réunions de travail s'effectuent alors de façon sécurisée via un mécanisme de modification continu de la clé de session au cours des transmissions. Ce mécanisme est intéressant car il pallie le manque de solutions pour la sécurisation des communications en mode non connecté. Il repose sur une utilisation de composants sur étagères pour authentifier les participants et échanger une clé de façon sécurisée. La solution permet de réutiliser les outils existants pour le courrier électronique. Elle reste malgré tout nouvelle et efficace car elle permet de chiffrer une communication en diffusion en mode non connecté (multicast). Simulation répartie sur l'internet L'apport consiste à mettre en oeuvre une technique originale pour permettre à différents simulateurs de se synchroniser en garantissant l'exactitude de la simulation et une certaine reproductibilité. La méthode consiste à relier différents simulateurs de façon arborescente au moyen d'extrémités TCP/IP (adresse IP et numéro de port). Chaque simulateur peut appartenir à différents groupes fonctionnels (commande de vol, ventilation, etc ). Un simulateur peut émettre un événement vers un groupe fonctionnel et tous les simulateurs appartenant au groupe reçoivent cet événement. Ainsi, les différents simulateurs se synchronisent en traitant les différents événements reçus. Il est alors possible de faire une simulation globale de la maquette 3D en synchronisation des simulateurs sur étagère qui ont des temps de simulation différents et qui ne peuvent être synchronisés par une horloge externe. L'intégration de simulateurs existants s inspire de HLA OMT mais elle est plus simple d usage. Elle réside en un canevas d intégration des simulateurs qui est plus extensible. La méthode d'intégration des simulateurs que nous proposons est intéressante car elle permet à un concepteur de coupler deux simulateurs sans définir explicitement les interactions entre ces deux simulateurs. Nous utilisons pour cela un méta-objet qui peut maintenir des informations pour les différents simulateurs. Les simulateurs partageant les mêmes objets, on peut les coupler aisément. Une technique d association automatique peut ainsi être envisagée. Par exemple, on couple automatiquement pour un objet des attributs du même type en entrée et en sortie. L utilisateur peut aussi instrumenter le couplage. La simulation partielle ou globale doit avoir des propriétés d'exactitude et de reproductibilité qui sont ici garanties en assurant un ordonnancement causal et total de tous les événements. La solution que nous avons développée s'appelle CTOP ("Causally and Totally Ordered Protocol"). La méthode d'ordonnancement utilisée ne demande pas de développer un protocole pour l'ordre causal. L'ordre total est réalisé par un simple parcourt de l'arborescence des simulateurs. Ce parcourt est optimal en ce sens qu'il ne met en jeu que l'arbre couvrant l'ensemble des destinataires. L'ordre total ne requiert qu'un séquencement local à chaque simulateur afin de garantir une livraison en séquence (FIFO) entre un père et ses fils. En pratique les numéros de séquence locaux n'ont pas à être gérés lorsque l'implantation utilise une transmission fiable entre les simulateurs (par exemple grâce au protocole TCP). Un résultat formel établi dans [TOI 93] et [TOI 99] nous permet de montrer que l'ordre total produit est causal. A l'inverse, dans des solutions comme [MOS 96] [REN 95] [AMIR 92] [MIS 93] [MAL 96] deux protocoles sont nécessaires. Un premier protocole garantit un ordre causal pour des groupes pouvant s'intersecter. Un second réalise un ordonnancement total des événements. Le déploiement de ces solutions peut nécessiter une administration de domaines de diffusion afin d'optimiser et de minimiser les surcoûts engendrés par ces deux protocoles. En pratique toutes les solutions pour les réseaux grandes distances reposent sur des architectures arborescentes. 14

La solution que nous proposons est simple à déployer. Elle repose sur une architecture arborescente. Cependant, elle n impose pas de constituer de domaine de diffusion pour limiter les surcoûts liés à l ordre causal. Elle évite certains parcourt de l architecture arborescente. Le multicast peut permettre des gains de performances. Les différents simulateurs peuvent venir s'intégrer dynamiquement dans l'arborescence en cours de simulation. Un simulateur a besoin de connaître uniquement l'extrémité du père auquel il veut se rattacher. Le système est donc simple à mettre en œuvre, son usage est aisé et il peut être déployé aisément sur l'internet. Le système a été développé au-dessus de l'environnement ACE ("ADAPTIVE communication environment") de Douglas Schmidt. Il est donc portable et fonctionne aussi bien sur des machines Windows, Unix ou même des exécutifs temps réel comme Chorus ou VxWorks. L'API de simulation peut être intégrée à la librairie DBSM. Ainsi, une entité d'application supporte la conception coopérative et permet la mise en place d une simulation répartie. 1.3 Contrôle réparti de procédés industriels 1.3.1 Objectifs et besoins Automatisme Le niveau automatisme constitue le premier niveau de la hiérarchie CIM ("Computer Integrated Manufacturing"). Il s'intéresse à la commande en temps réel des machines de production. D'un point de vue informatique, un réseau de terrain relie différents composants tels que des entrées-sorties déportées, des automates programmables, des commandes numériques et des PC industriels. On vise un comportement temps réel strict au sens où le système et les applications qui s'exécutent doivent répondre aux événements du procédé en un temps borné et connu qui peut être court. Le réseau de terrain présente généralement des propriétés temporelles et des réplications de données. Toutes les opérations ne sont cependant pas associées à des contraintes temporelles : il s'agit bien souvent de garantir le bon séquencement des opérations. Les réseaux de terrains sont le plus souvent des solutions propriétaires complexes de mise en œuvre et coûteuses financièrement. La complexité résulte du grand nombre de services de communication offerts par les coupleurs (services synchrones, asynchrones, messagerie) mais aussi du manque de définition précise des propriétés d'échange et des règles d'usage. Les coûts financiers limitent les usages. Il s'agit donc de dégager les caractéristiques de ces systèmes et de définir des alternatives moins coûteuses. Deux besoins essentiels se dégagent donc. Tout d'abord, définir clairement les propriétés d'échanges nécessaires aux applications et définir les règles d'usages des services de communication. Ensuite, proposer des implantations alternatives qui utilisent des composants sur étagères tels que les réseaux Ethernet et TCP/IP. Supervision Le second niveau de l'architecture CIM correspond à la supervision et au contrôle du procédé. On trouve à la fois des postes opérateurs et des calculateurs de supervision. Les postes opérateurs sont reliés par une messagerie industrielle aux composants d'automatisme. Ils permettent à l'opérateur d'interagir avec le procédé et de surveiller son déroulement. Les 15

calculateurs de supervision réalisent un suivi du procédé et peuvent déclencher des alarmes ou prendre des décisions rapides afin de garantir le bon fonctionnement de la fabrication. Les outils de communication présents à ce niveau sont là aussi coûteux et complexes. Les raisons sont assez proches de celles décrites pour le niveau automatisme. Deux besoins se dégagent là aussi. Le premier est définir les propriétés d'échanges qui sont nécessaires à ce niveau en les contrastant avec celle du niveau automatisme. Le second besoin consiste à définir des solutions alternatives aux messageries industrielles et permettant une réelle répartition des traitements de supervision. La solution doit reposer sur des composants sur étagères. Elle doit permettre de dégager une interface de communication simple d'usage et offrant un niveau d'abstraction qui soit facilement transposable pour différents types d'échanges. 1.3.2 Travaux existants Réseau de terrain Différents produits propriétaires comme [AEG 96] permettent aux stations connectées sur le réseau de terrain de communiquer par échange de variables. En fait, les stations partagent une même zone de mémoire. Dans [AEG 96], le temps nécessaire pour mettre à jour la zone mémoire dépend du nombre de stations et de leur charge. Par ailleurs, on trouve des solutions plus ouvertes car reposant sur un standard comme FIP (Factory Instrumentation Protocol). FIP [UTE 90] fournit un exemple représentatif des services qu'offrent les réseaux de terrain. Ainsi, le mode naturel de communication entre stations reste le partage de mémoire. FIP garantit certaines propriétés temporelles. En absence d'erreurs de transmission il garantit une mise à jour des variables en une durée bornée. De plus, il fournit des statuts définissant la validité temporelle d'une variable. Cependant, un bon usage de ces statuts temporels reste l'entière responsabilité de l'application. Notamment en cas de faute temporelle de la part du réseau de terrain, celle-ci doit décider des traitements nécessaires. De plus, l'application n'a pas de garantie d'ordonnancement des mises à jour des variables. Enfin, les situations de panne de réseau laissent généralement l'application sans moyen d'échange. Messagerie industrielle Différentes messageries propriétaires permettent à une station de supervision de communiquer avec un composant d'automatisme. MMS ("Message Manufacturing Specifications") [ISO 90] est une messagerie standardisée qui couvre les principaux besoins d'échange. Le principe de base est qu'une entité d'application sur un poste de supervision est cliente d'un serveur présent sur un composant d'automatisme. L'apport principal de MMS est de présenter une abstraction objet de l'équipement d'automatisme. Les implantations au-dessus des piles OSI ont rencontré peu de succès. [GGS 97] propose une implantation plus ouverte de MMS au-dessus de CORBA. MMS ne garantit aucun temps de communication ni aucune propriété d'ordonnancement. Enfin MMS n'est pas conçu pour mettre en œuvre des architectures tolérantes aux pannes. 16

Diffusion de message Les systèmes de diffusion vers des groupes sont très souvent utilisés au niveau supervision. Lorsque ces systèmes sont élaborés sans temps global (contexte asynchrone), ils proposent généralement des propriétés d'ordre causal et total [REN 95] [HULE 96] [MOS 96] ainsi que des propriétés d'atomicité. Les propriétés d'ordre permettent que les destinataires observent les événements dans le même ordre et en respectant les relations causales de communications. Les propriétés d'atomicité garantissent généralement que tous les destinataires reçoivent les événements quitte à retirer les destinataires pour éviter une terminaison en un temps infini. Cependant en univers asynchrone, ces systèmes ne garantissent généralement pas de propriétés temporelles. Leur utilisation pour des traitements temps réel reste alors difficile d'autant que les techniques d'ordonnancement et d'atomicité augmentent les temps de transmission. Dans le cadre synchrone, les systèmes comme [FET 99] calculent des bornes de transmission supérieures au-dessus de communication standard comme TCP/IP. Cette approche permet de détecter les fautes temporelles. Ainsi, une synchronisation des horloges peut être élaborée entre entités non fautives. Grâce au temps global ainsi fourni, une diffusion ordonnée et atomique peut être construite [CRI 91]. D'un point de vue pratique, ces approches présentent un certain nombre de difficultés. D'une part, les solutions font généralement l'hypothèse d'une borne supérieure connue sur les temps de transmission [FET 99]. Hors en pratique, il est difficile de connaître cette borne si elle existe. Par exemple, dans un réseau comme l'internet il n'y a aucune borne maximale accessible. D'autre part, les techniques reposant sur une synchronisation des horloges au moyen d'un canal de diffusion [DAN 97] sont coûteuses financièrement. Elles peuvent nécessiter une carte de synchronisation des horloges sur chaque calculateur. Ou bien, elles demandent la mise en place d'un serveur [MIL 92] pour distribuer le temps. En pratique, les solutions synchrones ne sont quasiment pas utilisées sur le plan industriel pour le contrôle réparti des procédés. En résumé Différentes difficultés ressortent vis à vis du contrôle réparti des procédés: - le manque d'étude des propriétés de communication qui sont réellement nécessaires au niveau automatisme et supervision - la faiblesse des solutions fournies par les réseaux de terrain pour le niveau automatisme concernant l'ordonnancement des événements - la difficulté d'usage des propriétés temporelles fournies au niveau automatisme par les réseaux de terrain - l'absence de propriétés temporelles fournies par les réseaux présents au niveau supervision - les surcoûts financiers et le peu d'usage des solutions synchrones 1.3.3 Apports Définitions des besoins de communication L'étude présente les services et les propriétés de communication dont a besoin l'application au niveau automatisme. Elle montre que le partage de mémoire est le service le plus adapté pour 17

les applications d'automatisme. Nous présentons les propriétés temporelles d'accès aux variables dont a besoin l'application et nous donnons des exemples d'usage de ces propriétés. L'intérêt essentiel est d'avoir des statuts temporels qui permettent à l'application de déclencher des traitements d'exception. Par ailleurs, nous montrons grâce à des exemples que l'automatisme requiert aussi la préservation des relations sémantiques. Les propriétés d'ordonnancement (local, causal, total) peuvent permettre de respecter les relations sémantiques. Les relations sémantiques donne une définition applicative des relations de causalité. Nous montrons que le non-respect des relations sémantiques peut conduire à un dysfonctionnement du système aussi bien au niveau automatisme que supervision. Nous expliquons aussi que le fait de disposer d'une information de validité temporelle au niveau de la supervision est intéressante car elle permet de détecter et traiter les fautes d'omission ou temporelle. Services unifiés d'accès à des variables L'idée de base est de proposer des services mémoires qui peuvent être utilisés aussi bien au niveau automatisme que supervision. Pour le développeur l'intérêt est disposer d'un unique service et d'éviter d'apprendre à utiliser des interfaces de services différentes selon le contexte dans lequel il travaille. Ces services unifiés présentent des propriétés d'ordre et supportent la validité temporelle. Au niveau automatisme, ils viennent compléter les manques des réseaux de terrain vis à vis de l'ordonnancement tout en fournissant une propriété de validité temporelle des variables. Ces services mémoire sont aussi utilisables par le niveau supervision. Ils complètent les propriétés d'ordre par des propriétés temporelles qui généralement ne sont pas disponible à ce niveau. Une propriété d'atomicité peut-être construite au-dessus. Services de communication orientés objet Les services mémoire sont intégrés dans un système à objet CORBA. Ainsi la communication par variable peut se faire entre systèmes hétérogènes. Une classe d'objet pour l'automatisme offre des services de lecture et d'écriture de variables. Des sous-classes permettent à l'application d'avoir des propriétés de communication différentes. Il est ainsi possible de privilégier les propriétés temporelles ou le respect des relations sémantiques via un ordonnancement des opérations mémoire. En privilégiant les propriétés temporelles, les propriétés d'ordonnancement sont fournies lorsqu'elles ne détériorent pas les propriétés temporelles demandées. De la même façon, privilégier les propriétés d'ordonnancement permet de restreindre les propriétés temporelles pour préserver les propriétés d'ordonnancement. La seconde classe d'objets permet aux entités de supervision de communiquer par échange de variables. Elles obtiennent ainsi des propriétés d'ordonnancement et temporelles. Enfin, une troisième classe d'objet permet à une entité de supervision de lire et d'écrire des variables présentes sur un contrôleur d'automatisme. Cette dernière classe correspond en fait à une classe de type messagerie industrielle. Cette classe d'objets n'offre aucune qualité d'ordonnancement ou temporelle. 18

Amélioration des propriétés d'ordonnancement des réseaux de terrain Les services mémoire pour l'automatisme et la supervision proviennent d'une étude que nous avons faite du réseau de terrain FIP. Grâce à un résultat formel, nous montrons que pour des vitesses faibles, FIP garantit un ordre causal et total en plus des propriétés temporelles. Dans certaines conditions, FIP préserve donc naturellement des propriétés d'ordonnancement. Une extension réalisée au-dessus du coupleur FIP nous permet de garantir des propriétés d'ordonnancement pour des vitesses élevées. Mais dans ce cas, on perd les propriétés temporelles. FIP est un système asynchrone qui n'offre pas de temps global. Cette étude montre la difficulté pour avoir à la fois des propriétés temporelles et d'ordonnancement dans un environnement asynchrone. En pratique, on ne peut pas utiliser FIP pour avoir simultanément ces deux propriétés. Afin d'avoir des propriétés d'ordonnancement réalisées de façon plus efficace et moins onéreuse qu'avec FIP, nous proposons un service mémoire qui garantit des propriétés d'ordonnancement et fournit aussi des temporelles. L'implantation des services est faite en utilisant le bus à objets répartis CORBA Chorus- COOL. Nous montrons que le système garantit un ordre causal et total pour les opérations mémoires. La solution fournit des propriétés temporelles proches de celles d'un réseau de terrain comme FIP. De plus, le système récupère les erreurs de transmissions. Les performances peuvent être meilleures que celles d'un réseau de terrain mais sans garanties temporelles. Cette restriction n'est pas vraiment pénalisante car un réseau de terrain n'offre pas non plus de garanties dès lors que des erreurs de transmission surviennent. Service mémoire présentant des propriétés d'ordre et temporelles Le service mémoire est original car nous évitons la construction d'une couche causale de communication et nous proposons des propriétés temporelles voisines d'un réseau de terrain. Contrairement à un réseau de terrain, il n'est pas nécessaire de mettre en œuvre un cycle de transmission. De plus, le système récupère les erreurs de transmission de façon plus efficace sans retransmettre continuellement les données. Architecture de communication tolérant les pannes Nous proposons une architecture de redondance passive permettant de traiter les pannes franches des contrôleurs d'automatisme. Afin de traiter les pannes franches de réseau, le système de communication est redondant. Il comporte d'une part un réseau de terrain FIP doublé de façon peu coûteuse par un réseau de type Ethernet TCP/IP. Ce réseau TCP/IP sur étagère permet de faire fonctionner nos services mémoire. Un réseau de terrain de type FIP n'est généralement pas utilisé pour construire des applications tolérantes aux fautes. Notre solution est une approche pragmatique et peu coûteuse permettant de faire de la tolérance aux pannes. Le réseau de terrain FIP réalise naturellement des points de reprise entre un contrôleur actif et les passifs. Il n'est donc pas nécessaire de mettre en place un protocole d'appartenance aux groupes, une livraison atomique et un protocole pour les points de reprise comme proposé dans [GUE 96]. 19

La détection des pannes, qui est un problème complexe dans un système asynchrone, est effectuée grâce au réseau de terrain. De plus, notre service de messagerie CORBA est utilisé par le poste opérateur pour améliorer la détection. La détection est effectuée de façon répartie via la mémoire temps réel (FIP et/ou notre service mémoire). La solution permet de tolérer k fautes simultanées de composants d'automatisme. Elle ne tolère cependant pas les fautes simultanées du poste opérateur et du contrôleur actif. Enfin, elle évite les basculements intempestifs en cas de partition du réseau de terrain. Pour effectuer un basculement, une solution est proposée pour vérifier si l'état du contrôleur passif élu est cohérent. Nous n'utilisons pas des principes classiques de tolérance aux pannes qui ne sont pas applicable dans un contexte de commande répartie d'un procédé industriel. Ainsi les techniques de rejeu et de retour arrière automatique ne sont pas utilisées. Au lieu de ça, la supervision va décider quelle méthode de reprise doit être effectuée. Elle offre la possibilité de continuer les traitements, d'annuler la reprise, d'un retour arrière contrôlé ou d'autre type de reprise. La solution que nous proposons offre les services de base afin de connaître l'état de l'automatisme et d'affecter en réponse les méthodes de reprise sur cet automatisme. En effet, bon nombre de méthodes de reprise automatique proposées par certains auteurs ne sont pas applicables pour la commande d'un procédé. De plus la solution est intéressante car elle utilise des composants sur étagère tels que les réseaux de terrains, les contrôleurs d'automatisme, les réseaux TCP/IP et les stations de travail. Elle ne demande pas de modifier les contrôleurs ou les réseaux existants. Elle évite d'avoir à mettre en œuvre des techniques complexes de pose de point de reprise, d'élection et permet différentes alternatives de tolérance aux pannes (continuation, exception, retour contrôlé, etc ). 1.4 Déroulement, encadrements, contrats, projet européen, publications De 1994 à 1997, le travail s'est déroulé au sein du LaBRI (Laboratoire Bordelais de Recherche en Informatique). Durant cette période, j'ai encadré deux DEA, 4 mémoires d'ingénieur ENSEIRB, 6 projets de fin de 2 ième année ENSEIRB (niveau maîtrise) soit un total de douze encadrements sur 4 ans. J'ai obtenu quatre contrats de recherche avec le Centre Commun de Recherches Aérospatiale de Suresnes pour un montant total de 300KFHT. Ces contrats concernent le contrôle réparti des procédés. Les travaux réalisés dans le cadre de ces contrats ont donné lieu à une communication internationale avec sélection et actes, une communication internationale avec sélection sans actes, deux communications nationales avec sélection et actes. Au cours de ces contrats, plusieurs prototypes logiciels ont été réalisés sous ma responsabilité pour le contrôle réparti de procédé et comprenant un système réparti sur Chorus-COOL ainsi qu'une architecture logicielle pour tolérer les pannes franches. Ces prototypes ont été développés à la fois dans le cadre de projets d'étudiant et de stages rémunérés. Ils ont été mis à disposition de l'industriel. Le dernier contrat m'a permis d'effectuer un état de l'art sur la réalité virtuelle distribuée. Cet état de l'art m'a ensuite servi de base pour les travaux concernant la conception coopérative de prototypes virtuels. Il faut noter que ce travail a été réalisé sous ma seule responsabilité tant administrative que scientifique. De plus, je suis le principal auteur des publications qui sont co-signées par le partenaire industriel. Durant la même période, j'ai mené d'autres travaux dans la continuité de ma thèse. Ces travaux portent sur les propriétés d'ordre dans les diffusions de message et sur une mémoire 20

virtuelle répartie utilisant les diffusions ordonnées. Ces travaux ont donné lieu à deux communications nationales avec sélection et actes, une communication nationale sans sélection, une conférence dans une école d'été et un chapitre dans un ouvrage collectif. De 1998 à 2000, le travail s'est déroulé au sein du Laboratoire CEDRIC (Centre d'etudes et de Recherche en Informatique du CNAM). Durant cette période, j'ai encadré un mémoire de DEA, deux mémoires d'ingénieurs CNAM à temps plein sur un an, sept mémoires d'ingénieur ENSEIRB, un étudiant ERASMUS à temps plein sur six mois et dix projets de fin de deuxième année ENSEIRB soit un total de vingt et un encadrements sur trois ans. On voit que le volume d'encadrement a doublé durant cette période. En 98 et 99, j'ai obtenu deux contrats de recherche d'un montant total de 700KFHT. On peut remarquer un quadruplement du volume financier par rapport à la période précédente. Ce volume plus important a notamment permis de financer un ingénieur par an à temps plein. Ces deux contrats ont donné lieu à 8 publications internationales sélectives une revue IEEE MultiMedia et un chapitre dans un livre international suite à la sélection du papier dans une conférence internationale. Les travaux concernent à la fois le travail coopératif et le prototypage virtuel rapide. Les solutions développées sont actuellement utilisées pour la conception des systèmes Aéronautiques. Il faut noter que certains résultats intéressants n'ont pas été publiés en raison de clauses contractuelles de confidentialité. J'ai poursuivi les travaux concernant les techniques d'ordonnancement. Cela a permis de faire une publication dans une revue internationale et une conférence nationale sélective (NOTERE'2000) au cours de laquelle l'article a été sélectionné pour une publication en anglais dans la revue "Annales des télécommunications". J'ai développé moi-même la bibliothèque de communication en diffusion qui fonctionne sur l'internet. Cette bibliothèque est intégrée à l'environnement coopératif afin de permettre la simulation répartie des systèmes. En 1999, j'ai participé à la définition d'un projet européen et obtenu une position de contractant principal dans ce projet. Ce projet a été accepté par la communauté européenne. Il offre au CEDRIC un financement sur deux ans de 1,7MFrancs à partir de juillet 2000. Il faut noter que le projet a été établi en grande partie sur les bases des travaux que j'ai mené sur la conception coopérative et la simulation distribuée. Il me permet de financer un des deux élèves ingénieur CNAM afin d'effectuer un doctorat. Sur cette période on peut noter une augmentation des publications internationales. De plus, il faut considérer mon éloignement géographique. Il est alors difficile d'encadrer un thésard MRT ou de bénéficier d'un soutien scientifique. Les résultats sont donc essentiellement le fait d'un travail personnel et d'un partenariat industriel qui s'est inscrit dans la durée et a été fructueux. De plus, la réalisation des contrats de recherche et la mise en œuvre de logiciels aboutis sont des activités de recherche difficiles. Le caractère opérationnel des outils mis en œuvre, l'avance technologique procurée à notre partenaire industriel et l'ouverture vers un projet européen constituent des résultats de recherche à part entière. Ainsi au cours des 5 dernières années j'ai développé une activité complètement nouvelle aussi bien pour moi que pour mon laboratoire. J'ai assuré seul l encadrement scientifique de cette activité qui a permis une avancée significative dans le domaine du prototypage virtuel coopératif. Malgré mon éloignement géographique j'ai réussi à trouver des financements et à faire participer des élèves ingénieurs du CNAM. Grâce au projet européen obtenu, je peux financer l'un d'eux pour effectuer une thèse dans ces domaines. J'encadre actuellement ce doctorant et les résultats obtenus sont déjà significatifs en terme de publications notamment. 21

2. Prototypage virtuel coopératif 2.1 Motivation Le prototypage virtuel coopératif permet une ingénierie concourante lors des premières phases de conception d'un produit. Les décisions et la conception initiales influent beaucoup sur la qualité finale du produit et sur son coût. Cependant, les outils pour faire rapidement un prototype sont peu nombreux et supportent mal le travail concourant. Le prototypage virtuel coopératif adresse ces premières étapes de la conception et fournit les moyens de concevoir à plusieurs un nouveau produit. Notre travail a été conduit dans le cadre de produits Aéronautiques complexes où les concepteurs peuvent être disséminés sur plusieurs sites distants géographiquement en ne partageant pas la même infrastructure réseau. Un outil de prototypage virtuel coopératif doit permettre aux concepteurs d'établir rapidement le meilleur prototype en examinant le plus rapidement possible un large choix d'alternatives. Les activités de conception d'un système complexe tel qu'un système Aéronautique peuvent être réalisées par des équipes de projet qui ont des délais serrés. Les équipes font partie d'une entreprise qui peut être étendue aux partenaires, fournisseurs, contractants et clients. Cette force de conception globale peut être organisée en plusieurs équipes responsables des différents systèmes qui composent le prototype complet. Ainsi des itérations successives doivent permettre de mixer facilement les différents travaux individuels, d'équipes et les différentes alternatives au travers d'étapes de conciliation des différentes propositions. L'équipe étendue doit pouvoir coopérer librement et facilement sans requérir qu'une entreprise ait plus de privilège et un accès plus aisé aux informations que les autres entreprises participant à cette entreprise étendue. Cependant, l'environnement de conception doit permettre de respecter les responsabilités et l'expertise des différents membres. Les systèmes coopératifs se focalisent sur des interactions de nature sociale qui permettent aux personnes de se mouvoir aisément parmi des styles de travail différents. Ils proposent des métaphores telle que [GRE 98] qui facilitent le passage d'un style de travail à un autre. Généralement, c'est la métaphore de pièce qui est retenue comme un conteneur pour les documents et un espace où les gens se réunissent. Ainsi, les participants se déplacent aisément d'une pièce à une autre et peuvent déposer des documents dans les différentes pièces. Mais ces métaphores n'adressent pas la façon dont des concepteurs peuvent coopérer à la construction d'un prototype virtuel d'un produit nécessitant des techniques d'ingénierie sophistiquées. Par exemple, elles ne permettent pas de partager et de construire un monde virtuel. Elles reposent essentiellement sur la manipulation de documents conventionnels contenant du texte, des images et éventuellement du son. Elles visent aussi à permettre de localiser les participants dans les différentes pièces, à contrôler l'accès aux différentes pièces et aux documents. Elles permettent aussi de dialoguer soit via des messages textuels ("chatting") soit en transmettant la parole ou la vidéo des participants. D'un autre côté, les environnements de Conception Assistée par Ordinateurs (CAO) tels que CATIA [DAS 98] partent d'une représentation en trois dimensions du produit. Cependant la maîtrise d'un outil de CAO conventionnel nécessite de nombreuses heures d'apprentissage. Le dessin d'une maquette numérique avec ce genre d'outil est long et fastidieux car ces outils offrent une grande précision numérique et les concepteurs doivent donc dessiner très finement le prototype. En phase de conception préliminaire les outils de CAO classiques ne sont pas donc pas adaptés car ils sont trop complexe d'usage et travaillent dans la précision. A l'inverse 22

en phase préliminaire on a besoin de pouvoir faire un croquis rapide mais malgré tout représentatif du produit. Enfin les modes de coopération supportés par les outils de CAO consistent essentiellement en de la revue de maquette, ce qui constitue un mode de coopération très limité. Des solutions comme [HP 99] permettent une modification d'un mode 3D partagé mais reposent sur un serveur central qui permet une mise à jour de la maquette et propagent chaque modification vers les différents participants. Ainsi chaque concepteur observe sur sa station une copie de la maquette hébergée par le serveur. Cependant ces solutions ne sont pas simples à utiliser car elles n'adressent pas vraiment des modes de travail variés. Par exemple, elles ne supportent pas le travail mobile, permettent difficilement d'unifier et de concilier différentes alternatives provenant des différents concepteurs. Enfin l'utilisation d'un serveur ne constitue pas une solution ouverte car elle nécessite qu'une entreprise unique collecte le monde partagé. De plus, l'utilisation d'un serveur pose des problèmes d'administration car chaque concepteur doit avoir un compte et les droits d'accès doivent être administrés sur le serveur. Enfin, une gestion centralisée prive les entreprises participantes de leur savoir-faire, de leur gestion des données et de leur droit. En effet, le gestionnaire central se voit attribuer des pouvoirs supérieurs à ceux des entreprises participantes puisqu'elles doivent déposer leur savoir et doivent déléguer la gestion des droits. Par ailleurs, ces solutions ne supportent pas un changement aisé d'un mode de travail à un autre. Par exemple, il n'est pas simple pour un concepteur mobile de préparer une partie d'une tâche globale avant de joindre une réunion pour concilier différentes parties préparées par les différents concepteurs. En effet, réunir automatiquement les différentes pièces du puzzle tout en permettant une modification interactive et cohérente de l'ensemble n'est pas simple. Ainsi, de nouvelles métaphores sont à inventer pour permettre l'ingénierie concourante lors des premières phases de conception d'un produit industriel. D'une part, les modèles coopératifs ne concernent pas le prototypage 3D. D'autre part, les systèmes actuels de Conception Assistée par Ordinateur offrent un style de coopération limité. Sur un autre plan, les environnements de réalité virtuelle distribuée sont guidés par les besoins provenant des simulations de champ de bataille. Ils permettent de réduire le trafic réseau pour les objets mobiles. Ces systèmes ne supportent pas le travail parallèle ou ne garantissent pas la progression du travail. Ils utilisent généralement un serveur et ne sont donc pas entièrement répartis. Ils reposent très souvent sur des mécanismes de diffusion fiable [BRO 98] coûteux ou peu adaptés [HAG 96] car ne garantissant pas la progression du travail. Par ailleurs, ces solutions n'adressent pas la répartition d'un arbre de scène 3D parmi des travailleurs mobiles ni la réunification des différentes parties d'un arbre de scène globale. Enfin, la sécurité des transmissions n'est généralement pas prise en compte. Des solutions de répartition existent qui sont associées à une technique ou boîte à outils de réalité virtuelle spécifique. Par exemple, des techniques de répartition [HES 99] [ZEL 2000] sont associées à la librairie Open Inventor de Silicon Graphics. Ces techniques travaillent au niveau d'un nœud de la scène Open Inventor et elles permettent de transmettre de façon transparente toute création ou modification d'un nœud vers les copies distantes de la scène. Bien que [ZEL 2000] introduise une notion d'arbre de scène neutre, cet arbre de scène est conçu pour être projeté sur un arbre de scène de bas niveau tel qu'un arbre de scène Open Inventor. Elles n'imposent pas de modifier les applications existantes qui peuvent tout simplement être recompilées avec la librairie 3D distribuée. Ces solutions présentes plusieurs inconvénients. Tout d'abord elles travaillent à un niveau d'arbre très bas qui n'a pas de sémantique d'application. Ce qui ne permet pas de minimiser les échanges réseau ni de construire d'applications réparties réellement hétérogènes. 23

Par ailleurs, les solutions ne garantissent pas la progression du travail. Elles ne permettent pas de répartir un arbre de scène parmi des travailleurs mobiles et de réunir un arbre de scène réparti parmi les différents travailleurs. Elles n'adressent pas non plus la sécurité. En ce qui concerne la simulation répartie, il y a en fait peu de solutions qui permettent de coupler aisément des simulateurs sur étagère tout en garantissant l'exactitude et la reproductibilité. Dans HLA la nécessité pour l'application de faire progresser le temps logique complique grandement l'intégration aux simulateurs. Les expériences conduites [SCHUL 99] montrent que l'intégration à des simulateurs sur étagère nécessite très souvent des compromis pour l'ordonnancement logique des opérations. Ces compromis peuvent conduire à des résultats erronés tels que des opérations qui sont effectuées avant celles qui les précèdent. La difficulté d associer des dates logiques aux événements transmis et les différents choix possibles en terme d'ordonnancement conduisent souvent à ces erreurs. Donc malgré l'usage de techniques de simulation à événements discrets la simulation répartie n'est pas toujours exacte. Aucun résultat "théorique" sur la simulation répartie à événements discrets, ne permet de garantir automatiquement l exactitude et la reproductibilité pour ce type de simulation répartie. Ces problèmes amènent à penser qu'une technique plus simple d'usage peut suffire dans de nombreux cas. 2.2 Principe et justification de notre solution 2.2.1 Conception coopérative Les solutions de CAO n'adressent pas bien les besoins de coopération lors des premières phases de conceptions. Nous nous plaçons dans le cadre des techniques de réalité de virtuelle qui permettent une plus grande simplicité d'usage. Nous avons défini une solution qui est indépendante des techniques de réalité virtuelle sous-jacentes. Nous maintenons un arbre de scène qui est un arbre applicatif offrant un haut niveau d'abstraction et de sémantique. Cet arbre de scène peut être projeté via l'application sur un arbre de scène 3D. Cela signifie notamment que la solution supporte des rendus plus ou moins précis voir dégradés selon les capacités des différentes applications qui communiquent et des moteurs 3D sous-jacents. Par exemple, on peut transmettre un ordre de création d'un tube selon une trajectoire et des caractéristiques fournies de sections et de formes variables le long de la trajectoire. Ainsi, une application qui ne saurait pas représenter le tube selon les caractéristiques fournies peut se contenter par exemple de représenter un tuyau de section et de forme constante le long de la trajectoire. Par ailleurs, transmettre une information de plus haut niveau limite le volume de données transmises. En effet, il n'est pas nécessaire de transmettre tous les objets composants le tube (par exemple tous les éléments composant la géométrie) mais une description plus synthétique décrivant le tube. La solution de répartition que nous avons définie s'appelle la métaphore du chantier réparti soit en anglais "Distributed Building Site Metaphor" (DBSM). Elle permet à des concepteurs d'une entreprise étendue de se répartir un arbre de scène. Les différents concepteurs peuvent alors travailler indépendamment sur une partie de l'arbre de scène globale comme le font des travailleurs qui préparent des pièces avant de les amener sur le chantier pour les assembler. Lorsque les concepteurs joignent le chantier c'est-à-dire une réunion de travail, les différentes parties de l'arbre de scène viennent s'assembler de façon automatique pour former un arbre de 24

scène global partagé. Les différentes pièces du puzzle trouvent donc automatiquement la place fonctionnelle qui leur est destinée. Lorsque des travailleurs sur un chantier viennent positionner leurs pièces à l'emplacement prévu, il est pratiquement inévitable que les différentes pièces puissent nécessiter des ajustements. En effet, les tuyauteries préparées par un plombier viendront peut être en collision avec le réseau électrique que vient d'installer l'électricien. De la même façon, les concepteurs ayant pu travailler de façon mobile et déconnectée à la préparation de leurs pièces, des modifications seront inévitablement nécessaire lorsqu'ils entreront dans une réunion pour assembler leurs travaux. Certaines solutions de travail coopératif visent à prévenir et interdire les incohérences notamment graphiques. Ces solutions sont non seulement extrêmement complexes à mettre à œuvre dès lors qu'on considère un mode de travail déconnecté mais en plus elles ne sont pas souhaitables car les concepteurs souhaitent pouvoir concilier leurs travaux de façon interactive. De plus, de telles techniques pour traiter les incohérences peuvent être mises en place soit de façon intégrée soit en dehors de la librairie de répartition qui nous proposons. Les concepteurs ont donc besoin de pouvoir faire des réunions de conciliation des différents travaux. Pour cela, notre solution permet de modifier la scène partagée. Elle autorise ces interactions entre les concepteurs au cours d'une réunion. Elle permet aux concepteurs de modifier en parallèle les différents nœuds de l'arbre de scène (ajout, suppression et modification des nœuds). La solution garantit la progression du travail en cas d'opérations concurrentes sur une même partie de la scène. Ainsi on évite à un concepteur d'avoir à refaire certaines opérations parce que celles-ci viennent d'être "écrasées" par un autre concepteur qui n'a tout simplement pas encore pu observer l'opération précédente. Les interactions en cours de réunion facilitent les conciliations et permettent de modifier directement le prototype selon les exigences des uns et des autres. De plus, les concepteurs peuvent introduire aisément les différentes alternatives qu'ils ont préparées afin d'examiner rapidement un grand nombre de solutions. La conciliation des travaux est donc obtenue par analyse et modification des différentes propositions. En fin de réunion, chaque concepteur peut conserver dans son espace de travail la totalité ou un sous-ensemble de l'arbre de scène. Ainsi il pourra aisément modifier de façon déconnectée sa copie de la scène. Les opérations effectuées de façon déconnectée respectent les responsabilités de chacun des concepteurs. Ainsi même si un concepteur a récupéré dans sa copie des éléments de la scène qui ne sont pas de sa responsabilité, il ne pourra pas les modifier. Malgré le contrôle et le respect des responsabilités de chacun, un certain nombre de possibilités sont offertes au concepteur pour faciliter son travail. Par exemple, il peut dupliquer des nœuds protégés afin de faire des modifications sur les clones. Cela permet d étudier de façon isolée une solution alternative. La solution permet donc à une entreprise étendue de pouvoir itérer en alternant différents modes de travail et en permettant à des équipes de partager aisément leurs résultats au cours des différentes réunions. On peut ainsi imaginer une organisation du travail où les concepteurs travaillent en petits groupes et de façon parallèle à différentes tâches. Les différentes tâches peuvent être réunies et consolidées au cours d'une réunion d'avancement. Ainsi, le travail progresse de façon itérative au sein des différents groupes de travail et d'un point d'avancement à un autre. D'un point de vue architecture réseau, la solution est efficace et originale. 25

La solution est entièrement répartie. Elle n'utilise aucun serveur. La répartition de l'arbre de scène est obtenue grâce à un mécanisme de désignation répartie de l'arbre. Un mécanisme de protection, lui aussi réparti, évite des opérations interdites aussi bien en réunion que de façon déconnectée. Le système fonctionne sur le multicast fourni au niveau "Internet Protocol" (IP). Il n'utilise ni diffusion fiable ni mécanisme d'ordonnancement des messages. Le multicast et la transmission d'événements ayant une sémantique de haut niveau permettent de limiter la bande passante nécessaire et charge peu les stations de travail. La perception synchrone est assurée via la diffusion en mode moindre effort mais aussi avec une gestion adaptée de la fraîcheur des événements. La progression du travail est garantie grâce à un protocole de transfert de propriété qui permet à un concepteur d'observer le dernier état d'un objet (ou d'un nœud) avant de modifier ce nœud. La solution ne demande aucune qualité de service particulière de la part du réseau sous-jacent. Ainsi elle peut être déployée aisément sur l'internet actuel. L'authentification et la confidentialité des données diffusée est garantie en utilisant le courrier électronique sécurisé pour transmettre une clé de session. La clé de session change en cours de réunion afin d'éviter les attaques. Ainsi une bonne sécurité est obtenue en utilisant des techniques sur étagères comme le courrier électronique et des protocoles solides comme Diffie-Hellman [DIFF 76] pour modifier la clé de session au cours de la réunion. Une gestion automatique de la connectivité en multicast permet de basculer facilement dans un mode point-à-point pour un récepteur qui n'est pas joignable autrement. De plus, la gestion de la connectivité réalloue dynamiquement une nouvelle adresse de multicast lorsque celle-ci se trouve utilisée par d'autres applications. On voit donc que la solution est avancée sur de nombreux points. Elle supporte le travail mobile et différents styles de coopération (conception coopérative, revue, travail en réunion et déconnecté, conciliation et validation interactives) en permettant aux concepteurs de travailler simultanément (en parallèle) et en garantissant la progression du travail. La façon d'implanter ces services est efficace. La solution est entièrement répartie aussi bien pour le partage de l'arbre de scène, la protection, la progression des opérations et la persistance. Elle consomme peu de bande passante et peut fonctionner sur des lignes à bas débits. Elle peut être déployée aisément sur l'internet actuel tout en offrant de bonnes performances et la sécurité des transmissions. 2.2.2 Services pour la simulation répartie La simulation répartie permettant d'intégrer des simulateurs sur étagère est nous l'avons vue très difficile à mettre en œuvre et à utiliser. Nous proposons deux solutions assez simples à utiliser et qui sont applicables à deux types de simulation. Pour une simulation de type best-effort (c'est-à-dire fonctionnant au plus vite selon les capacités des simulateurs), nous proposons d'utiliser DBSM. En effet, les services permettent de transmettre des mises à jour d'objet de façon efficace. Chaque mise à jour est transmise dans un mode moindre effort. Un numéro de version permet de supprimer les événements périmés et d'accélérer le traitement des événements récents. Deux types de simulation sont ainsi supportés. 26

Premièrement, un mode où les simulateurs traitent des sous-ensembles disjoints de la scène partagée. Le partage de la scène permet aux concepteurs de visualiser les résultats de la simulation globale. Deuxièmement, un mode permet à un simulateur produisant une sortie d'affecter l'entrée d'un autre simulateur. La technique d'intégration des simulateurs, décrite plus loin, repose sur l'utilisation d un méta-objet et le typage des attributs spécifiques à chaque simulateur. Pour obtenir une simulation correcte nous utilisons un service de communication vers des groupes qui garantit un ordre causal et total. En effet, l'objectif principal est de respecter les relations de causalité entre les événements. Ici, les événements considérés sont les mises à jour d'objet qui sont transmises lorsque la sortie d'un simulateur est utilisée en entrée d'un autre simulateur. L'ordre causal permet de préserver les relations de causalité entre ces événements. Il évite qu'un simulateur ait une perception erronée d'une partie de l'état du système. L'ordre total permet que les résultats soient perçus de façon identique par différents récepteurs. Grâce à cette vue identique d'un même ensemble d'événements les simulateurs peuvent progresser de façon cohérente. L'ordre total permet aussi un certain degré de reproductibilité sans pour autant qu'on puisse garantir une reproductibilité parfaite. Notamment, si pour une même séquence d'entrée, les temps de traitement de ces entrées varient de façon importante d'un essai à un autre, l'ordre total fournit en sortie ne sera pas le même que celui de l'essai précédent. Il faut cependant relativiser l aspect reproductibilité. Par exemple, pour des simulateurs qui ne sont pas régis par le temps, il n'existe aucun moyen simple d'associer des dates logiques aux évènements. Dans ce cas, il y a des chances qu une simulation de type HLA ne soit ni correcte ni reproductible. A l'inverse, un ordre causal et total, parce qu'il est plus automatique et régi uniquement sur l'ordre des communications, garantira mieux une simulation correcte. La technique pour obtenir l'ordre causal et total est celle définie dans CTOP. Le système consiste en deux composants différents. Le premier composant correspond à un service de transmission fiable qui peut être réalisée soit via TCP soit de façon plus efficace en utilisant UDP. Ce composant de transmission fiable a pour rôle de garantir une transmission fiable entre deux nœuds de l'arbre de transmission utilisé par CTOP pour diffuser les messages. La transmission fiable est utilisée par un second composant qui consiste en un protocole de routage. Le composant de routage maintient pour chaque groupe de destinataire une racine de diffusion qui est positionnée de façon optimale pour couvrir le groupe. Chaque nœud de l'arbre couvrant le groupe maintient une connaissance de l'appartenance au groupe. L'état à chaque nœud est minimal. Les états inutiles sont supprimés de façon cohérente. Chaque événement d'entrée ou de sortie d'un membre dans un groupe peut conduire le composant de routage à déplacer la racine du groupe de façon à couvrir le groupe efficacement. Les autres solutions de la littérature nécessitent généralement des files d'attente afin de réordonner les messages avant de les livrer dans l'ordre causal et total aux destinataires. CTOP livre les messages dès qu'il arrive de façon fiable chez le destinataire. Il n'y a donc pas d'autre réordonnancement que celui nécessaire pour réaliser une transmission fiable. Lorsque notamment on utilise TCP, le système ne gère aucun numéro de séquence ni aucune file d'attente. L'ordre total est garantit par le parcourt de l'arbre. L'ordre causal est garanti par preuve grâce à un résultat formel que nous avons établi. Nous montrons que la diffusion est identifiable. L'émetteur appartenant au groupe et la diffusion étant localement ordonnée (livraison en séquence due à la transmission fiable), le résultat formel garantit un ordre causal 27

et total. Les identifiants ne sont ni connus, ni transportés par le système. A l'inverse, les autres solutions de la littérature demandent que les messages transportent des estampilles pour l'ordre causal. Ici, il n'y a aucune information d'ordonnancement qui est transportée par les messages ni aucun réordonnancement à appliquer. Le système est donc simple à mettre en œuvre. Il est efficace car il évite certains délais introduits par le réordonnancement des messages et certains parcours de l arborescence. L'intégration des simulateurs se fait via des objets partagés qui jouent le rôle d'interface entre les services de répartition et les objets des simulateurs. Ces objets partagés sont plus qu'une simple interface réseau. En effet, ils peuvent permettre de coupler automatiquement des simulateurs sans qu'un utilisateur, mettant en place son simulateur dans la scène (au sens concepteur du prototype virtuel), ait besoin de faire une quelconque opération du point de vue des autres simulateurs. Typiquement, il se contente de sélectionner un objet de la scène 3D et l'associe à un nœud de simulation en sélection le type de simulateur et le type du nœud. Cette opération ajoute au méta-objet correspondant des attributs de simulation. Le méta-objet peut permettre de réaliser automatiquement le couplage lorsqu'un autre utilisateur installe un second simulateur qui utilise cet objet. Le travail qui est à réaliser d'un point logiciel (typiquement par les fournisseurs de simulateurs) pour intégrer un nouveau simulateur est de coder une classe d'objet mandataire qui sera instanciée par le méta-objet. Un objet mandataire assure la projection entre les attributs du simulateur et les attributs partagés qui sont transmissibles sur le réseau. Un objet mandataire sert donc d'interface entre un objet du simulateur et un objet réparti. Des techniques de Design Patterns permettent de définir un schéma de projection qui est réutilisable et extensible à différents simulateurs. 2.3 Conception coopérative 2.3.1 Etat de l art Notre état de l'art vise à donner une perception assez large des solutions existantes qui touchent de près ou de loin à la conception coopérative. Dans ce domaine, nous décrirons d'abord les solutions industrielles de CAO pour la conception coopérative de maquette numérique. Ensuite, nous décrirons les solutions pour la réalité virtuelle répartie. Une discussion présente les points sur lesquels la solution DBSM vise à améliorer les techniques. Les outils de travail coopératif (Computer Supported Cooperative Work) qui peuvent être candidats dans le domaine du prototypage virtuel, sont considérés à titre de comparaison une fois la solution DBSM présentée. 2.3.1.1 Environnements industriels de CAO coopératifs Il existe un très grand nombre de solutions industrielles qui offrent une solution complète permettant à un groupe d'utilisateurs de concevoir un prototype virtuel. Nous décrirons uniquement celles qui sont des références en terme de part de marché et celles qui présentent des capacités de coopération représentatives des produits actuels. 28

CATIA CATIA 4D Navigator [DAS 98] permet une navigation coopérative d'un prototype 3D au moyen d'une synchronisation des points de vues, de télépointeurs et d'annotations. C'est un environnement de revue de maquette. Typiquement, un des concepteurs pilote ce point de vue partagé à travers la scène 3D pour conduire un examen visuel du prototype. Les concepteurs passifs survolent la scène de façon téléguidée. Ainsi, l'environnement permet une vision simultanée de la scène par les différents participants. Un télépointeur permet de localiser les différents participants au sein de la scène 3D. Chaque participant peut utiliser son télépointeur pour montrer un objet ou une direction et il peut ajouter une annotation. Ainsi, les participants partagent la même scène, le même point de vue et ils observent les différents pointeurs et annotations. Des outils de travail coopératif tels que Microsoft NetMeeting [MIC 99] peuvent permettre d'exécuter l'application 4D Navigator. Ainsi, les participants peuvent réaliser une vidéoconférence durant une session 4D Navigator. Cela leur permet de discuter les uns avec les autres en transmettant leurs voix en même temps qu'ils utilisent l'environnement de revue de maquette. La voix aide par exemple à commenter les annotations réalisées durant la revue. D'un point de vue réseau, cet environnement utilise un serveur qui diffuse la scène et la position des points de vue. C'est donc une architecture client-serveur classique sans mécanisme de répartition sophistiqué. Ce produit est restreint à la revue technique, il ne permet pas de modifier la scène 3D de façon interactive en cours de réunion en créant, détruisant ou modifiant des objets 3D. CATIA V5R5 [DAS 2000] est la dernière version de CATIA. Elle améliore la technique de revue avec l'outil DMU Navigator qui est le successeur de 4D Navigator. La principale différence est la possibilité de connecter différents simulateurs permettant de détecter des interférences et faire des mesures. Ce navigateur permet aussi d'avoir des animations synchronisées avec des simulateurs de cinématique. La simulation n est pas répartie. Cet environnement ne permet pas de "plugger" n'importe quel type de simulateur et de connecter des simulateurs n'ayant pas été prévus pour fonctionner ensemble. C'est donc un produit industriel qui n'offre pas de réelle capacité de conception interactive ni d ouverture en terme de simulation. ENOVIA Il s'agit d'un ensemble de composants logiciels qui sont aussi fournis par Dassault Systèmes. Ils visent l'e-business, le prototypage virtuel et des techniques de simulations qui couvrent tout le cycle de vie d'un produit. C'est une approche de base de données qui gère les versions, le workflow et la coopération au sein d'une équipe étendue. Elle repose sur des systèmes de base de données comme DB2 ou Oracle. ENOVIAPortal [ENOP 2000] comprend des composants pour propager et partager des documents 3D. La fonction de base est une navigation Web au travers de documents 3D, 2D et de différents type de documents CAO. Des mesures locales sont possibles pour détecter des interférences ou des collisions dans la scène 3D. Une revue coopérative est supportée de façon similaire à CATIA 4D Navigator. Des simulations, du même ordre qu'avec CATIA 4D 29

Navigator, sont possibles telles que l'analyse d'interférence ou des simulations de montage et démontage selon une cinématique de déplacement. ENOVIA Product Lifecycle [ENOV 2000] [ENOA 2000] permet grâce à une propagation d'évènements que des concepteurs distants puissent réagir aux mises à jour relatives à la définition du prototype. Les changements vis à vis du prototype sont enregistrés au sein de la base de données. Un vote réparti pour valider les changements effectués sur le prototype est disponible. La technique de coopération synchrone (au cours d'une session coopérative) est proche de CATIA 4D Navigator. Elle est étendue par une notification asynchrone des changements. Ainsi, les concepteurs peuvent être notifiés d'un changement en dehors d'une phase de réunion. Les notifications asynchrones utilisent la base de données pour transmettre les messages aux différents concepteurs. Par essence, la solution consiste en une gestion centralisée du prototype. La répartition repose sur un système de base de données qui est onéreux et nécessite des procédures d'administration complexes. Certains simulateurs peuvent être exécutés au sein de la maquette virtuelle. Mais, il n'existe pas de méthode ouverte pour connecter des simulateurs entre eux. CoCreate OneSpace [HP 99] proposes des services de coopérations intéressants. Comme [DAS 98], les concepteurs peuvent réaliser des réunions de revue. Sur les mêmes principes, des points de vues et des télépointeurs permettent une visualisation simultanée de la maquette. Le principal avantage est la possibilité de modifier de façon interactive la scène 3D. Par exemple, un participant crée un nouvel objet et cet objet est transmis à tous les participants présents dans la réunion. Le système réalise ainsi une mise à jour incrémentale de la scène de façon à ce que les participants observent rapidement la modification. Les échanges sont réalisés au moyen d une architecture client-serveur. Après le chargement initial de la scène, les stations des participants effectuent localement le rendu de la scène. Le principe est le suivant. Une station envoie une commande (par exemple, une création) au serveur. Celui-ci traite la commande et envoie une mise à jour incrémentale aux différentes stations. Le serveur doit traiter toutes les mises à jour afin de les envoyer aux autres stations. 2.3.1.2 Réalité virtuelle répartie Nous décrivons maintenant des systèmes répartis qui peuvent être utilisés par une application de réalité virtuelle. La principale différence avec les environnements industriels décrits précédemment est que ces systèmes offrent une interface de programmation pour la répartition. Parmi le grand nombre de solutions dans la littérature, nous avons sélectionné les solutions de référence du domaine ainsi que celles qui présentent des points de comparaisons intéressants. 30

Distributed Interactive Simulation (DIS) DIS correspond à une norme [IEEE 95] et des implantations [MAC 95] réalisées par les militaires américains pour effectuer des simulations de champ de bataille au moyen d'un environnement de réalité virtuelle répartie. Dans ce type d application il existe un grand nombre d objets (par exemple, des chars et des avions) qui se déplacent dans la scène 3D. Il s agit donc de permettre à des utilisateurs répartis sur un réseau d observer la scène partagée et d interagir avec elle. Cette solution a inspiré bon nombre de solutions définies ensuite dans le domaine de la réalité virtuelle répartie. La norme définie la nature des entités d'application qui peuvent être réparties sur un réseau et les données d application qui peuvent être transmises. Il s agit donc d une description des applications de simulation de champs de bataille. Le point intéressant est le principe de système réparti sur lequel repose DIS. Dans un système réparti de type DIS, chaque entité d application maintient une copie des objets d application. DIS définit le format des messages permettant de transmettre les états des objets. Une technique permet d estimer l'état d'une entité entre deux transmissions (dead-reckoning). Le système réparti doit transmettre une mise à jour d objet à l ensemble des copies de l objet. Il doit le faire de la façon la plus efficace en utilisant peu de bande passante et en chargeant le moins possible les récepteurs. Le dead-reckoning est une technique d estimation de position qui permet de limiter le nombre d évènements transmis. Par ailleurs, DIS définit les caractéristiques de la couche transport qui permet la transmission des évènements. La couche transport est celle de l Internet. Les protocoles de transport peuvent être User Datagram Protocol (UDP) ou Transmission Control Protocol (TCP). L utilisation de l acheminement vers une adresse de groupe (multicast) est envisagée pour réduire les temps de transmission, limiter la bande passante nécessaire et décharger les récepteurs du traitement des évènements qui ne les concernent pas. L implantation de DIS décrite dans [MAC 95] utilise les capacités de diffusion vers un groupe d'entités (multicast) de l'internet Protocol (IP). La solution de multicast peut fonctionner soit à l'échelle d'un réseau local soit à l'échelle de l'internet au moyen de MBone [IETF 2001] qui est un réseau virtuel plaqué sur l Internet pour permettre le routage des adresses de multicast. Un composant appelé Area Of Interest Manager (AOIM) [MAC 95b] permet d associer différentes adresses multicast à différentes zones d intérêt de la scène 3D. Une zone d intérêt peut correspondre à une zone géographique (spatiale), fonctionnelle ou temporelle. Ainsi, le composant AOIM ouvre des extrémités réseau pour les adresses multicast correspondant aux zones d intérêt de l application. Cette solution limite le trafic traité par une station aux seuls évènements qui ont un intérêt pour l application. Différents filtrages sont effectués par les routeurs intermédiaires mais aussi par le coupleur réseau d une station réceptrice. Cela a pour effet de réduire le trafic réseau et de limiter le nombre d interruptions que génère le coupleur réseau en direction du système d exploitation de la station réceptrice. Ce travail a été précurseur car la plupart des solutions reprennent tout ou partie des principes définis pour les améliorer. Ainsi, dans les solutions qui suivent on retrouve des copies multiples maintenues au moyen d une transmission d événement via une transmission en diffusion (multicast IP). Distributed Interactive Virtual Environment (Dive) Dive [HAG 96] considère aussi des objets mobiles et vise à améliorer la perception synchrone des participants qui partagent la scène. La solution utilise des copies multiples maintenues par diffusion en utilisant le multicast IP. Le multicast IP étant non fiable une solution est proposée 31

pour récupérer les erreurs de transmission en récupérant une version récente de l objet. On évite ainsi de retransmettre des versions périmées d un objet. Dans ce système l application a la responsabilité de définir quel objet doit être présent dans une copie. Il s agit donc d une réplication partielle. Pour recevoir les mises à jour, l application joint l adresse de multicast correspondante. Chaque objet est associé à un propriétaire pendant une durée assez longue et les requêtes concurrentes devront attendre pendant toute cette durée. La solution considère donc que les requêtes concurrentes se produisent peu souvent. Puisque la réplication est partielle, un serveur doit maintenir l état de la scène pour assurer sa persistance. Le serveur recevra donc toutes les mises à jour et enregistre les modifications dans un support permanent. Le premier participant d une session charge la scène à partir du serveur. Les participants suivants demandent l état initial de la scène en multicast et reçoivent une réponse du participant le plus proche. Un protocole est défini pour localiser la copie la plus proche d un objet. Lorsqu une entité observe qu elle n est pas à jour ou lorsqu elle veut introduire l objet dans sa copie, elle envoie une requête en multicast. La copie la plus proche répond en incluant le numéro de version de l objet. En recevant la réponse, une autre copie répond aussi si elle possède une version plus récente. Les auteurs considèrent ainsi une propriété de cohérence qui en fait correspond à la fraîcheur d un objet. La solution implante aussi un module d estimation de position afin de réduire le nombre de mise à jour pour un objet mobile. High Level Architecture (HLA) HLA [IEEEa 2000] est le successeur de DIS. C est aussi une norme définie par les militaires américains. Elle repose sur les mêmes principes de copies multiples maintenues par diffusion. Elle étend sur plusieurs points l approche de DIS. D une part, elle améliore les capacités de perception temps réel pour un grand nombre d objet mobiles et des scènes 3D de très grandes tailles via un service de gestion de la distribution des données qui permet de définir des zones d intérêt [IEEEb 2000]. D autre part, elle propose des services de gestion du temps pour permettre de faire de la simulation répartie sur la base d un ordonnancement logique des évènements. Nous détaillerons plus avant ce point dans une section consacrée à ce thème. D autres services sont disponibles dont 1) une gestion de la simulation pour permettre aux simulateurs de joindre une session, 2) une déclaration des objets pour créer des instances d objets et s abonner aux mises à jour, 3) une gestion de la propriété des attributs d objets. Le service Data Distribution Management (DDM) de gestion de la distribution des données est en fait une généralisation du composant AOIM de [MAC 95b]. Il permet de restreindre les transmissions d évènements à une zone d intérêt. Bien qu il offre des solutions pour réduire le flux d évènements aux seuls évènements intéressants, ce service n est pas simple d usage. Si l application définit mal les zones, elle peut ne pas recevoir certains évènements qui la concerne. Des services pour gérer la propriété des attributs sont fournis. Ces services permettent à une entité d application de transférer la propriété d un attribut vers une autre entité d application. Ce standard ne définit cependant pas de niveau de propriété comme le droit en lecture ou en écriture. Enfin, il n est pas intégré à une solution qui supporte le travail mobile. Bien que HLA ne standardise pas les protocoles nécessaires pour réaliser les services, un environnement d exécution appelé Run-Time Infrastructure (RTI) est disponible mais il ne fait partie de la standardisation. Il n est donc pas possible que des RTI différents soient développés par différents parties en espérant qu ils interopèrent. RTI utilise différentes 32

techniques tels que la réservation de ressources, la diffusion en mode moindre effort (multicast IP) et la diffusion fiable. En pratique, l utilisation des services n est très aisée. Le développeur doit fournir le code d un grand nombre de méthodes virtuelles. Bien qu il puisse se faire dans un langage orienté objet, le développement s apparente plutôt à un échange de message où l application doit décoder elle-même les messages reçus et appeler le code correspondant. L environnement ne réalise pas, contrairement à CORBA par exemple, l appel de la méthode sur laquelle s applique l objet. C est à l application de trouver l objet concerné et d appeler la méthode correspondante. La standardisation [OMG 99] permet de traiter l hétérogénéité des architectures matérielles (format mémoire little-endian ou big-endian) mais elle ne vise pas à fournir un réel bus à objet de simulation. Notamment, elle ne permet pas un appel transparent de la méthode de l objet concerné. Locales [BAR 96] propose de combiner différentes pièces (au sens pièce d une habitation) pour former un monde virtuel partagé. Ainsi, un participant situé dans une pièce peut observer les évènements des pièces adjacentes à travers les portes de communication. Un participant peut se déplacer d une pièce à une autre en franchissant une porte. La combinaison repose sur des matrices de transformation afin de connecter deux pièces adjacentes reliées par une porte. Ces matrices permettent de représenter au niveau de la porte ce qui se passe dans la pièce adjacente avec un effet visuel classique d échelle liée à la distance d observation. Dans ce contexte, une pièce voisine peut être connectée dynamiquement. Cette solution fournit des éléments intéressants. Tout d abord, elle autorise un déplacement fluide entre les pièces. Ensuite, elle offre de bonnes performances en décomposant le monde partagé en cellules qui peuvent être traitée indépendamment. Enfin, elle permet aux participants de combiner différents objets en connectant dynamiquement les pièces qui contiennent ces objets. Un serveur maintient chaque pièce au moyen d une adresse multicast spécifique. Une entité d application obtient la description des pièces en ce connectant au serveur. Ensuite, l application ouvre une extrémité de communication pour les adresses multicast qui correspondent aux pièces qu elle souhaite observer. Ainsi, une entité d application reçoit seulement les évènements qui proviennent des pièces qu elle observe. L usage de différentes adresses de multicast permet de filtrer efficacement les évènements observés par une entité d application. L objectif est du même ordre que les solutions AOIM [MAC 95b] et DDM [IEEEb 2000]. Distributed World Transfer Protocol [BRO 98] considère l usage d un serveur pour réaliser l initialisation du monde virtuel partagé, la fiabilité des mises à jour, la persistance, superviser les connexions des participants. Par essence, la solution la solution est cependant proche de [HAG 96]. Des mandataires maintiennent une copie du monde virtuel pour réduire la charge du serveur. Le serveur et les copies sont mises à jour lorsqu une entité diffuse un événement en multicast. Le système récupère les erreurs de transmission grâce à un démon sur le serveur. Une entité a ainsi la possibilité de récupérer tous les évènements via le serveur. 33

Pour des objets qui nécessitent une prise en charge de la fraîcheur, les évènements transportent une date globale qui permet aux récepteurs de supprimer les évènements périmés. Cependant, cette solution nécessite une synchronisation précise des horloges. La solution permet un simple contrôle de concurrence basé sur un mécanisme de verrou. L approche est un verrouillage par interaction plutôt qu un verrouillage par objet. Le serveur relâche le verrou au bout d un certain temps. Ce type de contrôle de concurrence convient pour des besoins tels que le contrôle concurrent du déplacement des objets. Comme la solution travaille au niveau des nœuds gérés par Virtual Reality Modeling Language (VRML), le système nécessite des techniques pour éviter un trop grand flux en sortie de chaque entité grâce à un découpage statique de la scène en plusieurs cellules. Chaque cellule peut être associée à une adresse multicast différente. Les cellules et les adresses multicast correspondantes sont transmises par le serveur lors de la connexion du participant. La solution reprend donc les idées présentes dans [IEEEa 2000] et [BAR 96] pour réduire la charge réseau. Mais elle est moins évoluée car elle ne définit pas comment ajouter dynamiquement des cellules ou comment gérer l intérêt pour les différentes cellules. Virtual reality transfer protocol (vrtp) [BRUT 97] vise la définition d un protocole de transmission pour partager des mondes virtuels VRML. Il s agit d une proposition de standard faite par le Wed3D consortium qui fait la promotion de l utilisation de VRML. Quatre types de communications devront être supportés. Premièrement, des interactions légères permettront de transmettre des évènements en mode moindre effort. Ces interactions peuvent être typiquement implantées en utilisant UDP en mode point-à-point et en multicast. Deuxièmement, des objets de grandes tailles peuvent être transmis via un serveur Web. Typiquement, un serveur Web central est considéré par les auteurs pour charger une scène, garantir la persistance et détecter des collisions. Troisièmement, des flux vidéo et audio pourront être transmis via RTP [SCH 96] via des canaux point-à-point et en multicast. Ainsi, la transmission des différents flux video, audio et des flux d interaction sera effectuée par RTP. Enfin, une désignation des ressources doit supporter tous les types de données transmises en utilisant des extensions des Uniform Resources Locators (URLs). Le principal effort concerne les flux vidéo, audio et des interactions. Une architecture réseau est proposée qui est inspirée de celle définie dans [MAC 95b]. Ainsi, un composant de gestion des zones d intérêt (Area-of-interest manager) permet la connexion aux adresses multicast. Un composant de gestion de flux (Behavior streaming buffer) utilise la gestion des zones d intérêt et fournit des extrémités de transmission logique aux différents types de flux. Le protocole RTP utilise les services du composant de gestion de flux et permet donc une transmission pour les applications interactives et temps réel. Un composant (dial-a-behavior protocol) permet le codage et la sérialisation en utilisant XML. Enfin, un composant (Entity event dispatcher) permet de dispatcher les flux vers les différents nœuds de l arbre de scène. vrtp est considéré par le Web consortium comme le futur standard de communication pour les applications VRML. Cependant, vrtp n est pas complètement défini et manque de spécifications et de code utilisable. Il s agit donc d un premier niveau de proposition avec peu de détails de spécification et pas de code réellement disponible. 34

Bibliothèque de distribution pour librairie 3D [HES 99] permet le partage d un arbre de scène Open Inventor [STRA 92] qui est une bibliothèque de référence en matière de développement d application de réalité virtuelle. Comme dans les solutions décrites précédemment, le principe des copies multiples est là aussi retenu. Cependant ici le partage consiste à répliquer l arbre de scène Open Inventor. Il s agit d une réplication des objets géométriques élémentaires qui permettent de réaliser le rendu graphique. Par exemple, une bouteille peut typiquement comporter un nombre important d objets géométriques élémentaires afin de réaliser le rendu. Les opérations qui sont transmises aux répliques correspondent aux appels à la libraire Open Inventor pour créer, mettre à jour ou détruire un nœud de l arbre de scène Open Inventor. De ce point de vue, la solution est proche de [BRO 98] et génère un nombre d événements assez important. En effet, lors de la création d une bouteille il va falloir transmettre autant d événements qu il existe de nœuds Open Inventor pour le rendu. Certaines parties de l arbre de scène ne sont pas répliquées lorsqu un participant décide de ne pas les partager. Un séquenceur reçoit les évènements afin de les ordonner et pour que les répliques effectuent la même suite d opérations. Le séquenceur transmet en multicast les événements ordonnés. Plusieurs séquenceurs peuvent être utilisés pour des portions de scènes indépendantes afin de répartir la charge d ordonnancement sur plusieurs machines. Cependant la technique d ordonnancement utilisée n est pas décrite. La solution présente certains problèmes lorsque la structure de l arbre de scène est modifiée c est-à-dire lorsqu une entité d application ajoute ou détruit un nœud. En effet, elle ne permet pas de traduire directement la modification dans l arbre de scène. Ce qui peut laisser supposer que l application ne pourra pas accéder de façon simple aux modifications. Lorsqu un nouveau participant arrive, les échanges sont gelés jusqu à ce que le nouveau participant ait récupéré l état complet de la scène répartie. Cette technique est assez pénalisante car elle ne permet pas de travailler lors d une phase d entrée d un participant. De plus, la technique pour synchroniser le nouveau participant n est pas décrite. [ZEL 2000] vise aussi à répartir un arbre de scène 3D. A l inverse de [HES 99], [ZEL 2000] permet à des librairies 3D hétérogènes de pouvoir partager un arbre de scène 3D. Donc il s agit de partager des objets géométriques élémentaires selon le principe d arbre de scène mais de façon indépendante de la librairie 3D sous-jacente. Pour cela, un arbre de scène 3D neutre, Neutral Scene Graph (NSG), est partagé en copies multiples. L arbre neutre NSG correspond à une notion de syntaxe de transfert que l on trouve au niveau présentation de l architecture OSI. Cette syntaxe de transfert peut être projetée selon différentes syntaxes abstraites qui correspondent à des librairies 3D différentes (Open Inventor, Jot [ZEL 96] ). Le parallèle avec le niveau présentation OSI ne peut pas être fait complètement. En effet, dans [ZEL 2000] les applications ne partagent pas des données abstraites au moyen d un langage commun (tel que ASN-1 où CORBA-IDL) mais partagent directement les données définies selon la syntaxe de transfert. Une couche d adaptation projette l arbre neutre en un arbre de scène de la librairie 3D cible. Par exemple, une couche d adaptation est prévue pour projeter l arbre NSG en un arbre de scène Open Inventor. L arbre NSG contient des nœuds qui correspond à des nœuds de géométrie (matrices de transformation, polygones, etc ) que l on trouve classiquement dans une libraire 3D telle que Open Inventor ou Jot. Les nœuds NSG ont donc une sémantique de bas niveau. De ce point de vue la solution a la même approche que [HES 99] en ce sens qu elle vise des répliques d objets graphiques élémentaires (cube, sphere, cylindre ou ensemble quelconque de polygones). 35

La solution consiste en une librairie qui est liée à l application en lieu et place de la librairie cible habituelle. Lorsqu un objet de la libraire cible, Open Inventor par exemple, est créé, un objet associé est créé dans l arbre NSG et des appels montants sont ainsi installés vers l arbre neutre. De cette façon toute modification sur l arbre cible est propagée sur l arbre NSG partagé. Une première implantation est réalisée selon un mode réparti. Un nœud est maintenu par son entité d application créatrice. Lorsqu une autre entité d application veut modifier ce nœud, elle envoie une requête à l entité application créatrice. Une entité d application créatrice propage les modifications vers les répliques au moyen de connections TCP. Une seconde implantation repose sur un serveur qui reçoit les requêtes concernant les nœuds NSG et les propagent en multicast vers les répliques. Pour cela, un verrou est posé sur le nœud concerné afin de traiter les modifications concurrentes. Le verrou est propagé par le serveur vers les répliques au moyen de messages transmis de façon fiable. Ainsi seule la réplique possédant le verrou peut effectuer une modification. Les mises à jour du nœud sont ensuite transmises par le serveur de façon non fiable dans un mode moindre effort. Enfin, il faut noter que la couche d adaptation nécessite des fonctionnalités particulières de la part de la libraire cible. La couche d adaptation est selon l avis des auteurs difficilement transposables à certaines librairies 3D telles que Java3D ou Performer [ROH 94]. Le principal intérêt de cette solution est qu elle évite de modifier les applications Open Inventor bien qu en pratique des techniques spécifiques devront être développées par l application pour traiter des incohérences ou des problèmes de coopération. Comme dans [HES 99] des problèmes de performances peuvent se poser en partageant la géométrie. 2.3.1.3 Discussion Le principal objectif des produits industriels de CAO est la revue coopérative. Bien que certaines solutions permettent des opérations de modifications interactives (synchrones), elles traitent mal les activités de travail parallèle et mobile. La plupart du temps la mobilité est limitée au chargement de documents vers une base de donnée. Le travail mobile avec une réunion des travaux parallèles n est donc pas traité ou bien nécessite l utilisation de techniques de bases de données peu adaptées pour des solutions interactives. Une équipe étendue ne peut donc pas alterner aisément entre des phases de travail mobile et des réunions interactives pour le partage et la conciliation. Ces systèmes reposent sur des approches de type base de données et des architectures centralisées. Leur mise en œuvre est difficile et coûteuse dans le cadre d une entreprise étendue. De plus, il n est pas aisé d avoir une équipe complètement étendue puisque l hébergement et l administration est dévolue à une unique entreprise. D un autre côté les architectures centralisées présentent un goulot d étranglement et sont sensibles aux pannes. Les solutions industrielles sont donc des systèmes qui n offrent pas de services de coopérations (du type interface de programmation) pouvant être intégrés à n importe quelle application de prototypage. L ouverture n est pas non plus assurée en matière de simulation puisque ces systèmes ne proposent pas de canevas pour intégrer et faire communiquer n importe quel simulateur du commerce. Actuellement il n existe pas de solutions pour effectuer une simulation distribuée qui synchronise les différents simulateurs. D un autre côté, les environnements de réalité virtuelle répartie considèrent principalement comment réduire le trafic réseau des objets en mouvement. Ces systèmes ne supportent pas le travail parallèle [BAR 96] ou ne garantissent pas la progression du travail au sens où un concepteur peut avoir à refaire certaines opérations en raison de problème de concurrence. Si 36

certains auteurs comme [HAG 96] ont envisagé dans leur version première d utiliser des techniques de diffusion ordonnée afin de limiter les incohérences de partage, ils les ont très vite abandonnées en raison de problèmes de performances et de mise en œuvre qu elles engendrent. Aucune des solutions actuelles ne permet de répartir un arbre de scène entre des travailleurs mobiles. Elles n offrent pas de services pour réunir et concilier durant une réunion des travaux effectués de façon déconnectée sur une partie de la scène. Enfin, certaines utilisent un serveur pour garantir la persistance [HAG 96] [BRU 97] ou gérer les participants et effectuer un contrôle de concurrence [BRO 96] [ZEL 2000] basé sur des verrous. Cependant, l utilisation d un serveur fragilise le système et est peu applicable dans le cadre d une entreprise étendue. Enfin nous expliquerons par la suite que l utilisation de verrous n est pas une solution qui garantit la progression du travail et encore moins la cohérence des données répliquées. Certaines solutions [IEEEa 2000] peuvent utiliser des techniques de réservation de bande passante qui ne sont pas toujours disponibles ni au niveau des infrastructures réseau actuelles ni au niveau des stations de travail. Par ailleurs, certaines solutions [BRO 98] [HES 99] [ZEL 2000] travaillent à un niveau trop bas qui correspond à la transmission d informations de géométrie. Cela se traduit par une transmission d un trop grand volume de données sur le réseau. Enfin peu de propositions actuelles permettent de traiter l hétérogénéité des applications qui peuvent participer à une session coopérative. Lorsqu elles visent à traiter l hétérogénéité, elles le font comme [ZEL 2000] au niveau de la librairie 3D en introduisant une notion d arbre de scène 3D qui n est pas toujours facilement transposable pour toutes les librairies 3D. De plus, nous avons vu que cette approche conduit à un trafic réseau important puisque l arbre de scène partagé est un arbre proche des abstractions géométriques que manipulent les librairies 3D. Enfin, pas plus les outils industriels de CAO que les environnements de réalité virtuelle répartie ne proposent des propriétés de sécurité (authentification, confidentialité et intégrité) dans le contexte d un réseau ouvert et non sécurisé comme l Internet. Les environnements de réalité virtuelle répartie ne le permettent pas car ils utilisent généralement un mode non connecté et en multicast pour lequel il n existe actuellement pas de solutions de sécurité standardisées et déployées sur l Internet actuel. Ainsi, ces solutions ne peuvent pas être déployées de façon sécurisée sans avoir recourt à des architectures de réseau qui sont sécurisées par exemple au niveau d IP [IPSec 98]. 2.3.2 La solution de la métaphore du chantier réparti 2.3.2.1 Facteurs de choix et caractéristiques de la solution Principe du chantier réparti La définition d une nouvelle métaphore repose sur le constat que les solutions actuelles issues des produits industriels, des environnements de réalité virtuelle répartie et de travail coopératif ne permettent pas à des concepteurs mobiles de partager un arbre de scène en alternant aisément parmi différents modes de conception coopérative. La métaphore du chantier réparti repose sur le principe que l on trouve sur un chantier de construction. Dans ce cadre, différents corps de métiers préparent les différentes pièces dans 37

leurs ateliers respectifs et se réunissent sur le chantier pour les assembler en commun. Ils effectuent in situ les ajustements nécessaires pour régler les incompatibilités éventuelles. Par exemple, le concepteur d un système électrique peut, en concertation avec le concepteur d un système à combustible, être amené à déplacer certains éléments parce qu ils se trouvent trop prêt d un circuit d alimentation en combustible. Travail mobile, partage et répartition d un arbre de scène La métaphore supporte deux types de connectivité. La réunion permet aux concepteurs de partager un arbre de scène globale et de le modifier de façon interactive (en créant, détruisant ou modifiant certains nœuds). La réunion permet d assembler automatiquement les différentes pièces du puzzle global aux emplacements exacts du point de vue fonctionnel. Pour cela, chaque concepteur entre en réunion en apportant des pièces qu il a préparées généralement de façon déconnectée. Une pièce du puzzle, qui vient se placer à l emplacement exact dans l arbre, peut cependant présenter des incompatibilités avec d autres éléments du puzzle. Il est difficile d éviter ce type d incohérence étant donné que les concepteurs préparent les pièces de façon déconnectée et donc sans possibilité d échange entre eux. Par ailleurs, ils veulent généralement avoir la possibilité de résoudre par la négociation ce type d incompatibilité. Lorsqu il quitte la réunion un participant définit les pièces du puzzle qu il souhaite conserver dans son espace de travail déconnecté. Ainsi typiquement, l électricien ne conservera que les parties électriques et les parties associées d un point de vue fonctionnel tel que les circuits de combustible. En fait, un concepteur peut très bien décider de conserver la totalité de la scène partagée dans son espace de travail déconnecté. On se retrouve donc avec des répliques déconnectées qui sont des répliques partielles ou complètes de la scène globale. Le travail déconnecté permet à un concepteur d améliorer la scène globale sans avoir besoin d aucune connexion réseau. Il peut par exemple travailler dans le train sur son portable. Il peut alors ajouter de nouvelles pièces au puzzle (ajout de nœuds à la copie locale de la scène), supprimer ou modifier des pièces existantes (respectivement supprimer ou modifier un nœud de la copie locale de la scène). En dépit de la déconnexion, les mises à jour de la copie locale modifient la scène globale partagée. Tant que le concepteur reste dans le mode déconnecté, cette modification de la scène partagée n est simplement pas accessible aux autres concepteurs. Cependant, lors d une prochaine réunion, la scène globale va se reformer en assemblant automatiquement les éléments du puzzle à la bonne place. Protection répartie supportant la mobilité L utilisation d un arbre de scène partagée doit respecter les droits des différents concepteurs. Pour cela, chaque nœud a un seul propriétaire. La propriété et les droits du nœud peuvent évoluer au cours de la vie de la scène partagée. Nous verrons que ceci est réalisé via le transfert de propriété d un nœud. De plus, des attributs en écriture et lecture peuvent être modifiés pour étendre ou restreindre les permissions sur le nœud. Le système reste cohérent du point de vue de la protection malgré les phases de déconnexions. De plus, la notion de propriétaire permet de garantir une cohérence de la protection répartie aussi bien en réunion qu en phase déconnectée. 38

Travail simultané (ou parallèle) et progression du travail L arbre de scène partagé offre un grain suffisamment fin de coopération pour permettre le travail simultané (ou en parallèle) de plusieurs concepteurs aussi bien en réunion qu en mode déconnecté. En dépit de ce niveau élevé de parallélisme, une progression cohérente du travail est garantie. Cette propriété ne vise pas à garantir une cohérence globale de la scène dont on a vu qu elle était quasiment impossible à obtenir lorsqu on alterne des phases de connexions et de déconnexions. Elle évite cependant qu un concepteur voie son travail sur un nœud, perdu de façon intempestive, en raison d une opération concurrente d un autre concepteur. Avec notre métaphore, un concepteur observera toujours le dernier état d un nœud avant de pouvoir le modifier. Il décidera donc en contexte de modifier ou non ce nœud. La solution favorise donc le travail en contexte et évite aux concepteurs d avoir à refaire des opérations qui n ont pas été observées par les concepteurs distants. Arbre de scène portant la sémantique des objets de l application Nous avons vu que la partage d un arbre de scène de géométrie présente différents problèmes. D une part, cela ne permet pas de transporter efficacement un objet car celui-ci est alors transmis comme autant d éléments de géométrie. D autre part, un partage de trop bas niveau ne permet pas de traiter l hétérogénéité des librairies 3D sous-jacentes. En effet, les librairies 3D ne gèrent pas la géométrie de la même façon. C est pourquoi l arbre de scène que nous partageons est un arbre ayant la sémantique que lui associe l application. Les entités d application partagent donc un arbre qui constitue un métamodèle auquel on peut associer des attributs géométriques, des attributs de coopération mais aussi toute sorte d attribut comme des attributs de simulation. Chaque nœud de l arbre peut donc être vu comme un conteneur avec des données du méta-modèle (essentiellement des données de répartition), des données géométriques et des données diverses de simulation ou autre. L application dispose alors d une interface de programmation pour la coopération qui permet de créer des objets et de les partager en associant tous les types d attributs qu elle souhaite communiquer aux entités distantes. Par exemple, l application peut ajouter un nœud de l arbre qui correspond à une voiture et elle donne les attributs de la voiture (type de voiture, couleur, position, vitesse, etc ). Ainsi, toute entité d application réalisera un rendu graphique de l objet partagé selon ses propres capacités géométriques et les modèles d objet dont elle dispose. Cette technique est très souple car elle permet si nécessaire de travailler à un niveau plus bas pour transmettre la géométrie de l objet. Caractéristiques système et réseau de la solution Notre métaphore correspond à la définition d un canevas général de répartition pour la conception coopérative. Elle n est donc pas dépendante d une architecture système ou réseau particulière. La métaphore peut donc fonctionner sur un réseau Internet des plus standard et une architecture de système d exploitation telle qu on la rencontre actuellement sur les machines Windows, Unix ou Mac. Cependant, la métaphore contient aussi des solutions de répartition qui sont adaptées à l utilisation d un mode de communication moindre effort et en multicast. Elle contient aussi des techniques pour que la solution s adapte automatiquement à la nature de réseau sous-jacent (support ou non du multicast). Cela fait que même si la solution est déployée sur un réseau ne supportant pas certaines fonctionnalités (notamment le multicast), elle s adaptera dans une certaine mesure à la capacité du réseau. Elle peut être 39

implantée sur une pile de transport en mode connectée comme TCP. La principale différence étant qu une implantation au-dessus de TCP, ne permettra pas certains gains de performance. Notre métaphore fixe donc des contraintes relativement lâches de la part du réseau et du service de transport sous-jacent ce qui lui permet de pouvoir être implantée de différentes façons. Sécurité D un point de vue sécurité, la principale difficulté réside dans l usage de communications UDP en multicast pour lesquelles il n existe pas de solutions qui soient disponibles et largement déployées sur l Internet actuel. Actuellement, les solutions répandues d un point de vue de la sécurité résident dans l usage de connexions TCP sécurisées ou dans le déploiement d architectures réseau sécurisées. La métaphore propose un principe de sécurisation qui peut fonctionner sur l Internet actuel et dont la mise en œuvre peut être intégrée à la librairie actuelle. La proposition repose sur une utilisation originale d outils et techniques de sécurité largement répandues. Le principe est d utiliser le courrier électronique pour transférer une clé de chiffrement symétrique (DES) pour une réunion de coopération. En effet, les concepteurs utilisent généralement le courrier électronique pour planifier une réunion de travail. C est donc le courrier électronique qui servira à transmettre la clé de session. Ensuite, la clé de session est utilisée pour crypter de façon symétrique le donnée. Afin que la clé ne puisse pas être cassée par un attaquant qui observe le réseau, celle-ci doit être modifiée en cours de session. Le protocole Diffie-Hellman [DIFF 76] est utilisé pour échanger un secret qui sert à crypter une nouvelle clé de session. Ainsi, la nouvelle clé de session qui est transmise ne peut être découverte par un participant non authentifié. 2.3.2.2 Présentation de la métaphore La métaphore comprend différents services et définit leurs principes de mise en œuvre. Elle propose une architecture pair-à-pair (peer-to-peer) complètement répartie, des techniques et des protocoles pour réaliser les différents services. Durant une réunion, le principe de système réparti sur lequel repose la métaphore est que chaque participant dispose d une copie de la scène partagée. Une entité d application est un pair (peer) qui traite localement chaque interaction ce qui permet de mettre à jour la copie locale et de transmettre l interaction aux copies distantes. Chaque pair récepteur traite alors l interaction ce qui conduit au même état que si l interaction était locale. Un pair (peer) mets à jour un pair distant grâce à la transmission d un événement contenant l interaction à effectuer sur la copie distante. L événement contient tous les attributs d interaction (type, référence du nœud, état du nœud, propriétaire, droits). Décrivons maintenant les services rendus et les principes de mise en œuvre. Désignation répartie supportant la mobilité Problème Les nœuds de l arbre global doivent conserver des noms uniques dans le temps et dans l espace aussi bien parmi les espaces déconnectés que parmi les copies d une réunion. La 40

figure 1 montre un arbre relatif à un système de ventilation. Cet arbre inclut un sous-système électrique et un sous-système hydraulique. La figure présente le rendu 3D correspond. La solution doit garantir plusieurs propriétés. Tout d abord, les noms uniques doivent être faciles à générer et à utiliser. Deuxièmement, deux espaces privés ou répliques ne peuvent pas contenir le même nœud avec deux noms différents. Durant une phase de travail déconnecté, la pompe peut être présente dans deux espaces mais elle reste désignée avec le même nom. Durant une réunion, deux répliques utilisent le même nom pour accéder au nœud pompe. Troisièmement, si un nom désigne deux nœuds distincts alors seul un des deux est actif et l autre est un nœud fantôme qui ne peut pas être modifié localement. Un nœud fantôme disparaîtra lors d une prochaine réunion en étant remplacé par le nœud actif. Au contraire, deux versions d un même nœud portent le même nom. Pump Ventilation system Hydraulic pipes Electric Hydraulic Sensor 1 Pump Switch 1 Sensor 2 Sensor 3 Switch 2 Switch 3 Main pipe Air vent Pressure sensors Vent 1 Vent 2 Vent 3 Switch Fig. 1 Exemple d arbre de scène et de son rendu 3D Solution Un pair (c est-à-dire une entité d application traitant une copie ou un espace déconnecté) calcule localement un nouveau nom unique lorsqu un utilisateur crée un nouveau nœud. Un nom unique contient l adresse IP de la machine créatrice, une estampille locale et une position dans l arbre, par exemple @IPA,estampille,1.3. Une estampille contient la date locale de création plus un nombre aléatoire. La position dans l arbre comprend la position du nœud père et le numéro du nœud fils. Ainsi, le nœud @IPA,estampille,1.3 est un fils du nœud @IPA,estampille,1. Un nœud du premier niveau (c est-à-dire un nœud rattaché directement à la racine) porte un nom de la forme @IPA,estampille. Par ailleurs, un nœud maintient localement la liste de noms des nœuds fils. Pour créer ou détruire un nœud et donc supprimer le nom, un utilisateur doit être propriétaire du nœud père. Par exemple, pour créer le nom @IPA,estampille,1.3 l utilisateur doit être propriétaire du nœud @IPA,estampille,1. Un nœud @IPA,estampille peut être créé au premier niveau de façon déconnectée. Cela permet typiquement d ajouter de nouveaux sous-systèmes. Cette opération peut même se faire sans être attachée à un arbre existant. Un utilisateur prépare ainsi un sous-arbre et peut ensuite introduire le sous-arbre dans n importe quelle réunion. 41

Un nœud créé possède un attribut de propriété qui est positionné pour l utilisateur créateur du nœud. La propriété pourra être transférée à un autre utilisateur comme nous le verrons par la suite, mais le système devra garantir qu il existe un seul propriétaire à un instant donné pour ce nœud. La figure 2 présente un arbre partagé tel qu il peut exister à un instant donné dans une copie ou un espace privé. La racine de l arbre correspond au nom de la réunion. On peut remarquer que les noms uniques définissent la position fonctionnelle dans l arbre mais pas la position géométrique dans la scène 3D. En fait la position géométrique est une information d état de l objet qui ne peut en aucune façon définir le rôle fonctionnel du nœud. Ventilation Meeting @IPA,stampA Electric Hydraulic @IPB,stampB @IPA,stampA,1 Pump Main pipe @IPB stampb,1 @IPB,stampB,1.1 @IPB,stampB,1.3 @IPB,stampB,1.2 Vent 1 Vent 2 Vent 3 @IPB,stampB,1.3.1 @IPB,stampB,1.1.1 @IPB,stampB,1.2.1 Fig. 2 Noms uniques d un arbre partagé La première propriété est satisfaite. Les noms uniques sont faciles à créer puisque chaque nom peut être calculé localement. Ainsi, un nom unique peut être créé aussi bien en réunion qu en phase déconnectée. Le format d un nom unique présente plusieurs facilités d usage. Un nom unique est indépendant de la position géographique dans la scène 3D. Ainsi, les objets peuvent se déplacer dans l environnement virtuel sans que leurs noms changent. Un nom unique définit la position d un nœud dans l arbre global. Ainsi, un nom est unique, dans le temps et l espace, et il définit aussi le rôle fonctionnel du nœud. Enfin, l application et la librairie de coopération peuvent récupérer à partir d un nom quel est le nœud père. Cela permet par exemple de contrôler une opération de destruction en vérifiant que l application a bien la propriété du père sans pour autant que l application ou la librairie ait à maintenir le lien fils-père. La deuxième propriété est satisfaite puisque le nom d un nœud est défini au moment de la création et reste inchangé pendant toute la durée de vie de ce nœud. La troisième propriété est garantie. Le raisonnement est le suivant. Pour créer un nom un utilisateur doit être le propriétaire du nœud père. En récupérant la propriété du nœud père, l entité créatrice récupère aussi la liste des nœuds fils, elle peut ainsi garantir que le nom créé est bien unique c est-à-dire qu elle ne réutilise pas un nom existant. Pour être réutilisé, un nom doit donc être détruit ce qui signifie que le propriétaire du nom doit être présent. Donc si le même nom est utilisé par un autre nœud, c est que son utilisateur n est pas présent dans la réunion ou qu il n est pas le propriétaire de ce nœud. Donc seul un espace privé peut contenir un nœud fantôme. Le nœud fantôme sera remplacé lorsque l utilisateur déconnecté et le propriétaire du nouveau nœud entreront dans un même réunion. 42

On peut noter qu un utilisateur peut changer d adresse IP sans aucune difficulté. Un nom existant reste unique dans le temps et l espace puisque le nom est inchangé durant toute la vie du nœud. L attribution de cette même adresse IP produira des noms différents. La probabilité que les deux machines ayant utilisées une même adresse produisent le même nom est proche de zéro car il faudrait que les deux opérations de création se produisent à la même date et avec le même nombre aléatoire. Pour des machines possédant des horloges complètement désynchronisées, les nombres aléatoires permettent de discriminer deux noms. Protection répartie supportant la mobilité Problème En dépit d un traitement réparti et déconnecté, le système doit garantir une unique règle de protection tout en préservant la désignation répartie. Premièrement, une opération doit préserver la protection du nœud concerné. Par exemple, un participant a besoin d une permission en écriture pour modifier la couleur de la pompe. Deuxièmement, deux espaces déconnectés distincts (ou des répliques) ne peuvent présenter des propriétaires différents pour un même nœud. Troisièmement, une règle unique de protection existe pour une version donnée d un nœud et pour des espaces déconnectés ou des copies différentes. Quatrièmement, un utilisateur ne peut écrire un nœud dans son espace déconnecté si un autre espace ou copie ne permet l opération. Ainsi, les opérations interdites sont prévenues parmi des espaces déconnectés différents. Cinquièmement, la protection doit permettre de respecter les règles de désignation répartie. Prenons un exemple pour illustrer les problèmes à éviter. Un utilisateur est propriétaire d un nom, désignant une pompe, et interdit les opérations distantes sur ce nœud. Etant propriétaire du sous-système électrique, un second participant supprime le nœud correspond à ce soussystème. Ensuite, il crée un nouveau sous-système électrique en réutilisant la position du nœud détruit. Puis, il crée une seconde pompe à partir du nouveau sous-système électrique avec la même position que la première pompe. Les deux pompes ainsi créées possèdent la même référence vers le nœud père tandis que celui-ci n a connaissance que d un seul nœud fils. Le père n a donc plus de lien vers la première pompe qui se trouve donc complètement dissociée fonctionnellement du reste de l arbre. Donc les règles de protection peuvent efficacement contribuer à préserver une gestion correcte des noms et des positions fonctionnelles. Solution Pour qu un pair puisse lire un nœud, celui-ci doit posséder un attribut de lecture qui est positionné. Une permission en écriture est associée au propriétaire du nœud. Un autre utilisateur peut demander la permission en écriture lorsque l attribut est positionné pour un utilisateur distant. En réponse, il acquiert la propriété du nœud correspondant. Nous verrons plus loin comment ce transfert de propriété est réalisé. Les attributs de protection (lecture, écriture) sont transmis à chaque événement (création, suppression ou modification d un nœud) vers les copies distantes. Ainsi, chaque pair modifie l attribut de protection dans sa copie locale pour le nœud concerné par l événement reçu. Pour créer un nœud, l utilisateur doit être propriétaire du nœud père. Pour détruire un nœud, l utilisateur doit être propriétaire du nœud père et des nœuds fils. Les nœuds fils peuvent être 43

raccrochés au nœud père. Cela signifie que le sous-arbre associé à un nœud détruit n a pas besoin d être détruit. La première propriété est garantie puisque le système vérifie, avant de réaliser l opération, la permission nécessaire grâce aux attributs de protection. La seconde propriété est satisfaite car pour obtenir la propriété il faut la demander auprès du propriétaire actuel. Seul le propriétaire courant peut donc transférer la propriété. Une fois le transfert effectué, le nouveau propriétaire est le seul à avoir la propriété. Donc à tout instant, il ne peut y avoir qu un seul propriétaire dans le système. Nous expliquerons comment le transfert de propriété est fiabilisé. Pour se convaincre de la troisième propriété, deux espaces déconnectés ne peuvent présenter des règles de protection différentes que pour deux versions différentes du nœud considéré. Faisons un raisonnement pas l absurde. Considérons que deux espaces déconnectés présentent deux règles de protection différentes pour une même version d un nœud. Ces deux espaces ont alors récupéré la même version de l objet du même propriétaire. Donc, ils ont obtenu la même règle de protection de la part ce propriétaire. Ceci est contradictoire avec l hypothèse. Le même raisonnement s applique pour les copies d une réunion. Si un utilisateur a la permission d écrire un nœud, alors il est le propriétaire. Comme il ne peut y avoir qu un seul propriétaire à un instant donné, aucun autre utilisateur ne peut écrire. Donc aucune autre copie ou espace déconnecté n autorise l écriture. Un utilisateur doit être du père pour créer un nœud. La propriété du père interdit que l entité réutilise le nom d un fils existant comme nouveau nom. Ainsi, le nouveau nom est unique. Un utilisateur doit posséder le père et les fils pour supprimer un nœud. La propriété du père évite que celui-ci ne puisse être informé de la destruction du nœud. La propriété du père évite que la liaison fonctionnelle père-nœud, qui est détruite, continue d exister après la destruction. De même, la propriété des fils évite que les liaisons fonctionnelles avec les fils ne deviennent incohérentes. Ainsi le système garantit que les noms uniques existent et reflètent une position fonctionnelle correcte. On peut remarquer que la solution ne requiert pas la propriété du sous-arbre. Donc le coût d une opération de création ou de suppression est limité aux nœuds parents. Organisation sécurisée d une réunion Problème Les utilisateurs doivent avoir un support pour organiser une réunion. Il faut qu ils coopèrent pour établir la date et l heure de la réunion. Les données qui sont nécessaires pour établir la réunion doivent être transmises de façon sécurisée lors de cette phase d organisation de la réunion. Notamment, les canaux de communication et la clé de chiffrement, qui seront utilisés pour la réunion, sont transmis à ce moment. Pendant cette phase d organisation, les participants doivent être authentifiés et les données pour la réunion doivent être échangées de façon confidentielle. 44

Solution Nous proposons d utiliser les outils de messagerie électronique Internet car ils sont largement répandus et déployés actuellement. Cela évite de reconstruire une architecture de sécurité alors que des solutions existent actuellement. Ainsi, les utilisateurs utiliseront leur client habituel de messagerie (Microsoft Outlook ou Netscape Messenger par exemple) pour coopérer à l organisation de la réunion. Le protocole S/MIME [DUS 98] qui est intégré à tous les lecteurs de courrier électronique permet de transmettre de façon sécurisée les canaux de communication et la clé de session. La solution fournit les services suivants : - Négociation : les membres d un projet de conception coopérative utilisent le courrier électronique pour planifier la réunion. La négociation se fait en deux phases. Dans une première phase, un membre envoie un courrier en utilisant une liste de diffusion du courrier ce qui permet de démarrer la planification. Chaque membre du groupe répond sur cette même liste (qui peut évoluer au cours de la négociation). A la fin du processus de négociation, chaque membre de la liste de diffusion a authentifié les participants distants. Chaque membre a ainsi récupéré via les réponses, les certificats X509 [ITU 97] des autres membres. Les échanges des données de session ont lieu durant la seconde phase. Ainsi, la confidentialité est garantie pour la seconde phase d échange via les certificats X509 préalablement reçus. Les données, telles que les adresses de communication et la clé de chiffrement de la réunion, sont ainsi échangées de façon sécurisée entre les membres du projet. - Allocation d une adresse : durant la seconde phase, une adresse de session (typiquement une adresse de multicast) est choisie et transmise par courrier électronique. La réservation n est pas obligatoire car une solution est décrite par la suite pour résoudre dynamiquement en cours de réunion le problème d allocation d adresse. Pour résoudre les problèmes de conflits de propositions, un seul participant peut être choisi pour faire la proposition. Dans sa version la plus simple, la solution consiste donc en un protocole social pour choisir par e-mail un responsable pour la réunion (ce qui en pratique est souvent le cas). Le responsable de la réunion propose alors une adresse qu il peut choisir sans nécessité de réservation particulière. - Distribution de la clé de session : le responsable de la réunion alloue une clé de chiffrement symétrique PK S (par exemple, une clé du type Data Encryption Standard [US 93]) qui servira à crypter les données transmises au cours de la réunion. Cette clé est envoyée lors de la seconde phase d organisation de la réunion à la liste des participants. Elle est transmise de façon sécurisée via S/MIME et grâce aux certificats X509 acquis par lors de la première phase d organisation. Ainsi, seuls les participants authentifiés peuvent lire la clé de session PK S contenue dans le courrier électronique. Etablissement dynamique de la réunion Problème Chaque participant doit être en mesure de joindre une réunion dont il a acquit préalablement au cours de la phase d organisation les informations d établissement (adresse de communication et clé de session). De plus, il doit pouvoir découvrir dynamiquement qui est présent dans la réunion. En effet, certains membres prévus peuvent ne pas venir et d autres 45

peuvent s ajouter à la réunion en obtenant l autorisation et les données nécessaires d un des membres. Ceci se traduit par la nécessité que chaque entité établisse dynamiquement sa connaissance de l appartenance à la réunion. De plus, il est utile qu une couleur soit allouée dynamiquement à chaque participant de la réunion. C est un service qui peut être aisément utilisé pour agrémenter la coopération. Par exemple, l application peut colorer chaque objet selon la couleur allouée au participant qui en est propriétaire. Solution Un pair, entrant dans la réunion, diffuse le nom de son participant vers l adresse de multicast choisie. Les pairs distants répondent en diffusant leur nom. Ainsi, un nouveau pair établit localement sa connaissance de l appartenance à la réunion. Les pairs déjà présents mettent à jour leur propre connaissance en ajoutant le nouvel arrivant. Ensuite, un protocole alloue une couleur pour chaque participant. Le principe est le suivant. Un pair entrant diffuse vers l adresse de multicast une requête incluant son extrémité réseau (adresse IP et numéro de port). En réponse, un pair distant diffuse son nom, son extrémité et sa couleur. Pour terminer le protocole, le pair entrant diffuse un second message qui contient la couleur qu il a choisit. Lorsque deux pairs sont en conflit pour la même couleur, le pair ayant l extrémité réseau la plus petite change sa couleur et la diffuse. Ainsi, chaque pair obtient une couleur qui est unique et connaît les couleurs distantes. La première partie de la figure 3 donne un exemple de déroulement du protocole d établissement de la réunion. Elle montre Christian entrant en réunion concurremment avec Eric. Le conflit pour la couleur bleue est résolu à la fin de l entrée en réunion de Christian : seul ce pair envoie un second message en diffusion pour signaler son changement de couleur car il a la plus petite extrémité réseau. L attribution d une couleur est un agrément pour l application. Elle peut ne pas l utiliser. Elle peut aussi librement comme une bijection d un ensemble de valeurs entières contiguës vers l ensemble des participants. Agrégation automatique de l arbre partagé Problème Après la phase d établissement de la réunion, un participant doit pouvoir apporter des nœuds de l arbre global afin de reformer un arbre partagé. Les différents nœuds doivent rejoindre leur place fonctionnelle dans l arbre de façon automatique. A chaque nouvel arrivant, les participant distants doivent observer l ajout des nouveaux nœuds. Pour cela, chaque pair doit construire automatiquement l arbre partagé. De plus, chaque pair doit récupérer les erreurs de transmissions en obtenant un état frais pour chaque nœud de la scène globale. Solution Chaque pair maintient un objet liste qui contient le descriptif de tous les nœuds que le participant amène dans la réunion. Chaque nœud est décrit par son nom unique G X et son numéro de version, V X. L objet liste permet d annoncer les nœuds que le pair entrant va ajouter dans l arbre. L objet liste ne contient donc pas les états des nœuds. Un objet liste va évoluer avec les créations, les destructions et les transferts de propriété que le pair va effectuer. Comme un objet liste peut être relativement gros, sa transmission va se faire en 46

plusieurs messages. Un pair entrant diffuse un message [LIST: V L, TotParts, NPart, (G 1, V 1 ),, (G N, V N )] contenant une partie de l objet liste où V L est la version de l objet liste correspondant, TotParts est le nombre total de messages (parties) nécessaires pour transmettre l objet liste et NPart est le numéro de la partie de l objet liste qui est transmise. Le pair, qui a fait l annonce des nœuds entrants, diffuse un état [State: V L, G X, V X, T X, S X ] pour chacun des nœuds qu il a promis. Pour un état, V L est le numéro de version de l objet liste auquel appartient l objet G X transmis, T X est le type du nœud et S X est l état correspondant à la version V X de ce nœud. Ainsi, un pair distant récupère un descriptif de tous les nœuds entrant ainsi qu un état pour chacun d eux. Lorsqu un participant entre dans la réunion et diffuse ses nœuds, les participants distants vont répondre en transmettant à leur tour leur liste et les états de leurs nœuds. Les réponses sont faites en diffusion lorsqu un pair traite plusieurs entrants simultanément. Sinon les réponses sont faites en point-à-point. Un pair qui reçoit une partie de l objet liste sait s il a la totalité de l objet liste grâce au nombre de parties TotParts et au numéro de version V L. Ce mécanisme permet à un récepteur de reconstruire dans sa copie locale l objet liste d un participant distant. Il permet que l objet liste du participant distant évolue sans qu il y ait confusion pour un récepteur fautif qui n a pas encore reconstitué la liste précédente. Dès qu il recevra un message V L +1, ce récepteur mal chanceux pourra ainsi interrompre la reconstitution de l objet périmé V L et passer à la reconstitution de l objet suivant V L +1. Cela signifie que l agrégation de la scène peut se faire parallèlement avec des opérations de créations, destructions et modifications de nœuds. Un pair construit donc sa connaissance d un pair distant en même temps que celui-ci évolue. Il n y a donc pas de suspension de l utilisation de la copie locale de l arbre partagé lorsqu un nouveau participant entre dans la réunion. Donc l arrivée d un participant et les opérations (création, destruction, modification de nœuds) sur l arbre partagé peuvent se faire de façon complètement parallèle. Puisqu un pair maintient la liste des nœuds pour chaque participant, il peut demander la retransmission d un nœud manquant G X en diffusant une requête de retransmission pour un numéro de version supérieur ou égal à V X. Ainsi, le pair qui est actuellement le producteur du nœud G X va retransmettre uniquement la version courante V' X telle que V' X V X. Puisque chaque état transporte un numéro V L de version de liste, un pair récepteur qui n a pas encore reçu de message pour cette version de liste peut diffuser une requête de retransmission pour cette liste. Ainsi, un pair entrant assemble une copie de l arbre partagé grâce aux différentes réponses. De leur côté, les pairs ayant déjà une copie de l arbre partagé vont compléter cette copie en ajoutant les nœuds entrants. Donc à la fin d une étape d agrégation, déclenchée par l arrivée d un participant, chacun a reconstruit une copie du même arbre partagé. Lorsqu il y a plusieurs entrées en parallèle, les réponses sont diffusées. Ceci est intéressant car cela évite de transmettre plusieurs fois les messages et donc de traiter efficacement les entrées en parallèle. Nous avons vu qu une phase d agrégation n arrête pas les opérations sur les nœuds qui sont déjà dans l arbre partagé. Ainsi, les nouveaux nœuds viennent s agréger et en même temps des opérations peuvent se dérouler sur les nœuds qui sont dans une copie locale. Un pair A peut donc transmettre les nœuds entrants tandis qu en parallèle B modifie les nœuds qui viennent d être entrés ou qui existaient avant l entrée de A. 47

Chaque nœud va à la bonne place puisque le nom définit la position fonctionnelle dans l arbre partagé. Lorsqu un pair détecte une erreur de transmission (un nœud manquant ou une liste manquante), il demande des nouvelles versions. Ainsi, la retransmission donne toujours un état frais et on évite ainsi de retransmettre inutilement des données périmées. Begin membership for Christian Fabien Christian request request Eric 1 Begin membership for Eric reply red choose blue choose blue End Membership For Christian LIST: V L, TotParts, NPart, (G L, V L ), Conflict -> choose green End membership for Eric 2 LIST: V L, TotParts, NPart, (G L, V L ), STATE: V L, G 1, V 1, T 1, S 1. STATE: V L, G 2, V 2, T 2, S 2. STATE: V L, G 1, V 1, T 1, S 1. Fig. 3 (1) Etablissement dynamique de réunion et (2) agrégation automatique de l arbre partagé 48

La seconde partie de la figure 3 montre l envoie des messages de liste et d état pour le participant Fabien qui entre des nœuds dans la réunion (on considère ici que le participant Fabien bien qu il soit déjà dans la réunion n a pas encore entré ses nœuds dans l arbre partagé). Elle montre aussi les réponses qui sont faites par les pairs distants. Comme le pair pour Eric sait qu il y a deux entrants, il diffuse les réponses. Perception synchrone Problème Un participant doit percevoir les opérations (création, destruction ou modification d un nœud) réalisées par un participant distant de façon synchrone. Cela impose que le délai entre une interaction locale et sa perception par un utilisateur distant reste acceptable d un point de vue ergonomie. Il est préférable que la solution repose sur la suite de protocole la plus répandue sur l Internet à savoir IPv4 [IP 81]. Solution Un pair modifie un nœud G X en diffusant en multicast un message [State: V L, G X, V X, T X, S X ] ou [Delete: V L, G X, V X ]. Un pair récepteur utilise ces événements pour créer un nouveau nœud, mettre à jour ou détruire un nœud existant. Le récepteur n acquitte pas le message reçu. Lorsqu un pair créée ou détruit un nœud G X, il met à jour son objet liste en ajoutant ou retirant le nœud de la liste des nœuds qu il maintient (mylist:=mylist-g X ou mylist:=mylist+g X ) et en augmentant d une unité la version de son objet liste (mylistversion++). Ensuite, le pair diffuse un message [Deletion: V' L, G X, V X,] ou [State: V' L, G X, V X, T X, S X ] avec V' L =mylistversion. Un pair récepteur retire ou ajoute le nœud G X et il met à jour sa connaissance locale de l objet liste distant. Ainsi, l émetteur transmet un message court pour la mise à jour des copies distantes et n a pas besoin de transférer l objet liste. Un récepteur n acquitte pas ces opérations. Lorsqu un pair récepteur possède en attente de traitement deux versions pour le même nœud ou la même liste, il supprime la version la plus ancienne. Ce qui signifie qu un récepteur, qui reçoit un grand nombre d événements, ne traite que les événements qui sont d actualité. Les événements, pour mettre à jour les répliques de l arbre partagé, sont diffusés en multicast via le protocole UDP. On peut en déduire différentes considérations vis à vis des temps de réponse. Premièrement, UDP fournit un débit utile élevé car il fonctionne selon le mode moindre effort (best-effort). En effet, s il ne garantit aucune fiabilité, en contre-partie il n introduit pas les surcoûts et délais liés à la mise en œuvre des techniques nécessaires pour la fiabilité. Deuxièmement, le multicast est plus efficace lorsqu il faut transmettre un même message à un groupe de destinataires. En effet, l émetteur ne fait qu un seul envoie pour le groupe ce qui réduit le temps d émission par rapport à des envois multiples pour atteindre le groupe. Le multicast permet aussi d économiser la bande passante, au moins du côté de l émetteur puisqu il y a une plus petite quantité de données émises. Troisièmement, un émetteur n attend pas d acquittements positifs ce qui fait qu il peut émettre à un débit utile élevé. De son côté, le récepteur accélère le traitement des événements récents en évacuant les événements périmés. Ces trois éléments contribuent à l efficacité de la solution et permettent de réduire les temps de mise à jour des copies. Le débit utile est élevé et les événements périmés ne sont pas 49

traités. Les temps de réponse peuvent être réduits au maximum tout en reposant sur la pile Internet la plus standard à savoir IPv4. La solution ne nécessite donc aucune qualité de service particulière de la part du réseau sous-jacent. Elle peut ainsi se dispenser de techniques de réservation de ressources tels que [RSVP 97] [BLA 98]. Par ailleurs, les messages de mise à jour sont de petite taille. En effet, ce qui est transmis est une information décrivant fonctionnellement un nœud. C est donc une information qui est généralement beaucoup plus compact qu une information de géométrie. Pour fixer les idées et pour fournir une illustration simplifiée, on peut décrire une bouteille par un identifiant qui donne son type (bouteille de champagne) et sa position 3D tandis qu une description de la géométrie de la bouteille nécessitera de transmettre un grand nombre d objets 3D élémentaires (par exemple tous les polygones de la géométrie). Progression cohérente du travail Problème Le système doit garantir une progression du travail malgré les opérations concurrentes effectuées par les différents participants. Ici, le terme de cohérence est utilisé dans le sens où un nœud doit être observé par les participants selon différents sous-ensembles d une même séquence de progression : les participants n observent pas forcément toute la séquence des états d un nœud mais ils observent chacun une partie (plus ou moins complète) de cette séquence. En effet, nous avons vu qu une cohérence globale de la scène est difficilement envisageable dès que le travail alterne des phases connectées et déconnectées. La sémantique de cohérence qui doit être respectée est donc la suivante : une opération sur un nœud est effectuée à partir du dernier état du nœud. Ainsi, un concepteur peut observer l état courant du nœud avant de décider s il continue ou annule l opération qu il souhaitait effectuer. Solution Le transfert de propriété garantie qu une modification est effectuée à partir du dernier du nœud. Le propriétaire refuse le transfert si l attribut d écriture n est pas positionné. Sinon, le pair propriétaire transmet en même temps l état du nœud et la propriété au pair qui en fait la demande. Un transfert fonctionne en trois phases. Premièrement, le pair demandeur diffuse un message pour localiser le propriétaire. Deuxièmement, le propriétaire répond en point-à-point à la demande en donnant la propriété et l état. Troisièmement, lorsqu il reçoit la réponse, le pair gratifié de la propriété envoie un acquittement en point-à-point au donneur afin de terminer le transfert. Ce transfert de propriété doit être fiable. Pour cela, le demandeur attribue un numéro local à sa requête. Le propriétaire répond au demandeur en point-à-point avec le numéro reçu. Lorsqu il reçoit la réponse, le demandeur envoie l acquittement point-à-point contenant toujours le même numéro. Donc les trois messages portent le même numéro de séquence ce qui permet de les associer correctement. En absence de réponse, le demandeur renvoie sa requête. De son côté, le propriétaire renvoie sa réponse lorsqu il ne reçoit pas l acquittement. Ainsi, le transfert se termine lorsque le propriétaire est sûr d avoir cédé correctement la propriété. Les situations fautives sont ainsi traitées et on évite qu un nœud se retrouve sans propriétaire. 50

La figure 4 compare notre solution qui permet un travail en contexte avec une solution spéculative ne garantissant pas une progression cohérente du travail. Considérons d abord, une solution spéculative. A l instant T, le participant 1 met à jour l objet X avec la valeur B. A l instant T, le participant 2 spécule à propos de l état exact de l objet X et il met à jour X avec la valeur C. La mise à jour par le participant 2 a lieu avant que celui-ci ait pu observer l état B. Le participant 1 perd donc le travail effectué qui a conduit à l état B sans pour autant que le participant 2 ait eu l opportunité d observer cet état. B est donc un état non observable que devra éventuellement reconstituer le participant A. Il refera par exemple une seconde fois le même travail parce qu il n est pas satisfait de l état C proposé par la participant 2. Il n a cependant pas la garantie d aboutir mieux lors du second essai. L état du système étant incohérent (puisque les deux participants n ont pas le même état final pour l objet X), l utilisateur 2 peut de son côté décider lui-aussi de refaire l état C. L objet entre alors dans une phase d instabilité puisque les participants n ont pas les moyens d atteindre le même état. On peut observer que la pose d un verrou sur l objet X ne résout pas le problème. Sur la même figure, à l instant T, on peut considérer que le participant 1 a le verrou et le participant 2 l acquière à l instant T, mais le problème reste entier. La pose de verrou ne peut donc résoudre à elle seule le problème. La partie droite de la figure 4 présente comment notre transfert de propriété permet de résoudre le problème. Elle permet à un participant de travailler en contexte. A l instant T, le participant 2 veut modifier l objet X. Un transfert de propriété est alors déclenché et le participant 2 récupère donc d abord l état courant B auprès du propriétaire. Ainsi, le participant 2 peut décider en observant la valeur courante B s il veut ou non continuer son interaction pour mettre à jour l objet. La principale différence est que l utilisateur 2 observe l état courant avant d effectuer sa mise à jour. Ainsi, il décide en contexte et la spéculation sur l état courant de X est évitée. Notre solution préserve la séquence d état de l objet X sans pour autant que chaque participant ait besoin d observer toute la séquence. Il peut ne pas observer les états périmés, c est-à-dire les états qui n ont plus de raison d être présentés à un participant qui a pris du retard. En effet, la solution construit une séquence pour l objet X grâce aux différents transferts de propriété. Lors du transfert de propriété l état qui est transmis contient le numéro de version du nœud. Ce numéro de version matérialise en fait la séquence des états. Le numéro de version n est pas utilisé pour permettre l observation de toute la séquence mais au contraire pour supprimer et éviter l observation des états périmés. La figure 5 présente un scénario. Elle montre l objet X qui prend successivement les états A, B et C auprès des différents propriétaires. Le participant 3 observe les états A et C mais pas l état B car il arrive en retard et est donc supprimé. La progression cohérente peut être garantie pour une opération composée impliquant plusieurs nœuds. Dans ce cas, le transfert de propriété est réalisé pour chaque nœud impliqué. Ainsi, l utilisateur obtient un contexte exact pour tous les nœuds concernés par son interaction. 51

Object X=A Update: Object X=B User 1 User 2 T Object X=A User 1 User 2 Owner: Object X=A Object X=A Update: Object X=B T Object X=B T' Update: Object X=C Owner: Object X=B T' Start Interaction: Object X=C Object X=C Owner: Object X=B Redo Update: Object X=B Object X=B Continue or cancel? Speculation Work in context Fig. 4 Progression cohérente du travail Update: Object X=A User 1 User 2 Object X=A Start Interaction: User 3 Object X=A Object X=B Owner: Object X=A Update: Object X=B Start Interaction: Owner: Object X=B Update: Object X=C Object X=C Object X=C Fig. 5 Observation partielle de la séquence 52

Travail simultané (ou parallèle) Problème Plusieurs utilisateurs doivent pouvoir travailler simultanément durant la réunion mais aussi pendant les phases de déconnexion. La simultanéité des opérations doit être permise tout en garantissant la progression cohérente du travail. Solution Deux interactions, traitant deux nœuds distincts, sont traitées simultanément. Notamment, lorsque ces deux interactions sont effectuées par deux utilisateurs alors ces deux interactions s exécutent effectivement en parallèle. Les interactions opérant sur un grain suffisamment de nœuds partagés, deux utilisateurs réalisent des opérations simultanées lorsqu ils manipulent des nœuds différents : - Deux modifications pour des nœuds distincts sont exécutées simultanément. - Deux créations de nœuds sont traitées simultanément lorsqu elles n impliquent pas le même nœud père. - Deux suppressions sont simultanées lorsqu elles concernent deux ensembles disjoints pour le père et les fils. Deux interactions impliquant le même nœud sont sérialisées. Le pair propriétaire réalise une première interaction pour son utilisateur. Ensuite, le transfert de propriété à lieu vers le pair de l utilisateur distant. La seconde interaction peut alors s exécuter. La sérialisation est garantie par la transmission d état qui a lieu lors du transfert de propriété. Ainsi, la simultanéité des interactions est limitée seulement lorsque c est nécessaire afin de préserver la progression cohérente du travail. Rafraîchissement des copies Problème Un pair doit disposer d un servire pour re-synchroniser sa copie afin d obtenir un état frais pour l ensemble des nœuds détenus par des propriétaires distants. La solution pour rafraîchir une copie doit consommer peu de bande passante. Solution Pour améliorer les performances, les événements sont transmis dans un mode best effort. Donc, un récepteur peut perdre certains événements. En utilisant le service de rafraîchissement, un pair va pouvoir récupérer de façon efficace un état frais pour tous les états manquants. Pour récupérer les états frais, le service envoie une requête demandant l objet liste à un pair distant. Le pair distant répond en diffusion l objet liste. Le demandeur utilise l objet liste reçu pour ajouter et retirer les nœuds pour lesquels il a perdu l événement associé. Le pair récepteur utilise ensuite l objet liste pour vérifier quelles sont les versions de nœuds qui lui manque. Ainsi, il peut redemander une retransmission uniquement pour les nœuds qui n ont pas été rafraîchis. Seules les versions manquantes sont donc retransmises. Une requête de retransmission est une sorte d acquittement négatif (NACQ). Mais, ces NACQ ne sont pas générés pour récupérer tous les états d un nœud. Ils permettent de récupérer, 53

typiquement sur une demande de re-synchronisation l utilisateur ou de façon périodique, les versions manquantes. Les listes, les requêtes de retransmission et les réponses sont transmises en multicast. Ainsi, un pair qui observe un objet liste, une requête de retransmission où une réponse peut en profiter pour se re-synchroniser. Cela évite de retransmettre plusieurs fois la même chose pour les différents pairs. Un pair qui observe une requête de retransmission pour une version manquante peut ainsi se contenter d attendre la réponse. Enfin, des requêtes de retransmission pour différents nœuds sont assemblées afin d être diffusées dans un même message. Ainsi, un faible nombre de requêtes de retransmission circulent sur le réseau. En utilisant l objet liste demandé, un pair peut redemander les versions récentes qui lui manquent. Ainsi, la retransmission n a lieu que pour la dernière version du nœud demandé. Ce service transmet peu de données. Tout d abord, seules les versions manquantes sont retransmises en utilisant une technique d acquittement négatif. Ensuite, seul le dernier état du nœud demandé est retransmis et les versions périmées ne sont pas retransmises. Par ailleurs, la solution évite qu un émetteur ait à conservé les différentes versions d un nœud. Elle est donc simple et efficace en terme de gestion mémoire. Sécurité Problème La confidentialité doit être garantie durant la réunion. La solution doit permettre un cryptage robuste afin de rendre les attaques difficiles. La solution doit éviter de demander à un pair de traiter des certificats X509. Solution En utilisant une clé de chiffrement qui change en cours de réunion, chaque pair réalise pendant la réunion un cryptage symétrique DES pour les messages émis via UDP. Seuls les utilisateurs, authentifiés lors de l organisation de la réunion, ont reçu la clé de session initiale de façon sécurisée via S/MIME. Ainsi, seuls les utilisateurs authentifiés peuvent récupérer la clé de chiffrement courante et décrypter les messages échangés pendant la réunion. Pour limiter les attaques, la clé de session change en cours de réunion. Le protocole de changement de clé est le suivant. Le pair A ayant l extrémité réseau la plus petite, va choisir une nouvelle clé DES, PK N+1 S. Pour échanger cette nouvelle clé de façon sécurisée, A utilise le protocole Diffie-Hellman pour partager un secret K(I) avec chacun des participants I. A utilise le secret K(I) pour crypter la nouvelle clé, C=E K(I) (PK N+1 S), et il transmet le chiffre C résultant au participant I. Le participant I déchiffre alors la clé PK N+1 S=E K(I) (C). Chaque participant I conserve la clé précédente PK N S tant qu il n a pas réussi à décrypter un message émis par chacun des autres participants avec la nouvelle clé PK N+1 S. Ainsi, un participant peut continuer à décrypter les événements reçus avant l ancienne clé tant que la nouvelle clé n est pas utilisée de façon stable. Le pair A peut supprimer l ancienne clé PK N S quand il a transmis la nouvelle clé PK N+1 S à tous les autres participants. La clé de session initiale PK 0 S= PK S est changée avant de réaliser l agrégation de l arbre. La clé initiale servant peu souvent, un attaquant aura d autant plus de difficulté pour la casser. 54

La clé de session initiale PK 0 S est conservée pendant toute la durée de la réunion afin de pouvoir communiquer avec un participant qui entre en réunion après le changement de clé. Si la clé de session a changé, le pair A envoie à l entrant la nouvelle clé en utilisant le protocole Diffie-Hellman. Les données d agrégation sont donc transmises avec la nouvelle clé. Un nouveau pair peut avoir une extrémité réseau plus petite que le pair A qui pilote actuellement le changement de clé. Dans ce cas, le nouveau pair pilotera les changements ultérieurs une fois que A lui a transmis la nouvelle clé. Ceci évite d avoir plusieurs pairs qui pilotent le changement de clé. La confidentialité est fournie en cours de réunion avec un simple cryptage symétrique des données. L authentification, qui est une propriété nécessaire pour garantir la confidentialité, est garantie grâce au transfert par courrier électronique sécurisé de la clé de session initiale. Ainsi, seuls les participants authentifiés ont la clé de session initiale et peuvent récupérer la clé actuelle. La clé initiale étant peu utilisée, il est difficile pour un attaquant de la casser. Les pairs n ont pas à connaître les certificats X509, ni les clés RSA qui sont manipulées uniquement par les lecteurs de courriers électroniques. Cela simplifie le code des pairs et évite que les clés privées RSA soient présentes au niveau des entités qui coopèrent. La solution utilise de façon originale les outils sécurisés largement répandus (courrier électronique sécurisé) et des techniques classiques de chiffrement et de distribution pour mettre en œuvre une technique de sécurisation pour les outils de coopération au-dessus de UDP. Le niveau de sécurité atteint semble acceptable car la clé de session initiale qui est une information sensible est peu utilisée. De plus, le changement de clé évite les attaques par la force brute. Enfin, l adresse de multicast, utilisée pour les échanges, n est connue que des participants authentifiés. Cela évite qu une attaque soit planifiée sur cette adresse de multicast. Un attaquant n ayant pas la possibilité de connaître l adresse utilisée pour une réunion, il lui faudrait écouter toutes les adresses de multicast, deviner les canaux cryptés (sachant qu il peut difficilement savoir quels sont les canaux cryptés) et essayer de casser les échanges effectués sur toutes les adresses en service. Allocation dynamique d adresse de multicast Problème Puisqu il n y a pas de solutions standardisées pour réserver une adresse de multicast, une solution doit être fournie pour allouer dynamiquement en cours de réunion une adresse disponible. De plus, l adresse allouée doit être échangée de façon sécurisée entre les participants. Solution Lorsqu une autre application utilise la même adresse de multicast, chaque pair peut détecter automatiquement cette situation car certains messages reçus ne peuvent être décryptés avec aucune des clés en service. Le pair A (ayant la plus petite extrémité réseau) tire alors aléatoirement une adresse de multicast parmi toutes celles qui sont autorisées. Il écoute pendant un certain temps les activités sur l adresse choisie aléatoirement : s il n y a pas d activité, il la retient comme nouvelle adresse de multicast, sinon il tire aléatoirement une nouvelle adresse. Le pair A transmet ensuite la nouvelle adresse de multicast cryptée avec la clé de session courante. Recevant la nouvelle adresse, une pair B va joindre cette adresse. Pendant un certain 55

temps, le pair B écoute l ancienne adresse et la nouvelle jusqu à ce qu il reçoive un message de chaque pair sur la nouvelle adresse. Ensuite, il peut arrêter d écouter l ancienne adresse. Grâce au protocole de changement de clé de session, un nouveau participant ayant une extrémité réseau plus petite que A ne commencera à piloter l allocation d adresse qu une fois reçue le témoin pour le changement de clé de session. Puisque l adresse proposée est cryptée, le protocole permet d allouer et d échanger de façon sécurisée une nouvelle adresse pendant la réunion. Connectivité multicast Problème Le réseau Internet ne garantit pas que tout participant bénéficie du routage des adresses de multicast quel que soit son point d accès d un routage. Il n y a donc pas de garantie qu un message envoyé en multicast atteigne tous les participants. Dans ce cas, une solution doit être fournie pour détecter le problème et basculer automatiquement vers un mode point-à-point. De plus, la solution doit traiter une station de travail qui utilise une adresse IP allouée dynamiquement par exemple via DHCP [DRO 97]. Solution Le système détecte automatiquement si un participant n est pas accessible par multicast. Pour cela, chaque pair qui entre en réunion envoie un message au groupe des participants en incluant son adresse IP. Si deux pairs A et B arrivent à se joindre via le multicast, ils n ont pas besoin d utiliser l adresse IP reçue par courrier électronique. Sinon, A et B pourront communiquer directement en point-à-point grâce à l adresse IP reçue dans le courrier électronique. Puisque généralement un travailleur mobile peut recevoir du courrier électronique, il aura la possibilité de découvrir l adresse IP qui est allouée dynamiquement par un participant distant. 2.3.2.3 Implantation de la solution L implantation de la DBSM consiste en une librairie de répartition qui permet à des applications de réalité virtuelle hétérogènes de partager un arbre. Arbre partagé supportant les applications hétérogènes Chaque nœud de l arbre est un objet qui contient des données définissant le méta-objet et des données spécifiques à différents modules logiciels. Pour être plus concret, on peut imaginer qu une application héberge un module graphique (capable de faire un rendu 3D) et un module de simulation (qui permet de calculer des caractéristiques physiques telles qu un débit ou une pression). Dans ce cas, un objet comprendra trois niveaux d informations : 1) un niveau méta d un objet qui contient les données de répartition et de coopération, 2) un niveau graphique qui ajoute au méta-objet des données permettant le rendu graphique et 3) un niveau simulation qui ajoute des données pour le domaine physique simulé. 56

On voit qu un nœud de l arbre partagé devient un objet qui comprend différents types d informations intéressant les aspects coopération et les différents modules qui utilisent ce nœud. Un nœud est donc enrichi d informations spécifiques aux différents modules afin que ceux-ci ne traitent que les données qui les concernent. Par exemple, un simulateur d écoulement de fluide ne traitera que les informations (exemple : débit, pression, rugosité et géométrie) qui le concernent. De son côté, le module graphique traitera des informations de géométrie permettant un positionnement et un rendu 3D correct de l objet. Par exemple, un nœud peut correspondre à une pompe. Ce qui intéressera le simulateur sera la géométrie de l orifice de sortie, la courbe débit-pression de la pompe, etc. Ce qui intéressera la partie graphique sera la géométrie complète de la pompe (son volume et ses formes externes, la géométrie des différents composants internes de la pompe tels que la turbine ou le moteur). La figure 6 illustre deux applications A et B, issues de deux fournisseurs différents, qui ne sont pas prévues pour fonctionner ensemble. Ces applications peuvent être des outils autonomes qui n offrent aucune fonctionnalité de coopération. Grâce à l intégration de notre librairie de partage, ces deux applications vont cependant coopérer de façon transparente comme si les données partagées provenaient de leur propre environnement. L application A comprend un module d allocation spatiale des systèmes et de simulation d écoulement de fluides. L application B comprend un module de détection de collision et un simulateur électrique. La figure montre que l arbre partagé est projeté au niveau de chaque module de l application en un arbre de données que le module peut traiter. En effet, toutes les données de l arbre ne sont pas utiles pour un module, c est la librairie de partage qui assure la projection vers les modules de l application. Nous verrons ultérieurement comment est assurée cette projection est comment elle est rendue indépendante des outils sous-jacents (indépendance notamment vis à vis de l outil de rendu graphique). La figure illustre aussi une interaction en un nœud du module d allocation spatiale et le nœud correspondant dans le module distant de détection des interférences. L interaction peut correspondre par exemple à une modification par le module d allocation spatiale de la position 3D d un objet. Cette interaction est propagée automatiquement par la librairie au nœud correspondant dans la copie locale de l arbre partagé. Ce nœud local transmet l événement à la copie distante. Cette dernière met automatiquement à jour le nœud concerné dans le module de détection des interférences. Ainsi, le module de détection d interférence peut calculer les collisions avec l objet en mouvement comme si le déplacement était piloté localement au niveau de ce module. Une autre interaction est présentée entre le simulateur d écoulement de fluides et le simulateur électrique. Cette seconde interaction illustre que deux modules n ont pas besoin de partager tous leurs objets pour pouvoir coopérer. De plus, elle présente que cette technique de partage est un bon support pour faire communiquer des simulateurs qui ne sont pas fait pour dialoguer ensemble. L interaction présentée peut être la mise à jour d un attribut de pression qui est produit par le simulateur de fluide et consommé par le simulateur électrique. 57

A Module 3D (ex : allocation spatiale) B Module 3D (ex : détection interférences) Copie locale de l arbre partagé Copie locale de l arbre partagé Simulateur (ex : fluide) Simulateur (ex : électrique) Fig. 6 Interactions entre les modules de deux applications hétérogènes Librairie de coopération indépendante des outils de rendu graphique Nous présentons ici brièvement comment la librairie de coopération permet à deux applications hétérogènes, qui n utilisent pas les mêmes outils de rendu graphique, de coopérer. Bien que le principe soit présenté dans le cadre des modules 3D, il est extensible à des modules de simulation. Avant de décrire certains détails d architecture de la librairie de coopération, nous décrivons dans ce paragraphe le résultat d une intégration de la libraire de coopération de sous forme d une librairie de partage 3D. Cette librairie de partage 3D devient utilisable directement par les applications en masquant la nature de l outil de rendu graphique sous-jacent. La librairie de partage 3D fournie une classe appelée Node3D qui permet à une application de créer un arbre d objets au nouveau d un module. L interface C++ de cette classe est donnée ci-dessous. class Node3D : public NetworkNodeInterface { public: Node3D(int lib3d ); Node3D(Node3D *); Node3D(Node3D *, NetworkNodeInterface *); Node3D() {}; Node3D *addnode(string nodedata); Node3D *addnode(string nodedata, NetworkNodeInterface* obsappnode ); Node3D *addgroup(); Node3D *addseparator(); Node3D *addlight(); 58

Node3D *addcube(); Node3D *addsphere(); Node3D *addcylinder(); Node3D *addcone(); void deletenode(); void updatenode(string nodedata); void *getnode3d(); void setanglerotation(string angle); void setaxerotation(string axe); void setrotation(string axe, string angle); void setposition(string position); void setdimension(string dimension); void setdiffusecolor(string diffuse); void setspecularcolor(string specular); void settexture(string texture); string exportdata(); void display3d(); Node3D* createnode(string, string); void updatenode(string, string); ObserverAppliNode *observerappnode; protected: Node3D *createnode(string data, Node3D *father, NetworkNodeInterface* ); Node3D *createnode(node3d *father,string shape); Node3D *createnode(string data, Node3D *father); void removenode( Node3D * ); void update(); private: static int instanceexists; void setshape(string shape); AspectSlot *aspect; list<node3d *> childrennodelist; Node3D *father; void* subjectnode3d; Lib3D* usedlib3d; }; On trouve différentes méthodes dont des constructeurs, des méthodes pour ajouter des nœuds, des méthodes pour modifier les nœuds existants. Chaque nœud peut être projeté au travers le membre privé aspect. Un nœud maintient aussi des références vers le nœud père et les nœuds fils. Cette classe permet d envelopper (wrapper) les méthodes classiques du module graphique cible. On présente ici une enveloppe (wrapper) pour un module d assez bas niveau du type Open Inventor. Dans ce cadre, le wrapper présente une méthode display3d() pour réaliser le rendu graphique de l arbre ainsi créé. On peut envisager un wrapper pour une application comme CATIA, dans ce cas les objets enveloppés (wrappés) peuvent être d une toute autre nature (par exemple : une roue de voiture). Dans le cadre d une librairie cible du type Open Inventor, on trouve des méthodes telles que addcube(), addcylinder(),addcone() pour créer les objets élémentaires (cube, sphère, cylindre ou cône) dont a besoin l application. Le wrapper est donc adapté au besoin de l application (on pourrait ainsi définir une méthode addwheel() pour créer une roue de voiture). Un nœud possède une référence usedlib3d vers la libraire 3D cible. Cette librairie est chargée dynamiquement lorsque l application crée un nœud racine pour l arbre partagé. En 59

fait, le wrapper Node3D est lui-même indépendant de la librairie 3D cible. Pour cela, un mandataire target3d masque la librairie cible et fournit un symbole (ex : Cube) pour chaque type d objet que peut manipuler Node3D. Le mandataire target3d réalise l implantation concrète d un objet dont le symbole (ex : Cube) est défini. L exemple de code suivant montre comment l application utilise la librairie de partage 3D. L application crée un nœud racine en l associant à la librairie Open Inventor et en chargeant dynamiquement cette librairie. Ensuite, elle crée un cône et l attache à la racine de l arbre. Ensuite, l application crée une instance de la classe NetworkManager afin d entrer dans la réunion (dans cette exemple, la réunion est définie avec une adresse de multicast et un port par défaut). Enfin, l application crée une instance la classe Aggregation afin de partager les objets qu elle a ajoutés à sa racine locale. Cette classe effectue toutes les opérations nécessaires pour constituer la copie locale de l arbre partagé. Ensuite, on voit une modification setposition de la position du cône. Cet appel de méthode permet de projeter la mise à jour sur le nœud partagé et de propager ainsi l événement aux copies distantes. Si deux applications A et B sont lancées pour cette réunion, alors l arbre partagé va comporter deux cônes. Un cône étant crée par A et l autre par B. #include <stdlib.h> #include "Lib3D/lib3D.h" #include "node3d.h" #include "Network/networkManager.h" #include "Network/aggregation.h" int main(int argc, char argv[]) { } Node3D *myroot = new Node3D(Lib3D::INVENTOR); Node3D *mycone = myroot->addcone(); mycone1->setposition("10 10 0"); mycone1->setdiffusecolor("200 135 10"); mycone1->setdimension("10 10 10"); NetworkManager *net = NetworkManager::getInstance(); Aggregation *localcopy = Aggregation::getInstance(); myroot->display3d(); mycone1->setposition("10 10 0"); Design Patterns pour l intégration, la flexibilité et la réutilisation de la libraire coopérative Un des rôles de la librairie coopérative, hormis tous les services de coopération, est de découpler et dé-multiplexer les informations nécessaires aux différents les modules afin d assurer un échange transparent entre le module et la librairie de répartition. De plus, des techniques doivent être proposées pour faciliter l intégration de la librairie de coopération en une librairie directement exploitable par l application. En effet, le paragraphe précédent est un exemple d intégration de la librairie de coopération dans un wrapper 3D. 60

On peut aussi obtenir une intégration directe de la librairie de coopération dans une application sans passer par un wrapper 3D intermédiaire. Dans ce cas, les techniques que nous proposons basées sur les design patterns sont réutilisables. Elles servent à une intégration directe et évitent de trop modifier le code de l application existante. Afin d assurer le découplage entre les modules (coopération, 3D, simulation, etc ) et de simplifier l intégration de la librairie de coopération nous définissions une architecture logicielle en utilisant la méthode des schémas de conception, Design Patterns [GAMM 94]. Les solutions retenues améliorent l intégration, la réutilisation et l extensibilité de la librairie de coopération. Différents patterns ont été définis dont un pattern pour gérer une hiérarchie d objets et intégrer ces objets dans un module d application. L implantation de ces patterns repose sur le principe suivant. Une classe ObserverAppliNode a un rôle central. Elle réalise en effet la jonction entre les nœuds de l arbre partagé NetWorkNode et les nœuds applicatifs Node3D au moyen du pattern Categorized Observer [COS 2001] qui est une extension du pattern Observer [GAMM 94]. Dans cette architecture Node3D est observateur de ObserverAppliNode par l héritage de NetWorkNodeInterface mais également sujet de ObserverAppliNode par contenance. Ainsi, ObserverAppliNode, qui gère un nœud partagé, observe toute modification effectuée sur le nœud Node3D correspondant. Dans l autre sens, Node3D observe et répercute toute modification de ObserverAppliNode. Dans le sens application vers arbre partagé, un nœud Node3D notifie ainsi automatiquement d une modification à son homologue ObserverAppliNode dans l arbre partagé. Le nœud partagé propage alors l événement aux copies distantes. Dans le sens arbre partagé vers application, un nœud ObserverAppliNode qui reçoit un événement du réseau notifie automatiquement son homologue Node3D dans l arbre des objets d application. On a vu comment un mandataire target3d pouvait projeter l opération demandée sur la librairie 3D sous-jacente. Lorsque l on veut une intégration directe dans une application existante, le même principe est applicable. Un objet d application sera redéfini par une classe du type NodeAppli qui observera et sera sujet d un nœud ObserverAppliNode. Il suffira alors de transformer tous les appels aux objets d application, dans le code initial, par des appels à l objet NodeAppli. La classe NodeAppli doit mettre en œuvre le mandataire nécessaire. Ce mécanisme est intéressant car il évite de joncher le code de l application à des appels à la librairie de coopération, ce qui serait fastidieux, source d erreurs et ne permettrait pas la réutilisation d objets. Avec notre solution l application se contente de réutiliser des objets, écrits une fois pour toute, qui réalisent une projection bidirectionnelle et transparente avec l arbre partagé. La solution est extensible pour la simulation répartie. Dans ce cas, pour chaque simulateur un mandataire doit être écrit pour faire la projection. 61

2.3.3 Travaux comparables et discussion [ARI 99] propose un serveur pour gérer une scène 3D augmentée. Les objets 3D et des vidéos sont transmises en même temps. Par essence, cette solution est proche de MPEG-4 (Moving Picture Experts Group) [KOE 2001]. En effet, toutes les deux consistent en un serveur qui diffuse les objets de la scène 3D et la vidéo. Au contraire de [ARI 99], la solution MPEG-4 synchronise les différents flux et elle peut fonctionner sur des lignes moyen débit. Les environnements de travail coopératifs permettent de partager des applications et des données variées parmi un groupe de participants. D un côté, les outils de GroupWare tels que [GRE 98] et les environnements de partage Java [ABD 97] [KUH 98] [JSDT 99] [SAD 99] [SHI 98] permettent de partager des objets variés ou du texte simple [HAN 97]. Le principe est une distribution vers des répliques des événements, interactions et des objets. Ces solution utilisent un serveur central et des connexions TCP ou bien une diffusion fiable [LRMP 99] [HAN 97]. D un autre côté, les services de communication H.323 [ITU 2000] permettent de développer des outils de vidéo-conférence. L idée de base est d utiliser des connexions UDP et le protocole RTP pour transmettre les données vidéo ou audio. La sécurité est considérée pour les flux audio et vidéo au-dessus de UDP via le standard H.235 [ITU 98] qui nécessite des composants de sécurité additionnels tels que [TLS 99] [IPSec 98] ou bien elle permet de sécuriser un réunion au moyen de certificats X509. Cela impose donc que le déploiement d une architecture de sécurité spécifique ou bien l utilisation par les entités d application des certificats X509. Or le traitement des certificats X509 n est pas quelque chose d aisé notamment pour des connexions UDP. Une solution comme Microsoft NetMeeting repose sur l utilisation du standard H.323, elle permet ainsi de partager des documents ou fenêtre et de transmettre simultanément de la vidéo ou du son. Cette solution permet de partager toute application mono-utilisateur. Mais elle présente des problèmes de performance puisqu elle consiste à diffuser une fenêtre sur des connexions TCP. NetMeeting sécurise les flux TCP mais pas les flux UDP. Cela confirme la difficulté pour sécuriser les flux UDP. Selon un principe un peu similaire [MAL 97] permet la coopération via le partage d une fenêtre [ABD 94]. La principale différence avec NetMeeting est que leur solution repose sur un protocole à diffusion ordonnée [WHE 94]. Cela ce traduit pas une charge réseau importante au niveau du protocole à diffusion puisque l on transmet la fenêtre de rendu. D un côté, les techniques de diffusion fiable [LRMP 99][HAN 97] ne garantissent pas la progression du travail. D un autre côté, les solutions basées sur les protocoles ordonnés sérialisent toutes les opérations ce qui limite la concurrence. De plus une solution basée sur l ordonnancement n est applicable qu en réunion. Dès lors qu il existe des phases déconnectées ou les copies évoluent de façon indépendante, il est difficile d atteindre automatiquement un état global cohérent et les techniques d ordonnancement ne peuvent pas s appliquer pour réaliser cette automatisation. Pour ce qui est des environnements de réalité virtuelle répartie, ils proposent essentiellement de limiter le trafic réseau lié à un trop grand nombre d objets mobiles. Ces solutions ne supporte pas le travail simultané [BAR 96] ou ne garantissent pas la progression du travail [IEEEa 2000] [BRO 98] [HAG 96]. Par ailleurs, elles nécessitent souvent l utilisation d un serveur [BRO 98] [HAG 96] notamment pour gérer les participants et la persistance. Si certaines solutions comme [HAG 96] ont essayé à l origine d utiliser des techniques de 62

diffusion ordonnée pour résoudre les problèmes d incohérence, elles ont abandonné par la suite ce principe pour des problèmes de performances notamment. Actuellement il n y a donc quasiment pas de solution complète pour la conception coopérative en environnement de réalité virtuelle. Soit ce sont des solutions, basées sur un serveur, qui ne sont pas facilement extensibles ni applicables pour une entreprise étendue. Aucune ne permet de répartir et de réunifier un arbre d objets entre des concepteurs mobiles qui alternent des phases connectées et déconnectées. Par ailleurs, certaines solutions ne garantissent pas la progression du travail ou ne supporte pas le travail simultanée. D un autre côté, les techniques d ordonnancement si elles sont applicables pour la réunion, ne permettent pas de garantir la cohérence des copies déconnectées. Ces solutions vont limiter la concurrence et introduire des surcoûts. De plus, la mise en œuvre et le déploiement des technique de diffusion ordonnée posent des problème pratiques réels qui sont mal traités actuellement comme nous l expliquerons dans la section suivante sur la simulation répartie. Des techniques [LUB 2000] sont proposées dans le cadre des bases de données, pour essayer d obtenir automatiquement une unification cohérente de versions différentes. Cependant, ces techniques ne sont pas facilement applicables. D un côté, les concepteurs veulent très souvent pouvoir réaliser les opérations de conciliation des travaux de façon coopérative. Ils ne souhaitent donc pas qu un système fasse la conciliation pour eux. D un autre côté, des techniques de conciliation automatiques du type base de données, sont très complexes à mettre en œuvre car elles doivent reproduire l intelligence et la capacité d analyse des concepteurs. Enfin, la complexité des techniques de conciliation nécessaires est augmentée par l aspect géométrique et plus largement par l objectif de respect des exigences fonctionnelles. Par exemple, concilier des versions devra consister à détecter toutes les collisions et toutes les interférences entre les éléments du prototype et à trouver automatiquement le meilleur compromis pour garantir au mieux les contraintes. Dans le cadre général des systèmes répartis, il a été défini des techniques permettant d effectuer des opérations sur des copies déconnectées [LU 95]. Les solutions montrent que les conflits entre les versions déconnectées peuvent être détectés mais que la réparation pour concilier ces versions doit être manuelle. En effet, on retombe sur le problème qu une réconciliation automatique peut finalement ne pas respecter les souhaits des utilisateurs. Contrairement aux autres propositions, notre solution propose une technique de répartition et de réunification d un arbre d objets déconnectés en préservant la sémantique fonctionnelle du prototype. Elle ne vise pas, comme [LUB 2000], à garantir la conciliation automatique de versions. Elle offre cependant des techniques de bases supportant la conciliation coopérative. Premièrement, elle autorise la modification interactive du modèle partagé. Deuxièmement, elle permet d introduire dans la réunion différentes alternatives, préparées à l avance, qui permettent d examiner rapidement un grand nombre de possibilités et qui servent de base à la définition coopérative du prototype. Les services de coopération ne requièrent aucune technique de diffusion fiable ou d ordonnancement élaboré dont on a vu qu elles n étaient pas facilement applicables dans un contexte mobile et posaient des problèmes pratiques. Pour des cas complexes tels que des incohérences dues à des traitements concurrents, notre solution permet de mettre en œuvre des protocoles sociaux comme par exemple demander à un seul participant d exécuter toutes les opérations. Elle peut aussi imposer à un pair de traiter, au moins temporairement, tous les événements, ce qui réalisera un ordonnancement 63

des opérations puisque ce pair deviendra un séquenceur qui garantit un ordre causal et total [TOI 92]. La solution propose une architecture pair-à-pair (peer-to-peer). Elle est entièrement répartie et repose essentiellement sur un principe best-effort ce qui garantie les performances et peut permettre des usages plus larges comme pour les jeux vidéos. Le travail simultané et la progression cohérente sont garantis de façon complètement répartie par le propriétaire de chaque nœud. Le contrôle de la progression est réalisé uniquement lorsque c est souhaitable et pas de façon continue. Selon la classification des propriétés de cohérence des données réparties que l on trouve dans [GRE 94], la solution fournie une cohérence séquentielle. Cependant, l implantation est ici originale car d une part un pair n a pas besoin d observer toute la séquence et de plus l utilisateur lorsqu il récupère le dernier état de l objet concerné peut annuler son interaction (sa tentative d écriture). La solution présente aussi l intérêt de bien résister aux situations de pannes. La panne d un pair n empêche absolument pas les autres participants de travailler car cela correspond à un départ du membre fautif. Hors, le membre fautif pourra revenir à tout moment dans la réunion puisque par essence la solution est faite pour réunifier automatiquement les phases de déconnexion. Par ailleurs, la solution ne requiert aucune qualité de service particulière de la part du réseau sous-jacente. Elle est rendue efficace grâce à l utilisation du multicast et à une gestion de la fraîcheur des objets. Contrairement aux autres solutions, nous proposons une technique pour résoudre le problème de la connectivité multicast et des adresses dynamiques. D un point de vue graphique et intégration, la solution est indépendante de la librairie 3D sous-jacente et elle permet d intégrer différents modules (graphique, simulation ou autre). Elle permet à des applications hétérogènes de pouvoir communiquer en accédant à des données qui peuvent être projetées automatiquement dans le format qui les intéresse. Elle se distingue des solutions telles que [ZEL 2000] par le fait quelle permet d échanger des données ayant une sémantique d assez haut niveau, ce qui rend la solution indépendante des techniques graphiques sous-jacentes et limite le trafic réseau. Enfin, d un point de vue de la sécurité, une solution est définie qui évite aux pairs de traiter des certificats X509 et qui permet d utiliser les outils disponibles pour le courrier électronique afin de distribuer une clé de chiffrement. Grâce à une méthode simple mais malgré tout suffisamment sûr, la solution peut être utilisée sur l Internet le plus standard. 2.4 Simulation répartie La solution DBSM et les techniques de simulation répartie relèvent du même besoin de prototypage virtuel coopératif. En effet, le partage d un modèle virtuel et la coopération pour la conception de ce modèle constitue une première phase de prototypage. Ensuite, il faut pouvoir venir relier des simulateurs à ce modèle afin de pouvoir vérifier des caractéristiques physiques (de débit et de pression par exemple). La possibilité de pouvoir mettre en place des simulateurs de façon coopérative sur ce modèle est supportée par DBSM comme nous l avons vu préalablement. En effet, DBSM permet de partager un méta-modèle de prototype qui peut être enrichi par les composants (graphiques, simulateurs ou autre) qui traitent ce méta-modèle. Cette aptitude est déjà intéressante en soit car elle permet de faire une simulation répartie où les simulateurs ne sont pas parfaitement synchronisés les uns aux autres mais traitent un même modèle partagé. Dans cette section, nous allons présenter comment ces simulateurs peuvent être synchronisés pour garantir que la simulation reste cohérente et soit reproductible. 64

Le domaine de la simulation est extrêmement vaste (il va de la simulation de systèmes continus à la simulation de systèmes discrets) et complexe dès lors que les temps de simulation doivent être réels ou minimisés le plus possible. Ici, nous ne visons pas un objectif de simulation temps réel ni même à minimiser les temps de simulation. Pour une simulation temps réel, DBSM peut être utilisée afin d avoir un échange rapide entre les simulateurs. En fait, notre travail vise à relier des simulateurs sur étagère les uns aux autres. Ces simulateurs ne sont pas prévus pour fonctionner ensemble et n ont pas forcément des temps de traitement comparables. De plus, ils n offrent souvent aucune possibilité d accéder à leur modèle interne ou de synchroniser les boucles de calcul. Ce sont donc le plus souvent des simulateurs qui prennent des informations en entrée et produisent (dans un temps qui n est pas maîtrisable) des résultats en sortie. Cela signifie qu il serait illusoire de vouloir les synchroniser finement, en contrôlant leurs exécutions internes, pour réduire les temps de calcul. Donc la seule possibilité est de leur faire s échanger leurs informations de sortie et d entrée. La première possibilité est selon le mode best-effort comme proposé dans DBSM. La seconde, que nous étudions ici, est avec un objectif d une simulation qui soit correcte et reproductible. On se place alors typiquement dans le cadre d un simulateur qui produit une information discrète en sortie et cette information est consommée comme entrée par un autre simulateur. 2.4.1 Etat de l art 2.4.1.1 Simulation à évènements discrets Si dans certains cas ces techniques peuvent être utilisées pour réduire les temps de calcul, elles s orientent maintenant vers l exécution de modèle de grande taille nécessitant beaucoup de mémoire et d entités d exécution. Ainsi en considérant un "modèle objet" où chaque entité (processus) simule un ou plusieurs objets du monde réel, il devient possible de simuler de très grands modèles de façon répartie sur différentes machines. L accent n est plus alors mis sur la diminution des temps d exécution mais plutôt sur la nécessité de représenter le modèle sous forme d objets se synchronisant au moyen d échange de messages. Protocoles de synchronisation Ces environnements implantent essentiellement deux types de techniques de synchronisation qui sont appelées conservatrices ou optimistes. Pour ces deux techniques on retrouve le même concept de processus logique (LP: logical process) qui simule un ou plusieurs objets du monde réel. Les processus communiquent en échangeant des événements. Chaque événement est transmis au moyen d un message qui porte une estampille correspondant à sa date logique d apparition. Les dates logiques sont gérées par l environnement. Cependant le programmeur peut être amené à les connaître ou à les manipuler. Il peut donc émettre des événements dans un certain ordre et leurs attribuer des dates de réception inverses de l ordre d émission afin de forcer un ordre de traitement différent de l ordre d émission. 65

Afin de préserver l exactitude, chaque processus doit exécuter les événements selon un ordre logique. Cela permet de respecter les relations de cause à effet entre les événements (relation de causalité). La méthode repose sur l utilisation de dates logiques. Un message émis porte une date logique. La réception d un message fait progresser la date logique locale lorsque le message reçu porte une date supérieure à la date courante. L environnement réordonne les événements reçus selon leurs dates logiques afin de les livrer aux processus dans l ordre logique préservant ainsi les relations de causalité. Exemple de préservation des dates logiques : Sur la figure 7, l événement A, émis par le processus P1, porte la date logique 1. L événement B émis ensuite porte la date logique 2. Le processus P2 reçoit l événement B avant d émettre l événement C. Ce dernier est estampillé 3 c est-à-dire avec une date logique supérieure à celle de B. L environnement de simulation sur lequel s exécute P3 réordonne l événement C afin de le livrer au processus P3 après l événement A. Ainsi, P3 reçoit l événement A puis l événement C bien que l environnement sous-jacent ait en fait reçu C avant A du fait de délais de transmission différents. L événement A précède causalement B et B précède causalement C. Par transitivité A précède causalement C, A!C. Il est important que l environnement de simulation respecte la relation de causalité entre A et C, ce qu il fait ici correctement. Le non-respect pourrait conduire P3 a un traitement erroné. P1 A 1 B 2 P2 C 3 P3 Fig. 7 Ordonnancement logique des événements Protocole utilisant une méthode conservatrice Une première famille de protocole utilisent un algorithme conservateur [MIS 86] pour satisfaire les relations causales A!C. Chaque simulateur traite un événement seulement lorsqu'il est sûr qu'aucun autre événement avec une estampille plus petite n'arrivera des autres simulateurs. Afin d'éviter les interblocages, différentes méthodes sont employées par les environnements. La solution la plus courante consiste à utiliser des messages vides (ne contenant aucun événement) afin d'assurer la progression des simulateurs. Ces messages vides contiennent les dates locales courantes. Ainsi, une fois qu'un simulateur a au moins un message de chacun des autres simulateurs (dont des messages vides), il peut réordonner les événements afin de les livrer au processus en attente selon l'ordre définis par les estampilles. A partir de l'exemple précédant, on peut faire apparaître les messages vides. La figure 8 présente un scénario d'échange permettant la livraison des événements A, B et C. P3 émet un message vide avec l'estampille 1. Ce message vide permet au processus P2 de livrer l'événement B puisqu'il sait que P3 n'a pas d'événement inférieur ou égal à 1. Donc 66

l'événement pouvant être livré porte le numéro 2. L'événement B est donc livré. Cependant, on voit que le nombre de messages vides nécessaires peut être important. empty P1 A B 2 1 2 P2 C 3 P3 1 empty Afin d'éviter de générer trop de messages vides et de diminuer ainsi le temps d'exécution nécessaire pour effectuer la simulation, chaque simulateur peut prédire une date logique de d'avancement. L'avancement Aij pour un lien entre deux processus i et j correspond à la date d'avancement prédite par i à partir de laquelle i pourra générer un nouvel événement. Ainsi, j a la garantie de ne pas voir arriver d'événements avec une date inférieure ou égale à Aij. Fig. 8 Protocoles conservateurs utilisant des messages vides Supposons que Pi est à la date local Li et qu'aucun événement ne sera généré avant La alors il envoie un message vide à Pj signalant un avancement à la date Aij=Li+La. Ainsi, tout nouveau message généré aura une date supérieure ou égale à Aij. Ainsi, j peut avancer dans la simulation sans attendre d'événement de la part de Pi avant la date Aij. En reprenant l'exemple précédant, le processus P3 peut par exemple envoyé un message vide en avançant sa date à 5. Le processus P2 peut ainsi avancer jusqu'à la date 5 sans attendre d'événement de la part de P3. Cela évite à P3 d'envoyer des messages vides portant les numéros 2, 3 et 4. Par exemple, l'environnement PARSEC [BAG 97] implante une technique conservatrice. Il est largement utilisé. Il fournit un langage structuré et requière la bibliothèque de communication MPI [MPI 94] afin que les processus puissent s'exécuter sur des processeurs différents. Le compilateur est en fait un pré-compilateur C. PARSEC permet au programmeur de positionner la valeur d'avancement, au moyen de la fonction setlookahead(), afin que celle-ci soit transmise aux autres processus. Le code suivant illustre un processus qui attend une requête (receive()), avance ensuite sa date locale de 5 unités pour simuler le temps de traitement de la requête et envoie une réponse (send). Ainsi, le programmeur peut annoncer avant d'attendre la requête qu'il n'enverra pas d'événement avant 5 unités de temps (setlookahead()). setlookahead(5, CLOCKTYPE_MAX); receive (Request request) { hold(5); send reply to request.requester; } 67

Technique optimiste Au contraire, une solution optimiste [JEF 85] tolère que les événements soient livrés sans respecter les relations de causalité. Chaque processus va pouvoir ainsi traiter les événements dès qu'ils arrivent sans attendre qu'ils soient réordonnés. Si un événement arrive avec une date inférieure à celles des événements traités, le processus doit corriger cette erreur en défaisant les événements en avance qui ont été traités de façon optimiste. Ce traitement est appelé retour arrière (roll-back) et le message qui déclenche le retour est appelé retardataire (straggler). Le retour en arrière consiste à retourner à l'état sauvegardé qui est antérieur à la date du retardataire. Pour être capable d'effectuer un retour en arrière, chaque simulateur doit conserver un historique des opérations effectuées. Pour cela, il conserve la liste des événements en entrée qui ont été traités, la liste des événements en sortie et une liste donnant l'état associé à chaque événement traité. Lorsqu'un événement retardataire arrive, le simulateur positionne sa date locale en arrière sur celle de l'événement reçu. Il revient à l'état correspondant au moyen de la liste des états. Enfin, il doit envoyer des messages d'annulation pour tous les événements de la liste de sortie qui possède une date supérieure au retour arrière. Un message d'annulation reçu par un simulateur peut à son tour entraîner des annulations. La cascade d'annulation s'arrête en un temps fini. La technique qui consiste à envoyer immédiatement les messages est dite annulation agressive (aggressive cancellation). Une technique d'annulation paresseuse (lazy cancellation) évite de transmettre les annulations immédiatement. Elle attend que la nouvelle exécution ait lieu pour vérifier pour chaque message m(t) à annuler si le nouveau message m'(t) pour la date t est identique (m(t)=m'(t)). Dans ce cas, il n'est pas nécessaire d'envoyer le message d'annulation. Cependant cette méthode présente aussi des inconvénients puisqu elle retarde éventuellement d'autant l'instant où l'annulation est effectuée. Différentes variantes de la méthode d'annulation sont proposées dans la littérature. Certaines permettant notamment d'éviter des annulations en cascades. Les méthodes optimistes sont clairement plus complexes à mettre en œuvre et n'apportent pas forcément un gain en performance. L environnement WARPED [RAD 96] de l'université de Cincinnati dans l'ohio, implante des techniques optimistes. Du fait de la complexité d usage, il est moins utilisé que PARSEC. Il fournit une bibliothèque de classes C++ et requière aussi la bibliothèque de communication MPI pour une exécution parallèle. High Level Architecture (HLA) HLA implante en fait des techniques de simulation à événements discrets. Elle permet à des simulateurs de s échanger des événements en respectant leurs dates logiques. Elle offre à les deux méthodes conservatrice et optimiste. Par défaut, c est la méthode conservatrice qui est retenue. HLA supporte plusieurs types de simulateurs vis à vis de la progression logique : 68

- Les simulateurs à temps contraint qui sont régulés par les événements logiques produits par les simulateurs distants. - Les simulateurs régulateurs qui produisent des événements logiques pour piloter l avance des simulateurs distants. - Les simulateurs qui sont à la fois régulateurs et contraints. - Les simulateurs qui ne sont ni régulés ni contraints. Enfin pour une même simulation, la norme considère différentes façons de traiter les événements par les simulateurs : - Les simulateurs avec une cadence temporelle qui demandent à avancer jusqu à une certaine date logique. - Les simulateurs qui progresse temporellement selon les événements logiques qu ils reçoivent. Fédéré Update Attribute Values (TS=40) Time Advance Request (40) Reflect Attribute Value (TS=39) Receive Interaction (40) Time Advance Grant RTI 35 39 40 Temps logique Fig. 9 Scénario d un simulateur avec une cadence temporelle La figure 9 présente un scénario typique avec des interactions entre un simulateur avec une cadence temporelle et l environnement d exécution HLA (Run-Time Infrastructure). La durée d'une étape est de 5 unités de temps logique et l'anticipation du fédéré est aussi de 5 unités de temps logique. Tous les messages sont ordonnés logiquement c est-à-dire de type Time Stamp Order. Le schéma présente les invocations de services entre le simulateur et RTI ainsi que les variables de temps intéressantes. Le scénario commence à la date 35 qui correspond à l'étape précédente. On voit en effet que le fédéré calcule son nouvel état à la date 35 et produit des sorties pour la future étape 40 en invoquant UpdateAttributesValues avec la date 40. Ensuite, il commence la nouvelle étape en invoquant TimeAdvanceGrant. Cette requête signale à RTI de livrer au fédéré tous les messages avec une date 40 ou moindre. Une mise à jour d'attribut ReflectAttribute avec la date 39 et une interaction ReceiveInteraction avec la date 40 sont livrées. RTI doit attendre avant de livrer ces messages d'être sûr qu'aucun autre message avec une date inférieure ne sera reçu. Ensuite, il indique qu'il n'y a plus aucun message avec une date inférieure ou égale à 40 et termine la requête de progression avec le service TimeAdvanceGrant. Le second mode de progression temporelle est somme toute assez similaire. En effet, il consiste pour le simulateur à appeler une méthode NextEventRequest plutôt que TimeAdvanceGrant. Mais le principe reste le même. Le simulateur reçoit tous les événements jusqu à la date logique demandée. 69

Usage pratique L usage de ces techniques n est pas sans poser quelques difficultés dans le contexte qui nous concerne. D un côté, les simulateurs doivent être capable d annoncer leurs progressions logiques (lookahead). Dans le cas d un simulateur sur étagère, un wrapper doit recevoir les sorties du simulateur et les transmettre via les services de communication en temps logique. Hors ce wrapper ne peut généralement pas accéder au pas de progression temporelle interne au simulateur. Il lui est donc difficile de faire une annonce correcte. De plus l attribution des dates logiques par l application comme le propose l interface HLA pose d énormes difficultés. En effet, de nombreux simulateurs n ont pas une progression temporelle mais événementielle, il est donc difficile d attribuer des dates logiques correctes aux événements. Même si l on peut le faire de façon cohérente pour un simulateur donné, il est extrêmement difficile d attribuer des dates cohérentes pour l ensemble des simulateurs impliqués dans le système réparti. Ainsi, les tentatives [SCHUL 99] qui existent pour intégrer des simulateurs sur étagère montrent toutes des difficultés pour que la simulation répartie soit correcte et reproductible. En effet, ces simulateurs n ont pas les mêmes modes de fonctionnement et cette hétérogénéité rend difficile l attribution de dates logiques aux événements produits. En pratique, il est donc difficile en utilisant des dates logiques de respecter la causalité des traitements et de garantir un bon séquencement des opérations. Les expériences menées montrent que bien souvent le but n est pas atteint. 2.4.1.2 Systèmes à diffusion ordonnée Objectifs Les services de communication ordonnés ont été construits pour permettre la construction de systèmes répartis fournissant des propriétés de cohérence et de tolérance aux pannes. Ils ont trouvé plusieurs usages dans différents domaines de l informatique (contrôle de procédés, bases de données, systèmes tolérants les pannes). L utilisation de ces systèmes pour la simulation distribuée est évoquée dans la norme HLA. Mais ces systèmes n ont pas été retenus car historiquement les concepteurs de la norme HLA sont issus des systèmes à événements discrets. Nous verrons cependant qu ils peuvent fournir une alternative intéressante dans le cas d intégration de simulateurs sur étagère. Propriétés d ordre possibles Les propriétés d ordre sont intéressantes lorsqu il existe plusieurs destinataires d un même message. C est pourquoi on trouve les termes de communication vers un groupe ou de diffusion d un message vers un groupe. Il peut en fait exister autant de groupes que de messages émis. Pour deux messages donnés M et M, ce qui compte c est l ordre observé par les membres des deux groupes de destination autrement dit l intersection de ces deux groupes G(M) G(M'). Nous notons E X (M) et D Y (M) des événements qui apparaissent sur les entités d'application x et y. E X (M) est l'émission du 70

message M par l'entité d'application x. D Y (M) est la réception par l'entité y G(M) du message M. Nous notons la relation "apparaît avant" (happened before relation) qui existe entre les événements. Lorsque tous les membres de l intersection G(M) G(M') reçoivent les deux messages dans le même ordre, on dit que les deux messages sont livrés de façon ordonnée (délivrance ordonnée ou ordered delivery) : une livraison ordonnée peut se définir de la façon suivante, M do M' z G(M) G(M'), D Z (M) D Z (M'). Généralement les auteurs de système de communication ordonnés considèrent trois types d ordonnancement des messages, ordre local, ordre causal et ordre total. Ordre local Lorsque le système garantit une livraison selon un ordre local, deux messages émis par une entité d application sont livrés selon l ordre d émission : M l M' M do M'. Cette propriété correspond à la classique notion de livraison en séquence qu on trouve dans les communications fiables. Il s agit de respecter des relations locales l à une entité émettrice qui correspondent à la séquence d envoie des messages. Ordre causal On peut donner une définition de la relation causale entre deux messages [LAM 78] comme étant la fermeture transitive de la relation locale l et d une relation de causalité directe dc. M c M' [ M 0 =M,, M β+1, β 0]: M q-1 l M q M q-1 dc M q Cette relation causale définit par Lamport correspond à une relation de causalité perceptible au niveau du système de communication. Lorsque le système garantit une livraison selon un ordre causal les messages sont livrés selon les relations causales qu ils présentent : M c M' M do M' Sur la figure 10, M précède localement M' car x émet M avant M'. M' précède M'' selon la relation de causalité directe car y reçoit M' avant d'émettre M''. Donc par transitivité, M précède causalement M''. Comme la diffusion garantit un ordre causal, z reçoit M avant M''. Si M'' arrive sur le réseau avant M, les deux messages vont être réordonner afin de respecter la relation causale. E X (M) E X (M ') M l M' X Y D Y (M ') E Y (M '') M' dc M'' M c M'' Z D Z (M ) D Z (M '') Fig. 10 Ordre causal M do M'' Ordre total Un protocole qui livre tout couple de messages dans le même ordre à tous les destinataires, garantit un ordre total selon l'appellation classique : M, M', M M', M do M' M' do M 71

Il est communément admis qu'un ordre total ne satisfait pas les relations causales. La figure 11 illustre un protocole qui garantit un ordre total puisque toutes les entités d'application reçoivent les messages dans le même ordre. Cependant, la relation causale n'est pas respectée. Donc il est classiquement connu qu'un ordre total n'est pas causal. X M M' Y M'' M c M'' W M'' do M Z Fig. 11 Ordre total Propositions existantes Nous considérons les techniques qui sont intéressantes dans le cadre de la simulation répartie et permettent de garantir un ordre causal et total. De façon classique, pour obtenir un ordre causal et total, deux couches de communication sont nécessaires. L'ordre total est construit en utilisant les services de communication causale. La couche causale nécessite de transmettre une histoire causale qui peut être grande spécialement lorsque les groupes sont quelconques et peuvent s'intersecter. La construction de l'ordre total n'est pas simplifiée par la couche causale. [MOS 96] [BIRM 91] [REN 95] [AMIR 92] [MIS 93] [MAL 96] utilisent cette méthode. Ces systèmes permettent différentes qualités d'ordre. Certaines améliorations [HULE 96] [BAL 97] permettent de réduire la taille de l'histoire causale transmise dans les messages. Certains protocoles [VER 89] [MOS 96] évitent la construction d'un ordre causal dans le cas particulier de la diffusion vers un seul groupe (broadcast) correspondant à toutes les entités (tout le monde). Un résultat général que nous avons établi dans [TOI 92] prouve le caractère causal de tous les protocoles de type broadcast qui construisent un ordre total et local. Dans le cas général de la diffusion vers des groupes différents (multicast), il est plus difficile d'éviter la construction d'un ordre causal. Actuellement, la plupart de ces protocoles utilisent une structuration en arbre. Ils cherchent à limiter les surcoûts engendrés par l'ordre causal. En général, on trouve un ordre causal réalisé dans un domaine de diffusion [HUL 96] [MOS 96] [BAL 97]. Le message doit ensuite être ordonné causalement vis à vis des autres domaines. Enfin, un ordre total doit être construit en demandant un numéro de séquence à la racine de l'arbre [HUL 96] ou en attendant des messages des autres domaines [MOS 96] pour ordonner les messages concurrents. Donc, on trouve deux voir trois niveaux [MOS 96] de réordonnancement des messages. Chacune de ces couches introduit des attentes pour réordonner les messages et les temps de livraison se trouvent allongés d'autant. Donc en pratique aucune de ces solutions n évite la construction d un protocole pour garantir un ordre causal dans le cas de groupes qui présentent des intersections quelconques. 72

2.4.2 La solution CTOP Cette solution repose sur un ensemble de résultats formels que nous avons établis. Pour cela nous définissons de nouvelles propriétés d ordre et nous décrivons les résultats formels issus de ces propriétés. Ensuite nous présentons la mise en œuvre de la solution CTOP qui repose sur un de nos résultats. 2.4.2.1 Résultats formels obtenus Notions de base Nous distinguons les entités d'application des entités de protocoles. Une entité d'application correspond typiquement à un processus système qui utilise les services de diffusion vers des groupes. Tandis qu'une entité de protocole correspond à un processus système qui réalise le service de diffusion pour le compte d'une ou plusieurs entités d'application. Groupe: une entité d'application envoie un message vers un sous-ensemble d'entités d'application que l'on appelle le groupe et qui est noté G(M). Un groupe correspond à la notion classique sur l'internet de multicast. Pour nous un groupe est désigné par un nom textuel (ex: groupespécificationaérodynamisme). Groupe d'adressage: pour atteindre le groupe G(M) le message M est envoyé sur le réseau à destination d'un groupe d'entités de protocole noté A(G(M)). A(G(M)) correspond à l'ensemble des processus système qui vont traiter le message pour le livrer aux entités d'application correspondantes. Typiquement, une entité de protocole j A(G(M)) réordonne les messages avant de les livrer au destinataire y G(M). Nouvelles propriétés d'ordre Différentes propriétés de livraison ordonnée sont définies en utilisant cinq relations entre les messages: locale, causale directe, causal, identifiable ainsi qu'une relation de livraison ordonnée. La plupart de ces définitions utilisent la relation entre les événements "apparaît avant" (happened before relation) notée. Relation d'identifiants Cette notion a été définie initialement dans [TOI 93]. Selon le mode de fonctionnement du système, nous pouvons définir une relation id qui attribue à chaque message un identifiant id(m) pris dans un espace Id. Id est muni d'une relation < id telle que id est une relation d'ordre sur l'espace Id ( id est réflexive, antisymétrique et transitive). La relation d'identifiants id (non réflexive, non symétrique, transitive) est définie formellement de la façon suivante. M id M' [M M' id(m) id id(m')] Ordre identifiable 73

Les auteurs de système à diffusion ou plus largement les publications concernant les propriétés d'ordre n'utilisent généralement pas cette notion. Elle a été définie initialement dans [TOI 93]. Avec un protocole qui garantit l'ordre identifiable, les messages sont livrés par les entités de protocoles selon leurs identifiants. M id M' M do M' Plusieurs remarques ou résultats s'imposent: - un ordre identifiable est un ordre total, (M id M' M do M') ( M, M', M M', M do M' M' do M). - à l'inverse, un ordre total n'entraîne pas un ordre identifiable. - les identifiants n'ont pas besoins d'être calculés, connus ou maintenus par le protocole. Si l'on sait montrer que le système produit un ordre identifiable c'est suffisant pour les résultats que nous avons établis. Cependant, le système peut maintenir directement des identifiants qui respectent notre définition, le système fournit alors l'ordre identifiable par définition. - on peut remarquer que les identifiants n'ont pas besoin d'être uniques. C'est-à-dire que deux messages différents peuvent avoir le même identifiant (c'est le cas des messages pour lesquels A(G(M)) A(G(M'))= ). Ordre numérotable Cet ordre défini initialement dans [TOI 93] est un cas particulier de l'ordre identifiable. Dans ce cas, l espace des identifiants est tout simplement l'ensemble des entiers. Chaque message M se voit alors attribuer un entier n(m). M n M' M do M' Ordre identifiable satisfaisant une autre relation Un ordre identifiable respecte une autre relation R si M R M' M id M'. Cette définition est utilisée ensuite lorsque l'on considère un ordre identifiable qui satisfait M l M' ou M dc M'. Par exemple, lorsque M précède localement M' (M l M') alors l'identifiant de M est inférieur ou égal à celui de M' (M id M'). Résultats formels Les résultats suivants sont valables pour le cas général de diffusion vers des groupes (multicast). Les résultats reposent sur un théorème principal et des théorèmes pour des cas particuliers. Ici, nous ne donnons pas les preuves. Le lecteur peut les consulter dans [TOI 93] ou [TOI 99]. Résultat principal Théorème 1: un ordre identifiable qui satisfait à la fois les relations locales et causales directes fournit un ordre causal et total. [(M id M' M do M') (M l M' M dc M' M id M')] ( M c M' M do M') ( M, M', M M', M do M' M' do M) 74

En fait, le point important est la propriété de transitivité de id qui assure la fermeture transitive de l et dc. En pratique, un protocole qui respecte ce résultat n'a pas à transporter la fermeture transitive pour préserver les relations causales c. En pratique, dans [TOI 92] on trouve un protocole centralisé qui utilise ce résultat. Les identifiants sont tout simplement des numéros attribués selon l'ordre d'arrivé sur le serveur des messages à diffuser. C'est le cas d'un protocole qui maintient directement des identifiants. Dans ce cas, on montre que la complexité en quantité d'information transportée dans les messages est en O(n) au lieu de O(n 2 ) avec les solutions classiques. Résultat pour l'envoi à soi-même Nous considérons le cas où une entité d'application, qui émet un message vers un groupe G(M) appartient obligatoirement à G(M), c'est-à-dire que l'entité s'envoie le message à ellemême. x, E X (M) x G(M) Théorème 2: un ordre identifiable et local avec un envoi à soi-même fournit un ordre causal et total. [(M id M' M do M') (M l M' M do M') ( E X (M) x G(M)] ( M c M' M do M') ( M, M', M M', M do M' M' do M) Nous avons montré dans [TOI 93] qu'un système de diffusion arborescent fournit un ordre identifiable. De plus, s'il garantit un ordre local et fait de l'envoi à soi-même alors il garantit un ordre causal et total. S'il ne respecte pas une de ces conditions alors il n'est pas causal. Nous allons donner un contre exemple qui montre qu'en l'absence d'envoi à soi-même, une diffusion qui parcourt un arbre ne peut être causal. Sur la figure 12, on voit un message M émis par un processus du site S6 à destination de G(M)={S7,S4}. Le processus du site S7 reçoit M (la transmission de M est représentée par une flèche pleine) avant d'émettre M' (la transmission de M' est représentée par une flèche en pointillée), donc M dc M'. Or rien n'empêche le message M' d'arriver avant M sur le site S2 qui diffuse alors M' suivi de M. S2 attribue donc un numéro de séquence à M' plus petit que le numéro de séquence de M. Le site S4 réordonne les deux messages selon le numéro attribué par S2. Le processus du site S4 reçoit alors M' avant M, M' do M. Si ce sont les entités de protocole qui font de l'adressage à soi-même (plutôt que les entités d'application qui font de l'envoi à soi-même), le problème est identique. Nous ne détaillerons pas cet aspect. 75

S1 Légende: M Transmission de M: Transmission de M': S3 S2 M M' M S7 M dc M' S6 S5 S4 M' do M Fig. 12 Ordre identifiable et local sans envoi à soi-même n'est pas causal D'autres résultats ont été établis. Notamment, un résultat établi préalablement [TOI 92] prouve le caractère causal de la plupart des protocoles en diffusion à tout le monde (broadcast) qui fournissent un ordre total dans la mesure où ces protocoles garantissent aussi généralement l'ordre local c'est à dire la livraison en séquence. Ainsi, nous prouvons le caractère causal de [CHAN 84] et [KAA 89]. Nous décrirons par la suite des utilisations, que nous avons fait de ce résultat, dans le cadre des applications de contrôle de procédés. 2.4.2.2 Description de la solution CTOP Principe CTOP est un protocole qui fait une utilisation directe du théorème 2. Il peut être déployé sur l'internet. Une entité d application réalise une édition de lien avec la librairie CTOP. Via cette librairie chaque entité d application accède aux services CTOP et exécute directement le protocole. Ce protocole construit un arbre de propagation entre les entités d application pour diffuser les messages. Sur cet arbre, il maintient une racine de diffusion pour chaque groupe. Via CTOP, une entité qui veut s'installer dans un arbre existant envoie une requête d'installation à l'extrémité réseau d'une autre entité qui devient son père. Elle obtient ainsi entité un nom en notation pointée qui définit sa position dans l'arbre. Le cœur de CTOP est un composant de routage spécifique. Ce composant utilise les noms pointés pour établir de façon optimale un arbre couvrant et maintenir une racine de diffusion pour chaque groupe. Ce composant de routage constitue l essentiel de l architecture logicielle de CTOP. Un autre composant maintient de façon répartie l appartenance au groupe. Ce composant est extrêmement simple. Il se contente de recevoir des événements d entrée ou de sortie d un groupe de la part du composant de routage. Chaque entité peut demander à entrer dans un groupe en donnant le nom du groupe. Si le nom n'existe pas déjà, l'entité devient racine de diffusion pour ce groupe. La demande d'entrée d'un nouveau membre peut conduire le routage à repositionner la racine du groupe pour couvrir 76

tout le groupe. Le repositionnement de la racine du groupe sur un événement d'entrée repose sur le parcours de la requête d'entrée en remontant l'arbre jusqu'à atteindre la racine. La racine du groupe transmet alors une indication d'entrée qui parcourt l'arbre de façon minimale pour mettre à jour les listes d'acheminement et les informations d'appartenance au groupe. Une entité membre d'un groupe peut émettre un message vers ce groupe. Ce message est envoyé à la racine du groupe et il parcourt l'arbre de façon minimale. Une entité peut demander à la racine du groupe de sortir. L'indication de sortie parcourt l'arbre toujours de façon minimale pour mettre à jour les listes d'acheminement et l'appartenance au groupe. Le parcours (des indications d'entrée, indications de sortie et des messages) est rendu minimal par le composant de routage en utilisant l'appartenance au groupe et la notation pointée. Un groupe étant un ensemble de noms pointés, chaque nœud utilise le message reçu et les noms pointés pour calculer localement la position de la nouvelle racine et maintenir sa liste d acheminement (routage) et l appartenance pour le groupe concerné par le message. Exemple d arborescence d entités d application Acheminement: - commandevol:.1.1 Racine de l'arbre:. Acheminement: - simulfluides:.2 - simulpompes:.2,.3 - commandevol:.1 Groupes: - simulpompes={.2.1,.2.2,.2.3,.3.1} Groupes: - commandevol= {.1.1}.1.2.3 Acheminement: - simulpompes:.3.1 Groupes: - simulpompes= {.2.1,.2.2,.2.3,.3.1}.1.1.1.2.2.1.2.2.2.3.3.1.3.2 = simulfluides = simulpompes = Racine de simulfluides = Racine de simulpompes Groupes: - simulpompes= {.2.1,.2.2,.2.3,.3.1} = commandevol = Racine commandevol Fig. 13 Exemple d'arborescence et de composition des groupes CTOP permet de mettre en place une arborescence d'entités d'application. Sur la figure 13, chaque entité d'application de l'arbre porte un nom pointé qui définit sa position dans l'arbre. Dans cet exemple, il existe trois groupes simulfluides = {.2.1,.2.3}, simulpompes = {.2.1,.2.2,.2.3,.3.1} et commandevol={.1.1}. Chaque groupe possède une racine qui couvre de façon minimale le groupe. Une entité peut appartenir à plusieurs groupes, c'est le cas de.2.1 qui appartient aux groupes simulfluides et simulpompes. Une racine de diffusion n'appartient pas forcément au groupe, c'est le cas de la racine.2 pour le groupe simulfluides. Seuls les membres de l'arbre couvrant connaissent la composition du groupe. Les entités, qui vont de la 77

racine de l'arbre à la racine du groupe, ont seulement une table d'acheminement qui contient les fils vers lesquels il faut retransmettre les messages. C'est le cas de l'entité.1 qui n'a qu'une table d'acheminement pour le groupe commandevol. Les autres entités n'ont pas d'information pour le groupe. On voit que chaque entité maintient la quantité d'information minimale qui permet à la fois de maintenir l'appartenance au groupe et d'assurer le routage. Les nœuds qui ne sont pas concernés par un groupe n'ont aucune information et ne reçoivent aucun message concernant ce groupe. Architecture de CTOP L'architecture de CTOP est représentée sur la figure 14. Au niveau le plus bas, un composant assure la transmission fiable notamment entre un père et ses fils mais aussi entre un demandeur et la racine du groupe ou de l'arbre. Ce composant peut être instancié sous deux formes. La première consiste à utiliser des connexions TCP entre une paire d'entités, ainsi chaque liaison père-fils est réalisée par une connexion TCP. Une autre instance de ce composant est proposée au moyen d'udp. Dans ce cas, CTOP fiabilise les transmissions en utilisant un mécanisme d'acquittement négatif qui évite d'avoir systématiquement à retransmettre des acquittements. Le débit en sortie peut alors être supérieur à celui de TCP qui souffre des problèmes connus de slow-start et est mal adapté au cas où un même message est destiné à plusieurs entités (ce qui est le cas ici). L'application peut choisir d'instancier CTOP en mode TCP ou UDP. Nous ne détaillerons pas plus avant l'aspect transmission fiable. Ensuite, les événements transmis de façon fiable sont traités par le composant de routage. Celui-ci calcule la position de la racine, la déplace, et retransmet les événements reçus aux fils qui acheminent le groupe. Le composant d'appartenance aux groupes est appelé par le routage pour mettre à jour l'appartenance au groupe sur un événement d'entrée ou de sortie. C'est un composant simple car le routage effectue la plus grande partie du travail et n'achemine que les événements nécessaires. Donc les événements reçus par le composant d'appartenance sont forcément des informations utiles et qui permettent de mettre à jour de façon cohérente la base de donnée répartie d'appartenance aux groupes. On constate qu'il n'y a aucun composant d'ordonnancement dans CTOP. En effet, l'ordonnancement est réalisé par preuve. La livraison en séquence réalisée par la transmission fiable et le parcours de l'arbre garantissent les propriétés d'ordonnancement. L'ordre total est garanti par le fait qu'une entité retransmet les événements reçus sur l'arbre. C'est le parcours de l'arbre qui garantit une diffusion identifiable et donc un ordre total. Il suffit de faire un envoi à soi-même pour garantir l'ordre causal au moyen de notre résultat formel. Une remarque importante est que les identifiants ne sont pas connus ni maintenus par le système. Ils ne correspondent pas directement aux numéros de séquence pour la transmission fiable. L'identifiant d'un message est obtenu en assemblant d'un point de vue formel les numéros de séquences locaux des messages qui sont arrivés sur la racine de diffusion avant la diffusion de M. Ces identifiants ne sont pas maintenus par le système ni transmis dans les messages. Ils servent juste à montrer que la livraison se fait selon ces identifiants. 78

Appartenance aux groupes Routage Transmission fiable Fig. 14 Architecture de CTOP Service et protocole d'installation dans l'arbre Ce service est simple, il consiste en une méthode void installer(char *ip, short port)qui envoie une requête d'installation à l'entité d'application (ip,port). Cette méthode récupère en réponse le nom pointé alloué par le père (ip,port) et installe le fils demandeur en affectant son nom pointé avec l'information retournée par le père. Ce service peut être utilisé même en cours de fonctionnement de l'arborescence. C'est à dire qu'il est possible à tout moment d'installer une nouvelle entité d'application dans l'arbre..1 indentrée.2.3 reqentrée reqracine cède reqentrée indentrée Montée de la racine Racine inchangée Création.1.1.1.2.2.1.2.2.2.3.3.1.3.2 reqentrée indentrée Fig. 15 Protocole d'entrée reqracine et cède Service et protocole d'entrée dans un groupe Ce service correspond à une méthode void entrer(char *nomgroupe)qui est utilisée par une entité d'application pour entrer dans un groupe. Le service envoie une requête d'entrée (reqentrée) au père. Le protocole distingue trois cas principaux illustrés par la figure 15. Le premier cas est la création d'un groupe. Il correspond à l'entrée d'un premier membre (ex:.3.2) dans le groupe. La requête d'entrée (reqentrée) remonte l'arbre de proche en proche jusqu'à atteindre la racine de l'arbre. Celle-ci s'aperçoit qu'elle ne connaît pas le groupe. Elle en déduit que c'est une création et que le demandeur devient la racine du nouveau groupe. Elle envoie une indication d'entrée (indentrée) au demandeur lui indiquant qu'il est la racine. Cette indication parcourt l'arbre en direction du demandeur (ex:.3.2). Chaque processus intermédiaire (ex:.3) met à jour sa liste d'acheminement en ajoutant le fils concerné. Il retransmet alors le message vers ce fils. Lorsque le demandeur reçoit l'indication, il mémorise qu'il est la racine et le parcourt de l'arbre s'arrête. 79

Le second cas est celui de la montée de la racine. La requête d'entrée (reqentrée) remonte jusqu'à une entité qui achemine déjà l'adresse (ex:.1) avec un seul fils dans sa liste d'acheminement. L'entité (ex:.1) vérifie, au moyen de la composition du groupe et de la liste d'appartenance, que la racine courante est en dessous d'elle (ex:.1.1). Elle envoie alors une requête (reqracine) de demande de transfert de la racine du groupe. Cette requête descend l'arbre. Lorsque la racine courante reçoit la requête de transfert, elle envoie une réponse (cède) de façon directe au demandeur (sans passer par l'arbre) et cède la racine. La réponse contient la composition du groupe. Lorsque le demandeur (ex:.1) reçoit la réponse, il peut traiter la requête d'entrée qui est à l'origine de la montée et envoyer une indication d'entrée (indentrée) qui parcourt l'arbre selon les différentes listes d'acheminement. Dans le troisième cas, la racine est inchangée. La requête (reqentrée) remonte jusqu'à la racine courante (ex:.2). Dans l'exemple, le père du demandeur est la racine du groupe. Lorsqu'il y a des noeuds intermédiaires, ils font remonter la requête d'entrée pour atteindre la racine du groupe. Lorsqu'elle reçoit la requête, la racine courante envoie en réponse une indication d'entrée (indentrée) qui descend l'arbre. L'algorithme permet que les messages ne parcourent que les chemins nécessaires. L'entrée dans un groupe est donc effectuée au plus vite. Un point important est que l'indication d'entrée permet de mettre à jour les listes d'acheminement. Ainsi, un nœud ne retransmettra les futurs messages à destination de ce groupe que vers des fils présents dans la liste d'acheminement du groupe. Enfin, le nouvel arrivant connaît la composition du groupe lorsqu'il reçoit l'indication d'entrée..1.2.3 reqfin repfin descente de la racine Racine inchangée Supression.1.1.1.2.2.1.2.2.2.3.3.1.3.2 reqsortie indsortie Fig. 16 Protocole de sortie reqfin et repfin Service et protocole de sortie d'un groupe Ce service correspond à une méthode void sortir(char *nomgroupe)qui est utilisée par une entité d'application pour sortir d'un groupe auquel elle appartient. Le service envoie une requête de sortie (reqsortie) directement à la racine du groupe. Le protocole distingue trois cas illustrés figure 16. Dans le premier cas, la racine est inchangée. La racine du groupe (ex:.2) reçoit la requête (reqsortie). Elle recalcule la position de la racine grâce à la nouvelle composition du groupe (la composition courante moins le sortant). Elle s'aperçoit qu'elle reste racine. Elle envoie alors une indication de sortie (indsortie) en signalant via un champ du message (indsortie.descendracine=faux) qu'il n'y a pas de changement. L'indication de sortie descend l'arbre selon les listes d'acheminement. 80

Dans le second cas la racine descend. La racine courante (ex:.1) s'aperçoit en recalculant la position de la racine qu'elle n'est plus racine. Elle envoie une indication de sortie (indsortie) en signalant que la racine descend vers une nouvelle racine dont elle fournit le nom pointé. Les nœuds entre l'ancienne et la nouvelle racine en profitent pour supprimer les structures de données d'appartenance pour ce groupe. Le troisième cas correspond à la suppression du groupe. Lorsque le dernier membre (ex:.3.2) sort, il envoie une requête de fin de groupe à la racine de l'arbre. La racine de l'arbre transmet alors une réponse de fin qui descend la dernière branche possédant des listes d'acheminement. Au fur et à mesure de la descente de la réponse, chaque nœud supprime la liste d'acheminement de ce groupe. Service et protocole de diffusion d'un message vers un groupe Une entité d'application doit préalablement demander à entrer dans un groupe pour pouvoir diffuser un message vers ce groupe. Cette propriété est nécessaire sinon l'envoi à soi-même n'est pas assuré est la diffusion ne peut être causale. L'application utilise la méthode void emettre(char* nomgroupe, char* messappli)pour émettre un message applicatif vers un groupe. Elle utilise la méthode void recevoir(char* nomgroupe, listemessages *premier)qui retourne le premier message disponible ainsi que le nom du groupe. Cette primitive livre les messages selon l'ordre causal et total. Pour émettre un message, le service envoie une requête à la racine de diffusion, celle-ci reçoit le message et le diffuse vers tous les fils de sa liste d'acheminement. Un nœud qui reçoit le message, le retransmets en utilisant sa liste d'acheminement. Ainsi, le message atteint tous les membres du groupe en parcourant de façon minimale l'arbre. La primitive recevoir se contente de retirer un message de la file de livraison. A l'inverse d'autres protocoles, l'entité réceptrice n'effectue pas de réordonnancement selon des informations de causalité ou selon un séquencement global. Elle se contente de faire une livraison en séquence de tous les messages qui lui proviennent de son père. Ainsi, avec des connexions TCP, les entités de protocoles ne gèrent ni de numéros de séquence ni de files d attentes et elles n ont pas à effectuer de réordonnancement des messages. Mise en œuvre La solution est mise en œuvre au moyen de l environnement ADAPTIVE Communication Environment (ACE) [SCHM 98]. ACE consiste en une librairie objet qui assure la portabilité des appels systèmes (threads, IPC, entrée-sortie, etc ). Grâce à l utilisation d ACE, la librairie CTOP fonctionne sur différents systèmes, Windows et Unix notamment. Différentes threads ACE sont utilisés pour transmettre les messages et gérer les retransmissions sur délai dans le cas de UDP. Sur les bases de la méthode BB [KAA 93], une optimisation permet de diffuser directement un message, en utilisant un adresse de multicast IP, et une référence du message est diffusée sur l'arbre. Seule la référence du message du message parcourt l arbre et les données sont diffusées de façon efficace directement aux destinataires. De plus chaque groupe est associé à une adresse de multicast, ce qui évite de traiter de traiter des messages inutilement pour les récepteurs non concernés. 81

Ainsi seules de petites données empruntent l'arbre et les récepteurs ne traitent que les messages qui les intéressent. Les requêtes concurrentes d'entrée, de sortie ou de diffusion sont traitées. Pour les requêtes concurrentes avec une racine de diffusion en cours de transfert, nous évitons d'avoir à gérer des files de requêtes en attente. Si en cours de transfert de la racine de diffusion un nœud reçoit une requête qu il ne peut traiter pour ce groupe, il répond négativement afin que demandeur rejoue sa demande ultérieurement. Certains conflits sont donc résolus par rejeu sur avis négatif. Pour une réponse négative à une demande d entrée, le demandeur essaie à nouveau au bout d un délai. Une fois le transfert terminé, l ancienne racine laissera passer une demande d entrée de façon habituelle. Pour une réponse négative à une requête de sortie ou de diffusion, le demandeur attend d avoir l indication pour la position de la nouvelle racine afin de relancer sa requête avec celle-ci. Ces réponses négatives n arrivent que lorsque la racine change de place, sinon les requêtes sont traitées immédiatement par la racine courante. Principe de preuve pour l ordre causal et total Nous donnons ici seulement l idée de la preuve qui utilise le théorème 2. La preuve complète est dans [TOI 93]. Nous proposons une définition d identifiants. Un identifiant est un vecteur de numéros locaux dont la taille est la profondeur de l arbre. Ni les numéros locaux ni les identifiants n ont besoin d être maintenus par le système. Ils correspondent à des valeurs qu un observateur parfait pourrait faire de l arborescence de transmission. Bien sûr cet observateur n a pas existence dans le système implanté. Un numéro local correspond au numéro du dernier message qui a été reçu par la racine du message M. Donc seules les éléments du vecteur, qui correspondent aux nœuds situés entre la racine de l arbre à la racine de l adresse, ont un numéro non nul. On peut trouver d'autres façons de définir les identifiants. Mais pour la méthode retenue, la preuve qu'il y a un ordre identifiable, est dans [TOI 93]. Pour garantir l'ordre local, la méthode la plus simple est que chaque émetteur attende d'avoir en retour son message diffusé (c'est-à-dire l'indication de diffusion) avant de pouvoir émettre le message suivant, donc les messages sont forcément livrés selon l'ordre local. En fait dans CTOP la transmission fiable entre l'émetteur et la racine du groupe garantit que la racine va transmettre les messages selon l'ordre local de l'émetteur. Donc, il n'est pas nécessaire d'attendre pour émettre un nouveau message. Enfin, comme une entité doit appartenir au groupe vers lequel elle émet, il y a bien envoi à soi-même. Ainsi, on a un ordre identifiable et local avec envoi à soi-même et le théorème 2 s'applique. Intégration à un environnement de mise en œuvre coopérative d une simulation répartie Nous avons vu que la solution DBSM fournit un canevas permettant de mettre en place de façon coopérative des simulateurs au sein d un prototype virtuel. Elle permet aux concepteurs de coupler aisément des simulateurs. Avec DBSM les échanges sont faits en mode moindre 82

effort. L intérêt de CTOP est de permettre que les échanges de données entre les simulateurs soient ordonnés afin de garantir des traitements cohérents. L intégration à la solution DBSM est en fait assez aisée. Il s agit pour un nœud de l arbre partagé d utiliser les services CTOP pour transmettre vers les pairs distants les mises à jour des attributs de simulation plutôt que d utiliser le mode moindre effort présent classiquement dans DBSM. 2.4.3 Comparaisons et discussions 2.4.3.1 Simulation discrète versus systèmes à diffusion ordonnée La simulation répartie à événements discrets (ex : HLA) permet à l application de définir des dates logiques qu elle attribue aux événements. D un côté, les dates logiques permettent de matérialiser les relations de causalité qui existent entre les événements applicatifs. Dans [TOI 93], on appelle relations sémantiques ces relations de causalité car il s agit de définir d un point de vue applicatif la causalité du système. Une relation sémantique E S E' (respectivement, M S M') se définit simplement entre un événement E (respectivement, un message M) qui est une cause d un E' (respectivement, d un message M'). L attribution de dates logiques correctes, pour matérialiser l ensemble des relations sémantiques sur la totalité du système, est difficile voir impossible pour un ensemble de simulateurs sur étagère dont on ne connaît pas la logique interne de fonctionnement. D un autre côté, les dates logiques permettent d ordonner de façon reproductible des événements concurrents qui n ont pas de relation de causalité. Bien que les techniques de diffusion ordonnée soient peu utilisées dans le domaine de la simulation répartie, nous pensons qu elles présentent de réels avantages par rapport aux techniques à événements discrets. Tout d abord, elles adressent les mêmes besoins. Un ordre causal permet de respecter des relations causales de communication. Dans [TOI 93], on explique qu un ordre causal est suffisant pour respecter les relations sémantiques. Un ordre total permet lui aussi d ordonner les événements concurrents. Il permet d éviter que le système devienne incohérent en évoluant de façon différente selon les entités impliquées dans la simulation répartie. La différence essentielle avec les techniques à événements discrets, est qu une diffusion ordonnée garantie ces propriétés de façon automatique grâce à l observation qu elle a des événements de communication. C est donc un avantage majeur puisqu en pratique il est difficile d associer des dates logiques correctes pour des simulateurs sur étagère. Le principal défaut des techniques de diffusion ordonnées est qu elles ne garantissent pas une reproductibilité parfaite. Mais en pratique une simulation correcte est préférable à une simulation reproductible. 2.4.3.2 Comparaisons avec d autres systèmes à diffusion ordonnée Dans Transis [AMIR 92] [HULE 96], un arbre est nécessaire pour réaliser un ordonnancement causal et total. Des domaines de diffusion à tout le monde (broadcast) sont connectés à travers des liaisons point-à-point formant ainsi un arbre de domaines de broadcast. Un message est transmis de domaine en domaine lorsque le groupe recouvre 83

plusieurs domaines. Un message est d abord ordonné causalement dans son domaine d émission. Ensuite il est retransmis vers les autres domaines à travers les liaisons point-àpoint. Lorsque le message atteint le domaine racine, il est à nouveau retransmis vers les domaines inférieurs. Donc un message monte et redescend l arbre. Un ordonnancement causal est réalisé à chaque domaine traversé. Les auteurs nécessitent des domaines de diffusion pour réduire la taille de l histoire causale. L ordre total est réalisé au-dessus de l ordre causal. Pour cela, le message monte de proche en proche puis redescend l arbre. A la descente chaque nœud d entrée retransmet le message dans son domaine en respectant l ordre définit par la racine. Un message n est donc livré de façon totalement et causalement ordonné qu après avoir monté et redescendu et avoir subi plusieurs étapes de réordonnancement causal. Il ne semble pas que le système maintienne plusieurs racines de diffusion pour les différents groupes car il n est pas décrit comme ces racines seraient maintenues par le système. Il semble plutôt que le message joigne toujours la racine de l arbre. Totem [AMIR 93] utilise le même principe que celui défini dans [TOI 92] pour la diffusion à tout le monde. Ils utilisent le protocole en anneau [CHAN 84] dont nous avons montré qu il était causal ainsi que tous les protocoles localement et totalement ordonnés qui font de la diffusion à tout le monde. [MOS 96] vise à étendre la solution pour la diffusion vers des groupes. Pour cela, ils relient des domaines de diffusion par des liaisons point-à-point. Ils doivent alors réaliser un autre ordonnancement au-dessus de celui existant pour un domaine de broadcast. Ils utilisent pour cela un identifiant qui contient une estampille logique comme [LAM 78]. Un ordonnancement causal est réalisé entre les différents domaines grâce à cette estampille. Ensuite, ils réalisent un ordonnancement total en utilisant le nom du domaine comme référence d émetteur afin d appliquer le principe de [LAM 78]. Ainsi, trois niveaux de réordonnancement sont exécutés. La solution n évite donc pas la réalisation d un ordre causal dans le cas général de la diffusion vers des groupes. Horus [REN 95] ou Ensemble [HAY 98] construisent un ordre causal en utilisant des vecteurs d estampille. Dans le contexte de plusieurs groupes (multicast), ce vecteur a une taille en O(n 2 ) et il croit avec le nombre de groupes et le nombre de processus. Dans [BAL 97], ils organisent des domaines de diffusion pour réduire la taille du vecteur d estampilles. Cette solution est très proche de celles vues précédemment et souffre donc du même problème : les messages doivent être ordonnés causalement dans un domaine avant d être retransmis pour être ordonné causalement vers les autres domaines. La couche causale véhicule ainsi moins d information dans les messages mais les temps de livraisons se trouvent rallongés. De plus, la solution nécessite, comme les précédentes, un second protocole pour réaliser l ordre total. Celui-ci est construit en faisant circuler un jeton entre les émetteurs. Le passage d un jeton parmi un groupe ne peut pas garantir l ordonnancement pour des messages émis vers deux groupes différents. Il faut donc qu un seul jeton circule parmi tous les processus. Par ailleurs, on trouve des protocoles comme [MIS 93] qui construisent une diffusion vers des groupes (multicast) en diffusant les messages à tout le monde (broadcast). Ces solutions ne sont clairement pas applicables à un réseau grandes distances en raison de l impossibilité de diffuser un message afin qu il atteigne tout le réseau. Ils réalisent un ordre causal en maintenant, sur chaque entité de protocole, un graphe qui représente les relations causales de communication. Un ordre total est réalisé au dessus en attendant que chaque entité dans le système diffuse un message afin d ordonner les messages concurrents. Ainsi, lorsque chacun a transmis un message on peut ordonner totalement les messages concurrents. 84

Notons que [KIN 95] cite clairement l utilisation du résultat formel qui est appliqué à un séquenceur [TOI 92] pour éviter la construction d'une couche causale. Il propose simplement que plusieurs séquenceurs puissent être regroupés sur un seul séquenceur lorsque les groupes qu ils servent ne sont plus disjoints. Mais le principe reste fondamentalement centralisé car il repose sur l existence d un serveur. Pour les solutions proposées pour les réseaux grandes distances, elles utilisent toutes une structure arborescente [REN 95] [MOS 96] [HULE 96]. Cependant, ces solutions présentent toutes les mêmes défauts. D une part, un message monte et descend l arborescence pour être ordonné causalement et totalement. De plus, chaque niveau de l arborescence emprunté ralentit le message puisqu il doit y être ordonné causalement. Par ailleurs, afin de réduire les tailles des informations pour la causalité, la plupart de ces solutions nécessitent l existence de domaine de diffusion. A l opposé, nous évitons complètement d avoir à construire un ordre causal pour la diffusion vers des groupes (multicast). Ainsi il n y aucune information de causalité nécessaire dans les messages et donc aucun délai dû au réordonnancement causal. De plus, un message diffusé ne remonte pas l arbre, il va directement à la racine de diffusion. Donc par rapport aux autres solutions nous gagnons le temps de la montée dans l arbre. La solution peut aussi être appliquée à des domaines de diffusion puisqu un nœud de l arbre peut diffuser vers ces fils un message plutôt que de l émettre en point-à-point. Ce qui réduit alors le temps de propagation. On peut ainsi imaginer que chaque nœud utilise les adresses de multicast, qui existent au niveau d IP, pour minimiser le temps de propagation. Cependant la solution n impose pas l existence de domaine de diffusion. La solution peut être améliorée au moyen d un protocole de placement qui évite que la racine d un groupe vienne trop haut dans l arbre. A notre connaissance, notre proposition est la seule qui évite la construction d un ordre causal et repose sur une structure arborescente. De plus, notre solution pourrait être couplée à des solutions efficaces qui permettent une diffusion fiable. En effet, les études [LEV 98] concernant la diffusion fiable ont montré que les protocoles basés sur une arborescence sont les plus efficaces. Enfin, les résultats, qui nous ont permis de définir CTOP, sont généraux. Ces résultats formels montrent dans quels cas de figure un protocole ordonné totalement peut être causal. Au-delà de l utilisation dans CTOP, ces résultats ont permis de montrer le caractère causal de solutions existantes, ils ont déjà été utilisés par d autres pour établir de nouveaux protocoles et peuvent à l avenir déboucher sur de nouvelles solutions. 2.5 Résultats, intervenants et perspectives La solution DBSM a été implantée par Antoine Sgambato, élève ingénieur CNAM, sous ma direction. Cette réalisation a été effectuée de façon contractuelle pour l'aérospatiale. Elle a donné lieu a trois publications internationales. Cette solution a été intégrée a une application de prototypage virtuel. Cette première mise en œuvre a servi de base à la définition de la métaphore du chantier réparti. Fabien Costantini, élève ingénieur CNAM, a réalisé une application de prototypage virtuel rapide sous ma direction scientifique. Cette application est assez évoluée vis à vis des outils industriels actuels. Elle est utilisée en vraie grandeur. Dans ce travail, j ai aussi impliqué, Boris Mansencal et Nicolas Tarrin, deux élèves ingénieurs ENSEIRB qui en ont tiré une bonne compétence puisqu ils sont maintenant tous deux ingénieurs experts à l INRIA. Ils ont 85

été encadrés par moi et par Fabien Costantini sur les aspects graphiques et architecture logicielle. Nous avons ensuite étendu les principes de la solution DBSM non seulement d un point de vue réseau mais aussi en terme d'architecture logicielle en utilisant les designs patterns pour simplifier l'intégration aux applications existantes. Fabien Costantini a grandement contribué aux aspects graphiques et aux solutions à base de Design Patterns. Il a ainsi pu faire avec moi huit publications internationales sélectives dont une revue IEEE MultiMedia. Trois publications concernent l utilisation de Design Patterns afin d améliorer le développement des grandes applications et des architectures logicielles pour la coopération. Les six autres concernent les techniques de conception coopérative. Plusieurs élèves ingénieurs ENSEIRB, dont récemment trois élèves en mémoire d ingénieur (Le Compagnon, Loison et Fuchs), ont aussi participé au développement des différentes implantations de DBSM. Il faut noter que des solutions liées à l allocation d espace et à la simulation pour le prototypage virtuel rapide, n ont pu faire l objet de publications en raison d aspects confidentiels. L'essentiel de ce travail s'est donc déroulé de façon contractuelle sur deux ans et avec deux mémoires d'ingénieur CNAM à plein temps. Les résultats obtenus nous a permis de pouvoir déposer le projet européen IST AIT-VEPOP qui a été accepté du fait de l'expérience acquise et de notre bonne connaissance du domaine. J'ai moi-même assuré le montage de ce projet pour le CNAM aussi bien d'un point de vue scientifique qu'administratif. J'ai ainsi obtenu un financement de 1,7MF sur deux ans en tant que contractant principal. Cela nous permet de développer certaines activités dans ce domaine et de financer la thèse de Fabien Costantini. Ce projet européen est aussi pour nous la possibilité de pouvoir développer des solutions qui sont notre propriété et non couvertes par des clauses de confidentialité. A l'heure actuelle, nous sommes en train de développer une nouvelle implantation de la solution DBSM qui puisse être livrée sous forme d'un logiciel libre et de façon plus ouverte ce qui augmentera les possibilités d'usage et permettra d'autres champs d'application. Il faut noter que c'est une activité nouvelle que j'ai démarrée au CNAM et qui est relativement fructueuse aussi bien en terme d'outils logiciels que de publications. En effet, certaines solutions sont maintenant utilisées en vraie grandeur. Les publications permettent d'attester de la qualité du travail de recherche pour le domaine du prototypage virtuel coopératif. Les résultats obtenus dans ce domaine peuvent être étendus notamment au domaine du jeu ou de l enseignement à distance. Par ailleurs, j'ai développé moi-même le système CTOP. Il fonctionne de façon portable sur des machines Windows et Unix. Il est issu de travaux plus fondamentaux dans la continuité de mon travail de thèse. L ensemble des résultats formels, qui définissent dans quelles conditions un ordre total peut être causal, se trouvait déjà dans ma thèse. Cependant, j ai refait entièrement les preuves afin de corriger certaines imprécisions et les résultats sont maintenant plus robuste en terme de preuves. Le principe sur lequel repose CTOP était lui aussi décrit dans ma thèse. Cependant la nouveauté est une implantation sur l Internet au moyen d un composant de routage. J ai ainsi défini les protocoles nécessaires pour réaliser un routage efficace. Le résultat formel pour l envoi à soi-même, qui est nécessaire pour garantir la causalité d un système arborescent, provient de ma thèse. L absence de numérotation des messages, dès lors que la transmission entre les nœuds est fiable, est une conséquence directe du résultat formel présent dans la thèse. 86

Au-delà, la définition et la mise en œuvre de CTOP, les résultats formels sont maintenant mieux établis. Ils sont très généraux et peuvent donner lieu à de nombreuses solutions en terme d architecture réseau et de protocoles. Les résultats formels associés à CTOP ont été publiés dans ACM OSR en 1999. La solution CTOP a été publiée à la conférence sur les nouvelles technologies de la répartition (NOTERE 2000). Elle a reçu un bon accueil et la publication a été retenue pour être publiée en anglais et de façon étendue dans la revue "Annales des Télécommunications". Bien qu'à l'origine il n'y ait pas de lien entre DBSM et CTOP nous trouvons maintenant des liens possibles pour couvrir le domaine de la simulation répartie. Les techniques de couplage faible (entre les applications de réalité virtuelle, les composants réseaux et les simulateurs) en utilisant les designs patterns sont décrites dans trois publications internationales. Par ailleurs, la technique de couplage des simulateurs est décrite dans un livrable d'architecture logicielle pour le projet européen IST AIT-VEPOP. Enfin il faut noter que pour la partie scientifique de ces résultats, je suis le principal chercheur permanent. Ce fait est étayé en terme de publications puisque j en suis soit le principal auteur soit le seul chercheur permanent. J ai su développer une coopération industrielle continue à travers des contrats. Cette démarche est d ailleurs commune avec le domaine du contrôle réparti des procédés qui est décrit ensuite. La mise en place de ces activités n a pas été facilitée par l éloignement géographique de mon Laboratoire d accueil. Eric Gressier-Soudan, Maître de Conférences au CNAM, a participé à la gestion administrative et m a soutenu de façon constante. Les résultats obtenus ont assurément été facilités par ses qualités d organisateur et ses immenses qualités humaines. Il est aussi d une aide précieuse dans le projet européen. Enfin, son travail dans le domaine de la cohérence des services de mémoire partagée nous a servi pour la cohérence proposée dans DBSM. La solution qui se dégage du couplage entre DBSM et CTOP est à notre avis extrêmement intéressante et porteuse. Elle permettra de couvrir un champ d'applications très vaste en franchissant certaines barrières technologiques qui freinent leurs développements d'un point de vue industriel. Les résultats sont issus de deux démarches qui peuvent sembler différentes. En effet, DBSM est une solution très technologique alors que CTOP est issu de résultats formels. Mais en fait, la démarche dans ces deux domaines a été la même. Elle consiste à faire un l'état de l'art le plus complet possible aussi bien d'un point de vue industriel qu'académique. Parallèlement, nous avons travaillé dans un domaine d'application en relation avec des besoins industriels réels. Ainsi, nous avons défini des solutions nouvelles afin de mieux couvrir les besoins industriels d'une part, formaliser et faire progresser les techniques d'autre part. Les résultats sont assez probants car les logiciels mis en œuvre ont pu être intégrés à des applications existantes et les publications ont permis d asseoir les solutions. 2.4 Publications Les publications associées à ces travaux sont les suivantes. On peut distinguer les publications liées à la simulation répartie d'un côté [3], [12], [14], les publications concernant les systèmes coopératifs de prototypage virtuel [1], [2], [4], [6], [7], [8], [9], [10] et enfin les publications concernant l'intégration de composants logiciels [5], [11] et aussi [2]. Le travail, qui nous servi de support pour les aspects de la progression cohérente, correspond à une publication [13] sur la cohérence mémoire. 87

Revue d audience internationale avec sélection sur article: [1] F. Costantini, C. Toinard. 2001. "A New Approach of Collaborative Learning with the Distributed Building Site Metaphor." Soumis le 10 Juin 2000 et définitivement accepté le 27 Avril 2001. A paraître dans IEEE MultiMedia, July-September 2001. Chapitre de livre avec sélection sur article: [2] F. Costantini, C. Toinard. 2002. "Collaboration And Virtual Early Prototyping Using The Distributed Building Site Metaphor" Chapitre du livre "Multimedia Networking: Technology, Management and Applications" soumis à IDEA Group Publishing le 3 Mars 2000 et définitivement accepté le 10 Mars 2001. A paraître en 2002. Revue d audience internationale: [3] Toinard,C., Florin,G., Carrez,C. 1999. "A Formal Method to Prove Ordering Properties of Multicast Systems" ACM Operating Systems Review, Vol. 33, No.4, pp.75-89. Conférence d audience internationale avec sélection sur article et actes: [4] F. Costantini, C. Toinard, N. Chevassus, F. Gaillard. 2001. "Collaborative design using distributed virtual reality over the Internet", conference proceedings SPIE Internet Imaging, San José, 24-26 January. [5] F. Costantini, C. Toinard, N. Chevassus. 2001. "Optimizing Development of a Complex Software by Using and Extending Design Patterns ". Conference proceedings, Software Engineering Track, IRMA'2001, Toronto, 20-23 May. [6] Toinard,C., Chevassus,N. 1998. "Virtual world objects for real-time cooperative design of manufacturing systems" Workshop Object Oriented Technology and Real Time Systems of the European Conference on Object Oriented Programming, Bruxel, Lecture Notes in Computer Sciences, Object Oriented Technology ECOOP'98 Workshop Reader, Springer Verlag, conference proceedings, pp. 525-528. [7] Toinard,C., Chevassus,N., Sgambato,A. 1999. "Collaborative Virtual Reality and the Distributed Building Site Metaphor" WSCG'99, The 7-th International Conference in Central Europe on Computer Graphics, Visualization and Interactive Digital Media'99, conference proceedings, pp. SP/111-117. [8] Costantini,F., Sgambato,A., Toinard,C., Chevassus,N., Gaillard,F. 2000. "An Internet Based Architecture Satisfying the Distributed Building Site Metaphor" IRMA2000 Multimedia Computing Track, Anchorage, Alaska, 21-24 May, conference proceedings, pp.151-155, published by IDEA Group Publishing ISBN 1-878289-84-5. 88

[9] Fabien Costantini, Christian Toinard, Nicolas Chevassus. 2000. "Secure mobile replication for collaborative virtual reality" - In Proceedings Intelligent Multimedia Computing 2000, Rostock, 9-10 Novembre. Conférence d audience internationale avec sélection sur résumé et actes: [10] Costantini,F., Sgambato,A., Toinard,C., Chevassus,N., Gaillard,F. 2000. "Distributed Building Site Metaphor for concurrent engineering" MICAD2000, Paris, 28-30 Mars, conference proceedings, pp 187-194. [11] Fabien Costantini, Christian Toinard, Nicolas Chevassus. 2000. "Patterns for Collaborative Virtual Reality" - In Proceedings ICSSEA2000, Conference Proceedings, 2000, Paris, 5-8 décembre. Conférence d'audience nationale avec sélection sur article et actes: [12] Christian Toinard. 2000. "CTOP: un service de diffusion ordonnée causalement et totalement fonctionnant sur Internet" - Actes Nouvelles Technologies de la Répartition NOTERE'2000, 22-24 Novembre, Paris. [13] G. Calliet, T. Cornilleau, E. Gressier, C. Toinard. Mémoire partagée répartie à cohérence stricte sur un service d appartenance à des groupes Journées de recherches du GDR_PRC PRS sur la Mémoire Partagée Répartie MPR 96. 6-7 mai 1996. Bordeaux. Conférence invitée d audience nationale: [14] C. Carrez, G. Florin, C. Toinard. "Causally and totally ordered multicast protocols". JBOPAD'97. Actes des Journées Bordelaises sur les Ordres Partiels et les Algorithmes Distribués, Juin 1997. 3. Contrôle réparti des procédés industriels 3.1 Motivation Le terme de contrôle réparti que nous utilisons comporte en fait deux composantes appelées classiquement commande temps réel et contrôle de fabrication. La commande temps réel correspond à l'automatisation des machines de fabrication. A ce niveau on trouve des capteurs et des actionneurs qui sont commandés par des automates programmables ou des calculateurs temps réel. Les systèmes d'exploitation et les réseaux pour l'automatisme ont des caractéristiques assez spécifiques afin de pouvoir réagir assez vite aux événements provenant du procédé et pour garantir des temps de traitement pour ces événements. 89

Le contrôle de la fabrication, au sens classique, consiste pour une station de travail à récupérer des événements provenant du niveau automatisme. Ces événements sont typiquement traités pour être affichés et animer un synoptique qui représente graphiquement l'état de la machine de fabrication. Un opérateur peut aussi interagir avec le synoptique pour fournir des consignes, des ordres ou de façon élémentaire modifier des variables présentes au niveau automatisme. On parle alors de niveau supervision étant donné que le contrôle de la fabrication vise essentiellement à observer l'automatisme et à lui donner des consignes. Au niveau supervision on trouve des systèmes d'exploitation conventionnels (Unix, Windows) et des réseaux TCP/IP classiques qui n'offrent pas de qualité temporelle particulière. De façon pratique, aussi bien pour l'automatisme que pour la supervision on trouve d'un côté des composants propriétaires comme le réseau de terrain Modbus [AEG 96] qui sont largement répandus et utilisés et d'un autre des solutions normalisées pour l'automatisme [UTE 90] ou la supervision [ISO 90] qui n'ont pas rencontré le succès escompté. Dans tous les cas, les solutions sont finalement assez complexes et coûteuses à utiliser. Il existe plusieurs raison à cela. D'une part, les techniques sous-jacentes qu'elles soient propriétaires ou normalisées reposent sur des principes ad-hoc qui nécessitent des coupleurs réseaux et des systèmes de communication spécifiques. Ces techniques sont loin d'être éprouvées car elles définissent rarement les modes d'usages que peut en faire une application ou un développeur. Bien souvent celui-ci devra dimensionner finement le système et se poser de nombreuses questions quant aux techniques de répartition fournies et à leurs limites. En d'autres termes les solutions sont loin de fournir un niveau de transparence suffisant qui permettrait à un développeur de réaliser simplement une application répartie. Notre contribution vise à définir plus précisément les besoins en terme de communication qui peuvent être utiles aux applications d'automatisme et de supervision. Classiquement au niveau automatisme les services de communications visent essentiellement des propriétés temporelles qui ne sont pas toujours évidentes à appréhender. [UTE 90] [MAM 94] décrivent les priorités temporelles d'un réseau de terrain FIP. Par contre, ils ne décrivent les utilisations qui peuvent être faites par l'application de ces propriétés temporelles ni leurs limites. Par exemple, ils ne disent rien sur la capacité d'un réseau de terrain à préserver les relations de causalité qui existent dans le procédé commandé. Pourtant, le respect des relations de causalité pour faire une commande répartie d'un procédé industriel est important pour assurer un comportement transparent du système de communication. Notre travail précise ces points. Au niveau supervision, on s'intéresse essentiellement à accéder aux variables de l'automatisme et à développer des techniques de supervision répartie. Pour l'accès aux variables de l'automatisme sur un mode client-serveur, [ISO 90] est la solution qui a été standardisée. Elle permet à un calculateur de supervision d'accéder aux fonctionnalités et aux informations disponibles aux niveaux des composants d'automatisme (automates programmables, calculateurs temps réel, etc ). [ISO 90] repose sur les couches de protocole OSI qui n'ont pas fait de percée industrielle. L'architecture [ISO 90] est très complexe et les échanges sont effectués via un équipement virtuel de production ou VMD ("Virtual Manufacturing Device"). La formalisation des services rendus par un VMD si elle est intéressante a entraîné une certaine complexité et difficulté de perception de la part des utilisateurs. Enfin, le défaut essentiel de MMS est d'avoir été construit sur les piles de protocoles OSI. Des travaux comme [GGS 97] visent à simplifier l'architecture de MMS en 90

implantant les services au-dessus d'un système à objet réparti CORBA qui lui fonctionne directement sur les piles de protocoles TCP/IP de l'internet. D'un autre côté, des systèmes de communication vers des groupes tels que [REN 95] [AMIR 92] ou [MOS 96] peuvent être utilisés pour répartir les fonctions de supervision sur plusieurs stations. Grâce à la livraison ordonnée, les stations reçoivent les événements de supervision dans le même ordre tout en respectant la causalité entre les événements de supervision. Par exemple, si un opérateur observe une alarme et l'annule alors tous les postes de supervision afficheront l'alarme suivie de son annulation. Les usages de propriétés temporelles à ce niveau n'ont pas été clairement identifiés. Enfin, aucun de ces systèmes ne présente des performances suffisantes ou de propriétés temporelles leur permettant d'être utilisé au niveau automatisme. Dans le cadre synchrone, les systèmes [FET 99] calculent des bornes de transmission supérieures au-dessus de systèmes de communication standards tels que TCP/IP. Cette approche permet de détecter des fautes temporelles au-dessus de communications de type moindre effort. Des protocoles sont alors définis pour construire des groupes de destinataires connectés temporellement et élire un maître parmi chaque groupe. Ainsi, une synchronisation des horloges très précise entre le maître et les membres du groupe peut être mise en œuvre. Grâce au temps global, une diffusion ordonnée [CRI 91] peut être construite en utilisant le temps global pour estampiller les messages. [FET 99] positionne un indicateur temporel lorsqu'un participant n'arrive pas à respecter ses échéances. En fait, les statuts temporels de FIP sont très proches de cette notion d'indicateur temporel. Cependant l'approche de [FET 99] est très différente des réseaux de terrains tels que FIP puisqu'elle repose sur la construction d'un temps global très précis. Par la suite, nous n'envisagerons pas l'utilisation de techniques synchrones qui sont très peu utilisées en pratique. En effet, synchroniser précisément des horloges n'est pas trivial. Pour garder des horloges finement synchronisées, il faut soit constituer des groupes bien connectés temporellement comme le propose [FET 99] soit utiliser des cartes de synchronisation des horloges qui accède à un canal de diffusion de l'heure [DAN 97]. La première solution pose des problèmes pratique d'usage. En effet, retirer des calculateurs d'un groupe engendre de nouveaux problèmes: il faut trouver un autre composant capable de le remplacer et le mettre à jour. La seconde solution est onéreuse car elle demande l'équipement de chaque calculateur d'une carte de synchronisation d'horloge. Enfin, les techniques synchrones sont intéressantes surtout dans des conditions de fonctionnement difficiles et pour garantir un haut niveau de tolérance aux pannes. Elles permettent notamment de tolérer les pannes temporelles et byzantines. Nous écartons ce type de fautes de notre champ d'étude. Nous considérons seulement comment traiter simplement les pannes franches au niveau de l'automatisme. Afin de tolérer les pannes franches des contrôleurs d'automatisme, une technique de redondance est nécessaire. Une technique de redondance passive permet de traiter ce type de pannes. [CRI 91] décrit cette technique. La difficulté consiste alors à fournir un état correct au passif pour continuer le traitement en cas de panne du composant actif. Dans la pratique on ne peut pas garantir que le passif soit toujours parfaitement synchronisé. [GUE 96] propose une solution qui repose sur le fait qu'un client n'ayant pas reçu de réponse à sa requête, retransmettra sa requête au passif. Ce dernier exécutera à nouveau l'opération et retrouvera donc l'état de l'actif au moment de la panne. En fait, notre étude montre que ce type de solution n'est pas applicable dans le cadre d'une application d'automatisme. Nous proposons donc une solution adaptée au fonctionnement des automatismes industriels et qui utilise des composants sur étagères tels que les réseaux de terrains et les stations de supervision. 91

3.2 Principe et justification de notre solution Définitions des services et propriétés de communication nécessaires Mode message versus mémoire Le travail présente les distinctions entre le mode message et le mode mémoire et leur intérêt respectif. Le mode message correspond au cas où deux entités communiquent par transmission d'un message. L'émetteur utilise une primitive d'envoi d'un message M. Le récepteur utilise une primitive de réception. Ce mode d'échange est le plus répandu. Il permet de nombreux mode d'échanges. Le mode mémoire permet à deux entités de communiquer au moyen d'une variable. Une primitive d'écriture d'une variable permet à un écrivain de modifier la valeur de cette variable. Un lecteur peut accéder à la valeur courante d'une variable au moyen d'une primitive de lecture. En fait le mode mémoire est bien adapté pour l'automatisme car il permet d'avoir une copie locale des variables utiles. Les temps d'accès à une variable se trouvent donc réduits puisqu'il suffit d'accéder à une copie locale. Lorsqu'on dispose d'une indication de modification d'une variable, on peut déclencher des traitements sur notification comme on peut le faire en mode message. Propriétés temporelles L'étude présente les propriétés temporelles du mode mémoire que l'on trouve classiquement au niveau automatisme. Chaque variable est associée à des contraintes périodiques. Le système de communication essaie de respecter ces contraintes temporelles. En pratique, il existe toujours une limite pour un système à garantir des temps. L'intérêt majeur est, plutôt que garantir des temps de transmission, d'associer des statuts temporels aux variables. Un statut réseau indique si le système de communication a réussi ou échoué à mettre à jour la copie selon la contrainte fixée. Les usages possibles sont le traitement des défaillances du réseau de communication via un mécanisme de redondance par exemple du système de communication. Un statut de production indique si le producteur a réussi ou échoué à écrire la variable selon la contrainte. Un lecteur peut ainsi être informé des fautes du producteur. L'étude montre que même si les réseaux de terrain utilisent des cycles de communication qui ont des temps bornés, les transmissions ne se font pas pour autant en temps borné. En cas d'erreur de transmission, il n'y a en effet plus de borne garantie. Nous donnons des exemples qui illustre l'intérêt d'avoir des statuts temporels au niveau d'une application de supervision. Propriétés d'ordre Nous donnons des définitions pour le mode de communication par variable. C'est une transposition des définitions existant pour les communications par message. Nous distinguons l'ordre local qui permet de lire les valeurs des variables selon les relations séquentielles d'écriture, l'ordre causal qui permet de respecter les relations causales de communications et l'ordre total qui permet que tous les lecteurs lisent des valeurs indépendantes dans le même ordre. Nous montrons que l'ordre causal et total est nécessaire aussi bien au niveau automatisme que supervision. 92

Services unifiés d'accès à des variables A partir de la définition des besoins et du manque de solution de communication globale qui puisse être utilisée aussi bien au niveau automatisme que supervision, nous proposons un service de mémoire à diffusion qui présente une interface commune pour ces deux types d'application. Ce service unifié présente des propriétés d'ordre et supporte la validité temporelle. Les services mémoire peuvent être utilisés au niveau automatisme. Ils viennent compléter les manques des réseaux de terrain vis à vis de l'ordonnancement tout en fournissant une propriété de validité temporelle des variables. Cette propriété temporelle semble indispensable puisque l'automatisme l'utilise pour détecter les fautes temporelles. Ils reposent sur des composants sur étagères que sont les réseaux Ethernet et les protocoles TCP/IP. Enfin, ils peuvent partager la bande passante avec d'autres services de communication (MMS, CORBA, applications Internet, calculateurs de supervision, etc ). Détectant les fautes temporelles, ils peuvent être utilisés pour mettre en place des techniques de partage de la bande passante et en secours d'un réseau de terrain pour mettre en œuvre un mode d'urgence. Ces services mémoire sont aussi utilisables par le niveau supervision. Ils offrent une qualité d'ordre qui est typiquement nécessaire à ce niveau et permet aussi au niveau supervision de bénéficier de la validité temporelle pour les variables maintenues en copies multiples. Une propriété d'atomicité bien que non disponible peut-être construite au-dessus. L'intérêt est de simplifier l'interface de programmation en présentant une même interface de service au niveau supervision et automatisme. Services de communication orientés objet Les services offerts par notre mémoire à diffusion sont intégrés dans un système à objet CORBA. Ainsi, les communications peuvent se faire entre machines hétérogènes. De plus, des extensions CORBA en terme de diffusion de message simplifient la mise en œuvre du système de communication. L'application utilise des objets élémentaires qui sont des variables mémoire désignées par le nom de l'objet. Le système maintient chaque variable en copie multiple. L'application dispose essentiellement de deux méthodes pour chaque objet variable. La méthode appread permet à l'application de lire une valeur de variable et retourne le nom et la valeur de la variable. La méthode appwrite permet de modifier la valeur de la variable. La méthode appwrite est exécutée à distance sur toutes les copies de la variable grâce à la diffusion de la requête. Une requête appwrite est donc transmise au groupe des copies. Cette classe générique d'objet peut être déclinée en trois classes d'objets. Une classe d'objet pour l'automatisme correspond de près aux primitives de services de lecture et d'écriture locale d'un réseau de terrain. Ainsi, les développeurs des applications d'automatisme réparties n'ont pas à apprendre un nouveau mode de communication. Cette classe mémoire temps réel est une interface vers les services d'un réseau de terrain. Elle offre donc essentiellement des propriétés temporelles. Une seconde classe peut être utilisée à la fois par l'automatisme et la supervision. Elle est implantée grâce à nos services mémoire. Cette classe offre donc à la fois des propriétés d'ordonnancement et temporelles. Cette seconde classe complète donc les propriétés offertes par le réseau de terrain. De plus, elle permet à la supervision de bénéficier elle aussi de propriétés temporelles. 93

Une troisième classe permet à une entité de supervision de lire et d'écrire des variables présentes sur un contrôleur d'automatisme. Cette dernière classe correspond en fait à une classe de type messagerie industrielle. Elle présente des services proches de la lecture et l'écriture de variables à distance de MMS. Cette classe messagerie n'offre aucune qualité d'ordonnancement ou temporelle. Amélioration des propriétés d'ordonnancement des réseaux de terrain Nos services mémoire, fournissant des propriétés d'ordonnancement et temporelles pour l'automatisme et la supervision, sont issus d'une étude faite concernant le réseau de terrain FIP. Dans cette étude nous montrons qu'un réseau de terrain de type FIP (construit pour garantir uniquement des propriétés temporelles) fournit aussi un ordonnancement des opérations mémoires. Grâce au résultat formel que nous avons établi dans [TOI 92] concernant le broadcast, nous montrons en effet qu'en absence d'erreur de transmission et pour des vitesses de production (mise à jour par l'application) lentes FIP livre les valeurs des variables selon un ordre causal et total. Donc dans des conditions particulières, FIP préserve naturellement les relations causales de communication (ordre causal) et livre aussi des valeurs indépendantes dans le même ordre aux différents consommateurs (ordre total). Nous proposons aussi une extension qui peut être réalisée au-dessus du coupleur FIP et qui permet de garantir les propriétés d'ordonnancement pour les vitesses élevées de production. Cette extension est intéressante car elle ne demande pas de modifier les coupleurs existants. Par contre, on perd les propriétés temporelles. FIP est un système asynchrone. D'une part, il n'utilise et n'offre pas de temps global. Donc, aucun mécanisme de synchronisation des horloges n'est présent. D'autre part, bien qu'une borne temporelle existe sur un cycle de mise à jour, il n'y a pas de borne sur le temps de transmission d'une mise à jour. Les statuts de validité temporelle permettent de savoir si les contraintes de temps ont été satisfaites. FIP est un système à diffusion présenté comme un service mémoire. Cette première étude montre la difficulté pour avoir à la fois des propriétés temporelles et d'ordonnancement dans un environnement asynchrone. Dans la pratique avec un réseau de terrain comme FIP n'arrive pas à garantir ces deux propriétés. Grâce à cette première expérience autour du réseau de terrain FIP nous avons décidé de construire un service mémoire qui fonctionne sur des composants sur étagères afin d'être moins onéreux que FIP et qui fournisse à la fois des propriétés d'ordonnancement et temporelles. La solution repose le service de groupe Chorus-COOL qui offre une extension CORBA permettant de diffuser une requête vers un groupe de destinataire. Chorus-COOL utilise un serveur et des connexions TCP pour retransmettre les requêtes vers les membres du groupe. Le système réalise donc une diffusion localement et totalement ordonnée des requêtes. Un de nos résultats formels établi que l'ordre causal est aussi respecté. La solution garantit des propriétés temporelles qui sont proches de FIP. Ainsi nous fournissons deux statuts de validité temporels qui ont une sémantique assez proche d'un réseau de terrain de type FIP. De plus, le système récupère les erreurs de transmissions. Les performances peuvent être bonnes voir meilleures que celles de FIP mais sans que l'on puisse les garantir. L'absence de garantie provient essentiellement du fait que l'on fonctionne sur un réseau IP et le plus souvent audessus d'ethernet et que ces deux réseaux ne garantissent pas de délais bornés de 94

transmission. Par contre, les statuts temporels permettent de savoir si les performances souhaitées sont atteintes. Service mémoire présentant des propriétés d'ordre et temporelles La façon de réaliser les services mémoire est originale. D'une part, nous évitons la construction d'une couche causale de communication. D'autre part, nous arrivons à fournir des statuts de validité qui ont une sémantique voisine de celle présente classiquement dans un réseau de terrain. Une variable FIP peut présenter des statuts réseau négatif pour un ou plusieurs cycles de transmission. Avec notre solution, il n'y a pas de notion de cycle de transmission mais le statut réseau peut être négatif pendant une durée équivalente à un ou plusieurs cycles FIP. Le statut de production est lui transporté dans les messages comme dans FIP. La principale différence avec FIP est qu'ici il n'est pas nécessaire de dimensionner les cycles de transmission. De plus, les transmissions sont fiables. Contrairement à FIP, il n'est donc pas utile de retransmettre une même valeur à chaque cycle. Architecture de communication tolérant les pannes Nous utilisons une mémoire temps réel pour mettre en place un schéma de redondance passive des contrôleurs d'automatisme. Nous utilisons une mémoire temps réel FIP ou bien des mandataires de secours réalisés par notre service mémoire et qui permettent les communications lorsque la mémoire temps réel FIP est en panne. Une autre solution est d'utiliser directement notre service mémoire en lieu et place de la mémoire temps réel mais cette distinction est mineure. Habituellement, une mémoire temps réel de type FIP est utilisée pour répartir les variables d'automatisme sur les contrôleurs mais elle n'est pas utilisée pour construire des applications tolérantes aux fautes. La méthode est donc originale. Elle présente une approche pragmatique pour faire de la tolérance aux pannes. Elle utilise efficacement la mémoire temps réel et des échanges entre la supervision et l'automatisme via le service de messagerie. La mise à jour périodique réalisée par FIP réalise naturellement des points de reprise entre le contrôleur actif et les passifs. Il n'est donc pas nécessaire de mettre en place un protocole d'appartenance aux groupes, une livraison atomique et un protocole pour les points de reprise comme proposé dans [GUE 96]. De façon générale, la détection des pannes est un problème complexe dans un système asynchrone. Il est difficile d'avoir une bonne probabilité que la détection soit correcte. Ici, nous utilisons les statuts de validité temporelle pour détecter les pannes du contrôleur actif. De plus, les échanges via la messagerie CORBA permettent à la supervision d'améliorer la détection. Ainsi, nous obtenons une détection fiable qui présente une bonne probabilité de correction. Lorsqu'une faute est détectée par un passif, une négociation est engagée avec la supervision afin de vérifier que l'actif est bien fautif. Nous élisons donc un unique actif en utilisant la messagerie entre la supervision et les contrôleurs d'automatisme. L'unicité est garantie en cas de partition de la mémoire temps réel entre l'actif et le passif. Avec notre solution, l'élection d'un nouvel actif est réalisée de façon centralisée par un module de supervision qui établit un consensus entre les contrôleurs au moyen de la messagerie. Notre solution ne dégrade pas les performances car cette coordination centralisée 95

est réalisée seulement lorsqu'une panne est détectée. La détection est effectuée de façon répartie via la mémoire temps réel. De plus, le module de supervision peut gérer k+1 contrôleurs redondants afin de tolérer k fautes simultanées. La solution ne tolère cependant pas 2 fautes simultanées de la supervision et du contrôleur actif. La solution évite les basculements intempestifs en cas de partition de la mémoire temps réel. Avant d'effectuer le basculement, une solution utilisant la messagerie est proposée pour vérifier si l'état du contrôleur passif élu est cohérent. Ainsi, un basculement cohérent peut être réalisé. La solution repose sur le fait qu'un contrôleur utilise généralement un automate d'états fini pour réaliser ses traitements. Le passif recherche donc un état correspondant aux valeurs courantes des variables. Ainsi, il peut demander le basculement en indiquant s'il pense être ou non cohérent. A l'inverse d'autres solutions [BUD 93] [BRE 96] [GUE 96], un client (qui peut être une carte d'entrée déportée) n'essaie pas de retransmettre les requêtes lorsqu'il n'a pas de réponse. Ce principe n'est pas applicable dans un contexte temps réel. En effet, les requêtes sont essentiellement associées aux valeurs d entrée. Hors, dans un processus industriel, les entrées proviennent de cartes d entrée-sortie. Les entrées progressent avec la physique du procédé. Il n est donc pas possible pour la carte d entrée de retransmettre une valeur d entrée qui a changé. Sinon il faudrait modifier les cartes d entrées afin qu elles mémorisent les valeurs anciennes. Cela risquerait de nuire à leur efficacité. Une autre possibilité serait d'effectuer un retour arrière à un état cohérent afin de permettre au procédé de rejouer les opérations. Mais, un retour arrière peut être impossible (pour des raisons physiques ou mécaniques) ou bien peu nécessiter des ajustements, qui ne peuvent être réalisés par l'automatisme, pour ne pas détériorer la production. En raison de ces différentes difficultés, la supervision va permettre de décider quelle reprise doit être effectuée. La supervision peut modifier l'état du contrôleur élu grâce à la messagerie. Par exemple, elle évite une retransmission de la même opération en positionnant le nouvel actif dans l'état cohérent en écrivant à distance les variables nécessaires. De façon générale, la supervision offre la possibilité de continuer les traitements en acceptant le point de reprise présenté par l'automatisme, d'annuler la reprise en raison de sa complexité, de revenir en arrière ou tout autre type de reprise (telle qu'un traitement d'exception qui déroute la pièce en cours de fabrication vers un traitement manuel). Pour cela, elle demande via le service de messagerie CORBA à modifier les variables d état contenues dans le contrôleur d automatisme élu. L'idée consiste à considérer que le traitement de reprise doit être contrôlé par la supervision. L'application de supervision peut, par exemple, demander le recours d'un opérateur pour valider la reprise ou proposer une autre méthode. Cela peut être en effet l'opérateur qui choisit la méthode adaptée. L'application de supervision devient alors un système d'aide à la décision qui choisit, élabore et propose les méthodes de reprise. La solution que nous proposons offre les services de base afin que le système d'aide à la décision puisse connaître l'état de l'automatisme et affecter en réponse les méthodes de reprise sur cet automatisme. En effet, les méthodes de reprise automatique proposées par certains auteurs dans le cas d'une redondance passive ne sont pas directement applicables pour la commande temps réel d'un procédé de fabrication. 96

Mise en œuvre La figure 17 présente l architecture complète permettant la tolérance aux pannes franches des contrôleurs d automatisme. Au niveau le plus bas, on trouve les variables d entrée-sortie et d état qui sont répliquées soit via FIP soit via notre service mémoire. Sur chaque contrôleur, un module de gestion de la redondance (Redundancy Management) vient utiliser les statuts temporels (de FIP ou du service mémoire) et accède au code de l automatisme qui contient l automate d état. Les échanges entre le module de redondance d un contrôleur d automatisme et le module de supervision (Recovery Management) sont effectués par des appels de méthode CORBA. Ainsi la supervision dialogue, via CORBA, avec les contrôleurs d automatisme pour réaliser une détection fiable des pannes et piloter le basculement nécessaire. Les contrôleurs d automatisme existant ne permettaient pas des appels de méthode CORBA. De plus, il n aurait pas été facile d intégrer nos services mémoire dans le contrôleur. C est pourquoi l implantation a été faite entièrement avec l environnement CORBA Chorus-Cool. Nous avons implanté les différents composants (cartes d entrée-sortie et code d automatisme) afin qu ils utilisent les services mémoire. L implantation correspond à une simulation d un automatisme réparti étant donné que nous n avons pas utilisé de vraies cartes d entrée-sortie. Avec cette implantation, les temps de réponse des contrôleurs d automatisme ne sont pas bornés car la solution fonctionne sous Unix. Cependant hormis ces aspects performances, le fonctionnement est assez proche d un automatisme réel. L implantation a permis de valider les mécanismes de détection et de tolérance aux pannes. Par ailleurs, elle a montré que les services CORBA nécessaires sur le contrôle d automatisme sont réduits. L intégration d un service CORBA minimum dans les contrôleurs est donc envisageable. 97

Supervision : Recovery Management CORBA method calls Redundancy Management Automation code FIP or Memory Service Redundancy Management Automation code FIP or Memory Service I/O Var. Computing Var. I/O Var. Computing Var. Produced Values Physical bus Passive controller Active controller =Running =Copy of a consumer =Copy of a producer Fig. 17 Architecture pour la tolérance aux pannes franches d automatisme 3.3 Résultats, intervenants et perspectives Ce travail a été effectué sur la période 1993-1996. Les résultats sont donc plus anciens que ceux concernant le prototypage virtuel coopératif. Le travail a été effectué entièrement dans un cadre contractuel avec l'aérospatiale. Ces contrats s'élèvent à 300KFHT. Ainsi, les élèves de 2 ième année de l'enseirb Garnier, Kalt, Paumier, Romeo, Fauxpoint et Foucault ainsi que les mémoires d'ingénieurs Babonneau et Paumier ont participés au développement de la solution sous ma direction. De plus, Garnier a effectué un stage à l'aérospatiale dans le cadre de ces activités et a été encadré par moi pour effectuer des mises en œuvre et des tests de techniques de tolérance aux pannes. Les solutions ont été livrées à l'aérospatiale. Ces travaux ont d abord été publié de façon nationale [3] [4]. Ensuite, ils ont donné lieu à deux communications internationales sélectives [1] et [2]. Par ailleurs, les résultats plus fondamentaux, qui ont permis d'établir les propriétés d'ordonnancement du réseau de terrain FIP, ont été publiés dans [5], [6] et [7]. 98

Depuis 1996, nous avons dû délaisser les activités associées au contrôle réparti des procédés au profit des travaux sur le prototypage virtuel coopératif. En effet, nous ne pouvions mener de front les deux thèmes. Cependant, il faut noter que l'idée d'implanter un service de communication de type réseau de terrain sur Ethernet et TCP/IP était à l'époque assez neuve. Depuis, l'idée a progressée notamment chez les industriels qui font maintenant de nombreuses propositions autour d'ethernet et de TCP/IP. Ces travaux conservent donc une certaine pertinence et pourraient être poursuivis. 3.4 Publications Manifestations d audience internationale avec comité de sélection sur article: [1] C. Toinard, N. Chevassus. CORBA for distributed and fault tolerant process control. ECOOP97, Workshop CORBA: Implementation, Use and Evaluation. Jyvaskyla, Finland, June 1997. [2] C. Toinard, N. Chevassus. An object communication architecture for real time distributed process control. ECOOP97, Workshop on OO Technology and Real Time Systems, Jyvaskyla Finland, 10 june 1997. Actes publiés chez Springer Verlag comme "Lectures Notes in Computer Sciences". Manifestations d audience nationale avec comité de sélection sur résumé: [3] C. Toinard, N. Chevassus. De nouvelles architectures de communication pour le contrôle de procédés industriels: vers une répartition massive et tolérante aux fautes Real Time Systems & Embedded Systems 96. Janvier 96. Paris. Actes publiés aux éditions Teknea Toulouse ISBN 2-87717-054-3, N éditeur 064. [4] C. Toinard, N. Chevassus. Une nouvelle architecture de communication pour le temps réel réparti Real Time Systems & Embedded Systems 97. Janvier 97. Paris. Actes publiés aux éditions Teknea. Manifestations d audience nationale avec comité de sélection sur article: [5] C. Carrez, G. Florin, C. Toinard. Résultats pour la construction efficace de protocoles à diffusion qui garantissent une qualité d ordre maximale Rencontre du Parallélisme RENPAR 96. 20-24 mai 96. Bordeaux. Ecole d Eté: [6] C. Toinard. Protocoles pour diffusion ordonnée Actes de l'ecole d'eté "Réseaux de communication et techniques formelles" ENST Septembre 1994. Ouvrage Collectif: 99

[7] C. Toinard. Chapitre Protocoles pour diffusion ordonnée dans l'ouvrage collectif "Conception de réseaux de communication" Hermès 1995. 100

Bibliographie [ABD 94] Abdel-Wahad,H., Jeffay,K. 1994. Issues, problems and solutions in sharing x clients on displays. Journal pf Internet-working Research & experience, Vol.5, No.1, pp 1-15. [ABD 97] Abdel-Wahab H., Favereau J., Kim O., Kabore P., An Internet Collaborative Environment for Sharing Java Applications, IEEE Computer Society Workshop on Future Trends of Distributed Systems (FTDCS'97), Tunis, 1997. [AEG 96] AEG Schneider Automation, Inc. Modicon Modbus Plus Network I/O Servicing Guide. 840 USE 104 00 Version 2.0, March 1996. [AGAR 94] Agarwal D.A., Totem: A Reliable Ordered Delivery Protocol for Interconnected Local-Area Networks, PhD Thesis, University of California Santa Barbara, August 1994. [AMIR 92] Amir Y., Dolev D., Kramer S., Malki. D., Transis: A communication subsystem for high availability, In Annual Symposium on Fault Tolerant Computing, number 22, pages 76-78, July 1992. [AMIR 93] Amir, Y., Moser, L.E., Melliar-Smith, P.M., Agarwal, D.A., and Ciarfella, P., Fast Message Ordering and Membership Using a Logical Token-Passing Ring, In International Conference on Distributed Computing Systems, May 1993. [ARI 99] Arikawa,M., Shimojo,S., Amano,A., Maeda,K, Aibara,R, Nishimura,K., Hiraki,K., Fujikawa,K. 1999. Real-Time Spatial Data Management for Scalable Networked Augmented Virtual Spaces. IECIE TRANS. INF. & SYST., Vol.E82-D, No.1. [BAG 97] Bagrodia R., PARSEC User Manual Release 1.0, UCLA Parallel Computing Lab, 1997. [BAG 98] Bagrodia, R., Meyer, R., Takai, M., Chen, Y., Zeng, X., Martin, J., Park, B., Song, H., Parsec: A Parallel Simulation Environment for Complex Systems, Computer, Vol. 31(10), October 1998, pp. 77-85. [BAL 97] Baldoni, R., Friedman, R., and van Renesse, R.,. The Hierarchical Daisy Architecture for Causal Delivery, 17th International Conference on Distributed Computing Systems, 1997. [BAR 96] Barrus J.W., Waters C., Anderson D.B., Locales: Supporting Large Multiuser Virtual Environments, IEEE Computer Graphics and Application. November, Vol.16, No.6, pp.50-57, 1996. [BIRM 91] Birman K., Schiper A., Stephenson P., Lightweight Causal and Atomic Group Multicast, ACM TOCS Vol 9, Number 3, RFC2475, August 1991. [BLA 98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, An Architecture for Differentiated Services, Request for Comments RFC2475, December 1998. [BRE 96] T.C. Bressoud, F.B. Schneider, Hypervisor-Based Fault-Tolerance, ACM Transactions on Computer System, Vol 14, No1, February 96. [BRUT 97] Brutzman D., Zyda M., Watsen K., virtual reality transfer protocol (vrtp) Design Rationale, Workshops on Enabling Technology: Infrastructure for Collaborative Enterprises (WET ICE): Sharing a Distributed Virtual Reality, Cambridge Massachussets, June 1997. [BRO 98] Broll W., DWTP-An Internet Protocol For Shared Virtual World, International Symposium on the Virtual Reality Modeling Language VRML 98, ACM SIGGRAPH, conference proceedings, pp.49-56, 1998. [BUD 93] N. Budhiraja, K. Marzullo, F. B. Schneider, S. Toueg, The Primary-Backup Approach, In Distributed Systems, Second Edition, Edited by Sape Mullender, Addison- Wesley 1993. 101

[BUI 97] Bui, V.S., Molet, O., Comparison of two message passing approaches (PVM, MPI) for a FastDNAml parallel algorithm. Master Thesis, CNAM, 1997. [CAR 96] C. Carrez, G. Florin, C. Toinard. Résultats pour la construction efficace de protocoles à diffusion qui garantissent une qualité d ordre maximale. Rencontre du Parallélisme RENPAR 96. 20-24 mai 96. Bordeaux. [CHAN 79] Chandy, K.M., Misra, J.: "Distributed Simulation: A Case Study in Design and Verification of Distributed Program". IEEE Transactions and Software Engineering, SE- 5(5): 440_452, September 1979. [CHAN 84] Chang J., N. Maxemchuck., Reliable broadcast protocols, ACM Transactions on Computer Systems, 2(3):251-273, August 1984. [COR 97] Cornilleau, T., Gressier-Soudan, E., RT-Objects based on Temporal Causal Consistency, ECOOP97 Workshoop OO Technology and Real Time Systems, Conference Proceedings, Springer Verlag, 1997. [COS 2000] Costantini F., Sgambato A., Toinard C., Chevassus N., Gaillard F., An Internet Based Architecture Satisfying the Distributed Building Site Metaphor. IRMA2000 Multimedia Computing Track, Anchorage, Alaska, 21-24 May, conference proceedings, pp.151-155, published by IDEA Group Publishing ISBN 1-878289-84-5, 2000. [COS 2001] Costantini, F., Toinard, C., Chevassus, N., Optimizing Development of a Complex Software by Using and Extending Design Patterns, Conference proceedings, Software Engineering Track, IRMA'2001, Toronto, 20-23 May 2001. [CRI 91] Cristian F., Understanding Fault-Tolerant Distributed Systems, Communications of the ACM, Vol34, No2, February 1991. [DAN 97] Dana, P.H. Global Positioning System (GPS) time dissemination for real-time applications/ Real-Time Systems Journal, 12(1) 1997. [DAS 98] Dassault Systems CATIA Marketing Team, 4D Navigator, http://www-3.ibm.com/solutions/engineering/escatia.nsf/public/n4d, 1998. [DAS 2000] Dassault Systems, http://www-3.ibm.com/solutions/engineering/escatia.nsf/public/v5_public, 2000. [DEE 95] Deering S., Hinden R., Internet Protocol Version 6 (IPv6) Specification, Request for Comments 1883, December 1995. [DIFF 76] Diffie, W. Hellman, M., New Directions in Cryptography, IEEE Transactions on Information Theory, November, 1976. [DRO 97] Droms, R., Dynamic Host Configuration Protocol, Request For Comments 2131, March 1997. [DUS 98] Dusse S., Hoffman P., Ramsdell B., Lundblade L., Repka L., S/MIME Version 2 Message Specification, Request for Comments 2311, March 1998. [ENOA 2000] IBM/Dassault Systems, ENOVIAPM Version 3 Release 4, http://www.ibmlink.ibm.com/usalets&parms=h_200-187, June 2000. [ENOP 2000] IBM/Dassault Systems, ENOVIA Portal Solutions Version 5 Release 4, http://www.ibmlink.ibm.com/usalets&parms=h_200-191, June 2000. [ENOV 2000] IBM/Dassault Systems, ENOVIAVPM Version 1 Release 3, http://www.ibmlink.ibm.com/usalets&parms=h_200-191, June 2000. [FET 99] C. Fetzer and F. Cristian. A Fail-Aware Datagram Service. IEEE Proceedings - Software Engineering, pages 58-74, April 1999. [FIP 90] UTE, "Norme 46-602, FIP Couche application", juin 1990. [GAMM 94] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Design Patterns: Elements of Object-Oriented Software Architecture. Addison-Wesley, 1995. [GEI 92] G.A. Geist and V.S. Sunderam. Network-based concurrent computing on the PVM system. Concurrency: Practice and Experience, pages 293--311, June 1992. 102

[GGS 97] G. Guyonnet, E. Gressier-Soudan, J.Y. Simiand, F. Weiss. Une approche CORBA pour MMS: COOL_MMS. Real Time Systems Conference. Paris 97. Teknea Editors Toulouse France. [GRE 94] Gressier, E. Gestion Répartie des Données, support de cours du DEA de Systèmes Répartis, module CASR du DEA CNAM-ENST-Paris 6, 1994. [GRE 98] Greenberg S., Roseman M., Using a Room Metaphor to Ease Transitions in Groupware. Research report 98/611/02, University of Calgary, 1998. [GUE 96] Guerraoui R., Schiper A. Fault-Tolerant by Replication in Distributed Systems. In Proc. Reliable Software Technologies - Ada-Europe 96, Springer Verlag, LNCS 1088, 1996. [HAG 96] Hagsand O., Interactive Multiusers VEs in the DIVE system, IEEE Multimedia, Vol.3, No.1, pp.30-39, 1996. [HAN 97] Handley M., Crowcroft J., Network Text Editor (NTE) A scalable shared text editor for the MBone. Proceedings of ACM Sigcomm 97, Canne, France, 1997. [HAM 97] Hamilton G., The JavaBeans API specification, Sun Microsystems, 1997. [HAR 90] R.J. Harrison. Portable tools and applications for parallel computers. In International Journal of Quantum Chemistry, volume 40, pages 847--863, February 1990. [HAY 98] Hayden, M., The Ensemble System, Cornell University Technical Report, TR98-1662, January 1998. [HES 99] Hesina, G., Schmalstieg, D., Furhmann, A., Purgathofer, W. Distributed Open Inventor: a practical approach to distributed 3D graphics. In proceedings of ACM VRST'99, London, England, December 1999. [HP 99] Hewlett-Packard, CoCreate OneSpace: the Award-winning, Web enabled, CAD Independent, real-time Collaboration Solution, 1999. [HULE 96] Huleilhel N., Efficient Ordering of Messages in Wide Area Networks, Master Thesis, http://www.cs.huji.ac.il/labs/transis/publications.html, March 1996. [IEEE 95] IEEE Std 1278.1, Standard for Distributed Interactive Simulation Applications Protocols, IEEE Computer Society, 1995. [IEEEa 2000] IEEE Std 1516-2000, IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules, IEEE Computer Society, 2000. [IEEEb 2000] IEEE Std 1516.1-2000, IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification, IEEE Computer Society, 2000. [IEEEc 2000] IEEE Std 1516.2-2000, IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification, IEEE Computer Society, 2000. [IETF 2001] The MBONE Deployment Working, MBONE Deployment (mboned), 20-Jun-01, http://www.ietf.cnri.reston.va.us/html.charters/mboned-charter.html. [IP 81] Postel J., Internet Protocol, Request for Comments 791, September 1981. [IPSec 98] Kent S., Atkinson R., Security Architecture for the Internet Protocol, Request for Comments 2401, November 1998. [ISO 90] ISO, Manufacturing Message Specification Service Definition, ISO/IS 9506/1, 1990. [ITU 97] ITU-T, Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection The Directory: Authentication Framework, June 1997. [ITU 98] ITU-T, Recommandation H.235 Security and Encryption for (H.323 and other H.245-based) multimedia terminals, February 1998. [ITU 2000] ITU-T Recommendation H.323, Packet-based multimedia communications systems, November 2000. 103

[JSDT 99] Sun Microsystems, Java Shared Data Toolkit, http://www.sun.com/software/jsdt/index.html, 1999. [JEF 85] D. Jefferson, "Virtual Time", ACM Trans. on Programming Languages and systems, Vol.7, N.3, pp404-425, 1985. [KAA 89] Kaashoek, M. F., A. S. Tanenbaum, Hummel, S., Bal, H.E., An efficient reliable broadcast protocol, Operating System Review, 23(4):5-19, October 1989. [KAA 93] Kaashoek, M. F., A. S. Tanenbaum, K. Verstoep. Group Communication in Amoeba and its Application, Distributed Systems Engineering, vol. 1, no. 1, September 1993. [KEL 94] P. Keleher, S. Dwarkadas, A.L. Cox, and W. Zwaenepoel. Treadmarks: Distributed shared memory on standard workstations and operating systems. In Proceedings of the 1994 Winter Usenix Conference, pages 115--131, January 1994. [KIN 95] T. Kindberg, A Sequencing Service for Group Communication, Proc. 14th annual ACM Symposium on Principles of Distributed Computing, p.260, Aug. 1995. [KOE 2001] Koenen, R., Coding of Moving Pictures and Audio, MPEG-4 Overview - (V.18 Singapore Version), International Organisation For Standardisation, ISO/IEC JTC1/SC29/WG11-N4030, March 2001, http://www.cselt.it/mpeg/standards/mpeg- 4/mpeg-4.htm. [KUH 98] Kuhmünch C., Fuhrmann T., Schäppe G., Java Teachware - The Java Remote Control Tool and its Applications. In proceedings of ED-MEDIA'98, 1998. [LAM 78] Lamport L., Time, clocks and the ordering of events in a distributed system. CACM Vol 21, Number 7, July 1978. [LEI 97] Leigh J., Johnson A.E., Defanti T.A., Issues in the Design of a Flexible Distributed Architecture for Supporting Persistence and Interoperability in Collaborative Virtual Environments, Supercomputing, conference proceedings, pp.15-21, 1997. [LEV 98] Levine, B.N., and Garcia-Luna-Aceves, J.J., A Comparison of Reliable Multicast Protocols, ACM Multimedia Systems Journal, Vol. 6, No.5, August 1998. pp334-348. [LRMP 99] Tie Liao, Light-weight Reliable Multicast Protocol, http://webcanal.inria.fr/lrmp/index.html, 1999. [LU 95] Lu, Q, Satyanarayanan, M., Improving Data Consistency in Mobile Computing Using Isolation-Only Transactions. Proceedings of Fifth Workshop on Hot Topics in Operating Systems. Orcas Island, WA, May, 1995. [LUB 2000] Lubinski, A., Small Databases Answers for Small Mobile Resources, Conference Proceedings, Intelligent Interactive Assistance and Mobile Multimedia Computing (IMC 2000), Rostock-Warnemünde, Germany, 9-10 November 2000. [MAC 95] Macedonia M.R., Zyda M.J., Pratt D.R., Brutzman D.P., Barham P.T. 1995. Exploiting Reality with Multicast Groups, IEEE Computer Graphics and Applications, Vol.15, No.5, pp.38-45, 1995. [MAC 95b] Macedonia, Michael R., A Network Software Architecture For Large Scale Virtual Environments, Ph.D. Dissertation, Naval Postgraduate School, Monterey, California, June, 1995. [MAL 96] C.P. Malloth "Conception and implementation of a toolkit for building faulttolerant distributed applications in large scale networks", Thèse de Doctorat. Ecole Polytechnique Fédérale de Lausanne. 1996. [MAL 97] Maly, K., Abdel-Wahab, H., Overstreet, C.M., Wild, C., Gupta, A., Youssef, A., Stoica, E., Al-Shaer, E. 1997. Interactive Distance Learning over Intranets. IEEE Journal of Internet Computing, Vol 1, No. 1, pp. 60-71. [MAM 94] Mammeri, Z., Thomesse, J.P. 1994. Réseaux locaux industriels: FIP et MAP dans les systèmes automatisés. Eyrolles. 104

[MEN 98] Mentré, D., Priol., T., Noa: A Shared Virtual Memory over a SCI Cluster. Proceedings of SCI Europe'98, Technology and Applications, H. Hellwagner, A. Reinefeld (eds.), pages 43-50, Bordeaux, France, Septembre 1998. [MIC 99] Microsoft, NetMeeting, http://www.microsoft.com/windows/netmeeting/features/default.asp, June 1999. [MIL 92] D.L. Mills. Network Time Protocol (Version 3) Specification, Implementation. RFC1305, March 1992. [MIS 93] Mishra S., Peterson L.L., Schlichting R.D., Consul: a communication substrat for fault-tolerant distributed programs, Distrib. Syst. Engng 87-103, 1993. [MIS 86] Misra J., "Distributed Discrete-Event Simulation", ACM Computing Surveys, Vol. 18, N. 1, pp.39-65, 1986. [MMS 90] ISO. 1990. Manufacturing Message Specification Service Definition. ISO/IS 9506/2. [MOS 96] L.E. Moser, P.M. Melliar-Smith, D.A. Agarwal, R. Budhia, C. Lingley- Papadopoulos, "Totem: A Fault Tolerant Multicast Group Communication System". Communications of the ACM, 39(4):54-63, April 1996. [MPEG 98] Eleftheriadis, A., Herpel, C., Rajan, G., Ward, L., Text for ISO/IEC FCD 14496-1 Systems, ISO/IEC JTC1/SC29/WG11CODING OF MOVING PICTURES AND AUDIO, May 1998. [MPI 94] Message Passing Interface Forum. MPI: A message-passing interface standard, version 1.0, May 1994. [NET 98] Netscape, Netscape Conference, http://home.netscape.com/communicator/conference/v4.0/index.html, 1998. [OMG 97] Object Management Group, Control and Management of A/V streams specification, OMG Document telecom/97-05-07 edition, 1997. [OMG 2000] Object Management Group, Fault Tolerant CORBA, orbos/2000-01-19. [OMG 99] Object Management Group. CORBAmanufacturing: Manufacturing Domain Specifications. Version 1.0, October 1999. [PAR 92] Parasoft Corporation, Pasadena, CA. Express user's guide, version 3.2.5, 1992. [POS 80] Postel J., User Datagram Protocol, Request For Comments 768, 28 August 1980. [POS 81] Postel J., Transmission Control Protocol, Request For Comments 793, September 1981. [RMI 99] Sun Microsystems, Java Remote Method Invocation (RMI), http://www.javasoft.com/j2se/1.3/docs/guide/rmi/index.html, 1999. [ROSE 96] Roseman M., Greenberg S., Building real time groupware with GroupKit, a groupware toolkit, ACM Transactions on Computer Human Interaction, 3(1), pp. 66-106, 1996. [RAD 96] R. Radhakrishnan, T. J. McBrayer, K. Subramani, M. Chetlur, V. Balakrishnan, and P. A. Wilsey, A Comparative Analysis of Various Time Warp Algorithms Implemented in the WARPED Simulation Kernel, Proceedings of the 29th Annual Simulation Symposium, 107-116, March 1996. [REN 95] R. Van Renesse, K.P. Birman, R. Friedman, M. Hayden, and D. Karr, A Framework for Protocol Composition in Horus, ACM Symposium on Principles of Distributed Computing, August 1995. [ROH 94] Rohlf, J., Helman, J., Iris Performer: a high performance multi-processing toolkit for real-time 3d graphics, In Proceedings of ACM SIGGRAPH 94, PP 381-394. 1994. [RSVP 97] Braden R., Zhang L., Berson S., Herzog S., Jamin S., Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification, Request for Comments 2205, September 1997. 105

[SAD 99] Saddik A., Karaduman O., Fischer S., Steinmetz R., Collaborative Working with Stand-Alone Applets. Proc. Of Intelligent Mutimedia and Distance Education ISIMADE'99, Baden-Baden, Germany, 1999. [SDP 98] Handley M., Jacobson V., SDP: Session Description Protocol, Request For Comments 2327. 1998. [SCH 96] Schulzrinne H., Casner S., Frederick R., Jacobson V., RTP: A Transport Protocol for Real-Time Applications, Request For Comments 1889, January 1996. [SHI 98] Shirmohammadi S., Oliveira J.C., Georganas N.D., Java-Based Multimedia Collaboration: Approaches and Issues. Proc. International Conference On Telecommunications (ICT '98), Vol. I, Porto Carras, Greece, 1998. [SCHM 98] Schmidt,D., An Architectural Overview of the ACE framework. A Case-study of Successful Cross-platform Systems Software Reuse, USENIX login magazine, Tools special issue, November, 1998. [SCHUL 99] Schulze,T., Straßburger,S., Klein,U. Migration of HLA into Civil Domains: Solutions and Prototypes for Transportation Applications. SIMULATION, Vol. 73, No. 5, pp 296-303, November 1999. [STRA 92] Strauss, P.S., Carey, R., An Object-Oriented 3D Graphics Toolkit, In Computer Graphics (Proc. ACM SIGGRAPH 92), 341-349, August 1992. [TEAM 2000] TeamWave, TeamWave Workspace Overview, http://www.teamwave.com/advantages/index.html, April 2000. [TCS 99] Toinard C., Chevassus N., Sgambato A., Collaborative Virtual Reality and the Distributed Building Site Metaphor, WSCG'99, The 7-th International Conference in Central Europe on Computer Graphics, Visualization and Interactive Digital Media'99, conference proceedings, pp. SP/111-117, 1999. [TLS 2000] Dierks T., Allen C., The TLS Protocol Version 1.0, Request for Comments 2246, January 1999. [TOI 92] Florin G., Toinard C., A new way to design causally and totally ordered multicast protocols, ACM Operating Systems Review, Volume 26, Number 4, October 1992. [TOI 93] Toinard C., Study of ordered group communications, PhD Thesis, University Paris6. 1993. [TOI 97] Toinard C., Chevassus N., An object communication architecture for real time distributed process control, ECOOP97, Workshop on OO Technology and Real Time Systems, Conference Proceedings, Springer Verlag, Lectures Notes in Computer Sciences, Object Oriented Technology ECOOP'97 Workshop Reader, June 1997. [TOI 98] Toinard C., Chevassus N., Virtual world objects for real-time cooperative design of manufacturing systems, Lecture Notes in Computer Sciences, Object Oriented Technology ECOOP'98 Workshop Reader, Springer Verlag, conference proceedings, pp. 525-528, 1998. [TOI 99] Toinard C., Florin G., Carrez C., A Formal Method to Prove Ordering Properties of Multicast Systems, ACM Operating Systems Review, Vol. 33, No.4, pp.75-89, 1999. [TOI 2000] Toinard C., CTOP: a causally and totally ordered multicast service running over the Internet, NOTERE'2000, Conference Proceedings, November 2000. [US 93] U.S. Department of Commerce, Data Encryption Standard (DES), FIPS PUB 46-2 (C13.52), December 30, 1993. [UTE 90] UTE, "Norme 46-602, FIP Couche application", juin 1990. [WAH 97] Wahl, M., Howes, T., Kille, S., Lightweight Directory Access Protocol (v3) Request for Comments 2251, 1997. [VER 89] P. Verissimo, L. Rodrigues, M. Baptista, "AMp: A highly parallel atomic multicast protocol", In Proceedings of SIGCOM'89 Symposium, pages 83-93. ACM, 1989. 106

[WHE 94] Whetten, B., Montgomery, T., Kaplan, S., A high performance totally ordered multicast protocol, Theory and Practice in Distributed Systems, number 938 LCNS, Springer Verlag, Berlin, 1994. http://research.ivv.nasa.gov/rmp/. [W2W 97] Sense 8, World2World Release 1 Technical Overview, 1997. [XML 98] W3C, Extensible Markup Language (XML) 1.0, W3C Recommendation REC-xml- 19980210, 10 February 1998. [ZEL 96] Zeleznik, R.C., Herndon, K.P. and Hughes, J.F., SKETCH: An Interface for Sketching 3D Scenes, Proceedings of SIGGRAPH "96, Computer Graphics, Annual Conference Series, 1996, pp. 163-170. [ZEL 2000] Zeleznik, B., Holden., L., Capps, M., Abrams, H., and Miller, T., Scene-Graph- As-Bus: Collaboration between Heterogeneous Stand-alone 3-D Graphical Applications, Eurographics 2000, August 2000 107

108