Middleware Solution for HealthCare IoT Applications

Middleware Solution for HealthCare IoT Applications José Cecílio and Pedro Furtado University of Coimbra, Coimbra, Portugal {jcecilio, pnf}@dei.uc.pt

Abstract. Advances in Internet of Things (IoT) technologies present enormous potential for the intensified healthcare support of senior or disabled citizens. Everyday objects will have the capability of directly interacting with each other and with humans. In this context we propose NCeH – a middleware solution that hides heterogeneity and offers a single common configuration and processing component for all nodes of IoT applications developed on top of it. The middleware is intended for the caring of people with special needs, such as video-vigilance, monitoring and so on, with multi-function, and is currently applied as a prototype in collaboration with cerebral palsy, blind and seniors caring institutions. Keywords: Internet of Things, Senior or disabled citizens, Middleware, Heterogeneity, Interoperability.

1 Introduction The Internet of Things (IoT) is one of the recent technological and social trends that will have a significant impact in the delivery of healthcare. IoT represents a vision in which Internet extends to the real world, everything is interconnected and has a digital entity. The impact of IoT will not be the same in all sectors, healthcare being the one to play a leadership role. IoT will enable the patient to stay longer and safer at home, since smart devices can alarm the hospital in case of critical conditions. Furthermore, due to constant monitoring, the patient can be relieved from the hassle of routine checks, replacing costly travel and reducing patient stress. Using implantable wireless devices to store health records could save a patient's life in emergency situations. Currently, the services and technologies for accessing real world information are typically closed, leading to vertically integrated solutions for niches of applications. This approach leads to inefficient and expensive service infrastructures that lack interoperability. In this context we propose a middleware solution based on a single node component and a remote configuration/code loading component. The proposed solution ensures that all nodes will have at least a uniform configuration interface, important remote management and processing capabilities without any further programming or gluing together. The proposed approach advances the current state-of-the-art, by providing a model whereby a single but powerful component is deployed in any node, regardless of its

underlying differences, and the system is able to remotely manage and process data in a flexible way. In the literature, there are some middleware solutions for IoT and sensor networks. Most of the middleware are built on top of specific Operating Systems (mainly tinyOS) and almost all of them assumed it as a requirement and were not designed for abstracting away heterogeneous contexts. TinyDB [1] , Agilla [2], Impala [3] are examples of middleware approaches designed to operate within sensor networks. On the other hand, Borealis [4], GSN [5] and IrisNet [6] are examples of middleware approaches that do not operate within sensor networks. Our approach can be deployed in any device, including embedded devices of any type. For more information on sensor networks middleware, please consult [12], on internet-of-things, please consult [13], and the relation between IoT and WSN [14]. Our work focuses on providing a device-independent middleware for operating with any IoT nodes, targeted at healthcare applications.

2 IoT HealthCare Application Scenarios and Requirements IoT technologies and architectures could potentially impact a number of healthcare applications, such as medical treatment, pre- and post-hospital patient monitoring [7], people rescue [8]–[10], and early disease warning systems [11]. The healthcare application scenario is a very special scenario, since nodes store the data until some instant in time. All sensors are connected to one node, which is an embedded device. The node is placed on the body (human or animal body). Store and processing capabilities are the most important aspect in this scenario, because the node must collect and process data until a decision support system requests it. For instance, if a patient goes to the hospital and uses body sensors to monitor the heartbeat during a day [8], the node must be able to store the data it collects during a day and unload the data only when the patient returns to the hospital. Another application scenario [9] referring node processing and actuation is when a diabetic patient is monitored for insulin injection. Several middleware requirements can be extracted from the previous scenarios. We consider data acquisition and processing, system configuration as functional requirements, while heterogeneity, interoperability and adaptability are considered as non-functional requirements. Data acquisition and processing: Data have to be acquired and stored, processed (e.g., format adaptation, filtering), transferred, further processed or merged and delivered to users. Heterogeneity: The middleware should be modular and based on drivers and interfaces, which allow it to run over different hardware and software platforms. Interoperability: All nodes have to be provided with standard interfaces to access the data (different nodes have to be abstracted and accessed in the same way using a common API). Flexibility: The middleware must be flexible and adaptive. Each application context (e.g. measurements of blood pressure, glycemic levels) will demand a slightly different mix of operations, sample rates and response times. System configuration and Adaptability: It should be necessary to deploy the system, configure it and it should be up and running. In other scenarios, it may be

necessary to program part of the applications, using a common dialect and calling standard API functions. To end this section, we describe a simple example scenario. A glucometer sends readings to a smartphone using a Zigbee communication. The smartphone uses GSM to exchange data and commands with a server. Each of these devices has exactly the same node component software, although developed for different platforms. Additionally, it was not necessary to code, since data sensing, storage and sending is configurable in the middleware.

3 ARCHITECTURAL DESIGN In this section we propose the IoT architecture. It provides remote access for configuration and processing capabilities to any device. The proposed architecture builds an intermediate computing layer which will serve as an abstraction hiding different hardware implementations. Fig. 1 shows the proposed architecture. It defines a node component (NCeH) that must be included in all node devices, including computers and data servers. The architecture works on top of a network communication infrastructure that is used to exchange data messages between nodes, send configuration commands to nodes and send acknowledgements from them.

b)

a)

General Overview of the architecture

General architecture – Application context c)

Node Component architecture

Fig. 1. NCeH architecture.

The NCeH (represented in Fig. 1 c)) runs at application level and has a set of modules that provide: communication capabilities (Comm processor and API), whereby the node will be able to exchange messages with any other node in the system; data and command processing capabilities (Data and Command Processor), whereby the node will be able to configure itself based on remote commands, look and compute on data it collects from either sensors or other nodes, to take decisions and to route data;

acquisition/actuation capabilities (HW Adapter), whereby sensor nodes will be able to periodically acquire sensing values or issue actuation commands. The NCeH was designed to provide mechanisms to handle node referencing, heterogeneity and platform and communication protocol independency. Platform and Communication Protocol Independency: In order for NCeH to run over different hardware and communication protocols, it needs drivers to manage files, handle different communication protocols and sensors, as well as drivers to handle timer events and memory requirements. When developing NCeH for a not-yetsupported operating system, the programmer needs to develop a set of drivers that offer a common architecture defined API, translating the corresponding calls to operating system calls. Node Referencing and Heterogeneity: In order to handle communication protocol heterogeneity, NCeH defines a gateway component. This provides support for communication with non-IP embedded devices. Each gateway implements two communication protocols and translates data packets between them. Each gateway has a Translator module, which is an application level protocol translator. It receives the message at application level, looks up the destination address, and resubmits the message using the communication function on the other side. Publish/Subscribe External Interface: The NCeH architecture includes publish/subscribe mechanisms to publish data stream content to external applications. Users can subscribe to the data stream where each subscription is represented by a “subscribe” request, which includes the subscriber address, port, a connection timeout, and the stream source. Data and Processing Model: NCeH implements a query processor. Based on queries formulated by users, NCeH parses and transforms them into logical configuration commands. These commands consist of high-level representations of the operations that need to be executed to obtain answers to the query. The glucometer from the previous example is instrumented with the node component NCeH binaries for the device that has the glucometer. Similarly, the smartphone running android is instrumented with NCeH for android, and the server runs NCeH for Linux. The user sends configuration commands (read glucose every second; send to smartphone; store for 1 day; send to sever). Each of the keywords - glucose, smartphone, server - are defined using a simple mechanism (we do not explain further for lack of space).

4 EXPERIMENTAL EVALUATION As NCeH can be deployed for embedded devices or more powerful nodes, such as computers, in this section we will evaluate the NCeH when implemented in computer, Raspberry PI, TelosB and Arduino platforms. We have developed NCeH for the devices listed above. Next, we configured the devices remotely using the remote configurator with an application that samples temperature sensors periodically, stores them and sends the data to a central server. This was a straightforward Java application that called the APIs of the middleware for

interacting with the resources. In the rest of the experimental section, we focus on the issues related to development and porting of the middleware. 4.1 Development and porting between platforms The middleware must be developed once only for each type of platform/operating system. We have developed the middleware for the above listed platforms. Our experience from the development was that the first implementation that was done (the TelosB/Contiki one) required us to design all the structures and mechanisms of the middleware. However, the resulting code was used as a template for th remaining developments. This way, porting to other devices was quite easy. In agreement with the definition of NCeH, all functionalities were isolated from the operating system and hardware by using drivers. Additionally, some of the devices, such as the computer and Raspberry PI are less constrained, therefore we could make use of more memory and other resources. From these implementations and porting we concluded that the reference architecture of NceH is quite helpful, since it specifies which modules to implement and how should work. Porting to new platforms is also simple. 4.2 Memory and performance In this sub-section we will detail the amount of memory needed to implement NCeH in chosen platforms. Fig. 2 shows the amount of memory needed by each component of NCeH in the different platforms. From Fig. 2 we can conclude that NCeH implementation was significantly small to fit all devices that were tested. Implementations for either computer or Raspberry nodes need less than 60 KB (without operating systems). These consume more space than implementations for other platforms because they are java-based, but both computers and Raspberry PI resources do not pose any constraints on such code sizes. The Arduino implementation is smaller than the other ones, because it is written in C++ and it is not loaded with a full Operating System. Another important issue for some embedded devices with constrained resources is the quantity of RAM memory needed to run each implementation. Fig, 2 also shows the amount of memory needed by each component and in total for each platform.

a) Programming memory Fig. 2. Memory consumption.

b)

RAM memory

From Fig. 2 we conclude that the Contiki-C version is the implementation that needs less RAM. However, this is not accounting for the RAM used by the Contiki

Operating System. In general, the amount of RAM needed is small and fits nicely into each platform.

5 Conclusions In this paper we proposed an IoT architecture for healthcare applications. It offers easy and uniform configuration and operation for embedded devices and nodes such as computers or data servers. The model advances the state-of-the-art since it views the whole system as a distributed system and any computing device as a node, regardless of hardware or operating system. We have described main mechanisms and details of the architecture. Then we develop the architecture to show that the system is ease to implement and port for different classes of devices. Acknowledgments. This work was supported by the iCIS project (CENTRO-07ST24-FEDER-002003).

References [1]

[2]

[3] [4]

[5]

[6] [7]

[8]

[9]

[10]

[11]

S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, “TinyDB: an acquisitional query processing system for sensor networks,” in ACM Transactions on Database Systems, 2005, vol. 30, no. 1, pp. 122–173. C. L. Fok, G. C. Roman, and C. Lu, “Rapid Development and Flexible Deployment of Adaptive Wireless Sensor Network Applications,” in 25th IEEE International Conference on Distributed Computing Systems ICDCS05, 2005, pp. 653–662. T. Liu and M. Martonosi, “Impala: a middleware system for managing autonomic, parallel sensor systems,” in System, 2003, vol. 38, no. 10, pp. 107–118. D. J. Abadi, Y. Ahmad, M. Balazinska, J. Hwang, W. Lindner, A. S. Maskey, A. Rasin, E. Ryvkina, N. Tatbul, Y. Xing, and S. Zdonik, “The Design of the Borealis Stream Processing Engine,” in Time, 2005, pp. 277–289. K. Aberer, M. Hauswirth, and A. Salehi, “The Global Sensor Networks middleware for efficient and flexible deployment and interconnection of sensor networks,” in Network, 2006, no. 5005. P. B. Gibbons, B. Karp, S. Nath, and S. Seshan, “IrisNet: An architecture for a worldwide sensor web,” in Ieee Pervasive Computing, 2003, vol. 2, no. 4, pp. 22–33. B. P. L. Lo, S. Thiemjarus, R. King, and G.-Z. Yang, “BODY SENSOR NETWORK – A WIRELESS SENSOR PLATFORM FOR PERVASIVE HEALTHCARE MONITORING,” in Architectural Design, 2005, vol. 13, no. 2–3, pp. 77–80. M. Blount, V. M. Batra, A. N. Capella, M. R. Ebling, W. F. Jerome, S. M. Martin, M. Nidd, M. R. Niemi, and S. P. Wright, “Remote health-care monitoring using Personal Care Connect,” in IBM Systems Journal, 2007, vol. 46, no. 1, pp. 95–113. F. Zhou, H. Yang, J. M. R. Álamo, J. S. Wong, and C. K. Chang, “Mobile Personal Health Care System for Patients with Diabetes,” in Aging Friendly Technology for Health and Independence, 2010, vol. 6159, pp. 94–101. I. M. Lopes, B. M. Silva, J. J. P. C. Rodrigues, J. Lloret, and M. L. Proenca, “A mobile health monitoring solution for weight control,” in 2011 International Conference on Wireless Communications and Signal Processing WCSP, 2011, pp. 1–5. T. Gao, D. Greenspan, M. Welsh, R. Juang, and A. Alm, “Vital signs monitoring and patient tracking over a wireless network.,” in Conference Proceedings of the International Conference of IEEE Engineering in Medicine and Biology Society, 2005, vol. 1, no. September, pp. 102–105.