Overview

The center’s systems research group strives to advance the state of the art in large-scale observing systems. To this end, our research efforts have focused on two critical areas: the design and evaluation of architectures and programming systems, and the development of practical tools and platforms. Together, these two research directions are increasingly giving rise to sophisticated, rapidly reconfigurable, multi-user observing systems that support advanced sensing modalities.

Architecture and Programming Systems: Taking a sensing system that works in a small-scale lab setting out into the real world may seem like a simple step involving “packaging”. But we have repeatedly found the opposite. The effort required to deploy a long-running reliable ENS observing system is currently perhaps an order of magnitude greater than that needed to write the application itself.  Our ongoing research is changing this relationship by (1) re-architecting ENS software to ensure the development of manageable software, (2) integrating security into every aspect of the system, and (3) incorporating visibility into the deployed system to create more nimble observing systems.

For instance, our Tenet project re-imagines the architectural foundations of the wireless sensing systems. Researchers originally envisioned large, flat, networks of tiny wireless nodes (the motes) that collaboratively process data in application-specific ways. We have found that, in practice, the unexpectedly high complexity of mote-based multi-node data fusion makes the resulting software fragile and hard to debug. With Tenet, we capitalize on the fact that every system we deploy has masters: 32-bit CPU-class nodes for which power can be engineered. Tenet focuses multi-node fusion functionality on these less constrained nodes. This has three advantages: (1) a single system layer has simpler software and can be used to implement different applications; (2) application specific development is simpler because it occurs on the masters; and (3) applications can be designed to optimize and adapt their behavior based on dynamic system-wide state because masters have visibility over the entire network. The project has made considerable progress in the past year, having fleshed out the details of the system design, built a complete prototype, deployed a Tenet system for obtaining structural vibration data from the Vincent Thomas Bridge in San Pedro (see figure), ported the Centroute protocol from Emstar, and made a release of Tenet v1.0.

Existing programming systems and tools for observing systems are primitive. Today, programmers write the equivalent of assembler code to implement sensing applications and go through a labor-intensive design-debug-deploy cycle. There is a pressing need for more sophisticated tools, such as Tenet, as well as higher-level programming abstractions that can help reduce the development cycle and improve system efficiency and reliability.

Our work on staged checkers is an example of the kind of programming support that can improve application development. Writing reliable software for ENS systems is particularly difficult because software is distributed, timing-sensitive, event-driven, and closely coupled to hardware. To detect and eliminate these errors before they manifest in a running system, we need techniques to analyze ENS software itself.  Staged checking uses a sequence of checks that rely on increasing scope and knowledge and act on the code at compile, load, and run times.  The Lighthouse staged checker has two stages: the first stage enforces a memory ownership protocol, and the second stage ensures that a program’s execution conforms to a user-defined finite-state machine. Our checker detected 10 previously unknown errors in the SOS kernel and its user programs.

Another tool that can shorten the design-debug-deploy cycle considerably is a network simulator. Avrora simulates a network of motes with high fidelity so that an application developer can test their software on the desktop before deploying it in the real world. Unique to Avrora is the ability to support dynamically updatable code; simulation of which can help avoid nasty surprises during deployment. Also unique is the ability to profile application code at arbitrary code locations, a feature that can help explain performance bottlenecks in the system. Avrora has quickly become a critical tool, having helped streamline SOS and inform the design of a new object-oriented language, Virgil, tailored for memory-constrained microprocessor systems. Also, we recently integrated Avrora with Emstar.

Finally, we are investigating a novel programming model for ENS applications called Kairos. In a significant departure from current practice, Kairos allows a programmer to program an entire network of sensors as a single entity, an approach called macroprogramming. The Kairos programming model specifies the global behavior of a distributed ENS computation using a centralized approach to ENS programming. Kairos presents an abstraction of an ENS system as a collection of nodes that can all be tasked together simultaneously within a single program.  Using a small number of language constructs, programmers implicitly express both distributed data flow and distributed control flow. The Kairos compiler and run-time system then execute the application in a distributed manner on the ENS system. The Kairos compiler includes a novel program partitioning technique that uses program analysis to determine segments of code that can be executed as a unit at any network node; the Kairos runtime system then dynamically migrates control-flow to the node with the lowest segment execution cost. Moreover, the Kairos compiler supports a distributed locking protocol that ensures predictable program execution.

Tools and Platforms for Observing Systems: A second systems research thrust is the development of mature tools and platforms for deployments of observing systems. Our earliest efforts in this area focused on the general Emstar development platform. During this past year we made significant progress in maturing specific Emstar-based platforms for both acoustic and seismic monitoring. For example, we hardened the (1) acoustic localization and disruption-tolerant shell tools, (2) development and use of the LEAP platform, and (3) initial design plans for Geonet—a rapidly deployable aftershock monitoring network. Later, we discuss additional platform development to support Multiscale Actuated Sensing systems.

We used Emstar extensively to develop the Acoustic ENSbox, a sensing system featuring highly accurate source localization. This year our researchers hardened the software for extended field deployments. The ENSbox system is now robust enough for scientists to perform biological observations. In one test, the acoustic array localized marmots at the Rocky Mountain Biological Laboratory in real time to within 1 meter.

The Mesoamerican Subduction Experiment (MASE) broadband seismic array consists of 100 seismic stations stretching 500 KM from Acapulco to Tampico via Mexico city. This network, which is necessarily without infrastructure, consists of many long-haul wireless links strung together in a chain, and it is nearly impossible to obtain consistent end-to-end connectivity. To enable network communication and system management in this challenging environment, we developed the disruption-tolerant shell (DTS), which is a remote management facility designed to manage large numbers of nodes connected in this way. It makes this management problem tractable by ensuring exactly one execution of a series of commands and by providing centralized collections of responses, given a range of disconnected and poorly connected networks. Our tests show that DTS executes 100% of scripts, an essential requirement for our MASE experiment.

A broad range of embedded networked sensing systems for environmental monitoring require complex, high-peak-power-dissipating sensor devices, on-demand high performance computing, and high bandwidth communication.  Embedded computing demands for these new platforms include support for computationally intensive image and signal processing, optimization, and statistical computing. To meet these new requirements while still maintaining support for low-energy operation, we developed a new multiprocessor node hardware and software architecture, Low Power Energy Aware Processing (LEAP). LEAP integrates fine-grained energy dissipation monitoring and sophisticated power control scheduling for all subsystems, including sensor subsystems (see diagram). This year, we developed a profiling application for LEAP and ported TinyOS to the LEAP MSP co-processor. The latter development will enable innovative configurations in which the LEAP node is used as a low-power sensor device with an on-demand high-powered co-processor. The Geonet systems referred to above will be based on the LEAP platform.