1. Bridging the Gap Philip Levis, UC Berkeley David Gay, Intel Research Berkeley David Culler, UC Berkeley Programming Sensor Networks with Application Specific Virtual Machines

2. 4.vi.2004NEST Retreat1 Sensor Network Deployments Need to modify behavior after deployment –Evolving requirements, parameter tuning Energy is the critical resource Embedment complicates node failure

3. 4.vi.2004NEST Retreat2 Sensor Network Deployments Need to modify behavior after deployment –Evolving requirements, parameter tuning Energy is the critical resource Embedment complicates node failure We need an efficient and safe way to reprogram sensor network deployments.

4. 4.vi.2004NEST Retreat3 Application-Specificity Deployments are for an application class –Tracking, habitat monitoring –Don’t need complete generality in a given network Classes may have different programming models –Habitat monitoring: queries –Tracking: neighborhoods/regions –Need generality across networks

5. 4.vi.2004NEST Retreat4 Application-Specificity Deployments are for an application class –Tracking, habitat monitoring –Don’t need complete generality in a given network Classes may have different programming models –Habitat monitoring: queries –Tracking: neighborhoods/regions –Need generality across networks –Implementation alternatives Application-specific virtual machines (ASVMs) can provide a way to safely and efficiently program deployed sensor networks.

6. 4.vi.2004NEST Retreat5 Programming Space Efficiency Generality Config Deluge/Xnp

7. 4.vi.2004NEST Retreat6 Programming Space Efficiency Generality Config Deluge/Xnp ASVMs

8. 4.vi.2004NEST Retreat7 Execution Layer nesC, binary code, changed rarely Optimizations, resource management, hardware Transmission Layer Application specific VM bytecodes Efficiency, safety Programming Layer SQL-like queries, data parallel operators, scripts Expressivity, simplicity Three Layers

9. 4.vi.2004NEST Retreat8 Execution Layer nesC, binary code, changed rarely Optimizations, resource management, hardware Transmission Layer Application specific VM bytecodes Efficiency, safety Programming Layer SQL-like queries, data parallel operators, scripts Expressivity, simplicity Three Layers

10. 4.vi.2004NEST Retreat9 Outline Programming sensor network deployments RegionsVM QueryVM Maté: an architecture for building ASVMs Separating the transmission layer Conclusion

11. 4.vi.2004NEST Retreat10 Abstract Regions “Programming Sensor Networks with Abstract Regions,” Matt Welsh and Geoff Mainland, NSDI 2004. Proposed “abstract regions” as a data primitive for data-parallel operations Single lightweight “fiber” for synchronous code Compile regions program into a TinyOS image –20KB for a single-region program –Binary code: unsafe

12. 4.vi.2004NEST Retreat11 RegionsVM Export regions primitives as functions –Creation –Reductions –Tuple space put/get Regions programs become small scripts –Easy to install –Virtual code: safety

13. 4.vi.2004NEST Retreat12 Regions Fiber RegionsVM region = k_nearest_region_create(8); while(true){ val = get_sensor_reading(); region.putvar(v_key, val); region.putvar(x_key, val * loc.x); region.putvar(y_key, val * loc.y); if (val > threshold) { max_id = region.reduce(OP_MAXID, v_key); if (max_id == my_id) { sum = region.reduce(OP_SUM, v_key); sum_y = region.reduce(OP_SUM, x_key); sum_x = region.reduce(OP_SUM, y_key); centroid.x = sum_x / sum; centroid.y = sum_y / sum; send_to_basestation(centroid); } sleep(periodic_delay); } call KNearCreate(); for i = 1 until 0 val = call cast(call mag()); call KNearPutVar(0, val); call KNearPutVar(1, val*call locX()); call KNearPutVar(2, val*call locY()); if (val > threshold) then max_id = call KNearReduceMaxID(0); if (max_id = my_id) then sum = call KNearReduceAdd(0); sum_y = call KNearReduceAdd(1); sum_x = call KNearReduceAdd(2); buffer[0] = sum_x / sum; buffer[1] = sum_y / sum; call send(buffer); end if call sleep(periodic_delay); next i

14. 4.vi.2004NEST Retreat13 Cost Breakdown Regions FiberRegionsVM TinyOS Image Size19K39K Data Size2.25K3.02K Program Size19K71 bytes SafetyNoYes Max. Concurrency1N

15. 4.vi.2004NEST Retreat14 Cost Breakdown Regions FiberRegionsVM TinyOS Image Size19K39K Data Size2.25K3.02K Program Size19K71 bytes SafetyNoYes Max. Concurrency1N Reduces program size by 99.6% Provides safety

16. 4.vi.2004NEST Retreat15 Outline Programming sensor network deployments RegionsVM QueryVM Maté: an architecture for building ASVMs Separating the transmission layer Conclusion

17. 4.vi.2004NEST Retreat16 TinyDB Declarative SQL-like queries –Programs are direct binary encodings of queries Epoch-based data collection In-network aggregation up a routing tree

18. 4.vi.2004NEST Retreat17 QueryVM Imperative framework for processing queries Execution events for routing intercept –Same as TinyDB approach –Aggregate by examining forwarding messages Uses motlle as its language –Not as simple as SQL, but more powerful –Comparatively rich data types (vectors, lists, etc.)

19. 4.vi.2004NEST Retreat18 Three Queries Simple: basic periodic data collection (light) Conditional: send EWMA of temperature if light above a threshold SpatialAvg: periodic collection of spatially averaged temperature readings

20. 4.vi.2004NEST Retreat19 TinyDBQueryVM Querysizedraw (mW) sizedraw (mW) Simple933.0912.7 Conditional155NA1552.1 SpatialAvg623.02232.3 Results Energy savings due to more efficient interpretation

21. 4.vi.2004NEST Retreat20 Outline Programming sensor network deployments RegionsVM QueryVM Maté: an architecture for building ASVMs Separating the transmission layer Conclusion

22. 4.vi.2004NEST Retreat21 Scheduler Concurrency Manager Capsule Store Contexts Operations Capsules Maté Architecture Template

23. 4.vi.2004NEST Retreat22 Scheduler Concurrency Manager Capsule Store Contexts Operations Capsules Maté Architecture Template

24. 4.vi.2004NEST Retreat23 Building an ASVM (and a few terms in bold) User specifies three things –Contexts: events that trigger execution –Language: TinyScript or motlle, a set of primitives TinyScript: BASIC-like minimalist language motlle: Scheme-like language with C syntax –Functions: higher-level operations Functions and primitives define VM operations (instruction set) Maté core, shared across all VMs –Scheduler: execution –Capsule Store: code capsule storage and dissemination –Concurrency Manager: concurrency control

25. 4.vi.2004NEST Retreat24 Sample VM Description File (RegionsVM)

26. 4.vi.2004NEST Retreat25 Scheduler: Data and Execution Model Contexts execute in response to an event –Timer, reboot, receive a packet –Submit context to concurrency manager –Concurrency manager ensures race-free access to shared resources, submits runnables to scheduler Contexts execute synchronously –Operations encapsulate split-phase operations behind a blocking interface Contexts have an operand stack –Passes parameters to functions –Two basic types: values and sensor readings Operations provide additional data storage

27. 4.vi.2004NEST Retreat26 Capsule Store and Concurrency Manager Automatically propagates code using a series of network trickles (version numbers, fragment status, fragments) Analyze new code to detect which shared resources are used Controls context concurrency to ensure race- free, deadlock-free execution For more details, refer to paper

28. 4.vi.2004NEST Retreat27 Scheduler Concurrency Manager Capsule Store Contexts Operations Capsules Maté Architecture Template

29. 4.vi.2004NEST Retreat28 Extensions: Operations and Contexts Every operation and context has a nesC component –Some implement multiple operations: getvar/setvar –Some contexts have operations: Timers Wiring these to the VM template customizes the VM to a particular application –Contexts: when the VM executes –Operations: what the VM can do when it executes Components are small and simple –Example: operations

30. 4.vi.2004NEST Retreat29 Outline Programming sensor network deployments RegionsVM QueryVM Maté: an architecture for building ASVMs Separating the transmission layer Conclusion

31. 4.vi.2004NEST Retreat30 Execution Layer nesC, binary code, changed rarely Optimizations, resource management, hardware Transmission Layer Application specific VM bytecodes Efficiency, safety Programming Layer SQL-like queries, data parallel operators, scripts Expressivity, simplicity Three Layers

32. 4.vi.2004NEST Retreat31 Execution Layer nesC, binary code, changed rarely Optimizations, resource management, hardware Transmission Layer Binary Code Programming Layer SQL-like queries, data parallel operators, scripts Expressivity, simplicity Regions Model

33. 4.vi.2004NEST Retreat32 Execution Layer nesC, binary code, changed rarely Optimizations, resource management, hardware Transmission Layer SQL queries Programming Layer SQL-like queries, data parallel operators, scripts Expressivity, simplicity TinyDB Model

34. 4.vi.2004NEST Retreat33 Source of Inefficiency Regions conflate execution and transmission –Inefficient propagation TinyDB conflates programming and transmission –Inefficient execution Separating the transmission layer enables both efficient propagation and execution, while being flexible to different programming models.

35. 4.vi.2004NEST Retreat34 Outline Programming sensor network deployments RegionsVM QueryVM Maté: an architecture for building ASVMs Separating the transmission layer Conclusion

36. 4.vi.2004NEST Retreat35 Bridging the Gap Bridge the gap between programming and execution with an application-specific virtual machine Provides safety and efficient propagation Flexible architecture can be used for a range of programming models and languages

37. 4.vi.2004NEST Retreat36 Status There is a current Maté release, 1.1 (March) –Allows VM composition and TinyScript programming Current work (this summer): –Cleaning up code –More general UI –Expand library of contexts/functions –Incorporate motlle into distribution –Power management Actively supported: try it out and tell me what you think or need!

38. 4.vi.2004NEST Retreat37 Questions

39. 4.vi.2004NEST Retreat38 Sample VM Description File (RegionsVM)

40. 4.vi.2004NEST Retreat39 Operations interface MateBytecode { command result_t execute(uint8_t instr, MateContext* context); command uint8_t byteLength(); } module OPpopM { provides interface MateBytecode as Code; uses interface MateStacks as Stacks; } implementation { command result_t Code.execute(uint8_t i, MateContext* ctxt) { call Stacks.popOperand(ctxt); return SUCCESS; } command uint8_t byteLength() {return 1;} }

41. 4.vi.2004NEST Retreat40 Wiring Operations module MateEngineM { // Scheduler uses interface MateBytecode as Bytecode[uint8_t op]; } implementation { result_t execute(MateContext* context) {...fetch next bytecode... context->pc += call Bytecode.byteLength[op](); call Bytecode.execute[op](op, context); } // Automatically generated by toolchain configuration MateTopLevel { components MateEngineM as VM,...; VM.Code[OPadd] -> OPadd; VM.Code[OPsend] -> OPsend; VM.Code[OPsettimer] -> OPsettimer; VM.Code[OPgetvar] -> OPgetvar4;... VM.Code[OPgetvar+7] -> OPgetvar4;}