1. 1 CONSONA Constraint Networks for the Synthesis of Networked Applications Lambert Meertens Cordell Green Kestrel Institute Lambert Meertens Asuman Sünbül Stephen Fitzpatrick http://consona.kestrel.edu/ NEST PI Meeting San Diego, CA, January 28-31, 2003

2. 2 Administrative 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 Institution: Kestrel Institute Contract #: F30602-01-C-0123 AO number: L545 Award start date: 05 Jun 2001 Award end date: 04 Jun 2004 Agent name & organization: Juan Carbonell, AFRL/Rome

3. 3 Subcontractors and Collaborators Subcontractors –none Collaborators –none

4. 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 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 Consona Constraint Networks for the Synthesis of Networked Applications Lambert Meertens / Cordell Green Kestrel Institute

5. 5 Project Objective  The Consona project aims at developing truly scalable fine-grain fusion of physical and information processes in large ensembles of networked nodes  ‘‘Truly scalable’’ means that — at least conceptually — the networked system can be viewed as a discrete approximation of computation on a continuous field  Large-scale fine-grain systems have many potentially serious bottlenecks, and the design process must allow exploring trade- offs

6. 6 NEST needs New Methods For NEST we need model-based methods and tools that –integrate design and code generation  design-time performance trade-offs –of NEST applications and services  cross-layer fusion; low composition overhead –in a goal-oriented way  goal-oriented run-time performance trade-offs

7. 7 Why Middleware? Current Software Technology approaches to Middleware aim at creating abstractions that hide the ‘‘imperfections’’ of a physical system Such abstractions are indispensable to keep system design intellectually manageable, but threaten to hide the very thing that we need for exploring design-time trade-offs

8. 8 Perfection is Unattainable In a NEST system all guarantees are probabilistic: nodes may go dead, messaging may be subject to serious interference, … Sensor readings are subject to noise; actuator settings differ from the effects While the network is maintaining abstractions, the outside world changes and information gathered becomes obsolete A late result may be as useless as no result Timeliness (or other resource-related criteria) may be more important than precision

9. 9 Tunable Middleware Services In the NEST context, a ‘‘Middleware Service’’ is an idiom (e.g., Distributed Constraint Optimization or Sense-Fuse-Disseminate), expressing a (quantifiably) imperfect but nevertheless useful abstraction, typically realizable in a variety of ways For NEST we need Middleware Services that are tunable to desired quality-cost profiles, customizable to application-specific aspects, and specializable to the actual capabilities used

10. 10 Scalable Middleware Services NEST Middleware Services are represented by agents that are replicated throughout the network (i.e., the code is replicated, not the state) Such agents are typically lodged on groups of nearby nodes, and the agent-node assignment is typically dynamic A Middleware Service is an anytime thing

11. 11 Contributions to NEST Program Generation of Middleware Services that achieve useful global behavior using scalable local methods Laying out ground rules for techniques that can be extended to extremely large network (Future:) Tool for cross-layer optimizing code composition and generation for combined Application and Middleware Services

12. 12 Success Criteria Applications that use synthesized middleware code and scale to arbitrarily large networks Applications that use synthesized middleware code and run as well as with hand-crafted code (e.g. speed, communication cost, tracking accuracy) Complexity of middleware services that can be generated (e.g. measured in the complexity of the constraints)

13. 13 Overview of Technical Approach Services and applications are both modeled as logical formulas, expressing 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 provided that ancillary constraints S are maintained, executing code M maintains constraint C High-level code is optimized to generate efficient low-level code

14. 14 Project Progress Demo: Making the Boeing OEP CP Distributed –implemented Distributed Group Formation Service –designed and implemented Distributed Assignment Service –designed and implemented Distributed Actuator Control Modeler (Constraint Refinement System) –designed a prototype; implemented alpha version

15. 15 Distributed Boeing OEP CP Services The Boeing OEP Challenge Problem is concerned with active control for vibration damping in a rocket fairing 0s1 2 3 4 group formation delay A centralized Assignment Service (for allocating nodes to control of vibrational modes) was replaced by a distributed Assignment Service Sequential Group Formation (of groups of nodes assigned to control vibrational modes) was made concurrent, thereby reducing delay in control startup and reconfiguration

16. 16 Distributed Boeing OEP CP Control Designed and implemented a distributed algorithm for control of vibration damping, strongly reducing the vibrational energy Algorithm is based on purely local sensor readings and actuator control

17. 17 Prototype Modeler Alpha version Basic capabilities: –multiset matching & instantiation –automatic filtering for applicable schemas –history mechanism; unlimited undo Not implemented: –domain-level simplification (such as n = 0 V n > 0  true ) –version tree –library browser

18. 18 Publications and Milestones Publications –Specifying Components for NEST Applications. Asuman Sünbül. The Sixth Biennial World Conference on Integrated Design & Process Technology, H. Ehrig, B.J. Krämer & A. Ertaş (Eds.) –Scalable, Anytime Constraint Optimization through Iterated, Peer-to-Peer Interaction in Sparsely-Connected Networks. Stephen Fitzpatrick & Lambert Meertens. The Sixth Biennial World Conference on Integrated Design & Process Technology, H. Ehrig, B.J. Krämer & A. Ertaş (Eds.) –Asynchronous Execution and Communication Latency in Distributed Constraint Optimization. Lambert Meertens & Stephen Fitzpatrick. The Third International Workshop on Distributed Constraint Reasoning, pp. 80-85, Makoto Yokoo (Ed.) –Experiments on Dense Graphs with a Stochastic, Peer-to-Peer Colorer. Stephen Fitzpatrick & Lambert Meertens. Probabilistic Approaches in Search, pp. 24-28, Carla Gomes & Toby Walsh (Eds.) –Towards Component-based Systems: Refining Connectors. Mathias Anlauff & Asuman Sünbül. Proc. Refine 2002, Electronic Notes in Theoretical Computer Science, 2002 Milestones –October 2002: design of Prototype Modeler –January 2003: implementation of Prototype Modeler (alpha version) –January 2003: demonstration on Boeing OEP

19. 19 Goals and Success Criteria Measures of success: –flexibility of combining components –dynamic adaptivity –run-time efficiency –correctness & maintainability of generated applications Metrics: –run-time resource utilization –complexity of specification vs. code –number of critical errors (that cause failure)

20. 20 OEP Participation Berkeley OEP –Midterm Demo: distributed resource allocation data diffusion distributed tracking –Kestrel POC: Lambert Meertens –Berkeley POC: David Culler Boeing OEP –Demo (past contributions): distributed group formation & constraint service distributed control –Kestrel POC: Lambert Meertens –Boeing POC: Kirby Keller

21. 21 Project Plans Develop Prototype Code Generator Work on Berkeley OEP Midterm Demo: –Adapt existing services and tools to nesC –Identify middleware services that can be synthesized –Use modeler/generator to produce code Specific performance goals: –code gets generated and runs Progress will be measured and success determined by verifying that code gets generated and runs

22. 22 Project Schedule and Milestones Modeling using constraints: achieved Toolset: preliminary design – done, informal Alpha version prototype modeling toolset: done Prototype modeling toolset: March 2003 Prototype code generator: June 2003 Year One Year Two Year Three Design of modeler modeler Design of modeler modeler Prototype generator Jun ’01Jun ’02Jun ’03 Jun ’04 Code Synthesizer SynthesizerCode Alpha version of Prototype modeler Alpha version of Prototype modeler Integrated modeler & generator for NEST OEP Model of example NEST application Prototype modeler

23. 23 Technology Transition/Transfer Technology transition activities identified: currently none

24. 24 Program Issues Two recurrent themes: –high-level coding paradigms for mote-like systems –approximate solution techniques It would be a worthwhile program achievement to draw out the common ideas