1

Lambert Meertens & Cordell GreenKestrel Institute

CONSONAConstraint Networks for the

Synthesis of Networked Applications

Asuman SünbülMatthias Anlauff

Stephen Fitzpatrickhttp://consona.kestrel.edu/

NEST PI Meeting,Bar Harbor, Maine, July 9-12, 2002

4

Overview

System-level specification

Distributed specification

High-level single-node code

Low-level platform code

interactiveschema-based

refinement

interactiveschema-based

refinement

automatedsynthesis

what are the overall objectivese.g., track fastest targetsspecification = quality metric

what are a single node’s objectivese.g., collaborate with nearby nodesto maintain coherent views ofnearby targets; allocate actuators to fastest targets

specification = myopic quality metric

what are a single node’s actionse.g., sense-fuse-disseminatecode = e-Specs

code = TOS/C

5

Scaling

System-level specification

Distributed specification

High-level single-node code

Low-level platform code

metrics must be scalablee.g., smoothing rather than averagingdepth of spanning tree #nodesfor bounded comm. range andfixed node density in 2D

example later

metrics must be localmiddleware = standard idiomse.g., smoothing

everywhere, anytime algorithmse.g., distributed hill climbingconstant per-node, per-second costs

interactiveschema-based

refinement

interactiveschema-based

refinement

automatedsynthesis

6

Refinement Schemas

System-level specification

Distributed specification

High-level single-node code

Low-level platform code

interactiveschema-based

refinement

interactiveschema-based

refinement

automatedsynthesis

Schema = <C, M, S>C = complex constraintM = constraint maintainer (code)S = simpler constraints

C is maintainedif the constraints in S are maintainedand if the maintenance code M is continually executed

optimize middleware combinationse.g., exploit middleware side-effects

optimize low-level code

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

S

M

CONSONA: Constraint Networks for the Synthesis of Networked Applications

New IdeasNew Ideas

Model NEST services and applications Model NEST services and applications uniformlyuniformly with with constraint networksconstraint networks

Design applications out of components Design applications out of components directly at the model leveldirectly at the model level

Use constraint-propagation technology to Use constraint-propagation technology to generate generate highly optimized cross-cutting highly optimized cross-cutting codecode

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 OneYear One Year TwoYear Two Year ThreeYear Three

Kestrel Institute: Lambert Meertens, Cordell Green

ScheduleScheduleModel of example Model of example

NEST applicationNEST application

Design of Design of modelermodeler

Prototype Prototype modelermodeler

Prototype Prototype generatorgenerator

Integrated modeler & generator Integrated modeler & generator for one or more NEST OEPsfor one or more NEST OEPs

ScheduleSchedule

Jun ’01 Jun ’02 Jun ’03 Jun ’04

9

Status

System-level specification

Distributed specification

High-level single-node code

Low-level platform code

interactiveschema-based

refinement

interactiveschema-based

refinement

automatedsynthesis

examplesdesignprototype due this year

examplesdesignprototype due by spring

TinyOS/C code synthesisother platforms?

prototype graphical editor

examplesidiom library due this year

examplesidiom library due this year

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

100000properlycolorednodes

not asatisfactory solution!

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

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

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 <v1, v2, …, vr> where eE and viV• 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

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

16

Example: Ambient Light Calibration

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 SensorMoteespec BasicDataTransmission espec ReliableDataTransmission

espec SensorMoteWithBasicDataTransmission espec SensorMoteWithReliableDataTransmission

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

Integration with TOS

• Both tool integration and module integration

e-SpecsStateflow

OtherTOS/C Modules

nesC

CTOS/C Modules

Matlab

C(for embedded systems)

semantic integration

operational integration

e-Specs asformal documentation

generator KI generator

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

Project Schedule

• Modeling using constraints: achieved• Toolset: preliminary design – done, informal• Prototype modeling toolset March 2003

Year OneYear One Year TwoYear Two Year ThreeYear Three

Model of example Model of example NEST applicationNEST application

Design of Design of modelermodeler

Prototype Prototype generatorgenerator

Integrated modeler & generator Integrated modeler & generator installed on NEST OEPinstalled on NEST OEP

Jun ’01 Jun ’02 Jun ’03 Jun ’04

CodeCodeSynthesizerSynthesizer

Prototype Prototype modelermodeler

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

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