Many remote sensor networks already exist for other uses. Some may monitor building temperature or they may be motion sensors. Others may be set up outdoors to track pollutants in a river. What if the first responders could quickly and easily reprogram these networks to detect the new hazard? For instance, maybe they could use a voice command saying that they need to know where the fire is, and the software would reprogram any remote sensors in the area to look for fire. When the emergency was over, the sensor networks would return to what they had been doing originally.
That’s the vision of a team of researchers at Old Dominion University in Norfolk, Va., and Clemson University in Clemson, S.C. They hope it will be possible in the future for emergency responders to have specialized software with them for this purpose — built into their helmets. The software could quickly detect and reprogram any remote networks in the area to report, for example, not whether it’s time to turn the lights off but instead on whether a certain part of the building is on fire.
The group is partway through a three-year project sponsored by the National Science Foundation. (The grant could be extended beyond the three years.) The project is called ALERT: An Architecture for the Emergency Re-tasking of Wireless Sensor Networks.
The goal is not to produce a marketable product, but to create a “proof of concept to show that we could accomplish this retasking with separate networks and a simple mission,” said Michele C. Weigle, associate professor of computer science at Old Dominion and principal investigator. The hope is that if their research shows how it could be done, someone will turn it into a commercial product that emergency managers and first responders can use.
Wireless sensor networks consist of small devices, often running on one battery, that generally have a simple set of sensors to detect temperature, noise or humidity. More advanced sensors may check for a specific chemical in the air or detect motion in a room. The devices also have a small computation engine and a radio so they can communicate with other devices, Weigle said. Because they’re not connected to a wire, they can go outdoors or in other places where a wired network is impractical.
Many areas have more than one of these networks, but they may have been deployed by different groups — perhaps one monitors traffic and the other smog levels, for example — and the networks generally don’t talk to each other. “They attend to their own business,” said Stephan Olariu, professor of computer science at Old Dominion and part of the research team. “They do not even know of the existence of others.”
The ALERT project’s goal is for these networks to work together in an emergency to “serve a high-level mission,” Olariu said.
“Can you take the capabilities of these disparate sensor networks and combine them to do something that they couldn’t do individually?” Weigle asked. If one network is detecting temperature and another smoke, the two together could indicate where the fire is. Or a network that normally monitors one chemical could look for a different one for a time. “The retasking is about bringing them together so that they can talk to each other.”
The resulting information could be of great help to emergency responders who need to understand what’s going on in a hazardous environment. The retasked networks could help emergency responders assess the extent of hazardous materials in an area, locate movement to find survivors of a disaster, or guide a rescue team through a smoky room.
The retasking would be temporary — just to help with the emergency. “The idea is that they’re already deployed to do a specific function,” Weigle said. “In normal times, you don’t want to mess with that specific function.”
Challenges Ahead
For computer users accustomed to switching quickly between checking email and surfing the Web, retasking “has been built into their user experience for a decade or more,” said Jason Hallstrom, associate professor in the School of Computing at Clemson and part of the research team. But it’s trickier for wireless sensor networks.
One reason is that the networks are geographically distributed: Many machines need to change jobs when the network is retasked. In addition, most sensors have far less computational power than a typical computer, making any changes more difficult.
The researchers are taking a multistep approach to retasking remote sensor networks:
- Determine what networks are available and who has authority to commandeer them. If several different government agencies or departments have created their own sensor networks, is there one authority that knows about all of them and could make the decision to retask them to work together? This system isn’t in place yet, but one option would be that the U.S. Department of Homeland Security would be in charge of it.
- Make sure those networks have the necessary software for retasking. “We’re thinking that you would really need to add something to the sensor networks first,” Weigle said. “They would need some additional software or middleware on them that would allow them to respond to an instruction to retask.”
- In an emergency, decide what the network needs to do. For example, emergency responders might say they need to know the extent of a fire. The software needs to assess which sensors in the networks have which capabilities, as well as what specific tasks are needed to determine the fire’s location. In the case of fire, sensors might check for temperature, smoke and certain gases.
“When I tell you about fire, we all have a mental image of what we expect to see,” Olariu said. “The sensors are far more primitive. We are talking about a simple high-level action that needs to be translated very carefully into a well orchestrated cooperation between three types of sensors.”
- Convert the high-level mission into a communication the sensors understand. The software must create commands that the sensors can follow — a difficult technical task. And it must send each sensor in the newly combined network the correct commands. The sensors then have to send their information to a central location to be analyzed so the emergency responders get their question answered.
Technical Problems
The researchers have been focusing on the most efficient way to reprogram these simple machines. In some situations it may be relatively easy. For instance, emergency responders may decide they want a sensor network that’s monitoring air quality every 15 minutes to start doing it every minute. This would require a fairly simple change for the sensor. A more complicated scenario would involve more extensive reprogramming, replacing parts of the existing program. The most significant type of retasking involves replacing the entire program on the sensor network.
Researchers are striving for two goals as they work on retasking. The first is speed. “In the context of emergency management, there’s an advantage to doing this as quickly as you can,” Hallstrom said.
The second challenge is how much energy the change uses. Transmitting data wirelessly is the largest power consumer for these remote networks. “You have a very small energy budget,” Hallstrom said, and it has to be managed well. The less sent over the network, the better.
The group hopes to find efficient protocols and programming mechanisms to retask large-scale sensor systems, Hallstrom said.
Other questions the group is trying to answer:
- How do you know how many sensors are needed for a particular task? Sometimes it may be that a sensor network can’t do a particular task because it doesn’t have enough sensors. Other times, if there are more than enough to give a reliable result, some of the sensors could be used to monitor other things.
- How long does a sensor network need to get a particular result before the software reports an incident like a fire? “You want it quickly but also with as high confidence as possible,” Weigle said. “We’re doing theoretical work to look at what the tradeoff point is.”
- How frequently should sensors report their results? Sensors can be programmed to simply report their results at regular intervals. But since reporting uses energy, conserving power is key. So researchers are looking at different ways for sensors to determine how frequently to report their data.
One last area the team is still investigating is cost. Since the idea is to use existing networks, there should be few additional infrastructure costs, although there would be costs for developing and deploying the necessary software.
Figuring out how to keep the costs down while moving the networks to new uses is just one of the challenges that keeps the team going.
“This is ongoing, exciting work,” Olariu said.
