1. Lambert Meertens & Cordell Green Kestrel Institute 1 Consona Constraint Networks for the Synthesis of Networked Applications Refinement of a Sense-Fuse-Disseminate Paradigm for Scalable Sensor Networks Asuman Sünbül Matthias Anlauff Stephen Fitzpatrick

2. 2 Project Title: CONSONA - Constraint Networks for the Synthesis of Networked Applications PM: Vijay Raghavan PI: Lambert Meertens & Cordell Green PI phone # :650-493-6871 PI email:meertens@kestrel.edu & green@kestrel.edu Institution:Kestrel 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 Administrative

3. 3 Subcontractors: none Collaborators: Berkeley OEP & minitask Boeing minitask Subcontractors and Collaborators

4. Demonstration summary Relationship to Berkeley Challenge Problem Relationship to project Evaluation Criteria  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 CONSONA Refinement of a Sense-Fuse-Disseminate Paradigm for Scalable Sensor Networks Lambert Meertens & Cordell Green Kestrel Institute 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. 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. 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. 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. 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. 9 Specification Top level specification: –maintain an estimate of the target’s position Mote-level specification: –each mote maintains an estimate (est) of the target’s 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. 10 Refinement: Field Consistent  i:mote· FieldConsistent(x)   j:neighbors(i)· EdgeConsistent(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. 11 Refinement: Sensor Consistent SensorConsistent(S, x)  sense(S, x) code sense(S, x) { on tick do fuse(S, x) }

12. 12 Refinement: Estimates Target Estimate = 2D rotated Gaussian –represented as quintuple –p(x, y) = Kּexp(-Q(x-x c, y-y c )/2) –where Q(a,b) = uּa 2 + vּaּb + wּb 2 –K = 1/sqrt(uּw-v 2 ) x y x c, y c

13. 13 Refinement: Smoothing Smoothing is weighted product –smooth(e, f) = e (1-  ) ּf  –cheap to compute using logs under transformed coordinates 5 floating point additions 2D rotated Gaussians are closed under product

14. 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 reading’s estimate –not closed: use 2D rotated Gaussian that is a maximum likelihood estimator same means and first moments (approx.) d

15. 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. 16 Simplified Algorithm: Trilateralization Need simplified algorithm for today’s 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 d1d1 d3d3 d2d2

17. 17 Demonstration Live –e-Specs –code synthesis –tracking

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