Composing Sensor Network Services with SNACK, A Sensor Network Application Construction Kit

1
Composing Sensor Network Services with SNACK, A
Sensor Network Application Construction Kit

• Ben Greenstein
• Eddie Kohler
• Deborah Estrin
• June 3, 2004

This project was motivated by work doneduring
an internship at Intel Berkeley withDavid Culler.
2
Does efficiency require interface complexity?

• A systems expert configures a sensor network
  application
• Lots of initialization
• Explicit control over the underlying system
• Scientists require support from systems experts

• The key functionality is
• LightSampler -gt collectPut16 Tree

3
Programming Languages for Sensors

• Provide a framework for easily developing
  efficient sensor network applications on
  mote-grade platforms
• Use programming language support
• Goal Smart sensor network service libraries
• System designers build parameterized libraries
• Examples temperature sensing, sensor value
  smoothing, routing tree formation, link quality
  estimation, query processing,
• Scientists plug libraries together to build
  applications
• The libraries weave themselves into an efficient
  program

4
Making it easier Instantiation?

• What if we had instantiation?
• GOOD Better for describing data-flow.
• Two unrelated samplers that shape data using
  EWMAs before transmitting dont have to share a
  single EWMA server.
• BAD Every routing service would get its own
  private instance of a MAC
• strict memory limitations on sensor nodes require
  us to avoid any unnecessary instance duplication
• And two MACs in one application doesnt make much
  sense
• Can we merge module instances when merging
  doesnt change the desired application
  functionality?
• Can we provide instantiation with shared
  substructure?

5
Controlled Sharing

• SNACK compiler smart enough to combine components
  when possible.
• Without control, the compiler will create a
  single instance of any module in an application,
  no matter how many times that module is declared.
• Service authors control sharing with
• 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

6
Parameterized Configurations

• 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 ?

7
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

8
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!

9
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.
• Service TreeDispatch MsgSrc MsgRcv _at_once ..gt
  Dispatch ..gt Networkservice LQE MsgSrc
  MsgRcv _at_once ..gt LinkEstimator ..gt Network
• BecomesMsgSrc MsgRcv -gt Dispatch -gt
  LinkEstimator -gt Network
• Without service weaving, services would have to
  provide more complex hooks by which the user
  would perform weaving herself.

10
SNACK Expansion (1)

• Sample light and temperature, send both up a
  routing tree
• LightSampler -gt collectPut16
  TreeDispatchTempSampler -gt collectPut16
  TreeDispatch
• Pretty simple!

11
SNACK Expansion (2)

• The components came from a user-defined service
  library
• Easy to understand and change
• Compiler expands the services one step

12
SNACK Expansion (3)

• then further

13
SNACK Expansion (4)

• then contracts to a minimal, efficient program!

14
Conclusions

• SNACK a giant leap in thepractice of sensor
  networkprogramming for motes
• Readable
• Reusable libraries
• Efficient, too
• Next steps
• More real applications
• Multi-program systems
• Non-mote platforms
• Heterogeneous deployments

15
Emstar and Emtos

• What is Emstar?Simulation/emulation/experimentati
  on framework for developing Linux-class sensor
  network applications
• What is the EmTOS Platform?
• EmTOS is an extension of EmStar that enables an
  entire TinyOS application to run as a single
  EmStar module, and fully participate in an EmStar
  system

16
The EmTOS Platform (in Emstar)

• A Bridge Between TinyOS and EmStar
• Emulates the TinyOS API by interfacing to
  underlying EmStar services.
• Runs Real Code by encapsulating nesC unmodified
  within a wrapper library.
• Integrates to EmStar allowing TinyOS
  applications to provide new EmStar services
• Deploying Heterogeneous Applications using EmTOS
• Integration of Motes and Microservers. TinyOS
  mote code can be trivially ported to run on a
  Microserver, thus enabling a Microserver to
  participate in the Mote network. Using
  EmStatusServer and EmPacketServer, an EmTOS
  module can provide new EmStar interfaces that are
  easily integrated with other EmStar-based
  applications.

cvs.cens.ucla.edu/emstar/
17
Thank You
18
Simulating Heterogeneous Applications using EmTOS

• Supports simulations with different TinyOS builds
  on different nodes.
• Supports tiered applications that include both
  Motes and Microservers
• Supports TinyOS applications running on the PC
  using the real Mica2 RF channel
• EmTOS applications running on Microservers can
  share access to the radio with other EmStar
  devices and applications
• Makes Motes visible to EmStar visualization and
  analysis tools for debugging purposes

19
A Range of Simulation Modes

• Pure Simulation Mode Microserver and Mote code
  is run centrally in the EmStar environment, and
  all nodes communicate through a simulated RF
  channel.
• Emulation mode Microserver and Mote code is run
  centrally in the EmStar environment, but nodes
  communicate using a real RF channel
• Real Mode Microserver code runs centrally, while
  Mote code runs natively on real Motes, with a
  serial backchannel for debugging. Emulated
  Microservers communicate with real Motes and
  other Microservers through the real RF channel.
• Hybrid Mode A mixture of Real and Emulated
  modes, where some Motes are emulated and some run
  natively. All nodes communicate through the real
  RF channel.