1

NEST

NEST System Working GroupMeeting #1

NEST System Working GroupMeeting #1

Jack Stankovic

University of Virginia

11-13 September 2001

Boeing

Huntington Beach, CA

2

NESTPresentation OutlinePresentation Outline

• Project Overview• Research Products• Anticipated OEP Integration and Collaboration

3

NESTProject OverviewProject Overview

Title: A Network Virtual Machine for Real-Time Coordination Services

Jack Stankovic, PI

University of Virginia

Partners: (UIUC, CMU, LM)

4

NESTGoalGoal

• 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

NESTSensor/Actuator CloudsSensor/Actuator Clouds

Heterogeneous Sensors/Actuators/CPUs (macro motes)

Resource management, team formation: real-time, mobility, power

• battlefield awareness• pursuer/evader

6

NEST

RT MAC

Routing

In-network processing

Congestion control

Local RT CPU Scheduling

Real-time Service APIs

Applications

Run-timeService

Node Placement

Sch

edul

abili

ty a

naly

sis

Data placement

Middleware Components

7

NESTResearch QuestionsResearch 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

NESTThe TeamThe Team

LockheedMartin Virginia

CMU Illinois

Applications Req.

AggregateControlMMDP/

Power

RT/Power

FC/RT

TeamCoord.

DataDiscovery

Mobility/Wireless

REAL-TIME SERVICES

9

NEST1. Technology Development Program 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 2. Product Type 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

NESTTechnology AreasTechnology Areas

CPU

Memory

Network

Fault Tolerance

Time SynchronizationHeterogeneous

Processing

Middleware Services

Configurations

Tec

hn

olo

gy

Ch

alle

ng

es

Embedded SoftwareFocus Areas

Res.Mgmt

Safety Criticality

On-line

Off-line

Fill In Taxonomy For Project

Fill In Taxonomy For Project

Power

Coordination Services

Time-Bounded Synthesis

Service Composition and Adaptation

12

NEST4. Challenge Areas4. 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

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

NEST6. Integration Interface6. 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

NEST7. OEP Framework Requirements7. 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

NESTScalability and TrainingScalability 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

NESTReleasibility RestrictionsReleasibility Restrictions

• No proprietary claims.• No releasibility restrictions.

18

NESTScheduleSchedule

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