Overview

Current sensor networks commonly share two characteristics: the use of mote-class sensor platforms with their inherent computational and communications constraints; and, heterogeneous deployments consisting of both mote-class and microserver-class component systems. Both characteristics make designing, developing, debugging, deploying, and maintaining sensor networks a difficult problem. Emstar is a comprehensive and extensible development platform in the Linux environment that greatly reduces the costs and challenges of sensor network development. Emstar provides a complete mote-class simulation environment (EmTOS); it supports emulation of selected components, including radios; it allows for full native deployment; it provides visualization features (EmView); it provides a robust monitoring and restart facility at a software component level (EmRun).

Approach

We have developed EmStar, a new Linux-based software framework that addresses the difficulties in creating robust software in the sensor network domain. Broadly speaking, its contributions fall into two areas. First, EmStar's execution environments address the problem of visibility into an in-situ system. EmStar provides a spectrum of run-time platforms---a pure simulation, a true distributed deployment, and two hybrid modes that combine simulation with real wireless communication and sensors in the environment. Each of these modes run the same code and use the same configuration files, allowing developers to seamlessly iterate between the convenience of simulation and the reality afforded by physically situated devices

Second, EmStar's programming model aims to promote software reusability while being more flexible than a strictly layered stack. EmStar's modules may be flexibly interconnected using standardized interfaces; connections can be a flow of packets, stream data, state updates, or configuration commands. Our model also lets applications' domain knowledge affect modules that are common across applications, without making application-specific changes to those modules.

Third, EmStar’s programming model aims to be inclusive. Unlike systems such as TinyOS that are tightly coupled with a specific language, EmStar does not restrict users to use certain specific languages. In fact, in some cases whole legacy binaries can be used unchanged. This is advantageous from a perspective of rapid development and integration. However, more integrated code has numerous advantages, because it can leverage many features of EmStar that make it well-tuned to building Sensor Network applications. One of the languages that can be used to write EmStar modules is NesC/TinyOS. Using a wrapper library called EmTOS, a TinyOS application can be run as a single module within EmStar.

Systems/Experiments

Our first EmStar execution environment, emsim, is a pure simulation mode. n identical copies of a sensor node’s software stack run centrally on a single machine. Models of the communication and sensor channels define (for example) the effective range of each packet and the input of sensors. As in reality, instances of the stack can not share state directly; they are forced to communicate with each other via the simulated communication channel. Emsim allows software to be developed and debugged with the convenience of simulation.

EmStar also supports several execution environments that run all the code on a central server, making debugging easy, but use real channels for sensing and communications. We have created two permanent testbeds that can be used in this way. The first is a permanently mounted uniform array of 54 Mica1 motes on the ceiling of our lab. The motes are all wired for power and have a serial-port connection back to a central simulation machine. The second is a permanently mounted array of 40 Mica2 motes, stretched across a 200m by 10m L-shaped area. Because of the longer range of the Mica2 radio, the testbed must be physically larger in order to achieve multi-hop topologies. The Mica2 testbed also supports remote reprogramming, enabling the Mote software to be more readily upgraded. This second testbed also includes a dozen Stargate microservers to enable rich heterogeneous topologies of motes and microservers.

Figure 1: One leg of the Mica2 testbed, as shown by the EmView component of Emstar.

In emulation mode, each mote is programmed to be a wireless transceiver and sensor interface board using the Transceiver application. emcee, like emsim, runs instances of each node’s stack centrally. However, no channel simulator is used; instead, each simulated node is mapped to one of the motes on the ceiling. When a node sends a packet, it is transmitted and received by real motes, through the real channel. This mode gives developers the convenience of simulation, while bringing real aspects of channel dynamics to bear.

Using the testbeds, it is also easy to emulate heterogeneous systems, such as the Extensible Sensing System (ESS). In ESS, the Microserver tasks a network of Motes and data flows back through the Mote network to be processed at the Microserver. Using the new Mica2 testbed, experiments can be performed in which emulated EmStar systems interact with networks of real “standalone” Motes. This is done by selectively reprogramming some of the testbed motes directly with the Mote application code, and having the remaining motes programmed with Transceiver. Using this configuration, the complete system can be run on the testbed, and debugging information can be drawn back from the Real Motes over serial and visualized. New capabilities of “HostMote” enable this by providing an interface on the Mote to emit debugging messages that are piped back, eventually reaching the visualizer.

Heterogeneous systems can also be emulated using EmTOS, a wrapper library that enables NesC/TinyOS code to run as an EmStar module. Using EmTOS, the Mote application can be run on the central server along with other emulated EmStar nodes, using Transceiver to send and receive radio traffic. This enables the Mote application to be debugged in a more friendly environment, while it is still a part of a complete heterogeneous system such as ESS. It is even possible to test “Hybrid” emulation modes, where some of the Motes in the system are real motes running the real application, and some of the Motes in the system are emulated Motes running inside EmTOS.

EmStar is now used as a deployment platform for real deployed systems. EmStar has been deployed as part of the ESS2 and NIMS deployments in the James Reserve. NIMS is developing a robotic system that rides on a wire high inside a tree canopy and takes measurements of the environment and the plants and animals living in the forest, and they are using EmStar as the software framework for the software running on the NIMS robot. The CENS Seismic Array project is also using EmStar as its framework. In addition, we are collaborating with researchers at Intel’s Portland research center to add new routing features and new Mote/Microserver integration features to EmStar. EmStar has also been used as a platform for student projects in an undergraduate class CS113, including several assignments we developed based on EmStar and TinyOS. It is also a key platform for EE206A and EE209 embedded systems courses.

Accomplishments

EmStar has matured from a single-lab tool to a broadly used development environment. It currently has over 100 active users spanning at least 14 universities, 10 companies, 6 countries, and 4 continents. This wide—and growing—adoption inevitably exercises the system to a greater degree than have it’s developers. Misfeatures (and their mitigations) are reported through an established users’ group mailing list; desired features are frequently discussed, and the user community is starting to contribute their own modules. One example of a completely redesigned and now robust module is TOSnic, a successor to our previous MoteNic, which in turn succeeded the original TinyOS Serial Forwarder.

As our user community has grown, both locally and abroad, we have realized the need to frequently revisit our documentation and tutorials, revising them regularly in response to comments (and frustrations) from our colleagues. We have implemented new code documentation tools and standards; we have produced new tutorials that cover specific needs expressed by our users (in particular, examples of simple programs doing common tasks); and, we have integrated classroom lecture materials and projects as key parts of our ‘getting started’ materials. We also presented a half-day tutorial on Emstar at the SECON 2005 conference.

Future Directions

We are continuing to ‘harden’ all Emstar components and add to the quality and quantity of our documentation. We are also looking at ways to reduce the current complexity of installing Emstar on a minimal Linux environment. We sought and have received an NSF CRI grant to further Emstar’s adoption within the sensor network community by taking the essential steps to truly establish Emstar as a community resource, and have hired and experienced Emstar developer (originally external to CENS) to lead this effort.

People

Graduate students: Lewis Girod, Ben Greenstein, Nithya Ramanathan, Tom Schoellhammer, Thanos Stathopoulos, Martin Lukac, Rahul Kapur, Vineet Agarwal, Andrew Parker.

Staff: John Hicks, Karen Weeks, Richard Guy.

Faculty: Deborah Estrin.