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

1. 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

2. January 27, 2006 BOSS: snBench Overview 2 Imagine a networked world of ... Different sensors Different scale Need horsepower Different sensors Different scale Need horsepower

3. 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

4. January 27, 2006 BOSS: snBench Overview 4 Sensorium Infrastructure

5. 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!

6. 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/�

7. 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)

8. 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�

9. 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)

10. January 27, 2006 BOSS: snBench Overview 10 SNAFU: SNet Apps as FUnctions! Functional specification language e.g., identify the face seen through camera 1 High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations� High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations�

11. 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 High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations� High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations�

12. January 27, 2006 BOSS: snBench Overview 12 SNAFU: SNet Apps as FUnctions Functional specification language e.g., variable assignment works as in functional languages  High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations� High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations�

13. 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� High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations� High level language � glue for the building blocks� Trigger = interrupts Evaluate both arguments of email to enable it. Once enabled it will fire.. Inherent characteristics of different versions of �trigger� would be spelled out as annotations�

14. 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

15. 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

16. 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

17. January 27, 2006 BOSS: snBench Overview 17 Extension: Annotating triggers Level triggers could be made periodic This is an example of scheduling annotations Persistent triggers could have explicit longevity

18. 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

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

20. January 27, 2006 BOSS: snBench Overview 20 STEP: Sensorium Typed Exec Plan SNAFU compiles to STEP language of functions ? language of graphsSNAFU compiles to STEP language of functions ? language of graphs

21. 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 SNAFU compiles to STEP language of functions ? language of graphsSNAFU compiles to STEP language of functions ? language of graphs

22. 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... SNAFU compiles to STEP language of functions ? language of graphsSNAFU compiles to STEP language of functions ? language of graphs

23. January 27, 2006 BOSS: snBench Overview 23 STEP: XML Representation Serialized STEP graph represented in XML

24. January 27, 2006 BOSS: snBench Overview 24 SnBench: Runtime components SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher SXE = processor for STEP instruction set SD = linker and loaderSXE = processor for STEP instruction set SD = linker and loader

25. 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]

26. January 27, 2006 BOSS: snBench Overview 26 Map, Link, and Dispatch SD matches (linker analogy) available infrastructural resources to subgraphs from the compiled STEP code and dispatches (loader functionality)SD matches (linker analogy) available infrastructural resources to subgraphs from the compiled STEP code and dispatches (loader functionality)

27. 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

28. 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?

29. January 27, 2006 BOSS: snBench Overview 29 Scheduling: Processing Capacity Sensorium Resource Manager Keeps track of CPU loading conditions

30. January 27, 2006 BOSS: snBench Overview 30 Scheduling: Network Capacity Sensorium Resource Manager Keeps track of current network conditions

31. January 27, 2006 BOSS: snBench Overview 31 Scheduling: Node Capabilities Sensorium Resource Manager Keeps track of STEP activity, known sensors

32. 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�

33. January 27, 2006 BOSS: snBench Overview 33 Intrinsic Research: Scheduling Different programs may share STEP sub-graphs Examples:

34. January 27, 2006 BOSS: snBench Overview 34 STEP Scheduling: CSE Common Subexpression/Subgraph Elimination

35. January 27, 2006 BOSS: snBench Overview 35 STEP Scheduling: CSE Common Subexpression/Subgraph Elimination

36. January 27, 2006 BOSS: snBench Overview 36 STEP Scheduling: CSE

37. January 27, 2006 BOSS: snBench Overview 37 Intrinsic Research: Compilation Program Optimization What to optimize? STEP Node count? Trigger count?

38. January 27, 2006 BOSS: snBench Overview 38 SnBench: Runtime components SXE: Sensorium eXecution Environment SSD: Sensorium Service Dispatcher SXE = processor for STEP instruction set SD = linker and loaderSXE = processor for STEP instruction set SD = linker and loader

39. 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

40. 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?

41. 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)

42. January 27, 2006 BOSS: snBench Overview 42 Intrinsic Research: Expressive PL Better Programming Languages Alternate Execution Environments

43. 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