Http:// snBENCH A Development and Run-Time Platform for Rapid Deployment of Sensor Network...

http://www.cs.bu.edu/groups/wing

snBENCH

A Development and Run-Time Platform for Rapid Deployment of Sensor Network Applications

Michael OceanAzer Bestavros & Assaf Kfoury & Adam Bradley

Computer Science DepartmentBoston University

BOSSJanuary 27th 2006

January 27, 2006 BOSS: snBench Overview 2

Imagine a networked world of ...

... sensors, actuators, processors and storage,which is part of a shared physical infrastructure

Not hard to imagine!


Evolving Sensor Networks

Traditional Sensor Networks : Highly constrained

computation, communication, power, etc.

Shared single common goal Singularly tasked entities Program the nodes

Our domain: Heterogeneous/Hybrid networks

Not all devices/networks are uniformly constrained Shared, transient entities

Multiple, potentially conflicting goals Program the network


Sensorium Infrastructure

Sensorium: A common space equipped with video sensors (VS) for ubiquitous recognition and tracking of activities therein


Sensoria: A Paradigm Shift

The proliferation of networked, embedded, and mobile digital video sensors requires a paradigm shift in many areas of CS to address: The unique spatio-temporal aspects of sensory (video)

data acquisition, processing, representation, communication, storage, real-time indexing/retrieval, data mining

The challenges of programming, QoS management and coordinated resource arbitration of sensory networks, which are both embedded and mobile

The other extreme in sensor networks research!


Sensoria: Example Deployments

Assistive Environments e.g. for home/hospice/elder care/…

Safety Monitoring e.g. in factories/daycare/hospitals/garages/subway…

Intelligent Spaces e.g. for classrooms/meeting rooms/theaters/farms…

Secure Facilities and Homeland Security Uses e.g. at airports/embassies/prisons/…

People Flow/Activity Studies e.g. at retail stores/museums/…


snBench: SN Workbench

The Sensorium is the computer…Design/implement the programming and run-time infrastructure necessary for developers to specify and deploy truly distributed applications over a heterogeneous network of Sensing Elements (SEs) and of Computing Elements (CEs)

What sensors could I use and what functionality do I

get from them?


snBench: Goals

“Write Once, Run… Wherever” Don’t program nodes…

Program the network! Start with building blocks

Sensors Stock algorithms (edge detect, face count, FFT)

Glue together with high-level language Conditionals, loops, functions

Pretend the network isn’t there Location agnostic

“Single System Image”


snBench: Programming Cycle

Program Program specified by gluing together building blocks

using SNAFU language Compile

SNAFU program is compiled to produce a plan of execution expressed in STEP

Map and Link STEP plans are decomposed in smaller dispatch-able

STEPs which are linked Load and Execute

STEP plans are dispatched (i.e., loaded) onto a common runtime/execution environments (SXEs)


SNAFU: SNet Apps as FUnctions!

Functional specification language e.g., identify the face seen through camera 1

identify(facefind(snapshot(cam1)))


SNAFU: SNet Apps as FUnctions!

Use “annotative” functions for constraints e.g., what streams can be “exposed”

e.g., minimum acceptable resolution

public(facecount(snapshot(private(cam1)))))

facecount(resn(800x600x24b,snapshot(cam1)))


SNAFU: SNet Apps as FUnctions

Functional specification language e.g., variable assignment works as in functional

languages

let x = grabframe(cam1) incond(facefind(x),

identify(facecount(x)),“no faces found”)


Persistence and Iteration

SNAFU does not allow recursion Events in time, persistent computation

achieved through the “trigger” construct

Two general types of triggers: Transient – i.e., will expire naturally Persistent – i.e, will run “forever”

email(“[email protected]”, trigger( (motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)))


Transient: “wait until” Trigger

“Wait until p becomes true to evaluate a” trigger(p,a)

do {} until (p) ;

return (a) ;

Once fired, evaluation of trigger is complete

Time

Tri

gger

P = True

P = False

trigger(greater(roomtemp,”80c”),hvac_heatoff)


Persistent (1): Level Trigger

“On Every” “As long as p is true re-evaluate a”

level_trigger(p,a) while(true)

if (p) return (a);

Level triggers are persistent queries that return a stream of evaluations of “a” while “p” is true

Time

Tri

gger

P = True

P = False


Persistent (2): Edge Trigger

“On Every First” “When p becomes true re-evaluate a”

edge_trigger(p,a) while(true)

if (p) {return(a); while(p) {}};

Edge triggers are persistent queries that return a stream of evaluations of “a” every time “p” transitions from false to true

Time

Tri

gger

P = True

P = False


Extension: Annotating triggers

Level triggers could be made periodicThis is an example of scheduling annotations

Persistent triggers could have explicit longevity

period(100ms, level_trigger(motion(cam1),snapshot(cam1)) )

expires(10min, level_trigger(motion(cam1),snapshot(cam1)) )


Triggers: Accessing results

persistent triggers values change over time Three trigger “read” semantics:

Non-blocking read - Last result is returned Blocking read - Wait for next result Fresh read - Wait for a “from scratch” result

Tri

gger

P = True

P = False

Time

Non-b

lock

ing

Blo

ckin

g

Fre

sh

Read


STEP: Sensorium Typed Exec Plan

subtractLTE0

cond

isnilequals

level_trigger

not

SNAFU -compiled-into-> STEP

“Instruction Set Architecture”

Directed Acyclic Graph

level_trigger(

not(equals(0,LTE)),

cond(isnil(LTE),

5,

subtract(LTE,1)

)

)

LTE

5

LTE 1



Notes: “Evaluation”

percolates up from leaf nodes toward roots.

Value Nodes are always leaves.

Expression nodes evaluate once then disable themselves.

Trigger nodes re-enable children for re-evaluation.

LTE reads a trigger

subtractLTE0

cond

isnilequals

level_trigger

not

LTE

5

LTE 1



STEP is the execution plan: an XML representation of this DAG

“Let” nodes do not exist, they are directives to point multiple edges to the same node.

Recursion is not allowed Cycles are prohibited LTE is like a “cycle-

safe” cycle...

subtractLTE0

cond

isnilequals

level_trigger

not

LTE

5

LTE 1


STEP: XML Representation

Serialized STEP graph represented in XML level_trigger( not(equals(0,LTE)), cond(isnil(LTE),5,subtract(LTE,1)) )

<stepgraph id="prog_count"> <level_trigger id="TriggerHead"> <exp id="not" opcode="sxe.core.not"> <exp id="equals" opcode="sxe.core.equals"> <value id="0"> <snobject type="snbench/integer">0</snobject> </value> <last_trigger_eval id="lte" target="TriggerHead"/> </exp> </exp> <exp id="cond" opcode="sxe.core.cond"> <exp id="isnil" opcode="sxe.core.isnil"> <last_trigger_eval id="lte1" target="TriggerHead"/> </exp> <value id="start_value"> <snobject type="snbench/integer">5</snobject> </value> <exp id="subtract" opcode="sxe.core.math.subtract"> <last_trigger_eval id="lte2" target="TriggerHead"/> <value id="1"> <snobject type="snbench/integer">1</snobject> </value> </exp> </exp> </level_trigger></stepgraph>


SnBench: Runtime components

SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher

SSD, SXE

SXESXE

SXE

SXE

SXE

SXE

SXE, Compiler


SSD: STEP Decomposition

Given the state of the resources in the SN, split the STEP into smaller STEPs to be deployed onto available resources Insert into the sub-STEPs additional nodes

(e.g., network sockets) that allow the sub STEPs to compute the larger STEP

Find a partitioning that minimizes new computation i.e., maximize the reuse of already deployed STEP

nodes [Mapping and linking]


Map, Link, and Dispatch

SXE

SXE

SXE

edge_trigger

email

“[email protected]”

cam2

snapshot

motion

clock 4AM2AM

< <

&&


STEP: Linked Representation

A “linked” STEP graph includes bindings to physical resources, includes additional nodes (sockets) to reconnect flow of computation despite partitioning across physical resources


Intrinsic Research: Scheduling

Map & Link Challenges How did we arrive at this partitioning? How did we arrive at these assignments?

SXE

SXE

SXE

edge_trigger

email


cam2

snapshot

motion

clock 4AM2AM

< <

&&


Scheduling: Processing Capacity

SXE

SXESXE

SXE

Sensorium Resource Manager Keeps track of CPU loading conditions

SSD/SRM

V01 10%

S03 33%

S02 98%

S01 45%


Scheduling: Network Capacity

Sensorium Resource Manager Keeps track of current network conditions

SXE

SXESXE

SXE100Mb/s

20%

512kb/s75%

8Mb/s95%

100Mb/s40% SSD/

SRM

S02-v01 75% 512kb

S03-v01 20% 100mb

S01-S03 40% 100mb

S01-S02 95% 8mb


Scheduling: Node Capabilities

Sensorium Resource Manager Keeps track of STEP activity, known sensors

SXE

SXESXE

SXE

[empty]

delta

oflow

motion

email

bodytrack

facefind

delta

[empty]

[empty]

email

motion

delta

snapshot

SSD/SRM

V01

S03

S02

S01


SSD:Partitioning and Reuse

Scheduling amounts to a constrained graph embedding problem Difficult (NP-hard) Problem Approximations and heuristics

Different programs may share STEP sub-graphs Such situations are obvious candidates for “reuse”


Intrinsic Research: Scheduling

Different programs may share STEP sub-graphs Examples:

email(“[email protected]”, trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)))

trigger( facerecognizer( trigger((motion(snapshot(cam2)) && (2am<NOW<4am)),

snapshot(cam2)), facelibrary(“Azer Bestavros”)), email(“[email protected]”, “He’s working late again.”))





STEP Scheduling: CSE

Common Subexpression/Subgraph Elimination

cam2

snapshot

motion

clock 4AM2AM

< <

&&

trigger

email


cam2

snapshot

motion

clock 4am2am

< <

&&

trigger

email


trigger

“He’s working late again”

facerecognizer

facelibrary

“Azer Bestavros”


Com

mon

Subgra

ph






cam2

snapshot

motion

clock 4AM2AM

< <

&&

trigger

email


cam2

snapshot

motion

clock 4am2am

< <

&&

trigger

email


trigger


facerecognizer

facelibrary







cam2

snapshot

lights_are_on

clock 4AM2AM

< <

logical_and

trigger

email


cam2

snapshot

lights_are_on

clock 4AM2AM

< <

logical_and

trigger

email


trigger


facerecognizer

facelibrary




Intrinsic Research: Compilation

Program Optimization

What to optimize? STEP Node count? Trigger count?

let x = snapshot(cam2) inemail(“[email protected]”, block(edge_trigger(motion(x) && (2am<NOW<4am), x)))

let x = snapshot(cam2) intrigger( edge_trigger(motion(x) && (2am<NOW<4am), true), email(“[email protected]”, x))


SnBench: Runtime components

SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher

SSD, SXE

SXESXE

SXE

SXE

SXE

SXE

SXE, Compiler


Sensor eXecution Environment

What does it do? Provides an abstraction to the sensing and

computing capabilities of an SN participant STEP --> action

Communication via HTTP Receives STEP programs via HTTP post Give results via HTTP server (XML, open

standards based representations) Communicates current state/load to SSD/SRM

via HTTP post Sensor interaction/abstraction

Video:Java Media Framework Temperature: UDP


Sensor eXecution Environment

What does it do? Java 1.5 based classes for web server, web client,

XML parser, STEP interpreter, XSLT (markup XML results) and the core functionalities

core suite of “basic sensing and computing functionalities” For each exp node, there is an implementation of

the so-called “opcode” in sxe.core Limitations

Client must be able to run a Java run-time to participate, right?


SXEs

What if we can’t run SXE on a node?

STEP: as a virtual ISA Embedded C dialects? Java ME?

Alternate linking protocols Serial (base station) SN wireless protocols (e.g.

802.15.4)


Intrinsic Research: Expressive PL

Better Programming Languages Alternate Execution Environments

STEP

SNAFUSnQL SnLOG

SnC

SXEJ2ME

Native CJXTA


snBench: Status

Skeleton of snBench is done Basic SNAFU-STEP compiler Basic SSD

Basic STEP dispatcher Basic SRM

Basic SXE for Mid-powered computing nodes Sensor integration for

Video sensing Berkeley Motes (temperature)

DEMO

Http:// snBENCH A Development and Run-Time Platform for Rapid Deployment of Sensor Network...

Documents

Transcript of Http:// snBENCH A Development and Run-Time Platform for Rapid Deployment of Sensor Network...