Conception et réalisation d un système d instrumentation distribuée basé sur l architecture Jini

UNIVERSITE LIBRE DE BRUXELLES Faculté des Sciences appliquées Ecole Polytechnique Année académique 2000-2001 Conception et réalisation d un système d instrumentation distribuée basé sur l architecture Jini Promoteurs : Prof. Francis Grenez Prof. Hugues Bersini Philippe De Doncker Travail de fin d études présenté par Jean-Michel Dricot en vue de l obtention du grade d ingénieur civil informaticien

Remerciements Je tiens à remercier ici tout ceux qui de près ou de loin ont contribué à la réalisation de ce mémoire. Même si ce travail est avant tout l oeuvre d une seule personne, je n aurais pu aboutir sans les conseils avisés et les encouragements de mes promoteurs. J aimerais d abord remercier tout particulièrement le Professeur Francis Grenez ainsi que Mr. Philippe De Doncker pour leur aide, leur disponibilité et le soutien dont ils ont fait part tout au long de cette année. J ai été fort touché par leurs initiatives à mon égard et leurs encouragements qui ont permis la publication et la présentation de ce travail, m offrant de par là même un atout considérable au moment d entamer une carrière académique. Je voudrais également remercier le Professeur Hugues Bersini de m avoir offert la possibilité de découvrir la technologie Jini, marriant si subtilement l Informatique à l Electronique. Je tiens à remercier personellement Mr. Esteban Zimányi, à la fois Professeur et ami, qui a su prendre le temps de me conseiller à de nombreuses reprises quant la redaction de cet ouvrage. Il va sans dire que je remercie les membres du Service d Electricité Générale pour leur sympathie et leur acceuil chaleureux, une année durant, dans leurs locaux. J ai une pensée pour tous mes camarades de promotion dont l optimisme, la bonne humeur et la fraternité m ont permis de vivre pendant toutes ces années une amitié extraordinairement épanouissante. Je ne voudrais pas non plus oublier mon Amoureuse qui a toujours trouvé la force et la patience de me soutenir lorsque j en avais besoin. Enfin, j aimerais faire plus que de simples remerciements à mes Parents qui ont traversé avec moi toutes ces années d étude à l Université. Les épreuves que j ai traversées ont été les leurs également, et la moindre des choses que je puisse faire pour leur prouver ma gratitude est de leur dédier ce mémoire. 1

Table des matières I Étude théorique 6 1 Instrumentation Virtuelle 7 1.1 Introduction et Motivation........................... 7 1.2 Le contrôle local des appareils de mesure................... 9 1.2.1 GPIB.................................. 9 1.2.2 La programmation visuelle....................... 12 1.3 Instrumentation distribuée........................... 14 1.3.1 Introduction............................... 14 1.3.2 IEEE 1451................................ 15 1.3.3 GPIB-Enet............................... 16 1.3.4 Limitations............................... 18 2 CORBA 20 2.1 Introduction................................... 20 2.2 Architecture................................... 21 2.2.1 IDL................................... 22 2.2.2 l ORB et l IIOP............................. 23 2.2.3 Le mécanisme de marshallisation................... 25 2.2.4 Les Objets standards.......................... 27 2.3 Conclusion.................................... 28 3 JAVA et RMI 29 3.1 Introduction................................... 29 3.2 La technologie Java............................... 30 3.3 RMI....................................... 32 3.3.1 Le modèle proposé par Java : RMI.................. 33 3.3.2 Le transfert dynamique de code mobile................ 34 3.4 Java hardware : le PicoJAVA......................... 36 4 Architecture Jini 38 4.1 Introduction................................... 38 4.2 Architecture et principe............................ 39 4.3 Le modèle d interaction dynamique...................... 42 2

4.3.1 Interrogation du Lookup par les clients................ 42 4.3.2 Le concept de Leasing......................... 44 II Réalisation d un système d instrumentation distribuée 48 5 Positionnement de JINI par rapport aux solutions actuelles 49 5.1 CORBA..................................... 50 5.1.1 Introduction............................... 50 5.1.2 Aspects communs............................ 50 5.1.3 Éléments de distinction......................... 51 5.1.4 Conclusion................................ 52 5.2 UPNP...................................... 52 5.2.1 Introduction............................... 52 5.2.2 Principes................................ 52 5.2.3 Éléments de distinction......................... 53 5.3 IEEE 1451.................................... 53 5.4 Conclusion.................................... 54 6 Contrôle local des instruments de mesure en Java 55 6.1 Contrôle local des instruments GPIB..................... 55 6.2 l interface standard IEEE 488 pour Java................... 56 7 Utilisation de JINI dans le cadre de l instrumentation virtuelle 61 7.1 Introduction................................... 61 7.2 Interfaçage des instruments de mesure.................... 62 7.2.1 Interfaces standardisées......................... 62 7.2.2 Introspection dynamique des capacités des instruments....... 65 7.3 Exploitation du réseau............................. 67 7.3.1 Les domaines.............................. 67 7.3.2 Instrumentation distante........................ 67 7.4 Les apports propres à Jini........................... 68 7.4.1 Robustesse................................ 68 7.4.2 Interfaces graphiques.......................... 69 8 Intégration de Jini dans les solutions actuelles 71 8.1 Motivation.................................... 71 8.2 Implantation d une interface de programmation visuelle intégrant Jini... 72 8.3 Conclusions................................... 75 9 Conclusion et perspectives 80

Introduction Contexte de travail Le développement et l utilisation des instruments de mesure programmables sont actuellement largement exploités, tant dans le monde académique que dans les industries, menant à des résultats et à des mises en oeuvre prometteuses. Ceci découle principalement de la possibilité d utilisation d architectures programmables présentant actuellement des performances élevées à un coût raisonnable. En particulier, la capacité de modifier le processus de prise de mesure en repensant uniquement l algorithme exécuté par l ordinateur de contrôle et ce, sans remplacer la moindre pièce matérielle, rend l expérimentation plus modulaire, réutilisable et flexible. Le développement de composants d acquisition de mesure génériques et réutilisables, notamment par une approche orientée objet, a permis de réduire drastiquement les coûts de développement et de mise à niveau des laboratoires de mesure. Un certain nombre de standards existent afin de permettre le contrôle de senseurs ou d actuateurs depuis des stations de travail ordinaires. A ces standards éléctriques sont associés des outils logiciels facilitant la mise en oeuvre, souvent fastidieuse, de ces appareils. Problématique L introduction de cette approche et l élaboration des moyens logiciels qui les accompagne remonte à près de vingt ans. L Informatique et l Electronique ont connu, au cours de ces deux dernières décénies, des évolution majeures. Les ordinateurs présentent des puissances de calcul croissantes et sont actuellement presque toujours intégrés dans des réseaux locaux ou globaux, à l instar d Internet. De telles capacités, en terme de traitement des mesures, de stockage de données issues d interaction entre appareils, sont peu ou pas utilisées dans le cadre de l instrumentation. Les modèles mis en oeuvre dans les solutions actuelles ne peuvent tirer un bénéfice de cette explosion de nouvelles technologies, privant ainsi l ingéniérie de la mesure et du signal d outils précieux. 4

Contributions Le présent travail tente d apporter une solution à ce problème sous la forme de l utilisation d un nouvelle technologie connue sous le nom de Jini. Jini propose un modèle d interaction dynamique tirant bénéfice de la plateforme orientée objet Java. Ainsi, nous avons été à même de créer un réseau d instrumentation distribué dans lequel les appareils, actuateurs ou senseurs, sont à même d interragir entre eux et avec des logiciels clients de manière totalement transparente. Les contraintes de robustesse, vis-à-vis des pannes ou de la qualité du réseau, ont pu être intégrées dans cette technologie au moyen d une étude de Jini attachée spécifiquement à répondre aux besoins de l instrumentation. Une intégration de cette solution dans les logiciels existants, tels que LabVIEW, est également possible. Cheminement de l exposé Le présent manuscrit comporte deux parties. Une introduction théorique initie le cheminement. Dans un premier temps nous situerons le contexte de la prise de mesure ainsi que les technologies utilisées jusqu à présent pour réaliser celle-ci. Nous exposerons ensuites certaines techniques d interaction entre objets à travers le réseau qui nous permettrons dans le début de la seconde partie de justifier le choix de Jini comme solution à la problématique spécifique des instruments distribués. Nous poursuivrons en détaillant la réalisation complète d un système d instrumentation distribuée se basant sur la plateforme Java et l architecture Jini. Enfin, il sera montré comment il est possible d intégrer la solution proposée dans les logiciels existants. Un cédérom complète le présent travail. Il contient l ensemble des annexes,le programme de contrôle JiniLab ainsi que le code source des services Jini développés. Ce média a été remis au Professeur Grenez et est conservé dans la bibliothèque du Service d Electricité Générale.

Première partie Étude théorique 6

Chapitre 1 Instrumentation Virtuelle Sommaire 1.1 Introduction et Motivation..................... 7 1.2 Le contrôle local des appareils de mesure............ 9 1.2.1 GPIB................................. 9 1.2.2 La programmation visuelle..................... 12 1.3 Instrumentation distribuée..................... 14 1.3.1 Introduction............................. 14 1.3.2 IEEE 1451.............................. 15 1.3.3 GPIB-Enet.............................. 16 1.3.4 Limitations.............................. 18 1.1 Introduction et Motivation Le concept d instruments virtuels [26] a été introduit à la base pour simplifier la conception, l implantation et l utilisation de systèmes d instrumentation programmables en adoptant une interface visuelle. La programmation visuelle permet une réalisation avant tout conceptuelle du processus de prise de mesure, permettant ainsi aux personnes peu versées dans la programmation de mettre au point rapidement des algorithmes performants. Le programme y est décrit de manière graphique en sélectionnant et en assemblant des blocs fonctionnels présents dans des bibliothèques de développement. Ce type d approche, présentant des interfaces graphiques ressemblant aux instruments réels, rend ainsi l utilisation et la compréhension de l instrumentation virtuelle plus aisée pour les personnes expertes en expérimentation réelle. 7

1.1. INTRODUCTION ET MOTIVATION l utilisation du réseau a depuis peu été incorporée aux processus de prise de mesure avec beaucoup de succès. Cette nouvelle approche fonctionnelle permet en effet non seulement d interconnecter des instruments entre eux, mais également de créer des zones de post-traitement des données, comme des bases de données ou des logiciels de DSP. Cette configuration est particulièrement rentable, tant d un point vue économique que du point de vue de l utilisation efficace des ressources disponibles sur le réseau local du laboratoire, mais peut également se révéler nécessaire lorsque les points de mesure sont fortement disséminés ou distants et qu il deviendrait donc financièrement inabordable d y adjoindre un post-traitement informatique. Fig. 1.1 l utilisation de l instrumentation virtuelle permet l exploitation d une large variété de ressources, notamment celles fournies par les ordinateurs de contrôle et plus récemment, l intégration des réseaux locaux industriels ou de l Internet Enfin, le développement de systèmes embarqués présentant des puissances de calcul pour un coût acceptable et l émergence de technologies d interconnexion permettant de créer spontanément des réseaux nomades offrent des possibilité nouvelles qui permettent l introduction efficace d une composante logicielle à même le système ou situé dans un proche voisinage. 8

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE 1.2 Le contrôle local des appareils de mesure Les systèmes classiques de contrôle local des appareils par un PC offrent l avantage de pouvoir confiner en un même lieu les composants matériels d expérimentation chargés de l acquisition ainsi que les éléments chargés du contrôle des instruments et de la mise à jour des données. Toutes les opérations relatives à la prise de la mesure sont effectuées par un logiciel spécialisé. Ce schéma de conception et de déploiement a conduit à standardiser les cartes d entrées/sorties dévolues à l acquisition et la mise à jour du signal, tout en diminuant le coût global du processus entier d expérimentation (e.g. l acquisition, la maintenance mais aussi le développement logiciel et la prise en charge de la formation des techniciens). De nombreuses initiative relatives à la standardisation et l interfaçage ont été entreprises depuis longtemps par les industriels. Cependant, l analyse des solutions existantes sur le marché montre qu il n existe pas de standard ouvert universellement adopté mais uniquement deux systèmes propriétaires embrassés par une partie extrêmement importante des utilisateurs. Il s agit d une part de l utilisation du bus GPIB afin de permettre la connexion cohérente d appareils de mesure et d appareils de contrôle, PC par exemple. d autre part, du point de vue de l interfaçage et de la programmation visuelle, LabVIEW de la société National Instruments sera évoqué ici afin de bien montrer comment on peut utiliser les concepts proposés par le modèle de l instrumentation virtuelle. 1.2.1 GPIB Le bus GPIB, standardisé sous les références IEEE 488.1 et IEEE488.2 est un système d interconnexion des instruments imaginé par Hewlett-Packard en 1975. Anciennement connu sous la dénomination HPIB, ce modèle de bus est constitué d un certain nombre d éléments standardisés : 1. une interface électrique permettant l envoi d information et du statut actuel des périphériques de la ligne. 2. la possibilité de connecter des appareils sans les différencier au vu de leur rôle spécifique : envoi ou réception de données. Chaque appareil est vu comme un noeud du système à même d émettre ou de recevoir une information à un moment donné. 3. un modèle de communication basé sur l envoi de messages entre les appareils sous forme de chaînes de caractères. Chaque appareil est capable de répondre aux sollicitations par renvoi d un message et par l ajustement du statut de la ligne afin de refléter l état actuel du bus ou signaler une erreur. Notons enfin que 14 appareils sont ainsi connectables sur un bus GPIB sur une longueur totale ne dépassant pas 20 mètres. Le concept du contrôleur et des périphériques proposé par le IEEE 488.1 est illustré aux figures 1.2 et 1.3. Les contrôleurs ont la capacité d envoyer des commandes, de présenter 9

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE des données sur le bus et d écouter les messages envoyés par les périphériques. Le contrôle du bus peut passer à tout moment du Contrôleur en Charge (CIC : Controller In Charge) actif à n importe quel autre périphérique ayant la capacité d être un contrôleur. Un et un seul contrôleur du système est défini comme étant le Contrôleur Système global (System Controller) est sera désigné à l instant initial comme Contrôleur en Charge. Controller Device #1 Control, Talk, Listen Talk, Listen Piggyback Cables Device #n Talk, Listen Fig. 1.2 Schématisation du bus IEEE 488.1 Fig. 1.3 Le chaînage des appareils IEEE 488.1 sur le bus s effectue sans disposition particulière. Les périphériques sont identifiés sur la chaîne via un adresse unique qu ils doivent posséder lors de la mise en service de l appareil. Cette adresse est usuellement imposée par l expérimentateur au moyen du panneau frontal de l appareil. Les adresses sont faites de deux parties : un adresse primaire, comprise entre 0 et 31 et une adresse secondaire utilisée pour adresser des éléments particuliers internes à l appareil considéré. Par exemple, un appareil utilisé pour interfacer plusieurs ports série aura une adresse secondaire pour 10

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE chaque canal de transmission contrôlé. Notons que bien que 31 adresses soient disponibles, GPIB limite à 14 le nombre d appareils adressables sur un même bus à un moment donné. Lors de l utilisation, certains appareils sont dédiés uniquement à écouter et d autre à parler. On parle de modèle talker listener. Ceci permet de réaliser une communication sans nécessiter l existence d un contrôleur global pour tout le système : lorsqu un appareil parle, tous les autres écoutent. Lorsqu un appareil désire parler, il le signale sur le bus et devient l unique Contrôleur en Charge du bus. Lorsqu un instrument émet, les messages peuvent êtres envoyés pour toute la ligne ou adressés à un appareil particulier. IEEE 488.1 : Interface électrique L interface électrique présentée par les appareils compatibles GPIB repose sur un modèle de transmission des informations en parallèle. Les 16 lignes utiles sur le connecteur se divisent comme suit : 8 bits sont alloués à la transmission bidirectionnelle des informations, 3 au handshake et 5 permettent la signalisation de l état du bus et l envoi d évènements. Cette interface est largement décrite dans les documents [6], notons seulement qu il est toujours possible de réinitialiser un périphérique ou le bus entier via une des lignes ainsi que détecter les erreurs éventuelles par le changement d état de la ligne correspondante. IEEE 488.2 : Messages La normalisation IEEE 488.1 décrit un modèle de mise en oeuvre d un bus d interconnexion pour les instruments mais ne fournit aucune information quant à la normalisation des messages entre appareils. Certains détails, tels l utilisation ou non du retour à la ligne comme fin de communication, pouvait mettre à mal l interopérabilité voulue par GPIB. De même, les commandes les plus utiles ou les plus courantes (remise à zéro, extinction, identification,etc. ) ont souvent été implantées par les constructeurs de manière non uniforme, mettant ainsi au point un set de commande propre à chaque compagnie, voire à chaque appareil. Afin de standardiser la mise au point de logiciels de contrôle, Tektronix a proposé en 1985 une formalisation standard qui fût adoptée en 1987 sous la norme IEEE 488.2. Le nouveau standard spécifie un format unique d envoi de messages, un set de commandes de base commun ainsi qu une structure générique permettant d interroger l appareil sur son statut. Par exemple, l envoi de la commande *IDN? indique à l appareil qu il doit renvoyer son identification. Conclusion L utilisation d un standard électrique et la définition d un format commun d envoi de messages ont permis la mise au point de bibliothèques de fonctions accélérant ainsi le développement de logiciels de contrôle. Ces bibliothèques existent en accès libre [2] et ont ainsi pu servir de base au contrôle des instruments utilisés pour la mise en oeuvre et la commande des appareils, selon un schéma décrit dans la seconde partie de l ouvrage. 11

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE 1.2.2 La programmation visuelle l idée même de développer des outils de programmation visuelle afin d asservir des systèmes de mesure a été introduite en 1985 par la firme National Instruments. Son logiciel LabVIEW est actuellement largement utilisé par nombre de milieux académiques et industriels. Il a pour but de faciliter la mise en oeuvre de l acquisition et du post-traitement des mesures prises en laboratoire. Il utilise à cette fin les capacités graphiques des ordinateurs d entrée de gamme actuels. Les interfaces graphiques qu il met en oeuvre sont basées sur un ensemble organisé de fenêtres et d icônes interagissant entre elles afin de présenter à l utilisateur une schématisation du processus expérimental ainsi qu un certain nombre de grandeur de sortie. Fig. 1.4 Une session LabVIEW standard présentant le résultat d une acquisition sous forme d un graphe 12

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE Sur la fenêtre de base d une telle application se trouvent des représentations graphiques (icônes) de contrôleurs conventionnels (e.g. boutons, sélecteurs, potentiomètres) et d indicateur de sortie (e.g. oscillogrammes, lumières, valeurs numériques) familiers des expérimentateurs. La présentation sélective et organisée des données et des commandes offre le double avantage de spécifier les interactions avec les appareils et de minimiser les informations présentées à l utilisateur, le laissant ainsi se focaliser pleinement sur les éléments importants de la prise de mesure. l utilisateur agit sur l icône comme il agirait sur l instrument réel, en particulier, l utilisation de la souris permet d agir avec des composants symboliques de la même manière que les doigts de la main agiraient sur des boutons présents sur la face de l appareil. l utilisation d un modèle de programmation graphique, que nous avons déjà évoqué, fut importé de l informatique théorique afin de simplifier la conception des procédures d expérimentation en se basant sur des concepts fortement orientés-objet. Il est ainsi possible de décrire le processus de mesure sans devoir passer par un langage conventionnel de programmation procédurale. Dans un langage classique, les séquences d opération sur les données doivent être spécifiées selon une syntaxe peu accessible et souvent réservée aux seuls informaticiens ou ingénieurs. En programmation visuelle, les données et les opérations sont représentées par des icônes. Le programme lui-même est obtenu en dessinant un diagramme procédural restant à un niveau fort conceptuel. Les noeuds de ce graphe sont des opérations de haut niveau, typiquement du traitement de signal, des opérations arithmétiques, mais ils peuvent également être associées à des opérations de visualisation des données ou à un contrôle des instruments de mesure. Chaque noeud a des connecteurs d entrées et des connecteurs de sortie auxquels il suffit d attacher les bons fils afin de réaliser une opération donnée. Les éléments de base étant trop simples pour la plupart des expérimentations, des diagrammes préétablis peuvent être importés aisément, menant ainsi à une conception modulaire des programmes et à la mise à disposition de larges bibliothèques d instrumentation virtuelle appelées VI (Virtual Instrumentation element). Il existe des VI pour à peu près tous les instruments contrôlables depuis un PC. Ces VI servent donc bien souvent de gestionnaire de périphérique quasi-universels pour autant que l instrument soit connectable au PC de contrôle via un connecteur de type RS-232, parallèle ou GPIB. Notons enfin que l utilisation massive d une telle technique a un impact psychologique important sur la catégorie d utilisateurs amenés à utiliser ce produit : en effet, relier un appareil à un affichage présentant le résultat de la mesure prise par cet appareil revient simplement à tirer un fil de la sortie de l icône de l appareil et à le connecter sur une borne d entrée de l icône représentant l afficheur ; c est pourquoi les systèmes d instrumentation virtuels sont devenus aujourd hui un élément incontournable lorsqu il s agit d intégrer les techniques informatiques à la prise de mesure. 13

1.3. INSTRUMENTATION DISTRIBUÉE 1.3 Instrumentation distribuée 1.3.1 Introduction Tant dans la littérature [21] [7] [15] que dans la pratique, de nombreux exemples montrent l utilisation des réseaux afin d étendre les capacités de mesure et de traitement des systèmes de mesure exploités dans des environnements d instrumentation virtuelle. Ce besoin découle d un certain nombre de limitations inhérentes à l utilisation des architectures mettant en oeuvre des ordinateurs. La première limitation provient souvent du nombre de signaux qu il faut acquérir simultanément. Il arrive souvent en effet que le nombre d entrées des cartes d acquisition sur une même machine ne soit pas suffisant ou que la machine ne puisse fournir à elle seule la puissance nécessaire à la prise de mesure. l utilisation du réseau permet ici le déploiement de sous-systèmes de mesure, étendant ainsi la capacité de traitement de l unité d expérimentation. Des standards tels que Fastbus, GPIB, etc. ont été proposés il y a longtemps et sont maintenant utilisés à grande échelle dans l industrie, tout particulièrement lorsque des systèmes et des processus complexes doivent pouvoir être vérifiés et contrôlés en temps réel. Une seconde restriction découle de l aire d opération accessible par une même unité de traitement. Il suffit de penser par exemple aux fabriques chimiques ou pétrolières dont les différents processus sont disséminés sur une superficie élevée et présentant un besoin de sécurité globale important. Quel que soit l environnement, les senseurs et les cartes d acquisition ne peuvent être situés trop loin d une source, sous peine de voir le signal entaché de fortes perturbations. De même, le contrôle local d appareil impose une distance maximale entre l appareil et l unité en charge du traitement : typiquement 20 mètres pour GPIB. Si le signal doit être acquis sur une source distante, l exploitation d un réseau permet de rapprocher les instruments, les sources et les sous-systèmes d expérimentation, garantissant ainsi une qualité optimale pour le signal acquis de la source. Enfin, une troisième limitation est liée au traitement qui sera effectué sur le signal. Plus la complexité de calcul de l algorithme de post-traitement sera élevée, plus grandes seront les ressources prélevées sur le PC, rendant éventuellement impossible tout contrôle en temps réel. Pour palier à cela, des cartes de traitement de signal (DSP) sont adjointes au processeur de base, augmentant ainsi le coût ou la gamme de processeur requis. Une autre solution consiste à utiliser massivement les machines présentes sur le réseau pour distribuer les besoins de calcul et optimiser l utilisation des possibilité de traitement local. La promiscuité des interconnexions rend les communications entre noeuds de mesure quasi instantanées. Pour un réseau dédié uniquement à l acquisition, le trafic global généré sur un réseau commercial de faible coût (e.g. 10Mbps) est assez peu élevé, et il en résulte que pratiquement aucun retard n est introduit suite à une éventuelle contention. 14

1.3. INSTRUMENTATION DISTRIBUÉE 1.3.2 IEEE 1451 IEEE 1451 [15] est une nouvelle norme dont le but est de fournir un cadre cohérent et ouvert permettant la mise en relation d appareillages de faible capacité mémoire et dont les possibilités se réduisent à opérer des prises de mesure en un point donné. La philosophie générale du développement de ce standard repose sur la création d une volonté d uniformiser les interfaces des appareils et ce en ajoutant, de manière incrémentale, des capacités à celles déjà existantes, tout en conservant le coût de la transition accessible à tous les vendeurs de l industrie. Le standard envisagé propose également l indépendance vis-à-vis de la couche réseau mise en oeuvre ainsi que l indépendance vis-à-vis du type de microprocesseur embarqué sur le système. La famille 1451P consiste en la proposition et le développement de 4 standards : 1. IEEE 1451.1, Network Capable Application Processor (NCAP) 2. IEEE 1451.2, Transducer to Microprocessor and Transducer Electronic Data Sheet (TEDS) Format 3. IEEE 1451.3, Digital Communication and Transducer Electronic Data Sheet (TEDS) Format for Distributed Multidrop Systems 4. IEEE 1451.4, Mixed Mode Communication Protocols and TEDS Formats La figure 1.5 présente les différents composants présents dans un système de transducteurs compatibles avec la spécification que nous venons d évoquer. Fig. 1.5 Architecture d un système de transducteurs IEEE 1451. Le premier groupe de travail (1451.1) a été chargé de définir un modèle d information pour la mise en réseau de transducteurs intelligents. Il définit également les spécifications 15

1.3. INSTRUMENTATION DISTRIBUÉE de l interface logique. Le second groupe a défini le TEDS ainsi que l interface et les protocoles de communication à mettre en oeuvre afin de permettre la communication entre le transducteur et le contrôleur responsable de la prise en charge de la composante réseau. Le TEDS est stocké dans une EEPROM 1 et contient des champs décrivant complètement le type, les opérations accessibles, la calibration et les attributs secondaires du transducteur. La taille typique que peut représenter ces informations en mémoire est de l ordre de 256 octets. LE TEDS doit être physiquement relié au transducteur, réalisant ainsi un ensemble toujours cohérent et rendant donc conceptuellement l auto-identification sur le réseau possible, sans risque d erreur possible ; ce qui aurait été plus caduque si un tiers participant avait à se charger de cette opération ou si un opérateur devait manuellement définir les propriétés de l appareil à chaque mise en service. Le fait également de considérer que ce bloc est séparé de celui en charge de la couche réseau permet le remplacement ou la mise à jour de l instrument par le simple remplacement du transducteur et de son TEDS associé. Cependant, il est parfois peu aisé, voire impossible, de déployer en un même lieu le TEDS et le senseur proprement dit : c est pourquoi le document 1451.3 précise-t-il comment on peut connecter en un même noeud des transducteurs physiques multiples et le TEDS de description associé. Cette configuration permet de réaliser un micro-réseau interne au transducteur, tout en conservant une même interface externe. Enfin, nous avons supposé jusqu à présent que les communications externes tant qu internes se passent sur base d une transmission digitale. Certains groupes d appareils (piézoélectriques, capteurs de contraintes,etc.) tirent un meilleur parti de la transmission interne de l information sous forme de signaux analogiques. Ce besoin a induit la formation d une dernière recommandation, IEEE 1451.4, relative à la standardisation de l envoi, en interne, de signaux analogiques avant conversion en digital pour présentation sur le réseau. La taille fort réduite de l EEPROM contenant la description du TEDS ainsi que l interopérabilité voulues ont poussé le groupe de standardisation à évoquer l utilisation de langages semi-structurés ou peu structurés, comme XML, afin d offrir une flexibilité, une interopérabilité maximales lors de l implantation des descriptions des fonctions standards ou plus spécifiques des capteurs. Notons qu actuellement aucune forme de message standard n a été avancée comme finale, seule l existence de messages sous forme de texte semble avoir la préférence du groupe de travail dévolu à cette tâche. 1.3.3 GPIB-Enet Une solution proposée pour le contrôle réseau des instruments de mesure est l utilisation d une extension de GPIB connue sous le nom de GPIB-Enet. GPIB-Enet est un appareillage électronique portable se connectant sur le réseau et permettant de prendre en charge jusqu à 14 appareils compatibles GPIB. La Figure 1.6 illustre l architecture typique des réseaux hybrides GPIB / Ethernet. 1 Electricly Erasable Read Only Memory 16

1.3. INSTRUMENTATION DISTRIBUÉE Fig. 1.6 Architecture et déploiement typique d une installation utilisant GPIB-Enet. Le réseau se subdivise en 2 composantes principales : le Thin Ethernet global, à large rayon d action, et les bus locaux GPIB qui forment les noeuds du réseau global. GPIB-Enet se déploie typiquement sur des LAN ou des WAN via une interface 10Base- T Thin Ethernet ou 100Base-T. l exploitation du protocole IPX est également possible, bien que dans la pratique, seul le protocole IP soit utilisé. Chaque concentrateur GPIB possède donc une adresse unique qui doit être fixée dès la mise sur réseau. Pour se faire deux scénarios sont possibles. Le premier scénario de configuration consiste en l utilisation d un ordinateur tiers. Celuici adressera l instrument au moyen des adresses MAC qu il sait être présentes à un moment donné sur le réseau. Le PC procède par une approche d essais erreur jusqu à ce qu il trouve un appareil valide. Ayant reconnu les instruments disponibles sur le sous-réseau local, il peut communiquer avec eux au moyen d un protocole de bas niveau et imposer une configuration reflétant la structure du réseau local : adresse IP, passerelle, etc. Une deuxième approche consiste à laisser l appareil interroger un serveur DHCP présent sur le sous-réseau et laisser celui-ci lui fournir des données valides permettant l autoconfiguration. La technique DHCP a été mise au point afin d apporter une solution au problème de la configuration des paramètres réseau d une machine mise soudainement en connexion sur ce dernier. La machine apparaissant émet des paquets de propagation (broadcast packets) signalant sa présence et comportant une information faisant part de 17

1.3. INSTRUMENTATION DISTRIBUÉE son souhait de bénéficier de l aide d un serveur DHCP pour se configurer. Si une telle machine est présente à ce moment, elle établira, en fonction de règles de décision quant à la gestion du lot d adresses disponibles, une liste de paramètres qu elle renverra à la machine demandeuse. Ces informations sont notamment : une adresse IP, celle de la passerelle du réseau, l adresse du serveur de nom utilisable, le masque de sous-réseau, ainsi qu un temps de prêt au bout duquel il faudra recontacter le DHCP afin de renouveler les informations. La combinaison hybride ainsi obtenue en mettant en oeuvre des noeuds GPIB-Enet sur un réseau de type Thin Ethernet permet des débits pratiques d information maximum de l ordre de 800 kb/s depuis un élément de la chaîne GPIB jusqu à un autre noeud réseau. Un tel débit est relativement équivalent à ce que l on peut observer entre un appareil et une carte dédiée d une chaîne GPIB purement locale. Il apparaît donc que l utilisation des concentrateurs GPIB-Enet est totalement transparente pour autant que le réseau soit fort peu sollicité par d autres types d activité, non liées à la prise de mesure. Il est donc évident qu il y a un manque de maîtrise du débit maximal d information qui va pouvoir être acquis en temps réel depuis la source. L ampleur du réseau local ainsi que son architecture conditionneront grandement la disposition des appareils et l étendue maximale utile de l expérimentation. Notons enfin qu aucun mécanisme ne nous permet de garantir l état de bon fonctionnement des éléments du réseau GPIB-Enet. Seuls des mécanismes logiciels supplémentaires, intégrés par dessus la couche matérielle, permettraient de fournir à tout moment des renseignements relatifs au bon état de marche des appareils. Cette solution générant du trafic supplémentaire, croissant exponentiellement avec le nombre de noeuds à contrôler, réduit d autant plus la largeur de bande passante disponible au transport de l information, détériorant la qualité globale du système. 1.3.4 Limitations l utilisation de réseaux d instruments, quoique résolvant un nombre non négligeable de problèmes soulevés par l instrumentation locale et intégrant efficacement cette nouvelle dimension de l informatique que sont les intranets et l Internet, fait apparaître des problèmes de mise en oeuvre spécifiques. En effet, la latence fort faible présentée par les réseaux locaux peut s avérer critique lors de la généralisation de la mise en oeuvre d expériences d instrumentation à distance telles que celles décrites dans [21], [5] et [16]. Cette utilisation des possibilités de l Internet n est en fait qu une généralisation ou plutôt une globalisation des techniques sous-tendant l instrumentation locale. Lors d une telle expérience, la latence induite par le transfert de l information ainsi que l apparition asynchrone des résultats prohibent la conception d un système de mesure en temps de réel. Une solution efficace [17] consiste à segmenter l installation en cellules de traitement et à assigner le contrôle de chacune de celles-ci à une unité de traitement spécialisée. Ces unités servent d interface avec les éléments distants du système et sont à même de prendre en charge les décisions et une partie du post-traitement, rendant ainsi le contrôle en temps réel possible dans chacune des 18

1.3. INSTRUMENTATION DISTRIBUÉE cellules et préparant les données pour envoi vers les machines lointaines. Il n empêche que les données arrivant des contrôleurs de cellules n en restent pas moins peu cohérentes dans le temps et donc peu exploitables à distance. On perçoit donc bien ici le besoin de disposer d une composante logicielle forte dans les cellules de prise de mesure, composante logicielle qui serait éventuellement induite localement pour les seuls besoins de l expérimentation. L utilisation tant d un réseau local que global présuppose que chaque acteur prenant part à l expérience est à même de s identifier sur ce réseau. Ceci signifie, par exemple pour un réseau TCP/IP, que chaque machine doit disposer d une adresse IP unique mais également avoir connaissance du routeur local permettant le branchement le cas échéant au réseau global. De plus, le contrôle des expériences par réseau suppose une géométrie relativement statique au vu du manque d interopérabilité des appareils. En effet, chaque appareil pris en charge par un ordinateur aura nécessité l installation et la configuration d un gestionnaire propriétaire, quel que soit le système actuel utilisé, e.g. GPIB-Enet. Modifier un appareil, changer un voltmètre par un autre provenant d un constructeur différent, ou déplacer les appareils impose de réévaluer une partie non négligeable de la configuration. La robustesse du système de mesure est un élément également souvent peu ou pas intégré à l architecture de l expérimentation. Il faut donc parallèlement mettre en oeuvre un ensemble de techniques permettant l évaluation de l état courant des appareils. Un tel système sera donc forcément peu réutilisable et interopérable avec d autres systèmes de surveillance du bus, puisqu il s agit de mettre en oeuvre des solutions commerciales ou développées sur mesure. Enfin, le désir de faire communiquer des instruments et des ordinateurs selon un schéma homogène et portable impose l utilisation de protocoles standardisés qui présentent le double désavantage de ne pouvoir évoluer dans le temps et de ne pas tirer bénéfice des techniques de développement actuelles, notamment l utilisation de langages de très haut niveau orientés-objet et de techniques de mise en oeuvre d objets distribués. Constituer des points de mesures mobiles, dynamiques voire collaboratifs est donc actuellement fort peu aisé, voire impossible au vu de ces limitations. 19