1 / 18

NEST System Working Group Meeting #1

This project aims to develop a network virtual machine that abstracts and guarantees real-time behavior for unreliable and mobile networks, enabling coordination and control in sensor, actuator, and processor networks.

uresti
Download Presentation

NEST System Working Group Meeting #1

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. NEST System Working GroupMeeting #1 Jack Stankovic University of Virginia 11-13 September 2001 Boeing Huntington Beach, CA

  2. Presentation Outline • Project Overview • Research Products • Anticipated OEP Integration and Collaboration

  3. Project Overview Title: A Network Virtual Machine for Real-Time Coordination Services Jack Stankovic, PI University of Virginia Partners: (UIUC, CMU, LM)

  4. Goal • Create a network virtual machine that is a coordination and control layer (middleware) that • abstracts (API) • controls, and • guarantees aggregate real-time behavior for unreliable and mobile networks of sensors, actuators, and processors.

  5. Sensor/Actuator Clouds Resource management, team formation: real-time, mobility, power Heterogeneous Sensors/Actuators/CPUs (macro motes) • battlefield awareness • pursuer/evader

  6. Middleware Components Applications Real-time Service APIs In-network processing Data placement Node Placement Congestion control Routing Schedulability analysis RT MAC Run-time Service Local RT CPU Scheduling

  7. Research Questions • Invention of new lightweight protocols that can support guaranteed aggregate behavior • real-time • power • mobility • limited processing and memory capacity • large scale • Solutions based on • diffusion type algorithms with aggregation • randomness • feedback control principles/RT/ uncertainty/overload control • MMDP • real-time scheduling theory

  8. The Team REAL-TIME SERVICES Lockheed Martin Virginia Aggregate Control FC/ RT Applications Req. Team Coord. Mobility/ Wireless Data Discovery MMDP/ Power CMU Illinois RT/ Power

  9. 1. Technology Development Program • Berkeley OEP: • Real-time run-time services with aggregate performance guarantees (UVA and UIUC) • Power management and control in wireless communication (UIUC and CMU) • Merge results • Coordinating visit between UVA and UIUC in August • Coordinating visit between UIUC and LM • Boeing OEP • Consensus protocols (UVA and Xerox Parc): coordinating visit already completed in August

  10. 2. Product Type X___Operating system software X___Middleware _____Application software (noise control for Boeing OEP, pursuer/evader for Berkeley OEP) _____Configuration software X___Algorithms / theoretical foundations (please describe within comments) _____Tools (please describe) _____Other (please describe)

  11. Technology Areas Coordination Services Time-Bounded Synthesis Service Composition and Adaptation Embedded Software Focus Areas Middleware Services Configurations On- line Off- line Fill In Taxonomy For Project Technology Challenges Res. Mgmt CPU Memory Network Power Fault Tolerance Time Synchronization Heterogeneous Processing Safety Criticality

  12. 4. Challenge Areas 4. Challenge Area Classification:(Indicate all challenge area(s) targeted by your research.) a. Lifecycle: Is your technology targeted to: ____ design time (e.g. tools, techniques used during system development) X___ run time (e.g. online software) b. Domain: Is your technology targeted to: _____ application domain (e.g. noise control, pursuer evader games) X____ solution domain (software/system design related issues, e.g. middleware) c. Solution domain issues: Is your technology targeted to: _____ fault detection X____ online reconfiguration (possibly in response to faults) _____ offline configuration _____ time synchronization X____ group membership (online determination of group members) X____ group consensus (collaboration of group members towards aggregate goals) X____ probabilistic methods _____ other (please describe)

  13. 5. Collaborations • a. OEP collaboration: Are you expecting at this point to work with: • X____ Berkeley OEP • X____ Boeing OEP • b. Group I collaboration: • Xerox Parc: Consensus protocols for Boeing OEP • Intra-group (UVA, UIUC, CMU, and LM): Real-time services for Berkeley OEP

  14. 6. Integration Interface a. Provided interfaces Berkley OEP: high level APIs specifying environmental queries, commands and their aggregate real-time requirements (periods and deadlines) EXAMPLES: activity(area,event,ST,DU,P,D,MP,e) set_lifetime(L) b. Required interfaces: Boeing OEP: noise model and local vibration control Berkley OEP: Fine except for more memory, perhaps offload more from CPU to HW

  15. 7. OEP Framework Requirements • X___ Network (e.g. wireless, TTA, Ethernet, Fibre-channel), specifically: • Berkeley OEP: wireless • Boeing OEP: Switched Ethernet • ____Operating system, specifically: • X___Threads (e.g. single-threaded, preemptive multi-threaded), specifically: • Berkley OEP: preemptive multithreaded architecture • X___Scheduling protocols (e.g. static/dynamic, RMS, EDF, MUF), specifically: • A real-time scheduling policy, e.g., EDF or RMS • X___Other (describe): • Berkeley OEP • More RAM/ROM for code and data • Additional HW handling bits from radio

  16. Scalability and Training 8. Scalability a. Number of nodes: what network sizes are targeted by your technology: O(103) b. Memory: what node memory requirements are targeted by your technology: >100KB 9. Training Requirements: Real-time scheduling theory Control theory Markov decision process Our APIs - compliant with the TinyOS component interface

  17. Releasibility Restrictions • No proprietary claims. • No releasibility restrictions.

  18. Schedule 1/02 Motes 3/02 RT-MAC 8/02 RT Directed Diffusion 10/02 Data Placement/Node Placement 12/02 Schedulability Analysis 12/02 Integrate Power Management

More Related