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.