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

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

SystemC Code.sbs Rhapsody 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 TTP - A time-triggered protocol for fault-tolerant real-time systems The Real-time Systems Research Group, Institut f ü r Technische Informatik, Vienna University of Technology University of Technology REAL-TIME COMMUNICATION- Evaluation of protocols for automotive systems, MICHAEL WAERN, Waern.pdf Waern.pdf CAN bus, Time-triggered Technology,

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 , Springer, 2004.Timed vs. Time-Triggered Automata. You can find a link to this paper from my home page (

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.