1

Lecture 9
Real-Time Communication
The software substitute
Today mechanical and electrical
control systems are replaced by
computer based solutions. p
Contributing causes are:
It is possible to improve already
existing technologies, e.g., brakes in
cars
It is possible to do things previously p g p y
seemed impossible, e.g., drive-by-
wire, electronic stability program in
cars, etc..
2
Example: Drive-by-wire
Example: Volvo Sirius
by-wire - mechanical and hydraulically control are replaced by digital control
Four wheel steering, local brakes on each wheel, portable steering wheel
Puts very high requirements on reliable communication!
Example: running robot Dasher
A robot constructed by students
at Mlardalen University.
The aimof the project is to design The aim of the project is to design
and build a humanoid robot for
running 100 meters.
Students working with simulation,
mechanical design, hydraulic
systems, electronic design,
computer systems, programming
and questions regarding 'how does
a human do when running
100meters'.
Uses CAN-bus for
communication
3
Example intelligent ABS-system
One node for each brake
One node for break pedal
Application: a distributed control
ABS 1 ABS 3
Brake
pedal
ABS1
algorithm that computes break
force for each of the wheels
ABS 2 ABS 4
pedal
Brake pedal
S
ABS 3 & 4
ABS2
S1 C1 A1
S4
S3
S2
S2 C2 A2
S4
S3
S1
Why distributed architecture?
It used to look like this
As the number of electronic devices grew
the wiring gets more messy
the weight of the car increases
4
Why distributed architecture?
Cost reducing
Flexibility
Functionality
In modern cars,
point-to-point wiring
is replaced by a
common common
communication bus
Why distributed architecture?
Processing closer to data source
Intelligent sensors and actuators
F lt t l Fault-tolerance
Error-containment within nodes
Composability
System composition by integrating
sub-systems
Scalability
Easy addition of new nodes
Maintainability
Easy node replacement
5
Distributed real-time systems require robust real-
time communication
Non real-time systems
Throughput
Average response time
Average latency
Real-time systems
Predictability
Timing requirements on individual response times and latencies
Require predictable communications network
Analysis before the system is operating
Challenge
to construct the computer systems that have at least as good reliability
and safety as the system they are replacing
Event-trigged communication
Node 1 Node 2
Task C Task D Task E
Task A
Task B
NW
event
response
Message
from A to B
6
Time-trigged communication
Node 1 Node 2
Task C Task D Task E
Task A
Task B
NW
control
sampling
Ordinary communication protocols
Ethernet
Addressed broadcast messages
Collisions between packets
Resending after a random time g
Impossible to determine transmission
times
RT guarantees not possible (without
collision resolution)
T k i Token ring
Circulating token
No collisions
RT guaranties possible
7
Protocols suitable for RT-communication
Node 1
Node 2
Collision Highest
CSMA/CR
Priority based
Online scheduled
Fl ibl
TDMA
Node 3
Node 4
Collision
resolution
Highest
prio sends
Flexible
Example: CAN-protocol
TDMA
Time-trigged (periodic)
Predictable
High testability
Example: TTP-protocol
Node 1 Node 2 Node 3 Node 4 Node 1
Max waiting time =
1 TDMA round
CAN Control Area Network
Originally developed for automotive industry needs
1983: BOSCH starts CAN development (Intel joins 1985)
1987: First CAN chip 1987: First CAN chip
1990: First car with CAN
1993: ISO standard
Now used even in industry applications
Very common in machinery
CAN-controllers developed by Philips, Intel, NEC, Siemens
An implementation of CSMA/CR An implementation of CSMA/CR
Priority based
CR is the central mechanism
Bitwise arbitration to resolve collisions
8
Structure and function
Topology: a broadcast bus
A shared medium (cable) with connected nodes
The nodes send frames on the bus that can be picked up by all other
nodes on the same bus
1 Mbit/s at 50m bus length
Behaves as an AND-grind: bus value =AND between all bits on the
bus
Node
B
Node
D
Node
A
Node
C
<50m 1Mbit/s
A typical configuration
Node 1
(e.g. ABS)
Node 2
(e.g. ESP)
Host
controller
CAN
controller
Host
controller
CAN
controller
CAN
transceiver
CAN bus
CAN
transceiver
9
Traffic model
B D
Abstraction of CAN network:
- Frames in priority queues
- No pre-emption
A C
A
B
C
D
Resp time
Removed after sending
A buffer that holds
each frame C
i
time
units
Message format
Data frames
Used for data transmission e.g., sampling values from a sensor
Standard CAN frame (CAN 2.0 A), 11 bits identifier
Extended CAN frame (CAN 2.0 B), 29 bits identifier Extended CAN frame (CAN 2.0 B), 29 bits identifier
Remote Frames
Used for information requests.
The transmitting node is asking for information of the type given by
the identifier.
Error frames
Used for error signaling Used for error signaling
Overload Frames
Used to delay the transmission of the next message frame
The node sending the Overload Frame is not ready to receive
additional messages at this time
10
CAN-frame (version 2.0 A, standard format)
SOF ID RTR Control Data CRC CRC
DEL
ACK ACK
DEL
EOF IFS
1 11 1 6 0-8 15 1 1 1 7 min 3
bit bits bit bits bytes bits bit bit bit bits bits
SOF - Start of Frame, start bit (always 0), used for signaling that a frame will be
sent (the bus must be free)
ID - Identifier, identity for the frame and its priority
RTR - Remote Transmission Request
Control - indicates the length of the data field
Data - message data
CRC - Cyclic Redundancy Check,
CRC DEL - CRC delimiter
ACK - Acknowledgement
ACK DEL - ACK delimiter
EOF - End of Frame
IFS - Inter Frame Space, resending wait time
Arbitration mechanism
A node wants to
send a frame
B N Bus
free?
Put ID-bit 0 on the bus
Read bus value
Yes
No
Same as the
one we put?
No
Put the
next bit
Yes
Read bus
value
Same as
the one we
put?
Last bit?
Send the rest of
the frame
Yes
No
Yes
No
11
Arbitration mechanism
Example:
Assume a simplified CAN-system with only three ID-bits and three nodes A, B, C:
000 highest priority
A
ID=010
B
ID=100
C
ID=011
000 highest priority
111 lowest priority
which gives:
A-high prio, C-middle, B-low
How does the arbitration look like if the nodes are sending simultaneously?
Bit 0 Bit 1 Bit 2 Msg ID Bit 0 Bit 1 Bit 2
0
1
0
1
1
0
1
Send the rest of the frame
abort! (bit 0 bus value)
abort! (bit 2 bus value)
Msg ID
A
B
C
010
100
011
Bus value: 0 1 0
Error handling
Error detection with check sum (CRC)
If the frame is received correctly, the ACK-bit is set to 0
Error signaling
The node that detects an error puts instantly 000000 on the
bus
Because zero is the dominant value, all nodes will detect the
error rapidly
Some CAN-systems have one as the dominant bit bit-
pattern for error signaling is 111111 pattern for error signaling is 111111
12
Timing properties
CAN is time deterministic
The latency can be predicted
Possible to calculate how long time it takes to deliver a frame
How many bits are sent in a CAN-frame?
SOF ID RTR Control Data CRC CRC
DEL
ACK ACK
DEL
EOF IFS
1
bit
11
bits
1
bit
6
bits
0-8
bytes
15
bits
1
bit
1
bit
1
bit
7
bits
min 3
bits
Sum = 47 + 8n
(n =nr of data bytes)
Timing properties
We must avoid two bit-patterns that are used for error signaling
i.e., 000000 and 111111:
Bit stuffing: the sender puts extra bits on strategic places to prevent
forbidden bit-patterns forbidden bit patterns
The receiver reconstruct the original frame by removing the extra bits
Example:
00101000000101 Original frame:
Sender puts extra bits: 001010000010101 Sender puts extra bits: 001010000010101
Receiver removes extra bits: 00101000000101
Bits sent on the bus: 001010000010101
13
Timing properties
Do we need to perform bit stuffing on all 47+8n bits?
No, only 34 (of 47) control bits are affected
By forbidding some ID values we can avoid bit stuffing in the frame ID
SOF ID RTR Control Data CRC CRC
DEL
ACK ACK
DEL
EOF IFS
1
bit
11
bits
1
bit
6
bits
0-8
bytes
15
bits
1
bit
1
bit
1
bit
7
bits
min 3
bits
34+8n affected bits 3 8 a ected bts
One (1) extra bit after 5 same bits gives:

+
5
8 34 n
Nr of extra bits =
Timing properties
Is this correct?
Not completely. The standard allows both 000000 and 111111 for
error signaling. We might need to stuff even more extra bits
Example:
Original: 1111 1000 0111 1000 0111 1
After bitstuffing: 1111 10000 01111 10000 01111 1
Extra bit
after 5
original
Extra bit
after 4
original
Extra bit
after 4
original
Extra bit
after 4
original
..etc
To avoid forbidden bit patterns we must insert an extra bit after
the first five bits and one extra bit after each fourth original bit.
original
bits
original
bits
original
bits
original
bits
14
Timing properties
Hence, the number of extra bits in a CAN-frame is:

+ 1 8 34 n

4
Now we can calculate the total transmission time for a CAN-frame:
bit i
n
n C )
4
1 8 34
8 47 (

+
+ + =
n
max
=8 and 1Mbit/s, and
bit
=1s (bus speed) gives:
s s C
i
135 1 )
4
1 8 * 8 34
8 * 8 47 ( =

+
+ + =
Response time analysis for CAN
CAN is priority based. Can we use some kind of response time analysis
(similar as for tasks)?
Yes, with a slight modification. The CAN-bus is non-preemptive, so when a frame
has managed to send the first bit, then it will continue sending the rest of the
frame (without fear of being preempted by high priority frames)
j
i hp j j
i
i bit i
C
T
w
B w

+ + =
) (

Response time for a frame i:

bit i i i
C w R + =
Where the blocking time for a frame is given by:
bit k i lp k i
C B 135 max
) (
=

hp(i) =high priority frames (that can delay the first bit)
lp(i) =low priority frames (that can block the first bit)
15
Response time analysis for CAN
Even frames can have jitter:
- variations in time when a frame is queued
- usually due to the sender tasks jitter
J
j
i hp j j
j i
i bit i
C
T
J w
B w

+
+ + =
) (

bit i i i i
C w J R + + =
The equations above can be re-written as:
j
i hp j j
bit j i
i i
C
T
J w
B w

+ +
+ =
) (

i i i i
C w J R + + =
CAN - Example
Assume a CAN system with three nodes.
Task T C Msg
Node 1 (id=011)
Assumptions:
- Dominant bit: 0
A1 10000 3000 m1
A2 7000 1000 -
Task T C Msg
B1 5000 1000 m2
B2 4000 1000 -
Node2 (id=001)
- Bus speed:1 Mbit/s
- Task instances send their messages at
the end of the execution
- The size of each message is 135 bits
- Task priority assignment is according to
Rate Monotonic
000 000
Task T C Msg
C1 4000 1000 m3
C2 10000 1000 -
Node 3 (id=000)
a) Calculate jitter for the messages
b) Calculate response times for the
messages
16
CAN - Example
a) J itter
Node 1:
R
max R
min
0
0
4000 20000
7000 14000
10000 13000
A2
A1
J
m1
=R
max
(A1) - R
min
(A1) =4000-3000=1000
Node 2: Node 2:
(Same as above)
J
m2
=R
max
(B1) - R
min
(B1) =2000-1000=1000
Node 3:
J
m3
=R
max
(C1) - R
min
(C1) =0 (Note! No jitter, C1 has high prio)
CAN - Example
b) Response times (priorities: m3 high prio, m2 middle, m1 low)
m3:
s B w
m m
135 0
3 3
= + =
lp(m3)={m1,m2}B(m3)=max(C
m1
, C
m2
)=max(135, 135)=135
s C w J R
m m m m
270 135 135 0
3 3 3 3
= + + = + + =
lp(m2)={m1}B(m2)=C
m1
=135
s C w J R
m m m m
1405 135 270 1000
2 2 2 2
= + + = + + =
270 135
4000
1 0 0
135
3
3
3
0
2
2
1
2
=

+ +
+ =

+ +
+ =
m
m
bit m m
m m
C
T
J w
B w

270 135
4000
1 0 270
135
2
2
=

+ +
+ =
m
w
0
0
2
=
m
w
m2:
lp(m1)={}B(m1)=0 m1: lp(m1)={}B(m1)=0
s C w J R
m m m m
1405 135 270 1000
1 1 1 1
= + + = + + =
270
3
3
3
0
1
2
2
2
0
1
1
1
1
=

+ +
+

+ +
+ =
m
m
bit m m
m
m
bit m m
m m
C
T
J w
C
T
J w
B w

270 135
4000
1 0 270
135
5000
1 1000 270
0
2
1
=

+ +
+

+ +
+ =
m
w
0
0
1
=
m
w
m1:
17
TTP Time Triggered Protocol
An implementation of TDMA
Time-trigged
Bus access is pre-defined in an offline schedule
Nodes can be assigned several slots g
Originally developed on Technical University of Vienna in
Corporation with several car manufacturers
Commercial development by TTTech
Aimed for X-by-wire applications Aimed for X by wire applications
Boeing 777, Airbus 340, Audi,
Very high demands on reliability
Safety-critical real-time systems that require fault tolerance
TTP Priorities and requirements
Safety without compromise
No single point of failure
Formal analysis of critical functions
Composability
Building system out of prevalidatedcomponents
Flexibility
Flexible reuse of existing components
Communication with short and constant delay
Global time (clock synchronization)
Membership service
Small overhead
18
TTP - typical system configuration
Node
A
Node
B
Node
C
bus 1
bus 2
FTU
Fail Silent nodes
- Nodes detect errors by themselves
- They either deliver correct result or no result at all
Grouped in FTUs (Fail Tolerant Unit)
- Several nodes that do the same in parallel
- FTU:n is working as long one of the nodes is working
Time-trigged clocks must be synchronized
- continuous synchronization
- some tens of microseconds
TTP - synchronization
The receiver compares actual receiving time with expected
receiving time
19
CAN vs TTP
TTP
Time-trigged (periodic)
Easier analysis
P di t bl Predictable
High testability
CAN
Priority based
Faster response times for high priority messages
Flexible
Started in year 2000 as an industrial consortium: BMW, Daimler-Chrysler,
Philips och Motorola. Today, more than 100 members world wide.
The most important goals
FlexRay
The most important goals
High speed, an order of magnitude higher than CAN (10Mbps)
Deterministic communication that enables for easier system
integration
Fault-tolerant communication that makes it possible to replace
mechanic and hydraulic safety-critical with computer systems
Properties
Topological flexibility (different connection possibilities e.g., single p g y ( p g , g
channel, double channel)
Fault-tolerant clock synchronization
Separation of functions and structure
20
FlexRay
BMW first with FlexRay in 2006 -
a BMW X5
FlexRay
21
Combination of different buses
State-of-the-art
How do we guarantee timing requirements over several nodes with
communication involved?
Next time: scheduling in distributed RT
ALT1: We schedule nodes and communication bus together
Good control over the system
Resource effective
Not flexible the system must be rescheduled for each new node added
ALT2 E h d d i ti b h d l d t l ALT2: Each node and communication bus scheduled separately
Flexible different parts (nodes) from different manufacturers
The nodes must have an agreement about the data traffic