1. NEST 1 NEST System Working Group Meeting #1 Jack Stankovic University of Virginia 11-13 September 2001 Boeing Huntington Beach, CA

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

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

4. 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.

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

6. 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

7. 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

8. 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

9. 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

10. NEST 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. 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

12. NEST 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. NEST 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. NEST 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. NEST 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. 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

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

18. 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