EmStar: A Community Resource for Heterogeneous Embedded Sensor Network Development

1
EmStar A Community Resource for Heterogeneous
Embedded Sensor Network Development
Center for Embedded Networked Sensing
PIs Deborah L. Estrin (destrin_at_cs.ucla.edu),
Richard G. Guy (rguy_at_cs.ucla.edu), William J.
Kaiser (kaiser_at_ee.ucla.edu), Edward Kohler
(kohler_at_cs.ucla.edu), Mani B. Srivastava
(mbs_at_ee.ucla.edu) Senior Personnel Lewis Girod
(girod_at_nms.csail.mit.edu)
Goals and Objectives
Why EmStar?
Near Term Goals
Infrastructure and Facilities

• Development of sensor network systems
• Solution to common problems (wireless support,
  etc.)
• Native support for tiered architectures
• Development tools simulation, emulation,
  visualization
• Deployment tools Robustness, Process control,
  Logging, State Inspection, Interactive Debugging,
  Visualization
• Common platform and Community resource
• For educational purposes
• To reduce redundant development within research
  community
• To support researchers in other fields who want
  to use WSNs

• Testbeds at CENS
• 50-node Mica2 testbed
• 13-node Stargate testbed
• 10-node portable acoustic monitoring platform
• Software publication
• Emstar web site (http//cvs.cens.ucla.edu/emstar)
• Documentation tree and Wiki
• Emstar-users mailing list
• Acoustic ENSBox and ESS Wiki

• Ease of use
• Selective restructuring and redesign
• Documentation and implementation examples.
• Supporting common hardware platforms
• Outreach to the user community
• Through conferences, demos, and tutorials
• By providing easy startup kits
• By helping local users get going with exisiting
  research systems

Growing User and Application Community
MesoAmerican Subduction Experiment (MASE)
Acoustic ENSBox

• 50 Node, 250 Km Wireless Network of Seismic
  Sensors
• Kinemetrics A/D Converter
• 400 MHz ARM/Linux CPU
• Operated in conjunction with UCLA Geophysics,
  Caltech, and UNAM
• Emstar-based system software
• Multi-hop wireless networking
• Hop-by-hop delay-tolerant reliable delivery of
  seismic data (DTN)
• Delay-tolerant Shell (DTS) for remote system
  management
• Simulation and debugging in CENS Lab

• 10 Node ad-hoc deployable system
• 400 MHz CPU, 802.11 wireless, 1 GB flash
• 4 channel high-sensitivity acoustic array
• On-board processing capability
• Emstar-based system software provides
• Multi-hop wireless networking
• 10 microsecond multi-hop time synchronization
• 8 second sensor look-back buffer
• Automatic self-localization 4 cm position
  accuracy and 1 degree array orientation, in heavy
  foliage
• Most complex Emstar application to date
• Current users and applications
• UCLA Biology and UCLA EE Dept
• Initial tests in James Reserve, San Jacinto (May
  2006)
• Marmot localization and ID in the Rocky Mountains
  (July 2006)
• Dusky Antbird localization in Mexican rainforest
  (Sept 2006)
• California Wolf Center
• Detection and tracking of wolf calls (ongoing)
• Toyota Research project (UCLA EE)
• Marking road hazards with acoustic sensors

 
Extensible Sensing System (ESS)

• Deployable sensing system for low rate data,
  low-power operation
• Mica2 sensor motes, TinyOS
• Reconfigurable MDA300 sensor board
• Stargate-based gateway, running Emstar
• Provides
• Field-taskable system
• Reliable data delivery to backend database and
  web interface
• Current users and deployments
• James Reserve Cold Air Deployment (CAD)
  Microclimate monitoring
• Palmdale agricultural contaminant transfer
  measurement
• Bangladesh Arsenic study

Lessons Learned and EmStar Architecture Version 2
Desirable Properties
Lessons Learned
Plans for Version 2

• Status visibility
• Embedded log files
• Querying status on demand
• Centralized (Re)Initialization
• Control and Tasking
• Simulation
• Real, simulated, or playback channels
• Ability to warp time
• Keep system running
• Fault isolation
• VS. memory errors in other peoples code
• Import and export
• Plays well with others

• Emstar is too hard to write in
• Multi-process architecture is complex
• Correct recovery from failure of subcomponents is
  difficult to implement
• Emstar works well when done right but it can be
  hard to get right
• Configuration is not uniform
• Configuration is spread in many places
• Some configuration is set at run-time
• FUSD Kernel module dependency
• FUSD makes life hard for some people
• No trivial remote access
• Emphasis on processes and message passing
  introduces performance problems

• Registry-like global configuration mechanism
• One place where config is stored
• Persistent state
• Programmatic / concurrent access serialized
• Single process model with GCd language
• Mostly event driven, some long-running compute
  threads
• Integration with C libraries for compute-heavy
  operations
• Component model with standardized interfaces
• Debugging via query-able status and log-files
• In-ram log, routable to persistent store /
  network
• Sockets based version of status device
• Ability to trace and snoop on interfaces between
  components

UCLA UCR Caltech USC CSU JPL UC
Merced