Overview of the Sherpam system


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.


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

Sensors worn by a subject are used to acquire data pertaining to the subject’s status (acceleration, gyroscope, heart rate or full-featured ECG, temperature, location, etc.). Data streams produced by these sensors are gathered by a portable “gateway”, which is also worn by the subject. This gateway pre-processes data, so they can be transferred to a remote site for storage and analysis. The sensors and the gateway together constitute a Body Area Network (BAN), and transmissions in this BAN rely on Bluetooth links (including Bluetooth Low Energy). Support for other transmission technologies (e.g., ANT+) may be included later in the system.
Before transferring data to a remote site, the gateway can pre-process these data in order to reduce the amount of data to be transferred, or in order to detect interesting patterns in these data. In the latter case, the subject can be warned directly by audible or visual notifications.
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).








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.

Adaptive behavior of the gateway

Communication between the gateway and the remote site relies on medium-range to long-range transmission technologies such as Wi-Fi and 2.5G/3G/4G. Since network connectivity cannot be guaranteed anywhere and anytime for a mobile device, disruption-tolerant techniques are used to ensure that no data is lost during disconnections. The Sherpam system may thus be used in challenged environments where network connectivity is erratic, for example in rural or developing regions, or in disaster-relief scenarios.

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.


Comments are closed.