Time-Triggered Architectures, Protocols and Applications.

1. Time-Triggered Architectures, Protocols and Applications. P.S. Thiagarajan

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

3. Introduction • Application domains: • Automotive electronics • Fly-by-wire cockpits • Railway signaling systems • Reason: time-deterministic executions.

4. 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!

5. 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!

6. Time-Triggered Architecture

7. Time-Triggered Architecture • Basic unit: NODE • Node: • A processor with memory • I-O subsystem • Operating system • Application software • Time-triggered communication controller

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

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

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

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

12. Network Topologies

13. ECU + The Bus Controller

14. The TDMA Schedule (FlexRay)

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

16. 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)

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

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

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

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

21. 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)

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

23. Our Research • We are building system level design methodology for time-triggered applications. • Mainly targeted towards Flexray platforms.

24. Block diagram of BBW

25. Block diagram of BBW

29. Workflow UML models in Rhapsody .sbs Rhapsody internal Representations SystemC simulation kernel UML-SystemC Translator Trace Performance numbers .h, .cpp SystemC Code

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

31. 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 Technologyhttp://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/

32. 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).

33. Event-triggered Vs. Time-Triggered • Interface to the external physical world: • Event-triggered. • Implementation architecture: • Time- triggered? • Predicatable • Composability.

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

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

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

37. Conclusion • Time-Triggered architectures and protocols will become important. • Seemingly simple • But quite sophisticated • for time-deterministic, robust distributed systems.