Personalized Mobile Applications for Remote Monitoring Miguel A. Laguna, Javier Finat, and Yania Crespo
Abstract—The development of mobile applications is a challenging activity. The main problems are the limits of the mobile devices (in memory size, processing power, battery duration, etc.) and the diversity of target platforms, display sizes, or input modes (keypads or tactile screens). For these reasons, the software product line (SPL) development paradigm can improve the process of designing and implementing mobile systems. Our approach to SPL development uses the package merge relationship of the standard UML to represent the variability in all the SPL design and implementation models. The combination of this technique and conventional CASE and IDE tools (Eclipse or MS Visual Studio) makes the developments of SPLs for mobile applications easier as it removes the need for specialized tools and personnel. This article presents a SPL that makes possible the remote monitoring of dependent people to facilitate their autonomy. The SPL generic architecture uses Bluetooth wireless sensors connected to mobile devices. These devices are remotely connected to a central system, which could be used in hospitals or aged person’s residences. Moderate cost sensors allow health parameters such as heart rate or oxygen saturation level to be controlled. Risk situations can also be detected using a range of predefined values or specific sensors. The diversity of individual situations and the resource limitations favor the use of the SPL paradigm, as only the required features are incorporated in each concrete product. Index Terms— software product line, mobile application, wireless sensor, monitoring system, fall detection.
I. INTRODUCTION
T
HE raising of life expectancy and the increase in the number of dependent persons in developed countries introduce new challenges for improving their quality of life (in a broad sense, we include here supervised patients, elderly, or handicapped people). Quality of life is associated with autonomy and mobility. The mobility of dependent people can come into conflict with frequent monitoring of health parameters under medical supervision or with risk detection. The increased costs of care and the geographic dispersion favor the deployment of personalized health services based on low cost ubiquitous systems, accessible to more people while reducing the medical costs. Consequently, one of the most interesting applications of mobile devices is the development M. A. Laguna and Y. Crespo Authors are with the GIRO research group, University of Valladolid, Campus M. Delibes, 47011Valladolid, Spain, {mlaguna, yania}@infor.uva.es. J. Finat Author is with the MoBiVAP group, University of Valladolid, Campus M. Delibes, 47011 Valladolid, Spain,
[email protected].
of systems to increase the personal autonomy. These technologies have generated huge expectations but we should ensure that their costs are reasonable. Different inexpensive sensors can provide data about heart rate, oxygen saturation, temperature, etc. In addition to supervised patients, other people with varying degrees of dependence can improve their level of autonomy: persons with different physical disabilities, the elderly who live alone (and have a risk of fall that can be detected using a suitable sensor), etc. The Global Positioning System (GPS) is another inexpensive data source, directly accessible from conventional mobile devices that can be combined with health parameters, completing the information about people location required in the detection of risk situations. However, the big problem is that the personalization of an application to each person requirements and sensor or device characteristics can be unaffordable in terms of costs and development time. To make things worse, multiple platforms for mobile devices are appearing and evolving continuously (and several display sizes, color depth and variations in keypads or tactile screens can share the same platform). For these reasons we are working in a set of projects aimed to apply the product line paradigm of software development to the specific case of customizable mobile systems. Software product lines (SPL) are based on the idea of separating the common and variable parts of the product line as reusable coarse-grained components [4]. This approach is demanding and requires a great effort by the companies that take it on. We aim to simplify the change from a conventional development process towards the product line paradigm. To achieve this, we use standard UML elements to represent the SPL architecture variations with conventional CASE and IDE tools [9]. We have used that approach to build an e-Commerce SPL and with several mobile systems. This paper reports the practical experience in the development of a product line for remote monitoring systems, using a combination of sensors, (multiplatform) mobile devices and a server that can be consulted in real time from anywhere by medical personnel using a standard Internet browser. The rest of the article is organized as follows: Section 2 briefly presents the techniques and tools used for the SPL design and implementations. Section 3 is devoted to the description of the product line. In Section 4 the related work is analyzed and, finally, Section 5 concludes the paper.
II. SOFTWARE PRODUCT LINES: TECHNIQUES AND TOOLS Feature diagrams represent the variability and commonality of software product lines and permit the configuration of each specific application to be selected. Feature diagrams are the more specific SPL techniques, aimed to handle variability and traceability at each abstraction level of the product line. The product line development requires these diagrams to represent the SPL variability and as a mechanism to obtain the configuration of features that represent the selected combination of variants for each specific application. However, the optional features must be connected with the related variation points of the architectural models that implement the SPL. This link allows the automatic instantiation of the SPL generic architecture into each specific application. This is derived from the complete architecture selecting or not each optional feature. The selected feature sub-model, through traceability relationships, guides the composition of the pre-existing code packages. The precondition for the success of this process is the existence of traceability links from features to design and from design to implementation. Our solution to this problem [9] consist of expressing the SPL variability of UML models using the package merge relationship, defined in the UML infrastructure meta-model. This mechanism permits a clear traceability between feature and UML models to be established. The technique consists of associating a package to each optional feature, so that all the necessary elements that model the feature remain located in a package (maintaining the UML meta-model unchanged). The resulting package model is hierarchical, reflecting the feature diagram structure. Considering each pair of related packages, the dependent package can only be included if the base package is also selected. Therefore, the application to SPL consists of building the architectural model (including structural –class diagrams-, behavioral -use cases-, and dynamic –interaction diagrammodels) starting from a base package that gathers the common SPL aspects. Then, each variability point detected in the feature diagram originates a package, connected through a merge relationship with its parent package. When each product is derived, these packages will be combined or not, according to the selected feature configuration. In our first implementations we promoted the use of the C# language. Using C# partial classes organized in packages, a direct correspondence between design and code can be established. Therefore a one-to-one connection from features to design and from design to implementation is recorded. As an added value, the package structure of the code for each final product of the SPL can be obtained (and passed to the compiler) from the features configuration [10]. However, work done in Java adaptation and available tools [7] allows the SPL implementation with this language. Consequently we can use conventional CASE and IDE tools, a constraint imposed by our vision of the SPL paradigm. In particular, we have used .NET/Visual Studio and Java/Eclipse for the development of the monitoring SPL. In both platforms, only a specific plug-in is required to handle
the feature models and the configuration process, distinctive of the SPL approach. To achieve this, making the technique readily accessible to developers, we have designed and implemented FMT (Feature Modeling Tool), a plug-in that integrates with MS Visual Studio and able of managing the feature models characteristic of SPL paradigm, and generating the package structure of the product line. The tool is available from the GIRO web site. Once a configuration is selected and validated, the compiler reads the project configuration files and generates the final specific product that can be deployed and installed in minutes in the mobile device. Similar in its goal to the FMT tool, the FeatureIDE plug-in (Figure 1) for Eclipse [7] allows using Java classes in a similar way to the native C# partial classes. This is a good alternative for mobile devices that use Java as their preferred language (Symbian and Android platforms). In the case of the remote monitoring SPL, we have designed a platform independent architecture and subsequently, using the two alternative development tools, two platform-specific SPL designs. Additionally, the Java version has required two different implementations, due to the characteristics of the Android platform that do not use the standard Java ME facilities, in particular the standard user interface libraries.
Fig. 1. FeatureIDE, used for the definition of the feature diagram and the configuration of the remote monitoring product line (Java version).
III. MULTIPLATFORM REMOTE MONITORING PRODUCT LINE Remote monitoring can increase the autonomy of dependent people while reducing the costs of care (they could continue in many cases with their lives at home instead of being permanently hospitalized). The main goal of our product line is the personalized monitoring of health parameters and the detection of risk situations for dependents. The SPL must provide a complete range of solutions, allowing the selection of the most appropriate for each particular situation. The product line has been developed for different platforms. The first prototypes were developed in C# for Windows Mobile devices. Later, Java systems for the Android and Symbian platforms have been implemented. Figure 1 shows a general view of the tool used for the development of the Java SPL and Figures 2 and 3 describe some of the most representative aspects of the SPL variations. The next Subsections present the SPL analysis (using the feature modeling technique) and an overview of the SPL design and implementation. A. Product Line Analysis Using a feature diagram, we have analyzed the technical possibilities, as well as the desirable health parameters as recommended by medical experts. Figure 2 and 3 present details of the feature diagram of a generic health/risks monitoring SPL. The global feature diagram reflects that a health monitor requires at least one sensor and several auxiliary subsystems: positioning (optional), configuration and communication systems. Naturally, we could design a fully equipped solution for all situations but this is not a good choice if we consider the limits of mobile devices where these systems must be deployed. The main group of features is the set of continuous or discrete monitoring capabilities that can be included in the system. As the goal is the passive monitoring with a minimal intervention of health professionals, we need non-invasive sensors to get biological values of the patients. The information will be captured in a continuous way for treatment control and online detection of unusual situations, potentially dangerous. The number of possibilities is considerable and each parameter requires an exhaustive study of available wired and wireless sensors, the range of parameter values, etc. This is the part of the product line development where the collaboration of experts (health professionals in this case) is critical. As an example of implemented packages, some parameters, such as heart rate or oxygen saturation, appear in Figure 2. Although a sensor can send the information through a wired or wireless connection to a mobile device, we advocate for wireless sensors when possible as they are less intrusive, but wired sensors cannot be discarded. Nowadays, there is a great variety of commercial non-intrusive sensors, some of which include a wireless connection. Wireless technology is becoming cheaper, and more important, smaller and with less electrical consumption. Bluetooth is the best choice for our needs, as most mobile devices incorporate this protocol. The detection of risk situations is the other vital feature of the product line. Instantaneous risk detection can be performed
by means of a set of rules that compare the captured values by the different continuous sensors with reference values. The weighted sum of several innocuous parameters can indicate a dangerous situation for certain persons. It is then possible to detect a risk situation and report it to the assistance services at once, indicating the type of risk (and the location of the patient if a positioning sub-system is incorporated in the application). Apart from this risk detection based in continuous monitoring, other eventual situations can be considered. The possibility of raising an alarm signal (Panic Button) should be included in most systems. On the other hand, in aged people, accidental falls represent a frequent risk that can be detected with an accelerometer based sensor and an adequate algorithm. An experimental prototype was developed with a set of requirements, validated by the medical staff of a senior citizens’ residence that collaborates with us. This experimental system used a well known gamepad as accelerometer connected via Bluetooth with a workstation. The .NET platform and C # were used to develop the system, due to the ease of integration with the available platform libraries. This experimental version was intended for home scenarios (or a small residence), since the limits are defined by the Bluetooth connection range (a maximum theoretical distance of 100 meters, much less in practical situations). The results were satisfactory both in fall detection and false positive rejection [11]. This experience has been very useful for the integration of a smaller sized sensor in the monitoring SPL (the Fall Sensor of the Figure 2 diagram). Health Monitor
1..2
Continuous Sensor
1..*
Alarm Sensor
1..* Heart Rate
Temperature
Oxygen Sat Panic Button
Fall Sensor
Fig. 2. Partial feature diagram of a remote health monitoring system (continuous and discrete sensors features).
As expressed in Figure 3, the patient’s position can be controlled, using a GPS positioning system (when people can walk outdoors and medical staff needs to know the position) or an indoor alternative (if the patient has limited his/her mobility to the interior of a building). Then, we can use commercial GPS, Cellular towers/Wi-Fi triangulation algorithms, or simply an RFID based displacement control. Moreover, the system can combine two or more positioning systems to get total flexibility, as the lost of GPS signals can
force the alternative method to be used. This possibility is stated with the multiplicity of the positioning feature group of the Figure 3 ([1..*], at least one, but any combination is legal). Mobile and central system intercommunication can be based on Internet (Wi-Fi, or indirectly over 3G/3.5G) or on the plethora of protocols for mobile phones (CDMA, GSM, TDMA, etc.). It will be necessary to choose between advantages linked to mobility, bandwidth, costs, availability, etc. The connection with a central system can be achieved in two ways: a direct Internet Wi-Fi connection (using wireless networks when available, typically in the interior of a residence or hospital) or an alternative connection using Internet over the 3G/3.5G mobile phone technology (as a last resource, SMS can be used too). As the color code of the Figure 3 allows guessing, an outdoor solution will lead to a GPS and 3G combination, while an indoor product would be surely based in Wi-Fi technology.
Outdoor
Health Monitor
Indoor
Communication system
1..* GSM/GPRS
Positioning system
1..*
Wi-Fi
WAN (3G)
Wi-Fi based GSM antennas
GPS
data sent. Finally, not shown in the Figures, a set of platform related decisions must be taken. Some important differences concern device types (smart or conventional phones, PDAs, etc.) and operating systems (Windows mobile, Android, Symbian tactile and keypad based devices, etc.). More details are given in Sub-section III.C. B. Product Line Design The distributed architecture of the system has been designed and implemented following the scheme of Figure 4. The data are collected by the mobile device and sent to the central system using a Web service via http. If a situation reflects abnormal parameters or a possible fall, the mobile device indicates to the patient the problem and after a few seconds an alarm is generated to be sent to a central system using the Web service. The use of standard SOAP based Web services to communicate with the central station has the advantage that no changes are needed in the server when an application is configured for a new mobile platform. Also in the server, the monitored data is made persistent using a database. Finally, a conventional Web application makes the data available to medical staff using an Internet browser. The Web service and The Web application for monitoring were developed using ASP/.NET and SQL Server under Windows but is transparently used by the three mobile platforms. The coordinates that the mobile application sends to the Central System are used with the Google Maps API to represent the position of the monitored person inside the residence (or outdoor). Mobile Device
Central System Web Service
Mobile Application XML SOAP
RFID DB
Fig. 3. Partial feature diagram of a remote health monitoring system (positioning and communication subsystems). Web Application
With independence of the communication technology, data interchange can be carried out using the HTTP protocol and web services implemented in a central system. This approach allows the parameters obtained by the sensors to be sent every few seconds, as well as alarm signals if needed. Part of these web services are devoted to the parameterization of the mobile system (value ranges, monitoring frequency, emergency phone number, etc. are easier to configure using a desktop work station). The role of experts in health care monitoring is essentially the customized system configuration, and the analysis of the captured information. All the functions can be supervised from a remote central system with Internet access, allowing the ubiquity of the solution. Under this supervised system, intervention would be necessary only when parameters achieve some critical values. The security protocols of ubiquitous wireless networks are nowadays similar to that of wired alternatives and must be routinely considered due to the confidential character of the
HTML
Work Station Web Browser
Google Google Maps
Fig. 4. Deployment diagram of the generic monitoring system
The design of the SPL is adheres to the usual rules relative to the use of Web services for communications between the mobile device and the central system, in particular concerning with security in data transmission. Security in Bluetooth transmission is granted by associating the sensor to a unique device (password required) during the configuration steps. On the other hand, secure Web services are similar to the HTTPS standard.
C. Product Line Implementation The first prototypes were initially developed using PDAs and Smartphones that support Windows Mobile. The .NET framework in its Mobile version and C# was used, togheter with the FMT plug-in for MS Visual Studio. Later, Java/Eclipse and the FeatureIde plug-in have been used to develop the alternative implementations for the Android and Symbian platforms. The Java versions have been developed in parallel for the two platforms. Both have a common part that is basically the domain model but, however, each platform uses different user interface frameworks. The support libraries for Bluetooth communications are also specific for each platform. In the Symbian version we use standard Java ME to implement a simple interface. In the Android version, the native activities and XML definition of the user interfaces are used. The techniques used for adding the optional parts to the user interface are based in the dynamic incorporation of optional elements in each package. Figure 5 and 6 show two examples of the user interface for a product configuration in two Windows Mobile and Android devices.
professional tri-axial accelerometer with a standard communication protocol accessible from any mobile device using Java o C# languages and common Bluetooth libraries [19].
Fig. 6. Main form of a configuration in a Windows Mobile device
Fig.5. Main form of a configuration in a Windows Mobile device
In all the platforms, the integrated GPS and indoor Wi-Fi positioning module and Bluetooth/Wi-Fi communication features have been implemented. Wi-Fi or 3G are used to communicate directly with the central system via a Web service. If there is no Wi-Fi or 3G connectivity, alerts can be sent using SMS messages directly to a configurable telephone number, covering the risk situations when the Internet connection is unavailable. Heart rate and oxygen saturation parameters can be controlled using the data sent from a commercial wireless sensor. The fall detection package has been developed for the Java platforms and is under development for Windows Mobile. This feature implements the algorithm presented in [11] for the Java based mobile devices using Bluetooth communication with the WiTilt sensor. The WiTilt sensor is a
The first SPL application we deployed and tested in the residence was a prototype for a Windows based device, with continuous monitoring and GPS positioning. The hardware configuration was composed of a Smartphone (HTC Cruise) with integrated GPS and several communication systems (WiFi, Bluetooth, GPRS/3G). The sensor used (Figure 7) was a Nonin Bluetooth pulsi-oximeter [14] that provides heart-rate and oxygen saturation values. Bluetooth communication is managed using existing libraries. More complete systems have been implemented in Java using the same sensor and the WiTilt accelerometer and GPS/Wi-Fi based positioning. They have been deployed for several Symbian (Nokia 5800) and Android (Samsung Galaxy, HTC Hero) mobile devices. In all cases, the personnel involved in the SPL design and implementation were not specialists. Some of the developers had some professional experience in conventional techniques, others were last year students. The authors help them to define the feature model, the only specific SPL artifact required during the development process.
Fig.7. One of the mobile devices and the pulsi-oximeter sensor, used in the SPL.
IV. RELATED WORK Wireless health monitoring systems are not new. There are many proposals that use mobile devices and sensors for remote monitoring including commercial solutions [6]. Commercial devices are expensive and their integration difficult. In recent years, specialized sensors have been used to measure heart rate variability with portable devices [8], for monitoring blood oxygen saturation continuously [15], or tracking patients in their home environment [13]. The widespread use of minimally invasive wireless sensor is discussed in [2]. In [12] and [17] other examples of suitable sensors for monitoring are described. Most of these works present ad hoc solutions, valid for specific platforms and sensors. The difference with our approach is that we present a product line that allows that conventional mobile devices can gather information from a variety of sensors. The specific characteristics of mobile applications have been treated as SPL in several works. Some of these works provide design patterns and generic tools for SPL design and configuration in the mobile domain. For example, in [5] some generic architecture patterns for mobile applications were specified in a platform independent and adaptable way. Also, the paper of White et al. [18] proposes a model-driven product line variant selection for mobile systems. A configuration tool is described and a constraint solver is used to derive a valid product variant and contemplate the resource constraints into the derivation process. In particular, the interest is the adaptation to mobile devices with different capabilities (different set of libraries in the Java ME environment). Anastopoulos and Muthig [2] use Aspect Oriented Programming (AOP) as an alternative for building Java ME product lines. The same AOP approach is used by Alves et al. [1] in the context of an industrial mobile game product line. These proposals need specific techniques and languages that are not usual in a typical software company. Though these solutions are valid, the learning of new modeling or implementation techniques and the need of specialized tools represent barriers for the adoption of the approach of product lines in many organizations. We therefore believe that our solution improves the abovementioned proposals. V. CONCLUSION We have shown how a product line development approach can be used to customize mobile systems. We use the package merge relationship to derive and trace the SPL architecture from the feature diagrams. The mechanism of partial classes (native in C#, as an adaptation in Java), enables the automated generation of each product from the features configuration. Furthermore, the use of conventional CASE and IDE tools, complemented with a specific plug-in, avoids the need of specific tools and techniques as in previous alternatives. In particular, the approach has been applied to the design and implementation of a product line for personalized remote monitoring systems that facilitate the autonomy of dependents. Heart rate or oxygen saturation data are obtained using
wireless sensors. Risk situations, including accidental falls, can also be detected. In the context of a senior citizen residence, we use a combination of sensors/mobile devices with a monitoring central server accessible from any Internet browser. The diversity of individual requirements and mobile platforms favor the use of the SPL paradigm. ACKNOWLEDGMENT This work has been funded by the Spanish MICIINN, through the ADISPA (BIA2009-14254-C02-01) and TIN200805675 projects. REFERENCES [1]
[2]
[3]
[4] [5]
[6] [7]
[8]
[9]
[10]
[11]
[12]
[13]
[14] [15]
[16]
[17]
[18]
[19]
Alves, V., Matos Jr, P., Cole, L., Borba, P., Ramalho G. (2005). Extracting and Evolving Mobile Games Product Lines. In Proceedings of the 9th SPLC'05. September 2005. Springer-Verlag. Anastasopoulos, M. Muthig. D. (2004). An evaluation of aspect-oriented programming as a product line implementation technology. In Proceedings of the International Conference on Software Reuse (ICSR) Boric-Lubecke O, Lubecke VM (2002) Wireless house calls: using communications technology for health care and monitoring. IEEE Microw Mag 43–48, Sept. Bosch, J. (2000). Design & Use of Software Architectures. Adopting and Evolving a Product-Line Approach. Addison-Wesley. Cho, H., Yang, J.S. (2008) Architecture patterns for mobile games product lines, International Conference on Advanced Communication Technology, ICACT. pp. 118-122. Ericsson Mobile Health: http://www.ericsson.com/ hr/ict_solutions/ehealth/emh FeatureIde (2011): Eclipse-Plugin for Feature-Oriented Software Development. Otto-von-Guericke-Universität Magdeburg. http://www.fosd.de/fide Jovanov E, O’Donnel A, Morgan A, Priddy B, Hormigo R (2002) Prolonged telemetric monitoring of heart rate variability using wireless intelligent sensors and a mobile gateway. In Proc. Second Joint IEEE EMBS/BMES Conference, 1875–1876 Laguna, M. A., González-Baixauli, B., Marqués, J. M. (2007). Seamless Development of Software Product Lines: Feature Models to UML Traceability. GPCE 07. Laguna, M. A., Marqués, J.M. (2010) UML Support for Designing Software Product Lines: The Package Merge Mechanism. J. UCS 16(17): 2313-2332 Laguna, M. A., Tirado, M.J., Finat, J., Marqués, J.M. (2010) Fall Detection Systems: A Solution Based on Low Cost Sensors. Proceedings of ICSOFT 2010 Lubrin, E., Lawrence, E., Navarro, K.F. (2005) Wireless Remote Healthcare Monitoring with Motes, International Conference on Mobile Business (ICMB'05), pp. 235-241. Mendoza, GG., Tran, BQ. (2002) In-home Wireless Monitoring of Physiological Data for Heart Failure Patients, In Proc. of the Second Joint IEEE EMBS/BMES Conference, pp 1849–1850 Nonin (2011). Pulse Oximetry Monitoring. http://www.nonin.com/PulseOximetry. Rhee, S., Yang, B-H., Chang, K., Asada, HH. (1998). The ring sensor: a new ambulatory wearable sensor for twenty-four hour patient monitoring. In Proc. 20th Annual IEEE International Conference on Engineering in Medicine and Biology, Hong Kong, pp 1906–1909 Salva. A., Bolibar, I., Pera, G., Arias. C. (2004). Incidence and consequences of falls among elderly people living in the community. Med Clin (Barc) 122(5):172–6. Vicente Tocino, A. et al. (2009) Personal Health Monitor. New Directions in Intelligent Interactive Multimedia Systems and Services 2, pp 465-475 White, J., Schmidt, D.C. (2008). Model-driven product-line architectures for mobile devices. In IFAC Proceedings Volumes (IFACPapersOnline). WiTilt (2011). SparkFun Electronics. http://www.sparkfun.com/products/8563
