Lambert Meertens Cordell Green Kestrel Institute 1 CONSONA Constraint Networks for the Synthesis of...
-
Upload
theodore-jordan -
Category
Documents
-
view
214 -
download
0
description
Transcript of Lambert Meertens Cordell Green Kestrel Institute 1 CONSONA Constraint Networks for the Synthesis of...
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