Bridging the Gap

1
Bridging the Gap
Programming Sensor Networks with Application
Specific Virtual Machines

• Philip Levis, UC Berkeley
• David Gay, Intel Research Berkeley
• David Culler, UC Berkeley

2
Sensor Network Deployments

• Need to modify behavior after deployment
• Evolving requirements, parameter tuning
• Energy is the critical resource
• Embedment complicates node failure

3
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
Application-Specificity

• Deployments are for an application class
• Tracking, habitat monitoring
• Dont need complete generality in a given network
• Classes may have different programming models
• Habitat monitoring queries
• Tracking neighborhoods/regions
• Need generality across networks

5
Application-Specificity

• Deployments are for an application class
• Tracking, habitat monitoring
• Dont 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
Programming Space
Efficiency
Config
Deluge/Xnp
Generality
7
Programming Space
Efficiency
Config
ASVMs
Deluge/Xnp
Generality
8
Three Layers
Programming Layer SQL-like queries, data parallel
operators, scripts Expressivity, simplicity
Transmission Layer Application specific VM
bytecodes Efficiency, safety
Execution Layer nesC, binary code, changed
rarely Optimizations, resource management,
hardware
9
Three Layers
Programming Layer SQL-like queries, data parallel
operators, scripts Expressivity, simplicity
Transmission Layer Application specific VM
bytecodes Efficiency, safety
Execution Layer nesC, binary code, changed
rarely Optimizations, resource management,
hardware
10
Outline

• Programming sensor network deployments
• RegionsVM
• QueryVM
• Maté an architecture for building ASVMs
• Separating the transmission layer
• Conclusion

11
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
RegionsVM

• Export regions primitives as functions
• Creation
• Reductions
• Tuple space put/get
• Regions programs become small scripts
• Easy to install
• Virtual code safety

13
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 gt 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, valcall locX())
call KNearPutVar(2, valcall locY()) if (val
gt 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) buffer0 sum_x /
sum buffer1 sum_y / sum call
send(buffer) end if end if call
sleep(periodic_delay) next i
14
Cost Breakdown
Regions Fiber RegionsVM
TinyOS Image Size 19K 39K
Data Size 2.25K 3.02K
Program Size 19K 71 bytes
Safety No Yes
Max. Concurrency 1 N
15
Cost Breakdown

• Reduces program size by 99.6
• Provides safety

Regions Fiber RegionsVM
TinyOS Image Size 19K 39K
Data Size 2.25K 3.02K
Program Size 19K 71 bytes
Safety No Yes
Max. Concurrency 1 N
16
Outline

• Programming sensor network deployments
• RegionsVM
• QueryVM
• Maté an architecture for building ASVMs
• Separating the transmission layer
• Conclusion

17
TinyDB

• Declarative SQL-like queries
• Programs are direct binary encodings of queries
• Epoch-based data collection
• In-network aggregation up a routing tree

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

• Energy savings due to more efficient
  interpretation

TinyDB TinyDB QueryVM QueryVM
Query size draw (mW) size draw (mW)
Simple 93 3.0 91 2.7
Conditional 155 NA 155 2.1
SpatialAvg 62 3.0 223 2.3
21
Outline

• Programming sensor network deployments
• RegionsVM
• QueryVM
• Maté an architecture for building ASVMs
• Separating the transmission layer
• Conclusion

22
Maté Architecture
Template
Scheduler
Capsule Store
Capsules
Concurrency Manager
Contexts
Operations
23
Maté Architecture
Template
Scheduler
Capsule Store
Capsules
Concurrency Manager
Contexts
Operations
24
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
Sample VM Description File (RegionsVM)
ltVM NAME"KNearRegions" DIR"apps/RegionsVM"gt ltLA
NGUAGE NAME"tscript"gt ltFUNCTION
NAME"send"gt ltFUNCTION NAME"mag"gt ltFUNCTION
NAME"cast"gt ltFUNCTION NAME"id"gt ltFUNCTION
NAME"sleep"gt ltFUNCTION NAME"KNearCreate"gt ltFUNCT
ION NAME"KNearGetVar"gt ltFUNCTION
NAME"KNearPutVar"gt ltFUNCTION NAME"KNearReduceAdd
"gt ltFUNCTION NAME"KNearReduceMaxID"gt ltFUNCTION
NAME"locx"gt ltFUNCTION NAME"locy"gt ltCONTEXT
NAME"Boot"gt
26
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
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
Maté Architecture
Template
Scheduler
Capsule Store
Capsules
Concurrency Manager
Contexts
Operations
29
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
Outline

• Programming sensor network deployments
• RegionsVM
• QueryVM
• Maté an architecture for building ASVMs
• Separating the transmission layer
• Conclusion

31
Three Layers
Programming Layer SQL-like queries, data parallel
operators, scripts Expressivity, simplicity
Transmission Layer Application specific VM
bytecodes Efficiency, safety
Execution Layer nesC, binary code, changed
rarely Optimizations, resource management,
hardware
32
Regions Model
Programming Layer SQL-like queries, data parallel
operators, scripts Expressivity, simplicity
Transmission Layer Binary Code
Execution Layer nesC, binary code, changed
rarely Optimizations, resource management,
hardware
33
TinyDB Model
Programming Layer SQL-like queries, data parallel
operators, scripts Expressivity, simplicity
Transmission Layer SQL queries
Execution Layer nesC, binary code, changed
rarely Optimizations, resource management,
hardware
34
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
Outline

• Programming sensor network deployments
• RegionsVM
• QueryVM
• Maté an architecture for building ASVMs
• Separating the transmission layer
• Conclusion

36
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
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
Questions
39
Sample VM Description File (RegionsVM)
ltVM NAME"KNearRegions" DIR"apps/RegionsVM"gt ltLA
NGUAGE NAME"tscript"gt ltFUNCTION
NAME"send"gt ltFUNCTION NAME"mag"gt ltFUNCTION
NAME"cast"gt ltFUNCTION NAME"id"gt ltFUNCTION
NAME"sleep"gt ltFUNCTION NAME"KNearCreate"gt ltFUNCT
ION NAME"KNearGetVar"gt ltFUNCTION
NAME"KNearPutVar"gt ltFUNCTION NAME"KNearReduceAdd
"gt ltFUNCTION NAME"KNearReduceMaxID"gt ltFUNCTION
NAME"locx"gt ltFUNCTION NAME"locy"gt ltCONTEXT
NAME"Boot"gt
40
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(ct
xt) return SUCCESS command uint8_t
byteLength() return 1
41
Wiring Operations
module MateEngineM // Scheduler uses
interface MateBytecode as Bytecodeuint8_t op
implementation result_t execute(MateContext
context) ...fetch next bytecode...
context-gtpc call Bytecode.byteLengthop()
call Bytecode.executeop(op, context) //
Automatically generated by toolchain configuration
MateTopLevel components MateEngineM as VM,
... VM.CodeOPadd -gt OPadd
VM.CodeOPsend -gt OPsend
VM.CodeOPsettimer -gt OPsettimer
VM.CodeOPgetvar -gt OPgetvar4 ...
VM.CodeOPgetvar7 -gt OPgetvar4