CAN bus
A controller area network (CAN bus) is a vehicle bus
standard designed to allow microcontrollers and devices
to communicate with each other in applications without a
host computer. It is a message-based protocol, designed
originally for multiplex electrical wiring within automo-
biles, but is also used in many other contexts.
Development of the CAN bus started in 1983 at Robert
Bosch GmbH.[1] The protocol was officially released in
1986 at the Society of Automotive Engineers (SAE)
congress in Detroit, Michigan. The first CAN controller
chips, produced by Intel and Philips, came on the market
in 1987. The 1988 BMW 8 Series was the first production
vehicle to feature a CAN-based multiplex wiring system.
Bosch published several versions of the CAN specifica-
tion and the latest is CAN 2.0 published in 1991. This
specification has two parts; part A is for the standard for-
mat with an 11-bit identifier, and part B is for the ex-
tended format with a 29-bit identifier. A CAN device that
uses 11-bit identifiers is commonly called CAN 2.0A and
a CAN device that uses 29-bit identifiers is commonly
called CAN 2.0B. These standards are freely available
from Bosch along with other specifications and white pa-
pers.[2]
In 1993 the International Organization for Standardiza-
tion released the CAN standard ISO 11898 which was
later restructured into two parts; ISO 11898-1 which cov-
ers the data link layer, and ISO 11898-2 which covers the
CAN physical layer for high-speed CAN. ISO 11898-3
was released later and covers the CAN physical layer for
low-speed, fault-tolerant CAN. The physical layer stan-
dards ISO 11898-2 and ISO 11898-3 are not part of the
Bosch CAN 2.0 specification. These standards may be
purchased from the International Organization for Stan-
dardization (ISO).[3]
CAN in Automation (CiA) also published CAN stan-
dards; CAN Specification 2.0 part A and part B, but their 1.4
status is now obsolete (superseded by ISO 11898-1).[4]
Bosch is still active in extending the CAN standards. In
2012 Bosch released CAN FD 1.0 or CAN with Flexi-
ble Data-Rate. This specification uses a different frame
format that allows a different data length as well as op-
tionally switching to a faster bit rate after the arbitration
is decided. CAN FD is compatible with existing CAN
2.0 networks so new CAN FD devices can coexist on the
same network with existing CAN devices.
CAN bus is one of five protocols used in the on-board CAN is a multi-master serial bus standard for connecting
diagnostics (OBD)-II vehicle diagnostics standard. The Electronic Control Units [ECUs] also known as nodes.
OBD-II standard has been mandatory for all cars and Two or more nodes are required on the CAN network
1
light trucks sold in the United States since 1996, and the
EOBD standard has been mandatory for all petrol vehi-
cles sold in the European Union since 2001 and all diesel
vehicles since 2004.[5]
1 Applications
1.1 Automotive
The modern automobile may have as many as 70
electronic control units (ECU) for various subsystems.[6]
Typically the biggest processor is the engine control unit.
Others are used for transmission, airbags, antilock brak-
ing/ABS, cruise control, electric power steering, audio
systems, power windows, doors, mirror adjustment, bat-
tery and recharging systems for hybrid/electric cars, etc.
Some of these form independent subsystems, but commu-
nications among others are essential. A subsystem may
need to control actuators or receive feedback from sen-
sors. The CAN standard was devised to fill this need.
1.2 Cycling
The CAN bus protocol has been used on the Shimano Di2
electronic gear shift system for road bikes since 2009 and
is also used by the BionX system in its direct drive motor.
1.3 Industrial
Today the CAN bus is also used as a fieldbus in general
automation environments, primarily due to the low cost
of some CAN controllers and processors.
Entertainment
Manufacturers including NISMO aim to use CAN bus
to recreate real-life racing laps in the videogame Gran
Turismo 6 using the game’s GPS Data Logger function,
which would then allow players to race against real laps.[7]
2 Architecture
2 2 ARCHITECTURE

to communicate. The complexity of the node can range

from a simple I/O device up to an embedded computer
with a CAN interface and sophisticated software. The
node may also be a gateway allowing a standard computer
to communicate over a USB or Ethernet port to the de-
vices on a CAN network.
All nodes are connected to each other through a two wire
bus. The wires are 120 Ω nominal twisted pair.

High Speed CAN Network. ISO 11898-2

CANbus Node
ISO 11898-2, also called high speed CAN, uses a linear
bus terminated at each end with 120 Ω resistors.
• Sensors, actuators and control devices can be
connected to the host processor.

• CAN controller; often an integral part of the micro-

controller

• Receiving: the CAN controller stores the re-

ceived serial bits from the bus until an en-
tire message is available, which can then be
fetched by the host processor (usually by the
CAN controller triggering an interrupt).
• Sending: the host processor sends the transmit
message(s) to a CAN controller, which trans-
mits the bits serially onto the bus when the bus
is free.
Low Speed Fault Tolerant CAN Network. ISO 11898-3
• Transceiver Defined by ISO 11898-2/3 Medium Ac-
ISO 11898-3, also called low speed or fault tolerant CAN, cess Unit [MAU] standards
uses a linear bus, star bus or multiple star buses connected
by a linear bus and is terminated at each node by a fraction • Receiving: it converts the data stream from
of the overall termination resistance. The overall termi- CANbus levels to levels that the CAN con-
nation resistance should be about 100 Ω, but not less than troller uses. It usually has protective circuitry
100 Ω. to protect the CAN controller.
• Transmitting: it converts the data stream from
High speed CAN is usually used in automotive and in-
the CAN controller to CANbus levels.
dustrial applications where the bus runs from one end of
the environment to the other. Fault tolerant CAN is of-
ten used where groups of nodes need to be connected to- Each node is able to send and receive messages, but not
gether. simultaneously. A message or Frame consists primarily
of the ID (identifier), which represents the priority of the
The ISO specifications require the bus be kept within a message, and up to eight data bytes. A CRC, acknowl-
minimum and maximum common mode bus voltage, but edge slot [ACK] and other overhead are also part of the
do not define how to keep the bus within this range. message. The improved CAN FD extends the length of
Each node requires a: the data section to up to 64 bytes per frame. The message
is transmitted serially onto the bus using a non-return-to-
• Central processing unit, microprocessor, or host zero (NRZ) format and may be received by all nodes.
processor
The devices that are connected by a CAN network are
• The host processor decides what the received typically sensors, actuators, and other control devices.
messages mean and what messages it wants to These devices are connected to the bus through a host
transmit. processor, a CAN controller, and a CAN transceiver.
 3

A terminating bias circuit is power and ground pro- with two nodes with IDs of 15 (binary represen-
vided together with the data signaling in order to provide tation, 00000001111) and 16 (binary representation,
electrical bias and termination at each end of each bus 00000010000). If these two nodes transmit at the same
segment to suppress reflections. time, each will first transmit the start bit then transmit
the first six zeros of their ID with no arbitration decision
being made.
When the 8th bit is transmitted, the node with the ID of
3 Data transmission 16 transmits a 1 (recessive) for its ID, and the node with
the ID of 15 transmits a 0 (dominant) for its ID. When
CAN data transmission uses a lossless bit-wise arbitration this happens, the node with the ID of 16 knows it trans-
method of contention resolution. This arbitration method mitted a 1, but sees a 0 and realizes that there is a collision
requires all nodes on the CAN network to be synchro- and it lost arbitration. Node 16 stops transmitting which
nized to sample every bit on the CAN network at the same allows the node with ID of 15 to continue its transmission
time. This is why some call CAN synchronous. Unfor- without any loss of data. The node with the lowest ID will
tunately the term synchronous is imprecise since the data always win the arbitration, and therefore has the highest
is transmitted without a clock signal in an asynchronous priority.
format.
Bit rates up to 1 Mbit/s are possible at network lengths
The CAN specifications use the terms “dominant” bits below 40 m. Decreasing the bit rate allows longer net-
and “recessive” bits where dominant is a logical 0 (ac- work distances (e.g., 500 m at 125 kbit/s). The improved
tively driven to a voltage by the transmitter) and recessive CAN FD standard allows increasing the bit rate after ar-
is a logical 1 (passively returned to a voltage by a resis- bitration and can increase the speed of the data section
tor). The idle state is represented by the recessive level by a factor of up to eight of the arbitration bit rate.
(Logical 1). If one node transmits a dominant bit and
another node transmits a recessive bit then there is a col-
lision and the dominant bit “wins”. This means there is no
delay to the higher-priority message, and the node trans-
4 ID allocation
mitting the lower priority message automatically attempts
to re-transmit six bit clocks after the end of the dominant Message IDs must be unique on a single CAN bus, other-
message. This makes CAN very suitable as a real time wise two nodes would continue transmission beyond the
prioritized communications system. end of the arbitration field (ID) causing an error.
The exact voltages for a logical 0 or 1 depend on the phys- In the early 1990s, the choice of IDs for messages was
ical layer used, but the basic principle of CAN requires done simply on the basis of identifying the type of data
that each node listen to the data on the CAN network in- and the sending node; however, as the ID is also used
cluding the data that the transmitting node is transmit- as the message priority, this led to poor real-time per-
ting. If a logical 1 is transmitted by all transmitting nodes formance. In those scenarios, a low CAN bus utilization
at the same time, then a logical 1 is seen by all of the of circa 30% was commonly required to ensure that all
nodes, including both the transmitting node(s) and receiv- messages would meet their deadlines. However, if IDs
ing node(s). If a logical 0 is transmitted by all transmit- are instead determined based on the deadline of the mes-
ting node(s) at the same time, then a logical 0 is seen by all sage, the lower the numerical ID and hence the higher the
nodes. If a logical 0 is being transmitted by one or more message priority, then bus utilizations of 70 to 80% can
nodes, and a logical 1 is being transmitted by one or more typically be achieved before any message deadlines are
nodes, then a logical 0 is seen by all nodes including the missed.
node(s) transmitting the logical 1. When a node trans-
mits a logical 1 but sees a logical 0, it realizes that there
is a contention and it quits transmitting. By using this 5 Bit timing
process, any node that transmits a logical 1 when another
node transmits a logical 0 “drops out” or loses the arbi-
All nodes on the CAN network must operate at the same
tration. A node that loses arbitration re-queues its mes-
nominal bit rate, but noise, phase shifts, oscillator tol-
sage for later transmission and the CAN frame bit-stream
erance and oscillator drift mean that the nominal bit rate
continues without error until only one node is left trans-
may not be the same as the actual bit rate.[8] Since a sepa-
mitting. This means that the node that transmits the first
rate clock signal is not used, a means of synchronizing the
1 loses arbitration. Since the 11 (or 29 for CAN 2.0B)
nodes is necessary. Synchronization is important during
bit identifier is transmitted by all nodes at the start of the
arbitration since the nodes in arbitration must be able to
CAN frame, the node with the lowest identifier transmits
see both their transmitted data and the other nodes trans-
more zeros at the start of the frame, and that is the node
mitted data at the same time. Synchronization is also im-
that wins the arbitration or has the highest priority.
portant to ensure that variations in oscillator timing be-
For example, consider an 11-bit ID CAN network, tween nodes does not cause errors.
4 6 LAYERS

Synchronization starts with a hard synchronization on the layer. The transfer layer is responsible for bit timing and
first recessive to dominant transition after a period of bus synchronization, message framing, arbitration, acknowl-
idle (the start bit). Resynchronization occurs on every edgement, error detection and signalling, and fault con-
recessive to dominant transition during the frame. The finement. It performs:
CAN controller expects the transition to occur at a mul-
tiple of the nominal bit time. If the transition does not • Fault Confinement
occur at the exact time the controller expects it, the con-
troller adjusts the nominal bit time accordingly. • Error Detection
The adjustment is accomplished by dividing each bit into
• Message Validation
a number of time slices called quanta, and assigning some
number of quanta to each of the four segments within the • Acknowledgement
bit: synchronization, propagation, phase segment 1 and
phase segment 2. • Arbitration

Nominal Bit Time

• Message Framing

previous bit Sync Prop Phase 1 Phase 2 next bit • Transfer Rate and Timing
Sample Point • Information Routing
Time Quanta

Physical layer
An example CAN bit timing with 10 time quanta per bit.

The number of quanta the bit is divided into can vary

by controller, and the number of quanta assigned to each SG SG SG
segment can be varied depending on bit rate and network 1 2 n

conditions. CAN-Hi

A transition that occurs before or after it is expected

causes the controller to calculate the time difference and
lengthen phase segment 1 or shorten phase segment 2 by
this time. This effectively adjusts the timing of the re-
CAN-Low
ceiver to the transmitter to synchronize them. This resyn-
chronization process is done continuously at every reces-
sive to dominant transition to ensure the transmitter and CAN bus electrical sample topology with terminator resistors
receiver stay in sync. Continuously resynchronizing re-
CAN bus (ISO 11898−1:2003) originally specified the
duces errors induced by noise, and allows a receiving node
link layer protocol with only abstract requirements for
that was synchronized to a node which lost arbitration to
resynchronize to the node which won arbitration. the physical layer, e.g., asserting the use of a medium
with multiple-access at the bit level through the use of
dominant and recessive states. The electrical aspects of
6 Layers the physical layer (voltage, current, number of conduc-
tors) were specified in ISO 11898−2:2003, which is now
widely accepted. However, the mechanical aspects of the
The CAN protocol, like many networking protocols, can physical layer (connector type and number, colors, labels,
be decomposed into the following abstraction layers: pin-outs) have yet to be formally specified. As a result, an
automotive ECU will typically have a particular—often
Application layer custom—connector with various sorts of cables, of which
two are the CAN bus lines. Nonetheless, several de facto
Object layer
standards for mechanical implementation have emerged,
the most common being the 9-pin D-sub type male con-
• Message filtering nector with the following pin-out:
• Message and status handling
• pin 2: CAN-Low (CAN-)
Transfer layer
• pin 3: GND (Ground)
Most of the CAN standard applies to the transfer layer. • pin 7: CAN-High (CAN+)
The transfer layer receives messages from the physi-
cal layer and transmits those messages to the object • pin 9: CAN V+ (Power)
 5

transceiver nodes. The design provides a common supply

for all the transceivers. The actual voltage to be applied
by the bus and which nodes apply to it are application-
specific and not formally specified. Common practice
node design provides each node with transceivers which
are optically isolated from their node host and derive a
5 V linearly regulated supply voltage for the transceivers
from the universal supply rail provided by the bus. This
usually allows operating margin on the supply rail suffi-
cient to allow interoperability across many node types.
Typical values of supply voltage on such networks are 7
to 30 V. However, the lack of a formal standard means
that system designers are responsible for supply rail com-
patibility.
A male DE-9 connector (Plug).
ISO 11898−2 describes the electrical implementation
formed from a multi-dropped single-ended balanced line
configuration with resistor termination at each end of the
This de facto mechanical standard for CAN could be im- bus. In this configuration a dominant state is asserted by
plemented with the node having both male and female one or more transmitters switching the CAN- to supply
9-pin D-sub connectors electrically wired to each other 0 V and (simultaneously) switching CAN+ to the +5 V
in parallel within the node. Bus power is fed to a node’s bus voltage thereby forming a current path through the
male connector and the bus draws power from the node’s resistors that terminate the bus. As such the terminating
female connector. This follows the electrical engineering resistors form an essential component of the signalling
convention that power sources are terminated at female system and are included not just to limit wave reflection
connectors. Adoption of this standard avoids the need at high frequency.
to fabricate custom splitters to connect two sets of bus
During a recessive state the signal lines and resistor(s) re-
wires to a single D connector at each node. Such non-
main in a high impedances state with respect to both rails.
standard (custom) wire harnesses (splitters) that join con-
Voltages on both CAN+ and CAN- tend (weakly) towards
ductors outside the node reduce bus reliability, eliminate
½ rail voltage. A recessive state is only present on the bus
cable interchangeability, reduce compatibility of wiring
when none of the transmitters on the bus is asserting a
harnesses, and increase cost.
dominant state.
The absence of a complete physical layer specification
During a dominant state the signal lines and resistor(s)
(mechanical in addition to electrical) freed the CAN
move to a low impedance state with respect to the rails
bus specification from the constraints and complexity of
so that current flows through the resistor. CAN+ voltage
physical implementation. However it left CAN bus im-
tends to +5 V and CAN- tends to 0 V.
plementations open to interoperability issues due to me-
chanical incompatibility. Irrespective of signal state the signal lines are always in
low impedance state with respect to one another by virtue
Noise immunity on ISO 11898−2:2003 is achieved by
of the terminating resistors at the end of the bus.
maintaining the differential impedance of the bus at a
low level with low-value resistors (120 ohms) at each end This signalling strategy differs significantly from other
of the bus. However, when dormant, a low-impedance balanced line transmission technologies such as RS-
bus such as CAN draws more current (and power) than 422/3, RS-485, etc. which employ differential line
other voltage-based signaling busses. On CAN bus sys- drivers/ receivers and use a signalling system based on the
tems, balanced line operation, where current in one signal differential mode voltage of the balanced line crossing a
line is exactly balanced by current in the opposite direc- notional 0 V. Multiple access on such systems normally
tion in the other signal provides an independent, stable 0 relies on the media supporting three states (active high,
V reference for the receivers. Best practice determines active low and inactive tri-state) and is dealt with in the
that CAN bus balanced pair signals be carried in twisted time domain. Multiple access on CAN bus is achieved
pair wires in a shielded cable to minimize RF emission by the electrical logic of the system supporting just two
and reduce interference susceptibility in the already noisy states that are conceptually analogous to a ‘wired OR’ net-
RF environment of an automobile. work.
ISO 11898−2 provides some immunity to common mode
voltage between transmitter and receiver by having a 0 V
rail running along the bus to maintain a high degree of 7 Frames
voltage association between the nodes. Also, in the de
facto mechanical configuration mentioned above, a sup- A CAN network can be configured to work with two dif-
ply rail is included to distribute power to each of the ferent message (or “frame”) formats: the standard or base
6 7 FRAMES

frame format (described in CAN 2.0 A and CAN 2.0 B), [1] It is physically possible for a value between 9–15 to be
and the extended frame format (only described by CAN
2.0 B). The only difference between the two formats is
that the “CAN base frame” supports a length of 11 bits
for the identifier, and the “CAN extended frame” sup-
ports a length of 29 bits for the identifier, made up of
the 11-bit identifier (“base identifier”) and an 18-bit ex- 7.1.2 Extended frame format
tension (“identifier extension”). The distinction between
CAN base frame format and CAN extended frame for- The frame format is as follows:
mat is made by using the IDE bit, which is transmitted as
dominant in case of an 11-bit frame, and transmitted as
recessive in case of a 29-bit frame. CAN controllers that
support extended frame format messages are also able to
send and receive messages in CAN base frame format.
All frames begin with a start-of-frame (SOF) bit that de-
notes the start of the frame transmission.
CAN has four frame types:
• Data frame: a frame containing node data for trans-
mission
• Remote frame: a frame requesting the transmission
of a specific identifier
• Error frame: a frame transmitted by any node de-
tecting an error
• Overload frame: a frame to inject a delay between
data and/or remote frame
7.1 Data frame
The data frame is the only frame for actual data transmis-
sion. There are two message formats:
• Base frame format: with 11 identifier bits
transmitted in the 4-bit DLC, although the data is still lim-
ited to eight bytes. Certain controllers allow the transmis-
sion and/or reception of a DLC greater than eight, but the
actual data length is always limited to eight bytes.
[1] It is physically possible for a value between 9–15 to be
transmitted in the 4-bit DLC, although the data is still lim-
ited to eight bytes. Certain controllers allow the transmis-
sion and/or reception of a DLC greater than eight, but the
actual data length is always limited to eight bytes.
The two identifier fields (A & B) combine to form a 29-bit
identifier.
7.2 Remote frame
• Generally data transmission is performed on an au-
tonomous basis with the data source node (e.g., a
sensor) sending out a Data Frame. It is also possi-
ble, however, for a destination node to request the
data from the source by sending a Remote Frame.
• There are two differences between a Data Frame and
a Remote Frame. Firstly the RTR-bit is transmitted
as a dominant bit in the Data Frame and secondly in
the Remote Frame there is no Data Field.
i.e.,
RTR = 0 ; DOMINANT in data frame
RTR = 1 ; RECESSIVE in remote frame

• Extended frame format: with 29 identifier bits In the very unlikely event of a Data Frame and a Remote
Frame with the same identifier being transmitted at the
same time, the Data Frame wins arbitration due to the
The CAN standard requires the implementation must ac- dominant RTR bit following the identifier. In this way,
cept the base frame format and may accept the extended the node that transmitted the Remote Frame receives the
frame format, but must tolerate the extended frame for- desired data immediately.
mat.

7.3 Error frame

7.1.1 Base frame format
The error frame consists of two different fields:
Complete CAN Frame
Arbitration Field Control Data CRC Field End of Frame
Acknow. Delimiter
Acknow. Slot Bit

11 4 8 15

• The first field is given by the superposition of ER-

Requ. Remote
Start of Frame

CRC Delimiter
ID Ext. Bit
Reserved

CRC14
CRC13
CRC12
CRC11
CRC10
CRC9
CRC8
CRC7
CRC6
CRC5
CRC4
CRC3
CRC2
CRC1
CRC0

EOF6
EOF5
EOF4
EOF3
EOF2
EOF1
EOF0
ID10

IFS2
IFS1
IFS0
DB7
DB6
DB5
DB4
DB3
DB2
DB1
DB0
DL3
DL2
DL1
DL0
ID9
ID8
ID7
ID6
ID5
ID4
ID3
ID2
ID1
ID0

DATA
0000000101000000001000000010100001100000001011111111111 ROR FLAGS (6–12 dominant/recessive bits) con-
CAN
HI
CAN
tributed from different stations.
LO

• The following second field is the ERROR DELIM-

CAN-Frame in base format with electrical levels without stuffbits ITER (8 recessive bits).

The frame format is as follows: There are two types of error flags:
 7

Active Error Flag six dominant bits – Transmitted by preceded by an interframe space and multiple overload
a node detecting an error on the network that is in frames are not separated by an interframe space. Inter-
error state “error active”. frame space contains the bit fields intermission and bus
idle, and suspend transmission for error passive stations,
Passive Error Flag six recessive bits – Transmitted by a which have been transmitter of the previous message.[9]
node detecting an active error frame on the network
that is in error state “error passive”.
10 Bit stuffing
7.4 Overload frame
Complete CAN Frame
Arbitration Field Control Data CRC Field End of Frame

The overload frame contains the two bit fields Overload

Acknow. Delimiter
Acknow. Slot Bit
11 4 8 15

Requ. Remote
Start of Frame

CRC Delimiter
ID Ext. Bit
Reserved

CRC14
CRC13
CRC12
CRC11
CRC10
Flag and Overload Delimiter. There are two kinds of

CRC9
CRC8
CRC7
CRC6
CRC5
CRC4
CRC3
CRC2
CRC1
CRC0

EOF6
EOF5
EOF4
EOF3
EOF2
EOF1
EOF0
ID10

IFS2
IFS1
IFS0
DB7
DB6
DB5
DB4
DB3
DB2
DB1
DB0
DL3
DL2
DL1
DL0
ID9
ID8
ID7
ID6
ID5
ID4
ID3
ID2
ID1
ID0
DATA
0000000101000000001000000010100001100000001011111111111
overload conditions that can lead to the transmission of CAN
HI

an overload flag: CAN

LO
Complete CAN Frame
Arbitration Field Control Data CRC Field End of Frame

Acknow. Delimiter
Acknow. Slot Bit
11 4 8 15

Requ. Remote
Start of Frame

CRC Delimiter
ID Ext. Bit
Reserved

CRC14
CRC13
CRC12
CRC11
CRC10
CRC9
CRC8
CRC7
CRC6
CRC5
CRC4
CRC3
CRC2

CRC1
CRC0
1. The internal conditions of a receiver, which requires

EOF6
EOF5
EOF4
EOF3
EOF2
EOF1
EOF0
ID10

IFS2
IFS1
IFS0
DB7
DB6
DB5
DB4
DB3

DB2
DB1
DB0
DL3
DL2
DL1
DL0
ID9
ID8
ID7

ID6
ID5
ID4
ID3
ID2
ID1
ID0
DATA
00000100101000001000100000100101000011000001001011111111111
a delay of the next data frame or remote frame. CAN
HI
CAN
LO

2. Detection of a dominant bit during intermission.

The start of an overload frame due to case 1 is only al-
lowed to be started at the first bit time of an expected
intermission, whereas overload frames due to case 2 start
one bit after detecting the dominant bit. Overload Flag
consists of six dominant bits. The overall form corre-
sponds to that of the active error flag. The overload flag’s
form destroys the fixed form of the intermission field. As
a consequence, all other stations also detect an overload
condition and on their part start transmission of an over-
load flag. Overload Delimiter consists of eight recessive
bits. The overload delimiter is of the same form as the
error delimiter.
8 ACK slot
The acknowledge slot is used to acknowledge the receipt
of a valid CAN frame. Each node that receives the frame
without finding an error, transmits a dominant level in
the ACK slot and thus overrides the recessive level of the
transmitter. If a transmitter detects a recessive level in the
ACK slot it knows that no receiver found a valid frame.
A receiving node may transmit a recessive to indicate that
it did not receive a valid frame, but another node that did
receive a valid frame may override this with a dominant.
The transmitting node cannot know that the message has
been received by all of the nodes on the CAN network.
9 Interframe spacing
Data frames and remote frames are separated from pre-
ceding frames by a bit field called interframe space. In-
terframe space consists of at least three consecutive re-
cessive (1) bits. Following that, if a dominant bit is de-
tected, it will be regarded as the “Start of frame” bit of
the next frame. Overload frames and error frames are not
CAN-Frame before and after the addition of stuffbits (in purple)
To ensure enough transitions to maintain synchronization,
a bit of opposite polarity is inserted after five consecu-
tive bits of the same polarity. This practice is called bit
stuffing, and is necessary due to the non-return to zero
(NRZ) coding used with CAN. The stuffed data frames
are destuffed by the receiver.
All fields in the frame are stuffed with the exception of the
CRC delimiter, ACK field and end of frame which are a
fixed size and are not stuffed. In the fields where bit stuff-
ing is used, six consecutive bits of the same type (111111
or 000000) are considered an error. An active error flag
can be transmitted by a node when an error has been de-
tected. The active error flag consists of six consecutive
dominant bits and violates the rule of bit stuffing.
Bit stuffing means that data frames may be larger than one
would expect by simply enumerating the bits shown in the
tables above.
11 Standards
ISO 11898 specifies physical and datalink layer (levels
1 and 2 of the ISO/OSI model) of serial communica-
tion technology called Controller Area Network that sup-
ports distributed real-time control and multiplexing for
use within road vehicles.[10]
There are several CAN physical layer and other standards:
ISO 11898-1:2003 specifies the data link layer (DLL)
and physical signalling of the controller area network
(CAN).[11] This document describes the general architec-
ture of CAN in terms of hierarchical layers according to
the ISO reference model for open systems interconnec-
tion (OSI) established in ISO/IEC 7498-1 and provides
the characteristics for setting up an interchange of digi-
tal information between modules implementing the CAN
8 12
DLL with detailed specification of the logical link con-
trol (LLC) sublayer and medium access control (MAC)
sublayer.
ISO 11898-2:2003 specifies the high-speed (transmis-
sion rates of up to 1 Mbit/s) medium access unit (MAU),
and some medium dependent interface (MDI) features
(according to ISO 8802-3), which comprise the physical
layer of the controller area network. ISO 11898-2 uses a
two-wire balanced signalling scheme. It is the most used
physical layer in car powertrain applications and indus-
trial control networks.
ISO 11898-3:2006 specifies low-speed, fault-tolerant,
medium-dependent interface for setting up an inter-
change of digital information between electronic control
units of road vehicles equipped with the CAN at trans-
mission rates above 40 kBit/s up to 125 kBit/s.
ISO 11898-4:2004 specifies time-triggered communica-
tion in the CAN (TTCAN). It is applicable to setting up
a time-triggered interchange of digital information be-
tween electronic control units (ECU) of road vehicles
equipped with CAN, and specifies the frame synchronisa- 12 Higher layer implementations
tion entity that coordinates the operation of both logical
link and media access controls in accordance with ISO As the CAN standard does not include tasks of applica-
11898-1, to provide the time-triggered communication tion layer protocols, such as flow control, device address-
schedule.
ISO 11898-5:2007 specifies the CAN physical layer for
transmission rates up to 1Mbit/s for use within road ve-
hicles. It describes the medium access unit functions as
well as some medium dependent interface features ac-
cording to ISO 8802-2. This represents an extension of
ISO 11898-2, dealing with new functionality for systems
requiring low-power consumption features while there is
no active bus communication.
ISO 11898-6:2013 specifies the CAN physical layer for
transmission rates up to 1Mbit/s for use within road ve-
hicles. It describes the medium access unit functions as
well as some medium dependent interface features ac-
cording to ISO 8802-2. This represents an extension of
ISO 11898-2 and ISO 11898-5, specifying a selective
wake-up mechanism using configurable CAN frames.
• ISO 11992−1: CAN fault-tolerant for truck/trailer
communication
• ISO 11783−2: 250 kbit/s, Agricultural Standard
ISO 11783-2 uses four unshielded
twisted wires; two for CAN and two
for terminating bias circuit (TBC)
power and ground. This bus is used
on agricultural tractors. It is in-
tended to provide interconnectivity
between the tractor and any agri-
cultural implement adhering to the
standard.
• ISO 15765-2, also called ISO-TP, is a standard for
HIGHER LAYER IMPLEMENTATIONS
flow control and handling of messages larger than
eight bytes.
• SAE J1939−11: 250 kbit/s, Shielded Twisted Pair
(STP)
• SAE J1939-15: 250 kbit/s, Unshielded Twisted Pair
(UTP) (reduced layer)
The SAE J1939 standard uses a
two-wire twisted pair, −11 has a
shield around the pair while −15
does not. SAE 1939 defines also
application data and is widely used
in heavy-duty (truck) and autobus
industry as well as in agricultural &
construction equipment.
• SAE J2411: Single-wire CAN (SWC)
ing, and transportation of data blocks larger than one mes-
sage, and above all, application data, many implementa-
tions of higher layer protocols were created. Several are
standardized for a business area, although all can be ex-
tended by each manufacturer. For passenger cars, each
manufacturer has its own standard. Among these imple-
mentations are:
• ARINC 825 (for the aviation industry)
• CANaerospace (for the aviation industry)
• CAN Kingdom
• CANopen (used for industrial automation)
• CCP / XCP
• DeviceNet (used for industrial automation)
• EnergyBus (used for electrical vehicles)
• GMLAN (for General Motors)
• ISO 15765-4
• ISO 11783 or ISOBUS (agriculture)
• ISO 14229 Road vehicles — Unified diagnostic ser-
vices (UDS) — Specification and requirements
• SAE J1939 (heavy road vehicles)
• ISO 11992 for heavy trailers
• MilCAN
• NMEA 2000 (marine industry)
 9

• RV-C (used for recreational vehicles) • Car audio

• SafetyBUS p (used for industrial automation) • CAN bus monitor
• SmartCraft
• can4linux – Open Source Linux device driver for
• Smart Distributed System (SDS) CAN
• VSCP (used for building automation) • FlexCAN – An alternative implementation.

• FlexRay – A possible future direction

13 Security
• List of network buses
CAN is a low-level protocol, and does not support any • Local Interconnect Network – A low cost alterna-
security features intrinsically. Applications are expected tive.
to deploy their own security mechanisms; e.g., to authen-
ticate each other. Failure to do so may result in various • MOST bus
sorts of attacks, if the opponent manages to insert mes-
sages on the bus.[12] Password mechanisms exist for data • OBD-II PIDs - List of Parameter IDs
transfer that can modify the control unit software, like
software download or ignition key codes, but usually not • OSEK
for standard communication.
• SocketCAN – a set of open source CAN drivers and
a networking stack contributed by Volkswagen Re-
search to the Linux kernel.
14 Development tools
• CANopen
When developing and/or troubleshooting the CAN bus,
examination of hardware signals can be very important.
Logic analyzers and bus analyzers are tools which collect, 17 References
analyse, decode and store signals so people can view the
high-speed waveforms at their leisure. There are also spe-
[1] “CAN History”. CAN in Automation.
cialist tools as well as CAN bus monitors.
A CAN bus monitor is an analysis tool, often a combina- [2] Bosch Semiconductor CAN Literature
tion of hardware and software, used during development
[3] International Organization for Standardization
of hardware making use of the CAN bus.
Typically the CAN bus monitor will listen to the traffic [4] CAN in Automation (CiA) Other specifications
on the CAN bus in order to display it in a user interface.
[5] Building Adapter for Vehicle On-board Diagnostic, obd-
Often the CAN bus monitor offers the possibility to simu-
diag.net, accessed 2009-09-09
late CAN bus activity by sending CAN frames to the bus.
The CAN bus monitor can therefore be used to validate [6] Comparison of Event-Triggered and Time-Triggered
expected CAN traffic from a given device or to simulate Concepts with Regard to Distributed Control Systems A.
CAN traffic in order to validate the reaction from a given Albert, Robert Bosch GmbH Embedded World, 2004,
device connected to the CAN bus. Nürnberg

[7] http://www.gtplanet.net/
nismo-increases-gt6-gps-data-logger-functionality-and-track-count/
15 Licensing
[8] Understanding Microchip’s CAN Module Bit Timing
Bosch holds patents on the technology, and manufactur-
ers of CAN-compatible microprocessors pay license fees [9] “CAN BUS MESSAGE FRAMES – Overload Frame, In-
terframe Space”.
to Bosch, which are normally passed on to the customer in
the price of the chip. Manufacturers of products with cus- [10] “Controller Area Network (CAN)". Vector Group. Re-
tom ASICs or FPGAs containing CAN-compatible mod- trieved 25 Sep 2013.
ules need to pay a fee for the CAN Protocol License.[13]
[11] ISO 11898-1:2003 abtract

[12] We Drove a Car While It Was Being Hacked

16 See also
[13] License Conditions CAN Protocol and CAN FD Protocol
• Byteflight
10 18 EXTERNAL LINKS

18 External links
• Wiki on CAN technology and products

• Bosch specification (old document — slightly am-

biguous/unclear in some points, superseded by the
standard )

• Bosch CAN FD Specification Version 1.0

• Controller Area Network (CAN) Schedulability
Analysis: Refuted, Revisited and Revised
• Pinouts for common CAN bus connectors

• Independent discussion platform CANLIST

•

• A webpage about CAN in automotive

• Controller Area Network (CAN) Schedulability
Analysis with FIFO Queues
• Controller Area Network (CAN) Implementation
Guide
• Free Tutorial: Controller Area Network (CAN) In-
troduction and Fundamentals
• Freeware Bit-Timing calculator for Windows, sup-
ports a lot of microcontrollers, e.g. Atmel, STM32,
Microchip, Renesas, ... (ZIPfile)

• CAN Protocol Tutorial

 11

19 Text and image sources, contributors, and licenses

19.1 Text
• CAN bus Source: https://en.wikipedia.org/wiki/CAN_bus?oldid=694477776 Contributors: Heron, PhilipMW, Michael Hardy, Nixdorf,
SGBailey, Mcarling, Ee79, Egil, Ahoerstemeier, Ronz, ²¹², CAkira, Colin Marquardt, Sertrel, Selket, Natevw, Finlay McWalter, Jni,
Robbot, Pingveno, Akadruid, Zigger, Fleminra, Niteowlneils, RapidAssistant, Aechols, Bobblewik, Chrisbolt, Vsmith, Gejigeji~enwiki,
Agl~enwiki, Harriv, CanisRufus, Meestaplu, Mpeg4codec, Enric Naval, Nsaa, Tpikonen, Guy Harris, Hopp, Corwin8, Wdfarmer, Cbur-
nett, Suruena, Amorymeltzer, Versageek, Voxadam, Woohookitty, Robert K S, Slgrandson, MC MasterChef, Pentawing, Vegaswikian,
Allen Moore, FlaBot, Jidan, Benlisquare, DVdm, YurikBot, Deeptrivia, RussBot, Armistej, Arado, Shaddack, Grafen, Joel7687, Tony1,
Robotics1, Vanished user 34958, StealthFox, Dpotop, Attilios, SmackBot, Sagie, Marco Guardigli, KnowledgeOfSelf, Sam8, SethML,
Gilliam, Bluebot, EncMstr, MaxSem, Bsilverthorn, Thecoolestcow, Eliyahu S, JonHarder, Idonra, BIL, Kingdon, Drunken Pirate,
OhioFred, Khazar, IronGargoyle, Dicklyon, Ft1~enwiki, TastyPoutine, Russella, Kris iyer, Kvng, MisterTS, Wleizero, Dmorr, JohnCD,
Quibik, Optimist on the run, Thijs!bot, JacobBramley, Electron9, Mdem~enwiki, Iviney, Philippe, MStock, Stannered, AntiVandalBot,
Widefox, Hidayat ullah, Ramtam, MER-C, Skomorokh, IanOsgood, Wikipedia tang, Phosphoricx, Xoneca, Jredders, Benburleson, Nyq,
TheAllSeeingEye, Nikevich, Albramallo~enwiki, Gabriel Kielland, DerHexer, Calltech, MartinBot, STBot, Axlq, AGlossop, Stobor827,
Katharineamy, Plupp01, Patpou77, JuergenKlueser, Inwind, Trailprice, TFolsom, AlnoktaBOT, Langerwolfgang, Rocketmagnet, Nono le
petit robot~enwiki, Fxhomie, Qxz, Invernizzi.l, Andy Dingley, Kramer-Wolf, Thunderbird2, Kbrose, SieBot, Accounting4Taste, Fahidka,
Mc cappy, Radartooth3, Alex.muller, OKBot, Pikamander2, Treekids, Denisarona, Asher196, Zer0431, SlackerMom, ClueBot, Wolfch,
TinyMark, SuperHamster, Simon04, Lakshmank85, Alexbot, Tyler, Arjayay, Vendeka, IamNotU, Ajn1, Rvoorhees, Johnny.cespedes, Au-
tomotive joe, Andre maier, Ponchobonjo, Addbot, Meise, Mortense, Yoenit, Thomas888b, GyroMagician, Scientus, MrOllie, Lightbot,
Xylome~enwiki, Luckas-bot, Yobot, D rock naut, Thaiio, AnomieBOT, Hondrej, Littlebluenick, Xqbot, Notyetinspace, Marcelosr, Nasa-
verve, Ondrejandrej, RibotBOT, Reply123, Alexandreag, Anapaulasag, SD5, Depictionimage, FrescoBot, Miceduan, Hobsonlane, Nojan,
Plindemann, D'ohBot, Biker Biker, Triplestop, Jschnur, Betsytimmer, RedBot, Plasticspork, Marsal20, Kdub432, RolfBly, Deagle AP,
DASHBot, Thebigandroid, EmausBot, John of Reading, GoingBatty, Gregmelson, ZéroBot, Wikfr, Sbmeirow, Nyarcel, MarkO555, Leer-
aphael~enwiki, Rocketrod1960, Rotmat, ClueBot NG, Rcpinto, Millermk, Widr, 2001:db8, BG19bot, Erniotti, Piguy101, Juggers2k,
Hmpeople, Holyjoe722, BattyBot, Tayaq, Aaron Nitro Danielson, John from Idegon, AbuJazar, EE JRW, Marius siuram, Paxmar-
tian, Waheed446, Passengerpigeon, Epicgenius, Oneway3124, G2SPOT, DAALIYA, Catverine, Tc.guho, Liptakokgabora, Nyashinski,
Lagoset, Shanpali8, Levai.peter, Ncooper.csm, Wikigeek244, Crystallizedcarbon, KasparBot, Letuanbuh, SabakuOnigiri, Infatuationava,
Jegan2510, Emcguruexpert and Anonymous: 405

19.2 Images
• File:9_pin_d-sub_connector_male_closeup.jpg Source: https://upload.wikimedia.org/wikipedia/commons/7/78/9_pin_d-sub_
connector_male_closeup.jpg License: Public domain Contributors: Photo taken by Mike1024. Original artist: User Mike1024
• File:CAN-Bus-frame_in_base_format_without_stuffbits.svg Source: https://upload.wikimedia.org/wikipedia/commons/5/5e/
CAN-Bus-frame_in_base_format_without_stuffbits.svg License: CC BY-SA 3.0 Contributors: ? Original artist: ?
• File:CAN-Bus_Elektrische_Zweidrahtleitung.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/9e/CAN-Bus_
Elektrische_Zweidrahtleitung.svg License: CC-BY-SA-3.0 Contributors: Own work Original artist: Stefan-Xp
• File:CAN-Frame_mit_Pegeln_mit_Stuffbits.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/97/CAN-Frame_mit_
Pegeln_mit_Stuffbits.svg License: CC BY-SA 3.0 Contributors: ? Original artist: ?
• File:CAN_Bit_Timing2.svg Source: https://upload.wikimedia.org/wikipedia/commons/8/8a/CAN_Bit_Timing2.svg License: Public do-
main Contributors: en:Image:CAN Bit Timing2.png Original artist: en:User:Rocketmagnet, traced by User:Stannered
• File:CAN_ISO11898-2_Network.png Source: https://upload.wikimedia.org/wikipedia/commons/b/bc/CAN_ISO11898-2_Network.
png License: CC BY-SA 4.0 Contributors: Own work Original artist: EE JRW
• File:CAN_ISO11898-3_Network.png Source: https://upload.wikimedia.org/wikipedia/commons/0/07/CAN_ISO11898-3_Network.
png License: CC BY-SA 4.0 Contributors: Own work Original artist: EE JRW
• File:CAN_Node.png Source: https://upload.wikimedia.org/wikipedia/commons/c/c0/CAN_Node.png License: CC BY-SA 4.0 Contrib-
utors: Own work Original artist: EE JRW
• File:Folder_Hexagonal_Icon.svg Source: https://upload.wikimedia.org/wikipedia/en/4/48/Folder_Hexagonal_Icon.svg License: Cc-by-
sa-3.0 Contributors: ? Original artist: ?

19.3 Content license

• Creative Commons Attribution-Share Alike 3.0