IEEE International Workshop onVirtual and Intelligent Measurement SystemsBudapest, Hungary, May 19-20, 2001.

Development of Distributed Self-adaptative Instrumentation NetworksUsing JINI Technology

J-M. Dricot, Ph. De Doncker, M. Dierickx, F. Grenez and H. Bersini

Universite Libre de BruxellesService d’Electricte Generale

Elecgen CP 165/51Avenue Franklin Roosevelt 50

1050 Bruxelles – Belgium.E-mail: jdricot@ulb.ac.be.

Abstract – This paper describes a client-server architecture forthe creation of dynamic and self-adaptative instrumentationover the network, either local or the Internet. The proposedsolution allows multiuser, multi-instruments sessions by themeans of a new cooperative concept known as Jini. Clientsapplications take advantage of this system-independent tech-nology by using the Java programming langage.

Keywords – Open distributed measurement systems, intelligentsensors, Jini technology, mobile networks

I. INTRODUCTION

To understand why building robust softwares for the net-work is difficult, it is useful to look at the assumptionsa classical programmer relies on, and to submit to thatthey reveal to be false in the long run: network absolutereliability, zero-latency interactions and topology knowl-edge in terms of connectivity and instrumentation devices.Classical applications built on this model do not allow areal dynamic deployment of the instrumentation devicessince they do not provide enough reliability for wide scaleusage of mobile networks and they require the use of pro-prietary solutions. Changing a sensor by another is thussynonym of driver (re)installation or even of in-depth re-configuration of experiment software.

A solution is offered by a new cooperative technologyknown as Jini [1]. Jini runs on top of the Java platformand was first introduced by Sun Microsystems in January1999, with a host of licensees already on board includ-ing Xerox, Hewlett-Packard (Agilent), Cisco and Nokia.Jini enabled devices are able to communicate over thenetwork[4] to provide each other services that can be dis-covered and assembled dynamically, while the devices andthe consumers appear or disappear.

Using Jini one can provide dynamic access to the instru-ment at the time it is plugged into the network. Each de-vice is thus not just seen as attached to a specific computer

but as an independant and auto configurable network de-vice. Client applications can browse for instruments avail-able on the network and use them without any installationof any kind and without any code recompilation.

Since networks are inherently bandwith-limited andcan experience major connection failures, Jini providesa quality and reliability guarantee mechanism usefulto provide robustness. If an instrumentation devicesuddenly disappears or seems to experience failure, thewhole community is advertised thanks to broadcastedwarning messages.

Finally, since Jini is based on the Java technology whichprovides platform-independant deployment and object-oriented development [6][7], it enables integration withalready well-used network-distributed applications likeCORBA, LabVIEW or GPIB-ENET[5].

II. THE JAVA AND JINI TECHNOLOGIES

Java started out as an object-oriented langage called Oak,designed as a portable way to write platform-independantand network-oriented code for embedded processors. Itprovides common programming langage and deploymentregardless the operating system by the mean of a com-puter abstraction layer called the Virtual Machine.

Simply put, the Virtual Machine takes care of readinga Java compiled code – known as bytecode – and in-terpretates it for execution on the local system (Fig-ure 1). Such a Virtual Machine is available for nearlyany CPU/System combination, from PC/Windows toSparc/UNIX and Linux. Embbeded systems can also takeadvantage of Java technology using special Java editionknown as MicroEdition. These run on Motorola and Intelprocessors relative to small and lightweight systems. Re-searches are also currently undertaken to develop a pure

Fig. 1. Hardware abstraction with Java

Java processor, allowing thus to run Java directly overthe target hardware, without slowing the execution withthe interpretation process. Using these principles, one candevelop and compile under a given machine and directlydeploy the code over any other host that has a Java Vir-tual Machine or a Java processor installed.

Java is also backward compatible with old code and itcan use any library written in C or FORTRAN. Thistechnique, known as the use of native code allowed us forexample to write a Java program to locally control stan-dard GPIB devices using widely available C developmentlibraries.

In some ways, the history of Jini is an extension to the his-tory of Java – it fullfils the vision of a group of consumer-oriented electronic devices interchanging data and capa-bilities. Jini technology was first released January 25,1999 by Sun Laboratories and is now avalaible as a free ofcharge package that can be downloaded from the internet.While Jini implementation still varies from release to re-lease, the specifications are publicly released and frozen.We can thus rely on them to develop a long term solution.

III. THE JINI INSTRUMENTATION NETWORKS

The Jini instrumentation networks we deployed rely on 4key elements (see fig2):

1. the Lookup is a PC that manages the network, col-lects information about available services and inter-connects dynamically clients and instruments. Italso monitors device or network failures and dispatchevents to registered clients.

2. the Services which are provided by the instru-ments and are to be used by the client applica-tions. For example, a voltage measurement serviceis associated with voltmeter instrument. Advanceddevices can provide multiple services, e.g. volt-age/current/impedance measure capabilites for com-mon multimeters.

3. the Client is the service consumer. It looks upservices it wants to use via the Lookup and registers

for events. The client simply specifies to the Lookupwhat kind of services it wants to use and then getsfrom the Lookup to give it the necessary informationto connect to the matched services.

4. the Leases. Each device on the network is monitoredby the Lookup using a leasing mechanism. This en-sure flexible apparition or departures conditions andallows the detection of abnormal behavior of instru-ments – sudden disappearing or software crash.

The Jini model also supposes that the network layer isproperly configured. This is easely achieved dynamicallyby well know techniques such as DHCP (Dynamic HostConfiguration Protocol) which takes care of configuringon request a machine appearing on the network. Such alight management software is actually embedded in mostnetwork routers and could be also put in a future hardwareversion of the Lookup service.

Jini-enabled devices and softwares interact using a com-mon scheme to create the local instrumentation system.One Lookup need to be present on the network to orches-trate the transactions. Redundant Lookups can be put toincrease reliability or to act as bridges between two net-works. Since a Lookup service is a java program, it can berun on top of a standard, commercial computer or it couldbe embedded into a pure hardware machine dedicated tothis role. Hardware Lookup are thus low cost and easy todeploy.

IV. THE JINI MECHANISM

In a first step, the instrumentation device tries to discovera Lookup using a broadcasting technique[3]: it sends pack-ets to all machines and waits for a positive response (seefig2)

Fig. 2. initial situation

As soon as a local Lookup is detected, the device sends

to it a portion of code called a proxy. The Lookup is therepository of all the proxies coming from detected devices(see fig3).

Fig. 3. Proxy is sent to Lookup

Any client application on the network can ask the Lookupif a given service is present on the network (for instance agiven device located in a given room). If the Lookup holdsone or more proxies matching the needs of the client, itsends a copy of the requested proxy to the client(see fig4).This proxy has thus travelled point-to-point from the de-vice to the consumer program without need of knowingeach other network parameters, such as IP address or pro-tocol.

Fig. 4. Client searchs and gets device’s proxy

The instrument proxy sent to a client can be seen as somekind of driver that is dynamically installed on request andthat can be removed after use, without requiring humanintervention or reconfiguration. In our case, the proxy isused by the client to call back the device. Jini does not laydown a specific protocol at that point and the remote con-trol can be performed using CORBA (distributed objectsindustry standard), ENET-GPIB or Java’s RMI (RemoteMethod Invocation). The whole ”callback” method is en-tirely included in the proxy and does not need to be knownby the parties (see fig5).

It is important here to note that looking up for a proxysupposes that the client has prior knowledge of the kind of

Fig. 5. proxy is used control remotly the instrument

service it wants to use. For example, a voltage monitoringprogram wants to find a voltmeter or a more complexdevice offering at least the ”measure voltage” ability. Thismutual knowledge can be implemented by using specialobjects called interfaces. These interfaces define what thedevice is able to do in a standard form, but not how itdoes it. Altough each manufacturer has the freedom todevelop its own implementation of the service and putits own code in the service, everyone knows how it willlook like ”from the outside” and how to gain access tothe instrument. Interfaces are used to define a commoncanvas of work and communication.

It is here obvious that enabling Jini in instrumentationtechnology needs the manufacturers to agree on a stan-dardized set of common interfaces. Currently, no commoninterfaces are officially set by software manufacturers orstandardization organism, but the in-depth analysis of thedevices functionalities and the way they interact has ledus to propose a first definition which could be used as abasis for further standardization. Since this definition isimplemented in the Java programming language, it can beused to describe and develop applications in any objectoriented language. CORBA or DCOM systems, largelyused to deploy distributed applications over the networkcan rely on this descriptive and object oriented structureof the virtual instruments and take advantage of the priorknowledge of the attributes of the objects present on thebus.

V. BUILDING SELF-ADAPTIVEINSTRUMENTATION OVER JINI

Actual mobile instrumentation networks are bound to theknowledge of present hardware and the use of proprietarysolutions[2]. Using Jini, gaining control to a voltmeter isas easy as plugging a network cable in the device. ButJini offers also solutions to robustness and reliability.Each proxy sent by a service to a Lookup is stamped witha leasing agreement established by the service and theLookup. This lease can be cancelled properly at any time

and is to be renewed periodically to ensure the device isstill alive on the network. If it cannot be renewed, theLookup in charge of the device broadcast messages tothe client, indicating that devices network topology haschanged.

The proxy can also be enhanced to provide morefunctionalities. Beside offering remote measurement,the proxies we developed hold a set of graphical userinterfaces for purpose of displaying devices front panels,installation wizards or even debugging environements. Asusual with the proxies, no prior knowledge or installationare required. These softwares are sent directly by thedevice and are automatically uninstalled after leaving thelocal area network, thanks the Java cleaning mechanismknown as garbage collection: objects present on themachine that are not bound to any particular usage andthat are not required anymore by any piece of code areperiodically collected and removed from the memory.This mechanism is designed to ensure that there will beno leak of dynamic memory on the local machine andcan be seen here as a sort of uninstallation of the codethat was downloaded from the service. Many proxiescan thus be downloaded and used for a given time, andonce the experiment is finished, the programs uninstallsproperly, cleaning the client side of the experiment.Because Jini concepts are not limited to the controlof devices, Jini-enabled software can also be put onthe network to offer assitance and intelligent decisionmechanism available for all elements taking part in themeasurement process. One could develop mobile agentsor intelligents agents available from the local networkto perform decisional-level tasks, data collection or toincrease reliability via monitoring processes.

Virtual instrumentation softwares (e.g. LabVIEW)integration is possible with special VI’s that connect onthe network as clients and provide dynamic presentationof devices available for measurement. These devicescan be added or bound to diagram elements just as ifthey where classical GPIB instrumentation devices withthe advantage that no reconfiguration is needed if aninstrument is replaced by another with the same capa-bilities – they juste have to present the same interface.We have shown that such an integration requires noin-depth redevelopment of current applications. Theuse of Jini functionalities is possible by the means ofa handling layer written in Java and working with theapplication. This layer has been designed to manageevery aspect relative to Jini and it presents the availableinstruments to the application. The layer and the appli-cation interact using a very minimal set of functions, forexample a simple VI library in LabVIEW, demonstrating

that it can be viewed as an add-on or plugin, ratherthat a piece of code that must be compiled in the software.

Finally, Jini technology can be used to improve reliabil-ity, scalability and maintenance in large scale experimentsor enterprise measurement environements. If one devicefails during the time of the experiment, it can be directlyreplaced by another Jini-enabled device as much as thereplacement device is able to provide the same fonction-ality. Heterogenous devices networks, mostly in term ofmanufacturers, are no more a problem because the devicesare seen as fonctionalities present on the network, not asa particular instance of a given device locally present. De-vice replacement thus means only to unplug the defectivedevice to plug in a replacement one.

VI. REMOTE INSTRUMENTATION

We have seen that Jini services and clients can act ona local network, such as a classical enterprise network ,when they are able to detect the local Lookup using abroadcasting technique. Jini also offers the possibility tobypass the broadcasting-based discovery process to desig-nate the address of a prior known local Lookup. Since thelocation used in this method must only be a valid TCP/IPadress, one could reference a Lookup located anywhere onthe Internet. The services using that Lookup will thus beavaible for the clients connected with that remote Lookup.Many use cases are then possible:

1. control of remote devices that are looked up by aclient on a distant location

2. making avalaible local devices from a remote labo-ratory anywhere on the Internet

3. using a company-centric Lookup to put largelyspread clients and services in touch. These clients orservices can be thus distributed far from each otherbut, as they communicate with a central point, theyare available as if they were present locally.

This static vision of Jini is in fact a complementary of thedynamic one we have exposed upper. The innovative ap-proach compared to the well-known technique of remotecontrol is the common scheme of development enabled byusing Jini-based on a set of well known interfaces. Onecan thus develop an application that will be globally func-tional, because everyone knows what kind of objects andfunctionalities will be available on the remote side andthat the application developped for local control of devicesuses the same principles in case of distant measurementexperimentation.

VII. THE INNOVATIVE APPROACH OF JINI

Many solutions exist for remote control or distibuted com-puting, but Jini offers some enhancements that enable

totally new possibilities for distributed virtual instrumen-tation.

First of all, Jini distinguishes from the other distributedsystems protocol, like CORBA or RPC (Remote Proce-dure Call), in that it does not only call a function or use aremote object (in term of object-oriented programming)but also transfers a piece of program from the service tothe client. This vision leads to the usage of smart proxiesthat can be used to communicate with the remote in-strument but also could make the post-treatement of thedata acquisition on the client, for example FFT analysis,graphical display. All these possibilities are contained inthe device.

Jini also differs from electronic systems used for remotecontrol thanks to the dynamic deployment of the device.The usage of remote instruments actually suppose theknowledge of their TCP/IP address and require to havethe correct driver to be installed on the client machine.Because all the necessary software is embedded in the de-vice itself, a Jini device is far more flexible and deploysfaster.

VIII. PRACTICAL JINI DEPLOYMENT EXAMPLE

All of the above explained concepts were used in an experi-ment taking place at the University of Brussels(ULB). Theexperiment concerned digital voltmeters used in a hypo-thetical measurement experimentation in our laboratory.Each device is controlled by a standard computer usingGPIB connectors. Since the Jini service is built on theJava platform, we used here the native code usage capa-bility of Java to control the GPIB bus using C libraries onthe local machine (see Fig.6). The proxy of the voltmeter

Client

LookupTranslation box

Fig. 6. Enabling Jini with standard PC

service is able to fournish the voltage. It also provides agraphical interface that can be used to set location of thedevice, and a small comment helping to fix its role in theexperiment. These information are used later to browsethe devices on the network and to choose the one we wantto connect to.

A second service represents a digital multimeter that isable to measure voltage, current, impedance and fre-quency. It provides a proxy similar to the one of the firstdevice but also one for current measurement, one for thefrequency and one for the impedance. That device offersthus 4 services.

Fig. 7. The devices browser

As soon as the devices are plugged in the network, theyappear in the client browse list and are categorized on thebasis of their functionalities. We can see on Fig. 7 thatthe second device is available in four categories: one foreach service it offers. Note here that it is just a questionof software to enable or disable a service that a deviceoffers on the local Jini bus. One can restrict the field ofaction of an instrument by selecting which interfaces theproxy of the device implements.

The device can now be used in the client application orbe asked to transfer on the client-side its graphical con-figuration interface. Using that interface, one can set upnew parameters for the device and , as soon as the newarguments are set, the client are notified by a propagatingevent that the device has changed its configuration.

Remote events are also used when the device disappearssuddenly. When the leasing renewal sequence can nomore take place between the service and the Lookup, theLookup discards the local copy of the proxy it holds andsends an alert event to the clients. Many ”crash tests”have been practised using typical security time as small asten seconds, all showing confident reliability in the moni-toring of the presence and the availability of the devices.

Finally, connecting the two devices to the same source

of signal allowed to use any of the voltmeters withoutany kind of reconfiguration, simply switching from onesoftware service to the other.

IX. ENABLING JINI IN DEVICES

Jini is built on top of Java to offer code mobility anddynamic interoperability. Allowing a device to join a Jinicommunity requires the device to be able to run Java pro-grams. Such hardware exists in the form of the PicoJAVAprocessors. They are designed to execute Java bytecodeon an embedded electronic device, allowing to integrateJini technology directly in the device. This technology isalready available by major electronic manufacturers andit offers cheap solutions for building Jini-enabled embed-ded devices. Another solution is to consider the use of theKVM, a small signature Java Virtual Machine that wasdesigned to run over Intel x86 and Motorola processors.These processors are widely used in small devices and pro-vide two major advantages: their low cost and the use ofwell known and easy to find development environements.

Finally, an easier to deploy solution is the use of stan-dard PC controlling instruments via standard ports suchas GPIB, serial or parallel controllers. The computer actsthen as a ”translation box” that allows to run the soft-ware needed to join a Jini community. The remote con-trol instructions received by the service are translated intoinstrument-specific instructions and sent locally to the de-vice. This configuration and the use of GPIB-ENET allowalso to create a centralized set of services that can be usedas a bridge between GPIB-ENET networked instrumentsand the Jini services.

X. CONCLUSIONS

Using Jini technology enables dynamic instrumentation inan easy to implement fashion. It provides open program-ming model interfacing with industry-standards solutionslike CORBA and LabVIEW. Absolute interoperability be-tween the actors of measurements is achieved by abstrac-tion mechanisms which hide vendor-specific implementa-tion requirements. The existing devices can easily becomeJini-enabled by putting a small embedded system in thedevice itself or on GPIB connectors. Helper and intelli-gent modules can be developped and added ”on-the-fly”to help improving instrumentation network capabilitiesand meeting local engineering needs. Remote instrumen-tation on distant systems can be achieved using the samescheme of development as for local control of instruments,enabling an easier scheme of development.

References

[1] W. Keith Edwards: ”Core Jini 2nd edition”, Prentice Hall PTR,Java Series, 2001

[2] Fortino Grimaldi Nigro, ”IEEE trans. instr. and meas.”, vol. 47,no. 5, oct. 1998

[3] S. Deering, ”Host extensions for IP multicasting”, IETF RFC1112, Aug. 1989

[4] P. Arpaia, A. Baccigaluppi, F. Cennamo, P. Daponte, ”A dis-tributed laboratory based on geographic network”,Proc. ImekoTC-4, Budapest, Sept. 96, pp 294-297

[5] D.J. Rawnsley, D.M. Hummels, B.E. Segee, ”A virtual instru-ment bus using network programming”, Proc. IEEE IMTC/97,vol.1, pp. 694-697.

[6] P. Arpaia, F. Cennamo, P. Daponte and M. Savastano, ”A dis-tributed measurement laboratory based on object oriented sys-tems”, in Proc. IMTC/96,Brussels, June 1996, pp 27-32

[7] P. Daponte, D. Grimaldi and L. Nigro ”Distributed measure-ment systems: An object oriented architecture and a casestudy”, Comput. Standards Interfaces,vol. 18, no. 5,pp 383-395,june 1997.

Jean-Michel Dricot was born in Belgium in 1976. Hehas been graduated in Computer Science Engineering atthe University of Brussels, Belgium (ULB) where he iscurrently working on a PhD. His main interest concernsdistributed objetcs, cooperative and mobile agents and thedesigning of smart embedded devices.