Presentation on theme: "Software Challenges in Wireless Sensor Networks Jeremy Elson Microsoft Research IPSN/SPOTS Tutorial Wednesday, April 27, 2005."— Presentation transcript:
Software Challenges in Wireless Sensor Networks Jeremy Elson Microsoft Research IPSN/SPOTS Tutorial Wednesday, April 27, 2005
Outrageous (?) Opinion Tutorial Outrageous opinion survey –A dozen contributors –Ideas that deserve credit are theirs, blame for dumb ideas is mine More questions than answers Basic question: Why is writing software for sensor networks so hard? Some examples of ongoing research
Is it hard? Internet: –Cost of new devices is really just the device –Pressure is on hardware designers – smaller, cheaper, faster –We can network every node that exists Far more motes exist than we can network –100,000 (?) exist –Biggest networks, ~100 or maybe ~1000 –Why is this?
Can we just blame hardware? Energy is non-negotiable –Un-tethered sensing is the reason were here –Will always limit radio ranges, link qualities Architecture challenges come somewhere in between hardware and software –e.g., how do we structure hierarchies? –Billions of PCs cant be wrong! Even with the right structure, its harder –Why?
Worst of All Worlds Text Timing- Dependent Data Real-World Sensor Inputs Single- or Few- Threaded Multi-Threaded OS Kernels/ Device Drivers MS Word cat Robotics Sensor Networks Distributed, Timing Dependent System MPI/Linda Distributed Robotics Squid TCP System Uncertainty Data Uncertainty
Big Challenge 1: Visibility, Visibility, Visibility! Of a dozen sensor network researchers polled, 10 listed debugging support in some form as a core challenge
Visibility, visibility, visibility… Ground truth is hard to capture, even with unlimited capacity systems – damn you, real world! –We want to interpret responses to stimuli –The stimuli, not the sensor outputs, are ground truths The lab is not the same as the field –Things that worked in the lab dont work during deployment –Bugs in MAC layers, positioning errors, non-Guassian noise… Its also hard to model –Models are appearing (e.g., Cerpa, Whitehouse) –But notice that models are highly environment- specific
Visibility, visibility, visibility… The differences have substantial effects –If only I had $100 for every routing algorithm designed with a circular radio model –I still couldnt afford to buy a circular radio Observing reality concurrent with design should be mandatory –Brings us back to needing visibility
Visibility, visibility, visibility… Even traditionally easy-to-observe things (e.g. messages, states) become hard to capture, because… Debugging information is now huge compared to data, instead of the opposite (vs. Internet) You cant store it on Mote-sized devices, either
Simulators, Emulators, Testbeds TOSSIM (Levis) –Real-code-simulator for motes Avrora (Titzer, Palsberg) –Simulates down to microcode level Motelab (Welsh, et al.) –Always-on testbed, lowers the massive systems motivation effort required for deployments EmStar (Girod, Elson, et al.) Reminders: –Sensor outputs are not ground truths –Matts office is not the same as a Redwood forest
Simulators, Emulators, Testbeds EmStars runtime environments allow high-visibility debugging before jumping into low-visibility deployment
Visibility for Design Even understanding the behavior of a big parallel process is hard –How do you know whats going on But even if you do… Designing local rules to cause global behavior is hard (Culler, Liu, Welsh) –How do you control whats going on
Visibility for Management The need for visibility doesnt end when the design is done (Madden, Polastre) Which sensors have failed? –For repair purposes –Because it tells you about the data Doesnt obviate the need for statistical elimination of sensors we think are bad –Shut up, youre confusing everyone!
Another take: Predictability Instead of observing what happened (post-facto), predict what will happen (static analysis) (Srivastava)
Giving Up Tenet (Kohler) – motes can only do the most basic tasks (e.g., thresholding), and route back to a microserver –In the low-visibility nodes, complexity is limited to reasoning about one nodes data –Hard part happens at microservers Mechanism vs. policy separation for routing (Girod) –Motes send link states to microserver –Microserver computes routes; installs them on motes
Big Challenge 2: Higher Level Abstractions How long can we keep on doing it this way?
Why are abstractions important? They let you reason about software at a higher level –Right now we manually script every packet sent and received, most timers… They (can) let software interoperate better –Applications can share the underlying building blocks; system is smaller, more consistent –Services like TCP port numbers
Higher Level Abstractions Consider compiler arc: –First, compiled code is too slow –Second, But computers are now fast –Third, The compiler does it better anyway Were still at Step 1 –Not with CPU cycles (we use compilers)… –… but bandwidth, energy, and memory. Unfortunately there may not be a Step 2
What if theres no Step 3? The Internet has TCP, which is well-behaved, and which many apps use –Nice model: fixed data len, variable time Some (minority?) apps dont fit this model, adapt at the app layer (e.g. video quality) Sensor network congestion control (e.g. Woo, Hull): good first steps but still has a focus on collision avoidance Root of the problem: rate adaptive sensor apps must be the common case; they arent! Common case is no longer fixed data size, transport it when you can model – infinite data like streaming video
Some Abstractions TinyDB (Madden) –Among the first; programming interface is queries Abstract regions (Welsh) –Program collections at a higher layer than sending messages Reliable Multi-Hop State Sync (Girod) –Publish and update structs over lossy nets This week, weve seen State-Machines (Kasten) and new intermediate languages (Newton) But the real question: do they work across a diversity of applications? Only time will tell.
Sub Challenge: Re-Usable Software TinyOS, EmStar, etc. are modular, yet reuse isnt as pervasive as it should be One part software engineering, one part Big Problem (as in congestion control) An encouraging first step: SP (Sensor Protocol) by Polastre, Culler, et al. –Standardized interface to MAC, with some basic feedback in both directions
Meta-Challenge: Applications That Do More Than Web Cameras 1999 Grand Challenges paper: Data processing must be in-network Where are we now? Many (most?) applications are bring all the data back –Some notable exceptions including sniper tracking (vanderbilt), Magneto-Car Tracking (berkeley), Self-Healing networks (sensoria)
Self-Healing Networks Sensoria Corp under contract from DARPA Goal: Nodes localize themselves within 1m, MOVE to fill in gaps Network completely self-organizing, autonomous at many layers
Summary Ultimately we want to get to systems that do amazing things We just keep building on ideas; we have to build on each others systems Abstractions are needed, so we can build additive systems instead of just more None of this will happen without visibility And above all…
What the heck is the killer application?!!??
Acknowledgements David Culler Henri Dubois-Ferrier Lew Girod Richard Guy Bill Kaiser Eddie Kohler Jie Liu Sam Madden Andrew Parker Joe Polastre Matt Welsh Alec Woo Yan Yu Feng Zhao