Backbone 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

No system meeting all the criteria listed in the above paragraph is openly available to date. Part of the work conducted during the first year of 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).
 
 

 

Problems and solutions

The development of the prototype system described above has mostly required plain software engineering work rather than research work. This work was necessary, though, as the resulting system is meant to serve as a backbone for future developments and experiments in project Sherpam.

Many technical problems have been identified while developping this system. For example, the gateway used in the project is an Android smartphone. Since the Android OS does not allow an application to load external classes at runtime, an original plugin system has been developped for the 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.
Another problem is that although each kind of sensor is usually distributed with a dedicated demonstrator application, the protocol used by a sensor to transmit data to the application is sometimes poorly documented, or not document whatsoever. Part of the work conducted during the first year of project Sherpam has therefore been devoted to selecting which sensors can effectively be used in the project, developing the appropriate plugin modules for some of these sensors, and testing these modules extensively.

Prospects for future work

As mentioned above the prototype system is meant to support future developments and experiments conducted in project Sherpam. Future work might thus include:

  • The definition, implementation, and experimentation of adaptive data transmission strategies: the gateway shall ultimately be able to switch automatically between several kinds of networks (e.g., 2.5G/3G/4G, private/corporate Wi-Fi hotspots, community Wi-Fi hotspots) depending on multiple criteria such as network availability, induced power consumption, the nature of the data to be transmitted, etc. Special attention will be paid to tolerating network disruptions, so data are never lost during such events. 
  • The implementation of data processing algorithms to be embedded on the gateway: the gateway should be able to run autonomously when network connectivity is disrupted. Major constraints here will be the limited resources offered by a smartphone, especially as far as power and CPU are concerned.
  • The implementation of advanced (and possibly resource-greedy) data processing algorithms to be run on a dedicated processing unit, which should get data from the aggregation server.
  • A clinical experiment is planned at the end of the project. Several patients will be involved, and they will use the Sherpam system for a real use-case application. This experiment shall validate the whole system, and assess its acceptability by the patients.