Kestrel Institute Palo Alto, California www'kestrel'edu

1
Kestrel InstitutePalo Alto, Californiawww.kestr
el.edu

• EPOXI
• Evolutionary Programming Over Explicit Interfaces

Matthias Anlauff Dusko Pavlovic, co-PI Doug
Smith, co-PI Asuman Suenbuel
2
Overview

• Motes example
• Evolving Specifications (especs)
• Planware
• Mobile IPv6
• implementation

3
Continuous Re-Assembly of a Sensor Network
Initially, motes are randomly strewn at a site
S
S
low cost motes 4 mHz, 8-bit CPU 4 KB RAM 19.2
kbps radio links 2?2 inch 50
S
S
S
S
C
S - sensor C - collector
C
C

• Refinement of the logical architecture to mote
  components
• reveals unreliable communication
• At design-time, formally compose in active
  probes, gauges and
• an adaptivity scheme that at run-time
  re-architects the system
• to adapt to communication failures

4
Characteristics of motes

• Equipped with different sensors (microphone,
  temperature, light, accelerometer, magnetometer,
  sounder)
• Size
• Mote 2?2 in
• Compare pocket PC 5.2?3.1 in
• CPU
• Mote 4 MHz, 8 bit CPU
• Compare pocket PC 133 MHz, 32 bit
• Memory
• Mote 128 KB instruction memory, 4KB RAM
• Compare pocket PC 32 MB RAM

• Radio
• 900 MHz, 19.2 kbps
• Compare Bluetooth 433.8 kbps
• Lifetime (Power)
• Mote 3-2 years
• Compare pocket PC 8 hrs
• Cost
• Pocket PC 400
• Mote 50

5
Basic Architecture of a Sensor Net each sensor
transmits data to a designated data collector
mote
mote
one sensor component running on a mote
Sensor
Sensor
?
?
radio connector links a sensor component to its
data collector
mote
Fusion
6
A Simple Adaptive Architecture
mote
mote
clock
gauge
?
?
probe
heartbeat probe plus clock allows gauge to decide
if a connector is alive, and to send adaptation
information otherwise
mote
7
Composing ArchitecturesBasic architecture is
composedwith adaptive architecture
Sensor
Sensor
?
?
?
?
Fusion
the composition is carried out by the automatic
colimit operation on diagrams of especs
8
Result An Adaptive Sensor Net
mote
mote
Sensor
Sensor
?
?
Fusion
mote
9
Refinement of a Sensor Net Architecture
Sensor Net Architecture
msg service
colimit
Adaptive Sensor Net Architecture
Adaptive communication channel
espec compiler
C code KNAL primitives
C compiler
Mote code under TinyOS
10
Boolean Gauge for Composition
Semantic Distance
Interface Specification
ComponentSpecification
I
C
A
ArchitectureA
Compliant?
Yes
composable
Time-boundedTheorem Prover
A C ? I
No
incompatible
11
Wrapper Gauge for Composition
Semantic Distance
Interface Specification
ComponentSpecification
I
C
GeneratedWrapper
ArchitectureA
Compliantwith wrapping?
Time-boundedConstructive Inference
Yes,W composable using wrapper W
A ?W W(C) ? I
No incompatible
12
Specification Carrying Software
? P,?????, S?
13
Specification Carrying Software
simulates behavior
interprets structure
14
Especs (Evolving Specifications)

• adding behavior

espec Basic_Acct is spec end-spec
prog stad Create initX is stad
Amountself is step Deposself,d
Amountself -gt Amountself,d
cond dgt0 balance(self)-gt
balance(self)d end-step end-prog end-espec
15
Evolving specifications (especs)
Key ideas that link state machine concepts with
logical concepts
16
Abstract State Machine for a GCD Algorithm
Each state has common structure x0, y0
Pos x, y, z Pos
y ? x ? y ? y - x
x0, y0
x ? x0
x ? y ? z ? x
Two
One
Loop
y ? y0
axiom z ? gcd(x0, y0)
x?y ? x ? x - y
axiom gcd(x0, y0) gcd(x, y)
x0 y0 x y z
x0 y0 x y z
x0 y0 x y z
example run
17
Evolving specifications (especs)
3. Abstract states are sets of states Specs
denote sets of models -----------------------
------------- Specs represent abstract states
4. Abstract transitions are interpretations (in
the opposite direction)!
18
Control Constructs vs Logical Concepts
Command Language Categorical
Logic Concepts P x e Q
interpretation I ThyQ ? ThyP
skip
identity interpretation sequencing
S1S2 composition I1
? I2 guarded command g ? S
conditional interpretation if fi
conditional
interpretations
with a common codomain
do od
conditional interpretations
with common domain
and codomain
19
GCD espec
espec GCD-base is spec op X-in,Y-in Pos
op X,Y Pos op Z Pos op gcd Pos,
Pos -gt Pos axiom gcd-spec is
gcd(x,y) z gt (divides(z,x) divides(z,y)
forall(wPos)(divides(w,x)
divides(w,y) gt w lt z)) end-spec
stad Two finZ is axiom Z
gcd(X-in,Y-in) axiom X Y end-stad
prog stad One initX-in,Y-in is
end-stad end-prog end-espec
stad Loop is thm loop-invariant is
gcd(X-in,Y-in) gcd(X,Y) end-stad
step initialize One -gt Loop is X X-in
Y Y-in end-step
step Out Loop -gt Two is Z X cond
X Y end-step
step Loop1 Loop -gt Loop is X X - Y
cond XgtY end-step step Loop2 Loop -gt
Loop is Y Y - X cond YgtX
end-step
20
GCD especs, states, and computation

21
Espec Refinement
x0, y0
z ? gcd(x0, y0)
x0, y0 Pos z Pos
Two
One
ax z ? gcd(x0, y0)
y ? x ? y ? y - x
x0, y0
x ? x0
x ? y ? z ? x
x0, y0 Pos x, y, z Pos
Loop
Two
One
y ? y0
ax z ? gcd(x0, y0)
x?y ? x ? x - y
ax gcd(x0, y0) gcd(x, y)
22
Espec Pushout

• pullback of underlying shapes
• pushout of global specs
• pushout of corresponding state specs
• transitions obtained via universality

23
Composing especs
24
Composition of Behavior Mutual Exclusion
Service Spec-2 var u2 boolean
Service Spec-1 var u1 boolean
Working-2
Idle
b false
u2 false
u2 true
b true
Using-2
Busy
Resource Invariants ?(u1 ? u2) b ? (u1 ? u2)
Abstract User process
Abstract User process
Unit Capacity Resource
25
Colimit of especs
axiom 2
26
Composition of Behavior Mutual Exclusion
Service Spec-2 var u2 boolean
Service Spec-1 var u1 boolean
Working-2
Idle
b false
u2 false
u2 true
b true
Using-2
Busy
Resource Invariants ?(u1 ? u2) b ? (u1 ? u2)
Abstract User process
Abstract User process
Unit Capacity Resource
The composed espec exhibits exactly the mutual
exclusive behaviors
W1, I, W2
U1, B, W2
W1, B, U2
27
Espec Colimitsuperposition of transitions
28
Representation of the Basic Sensor Net
Architecture
29
Applications of especs

• Modeling of Resources and Synthesis of
  Schedulers
• Modeling of Protocols (e.g. Mobile IP v6)

30
Planware Process
Model of Users Problem
TPFDD data, Resource data
Customized Scheduler
31
Key Idea Model resources as especs
The modes model the activities of the
resource The transitions model the allowed
sequences of activities Constraints on the modes
and transitions constrain the evolution of the
mode variables Each mode may offer services (to
accomplish a certain kind of task) and each mode
may require services of other resources
ft ? st
loc?pod ? ft 135 ? st
ft ? st
locpod ? ft ? st
Fly
Offload
fuel(poe,pod)? fuel-amt weight(mani) ?
max-cap offers transportation requires crew
32
Code Generation Process
Planware Scheduler Generator
Optimization and Code Generation