Monitoring experiments using mobile devices

Download PDF
2 downloads 423 Views 3MB Size Report
Comment
can monitor instruments and equipment efficiently from ... The mobile monitoring can be useful in some experiments .... Request pending alerts in server.
Monitoring experiments using mobile devices A practice case with Android

Jesús L. Muros-Cobos , Juan A. Holgado-Terriza

Miguel A. Cabrerizo-Vilchez

Software engineering Department University of Granada Granada, Spain [email protected], [email protected]

Applied Physics Department University of Granada Granada, Spain [email protected]

Abstract— Nowadays most of people have smartphones which can run complex application. Some kinds of experiments need several hours to finish. Using recent mobiles capabilities, anyone can monitor instruments and equipment efficiently from anywhere. Hence, alert services can prevent users from any incidence on supervised instruments and experiments. In this paper a new monitoring mechanism is proposed for the supervision of an experiment by improving the reception of messages in any case using mobile devices. Finally, a practice case of the implemented mechanism is presented for Android mobiles. Keywords—Monitoring; mobile devices; Android; embedded devices;

I.

INTRODUCTION & BACKGROUND

Smartphones are used every days by millions people [1]. There is an increasing interest in the research community to explore the capabilities of smartphones for the development of monitoring and tracking systems, i.e., with robots [2], health care [3], transport [4] and sensor network [5] among others. The mobile monitoring can be useful in some experiments where the involved supervision time is very high. Hence, some kinds of experiments need several hours to finish without the interaction of users and sometimes experiments are carried out in special laboratories where researchers have to stay long periods of time in order to check the successful of these experiments [6] [7]. In the latter case, in addition, the researcher usually has to supervise the experiment by inspection on a screen. Inasmuch, it can be a waste of time. Currently, there are enough technologies to improve the monitoring process; for example, researchers can setup an online lab and use remote monitors to check if theirs experiments are working correctly without ocular Inspection. There are two possible alternatives for monitoring an experiment: remote labs and monitors. The remote lab usually uses a web technology to control the lab equipment and provides full control of the lab to users through a remote client [8] [9] [10]. This kind of system is essentially interactive. Then the user has to see constantly the screen in order to supervise the monitoring process, and do actions when an abnormal behavior or a notification is shown. As a result, the power consumption is high. Since notifications are shown directly into the screen, the users must also need to have a full

978-1-4673-4703-7/13/$31.00 ©2013 IEEE

interaction with the measurement system. In this case it is essential to have an internet connection in order to communicate with the lab. Therefore, the development of a remote lab is complex and is a hungry resource consumer, not valid for mobile devices. In contrast the monitor is a lightweight system which connects to instruments to achieve a flow of structured data (e.g. measurements, warnings or errors) produced by the instruments [11] [12]. A monitor can be used to supervise some specific magnitude; i.e., the temperature monitor of a computer can be programmed to power off the computer if the temperature of the processor is greater than a preset temperature value. But, a monitor can also be used to receive data out of range or an error which must be informed immediately to users such as notifications. The main advantage of a monitor is that it can run in background without the necessity to interact with it. His capacity of staying in background is very important in a mobile because the user can use other apps at the same time. Moreover, the mobile can save battery when the user is seeing the monitor because the screen can be turned off. The lack of interaction may be the biggest disadvantage since the user’s actions are very limited. The connection status of a mobile device and the possible connectivity may also be important. In some cases the lack of internet connection has been substituted by the implementation of a short message system (SMS) [13]. In our case the monitor is the preferred choice for several reasons. It is simpler and can run several hours without depleting the battery of the mobile; especially interesting in long time experiments. In order to develop a system for a mobile, we can choose between a web or native app [14]. A web application can be load by a mobile or a computer independently of the operative system (OS) because it runs into a browser. However, web apps cannot access to all available mobile resources such as the sms support or the OS alert system. Furthermore, in a web app the user has to be always connected to internet and he or she has to have the browser running in foreground to detect possible errors in his/her experiments. In fact those limitations are similar to the disadvantages found on a remote lab. Then, a native app is a better solution for the monitor.

When a computer is connected to internet, the system is exposed to several kinds of attacks, including the laboratory equipment. To avoid it, in some laboratories the critical equipment is connected to computers without internet connection. A method to protect a critical instrument maintaining the internet connection is the insertion of a computing device (the monitor system) in the middle between the instrument and internet. This device acts as a mediator, hiding the data flow from instruments and providing at the same time a data source to mobile clients. In this paper a new monitor system running in mobile devices for the supervision of experiments is presented. This monitor runs two operation modes: (a) an active mode allows monitoring an experiment using a smartphone from everywhere through internet; and (b) the passive mode alerts clients asynchronously when it is necessary. The alerts are sent when there is an incidence using different communication links, even if researcher does not have the application in foreground. The monitor is running into an embedded device which is connected to measurement system through Ethernet, USB o RS-232. In addition, the monitor has also support for a GPRS/GSM network if it loses Internet connection. Finally, an Android application (named app) is presented as the client of the monitor. Using Android platform it is possible to build a generic client which uses phone internet connections and intercepts sms transparently, avoiding researcher to be aware of sms interface. II.

MONITOR SYSTEM

Fig. 2. Software components on the proposed monitor system

Although a standard protocol such as IEEE-488.2, (Standard Commands for Programmable Instrumentation) [15] or XML might have been used for the communication protocol; a specific protocol has been implemented in our case. This allows disposing a simpler and lighter protocol that can be managed even with GSM network.

A. System Architecture The architecture of the proposed system is shown in Fig. 1 and Fig 2. It is composed of three elements: the Instrument, the Instrument Monitoring System (IMS) and mobile clients. The Instrument includes an Instrument Adapter as a software component which is responsible to connect the control software of the instrument with IMS. The IMS is an independent system which decouples the instruments from mobiles, hiding instruments from internet access and exposing measurements to mobile devices through different communication protocols.

The data protocol is composed of a set of messages which states the communication between the measurement system and IMS as well as the communication between the IMS and mobile clients. Each message is a string which contains a command followed by a set of data as it is shown in Fig. 3. In order to split data the symbol # will be used to separate different values, and the command is added to specify the end of a message; for example, the message, Data#1#5.4#TRUE, specifies the transmission of the set of data, 1, 5.4 and TRUE, to receiver.

B. Data Protocol. The communication between instruments and IMS can be established using several communication protocols such as USB, serial or Ethernet using a Message-based data exchange protocol. The data protocol defines an API independent of the communication protocol by using a data stream mechanism.

C. Measurement system-IMS communication. Table I provides the API for the measurement system-IMS communication. It consists of a few message-based calls to send/receive data, send alert, send pattern, and get measurement application status. These messages are sent and received through USB, serial or Ethernet. The reusability is a strong feature desirable for any system. In order to improve that property in this monitor system, the measurement application sends definable patterns of data first to IMS, and then from IMS to mobile clients by means the command pattern+string. This allows knowing the dataset of any measurement obtained by the instrument through command data, the format of any data that represents that measurement and how it has be shown to the user. A pattern

Command # Data1 …. # DataN Fig. 1. System Architecture

Fig.3. Data protocol format for a message from/to monitor.

TABLE I.

MEASUREMENT SYSTEM-IMS API

IMS Requests to Measurement system

Description

getData

Request measurements if available.

getStatus

Request the status of the measurement system.

getExperimentsNames startExperiment String

+

stopExperiment Responses from Measurement system

pattern + String data + String… status + String

TABLE III.

Stop an experiment in progress. description

Client identifies user and password

getStatus

Return status of the measurement application (0: no experiment in progress, 1: experiment in progress)

getExperimentsNames

Get names of all experiments

startExperiment String

Start an experiment specifying its name Stop an experiment in progress

getPendingAlert

Request pending alerts in server

phoneNumber

Set the phone number of the client

getData

Request measurements if available.

Send the pattern of the measurements. Send the dataset of a measurement described in pattern. 0: no experiment in progress, 1: experiment in progress.

Responses from IMS

Send all possible experiments.

pattern + String

alert + String[2]

Send an alert composed of a pair string, title and description.

data + String…

delimits each data in base of a tag (representing a magnitude) with the format key:value# and a value (representing the data type, int, float, double) with the format key:typeValue#. An example, indexTag : Time # indexValue : float # mainTag : Tension Superficial # mainValue : float # tag : Area # value : float… is the pattern used in Table 4. Therefore, a generic Android application adaptable to any instrument can be developed. D. IMS-mobile client communication In order to communicate mobile clients with IMS, internet or the sms interface can be used depending on the mobile and it compatibility with the client app. Users will be able to receive alerts and start or stop an experiment with both API defined in Table 2 and Table 3. Since IMS is exposing to internet and sms, a login subsystem is developed to secure the access to the instruments. This subsystem checks the user and his/her password. If connection can connect to internet subsystem, it will check the opened socket and the login before opening the access. When the user uses the sms interface, the access requires an additional messages exchange. First the user has to send a sms

Sms sent by client

SERVER-CLIENT API SMS INTERFACE

Description

getCode+String[2]

Return a ramdon code.

getExperimentsNames +String[2] startExperiment + String[3] stopExperiment +String[2]

Get the names of all experiments by indicating the user and code. Start the experiment with the specified name, user and code. Stop experiment in progress specifying user and code.

Sms sent by server

alert+String[2]

+

stopExperiment

experimentsNames+ String …

TABLE II.

Description

login + String[]

Get names of all experiments. Start an experiment passing its name.

IMS-MOBILE CLIENT API

Mobile client requests to IMS

Description

Send an alert with the name and the description.

alert + String[2] status+ String

Description

Send the pattern of the measurements. Send the dataset of a measurement described in pattern. Send an alert composed of a pair string, title and description. 0: no experiment in progress, 1: experiment in progress

with his or her user and password. Then he will receive a response with a random code. Thereafter the researcher will use his user and the code at the beginning of the sms to control the system. The code can only be used along for 30 minutes. The reason is that is more difficult for an attack to intercept the password or at least it only will be valid during 30 minutes as maximum. E. Connections In order to maximize the robustness, IMS admits several internet connections to mobile clients in the following order, WI-FI, 3G, and SMS. If one of them falls, it can detect and use another. Depending on the situation that a mobile client can be behind a router or a proxy, then IMS will not be able to establish a connection with clients. Thus, all internet connections will be started by the client and validated by the IMS using a login. The phone number of client is used in two situations: (a) when the mobile client has used sms interface to login in the system, then the number will be sent in the login sms; and (b) when the client has used internet connection and client has sent the command phoneNumber. F. Notification subsystem The main objective of this subsystem is to alert users when there is an incidence. Using a notification system a researcher must not be taking care to experiment constantly, since the system automatically will send a notification to user’s phone when an incidence is fired. The notification is managed by IMS when the measurement system executes the command alert using all available channels in order to send the alert to mobile clients.

TABLE IV.

2.

When the mobile client does login the first time in the application, it has to send the command phoneNumber to IMS, since IMS must know the phone number of the client.

3.

When application is in background, it should poll the IMS for checking new alerts.

TOKEN KEYS

Token keys

Description

indexTag

The tag associated to index value.

indexValue

Represent the value wich can be used by client to index data.

mainTag

The tag associated to main value.

mainValue

Primary value for a measure.

tag

Tag associated to a value.

anvalue

Other values for a measure.

The first obstacle when a system deals with notifications using internet is that mobile might not have Wi-Fi or data connection due to a lack of mobile coverage. In this case mobile clients cannot receive any data. In order to avoid this obstacle the IMS can work with sms, since in most of countries coverage for sms is better than coverage for data connection. This mechanism can also be useful when the coverage is unstable due to the mobile client might not check when the mobile client has coverage. In order to take advantage, our system can use both communications. The messages exchange with sms may be more expensive than internet, since IMS can be connected to internet through the research center infrastructure. In order to save costs [16] (supposing that laboratory has an internet connection), the IMS tries to reduce the number of sms sent according to Algorithm1 detailed in Fig. 4. G. Mobile Client There are two possibilities to use a mobile client depending of the kind of mobile device. If the mobile device is not a smartphone one, the researcher can use the sms support in order to connect to IMS and inspect sms messages. But if the mobile device is a smartphone, he or she will be able to load the full native application to take more advantage. It can query for new measurements to IMS while it is checking for new alerts at the same time. Moreover, if measurements are stored in the mobile device, we can develop a full data-logger. In addition we can improve the user experience by selecting different arranging schemes or graphic views.

Fig. 5. shows the sequence diagram of the messages exchange which takes place in the system. III.

PRACTICE CASE

In order to verify the validity of the proposal, a practice case of the system has been developed using a Pendant Drop Surface Film Balance equipped with a subphase multiexchange device [17] Fig. 6. This instrument is fully computer controlled by control software DINATEN©, which allows the planning, control and monitoring of interfacial experiments for the study of the surfactant and protein adsorption, insoluble monolayer or digestion process, among others [18]. In order to adapt the control software Dinaten to this system, an instrument adapter plugin was implemented in C++. Once the experiment is running, Dinaten can take several measurements such as the drop area, the drop volume, the interfacial tension, the pressure area, and so on. The instrument adapter is responsible to convey data flow to IMS, specifying first the data pattern according to the API presented in above section. Also it can receive commands from IMS to start a new Algorithm 1 Notification system 1.

2.

3. 4. 5.

6.

Check if a. b. Check if a.

a registered client has internet If not, go to 5. Else go to 2. client is connected. If so, IMS sends an alert using the opened socket and it will finish the operation. IMS puts the alert in a queue in the server with a timeout. If client checks the queue and gets the alert, the operation will be finished. If timeout finishes and the alert has not been got or client does not have internet, IMS will send a sms. The alert will continue in the queue until the client receives a response.

When a mobile client is being developed, it is necessary to take account some restrictions, since the mobile device has limited resources. In order to save battery is good to limit the CPU consuming, reducing the time that the mobile is connected to the network, especially when the application is in background. Thus, a timer can wake up the application regularly for checking alerts and then returning to a disconnected state. Although an Android application is presented in next section, a mobile application can be ported to other OSes, while the API shown in Table II is preserved. Only three rules should be fulfilled: 1.

After creating a new connection, the mobile client has to send a login command to IMS, since IMS only accepts commands from validates clients. Fig.4. Flow diagram for notification system.

IMS must wait until a message from mobile clients is received, checks the communication links and verifies the identity of the sender when the mobile client does a login. The alerts are managed by the algorithm explained in section II.F. In order to check if the mobile client is connected, IMS saves a pointer of the client socket. If socket is 0, the alert will be queued until the client is reconnected or a timeout is fired. The first IMS prototype allows access to measurement system for only one user at the same time. That user will be the first client connected to IMS when an experiment is in progress or will be the user who starts the experiment until the experiment is finished. Next version will support multiple clients. The mobile application is implemented in Android and is tested in a HTC One X with Android 4.1.1. Android is selected, since currently it is the mobile OS more widely extended. The application is relatively very easy to program, since the programming language is Java. Finally, it is cheaper to publish and maintain an application in Google Play.

Fig. 5. Secuence diagram of the system

experiment or stop an experiment in progress. The IMS is also implemented in C++ on top of a Debianbased Linux OS in an embedded device Beagleboard xM Rev C [19], since it has support for USB Wi-Fi based on the Railink e73 chip and the USB GSM modem Huawei e1752. It implements the API shown in Table 1, Table 2 and Table 3. IMS is connected to instruments using Ethernet over USB, leaving free the other Ethernet port of the board in order to provide access to an internet connection through a LAN. On the other hand, GSM modem and Wi-Fi adapter are connected to the device using two USB ports of the board. Thus, if LAN fails, IMS tries to connect to WLAN; if it fails too, then system will connect into phone carrier. In the case that 3G connection fails too, the support of sms is used. In order to send and receive sms, IMS uses gammu [20], a program which provide the sms support. In order to improve security all connections will be carried out using secure sockets layer (SSL) when it is possible.

Fig. 6. Dinaten, software and measurement system.

The mobile app is implemented by an Activity class which loads the appropriate UI layout depending of the screen capabilities of the device Fig 7. Android shows data in an ExpandableListView. This object draws in the screen a list with primary items, which can be expanded to show another list with secondary items when the user clicks over them. The index value and the main value represented in the pattern with IndexValue and MainValue respectively are represented in primary items. If user clicks on a primary item where a value is represented, the list will be expanded to show secondary values for the same measure. Therefore, the mobile client is generic and can show any data of any experiments using the pattern defined by the measurement adapter. In order to save battery, the application only checks data when it is in foreground. When the app is in background or mobile screen is turned off, an android Service is running in background for checking regularly if there are alerts within a period of time defined by user; i.e., five minutes by default. When an alert is found, Android notification manager puts a notification in the Android status bar, as it is shown in Fig 6. When there is not data connection or Wi-Fi, the mobile

Fig. 7. Client screenshot and alert notification.

client and IMS exchanges automatically SMS messages. When an alert is sent by IMS phone number, the mobile client intercepts SMS messages and shows a notification in status bar. If client clicks the notification, the application will be opened and will show the problem. IV.

CONCLUSSION AND FUTURE WORKS

Monitoring and controlling scientific experiments anywhere and anytime can be useful in experiments that run through a long period of time. Mobile devices can be used to achieve that requirement, but in contrast we keep in mind that they have limited processing and memory resources and an urgent requirement to save power consumption. We have proposed a new lightweight mechanism composed of two main parts: an IMS in order to manage securely the provision of data from instruments to mobile devices independently of the connection status of the mobile device through Wi-Fi, 3G or SMS management, and a notification facility in order to keep users informed even when the mobile is in standby status. In similar proposals [11] [12] the mobile client must have internet and the mobile application only works in foreground. In addition they do not have redundancy methods to communicate with clients. However, our proposal includes a mechanism with redundancies in order to increment the possibilities of receiving data and alerts when IMS lose the connection with internet, the mobile device does not have temporary internet connection, the application is turned off, or is in background. The proposed system is robust, secure and reusable. Instead of developing a monitor for each application, in our system it is only necessary to develop an adapter for measurement application because IMS and app are generic. In future versions of the presented system the communication protocol will be improved in order to include metadata information. If alerts have metadata, the android application will be able to suggest actions to researcher. Also, the android application could make predefined actions, such as restart/stop experiments or change some conditions of the experiment and restart it. Moreover, using metadata the system will be able to create warnings. These warnings will allow researchers to avoid critical events which could make fail an experiment, improving consequently their experimentation work.

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15] [16]

REFERENCES [1]

[2]

[3]

[4]

[Online]. Available: http://www.marketingcharts.com/wp/interactive/smartphone-penetration-crosses-majority-threshold-of-mobile-market24540/ S.-W. Moon, Y.-J. Kim, H. J. Myeong, C. S. Kim, N. J. Cha, and D. H. Kim, “Implementation of smartphone environment remote control and monitoring system for android operating system-based robot platform,” in Ubiquitous Robots and Ambient Intelligence (URAI), 2011 8th International Conference on, 2011, pp. 211–214. P. Zhang, Y. Kogure, H. Matsuoka, M. Akutagawa, Y. Kinouchi, and Q. Zhang, “A remote patient monitoring system using a java-enabled 3g mobile phone,” in Engineering in Medicine and Biology Society, 2007. EMBS 2007. 29th Annual International Conference of the IEEE, 2007, pp. 3713–3716. X. Feng, J. Qian, Z. Sun, and X. Wang, “Wireless mobile monitoring system for tram rail transport in underground coal mine based on wmn,”

[17]

[18]

[19] [20]

in Computational Aspects of Social Networks (CASoN), 2010 International Conference on, 2010, pp. 452–455. C. So-In, N. Weeramongkonlert, C. Phaudphut, B. Waikham, C. Khunboa, and C. Jaikaeo, “Android os mobile monitoring systems using an efficient transmission technique over tmote sky wsns,” in Communication Systems, Networks Digital Signal Processing (CSNDSP), 2012 8th International Symposium on, 2012, pp. 1–6. J. Maldonado-Valderrama, J. A. H. Terriza, A. Torcello-Gomez, and M. A. Cabrerizo-Vilchez, “In vitro digestion of interfacial protein structures,” Soft Matter, vol. 9, pp. 1043–1053, 2013. [Online]. Available: http://dx.doi.org/10.1039/C2SM26843D A. Torcello-Gomez, J. Maldonado-Valderrama, A. B. Jodar-Reyes, and T. J. Foster, “Interactions between pluronics (f127 and f68) and bile salts (natdc) in the aqueous phase and the interface of oil-in-water emulsions,” Langmuir, vol. 29, no. 8, pp. 2520–2529, 2013. [Online]. Available: http://pubs.acs.org/doi/abs/10.1021/la3044335 D. Weisman, “EnglishIncorporating a collaborative web-based virtual laboratory in an undergraduate bioinformatics course,” EnglishBiochemistry and Molecular Biology Education, vol. 38, no. 1, pp. 4–9, 2010, cited By (since 1996) 2. [Online]. Available: http://www.scopus.com/inward/record.url?eid=2-s2.076349084300&partnerID=40&md5=cbbc2f1be2e4db9d1c33ab1b60cdb 598 V. Harward, J. del Alamo, S. Lerman, P. Bailey, J. Carpenter, K. DeLong, C. Felknor, J. Hardison, B. Harrison, I. Jabbour, P. Long, T. Mao, L. Naamani, J. Northridge, M. Schulz, D. Talavera, C. Varadharajan, S. Wang, K. Yehia, R. Zbib, and D. Zych, “The ilab shared architecture: A web services infrastructure to build communities of internet accessible laboratories,” Proceedings of the IEEE, vol. 96, no. 6, pp. 931 –950, june 2008. J. L. Muros-Cobos and J. A. Holgado-Terriza, “A componentizable server-side framework for building remote and virtual laboratories,” iJOE, vol. 8, no. S4, pp. 43–51, 2012. W. Ai and C. Chen, “Green house environment monitor technology implementation based on android mobile platform,” in Artificial Intelligence, Management Science and Electronic Commerce (AIMSEC), 2011 2nd International Conference on, 2011, pp. 5584–5587. N.-V. Truong and D.-L. Vu, “Remote monitoring and control of industrial process via wireless network and android platform,” in Control, Automation and Information Sciences (ICCAIS), 2012 International Conference on, 2012, pp. 340–343. P. Kittisut and N. Pornsuwancharoen, “Design of information environment chicken farm for management which based upon gprs technology,” Procedia Engineering, vol. 32, no. 0, pp. 342 – 347, 2012, ISEEC. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1877705812013264 A. Charland and B. LeRoux, “Mobile application development: Web vs. native,” Queue, vol. 9, no. 4, pp. 20:20–20:28, Apr. 2011. [Online]. Available: http://doi.acm.org/10.1145/1966989.1968203 [Online]. Available: http://www.ivifoundation.org/scpi/ M. Paschou, E. Sakkopoulos, E. Sourla, and A. Tsakalidis, “Health internet of things: Metrics and methods for efficient data transfer,” Simulation Modelling Practice and Theory, no. 0, pp. –, 2012. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1569190X12001232 H. Wege, J. Holgado-Terriza, A. Neumann, and M. Cabrerizo-Vilchez, “Axisymmetric drop shape analysis as penetration film balance applied at liquid-liquid interfaces,” Colloids and Surfaces A: Physicochemical and Engineering Aspects, vol. 156, no. 1-3, pp. 509 – 517, 1999. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0927775799001089 A. Torcello-Gomez, J. Maldonado-Valderrama, A. Jodar-Reyes, M. Cabrerizo-Vilchez, and A. Martin-Rodriguez, “Pluronic-covered oilwater interfaces under simulated duodenal conditions,” Food Hydrocolloids, no. 0, pp. –, 2013. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0268005X12003281 [Online]. Available: http://beagleboard.org/hardware-xM [Online]. Available: http://wammu.eu/