Undergraduate course on Real-time Systems Linköping TDDD07 Real-time Systems Lecture 5: Real-time Communication Simin Nadjm-Tehrani Real-time Systems Laboratory Department of Computer and Information Science Linköping university 36 pages Autumn 2009

Undergraduate course on Real-time Systems Linköping 2 of 36 Autumn 2009 TDDC47: Real-time and Concurrent Programming Lecture 8: Real-time communication Simin Nadjm-Tehrani Real-time Systems Laboratory Department of Computer and Information Science Linköping university

Undergraduate course on Real-time Systems Linköping 3 of 36 Autumn 2009 Reading material TDDD07: H. Kopetz 2003 article (see course web) Davis et al 2007 article (- ” -) TDDC47: Course compendium Davis et al 2007 article (see course web)

Undergraduate course on Real-time Systems Linköping 4 of 36 Autumn 2009 From last lectures In two scheduling lectures we looked at –Single processor hard real-time scheduling –TDDD07: Distributed case with dynamic load Time and clocks in distributed systems...

Undergraduate course on Real-time Systems Linköping 5 of 36 Autumn 2009 Real-time communication This lecture: How can the communication network and protocols support real-time? RT communication is about scheduling the communication medium – NOT the CPU...

Undergraduate course on Real-time Systems Linköping 6 of 36 Autumn 2009 Distributed applications Assume that tasks are run on different nodes according to some local scheduling Nodes need to exchange data messages need to reach destination before their deadline...

Undergraduate course on Real-time Systems Linköping 7 of 36 Autumn 2009 Real-time constraints When message transmissions must have a well-defined time bound for the system to meet it deadlines –So called end-to-end deadlines Example: shortly after each braking, brake light must know it in order to turn on!

Undergraduate course on Real-time Systems Linköping 8 of 36 Autumn 2009 New resource Single NodeDistributed ResourceCPUBandwidth Scheduled element Task/processMessage Demand on resource WCET & interarrival Message size & frequency Performance metric Deadlines met Utilisation Message delay Throughput

Undergraduate course on Real-time Systems Linköping 9 of 36 Autumn 2009 Two approaches We will look at two dominant methods for bus scheduling –Time triggered (TTP) –Event triggered (CAN) Used extensively in automotive and aerospace applications

Undergraduate course on Real-time Systems Linköping 10 of 36 Autumn 2009 Time-triggered protocol (TTP) Origin in research projects in Vienna in early 90´s [Kopetz et.al] Time division multiple access (TDMA) Node 1 Node n … Node n-1

Undergraduate course on Real-time Systems Linköping 11 of 36 Autumn 2009 Communication protocol Message Description List: allocates a pre-defined slot within which each node can send its (pre-defined) message A TDMA round Node 1 Node n … Node n-1 …

Undergraduate course on Real-time Systems Linköping 12 of 36 Autumn 2009 Message scheduling TDMA round implemented through the MEDL (message description list) MEDL has a static schedule for each message No constraints on (local) node CPU scheduling

Undergraduate course on Real-time Systems Linköping 13 of 36 Autumn 2009 Temporal firewall … CC Host CC Host CNI CNI provides temporally accurate state information (via clock synchronisation) When the data is temporally not valid, it can no longer be exchanged Node n

Undergraduate course on Real-time Systems Linköping 14 of 36 Autumn 2009 Replication & failure detection BG: Buss Guardian (stops babbling idiots) … BG CC Host BG CC Host BG CNI

Undergraduate course on Real-time Systems Linköping 15 of 36 Autumn 2009 The major success of the TTP bus is due to the possibility of detecting arbitrary (Byzantine) failures We will come back to this later…

Undergraduate course on Real-time Systems Linköping 16 of 36 Autumn 2009 Two approaches We will look at two dominant methods for bus scheduling –Time triggered (TTP) –Event triggered (CAN) Used extensively in automotive and aerospace applications

Undergraduate course on Real-time Systems Linköping 17 of 36 Autumn 2009 The CAN bus Amount of wires… Controller area network that exists in all cars built in Europe today Compulsory for the on-board diagnostics in USA car models from 2008 Why? –Imagine: 2500 signals, 32 ECUs on one bus

Undergraduate course on Real-time Systems Linköping 18 of 36 Autumn 2009 Predecessor to CAN (1976) Ethernet: Current versions give high bandwidth but time-wise nondeterministic CSMA/CD –Sense before sending on the medium (Carrier Sense: CS) –All nodes broadcast to all (Multiple Access: MA) –If collision, back off and resend (Collision Detection: CD)

Undergraduate course on Real-time Systems Linköping 19 of 36 Autumn 2009 Collisions Ethernet has high throughput but temporally nondeterministic Node 1 sends Node 3 waits for sending Node 2 waits for sending Node 2 & 3 start to send Collision

Undergraduate course on Real-time Systems Linköping 20 of 36 Autumn 2009 Backoff The period for waiting after a collision Each node waits up to two “slot times” after a collision (random wait) If a new collision, the max. backoff interval is doubled After 10 attempts the node stops doubling After 16 attempts declares an error

Undergraduate course on Real-time Systems Linköping 21 of 36 Autumn 2009 Treating non-determinism Model the network throughput and compute probabilistic guarantees that collisions will not be too often Theoretical study:With 100Mbps, sending 1000 messages of 128 bytes per second, there is a 99% probability that there will be a 1 ms delay over ~1140 years [ Ethernet study] Make collision resolution deterministic! How often?

Undergraduate course on Real-time Systems Linköping 22 of 36 Autumn 2009 CAN protocol Developed by Bosch and Intel (1986) ISO Standard 1993 Highest bandwidth 1Mbps, ~40-50m CSMA/CR: broadcast to all nodes CR: Collision resolution by bit-wise arbitration plus fixed priorities (deterministic) Bus value is bitwise AND of the sent messages

Undergraduate course on Real-time Systems Linköping 23 of 36 Autumn 2009 Message priority The ID of the frame is located at the beginning –initial bits that are inserted into the bus are the ID-bits –ID also determines the priority of a frame –priority of the frame increases as the ID decreases

Undergraduate course on Real-time Systems Linköping 24 of 36 Autumn 2009 Bitwise arbitration Node 1 sends: 010………sends rest of packet Node 2 sends: 100……detects collision first Node 3 sends: 011……detects collision next This is how ID for a message (frame) works as its priority

Undergraduate course on Real-time Systems Linköping 25 of 36 Autumn 2009 Note Two roles for message ID: –Arbitration and priority –Every node upon receiving a message, uses the ID to work out whether that message is any use to it or not

Undergraduate course on Real-time Systems Linköping 26 of 36 Autumn 2009 Response time analysis Fixed priorities means RMS-like worst case analysis Messages are sent non-preemptively! Blocking is only possible before the first bit Scheduling analysis: Is every message delivered before its deadline?

Undergraduate course on Real-time Systems Linköping 27 of 36 Autumn 2009 Worst Case Response According to Tindell & Burns 94: Message response time = J i : Jitter (from event to placement in queue)+ w i : Queuing time (response time of first bit)+ C i : Transmission time R i = J i +w i + C i – t bit w i = t bit + B i + I i B i + I i : Blocking and Interference time (as RMS)

Undergraduate course on Real-time Systems Linköping 28 of 36 Autumn 2009 Interference and blocking I i : waiting due to higher priority processes, bounded if messages are sent periodically B i : waiting due to lower priority messages, only one can start before i J i : jitter, has to be assumed bounded (by assumptions on the node scheduling policy!)

Undergraduate course on Real-time Systems Linköping 29 of 36 Autumn 2009 Blocking is fixed: max C j of all lower priority messages w i = B i +  k  hp(i) ( w i + J k + t bit )/ T k  C k w 0 i = B i w n+1 i = B i +  k  hp(i) ( w i n + J k + t bit )/ T k  C k After fixed point is reached: B i + w n+1 i + C i  D i ? Solving recurrent equations

Undergraduate course on Real-time Systems Linköping 30 of 36 Autumn 2009 Example From [Davis etal 2007]: –To show how a w-term for each message was computed based on original method from 1994 –Assume j i = 0 MessagepriorityperioddeadlineTX time A12.5ms 1ms B23.5ms3.25ms1ms C33.5ms3.25ms1ms

Undergraduate course on Real-time Systems Linköping 31 of 36 Autumn 2009 Exercise Compute response times for the three messages

Undergraduate course on Real-time Systems Linköping 32 of 36 Autumn 2009 Blocking is fixed: max C j of all lower priority messages w i = B i +  k  hp(i) ( w i + J k + t bit )/ T k  C k w 0 i = B i w n+1 i = B i +  k  hp(i) ( w i n + J k + t bit )/ T k  C k After fixed point is reached: B i + w n+1 i + C i  D i ? Solving recurrent equations

Undergraduate course on Real-time Systems Linköping 33 of 36 Autumn 2009 The original analysis From 1994 … was Optimistic! There can be a case where analysis shows schedulability but in fact deadlines can be missed! [Davis, Burns, Bril, Lukkien 2007]

Undergraduate course on Real-time Systems Linköping 34 of 36 Autumn 2009 The correct analysis Takes account of the fact that different instances of a message may appear in a busy period and All such instances should be shown to meet their deadlines! [Reading: Sec. 3.1 & 3.2, Davis et al.07]

Undergraduate course on Real-time Systems Linköping 35 of 36 Autumn 2009 Revised computation R m (q)= J m + w m (q) – qT m + c m q=i, w(q) computes busy period for i th instance of message m To know range of q, i.e. how many instances of message m are relevant, we need to find the longest busy period for m denoted t m

Undergraduate course on Real-time Systems Linköping 36 of 36 Autumn 2009 Example revisited Now with the new formula where busy period term is according to [Davis etal 2007]: MessagepriorityperioddeadlineTX time A12.5ms 1ms B23.5ms3.25ms1ms C33.5ms3.25ms1ms

Undergraduate course on Real-time Systems Linköping 37 of 36 Autumn 2009 Exercise Redo the old exercise with the Davis et al. variant of the busy period W n+1 m (q) = B m +  khp(m) ( w n m + J k + t bit )/ T k  C k

Undergraduate course on Real-time Systems Linköping 38 of 36 Autumn 2009 Solution To know how many instances of message m are relevant we need to find the longest busy period for m denoted t m t 0 3 = C 3 = 1 t 1 3 =  t 0 3 / T 3  C 3 +  t 0 3 / T 2  C 2 +  t 0 3 / T 1  C 1 = 1+1+1= 3 t 2 3 =  t 1 3 / T 3  C 3 +  t 1 3 / T 2  C 2 +  t 1 3 / T 1  C 1 = 1+1+2= 4 t 3 3 =  t 2 3 / T 3  C 3 +  t 2 3 / T 2  C 2 +  t 2 3 / T 1  C 1 = 2+2+2= 6 t 4 3 =  t 3 3 / T 3  C 3 +  t 3 3 / T 2  C 2 +  t 3 3 / T 1  C 1 = 2+2+3= 7 t 5 3 =  t 4 3 / T 3  C 3 +  t 4 3 / T 2  C 2 +  t 4 3 / T 1  C 1 = 2+2+3= 7 Which means 3 instances of message C are relevant! Q=2 and q:0.. Q-1

Undergraduate course on Real-time Systems Linköping 39 of 36 Autumn 2009 Computing the queuing time w 0 3 (0) = B 3 +0.C 3 = 0 w 1 3 (0) = ( w 0 3 (0)+ t bit )/ T 2  C 2 + ( w 0 3 (0)+ t bit ) / T 1  C 1 = 1+1 =2 w 2 3 (0) = 1+1= 2  w 3 (0) = 2 R 3 (0) = w 3 (0) – qT 3 + C 3 = 3 w 0 3 (1) = w 3 (0) + C 3 = 2+1= 3 w 1 3 (1) = C 3 + ( w 0 3 (1)+ t bit ) / T 2  C 2 + ( w 0 3 (1)+ t bit ) / T 1  C 1 = = 4 w 2 3 (1) = C 3 + ( w 1 3 (1)+ t bit )/ T 2  C 2 + ( w 1 3 (1)+ t bit ) / T 1  C 1 = 1+2+2=5 w 3 3 (1) = C 3 + ( w 2 3 (1)+ t bit )/ T 2  C 2 + ( w 2 3 (1)+ t bit )/ T 1  C 1 = = 6 w 4 3 (1) = C 3 + ( w 3 3 (1) + t bit ) / T 2  C 2 + ( w 3 3 (1)+ t bit ) / T 1  C 1 = = 6 w 3 (1) = 6 R 3 (1) = w 3 (1) – qT 3 + C 3 = 3.5

Undergraduate course on Real-time Systems Linköping 40 of 36 Autumn 2009 Now for the 3rd instance w 0 3 (2) = w 3 (1) + C 3 = 6+1=7 w 1 3 (2) = C 3 + ( w 0 3 (2) + t bit )/ T 2  C 2 + ( w 0 3 (2)+ t bit )/ T 1  C 1 = = 7 w 3 (2) = 7 R 3 (2) = w 3 (2) – qT 3 + C 3 = 1 Not adding to the response time R m =max {q:0..qm-1} R m (q) = 3.5 That’s why message C missed its deadline!

Undergraduate course on Real-time Systems Linköping 41 of 36 Autumn 2009 Error detection If a node sends a message that is corrupted in transmission the Cyclic Redundancy Check (CRC) field will be wrong The first node that notes this sends This works as long as the node is not erroneous – Babbling idiot!

Undergraduate course on Real-time Systems Linköping 42 of 36 Autumn 2009 Recent developments Formal verification of clock synchronisation and fault tolerance mechanisms X-by-wire applications seem to adopt TTP solutions for higher reliability and fault tolerance New solutions to combine event-triggered and time-triggered messages are needed: –Simulating CAN over TTP, or TT-CAN? –FlexRay

Undergraduate course on Real-time Systems Linköping 43 of 36 Autumn 2009 Summary CAN: Event-triggered vs TTP: Time-triggered Both have pros and cons in hard real- time applications...