3.4.1 Architecture

A high‐level representation of the SPINE architecture is shown in Figure 3.1. The SPINE MW is partially located at the coordinator device and partially on the wearable sensors. The MW provides an API both on the coordinator and the sensor nodes to support the development of applications that finally rely on the platform‐independent communication protocol layer. This protocol represents an abstraction layer including diverse platform‐dependent communication adapters that are dynamically loaded at the coordinator, whereas are linked at compile time at the sensor‐node level.

Figures 3.2 and 3.3 show, respectively, the architecture of the SPINE Node(s) and SPINE Coordinator components. The former is implemented in the sensor platform‐specific embedded programming language and is placed on each BSN sensor node; the latter is implemented in Java and runs on the coordinator device (an Android porting of the SPINE Coordinator has also been realized).

The SPINE Node (see Figure 3.2) consists of four main components:

• Sensor Node Manager, which handles the interactions among the Sensing Management, Signal Processing, and Communication modules; it dispatches the requests from the remote coordinator to the appropriate module.
• Communication, which handles message reception/transmission and controls radio duty‐cycling. It consists of inbound packet decoders (i.e. service discovery, start and reset computation requests, setup function request, function (de)activation request, and setup sensor request) and outbound packets encoders (i.e. service advertisement, buffered sensor readings, processed data message, and acknowledgment packet). Any packet is initially handled by the Radio Controller module, which provides a generic interface independently from the specific underlying radio chip adapter.
• Sensing Management (or SensorBoard controller), which is the component providing a generic interface to the physical sensors available on the node. It allows to perform one‐shot sensor readings and to setup timers for periodic sensor sampling. This component provides easy hardware‐independent access to all the supported sensor drivers (SPINE currently supports 3D accelerometer, 2D gyroscope, 4‐leads ECG, respiration rate, GSR, EMG, visible and infrared light, humidity, and environmental temperature) through a list of parameterized Sensor interfaces. This design choice is motivated by the need for high modularity and efficient customization to support heterogeneous sensing resources in a convenient way. Sensor readings are stored in the BufferPool, a data structure that is shared with the Signal Processing module. The BufferPool, internally organized as multiple circular buffers, provides two mechanisms to access the sensor data: (i) upon requests, using getter functions, and (ii) through event listeners that must be registered by interested components (e.g. Signal Processing module) to be notified when new sensor data are available. The Sensing Management also features a shared sensor registry to which each sensor driver self‐registers upon program bootstrap. This registry is accessed at runtime by other components to retrieve the list of sensors actually available on that specific node.
• Signal Processing, which uses a block called Function Manager that is responsible for handling a customizable and expansible set of signal‐processing functionalities such as (i) math aggregators (features like maximum value, minimum value, amplitude, average, standard deviation, signal energy, and entropy), (ii) threshold‐based triggers (also known as alarms), and (iii) filters; such processing functionalities can be arbitrarily applied to any sensor data stream. The Function Manager engine uses an efficient design approach based on a list of parameterized Function interfaces providing a general‐purpose abstraction for any type of processing task. The Signal Processing module retrieves sensor data from the BufferPool and, by interacting with the Sensor Node Manager and the Packet Manager, it communicates the results to the coordinator unit.

The SPINE Coordinator (see Figure 3.3) consists of two main components:

• Communication, which has similar functionalities to its corresponding component on the sensor node; it loads at runtime the proper radio module adapter according to the required network stack. It abstracts the logical interactions between the coordinator and the sensor nodes from the actual network activity that depends on the selected platform. This abstraction layer is realized by decoupling the communication interface from its platform‐dependent implementation layer.
• SPINE Coordinator Manager, which is the most superficial layer atop which every SPINE applications will rely. It is composed of Sensor Network Control API (see Table 3.1) and Event Dispatcher. The former is an interface used by end‐user application developers for the management of the underlying BSN (e.g. to configure the sensors and enable on‐node signal processing). The latter is responsible for dispatching events, such as new node discovery and data message arrival, to the registered listeners implemented by the SPINE applications.

3.4.2 Programming Perspective

From a programming perspective, SPINE provides an intuitive Java API (documented in Chapter 12) for convenient BSN management to easily support node discovery, sensing operations, signal processing, and data communication. In addition to several sensor natively supported and pre‐defined processing functions, SPINE is designed such that framework tailoring (i.e. customization and extension) becomes very straightforward.

3.4.3 Optional SPINE Modules

The SPINE MW is completed with “optional add‐on” modules available only on the coordinator node; they represent an important aspect, despite not being part of its core architecture:

• High‐Level Data Processing, which provides advanced signal processing and pattern recognition functionalities. It supports the design and implementation of complex applications by means of highly generalized interfaces for data preprocessing, feature extraction and selection, signal processing, and pattern classification. It supports the integration of SPINE in analysis and data mining environments with functionalities such as automatic network configuration and aggregate data collection. It includes a predefined bridge to WEKA [7] (an open‐source Data Mining toolkit) to allow the use of its powerful algorithms directly within SPINE.
• SPINE Management GUI, which consists of a visual programming tool to configure a SPINE‐based BSN without manually coding. According to our experience, it has been useful during initial system testing. Screenshots of its PC and Android implementations are shown in Figures 3.4 and 3.5, respectively.

3.4.4 High‐Level Data Processing

The High‐Level Data Processing module is an optional SPINE plug‐in that empowers the core framework functionalities with additional signal processing and decision‐support algorithms (e.g. signal filters, pattern recognition, classification, etc.). This module is available at the coordinator level and provides robust support throughout the typical signal‐processing workflow, from sensor data acquisition up to classification (see Figure 3.6).

A layered representation of the High‐Level Data Processing component is depicted in Figure 3.7. SPINE acts as a MW layer between this module and the underlying BSN. On top of SPINE, a set of converters are placed to convert SPINE data representations into more abstract objects, Datasets and Signals. Data mining and machine learning tools can therefore transparently handle BSN data, since the module can also generate WEKA‐compliant Comma Separated Values (CSVs) and Attribute‐Relation File Format (ARFF) files. Finally, a collection of functionality wrappers further support rapid implementation of common tasks needed during the development of SPINE applications. A typical use of this module is described in detail in the following.

BSN sensory data are retrieved with SPINE and converted into more convenient data structures (Signal and Dataset objects, depending on application‐specific requirements). Then, developers can optionally apply filtering and segmentation to incoming signals. Feature Extraction algorithms are also available and they are useful when in‐node feature extraction functionalities provided by SPINE are not enabled (i.e. SPINE is used to acquire raw sensor signals). To support the initial problem analysis, several feature selection algorithms are provided to identify the most significant subset of extracted features to reach satisfactory classification accuracy. Finally, the classification phase is widely supported, including training. A few algorithms are implemented and ready‐to‐use; in addition, developers may easily integrate further classifiers, especially thanks to the choice of providing support for using WEKA libraries.

3.4.5 Multiplatform Support

SPINE supports a heterogeneous plethora of hardware platforms, sensors, programming languages, and operating systems; these make this framework suitable for diverse application scenarios (such as smart‐Health and e‐Fitness), in which, due to specific requirements, only certain hardware/software sensor platforms might be used.

SPINE supports the most common sensor motes. The TinyOS implementation runs on MicaZ, TelosB, and Shimmer/2/2R [8] (for the latter, SPINE supports both IEEE 802.15.4 and Bluetooth radios). This implementation includes a security function using hardware AES‐128 encryption of the CC2420 radio. In addition, there exist SPINE implementations for ZigBee devices (like the Telecom Italia “Bollino”, equipped with the CC2530 System‐on‐Chip) based on Texas Instruments Z‐Stack and for Java‐based Sun SPOT nodes [9]. SPINE also notably provides native support for several physical sensor transducers, including accelerometers, gyroscopes, electrocardiogram, electro impedance plethysmography, temperature, humidity, and light.

In addition to sensors and platforms supported by default, SPINE is designed in such a way that it is easy to integrate further drivers for other sensors and even add support for new platforms. The same happens for the processing functions: integrating additional feature extractors (and even simple classifier algorithms) is straightforward.

At the coordinator level, SPINE supports heterogeneous mobile and desktop devices, as depicted in Table 3.2. Originally, Windows‐ and Linux‐based computers were supported through the SPINE Java SE implementation. However, with the spread of smartphones and tablets having more than sufficient computation and storage capabilities to support mobile‐health applications and (almost) continuous Internet connectivity (through which it is possible to transmit raw signals and high‐level information to remote servers or in the cloud), we put significant efforts to obtain mobile SPINE coordinators since their use is particularly useful (sometimes strictly necessary) when continuous, outdoor mobility is required and is not possible to rely on fixed infrastructures. A JavaME porting of the framework has been in fact realized. A limited QT implementation is also available and runs on Symbian and Windows smartphones, enabling Bluetooth communication with Shimmer nodes using the third‐party QBluetooth library. Finally, and most significant, an Android implementation of SPINE has been more recently developed. SPINE Android has been evaluated on several devices (that have been connected to Shimmer nodes over Bluetooth).

Finally, SPINE provides a Java‐based emulation environment that virtualizes generic sensor nodes. With this tool, it is possible to emulate a SPINE‐based BSN, provided that a dataset is available for each node. Hence, each emulated node is equipped with emulated sensors defined by its given dataset. The SPINE emulator is helpful in various situations; for example, to simplify testing and debugging, processing functionalities can be initially implemented in the emulated environment. In addition, the emulator, along with a simple dataset, has been released in open‐source to allow interested developers for investigating the potential of the SPINE framework itself, even if they are not equipped with real wireless sensor nodes.