1. Lambert Meertens & Cordell Green Kestrel Institute 1 CONSONA Constraint Networks for the Synthesis of Networked Applications Asuman Sünbül Matthias Anlauff Stephen Fitzpatrick http://consona.kestrel.edu/ NEST PI Meeting, Bar Harbor, Maine, July 9-12, 2002

2. 2 Administrative Project Title: CONSONA — Constraint Networks for the Synthesis of Networked Applications Program Manager:Vijay Raghavan PI: Lambert Meertens650-493-6871 lambert@kestrel.edu Co-PI: Cordell Green 650-493-6871 Company/Institution:Kestrel Institute Contract Number:F30602-01-C-0123 AO Number:L545 Award Start Date:05 Jun 2001 Award End Date:04 Jun 2004 Agent Name and Organization: Juan Carbonell, AFRL/IF-NY

3. 3 Collaboration Berkeley minitask: multi-target tracking application –distributed resource allocation –data diffusion –distributed tracking Berkeley OEP: single-target distributed tracking –sensor use/middleware –data diffusion middleware Boeing minitask: acoustic damping for launch vehicle –scalability issues

4. 4 Overview System-level specification Distributed specification High-level single-node code Low-level platform code interactive schema-based refinement interactive schema-based refinement automated synthesis what are the overall objectives e.g., track fastest targets specification = quality metric what are a single node’s objectives e.g., collaborate with nearby nodes to maintain coherent views of nearby targets; allocate actuators to fastest targets specification = myopic quality metric what are a single node’s actions e.g., sense-fuse-disseminate code = e-Specs code = TOS/C

5. 5 Scaling System-level specification Distributed specification High-level single-node code Low-level platform code metrics must be scalable e.g., smoothing rather than averaging depth of spanning tree  #nodes for bounded comm. range and fixed node density in 2D example later metrics must be local middleware = standard idioms e.g., smoothing everywhere, anytime algorithms e.g., distributed hill climbing constant per-node, per-second costs interactive schema-based refinement interactive schema-based refinement automated synthesis

6. 6 Refinement Schemas System-level specification Distributed specification High-level single-node code Low-level platform code interactive schema-based refinement interactive schema-based refinement automated synthesis Schema = C = complex constraint M = constraint maintainer (code) S = simpler constraints C is maintained if the constraints in S are maintained and if the maintenance code M is continually executed optimize middleware combinations e.g., exploit middleware side-effects optimize low-level code

7. 7 Example Schema: Field Consistency of Target Estimates Each mote maintains an estimate of the target’s position  i:mote· Field Consistent(x)   j:neighbors(i)· Edge Consistent(i.x, j.x) neighbors(i, j)  Edge Consistent(i.x, j.x)  diffuse(x) code diffuse(x) { on tick do broadcast(x); on receive(x’) do smooth(x, x’) } Sense-fuse-disseminate idiom C C S S M M

8. CONSONA : Constraint Networks for the Synthesis of Networked Applications New Ideas  Model NEST services and applications uniformly with constraint networks  Design applications out of components directly at the model level  Use constraint-propagation technology to generate highly optimized cross-cutting code ImpactImpact  Ultra-high scalability and unprecedented level of granularity  The technology enables flexible, manageable and adaptable application design at a mission-oriented level  Generated systems are robust (fault tolerant, self-stabilizing) with graceful degradation on task overload Year One Year Two Year Three Kestrel Institute: Lambert Meertens, Cordell Green ScheduleSchedule Model of example NEST application Design of modeler Prototype modeler Prototype generator Integrated modeler & generator for one or more NEST OEPs ScheduleSchedule Jun ’01Jun ’02Jun ’03 Jun ’04

9. 9 Status System-level specification Distributed specification High-level single-node code Low-level platform code interactive schema-based refinement interactive schema-based refinement automated synthesis examples design prototype due this year examples design prototype due by spring TinyOS/C code synthesis other platforms? prototype graphical editor examples idiom library due this year examples idiom library due this year

10. 10 Example: Graph Coloring Assign a color from {0 … k-1} to each node in an undirected graph Traditional problem: no adjacent nodes are to have the same color –not a scalable problem: single change by any node may reduce solution quality by 100% –no known scalable solutions 100000 properly colored nodes not a satisfactory solution!

11. 11 Scalable, Approximate Graph Coloring Approximate problem: minimize color conflicts –color conflict = edge connecting nodes of the same color Scalable metric: #conflicts/#edges –single node can only have a small effect Distributed problem: each node is to minimize its conflicts with its neighbors –myopic metric for node i: fraction of i’s edges that are conflicts –idiom: distributed constraint optimization more later

12. 12 Scalable, Anytime Algorithm Each node continually changes its color to optimize its metric And broadcasts changes –need to ensure stability by keeping rate of change low enough –idiom: distributed hill- climbing with stochastic activation –characterized by rapid improvement in quality and asymptotic convergence fraction of color conflicts vs. time step (y=1 equivalent to random coloring) fraction of nodes changing per step indicated in parentheses

13. 13 Distributed Constraint Optimization Important idiom for NEST systems Set of vertices V –inherently distributed due to communication latency Each vertex v is labeled with a value in domain D(v) Set of hyper-edges E –e  where e  E and v i  V Each hyper-edge e is labeled with a score function from D(v 1 )  D(v 2 )  …  D(v r )  Real Objective: assign values to vertices that optimize the mean of the hyper-edges’ values Initial performance experiments with simple algorithms have promising results –rapid, cheap short-term improvement

14. 14 e-Specs for Motes Formalism for writing high-level code –combines axiomatic and operational semantics Used to define TOS-like modules as state machines –highlights the structure of behavior usually hidden in C-level code Automated synthesis into low-level code –e.g., TOS/C module

15. 15 Basics of e-Specs Modes are refinements of the global state Transitions are expressed as simultaneous rewrites of local & global state global state invariants mode-A local state axioms mode-B local state axioms mode-C local state axioms (b’,g’) := f 1 (a,g) (c’,g’) := f 2 (b,g) (a’,g’) := f 3 (c,g) (b’,g’) := f 2 (b,g)

16. 16 Example: Ambient Light Calibration

17. 17 e-Specs for Motes: Composition Different aspects can be modeling independently Interaction is currently expressed through shared state –semantics on states/transitions allows strong checking of properties at design time –goal is to express interface to a module as an e-Spec that formally captures the protocol for using the module e-Specs composition operation can be used to synthesize the composed model espec SensorMote espec BasicDataTransmission espec ReliableDataTransmission espec SensorMoteWithBasicDataTransmissionespec SensorMoteWithReliableDataTransmission

18. 18 e-Specs for Motes: Refinement e-Specs can be used to model whole network Network e-Spec refined into composition of single-mote e-Specs espec TargetTracking espec TargetTrackingRefined espec SensorMote espec BaseStation espec ComputationMote

19. 19 Integration with TOS Both tool integration and module integration e-SpecsStateflow Other TOS/C Modules nesC C TOS/C Modules Matlab C (for embedded systems) semantic integration operational integration e-Specs as formal documentation generator KI generator

20. 20 Conclusion Have gotten our feet wet with the motes Have developed a formalism and tool for high-level coding of the motes –promises interesting compositional & refinement techniques Have laid out basic framework for specification and refinement of NEST algorithms & services Have applied the techniques from top-to- bottom for non-trivial application with reasonable results

21. 21 Project Schedule Modeling using constraints: achieved Toolset: preliminary design – done, informal Prototype modeling toolset March 2003 Year One Year Two Year Three Model of example NEST application Design of modeler Prototype generator Integrated modeler & generator installed on NEST OEP Jun ’01Jun ’02Jun ’03 Jun ’04 Code Synthesizer Prototype modeler

22. 22 Performance Goals Measures of success: – Flexibility of combining components – Dynamic adaptivity – Run-time efficiency – Correctness & maintainability of generated applications Metrics: –complexity of specification vs. code experience: code has 2 to 5 times more interdependencies –number of critical errors (that cause failure) experiment: manual code has ~10 times more critical errors than refined-synthesized code

23. 23 Program Issues Recurrent themes: –high-level coding paradigms for mote-like systems –approximate solution techniques Would be worthwhile program achievement to draw out common ideas