A PROGRAMMABLE WIRELESS SENSING SYSTEM FOR STRUCTURAL MONITORING

Recent work has examined the design of wireless sensor network (WSN) systems for structural health monitoring (SHM). Wireless sensors enable dense monitoring of large physical structures and promise enormous ease and flexibility of deployment of instrumentation, as well as low maintenance and deployment costs. However, programming sensing applications on a network of wireless sensors remains a difficult and time-consuming endeavor. This is due in part to the complexity of such systems. Their limited battery resources, and the highly variable performance of wireless communication in different environments represent significant constraints that, if each application developer were forced to deal with, can significantly increase the time to develop robust applications. We have been developing a networked software system called TENET that simplifies the programming of wireless sensor actuator systems. A TENET system is a two-tier networked system consisting of two classes of nodes: a higher-tier with several nodes containing 32-bit processors and IEEE 802.11b radios, and a lower-tier comprising battery-operated sensor nodes with less-capable processors, low-power radios. Our TENET software runs application code on the higher-tier nodes, and provides a generic interface for tasking sensors and actuators. This separation of functionality simplifies application development greatly, since developers can reuse networking and sensor data extraction code, thereby reducing application development time. We will report on the development of and experiences with structural data acquisition application for a long-span suspension bridge using TENET. We will report on our experiences in deploying a two-tier network of wireless sensors on the bridge. We will report on the performance of the TENET system in this setting as well. Introduction Structural Health Monitoring (SHM) focuses on developing technologies and systems that assess integrity of structures such as buildings, bridges, Earp-space structures and off-shore oil rigs Doebling et al. (1996). Most existing SHM implementations use wired data acquisition systems to collect structural vibration data from various locations in the structure for analysis. More recently, with the advent of low-cost platforms for wireless sensing, wireless structural monitoring systems become feasible. Such wireless structural monitoring systems promise ease and flexibility of deployment in addition to low maintenance and deployment costs. Much recent work in wireless structural monitoring has focused on the development of hardware and node platforms (Lynch & Loh, 2005). little attention has been devoted to the software for such systems, yet a standardized software system that provides the right level of programming abstraction can greatly advance wireless structural sensing. Today, programming sensing applications on a network of wireless sensors remains a difficult and time-consuming endeavor. This is due in part to the complexity of such systems. Their limited battery resources, and the highly variable performance of wireless communication in different environments represent significant constraints that, if each application developer were forced to deal with, can significantly increase the time to develop robust applications. In this paper, we report on the design of a generic sensing software called TENET. TENET is designed for a two-tier network of sensors and actuators: a lower tier consisting of low-power sensing nodes which we generically call motes and which enable flexible deployment of dense instrumentation, and an upper Paek, Gnawali, Jang, Govindan, Johnson, Wahbeh and Masri 1 4th World Conference on Structural Control and Monitoring 4WCSCM-317 tier containing fewer, relatively less constrained, 32-bit nodes with higher-bandwidth radios, which we call masters. In TENET, applications run on one or more master nodes. They task motes to sense and locally process data. Conceptually, a task is a small program written in a constrained language. The results of tasks are delivered by the TENET system to the application program. This program can then fuse the returned results, and re-task the motes or trigger other sensing modalities. More than one application can run concurrently on a TENET. We have designed and implemented TENET and have implemented several applications on it (Gnawali et al., 2006). In this paper, we report on the performance of a wireless sensor network running TENET on a longspan suspension bridge. We instrumented 600 ft of the suspension bridge using a tiered wireless network consisting of five master nodes and 20 motes, and collected data for 24 hours. We report on our experiences with the deployment, and provide some preliminary data about the structural characteristics of the bridge. The TENET System Overview TENET is a two-tier networked system consisting of two classes of nodes: a higher-tier with nodes (called Master) containing 32-bit processors and IEEE 802.11x radios, and a lower-tier comprising battery-operated sensor nodes with less-capable processors, and low-power radios such as IEEE 802.15.4. Our TENET software runs application code on the higher-tier nodes, and provides a generic interface for tasking sensors and actuators. This separation of functionality simplifies application development greatly, since developers can reuse networking and sensor data extraction code, thereby reducing application development time. Our architecture is based on the assumption that future large-scale sensor networks will be tiered. Since motes have a small form-factor and are untethered, they enable flexible, low-cost, dense deployment of sensors; masters, which have significantly higher communication capacity and radio range, enable larger spatial coverage and, more important, network capacity scaling. Because master nodes have higher communication capacity, tiered networks scale better than similarly-sized flat networks of motes. A TENET system is based on a design principle that clearly identifies the role of the masters and the motes. In TENET, any and all communication takes the form of a task and a response to a task. Only masters are able task a mote, and the motes are only allowed to send task responses back to the masters. Master send tasks to the motes and receive the response back from the motes. Motes provide a limited library of generic functionality, such as timers, sensors, thresholding, data compression, and other forms of simple signal processing. Each task activates a simple subset of this functionality. Three important advantages arise from these design principles. First, applications execute on the master tier where application programmers can use familiar programming interfaces since that tier is relatively less constrained. Second, the mote tier networking functionality is generic, since TENET’s networking subsystem merely needs to robustly disseminate task descriptions to motes, and reliably return results to masters. This enables significant code re-use across applications. Finally, mote functionality is limited to executing tasks and returning responses, enabling energy-efficient operation. Tasks and Task Library In the TENET task library, tasks are composed of tasklets. Each tasklet may be thought of as a service to be carried out as part of the task. The tasklets in the TENET task library provide the building blocks for a wide array of data acquisition, processing, filtering, measurement, classification, diagnostic, and management tasks. For example, to construct a task that samples a particular ADC channel 0 every 1000 ms and transmit ten samples at a time, with the tag TEMPERATURE, to its master, we write: Sample(500ms, 10, REPEAT, 1, ADC0, TEMPERATURE) -> SendPtr() Paek, Gnawali, Jang, Govindan, Johnson, Wahbeh and Masri 2 4th World Conference on Structural Control and Monitoring 4WCSCM-317 Figure 1: A tiered embedded network Figure 2: vibration Sensing with Onset-Detector This provides the most basic sampling and transmission support one might expect from a mote. It periodically collects a single sensor value and delivers data using multi-hop transport. If the application programmer wishes to put a timestamp on every packet, and send the packet only if the the sample value is above 45, then the task description will be in the following form: Sample (1000ms, 10, REPEAT, 1, ADC0, TEMPERATURE) -> StampTime(B, LOCAL) -> ClassifyAmplitude(45, 3, A, ABOVE) -> SendPtr() This linear form of task construction are flexible, general, high-level, and efficient enough to support easy programming and tasking from masters. How can a TENET application make use of this tasking library? Shown below is the code for a complete application which collects vibration data from three axes at sampling frequency of 20Hz. This application is exactly what we have used for our bridge deployment. Here, SampleMDA400 is the tasklet that controls a specific vibration sensorboard, and SendStr() invokes our stream transport (described later). int main() { task string = ”SampleMda400(50000,0,X,Y,Z,TIME,7,15)->SendStr()”; /* task description */ task packet = construct task(task string); /* construct a task packet */ task id = send task(task packet); /* send the task */ while (1) { packet = receive packet(&mote id); /* receive response packet */ parse packet(&TIME, &CHANNEL, &DATA, packet); /* parse the packet and fetch data*/ store data to database(TIME, DATA, mote id, CHANNEL); /* store into database */ } } TENET provides the API to construct a tasking packet from a task description (construct task()), disseminate the task (send task()), and receive the task response from the motes(receive packet()). An application programmer only needs to write down the task description, parse the response, and process the data. In our application, the data is stored in a database, but a more realistic application might process the data in near real-time. To describe the generality of TENET, we