7th biennial ptolemy miniconference berkeley, ca february 13, 2007 ptides: a programming model for...

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.


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


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


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


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.


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


DE Model for the Example

Clock

Merge

Camera

DisplayCommand

Central Computer

s1

Device

Delayd

Queue

ProcessImage

s2

Route


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.


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.


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


s1

s2

Clock

Merge

Camera

Device

Delayd

Queue

Route


tm

v

12

1 32

34

4 65tm

v

12

1 32

34

4 65

Assume d = 1


s1

s2

Clock

Merge

Camera

Device

Delayd

Queue

Route


tm

v

12

1 32

34

4 65

Assume d = 1

tm

v

12

1 32

34

4 65

tm12

1 32

v


s1

s2

Clock

Merge

Camera

Device

Delayd

Queue

Route


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.


s1

s2

Clock

Merge

Camera

Device

Delayd

Queue

Route


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.


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.


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.


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.


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!


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.


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


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.)


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.


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


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


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


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.


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.


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.

7th biennial ptolemy miniconference berkeley, ca february 13, 2007 ptides: a programming model for...

Documents