CAN

Controller Area
Network
mbedlabs Technosolutions
www.mbedlabs.com
mbedlabs@gmail.com
+91 8050353585
 Timeline of CAN Bus

1987 - CAN 1988 - BMW 8

1983 - 1986 - Protocol
controller chips Series is first
Development of was officially
produced by Intel production vehicle
CAN bus released at SAE
and Philips to feature CAN bus

1996 - OBD-II 2012 Bosch

1991 - CAN 2.0A 1993 - CAN
standard released CAN
specification standard ISO
incorporated with Flexible
published 11898 released
CAN Data-Rate

SAE - Society of Automotive En2gineer

Applications of CAN Bus
Railways
, Ships
&
Marine
Construction
Automotive
Equipments

CAN
Building Medical
Automation Equipments

Industrial
Automation

3
 CAN and Other
BUS LIN CAN FlexRay MOST

Application
protocols
Low level
communication
Soft Real Time
Systems
Hard Real Time
Systems (X - by - Multimedia
Systems Wire)
Example Body Engine, Powertrain, Powertrain, Chassis Multimedia,
Chassis Telematics
Architecture Single Master Multi Master Multi Master up to Multi Master up to
typ 2…10 slaves typ 10…40 nodes 64 nodes 64 nodes
Bus Access polling CSMA/CA TDMA/FTDMA TDM CSMA/CS
Topology Bus Bus Bus/Star Ring/Star
Message Synchronous Asynchronous Synchronous & Synchronous &
Transmission Asynchronous Asynchronous
Msg Identification Identifier Identifier Time Slot

Data Rate 20 Kbps 1 Mbps 10 Mbps 24 Mbps

Data bytes per 0 to 8 0 to 8 0 to 254 0 to 60
frame
Physical layer Electrical - Single Electrical–Dual wire Dual wire – Optical fiber 4
wire Optical/Electrical
 Examples for CAN in Automotive
High Speed Low Speed

500-1000 [Kbit/s] 25-125 [Kbit/s]

-Engine -Airbag

-Brakes -Central locking system

-Gearbox -Air conditioning

-Lights

5
 Bus characteristics
 Serial data communications bus
Inexpensive and simple, but slower than parallel bus.

 Linear bus structure

No star structure, No ring structure, No tree structure !

 Sensor / actuator bus

Every participant is equal to all others from the protocol point of view
=> peer-to-peer data transmission
Example: rain sensor = sensor, windscreen wipers = actuator, both
connected via the same bus and communicating the same way.

6
 Data Rates
 “Good” real-time capabilities
Small latency (“fast enough”)
 indispensable for automotive
applications.

 Data
Classrate dependent
C - data rate: 1 Mbit/secon bus
 length
Bus length: 40 meters,
Class B - data rate: 125 kBit/sec  Bus length: 500 meters,
Class A - data rate: 50 kBit/sec  Bus length: 1000 meters.

Typical definitions:
Low-speed: 25 kBit/sec up to 125 kBit/sec.
High-speed: 500 kBit/sec up to 1 Mbit/sec.

7
 Transmission principles
 Multicast / broadcast philosophy
CAN messages do not include address of
sender or receivers, but to information contents.

 Bus access principle: CSMA/CA

Carrier Sense Multiple Access with Collision
Avoidance
Carrier Sense: Every node monitors the bus level, all the time =>
monitoring of foreign and own CAN frames!
Multiple Access: Every node can start a transmission any time
when the bus is free.
Collision Avoidance: When several nodes start transmission at
the same time, all but one withdraw from
sending.

8
 Hardware characteristics
 Hardware message acceptance filtering
Only messages that carry relevant information pass through
 reduces CPU load.

 Sophisticated hardware error management

Error prevention and detection methods
Automatic re-transmission of messages detected as erroneous
 very high transmission security

 Standardized connector
Recommended: 9-pin D-sub connectors (DIN 41652).

9
 Signal coding
 NRZ (non-return-to-zero) coding
Example: Voltage levels: 0V (dominant), 5V (recessive)
5V
recessive
1 0 1 0 0 0 1 1 0 1 0 0 1
0V
dominant

Characteristics of NRZ coding:

Voltage level stays the same for consecutive bits of same polarity.

Note:
Different voltage levels are defined for different purposes.

10
Bus stations (Nodes)
 Typically 3 to 40 nodes per bus
No limit for node number defined in CAN specification.
Number of nodes depends on capabilities of CAN transceivers.
Bus load usually gets higher with more nodes.

 Hot plug-in / plug-out

Connect / disconnect nodes while the bus is up and running.

11
 Advantages of CAN Bus
Advantages of
CAN Bus conventional
over cabling

Less wires Less space requirements

Less connections Easier addition of new nodes
Less weight Lower assembly costs
Less EMI problems Increased transmission
reliability

12
 International Standards

International CAN standards

 ISO 11898 “Road vehicles: CAN for high-speed communication”

 ISO 11519 “Road vehicles: Low-speed serial data communication -

Low-Speed CAN / VAN”

 ISO 11992 “Road vehicles: Electrical connections between

towing and towed vehicles”

 EIA RS-485 “Electrical Characteristics of Generators and

Receivers for Use in Balanced Digital Multipoint Systems”
(formerly used for CAN Physical Layer)

13
 The ISO/OSI seven-layer model
7 •Applications, operating system
Application Layer

6 Presentation Layer
•Conversion of data formats

•Task synchronization, buffers, connection setup

5 Session Layer and monitoring, access rights control

•Address conversion, routing,

Transport Layer segmentation
4
•Setup of logical connection,
Network Layer transport protocol
3
Data Link Layer •Transmission security, frame setup, error
management

2 Physical Layer •Electrical / mechanical characteristics:

Transmission medium, wiring, connectors,
encoding, signals

1 Electronic Control Unit

14
CAN within the ISO/OSI model
Application Layer

Presentation Layer

Session Layer not specified by the

CAN Specification,
Transport Layer implemented in Software

Network Layer
Implemented in Hardware

Data Link Layer Acceptance filtering, error management,

(de-)stuffing, arbitration,
frame setup, acknowledgement
Physical Layer Encoding / decoding, bit timing,
synchronization, wiring, connectors,
bus, transceiver characteristics
Electronic Control Unit

15
CAN ISO coverage on ISO/OSI layers1,2
CAN Driver
LLC: BusOff-Recovery
Software
Data Link Layer
2 LLC (Logical Link Control) Acceptance filtering,
Overload Notification
MAC (Medium Access
Control)
MAC: Data De-/Encryption, Frame Setup,
(De-)Stuffing, Collision Detection,
Arbitration, Error Management,
CAN Controller Acknowledgement

Physical Layer
PLS (Physical Signalling)
1 PMA (Physical Medium
Attachment)
MDT (Medium Dependent
Hardware)
PLS: Bit Encoding / Decoding Bit Timing,
Synchronization
CAN
Transceiver PMA: Transceiver Characteristics
MDT: Wiring, Connectors, Bus
CAN Bus

16
Frames: Overview
 Frame: “Envelope” for transmission data
Exact frame format is defined in CAN specification

 Note: CAN Frame  CAN Message !!!

A CAN message can be spread out over several CAN frames

 Four different frame types:

Data Frame: Transmission of regular data
Remote Frame: Remote request for data transmission
Overload Frame: Indication of bus overload situations
Error Frame: Indication of transmission errors

17
 Frames

Remote
Data Frame Frame

Overload
Frame Error Frame

18
 Data Frame: Formats
 Standard Format (CAN 2.0A): 11-bit Identifier
211 = 2048 identifiers possible
Bus Idle Arbitration Control Data Field CRC Field Ack End of Inter- Bus Idle
Field Field Field Frame frame
Field
Space
recessive
S R I r DA D
Bus Idle O 11-bit Identifier TD 0 DLC 0..64 Bit Data 15-bit CRC ECE 7-bit EOF IFS Bus Idle
F RE LK L
dominant

 Extended Format (CAN 2.0B): 29-bit Identifier

229 = 536.870.912 identifiers possible

Bus Idle Arbitration field Control Data Field CRC Field Ack End Inter- Bus Idle
Field of
Field Frame frame
Field
Space
recessive
S S I Rr r DA D
Bus Idle O
F
11-bit Base Id RD
RE
18-bit Ext. Id TR1 0 DLC 0..64 Bit Data 15-bit CRC E CL KE 7-bit
L
EOF IFS Bus Idle
dominant

19
Data Frame: Start Of Frame (SOF) bit

Start Of Frame (SOF) bit

B us Idle SOF Arbitr ation Field

recessive
1 0
dominant

 marks the start of any CAN frame

 is always a dominant bit
 provides a falling edge for hard synchronization of transmitter and receivers

20
Data Frame: Arbitration Field

Arbitration Field
us Idle SOF Arbitration Field Contr
B ol Field

MSB LSB RTR

recessive
1 0 11-bit Identifier 0 0
dominant

 contains the Identifier which is used for arbitration

 Identifier determines frame priority: low identifier = high priority
 Remote Transmission Request (RTR) bit is always dominant in a Data Frame
 Arbitration = the allocation of bus acces rights
 Arbitration occurs when several nodes start transmission at the same time

21
Data Frame: Control Field

Control Field
Ar bitration Field Control Field Data ield
F
RTR IDE r0 DLC3 DLC2 DLC1 DLC0
recessive
0 0
dominant

 Identifier Extension (IDE) bit is dominant for Standard

Frames and recessive for Extended Frames
 r0 bit is not used (“reserved for future extensions”)
 Data Length Code (DLC, 4 bits) indicates number of data bytes in Data
Field; may take values ranging from 0 to 8, other values are not
allowed

22
Data Frame: Data Field

Data Field
Contr ol Field Data Field CRC ield
F
DLC
recessive
0 .. 64 bits ( 0 .. 8 bytes )
dominant

 contains the actual information which is transmitted

 number of data bytes may range from 0 to 8 in units of bytes
 number of data bytes is given in the Data Length Code (DLC)
 transmission starts with the first data byte (byte 0), MSB first

23
Data Frame: CRC Field

CRC Field
Dat a Field CRC Field ACK ield
F
DEL
recessive
15-bit CRC code 1
0
dominant

 contains the 15-bit Cyclic Redundancy Check (CRC) code

 CRC is a complex, but fast and effective error detection method
 the CRC Field Delimiter (DEL) marks the end of the CRC field
 the CRC Field Delimiter is always recessive

24
Data Frame: Acknowledge (ACK) Field

Acknowledge (ACK) Field

CR C Field ACK Field EOF ield
F
DEL ACK
recessive DEL
1 0 1 1
dominant

 contains the Acknowledgement (ACK) bit

 the Acknowledgement bit can be dominant or
recessive
 the ACK Field Delimiter (DEL) marks the end of the
ACK field
 the ACK Field Delimiter is always recessive
25
ACK Bit: Values and interpretation
 Acknowledgement procedure:
1. Sender transmits a recessive bit in the ACK bit slot
2. Every receiver which received the frame without an error
transmits simultaneously a dominant bit in the ACK bit slot

 A dominant ACK bit

1. means that at least one node received the frame without an
error, but
2. does not necesarily mean that the frame was error-free

 A recessive ACK bit

1. could mean that no node received the frame without an
error or
2. that no other node is connected to the bus

26
Data Frame: End Of Frame (EOF) Field

End Of Frame (EOF) Field

ACK Field EOF Field IFS

DEL
recessive

1 1 1 1 1 1 1 1 1
dominant

 consists of seven consecutive recessive bits

 marks the end of the Data Frame

27
Data Frame: Interframe Space (IFS)

Interframe Space (IFS)

EOF Field Interframe Space Bus Idle

recessive

1 1 1 1 1
dominant

 consists of at least three consecutive recessive bits

 no transmission is allowed during the Interframe Space (IFS)
 is needed by controllers to copy received frames from their Rx buffers
 ACK Field Delimiter + EOF + IFS = 11 consecutive recessive bits

28
Recessive and dominant bus levels
Hardware representation of

recessive and dominant bus

levels
5V
Bus line

S1 0 1 0 1 0 1 0 1
S2 0 0 1 1 0 0 1 1
S3 0 0 0 0 1 1 1 1
Bus 0 0 0 0 0 0 0 1
S1 E1 S2 E2 S3 E3
Transceiver 1 Transceiver 2 Transceiver 3

Wired-AND / Open-Collector circuit

29
 Arbitration: Example
Start Withdraws and listen only

Bus
Idle SOF
recessive
Unit 1 1 0 0 0 1 0 0 1 1 1 1 0 1
loses arbitration
ID: 13Dh dominant

Start

Bus
Idle SOF
recessive
Unit 2 1 0 0 0 0 0 1 1 0 1 0 0 1
wins arbitration
ID: 069h dominant

Start Withdraws and listen only

Bus
SOF
recessive
Unit 3 Idle
1 0 0 0 0 0 1 1 1 1 0 0 1
loses arbitration
ID: 079h dominant

Bus recessive
1 0 0 0 0 0 1 1 0 1 0 0 1
level dominant

30
Arbitration: Identifier  Priority

Consequence: Frames
carrying information of
priority should
have a identifier

31
 Bit stuffing: Motivation
Problems when using NRZ coding
recessive
1 0 1 0 0 0 1 1 0 1 0 0 1
dominant

 Long sequences of bits of the same polarity

 No changes in voltage level for a longer time
 No falling edges for synchronization
 Synchronization between sender and receiver may be lost

32
 Bit stuffing: Approach
Solution: Bit stuffing
 After five consecutive bits of same polarity, insert one bit of reverse polarity
 CRC code is calculated before bit stuffing is done
 bit stuffing is done by the sender directly before transmission
 de-stuffing is done by the receiver directly after reception
 CRC code check is done after de-stuffing the frame
 bit stuffing is applied to part of the frame from SOF to CRC field

33
 Bit stuffing: Examples
Example 1 recessive
1 0 0 0 0 0 0 1 0 1 0 0 1
original
sequence dominant
recessive
stuffed 1 0 0 0 0 0 1 0 1 0 1 0 0 1
sequence
dominant
stuff bit

Example 2 recessive
1 0 0 0 0 0 1 1 0 1 0 0 1
original
sequence dominant
recessive
stuffed 1 0 0 0 0 0 1 1 1 0 1 0 0 1
sequence
dominant
stuff bit

Example 3 recessive
1 0 0 0 0 0 1 1 1 1 0 0 1
original
sequence dominant
recessive
stuffed 1 0 0 0 0 0 1 1 1 1 1 0 0 0 1
sequence
dominant
stuff bit stuff bit

34
Data Frame: Maximum size
Maximum frame size (for 8 Data Bytes)

Standard Frame Extended Frame

CAN 2.0A CAN 2.0B
(11-bit identifier) (29-bit identifier)

without stuff bits 111 bits 131 bits

with stuff bits 130 bits 154 bits

35
Error types

36
 Error types: Bit errors
Error description
 The bit actually appearing on the bus is different from the one transmitted

Method of detection
 Sending unit constantly monitors the bus while transmitting

Possible cause
 Sending unit hardware is defective

Exceptions
 Arbitration phase (unit loses arbitration)
 Acknowledgement bit (unit gets positive ACK from at least one receiver)
 Sending of a Passive Error Frame

37
Error types: Bit stuffing errors
Error description
 Data Frame contains six or more consecutive bits of the same polarity

Method of detection
 Receiver detects error when de-stuffing a received frame

Possible causes
 Error of sending unit during bit stuffing and/or transmission
 Bit changed value during transmission, possibly due to EMI/RFI
 An Active Error Frame was sent

Exceptions
 Transmission of ACK delimiter, EOF field and Interframe Space (IFS):
11 consecutive recessive bits, bit stuffing does not apply to this section

38
Error types: CRC errors
Error description
 CRC code calculated by receiver does not match received CRC code

Method of detection
 Receiver calculates CRC code immediately after reception of the Data Field
 Receiver compares calculated CRC code with the one contained in frame

Efficiency
 Recognizes up to 5 single bit errors per frame  Hamming distance: 6
 Recognizes burst errors with lengths of up to 14 bits
 Recognizes all odd numbers of bit errors
 The more bits the CRC code has, the more efficient it is

39
Error types: Message format errors
Error description
 Frame integrity is not preserved

Method of detection
 Receiver checks received frames for bits or bit fields having a fixed
value (e.g. SOF bit, CRC delimiter, ACK delimiter, EOF field, Interframe
Space)
 Violation of frame integrity when wrong value in one of these fields

Possible cause
 Transmission error, error in sender and/or receiver
 Transmission of an Active Error Frame during EOF field
 Transmission of an Overload Frame during Interframe Space (IFS)

40
Error types: Acknowledgement errors
Error description
 Acknowledge (ACK) bit is recessive

Method of detection
 Sender monitors the bus while transmitting recessive ACK bit
 Sender expects to observe dominant ACK bit on bus
 Acknowledgement error when ACK bit on bus remains recessive

Possible cause
 No other nodes are connected to the bus
 Not one single receiver acknowledges that the received frame was error-
free
 Cause of error is very likely to be found in sender

41
Error management
Procedure observed after detection of an error
 Immediate transmission of an Error Frame

Format of an Active Error Frame:

Data Frame Active Error Flag Error Delimiter Interframe Bus Idle
Space

recessive
Data Frame 6 dominant bits 8 recessive bits 3 bits Bus Idle
dominant

No bit stuffing is applied to Error Frames!

 Error Frame violates the bit stuffing rules  Other receivers are instantly
informed that an error has occurred (unless they already found out)
 As a result, other units also send Error Frames

 Sender and receivers reject erroneous frame completely

 Sender retries transmission later

42
Error counters and node states
Two error counters for each unit
 Transmit Error Counter (TEC)
 Receive Error Counter (REC)

Characteristics of error counters

 TEC and REC start counting at 0 (zero)
 Distinction between sporadic (temporary) and permanent errors possible
 Error-prone units are deactivated automatically after a certain time
 Depending on the values of their error counters, units can assume
one of three possible node states: Error Active, Error Passive, Bus Off.

43
Transmit Error Counter (TEC)
The TEC is increased by 8 when
 the unit detected an error in the frame it just +8
sent. It is very likely the unit itself is defective.
 there are several other conditions of TEC
lesser importance and exceptions to
them. Refer to the CAN specification for
details.

The TEC is decreased by 1 when

 the unit successfully transmitted a frame,
i.e. a dominant ACK bit was observed on the bus TEC
and Error Frames were neither sent nor received.
 Note: The TEC is not decreased when TEC = 0.
-1

44
Receive Error Counter (REC) +1
The REC is increased by 1 when
 the unit detected an error in a received frame. REC

Additionally, the REC is increased by 8 when

 the unit detected this error autonomously, +8
i.e. not through another unit’s Error Frame.
This is the case when the unit observes a dominant
bit following its own Error Flag on the bus. REC
 Usually, the REC cannot be greater than ca. 135.

The REC is decreased by 1 when

 the unit successfully received a frame,
i.e. Error Frames were neither sent nor received. REC
 Notes: The REC is not decreased when REC = 0.
Usually, the REC is decreased by 8 when REC > 127.
-1
45
 Node states: Error active
A unit is in Error Active state when
 its Transmit Error Counter (TEC) is less than 128: TEC < 128 AND
 its Receive Error Counter (REC) is less than 128: REC < 128

In Error Active state a unit

 is fully operational
 sends an Active Error Frame when it has detected an error

02.09.2016
46
Node states: Error management
Init (Normal Mode Request)

Normal Mode Request

REC<=127 &
and 128 occurrences
Error Active
TEC<=127 of 11 consecutive
recessive bits

REC>127 ||
TEC>127
& TEC
<=255

Bus Off
Error Passive

TEC>255

47
Node states: Error passive
A unit is in Error Passive state when
 its Transmit Error Counter (TEC) is greater than 127: TEC > 127 AND /
OR
 its Receive Error Counter (REC) is greater than 127: REC > 127

In Error Passive state a unit

 sends a Passive Error Frame when it has detected an error
 can still receive frames like a unit in error active state can
 has to wait after transmission of a Data Frame for 8 additional
consecutive recessive bit cycles on the bus (Suspend Transmission
Field) until it is permitted to transmit another Data Frame
 can go back to error active state for TEC <= 127 AND REC <= 127

48
Passive Error Frame
Passive Error Frame

Data Frame Passive Error Flag Error Delimiter Interframe Bus Idle
Space

recessive
Data Frame 6 recessive bits 8 recessive bits 3 bits Bus Idle
dominant

 a node in error passive state sends a Passive Error Frame in case of an

error
 a Passive Error Frame cannot destroy an ongoing transmission on the bus
 the Passive Error Frame might overlap with Active Error Frames

49
Node states: Bus off
A unit is in Bus Off state when
 its Transmit Error Counter (TEC) is greater than 255: TEC > 255
 Note: The value of the Receive Error Counter (REC) is of no importance
 In case of an Acknowledge error a Bus Off never occurs in the sending
node
In Bus Off state a unit
 is practically disconnected from the bus
 cannot receive and transmit anything any more
 can only leave Bus Off mode via a hardware reset OR
a software reset and subsequent initialization carried through by the host
(CAN specification: TEC and REC are set to zero and the unit must
receive 128 times a field of 11 consecutive recessive bits)

50
Node states: Warning level
The Warning Level for a unit is set when
 its Transmit Error Counter (TEC) is greater than 96: TEC > 96 AND /
OR
 its Receive Error Counter (REC) is greater than 96: REC > 96

When a unit reaches the Warning Level

 the CAN controller sets its “Error Warning Flag”
 the “Error Warning Flag” is cleared for TEC <= 96 AND REC <= 96

Practical use of the Warning Level

 by constantly checking the “Error Warning Flag”, it can be
determined whether a unit gets near the threshold to the error
passive state
 unfortunately, by checking this flag, one cannot
determine whether a unit is already in error passive
state 51
Transmit Error Counter (TEC): Example
TEC Bus Off

255
Error Passive

127
Warning Level
96

Error Active

52
Receive Error Counter (REC): Example
TEC Bus Off

255
Error Passive

135
127
Warning Level
96

Error Active

53
Efficiency of the CAN error management
The probability for not discovering an error is

4.7  10-11
Example 1*
A CAN bus is used 365 days / year *Source: CiA
8 hours / day
with a transmission speed of 500 kBit / sec
and errors arise every 0.7 seconds
 in 1.000 years, only one error remains
undiscovered

Example 2**
A CAN bus in a car is run at 500 kBit / sec **Source: Kaiser, Schröder:
“Maßnahmen zur Sicherung
with an average bus load of 15 % der Daten beim CAN-Bus”
an average data frame size 110 bits
of 4000 hours
for
 an average
only operating
one error time automobiles remains
in 100.000
of
undetected

54
When is CAN Frame valid?
The CAN specification includes the following rules to this:

 The CAN Frame is valid for the transmitter, if up to the end of END OF
FRAME no fault appears. Is a CAN Frame faulty, it will be repeated
automatically.

 The CAN Frame is valid for the receiver, if up to the second last bit OF
END OF FRAME end no fault appears.
 The receiver must reject the CAN Frame and has to force the transmitter to
repeat the frame, if a local error was detected during the last bit, which was
necessary for the validation of the CAN Frame.

 So that the receiver can inform the transmitter, it is clear that the transmitter
must wait an additional bit time till the message for him is valid.

 The problem is independent of this, which last bit is required for the validity.
Therefore nothing helps to introduce further additional bits at the end of
message.

55
Remote Frame
Remote Frame
Bus Idle Arbitration Field Control CRC Field Ack End Inter- Bus Idle
Field of
Field Frame frame
Field
Space
recessive
S R I r DA D
Bus Idle O 11-bit Identifier TD 0 DLC 15-bit CRC ECE 7-bit EOF IFS Bus Idle
F RE LK L
dominant

 Used to request transmission of a specific Data Frame

 Similar to a Data Frame, but without Data Field
 Remote Transmission Request (RTR) bit is recessive
 Same identifier as the Data Frame which is requested
 Note: When Remote Frame is transmitted at the same time as
corresponding
Data Frame, Data Frame wins arbitration because of
dominant RTR bit

56
Overload Frame
Overload Frame
Bus Idle Overload Flag Overload Delimiter Interframe Bus Idle
Space

recessive
Bus Idle 6 dominant bits 8 recessive bits 3 bits Bus Idle
dominant

 Unit sends Overload Frame when at present it cannot receive frames

any more due to high workload
 Transmission of an Overload Frame is started during the first two bits
of the Interframe Space (IFS) of the preceding frame
 Other units react immediately by also transmitting Overload Frames
 Overload Flags overlap, resulting in up to 12 consecutive dominant
bits
 Implemented in very few (mostly older) controllers, though controllers
must still be able to interpret correctly Overload Frames they receive
 Overload Frames do not influence the error counters (TEC and REC)

57
BasicCAN controllers
Characteristics
Electronic Control Unit
 Limited number of Receive and Transmit
Buffers
 Reception of all CAN identifiers, all the time
 Additional transmit frames are stored in a
queue
Problems Transmit
Queue
 High CPU load because all received
frames have to be evaluated
 Low-priority frames in the Transmit Buffers Transmit
can block high-priority frames in the queue Buffers

Solution Bus

 For reception: Hardware acceptance filters

58
FullCAN controllers
Characteristics
Electronic Control Unit
 Large number of buffers for reception and
transmission (usually 15 to 16)
 Buffers can be pre-defined for specific
identifiers
 All transmit frames in these buffers
participate
in arbitration

Problems
 FullCAN controllers can only transmit Transmit
and receive pre-defined identifiers Buffers

Solution
Bus
 Buffers are pre-defined for groups of identifiers
instead of identifiers only

59
Philips transceiver, hardware connection example

60
Double-Wire Voltage Levels: High Speed
High-Speed definitions according to ISO 11898-2

Volts
CAN-H
3.5

2.5
CAN-L
1.5
Time

Recessive Dominant Recessive

61
Double-Wire Voltage Levels: Fault-Tolerant
Low Speed
Low-Speed definitions according to ISO 11519-2

Volts
CAN-H
4.0
3.25

1.75
CAN-L
1.0
Time

Recessive Dominant Recessive

62
Double-Wire Bus High Speed Line
Termination

Node 1 . . . . . . Node n

CAN-H

120  120 
CAN-L

63
Sub-D Connector
male female

1 - Reserved

2 CAN_L Dominant low bus line

3 CAN_GND CAN ground

4 - Reserved

5 CAN_SHLD CAN shield, optional

6 GND CAN ground

7 CAN_H Dominant high bus line

8 - Reserved

9 CAN_V+ Power, optional

64
CAN Bit Timing: Motivation
? Problem:
Frequencies of the quartz oscillators of the CAN nodes usually differ.
Re-synchronization of nodes during transmission is necessary.

! Solution:
CAN Bit Timing divides the bit time into several segments.
Segments can be lengthened or shortened during transmission.
Re-synchronization of nodes during transmission is possible.

65
CAN Bit Timing: Bit time
Bit time
Bit time

1 Bit

The bit time tBit is the time it takes to transmit one bit.

Example: Data rate: f = 500 kBit / s

 Bit time: tBit = 2 μs

66
CAN Bit Timing: Time quantum
Time quantum
Bit time

1 Bit

tq
The bit time is divided up into time quanta tq.
Length of one time quantum: tq = BRP / fSys
Allowed number of time quanta: 8  nq  25
BRP: Baud Rate Prescaler, System clock
fSys:

67
CAN Bit Timing: Bit time segments
Bit time segments
Bit time

tq
Sync_Seg Synchronization Segment
Prop_Seg Propagation Time Segment
Phase_Seg1 Phase Buffer Segment 1
Phase Buffer Segment 2
Phase_Seg2

68
CAN Bit Timing: Synchronization Segment
Synchronization Segment
Bit time

tq

Edges in CAN bus level are expected to occur here.

Synchronization Segment has fixed length: tSync_Seg = 1 tq

69
CAN Bit Timing: Propagation Time Segment
(1)
Propagation Time Segment
Bit time

tq
The Propagation Time Segment compensates for
physical delay times within the CAN network.
Length: 1 tq  tProp_Seg  14 tq

70
CAN Bit Timing: Propagation Time Segment
(3)
How to determine the length of the
Propagation Time Segment: Method 2

Node 1 Node 2

Node_Output_Delay Node_Input_Delay

Bus_Line_Delay

Prop_Seg  2*
( Node_Output_Delay
+
Bus_Line_Delay
+
Node_Input_Delay ) 71
CAN Bit Timing: Sample point
Sample point
Bit time

tq Sample point

The Phase Buffer Segments surround the sample point.

Lengths: 1 tq   8 tq
tPhase_Seg1
2 tq  tPhase_Seg2  8 tq

72
CAN Bit Timing: Adjustable controller
parameters
Adjustable controller parameters
TSE G1 TSEG2

TSEG1 Time Segment 1

TSEG1 = Prop_Seg + Phase_Seg1

TSEG2 Time Segment 2

TSEG2 = Phase_Seg2

BRP Baud Rate Prescaler

Synchronization Jump Width
SJW  min ( Phase_Seg1, Phase_Seg2 ) AND SJW  4
SJW SJW indicates the maximum number of time quanta tq
by which TSEG1 may be lengthened or TSEG2 may be
shortened.

73
CAN Bit Timing: Parameters

Refer to
the microcontroller manual
to see which registers
have to be filled with
the calculated
Bit Timing Parameters
BRP, TSEG1, TSEG2 and
SJW.

74
Embedded Communication Software Layers
ISO/OSI Model

Diagnostic Application Software Application Layer

Services

Presentation Layer
 Controller independent DP IL
Diagnostic Interaction
NM Session Layer
Protocol Layer
Network
Management CCP Driver Transport Layer
TP Can
Transport Calibration
Protocol Protocol Network Layer
Software

CAN Driver Data Link Layer

Hardware

CAN Controller / Transceiver Physical Layer

75
CAN Driver
ISO/OSI Model

 Initializes CAN controller Application Layer

Presentation Layer
 Transmits (Tx) and receives (Rx) frames
Session Layer

Transport Layer
 Provides Tx and Rx frame buffers
Network Layer

 Handles Tx, Rx and error interrupts

Data Link Layer

 Filters messages
Physical Layer

76
PD
U Term : PDU =
PROTOCOL
 Meaning : unit of data that has
acertain meaning in a certain context
and can be differentiated from another
DATA unit depending on it’s purpose.
UNIT
 Example : the bit is a PDU at
Physical Layer

From the perspective of ECU functionality:

 PDU = Data Field from Data Frame.

 The Data Field contains the useful information.

 All other pieces of data are useful for formatting only.

77
Network Management (NM)
ISO/OSI Model
 Presents current status and configuration Application Layer
of the CAN network to the application
Presentation Layer

 Supervises CAN network during operation Session Layer

(Detection of plug-ins / plug-outs)
Transport Layer
 Each node has a Network Management
 Frame ID reserved Network Layer

 Network Management PDU = NM_PDU Data Link Layer

 Each node participates in the Network

 Management process (via it’s own NM_PDU) Physical Layer

78
Direct Network Management
ISO/OSI Model
 ECUs send consecutively specific frames
Application Layer
containing Network Management
information
Presentation Layer
 “Network Managament Token Ring”
 Each ECU is always informed about other ECUs Session Layer

 On ECU addition, ring is dissolved and Transport Layer

re-forms
 On ECU failure, ring shrinks Network Layer

Data Link Layer

1 2
ECU 1 ECU 2

Physical Layer
3 1

ECU 3 2 3

79
Indirect Network Management
ISO/OSI Model
 Each ECU constantly monitors one periodic
Application Layer
frame from each other ECU
Presentation Layer
 When one supervised frame fails to
arrive, monitored ECU is considered not Session Layer

present
Transport Layer
 On no internal activity and no bus
activity, ECU switches to Sleep Mode Network Layer

ECU 1 $xxx Data Link Layer

ECU 2
$yyy
$zzz Monitored
by ECU2
Physical Layer
ECU 3

80
Network Management (NM)
Possible Network Management states:

 Bus Sleep : occurs when no messages are exchanged on bus

 => all nodes can reduce power consumption

 Prepare Bus Sleep : occurs when message exchange rate is

reduced precedes Bus Sleep state.

 Ready Sleep makes transition between Normal Operation and Prepare Bus Sleep
exists so that nodes can synchronize when entering Prepare Bus Sleep

 Normal Operation : occurs when nodes exchange frames almost

constantly
 Repeat Message occurs after Bus Sleep
: in this state the network is initialized

81
Network Management (NM)
Network Management state machine:

82
Network Management (NM)
Notes:

 This state machine form is not mandatory, but it is AUTOSAR compliant

 Additional states may be added according to customer needs

 Network Management frames are generally transmitted in bursts

when some transitions occur.

 Entering and leaving Bus Sleep state is affected by NM-PDUs exchange

 when it does not occur nodes will begin transition towards Sleep
 Sleep is left when NM-PDUs are seen on the bus

 NM states should NOT be confused with System states

83
Transport Protocol (TP)
ISO/OSI Model
 Transfer of messages larger than 8 bytes
Application Layer

 Segmentation into frames before transmission

Presentation Layer

 Recombination of frames after reception Session Layer

Transport Layer
 Flow control handling
Network Layer
 Time-out detection and handling

 Error detection and handling Data Link Layer

 TP PDUs = N_PDUs (Network)

Physical Layer

www.mbedlabs.com - +918050353585 84
Transport Protocol (TP)
Types of messages :

 Single Frame messages : for transmission of a maximum of 7

 bytes long messages.

 Multi Frame messages : for transmission of at least 8 bytes long

 messages (maximum length is project
 specific).

www.mbedlabs.com - +918050353585 85
Transport Protocol (TP)
Single Frame (SF) Messages:
F rmat Message

B1 B2 B3 B4 B5 B6 B7 B8

0L XX XX XX XX XX XX XX

 B1 : single byte used for formatting of the message

 0 : All Single Frame message will start Data Field with the
 first nibble 0
 L : This nibble describes the length of the message

 B2-8 (XX) :Message bytes (the actual useful information)

 Unused bytes are called pad bytes

www.mbedlabs.com - +918050353585 86
Transport Protocol (TP)
A Multi Frame message requires :

 First Frame (FF) contains message length and first 6 bytes of

: message

 Consecutive Frames (CF) contains an increment used for frame

: and 7 bytes of the message
discrimination

 Flow Control frames (FC) contains data used for controlling frame
: flow

www.mbedlabs.com - +918050353585 87
Transport Protocol (TP)
First Frame (FF):
Format Message

B1 B3 B4 B5 B7 B8
B2
B6
1L LL XX XX XX XX XX XX

 B1-2 : bytes used for formatting of the message

 1 : All First Frames will start Data Field with the first nibble 1
 LLL : These 3 nibbles describes the length of the message

 B3-8 (XX) :Message bytes (the actual useful information)

 No padding here; maximum message size = 212 = 4096

www.mbedlabs.com - +918050353585 88
Transport Protocol (TP)
Consecutive Frame (FF):
For atting Message
data
B1 B2 B3 B4 B5 B7 B8
B6
2S XX XX XX XX XX XX XX

 B1 : byte used for formatting of all CFs

 2 : All Consecutive Frames will start Data Field with the first nibble 2
 S : An index (increment) : starts at value 1 and increments
 After 0x0F the index goes to value 0x00 and continues
incrementation
 In ISO it is called Sequence Number (SN).
 B2-8 (XX) : Message bytes (the actual useful information)

www.mbedlabs.com - +918050353585 89
Transport Protocol (TP)
Flow Control frame (FC):
Control data Padding

B1 B2 B4 B5 B6 B8
B3 B7
3F BS ST XX XX XX XX XX

 B1-3 : useful control data

 3 : All First Frames will start Data Field with the first
 nibble 3
 F : FC flag OR  BS : Block Size  ST : Separation Time
 Flow Status (FS) in ISO

 B4-8 (XX) : Padding (usually 00)

www.mbedlabs.com - +918050353585 90
Transport Protocol (TP)
Flow Control frame (FC):

 FC flag can have values : 0, 1 or 2

 Value 0 FC.CTS (Flow Control Clear To Send)
– – it’s format was mentioned previously
 – is transmitted after a FF

 Value 1 – FC.WAIT (Flow Control Wait)
 – does not contain BS or ST
 – it is used to tell the message receiver to wait for a FC.CTS

 Value 2 – FC.OVFLW (Flow Control

Overflow)
 – does not contain BS or ST
 – it is sent when message length is
too big
 – marks the abortion of message
transmission

www.mbedlabs.com - +918050353585 91
Transport Protocol (TP)
Flow Control frame (FC):

 BS tells the receiver after how many CFs to send a new FC.CTS

 If the value of BS is equal to 00 than no FC.CTS needs to be sent after the

first one.

 ST tells the receiver what the time between every two CFs should be.

 The FCs will always be sent by the node that receives the message, unlike
the FFs and the CFs.

www.mbedlabs.com - +918050353585 92
Transport Protocol (TP)
Message Transmission

Single Frame Messages

(Non-segmented messages)

www.mbedlabs.com - +918050353585 93
Transport Protocol (TP)

Multi Frame Messages

(Segmented messages)

www.mbedlabs.com - +918050353585 94
 Transport Protocol (TP)
Timing parameters :
 N_As : Time for transmission of
the CAN frame (any N_PDU) on
the sender side
 N_Ar : Time for transmission of
the CAN frame (any N_PDU) on
the receiver side
 N_Bs : Time until reception of the
next FlowControl N_PDU
 N_Br : Time until transmission of
the next FlowControl N_PDU
 N_Cs : Time until transmission of
the next ConsecutiveFrame
N_PDU
 N_Cr : Time until reception of the
next ConsecutiveFrame N_PDU

www.mbedlabs.com - +918050353585 95
 Transport Protocol (TP)
Communication models:
 Physical addressing :
 corresponds to 1-to-1 communication
 supports both multi-frame and single-frame messages
 each node has unique frame IDs used for communication
known as Physical Addresses

 Functional addressing :
 corresponds to 1-to-n communication
 supports only single-frame messages
 functional addresses are recognized be each node (they
are not unique, and they may be multiple)

www.mbedlabs.com - +918050353585 96
Interaction Layer (IL) / Message Manager
ISO/OSI Model
 Automatic transmission of frames
with the most recent data: Application Layer

 event-triggered Presentation Layer

 cyclic
Session Layer
 cyclic and event-triggered
Transport Layer

 Supervision of Rx/Tx time-outs Network Layer

 Presentation of signals contained in

received frames to the application Data Link Layer

 Supports signal-based
API Physical Layer
 Signal-based frames contain I_PDUs

www.mbedlabs.com - +918050353585 97
Interaction Layer (IL) / Message Manager
 Signal:

 segment/section of the Data Field

 can start at any bit within the Data Field
 can have any length as long as maximum Data Field length is not
breached
 corresponds to a definable property (has a meaning of it’s own)
 data interpretation may be accompanied by additional
mathematical
transformations and measurement units
 value is updated by ECU Application (for Tx frames)

www.mbedlabs.com - +918050353585 98
Interaction Layer (IL) / Message Manager
 Signal-based frames can be:

 multiplexed : one (or more) signals (sometimes

called Block ID signals) will remain identical (as meaning
not as value), while the rest will change depending on the
values that the Block IDs have during each frame
transmission.

 simple : Data Field will keep the same signal delimitation

for every frame transmission.

www.mbedlabs.com - +918050353585 99
Interaction Layer (IL) / Message Manager
 Possible signal usage
:
 raw values : these signals correspond to a certain measurable property
that exists in the real world
 update bits : these signals contain only one bit that shows whether data
on the frame is valid or not
 checksums : these signal values rely on a checksum algorithm and on
the values of neighboring signals
 counter : these signals are incremented for each frame
transmission
 factors : their values influence decisions made by ECU
Application when using other data
 block used for identifying different signal blocks on multiplexed
IDs : I_PDUs

www.mbedlabs.com - +918050353585 100

Diagnostic Protocol (DP)
ISO/OSI Model
 Reception and transmission Application Layer
of diagnostic requests
Presentation Layer
 Format check of received requests
Session Layer
 Check for supported diagnostic services
Transport Layer

 No processing of requests !
Network Layer

 Most popular diagnostic protocol:

UDS (ISO 14229-1), KWP 2000 (ISO Data Link Layer
14230)
 Diagnostic PDUs = C_PDUs (Communication)
Physical Layer

www.mbedlabs.com - +918050353585 101

CCP (CAN Calibration Protocol)
ISO/OSI Model

 Calibration of ECU parameters Application Layer

 Mostly used during development Presentation Layer

or for end-of-line tests

Session Layer

 Optional Transport Layer

Network Layer

Data Link Layer

Physical Layer

www.mbedlabs.com - +918050353585 102

 Questions

www.mbedlabs.com - +918050353585 103