em: Moving embedded networked sensor applications from concept to deployment

1
em Moving embedded networked sensor
applicationsfrom concept to deployment

• Jeremy Elson, Lew Girod
• Center for Embedded Networked Systems
• January 16, 2003

2
Fundamental Problems

• We are trying to build systems that meet global
  performance criteria
• Design evaluation must use a global view

BUT...

• The systems are inherently distributed and have a
  strictly local view.
• In a deployed system, we cant iterate on design.
  There is no way to know if using the discarded
  information would have changed the outcome.

3
Fundamental Problems

• Reuse of proven algorithms (and code) is very
  important, even for normal software
• Given the difficulty of instrumenting our fielded
  systems, reuse becomes critical

BUT...

• Domain and application knowledge is needed at
  many layers.

How do we create reusable components? How do we
verify components that we change?
4
Hardware
1. Fine Grained decomposition/reuse 2. No
strict layer boundaries
5
The em Strategy

• Fine-Grained Decomposition
• Individual modules (processes) with well-defined
  and standardized interfaces
• Can be debugged individually, interchanged (e.g.,
  routing, ranging), run-time configured
• No strict layering
• The processes have much more complex (DAG)
  dependencies
• Makes it easier to isolate the pieces that are
  domain-specific the application layer can
  connect to things deep within parts of the stack
• Event-based reactive to changes

6
In the real system, each node is autonomous they
communicate via the real environment
. . .
Problem deploying and debugging is a big mess
7
Can we simulate?

• Simulations have been used extensively in
  sensornets (ns, ParSec/GlomoSim, custom)
• But how do you deploy NS code?
• Its too easy to make unrealistic assumptions
• Recent trend run-real-code simulations
• Forces you to think through the real issues
• Easily move between simulation and reality
• Simulator becomes very useful as a
  pre-deployment tool, not just for paper-writing

8
In the simulator, the real software runs in
a synthetic environment (radio, sensors,
acoustics)

. . .
Very Simple Radio Channel Model
Very Simple Acoustic Channel Model
EMULATOR/SIMULATOR CONTROLLER
9
In the hybrid, the real software runs
centrally, interfaced to hardware distributed in
the real world.

. . .
EMULATOR/SIMULATOR CONTROLLER
Radio
Radio
10
So what is em exactly?

• A standard set of useful sensornet services
• Radio device drivers, neighbor discovery, time
  sync, routing, flooding, acoustic ranging...
• A framework for implementing new services or apps
  that fit into the stack
• Control programs run an autonomous system, or n
  copies with a channel sim
• Visualization easy to plug in your code
• A library of useful but mundane functions
• Get your node ID, timers, logging

11
Summary

• This stuff will be really cool...
• ...but pieces dont quite exist yet
• Basic services (send/receive packets, neighbor
  discovery, flooding, timesync, simulator) ready
  this week
• Visualization next week
• Emulator (with real motes) in another couple of
  weeks... But the beauty is that you can develop
  code today in the sim
• Classmates and labmates will then be developing
  in parallel