• Aucun résultat trouvé

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

N/A
N/A
Protected

Academic year: 2022

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

Copied!
84
0
0

Texte intégral

(1)

UNIVERSITE LIBRE DE BRUXELLES Facult´e des Sciences appliqu´ees

Ecole Polytechnique

Ann´ee acad´emique 2000-2001

Conception et r´ ealisation d’un syst` eme

d’instrumentation distribu´ ee bas´ e sur l’architecture Jini

Promoteurs :

Prof. Francis Grenez Prof. Hugues Bersini Philippe De Doncker

Travail de fin d’´etudes pr´esent´e par Jean-Michel Dricot en vue de l’ob- tention du grade d’ing´enieur civil informaticien

(2)

Je tiens `a remercier ici tout ceux qui de pr`es ou de loin ont contribu´e `a la r´ealisation de ce m´emoire. Mˆeme si ce travail est avant tout l’oeuvre d’une seule personne, je n’aurais pu aboutir sans les conseils avis´es et les encouragements de mes promoteurs.

J’aimerais d’abord remercier tout particuli`erement le Professeur Francis Grenez ainsi que Mr. Philippe De Doncker pour leur aide, leur disponibilit´e et le soutien dont ils ont fait part tout au long de cette ann´ee. J’ai ´et´e fort touch´e par leurs initiatives `a mon ´egard et leurs encouragements qui ont permis la publication et la pr´esentation de ce travail, m’of- frant de par l`a mˆeme un atout consid´erable au moment d’entamer une carri`ere acad´emique.

Je voudrais ´egalement remercier le Professeur Hugues Bersini de m’avoir offert la pos- sibilit´e de d´ecouvrir la technologie Jini, marriant si subtilement l’Informatique `a l’Electro- nique.

Je tiens `a remercier personellement Mr. Esteban Zim´anyi, `a la fois Professeur et ami, qui a su prendre le temps de me conseiller `a de nombreuses reprises quant la redaction de cet ouvrage.

Il va sans dire que je remercie les membres du Service d’Electricit´e G´en´erale pour leur sympathie et leur acceuil chaleureux, une ann´ee durant, dans leurs locaux.

J’ai une pens´ee pour tous mes camarades de promotion dont l’optimisme, la bonne humeur et la fraternit´e m’ont permis de vivre pendant toutes ces ann´ees une amiti´e extra- ordinairement ´epanouissante.

Je ne voudrais pas non plus oublier mon Amoureuse qui a toujours trouv´e la force et la patience de me soutenir lorsque j’en avais besoin.

Enfin, j’aimerais faire plus que de simples remerciements `a mes Parents qui ont travers´e avec moi toutes ces ann´ees d’´etude `a l’Universit´e. Les ´epreuves que j’ai travers´ees ont ´et´e les leurs ´egalement, et la moindre des choses que je puisse faire pour leur prouver ma gratitude est de leur d´edier ce m´emoire.

(3)

Table des mati` eres

I Etude th´ ´ eorique 6

1 Instrumentation Virtuelle 7

1.1 Introduction et Motivation . . . 7

1.2 Le contrˆole local des appareils de mesure . . . 9

1.2.1 GPIB . . . 9

1.2.2 La programmation visuelle . . . 12

1.3 Instrumentation distribu´ee . . . 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´ecanisme 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`ele propos´e 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`ele d’interaction dynamique . . . 42

(4)

II R´ ealisation d’un syst` eme d’instrumentation distribu´ ee 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 El´ements 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 El´ements de distinction . . . .´ 53

5.3 IEEE 1451 . . . 53

5.4 Conclusion . . . 54

6 Contrˆole local des instruments de mesure en Java 55 6.1 Contrˆole 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¸cage des instruments de mesure . . . 62

7.2.1 Interfaces standardis´ees . . . 62

7.2.2 Introspection dynamique des capacit´es des instruments . . . 65

7.3 Exploitation du r´eseau . . . 67

7.3.1 Les domaines . . . 67

7.3.2 Instrumentation distante . . . 67

7.4 Les apports propres `a Jini . . . 68

7.4.1 Robustesse . . . 68

7.4.2 Interfaces graphiques . . . 69

8 Int´egration de Jini dans les solutions actuelles 71 8.1 Motivation . . . 71

8.2 Implantation d’une interface de programmation visuelle int´egrant Jini . . . 72

8.3 Conclusions . . . 75

9 Conclusion et perspectives 80

(5)

Introduction

Contexte de travail

Le d´eveloppement et l’utilisation des instruments de mesure programmables sont ac- tuellement largement exploit´es, tant dans le monde acad´emique que dans les industries, menant `a des r´esultats et `a des mises en oeuvre prometteuses. Ceci d´ecoule principalement de la possibilit´e d’utilisation d’architectures programmables pr´esentant actuellement des performances ´elev´ees `a un coˆut raisonnable. En particulier, la capacit´e de modifier le pro- cessus de prise de mesure en repensant uniquement l’algorithme ex´ecut´e par l’ordinateur de contrˆole et ce, sans remplacer la moindre pi`ece mat´erielle, rend l’exp´erimentation plus modulaire, r´eutilisable et flexible. Le d´eveloppement de composants d’acquisition de me- sure g´en´eriques et r´eutilisables, notamment par une approche orient´ee objet, a permis de r´eduire drastiquement les coˆuts de d´eveloppement et de mise `a niveau des laboratoires de mesure.

Un certain nombre de standards existent afin de permettre le contrˆole de senseurs ou d’actuateurs depuis des stations de travail ordinaires. A ces standards ´el´ectriques sont associ´es des outils logiciels facilitant la mise en oeuvre, souvent fastidieuse, de ces appareils.

Probl´ ematique

L’introduction de cette approche et l’´elaboration des moyens logiciels qui les accom- pagne remonte `a pr`es de vingt ans. L’Informatique et l’Electronique ont connu, au cours de ces deux derni`eres d´ec´enies, des ´evolution majeures. Les ordinateurs pr´esentent des puis- sances de calcul croissantes et sont actuellement presque toujours int´egr´es dans des r´eseaux locaux ou globaux, `a l’instar d’Internet.

De telles capacit´es, en terme de traitement des mesures, de stockage de donn´ees issues d’interaction entre appareils, sont peu ou pas utilis´ees dans le cadre de l’instrumentation.

Les mod`eles mis en oeuvre dans les solutions actuelles ne peuvent tirer un b´en´efice de cette explosion de nouvelles technologies, privant ainsi l’ing´eni´erie de la mesure et du signal d’outils pr´ecieux.

(6)

Le pr´esent travail tente d’apporter une solution `a ce probl`eme sous la forme de l’uti- lisation d’un nouvelle technologie connue sous le nom de Jini. Jini propose un mod`ele d’interaction dynamique tirant b´en´efice de la plateforme orient´ee objet Java. Ainsi, nous avons ´et´e `a mˆeme de cr´eer un r´eseau d’instrumentation distribu´e dans lequel les appareils, actuateurs ou senseurs, sont `a mˆeme d’interragir entre eux et avec des logiciels clients de mani`ere totalement transparente.

Les contraintes de robustesse, vis-`a-vis des pannes ou de la qualit´e du r´eseau, ont pu ˆetre int´egr´ees dans cette technologie au moyen d’une ´etude de Jini attach´ee sp´ecifiquement

`a r´epondre aux besoins de l’instrumentation. Une int´egration de cette solution dans les logiciels existants, tels que LabVIEW, est ´egalement possible.

Cheminement de l’expos´ e

Le pr´esent manuscrit comporte deux parties. Une introduction th´eorique initie le che- minement. Dans un premier temps nous situerons le contexte de la prise de mesure ainsi que les technologies utilis´ees jusqu’`a pr´esent pour r´ealiser celle-ci. Nous exposerons en- suites certaines techniques d’interaction entre objets `a travers le r´eseau qui nous permet- trons dans le d´ebut de la seconde partie de justifier le choix de Jini comme solution `a la probl´ematique sp´ecifique des instruments distribu´es. Nous poursuivrons en d´etaillant la r´ealisation compl`ete d’un syst`eme d’instrumentation distribu´ee se basant sur la plateforme Java et l’architecture Jini. Enfin, il sera montr´e comment il est possible d’int´egrer la solu- tion propos´ee dans les logiciels existants.

Un c´ed´erom compl`ete le pr´esent travail. Il contient l’ensemble des annexes,le programme de contrˆole JiniLab ainsi que le code source des services Jini d´evelopp´es. Ce m´edia a ´et´e remis au Professeur Grenez et est conserv´e dans la biblioth`eque du Service d’Electricit´e G´en´erale.

(7)

Premi` ere partie

Etude th´ ´ eorique

(8)

Instrumentation Virtuelle

Sommaire

1.1 Introduction et Motivation . . . 7

1.2 Le contrˆole local des appareils de mesure . . . 9

1.2.1 GPIB . . . 9

1.2.2 La programmation visuelle . . . 12

1.3 Instrumentation distribu´ee . . . 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 ´et´e introduit `a la base pour simplifier la concep- tion, l’implantation et l’utilisation de syst`emes d’instrumentation programmables en adop- tant une interface visuelle. La programmation visuelle permet une r´ealisation avant tout conceptuelle du processus de prise de mesure, permettant ainsi aux personnes peu vers´ees dans la programmation de mettre au point rapidement des algorithmes performants. Le pro- gramme y est d´ecrit de mani`ere graphique en s´electionnant et en assemblant des blocs fonc- tionnels pr´esents dans des biblioth`eques de d´eveloppement. Ce type d’approche, pr´esentant des interfaces graphiques ressemblant aux instruments r´eels, rend ainsi l’utilisation et la compr´ehension de l’instrumentation virtuelle plus ais´ee pour les personnes expertes en exp´erimentation ”r´eelle”.

(9)

1.1. INTRODUCTION ET MOTIVATION

l’utilisation du r´eseau a depuis peu ´et´e incorpor´ee aux processus de prise de mesure avec beaucoup de succ`es. Cette nouvelle approche fonctionnelle permet en effet non seule- ment d’interconnecter des instruments entre eux, mais ´egalement de cr´eer des zones de post-traitement des donn´ees, comme des bases de donn´ees ou des logiciels de DSP. Cette configuration est particuli`erement rentable, tant d’un point vue ´economique que du point de vue de l’utilisation efficace des ressources disponibles sur le r´eseau local du laboratoire, mais peut ´egalement se r´ev´eler n´ecessaire lorsque les points de mesure sont fortement diss´emin´es ou distants et qu’il deviendrait donc financi`erement inabordable d’y adjoindre un post-traitement informatique.

Fig. 1.1 – l’utilisation de l’instrumentation virtuelle permet l’exploitation d’une large vari´et´e de ressources, notamment celles fournies par les ordinateurs de contrˆole et plus r´ecemment, l’int´egration des r´eseaux locaux industriels ou de l’Internet

Enfin, le d´eveloppement de syst`emes embarqu´es pr´esentant des puissances de calcul pour un coˆut acceptable et l’´emergence de technologies d’interconnexion permettant de cr´eer spontan´ement des r´eseaux ”nomades” offrent des possibilit´e nouvelles qui permettent l’introduction efficace d’une composante logicielle `a mˆeme le syst`eme ou situ´e dans un proche voisinage.

(10)

1.2 Le contrˆ ole local des appareils de mesure

Les syst`emes classiques de contrˆole local des appareils par un PC offrent l’avantage de pouvoir confiner en un mˆeme lieu les composants mat´eriels d’exp´erimentation charg´es de l’acquisition ainsi que les ´el´ements charg´es du contrˆole des instruments et de la mise

`a jour des donn´ees. Toutes les op´erations relatives `a la prise de la mesure sont effectu´ees par un logiciel sp´ecialis´e. Ce sch´ema de conception et de d´eploiement a conduit `a stan- dardiser les cartes d’ entr´ees/sorties d´evolues `a l’acquisition et la mise `a jour du signal, tout en diminuant le coˆut global du processus entier d’exp´erimentation (e.g. l’acquisition, la maintenance mais aussi le d´eveloppement logiciel et la prise en charge de la formation des techniciens).

De nombreuses initiative relatives `a la standardisation et l’interfa¸cage ont ´et´e entre- prises depuis longtemps par les industriels. Cependant, l’analyse des solutions existantes sur le march´e montre qu’il n’ existe pas de standard ouvert universellement adopt´e mais uniquement deux syst`emes propri´etaires embrass´es par une partie extrˆemement impor- tante des utilisateurs. Il s’ agit d’une part de l’utilisation du bus GPIB afin de permettre la connexion coh´erente d’appareils de mesure et d’appareils de contrˆole, PC par exemple.

d’autre part, du point de vue de l’interfa¸cage et de la programmation visuelle, LabVIEW de la soci´et´e National Instruments sera ´evoqu´e ici afin de bien montrer comment on peut utiliser les concepts propos´es par le mod`ele de l’instrumentation virtuelle.

1.2.1 GPIB

Le bus GPIB, standardis´e sous les r´ef´erences IEEE 488.1 et IEEE488.2 est un syst`eme d’interconnexion des instruments imagin´e par Hewlett-Packard en 1975. Anciennement connu sous la d´enomination HPIB, ce mod`ele de bus est constitu´e d’un certain nombre d’´el´ements standardis´es :

1. une interface ´electrique permettant l’envoi d’information et du statut actuel des p´eriph´eriques de la ligne.

2. la possibilit´e de connecter des appareils sans les diff´erencier au vu de leur rˆole sp´ecifique : envoi ou r´eception de donn´ees. Chaque appareil est vu comme un noeud du syst`eme `a mˆeme d’´emettre ou de recevoir une information `a un moment donn´e.

3. un mod`ele de communication bas´e sur l’envoi de messages entre les appareils sous forme de chaˆınes de caract`eres. Chaque appareil est capable de r´epondre aux solli- citations par renvoi d’un message et par l’ ajustement du statut de la ligne afin de refl´eter l’´etat 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´epassant pas 20 m`etres.

Le concept ducontrˆoleuret desp´eriph´eriques propos´e par le IEEE 488.1 est illustr´e aux figures 1.2 et 1.3. Les contrˆoleurs ont la capacit´e d’envoyer des commandes, de pr´esenter

(11)

1.2. LE CONTR ˆOLE LOCAL DES APPAREILS DE MESURE

des donn´ees sur le bus et d’´ecouter les messages envoy´es par les p´eriph´eriques. Le contrˆole du bus peut passer `a tout moment du Contrˆoleur en Charge (CIC : Controller In Charge) actif `a n’ importe quel autre p´eriph´erique ayant la capacit´e d’ˆetre un contrˆoleur. Un et un seul contrˆoleur du syst`eme est d´efini comme ´etant le Contrˆoleur Syst`eme global (System Controller) est sera d´esign´e `a l’instant initial comme Contrˆoleur en Charge.

Control, Talk, Listen

Controller Device #1

Device #n Piggyback

Cables

Talk, Listen

Talk, Listen

Fig. 1.2 – Sch´ematisation du bus IEEE 488.1

Fig. 1.3 – Le chaˆınage des appareils IEEE 488.1 sur le bus s’ effectue sans disposition particuli`ere.

Les p´eriph´eriques sont identifi´es sur la chaˆıne via un adresse unique qu’ils doivent poss´eder lors de la mise en service de l’appareil. Cette adresse est usuellement impos´ee par l’exp´erimentateur 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 uti- lis´ee pour adresser des ´el´ements particuliers internes `a l’appareil consid´er´e. Par exemple, un appareil utilis´e pour interfacer plusieurs ports s´erie aura une adresse secondaire pour

(12)

chaque canal de transmission contrˆol´e. Notons que bien que 31 adresses soient disponibles, GPIB limite `a 14 le nombre d’appareils adressables sur un mˆeme bus `a un moment donn´e.

Lors de l’utilisation, certains appareils sont d´edi´es uniquement `a ´ecouter et d’autre `a parler. On parle de mod`eletalker–listener. Ceci permet de r´ealiser une communication sans n´ecessiter l’existence d’un contrˆoleur global pour tout le syst`eme : lorsqu’un appareil parle, tous les autres ´ecoutent. Lorsqu’un appareil d´esire parler, il le signale sur le bus et devient l’unique Contrˆoleur en Charge du bus. Lorsqu’un instrument ´emet, les messages peuvent ˆetres envoy´es pour toute la ligne ou adress´es `a un appareil particulier.

IEEE 488.1 : Interface ´electrique

L’interface ´electrique pr´esent´ee par les appareils compatibles GPIB repose sur un mod`ele de transmission des informations en parall`ele. Les 16 lignes utiles sur le connecteur se di- visent comme suit : 8 bits sont allou´es `a la transmission bidirectionnelle des informations, 3 au handshake et 5 permettent la signalisation de l’´etat du bus et l’envoi d’´ev`enements.

Cette interface est largement d´ecrite dans les documents [6], notons seulement qu’il est toujours possible de r´einitialiser un p´eriph´erique ou le bus entier via une des lignes ainsi que d´etecter les erreurs ´eventuelles par le changement d’´etat de la ligne correspondante.

IEEE 488.2 : Messages

La normalisation IEEE 488.1 d´ecrit un mod`ele de mise en oeuvre d’un bus d’intercon- nexion pour les instruments mais ne fournit aucune information quant `a la normalisation des messages entre appareils. Certains d´etails, tels l’utilisation ou non du retour `a la ligne comme fin de communication, pouvait mettre `a mal l’interop´erabilit´e voulue par GPIB. De mˆeme, les commandes les plus utiles ou les plus courantes (remise `a z´ero, extinction, iden- tification,etc. ) ont souvent ´et´e implant´ees par les constructeurs de mani`ere non uniforme, mettant ainsi au point un set de commande propre `a chaque compagnie, voire `a chaque appareil. Afin de standardiser la mise au point de logiciels de contrˆole, Tektronix a propos´e en 1985 une formalisation standard qui fˆut adopt´ee en 1987 sous la norme IEEE 488.2.

Le nouveau standard sp´ecifie un format unique d’envoi de messages, un set de commandes de base commun ainsi qu’une structure g´en´erique permettant d’interroger l’appareil sur son statut. Par exemple, l’envoi de la commande ’ *IDN ?’ indique `a l’appareil qu’il doit renvoyer son identification.

Conclusion

L’utilisation d’un standard ´electrique et la d´efinition d’un format commun d’envoi de messages ont permis la mise au point de biblioth`eques de fonctions acc´el´erant ainsi le d´eveloppement de logiciels de contrˆole. Ces biblioth`eques existent en acc`es libre [2] et ont ainsi pu servir de base au contrˆole des instruments utilis´es pour la mise en oeuvre et la commande des appareils, selon un sch´ema d´ecrit dans la seconde partie de l’ouvrage.

(13)

1.2. LE CONTR ˆOLE LOCAL DES APPAREILS DE MESURE

1.2.2 La programmation visuelle

l’id´ee mˆeme de d´evelopper des outils de programmation visuelle afin d’asservir des syst`emes de mesure a ´et´e introduite en 1985 par la firme National Instruments. Son logiciel LabVIEW est actuellement largement utilis´e par nombre de milieux acad´emiques et indus- triels. Il a pour but de faciliter la mise en oeuvre de l’acquisition et du post-traitement des mesures prises en laboratoire. Il utilise `a cette fin les capacit´es graphiques des ordinateurs d’entr´ee de gamme actuels. Les interfaces graphiques qu’il met en oeuvre sont bas´ees sur un ensemble organis´e de fenˆetres et d’icˆones interagissant entre elles afin de pr´esenter `a l’utilisateur une sch´ematisation du processus exp´erimental ainsi qu’un certain nombre de grandeur de sortie.

Fig. 1.4 – Une session LabVIEW standard pr´esentant le r´esultat d’une acquisition sous forme d’un graphe

(14)

Sur la fenˆetre de base d’une telle application se trouvent des repr´esentations gra- phiques (icˆones) de contrˆoleurs conventionnels (e.g. boutons, s´electeurs, potentiom`etres) et d’indicateur de sortie (e.g. oscillogrammes, lumi`eres, valeurs num´eriques) familiers des exp´erimentateurs. La pr´esentation s´elective et organis´ee des donn´ees et des commandes offre le double avantage de sp´ecifier les interactions avec les appareils et de minimiser les informations pr´esent´ees `a l’utilisateur , le laissant ainsi se focaliser pleinement sur les

´el´ements importants de la prise de mesure. l’utilisateur agit sur l’icˆone comme il agirait sur l’instrument r´eel, en particulier, l’utilisation de la souris permet d’agir avec des compo- sants symboliques de la mˆeme mani`ere que les doigts de la main agiraient sur des boutons pr´esents sur la face de l’appareil.

l’utilisation d’un mod`ele de programmation graphique, que nous avons d´ej`a ´evoqu´e, fut import´e de l’informatique th´eorique afin de simplifier la conception des proc´edures d’exp´erimentation en se basant sur des concepts fortement orient´es-objet. Il est ainsi pos- sible de d´ecrire le processus de mesure sans devoir passer par un langage conventionnel de programmation proc´edurale. Dans un langage classique, les s´equences d’op´eration sur les donn´ees doivent ˆetre sp´ecifi´ees selon une syntaxe peu accessible et souvent r´eserv´ee aux seuls informaticiens ou ing´enieurs. En programmation visuelle, les donn´ees et les op´erations sont repr´esent´ees par des icˆones. Le programme lui-mˆeme est obtenu en dessi- nant un diagramme proc´edural restant `a un niveau fort conceptuel. Les noeuds de ce graphe sont des op´erations de haut niveau, typiquement du traitement de signal, des op´erations arithm´etiques, mais ils peuvent ´egalement ˆetre associ´ees `a des op´erations de visualisation des donn´ees ou `a un contrˆole des instruments de mesure. Chaque noeud a des connec- teurs d’entr´ees et des connecteurs de sortie auxquels il suffit d’attacher les bons fils afin de r´ealiser une op´eration donn´ee.

Les ´el´ements de base ´etant trop simples pour la plupart des exp´erimentations, des diagrammes pr´e´etablis peuvent ˆetre import´es ais´ement, menant ainsi `a une conception mo- dulaire des programmes et `a la mise `a disposition de larges biblioth`eques d’instrumentation virtuelle appel´ees VI (Virtual Instrumentation element). Il existe des VI pour `a peu pr`es tous les instruments contrˆolables depuis un PC. Ces VI servent donc bien souvent de ges- tionnaire de p´eriph´erique quasi-universels pour autant que l’instrument soit connectable au PC de contrˆole via un connecteur de type RS-232, parall`ele ou GPIB.

Notons enfin que l’utilisation massive d’une telle technique a un impact psychologique important sur la cat´egorie d’utilisateurs amen´es `a utiliser ce produit : en effet, relier un appareil `a un affichage pr´esentant le r´esultat de la mesure prise par cet appareil revient simplement `a tirer un fil de la sortie de l’icˆone de l’appareil et `a le connecter sur une borne d’entr´ee de l’icˆone repr´esentant l’afficheur ; c’ est pourquoi les syst`emes d’instrumentation virtuels sont devenus aujourd’hui un ´el´ement incontournable lorsqu’il s’ agit d’int´egrer les techniques informatiques `a la prise de mesure.

(15)

1.3. INSTRUMENTATION DISTRIBU ´EE

1.3 Instrumentation distribu´ ee

1.3.1 Introduction

Tant dans la litt´erature [21] [7] [15] que dans la pratique, de nombreux exemples montrent l’utilisation des r´eseaux afin d’´etendre les capacit´es de mesure et de traitement des syst`emes de mesure exploit´es dans des environnements d’instrumentation virtuelle. Ce besoin d´ecoule d’un certain nombre de limitations inh´erentes `a l’utilisation des architec- tures mettant en oeuvre des ordinateurs.

La premi`ere limitation provient souvent du nombre de signaux qu’il faut acqu´erir si- multan´ement. Il arrive souvent en effet que le nombre d’entr´ees des cartes d’acquisition sur une mˆeme machine ne soit pas suffisant ou que la machine ne puisse fournir `a elle seule la puissance n´ecessaire `a la prise de mesure. l’utilisation du r´eseau permet ici le d´eploiement de sous-syst`emes de mesure, ´etendant ainsi la capacit´e de traitement de l’unit´e d’exp´erimentation. Des standards tels que Fastbus, GPIB, etc. ont ´et´e propos´es il y a long- temps et sont maintenant utilis´es `a grande ´echelle dans l’industrie, tout particuli`erement lorsque des syst`emes et des processus complexes doivent pouvoir ˆetre v´erifi´es et contrˆol´es en temps r´eel.

Une seconde restriction d´ecoule de l’aire d’op´eration accessible par une mˆeme unit´e de traitement. Il suffit de penser par exemple aux fabriques chimiques ou p´etroli`eres dont les diff´erents processus sont diss´emin´es sur une superficie ´elev´ee et pr´esentant un besoin de s´ecurit´e globale important. Quel que soit l’environnement, les senseurs et les cartes d’acqui- sition ne peuvent ˆetre situ´es trop loin d’une source, sous peine de voir le signal entach´e de fortes perturbations. De mˆeme, le contrˆole local d’appareil impose une distance maximale entre l’appareil et l’unit´e en charge du traitement : typiquement 20 m`etres pour GPIB.

Si le signal doit ˆetre acquis sur une source distante, l’exploitation d’un r´eseau permet de rapprocher les instruments, les sources et les sous-syst`emes d’exp´erimentation, garantissant ainsi une qualit´e optimale pour le signal acquis de la source.

Enfin, une troisi`eme limitation est li´ee au traitement qui sera effectu´e sur le signal.

Plus la complexit´e de calcul de l’algorithme de post-traitement sera ´elev´ee, plus grandes seront les ressources pr´elev´ees sur le PC, rendant ´eventuellement impossible tout contrˆole en temps r´eel. Pour palier `a cela, des cartes de traitement de signal (DSP) sont adjointes au processeur de base, augmentant ainsi le coˆut ou la gamme de processeur requis. Une autre solution consiste `a utiliser massivement les machines pr´esentes sur le r´eseau pour distribuer les besoins de calcul et optimiser l’utilisation des possibilit´e de traitement local.

La promiscuit´e des interconnexions rend les communications entre noeuds de mesure quasi instantan´ees. Pour un r´eseau d´edi´e uniquement `a l’acquisition, le trafic global g´en´er´e sur un r´eseau commercial de faible coˆut (e.g. 10Mbps) est assez peu ´elev´e, et il en r´esulte que pratiquement aucun retard n’ est introduit suite `a une ´eventuelle contention.

(16)

1.3.2 IEEE 1451

IEEE 1451 [15] est une nouvelle norme dont le but est de fournir un cadre coh´erent et ouvert permettant la mise en relation d’appareillages de faible capacit´e m´emoire et dont les possibilit´es se r´eduisent `a op´erer des prises de mesure en un point donn´e. La philosophie g´en´erale du d´eveloppement de ce standard repose sur la cr´eation d’une volont´e d’unifor- miser les interfaces des appareils et ce en ajoutant, de mani`ere incr´ementale, des capacit´es

`a celles d´ej`a existantes, tout en conservant le coˆut de la transition accessible `a tous les vendeurs de l’industrie. Le standard envisag´e propose ´egalement l’ind´ependance vis-`a-vis de la couche r´eseau mise en oeuvre ainsi que l’ind´ependance vis-`a-vis du type de micropro- cesseur embarqu´e sur le syst`eme.

La famille 1451P consiste en la proposition et le d´eveloppement 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´esente les diff´erents composants pr´esents dans un syst`eme de transducteurs compatibles avec la sp´ecification que nous venons d’´evoquer.

Fig. 1.5 – Architecture d’un syst`eme de transducteurs IEEE 1451.

Le premier groupe de travail (1451.1) a ´et´e charg´e de d´efinir un mod`ele d’information pour la mise en r´eseau de transducteurs intelligents. Il d´efinit ´egalement les sp´ecifications

(17)

1.3. INSTRUMENTATION DISTRIBU ´EE

de l’interface logique. Le second groupe a d´efini le TEDS ainsi que l’interface et les proto- coles de communication `a mettre en oeuvre afin de permettre la communication entre le transducteur et le contrˆoleur responsable de la prise en charge de la composante r´eseau. Le TEDS est stock´e dans une EEPROM1 et contient des champs d´ecrivant compl`etement le type, les op´erations accessibles, la calibration et les attributs secondaires du transducteur.

La taille typique que peut repr´esenter ces informations en m´emoire est de l’ordre de 256 octets. LE TEDS doit ˆetre physiquement reli´e au transducteur, r´ealisant ainsi un ensemble toujours coh´erent et rendant donc conceptuellement l’auto-identification sur le r´eseau pos- sible, sans risque d’erreur possible ; ce qui aurait ´et´e plus caduque si un tiers participant avait `a se charger de cette op´eration ou si un op´erateur devait manuellement d´efinir les propri´et´es de l’appareil `a chaque mise en service. Le fait ´egalement de consid´erer que ce bloc est s´epar´e de celui en charge de la couche r´eseau permet le remplacement ou la mise

`a jour de l’instrument par le simple remplacement du transducteur et de son TEDS associ´e.

Cependant, il est parfois peu ais´e, voire impossible, de d´eployer en un mˆeme lieu le TEDS et le senseur proprement dit : c’ est pourquoi le document 1451.3 pr´ecise-t-il com- ment on peut connecter en un mˆeme noeud des transducteurs physiques multiples et le TEDS de description associ´e. Cette configuration permet de r´ealiser un ”micro-r´eseau”

interne au transducteur, tout en conservant une mˆeme interface externe. Enfin, nous avons suppos´e jusqu’`a pr´esent que les communications externes tant qu’internes se passent sur base d’une transmission digitale. Certains groupes d’appareils (pi´ezo´electriques, 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`ere recom- mandation, IEEE 1451.4, relative `a la standardisation de l’envoi, en interne, de signaux analogiques avant conversion en digital pour pr´esentation sur le r´eseau.

La taille fort r´eduite de l’EEPROM contenant la description du TEDS ainsi que l’in- terop´erabilit´e voulues ont pouss´e le groupe de standardisation `a ´evoquer l’utilisation de langages semi-structur´es ou peu structur´es, comme XML, afin d’offrir une flexibilit´e, une interop´erabilit´e maximales lors de l’implantation des descriptions des fonctions standards ou plus sp´ecifiques des capteurs. Notons qu’actuellement aucune forme de message stan- dard n’ a ´et´e avanc´ee comme finale, seule l’existence de messages sous forme de texte semble avoir la pr´ef´erence du groupe de travail d´evolu `a cette tˆache.

1.3.3 GPIB-Enet

Une solution propos´ee pour le contrˆole r´eseau des instruments de mesure est l’utilisation d’une extension de GPIB connue sous le nom de GPIB-Enet. GPIB-Enet est un appareillage

´electronique portable se connectant sur le r´eseau et permettant de prendre en charge jusqu’`a 14 appareils compatibles GPIB. La Figure 1.6 illustre l’architecture typique des r´eseaux hybrides GPIB / Ethernet.

1Electricly Erasable Read Only Memory

(18)

Fig. 1.6 – Architecture et d´eploiement typique d’une installation utilisant GPIB-Enet. Le r´eseau se subdivise en 2 composantes principales : le Thin Ethernet global, `a large rayon d’action, et les bus locaux GPIB qui forment les noeuds du r´eseau global.

GPIB-Enet se d´eploie typiquement sur des LAN ou des WAN via une interface 10Base- T Thin Ethernet ou 100Base-T. l’exploitation du protocole IPX est ´egalement possible, bien que dans la pratique, seul le protocole IP soit utilis´e. Chaque concentrateur GPIB poss`ede donc une adresse unique qui doit ˆetre fix´ee d`es la mise sur r´eseau. Pour se faire deux sc´enarios sont possibles.

Le premier sc´enario de configuration consiste en l’utilisation d’un ordinateur tiers. Celui- ci adressera l’instrument au moyen des adresses MAC qu’il sait ˆetre pr´esentes `a un moment donn´e sur le r´eseau. Le PC proc`ede par une approche d’”essais erreur” jusqu’`a ce qu’il trouve un appareil valide. Ayant reconnu les instruments disponibles sur le sous-r´eseau local, il peut communiquer avec eux au moyen d’un protocole de bas niveau et imposer une configuration refl´etant la structure du r´eseau local : adresse IP, passerelle, etc.

Une deuxi`eme approche consiste `a laisser l’appareil interroger un serveur DHCP pr´esent sur le sous-r´eseau et laisser celui-ci lui fournir des donn´ees valides permettant l’auto- configuration. La technique DHCP a ´et´e mise au point afin d’apporter une solution au probl`eme de la configuration des param`etres r´eseau d’une machine mise soudainement en connexion sur ce dernier. La machine apparaissant ´emet des paquets de propagation (broadcast packets) signalant sa pr´esence et comportant une information faisant part de

(19)

1.3. INSTRUMENTATION DISTRIBU ´EE

son souhait de b´en´eficier de l’aide d’un serveur DHCP pour se configurer. Si une telle ma- chine est pr´esente `a ce moment, elle ´etablira, en fonction de r`egles de d´ecision quant `a la gestion du lot d’adresses disponibles, une liste de param`etres qu’elle renverra `a la machine demandeuse. Ces informations sont notamment : une adresse IP, celle de la passerelle du r´eseau, l’adresse du serveur de nom utilisable, le masque de sous-r´eseau, ainsi qu’un temps de prˆet 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´eseau de type Thin Ethernet permet des d´ebits pratiques d’information maximum de l’ordre de 800 kB/s depuis un ´el´ement de la chaˆıne GPIB jusqu’`a un autre noeud r´eseau.

Un tel d´ebit est relativement ´equivalent `a ce que l’on peut observer entre un appareil et une carte d´edi´ee 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´eseau soit fort peu sollicit´e par d’autres types d’activit´e, non li´ees `a la prise de mesure. Il est donc

´evident qu’il y a un manque de maˆıtrise du d´ebit maximal d’information qui va pouvoir ˆetre acquis en temps r´eel depuis la source. L’ampleur du r´eseau local ainsi que son architec- ture conditionneront grandement la disposition des appareils et l’´etendue maximale utile de l’exp´erimentation.

Notons enfin qu’aucun m´ecanisme ne nous permet de garantir l’´etat de bon fonctionne- ment des ´el´ements du r´eseau GPIB-Enet. Seuls des m´ecanismes logiciels suppl´ementaires, int´egr´es par dessus la couche mat´erielle, permettraient de fournir `a tout moment des renseignements relatifs au bon ´etat de marche des appareils. Cette solution g´en´erant du trafic suppl´ementaire, croissant exponentiellement avec le nombre de noeuds `a contrˆoler, r´eduit d’autant plus la largeur de bande passante disponible au transport de l’information, d´et´eriorant la qualit´e globale du syst`eme.

1.3.4 Limitations

l’utilisation de r´eseaux d’instruments, quoique r´esolvant un nombre non n´egligeable de probl`emes soulev´es par l’instrumentation locale et int´egrant efficacement cette nouvelle di- mension de l’informatique que sont les intranets et l’Internet, fait apparaˆıtre des probl`emes de mise en oeuvre sp´ecifiques. En effet, la latence fort faible pr´esent´ee par les r´eseaux lo- caux peut s’ av´erer critique lors de la g´en´eralisation de la mise en oeuvre d’exp´eriences d’instrumentation `a distance telles que celles d´ecrites dans [21], [5] et [16]. Cette utilisation des possibilit´es de l’Internet n’est en fait qu’une g´en´eralisation ou plutˆot une globalisation des techniques sous-tendant l’instrumentation locale. Lors d’une telle exp´erience, la latence induite par le transfert de l’information ainsi que l’apparition asynchrone des r´esultats pro- hibent la conception d’un syst`eme de mesure en temps de r´eel. Une solution efficace [17]

consiste `a segmenter l’installation en cellules de traitement et `a assigner le contrˆole de cha- cune de celles-ci `a une unit´e de traitement sp´ecialis´ee. Ces unit´es servent d’interface avec les ´el´ements distants du syst`eme et sont `a mˆeme de prendre en charge les d´ecisions et une partie du post-traitement, rendant ainsi le contrˆole en temps r´eel possible dans chacune des

(20)

cellules et pr´eparant les donn´ees pour envoi vers les machines lointaines. Il n’ empˆeche que les donn´ees arrivant des contrˆoleurs de cellules n’ en restent pas moins peu coh´erentes dans le temps et donc peu exploitables `a distance. On per¸coit donc bien ici le besoin de disposer d’une composante logicielle forte dans les cellules de prise de mesure, composante logicielle qui serait ´eventuellement ”induite” localement pour les seuls besoins de l’exp´erimentation.

L’utilisation tant d’un r´eseau local que global pr´esuppose que chaque acteur prenant part `a l’exp´erience est `a mˆeme de s’ identifier sur ce r´eseau. Ceci signifie, par exemple pour un r´eseau TCP/IP, que chaque machine doit disposer d’une adresse IP unique mais

´egalement avoir connaissance du routeur local permettant le branchement le cas ´ech´eant au r´eseau global. De plus, le contrˆole des exp´eriences par r´eseau suppose une g´eom´etrie relativement statique au vu du manque d’interop´erabilit´e des appareils. En effet, chaque appareil pris en charge par un ordinateur aura n´ecessit´e l’installation et la configuration d’un gestionnaire propri´etaire, quel que soit le syst`eme actuel utilis´e, e.g. GPIB-Enet. Mo- difier un appareil, changer un voltm`etre par un autre provenant d’un constructeur diff´erent, ou d´eplacer les appareils impose de r´e´evaluer une partie non n´egligeable de la configuration.

La robustesse du syst`eme de mesure est un ´el´ement ´egalement souvent peu ou pas int´egr´e `a l’architecture de l’exp´erimentation. Il faut donc parall`element mettre en oeuvre un ensemble de techniques permettant l’´evaluation de l’´etat courant des appareils. Un tel syst`eme sera donc forc´ement peu r´eutilisable et interop´erable avec d’autres syst`emes de surveillance du bus, puisqu’il s’ agit de mettre en oeuvre des solutions commerciales ou d´evelopp´ees sur mesure.

Enfin, le d´esir de faire communiquer des instruments et des ordinateurs selon un sch´ema homog`ene et portable impose l’utilisation de protocoles standardis´es qui pr´esentent le double d´esavantage de ne pouvoir ´evoluer dans le temps et de ne pas tirer b´en´efice des techniques de d´eveloppement actuelles, notamment l’utilisation de langages de tr`es haut niveau orient´es-objet et de techniques de mise en oeuvre d’objets distribu´es.

Constituer des points de mesures mobiles, dynamiques voire collaboratifs est donc ac- tuellement fort peu ais´e, voire impossible au vu de ces limitations.

(21)

Chapitre 2 CORBA

Sommaire

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´ecanisme de marshallisation . . . 25

2.2.4 Les Objets standards . . . 27

2.3 Conclusion . . . 28

Nous d´etaillerons bri`evement dans ce chapitre les concepts et les m´ecanismes mis en oeuvre par la Common Object Request Broker Architecture (CORBA) afin de mieux la positionner par rapport `a Jini. Nous pr´esentons ´egalement dans le chapitre cinq, lors de la justification du choix de l’architecture utilis´ee pour la r´ealisation du syst`eme d’instrumen- tation distribu´ee, une comparaison des m´ecanismes utilis´es par CORBA d’une part et la combinaison RMI/Jini d’autre part.

2.1 Introduction

Les syst`emes d’objets distribu´es sont actuellement incontournables pour le d´eveloppement et le d´eploiement de logiciels par dessus une couche r´eseau de plus en plus importante.

Leurs avantages d´ecoulent de l’utilisation de langages de programmation orient´es objet : ces syst`emes en tirent une r´eusabilit´e de code accrue, ce qui ´etait quasi impossible dans une logique fortement protocolis´ee, mais ´egalement une transparence compl`ete quant `a la localisation des objets lors du d´eploiement. Un syst`eme distribu´e d´evelopp´e en un langage de haut niveau offre l’avantage d’ˆetre,`a peu de choses pr`es, con¸cu comme s’ il devait ˆetre

(22)

ex´ecut´e en local. De nombreux proc´ed´es existent afin de mettre en oeuvre des objets dis- tribu´es et le plus connu de tous est sans nul doute CORBA, la solution de prime abord la plus efficace et la plus standardis´ee `a ce jour.

CORBA est avant tout une norme [25] [27], c’ est-`a-dire un ensemble de sp´ecifications et de recommandations ´emises par l’Object Management Group (OMG) [4]. l’OMG est un groupe de travail ind´ependant au sein duquel si`egent plus de sept cent partenaires issus de tous horizons : d´eveloppeurs de logiciels, fabricants de mat´eriel et grands utilisateurs.

l’objectif de CORBA est avant tout d’assurer une interop´erabilit´e entre des applications orient´ees objet h´et´erog`enes tant du point du vue de leur langage de d´eveloppement que du syst`eme d’exploitation sur lesquels celles-ci seront amen´ees `a ˆetre d´eploy´ees. Ces ap- plications reposent sur un mod`ele de mise en relation d’objets distribu´es sur un r´eseau et interop´erant entre eux de mani`ere totalement transparente du point de vue de l’utilisateur.

Pour parvenir `a ses fins, CORBA d´efinit et impl´emente plusieurs concepts. Tout d’abord un mod`ele de communication entre les objets distribu´es `a travers le r´eseau. Ensuite, elle d´efinit une couche de transport commune `a tous les logiciels : l’ORB (Object Request Bro- ker). l’OMG met ´egalement `a disposition un langage de description des interfaces pr´esent´ees par chacun des acteurs du bus d’objets distribu´es : l’IDL (Interface Definition Language).

Enfin, des services et des objets ´el´ementaires sont introduits afin de faciliter le d´eploiement et l’utilisation de CORBA : il s’ agit, entre autres, des Common Object Services, des CORBA Facilities et des Domain Interfaces.

Chacun des ´el´ements formant le bus est simplement sp´ecifi´e par l’OMG et celle-ci n’

impose donc aucun langage ni aucune plateforme lors de l’implantation et du d´eploiement final. La plupart des langages actuels sont `a mˆeme d’exploiter les standards de l’OMG et bon nombre de constructeurs ont d´evelopp´e leur ORB, offrant ainsi une diversit´e quant aux possibilit´es accessoires que chacune des implantations offre, mais autorisant ´egalement la r´ealisation d’application hautement interop´erables. Seule la fonction et la nature mˆeme des applications d´evelopp´ees forcera le choix de tel ou tel autre logiciel CORBA.

2.2 Architecture

Les interactions entre objets sur un bus CORBA suivent un mod`ele classique client–

serveur. Les applications clientes ´emettent des requˆetes vers les objets serveurs, ceux-ci les ex´ecutent de leur cˆot´e et enfin ils renvoient le r´esultat ´eventuel `a l’appelant. Ce mod`ele pr´esuppose que la m´ethode invoqu´ee et implant´ee dans le serveur soit connue du client et que celui-ci poss`ede tout le mat´eriel n´ecessaire `a la prise de contact avec le serveur et l’envoi des param`etres. A cet effet, quatre ´el´ements importants sont mis en jeu :

– l’Interface reprenant toutes m´ethodes accessibles sur l’objet distant. Cette interface est implant´ee par le serveur et connue du client. L’IDL offre une formalisation de la d´efinition de cette interface, de mani`ere ind´ependante du langage mais selon une

(23)

2.2. ARCHITECTURE

structure fortement inspir´ee de l’orient´e objet.

– Le Stub conserv´e par le client. Il est obligatoirement coh´erent avec l’interface du serveur puisqu’il s’ agit de la partie d’un objet d´el´egu´e par le serveur et `a mˆeme de prendre en charge de mani`ere totalement transparente la communication avec l’objet lointain.

– Le Skeleton situ´e cˆot´e serveur. Il s’ agit ici de l’implantation proprement dite des m´ethodes d´eclar´ees au moyen de l’interface et activ´ees `a travers le stub.

– l’ORBqui est la couche de transport des requˆetes et des r´ef´erences sur le bus CORBA.

Il s’ agit d’unmiddleware situ´e entre l’application et la plateforme. Celui-ci doit donc ˆetre implant´e pour chacune des plateformes existantes.

La figure 2.1 indique le positionnement relatif de chacun des ´el´ements d’une architecture CORBA de base. L’IIOP (Internet Inter Orb Protocol) permet de connecter deux ORB de vendeurs ´eventuellement diff´erents `a travers l’Internet. Il est important de noter ici que les fl`eches ne repr´esentent pas un mouvement de donn´ees du client vers le serveur, mais mod´elisant le jeu de pointeurs qui permet de r´ef´erencer chaque objet en CORBA. En effet, CORBA fait abondamment usage de r´ef´erences distantes ou locales tant pour les objets serveurs que pour les arguments des m´ethodes. Ces arguments sont donc toujours pass´es par r´ef´erence et non par valeur, bien que ceci semble changer dans les versions de CORBA ult´erieures `a la deuxi`eme.

Server Object Reference

g etVoltag e() method

Server Object Implémentation

IIOP

ORB ORB

Client Server

Fig. 2.1 – ´El´ements de base d’une architecture CORBA

2.2.1 IDL

Le langage de d´efinition d’interface est un ´el´ement clef du bus de distribution d’objets CORBA. IDL est utilis´e afin de d´ecrire formellement chacun des objets selon des conven- tions non li´ees au langage final utilis´e pour l’implantation. Ces interfaces seront ensuite d´evelopp´ees au moyen d’un outil appropri´e afin de fournir un squelette d’application pou-

(24)

vant servir de base `a la r´ealisation concr`ete du syst`eme distribu´e, aussi bien client que serveur. De plus, IDL masque compl`etement les processus de communication entre objets, rendant ainsi le d´eveloppement de l’architecture client-serveur totalement transparente. Il s’agit donc ici de d´efinir ce que l’objet est `a mˆeme de proposer comme service en le situant dans une hi´erarchie de services ainsi qu’en ´enum´erant les m´ethodes qu’il met `a disposition.

L’exemple suivant pr´esente une d´efinition r´ealis´e au moyen de IDL. Il s’agit ici de cr´eer un module, semblable `a la notion de package en Java, contenant un objet ”Ammeter” et un objet ”Voltmeter”. Chacun de ces objets implante des m´ethodes qui seront accessibles via le Stub g´en´er´e par les outils de compilation sp´ecifique `a chaque langage.

module TestModule – interface Ammmeter –

void reset();

float getCurrent();

˝;

interface Voltmeter –

void reset();

float getVoltage();

˝;

˝;

Il est important ici de noter cette structure fortement hi´erarchis´ee depackages dispos´es selon un arbre. Cet ´el´ement sera fondamental dans la comparaison que nous offrons de CORBA vs.JINI dans le chapitre 5.

Le langage IDL propose ´egalement un m´ecanisme d’h´eritage entre et depuis les inter- faces. Cet h´eritage peut ˆetre simple, multiple ou r´ep´et´e. La notion d’h´eritage r´ep´et´e a ´et´e introduite en raison de la possibilit´e d’implanter un h´eritage multiple tout en respectant la contrainte de non r´ep´etition des noms. Cette contrainte sp´ecifie qu’au sein d’un mˆeme mo- dule, la surcharge – c’est-`a-dire d´efinir plusieurs m´ethodes dont la signature est diff´erente mais dont le nom est identique – est interdite.

2.2.2 l’ORB et l’IIOP

L’ORB est le composant central de la r´epartition des objets sur le bus CORBA. Il assure le transport des requˆetes entre les clients et les serveurs ou, pour ˆetre plus pr´ecis, entre les stubs des clients et les implantations correspondantes pr´esentes dans les skeleton des objets serveurs. Il s’agit d’un middleware qui se d´eploie entre la couche application proprement dite o`u vivent les objets et le syst`eme d’exploitation qui g`ere les fonctionnalit´es r´eseau du

(25)

2.2. ARCHITECTURE

syst`eme local. Son existence marque la volont´e de s’abstraire de l’h´et´erog´en´eit´e qui existe entre diff´erentes implantations d’un mˆeme objet, h´et´erog´en´eit´e qui puise sa source dans le choix du langage de programmation, du syst`eme d’exploitation retenu pour le d´eploiement final ou encore dans le formalisme de repr´esentation de donn´ees des machines. Les stubs d´esireux d’effectuer une requˆete l’adressent premi`erement `a l’ORB qui se charge de la pour- suivre jusqu’au skeleton correspondant. Du point de vue du serveur, l’ORB accueille les invocations distantes et les traduit en des appels de m´ethodes sur des objets locaux.

L’ORB comporte neuf blocs fonctionnels, pr´esent´es `a la figure 2.2, permettant de r´ealiser pratiquement les interconnexions n´ecessaires entre objets. Afin de ne pas entrer dans les d´etails du fonctionnement de l’ORB, seuls 3 ´el´ements fondamentaux pour la suite de l’ex- pos´e seront abord´es ici.

Fig. 2.2 – Structure de l’ORB. Les r´ef´erentiels des interfaces et des implantations gardent trace des objets mis `a disposition sur le bus.

L’interface d’invocation statique

L’interface d’invocation statique est le r´esultat de la projection des descriptions IDL dans le langage d’implantation. A travers la SII (Statical Invocation Interface), les stubs clients peuvent invoquer les m´ethodes sur les objets distants de mani`ere totalement trans- parente : la SII se charge du transfert de l’invocation `a l’objet distant via la couche de com- munication r´eseau constitu´ee par le coeur de l’ORB (Core ORB). Son principal d´esavantage est sa staticit´e intrins`eque : le stub doit imp´erativement ˆetre fourni au programme client, ce qui implique que tout changement dans le contexte de d´eploiement du client (langage,

(26)

hardware) requiert la g´en´eration d’un nouveau stub, compatible avec la nouvelle configu- ration.

Le r´ef´erentiel des interfaces

Le r´ef´erentiel des interfaces garde trace des objets d´eploy´es sur l’ORB en utilisant la description de l’Interface Definition Language. Cette base de donn´ees contient les modules, m´ethodes, attributs, exceptions, types de donn´ees accessibles et facilite ainsi l’introspection de l’ORB afin de permettre pratiquement le mise en relation des r´ef´erences des stubs clients et de leur skeleton correspondant.

L’interface d’invocation dynamique

L’interface d’invocation dynamique offre une plus grande souplesse dans l’envoi de requˆetes vers les serveurs. Son m´ecanisme est plus flexible et consiste `a localiser dans un premier temps l’objet distant d´esir´e en sp´ecifiant le nom de la m´ethode devant ˆetre invoqu´ee, les param`etres d´esir´es ainsi que la classe d’objet que l’on d´esire ainsi adresser.

Suite `a cette requˆete, et pour peu qu’un tel objet existe, un stub et un skeleton sontg´en´er´es respectivement du cˆot´e client et du cˆot´e serveur, permettant l’appel de m´ethodes distantes, au moyen de m´ecanismes similaires `a ceux d’une invocation statique.

Chaque implantation de l’ORB, avec plus ou moins de possibilit´es annexes, est laiss´ee

`a la discr´etion des vendeurs. Afin de rendre possible l’exploitation de CORBA sur des r´eseaux de grande ´echelle ou dans des environnements o`u sont d´eploy´es des implantations diff´erentes de l’ORB, l’OMG d´efinit un certain nombre d’adapteurs inter-ORB dont le plus important est IIOP : Internet Inter-Orb Protocol. IIOP d´efinit simplement comment un ORB est `a mˆeme d’´echanger des informations avec un autre ORB.

2.2.3 Le m´ ecanisme de marshallisation

L’activation de m´ethodes distantes suppose la possibilit´e de fournir `a ces m´ethodes et de recevoir de celles-ci des objets. IDL d´efinit deux modes de transfert des objets : IN et OUT, un objet IN allant du stub vers le skeleton et un objet OUT repr´esentant une valeur de retour. Ce transfert d’objet, totalement transparent pour l’utilisateur, s’effectue au moyen d’un m´ecanisme dit de marshallisation.

(27)

2.2. ARCHITECTURE

La marshallisation est le proc´ed´e par lequel l’´etat d’un objet ou un objet mˆeme est transform´e afin d’ˆetre transf´er´e sur le bus d’objet distribu´e. Dans le cas de CORBA, les objets arguments ne pouvant ˆetre pass´es par valeur, l’ORB devra g´erer un jeu de r´ef´erences permettant d’un cˆot´e de la transaction d’´enum´erer les valeurs des attributs d’un objet et,

`a l’autre bout du transport, de reconstituer un objet coh´erent `a l’interface IDL de l’objet marshallis´e et pr´esentant le mˆeme ´etat, `a savoir : les mˆemes attributs. L’objet transf´er´e n’est pas r´eellement transport´e dans son int´egralit´e, comme c’est le cas, nous le verrons plus loin, lors de l’utilisation du mod`ele RMI de Java.

La marshallisation n’induit donc pas un vrai polymorphisme en ce sens que si un objet d´eriv´e d’une classe donn´ee est transf´er´e sur un canal du bus d´evolu au transport d’un membre de la classe m`ere ; il commencera le processus comme objet d´eriv´e de la classe m`ere et sera reconstitu´e plus tard comme un objet membre de la classe m`ere. En effet, l’autre cˆot´e du canal est `a mˆeme de reconstruire des objets de la classe m`ere, au vu de sa sp´ecification IDL, et n’ aucune connaissance de ce qu’il s’agit en fait d’un objet d´eriv´e qui a en r´ealit´e transit´e sur l’ORB.

Fig. 2.3 – CORBA ne permet pas l’exploitation d’un vrai polymorphisme.

Pour prendre un exemple plus ludique et plus simple (Fig. 2.3), imaginons une classe Chat, d´erivant d’Animal, et qu’il existe un objet serveur dont nous d´esirons activer une m´ethode. Cette m´ethode accepte en argument un membre de la classe Animal. Si nous envoyons un Chat, ce qui est coh´erent du point de vue de l’IDL de la classe distante, le serveur recevra en fait, apr`es reconstitution, un Animal car le processus de marshallisation examinera les attributs du Chat, vu comme un Animal, pour reconstituer un Animal du cˆot´e serveur, d´egradant ainsi l’information. Ce point de vue peut se justifier par le fait que la sp´ecialisation en Chat de l’objet Animal peut n’ˆetre connu que par le client seul.

(28)

Nous verrons que ceci n’est pas du tout le cas de RMI, et donc de Jini, car un m´ecanisme suppl´ementaire, appel´e code mobile, permet la mise en commun des classes entre le client et le serveur, y compris celles qui ne sont connus que par un de deux protagonistes. Dans ce cas, l’envoi d’une sous-classe permettra de r´ecup´erer un membre de cette sous-classe en bout de marshallisation mˆeme si `a l’origine seule la super-classe est connue du serveur.

2.2.4 Les Objets standards

L’OMG a sp´ecifi´e un ensemble d’objets standardis´es `a mˆeme d’ˆetre d´eploy´es sur le bus CORBA de mani`ere `a offrir des services sp´ecifiques `a de nombreux sc´enarios d’utilisation.

Il s’agit d’abstractions aux fonctions syst`emes de base, telles que la d´enomination (Naming Service), la persistance des objets, le cycle de vie, la s´ecurit´e, la gestion des licences d’utili- sation des objets,les ´ev´enements, etc. L’ensemble form´e de ces services ne sont pas toujours impl´ementes de mani`ere compl`ete par les ORB disponibles actuellement. Dans le cadre de la r´ealisation de r´eseaux de terrains et d’instrumentation distribu´ee, seuls trois services im- portants sont `a mˆeme de remplir des fonctionnalit´es cl´es dans les processus d’interaction et de coop´eration intervenant entre les appareils d’une part et les clients logiciels d’autre part. Il s’agit des Naming Service, Trader Service et Event Service.

Le Naming Service

Ce service fournit un syst`eme de d´esignation permettant d’obtenir les r´ef´erences des objets r´epondant `a un nom d’enregistrement donn´e. Les noms sont structur´es selon un graphe de contextes de d´enominations interconnect´ees, permettant ainsi la cr´eation d’un espace de nom r´eparti et ´eventuellement fort vaste. A l’int´erieur de chaque contexte, chaque nom symbolique doit ˆetre unique, mais un mˆeme objet peut utiliser plusieurs noms. Ceci permet aux objets de s’enregistrer multiplement : sur base de noms diff´erents ou dans des contextes diff´erents. Ce m´ecanisme est en r´ealit´e assez pauvre dans un cadre dynamique, car un nom seul ne peut refl´eter les capacit´es des objets et rien ne pr´ecise si un objet se pr´esentant sous un nom donn´e est susceptible d’implanter une interface recherch´ee.

Le Trader Service

Le Trader Service pr´esente un m´ecanisme plus puissant et plus exploitable que le Na- ming Service. Les serveurs s’y enregistrent en d´etaillant l’ensemble des propri´et´es qui les caract´erisent, sous forme d’un ensemble d’associations clef-valeur, ainsi qu’en fournissant l’interface IDL qu’ils implantent. Les clients utilisent ce service en indiquant le type d’in- terface recherch´ee et des crit`eres annexes : type des objets arguments, nombre d’argu- ments,etc. Le Trader Service r´esout les requˆetes en parcourant l’ensemble du r´ef´erentiel des enregistrements qu’il a collect´es. Le client ayant obtenu ainsi l’ensemble des r´ef´erences des objets qu’il d´esire utiliser, la transaction peut commencer avec le serveur, par exemple en exploitant la Dynamic Invocation Interface.

(29)

2.3. CONCLUSION

l’Event Service

Notons enfin l’existence d’un service de gestion des ´ev´enements bas´e sur un mod`ele producteur–consommateur. Ce service permet une propagation asynchrone des ´ev´enements au moyen d’un canal r´eserv´e : le canal ´ev`enements. Les objets peuvent jouer deux rˆoles dans cette interaction : ils sont soit producteurs et g´en`erent des ´ev`enements, soit consommateurs et cherchent `a les acqu´erir. Les ´ev`enements sont transmis selon deux modes sur le canal :pull etpush. Le mode de d´epˆot (push) est utilis´e par les producteurs pour envoyer un ´ev´enement vers les consommateurs. Les objets consommateurs concern´es sont d`es lors avertis de la pr´esence d’un nouvel ´ev´enement disponible sur le canal. Le mode de retrait (push) permet

`a un objet consommateur d’interroger le canal ´ev´enement quant `a l’existence d’un nouvel

´ev´enement. Ainsi, par un m´ecanisme de scrutation, un objet peut avoir une connaissance

`a tout moment de l’´etat actuel de la pile ´ev´enements du canal local.

2.3 Conclusion

L’exploitation des m´ecanismes de base de CORBA, combin´ee aux services standards d’invocation dynamique, de collaboration avec le Trader Service et le Event Service permet la r´ealisation de syst`emes distribu´es sur un mod`ele service–consommateur. Nous verrons plus loin dans ce m´emoire que Jini propose la mˆeme d´emarche mais port´ee cette fois dans le monde de Java. Il nous faut cependant apporter un b´emol `a cette vision idyllique de CORBA en constatant qu’actuellement aucun vendeur d’ORB ne fournit simultan´ement l’ensemble des services requis pour le d´eploiement d’un syst`eme d’instrumentation flexible et pr´esentant une fiabilit´e ´elev´ee.

(30)

JAVA et RMI

Sommaire

3.1 Introduction . . . 29 3.2 La technologie Java . . . 30 3.3 RMI . . . 32 3.3.1 Le mod`ele propos´e par Java : RMI . . . 33 3.3.2 Le transfert dynamique de code mobile . . . 34 3.4 Java hardware : le PicoJAVA . . . 36

La solution que nous proposons pour l’implantation de r´eseaux d’instruments distribu´es est l’utilisation d’un nouveau mod`ele d’architecture distribu´ee connue sous le nom de Jini.

d’un point de vue logiciel, Jini est une sur-couche de la plateforme Java et utilise massi- vement le syst`eme d’objets distribu´es de Java : RMI. Afin de pr´esenter au mieux les pos- sibilit´es ´etendues d’utilisation que permet Jini, nous nous devons dans un premier temps de d´etailler ce qu’est la plateforme Java ainsi que de pr´esenter de mani`ere d´etaill´ee les m´ecanismes pr´esents dans RMI.

3.1 Introduction

Le d´eveloppement de la plateforme Java [13] est certainement une des grandes r´evolution de l’informatique actuelle. Le langage Java est apparu en 1995. Il est le fruit des recherches des ing´enieurs de Sun Microsystems, d´esireux de mettre en oeuvre un langage de haut niveau afin de programmer des p´eriph´eriques embarqu´es. Tr`es rapidement confront´es aux limitations de langages orient´es objets tels que C++ et ADA, ceux-ci ont opt´e pour le d´eveloppement d’un nouveau langage baptis´e Oak, extrˆemement lisible, purement orient´e- objet et surtout ind´ependant autant que possible du mat´eriel sur lequel il serait amen´e `a ˆetre d´eploy´e.

(31)

3.2. LA TECHNOLOGIE JAVA

3.2 La technologie Java

La technologie Java regroupe deux concepts : Java est `a la fois un langage de program- mation et une plateforme. La plupart des langages permettent soit leur interpr´etation, soit leur compilation sur une machine donn´ee en vue de r´ealiser une ex´ecution. Java a cela de singulier qu’il est `a la fois compil´e et `a la fois interpr´et´e dans la plus grande majorit´e des cas. Avec le compilateur, il est possible de transformer le code ´ecrit en langage Java en bytecode. Le bytecode Java est un code ind´ependant de la plateforme qui sera inject´e dans un interpr´eteur pr´esent sur le syst`eme local. La compilation n’ est requise qu’une fois, alors que l’interpr´etation aura lieu `a chaque fois que le programme est ex´ecut´e. La figure 3.1 illustre ce m´ecanisme.

Fig.3.1 – Sch´ema classique de mise en oeuvre de Java. Le code est compil´e sous un format ind´ependant de la plateforme et est ensuite ex´ecut´e sur un interpr´eteur li´e au syst`eme.

La g´en´eration d’un bytecode qui sera par la suite interpr´et´e permet de d´evelopper des applications sans se soucier de la plateforme finale de d´eploiement : il suffit en effet qu’un interpr´eteur Java, connu sous le nom de Java Virtual Machine, soit pr´esent sur la plateforme cible. De tels interpr´eteurs existent actuellement pour quasi toutes les combinaisons de syst`eme d’exploitation et de composante mat´erielle : du PC sous Windows jusqu’`a la station multi-processeurs utilisant des CPU SPARC en passant par toutes les versions de Linux (x86,Alpha,Sparc, etc.). La figure 3.2 illustre le d´eploiement d’une application compil´ee en bytecode Java.

On comprend donc tout l’int´erˆet d’un tel langage dans un environnement h´et´erog`ene de machines interconnect´ees entre elles au moyen d’une couche r´eseau. Nous verrons ´egalement dans le chapitre suivant que l’existence sur chaque machine d’un code commun, le bytecode, ouvre des perspectives nouvelles quant `a l’utilisation d’objets distribu´es et aux possibilit´es de transfert de code d’une machine virtuelle `a une autre. Enfin, un autre aspect non n´egligeable de nos jours est la possibilit´e de r´ealiser de mani`ere extrˆemement facile des interfaces graphiques (GUI : Graphical User Interfaces) au moyen d’un ensemble de classes pr´ed´efinies en Java. On peut ainsi r´eduire drastiquement le temps consacr´e `a l’´elaboration de l’interface homme-programme puisque le canevas d’´elaboration est le mˆeme quelle que soit la plateforme, ´evitant ainsi de devoir recourir `a des biblioth`eques propri´etaires peu portables et souvent fort lourdes `a maˆıtriser.

(32)

Fig.3.2 – Le bytecode produit par la compilation pourra ˆetre interpr´et´e sur une JVM sans se soucier des composantes mat´erielles du syst`eme.

Portabilit´e

Le choix du langage Java pour le d´eveloppement des applications d’instrumentation distribu´ee est souvent mis en ´evidence dans la litt´erature [22] [23]. En effet, de telles archi- tectures sont caract´eris´ees par la mise en pr´esence de syst`emes d’exploitation forts diff´erents selon qu’il s’ agisse de stations client conviviales ou de machines noeuds du syst`eme de me- sure choisies plutˆot pour leur robustesse. Java permet de r´ealiser des applications portables, interop´erables entre toutes ces machines en utilisant un mˆeme mod`ele de d´eveloppement, les mˆemes outils et surtout en faisant appel `a des comp´etences semblables, quel que soit l’aspect du probl`eme abord´e : client ou serveur.

De plus, l’exploitation de techniques propres `a Java, telles que les applets, permet d’enrichir encore l’exp´erimentation, permettant ainsi aux utilisateurs d’acc´eder `a des pr´esentation des r´esultats via leur navigateur Internet habituel. Rappelons ici que les applets sont de pe- tites applications graphiques qui peuvent ˆetre ex´ecut´ees dans un navigateur Internet pour autant que celui-ci int`egre une Java Virtual Machine. l’utilisateur, en se connectant sur le site contenant l’applet, initie le chargement puis l’ex´ecution de celle-ci dans le navigateur, permettant ainsi d’obtenir une pr´esentation des donn´ees ou d’envoyer des commandes `a un syst`eme distant.

Interfa¸cage de code natif C ou C++

Un autre aspect important du langage Java est sa capacit´e `a pouvoir interagir avec du code natif de mani`ere totalement transparente [19]. On entend par code natif tout type de code binaire compil´e sp´ecifiquement pour une machine donn´ee tournant sous un syst`eme d’exploitation donn´e. On pourrait citer comme exemple n’ importe quel programme compil´e sous Windows/Intel ou n’ importe quelle biblioth`eque mise `a disposition sous Linux/Intel.

Le langage d’origine du code natif n’ a pas d’importance puisqu’il s’ agit d’adresser du code relogeable ; n´eanmoins les outils mis couramment `a disposition couramment ciblent plus particuli`erement les langages C et C++.

(33)

3.3. RMI

Il faut ˆetre conscient qu’il s’ agit en quelque sorte d’une entorse faite au principe de portabilit´e mais la volont´e de rester compatible avec les programmes existant auparavant explique ce qui a motiv´e les concepteurs de Java `a d´evelopper cette interface native connue sous le nom de JNI (Java Native Interface).

Exploitation du code natif

Le code natif a principalement deux utilit´es : l’exploitation des ressources locales de la machine au moyen d’un code plus rapide, plus puissant et le d´esir de pouvoir mener des actions sur des ´el´ements du syst`eme qui ne sont pas repris dans la plateforme Java. A titre d’exemple, il pourrait s’ agir dans le premier cas de routines ultra-rapides de traitement digital du signal et pour le second de l’´ecriture dans les registres des cartes mat´erielles pr´esentes sur l’ordinateur.

Comme nous le verrons plus tard, cette derni`ere technique a ´et´e mise en oeuvre dans le pr´esent travail afin de permettre la prise de contrˆole du bus GPIB par un programme Java au moyen des biblioth`eques standard fournies par le constructeur de la carte. Notons que l’utilisation du langage C ou C++ standard jumel´e avec un code soign´e du point de vue de la portabilit´e, permet n´eanmoins de d´eployer assez facilement de code natif venant de pair avec une application Java. De plus, dans le cas pr´esent de l’instrumentation, des biblioth`eques fortement standardis´ees existent pour un grand nombre de plateformes natives utilisant le langage C. Ce dernier point, plus propre `a la r´ealisation pratique du syst`eme d’instrumentation sera trait´e dans la seconde partie de ce travail.

Les extensions de la plateforme Java

Une autre particularit´e de la plateforme Java est l’existence d’un grand nombre d’exten- sions, permettant par exemple l’utilisation des ports de communication s´erie ou parall`ele, le d´eploiement sur des stations mobiles l´eg`eres (PDA ou GSM), ou l’implantation de Java dans des syst`emes embarqu´es peu coˆuteux et pr´esentant des ressources m´emoire et calcul limit´ees. Ce large ´eventail d’ajouts `a la plateforme commune permet de consid´erer que l’utilisation de Java est un choix excellent et durable dans le temps, tant du point de vue de l’exploitation de l’´electronique embarqu´ee, de plus en plus pr´esente autour de nous, que du point de vue du programmeur d’applications complexes orient´ees utilisateur.

3.3 RMI

Nous avons expos´e dans le chapitre 2 le syst`eme d’objets distribu´e CORBA. Les concepts introduits par l’OMG dans le cadre de la mise en oeuvre de CORBA d´ecoulant de prin- cipes g´en´eraux relatifs `a la mise en oeuvre d’objets distribu´es, ceux-ci sont ´egalement le fondement de la Remote Methode Invocation (RMI) de Java [3]. Nous pr´esenterons dans un premier temps le mod`ele RMI, puis nous exposerons une technique de partage de classes entre le client et le serveur connue sous le nom de chargement dynamique du code mobile.

(34)

3.3.1 Le mod` ele propos´ e par Java : RMI

Comme nous l’avons ´evoqu´e, la Remote Method Invocation (RMI) de Java s’ apparente au sch´ema classique de distribution d’objets sur un bus r´eseau, `a cette exception pr`es que le but recherch´e n’ est pas ici d’interfacer tous les langages possibles mais bien de conce- voir des applications distribu´ees issues d’un mˆeme langage : Java. Ces applications seront donc amene´es `a r´esider sur des machines virtuelles [14] diff´erentes et non sur des plate- formes diff´erentes. Cette diff´erence apparaˆıtra fondamentale dans le paragraphe suivant.

La figure 3.3 pr´esente les ´el´ements d’une application ´ecrite au moyen de RMI.

Fig. 3.3 – Protocoles mis en oeuvre par RMI

Dans un premier temps, Le serveur appelle leregistry afin d’associer un nom symbolique avec l’objet qu’il met `a disposition sur le bus. Le client peut alors entamer un processus de recherche et interroger le registry sur la pr´esence ou non d’un nom de service disponible.

En cas de succ`es, il obtient alors une r´ef´erence sur l’objet correspondant et est `a mˆeme d’invoquer sur ce dernier une m´ethode particuli`ere.

L’ensemble des m´ethodes disponibles aupr`es du serveur est d´ecrite au moyen d’une interface connue du client et du serveur. Cette approche est semblable `a celle propose´e par CORBA au travers de l’IDL. Rappelons `a cet effet qu’une interface est un formalisme

´enon¸cant le comportement d’une objet, mais ne r´ealisant pas l’impl´ementation de la classe.

Il s’agit donc d’un ”contrat” que s’engage `a remplir la classe impl´ementant l’interface, dont la r´ealisation finale est discr´etionnaire.

Comme nous le verrons dans la section suivante, des serveurs Web sont ´egalement utilis´es par RMI afin de permettre le transfert de bytecode entre le client et le serveur.

Insistons bien ici sur le fait qu’il ne s’agit pas de la marshallisation proprement dite d’objets, tels que les param`etres des m´ethodes activ´ees, mais bien de transf´erer, le besoin ´ech´eant, des classes depuis un intervenant jusqu’`a l’autre. Ce m´ecanisme n’a pas d’´equivalent en CORBA et est appel´e transfert dynamique de code mobile.

Références

Documents relatifs

• 1943 : Cr´ eation du ASCC Mark I qui permet de faire 3 op´ erations sur 23 chiffres par seconde, tr` es proche de la machine analytique de Babbage.. Les branchements

En particulier, nous discutons des extensions possibles pour le contrôle d’un ensemble de robots coopérants entre eux, mais aussi de la nécessité d’avoir des liens plus forts

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des

En d´ eduire une expression du cardinal de

[r]

Mots-cl´ es : espace sym´ etrique, tenseur de courbure, crochet de Lie, immeuble euclidien, immeuble ` a l’infini, groupe de Lie, alg` ebre de Lie, groupe arithm´ etique, groupe

La porte NXOR (ou porte NON OU exclusif) la plus simple possède deux entrées et une sortie. Elle réalise le complément d’un OU exclusif entre ses entrées. Si on reprend

Sous Linux, ouvrez une console et logez vous en tant qu’administrateur (tapez sudo -s et [enter] puis renseignez le mot de passe d’utilisateur pour vous connecter