CAN Bus

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

Timeline of CAN Bus
1983 -
Development of
CAN bus
1986 - Protocol
was officially
released at SAE
1987 - CAN
controller chips
produced by Intel
and Philips
1988 - BMW 8
Series is first
production vehicle
to feature CAN bus
1991 - CAN 2.0A
specification
published
1993 - CAN
standard ISO
11898 released
1996 - OBD-II
standard
incorporated
CAN
2012 Bosch
released CAN
with Flexible
Data-Rate
SAE - Society of Automotive Engineerwww.mbedlabs.com - +918050353585 2

Applications of CAN Bus
CAN
Railways,
Ships &
Marine
Construction
Equipments
Medical
Equipments
Industrial
Automation
Building
Automation
Automotive
www.mbedlabs.com - +918050353585 3

BUS LIN CAN FlexRay MOST
Application
Low level
communication
Systems
Soft Real Time
Systems
Hard Real Time
Systems (X - by -
Wire)
Multimedia
Example Body
Engine, Powertrain,
Chassis
Powertrain, Chassis
Multimedia,
Telematics
Architecture
Single Master
typ 2…10 slaves
Multi Master
typ 10…40 nodes
Multi Master up to
64 nodes
Multi Master up to
64 nodes
Bus Access polling CSMA/CA TDMA/FTDMA TDM CSMA/CS
Topology Bus Bus Bus/Star Ring/Star
Message
Transmission
Synchronous Asynchronous
Synchronous &
Asynchronous
Synchronous &
Asynchronous
Msg Identification Identifier Identifier Time Slot
Data Rate 20 Kbps 1 Mbps 10 Mbps 24 Mbps
Data bytes per
frame
0 to 8 0 to 8 0 to 254 0 to 60
Physical layer
Electrical - Single
wire
Electrical - Dual wire
Dual wire –
Optical/Electrical
Optical fiber
CAN and Other protocols

Examples for CAN in Automotive
-Engine
-Brakes
-Gearbox
-Airbag
-Central locking system
-Air conditioning
-Lights
500-1000 [Kbit/s] 25-125 [Kbit/s]
High Speed Low Speed

Bus characteristics
 Serial data communications bus
Inexpensive and simple, but slower than parallel bus.
 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.
 Linear bus structure
No star structure, No ring structure, No tree structure !

Data Rates
 “Good” real-time capabilities
Small latency (“fast enough”)
 indispensable for automotive applications.
 Data rate dependent on bus length
Class C - data rate: 1 Mbit/sec  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.

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.

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).

Signal coding
 NRZ (non-return-to-zero) coding
Example: Voltage levels: 0V (dominant), 5V (recessive)
Characteristics of NRZ coding:
Voltage level stays the same for consecutive bits of same polarity.
Note:
Different voltage levels are defined for different purposes.
0 11 1 1 1 10 0 0 0 0 0
recessive
5V
dominant
0V

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.

Advantages of CAN Bus
Advantages of
CAN Bus conventional
cablingover
Less wires
Less weight
Less connections
Less EMI problems Increased transmission reliability
Less space requirements
Easier addition of new nodes
Lower assembly costs

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)

The ISO/OSI seven-layer model
Electronic Control Unit
Application Layer
Presentation Layer
Session Layer
Network Layer
Transport Layer
Data Link Layer
Physical Layer
7
6
5
4
3
2
1
•Applications, operating system
•Conversion of data formats
•Task synchronization, buffers, connection setup
and monitoring, access rights control
•Address conversion, routing,
segmentation
•Setup of logical connection,
transport protocol
•Transmission security, frame setup, error
management
•Electrical / mechanical characteristics:
Transmission medium, wiring, connectors,
encoding, signals

CAN within the ISO/OSI model
not specified by the
CAN Specification,
implemented in Software
Acceptance filtering, error management,
(de-)stuffing, arbitration,
frame setup, acknowledgement
Encoding / decoding, bit timing,
synchronization, wiring, connectors,
bus, transceiver characteristics
Implemented in Hardware
Application Layer
Presentation Layer
Session Layer
Network Layer
Transport Layer
Data Link Layer
Physical Layer

CAN Driver
Software
CAN ISO coverage on ISO/OSI layers1,2
Data Link Layer
LLC (Logical Link Control)
MAC (Medium Access
Control)
Physical Layer
PLS (Physical Signalling)
PMA (Physical Medium
Attachment)
MDT (Medium Dependent
Hardware)
2
1
CAN
Transceiver
CAN Bus
CAN Controller
LLC: BusOff-Recovery
Acceptance filtering,
Overload Notification
MAC: Data De-/Encryption, Frame Setup,
(De-)Stuffing, Collision Detection,
Arbitration, Error Management,
Acknowledgement
PLS: Bit Encoding / Decoding Bit Timing,
Synchronization
PMA: Transceiver Characteristics
MDT: Wiring, Connectors, Bus

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

Frames
Data Frame
Remote
Frame
Overload
Frame
Error Frame

Data Frame: Formats
 Standard Format (CAN 2.0A): 11-bit Identifier
211 = 2048 identifiers possible
11-bit Identifier 0..64 Bit Data 15-bit CRC Bus IdleBus Idle
S
O
F
DLC 7-bit EOF
R
T
R
I
D
E
r
0
D
E
L
A
C
K
D
E
L
IFS
Arbitration Field Control
Field
Data Field CRC Field End of
Frame
Field
Bus IdleAck
Field
Inter-
frame
Space
Bus Idle
recessive
dominant
 Extended Format (CAN 2.0B): 29-bit Identifier
229 = 536.870.912 identifiers possible
18-bit Ext. Id DLC 0..64 Bit Data 7-bit EOF IFS Bus Idle
Arbitration field
11-bit Base IdBus Idle
S
O
F
S
R
R
I
D
E
Bus Idle
recessive
dominant
15-bit CRC
R
T
R
r
1
r
0
D
E
L
A
C
K
D
E
L
Control
Field
Data Field CRC Field End of
Frame
Field
Bus IdleAck
Field
Inter-
frame
Space

Data Frame: Start Of Frame (SOF) bit
 marks the start of any CAN frame
 is always a dominant bit
 provides a falling edge for hard synchronization of transmitter and receivers
01
recessive
dominant
Bus Idle SOF Arbitration Field
Start Of Frame (SOF) bit

Data Frame: Arbitration Field
 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 Field
01
recessive
dominant
Bus Idle SOF Arbitration Field
011-bit Identifier
RTR
0
Control Field
MSB LSB
 Arbitration = the allocation of bus acces rights
 Arbitration occurs when several nodes start transmission at the same time

Data Frame: Control Field
 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
Control Field
recessive
dominant
Arbitration Field
0
RTR
0
Control Field Data Field
IDE r0 DLC3 DLC2 DLC1 DLC0

Data Frame: Data Field
 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
Data Field
recessive
dominant
Control Field Data Field
DLC
CRC Field
0 .. 64 bits ( 0 .. 8 bytes )

Data Frame: CRC Field
 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
CRC Field
recessive
dominant
Data Field CRC Field
DEL
ACK Field
15-bit CRC code 1 0

Data Frame: Acknowledge (ACK) Field
 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
Acknowledge (ACK) Field
recessive
dominant
DEL
ACK Field
1 0
CRC Field
1 1
EOF Field
DELACK

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

Data Frame: End Of Frame (EOF) Field
 consists of seven consecutive recessive bits
 marks the end of the Data Frame
End Of Frame (EOF) Field
recessive
dominant
ACK Field
1 1
EOF Field
DEL
IFS
1 1 1 1 1 1 1

Data Frame: Interframe Space (IFS)
 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
Interframe Space (IFS)
recessive
dominant
EOF Field
1 1
Interframe Space Bus Idle
1 1 1

Recessive and dominant bus levels
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
5 V
S1 E1
Transceiver 1
S2 E2
Transceiver 2
S3 E3
Transceiver 3
Bus line
Hardware representation of
recessive and dominantbus levels
Wired-AND / Open-Collector circuit

Arbitration: Example
0
0
0
0
1
0
0
0
1
1
1
0
1
0
0
SOF
0
SOF
0
SOF
0
Start
1
recessive
dominant
Unit 1
ID: 13Dh
Bus
Idle
Start
1
recessive
dominant
Unit 2
ID: 069h
Bus
Idle
1
recessive
dominant
Start
Unit 3
ID: 079h
Bus
Idle
1
recessive
dominant
Bus
level
0
0
0
0
1
1
1
1 10 0 wins arbitration
1 10 0 loses arbitration
Withdraws and listen only
11 0 0
Withdraws and listen only
0
0
0
loses arbitration0 1 1 10 1 1 0

Arbitration: Identifier  Priority
Consequence: Frames
carrying information of
priority should
have a identifier

Bit stuffing: Motivation
Problems when using NRZ coding
 Long sequences of bits of the same polarity
 No falling edges for synchronization
 Synchronization between sender and receiver may be lost
 No changes in voltage level for a longer time
0 11 1 1 1 10 0 0 0 0 0
recessive
dominant

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

Bit stuffing: Examples
1
stuff bit
0 1 1 10 0 0
0 01 0 1 1 10 0 0 0 0 0
recessive
dominant
Example 1
original
sequence
00 01 0 0
recessive
dominant
stuffed
sequence
1 1 1 10 0 01
stuff bit
0 01 1 1 1 10 0 0 0 0 0
recessive
dominant
Example 2
original
sequence
0 01 0 0 0
recessive
dominant
stuffed
sequence
1 1 111
stuff bit
0
stuff bit
10 0
0 01 1 1 1 10 0 0 1 0 0
recessive
dominant
Example 3
original
sequence
0 01 0 0 0
recessive
dominant
stuffed
sequence

Data Frame: Maximum size
Maximum frame size (for 8 Data Bytes)
Standard Frame
CAN 2.0A
(11-bit identifier)
111 bits
130 bits
Extended Frame
CAN 2.0B
(29-bit identifier)
131 bits
154 bits
without stuff bits
with stuff bits

Error types

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

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
Exceptions
 Transmission of ACK delimiter, EOF field and Interframe Space (IFS):
11 consecutive recessive bits, bit stuffing does not apply to this section
 Bit changed value during transmission, possibly due to EMI/RFI
 An Active Error Frame was sent

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
Efficiency
 Recognizes up to 5 single bit errors per frame  Hamming distance: 6
 Receiver compares calculated CRC code with the one contained in frame
 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

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)
Possible cause
 Transmission error, error in sender and/or receiver
 Violation of frame integrity when wrong value in one of these fields
 Transmission of an Active Error Frame during EOF field
 Transmission of an Overload Frame during Interframe Space (IFS)

Error types: Acknowledgement errors
Error description
 Acknowledge (ACK) bit is recessive
Method of detection
 Sender monitors the bus while transmitting recessive ACK bit
Possible cause
 No other nodes are connected to the bus
 Sender expects to observe dominant ACK bit on bus
 Acknowledgement error when ACK bit on bus remains recessive
 Not one single receiver acknowledges that the received frame was error-
free
 Cause of error is very likely to be found in sender

Error management
Procedure observed after detection of an error
 Immediate transmission of an Error Frame
 Error Frame violates the bit stuffing rules  Other receivers are instantly
informed that an error has occurred (unless they already found out)
Format of an Active Error Frame:
No bit stuffing is applied to Error Frames!
Active Error FlagData Frame
recessive
Error Delimiter Interframe
Space
Bus Idle
dominant
3 bits Bus Idle6 dominant bitsData Frame 8 recessive bits
 As a result, other units also send Error Frames
 Sender and receivers reject erroneous frame completely
 Sender retries transmission later

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.

Transmit Error Counter (TEC)
TEC
+ 8
The TEC is increased by 8 when
 the unit detected an error in the frame it just sent.
It is very likely the unit itself is defective.
TEC
- 1
The TEC is decreased by 1 when
 the unit successfully transmitted a frame,
i.e. a dominant ACK bit was observed on the bus
and Error Frames were neither sent nor received.
 there are several other conditions of lesser
importance and exceptions to them.
Refer to the CAN specification for details.
 Note: The TEC is not decreased when TEC = 0.

Receive Error Counter (REC)
REC
+ 1
The REC is increased by 1 when
 the unit detected an error in a received frame.
Additionally, the REC is increased by 8 when
 the unit detected this error autonomously,
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
+ 8
 Usually, the REC cannot be greater than ca. 135.
REC
- 1
The REC is decreased by 1 when
 the unit successfully received a frame,
i.e. Error Frames were neither sent nor received.
 Notes: The REC is not decreased when REC = 0.
Usually, the REC is decreased by 8 when REC > 127.

Node states: Error active
02.09.2016
A unit is in Error Active state when
 its Transmit Error Counter (TEC) is less than 128: TEC < 128 AND
In Error Active state a unit
 is fully operational
 its Receive Error Counter (REC) is less than 128: REC < 128
 sends an Active Error Frame when it has detected an error

Node states: Error management
Error Active
Error Passive
Bus Off
Init (Normal Mode Request)
REC<=127 &
TEC<=127
REC>127 ||
TEC>127 &
TEC <=255
TEC>255
Normal Mode Request
and 128 occurrences
of 11 consecutive
recessive bits

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
In Error Passive state a unit
 sends a Passive Error Frame when it has detected an error
 its Receive Error Counter (REC) is greater than 127: REC > 127
 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

Passive Error Frame
Passive Error Frame
 a node in error passive state sends a Passive Error Frame in case of an
error
Passive Error FlagData Frame
recessive
Error Delimiter Interframe
Space
Bus Idle
dominant
3 bits Bus Idle6 recessive bitsData Frame 8 recessive bits
 a Passive Error Frame cannot destroy an ongoing transmission on the bus
 the Passive Error Frame might overlap with Active Error Frames

Node states: Bus off
A unit is in Bus Off state when
 its Transmit Error Counter (TEC) is greater than 255: TEC > 255
In Bus Off state a unit
 is practically disconnected from the bus
 Note: The value of the Receive Error Counter (REC) is of no importance
 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)
 In case of an Acknowledge error a Bus Off never occurs in the sending
node

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
When a unit reaches the Warning Level
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
 its Receive Error Counter (REC) is greater than 96: REC > 96
 the CAN controller sets its “Error Warning Flag”
 the “Error Warning Flag” is cleared for TEC <= 96 AND REC <= 96
 unfortunately, by checking this flag, one cannot determine
whether a unit is already in error passive state

Transmit Error Counter (TEC): Example
TEC
255
127
96
t
Error Active
Warning Level
Error Passive
Bus Off

Receive Error Counter (REC): Example
127
TEC
255
96
t
Error Active
Warning Level
Error Passive
Bus Off
135

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

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.

Remote Frame
Remote Frame
11-bit IdentifierBus Idle
S
O
F
DLC
R
T
R
I
D
E
r
0
Arbitration Field Control
Field
15-bit CRC Bus Idle7-bit EOF
D
E
L
A
C
K
D
E
L
IFS
CRC Field End of
Frame
Field
Bus IdleAck
Field
Inter-
frame
Space
Bus Idle
recessive
dominant
 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
 Used to request transmission of a specific Data Frame

Overload Frame
Overload FlagBus Idle
recessive
Overload Delimiter Interframe
Space
Bus Idle
dominant
3 bits Bus Idle6 dominant bitsBus Idle 8 recessive bits
Overload Frame
 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)

BasicCAN controllers
Bus
Transmit
Queue
Transmit
Buffers
Characteristics
Problems
 Low-priority frames in the Transmit Buffers
can block high-priority frames in the queue
 For reception: Hardware acceptance filters
Solution
 Limited number of Receive and Transmit
Buffers
 Reception of all CAN identifiers, all the time
 Additional transmit frames are stored in a
queue
 High CPU load because all received frames
have to be evaluated

FullCAN controllers
Characteristics
Problems
 FullCAN controllers can only transmit and
receive pre-defined identifiers
 Buffers are pre-defined for groups of identifiers
instead of identifiers only
Solution
 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
Bus
Transmit
Buffers

Philips transceiver, hardware connection example

Double-Wire Voltage Levels: High Speed
Recessive RecessiveDominant
CAN-L
CAN-H
3.5
2.5
1.5
Volts
Time
High-Speed definitions according to ISO 11898-2

Double-Wire Voltage Levels: Fault-Tolerant
Low Speed
Recessive RecessiveDominant
CAN-L
CAN-H
3.25
1.75
1.0
Volts
Time
4.0
Low-Speed definitions according to ISO 11519-2

Double-Wire Bus High Speed Line Termination
Node 1 Node n
CAN-H
CAN-L
120 W120 W
. . . . . .

Sub-D Connector
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
male female

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.
!

CAN Bit Timing: Bit time
Bit time
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
Bit time
1 Bit

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, fSys: System clock

CAN Bit Timing: Bit time segments
Bit time segments
Bit time
tq
Sync_Seg
Prop_Seg
Phase_Seg2
Phase_Seg1
Synchronization Segment
Propagation Time Segment
Phase Buffer Segment 2
Phase Buffer Segment 1

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

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

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 )

CAN Bit Timing: Sample point
Sample point
The Phase Buffer Segments surround the sample point.
Lengths: 1 tq  tPhase_Seg1  8 tq
2 tq  tPhase_Seg2  8 tq
Bit time
tq Sample point

CAN Bit Timing: Adjustable controller
parameters
Adjustable controller parameters
TSEG1
TSEG2
BRP
SJW
Time Segment 1
TSEG1 = Prop_Seg + Phase_Seg1
Time Segment 2
TSEG2 = Phase_Seg2
Baud Rate Prescaler
Synchronization Jump Width
SJW  min ( Phase_Seg1, Phase_Seg2 ) AND SJW  4
SJW indicates the maximum number of time quanta tq
by which TSEG1 may be lengthened or TSEG2 may be shortened.
TSEG2TSEG1

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.

Embedded Communication Software Layers
NM
Network
Management
CCP Driver
Can
Calibration
Protocol
SoftwareHardware
CAN Controller / Transceiver
Application Software
CAN Driver
Controllerindependent
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
Diagnostic
Services
IL
Interaction
Layer
TP
Transport
Protocol
DP
Diagnostic
Protocol

CAN Driver
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
 Transmits (Tx) and receives (Rx) frames
 Handles Tx, Rx and error interrupts
 Initializes CAN controller
 Provides Tx and Rx frame buffers
 Filters messages

PDU
Term : PDU = PROTOCOL
DATA
UNIT
 Meaning : unit of data that has a
certain meaning in a certain context
and can be differentiated from
another unit depending on it’s
purpose.
 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.

Network Management (NM)
Application Layer
Presentation Layer
Session Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
Transport Layer
 Presents current status and configuration
of the CAN network to the application
 Supervises CAN network during operation
(Detection of plug-ins / plug-outs)
 Each node has a Network Management
 Frame ID reserved
 Network Management PDU = NM_PDU
 Each node participates in the Network
 Management process (via it’s own NM_PDU)

Direct Network Management
 On ECU addition, ring is dissolved and
 re-forms
 ECUs send consecutively specific frames
containing Network Management information
 “Network Managament Token Ring”
 Each ECU is always informed about other ECUs
 On ECU failure, ring shrinks
ECU 1
ECU 3
ECU 2
1 2
2 3
3 1
Application Layer
Presentation Layer
Session Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
Transport Layer

Indirect Network Management
 On no internal activity and no bus activity,
ECU switches to Sleep Mode
 Each ECU constantly monitors one periodic
frame from each other ECU
 When one supervised frame fails to arrive,
monitored ECU is considered not present
ECU 1
ECU 3
ECU 2
$xxx
$zzz
$yyy
Monitored
by ECU2
Application Layer
Presentation Layer
Session Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
Transport Layer

 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.
Possible Network Management states:
 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

Network Management state machine:

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

Transport Protocol (TP)
Application Layer
Presentation Layer
Data Link Layer
Physical Layer
ISO/OSI Model
Transport Layer
Network Layer
 Transfer of messages larger than 8 bytes
 Segmentation into frames before transmission
 Recombination of frames after reception
 Flow control handling
 Time-out detection and handling
 Error detection and handling
 TP PDUs = N_PDUs (Network)
Session Layer

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).

Single Frame (SF) Messages:
Format
B1
0L
Message
B2 B3 B4 B5 B6 B7 B8
XX XX XX XX XX XX XX
 B1 : single byte used for formatting of the message
 B2-8 (XX) :Message bytes (the actual useful information)
 0 : All Single Frame message will start Data Field with the
 first nibble 0
 L : This nibble describes the length of the message
 Unused bytes are called pad bytes

A Multi Frame message requires :
 First Frame (FF) : contains message length and first 6 bytes of
message
 Flow Control frames (FC) : contains data used for controlling frame
flow
 Consecutive Frames (CF) : contains an increment used for frame
discrimination and 7 bytes of the message

First Frame (FF):
Format
B1
1L
Message
B2 B3 B4 B5 B6 B7
LL XX XX XX XX XX XX
B8
 B1-2 : bytes used for formatting of the message
 B3-8 (XX) :Message bytes (the actual useful information)
 1 : All First Frames will start Data Field with the first nibble 1
 LLL : These 3 nibbles describes the length of the message
 No padding here; maximum message size = 212 = 4096

Consecutive Frame (FF):
 B1 : byte used for formatting of all CFs
 B2-8 (XX) : Message bytes (the actual useful information)
 2 : All Consecutive Frames will start Data Field with the first nibble 2
 S : An index (increment) : starts at value 1 and increments
Formatting
data
B1
2S
Message
B2 B3 B4 B5 B6 B7
XX XX XX XX XX XX
B8
XX
 After 0x0F the index goes to value 0x00 and continues
incrementation
 In ISO it is called Sequence Number (SN).

Flow Control frame (FC):
 B1-3 : useful control data
 B4-8 (XX) : Padding (usually 00)
 3 : All First Frames will start Data Field with the first
 nibble 3
 F : FC flag OR
 Flow Status (FS) in
ISO
Control data
B1
3F
Padding
B2 B3 B4 B5 B6 B7
XX XX XX XX XX
B8
BS ST
 BS : Block Size  ST : Separation Time

 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

 BS tells the receiver after how many CFs to send a new FC.CTS
 ST tells the receiver what the time between every two CFs should be.
 If the value of BS is equal to 00 than no FC.CTS needs to be sent after the
first one.
 The FCs will always be sent by the node that receives the message, unlike
the FFs and the CFs.

Message Transmission
Single Frame Messages
(Non-segmented messages)

Multi Frame Messages
(Segmented messages)

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

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)

Interaction Layer (IL) / Message Manager
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
 Automatic transmission of frames with
the most recent data:
 event-triggered
 cyclic
 cyclic and event-triggered
 Supervision of Rx/Tx time-outs
 Presentation of signals contained in
received frames to the application
 Supports signal-based API
 Signal-based frames contain I_PDUs

 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)

 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.

 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 IDs : used for identifying different signal blocks on multiplexed
I_PDUs
www.mbedlabs.com - +918050353585 100

Diagnostic Protocol (DP)
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
 Reception and transmission of
diagnostic requests
 Format check of received requests
 Check for supported diagnostic services
 No processing of requests !
 Most popular diagnostic protocol:
UDS (ISO 14229-1), KWP 2000 (ISO 14230)
 Diagnostic PDUs = C_PDUs (Communication)
Application Layer
www.mbedlabs.com - +918050353585 101

CCP (CAN Calibration Protocol)
 Calibration of ECU parameters
 Mostly used during development or
for end-of-line tests
 Optional
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
ISO/OSI Model
www.mbedlabs.com - +918050353585 102

Questions
?
www.mbedlabs.com - +918050353585 103

CAN Bus

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to CAN Bus (20)

Recently uploaded (20)

CAN Bus