Comparing Models of Computation for Real-time, Distributed Control Systems
description
Transcript of Comparing Models of Computation for Real-time, Distributed Control Systems
Comparing Models of Computation for Real-time, Distributed Control Systems
Shawn SchaffertBruno Sinopoli
Outline The real-time, distributed control
problem The two car example Analysis of different models Implementation Conclusion
The real-time, distributed control problem
The Real-time, Distributed Control Dream Model for classical control Model for discrete world
High level: networking, synchronization
Low level: task scheduling Verification tools Code-generation -> implementation
Key Ideas
Applications Environmental monitoring
(distributed sensing) Rocket vibration damping
(distributed actuation) Two car example
(distributed sensing and actuation)
Algorithms Routing Localization Synchronization Control Scheduling
Mechanisms Communication network Local & global clocks Distributed dynamical
environment Local shared resources Dynamic node
creation/destruction
Properties Controller stability Fault tolerance Task deadlines Network reliability Synchronization error
The two car example
System Structure
Cluster1
TURN!
Cluster2
TURN!
Ext_Node1
sensor
RF
Int_Node1
sensor
RF
Int_Node2
sensor
RF
Ext_Node2
sensor
RF
Distributed wireless sensor nodes detect the coming cars and their directions, communicate with neighbor nodes, and control the cars to avoid collision
Analysis of different models
Models Continuous Time Timed Multitasking Continuous Time with Discrete Event Globally Asynchronous Locally
Synchronous (GALS) Other models
Giotto SDF SR
Continuous Time (CT) This model captures:
Control stability This model doesn’t capture:
Synchronization Scheduling Network
Timed Multitasking (TM) One purpose: analysis of scheduling of
shared resources Isn’t interesting for the two car
example Could be useful for general problems
Higher level provides bounds on event inter-arrival time
This level guarantees task deadlines are met
Continuous Time with Discrete Event (CT-DE) Our models captures
Radio communication Broadcast channel Radio delay Radio collision
Distributed environment Nodes are separate entities Communication only via radio channel Distributed sensor readings
Continuous Time with Discrete Event (CT-DE)
Our model could be extended to capture: Improved radio model
Radio noise Low radio bandwidth – collision window based on packet
size Local and global clocks Nodes query environment individually Hardware-in-the-loop
Problems with the CT-DE model: Dynamic node creation/destruction seems
cumbersome Does not model task level Scale to 100 or 1000 nodes
Esterel
Synchronous language Control-dominated software or
hardware reactive system High-level programming using
functional models C code is automatically generated
Design Flow Implement functional
specification using high-level language (Esterel)
Directly generate function modules(C code) through compiling
Build interfaces and wrappers needed by the execution platform
Target Execution Platform
CodeGeneration
Performance evaluation
Design Concepts
Functional Specification
Compiler
High-Level Description
module extnode:Loop await CAR;
emit TO_Nend loop
module Cluster:loop await FROM_NC; await E;
emit CAR_TURN each L||loop await E;
emit TO_NCeach L||loop await T;
emit CAR_TURN;emit TO_NC
each L
module intnode:loop await [CAR or FROM_N]; present CAR then present FROM_N then emit T else [await FROM_N; emit L] end present else present FROM_N then [await CAR; emit E] end present end presentend loop
Cluster1
TURN!
Cluster2
TURN!
Ext_Node1
sensor
RF
Int_Node1
sensor
RF
Int_Node2
sensor
RF
Ext_Node2
sensor
RF
The real World
Esterel –A <modulename>.strl
Synch vs Asynch In Synchronous models
“Reaction based” Absence () can be sensed and used in the
specification of behaviors A global tick exists
In Asynchronous models “Signal based” No global tick Reaction cannot be observed anymore cannot be sensed
Endochronicity define
desynchronization of P This map is unique but not invertible
a aPP
“If P satisfies a special condition called endochrony, then there exists a unique such that holds”
aa PP a
Endochronicity: Meaning STS Set of variables W’ clock inference of W ( ) if
knowing presence/absence of allows deriving the presence absence of
If then the process is endochronous
,, V
VWW 'WW '
'Wv
Wv
VVVV )...2()1()0(0
Isochronicity In general
WE want the equality to hold (no spurious behavior due to asynchronous communication)
)||()||( aa
aa QPQP
“If (P,Q) satisfies a special condition called isochrony then the equality indeed holds”
Isochronicity: Meaningif b = T emit u(false)TTTT FFFF
if b == T emit u(false)
TFTT
FFF
TFTT
if a==T if b == T emit u(false)TFTT
FFF TFFTFTT
Our Casemodule extnode:Loop await CAR;
emit TO_Nend loop
This is endochronous:}_,{)2(}{)1( NTOCARVCARV
module intnode:loop await [CAR or FROM_N]; present CAR then present FROM_N then emit T else [await FROM_N; emit L] end present else present FROM_N then [await CAR; emit E] end present end presentend loop
This is not endochronous since CAR and FROM_N are not related:if (messagePayload_ptr->sourceNodeID == DUMB_NODE) {
internal_I_FROM_N()}
else if (messagePayload_ptr->sourceNodeID == OTHER_SMART_NODE) {
internal_I_FROM_NC()}
internal()
Make it Endochronous Simple solution: add signaling
For each signal add a boolean flag which indicates presence/absence
During the execution the functions will wait for all the flags and then will react
Very expensive in general: If (flag==T) { set_input;set_arrived} If (all_flag) {react;reset_arrived}
Some discussion External node:
Code size overhead 7% Internal node
Code size overhead 18% The external node is already
endochronous Internal node needs some extra
signaling
Implementation
Conclusion Ptolemy
Allows accurate model for entire system Network, dynamics, scheduling
User friendly (intuitive) Scalability issues Code generation for sensor networks?
Esterel Limited modeling (only behavioral level) Verifiability Code generation
Proposed Design Methodology
Controller
CT
DE
Synchronization
Routing
Task & Resource Scheduling
TM
Hardware
END
Acknowledgements:Professor Lee for stimulating discussionAlessandro Pinto, Yanmei Li for their contribution in the Esterel implementation