1. CONSONAConstraint Networks for theSynthesis of Networked Applications Asuman Sünbül Matthias Anlauff Stephen Fitzpatrickhttp://consona.kestrel.edu/ NEST PI Meeting,Bar Harbor, Maine, July 9-12, 2002

2. Overview System-level specification • what are the overall objectives • e.g., track fastest targets • specification = quality metric interactive schema-basedrefinement Distributed specification • what are a single node’s objectives • e.g., collaborate with nearby nodesto maintain coherent views ofnearby targets; allocate actuators to fastest targets • specification = myopic quality metric interactiveschema-basedrefinement High-level single-node code • what are a single node’s actions • e.g., sense-fuse-disseminate • code = e-Specs automatedsynthesis Low-level platform code • code = TOS/C

3. Scaling System-level specification 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 interactive schema-basedrefinement Distributed specification metrics must be local middleware = standard idioms e.g., smoothing interactiveschema-basedrefinement High-level single-node code everywhere, anytime algorithms e.g., distributed hill climbing constant per-node, per-second costs automatedsynthesis Low-level platform code

4. Refinement Schemas System-level specification Schema = <C, M, S> C = complex constraint M = constraint maintainer (code) S = simpler constraints C is maintainedif the constraints in S are maintainedand if the maintenance code M is continually executed interactive schema-basedrefinement Distributed specification interactiveschema-basedrefinement optimize middleware combinations e.g., exploit middleware side-effects High-level single-node code automatedsynthesis • optimize low-level code Low-level platform code

5. C M 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 S

6. CONSONA: Constraint Networks for the Synthesis of Networked Applications Model of example NEST application Integrated modeler & generator for one or more NEST OEPs Prototype modeler Design of modeler Prototype generator 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 Impact Schedule Schedule • 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 Jun ’01 Jun ’02 Jun ’03 Jun ’04 Year One Year Two Year Three Kestrel Institute: Lambert Meertens, Cordell Green

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

8. 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 100000properlycolorednodes not asatisfactory solution!

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

10. 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 changingper step indicated in parentheses

11. 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  <v1, v2, …, vr> where eE and viV • Each hyper-edge e is labeled with a score function from D(v1)D(v2)… D(vr)  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

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

13. Example: Ambient Light Calibration

14. espec ReliableDataTransmission espec SensorMoteWithBasicDataTransmission espec SensorMote espec BasicDataTransmission espec SensorMoteWithReliableDataTransmission 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

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

16. Integration with TOS Matlab semantic integration • Both tool integration and module integration Stateflow e-Specs generator KI generator OtherTOS/C Modules nesC C TOS/C Modules C(for embedded systems) e-Specs asformal documentation operational integration

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

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

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

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