1 / 20

CONSONA Constraint Networks for the Synthesis of Networked Applications

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. Overview. System-level specification. what are the overall objectives

dylan
Download Presentation

CONSONA Constraint Networks for the Synthesis of Networked Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related