Wireless sensor networks seem to be everywhere. Technology magazines talk about them. Universities offer courses on the topic. Companies, both large and small, are working aggressively to push the development of these systems. Despite this interest and activity, such systems have not yet achieved the broad adoption envisioned by pundits and anticipated by engineers. Before this technology can attain its expected ubiquity, more effort is required to identify and satisfy real-world needs.
Pods with Potential
The Sensor Web (see the April 2004 article for an in-depth description, www.sensorsmag.com/sensors/article/articleDetail.jsp?id=328918) is a type of wireless network of sensors that acts as a single, autonomous macroinstrument. It is a temporally synchronous, spatially amorphous network, creating an embedded, distributed monitoring presence. This provides a dynamic infrastructure for distributed sensing and collective action. Because its architecture is both synchronous and router-free, the Sensor Web is distinct from the more typical TCP/IP-like network schemes. The architecture allows every pod to know what is going on with every other pod throughout the Sensor Web within every measurement cycle. A portal pod provides the system's master clock to which all other pods synchronize. Sensor Web networking is more akin to a data bus inside a computer that allows for interactive communication and reaction among various components.
By design, the Sensor Web spreads collected data and processed information throughout the entire network. As a result, there is no design criterion for routing as in more typical wireless systems since routing, by definition, is a focused moving of information from one point to another. Instead, the communication architecture is relatively simple and structured for both omni-and bidirectional information flows. Omnidirectional communication implies no directed information flow, while bidirectional communication allows individual pods (and end users) to command other pods, as well as receive information from them. Consequently, information on the Sensor Web can result from four types of data: (a) raw data sensed at a specific pod, (b) post-processed sensed data from a pod or group of pods, (c) commands entered into the distributed instrument by an external end user via the portal pod, and (d) commands entered into the distributed instrument by a component pod. The Sensor Web processes this internal, continuous data stream, draws knowledge from it, and reacts to that knowledge.
To date, more than 25 Sensor Webs have been fielded, with systems spanning up to 6 miles and running continuously for >3 years. The systems have been extensively tested in challenging environments, ranging from the ice slopes of Antarctica, to the searing heat of the central New Mexico desert, and to the corrosive salt air of the Florida coast. Real-time, streaming output of some of these systems is available over the Internet in a variety of presentation formats (e.g., http://caupanga.Huntington.org/swim/). It is also possible to remotely command the Sensor Web via the same Internet connection. Originally developed at the NASA/Jet Propulsion Laboratory, the technology is ready to be customized for a variety of practical uses, including environmental resource management and life safety applications.
Because of its architecture, this distributed instrument is particularly well-suited to macroscopic, on-the-fly data fusion and reaction, including statistical analysis and vector identification, allowing the entire system to actuate as a collective whole to the incoming data stream. For example, instead of having a collection of uncoordinated smoke detectors, a Sensor Web can organize the sensor information into a single, spatially-dispersed, fire locator. Previous discussions of the Sensor Web have often focused on botanical issues (Figure 1, page 18). In this article we'll examine two other case studies of real-world applications—snowpack monitoring and urban search and rescue—that illustrate the power of the Sensor Web's unique properties.
 Figure 1. Researchers from NASA/Jet Propulsion Laboratory install a Sensor Web 5.0 pod at the Huntington Botanical Gardens in San Marino, CA |
Pods as Pixels
The fact that the Sensor Web is a synchronous, distributed instrument means it can be viewed as a camera with each of the individual pods providing a pixel of local data. Every sensor in a Sensor Web is in sync with all the other sensors in the collection. Consequently, at each measurement cycle, the Sensor Web provides a synchronized snapshot of the area it is monitoring. This feature is of particular importance when building up a large-scale picture of an area to compare with, say, satellite data.
Remote sensing measurements provide data on many geophysical variables that have spatial and temporal fluctuations on a wide range of scales. Because the ground footprint of remote airborne or spaceborne sensors is often larger than the scale on which the particular measurement of interest varies, the remote sensing data provide only a coarse-resolution estimate of the desired parameter's overall average value. Using these data for practical applications at local scales requires the type of information that could be provided by a Sensor Web. For example, if satellite measurements at the 30–50 km scale are supplemented by ground-based information at finer scales, it is possible to attain sufficiently high-resolution measurements (0.1–1 km) for Earth science applications, such as water resource management and weather forecasting.
The Sensor Web can also help validate coarse-scale satellite estimates, one of the current challenges in Earth and planetary science. In traditional ground-validation, in situ sensors often sample a point location in a varying, heterogeneous field. This approach lacks statistical confidence limits on the degree of match between remote and local data and so requires more information from ground probes. In contrast, the Sensor Web can cover a larger area than a single-point measurement and increase the statistical confidence limits on the estimated field average.
Additionally, because every pod in the Sensor Web knows about the measurements at every other pod, the Sensor Web can aggregate, organize, and process its collective information into a form that is directly comparable to what the satellite sensor is expected to observe. This is crucial when a Sensor Web is located remotely without Internet access. For long-duration, unattended deployments under such circumstances, memory restrictions will require the Sensor Web to condense the mass of data acquired on the fly. For example, a Sensor Web can change the periodicity of the measurement cycle to take more measurements during a dynamic period and fewer during more stable times. In addition, it can, on its own, statistically reduce the local data to be ready for comparison to the remote measurements. Such behavior has already been demonstrated in the laboratory.
 Figure 2. A Sensor Web 5.0 pod being deployed in the Sierras near Merced, CA. Pods were installed over the site with a density of ~1 pod/acre |
As a modest real-world example of these ideas, consider the Sensor Web deployed in the Upper Merced River basin, CA, (Figure 2, page 19, and Figure 3) to monitor the snowpack there (the site was chosen because it is also studied via remote measurements). Studying the rate of change of the snowpack depth provides resource managers valuable information on the local water distribution and pathways. Such knowledge is crucial for enabling informed decisions and in creating forecast models of water usage and contaminant fluxes. Each pod contains sensors for humidity, temperature, and light. Most important, however, is an attached sensor that bounces a sonic pulse toward the ground to measure the position of the water-air interface based on the reflection time of the pulse. Comparing the pulse's flight time to that measured when no snow is on the ground gives the snow depth measurement. This system has been deployed for two seasons now (in the first season 10 pods were deployed over 10 acres while the present season uses 20 pods to cover 18 acres). Since all pods share information, any convenient pod can be used to peek into the overall system (Figure 3). Internet access is difficult in this isolated region and so the data are instead collected in a memory module connected to the portal pod. These modules can be hot-swapped once a month to ensure continuous data collection.
 Figure 3. Researchers from the University of California, Merced, check the deployed Sensor Web. The pod is located just to the left of the upright mount, the sonic pinger used to determine snow depth is at the end of the cantilever to the right |
The Sensor Web provides a snapshot of the snow depth across the entire study site every 5 min. The first deployment season proved particularly challenging given the extreme snowfall (180% greater than average), which often buried the pods under snow, thereby cutting off inter-pod radio communication. However, as soon as the snow melted, the pods—some of which had been buried for several weeks—immediately joined together again as a single, functioning macroinstrument. Power was sufficiently well managed within the pods to provide robust operation of the overall Sensor Web. More important, the sonic pingers connected to these pods were, by definition, synchronized to the other pingers on the other pods already operating. This resulted in a particularly rich data set that could then be matched to remote measurements.
Pods as Pointers
The global pod-to-pod information sharing intrinsic to a Sensor Web is of great value for situational awareness. A good example is the Sensor Web designed for urban search and rescue in collapsed structures. The pods in this system are equipped with four gas monitor sensors (oxygen, carbon monoxide, hydrogen sulfide, and explosive limits) and a tilt meter. Because of global information sharing, when any one pod alarms, the others will as well. As a result, responders will know when to exit and even how to modify egress paths based on the pods' detection of distant atmospheric changes due to gas leaks or remote ground shifts in the structure. In addition, other responders working in other portions of the building will also be aware if there is a gas leak or structural shift that could affect them. Finally, the incident commander also gets a global view of the entire situation, something not possible using existing equipment.
The global information sharing also allows the incident commander to send text messages into the system, which will simultaneously show up on any pod with a display. This supplements direct radio communication to the squad, and, because the information hops pod-to-pod, can effectively travel around the concrete and steel found in modern structures. As a result, the Sensor Web becomes a rapidly deployable infrastructure.
A 10-pod Sensor Web system—taking temperature, humidity, the four gas concentrations, and tilt readings every 30 s—has been used by urban search and rescue workers in actual field exercises. Inter-pod communication on the open 900 MHz band proved very stable despite the intense wireless activity during the exercises. One such session took place at an urban search and rescue training facility at Elk Grove, CA (Figure 4, page 20). The system performed quite well. Indeed, when a chain saw was left running near pod 6, the incident commander could track the motion of the moving hazardous gas front caused by the resulting carbon monoxide buildup. When one of the pods alarmed, the rest did too, providing all workers with awareness beyond their local confines.
 Figure 4. The urban search and rescue training facility at Elk Grove, CA, where a Sensor Web system (represented by the orange lines and dots) was deployed |
In other exercises carried out in a much larger collapsed-structure training facility at NASA/Ames (Figure 5, page 22), the incident commander was able to simultaneously monitor four separate rescue squads as they penetrated the structure at four different points. A special display pod, showing the activity of all the gas monitors throughout the Sensor Web system, allowed the incident commander to be mobile around the structure while still keeping an eye on the operations. A fixed laptop interface connected to the portal pod at the command post provided a valuable permanent record of the atmospheric conditions for each of the squads. Figure 5 (right) shows a rescue worker lowering a pod into a small confined space. This allows the incident commander to watch for, and prevent by forced ventilation, any hazardous gas buildup in the space. This capability can help avoid a worker evacuation that would critically slow down a rescue operation.
 Figure 5. Members of the Sacramento Metro Fire District use the Sensor Web at the Disaster Assistance and Rescue Team Training Facility at NASA/Ames to aid in their collapsed-structure operations. On the left, a rescue worker monitors the entire system from a portal pod. On the right, a rescue worker lowers a pod into a confined space |
At one point in the exercises, a worker ignited an oxy-acetylene torch to break through rebar. The rapid buildup of carbon monoxide gas created by the torch in the confined space caused the local pod to alarm, triggering the rest of the pods to alarm, and alerting the incident commander of the situation at the same time as the squad near the incident. In fact, the incident commander was there to greet the rescue workers as they evacuated the structure.
In another exercise, the Sensor Web was attached to a highly stressed shoring. When the shoring began to give way at a weak point, the nearest pod tilt meter alarmed, again triggering the rest of the Sensor Web. This happened a full minute before total structural collapse. If it had been an actual operation, advance notice of this type would have provided critical evacuation time for workers throughout the structure.
Pods with a Purpose
While the Sensor Web has had a long history of making passive measurements in a variety of environments, the technology is increasingly moving toward applications where its collective action properties enable new types of operations. As important as monitoring is, autonomous reaction to the environment will be the ultimate hallmark of Sensor Web technology. The stable platform provided by the Sensor Web allows algorithm development based on the data stream coming from the entire distributed instrument. Putting intelligence into the instrument embedded in the field is the only way to ensure practical performance for real-world demands. Once that occurs, the applications for this wireless technology are truly as endless as projected.
This work was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with NASA, by support from the Technical Support Working Group with funding from the Department of Defense, Department of Homeland Security, and Department of State.
Kevin A. Delin, PhD, can be reached at SensorWare Systems, Inc., Arcadia, CA; [email protected] , www.sensorwaresystems.com.