So far... TDDC47: Real-time and Concurrent Programming Lecture 8: Real-time Communication

advertisement
So far...
TDDC47: Real-time and
Concurrent Programming
Lecture 8: Real-time Communication
Simin Nadjm-Tehrani
• In CPU scheduling lectures we looked at
– Single processor hard real-time
scheduling
...
• But...
• Most real-time systems are distributed
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping University
Undergraduate course on Real-time Systems
Linköping
40 pages
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
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
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
3 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
Real-time constraints
• When message transmissions must have
a well-defined time bound for the
system to meet it deadlines
– So called end
end-to-end
to end deadlines
• Example: shortly after each braking, the
brake light must know it in order to turn
on!
Undergraduate course on Real-time Systems
Linköping
2 of 40
Autumn 2010
5 of 40
Autumn 2010
4 of 40
Autumn 2010
New resource
Single Node
Distributed
Resource
CPU
Bandwidth
Scheduled
element
Task/process
Message
Demand on
resource
WCET &
interarrival
Message size &
frequency
Performance
metric
Deadlines met,
Utilisation
Message delay,
Throughput
Undergraduate course on Real-time Systems
Linköping
6 of 40
Autumn 2010
1
Two approaches
• We will look at two dominant methods
for bus scheduling
– Time-triggered (TTP)
– Event-triggered (CAN)
Time-triggered protocol (TTP)
• Origin in research projects in Vienna in
early 90´s
[Kopetz et.al]
Node 1
…
Node n
n-1
1
Node n
• Used extensively in automotive and
aerospace applications
• Time division multiple access (TDMA)
Undergraduate course on Real-time Systems
Linköping
7 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
Communication protocol
• Message Description List: allocates a
pre-defined slot within which each node
can send its (pre-defined) message
Node 1
…
Node n-1
8 of 40
Autumn 2010
Message scheduling
• TDMA round implemented through the
MEDL (message description list)
• MEDL has a static schedule for each
message
Node n
• No constraints on (local) node CPU
scheduling
…
A TDMA round
Undergraduate course on Real-time Systems
Linköping
9 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
Temporal firewall
Host
CNI
Node 1
CC
…
Host
Node n
CC
10 of 40
Autumn 2010
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
• CNI provides temporally accurate state
information (via clock synchronisation)
• When the data is temporally not valid, it
can no longer be exchanged
Undergraduate course on Real-time Systems
Linköping
11 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
12 of 40
Autumn 2010
2
The CAN bus
• Controller area network that exists in all
cars built in Europe today
• Compulsory for the on-board diagnostics
in USA car models from 2008
Amount of
wires…
• Why?
– Imagine: 2500 signals, 32 ECUs on
one bus
Undergraduate course on Real-time Systems
Linköping
13 of 40
Autumn 2010
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
Collisions
• Ethernet has high throughput but
temporally nondeterministic
Node 3 waits for sending
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
Node 2 & 3 start to send
Node 2 waits for sending
Node 1 sends
Collision
Undergraduate course on Real-time Systems
Linköping
15 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
Collisions & non-determinism
How
• Model the network throughput andoften?
compute probabilistic guarantees that
collisions will not be too often
– Theoretical study:With 100Mbps, sending
1000 messages of 128 bytes per second,
there
h
is a 99% probability
b bl
that
h there
h
will
ll b
be
a 1 ms delay over ~1140 years
[www.rti.com Ethernet study]
• If you cannot measure effects of
collisions, make collision resolution
deterministic!
Undergraduate course on Real-time Systems
Linköping
14 of 40
Autumn 2010
17 of 40
Autumn 2010
16 of 40
Autumn 2010
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
18 of 40
Autumn 2010
3
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
19 of 40
Autumn 2010
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
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
20 of 40
Autumn 2010
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
21 of 40
Autumn 2010
Worst Case Response
Undergraduate course on Real-time Systems
Linköping
22 of 40
Autumn 2010
Interference and blocking
According to [Tindell & Burns 94]:
Message response time =
Ji: Jitter (from event to placement in queue)+
wi: Queuing time (response time of first bit)+
Ci: Transmission time
Ri = Ji +wi + Ci – tbit
• Ii: waiting due to higher priority
processes, bounded if messages are
sent periodically
wi = tbit + Bi + Ii
Bi + Ii : Blocking and Interference time (as RMS)
• Ji: jitter, has to be assumed bounded
(by assumptions on the node scheduling
policy!)
Undergraduate course on Real-time Systems
Linköping
• Bi: waiting due to lower priority
messages, only one can start before i
23 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
24 of 40
Autumn 2010
4
Solving recurrent equations
• Blocking is fixed: max Cj of all lower priority
messages
• wi = Bi +
 khp(i) ( w + J
i
k
+ tbit
Solving recurrent equations
• Blocking is fixed: max Cj of all lower priority
messages
)/ Tk Ck
• wi = Bi +
• w0i = Bi
 khp(i) ( w + J
i
k
+ tbit
)/ Tk Ck
• w0i = Bi
• wn+1i = Bi +
 khp(i) ( win + Jk + tbit
)/ Tk Ck
• After fixed point is reached: Bi + wn+1i + Ci  Di ?
Undergraduate course on Real-time Systems
Linköping
25 of 40
Autumn 2010
• wn+1i = Bi +
 khp(i) ( win + Jk + tbit
• After fixed point is reached: Bi + wn+1i + Ci  Di ?
Undergraduate course on Real-time Systems
Linköping
Example
• From [Davis etal 2007]:
Message priority
period
deadline TX time
A
1
2.5ms
2.5ms
1ms
B
2
3.5ms
3.25ms
1ms
C
3
3.5ms
3.25ms
1ms
Exercise
27 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
The original analysis
• From 1994
• … was Optimistic!
• There can be a case where analysis
shows schedulability but in fact
deadlines can be missed!
28 of 40
Autumn 2010
The correct analysis
• Takes account of the fact that different
instances of the same message may
appear in a busy period
and
• All such instances should be shown to
meet their deadlines!
[Davis, Burns, Bril, Lukkien 2007]
Undergraduate course on Real-time Systems
Linköping
26 of 40
Autumn 2010
• Compute response times for the three
messages
– To show how a w-term for each message
was computed based on original method
from 1994
– Assume ji= 0
Undergraduate course on Real-time Systems
Linköping
)/ Tk Ck
[Reading: Sec. 3.1 & 3.2, Davis et al.07]
29 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
30 of 40
Autumn 2010
5
Revised computation
• Now with the new formula where busy
period term is according to
[Davis etal 2007]:
• Rm(q)= Jm + wm(q) – qTm + cm
• q=i, w(q) computes busy period for ith
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 message m, denoted tm
Undergraduate course on Real-time Systems
Linköping
Example revisited
31 of 40
Autumn 2010
Message priority
period
deadline TX time
A
1
2.5ms
2.5ms
1ms
B
2
3.5ms
3.25ms
1ms
C
3
3.5ms
3.25ms
1ms
Undergraduate course on Real-time Systems
Linköping
Exercise
• Redo the old exercise with the Davis et
al. variant of the busy period
Solution
• To know how many instances of message m are relevant
we need to find the longest busy period for m denoted
tm
• t0C = CC= 1
wn+1m (q) =
Bm + q.Cm +
 khp(m) (
32 of 40
Autumn 2010
• t1C = t0C/TC CC + t0C/TB CB+ t0C/TA CA = 1+1+1= 3
• t2C = t1C/TC CC + t1C/TB CB+ t1C/TA CA = 1+1+2= 4
• t3C = t2C/TC CC + t2C/TB CB+ t2C/TA CA = 2+2+2= 6
wn
m
• t4C = t3c/TC CC + t3C/TB CB+ t3C/TA CA = 2+2+3= 7
+ Jk + tbit )/ Tk Ck
• t5C = t4C/TC CC + t4C/TB CB+ t4C/TA CA = 2+2+3= 7
• tC = 7 Which means 2 instances of message C are
relevant! QC= 2 and q: 0..QC-1
• Qm = ( tm + Jm )/ Tm
Undergraduate course on Real-time Systems
Linköping
33 of 40
Autumn 2010
Computing the queuing time
• w0C (0) = BC+0.CC= 0
• w1C (0) = (w0C(0)+ tbit)/TB CB + (w0C (0)+ tbit) /TA CA = 1+1
=2
• w2C (0) = 1+1= 2
 wC (0) = 2
 RC (0) = wC (0) – qTC + CC = 3
• w0C (1) = wC (0) + 1.C
1 CC = 2+1=
2+1 3
• w1C (1) = 1.CC + (w0C (1)+ tbit)/TB CB + (w0C (1)+ tbit)/TA CA
= 1+1+2 = 4
• w2C (1) = 1.CC + (w1C (1)+ tbit)/TB CB + (w1C(1)+ tbit)/TA CA
= 1+2+2=5
• w3C (1) = 1.CC + (w2C (1)+ tbit)/TB CB + (w2C (1)+ tbit)/TA CA
= 1+2+3 = 6
• w4C (1) = 1.CC + (w3C(1) + tbit )/TB CB + (w3C (1)+ tbit) /TA
CA = 1+2+3 = 6
 wC (1) = 6
 RC (1) = wC (1) – qTC+ CC = 3.5
Undergraduate course on Real-time Systems
Linköping
35 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
34 of 40
Autumn 2010
If we continue with Qm ...
• w0C (2) = wC (1) + 2.CC = 6+2=8
• w1C (2) = 2.CC + (w0C(2) + tbit )/TB CB +
(w0C (2)+ tbit )/TA CA = 2+3+4 = 9
• w2C (2) = 2.CC + (w1C(2) + tbit )/TB CB +
( 1C (2)+
(w
(2) tbit )/TA CA = 2+3+4
2 3 4= 9
wC (2) = 9
RC (2) = wC (2) – qTC+ CC = 3
Not adding to the response time
RC =max{q:0..QC-1} RC(q) = 3.5
Undergraduate course on Real-time Systems
Linköping
So the
second
instance
was why
message
C missed
its
deadline!
36 of 40
Autumn 2010
6
Error detection
• If a node sends a message that is
corrupted in transmission the Cyclic
Redundancy Check (CRC) field will be
wrong
Host
CNI
• The first node that notes this sends
000000
BG
• This works as long as the node is not
erroneous – Babbling idiot!
Undergraduate course on Real-time Systems
Linköping
TTP: failure detection
Host
…
CC
BG BG
BG
CC
BG BGBG BG
BG: Buss Guardian (stops babbling idiots)
37 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
38 of 40
Autumn 2010
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
Questions?
Q
• 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
39 of 40
Autumn 2010
Undergraduate course on Real-time Systems
Linköping
40 of 40
Autumn 2010
7
Download