Data Collection

Original version by

Current author:


A local forest technology company, TerraSense, wants to build and sell a system for gathering and analyzing weather information to predict forest fires and help with water table management. The ArborXT will be sold to National Forests, Environment Canada, the U.S. Forest Service, and large private land owners. It will consist of hardware and software both locally at the owner's central site and field locations (forests).

The data sensors in the forest report at various intervals to the central computer via various telecommunication hardware (satellite, packet radio, cellular, terrestrial dial-up phone or dedicated line, etc.). The central computer stores and analyzes the information. The users run a wide variety of reports, browsers, historical trend analysis, and future prediction algorithms over the data. Furthermore, given the inherently geographic nature of the data, many of the reports incorporate maps (a cartographic interface, however, is beyond the scope of this project).

The field components are sensors that report measurements of physical data such as:

They report their data in three basic ways:

Some sensors fall in multiple groups, for example, they report events but can also be queried.

The sensors are produced by different manufacturers and return numeric values in a wide variety of units (miles/hour, km/hour, lumens, watts, calories/day, etc.) and at widely varying intervals and tolerances. All of these things are part of their configurations. That is, setup information that can help clients of the sensors interpret the kind of information they're receiving. The notion of "configuration" is general enough to include deployment issues like location and network connection type.

Additionally, the data links are not necessarily reliable, and yet the system must deal with all these issues while presenting both a uniform and a detailed view of the data to the user and the system's central reporting and analysis programs.

Desired Programs

TerraSense needs three categories of programs at the central site:

When a new sensor is installed, one of two things may happen, depending on the sensor:

Gathering the sensor data is relatively simple: the field sensors send information packets to the central computer, and the central computer stores them. Each packet contains the sensor ID, the time stamp, and the numeric sensor measurement.

The browsing and analyzing programs are the heart of the system. The analysis algorithms provide fire danger ratings, water table estimates, flash flood warnings, and so on. The browsing interfaces provide detailed information, both tabular and geographic, from the database. For example, the temperature maps similar to those seen on the evening news are one of the possible graphical outputs. But again, the system to be developed here would only deal with the numerical and textual data that would allow such a map to be realized. The user should be able to navigate through the information in many ways including:

The longer-lived applications are analysis plug-ins. The currently planned offering includes forest fire risk computation, sensor reliability trends, and short-term weather prediction. (TerraSense intends to sell additional modules for other risk factors, such as earthquake prediction, in the future.)


Scenario #1 - Data Analysis

There are sixteen sensor groups, each group having three or four sensors, placed in the Rumbling Range National Forest. The sensors are randomly chosen from rainfall, temperature, sunlight, wind speed, wind direction, and snow pack sensors. The sensors report from once a minute to once a day and in a variety of units. Frequency of reporting is part of a sensor's configuration it transmits to the central site upon deployment.

Jane Arden, a National Park Service Ranger, wants to post the fire danger results outside the Visitor Information Center, so she uses the ArborXT to examine the graphical view of fire danger in the forest. Overall, the fire danger is "moderate" with one area of "low danger + high uncertainty". Looking into the uncertain area, she finds that a number of the sensors have not reported for quite a while, leading to the uncertainty. Further investigation reveals that none of the sensors in groups 2 and 4 have reported, and further checking shows that groups 2 and 4 are the only two which use the 555-3473 dialup modem. She dispatches a repair crew to figure out the problem with the phone line while she posts the "moderate" fire danger sign in front of the visitor's center, just to be safe. She also checks the fire danger from last year, and finds out that it was "low" over the entire forest, so she calls the park newspaper publisher and asks them to print a story about how the fire danger may higher this year.

Scenario #2 - Installation of New Sensors

The Rumbling Range National Forest (RRNF) buys two new arrays of sensors. (Sensor arrays are so named because they are colocated and allow the central site to glean more information than just the sum of that from each individual sensor.) The RRNF hires a helicopter crew to plant them sensors in the forest. After they return with Global Positioning System (GPS) confirmation of the latitude and longitude of the sensors, Jane configures the system to receive the new data. Fortunately, the ArborXT was clever enough to store the unidentified incoming data until Jane had time to indicate where the sensors were located, what sensor types they were, and in what units the measurements were taken.

Scenario #3 - Sensor Reliability Example

TerraSense comes out with a new plug-in module that it generously gives away free over the Internet. This new module computes trend analysis of the sunlight sensors to detect premature failure. Ms. Arden downloads and runs the module against the Rumbling Range database, only to discover that sensor #372 on Bald Mountain shows signs of age -- its measured output has slowly declined over the past four years. Jane decides to hike to the top of the mountain and replace the sensor.

When she reaches the top, she discovers that the problem is not the sensor, but rather a small pine tree shielding the sensor from the sun. Unwilling to cut down the only tree on Bald Mountain, she relocates the sunlight sensor 100 meters to the south. When she returns to base, she updates the database with the sensor's new location.

Previously updated by Torsten Layda, SWX Swiss Exchange, DesignFest® Webmaster.

Last updated by James Heliotis, RIT, DesignFest® Committee Member.