NEST 1 NEST System Working Group Meeting #1 Jack Stankovic University of Virginia September 2001 Boeing Huntington Beach, CA
NEST 2 Presentation Outline Project Overview Research Products Anticipated OEP Integration and Collaboration
NEST 3 Project Overview Title: A Network Virtual Machine for Real-Time Coordination Services Jack Stankovic, PI University of Virginia Partners: (UIUC, CMU, LM)
NEST 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.
NEST 5 Sensor/Actuator Clouds Heterogeneous Sensors/Actuators/CPUs (macro motes) Resource management, team formation: real-time, mobility, power battlefield awareness pursuer/evader
NEST 6 RT MAC Routing In-network processing Congestion control Local RT CPU Scheduling Real-time Service APIs Applications Run-time Service Node Placement Schedulability analysis Data placement Middleware Components
NEST 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
NEST 8 The Team Lockheed Martin Virginia CMUIllinois Applications Req. Aggregate Control MMDP/ Power RT/ Power FC/ RT Team Coord. Data Discovery Mobility/ Wireless REAL-TIME SERVICES
NEST 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
NEST 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)
NEST 11 Technology Areas CPU Memory Network Fault Tolerance Time Synchronization Heterogeneous Processing Middleware Services Configurations Technology Challenges Embedded Software Focus Areas Res. Mgmt Safety Criticality On- line Off- line Fill In Taxonomy For Project Power Coordination Services Time-Bounded Synthesis Service Composition and Adaptation
NEST 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)
NEST 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
NEST 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
NEST 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
NEST 16 Scalability and Training 8. Scalability a. Number of nodes: what network sizes are targeted by your technology: O(10 3 ) 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
NEST 17 Releasibility Restrictions No proprietary claims. No releasibility restrictions.
NEST 18 Schedule Motes RT-MAC RT Directed Diffusion Data Placement/Node Placement Schedulability Analysis 1/02 3/02 8/02 10/02 12/02 Integrate Power Management 12/02