1. http://www.cs.bu.edu/groups/wing snBENCH A Development and Run-Time Platform for Rapid Deployment of Sensor Network Applications Michael Ocean Azer Bestavros & Assaf Kfoury & Adam Bradley Computer Science Department Boston University BOSS January 27 th 2006

2. January 27, 2006BOSS: snBench Overview2 Imagine a networked world of...... sensors, actuators, processors and storage, which is part of a shared physical infrastructure Not hard to imagine!

3. January 27, 2006BOSS: snBench Overview3 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

4. January 27, 2006BOSS: snBench Overview4 Sensorium Infrastructure Sensorium: A common space equipped with video sensors (VS) for ubiquitous recognition and tracking of activities therein

5. January 27, 2006BOSS: snBench Overview5 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!

6. January 27, 2006BOSS: snBench Overview6 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/…

7. January 27, 2006BOSS: snBench Overview7 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?

8. January 27, 2006BOSS: snBench Overview8 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”

9. January 27, 2006BOSS: snBench Overview9 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)

10. January 27, 2006BOSS: snBench Overview10 SNAFU: SNet Apps as FUnctions!  Functional specification language e.g., identify the face seen through camera 1 identify(facefind(snapshot(cam1)) )

11. January 27, 2006BOSS: snBench Overview11 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)) )

12. January 27, 2006BOSS: snBench Overview12 SNAFU: SNet Apps as FUnctions  Functional specification language e.g., variable assignment works as in functional languages let x = grabframe(cam1) in cond(facefind(x), identify(facecount(x)), “no faces found”)

13. January 27, 2006BOSS: snBench Overview13 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(“security@bu.edu”, trigger( (motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)))

14. January 27, 2006BOSS: snBench Overview14 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 Trigger P = True P = False trigger(greater(roomtemp,”80c”),hvac_heatoff)

15. January 27, 2006BOSS: snBench Overview15 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 Trigger P = True P = False

16. January 27, 2006BOSS: snBench Overview16 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 Trigger P = True P = False

17. January 27, 2006BOSS: snBench Overview17 Extension: Annotating triggers  Level triggers could be made periodic This 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)) )

18. January 27, 2006BOSS: snBench Overview18 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 Trigger P = True P = False Time Non-blocking Blocking Fresh Read

19. January 27, 2006BOSS: snBench Overview19 Trigger “recursion”  LAST_TRIGGER_EVAL construct Allows the body of a trigger to access the value returned at the “last” evaluation of that trigger  LTE is the only recursion form in SNAFU Example: down-counter 5 to 1 level_trigger( not(equals(0,LTE)), cond(isnil(LTE),5,subtract(LTE,1)) )

20. January 27, 2006BOSS: snBench Overview20 STEP: Sensorium Typed Exec Plan subtract LTE 0 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 1

21. January 27, 2006BOSS: snBench Overview21 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 subtract LTE 0 cond isnilequals level_trigger not LTE 5 1

22. January 27, 2006BOSS: snBench Overview22 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... subtract LTE 0 cond isnilequals level_trigger not LTE 5 1

23. January 27, 2006BOSS: snBench Overview23 STEP: XML Representation Serialized STEP graph represented in XML level_trigger( not(equals(0,LTE)), cond(isnil(LTE),5,subtract(LTE,1)) ) 0 5 1

24. January 27, 2006BOSS: snBench Overview24 SnBench: Runtime components SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher SSD, SXE SXE SXE, Compiler

25. January 27, 2006BOSS: snBench Overview25 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]

26. January 27, 2006BOSS: snBench Overview26 Map, Link, and Dispatch SXE edge_trigger email “security@bu.edu” cam2 snapshot motion clock4AM 2AM << &&

27. January 27, 2006BOSS: snBench Overview27 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

28. January 27, 2006BOSS: snBench Overview28 Intrinsic Research: Scheduling  Map & Link Challenges How did we arrive at this partitioning? How did we arrive at these assignments? SXE

29. January 27, 2006BOSS: snBench Overview29 Scheduling: Processing Capacity SXE  Sensorium Resource Manager Keeps track of CPU loading conditions SSD/ SRM V01 10% S03 33% S02 98% S01 45%

30. January 27, 2006BOSS: snBench Overview30 Scheduling: Network Capacity  Sensorium Resource Manager Keeps track of current network conditions SXE 100Mb/s 20% 512kb/s 75% 8Mb/s 95% 100Mb/s 40% SSD/ SRM S02-v01 75% 512kb S03-v01 20% 100mb S01-S03 40% 100mb S01-S02 95% 8mb

31. January 27, 2006BOSS: snBench Overview31 Scheduling: Node Capabilities  Sensorium Resource Manager Keeps track of STEP activity, known sensors SXE [empty] delta oflow motion email bodytrack facefind delta [empty] email motion delta snapshot SSD/ SRM V01 S03 S02 S01

32. January 27, 2006BOSS: snBench Overview32 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”

33. January 27, 2006BOSS: snBench Overview33 Intrinsic Research: Scheduling Different programs may share STEP sub-graphs Examples: email(“security@bu.edu”, trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2))) trigger( facerecognizer( trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)), facelibrary(“Azer Bestavros”)), email(“azer.wife@cs.bu.edu”, “He’s working late again.”))

34. January 27, 2006BOSS: snBench Overview34 email(“security@bu.edu”, trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2))) trigger( facerecognizer( trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)), facelibrary(“Azer Bestavros”)), email(“azer.wife@cs.bu.edu”, “He’s working late again.”)) STEP Scheduling: CSE Common Subexpression/Subgraph Elimination cam2 snapshot motion clock4AM 2AM << && trigger email “security@bu.edu” cam2 snapshot motion clock4am 2am << && trigger email “azer.wife@cs.bu.edu” trigger “He’s working late again” facerecognizer facelibrary “Azer Bestavros”

35. January 27, 2006BOSS: snBench Overview35 Common Subgraph email(“security@bu.edu”, trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2))) trigger( facerecognizer( trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)), facelibrary(“Azer Bestavros”)), email(“azer.wife@cs.bu.edu”, “He’s working late again.”)) STEP Scheduling: CSE Common Subexpression/Subgraph Elimination cam2 snapshot motion clock4AM 2AM << && trigger email “security@bu.edu” cam2 snapshot motion clock4am 2am << && trigger email “azer.wife@cs.bu.edu” trigger “He’s working late again” facerecognizer facelibrary “Azer Bestavros”

36. January 27, 2006BOSS: snBench Overview36 email(“security@bu.edu”, trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2))) trigger( facerecognizer( trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)), facelibrary(“Azer Bestavros”)), email(“azer.wife@cs.bu.edu”, “He’s working late again.”)) STEP Scheduling: CSE cam2 snapshot lights_are_on clock4AM 2AM << logical_and trigger email “security@bu.edu” cam2 snapshot lights_are_on clock4AM 2AM << logical_and trigger email “azers.wife@cs.bu.edu” trigger “He’s working late again” facerecognizer facelibrary “Azer Bestavros” Common Subexpression/Subgraph Elimination

37. January 27, 2006BOSS: snBench Overview37 Intrinsic Research: Compilation  Program Optimization What to optimize?  STEP Node count?  Trigger count? let x = snapshot(cam2) in email(“security@bu.edu”, block(edge_trigger(motion(x) && (2am<NOW<4am), x))) let x = snapshot(cam2) in trigger( edge_trigger(motion(x) && (2am<NOW<4am), true), email(“security@bu.edu”, x))

38. January 27, 2006BOSS: snBench Overview38 SnBench: Runtime components SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher SSD, SXE SXE SXE, Compiler

39. January 27, 2006BOSS: snBench Overview39 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

40. January 27, 2006BOSS: snBench Overview40 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?

41. January 27, 2006BOSS: snBench Overview41 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)

42. January 27, 2006BOSS: snBench Overview42 Intrinsic Research: Expressive PL  Better Programming Languages  Alternate Execution Environments STEP SNAFU SnQL SnLOG SnC SXE J2ME Native C JXTA

43. January 27, 2006BOSS: snBench Overview43 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