Synchronous Languages for the Modeling of: Logical Behavior, Functional/Non-Functional ... · 2010-11-30 · Synchronous Languages for the Modeling of: Logical Behavior, Functional/Non-Functional
Post on 29-Jan-2020
7 Views
Preview:
Transcript
Synchronous Languages for the Modeling of:
Logical Behavior, Functional/Non-Functional
Time, Energy Consumption, etc.
with an application to wireless sensor networks
Florence Maraninchi and Catherine Parent
SYNCHRON meeting, Frejus
November 30th, 2010
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 1 / 26
Sensor Networks and Ongoing Work at Verimag/Synchrone
1 Sensor Networks and Ongoing Work at Verimag/Synchrone
2 Detailed System-Wide Executable Models
3 The “Constraint” View of Things
4 The Experiment
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 2 / 26
Sensor Networks and Ongoing Work at Verimag/Synchrone
Sensor Networks
Several thousands of sensorscommunicating by radio + aspecial node connected to thenetwork (the sink).
Examples: detection of aradioactive cloud, ...
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 3 / 26
Sensor Networks and Ongoing Work at Verimag/Synchrone
The node itself
a radio
a sensor
a CPU
a memory
a battery
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 4 / 26
Sensor Networks and Ongoing Work at Verimag/Synchrone
Current Topics at Verimag
Synchronous programming of device drivers (talk by N. Berthier,LCTES’11)
Designing protocols (mainly at the routing level) for finding anacceptable trade-off between energy consumption and security.
Applying a systematic “distributed system + fault tolerance”approach to the design of protocols for WSNs (talk by YvanRivierre on self-stabilization)
Using probabilities... (in the design of protocols, in themodeling, next year talk)
Fine-grain Modeling of energy consumption (this talk)
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 5 / 26
Detailed System-Wide Executable Models
1 Sensor Networks and Ongoing Work at Verimag/Synchrone
2 Detailed System-Wide Executable Models
3 The “Constraint” View of Things
4 The Experiment
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 6 / 26
Detailed System-Wide Executable Models
What do we Model?
Functional behavior +
Energy consumption +
Several Time Scales...
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 7 / 26
Detailed System-Wide Executable Models
Why do we Model?
For simulations before deployment:
To find functional bugs (messages are lost because a node is notlistening when it hould be listening),
and non-functional potential gains (the radio is not turned offwhile it could be)
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 8 / 26
Detailed System-Wide Executable Models
Direct vs. Indirect Models
of Non-Functional properties
Indirect models of energy consumption: decide once and for allthat sending a message to the sink costs N units of energy, thenforget about energy and count messages;
Direct models of energy consumption: describe each hardwaredevice by a power-state model; then add the model of the rest ofthe system, that drives this power-state model.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 9 / 26
Detailed System-Wide Executable Models
Direct vs. Indirect Models
of Non-Functional properties
Indirect models of energy consumption: decide once and for allthat sending a message to the sink costs N units of energy, thenforget about energy and count messages;
Direct models of energy consumption: describe each hardwaredevice by a power-state model; then add the model of the rest ofthe system, that drives this power-state model.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 9 / 26
Detailed System-Wide Executable Models
Power-State Models from Device Documentation
Equationsde/dt = k on thestates
Delays T andenergy penalties Eon transitions
This can be encoded into a simple hybrid automaton (with additionalstates); see also LPTA (Linear-Priced Timed Automata).
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 10 / 26
Detailed System-Wide Executable Models
Energy Automata in a Synchronous Setting
else
a
b
b
−a
else
3t.−b
2t.−b
timeext. input
A
B
C
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 11 / 26
Detailed System-Wide Executable Models
Energy Automata in a Synchronous Setting
5
2
20
de/dt
else
a
b
b
−a
else
3t.−b
2t.−b
timeext. input
A
B
C
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 11 / 26
Detailed System-Wide Executable Models
Energy Automata in a Synchronous Setting
time t
5
2
20
de/dt
else
a
b
b
−a
else
3t.−b
2t.−b
timeext. input
A
B
C
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 11 / 26
Detailed System-Wide Executable Models
Energy Automata in a Synchronous Setting
−a
a
−
−
−
−a
−
−
−
b
time t
5
2
20
de/dt
else
a
b
b
−a
else
3t.−b
2t.−b
timeext. input
A
B
C
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 11 / 26
Detailed System-Wide Executable Models
Energy Automata in a Synchronous Setting
A
A
A
B
B
B
C
C
B
B
A
−a
a
−
−
−
−a
−
−
−
b
time t
5
2
20
de/dt
else
a
b
b
−a
else
3t.−b
2t.−b
timeext. input
A
B
C
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 11 / 26
Detailed System-Wide Executable Models
Energy Automata in a Synchronous Setting
5
55
5
2
22
22
2020
5
101517
19214161636570
Cumulatedenergy
A
A
A
B
B
B
C
C
B
B
A
−a
a
−
−
−
−a
−
−
−
b
time t
5
2
20
de/dt
else
a
b
b
−a
else
3t.−b
2t.−b
timeext. input
A
B
C
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 11 / 26
Detailed System-Wide Executable Models
Component-Based System-Wide Models
One node
PhysicalEnvironment
Sensor
RTC
Appli
Routing
Pow
er
Manag.
MAC
Radio
(Topo)Channel
Perturb.Rand.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 12 / 26
Detailed System-Wide Executable Models
Component-Based System-Wide Models
One node
Environment
(night/ day...)
Battery(init.E)
E. Sum
RTC
Radio
MAC
Mem.
CPU
Sensor
Pow
er
Manag.
Charge mode
charging
PhysicalEnvironment
Sensor
RTC
Appli
Routing
Pow
er
Manag.
MAC
Radio
(Topo)Channel
Perturb.Rand.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 12 / 26
Detailed System-Wide Executable Models
Component-Based System-Wide Models
One node
Environment
(night/ day...)
Battery(init.E)
E. Sum
RTC
Radio
MAC
Mem.
CPU
Sensor
Pow
er
Manag.
Charge mode
charging
PhysicalEnvironment
Sensor
RTC
Appli
Routing
Pow
er
Manag.
MAC
Radio
(Topo)Channel
Perturb.Rand.
a4
b
3
A discrete Energy
model
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 12 / 26
Detailed System-Wide Executable Models
Component-Based System-Wide Models
One node
Environment
(night/ day...)
Battery(init.E)
E. Sum
RTC
Radio
MAC
Mem.
CPU
Sensor
Pow
er
Manag.
Charge mode
charging
PhysicalEnvironment
Sensor
RTC
Appli
Routing
Pow
er
Manag.
MAC
Radio
(Topo)Channel
Perturb.Rand.
code
real
The
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 12 / 26
Detailed System-Wide Executable Models
Component-Based System-Wide Models
One node
Environment
(night/ day...)
Battery(init.E)
E. Sum
RTC
Radio
MAC
Mem.
CPU
Sensor
Pow
er
Manag.
Charge mode
charging
PhysicalEnvironment
Sensor
RTC
Appli
Routing
Pow
er
Manag.
MAC
Radio
(Topo)Channel
Perturb.Rand.
A discretized
model of the
non−deterministic
physical
environment
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 12 / 26
Detailed System-Wide Executable Models
Component-Based System-Wide Models
One node
Environment
(night/ day...)
Battery(init.E)
E. Sum
RTC
Radio
MAC
Mem.
CPU
Sensor
Pow
er
Manag.
Charge mode
charging
PhysicalEnvironment
Sensor
RTC
Appli
Routing
Pow
er
Manag.
MAC
Radio
(Topo)Channel
Perturb.Rand.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 12 / 26
Detailed System-Wide Executable Models
Several Approaches
Models in ReactiveML, Lustre
Comparison with SystemC and other event-driven simulationengines (Synchron’08)
Current: Using WSNET (an existing simulator for sensornetworks, Lyon) to be able to use the protocols as they arewritten (without re-encoding them in RML); WSNET alone isnot sufficient: designing a MAC protocol that limits energyconsumption (in particular overhearing) is quite tricky; WSNetdoes not show the benefits because the radio is not modeled!
Current: Using Lutin/Lucky (Verimag) or CCSL to build moreabstract models, relying on “time” constraints only
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 13 / 26
Detailed System-Wide Executable Models
Common Point:
Avoid Synchronous Models!
A sensor network is a typical GALS: inside a node it’s synchronous,between nodes it’s asynchronous.
The physical clocks of the nodes are not synchronized, and they canderive a lot.
Avoid “unique-time-scale” simulation models that describesynchronized clocks!
But you can use a synchronous language to describe a constrainedasynchronous system (e.g., a quasi-synchronous system as defined byP. Caspi)
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 14 / 26
The “Constraint” View of Things
1 Sensor Networks and Ongoing Work at Verimag/Synchrone
2 Detailed System-Wide Executable Models
3 The “Constraint” View of Things
4 The Experiment
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 15 / 26
The “Constraint” View of Things
Overview
HW
SW
Time
Mode
command
command
Exec time
wait (delta) on local clock
— HW has (energy) modes and transitions between modes that takesome time— HW receive mode changing commands from the software— SW has execution time, and explicit wait instructions (counting ona local clock)
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 16 / 26
The “Constraint” View of Things
Overview
Simultaneity
HW
SW
Time
Mode
command
command
Exec time
wait (delta) on local clock
— HW has (energy) modes and transitions between modes that takesome time— HW receive mode changing commands from the software— SW has execution time, and explicit wait instructions (counting ona local clock)
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 16 / 26
The “Constraint” View of Things
Overview: several nodes
commandHW Mode
Time
SWcommand
wait (delta) on local clock 2
Exec time
commandHW Mode
Time
SWcommand
wait (delta) on local clock 1
Exec time
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 17 / 26
The “Constraint” View of Things
Overview: several nodes
The radio
channelM
Topology
Losses
Transfer time
Transfer Time + clocks
real time
commandHW Mode
Time
SWcommand
wait (delta) on local clock 2
Exec time
commandHW Mode
Time
SWcommand
wait (delta) on local clock 1
Exec time
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 17 / 26
The “Constraint” View of Things
Overview: several nodes
The radio
channelM
Topology
Losses
Transfer time
Transfer Time + clocks
real timeck1
ck2
commandHW Mode
Time
SWcommand
wait (delta) on local clock 2
Exec time
commandHW Mode
Time
SWcommand
wait (delta) on local clock 1
Exec time
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 17 / 26
The “Constraint” View of Things
Overview: several nodes
The radio
channelM
Topology
Losses
Transfer time
Transfer Time + clocks
real timeck1
ck2
commandHW Mode
Time
SWcommand
wait (delta) on local clock 2
Exec time
commandHW Mode
Time
SWcommand
wait (delta) on local clock 1
Exec time
between ck1, ck2
+ Constraint
+ constraints
between cki and
real time
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 17 / 26
The Experiment
1 Sensor Networks and Ongoing Work at Verimag/Synchrone
2 Detailed System-Wide Executable Models
3 The “Constraint” View of Things
4 The Experiment
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 18 / 26
The Experiment
The Radio component with energy modes
Idle
Receive
Sleep
Transmit
& c!=3
& 1<=duration<=5
&1<=t<=2
&1<=t<=2
& 1<=t<=2
c=1
&1<=t<=2
&1<=t<=2
5
7
3
2
11 9
3
7
3
7
& timeout
c=0
c=2
c=0
c=3
c=0
c!=1
& c!=2
&1<=t<=2
c!=0
c!=0
c!=0
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 19 / 26
The Experiment
The software (e.g., a MAC protocol)
while true
{
// send
emit command to put the radio in Transmit mode
wait max time for the radio to go Idle->Transmit->Idle
// receive
emit command to put the radio in Receive mode
wait max time of a reception
emit command to put the radio in Idle mode again
}
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 20 / 26
The Experiment
The same in Lutin (input: local clock)
node mac (clk : bool) returns (comm : int) =
let wait_clk =
loop { not clk and comm = 4 (* 4 means "no command" *)} in
let manage_time (t : int) =
exist time : int in
time = t and comm = 4
fby
assert (pre time > 1 and comm = 4) in
loop {
clk and (time = pre time - 1)
| not clk and time = pre time
} in
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 21 / 26
The Experiment
The same in Lutin, cont’dloop {
wait_clk
(* sending *)
fby comm = 2 (* 2 means "go to Transmit" *)
fby wait_clk
(* wait the time to do Idle-Transmit-Idle *)
fby manage_time (9)
fby wait_clk
(* receiving *)
fby comm = 3 (* 3 means "go to Receive" *)
fby wait_clk
(* waiting to arrive in Receive *)
fby manage_time (2)
fby wait_clk
(* waiting the time of a complete receiving *)
fby manage_time (5)
fby wait_clk
(* going back to Idle *)
fby comm = 0 (* 0 means "go to Idle" *)
fby wait_clk
fby manage_time (2)
}
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 22 / 26
The Experiment
Generalization for SW
Encoding of the control structure: easy
Wait statements: count occurrences of the clock
send events: a constraint on the occurrences of the event
+ a bit of non-determinism for data-dependent choices
Execution times: for the moment, we ignore them. Otherwise:WCET on basic blocks.
An imperative C program can be translated systematically into thiskind of formalism.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 23 / 26
The Experiment
The Radio Device with Energy Modes
Easy to encode.Time is counted on the “real-time” scale, different from all thesoftware clocks.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 24 / 26
The Experiment
Demo with Verimag Tools (Catherine)
Testing tool, language for non-deterministic behaviors, executionengine: Lurette/Lutin/Lucky... (P. Raymond et al.)
Describing the system with Lutin
Using Lutin/Lucky
Connection to sim2chro for the timing diagrams
Exercice for Charles: the same in CCSL + t2.Report is due tomorrow!
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 25 / 26
The Experiment
Work in Progress
With Lutin/Lucky (or CCSL): model an existing stack (choice ofa routing and MAC protocols for sensor networks from WSNETor SensLab)
With WSNET: trick to add the radio model and the constraintsbetween the MAC layer and the radio modes
Same goal: find functional bugs (messages are lost because a node isnot listening when it should be listening), and non-functionalpotential gains (the radio is not turned off while it could be)
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 26 / 26
The Experiment
No Conclusion Yet... However:
When debugging a MAC protocol that cares about the radio states,people try and produce pathological orders of events (sending, beingin receive mode, ...).
You don’t need the whole detailed code to do that.The type of models we build could be used in formal verification.
FM+CP (SYNCHRON meeting, Frejus) November 30th, 2010 27 / 26
top related