1 / 10

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

2. Embedded Networked Sensing (ENS). Seismic. Seismic detection, analysis arrays, in the CENS Seismic Array, a proposed array of 50 nodes that seeks to provide real-time recovery of seismic data from fielded nodes. Habitat Monitoring at the James Reserve. Data from multiple clusters of motes are gathered by microservers and processed. The microserver network imp-roves system scaling properties..

jamese
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. 1 EmStar: a Software Environment for Developing and Deploying Wireless Sensor Networks CENS Research Review 15 October 2004 Lewis Girod, Thanos Stathopoulos, Jeremy Elson, Martin Lukac, Andrew Parker, Ning Xu, Rahul Kapur, Deborah Estrin CENS Systems Lab

    2. 2 Embedded Networked Sensing (ENS)

    3. 3 Why a new S/W environment? Logistical and environmental issues in deployment Fielded systems tend to degrade more quickly than in the lab Environmental conditions: weather, animals, RF and sensor channel Uniform deployments are difficult to achieve: node replacement Observed Data can cause unexpected failures, new bugs in the field e.g. Acoustic ranging system encountered new kinds of noise, leading to new kinds of inconsistencies in geometry, crashing Non-Linear Least-Squares (NLLS) algorithm but not reproducible in the lab

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

    5. 5 Libraries, Tools, Services Libraries and IPC Support FUSD: IPC via device file interfaces Device Patterns: Libraries that provide standard kinds of devices. Status Device, Packet Device, Sensor Device EmTOS NesC/TinyOS compatibility wrapper Tools EmRun: Manage running EmStar processes and collect logs EmSim/EmCee: A real-code simulator that can support real radios EmView: A visualization tool Services Link/Neighborhood estimation Time Synchronization Routing: Flooding, Sink Tree, Diffusion

    6. 6 EmTOS: Support for Heterogeneous Systems Wrapper Library Provides TinyOS API and Services Enables NesC to provide new EmStar services Compiles NesC Application + EmTOS library into a single EmStar module Benefits: Simulate systems of motes and microservers in same world Easy porting of TinyOS/NesC services to microservers ESS2 TinyDB

    7. 7 EmSim/EmCee EmSim: a real code simulation environment for EmStar Runs N copies of an EmStar system on a single machine Each node gets its own device namespace Sim components provide interface to simulated world sim_radio: models an RF channel and MAC layer sim_sensor: models or replays sensor data EmCee: simulated nodes use real radios for comm Runs N copies of an EmStar system, connects each nodes link device to a real Mote radio connected by a serial multiplexer

    8. 8 Visibility and Debugging Why is Visibility important? Reveals internal state of modules Reveals traffic between modules, e.g. Observe when each neighbor update is issued Observe data traffic through network stack How: Browsable Device File Hierarchy Similar to /proc, modules report their internal state Human readable and binary versions Binary channel used for IPC Same info visible interactively from the shell Enables Debugging Locate faults by verifying modules input and output Visualize distributed system including dynamics In simulation In real life with debugging backchannel

    9. 9 Robustness and Fault Tolerance Why is robustness so important? Degradation in presence of permanent HW, SW faults Recovery from transient faults, limiting cascading failures e.g. unanticipated sensor data Unusual cases that yield inconsistent or confusing data Microkernel Implementation FUSD (Framework for User Space Devices) Fault isolation between client, server, and kernel Servers robust to faulty clients Modules communicate through POSIX Device API Inter-module Fault Tolerance Similar approach as in distributed systems Survive a range of errors and module failures Soft-state protocols between modules Rate limiting, filtering, refresh at module interfaces

    10. 10 Conclusion An environment for developing complex distributed systems Designed specifically to support ENS system deployment Enables seamless migration deployment ??simulation Easy to integrate with systems of TinyOS motes via EmTOS

    11. 11 Thank You More information: The EmStar website, for downloads, documentation, mailing lists: http://cvs.cens.ucla.edu/emstar A System for Simulation, Emulation, and Deployment of Heterogeneous Sensor Networks in SenSys 2004: http://lecs.cs.ucla.edu/~girod/papers/emtos-sensys04.pdf EmStar: a Software Environment for Developing and Deploying Wireless Sensor Networks, in USENIX 2004: http://lecs.cs.ucla.edu/~girod/papers/emstar-usenix04.pdf

More Related