Remote Instrumentation Control and Monitoring

Remote Instrumentation Control and Monitoring based on LabVIEW and SMS Rafael C. Figueiredo, Antonio M. O. Ribeiro, Rangel Arthur*, Evandro Conforti School of Electrical and Computer Engineering and Center for High Education on Technology* University of Campinas (UNICAMP) - 13083-970, Campinas, SP, BRAZIL {rafaelf,conforti}@dmo.fee.unicamp.br

Abstract - Remote applications are becoming widely used in various fields such as industry, education, and security. This paper presents a low cost system to monitor and control laboratory instruments remotely by Short Message Service (SMS). The system has been designed using the National Instruments Laboratory Virtual Instrument Engineering Workbench (LabVIEW) development system. The user sends commands using a mobile phone remotely connected to a modem. The software recognizes the received code and transmits the command to the instrument. The system was successfully tested locally and remotely in a signal measurement procedure.

I.

INTRODUCTION

Advances in information and communication technologies have brought changes in several areas. Among them, companies use remote control and off-presence monitoring, and researchers and students make use of distance learning, virtual laboratories, along with other resources. There are various recent application examples, such as a virtual laboratory prototype [1] for Digital Signal Processors (DSP) training, in which the virtual environment is based on LabVIEW and the access is done by the web. In addition, a virtual laboratory permits remote access via TCP/IP, enabling control and supervision through the Internet [2], and a webbased remote control laboratory employs a greenhouse scale model for teaching greenhouse climate control techniques using different hardware and software platforms [3]. Regarding the industrial field, an e-monitoring and emaintenance system have access to report maintenance tasks [4] based on web and Personal Digital Assistant (PDA). Also, a remote fault diagnostic system permits users to check the machine status including data, image and video through the Internet and mobile terminals by Wireless Application Protocol (WAP) [5]. Thanks to technological advances, the systems have their resources and transmission rates increased, consequently increasing its complexity and cost. On the other hand, sometimes we just need to run or monitor simple tasks, which can be performed with less complex and cheaper systems. As it can be seen from the above, powerful programming tools with the Internet allows the management of a industrial equipment or even the remote control of a laboratory instrument with graphical interfaces that are a virtual and

© IEEE 2009

real-time copy of the device [1][5][6], making the necessary broadband connection to specific devices in order to access the network. Simple text command can meet the needs to monitor and control instruments remotely using the Short Message Service (SMS). Despite limitations, such as 160 characters per message without a user-friendly graphical interface, the SMS is widely available over the digital cellular network. It can be used by any 2G phone, is a low cost service, and does not overload the network because it does not consume too many resources. These and other advantages such as using SMS in off-presence monitoring and remote control were implemented in systems which send alerts by SMS when the machine’s status in an industrial environment is abnormal [5] or when an audible alarm of a medical instrument connected to a patient under observation is triggered [7]. Using SMS there is also a system which allows the control of a car alarm remotely [8]. The use of SMS originated this paper which proposes a system to remote monitoring and controlling laboratory instrumentation. Regarding the above applications, the application here has the advantage of neither requiring broadband connection nor sophisticated mobile devices, making possible the creation of low-cost systems for the execution of simple tasks. It also differs from others SMS applications because it is not designed for one sole specific purpose. Indeed, this project is a framework for instrument control using dataflow oriented LabVIEW graphical programming. This software has shown to be an efficient tool in virtual laboratories [1-3]. Further, the graphical language permits the development of programs by inexpert users [6] [9]. Thus the project described here provides the necessary steps to the development of an application with an easy adaptation in accordance to the user’s needs. The developed system was tested in a signal measurement procedure and the results are presented. The remainder of this paper is structured as follows: Section 2 describes the system and its architecture; Section 3 depicts the programming; Section 4 details the graphical interface; Section 5 discusses the tests and results; and Section 6 presents the conclusions and possible future works. II.

SYSTEM ARCHITECTURE AND DESCRIPTION

The system’s main block is responsible for receiving, interpreting and sending text messages, and it is basically

2497

Preprint of IECON 2009 Proceedings

composed by a GSM modem (manufactured with the Motorola G24 module) and a computer with LabVIEW. This block needs to interact with the devices to be controlled/monitored. To evaluate this step, the block was tested with the instrumentation used for a coherence bandwidth measurement in a 1.8-GHz urban mobile radio channel [10]. The relevant feature about the measurement procedure in which the SMS system was implemented is described below and the results obtained from these tests will be described later. In this process a receiver antenna is located on a vehicle in motion which receives signals sent by a transmitter antenna (TA). The TA is connected to the signal generators within the laboratory. Inside the vehicle, the antenna is also connected to an amplifier, two spectrum analyzers, a trigger and a laptop, as shown in Fig. 1(b). The focus of this paper is the block connected at the laboratory, composed by the signal generator, a computer with LabVIEW, and a GSM modem. This setup is illustrated in Fig. 1(a). The data transmission between the computer and modem is performed by a RS-232 serial communication and the communication between computer and instruments in turn, is done by an IEEE 488 – General Purpose Interface Bus (GPIB). The individual who performs the signal measurement connects all the equipments, set the signal generators to work within the laboratory, and then goes to the vehicle, where he works with the laptop and the spectrum analyzers. Sometimes during the process it is necessary to change the parameters of one of the generators. This can be done by using LabVIEW to control the signal generators, and such parameters can be changed with commands sent via GPIB through the computer. In addition, these commands can be triggered remotely by a simple text message, without hard programming, broadband connection nor expensive mobile devices, e.g. a PDA. As a consequence, the person who is doing the measurements in the vehicle can send a text message for the GSM modem, which by serial communication transmits the message to computer, where the message is interpreted and translated in a command, which is finally sent by GPIB to the signal generator. Thus this procedure saves time, since there is no need to return to the laboratory for changing parameters, and there is no need of an additional person in the laboratory. III.

PROGRAMMING FRAMEWORK

In the vehicle, the spectrum analyzers are also controlled using the LabVIEW, which acquires data from instruments and saves them in a file for further studies. The software located in the laboratory for the SMS system is described in this Section. Instead of making a specific program for a particular task, a basic program was developed serving as a framework for several applications. Thus, it is shown how the main basic program was designed, and the adjustments necessary to use it in a specific application such as the measurement procedure cited previously.

© IEEE 2009

Fig. 1. Setup block diagram. Equipment list: (a) Signal Gen. #1 – Agilent E6380, Signal Gen. #2 – Agilent E8257D, Amp – Hughes TWT RF Amplifier 1.4 - 2.4 GHz, (b) Pre-Amp – Agilent 87405B, Spectrum Analyzer #1 and #2 – Agilent E4408B, Trigger – Agilent 34970A, and USB/GPIB interface – Agilent 82357A.

The main structure of the program is done using sequence diagrams. The first step is to identify which port is being used for serial communication, and then the modem is configured starting by its transmission rate, which is set at 9600 bps without parity bit. Later, using AT commands, the functions to receive messages are configured (the AT commands supported by the modem are supplied by the manufacturer). Next, the program verifies the modem signal level by an AT command which gets this level indicated through a numerical response. Then this number is analyzed in a separate program, called Sub Virtual Instrument (SubVI), and displayed in a Graphical User Interface (GUI) in bars form like the one used in mobile phone screens. After these initial procedures, the program enters in its foremost stage where the serial buffer is continually reading and waiting an incoming message. When the program recognizes a message with a valid command, it identifies the command number and enters in the corresponding routine. The message received by the modem is composed by several other characters besides the user informed text, such as date and number of the sender. Thus, in order to recognize a command within the received message it is necessary to create a code table. This table must be composed of codes that cannot be confused with other message characters or difficulty to be typed at the cell keypad. In this work codes formed by the X character followed by a number or a letter were chosen, as it will be seen below in the tables used for the applications (Tables I and II). After the command execution it is possible to send a confirmation message to the

2498

Preprint of IECON 2009 Proceedings

user, indicating that the requested action was executed, and then the program returns to the reading routine, waiting for a new command. The main program hierarchy and your SubVIs are shown in Fig. 2. In this basic program the routines regarding the codes do not perform any operation. In this way, the tasks to be executed are programmed separately and added as SubVIs in the place indicated in Fig. 3, which shows the block diagram of the main program. During the test execution, the codes must adjust certain parameters of the signal generator. Therefore, each SubVI is a program that sends GPIB commands to the instrument, in accordance with each action to be executed. One can argue about the need to make a program for each action, but making a first SubVI to control the instrument, the next SubVIs can be made using that first. Therefore, no more than one GPIB command is changed, which is a relatively simple task. IV.

GRAPHICAL USER INTERFACE

The graphical user interface is mounted on the LabVIEW front panel. The graphical programming allows the creation of detailed interfaces and with high iteration levels. However, in this application it is not necessary to provide many options in the GUI, because the user will use it only to start the

program, subsequently working via SMS. The front panel is shown in Fig. 4. The signal intensity received by the modem is shown in the bars on the right. In the center, there is a switch where the user chooses to receive or not the confirmation messages indicating the requested action execution. By choosing “Yes”, it is necessary to inform the mobile number where the messages should be sent. On the left of Fig. 4, it is shown the command table, from code X1 until X9, but this does not mean that the main program is limited to only nine actions because it is possible to expand it to the desired number of commands with very simple alterations. As stated earlier, the basic program does not perform any operation, and the command table needs to be completed as soon as the SubVIs are added. The characters written in these spaces will be sent in the message returned to user. The remainder options in the front panel are just to monitor some information: the left windows show if there is some error while reading or writing messages; the “info” window shows the text that will be sent in the message, and the green indicators below show the code of the last message received. If the modem receives a message without a valid code the program triggers the “error” indicator and sends a message informing the user, if the confirmation messages are activated. V.

Fig. 2. Programs hierarchy.

TESTS AND RESULTS

The first tests of the main program were conducted with a simplified setup, entirely mounted within the laboratory as shown in Fig. 5, and it was chosen some basic commands to be sent to the signal generator, listed in Table I. The tests were basically done by sending the commands and examining whether the requests were properly executed by observing the parameter’s changes in the instruments. To measure the full response time of an execution, the

Fig. 3. Block diagram of the main program, which initializes the modem (a), verifies its signal level (b) and waits for an incoming message (c) with a code that will determine which Sub VI will be run (d).

© IEEE 2009

2499

Preprint of IECON 2009 Proceedings

TABLE I BASIC COMMANDS

Code X1 X2 X3 X4 X5 X6

Action Set power to -30 dBm Set power to -70 dBm Set power to -100 dBm Set frequency to 1800 MHz Set frequency to 1801 MHz Turn off power out TABLE II APPLICATION COMMANDS

Fig. 4. Control panel of the main program.

Code X0 X1 X2 X3 X4 X5 X6 X7 X8 X9 XX

Fig. 5. Simplified setup in the laboratory.

confirmation messages were chosen to be received. Thus it was possible to analyze how long the system took to receive, interpret and execute the command, and then assemble and send the confirmation message to the user. Throughout a week, each one of the commands in Table I were sent twice a day, the first at 10:00 AM and the second at 6:00 PM, thereby obtaining a total of 14 executions for each command. The execution time was measured from the moment the message with a command was sent until the moment when the confirmation returns. The mean and standard deviation obtained are shown in Fig. 6. As it can be seen, in just over half a minute it is possible to change a parameter of the instrument and receive the confirmation of this change. Part of this time is composed by the delays inserted into programming, in order to give time for the modem to make the assembling and transmission of the message. The rest is the message transmission time, from the sender to the message center, and from the center to the recipient. Making only the monitoring of a device that sends a text message when an event occurs, this message could be previously stored reaching the receiver in about 20 seconds [8], which is a good time to notify any technical or responsible who is away from the referred device. It is also possible to send the notification messages to more than one recipient, warning people in a short space of time [11]. Observing the Fig. 6, it is possible to see that the standard deviation values of the commands are low, which indicates that even on different days and times of network congestion, the message receiving and sending times do not show large variations.

© IEEE 2009

Action Set frequency to 1800.0 MHz Set frequency to 1800.1 MHz Set frequency to 1800.2 MHz Set frequency to 1800.3 MHz Set frequency to 1800.4 MHz Set frequency to 1800.5 MHz Set frequency to 1800.6 MHz Set frequency to 1800.7 MHz Set frequency to 1800.8 MHz Set frequency to 1800.9 MHz Set frequency to 1801.0 MHz

In a second step to test the main program in a practical application, it was added two more codes to the main program (“X0” and “XX”), so that the frequency of the signal generator could be varied from 1800 MHz until 1801 MHz in steps of 100 kHz, as shown in Table II. The tests were performed in the signal measurement procedure mentioned before, with the laboratory and vehicle setups in accordance with Fig. 1(a) and 1(b). The sent code only affects the frequency of the signal generator #1, because the frequency of the signal generator #2 is kept fixed. In this test the confirmation messages were disabled, because it is possible to note if the action was executed through the spectrum analyzer screen in the vehicle. As in the previous tests, all requests were executed correctly in times less than thirty seconds, recalling that in this case there are no times of confirmation messages. It was also performed some additional tests to be known: in the early minutes of the Christmas day it was made three phone calls to a cell phone from a cell in the same region and sent three messages to this same number; all the messages arrived in about 15 seconds, but the phone calls did not achieve one hundred per cent of success because one of them could not be completed due to network congestion. Next week, the same test was conducted in the early minutes of the New Year. Again the three messages arrived quickly, and this time only one of the three phone calls was successfully completed. Thus, these tests demonstrated a satisfactory

2500

Preprint of IECON 2009 Proceedings

ACKNOWLEDGMENT This work was supported in part by the Brazilian agencies CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior), CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico), and FAPESP (Fundação de Amparo a Pesquisa do Estado de São Paulo), under CEPOF and TIDIA-Kyatera Programs, to which the authors wish to thank. REFERENCES [1]

[2] Fig. 6. Execution mean times and standard deviations.

performance of SMS even under an intense traffic on the cellular network. VI.

CONCLUSIONS AND FUTURE WORKS

This contribution presented a system to control and monitor instruments remotely by SMS. The system was applied in a RF signal procedure measurement, and saved time and staff in this process. The project presents as major advantages easy maintenance and adjustment, with coverage all over 2G cellular network without the need to use high cost devices. Therefore, it is a cheap and efficient option in many applications. The tool is LabVIEW-based and uses standard interfaces for communication, so it is not required expert programmers to perform adjustments in the program. As a result it allows a wide range of future work, because it is just necessary to adapt the program in accordance with the requirements of any application where it is desirable to control or monitor instrumentation remotely. One can note that once the software has been created, a free of charge run-time version of it can be generated to be executed at any computer without requiring a LabVIEW license [12]. A suggestion is to use the application of this work as a model, to easily modify the programs in order to control the parameters of another instrument, besides the signal generator. As a industry monitoring example, the program make repeated readings of certain instrument value and enters in a write message routine when such value is reached, warning one or more phone numbers.

© IEEE 2009

[3]

[4]

[5]

[6] [7]

[8] [9]

[10]

[11] [12]

2501

S. Gallardo, F. Barrero, S.L. Toral, M.R. Durán, “eDSPlab: A remoteaccessed instrumentation laboratory for digital signal processors training based on the Internet”, in Proceedings of 2006 IEEE Industrial Electronics 32nd Annual Conference - IECON, pp.4656-4661, 6-10 Nov. 2006. R.U. Garbus, I.J.O. Aguirre, R.C. Sanchez, O.R. Pureco, “Virtual Remote Lab for Control Practices”, in Proceedings of 2006 Electronics, Robotics and Automotive Mechanics Conference, vol.2, pp.361-366, 26-29 Sept. 2006. J.L. Guzmán, M. Berenguel, F. Rodríguez, S. Dormido, “Web-Based Remote Control Laboratory Using a Greenhouse Scale Model”, Computer Applications in Engineering Education - Wiley Periodicals, Inc. vol. 13, no. 2, 2005, pp. 111-124. J. Campos, E. Jantunen, O. Prakash, “Modern maintenance system based on web and mobile technologies”, in Proceedings of 2007 Modeling in Industrial Maintenance and Reliability - MIMAR, pp. 9195, 10-11 Sept. 2007. W. Wang, P.W. Tse, J. Lee, “Remote machine maintenance system through Internet and mobile communication”, The International Journal of Advanced Manufacturing Technology, vol. 31, no. 7-8, 2006, pp. 783-789. T. Fountain, “Software advances in measurement and instrumentation”, in Proceedings of 1993 IEE Colloquium on Software Instrumentation Software Components, pp.4/1 - 4/45, 21 Feb 1993. U.H Siddiqui, “Universal remote alarm system by using virtual instrumentation and LabVIEW graphical programming”, in Proceedings of 2004 IEEE Bioengineering 30th Annual Northeast Conference, pp. 255-256, 17-18 April 2004. R.C. Figueiredo, R. Arthur, L.H. Bonani, F.J. Arnold, “Wireless Control System Based on SMS”, in Proceedings of 2008 IEEE Andean Region IV International Conference - ANDESCON, 15-17 Oct. 2008. I.B. Cioc, I. Lita, M. Teodorescu, D.A. Visan, “Automated system for temperature measurement and regulation using I-7012 module”, in Proceedings of 27th International Spring Seminar on Electronics Technology: Meeting the Challenges of Electronics Technology Progress, vol. 3, pp. 429 - 433, 13-16 May 2004. A.M.O. Ribeiro, C.S. Castelli, E.M.M. Barrientos, E. Conforti, “Coherence bandwidth in a 1.8-GHz urban mobile radio channel”, in Proceedings of 2007 Microwave and Optoelectronics Conference IMOC, pp.599-602, Oct. 29 2007-Nov.1 2007, in IEEE Explore. T.S. Ueng, Z.D. Tsai, J.C. Chang, “SMS alert system at NSRRC”, in Proceedings of 2007 IEEE Particle Accelerator Conference -PAC, pp.401- 403, 25-29 June 2007. National Instruments website, “LabVIEW Run-Time Engine” [Online]. Available: http://joule.ni.com/nidu/cds/view/p/id/1244. [Accessed: July 28, 2009].

Preprint of IECON 2009 Proceedings