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

Transcription

1 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

2 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

3 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

4 PLAN 1. Introduction Motivation et démarche Prototypage virtuel coopératif Objectifs et besoins Travaux existants Apports Contrôle réparti de procédés industriels Objectifs et besoins Travaux existants Apports Déroulement, encadrements, contrats, projet européen, publications Prototypage virtuel coopératif Motivation Principe et justification de notre solution Conception coopérative Services pour la simulation répartie Conception coopérative Etat de l art Environnements industriels de CAO coopératifs Réalité virtuelle répartie Discussion La solution de la métaphore du chantier réparti Présentation de la métaphore Implantation de la solution Travaux comparables et discussion Simulation répartie Etat de l art Simulation à évènements discrets Systèmes à diffusion ordonnée La solution CTOP Résultats formels obtenus Description de la solution CTOP Comparaisons et discussions Simulation discrète versus systèmes à diffusion ordonnée Comparaisons avec d autres systèmes à diffusion ordonnée Résultats, intervenants et perspectives Publications Contrôle réparti des procédés industriels Motivation Principe et justification de notre solution Résultats, intervenants et perspectives Publications...99 Bibliographie

5 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

6 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 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

7 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

8 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

9 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 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

10 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

11 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

12 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 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

13 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

14 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

15 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 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

16 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 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

17 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 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

18 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

19 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

20 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