Overview of the Sherpam system

Challenges

Project Sherpam aims at monitoring continuously the health status of people during their daily activities. A system for data acquisition, transmission, and processing is therefore required that meets the following criteria:

• Extensibility
  Since distinct pathologies may require different types of data the system should not be limited to a pre-defined, immutable set of sensors, but it should on the contrary be extensible so as to easily accommodate new types of sensors whenever needed;
• Self-sufficiency
  The system should allow that data acquired by sensors be processed either “locally” or on a remote site. Local processing makes it possible for the sensing system worn by a subject to run autonomously –though possibly in a degraded mode– when no communication network is available. In contrast remote processing makes it possible to run advanced (CPU intensive) algorithms on the data collected by the sensors.
• Agility
  The system should be agile regarding network connectivity, switching from cellular (2.5G/3G/4G) networks to Wi-Fi hotspots depending on their availability, but also depending on other parameters such as the nature of the data to be transmitted or the power consumption involved when using each kind of network.
• Disruption-tolerance
  The system should be able to tolerate disruptions in network connectivity, including long disruptions as can be observed in “white zones” that are not covered by any wireless network.

Achievements

General architecture

No system meeting all the criteria listed in the above paragraph is openly available to date. Part of the work conducted in project Sherpam has therefore been devoted to designing and implementing a prototype system that meets these criteria. To date the source code of this system is composed of about 170 Java classes, which together contain about 17.000 lines of code.

An overview of this prototype system is provided in Figure 1. This system encompasses all stages of data acquisition, transmission, and processing, and each of these operations can be performed automatically and continuously.

Fig 1. Overview of the Sherpam system

Fig 2. Screenshots taken from the Android application deployed on the gateway

Since the Android OS does not allow an application to load external classes at runtime, an original plugin system has been developped for this project’s Android app. With this plugin system, software modules can be “plugged in” the application at any time, each module being designed to drive a specific type of sensor. With this feature, the Android app is highly modular, as new types of sensors can be included at any time in the Sherpam system, without requiring any update of the app itself.

In the Sherpam system, the data collected by the gateway are not necessarily transmitted immediately to the remote site. They are first assembled into bundles, which can be stored for a while on the gateway, and be transmitted to the remote site when circumstances permit. A bundle is basically a collection of data samples, together with meta-information about these samples (data type, timestamps, priority level, etc.). Using bundles as transmission units in the Sherpam system makes it possible to devise and implement adaptive strategies in the gateway. For example, when a connectivity disruption occurs, the order in which bundles are sent once the connectivity is reestablished may depend on the nature or priority level of the data samples contained in these bundles. Bundles containing urgent data may thus be transmitted first, while less urgent bundles are delayed or discarded. Using bundles also makes it possible to transmit data in short high-speed bursts, rather than in continuous low-speed streams. With this approach the radio circuits used by the gateway can be disabled most of the time, which significantly reduces the power drain on this device. Indeed, the Android app running on the gateway can deliberately disable all radio circuits in order to save power, enabling only the Wi-Fi radio every now and then to send all or part of the available bundles, and switching to cellular (i.e., 2.5G/3G/4G) transmissions only when Wi-Fi transmissions are not possible. Field experiments have shown that such an approach proves very effective to preserve the power budget of the gateway, multiplying its autonomy up to tenfold.

Aggregation server

The front-end of the “remote site” is an aggregation server, whose role is to receive the bundles sent by mobile gateways, to extract the data contained in these bundles, and to store these data so they can be accessed by processing units.

A processing unit is typically an application that subscribes with the server in order to receive all data pertaining to a given patient, and to process these data continuously and autonomously, looking for interesting patterns (for examples signs of arrythmia in a stream of ECG samples). When a processing unit detects anything interesting or unusual, a notification can be sent automatically to medical staff, or directly to the patient.

A very basic processing unit has been developped to serve as a demonstrator in project Sherpam. This unit is simply a Web server (Fig. 3), which makes it possible to parse the data stored on the aggregation server, to visualize data sets, and to download selected data for further analysis.

Fig 3. Screenshot of the demonstration website

Data encryption

Since data pertaining to the health of people are inherently sensible data, the whole Sherpam system has been designed so as to preserve the confidentiality of these data. All transmissions between a Sherpam gateway and the aggregation server are encrypted  using state-of-the-art encryption algorithms. Besides, a gateway must authenticate itself with the server before being able to send any bundle of data samples. Once they reach the aggregation server the bundles are processed locally, and the data they contain are stored in the local filesystem in an encrypted form.

Prospects for future work

The prototype system developed in the framework of project Sherpam is extensible. Future extensions might cover:

• The implementation of data processing algorithms to be embedded directly on the gateway, so it can run autonomously when network connectivity is disrupted.
• The implementation of advanced (and possibly resource-greedy) data processing algorithms to be run on dedicated processing units.