A client-server architecture for distributed measurement systems
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
Citations
1 citations
1 citations
1 citations
Cites methods from "A client-server architecture for di..."
...This requires also remote testing features to be included in practical solutions (e.g. Bertocco et al., 1998; Van Houcke and Sparks, 2006; Armengaud et al., 2008; Ilarri et al., 2009)....
[...]
1 citations
Cites background from "A client-server architecture for di..."
...Using Ethernet-based networks in control and monitoring systems is very attractive when it is required to collect data from multiple distant measurement points [6] ....
[...]
1 citations
Cites methods from "A client-server architecture for di..."
...Until now, the research on DMS were devoted to solve the problem of: throughput [9], [10], security [11], improvement of transmission medium used for the connection between MIs and DMS nodes [12], [13], computational burden of the measurement software on the DMS node, synchronization among measurements both in wired, [14]-[17], and wireless environment [18]....
[...]
References
Related Papers (5)
Frequently Asked Questions (2)
Q2. What are the future works mentioned in the paper "A client–server architecture for distributed measurement systems" ?
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.