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!
January 27, 2006 BOSS: snBench Overview 3
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
January 27, 2006 BOSS: snBench Overview 4
Sensorium Infrastructure
Sensorium: A common space equipped with video sensors (VS) for ubiquitous recognition and tracking of activities therein
January 27, 2006 BOSS: snBench Overview 5
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!
January 27, 2006 BOSS: snBench Overview 6
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/…
January 27, 2006 BOSS: snBench Overview 7
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?
January 27, 2006 BOSS: snBench Overview 8
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”
January 27, 2006 BOSS: snBench Overview 9
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)
January 27, 2006 BOSS: snBench Overview 10
SNAFU: SNet Apps as FUnctions!
Functional specification language e.g., identify the face seen through camera 1
identify(facefind(snapshot(cam1)))
January 27, 2006 BOSS: snBench Overview 11
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)))
January 27, 2006 BOSS: snBench Overview 12
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”)
January 27, 2006 BOSS: snBench Overview 13
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)))
January 27, 2006 BOSS: snBench Overview 14
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)
January 27, 2006 BOSS: snBench Overview 15
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
January 27, 2006 BOSS: snBench Overview 16
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
January 27, 2006 BOSS: snBench Overview 17
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)) )
January 27, 2006 BOSS: snBench Overview 18
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
January 27, 2006 BOSS: snBench Overview 20
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
January 27, 2006 BOSS: snBench Overview 21
STEP: Sensorium Typed Exec Plan
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
January 27, 2006 BOSS: snBench Overview 22
STEP: Sensorium Typed Exec Plan
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
January 27, 2006 BOSS: snBench Overview 23
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>
January 27, 2006 BOSS: snBench Overview 24
SnBench: Runtime components
SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher
SSD, SXE
SXESXE
SXE
SXE
SXE
SXE
SXE, Compiler
January 27, 2006 BOSS: snBench Overview 25
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]
January 27, 2006 BOSS: snBench Overview 26
Map, Link, and Dispatch
SXE
SXE
SXE
edge_trigger
cam2
snapshot
motion
clock 4AM2AM
< <
&&
January 27, 2006 BOSS: snBench Overview 27
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
January 27, 2006 BOSS: snBench Overview 28
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
cam2
snapshot
motion
clock 4AM2AM
< <
&&
January 27, 2006 BOSS: snBench Overview 29
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%
January 27, 2006 BOSS: snBench Overview 30
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
January 27, 2006 BOSS: snBench Overview 31
Scheduling: Node Capabilities
Sensorium Resource Manager Keeps track of STEP activity, known sensors
SXE
SXESXE
SXE
[empty]
delta
oflow
motion
bodytrack
facefind
delta
[empty]
[empty]
motion
delta
snapshot
SSD/SRM
V01
S03
S02
S01
January 27, 2006 BOSS: snBench Overview 32
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”
January 27, 2006 BOSS: snBench Overview 33
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.”))
January 27, 2006 BOSS: snBench Overview 34
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
cam2
snapshot
motion
clock 4am2am
< <
&&
trigger
trigger
“He’s working late again”
facerecognizer
facelibrary
“Azer Bestavros”
January 27, 2006 BOSS: snBench Overview 35
Com
mon
Subgra
ph
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
cam2
snapshot
motion
clock 4am2am
< <
&&
trigger
trigger
“He’s working late again”
facerecognizer
facelibrary
“Azer Bestavros”
January 27, 2006 BOSS: snBench Overview 36
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
cam2
snapshot
lights_are_on
clock 4AM2AM
< <
logical_and
trigger
cam2
snapshot
lights_are_on
clock 4AM2AM
< <
logical_and
trigger
trigger
“He’s working late again”
facerecognizer
facelibrary
“Azer Bestavros”
Common Subexpression/Subgraph Elimination
January 27, 2006 BOSS: snBench Overview 37
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))
January 27, 2006 BOSS: snBench Overview 38
SnBench: Runtime components
SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher
SSD, SXE
SXESXE
SXE
SXE
SXE
SXE
SXE, Compiler
January 27, 2006 BOSS: snBench Overview 39
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
January 27, 2006 BOSS: snBench Overview 40
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?
January 27, 2006 BOSS: snBench Overview 41
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)
January 27, 2006 BOSS: snBench Overview 42
Intrinsic Research: Expressive PL
Better Programming Languages Alternate Execution Environments
STEP
SNAFUSnQL SnLOG
SnC
SXEJ2ME
Native CJXTA
January 27, 2006 BOSS: snBench Overview 43
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