PTIDES: A Programming Model for Time-Synchronized Distributed Real-time Systems

1
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

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

3
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

4
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

5
Discrete Event Modeling in Ptolemy II
DE Director implements timed semantics to make
sure ordering of time stamps be respected.
Reactive actors
Event source
Signal
Time line
6
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.

7
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 lt , then e should be dropped.
8
DE Model for the Example
9
DE Model on the Central Computer
zoom in all
tr 2
10
DE Model on the Central Computer
v
v 2 zoom in camera.
v 2 zoom in camera. v gt 2 change period p to
(v-2)p.
4
3
2
1
tm
1
3
2
4
6
5
double period
tr 5.5
11
DE Model for the Cameras
12
DE Model for the Cameras
13
DE Model for the Cameras
14
DE Model for the Cameras
e zoom camera at t e take picture at t If t
t lt 1, then e should be dropped.
15
DE Model for the Cameras
Ex. v 1, tm 1 take a picture at tr 1.
v 2, tm 3 zoom in camera at tr 3.
16
Actors bind model time to real time
v
producing an event with model time corresponding
to the real time when the user input happens.
4
3
2
1
tm
1
3
2
4
6
5
double period
tr 5.5
17
Actors bind model time to real time
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.
18
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.

19
Conservative Execution of the Example
Deadline missed!
Received at real time tr gt 3
Assure no event with time stamp tm lt 3 at tr 3
20
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.

21
Intuition on Out of Order Execution
Received by real time tr lt 3-dD
If there is an event with time stamp tm lt 3-d
at tr lt 3-d
D is the up bound of network delay d gt D
22
Intuition on Out of Order Execution
We can always safely process an event e at the
first input of Merge by tr gt 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.)
D is the up bound of network delay d gt D
23
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.
24
Causality Interface

• Zhou--Lee
• Causality interface of a component declares the
  dependency between input and output.

25
Causality Interface Composition
26
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.

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

28
Relevant Order

• Relevant dependencies induce a partial order,
  called the relevant order, on events.
• e1 ltr e2 means that e1 must be processed before
  e2.
• If neither e1 ltr e2, nor e2 ltr e1, i.e. e1 r
  e2, then e1, e2 can be processed in any order.
• This technique can be adapted to distributed
  execution.

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