BodyCloud Official Website!

BodyCloud: A Cloud-assisted Software Platform for Pervasive and Continuous Monitoring of Assisted Livings using Wearable and Mobile Devices


Latest stable version, source code and documentation are available for free download at our GitHub Project.

Info about the BodyCloud Licence will be available shortly.

Get involved

We welcome contributions from all users, including bug reports and fixing, suggestions, and sub-projects of BodyCloud.
Proposals for new sub-projects should be sent via e-mail to: 'rgravina(at)deis(dot)unical(dot)it' by specifying a short workplan with a description of the new functionalities, the impact on existing code, and the expected time for the first stable release.

BodyCloud: Architecture

BodyCloud is an open platform for the integration of BSNs with a Cloud Platform-as-a-Service (PaaS) infrastructure and it's currently based on Google App Engine. It has been developed to make the middleware layer fully distributed; it specifically supports remote sensory data storage, offline signal processing and custom-defined algorithms via a plug-in mechanism. Its design and implementation choices allow BodyCloud to flexibly be tailored, in a very effective manner, for supporting a broad range of application domains, including m-Health, Building automation, and environmental monitoring.

The architecture consists of four main subsystems (or sides):
  • Body, which is the system side that monitors the target environment, phenomenon, or assisted living by means of wireless networked sensors, and sends the collected data to the Cloud through a mobile coordinator device. In particular, BSN data acquisition is currently based on SPINE, and on the BMF for Building sensor networks. Data collected are then streamed up to the Cloud-side. In Android-SPINE communication of wearable sensors with the BAN coordinator is based on Bluetooth, while for the BMF the communication is based essentially on IEEE 802.15.4/Zigbee.
  • Cloud, which is the system side providing full support for specific applications through data collection, processing/analysis and visualization. In particular, each specific application can be defined through the following programming abstractions: Group, Modality, Workflow/Node, and View. Such abstractions are supported by a RESTful web service (Server Servlet), implemented using the Restlet Framework, making the interaction with the Cloud-side fully based on HTTP methods (get, put, post, delete). The interactions are authenticated by the OAuth Verifier component based on OAuth 2.0. The Cloud-side is supported by the Google App Engine PaaS that provides the Datastore API, atop which the Persistence Layer managing the collected sensory data is built, and the Task Queue API, which enables asynchronous execution of tasks triggered by requests.
  • Analyst, which is the side of the system that supports the development of new BodyCloud application services. In particular, users can create new BodyCloud services by defining the aforementioned entities: groups, modalities, workflows, and views. Each entity can be created with an HTTP PUT request to the corresponding Cloud-side resource, thus requiring only a simple HTTP client as Analyst-side supporting application. As the workflow requires new nodes to be developed, the Analyst-side also requires an appropriate development environment. Once developed, new nodes are also uploaded with a HTTP PUT request to the corresponding Cloud-side resource. A predefined set of nodes is typically available, depending on the adopted implementation of the Workflow Engine.
  • Viewer, which is the system side able to visualize the output produced by the data analysis through advanced graphical reporting facilities. The graphical view is automatically generated by applying the View specification to the data.