time-triggered architectures, protocols and applications. p.s. thiagarajan
Post on 23-Dec-2015
228 Views
Preview:
TRANSCRIPT
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
SystemC Code
.sbsRhapsody internal Representations
UML-SystemC Translator
.h, .cpp
UML models in Rhapsody
SystemC simulation kernel
Performance numbers
Trace
Workflow
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 Fault-Tolerant 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-Evaluation-Waern.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.
top related