TinyOS applications are built with software components that communicate through narrow interfaces. Since components enable finegrained code reuse, this approach has been successful in creating applications that make very efficient use of the limited code and data memory on sensor network nodes. However, the other important benefit of components—rapid application development through black-box reuse—remains largely unrealized because in many cases interfaces have implied usage constraints that can be the source of frustrating program errors. Developers are commonly forced to read the source code for components, partially defeating the purpose of using components in the first place. Our research helps solve these problems by allowing developers to explicitly specify and enforce component interface contracts. Due to the extensive reuse of the most common interfaces, implementing contracts for a small number of frequently reused interfaces permitted us to extensively check a number of applications. We uncovered some subtle and previously unknown bugs in applications that have been in common use for years.

Abstract — When deployed in a real-world setting, many sensor networks fail to meet application requirements even though they have been tested in the lab prior to deployment. Hence, concepts and tools for inspection are needed to identify failure causes in situ on the deployment site. Tools for inspection should minimize the interference with the sensor network to, firstly, ensure that failures of the sensor network do not break the inspection mechanism, and, secondly, to ensure that the inspection mechanism does not change the behavior of the sensor network. In this paper, we propose passive distributed assertions (PDA) as a novel tool for identifying failure causes. PDA allow a programmer to assert certain predicates over distributed node states. Packet sniffing is used to detect failed assertions, thus minimizing the interference with the sensor network. 1 I.

We argue that the principal cause of sensornet deployment and development difficulty is an inability to observe a network’s internal operation. We further argue that this lack of visibility is due to the activity and resource constraints enforced by limited energy. We present the Mote Network (MNet) architecture, which elevates visibility to be its dominant design principle. We propose a quantitative metric for network visibility and explain why network isolation and fairness are critical concerns. We describe the Fair Waiting Protocol (FWP), MNet’s single-hop protocol and show how its fairness and isolation can improve throughput and efficiency. We present the Pull Collection Protocol as a case study in designing multihop protocols in the architecture. 1

Wireless sensor networks (WSNs) are a relatively new and rapidly developing technology; they have a wide range of applications including environmental monitoring, agriculture, and public health. Shared technology is a common usage model for technology adoption in developing countries. WSNs have great potential to be utilized as a shared resource due to their on-board processing and ad-hoc networking capabilities, however their deployment as a shared resource requires that the technical community first address several challenges. The main challenges include enabling sensor portability – the frequent movement of sensors within and between deployments, and rapidly deployable systems – systems that are quick and simple to deploy. We first discuss the feasibility of using sensor networks as a shared resource, and then describe our research in addressing the various technical challenges that arise in enabling such sensor portability and rapid deployment. We also outline our experiences in developing and deploying water quality monitoring wireless sensor networks in Bangladesh and California. 1

Abstract Many sensor network applications are concerned with discovering interesting patterns among observed real-world events. Often, only limited apriori knowledge exists about the patterns to be found eventually. Here, raw streams of sensor readings are collected at the sink for later offline analysis – resulting in a large communication overhead. In this position paper, we explore the use of in-network data mining techniques to discover frequent event patterns and their spatial and temporal properties. With that approach, compact event patterns rather than raw data streams are sent to the sink. We also discuss various issues with the implementation of our proposal and report our experience with preliminary experiments.

This paper presents a hierarchical approach for detecting faults in wireless sensor networks (WSNs) after they have been deployed. The developers of WSNs can specify “invariants ” that must be satisfied by the WSNs. We present a framework, Hierarchical SEnsor Network Debugging (H-SEND), for lightweight checking of invariants. H-SEND is able to detect a large class of faults in data gathering WSNs and leverages the existing message flow in the network by buffering and piggybacking messages. H-SEND checks as closely to the source of a fault as possible, pinpointing the fault quickly and efficiently in terms of additional network traffic. Therefore, H-SEND is suited to bandwidth or communication energy constrained networks. A specification expression is provided for specifying invariants so that a protocol developer can write behavioral level invariants. We hypothesize that data from sensor nodes does not change dramatically, but rather changes gradually over time. We extend our framework for the invariants that include values determined at run time in order to detect the violation of data trends. The value range can be based on information local to a single node or the surrounding nodes ’ values. Using our system, developers can write invariants to detect data trends without prior knowledge of correct values. Automatic value detection can be used to detect anomalies that were not previously possible. To demonstrate

Sensor network computing can be characterized as resource-constrained distributed computing using unreliable, low bandwidth communication. This combination of characteristics poses significant software development and maintenance challenges. Effective and efficient debugging tools for sensor network are thus critical. Existent development tools, such as TOSSIM, EmStar, ATEMU and Avrora, provide useful debugging support, but not with the fidelity, scale and functionality that we believe are sufficient to meet the needs of the next generation of applications. In this paper, we propose a debugger, called S 2 DB, based on a distributed full system sensor network simulator with high fidelity and scalable performance, DiSenS. By exploiting the potential of DiSenS as a scalable full system simulator, S 2 DB extends conventional debugging methods by adding novel device level, program source level, group level, and network level debugging abstractions. The performance evaluation shows that all these debugging features introduce overhead that is generally less than 10 % into the simulator and thus making S 2 DB an efficient and effective debugging tool for sensor networks.

The most common programming languages and platforms for sensor networks foster a low-level programming style. This design provides fine-grained control over the underlying sensor devices, which is critical given their severe resource constraints. However, this design also makes programs difficult to understand, maintain, and debug. In this paper, we describe an approach to automatically recover the high-level system logic from such low-level programs, along with an instantiation of the approach for nesC programs running on top of the TinyOS operating system. We adapt the technique of symbolic execution from the program analysis community to handle the event-driven nature of TinyOS, providing a generic component for approximating the behavior of a sensor network application or system component. We then employ a form of predicate abstraction on the resulting information to automatically produce a finite state machine representation of the component. We have used our tool, called FSMGen, to automatically produce compact and fairly accurate state machines for several TinyOS applications and protocols. We illustrate how this high-level program representation can be used to aid programmer understanding, error detection, and program validation. 1.

Soil contains vast ecosystems that play a key role in the Earth’s water and nutrient cycles, but scientists cannot currently collect the high-resolution data required to fully understand them. In this paper, we present Suelo, an embedded networked sensing system designed for soil monitoring. An important challenge for Suelo is that many soil sensors are inherently fragile and often produce invalid or uncalibrated data. Therefore Suelo is an assisted sensing system: it actively requests the help of a human when necessary to validate, calibrate, repair, or replace sensors. This approach allows us to use available sensors without sacrificing data integrity, while minimizing the human resources required. We tested our system in multiple real soil monitoring deployments and demonstrate that, using human assistance, Suelo produced 91 % fewer false negatives and false positives than common fault detection solutions on these datasets.

Abstract — We demonstrate a tool that allows inspection and debugging of deployed wireless sensor networks (WSN) by analyzing overheard radio messages. This tool can identify common problems such as node crashes, reboots, routing problems, and network partitions without instrumentation of sensor nodes. Existing approaches to identify performance problems and bugs in deployed WSN such as Sympathy [5] require to add logging and debugging code to the application running on the sensor nodes, with monitoring traffic being sent in-band with the sensor network data to the sink. These approaches result in significantly increased resource consumption in the WSN and bugs in the sensor network may also affect the monitoring mechanism. The presented tool is an implementation of our Sensor Network Inspection Framework (SNIF) [6], which consists of hardware to