4.1 Introduction

The SPINE framework described in Chapter 3 provides an effective solution for easily and rapidly developing highly customizable signal‐processing applications for BSNs. The in‐node processing applications supported by SPINE are usually defined as a three‐layer chain of tasks: (i) acquisition of raw data streams from the sensors, (ii) computation of processing functions on the data streams to extract specific features, and (iii) transmission of processed data to the base station for further computation.

However, some signal‐processing applications require an extension of this approach to fully satisfy the needs for a more complex composition of sensing and processing tasks. Therefore, a task‐centric programming model has been experimented in a new reengineering of the SPINE framework, dubbed SPINE2 [1]. Conceived not to be a replacement for SPINE 1.x versions, SPINE2 is actually intended as an alternative application design tool exposing a different methodology to translate the high‐level intentions of the developers into actual executable routines to be deployed on a BSN. The task‐oriented approach aims at providing an easy and effective way for developing distributed signal‐processing applications, thanks to its intuitive and graphical design model. It offers a wide range of benefits to developers, like the advantage of abstracting away low‐level details of the sensor platforms and their operating system as well as the complexity of managing the communication among nodes. Moreover, a platform‐independent middleware eases the reusability and portability of the code and the interoperability of applications among heterogeneous embedded environments, while not neglecting the stringent requirements in terms of execution efficiency and stability.

In this chapter, the SPINE2 programming paradigm and the software architecture of the underlying distributed middleware running on the sensor nodes are presented. With SPINE2 we show how fairly sophisticated signal‐processing applications can be realized in the form of easy‐to‐implement embedded processes.

4.2 Background

The main limitation in developing applications for BSN‐based systems is the need for proper design and programming skills to successfully deal with the low‐level aspects of embedded devices. Also, application development is even more challenging and time‐consuming due to the very resource‐constrained environments provided by the most commonly available sensor platforms. Unfortunately, such a hard task prevents BSN‐domain experts, who may not have a software development background, from directly contributing to the building of applications. Therefore, a proper high‐level development paradigm is highly desirable to hide the low‐level programming issues, so as to allow anyone with poor or no skills in programming to autonomously prototype and test their own applications by focusing on the desired algorithms. Such a desired paradigm should come with a set of well‐defined constructs that lead to a faster application definition as well as a more component reusability and a minimized maintenance process.

That entails the adoption of abstract, easy‐to‐use, and fully configurable functional blocks, which should allow to quickly implement the set of the most common operations needed by BSN applications. Interoperability and interconnection among applications, possibly defined by different users, should also be part of the features supported by a high‐level development framework. This is usually achieved by defining a common higher level communication protocol, which is independent from the actual underlying protocols supported by a specific sensor platform. Moreover, its paradigm philosophy should strongly promote the potential benefit of enabling an easier application reconfiguration at runtime and thus providing built‐in mechanisms for dynamic reprogramming without directly accessing the already deployed devices.

The idea of employing the well‐known task‐based paradigm in the BSN context comes from the need of finding a better way to meet all these requirements with an easy‐to‐understand high‐level paradigm able to (i) effectively and efficiently abstract away from the hardware and the network‐specific details and (ii) provide constructs particularly devoted to easily define distributed signal‐processing applications.

4.3 Motivations and Challenges

4.4 SPINE2 Overview

The SPINE2 framework has been conceived to further increase simplicity and effectiveness in developing distributed signal‐processing application atop BSNs. Specifically, its peculiar feature is the adoption of a task‐oriented paradigm, which allows developers to quickly make use of simple constructs to translate the high‐level application logic (global behavior) into actual operations to be executed on each single sensor node of the networks. Moreover, SPINE2 makes reconfigurability and reusability of applications easier than other proposed programming frameworks for sensor networks.

SPINE2 comes with two main software components: the sensor node middleware running on the network and the management software running on the coordinator side (typically a PC or a supported hand‐handled device). The latter one, developed in Java, is the main interface to the BSN. In particular, it provides well‐defined APIs, thanks to which developers can easily manage the network as well as the application, i.e. defining, deploying, and running the defined set of interconnected tasks. Moreover, it gathers the data preprocessed on the nodes, which can be further processed by more complex and resource‐demanding user‐defined algorithms and visualization tools. The node‐side middleware running on top of the sensor node operating system has two main functions: (i) handling messages received from the coordinator or any other node and (ii) managing and executing the tasks the node is responsible for.

The key characteristics of the framework are discussed below.

• Platform independence and quick portability: supporting a swift portability across diverse sensor platforms was one of the primary motivations for which SPINE2 has been designed. As such, the node‐side middleware architecture has been conceived for decoupling the task runtime execution engine from any other services provided by specific operating systems, as depicted in Figure 4.1. Based on the software layering approach, the whole runtime system of the node is composed of two main set of components. The “core modules,” which are implemented in C language, is developed to support any C‐like sensor platform with any or little need for modifications. Underneath the core, a set of “platform‐specific modules” are properly defined as adaptors for allowing the core to interact with the operating system services and resources (sensors, timers, communication, etc.). Different adaptors interface with specific sensor platforms and software environments, such as TinyOS [2] and Z‐Stack [3] (the ZigBee‐compliant implementation provided by Texas Instruments). The benefit of such an architecture is that a developer needs to implement just the necessary adaptation modules in order to deploy the platform‐independent components and the applications onto new sensor platforms.
• Extensibility and customization: thanks to the task‐oriented approach, it is possible to easily add new functionality when the need arises. This is done by defining a new task implementing a user‐defined computing logic without having to change the underlying runtime environment. New drivers for sensors or actuators can also be added by simply developing proper adaptation modules.
• Modularity: the node‐side middleware architecture, described in Section 4.6, includes independent modules interacting through well‐defined interfaces, with the benefit of easier software maintenance and upgrade processes.

4.5 Task‐Oriented Programming in SPINE2

The task‐oriented programming paradigm provided by SPINE2 is specifically conceived to support the creation of data‐flow‐based task chains for defining distributed signal‐processing applications. Less error‐prone with respect to explicitly coding a low‐level code, this approach is more intuitive as the user, according to the application requirements, has to specify a set of interconnected tasks made available from a task library. Thus, the basic abstract components constituting the high‐level application model are tasks and task‐connections.

A task represents a specific activity or operation, e.g. a signal‐processing function, a data transmission, or a sensor querying. Tasks are executed in an atomic way with respect to other tasks, whereas they can be interrupted by triggered events. In fact, the event‐reactive nature of the sensor nodes implies the need for a fast response to asynchronous events like a radio message reception or a timer expiration. Tasks are connected by means of task‐connection representing temporal and data dependency between tasks.

In Figure 4.2, a typical (in this case rather simple) sensor data‐processing application is shown. It basically consists of three phases: (i) gathering the sensor readings, (ii) executing processing functions on the sensed data, and (iii) sending results to other nodes of the network or to the coordinator for further elaboration.

In order to achieve load‐balancing of resources and an efficient communication, SPINE2 allows to allocate specific subset of tasks to different nodes, thus realizing a full distributed data processing over the network. Since the nodes may have different features and capabilities, it is possible, for instance, to allocate the most computational‐intensive tasks to more powerful nodes in the network. Thus, the implemented task‐based paradigm gives developers full control over data feed, control flows, and event scheduling for performance‐balancing on multiple dimensions (e.g. CPU, memory, and energy). Moreover, composing an application by means of basic functional blocks with well‐specified inter‐task interface allows an easy and rapid application reconfiguration and a simpler maintenance process. The library of reusable tasks includes two main types of tasks:

• Functional tasks: perform data processing/manipulation or execution control.
• Data‐routing tasks: provide data forwarding or replication.

Each task is defined as a triple of attributes: Input, Output, and Parameters. Depending on the specific functionality for which a task has been defined and implemented, the user can configure it by means of a set of pairs (parameter and value). Also, there may be zero to multiple (usually in data‐routing tasks) input or output connections. Each connection can handle a particular sensed data, processed information, or even an empty data, intended to be used as a simple “execution complete notification” for the connected task.

The main tasks constituting the currently available library are the following:

• TimingTask: defines timer expiration and can be adopted for timing other tasks. It has no input connection and does not have to process any data. It signals a notification through its output when its inner timer expires depending on the following parameters: the periodicity (i.e. specifies if it is a periodic timing or a one‐shot expiration), the period of expiration, and the corresponding time scale/unit.
• SensingTask: performs a reading from a particular onboard physical sensor. It encloses an inner timer for scheduling the sensing operation. The data output depends on the specific type of sensor it is configured to read data from. Specifically, it can consist of a simple scalar reading value (e.g. when linked to the luminosity sensor) or a vector of samples each coming from a specific “sensor channel” (e.g. a triaxial accelerometer provides three different samples).
• ProcessingTask: provides the actual computing capabilities by performing functions or algorithms to process data. Some set of functions are called “feature extractors,” which are usually applied to temporal data series. Some examples are mean, variance, max, and min.
• TransmissionTask: is in charge of explicitly transmitting data coming from other connected tasks to a specific destination node/device. It is usually used for sending in‐network preprocessed data to the coordinator of the BSN. In the case of interconnected tasks deployed on different nodes, the SPINE2 middleware performs proper data transmission (encapsulated in proper messages) without the need of a TransmissionTask.
• StoringTask and LoadingTask: perform data (stream) storage and retrieval by using the onboard flash memory, if available on the platform.
• SplitTask: duplicates incoming data from its input connection to all its output connections, so as to make it available to multiple tasks.
• MergeTask: merges incoming data from its input connections and feeds its single output connection; it first normalizes and/or uniformly formats the collected data.
• HistoricalMergeTask: performs a number (specified by a parameter) of sequential merge operations over the time and makes the collected data available to the output.

4.6 SPINE2 Node‐Side Middleware

The main purpose of the middleware running on the nodes of a SPINE2 sensor network is to “interpret” and “execute” the high‐level application defined through the task‐oriented paradigm. Figure 4.3 depicts its modular architecture composed of a set of modules, each including interacting (but independent) software components intended to accomplish well‐defined operations.

The core framework of SPINE2 (see also Figure 4.1) is made up of all the components in white blocks of Figure 4.3. Implemented in ANSI C language, they can be compiled in any “C‐like” development environment with no changes in their inner code. The core encloses all the unchangeable parts of the middleware implementing the main runtime task execution logic, including task and memory management, application‐level message handling, and abstract access to onboard sensors and actuators. By contrast, the grey blocks are the architecture‐dependent part of the middleware and are tailored for a specific sensor platform in order to manage the lower level mechanisms and services. Some adaptation components (or drivers) bridge the core with the platform by granting access to the physical resources through well‐defined interfaces.

The use of a common programming language, and its standard libraries, along with a strong software decoupling between the core and the platform‐related components are the key characteristics for the very high portability of the SPINE2 middleware.

A more specific description of the modules shown in Figure 4.3 is provided below.

• SPINE2Manager: is the central component of the architecture. Its main functionalities include (i) system initializing at startup, (ii) orchestrating the modules managing the node resources (sensors, actuators, radio, and flash memory), (iii) dispatching the necessary commands to the other components to accomplish required operations (e.g. a new task creation or a buffer allocation), and (iv) handling the SPINE2 application‐level protocol (see Section 4.7) for communication with the coordinator and the other nodes, which includes formatting of the SPINE2 outgoing messages before its encapsulation into a low‐level packet by the Comm Module.
• Comm Module: provides the basic services for exchanging messages with the other sensor nodes and the BSN coordinator. It encapsulates the application‐level messages into packets and performs the reverse operation, by also handling the (de)fragmentation operations when required, depending on the message length and on the maximum payload supported by the platform‐specific communication protocol (see Section 4.7).
• Task Module: is the middleware “task execution engine” in charge of (i) instantiating the tasks allocated on the node by the coordinator, (ii) scheduling, and (iii) terminating their executing based on the inter‐task connections.
• Memory Module: handles the memory space by allocating the task‐based application definitions as well as the buffers required both for the inter‐task data exchange and for the tasks’ inner operations (the user application may require a variable number of buffers each of which having an arbitrary size). It implements an ad‐hoc solution for allowing dynamic memory allocation and thus providing other components with a simple interface for allocating memory blocks on demand at runtime.
• Timer Module: manages the dynamic allocation of timers requested by other components. The allocation is based on a publish/subscribe mechanism: when a SPINE2 component (the subscriber, e.g. the Sensor Manager) needs a timer for its own purposes, it makes a request to the Timer Manager (the publisher), which in turns provides a timer’s identification code to the subscriber to be able to properly schedule it.
• Sensing Module: provides a common interface for accessing the physical sensors equipping the sensor node. Each sensor‐specific driver has to be compliant to the common Sensing Module interface.
• Actuating Module: similar to the Sensing Module, it provides a common access point to the available actuators installed on a sensor node.
• Flash Module: handles storing and loading of data to and from the flash memory, if made available by the sensor platform.

4.7 SPINE2 Coordinator

A set of software components, the SPINE2 Coordinator, which comes with a proper API, have been developed for running on the coordinator side and conceived to provide a simple software interface to the developer to be able to effectively manage a task‐based application over a sensor network.

In particular, on top of an intuitive API, the programmer can develop their own application for (i) controlling the remote nodes of a BSN and getting the high‐level event notifications issued by the nodes, (ii) defining, deploying, and running the task‐based application, and (iii) collecting the in‐network processed data for further off‐line analysis.

To favor portability, Java has been adopted to implement the SPINE2 Coordinator software architecture. It is worth noting that a specific set of components have been implemented to support some platform‐dependent base stations. These are particular devices (a sensor node or a dongle) that need to be connected to the Coordinator in order to properly get access to the common IEEE 802.15.4 wireless communication interface and be able to communicate with the sensor nodes.

4.8 SPINE2 Communication Protocol

A two‐layer communication stack (see Figure 4.4a) has been defined in SPINE2 for handling the communication between sensor nodes and the coordinator and is built atop the platform‐specific protocol supporting the available onboard radio. The layer in the middle (Packet Layer) provides a point‐to‐point communication interface, by also managing the fragmentation of the long application‐level messages (split into multiple packets’ payload) coming from the upper layer. In particular, the fields constituting the SPINE2 packet are depicted in Figure 4.4b.

The upper layer is defined to handle a set of SPINE2 messages, which encapsulate the application‐level commands and information for interacting with the BSN and more specifically with the deployed task‐oriented application.

The currently supported application‐level messages are summarized in Table 4.1 along with some additional information about the communication direction and the carried payload. The Init Application, Start Application, and Reset Application Messages, which have no additional payload data, are adopted for controlling the execution of the task‐based application once correctly deployed.

The Discovery Nodes initiates the communication scheme between the coordinator and the BSN in order to get general information from the nodes (through the Node Advertisement message), like the sensor platform, the available onboard sensors, and the list of supported tasks. Once the Discovery/Advertisement phase has terminated, the user can complete modeling the application, which is then deployed by mapping the task‐graph throughout the network. The Create Task Message is issued to instantiate each single task on the intended node. Similarly, the Create Connections message is sent to create a connection or a set of connections between tasks. It therefore includes information related to the destination task of a specific connection since a task may be either local (i.e. instantiated on the same node) or remote. It also includes information for allocating the needed buffers on the node. Once the application has been deployed, the coordinator can broadcast the Init Application to initialize the tasks instantiated over the network, after which every node communicates that it is ready to run (part of) the application by sending a Node Application Ready. The Start Application Message can now be broadcast, causing the application to run. The Sensor Data message is for forwarding data (either raw or preprocessed) from a node to the coordinator, whereas the Sensor to Sensor Data message is for data that needs to be exchanged between remote tasks. The Error and Status Info messages are issued in case of unexpected errors at runtime (e.g. no further block can be allocated in the dynamic memory) or for periodic node status advertisement (e.g. for communicating the remaining battery charge).

4.9 Developing Application in SPINE2

A typical interaction between the SPINE2 environment and the Java‐based user‐defined applications is depicted in Figure 4.5. It is worth noting that a SPINE2 Console is made available along with the SPINE2 Coordinator component. Specifically, it comes with a simple GUI that allows a user to immediately interact with the BSN and define the task‐based application without having to implement an application atop the SPINE2 API.

As a consequence of the presence of such GUI, a developer can actually interface his own applications to the SPINE2 environment in two different ways.

As a first example, since the SPINE2 Console can be adopted for managing both the BSN and defining the task‐based application, the Java‐based Application 1 needs just to register to the Console in order to get notified of messages coming from the network, thus needing only to code the logic for collecting information and data useful for off‐line analysis and displaying.

By contrast, Application 2 directly makes use of the SPINE2 API and takes care of both managing the BSN and the task‐based application, thus requiring a greater effort by the developer.

4.10 Summary

This chapter has presented the SPINE2 programming framework, an easy‐to‐use solution for rapidly and effectively developing distributed application on BSNs. We have first provided motivations for needing different programming abstractions, by explaining why the well‐known task‐based paradigm is able to successfully meet the desired requirements of the BSN domains. Then, an overview of the main features of SPINE2 has been presented, along with a description of the supported task‐oriented programming approach and related benefits: rapid prototyping and easy runtime reconfiguration of highly customizable and flexible distributed signal‐processing applications. Furthermore, its software architecture has been described by highlighting the benefits in having a platform‐independent node‐side middleware in terms of quick portability and extensibility.