A Whirlwind Tour of SNACK A Sensor Network Application Construction Kit Oral Qualifying Examination

1
A Whirlwind Tour of SNACK(A Sensor Network
Application Construction Kit)Oral Qualifying
Examination for Ph.D. Candidacy

• Ben Greenstein
• Committee
• Deborah Estrin, Eddie Kohler,
• Todd Millstein, Jens Palsberg,
• Mani Srivastava
• June 2, 2004

This project was motivated by work doneduring
an internship at Intel Berkeley withDavid Culler.
2
Outline

• Introductory Remarks (3 slides)
• Related Work (2 slides)
• A Quick Example (2 slides)
• System Features (2 slides)
• Language Features (16 slides)
• Compilation (4 slides)
• Service Library (4 slides)
• Preliminary Results (3 slides)
• Work Plan (2 slides)

3
Introductory Remarks Why SNACK? Whats the
goal?

• Provide a framework for easily developing
  efficient sensor network applications on
  mote-grade platforms
• Focus
• Configuration of modular software
• Not
• Virtual Machine
• Macroprogramming environment
• Graphical development environment
• System for over-the-air re-flash or module
  insertion

4
Introductory Remarks Whats wrong with nesC and
tinyOS?

• Most common complaint about tinyOS/nesC You
  have to be a genius to program in it
• Almost correct you have to be an experienced
  systems developer to program in it
• The goal of tinyOS has largely been one of
  efficiency. Very little effort has been focused
  on making application development easy
• Note TinyDB and tinyDiffusion themselves are not
  what were after

5
Introductory Remarks Does efficiency require
interface complexity?

• nesC configuration for collecting light data and
  delivering it to the root of a routing tree
• Main.StdControl -gt SurgeM.StdControl
• Main.StdControl -gt Photo
• Main.StdControl -gt Bcast.StdControl
• Main.StdControl -gt multihopM.StdControl
• Main.StdControl -gt QueuedSend.StdControl
• Main.StdControl -gt TimerC
• Main.StdControl -gt Comm
• SurgeM.ADC -gt Photo
• SurgeM.Timer -gt TimerC.Timerunique("Timer")
• SurgeM.Leds -gt LedsC // NoLeds
• SurgeM.Bcast -gt Bcast.ReceiveAM_SURGECMDMSG
• Bcast.ReceiveMsgAM_SURGECMDMSG -gt
  Comm.ReceiveMsgAM_SURGECMDMSG
• SurgeM.RouteControl -gt multihopM
• SurgeM.Send -gt multihopM.SendAM_SURGEMSG
• multihopM.ReceiveMsgAM_SURGEMSG -gt
  Comm.ReceiveMsgAM_SURGEMSG
• SNACK syntax for more or less the same thing

• Lots of initialization
• Explicit control over underlying system

6
Related WorkWhere can we turn for advice?

• NesC and TinyOS
• Emstar and EmTOS
• SOS
• Virtual Machines
• Maté and Sensorware
• SN Databases and In-Network Processors
• TinyDB, Cougar, Diffusion
• Macroprogramming Efforts
• Hood, Abstract regions, Spatial Average, and
  Region Area

7
Related WorkMore advice from other fields

• Architecture Description Languages (ADLs)
• Ptolemy
• Environment for simulating and prototyping
  heterogenous systems that supports a variety of
  system description styles
• Acme
• Supports modular composition of architectures via
  interface connections
• Provides constraint language based on first order
  predicate logic to describe guidelines for how
  architectures can change over time
• Composable and Readable Systems
• Click
• Has elements, ports, configuration strings that
  map to SNACK components, interface names, and
  service initialization parameters
• Router elements wired together using similar
  language to SNACKs
• SNACK and Click share goal of providing
  composable elements with readable interfaces that
  produce efficient systems
• But, Click is for Routers of packets, Snack is
  for Sensor Networks. This leads to more variety
  in interfaces
• Knit
• Component definition and linking language for
  building operating systems
• Semantically similar to nesC Atomic units
  (modules in nesC), which can be composed into
  compound units (configurations) have
  bundles (interfaces) that are imported
  (used) or exported (provided) and renamed
  using to (as).
• Unlike nesC, implementations can refer to
  external C files.
• Like emstar in its initialization dependency graph

8
A Quick Example

• Sample temperature over the network
• Construct homogenous regions in which temperature
  is uniformly above a defined threshold
• If the area of any such region is large enough to
  merit further study, turn on more power-hungry
  sensors like magnetometers, seismometers, and
  cameras or actuators like sprinklers, air
  conditioners, etc.

9
A Quick ExampleApplication Structure
Push
Push
Temperature Sampler
EWMA
Threshold
Edge Switch
Local Area Estimator
Push
FromChild
Sum Aggregator
Spanning Tree
UART to DB
ToRoot
ToTree
AtRoot
Threshold
Expensive Sampler
Rooted Tree
ToRoot
Edge Switch
10
System FeaturesEfficiency achieved at many
levels

• Hardware
• CC1000 Radio with Power Management
• AVR 128L (also with power management) although
  arguably a Pentium is more efficient when
  measuring instructions per Watt.
• Low power sensors, choice of EEPROM, UART, etc.
  all factor in
• Languages/Compilation Techniques
• Code reduction improves code density and hence
  increases functionality for a give space
• Inlining can reduce maximum stack size
• Conventional optimizations instruction
  selection, register allocation, etc.
• Module-level optimizations (shared substructure)
• Systems
• Interrupt management/reduction
• Cross-service communication
• Scheduling
• Cross-service cooperation in radio usage
• Algorithms
• Information theoretic algorithms
• Efficient algorithms for routing and medium access

11
System Features

• Cross-service cooperation in radio usage
• Type/Length/Value (TLV) packet format
• Elevator communication stack
• Dynamic memory pool
• Sharing of non-local structure
• MsgSrc, TimerSrc
• Reduces timers, temporally correlates processing

12
Language Features

• Syntactic support
• Differences from nesC syntax
• Multi-module chaining
• Cross configuration reference
• Parameterized configurations
• Instantiation
• Instantiation, default objects
• Controlled Sharing
• Loose parameter constraints
• Connectedness constraints
• Explicitly marked exclusivity
• Default Substructure
• Service Weaving
• Transitive arrows

13
Language FeaturesSyntactic Support

• Syntactic differences between nesC and SNACK
• configuration becomes service
• Interfaces in brackets and can have both a type
  (uppercase) and a name (lowercase).
  configuration ModuleA uses Interface1 as
  fooModuleA.foo -gt ModuleB.Interface1becomes
  ModuleA fooInterface1 -gt Interface1
  ModuleB
• provides and uses become ?

14
Language Features Syntactic Support (cont.)

• Module chaining
• nesC wiring to process and broadcast light
  dataLightSampler.put16 -gt DeltaCompressionDelta
  Compression.put8 -gt Broadcast
• Snack wiring captures dataflowLightSampler
  put16 -gt put16 DeltaCompression put8 -gt
  Broadcast
• Cross-configuration reference
• Service SmoothLight (uint16_t p, uint8_t
  a) LightSampler(period lt p) put16 ..gt
  EWMA(alpha a) -gt Broadcast
• sSmoothLights.LightSamplerput16-gtSnoop

15
Language Features Parameterized Configurations

• In nesC, application parameters such as timer
  values are specified in code.
• To change the timer frequency within some
  service, you must change its initialization code
  thus you must understand its initialization
  code.
• SNACK lets a service or component author expose
  specific tunable initialization knobs to the
  service user.
• module LightSampler(uint16_t period)module
  EWMA(uint8_t alpha)Service SmoothLight
  (uint16_t p, uint8_t a) LightSampler(period lt
  p) put16 -gt EWMA(alpha a) -gt ?

16
Language Features Instantiation

• Suppose temperature and light samplers each want
  to average their sample values
• Software engineering principles would suggest
  using instances of component, such as a EWMA,
  to implement this averaging
• EWMA could be optimized and debugged once, then
  used inside both Temp and LightSampler
• SNACK implements instances on top of nesC
• Provides service instantiation with possibly
  shared substructure between instances

17
Language Features Instantiation (of Modules)

• LightSampler put16 -gt EWMA(alpha
  64)TempSampler put16 -gt EWMA(alpha
  128)constructs two separate EWMA objects
• However,LightSampler put16 -gt EWMA(alpha lt
  64)TempSampler put16 -gt EWMA(alpha lt
  128)does not, necessarily.
• Can refer to a particular instance by declaring a
  name for that instanceLightSampler put16 -gt
  eEWMA(alpha 64)e put16 -gt Broadcast

18
Language Features Instantiation facilitates
reasoning about dataflow TimerC example

• interface Timer command result_t start(char
  type, uint32_t interval) command result_t
  stop() event result_t fired()
• Allows you to do something like
• What if you wanted

start
Timer
A
fired
start
Ain
fired
Aout
start
Timer
Timer
A
B
OR
start
fired
Bin
Bout
fired
19
Language Features Instantiation (of Services)

• service SmoothLight (uint16_t p, uint8_t
  a) LightSampler(period lt p) put16 -gt
  EWMA(alpha a) -gt ?SmoothLight(p 100, a
  64)put16 -gt BroadcastSmoothLight(p 150, a
  128)put16 -gt EEPROMStore
• Has functionality that can be represented
  bylsLightSampler(p100)lsput16-gte1EWMA(al
  pha 64) -gt Broadcastlsput16-gte2EWMA(alpha
  128) -gt EEPROMStore
• Which is the same as having one instance of
  LightSampler and two instances of EWMA

20
Language Features Controlled Sharing

• Strict memory limitations on sensor nodes require
  us to avoid any unnecessary instance duplication
• SNACK compiler smart enough to combine components
  when possible
• Service authors control sharing with
• Loose parameter constraints
• this timer frequency is at least 10 Hz, which
  lets this timer be combined with any other timer
  with frequency gt 10 Hz.
• Connectedness constraints
• this interface can be used at most once
• Explicitly marked exclusivity
• This component must not be shared, because its
  used to store private state, for example

21
Language Features Loose Parameter Constraints
p gt 3
A
p 3
A
p 3

p Ap
C
C
B
p gt 2
p 3
B
C
p Bp
p gt 3
A
p 3
A
p 3

p Ap
C
C
B
p lt 2
p 2
B
C
C
p 2
p Bp
22
Language Features Connectedness Constraints

• TimerSrcSignal -gtSamplerATimerSrcSignal
  -gtSamplerBcan be resolved with a single instance
  of TimerSrc
• TimerSrcSignal _at_once -gt SamplerATimerSrcSignal
  _at_once -gt SamplerBrequires two instances of
  TimerSrc
• Types of interface constraints
• _at_once exactly once_at_least at least
  once_at_most at most once_at_any anything
  goes

23
Language Features Explicitly Marked Exclusivity

• Sometimes a module maintains state. Therefore
  separate instantiation is necessary, and the my
  keyword ensures it
• LightSamplerput16 -gt EWMA(alpha lt
  64)TempSamplerput16 -gt EWMA(alpha lt 128)can
  be satisfied with a single instance of EWMA
• LightSamplerput16 -gt my EWMA(alpha lt
  64)TempSamplerput16 -gt EWMA(alpha lt
  128)cannot!

24
Language Features Explicitly Marked Exclusivity


25
Language Features Default Substructure

• A service can specify some default components
  that the application can override
• service SmoothLight (uint16_t p, uint8_t
  a) LightSampler(period lt p) put16 -gt
  EWMA(alpha a) -gt Broadcast
• SmoothLight(p 100, a 64)broadcasts smoothed
  light values
• SmoothLight(p 100, a 64)put16 -gt
  EEPROMStorestores smoothed light values

26
Language Features Service Weaving

• Self-weaving services. components weave
  themselves into an optimally small configurations
• Transitive connection (..gt).
• Conventional component connection says A and B
  are directly connected using interface I
• Transitive connection says A and B are connected
  via some path using interface I.
• Multiple services automatically join together to
  create a minimal, shared path for messages or
  events. This in turn reduces asynchrony and
  memory cost.
• Without service weaving, services would have to
  provide more complex hooks by which the user
  would perform weaving herself.

27
Language Features Service Weaving (Transitive
Arrows)

• service TempBroadcast (uint16_t
  p) MsgSrc(period lt p)MsgRcv _at_once ..gt
  TempSend ..gt Networkservice LightBroadcast
  (uint16_t p) MsgSrc(period lt p)MsgRcv _at_once
  ..gt LightSend ..gt Network
• TempBroadcast(p 100)LightBroadcast(p
  200)BecomesMsgSrc(period 100)MsgRcv -gt
  TempSend -gt LightSend -gt Network
• ..gt establishes a precedence relation so that
  services may be woven together into optimally
  small configurations

A
C

(..gt)
A
C
B
B
C
28
Language Features Putting it all together TreeS
Parameterized services

• service TreeS (uint16_t bperiod)
• my treeTreeM(period b)
• srcPeriodicSrcS(period lt b)
• APPInitTreeM _at_once -gt tree
• APPToggle _at_any -gt Toggle _at_least src
  Ready _at_any -gt ?
• ? Get16 -gt Lookup _at_any tree
• treeSignal _at_once
• -gt Signal _at_any src OutMsgRcv
  _at_once
• ..gt tree
• ..gt NetworkS In _at_once
• ..gt tree
• treeStamp _at_once -gt Stamp _at_any AttrS
  
• treeExtract _at_once -gt Extract _at_any
  AttrS
• treeAccess64 _at_once -gt Access64 _at_any
  my NodeStore64

Value constraints on initializations
Do not share qualifier
Default wirings
Interface constraints
Precedence wirings
29
Compilation
30
(No Transcript)
31
CompilationStrategies

• Module declarations within a SNACK configuration
  are compatible if they can be represented by a
  single instance
• SNACK provides syntax to restrict compatibility
  by placing constraints on components and on the
  interfaces they expose
• my.
• If two declarations of a service are not
  compatible, then their sub-services declared with
  my are not compatible.
• Loose initialization parameters.
• Components may be declared with initialization
  constraints specified as inequalities.
• Two component declarations are compatible iff
  their initialization constraints are compatible.
• Connectedness constraints.
• Two declarations, c1,c2, of a component of type C
  cannot be compatible if
• C has an interface, i, declared to be at most
  once or exactly once, and
• c1 and c2 use that interface to connect to d and
  e respectively, and
• d and e cannot be represented by a single
  instance.

32
Compilation Preliminary Approaches

• topological sort and expansion (loose parameter
  constraints)
• An application can therefore be represented as a
  tree of services (no loops) recursively expanded
  into their sub-services
• Constraint satisfaction on services
• Topmost services topologically sorted with
  respect to the encapsulation relation over
  services.
• Initialization and my constraints are solved
  for the first type of component in the sort.
• All declarations of this first type are expanded
  into their sub-services
• The process repeats until no more services can be
  expanded
• min-clique-partition (compatibility resolution)
• Node compatibility can be represented as a graph
  where edges represent compatibility. The smallest
  number of instances can be found by solving the
  min-clique-partition problem, which,
  unfortunately, is known to be NP-complete.
• k-coloring (connectedness constraints)
• Represent components and interfaces as colored
  nodes connected by undirected edges.

33
Service Library

• The SNACK language inspires new types of services
  that can be composed into a wide array of
  applications and woven into efficient
  implementations.
• Application-oriented
• No longer client-server, necessarily
• Guiding principles

34
Service LibraryInterrupt Reduction

• Three sources of interrupts in a sensor network
  node timer interrupts, radio interrupts, and
  sensor interrupts.
• Timer interrupt reduction
• identify modules across service boundaries that
  run at compatible periodicities, attaching them
  to a single timer, and chain their execution
  using a single signal
• Radio interrupt reduction
• Transmit fewer bytes. This can be achieved by
  aggregating outbound data into as few packets as
  possible
• Sensor interrupt reduction
• Use sampling infrastructure that aggregates
  sampling requests from multiple modules/queries
  into a single request schedule

35
Service Library Shared substructure

• Application-level services may have similar
  substructure
• For example, a dispatch service for tree routing
  may have similar substructure (e.g., a MAC) to a
  broadcast service
• Developing services that can leverage shared
  substructure while separating substructure that
  is not intended to be shared is a key focus of
  this work

36
Service Library Interface simplicity

• Increased control often leads to interface
  complexity.
• But, interfaces can be constructed that improve
  control while staying relatively simple.
• We explore the tradeoffs in interface design to
  construct services that expose the key knobs to
  tune service function simply yet comprehensively.

37
Preliminary ResultsResource allocation
38
Preliminary Results Dynamic Memory Pool Usage
39
Preliminary Results Bytes sent
40
Work Plan

• syntax and semantics 1 quarter
• The essence of our language is in applying
  constraints to instantiation.
• Must determine whether our syntax provides the
  correct semantics. The following will be
  addressed
• my semantics could be better described
• Syntax not yet developed for passing substructure
  (other than default).
• Syntax for partitioning an application wiring to
  create multiple-binary applications should be
  provided.
• compiler algorithms and compiler 2 quarters
• Some problems believed to be NP-Complete
• Derive complexity analysis for all
  compiler-related problems
• For those that are non-polynomial, derive
  heuristics to find optimal solutions in most
  cases and near-optimal solutions in the rest.
• Implement all resulting algorithms as part of the
  SNACK compiler.

41
Work Plan (part 2)

• service library expansion 3 quarters
• Develop a broad class of application services
  including data gatherers, filters, query engines,
  message dispatchers, and actuators.
• deployment grade application. 2 quarters
• Rewrite the ESS system as a collection of SNACK
  services. This will require the generation of
  more SNACK services in the following areas
• data samplers
• queues
• tinyDiffusion
• query engine.
• It might mean that we develop language support
  for multiple-binary applications.
• Architectural optimizations 1 quarter
• The MsgSrc component in conjunction with the
  transitive arrow and a type-length-value packet
  format provides a mechanism for multiplexing the
  transmission-requests of multiple application
  components into a single outbound packet. We plan
  to
• provide better control over this multiplexing,
  e.g., by providing QoS mechanisms
• further improve the energy savings derived from
  multiplexing by providing smarter mechanisms.

42
Thank You