Tagus-SensorNet Integration

Project Details

Goal: The Tagus-SensorNet Platform has always strived to provide an integrated experience, allowing multiple applications to peacefully co-exist within the network. This has been done through the use of shared libraries, both in the sensor nodes and on the computer. While this approach does constitute a great improvement over the traditional, single-application model commonly found in WSNs, it has also brought a distinct application-orientation to the network's use. This project aims to break this barrier by building a new framework, within Tagus-SensorNet, that enables a truly integrated experience.

While the severe resource limitations found on the sensor nodes may easily justify the need to limit each node's functionality to a single application and the shared libraries, this is not the case on the computer. Furthermore, the capabilities of the TinyOS Deluge system should be further explored to promote the use of multiple applications, in a more dynamic way, within the network. As such, this project has the following goals:

  1. Isolate functionality that has been embedded within single applications but that, by nature, should be shared among all applications (e.g transmission power, fixed routing, LPL duty cycle, configuration management, etc.) and develop a new shared library that should be included in all sensor nodes.
  2. Put all of the Tagus-SensorNet shared functionality into a single component for easy inclusion in current and future applications.
  3. Redesign the Tagus-SensorNet centralized graphical management console to provide a more integrated, less application-centric, interface.
  4. Develop a new shared library that uses Deluge, enabling over-the-air programming and allowing the user to choose, in run-time, which application runs at each node.

Project Context

In the last few years, WSNs (wireless sensor networks have enjoyed a widespread evolution, and have been subject of lots of research and work. However, the WSN paradigm is still totally application aware. This means that one application is entirely developed in order to run in one specific sensor network, thus, the applications are not portable among different networks. Tagus SensorNet aims to be a paradigm shift, where one single network has different applications deployed, each one of them running in a different sub-network. Despite its capabilities, the integrated experience provided from the Tagus SensorNet platform is far from optimal, since its functionalities (even the shared ones) are embedded in the different applications. Furthermore, in order to provide a more dynamic applicational environment, and to increase the testbed flexibility, there’s the need to provide over the air programming , to dynamically change the application being run at each node.

Goals & Problem Description

The abstract goal of this WSN project is to break the current programming paradigm used in sensor networks, in which one network gives the answers to one specific question, and an application is built to one specific end. This is the true nature of the problem. Whenever a programmer has to start a new application, despite the fact that TinyOS development is highly modular, there is not much he can reuse from past projects, since the code written was application aware. The problem gets bigger if this new application should somehow work collaboratively with other applications previously developed. These aspects justified the need for this project, in which the main goal is to develop a shared library which enables different applications to work in the same testbed, while easing future application development. The specific project goals are the following (their order of development was as presented):

  1. Isolate functionality that has been embedded within single applications but that, by nature, should be shared among all applications (e.g transmission power, fixed routing, LPL duty cycle, configuration management, debug status, etc.) and develop a new shared library that should be included in all sensor nodes.
  2. Put all of the Tagus-SensorNet shared functionality into a single component for easy inclusion in current and future applications.
  3. Redesign the Tagus-SensorNet centralized graphical management console to provide a more integrated, less application-centric, interface.
  4. Develop a new shared library that uses Deluge, enabling over-the-air programming and allowing the user to choose, in run-time, which application runs at each node.

Architecture

In order to provide the user with a more integrated experience, there was the need to redesign the existing application, to extract these functionalities which were embedded within single applications.

  1. Configuration Manager: only handles shared functionality (Tx Power, Duty Cycle,debug period, multi-hop routes) used by all nodes in Tagus SensorNet. Also allows the user to choose dynamically which application runs at a chosen node.
  2. Duty Cycle Manager: configures the duty cycle of the mote’s radio; configures the sleep interval of the receiving node for each sent message.
  3. Transmission Power Manager: provides a Send interface which configures the respective transmission power for each sent packet.
  4. Multi-Hop Fixed route configuration Manager: provides fixed multi-hop routes by specifying the next hop for a given node.
  5. Debug system Manager: indicates the periodicity of the debug messages sent.

All of these components are included in the GeneralConfigurationsManagerC, in order to be easily included in future application development. It is noteworthy to state that if the GeneralConfigurationsManagerC component is not declared (the programmer only wants to use one – or any combination of the managers – it is possible, but it is also imperative that the ConfigurationManager component is used, since it is through it that each independent manager accesses the node’s internal state and manipulates it).

The Configuration Manager is the component responsible for manipulating the node’s internal state at any time. This basically means that without this configuration manager, nothing works. This configuration manager manipulates the node’s internal state, and sends messages in a unicast way to the specific node being configured. This way, it is possible to configure each node independently. Upon this message reception, the configuration manager signals all the components using its data that a new configuration was received, so they can adjust, if necessary, their respective parameters.

The relationships among these different components are depicted below.

TSN-CommonLib.jpg: 532x285, 15k (October 15, 2009, at 05:04 PM)
Configuration Manager architecture

Environmental Interaction Application Specific Configurations This application heavily relies on its own specific configurations, since it is possible, at run-time, using the GUI supplied with the project, to specify which sensors are read, which aggregation functions are used, upon which data and what to do with the data gathered – trigger some event, p.e. For this reason, there is the need to use a specific configuration manager for this application, called Environmental Interaction Application Configuration Manager. Like the former configuration manager, this manager is responsible for accessing and manipulating a part of the node’s internal state – the application specific part. In this case, it is which sensor(s) to read, which aggregation rules for received data are used and if they will trigger some acting device based on a supplied condition.

Likewise, this manager also allows for a user to configure each node independently, since the messages with the node’s state are also sent using unicast message delivery.

On the picture below it’s possible to see the relationships among the Configurations Manager and the Environmental Interaction Application Configurations Manager, as well as their corresponding relationship with the internal state of the node.

TSN-EnvInter.jpg: 697x370, 23k (October 15, 2009, at 05:04 PM)
Environmental Interaction Application architecture

As stated in this topic, the EnvironmentalInteractionConfigManager is the component who manages the Environmental Interaction specific application logic, thus having to configure which sensors are read, which aggregation functions are used and which trigger functions, operator and thresholds will be actuated upon.

In the same way, the ConfigManager depicted above is responsible for managing common applications configurations, like transmission power and duty cycle, p.e.

VibSense Application Specific Configurations

Since this application had a major discrepancy to the Environmental Interaction Application, and that application was used as a model to build the Configuration Manager, on this specific application it wasn’t built a specific configuration manager, so the application aware configuration system is the same as before.

In the picture below there is a diagram showing the relationships among the Configuration Manager and the regular application logic, as well as their corresponding relationship with the internal state of the node.

TSN-Vibsense.jpg: 544x263, 20k (October 15, 2009, at 05:04 PM)
VibSense Application architecture

Implementation

Configuration Manager Probably the most important component developed throughout the Tagus SensorNet integration project is the Configuration Manager. It provides the programmer control over one simple but paramount service – bit delivery – among nodes, since it configures how those bits are delivered (static routes, sent packets transmission power, debug information on the nodes, etc). It has version control, so each node can understand if the configuration it currently has is the same being received or even if the configuration it has is more recent than the one received. If so, the configuration is discarded.

It also has reception acknowledge, so there can be a certainty that the node is correctly configured. It is also through this functionality that the routes are kept “alive”.

The ConfigManager provides two interfaces:

  1. ConfigManager: which grants the other managers access to the node’s internal state (get/set and what to do when a new configuration is received)
  2. Init: this interface is used when the node is booting up, and is responsible for initiating the node’s internal state variables

In order to develop this configuration manager, a new message type had to be defined, as well as an AM type – sort of a channel abstraction – to multiplex data to the respective application. A new Java application had to be developed, as well as a new application independent configuration panel so the user could configure the application independent configurations. In the image below shows the interfaces used and provided by the configuration manager.

TSN-ConfigManager.png: 1171x540, 58k (October 15, 2009, at 04:46 PM)
Configuration Manager NesDoc

Transmisson Power Manager Transmission power management in TinyOS 2.1 is done for each sent packet. Because of this, the best way to do was to develop a component that uses and provides the send interface. When instantiated, this component receives the AM type for the messages it configures the transmission power, so they can be later multiplexed to the respective applications. The next image helps to understand this concept, since it shows the interfaces provided and used, as well as the components used to provide those interfaces.

TSN-TxPowerManager.png: 998x539, 40k (October 15, 2009, at 04:48 PM)
Transmission Power Manager NesDoc

Debug System The debug system developed was based on the one presented on Environmental Interaction. What it does is basically to use the configManager interface provided by the ConfigManager component to read the debugPeriod variable. If it is greater than zero, a timer is configured and when it "fires" the light and temperature - as well as the battery level - are read and sent to the sink. If the debug value is greater than zero, the leds be used, if not, they will never light up.

This explanation can be easily seen in the picture below.

TSN-DebugManager.png: 999x539, 60k (October 15, 2009, at 04:47 PM)
Debug Manager NesDoc

Duty Cycle Manager The Duty Cycle Manager operates in a similar way to Transmission Power Manager. It uses the ConfigManager interface to access the node’s configuration and get the current duty cycle, and then uses the LowPowerListening interface to configure the node’s local sleep interval and the SendNotifier interface to specify the receiving node sleep interval. These relationships are depicted below.

TSN-dutyCyclingManager.png: 562x426, 34k (October 15, 2009, at 04:48 PM)
Duty Cycle Manager NesDoc

Tests & Results

The following image proves that the shared library developed works well, by showing both applications being run at the same time, while using the debug option on the configuration manager panel (this debug option was initially only existent on Environmental Interaction).

TSN-functional2.png: 1280x800, 81k (October 15, 2009, at 05:49 PM)
The new Java GUI

As can be seen in the picture above, nodes 3 and 4 are running the Vibsense application while running debug mode. This information is forwarded towards the sink through a node running the Environmental Interaction application (nodes 1 and 2 have it installed). While the debug information from both Vibsense nodes are being routed through node 1, this same node is also measuring light, as can be seen in the Environmental Interaction Application panel.

In the next image, it can be seen both Environmental Interaction nodes (10 drawing a sine & 11 measuring light) working at the same time, while node 21 is measuring vibrations. It can also be seen in the "General Configurations Manager" panel that node 21 route to the sink passes by node 10, which proves that both applications are integrated on the TSN.

TSN-functional.png: 1280x800, 90k (October 15, 2009, at 05:48 PM)
Proof of concept

Objectives not met

During this project development, one of the objectives could not be completed due to lack of time and extreme complexity. This objective was to develop a new shared library using Deluge to provide over the air programming. This objective was very important since it is through it that the user could specify, at run time, which application is run at each node. The problem itself is due to the fact that the MicaZ motes (the mote type used in this project and in the whole Tagus SensorNet) use a different flash chip then the Telosb motes (Deluge developers use these motes). This generates a bug while translating the program slot to the actual flash address, and when the mote reboots, instead of booting to the intended program slot, it boots to the image that was being run.

Conclusions

The solution described in the past sections of this report, despite not meeting all the goals, still is a great improvement over the original Tagus SensorNet. Over the air programming is not available because it couldn’t be developed, and this factor has great impact on the overall flexibility of the system, since it does not meet its full potential. The shared library is of great importance since it helps in future application development, providing application independent bit delivery that meets the configurations provided by the application user. A new Java application has been also developed to provide the user a centralized graphical management console with a less application centric interface. This application requires the nodes to have the described shared library.

Project Related Files

  • Project Report (.pdf)
  • Project Presentation (.pptx)
  • How to integrate an application into TSN? (.txt)