An Interactive, Source-Centric, Open Testbed for Developing and Profiling Wireless Sensor Systems

Andrew R. Dalton, Jason O. Hallstrom
2009 International Journal of Distributed Sensor Networks  
The difficulty of developing wireless sensor systems is widely recognized. Problems associated with testing, debugging, and profiling are key contributing factors. While network simulators have proven useful, they are unable to capture the subtleties of underlying hardware, nor the dynamics of wireless signal propagation and interference; and physical experimentation remains a necessity. To this end, developers increasingly rely on shared deployments exposed for physical experimentation. Sensor
more » ... network testbeds are under development across the world. We present a complementary testbed architecture that derives its novelty from three characteristics. First, the system is interactive; users can profile source and network level components across a network in real time, as well as inject transient state faults and external network traffic. Second, the system is source-centric; it enables automated source code analysis, instrumentation, and compilation. Finally, the design is open; developers can extend the set of exposed inter faces as appropriate to particular projects without modifying the underlying middleware. We present the testbed design and implementation, a graphical user interface, a shell-based macro programming interface, example scenarios that illustrate their use, and discuss the testbed's application in the research and teaching activities at client institutions. Finally, by open, we refer to a design that enables developers to extend the set of interfaces used to access the testbed without modifying or even restarting the underlying middleware. Developers may choose to use the default graphical user interface, the default shell scripting interface, or a custom interface appropriate to a particular system or experimentation task. We refer to the testbed architecture as the "NESTbed," for "Network Embedded Sensor Testbed." While much of the design is platform independent, the current implementation targets applications developed using nesC [24] and TinyOS [30, 59] . We take this platform to represent the state-of-the-art in sensor network platforms, and the evolving de facto standard. Novelty. A number of testbeds have been discussed in the literature, including architectures tailored for 802.11 networks [72, 16, 34, 47, 44, 68, 7] , and more recently, wireless sensor networks [21, 61, 28, 67, 33, 64] . While a detailed discussion of related work appears in Section 6, it is useful at this point, given the number of related systems, to preview the points of novelty in our work. In short, the novelty lies in the three distinguishing characteristics of the supporting middleware: interactive, source-centric, and open. Interactive. Existing sensor testbeds are largely batch-based; they provide few features for real-time debugging and experimentation. They do not, for instance, provide integrated support for real-time network and source-level profiling (without a priori knowledge of the elements to be profiled), nor do they support source-level fault injection. This lack of execution accessibility reduces developer productivity, and limits possible evaluation scenarios, including those designed for assessing state related fault tolerance properties. Source-centric. Existing sensor testbeds are image-based; developers are required to upload precompiled applications that include requisite testbed management components integrated by the developer. Consequently, existing designs preclude automated sourcelevel analyses, instrumentation services, and build processes. This imposes a burden on developers responsible for testbed specific component integration, reduces the level of implementation detail exposed by the testbed, and limits the efficacy of software configuration testing to evaluate the program variants. Open. Existing sensor testbeds are principally realized as web based systems that expose their services through standard forms pages. This approach prevents client institutions from extending testbed functionality without modifying the shared server installation. Remote developers are unable, for instance, to construct specialized testbed driver components, or interfaces tailored to particular experimentation tasks or applications.
doi:10.1080/15501320701863403 fatcat:ejvdzce2h5eb7afeldoteitbly