View
215
Download
0
Embed Size (px)
Citation preview
7th Biennial Ptolemy Miniconference
Berkeley, CAFebruary 13, 2007
PTIDES: A Programming Model for Time-Synchronized Distributed Real-time Systems
Yang Zhao, EECS, UC Berkeley
Edward A. Lee, EECS, UC Berkeley
Jie Liu, Microsoft Research
Zhao, Berkeley 2Ptolemy Miniconference, February 13, 2007
Distributed Real-Time Systems
Multiple computers, comprising of sensors and actuators, connected on a network that act and react on events to meet timing constraints.
Zhao, Berkeley 3Ptolemy Miniconference, February 13, 2007
Related Work
RTOS: prioritize tasks and trigger computation. Languages:
synchronous languages: Esterel, Scade, Luster, Signal time-triggered languages and the concept of logical execution time: Simulink (RTW),
Giotto.
Real-Time Networking Time Triggered Protocol (MARS project) FlexRay (BMW, etc.) SAFEbus (Honeywell)
•deterministic message sending or guaranteed message latency
•clock synchronization
•requiring special bus-architecture
Zhao, Berkeley 4Ptolemy Miniconference, February 13, 2007
Related Work
Time synchronization over standard network NTP (~ms): internet RBS (~ms): wireless network IEEE1588(~ns): Ethernet
Provides a useful common notion of time for general distributed real-time systems.
How to design such systems leveraging time synchronization? Event-triggered approach: more dynamic environment. PTIDES (Programming Time-Integrated Distributed Embedded
Systems): Discrete-event semantics Carefully chosen relations between model time and real time. Efficient execution based on causality analysis that guarantees determinacy is preserved at
runtime. Does not depends on domain specific network architectures
Zhao, Berkeley 5Ptolemy Miniconference, February 13, 2007
Discrete Event Modeling in Ptolemy II
DE Director implements timed semantics to make sure ordering of time stamps be respected.
Event source
Time line
Reactive actors
Signal
Zhao, Berkeley 6Ptolemy Miniconference, February 13, 2007
Discrete Event Models
DE models have been primarily used in performance modeling and simulation:
Hardware systems (VHDL, Verilog) Manufacturing systems Communication networks (OPNET, NS-2) Transportation systems Stock market
DDE is usually to accelerate simulation, not to implement distributed real-time systems.
PTIDES uses DE as a application specification language which serves as a semantic basis for obtaining determinism in distributed real-time systems.
Applications are given as distributed DE models. Certain events have their model time mapped to real time.
Zhao, Berkeley 7Ptolemy Miniconference, February 13, 2007
Example: Networked Cameras
Camera has computer-controlled zoom and focus capabilities. Zoom and focus take time to set up, and the camera should not take
picture during this period. The video of each camera is synchronized and time stamped
All the views of some interesting moment can be played back in sequence How often a camera takes picture is also controlled by the computer.
e: zoom camera at t
e’: take picture at t’
If t – t’ < , then e should be dropped.
20
40
40
20
50
30
30
20
40
40
20
50
30
30
Zhao, Berkeley 8Ptolemy Miniconference, February 13, 2007
DE Model for the Example
Clock
Merge
Camera
DisplayCommand
Central Computer
s1
Device
Delayd
Queue
ProcessImage
s2
Route
Zhao, Berkeley 9Ptolemy Miniconference, February 13, 2007
DE Model on the Central Computer
DisplayCommand
Central Computer
ProcessImage
s1 s2
zoom in
all
tr = 2
tm
v
1
2
1 32
v = 2: zoom in camera.
Zhao, Berkeley 10Ptolemy Miniconference, February 13, 2007
DE Model on the Central Computer
DisplayCommand
Central Computer
ProcessImage
s1 s2
double period
tr = 5.5
tm
v
12
1 32
v = 2: zoom in camera.34
4 65
v = 2: zoom in camera.
v > 2: change period p to (v-2)*p.
Zhao, Berkeley 11Ptolemy Miniconference, February 13, 2007
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
DE Model for the Cameras
tm
v
12
1 32
34
4 65
1 3 5 62 4tm
1v
1097 8
Zhao, Berkeley 12Ptolemy Miniconference, February 13, 2007
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
DE Model for the Cameras
tm
v
12
1 32
34
4 65tm
v
12
1 32
34
4 65
Assume d = 1
Zhao, Berkeley 13Ptolemy Miniconference, February 13, 2007
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
DE Model for the Cameras
tm
v
12
1 32
34
4 65
Assume d = 1
tm
v
12
1 32
34
4 65
tm12
1 32
v
Zhao, Berkeley 14Ptolemy Miniconference, February 13, 2007
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
DE Model for the Cameras
1 3 5 62 4tm
1v
1097 8
tm12
1 32
v
1 3 5 62 4tm
1
v
1097 8
2
e: zoom camera at t
e’: take picture at t’
If t – t’ < =1, then e should be dropped.
Zhao, Berkeley 15Ptolemy Miniconference, February 13, 2007
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
DE Model for the Cameras
1 3 5 62 4tm
1
v
1097 8
2
Ex. v = 1, tm = 1: take a picture at tr = 1.
v = 2, tm = 3: zoom in camera at tr = 3.
Zhao, Berkeley 16Ptolemy Miniconference, February 13, 2007
Actors bind model time to real time
DisplayCommand
Central Computer
ProcessImage
s1 s2
double period
tr = 5.5
tm
v
12
1 32
34
4 65
producing an event with model time corresponding to the real time when the user input happens.
Zhao, Berkeley 17Ptolemy Miniconference, February 13, 2007
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
Actors bind model time to real time
1 3 5 62 4tm
1
v
1097 8
2
The Device actor producing an physical action at the real time corresponding to the model time of each input event.
Input events must be made available for processing at real time strictly earlier than the model time.
Zhao, Berkeley 18Ptolemy Miniconference, February 13, 2007
Challenges in Executing the Model
Not be practical nor efficient to use a centralized event queue to sort events in chronological order.
Do the techniques developed for distributed DE simulation work?
Conservative (Chandy and Misra) Optimistic (Time warp, Jefferson)
Our approach: events only need to be processed in time-stamp order when they are causally related.
Zhao, Berkeley 19Ptolemy Miniconference, February 13, 2007
Conservative Execution of the Example
Clock
Merge
Camera
DisplayCommand
Central Computer
s1
Device
Delayd
Queue
ProcessImage
s2
Route
tm1
1 32
v
Assure no event with time
stamp tm <= 3 at tr = 3
Received at real time tr > 3
Deadline missed!
Zhao, Berkeley 20Ptolemy Miniconference, February 13, 2007
Challenges in Executing the Model
Not be practical nor efficient to use a centralized event queue to sort events in chronological order.
Do the techniques developed for distributed DE simulation work?
Conservative (Chandy and Misra) Optimistic (Time warp, Jefferson)
Our approach: events only need to be processed in time-stamp order when they are causally related.
Zhao, Berkeley 21Ptolemy Miniconference, February 13, 2007
Intuition on Out of Order Execution
Clock
Merge
Camera
DisplayCommand
Central Computer
s1
Device
Delayd
Queue
ProcessImage
s2
Route
tm1
1 32
v
If there is an event with time
stamp tm <= 3-d at tr <= 3-d
Received by real time
tr < 3-d+D
tm1
1 32
?
tm1
1 3-d
?
D : is the up bound of network delay; d > D
Zhao, Berkeley 22Ptolemy Miniconference, February 13, 2007
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
Intuition on Out of Order Execution
tm1
1 32
v
D : is the up bound of network delay; d > D
We can always safely process an event e at the first input of Merge by tr > tm - d + D, no matter whether there are events received at s1 or not! (If some sub-system fails, the rest of the system can continue without being blocked.)
Zhao, Berkeley 23Ptolemy Miniconference, February 13, 2007
Relevant Dependency Analysis
Relevant dependency analysis gives a formal framework for analyzing causality relationships to determine the minimal ordering constraints on processing events.
It capture the idea that events only need to be processed in time-stamp order when they are causally related.
Can preserve the deterministic behaviors specified in DE models without paying the penalty of totally ordered executions.
Yang Zhao, Jie Liu and Edward A. Lee, "A Programming Model for Time-Synchronized Distributed Real-Time Systems", in Proceedings of the 13th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS 07), Bellevue, WA, United States, April 3-6, 2007.
Zhao, Berkeley 24Ptolemy Miniconference, February 13, 2007
Causality Interface
[Zhou--Lee] Causality interface of a component declares the dependency
between input and output.
DPP oia :
dppa ),( 21
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
p13
p1
p6
p7
p8p9
p11p10p14
p15p12 p16
p2
p4
p5
p3
0),(
),(
87
min86
pp
Tpp
a
a
'),( 1615 ppa
Zhao, Berkeley 25Ptolemy Miniconference, February 13, 2007
Causality Interface Composition
dpp ),( 91
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
s1
s2
Clock
Merge
Camera
Device
Delayd
Queue
Route
p13
p1
p6
p7
p8p9
p11p10p14
p15p12 p16
p2
p4
p5
p3
minT
p3
p6
p4
p5
p2
p15p7
p10
p8 p9
p14
p13
p16'p1 d
p11 p12
Zhao, Berkeley 26Ptolemy Miniconference, February 13, 2007
Relevant Dependency
Relevant dependency on any pair of input ports p1 and p2 specifies whether an event at p1 will affect an output signal that may also depend on an event at p2.
minT
p3
p6
p4
p5
p2
p15p7
p10
p8 p9
p14
p13
p16'p1 d
p11 p12
p6 & p7
p3
p4
p5
p2
p15
p8
p14p16'
p1 d
p11
p9 & p10
p12 & p13
Zhao, Berkeley 27Ptolemy Miniconference, February 13, 2007
p6 & p7
p3
p4
p5
p2
p15
p8
p14p16'
p1 d
p11
p9 & p10
p12 & p13
Relevant Dependency
d( p1, p6) = d means any event with time stamp t at p2 can be processed when all events at p1 are known up to time stamp t − d.
Zhao, Berkeley 28Ptolemy Miniconference, February 13, 2007
Relevant Order
Relevant dependencies induce a partial order, called the relevant order, on events.
e1 <r e2 means that e1 must be processed before e2.
If neither e1 <r e2, nor e2 <r e1, i.e. e1 ||r e2, then e1, e2 can be processed in any order.
This technique can be adapted to distributed execution.
Zhao, Berkeley 29Ptolemy Miniconference, February 13, 2007
Conclusion
Time synchronization can greatly change the way distributed systems are designed.
Discrete-event model can be used as a programming model to explicitly specify and manipulate time relations between events.
It is challenging to design distributed systems to make sure they are executable.
Causality analysis can be used to determine when events can be processed out of order to improve executability and reliability.
Work in progress: statically check whether a system design is executable. Implementing a runtime environment on P1000 by Agilent.