scispace - formally typeset
Search or ask a question
Journal ArticleDOI

A client-server architecture for distributed measurement systems

18 May 1998-Vol. 47, Iss: 5, pp 1143-1148
TL;DR: This paper describes a client-server architecture for the remote control of instrumentation over the Internet network that allows multi-user, multi-instruments sessions to be obtained by means of a queueing process and provides instrument locking capability.
Abstract: This paper describes a client-server architecture for the remote control of instrumentation over the Internet network. The proposed solution allows multi-user, multi-instruments sessions to be obtained by means of a queueing process and provides instrument locking capability. Client applications can be easily developed by using conventional high-level programming languages or well-assessed virtual instrumentation frameworks. Performance tests are reported, which show the low overhead due to network operations with respect to the direct control of the instruments.

Summary (2 min read)

A. The VXI-11 Solution

  • Techniques for the remote access to instrumentation have already been proposed in the literature.
  • Software solutions exist that can be used to embed the RPC approach in already developed applications.
  • Furthermore, deadlock can arise, since two users can simultaneously lock two instruments and then they can mutually require the instrument the other user already locked to complete execution.

B. A Multiuser Multi-Instrument Proposal

  • To overcome the limitations of the RPC mechanism, an alternative technique has been developed.
  • Moreover, by employing specific TCP "ports" for the message interchange, the limitations due to firewall hosts can be easily solved.
  • The second quoted drawback of the VXI-11 proposal due to possible multiuser interaction is addressed by establishing and handling a queue of client requests, and by allowing the clients to receive fast responses to requests for information forwarded to the server, such as the queue status or the server actual load.
  • The measurement server (MS) contains the networkrelated procedures on the server side and the queuing management.
  • The choice of splitting both client and server into two layers that are operated by different software modules allows the MC and MS to be developed independently from the user and instrument interfaces.

C. Interconnection Protocol

  • All the messages have to pass through the MC and MS and the headers are used to efficiently identify the modules that have to process the message body.
  • This allows both a simple program development and an efficient use of the network bandwidth.
  • The instrument messages refer to operations that have to be performed on single instruments and are the natural extension of the IEEE-488 messages as in the VXI-11 approach.
  • Each experiment requires a procedure in the IM capable of decoding the message, setting up the instruments, and encoding back the response.
  • This extension, though not as simple and flexible as the simple instrument driver, has been designed to allow both a substantial reduction of the network traffic and efficient instrument use where complex measurement procedures are required.

III. EXPERIMENTAL RESULTS

  • Experiments have been performed both to investigate the degree of difficulty and skill required to port existing applications in the remote environment and to test the environment performance in term of measurement throughput.
  • Programs that were originally developed in VisualBasic or VisualC required only the addition of a very small number of statements necessary for establishing and closing the network connections, together with the substitution of the calls to the interface-related functions to corresponding network functions.
  • The tests were performed with both client and server connected to the same local area network which is used in the facility.
  • The resistance experiment involved only three network transactions to carry out the measurement (data request and result report) plus the lock/unlock procedure, while the oscilloscope experiment was composed of 17 network transactions (including lock/unlock procedures) that are required to set up the instruments and to receive the data from the oscilloscope.
  • The measurement time, therefore, agrees with the sum of the time the multimeter takes to perform the measurement (about 0.5 s) plus the total average network time (five transactions, each of 120 ms), showing that system overhead is limited to about 0.04 s per network transaction.

IV. CONCLUSIONS

  • The remote instrumentation control is becoming popular since the networks have become reliable and worldwide, and almost every new instrument embeds programmable capabilities.
  • This paper presents a proposal that takes the multiuser problems into account.
  • A queue mechanism has been added to the remote environment along with the possibility for each client to query the actual server load.
  • Tests have been performed to estimate this overhead, and it has been found to be reasonably low: about 0.2 s are required for the initial instrument locking and an additional penalty of 0.04 s is experienced for each command with respect to the execution time in nonnetworked environments.
  • A set of precompiled experiments based on the proposed technique for the control of far instrumentation has been made available to the students of "Electronics and Measurement" courses held in Torino and Padova Universities [2] .

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

10 August 2022
POLITECNICO DI TORINO
Repository ISTITUZIONALE
A Client-Server Architecture for Distributed Measurement Systems / Bertocco, M.; Ferraris, Franco; Offelli, C.; Parvis,
Marco. - In: IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT. - ISSN 0018-9456. - STAMPA. -
47:5(1998), pp. 1143-1148. [10.1109/19.746572]
Original
A Client-Server Architecture for Distributed Measurement Systems
Publisher:
Published
DOI:10.1109/19.746572
Terms of use:
openAccess
Publisher copyright
(Article begins on next page)
This article is made available under terms and conditions as specified in the corresponding bibliographic description in
the repository
Availability:
This version is available at: 11583/1400295 since:
IEEE / Institute of Electrical and Electronics Engineers Incorporated:445 Hoes Lane:Piscataway, NJ 08854:

IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 47, NO. 5, OCTOBER 1998 1143
A Client–Server Architecture for
Distributed Measurement Systems
Matteo Bertocco, Franco Ferraris, Carlo Offelli, and Marco Parvis, Member, IEEE
AbstractThis paper describes a client–server architecture for
the remote control of instrumentation over the Internet network.
The proposed solution allows multiuser, multi-instrument ses-
sions by means of a queueing and instrument locking capability.
Client applications can be easily developed by using conventional
high-level programming languages or well-assessed virtual in-
strumentation frameworks. Performance tests are reported; they
show the low overhead due to network operation with respect to
the direct control of instrumentation.
Index TermsClient–server systems, education, intelligent sen-
sors, internetworking, measurement system data handling, re-
mote sensing.
I. INTRODUCTION
T
HE increasing use of programmable instruments has
brought about changes in the operating procedures which
are commonly adopted for the solution of practical mea-
surement problems. Before the availability of programmable
instrumentation, the user was required to set up the test
system by connecting the device under analysis to proper
instruments; then one had to choose the best excitation signals
and configure the instruments by interacting with their front
panels. The results were obtained by reading the data-displays
of the instruments and, sometimes, after some further simple
calculations made by hand. Nowadays, this operating scheme
is outdated and often cannot be applied. Many intelligent
instruments are not provided with a front panel; moreover,
modern tests are performed first by writing a suitable program
for a host computer that controls the instruments, and then
by running that program with the device under test (DUT)
connected to the test station.
In addition, in the last few years a surprisingly rapid growth
of fast and reliable communication networks has allowed
an easy interchange of information and commands between
computers both connected to local networks and connected to
far sites of wide area networks (WAN) such as the Internet.
Thus, network services and programmable instrumentation
now permit the development of measurement laboratories
distributed on a wide geographical area and simultaneously
available to several users variously located in the territory.
Such a kind of distributed measurement laboratory can satisfy
two main requirements.
Manuscript received May 21, 1998; revised November 9, 1998.
M. Bertocco and C. Offelli are with the Department of Electronics and
Computer Science, University of Padova, Padova 33131 Italy.
F. Ferraris and M. Parvis are with the Dipartimento di Elettronica, Politec-
nico di Torino, Torino 10129 Italy.
Publisher Item Identifier S 0018-9456(98)09754-X.
The first one consists of an easy and efficient use of expen-
sive or complex instrumentation systems. Typical examples are
the anechoic chambers used for electromagnetic compatibility
(EMC) experiments or the complex instruments that are used
to test the integrated circuit wafers during the design of new
devices. In these cases, the remote access to measurement sys-
tems allows the interaction between designers or application
engineers and instrumentation without the need to physically
move people or bulk instrumentation, thus increasing the speed
of the development process and also improving the interaction
between many experts in the field. One should also note that
the rental of costly measurement services is possible in a rather
simple way, because only the target device needs to be moved
while a better exploitation of valuable instrumentation can be
achieved.
A second advantage coming from the availability of a
remote instrumentation is the possibility of arranging dis-
tributed measurement systems which are both controlled from
a single position and able to perform complex measure-
ments strictly related to the site where instrumentation is
located. An important example is the control of environ-
mental parameters where scientists or government agents
have the need to perform several measurements in many
locations distributed on the earth. In this last example more
users possibly would like to perform their own measure-
ments by sharing the instruments with the others to gather
different data or compare different post-processing analysis
techniques.
This paper presents a technique for the remote control of
distant instrumentation in a multiple-user, multiple-laboratory
environment. Such a solution has been developed under a
common project that involves the University of Padova and
the Polytechnic of Torino, which are located in the eastern
and western parts of Italy.
The proposed technique is based on a client–server archi-
tecture which is described in Section II. With this technique,
many users can simultaneously share remote instruments by
using suitable client procedures that interact with a server
program running on a computer physically connected to the
instruments. This paper also shows that client programs can be
easily built by using a set of library functions provided with
the developed environment.
Section III reports meaningful examples of end-user appli-
cations. The examples show that measurement problems can
be solved in a remote-controlled environment with a moderate
overhead due to network operation.
0018–9456/98$10.00
1998 IEEE

1144 IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 47, NO. 5, OCTOBER 1998
II. CLIENT-SERVER ARCHITECTURE
A. The VXI-11 Solution
Techniques for the remote access to instrumentation have
already been proposed in the literature. One interesting pro-
posal comes from the VXI Consortium, which has designed
a powerful extension to the IEEE-488 bus [1] referred to as
VXI-11 specification. Such an extension allows remote hosts
and an instrument controller to communicate over a network
to perform measurements as if the instruments were connected
directly to the clients.
The VXI-11 specification relies on the TCP/IP communi-
cation protocol and therefore is suitable for use on both local
area networks and on the Internet, thus allowing addressing
long-distance connections. Moreover, it suggests the use of
a technique referred to as remote procedure call (RPC).
According to this technique, the server computer, which is
connected physically to the instruments, makes available a
set of remotely callable procedures that perform all standard
IEEE-488 activities (addressing, read, write, status polling,
etc.). The client or “remote” computer asks for a procedure
to be executed and receives the results.
Software solutions exist that can be used to embed the RPC
approach in already developed applications. This approach
therefore allows for the distribution of the measurement tasks
among several computers, but it has a major drawback when
employed in a multiuser environment. In fact, the IEEE-488
was designed for a scenario where a single user has complete
control over all the available instrumentation, while a mul-
tiuser approach implies the simultaneous access of different
computer tasks to the same network-shared instruments.
To solve this problem, the VXI-11 specifies a locking
mechanism. Each resource (i.e., each instrument) can be
“locked” by a user so that any other request of access to
the same resource is denied until the locking expires. This
approach actually prevents abnormal operations, but has a
limited flexibility. In fact, a user that cannot gain access to
a measurement subsystem due to a pending lock operation is
not able to gain any information concerning the duration of
the lock or about the number of other clients potentially able
to access the same resource. Furthermore, deadlock can arise,
since two users can simultaneously lock two instruments and
then they can mutually require the instrument the other user
already locked to complete execution.
B. A Multiuser Multi-Instrument Proposal
To overcome the limitations of the RPC mechanism, an
alternative technique has been developed. It consists of a
communication protocol and a set of procedures for the inter-
connection in a wide area network of a measurement system
controlled by a “server” computer, with more concurrently
operating remote “client” computers possibly running different
operating systems.
Since network connections could be established between
different computing environments or operating systems, a
message-based protocol has been adopted, based on the well-
accepted TCP/IP suite. This latter choice overcomes the prob-
lems arising from the physical location of the RPC server.
Moreover, by employing specific TCP “ports” for the message
interchange, the limitations due to firewall hosts can be easily
solved.
The second quoted drawback of the VXI-11 proposal due to
possible multiuser interaction is addressed by establishing and
handling a queue of client requests, and by allowing the clients
to receive fast responses to requests for information forwarded
to the server, such as the queue status or the server actual load.
The block diagram of the proposed solution is shown in
Fig. 1 where one client and one server are reported for the
sake of clarity. Both client and server computers run programs
which are logically split into two layers. One layer in both
client and server sides deals with the network interconnection
while the other layer deals with the instrument management
and user interface.
The client application (CA) contains the procedures that
are related to the user interface as well as to the measure-
ment request and processing. This is the program part
that would be required if the measurement session were
carried out by means of instruments directly controlled
by the client computer.
The measurement client (MC) contains the procedures
that are related to the network management: server contact
and log-in, data flow control, and recovery from network
failures. The communication between the MC and the
CA can be designed according to the different operating
system opportunities.
The measurement server (MS) contains the network-
related procedures on the server side and the queuing
management. It accepts the connection requests from the
clients and processes their messages according to the
kind of request: the messages regarding the queue and
server status are acknowledged immediately, while all the
requests regarding a measurement operation are queued
and dispatched to the instrument manager as soon as
possible.
The instrument manager (IM) contains the procedures
related to the instrument management. It can be designed
to operate by means of IEEE-488 boards as well as with
serial ports and can be used to manage acquisition boards
and other daughter boards, which can be employed by the
remote clients for control and configuration purposes.
The development of the MC and MS modules, which have
to deal with network issues, requires a considerable skill and
the knowledge of several network-related topics. The choice
of splitting both client and server into two layers that are
operated by different software modules allows the MC and MS
to be developed independently from the user and instrument
interfaces.
C. Interconnection Protocol
The interconnection protocol relies on messages composed
of a header and a body. All the messages have to pass through
the MC and MS and the headers are used to efficiently identify
the modules that have to process the message body. The header
need not be encoded and is composed of a sequence of ASCII

BERTOCCO et al.: CLIENT-SERVER ARCHITECTURE FOR DISTRIBUTED MEASUREMENT SYSTEMS 1145
Fig. 1. Block diagram of the client–server architecture for the remote control of instrumentation.
characters, while the message body, which can be composed
of a long stream of data, can be either a binary stream or
a character sequence. This allows both a simple program
development and an efficient use of the network bandwidth.
The messages directed to the IM have been classified into
two categories which have been referred to as “instrument”
and “experiment.” The instrument messages refer to operations
that have to be performed on single instruments and are the
natural extension of the IEEE-488 messages as in the VXI-
11 approach. The experiment messages refer to more complex
environments where a more complex measurement involving
several instruments can be set up with a single encoded
message. Each experiment requires a procedure in the IM
capable of decoding the message, setting up the instruments,
and encoding back the response. The experiment procedures
have to be designed by the end user of the experiment and
need to be installed in the IM by the server manager. This
extension, though not as simple and flexible as the simple
instrument driver, has been designed to allow both a substantial
reduction of the network traffic and efficient instrument use
where complex measurement procedures are required.
III. E
XPERIMENTAL RESULTS
Experiments have been performed both to investigate the
degree of difficulty and skill required to port existing applica-
tions in the remote environment and to test the environment
performance in term of measurement throughput.
The porting has been carried out on programs currently in
use for training and research in the authors’ laboratories [2]. In
all tests the computer that hosted the server was running Win-
dows 95 or Windows NT, while some clients were tested in the
UNIX environment also. The IM was written in VisualBasic,
and both Hewlett-Packard and National Instruments IEEE-
488 boards were used on different computers. The IM was
designed to provide basic
send to instrument and receive
from instrument capabilities and to manage an “experiment”
involving the simultaneous use of different instruments.
In all cases the modifications required to existing programs
were rather small. Programs that were originally developed in
VisualBasic or VisualC required only the addition of a very
small number of statements necessary for establishing and
closing the network connections, together with the substitution
of the calls to the interface-related functions to corresponding
network functions.
Even simpler modifications were required when LabView
programs were considered. In this case, most of network
overhead is handled by some library functions that should be
installed overwriting the vendor-supplied ones. The modifi-
cations which were required to port the existing applications
were then limited to the addition of some new global vari-
ables which are required to handle the necessary network
information.
Specific tests were written to understand the performances
of network-controlled instrumentation systems. The tests were
designed to investigate the overhead due to network con-
nection and the effect of a concurrent access. A LabView
program was written that remotely interacts with a waveform
generator (Hewlett-Packard HP8904A) and a sampling oscil-
loscope (Hewlett-Packard HP54501), the former being directly
connected to an input channel of the latter.
The test consisted of a simple remote measurement session,
which was repeated 500 times. Each session was composed of
four steps: 1) request of the exclusive use of instruments to
the server (lock); 2) setup of the waveform generator and the
oscilloscope to generate a sinewave and to measure its peak-
to-peak value; 3) reading of the measurement results from
the server; and 4) release of the instruments (unlock). Three
time intervals were determined by using the real-time clock of
the local computer during each session: 1) the time required
for obtaining the exclusive use of the instruments (
);
2) the time required to remotely set up the instruments and
obtain the measurement results from server (
); and 3)
the time elapsed from the request of connection to the server
up to the instant in which the connection is eventually closed
(
). The tests were performed with both client and server
connected to the same local area network which is used in
the facility.
The first run was performed by activating one client only;
the time required to obtain an exclusive use of the instruments
from server (
) was rather low, spanning in the range of
0.15–0.35 s. The variability is mainly due to the obvious lack
of synchronization between client and server activities, as well
as to network-dependent parameters such as the data traffic.
The measurement time (
) exhibited a lower variability;
in fact, its standard deviation was approximately equal to 0.06
s, while the mean value was about 1.5 s. One should note that
includes the time required by the instrument to perform
the measurements and some overhead due to the transmission
over the network of the commands and of the measurement
results.
The total connection time (
) is equal to the summation
of
, and of the time required for the client–server

1146 IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 47, NO. 5, OCTOBER 1998
pair to release the exclusive use of instruments granted to
the client as well as to close the connection (
). By
subtracting from
the sum + , it is easy to see
that the average values of
and are about 0.2 s.
A second test was carried out by activating two clients
that simultaneously interacted with the server. As the second
client activated, the
of the first client increased, from the
previous recorded values of 0.2 s, to about 2 s. The increase
of about 1.8 s is approximately equal to
of the other
client. For comparison, the measurement procedure described
above has been performed in a “local” environment, i.e., by
directly using the CA to control the instruments by means
of a computer equipped with a IEEE-488 interface. The time
intervals
which were required for accomplishing single
measurements have a mean value of about 0.8 s, which is
lower than the mean
for a remote client (about 2 s).
The difference is due to the intrinsic overhead imposed by the
remote-controlled environment driven in “instrument” mode.
In this operational mode the client has to await an “operation
completed” message before posting a new command so that
the synchronization between client and server is assured. This
penalty is often negligible when using instruments that take
a long time to complete the measurement procedure, but can
become significant with complex devices requiring a lengthy
setup. In this case the “experiment” approach can be employed
that nearly eliminates the overhead by encoding all the requests
in a single network packet.
Other tests were performed by increasing the number of
clients up to ten. The locking time showed a linear increase
with the number of connected clients. This confirms that
the MS does not add significant delay due to the queue
management.
Another series of tests was performed to investigate the
performance of the system over a wide area network. The
Italian Interuniversity 2 Mb/s network was used for the con-
nection between a client located in the Torino University and a
server located in the Padova University. One should note that
the connection required eight network hops involving different
routers located along the path between the server and the client
computers.
A couple of simple “send-packet” and “echo-packet” pro-
grams were specifically developed to track the actual net-
work speed during the measurement tests The programs were
designed to measure the trip-time of transmission control
protocol (TCP) and user datagram protocol (UDP) network
packets having the same size of those required for the remote
measurements, in such a way that network overload can be
evaluated.
Two measurement experiments were arranged by writing
client programs within the LabView environment. The first
one consisted of a simple measurement of a resistance value
performed with a digital multimeter. The second experiment
consisted of a more complex test where a function generator
and a sampling oscilloscope were controlled to acquire a 1024-
sample waveform. Both tests were performed repeatedly while
collecting the data during an experiment that lasted about 24 h.
The resistance experiment involved only three network
transactions to carry out the measurement (data request and
Fig. 2. Probability density function associated with the measurement time
required for the resistance test and corresponding transmission round trip times
for the case of TCP and UPD protocols.
result report) plus the lock/unlock procedure, while the oscil-
loscope experiment was composed of 17 network transactions
(including lock/unlock procedures) that are required to set up
the instruments and to receive the data from the oscilloscope.
Fig. 2 shows the results for the resistance measurement test
while Fig. 3 refers to the oscilloscope test. In both cases the
three plots summarize the total measurement time (including
the lock and unlock time) and the TCP and UDP trip times. The
average measurement time for the resistance test was about 1.3
s while the mean TCP trip time for packets with dimension
below 200 bytes was about 120 ms. The measurement time,
therefore, agrees with the sum of the time the multimeter takes
to perform the measurement (about 0.5 s) plus the total average
network time (five transactions, each of 120 ms), showing
that system overhead is limited to about 0.04 s per network
transaction.
A similar situation is shown in the oscilloscope experiment
where the average measurement time is about 4.8 s and
the trip time for TCP packets with dimension of up to 3
kB is about 0.23 s. The oscilloscope requires 0.21 s to
perform the measurement with a network time for each of
the 17 transactions of about 0.23 ms. The system overhead is
therefore again limited to 0.04 ms per network transaction.
It is interesting to note that the use of the UDP protocol
could reduce the network overhead of a ratio of about 10%.
In fact, the mean trip time for small packets was about 90
ms instead of 110 ms, and 210 ms instead of 230 ms for
large packets. This overhead reduction, however, is obtained
at the expense of a lower transmission reliability. In fact,
it has been noticed that the TCP protocol timed out during

Citations
More filters
01 Jan 2005
TL;DR: Both the end user’s benefits and the technical implementation challenging issues in enabling cooperative distributed laboratories are discussed and an example of possible network architecture design guidelines able to enable cooperation and remote control of instrumentation is provided.

5 citations


Cites background from "A client-server architecture for di..."

  • ...distributed measuring systems based on sensors and acquisition subsystems or distributed educational workbenches for measure, for which different solutions have been presented [4], [5], [6]....

    [...]

Proceedings ArticleDOI
01 Oct 2017
TL;DR: An extension to IEC 61499 compliance profile is proposed to support real-time data acquisition and both client/server and peer-to-peer model are supported.
Abstract: Industrial Cyber-Physical Systems enhance physical devices with control, computing and communication abilities to provide smart solutions for industrial applications. In industrial applications, data acquisition is an important topic. Based on feedback data from sensors and equipment, industrial processes could be optimized either by experienced engineers manually or smart agents automatically. The IEC 61499 standard is designed for modeling distributed automation systems that perfectly fits the scope of industrial CPS. However, real-time data acquisition is not supported by the IEC 61499 standard currently. In this paper, an extension to IEC 61499 compliance profile is proposed to support real-time data acquisition. Both client/server and peer-to-peer model are supported. The proposed extension is demonstrated using a demo car manufacturing line.

5 citations

Proceedings ArticleDOI
18 May 2004
TL;DR: Some peculiar aspects of the instrumentation and measurement courses are discussed, focusing on the impact of e-learning techniques in laboratory activities, and practical hints coming from the authors' experience in in-the-field trials are reported and discussed.
Abstract: E-learning is the one possible evolution of traditional teaching techniques and is becoming a mature technology. Several commercial suites are available to author multimedia courses either to be distributed in physical form (e.g. on CD or DVD) or to be used on-line. However the application of these suites to the instrumentation and measurement courses and in general to courses that require students to learn the use of real devices is difficult and sometime useless. In this paper, some peculiar aspects of the instrumentation and measurement courses are discussed, focusing on the impact of e-learning techniques in laboratory activities. Practical hints coming from the authors' experience in several years of in-the-field trials are reported and discussed.

5 citations

Patent
28 Sep 2000
TL;DR: In this paper, an apparatus for remotely monitoring and developing steps in a semiconductor manufacturing process that includes, at least one remote workstation connected via remote access link to a local workstation, and a test system connected via a link to the local work station.
Abstract: An apparatus is disclosed for remotely monitoring and developing steps in a semiconductor manufacturing process that includes, at least one remote workstation connected via a remote access link to a local workstation, and a test system connected via a link to the local workstation. A method is also disclosed that includes running a semiconductor test system remotely, monitoring the semiconductor test system remotely, and receiving data from the semiconductor test system remotely. Another embodiment includes an apparatus for remotely monitoring and developing steps in a semiconductor manufacturing process. This embodiment includes a plurality of remote workstations each connected via a remote access link to a local workstation, and a test system connected via a link to a local workstation. Security features in this embodiment prevent any one remote workstation from accessing any other remote workstation.

5 citations

DissertationDOI
15 Jun 2007
TL;DR: The development of a data acquisition system to control experiments in measurement instruments through GPIB interface is presented, representing not only an internet extension for laboratory, but also offer distance education interactive resources to improve user communication.
Abstract: This work presents the development of a data acquisition system to control experiments in measurement instruments through GPIB interface The system created is intended to be applied for educational purposes, thus it was integrated to an online learning environment, enabling remote access to real instruments, to be used in e-learning courses It was used an open source environment with interactive tools and easy management Chose system allows modular e-learning courses creation, which learning components or interactive resources can be selected independently The aim was to create a new module, representing a remote laboratory, to perform data acquisition experiments in instruments It was proposed a modular architecture to remote laboratory based on open source technologies It includes Web Services architecture to integrate data acquisition system and distance education environment This research presents a differential approach for remote instrumentation It represents not only an internet extension for laboratory, but also offer distance education interactive resources to improve user communication

5 citations

References
More filters
Frequently Asked Questions (2)
Q1. What are the contributions in "A client–server architecture for distributed measurement systems" ?

This paper describes a client–server architecture for the remote control of instrumentation over the Internet network. 

A queue mechanism has been added to the remote environment along with the possibility for each client to query the actual server load. The communication between server and clients can be obtained either at instrument level or by means of encoded requests in order to reduce the network-imposed overhead.