Sensor Network Application Construction Kit SNACK

1
Sensor Network Application Construction Kit
(SNACK)
Center for Embedded Networked Sensing
Ben Greenstein, Eddie Kohler, Deborah Estrin CENS
Systems Lab http//lecs.cs.ucla.edu
Introduction Make application development easy
without sacrificing control or efficiency
Sensor networks are hard to program
Can we doing anything to make it easier?

• Complicated systems implementations
• Complexity of SN systems (due in large part to
  the need for efficient use of constrained
  resources), has required application development
  by systems programmers, not end users
• Hand-crafted applicationsComponents,
  initializations, and wirings typically are
  handcrafted for single services or for monolithic
  applications optimized by eye, not by a
  compiler and require much tinkering upon reuse

• Macrocompiler support for application
  construction
• SNACKs objective is to automate the difficult
  parts of application construction. Its goal is
  to provide a way for non-programmers to easily
  develop efficient sensor network applications
• New component library and configuration
  languageHow should components be written? How
  should interfaces be specified and used? How
  should applications be configured? What sorts of
  compiler support can help to achieve our goals?

Goals Desired properties of an application
construction paradigm for sensor networks

• Efficiency
• Macrocompiler support for structural optimization

• Ease
• Non-programmers can snap together services to
  build an application

• Reusability
• Components should be general enough to be reused
  in a variety of contexts

• Backwards compatibility
• Services comprised of nesC components

• Flexibility
• Default behaviors make it easy to create apps,
  while still exposing fine control over
  functionality

• Extensibility
• Easy to write new components and wire together
  new services

Proposed Solution A new configuration language,
application service library, and compiler
Extensions to nesCs Component Model
Sample Application Data Collection via a
Routing Tree
Sample Service Tree Dispatch

• Instances
• SNACK implements instances on top of nesC
• Simpler and easier to debug than code duplication
• Enables creation of pluggable, reusable services
• Parameterization
• SNACK lets a service or component author expose
  specific tunable initialization knobs to a
  service user
• Controlled sharing
• Strict memory limitations on sensor nodes require
  us to avoid any unnecessary instance duplication
• The SNACK compiler is smart enough to combine
  components when possible. Service authors can
  control this 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 ? 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)
• Default components
• A service can specify some default components
  that the application can override
• Service weaving
• Self-weaving services, whose components weave
  themselves together with other services into a
  small configuration
• The key is the transitive connection ( ..gt) .
  Where a conventional component connection says A
  and B are directly connected using interface I,
  a 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
• Reduces asynchrony and memory cost

• An application is specified by connecting a few
  application-level services.
• These application-level services light and
  temperature samplers and two declarations of tree
  dispatch are expanded into their composite
  services.
• The partial expansion shows a one level service
  expansion of the tree dispatch and the samplers.
  The further expansion shows the expansion of the
  tree service and link estimator. The full
  expansion (not shown) is a wiring containing the
  maximum set of component instances required to
  realize the application.
• SNACKs compiler generates this full expansion,
  identifies component declarations that are
  compatible and can be realized with a single
  instance, and constructs the application with the
  minimum number of instances required to do so.

LightSampler -gt collectPut16
TreeDispatch TempSampler -gt collectPut16
TreeDispatch service TreeDispatch (uint32_t
period) my dispatch TreeDispatch16PM my
nf NullForwarder16M ? collect
NodePut16 -gt dispatch nf collect
NodePut16 -gt dispatch dispatch putRoot
NodePut16 -gt nf dispatch dataFromChild
NodePut16 -gt nf dispatch subtreeReady
Signal -gt nf srcMsgSrc
(period lt period) outMsgRcv ..gt
dispatch ..gt Network inMsgRcv
..gt dispatch ..gt MsgSink
dispatch newMessage Put32 -gt src
dispatch lookup Get16 -gt Tree(period
period) dispatch Attr -gt Attr dispatch
Access16 -gt my NodeStore16M
A two line application specification
Services may take initialization parameters
 
Default components, which may be overridden
Inequalities place bounds on initialization
parameters
Transitive wirings establish precedence
relationships
Some components cannot be shared
Performance Comparison
Comparison of a SNACK application that senses
light and temperature and forwards up a routing
tree with a SNACK application that just senses
temperature, a SNACK application that was built
with no transitive arrows, and the Surge
application modified to sample light and
temperature.
Resource allocation for the mica2.
Breakdown of resource allocation for SNACK
Forwarders largest modules.
Work initiated in collaboration with David
Culler, Intel Research Berkeley
UCLA UCR Caltech USC CSU JPL UC
Merced