OVERVIEW

The use of local processing, hierarchical collaboration, and domain knowledge to convert data into increasingly distilled and high-level representations --or, data reduction -- is key to the energy efficiency of sensor networks.  In general, a perfect system will reduce as much data as possible as early as possible, rather than incur the energy expense of transmitting raw sensor values further along the path to the user.  For a system designer, there is an unfortunate paradox intrinsic to this ideal: the data that must be discarded to meet the energy and channel capacity constraints are necessary for the evaluation and debugging of the data reduction process itself.  How can a designer evaluate a system where, by definition, the information necessary for the evaluation is not available?

A second paradox arises in the structure of the software itself.  As in any software system, it is important to promote code reuse.  In sensor networks, the difficulty we described in evaluating a system's correctness makes it especially important to reuse algorithms that are known to be correct.  However, the communication efficiency required has made it difficult to construct a traditional strictly-layered network stack.

For example, routing is often influenced by higher layers, such as data aggregation, user queries, and time synchronization. Traditional abstractions such as TCP's end-to-end reliable and congestion-responsive streams, which have served Internet development so well, do not address the desire in sensor networks to encourage as much hop-by-hop processing of data as possible (e.g., aggregation and filtering).  How can we create reusable components, beyond basic device drivers, when application and domain knowledge seems to seep into every layer?

APPROACHes

We are developing 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 14 Mica2 motes, stretched across a 50m by 10m 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.

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 new testbed, 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.

Of course, the ceiling arrays represent only one particular channel, and is not representative of all channels.  Therefore, we also have built a portable array.  Software-wise, it is identical to ceiling array.  However, instead of using a server attached to motes permanently mounted on the ceiling, the portable array uses a laptop and “loose” battery-powered motes that can be placed anywhere.

By running applications on these three execution environments that have quantitative performance metrics, we can begin to understand the advantages and disadvantages of each – trading off convenience of simulation and the reality of the outdoor channels.

We have also begun to see EmStar be used as a deployment platform for real deployed systems.  EmStar has been deployed as part of the ESS 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.  Within this project, routing modules and new time synchronization systems are being developed.  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 this winter’s graduate class CS213, including several assignments we developed based on EmStar and TinyOS.

ACCOMPLISHMENTS

EmStar has been greatly expanded and improved over the past year.  We have made several minor releases and release 2.0 is scheduled for April 2004.  Numerous new features have been added over the last year:

• New device interface libraries have been developed:
  • The Sensor device library, for sensor drivers and signal processing modules.
  • The Query device library, for devices that need per-client stateful connections.
  • The Dictionary device library, for mappings of strings to small integers that are needed within a node, that can be shared among modules. 
• EmView, a visualization tool for EmStar systems, has been developed and has integrated the functionality of several independent stand-alone visualizers.  EmView can be used to visualize all modes of operation of EmStar, including simulation, emulation, real and hybrid emulation modes.
• EmTOS, a wrapper library for including NesC/TinyOS applications in EmStar systems
• Completely redesigned Link device interfaces, solving many flaws in the old interface.
• New documentation web tree.
• Vastly improved MoteNIC/HostMote, including changes required to add robustness.
• Ported FUSD to work on non-DevFS Linux systems, greatly reducing the effort required to start experimenting with EmStar.  In addition, patches have been developed to support Linux 2.6.

FUTURE DIRECTIONS

EmStar is growing in many directions.  We plan to continue improving the Sensor Device interface, replacing the older “audio server” interface with the Sensor device, and gaining some early experience writing DSP modules.  Through NIMS we hope to learn a great deal about how to support sensors and actuators in EmStar, and hopefully students on the NIMS project will begin adding useful modules that support mobility and other aspects unique to robotics.  Along with mobility, in the context of NIMS, we will be implementing sensor simulation and replay capabilities to EmSim, and we will be adding new visualization capabilities.  Through our support of ESS and continuing work on Multihop Over-Air Programming (MOAP), we hope to continue to debug the new EmTOS support.  Through ESS, NIMS and new work on the Seismic Array, we also anticipate working out many of the bugs that will crop up in deployment.  Through our collaboration with Intel/Portland, we hope to gain new users and new perspectives, as well as add the new routing functionality that is the current focus of their research.

PEOPLE

Faculty:

Prof. Deborah Estrin

Graduate Students:

Naim Busek
Alberto Cerpa
Deepak Ganesan
Lewis Girod
Ben Greenstein
Andrew Parker
Nithya Ramanathan
Tom Schoellhammer
Thanos Stathopoulos
Yan Yu

Staff:

Jeremy Elson