EmStar: A Software Environment for Developing and Deploying Wireless Sensor Networks

1
EmStarA Software Environment for Developing and
Deploying Wireless Sensor Networks

• CENS Research Review
• October 28, 2005
• UCLA CENS EmStar Team

2
Outline

• Why is EmStar useful?
• Where is EmStar used?

3
Numerous Software Requirements
Communication (ad-hoc/wireless)
Algorithm/Sensing
Heterogeneity
Avoid nesC/ C duplication
Inter-platform communication
Poor/dynamic Hard to estimate links
Not all nodes Are 1-hop
Task Scheduling
Calibration
Signal Processing
Time Synch
Field coverage / Bird Localization
Routing Algorithm
Bird Detection
Remote Management
State inspection/ Interactive Debugging
Process control
Remote actuation/ monitoring
Visualization
Dynamic topology
Logging
System Monitoring (development/deployment)
4
Experimental Systems are Experimental

• Prototypes
• Bugs
• Unexpected and transient behavior
• Things that will cause trouble
• Multiple asynchronous inter-dependent events
• Trying to optimize application and make it smart
• Unexpected data and environmental conditions
• We need things to be (in lab and for
  deployments)
• Robust so everything keeps running
• Can not atomically restart the world
• Partial failure is normal in large distributed
  systems
• Softstate is crucial to success of distributed
  systems
• Diagnosable so you can figure out what the
  problem is

5
How does EmStar help?

• EmStar is a layer above Linux designed to enable
• Simulation Rapid iteration via real-code
  simulation tools
• Robustness Keep running despite unexpected
  failures and bugs
• Visibility Easily debug/diagnose running systems
• Module Reuse Leverage existing libraries, tools,
  and services

6
What is EmStar?
Layer 3.5 Extra Tools Help run, maintain, and
debug application
Layer 3 Existing Modules and Services Existing
useful components for applications
Layer 2 Device Patterns Libraries IPC mechanism
for a variety of interactions
Layer 1 Glib Handle events on IPC
Layer 0 FUSD Low Level IPC
7
EmStar Provides
Communication (ad-hoc/wireless)
Algorithm/Sensing
Heterogeneity
Avoid nesC/ C duplication
Inter-platform communication
Poor/dynamic Hard to estimate links
Not all nodes Are 1-hop
Calibration
Task Scheduling
Signal Processing
Time Synch
ESS / DSE
RNPlite
EmTOS
Acoustic Ranging
syncd
Statesync, flooding, sinktree
Sensor devices, libraries, staged event driven
processing
Emview / xoscope
Device files
EmRun
In-memory Logrings
Web server
clustersync
State inspection/ Interactive Debugging
Process control
Remote actuation/ monitoring
Visualization
Dynamic topology
Logging
System Monitoring (development/deployment)
8
Transparent Trade-off of Scale vs. Reality

• Pure Simulation
• Initial development
• Smoke test
• Fix major design flaws
• Emulation
• Real radio channels
• Real Mote hardware in the loop
• Catch bugs, tune algorithms
• Deployment
• Time consuming
• Difficult to monitor and manage
• Little/No out-of-band debugging
• But by now, its bug free..?

9
Enables Mote-Microserver Integration
Example ESS
ESS network

• NesC-based Multihop tree routing protocol
• Runs natively on motes
• Runs in EmTOS wrapper on microserver
• Wrapped version exposes EmStar devices
• Used by microserver sink implementation
• Increased visibility on microserver

ESS
EssDse
Multihop
link/mote0
motenic
Dse
TimerC
AM
Transceiver (Mica2)
RadioCRCPacket
ClockC
ADC
Mote RF Channel
10
Acoustic Platform

• Linux-based wireless platform
• 4-channel microphone array
• Distributed acoustic sensing
• 15-20 nodes surround targets

• Localize motes
• Localize and count woodpeckers

11
Sounds fun, but first
Emstar provides

• Support for time-synchronized sampling?
• Network primitives for coordination among groups
  of nodes?
• Automatic calibration of array location and
  orientation?
• Development tools
• Simulation tools, testbeds, visualization
• Debugging and Deployment tools
• Control groups/individual nodes
• Health monitoring
• Diagnostic data
• Error logs

12
Outside CENS Use

• Current external users of our prototype system
• Ohio State
• Tiered testbed in support of the DARPA NEST
  program
• Implemented Stargate routing layer and software
  update mechanism
• MIT
• Mote software development using EmTOS on an ePRB
  testbed
• Experiences and feedback
• Initial experiences have been generally positive

13
Conclusion

• Thanks for listening!
• More information at
• http//cvs.cens.ucla.edu/emstar