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

 
In the framework of project Sherpam, the gateway is typically an Android smartphone running a dedicated application (see the screenshots in Fig. 2), as this kind of device is readily available at reasonable cost, is programmable, supports several radio standards (e.g., Bluetooth, Wi-Fi and 2.5G/3G/4G), has enough processing power to handle data streams, and offers a nice user interface. The Android application developped in the framework of project Sherpam has been registered with the French Agence pour la Protection des Programmes  (IDDN.FR.001.540019.000.S.P.2015.000.31230).
 

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.

Adaptive behavior of the gateway

 
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.

 
Security considerations
 
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 and the integrity of these data:
  • The real identity of the patient is never associated with the data collected and processed by the Sherpam system. Instead a neutral identifier is used, and this identifier is included in the meta-information of each data bundle. Matching a dataset with the corresponding patient's real identity is only possible for medical staff;
  • The data bundles stored in a wearable gateway are encrypted (using AES-256 encryption), so the data they contain are safe in case the gateway is lost or stolen;
  • All transmissions between the gateway and the aggregation server are encrypted using the TLS suite, which prevents eavesdropping and data tampering;
  • Once a TLS session is established between the gateway and the aggregation server, the gateway must authenticate before being able to send any bundle, so the server's database cannot be corrupted by faked data;
  • 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 (so the data they contain would be safe even if the server was compromised);
  • The server can —and should!— be installed in a data-center providing standard security measures, such as restricted access, reliable backup procedures, redundant power source, fire prevention, etc.

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.