Eg. Volvo S80 contains 18 major units connected via two in-vehicle ... Highly
robust (error mechanisms to overcome ... DLC DATA (0-8 bytes) CRC code. EOF.
ASTEC/WCET
10/15/2007
RealReal-Time Networks and Distributed Systems
A Distributed RealReal-Time System
» Topics ¡
Distributed RealReal-Time Systems
¡
Real Time Networks
¡
Analysis of Distributed RT Systems
BusBus-based multimulti-processor systems RT busses e.g. CAN, TTP, TTCAN Message Transmission Analysis Response Time Analysis
1
2
Why Distributed Systems ?
Electronics in automobiles
Physically distributed applications (close to physical equipment, e.g. engine control) Capacity (better price/performance than single CPU and much less wiring, wiring, 1200m in 1997!) ¡ Modularity (components developed in isolation) ¡ Scalability (just add another node) ¡ Debugging (easier?) ¡ Fault tolerance (errors only
» Trend towards more and more electronics ¡
¡
15% to 30% of component cost of a car is electronics
¡
» Trend towards more complex systems ¡ ¡
Many functions (both comfort and vehicle control) Eg. Volvo S80 contains 18 major units connected via two inin-vehicle networks
propagate within subpart of system)
Challe Challenge: nge: low cost!
build complex distributed systems and maintain high reliability at
3
Dsign of Distributed RTS
RTRT-Networking: Basic Problem
Tasks - Execution time - Period - Deadlines - Dependences
Kernel
allocation/ scheduling
4
Running system
Bounded latency: A → B » Competing traffic » Guarantees
Functional Design
¡ ¡
HardHard-RT: Absolute G. SoftSoft-RT: Probabilistic G.
» Other issues
3 aspects: The core for the development - off-line allocation of real time systems - run-time scheduling - á priori schedulability analysis
¡
Reliability
¡
Resource Utilisation
F. detection & recovery
5
6
1
ASTEC/WCET
10/15/2007
RTRT-Networking: Solutions
CSMA/CD
RTRT-Networking: Solutions
Token-ring
(Carrier Sense Multiple Access / Collision Detection)
Time triggered
Event triggered
TDMA
Physical or logical ring Circulating token No collisions RT-guarantees possible
Ethernet Collisions back-off Stochastic behaviour No RT-guarantees
(Time
CSMA/CR
Division Multiple Access,e.g. GSM)
Priority driven Dynamic Scheduling
Pre-Scheduled Predictable Testable
Flexible e.g. CAN
Static e.g. TTP
D A
B
Pri: A>B>C>D
B
C
A
0
D
C
T time
0
time Response time for C
7
8
Controller Area Network (CAN)
More examples
» Initiated in the late 70’s to connect a number of processors
» Time triggered:
over a cheaper shared serial bus
SAFEbus - airplanes, eg. Boeing TTA - cars, eg. Audi, Volkswagen ¡ FlexRay - cars, eg. BMW, DaimlerChrysler ¡ ¡
» From Bosch (mid 80ies) for automotive applications
» Event triggered ¡ ¡ ¡
» De facto standard for
invehicle comm.
CAN - cars, eg. Volvo, Volvo, Saab, VW, Ford, GM Byteflight - cars, BMW LIN – a cheaper and simple bus protocol
(100 million CAN nodes sold 2000)
» Controllers available
(from Phillips, Intel, NEC, Siemens, etc.)
» Mixtures
» Shared broadcast bus (one sender many receivers)
TimeTime-triggered CAN TTA extended with events
(CSMA/CR)
» Highly robust (error mechanisms to overcome
disturbance on the bus)
» Medium speed: ¡
Max: 1Mbit/sec; typically used from 35 Kbit/sec Kbit/sec up to 500Kbit/sec
9
10
Controller Area Network (CAN)
Controller Area Network (CAN)
Node 1 Host Microcontroller
TxD
CAN Transceiver
Vcc +5V
Line Voltage
Driver
3.5 V Vdiff
Frame layout:
CAN_L
Vdiff
CAN_H
1.5 V
Vcc +5V
Recessive Logic "1"
RxD
Dominant Logic "0"
Recessive Logic "1"
Receiver
Node 2
Node 3
Node n
120 R
120 R
Global Time
¡ ¡
twisted-pair, optic fibre or coax
» Small sized frames (messages) ¡ ¡
Arbitration Field
Control Field
Data Field
ACK
» Relatively high overhead
Delimiter SOF 1
ID part 1 11
RTR IDE 1
1
r0
DLC
DATA (0-8 bytes)
1
4
Max. 64 data bits
CRC code 15
¡
EOF 111
0 to 8 bytes Very different from mainstream computing messaging A frame size of more than 100 bits to send just 64 bits
7
CAN-frame
CAN data frame 11
id 11 bits
control 36 bits
data 0-8 bytes
12
2
ASTEC/WCET
10/15/2007
The CAN Arbitration Mechanism
The CAN Arbitration Mechanism Vill sända ram Send a frame ?
» Shared broadcast bus
Nej
- if all nodes sends 1 the bus becomes 1, otherwise 0.
» A frame is tagged by an ¡ ¡
Bus Bussen ledig? free?
identifier
indicates contents of frame also used for arbitration as ”priority”
» BitBit-wise arbitration
D B
» Bus behaves behaves like a large ANDAND-gate
Ja
D
Node Priority
Send Lägg ID ut bit 00 id-bit
B A
C
C
A
node A wins arbitration
Example:
A 001
B 010
Läs data värdet Read on på bussen bus
Each message has unique priority ⇒ node with message with lowest id wins arbitration ¡ Lowest id = highest priority! ¡
Nej
The same Samma som as sent? utlagt?
» The CAN bus is a prio. scheduled resource
C 101
D 011
Nej Ja
Send Läggnext ut bit bit nästa
Läs värdet Read data on bus på bussen
The same Samma som as sent? utlagt?
Ja
Sista The last biten? bit? Ja
Nej
Send theresten rest of Skicka the frame av ramen 13
14
Details on CAN
Details on CAN
» Each message has a priority: a unique static
» When the bus is busy, the stations wait (listening all time) » As soon as the bus is idle, all stations who want to send
number, used as the identifier of the message » Arbitration mechanism to ensure: the highest priority message is the one transmitted » Limits on speed and length (physical/electrical properties):
enter the arbitration phase (run the arbitration algorithm) ¡ ¡
Transmit the highest priority message, from the most significant bit to the least significant one 0 is the highest priority!! 0: dominant bit (in fact, sending 0 by ”high voltage”) 1: recessieve bit
to send 1Mbit/sec, wire/bus must be no longer than 50m ¡ To send 0.5Mbit/sec, the bus must be no longer than 100m ¡ The bus can have an arbitrary number of nodes ¡ Each station has a queue for messages ordered by priorities ¡
¡ ¡
It behaves like an ANDAND-gate Send and monitor: Send a 1, but monitor a 0: a collision the protocol says: nodes sending 0’s win, the others back off (monitor (monitor and send) This means: the highest priority message wins, to be transmitted E.g. 100, 101, 111 on three stations, 100 will be sent
15
16
Details on CAN
More details on CAN
» After the priority transmitted (the arbitration is finished), the the
» The total number before bitstuffing: 8n+47
» A message contains: 0-8 bytes for data and 47bits OH
» After bitstuffing: 8n+47+ 8n+47+(34+8n(34+8n-1)/4 1)/4
rest of the message is transmitted ¡ ¡ ¡ ¡
Priority/identity: 11bits Data field: 00-8 bytes long CRC field (checksum, parity bits etc: checking the message has not been corrupted, and other ”housekeeping” bits) Out of the 47, 34 bits are bitstuffed
Max: 64+47+24=135 bits E.g. 1Mbit/sec, 1 bit needs 1 micro seconds ¡ The max transmission time for one message= 135 micro sec ¡ ¡
» 000000 and 111111 are reserved as ”marker” to signal all
stations on the bus ¡ ¡
So ”bitstuffing” is needed: whenever 00000 or 11111 appears in a bitstream, an extra bit of the opposite sign should be added E.g. 1111 1000 0111 1000 0111 1 should be 1111 10 1000 001 0011 1110 1110 0000 1111 10 10
17
18
3
ASTEC/WCET
10/15/2007
A B C D
The CANCAN-bus Abstraction Frames queued in priority order
Response time
Set of messages = M (queued on different nodes) Mj = < Tj, Cj > (Mj ∈M )
D B C
A
Tj = period (time between queuing) Cj = transmission time
The whole bus + CAN controllers can be abstracted as one queue
A
Transmission Delay Calculation for CAN
Bj = blocking time (waiting for low priority message, bus non-preemptive) Worst-case waiting/queuing time (before transmission ):
B
qi = Bi +Σj∈hp(i) qi/TjCj
Removed after transmission time
C Priority queue
D
Frame in transmission
hp(i) = frames with priority higher than Pi
Worst-case Response time (delay before delivered):
Ri = Ci+qi
Response time 19
20
End of Story?
Transmission delay analysis » Ci = (number of bits) X (time to transmit 1 bit)
D B
» Bi = MAX ∀k ∈ lp(i) (Ci) K ⇒ the node shutsshuts-off itself (is failfail-silent)
D B C
A
Detect obstacle (read sensor)
Initial processing
Send msg on bus
Calculate action
Send msg on bus
Inflate airbag
time
» System wide (end(end-toto-end) timing requirements ¡ ¡
»
control closed over the entire system includes sensors, CPUs, controllers, busses, actuators, OS, ...
Holistic analysis can be applied!
27
28
Distributed Systems
Holistic Scheduling Problem » When tasks on a node can both send and receive
messages we have a holistic scheduling problem » The equations giving the worst case time for tasks depends on messages arriving at the node » We cannot apply the processor send(i) scheduling analysis before we 0 CPU dest(i) act(i) get values from the bus msg(i) scheduling analysis CAN msg(j) » Similarly: We cannot apply the bus scheduling analysis before we get values from the processor scheduling analysis » Solution: Holistic Analysis 29
» Tasks on CPUs are exchanging msgs over CAN » Tasks are queuing messages ¡ Completion times will vary => ¡ Jitter (variations in release times) will be inherited » Message m(i m(i), queued by a task
⇒ Jm(i)= Rsend(i) – Csend(i)
dest(i) is activated by a message m(i m(i): ⇒ Jdest(i) dest(i) = Rm(i) - Cm(i)
send(i): send(i):
» Task
0 send(i) CPU
CPU dest(i) msg(i)
CAN 30
5
ASTEC/WCET
10/15/2007
Distributed Systems 0 send(i)
» Example: Node A: ¡
Rsend(i) = Csend(i)+Σ
¡ Jm(i)
CPU dest(i)
msg(i)
∈
j
hp(send(i))
CAN
(Rsend(i) + Jj)/Tj Cj
= Rsend(i) send(i) - Csend(i) send(i) = wm(i) + Jm(i) ¡ wm(i) = Cm(i) + Bm(i) +Σ j∈hp(m(i)) (wm(i) + Jm(j m(j)) /Tm(j) Cm(j) ¡ Jdest(i) = Rm(i) - Cm(i) ¡ Rdest(i) = wdest(i)+ Jdest(i) dest(i) ¡ wdest(i) = Cdest(i)+Σ j∈hp(dest(i)) (wdest(i) + Jj)/Tj Cj
Node B:
Cm(i) m(i) = Bm(i) = 135 micro sec
31
Event Driven Peak Load
Network Message Queue
Problem with CAN: some of the message may never get a chance for transmission
¡ Rm(i)
CAN:
9
9
Other Solutions: e.g.TTP - the Time Triggered Protocol
Deadline for message 9 9
9
9
8
9
9
9
2
5
8
9
3
6
1
2
5
8
6
3
2
1
» Intended for XX-byby-wire applications
9
8
5
CAN BUS
9
Time
Example: BreakBreak-byby-wire in car
» A lot of features built in into the bus protocol (which must be added on top of the CAN bus)
9 3
6
2
1
5
» Conceptually similar to
8
Time
2 1 8
3
static cyclic scheduling
9
network
Message Ready
32
6 5
Engin
Gear-Shift
Gear-Box
ABS
ABS
ABS
ABS 33
34
TTP - Time Triggered (TDMA)
TTP - Clock Synchronization » All nodes must have the same time
Node 1
Node 2
Node 3
» Clocks synchronized within bound δ
Node 4
» Adjust by speeding
All nodes has identical message tables TDMA round
TDMA round
up or down » Messages used for sync.
Local C time
dC/dt > 1
dC/dt < 1
δ
Expected arrival (EA) ¡ Real arrival (RA) ¡ All clocks set to average ¡
Perfect t time
∆t TDMA runda TDMA - slot reserved for node 1
frame
Nod 1 does not use its slot.
Delay of message sending due to synchronization 35
dCn/dt = 1
EA
0
25
50
75
RA
0
23
52
79
Diff
0
2
-2
-4 36
6
ASTEC/WCET
10/15/2007
TTCAN: an example of TTP TTP - CAN: a comparison TTP Node 1 Master
Node 2
Node 3
Node 4
¡ ¡ ¡ ¡ ¡
Transmission Column 0
REF1
1
MSG1
2
MSG2
3
MSG3
Basic Cycle (n)
0
REF1
1
2
MSG 4
3
MSG5
0
ClockClock-synchronization FaultFault-handling Membership protocol
REF1
Basic Cycle (n+1)
Time triggered Overallocation of aperiodic messages No jitter UltraUltra-reliable systems Includes distributed system functionality
¡
Capacity 10 Mb/sec
CAN ¡ ¡ ¡ ¡ ¡ ¡
¡
Event triggered No message sending if not neccessary Jitter due to varying system loads Priority driven RTRT-Network Some functionality added on top Capacity: 1Mb/sec
Time 37
38
Trends for RT networks in Automotives » Today CAN dominates » TimeTime-triggered seems to be the future for XX-byby-wire: TTP
e.g. FlexRay, FlexRay, TTCAN
» Future cars will include many different and parallel buses: ¡ ¡ ¡ ¡
CAN for comfort TT for XX-byby-wire MOST for multimedia etc.
39
7
