Time-Triggered Architectures,
Protocols and Applications.
P.S. Thiagarajan
Introduction
• The Time-triggered paradigm:
– Events happen at pre-determined time
points.
• Architectures can be designed around this
principle.
• The components of a TTA will
communicate using a time-triggered
protocol.
– Hardware support needed for running the
protocol!
Introduction
• Application domains:
– Automotive electronics
– Fly-by-wire cockpits
– Railway signaling systems
• Reason: time-deterministic executions.
The Main Idea
• Event-triggered
– Timed automata
– CAN (Controller Area Network)
– Meeting of 3 people
• Everyone speaks whenever he/she has something
to say.
• Must wait for the currently speaker to finish before
a new speaker can start.
• Imagine a meeting of 40 people!
The Main Idea
• Time-triggered
– Every speaker is assigned a predetermined time slot.
– After one round, the speaker gets a slot again.
– Also, a topic-schedule has been worked out in
advance.
• Top1, Top2, Top4 in the first round.
• Top1, Top3 and Top5 in the second round
• Top2, Top4 and Top5 in the third round.
– Ensure no one breaks the rules!
Time-Triggered Architecture
Time-Triggered Architecture
• Basic unit: NODE
• Node:
 A processor with memory
 I-O subsystem
 Operating system
 Application software
 Time-triggered communication
controller
Time-Triggered Architecture
• Communication (TTA Protocol)
 Nodes connect to each other via two
independent channels.
 The communication subsystem
executes a periodic Time Division
Multiple Access (TDMA) schedule.
 Read a data frame + state information
from CNI (Communication Node
Interface) at predetermined fetch instant
and deliver to the CNIs of all receiving
nodes at predetermined delivery
instants.
Time-Triggered Architecture
• Communication
 All the TTPs in a cluster know this
schedule.
 All nodes of a cluster have the “same”
notion of global time.
 fault-tolerant clock synchronization.
 TTA BUS topology.
Features of the TTP
• Fault-tolerance
• Small overhead
• Only data signals (and no control signals)
cross interfaces.
• Integrates numerous services
–
–
–
–
Predictable message transmission
Message acknowledgement in group communication
Clock synchronization
Membership
Assumptions
• Fail-silence
– Communication channels only have omission
failures.
– Nodes either deliver correct results or no
results
• Internal failures are detected and node turned off
Network Topologies
ECU + The Bus Controller
The TDMA Schedule (FlexRay)
System Overview
• Replicated
communication channels
• The channel is a
broadcast bus
• Access is by TDMA
driven by progression of
global time
• Local nodes time
synchronized by TTP
• Communication by rapid
and periodic message
exchanges
TTP Design Rationale
• Sparse time base
– Messages are sent only at statically designated intervals
– Inflexible compared to Event-triggered (ET) model, but easier to
test
• Use of a priori knowledge
– All nodes are aware of when each node is scheduled to transmit
– Sender node information need not be included in frame
– Reduced overhead
• Broadcast
– Correctness of transmitted message can be concluded as soon
as one receiver acknowledges message delivery (broadcast
medium)
Protocol Highlights
• Bus access
– A FTU will have one or two time slots depending on class of
fault-tolerance
– Number of slots in a TDMA round given to an FTU may also be
different
• Membership Service
– If a message from a sending node does not occur in designated
interval, its membership is set to 0 in other nodes
– Membership checked before transmission. A node is alive if
• Its internal error detection mechanism has not indicated error
• At least one of its transmitted frames has been correctly
acknowledged.
Protocol Highlights
• Temporary blackout handling
– Correlated failure of a number of nodes
– Identified by sudden drop in membership
– Nodes send I-messages and perform local
emergency control
– After membership has stabilized, mode
changed to global emergency service
Protocol Highlights
Temporal encapsulation of nodes
– Communication bandwidth assigned statically
– Time base is sparse- every input can be observed
and reproduced exactly
• Testability
– Easy to test the implementation in comparison to ET
– Easy to simulate –finite number of execution
scenarios
• Uncontrolled interactions between nodes are prevented
• Determinism: can replicate states of nodes
Strengths
• Can provide fault-tolerant real-time performance
• Practical (MARS platform), efficient, and
scalable
– Can be implemented using available hardware,
signalling mechanisms
– Low overhead
– High data rates, used in both twisted fiber and optical
channels
• Reusability, composability, and testability
Weaknesses
• The schedule is fixed so there is no bandwidth
allocated for alarms and other spontaneous
messages
• All fault-tolerance mechanism is implemented
at system level, this means that very little
“freedom” is left for application specific
implementations
• Addition of nodes affects the existing system
(although not the application)
Current Status
• There are basically two competing
protocols/platforms.
– One due to Kopetz et.al
– The second one driven by a consortium based on a
standard called FLEXRAY.
• Flexray is more flexible.
– Allows for a dynamic segment during which it can
display event triggered behavior.
– Does not have a fault model.
– Does not provide a membership service.
Our Research
• We are building system level design
methodology for time-triggered
applications.
• Mainly targeted towards Flexray platforms.
Block diagram of BBW
Block diagram of BBW
UML models in
Rhapsody
Rhapsody internal
Representations
Workflow
.sbs
SystemC simulation
kernel
UML-SystemC
Translator
SystemC Code
Trace
.h, .cpp
Performance
numbers
Other Research at SOC
• Samarjit Chakraborty and his student are
also studying time-triggered applications.
• Main aim:
– To do timing analysis.
• GIOTTO is a software level abstraction of
time-triggered applications.
– One needs to solve a mapping problem.
References
• Kopetz, H., and Grunsteidl, G., "TTP - A time-triggered
protocol for fault-tolerant real-time systems", Digest of
Papers., FTCS-23. (IEEE CS 23rd Int' Symp. on FaultTolerant Computing), Aug. 1993, pp.524 -533
• The Real-time Systems Research Group, Institut für
Technische Informatik, Vienna University of Technology
http://www.vmars.tuwien.ac.at/projects/ttp/ttpmain.html
• REAL-TIME COMMUNICATION- Evaluation of protocols for
automotive systems, MICHAEL WAERN,
http://www.md.kth.se/RTC/MSc-theses/RT-Com-EvaluationWaern.pdf
• CAN bus, http://www.can-cia.org/can/protocol/
• Time-triggered Technology, http://www.tttech.com/
Event-triggered Vs. Time-Triggered
• How to integrate the two paradigms?
– Interesting research opportunities!
• Theoretical and more importantly, practical.
– We have one paper on the theoretical front. Much
more needs to be done.
• Krcal, P, L Mokrushin, P S Thiagarajan and W Yi: Timed vs.
Time-Triggered Automata. Proc. of CONCUR'04, LNCS
3170, pp. 340-354, Springer, 2004.
• You can find a link to this paper from my home page
(www.comp.nus.edu.sg/~thiagu).
Event-triggered Vs. Time-Triggered
• Interface to the external physical world:
– Event-triggered.
• Implementation architecture:
– Time- triggered?
– Predicatable
– Composability.
The Automotive Electronics Case
• Current scene:
– Current systems contain upto 70 ECUs
(Electronic Control Units).
– Each ECU is developed and acts
independently; very little integration.
– Communication:
• Event-triggered
• Slow; 500 Kbits/sec
The Automotive Electronics Case
• Next Generation:
– Integrated architecture.
– Distributed, safety-critical, real time.
– Why?
• Costs:
– reduce the number of ECUs.
• Reliability
• Safety
• Multiple use of sensors.
Conclusions
• Global time and clock synchronizations
play a fundamental role.
– But this also incurs overhead.
• The (TDMA) schedule is static.
– Can’t do application specific optimizations.
Conclusion
• Time-Triggered architectures and
protocols will become important.
• Seemingly simple
– But quite sophisticated
• for time-deterministic, robust distributed
systems.