TOSServ

Background and Project Objective

The TOSSERV centralized TOSSIM service was developed in order to surmount the problems sustaining application development in the antiquated environment required to run TOSSIM. This environment is bound to using old versions of the msp430 cross compiler, and old versions of gcc and build-essential (3.x, which is only available in older versions of Linux such as the User Contributed XUbunTOS image). By moving the TOSSIM emulator/simulator onto a central server away from our application's client, our own application became platform independent while TOSSIM remains on the server in its own environment. This also allowed future versions of TOSSIM to be interoperable with our application and allowed for simulation to occur across a network when desired, instead of localized on one machine. While no new releases of TOSSIM were released during the development of TOSServ, it was expected that down the road there would be newer releases from within the tinyOS community.

Our release version of TOSServ is bound to the Policy IDE client we developed to interact with the Finger2 policy programming platform for micaz based boards. Finger2 is included with the TOSServ server package, and the Policy IDE provides an example client.

Development Products

- Centralized TOSSIM Service, which can be loaded with micaz compliant tinyOS binaries.

- Finger2 was moved to a central simulation server.

- Policy IDE became cross-platform and could be developed independently from Finger2.

- A multiplatform Policy IDE Client was created.

Architectural Overview

TOSSIM was already using a Java based backend (mig) for passing packets between external applications within the desktop computing environment into the simulated sensor network. This utility was leveraged via remote commands which were invoked on the TOSSIM side through a proxy. The origin of the commands, and the destination for the resultant feedback was our application client, which resided in a different process.

As a result, TOSServ could run on a remote client machine and be interacted with. The common protocol used between the client and server interaction was XML-based Remote Procedure Call. Since our application client was already using a Python based GUI, the backend for the GUI was simply reprogrammed to send procedure calls to the server. These procedure calls could invoke any of the TOSSIM simulator functions, as well as dump the contents of the debug log. The debug log collected the contents of the debugging messages from within the simulated sensor network in the same manner as the first-generation Policy IDE.

Conclusions and Future Work

TOSSIM works well to simulate wireless sensor networks, but does poorly to simulate the actual sensor mote hardware itself. During the course of development for both Policy IDE and TOSServ, it became obvious that there was a major limitation which prevented the widespread adoption of either product becoming possible; they cannot run on actual sensor hardware. Further, TOSSIM still had to run somewhere. This meant that although the Policy IDE client can work on any platform and interact with the central simulation server, the server itself had to run with the specialized environment that TOSSIM requires. To make things worse, TOSSIM was beginning to show its inability to support more complex and interoperable codebases, as it was only capable of supporting tinyOS binaries built for the micaz platform. Advanced networking stacks such as blip or COAP were incapable of running on this platform, and could not be compiled to work with TOSSIM since they required newer compiler versions. In addition, the TOSSIM system architecture was too tightly coupled with the provisions of the tinyOS version it was originally built for. Therefore, without a major overhaul, it was no longer practical to use TOSSIM. The main shortcoming of TOSSIM is that it needs to be improved to work on newer versions of the tinyOS tool chain, such as gcc-msp430 4.6.3. This tool chain was used to great effect in subsequent projects using the blip tinyOS 2.0 IPv6 stack. TOSSIM’s architecture could be upgraded, and its simulation features enhanced as well. In general, reducing TOSSIM’s reliance on coupling with the components in the nesC binaries would increase its interoperability with code developed for different wireless sensor network platforms. This will likely require a major rethinking of TOSSIM’s core architecture.