NEST
NEST System Working Group
Meeting #1
Jack Stankovic
University of Virginia
11-13 September 2001
Boeing
Huntington Beach, CA
1
Presentation Outline
NEST
• Project Overview
• Research Products
• Anticipated OEP Integration and Collaboration
2
Project Overview
NEST
Title: A Network Virtual Machine for
Real-Time Coordination Services
Jack Stankovic, PI
University of Virginia
Partners: (UIUC, CMU, LM)
3
Goal
NEST
• 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.
4
Sensor/Actuator Clouds
NEST
Resource management, team formation:
real-time, mobility, power
Heterogeneous Sensors/Actuators/CPUs (macro motes)
• battlefield awareness
• pursuer/evader
5
Middleware Components
NEST
Schedulability analysis
Applications
Real-time Service APIs
In-network processing
Data placement
Congestion control
Node Placement
Routing
RT MAC
Run-time
Service
Local RT CPU Scheduling
6
Research Questions
NEST
• 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
7
The Team
NEST
REAL-TIME SERVICES
Lockheed
Martin
Applications
Req.
MMDP/
Power
CMU
Virginia
FC/
RT
Aggregate
Control
RT/
Power
Team
Coord.
Mobility/
Wireless
Data
Discovery
Illinois
8
1. Technology Development Program
NEST
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
9
2. Product Type
NEST
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)
10
Technology Areas
Coordination Services
NEST
Embedded Software
Focus Areas
Time-Bounded Synthesis
Service Composition and Adaptation
Middleware
Services
Configurations
Online
Offline
Fill In Taxonomy
For Project
Technology Challenges
CPU
Res.
Mgmt
Memory
Network
Power
Fault Tolerance
Time
Synchronization
Heterogeneous
Processing
Safety Criticality
11
4. Challenge Areas
NEST
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)
12
5. Collaborations
NEST
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
13
6. Integration Interface
NEST
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
14
7. OEP Framework Requirements
NEST
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
15
Scalability and Training
NEST
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
16
Releasibility Restrictions
NEST
• No proprietary claims.
• No releasibility restrictions.
17
Schedule
NEST
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
18