Consona Constraint Networks for the Synthesis of Networked Applications

1
Consona Constraint Networks for the Synthesis of
Networked Applications

• Refinement of aSense-Fuse-Disseminate Paradigm
  forScalable Sensor Networks

Asuman SünbülMatthias AnlauffStephen Fitzpatrick
2
Administrative

• Project Title CONSONA - Constraint Networks for
  the Synthesis of Networked Applications
• PM Vijay Raghavan
• PI Lambert Meertens Cordell Green
• PI phone [phone]
• PI emailmeertens_at_kestrel.edu green_at_kestrel.edu
• InstitutionKestrel Institute
• Contract F30602-01-2-0123
• AO number L545
• Award start date 05 Jun 2001
• Award end date 04 Jun 2003
• Agent name organization Juan Carbonell,
  AFRL/Rome

3
Subcontractors and Collaborators

• Subcontractors none
• Collaborators Berkeley OEP minitaskBoeing
  minitask

4
CONSONA Refinement of a Sense-Fuse-Disseminate
Paradigm for Scalable Sensor Networks
Lambert Meertens Cordell GreenKestrel Institute

• Simple constraint-maintenance specification of a
  significant application
• Refinement through library schemas
• Network-sensor abstraction layer for high-level
  code
• Synthesis of low-level code
• Demonstrates local data processing a scalable
  paradigm

Show refinement from constraints to code.Show
code has realistic performance.

• Services of use to the challenge problem
• Synchronous access to local sensor data
• Transparent access to remote sensor data
• SFD paradigm for collaborative data processing
• Efficient representation of target estimates
• Complementary services needed to complete the
  challenge problem
• Dynamic space-time coordinate systems
• Distributed planning

• How natural the specification seems
• How typical are the refinements
• Reusability of network-sensor abstractions
• Accuracy of target estimates (static target)
• Communication requirements of SFD paradigm

5
Overview of Project

• Software focus
• use the motes as given
• would like to be able to use other types of
  hardware
• Develop model-based methods and tools that
• integrate design and code generation
• ? design-time performance trade-offs
• in a goal-oriented way
• ? goal-oriented run-time performance trade-offs
• of NEST applications and services
• ? low composition overhead

6
Overview of Technical Approach

• Both services and applications are modeled as
  sets of soft constraints, to be maintained at
  run-time
• High-level code is produced by repeated
  instantiation of constraint-maintenance schemas
• Constraint-maintenance schemas are represented
  as triples (C, M, S), meaning that
• constraint C can be maintained by
• running code M,
• provided that ancillary constraints S are
  maintained
• High-level code is optimized to generate
  efficient low-level code

7
Overview of Demonstration

• Constraint-based specification of tracking
  application
• Schema-based refinement into high-level code
• assumes coordinate system
• Synthesis of low-level code
• reality check simplified algorithm
• Code in action

8
Application

• Track a moving target
• solution must be scalable robust
• For simplicity, use photocell
• target carries a standardized light source
• target-mote distance estimated from photocell
  reading
• could use any sensor that provides a reliable
  distance estimate
• RF, acoustic found to be unreliable

9
Specification

• Top level specification
• maintain an estimate of the targets position
• Mote-level specification
• each mote maintains an estimate (est) of the
  targets position
• Constraint FieldConsistent(est)
• the estimates must agree with each other
• Constraint SensorConsistent(photocell, est)
• the estimates must agree with the sensors
• scalable specification/requirement local
  coupling

10
Refinement Field Consistent

• ?imote FieldConsistent(x)? ?jneighbors(i) Ed
  geConsistent(i.x, j.x)
• neighbors(i, j)? EdgeConsistent(i.x, j.x) ?
  diffuse(x)
• code diffuse(x) on tick do broadcast(x) on
  receive(x?) do smooth(x, x?)
• scalable, local interaction

11
Refinement Sensor Consistent

• SensorConsistent(S, x) ? sense(S, x)
• code sense(S, x) on tick do fuse(S, x)

12
Refinement Estimates

• Target Estimate 2D rotated Gaussian
• represented as quintuple ltxc, yc, u, v, wgt
• p(x, y) K?exp(-Q(x-xc, y-yc)/2)
• where Q(a,b) u?a2 v?a?b w?b2
• K 1/sqrt(u?w-v2)

13
Refinement Smoothing

• Smoothing is weighted product
• smooth(e, f) e(1-d) ?fd
• cheap to compute using logs under transformed
  coordinates
• 5 floating point additions
• 2D rotated Gaussians are closed under product

14
Refinement Fuse

• To fuse a photocell reading into a position
  estimate
• deduce a distance estimate (ring) from the
  photocell reading
• interpolation over calibration table
• approximate the product of the original estimate
  and readings estimate
• not closed use 2D rotated Gaussian that is a
  maximum likelihood estimator
• same means and first moments (approx.)

d
15
High-Level Code

• High-level code represented as e-Specs
• practical category theory for motes
• state machines with strong semantics defining
  each state and transition
• hope common abstraction for Berkeley Boeing
  OEPS
• Well-suited to representing single-mote
  modules/algorithms
• composition refinement
• optimization at code level
• Low-level C code is automatically synthesized

16
Simplified Algorithm Trilateralization

• Need simplified algorithm for todays demo
• still getting acquainted with TOS/C
• Motes periodically broadcast distance estimates
• Motes periodically estimate new target position
  using (approximate) trilateralization
• and smooth with old target estimate

d3
d1
d2
17
Demonstration

• Live
• e-Specs
• code synthesis
• tracking

18
Evaluation Criteria Qualitative

• Field Consistent Sensor Consistent
• are useful, intuitive constraints for specifying
  applications in scalable sensor networks
• Incremental constraint maintenance / optimization
• through perpetual smoothing fusion is a useful
  coding paradigm for scalable sensor networks

19
Evaluation Criteria Quantitative

• Accuracy of estimates
• most easily measured with static targets
• value 6 inches
• outliers more extreme
• Communication requirements
• number of messages per mote per second
• value 2

20
Demonstration Issues

• TOS software is poorly documented
• circuit diagrams are of little value to software
  engineers (me)
• Communication range is low when sensor boards are
  added
• For large scale experiments
• field programmable motes would be nice
• faithful sensor simulators would be nice