Remote Target Monitoring in Embedded Systems Lab Courses

using a Sensor Network

Christian Trodhandl, Markus Proske, and Wilfried ElmenreichVienna University of Technology,

Institute of Computer Engineering,Treitlstrasse 3, 1040 Vienna, Austria

{troedhandl,proske}@ecs.tuwien.ac.at, wil@vmars.tuwien.ac.at

Research Report 93/2006

Abstract – This paper describes an architecture forremote monitoring of a distributed embedded systemvia Internet. The data at the target system is gatheredwith a time-triggered sensor network which transmitsthe measured values to a local target server. The sen-sor network approach makes the system easily adapt-able to different embedded target systems.

The sensor network is connected to a target serverthat communicates via Internet with visualization andprogramming tools at the monitoring computer. Thevisualization clients provide a live display of the pa-rameters of the observed system.

The target server acts as a gateway between targetsystem and monitoring clients and provides securityand authentication features for connecting monitor-ing clients. One target server is able to serve formultiple target systems.

As a case study, the presented system will be usedin an embedded systems lab course where studentsare requested to implement various applications onan embedded target board. Using the remote moni-toring feature, a student is able to do the work fromhis or her home place.

1 Introduction

The increased use of embedded applications in the do-mains of automation, process control, transportationsystems, ubiquitous computing, etc. calls for meansto monitor and control the embedded system with-out the need to be physically at the place of the ob-served system. We will follow a remote monitoringapproach using Internet technologies as it is used inapplications in the automation domain [1, 2, 3, 4] andin railway transportation systems [5].

Typically, the monitored target system has real-time properties, which puts real-time requirementsonto the monitoring system. When also consider-ing aspects like flexibility, extensibility and, since themonitored data is usually transmitted over the In-ternet, security, the design of the monitoring systembecomes a challenging and difficult task.

This paper presents a distributed remote monitor-ing system based on a real-time fieldbus network, anInternet server, and a data visualization system onthe user’s PC. The real-time fieldbus network inter-connects several smart transducers that periodicallygather measurements from the process variables ofinterest. The fieldbus approach supports the flexibleadaption of the system to different target systems.The resulting data is forwarded to a target server thatcommunicates the data via Internet to the user’s PCwhere a dedicated visualization software displays theactual system state.

As case study, we present a distant learning appli-cation which enables students to implement and testembedded software on real embedded systems hard-ware. The case study supports the parallel monitor-ing of several target boards which are connected toa target server. An authentication server takes carethat students can access only their admitted targetboards. For the communication between the targetserver and the visualization and programming toolsat the students PC, we have developed the so-calledRemote Workplace Protocol (RWP).

The remaining parts of this paper are organizedin the following way: Section 2 elaborates generalrequirements for remote monitoring of embedded ap-plications. Section 3 describes the monitored systemused in the case study. Section 4 presents the time-triggered fieldbus approach used to do the real-time

gathering of the monitored data. The authenticationand data transmission and visualization is describedin Section 5. Section 6 describes the local client sys-tem. Section 7 describes how remote monitoring willbe used in our embedded systems lab-courses. Sec-tion 8 briefly discusses related approaches providingremote access to embedded systems hardware. Sec-tion 9 concludes the paper.

2 General Requirements forRemote Monitoring

A typical remote monitoring application comes withseveral requirements in real-time capabilities, archi-tectural requirements, and security/collaboration is-sues:

Firm real-time support: In order to get sufficientinformation, it is necessary to periodically andregularly sample the real-time variables of thetarget system with appropriate speed. In theorywe need at least Nyquist frequency [6], that is thedouble of the highest frequency in the monitoredsignal, to reconstruct the signal dynamics. Inpractice an oversampling of about ten times ofthe signal with highest frequency is convenient.

Synchronized snapshots: The time difference be-tween two concurrent measurements of differentvariables should be minimal in order to receiveconsistent snapshot views of the target system.

No interference at the target system: Themonitoring system must not interfere in thefunctionality of the measured system. Note thatin an embedded system such a probe effect [7]can arise from inserted monitoring code aswell as from active measurement methods(e. g., ultrasonic sensors emitting a scanningsignal), heat dissipation, and shared resourcessuch as common power supplies or, especiallyin wireless system, shared bandwidth of thecommunication system.

Bandwidth: The bandwidth of the fieldbus systemand the Internet stream must be sufficient in or-der to transmit the monitored data.

Temporal accuracy: The freshness of the datamust be provided at the user’s PC, especiallywhen the user is intended to perform feedbackactions on the observed system.

Target system flexibility: The remote monitor-ing system should be adaptable to different tar-get applications without the need to performchanges throughout the whole monitoring archi-tecture.

Target system extensibility: The number ofcomponents in a typical embedded applicationsis likely to increase, therefore the system shouldsupport monitoring of large embedded systemswith a high number of process variables. More-over, it should be possible to use the systemconcurrently for multiple processes.

Flexible client system: Since the idea of remotemonitoring is to enable the access from an arbi-trary place in the Internet, it would be counter-productive to require an extensive setup of thespecific visualization and communication soft-ware at the clients computer.

Secure access: We require a save authenticationand data transmission for the monitoring sessionin order to avoid interception or interference ofdata from an outside attacker.

3 Target System

Our target system to be monitored contains four 8-bitmicrocontrollers (Atmel AVR ATmega128) which in-strument a display, a small light bulb, a photo sensor,a temperature sensor and a small cooling fan. Fur-thermore, the nodes are interconnected by an ISOk-line communication bus. Figure 1 shows a tar-get board with microcontroller nodes, add-on hard-ware, JTAG debugging interface board, and measure-ment network. Unlike standard debugging boards,our JTAG debugging board was especially developedin order to support an electronic switching betweenmultiple target processors without the need to locallyre-plug the debugging cables.

Thus, the target system contains the following datasources to be monitored:

Seven-segment display: The seven-segment dis-play consists of 8 separate seven-segment digitswhich are refreshed with a frequency of 100 Hz.A single digit has 8 connections for the cathodesof the LEDs (7 segments and one decimal point)and one for the common anode. The multiplex-ing is done by applying supply voltage to oneof the eight anodes and thereby activating thecorresponding digit. A segment is lit if supply

Table 1: Sensor inputs and expected data rateI/O Sampling frequency data size req. Bandwidth7 segment display 100 Hz 24 bytes 2 400 bytes/sLight bulb input 50 Hz 3 bytes 150 bytes/sPhoto sensor 50 Hz 1 byte 50 bytes/sTemperature sensor 50 Hz 1 byte 50 bytes/sMotor input voltage 50 Hz 1 byte 50 bytes/sMotor rotation speed 160 Hz 2 bytes 320 bytes/sISO k-line signal (compressed) – – 10 000 bytes/s

voltage is applied to the common anode and thecathode is pulled to ground. The current contentof the display can therefore be stored in an arrayof 8 bytes. A second array can be used to storethe activation time of each digit to represent thebrightness of each digit.

Light bulb input signal: The brightness of thelight bulb is controlled by pulse-width modu-lation (PWM). The interesting parameters forPWM are the signal frequency (two bytes) andthe duty cycle percentage (one byte). Since thelight bulb reacts rather slowly to the control sig-nal, a sampling frequency of 50 Hz is sufficientfor monitoring the light bulb signal.

Photo sensor: The photo sensor converts the lightemitted by the light bulb to an analog voltage.This voltage is digitized to an 8 bit value. Asampling frequency of 50 Hz is sufficient for mon-itoring the photo sensor.

Temperature sensor: The temperature of the

Figure 1: The remote workplace target board

Target Server

FieldbusSensors

SystemTarget

Smart Transducers

Gateway

Figure 2: Monitoring network system

light bulb is measured by a temperature sensorand also converted from an analog voltage to an8 bit value. A sampling frequency of 50 Hz issufficient for monitoring the temperature sensor.

Motor input voltage: The supply voltage of thefan motor is measured by an 8bit analog/digitalconverter. We have specified a sampling fre-quency of 50 Hz for the monitoring the supplyvoltage.

Motor rotation speed: The motor supplies a ro-tation speed signal with one impulse per revo-lution. The rotation speed of the motor can becontrolled in a range of 580 to 9600 revolutionsper minute, thus, the expected maximum datarate if one assumes a 2 byte integer for the speedis 320 bytes/sec.

ISO k-line bus: The four microcontrollers used inour target system are interconnected by an ISOk-line bus. The bus communication will be com-pressed by run-length encoding, the compressedsignal is expected to require a bandwidth ofabout 10 kbytes/s. Different from the other sen-sor inputs, the ISO k-line signal is captured by

Internet

. . .

Authentication Server

Target Server

Student PC

Targets

� � �� � �� � �� � �

� �� �� �� �

DBUser

Figure 3: Overview of the remote workplace setup

the gateway node, thus, it does need to be trans-mitted via the fieldbus network.

Table 1 summarizes the expected data rates for thedifferent sensor inputs.

The measured values (display content, motorspeed, . . . ) are transmitted via the gateway to thetarget server by a USB connection. The target servertransmits the data via Internet to the monitoring PC,where the current system state is visualized.

A first idea was to apply a digital video cameraviewing the target board that streams the informa-tion over the Internet. While this approach wouldbe rather generic (changing or extending the targetsystem would not require a change in the video sys-tem set up), we decided to use a dedicated measuringapproach for the following two reasons:

• The overall data rate in our application is about13 kbytes/sec — far less then the usual data ratefor a video stream. Thus, the transfer of mea-surement values and debugging data uses lessnetwork bandwidth than the transfer of a videostream.

• The camera would not show all information ofinterest. Due to frame rate restrictions, fastchanges on the display or motor would not bedisplayed properly. Furthermore, some datasources do not have a visual feedback at thetarget board like the temperature sensor or thestate on the communication bus (this would re-quire to connect an oscilloscope and other mea-surement devices for visualization).

Thus, we decided to use a specific measurementsystem that collects the data of interest.

4 Monitoring Fieldbus Net-work

The monitoring fieldbus system interconnects severalsmart transducers. A smart transducer is the inte-gration of an analog or digital sensor or actuator el-ement, a processing unit, and a communication in-terface. In case of a sensor, the smart transducertransforms the raw sensor signal to a standardizeddigital representation, checks and calibrates the sig-nal, and transmits this digital signal to its users viaa standardized communication protocol [8].

Each smart transducer periodically performs mea-surements on several target system variables andtransmits these to a gateway that is connected tothe target server via a USB interface. The smarttransducers are interconnected via a time-triggeredTTP/A [9] network. The time-triggered approachuses a global schedule for all communication, compu-tation, and action schedules. All nodes are synchro-nized to a global time which enables synchronizedactions, as for example triggering of measurementsand a predictable real-time data transfer using a pre-defined conflict-free TDMA scheme.

Figure 2 depicts the monitoring network architec-ture. The collected data is transmitted from thesmart transducers to a gateway node that forwardsthe data to the target server. Note that our archi-tecture supports multiple monitoring networks pertarget server as indicated in Figure 3.

5 Authentication and DataTransmission

The remote workplace software has to handle the fol-lowing tasks:

• Authentication of students: Login requests haveto be checked in the database.

• Assignment of time-slots: To assure each stu-dent a fair portion of the available target time,students can reserve target time. Without reser-vation, access time is assigned according to the“first come - first serve” principle.

• Data transmission: Measured values and debug-ging information have to be transmitted over theInternet and dispatched to the assigned target.Furthermore the students must be able to uploadtheir programs to the target.

Figure 4: Microcontroller node with attached seven-segment display and visualization of a display module

• Visualization of the target board: On the clientside, the remote workplace software has to visu-alize the state of the target system.

Figure 3 shows the different parts of the remoteworkplace setup: The authentication server, the tar-get server, the login client, and the visualization soft-ware.

For the communication between authenticationserver, target server, and local client software we de-veloped the RWP protocol. Requests and responsesbetween the programs are encoded using XML, op-tionally followed by a binary data stream which isseparated from the XML part by a single NUL char-acter. First the client software initializes a connec-tion to the authentication server. If the authentica-tion succeeds, a target is assigned to the student andan authentication cookie is transmitted back. Thiscookie is used by the visualization software to set updata connections to the target server. If the assignedtime-slot of the student expires the session is closed.

The RWP protocol builds the concept of so-calledendpoints – virtual sensors that form a hierarchy(similar to the directory hierarchy in a computerfilesystem) that is later mapped onto the hardwareby the target server. Since the RWP protocol is inde-pendent of the underlying sensor hardware, differenttypes of interfaces can be easily integrated by addinga new driver module to the target server.

6 Local Client Software

For our remote workplace setup we needed to get twothings to the students: The development environ-ment and the visualization software. Our develop-ment toolchain is based on the Free Software Foun-dation GNU tools in order to be able to distributethe client system without costs for software licenses.

The client set-up contains the following software:The cross-compiler avr-gcc (the normal gcc compiler

set up for cross-compilation for Atmel AVR 8-bit mi-crocontrollers), the automation tool make, and theGNU debugger gdb with the graphical frontend in-sight.

Additionally, a visualization system that providesa virtual dashboard [10] to allow the students to re-motely monitor the current state of the target boardis included within the client software. Using a webbrowser as visualization client at the user’s PC isa appealing approach, however experiences with re-mote monitoring applications running as Java appletshave shown that standard settings of communica-tion and access rights for Java applets in typical webbrowsers are very restrictive and hinder the commu-nication with local software (e. g., debuggers). There-fore, the visualization software runs as a stand-aloneJava program.

All the described software packages are availablefor several operating systems like Windows, Linux,and Mac OS X. However, our lab course requires toestablish about 120 students with the correct soft-ware setup. In order to avoid problems with het-erogenous environment and system software, we havedecided to provide all the necessary software on abootable CD featuring the auto-configuring Linuxsystem based on Knoppix [11]. Knoppix supportsvarious PC hardware (desktops as well as notebooktypes). Knoppix users do not need to have Linux orany other Software pre-installed on the user’s com-puter. The Knoppix system fully runs from CD anddoes not install any software on the user’s computer.However, it supports access to local harddisk in orderto store the user’s private files.

The Knoppix system we use has been customizedin order to provide our development toolchain andthe visualization software, which is tailored to visu-alize the state of the target system. After bootingthe Knoppix environment, the user starts a sessionby running the local client software. The softwarecontacts the authentication server and – if the login

Figure 5: Snapshot of the development environmenton a customized Knoppix CD

succeeds – is connected to a free target. Whenever alocal program is started, it contacts the login clientfor the assigned session cookie and uses this to con-nect to the target.

All connections between the local client softwareand the authentication- and target servers are accom-plished with the RWP protocol, using secure socketlayer (SSL) connections to achieve a secure communi-cation channel between client and server. The targetserver will transmit all measured values from the tar-get to the visualization client and will forward theGDB debugging stream which enables the studentsto debug their programs over the Internet. The au-thentication server keeps track of all user connectionsand terminates the session if the assigned time-slotelapses.

The visualization software will display the mea-sured values as a graphical visualization of the targetboard, where the hardware elements of the board aredisplayed in real-time similar as if was filmed by acamera (e.g., the picture of the display will show thecurrently measured values and the light bulb’s bright-ness shown on the screen will correspond to the mea-sured values).

7 Application Scenario

We are planning to deploy a remote workplace setupthat uses a graphical visualization of the targetboards in the “Embedded Systems Design and Pro-gramming” course in the winter term 2006/07. TheEmbedded Systems Programming (ESP) course isan undergraduate course designed to introduce third

year computer engineering students to design andprogramming of distributed embedded computer sys-tems. In the practical part of the course, the studentshave to implement three exercises like using a multi-plexed seven-segment display, controlling the speed ofa fan, or measuring the brightness and temperatureof a light bulb on an embedded system, consistingof four 8-bit Atmel AVR microcontrollers with 128kbytes program and 4 kbytes data memory that areconnected through a fieldbus network.

Students that want to use a remote workplace aresupplied with a customized Knoppix CD that in-cludes a full, pre configured development environ-ment for our remote target boards. To start a remoteworkplace session, the student inserts the KnoppixCD into his/her computer and reboots the system.On start-up the Knoppix system establishes an Inter-net connection using the standard DHCP protocol.

The student starts up the login client program thatcontacts the target server using the account data thatthe student received at the course registration. If thelogin succeeds the local client software is connectedto a free target and the student can start with his orher programming tasks.

The course programs are written and compiled lo-cally and then sent to the remote target system. Fig-ure 5 shows the desktop of a customized Knoppix CDwith various development tools.

For debugging the programs the GNU Debuggerfrontend insight is used that communicates with thetarget server using the GDB protocol. Visualizationclients are used to monitor the physical outputs ofthe tested software (see Figure 4 for a prototype vi-sualization of a seven-segment display). If a courseexample is finished, it can be submitted electronicallyover the Internet. The remote workplace session ei-ther ends if the student logs out or if the assignedtime-slot elapses.

8 Related Work

At the University of Technology in Sydney, Moultonet al. have developed an embedded systems lab withremote access [12]. Their target system is equippedwith a master server providing access to the devel-opment board and a camera server monitoring thetarget board. Master and camera server are accessi-ble remotely via Internet. The students’ computer re-quire an SSH (Secure Shell) client and a web browser.

Tzafestas et al. describe a remote robotic labo-ratory featuring an industrial robotic manipulatorand a camera accessible via a web-based graphical

interface connected to a robot and video Internetserver [13].

The NetLab approach [14] at the University ofSouth Australia provides remote access to measure-ment equipment that is interfaced via IEEE 4888.2, astandard interface to measurement instruments. Us-ing a LabView client, students are able to access theinstruments via Internet in order to gather measure-ment data. Additionally, a camera provides visualaccess to the set-up. However, since the target sys-tem is neither a programmable microcontroller nora remote configurable hardware, the possibilities ofinteractions are limited.

Gonzalez-Castano et al. describe a remote lab fea-turing target boards accessible through the Internetvia CORBA [15]. While in this approach studentswork with real hardware, there is not much interac-tion with a physical environment except for a modulethat allows students to remotely press physical but-tons. The module is connected directly to the targetserver via the printer parallel interface.

Callaghan et al. use a remote desktop approach toaccess a PC with connected measurement hardwareinterfaced by IEEE 4888.2 and various target sys-tems such as Microcontrollers, Field-programmablegate array, Digital signal processors, etc., which areinterfaced by an RS232 connection [16]. While theremote desktop approach easily establishes a remoteinterface, the approach is resource-demanding sinceeach working student monopolizes one workstationduring experiments.

The Virtual Laboratory project [17, 18] at the Uni-versity of Zagreb employs an architecture that is sim-ilar to our proposed approach. The architecture spec-ifies a CAN network that connects two C167 devel-opment kit to an Internet server. One C167 boardacts as development board for the students while theother one is used to monitor the effects on the phys-ical process environment.

The Internet server provides a web interface forlab time reservation, gives access to the developmentboard, and forwards the data from the monitoringnode. The students’ computer are running a Javavisualization client that displays the current state ofthe target system.

Besides technical differences regarding the type offieldbus network and employed web techniques, themain difference to our approach is that the targetsystem in the virtual lab is a single computer insteadof a distributed system.

9 Conclusion

We have presented a remote monitoring architectureon the example of a distant learning application. Thesystem consists of a monitoring network system ofnetworked smart transducers that collect data aboutthe target system. The data is made available onthe Internet via a target server using our RWP pro-tocol. The software on the client computer visual-izes the current state of the target system. In orderto be independent of the client computer’s softwaresetup, we propose a self-contained Knoppix systemthat contains all the necessary communication andvisualization software.

The general properties of our architecture make theapproach also interesting for different applicationswhere real-time monitoring, flexibility with respectto the target and the client systems and authenti-cated access is required. The used software is fullyeither open source or developed by our group so thatit is easily possible to extend the course size or set-upthe presented system at other universities without li-censing costs. The remote workplace will be usedin the course “Embedded Systems Design and Pro-gramming” in autumn 2006 at the Vienna Universityof Technology.

Acknowledgments

This work was supported by the SCDL project(http://www.ecs.tuwien.ac.at/Projects/SCDL/)from the Austrian “FIT-IT Embedded systems”initiative, funded by the BMVIT and managed byFFG (grant 808210).

We would like to thank Leo Mayerhofer for givingtechnical advice on computer interfaces.

References

[1] A. Weaver, J. Luo, and X. Zhang, “Monitor-ing and control using the internet and java,”in Proceedings of the 25th Annual Confer-ence of the IEEE Industrial Electronics Society(IECON’99), vol. 3, 1999, pp. 1152–1158.

[2] M. P. de Albuquerque and E. Lelievre-Berna,“Remote monitoring over the internet,” NuclearInstruments & Methods in Physics Research, vol.412, no. 1, pp. 140–145, 1998.

[3] K. Kusunoki, I. Imai, H. Ohtani, T. Nakakawaji,M. Ohshima, and K. Ushijima, “A corba-based

remote monitoring system for factory automa-tion,” in Proceedings of the First InternationalSymposium on Object-Oriented Real-time Dis-tributed Computing, Kyoto, Japan, Apr. 1998.

[4] F. Olken, H. A. Jacobsen, C. McParland, M. A.Piette, and M. F. Anderson, “Objects lessonslearned from a distributed system for remotebuilding monitoring and operation,” in Pro-ceedings of the Conference on Object-orientedProgramming, Systems, Languages and Applica-tions, Vancouver, Canada, Oct. 1998.

[5] T. Nieva, A. Fabri, and A. Wegmann, “Re-mote monitoring of railway equipment usinginternet technologies,” Faculte I&C, School ofComputer and Communication Sciences, Tech.Rep. Publication ID:200118, 2001, availableat icwww.epfl.ch/publications/documents/IC\TECH\ REPORT\ 200118.pdf.

[6] H. Nyquist, “Certain topics in telegraph trans-mission theory,” Transactions of the A.I.E.E.,vol. 47, pp. 617–644, Feb. 1928.

[7] C. E. McDowell and D. P. Helmbold, “Debug-ging concurrent programs,” ACM ComputingSurveys, vol. 21, no. 4, pp. 593–622, Dec. 1989.[Online]. Available: http://www.acm.org/pubs/toc/Abstracts/0360-0300/76897.html

[8] H. Kopetz, M. Holzmann, and W. Elmenre-ich, “A universal smart transducer interface:TTP/A,” International Journal of ComputerSystem Science & Engineering, vol. 16, no. 2,pp. 71–77, Mar. 2001.

[9] H. Kopetz et al., “Specification of the TTP/Aprotocol,” Technische Universitat Wien, Institutfur Technische Informatik, Vienna, Austria, Re-search Report 61/2002, Sept. 2002, version 2.00.

[10] W. Elmenreich, C. Trdhandl, and M. Proske,“Virtual dashboard specification,” TechnischeUniversitat Wien, Institut fur Technische Infor-matik, Treitlstr. 1-3/182-1, 1040 Vienna, Aus-tria, Research Report 76/2006, 2006.

[11] K. Knopper, “Building a self-contained auto-configuring Linux system on an iso9660 filesys-tem,” in Proceedings of the 4th Annual LinuxShowcase & Conference. Atlanta, Georgia,USA: USENIX Association, Oct. 2000.

[12] B. D. Moulton, V. L. Lasky, and S. J. Murray,“The development of an enviroment for remote

embedded systems: Feedback from studentsand subsequent enhancements,” World Transac-tions on Engineering and Technology Education,vol. 2, no. 1, pp. 65–68, 2003.

[13] C. S. Tzafestas, N. Palaiologou, and M. Al-ifragis, “Virtual and remote robotic laboratory:Comparative experimental evaluation,” IEEETransactions on Education, vol. 49, no. 3, pp.360–369, Aug. 2006.

[14] Z. Nedic, J. Machotka, and A. Nafalsk, “Re-mote laboratories versus virtual and real labora-tories,” in Proceedings of the 33rd ASEE/IEEEFrontiers in Education Conference, Boulder,CO, USA, Nov. 2003, pp. T3E1–6.

[15] F. J. Gonzalez-Castana, L. Anido-Rifon,J. Vales-Alonso, M. J. Fernandez-Iglesias,M. L. Nistal, P. Rodrıguez-Hernandez, andJ. M. Pousada-Carballo, “Internet access toreal equipment at computer architecture lab-oratories using the Java/CORBA paradigm,”Computers & Education, vol. 36, no. 2, pp.151–170, Feb. 2001.

[16] M. J. Callaghan, J. Harkin, T. M. McGinnity,and L. Maguire, “An internet-based methodol-ogy for remotely accesses embedded systems,” inProceedings of the IEEE International Confer-ence on Systems, Man and Cybernetics, vol. 6,Oct. 2002.

[17] G. Muzak, I. Cavrak, and M. Zagar, “The vir-tual laboratory project,” in Proceedings of the22th International Conference on InformationTechnology Interfaces, Pula, Croatia, June 2000,pp. 241–246.

[18] N. Peric and I. Petrovic, “Virtual laboratory forautomatic control and supervision - challengesand opportunities,” in Proceedings of UN-ECEInternational Conference on Technology Trans-fer for Economic Development, Zagreb, Croatia,June 2000.