Introduction

Developed by Robert Bosch GmbH, CAN is protocol is main used in automobiles

for communication between a control unit and its components.

It is a message-based protocol, designed originally for multiplex electrical wiring

within automobiles to save on copper, but can also be used in many other contexts.
For each device the data in a frame is transmitted sequentially but in such a way
that if more than one device transmits at the same time the highest priority device
can continue while the others back off. Frames are received by all devices,
including by the transmitting device.

For example, the Engine Control Unit is a major control using in a car. This unit
is connected to many sensors and actuators like air flow, pressure, temperature,
valve control, motors for air control etc. The communication between these
modules and the control unit is through CAN Bus.

In order to understand a little bit more about CAN Bus, CAN Controller and other
important aspects, the MCP2515 CAN Bus Controller Module is very helpful.

CAN is a multi-master serial bus standard for connecting Electronic Control Units
(ECUs) also known as nodes. (Automotive electronics is a major application
domain.) Two or more nodes are required on the CAN network to communicate.
A node may interface to devices from simple digital logic e.g. PLD, via FPGA up
to an embedded computer running extensive software. Such a computer may also
be a gateway allowing a general-purpose computer (like a laptop) to communicate
over a USB or Ethernet port to the devices on a CAN network.

All nodes are connected to each other through a physically conventional two wire
bus. The wires are a twisted pair with a 120 Ω (nominal) characteristic impedance.

A Controller Area Network (CAN bus) is a robust vehicle bus standard designed
to allow microcontrollers and devices to communicate with each other's
applications without a host computer. It is a message-based protocol which is
designed originally for multiplex electrical wiring within automobiles to save on
copper but can also be used in many other contexts. For each device the data in a
frame is transmitted sequentially but in such a way that if more than one device
transmits at the same time the highest priority device can continue while the others
back off. Frames are received by all devices, including by the transmitting device.

CAN is a multi-master serial a bus standard for connecting Electronic Control

Units (ECUs) also known as nodes. Automotive electronics is a major application
domain. Two or more nodes are required on the CAN network to communicate. A
node may interface to devices from simple digital logic e.g. PLD, via FPGA up to
an embedded computer running extensive software. Such a computer may also be
a gateway allowing a general-purpose computer (like a laptop) to communicate
over a USB or Ethernet port to the devices on a CAN network.

1
This bus uses differential wired-AND signals. Two signals, CAN high (CANH)
and CAN low (CANL) are either driven to a "dominant" state with CANH >
CANL, or not driven and pulled by passive resistors to a "recessive" state with
CANH ≤ CANL. A 0 data bit encodes a dominant state, while a 1 data bit encodes
a recessive state, supporting a wired-AND convention, which gives nodes with
lower ID numbers priority on the bus. Controlled Area Network of simple CAN is
a bus standard that allows a Microcontroller and its peripheral devices to
communicate without the need of a host device or a computer.

CAN BUS Protocol Speed and Range?

Communication speeds of the CAN BUS protocol ranges from 10kpbs to 1Mbps.

The speed also depends on the length of wire used. The shorter it is, the faster the
communication speed and the longer it is, the slower the communication speed.
For example, at 40 meters, the speed will be at 1Mbps. At 1000 meters, the speed
can be at 50kpbs.

The node distance is generally advised to be no more than 0.3 meters / 1 foot.

Advantage Of CAN Protocol

CAN is a two-wire, half duplex, high-speed network system, that is far superior to
conventional serial technologies such as RS232 in regard to functionality and
reliability and yet CAN implementations are more cost effective.

Fig 1. Basic CAN structure

While, for instance, TCP/IP is designed for the transport of large data amounts,
CAN is designed for real-time requirements and with its 1 MB/sec baud rate can
easily beat a 100 MB/sec TCP/IP connection when it comes to short reaction
times, timely error detection, quick error recovery and error repair.

CAN networks can be used as an embedded communication system for

microcontrollers as well as an open communication system for intelligent devices.
Some users, for example in the field of medical engineering, opted for CAN
because they have to meet particularly stringent safety requirements.

2
Similar requirements had to be considered by manufacturers of other equipment
with very high safety or reliability requirements (e.g. robots, lifts and
transportation systems).

The greatest advantage of Controller Area Network lies in the reduced amount of
wiring combined with an ingenious prevention of message collision (meaning no
data will be lost during message transmission).

Without CAN - With CAN

Fig 2. Advantage of CAN

CAN Communication

A great variety of microprocessor chips, such as the ARM Cortex-M3 processor,

provide interfaces such as Ethernet, digital I/O, analog I/O, USB, UARTS, and,
last but not least, Controller Area Network. However, that does not mean that you
can use the chip “as is” and connect it to a network, sensors, etc. All of these
interfaces require some kind of a “hardware driver.” In case of serial technologies
such as RS232 or CAN, you will need the corresponding transceiver.

In the specific case of the CAN bus controller, we need a line driver (transceiver)
to convert the controller’s TTL signal to the actual CAN level, which is a
differential voltage. The use of differential voltage contributes to the vast
reliability of CAN.

3
 Fig 3. Can Bus structure

The next image compares both signals, TTL and differential voltage:

Fig 4. Comparison between CAN and TTL logic

The actual signal status, recessive or dominant, is based on the differential voltage
between CAN_H and CAN_L (2V during dominant bit time; 0V during recessive
bit time).

4
CAN Node

An ECU that performs its tasks in a CAN network is referred to as a CAN node.
In the beginnings of ECU networking, an adequate implementation of the CAN
interface involved a simple CAN driver — which provided an essentially simple
hardware independent interface for the application — together with a CAN
controller and a CAN transceiver. Today, it is no longer possible to do without an
operating system, network management functions or diagnostics. The software
complexity, which has meanwhile become enormous, makes it necessary to
standardize the ECU infrastructure.

CAN Controller

An electronic control unit (ECU) that wants to participate in CAN communication

requires a CAN interface. This comprises a CAN controller and a CAN
transceiver. The CAN controller fulfills communication functions prescribed by
the CAN protocol, which relieves the host considerably.

CAN Transceiver

Previously, the CAN controller was frequently connected to the communication

media (CAN bus) by a discrete circuit. Today, however, CAN transceivers handle
the bus connection. A CAN transceiver always has two bus pins: one for the CAN
high line (CANH) and one for the CAN low line (CANL). This is because physical
signal transmission in a CAN network is symmetrical to achieve electromagnetic
compatibility, and the physical transmission medium in a CAN network consists
of two lines.

CAN Bus

Physical signal transmission in a CAN network is based on transmission of

differential voltages (differential signal transmission). This effectively eliminates
the negative effects of interference voltages induced by motors, ignition systems
and switch contacts. Consequently, the transmission medium (CAN bus) consists
of two lines: CAN high line (CANH) and CAN low line (CANL).

Twisting of the two lines reduces the magnetic field considerably. Therefore, in
practice twisted pair conductors are generally used as the physical transmission
medium.

CAN Bus Logic

A basic prerequisite for smooth communication in a CAN network — especially

for bus access, fault indication and acknowledgement — is clear distinctions
between dominant and recessive bus levels. The dominant bus level corresponds
to logical “0”. The recessive bus level corresponds to logical “1”.

5
CAN Communication Principle
CAN network is based on a combination of multi-master architecture and line
topology: essentially each CAN node is authorized to place CAN messages on the
bus in a CAN network. The transmission of CAN messages does not follow any
predetermined time sequence, rather it is event-driven. A method of receiver-
selective addressing is used in a CAN network to prevent dependencies between
bus nodes and thereby increase configuration flexibility: Every CAN message is
available for every CAN node to receive (broadcasting). A prerequisite is that it
must be possible to recognize each CAN message by a message identifier (ID) and
node specific filtering. Although this increases overhead, it allows integration of
additional CAN nodes without requiring modification of the CAN network.

CAN Message Frames

The actual signal status, recessive or dominant, is based on the differential voltage
between CAN_H and CAN_L (2V during dominant bit time; 0V during recessive
bit time).

So what does a CAN message actually look like? The original ISO standard laid
out what is called Standard CAN. Standard CAN uses an 11-bit identifier for
different messages, which comes to a total of 2 11 , i.e. 2048, different message IDs.
CAN was later modified; the identifier was expanded to 29 bits, giving
229 identifiers. This is called Extended CAN. CAN uses a multi-master bus, where
all messages are broadcast on the entire network. The identifiers provide a
message priority for arbitration.

CAN uses a differential signal with two logic states, called recessive and
dominant. Recessive indicates that the differential voltage is less than a minimum
threshold voltage. Dominant indicates that the differential voltage is greater than
this minimum threshold. Interestingly, the dominant state is achieved by driving a
logic '0' onto the bus, while the recessive state is achieved by a logic '1'. This is
inverted from the traditional high and low used in most systems. These two states
will be detailed later on in the article. The important thing is that a dominant state
overrides a recessive during arbitration.

CAN Frames

For transmitting user data, ISO 11898-1 prescribes the so-called data frame.

The error frame is available to indicate errors detected during communication. An

ongoing erroneous data transmission is terminated and an error frame is issued.
The layout of an error frame differs significantly from the structure of the
terminated erroneous data or remote frame. It consists of just two parts: The error
flag and the error delimiter.

6
 Fig 5. CAN Frames

Data Frame

Data frames assume a predominant role in a CAN network: They serve to transmit
user data. A data frame is made up of many different components. Each individual
component carries out an important task during transmission. Tasks to be
performed are: Initiate and maintain synchronization between communication
partners, establish the communication relationships defined in the communication
matrix and transmit and protect the user data. Transmission of a data frame begins
with the start bit (Start of Frame — SOF). It is transmitted by the sender as a
dominant level which produces a signal edge from the previous recessive (bus
idle) level which is used to synchronize the entire network. In order for the
receivers not to lose synchronism to the sender during transmission of the frame,
they compare all recessive-to-dominant signal edges with their preset bit timing.
In case of deviation, receivers re-synchronize by the amount of the relevant phase
error (resynchronization). Following the SOF is the identifier (ID). This sets the
priority of the data frame, and together with the acceptance filtering it provides for
sender-receiver relations in the CAN network that are defined in the
communication matrix. Next comes the RTR bit (Remote Transmission Request).
It is used by the sender to inform receivers of the frame type (data frame or remote
frame). A dominant RTR bit indicates a data frame. The IDE bit (Identifier
Extension bit) which follows serves to distinguish between standard format and
extended format. In standard format the identifier has 11 bits, and in extended
format 29 bits. The figure “Data Frame in Standard and Extended Format” is
available to study the two formats.

7
Standard CAN Data Frame

Fig 6. Standard CAN Data Frame

The standard CAN message frame consists of a number of bit fields. The first bit
is the start of frame (SOF). This dominant bit represents the start of a CAN
message. Next is the 11-bit identifier, which establishes the priority of the CAN
message. The smaller the identifier, the higher the priority of the message.

The remote transmission request (RTR) bit is normally dominant, but it goes
recessive when one node is requesting data from another. The identifier extension
(IDE) bit is dominant when a standard CAN frame is being sent and not an
extended one. The r0 bit is reserved and not currently used. The data length code
(DLC) nibble signifies how many bytes of data are in this message.

Next is the data itself, being as many bytes as represented in the DLC bits. The
cyclic redundancy check (CRC) is a 16-bit checksum for detecting errors in the
transmitted data. If the message is properly received, the receiving node overwrites
the recessive acknowledge bit (ACK) with a dominant bit. The ACK also contains
a delimiter bit to keep things synchronized. The end of frame (EOF) signifies the
end of the CAN message and is 7 bits wide, for detecting bit-stuffing errors. The
last part of a CAN message is the interframe space (IFS), used as a time delay.
This time delay is precisely the amount of time needed for a CAN controller to
move the received message into a buffer for further processing.

Extended CAN Data Frame

Extended CAN uses a 29-bit identifier along with a few additional bits. An
extended message has a substitute remote request (SRR) bit after the 11-bit
identifier, which acts as a placeholder to keep the same structure as standard CAN.
This time the identifier extension (IDE) should be recessive, indicating that the
extended identifier follows it. The RTR bit is after the 18-bit ID and is followed
by a second reserve bit, r1. The rest of the message remains the same.

Fig 7. Extended CAN Data Frame

8
 Fig 8. CAN standard and extended frame

The DLC (Data Length Code) communicates the number of payload bytes to the
receivers. The payload bytes are transported in the data field. A maximum of eight
bytes can be transported in one data frame. The payload is protected by a
checksum using a cyclic redundancy check (CRC) which is ended by a delimiter
bit. Based on the results of the CRC, the receivers acknowledge positively or
negatively in the ACK slot(acknowledgement) which also is followed by a
delimiter bit. After this the transmission of a data frame is terminated by seven
recessive bits (End Of Frame —EOF).

Remote Frame

Besides the data frame used to transport data, there is the remote frame — a frame
type used to request data, i.e. data frames, from any CAN node. Nonetheless, these
frames are hardly ever used in automotive applications, since data transmission is
not based on requesting, rather it is primarily based on the self-initiative of
information producers. Remote frames may be transmitted in either standard or
extended format.

Addressing

Communication in the CAN network is based on content-related addressing. It is

not the CAN nodes that have identifiers, but rather the data and remote frames are
identified (identifier — ID). So, all CAN messages can be received by every CAN
node (broadcasting). Each receiver is independently responsible for selecting
CAN messages. Such receiver-selective addressing is very flexible, but it requires

9
that each receiver filters the received CAN messages (acceptance filtering).

SOF (1 Bit)

The dominant Start of Frame (SOF) bit represents the start of a Data/Remote
Frame and, in all consequence, also starts the arbitration sequence (the arbitration
field follows right after the SOF bit). A CAN node, before attempting to access
the bus, must wait until the bus is idle. An idle bus is detected by a sequence of 11
recessive bits, i.e. the sequence of ACK Delimiter bit in the Acknowledgement
Field (1 bit), the End of Frame Field (7 bits) and the Intermission Field (3 bits).

Arbitration Field (12 or 32 Bit)

The arbitration field contains of two components:

11/29 Bit Message Identifier, first Bit is MSB .The CAN message ID can be 11 or
29 bits long.

RTR (Remote Transmission Request) indicates either the transmission of a Data

Frame (RTR = 0) or a Remote-Request Frame (RTR = 1).

A low message ID number represents a high message priority.

A Data Frame has higher priority than a Remote Frame.

Fig 9. Arbitration Field with 11-Bit Identifier

The total length of the arbitration field is 12 bits when an 11 bit message identifier
is used

Fig 10. Arbitration Field with 29-Bit Identifier

the total length of the arbitration field will be 32 bit with a 29 bit identifier . An

10
11 bit identifier (standard format) allows a total of 2 11 (= 2048) different messages.
A 29 bit identifier (extended format) allows a total of 2 29 (= 536+ million)
messages.

Control Field (6 Bits)

The 4 LSB bits of the Control Field specify the length of the data block (DLC =
Data Length Code), the MSB bit (IDE = Identifier Extension) indicates either
standard 11-Bit format (Bit = 0) or 29-Bit extended format (Bit = 1).

Fig 11. Control Field

the CAN message ID can be 11 or 29 bits long. The IDE bit became active with
the release of the CAN 2.0B standard (i.e. the extension of the message identifier
from 11 to 29 bits). The previous standard CAN 2.0A referred to bits r0 and r1
(instead of IDE), which were, at the time, reserved for future purposes. Both bits,
r0 and r1, were always sent as dominant (zero), which, according to standard CAN
2.0B, indicates an 11 bit identifier per default.

The Data Length Code (DLC) is usually set to a value between 0 and 8 indicating
a data field length between 0 and 8 bytes. A value greater than 8 is permissible for
application specific purposes. In this case the sending node must send 8 data bytes,
while the receiving nodes are expecting 8 bytes.

Data Field

Maximum 8 bytes, first Bit is MSB.

CRC and Acknowledgement

The CRC (Cyclical Recovery Checking) Field contains of the CRC Sequence and
a CRC Delimiter Bit.

11
 Fig 12. CRC Field

The 15 bit CRC Segment contains the frame check sequence spanning from SOF
(Start of Frame), through the arbitration field, control field and data field. Stuffing
Bits are not included .

Fig 13. Range of Checksum application

The CRC Delimiter Bit (always recessive, i.e. 1), following right behind the CRC
Segment, allows for CRC processing time.

One of the greatest challenges of serial communication in the automotive

environment is to guarantee an extremely high level of reliability in transmission.
The CRC method that is used (CRC: Cyclic Redundancy Check) represents one
of the most powerful error detection methods. In the CRC method, a CRC
sequence is computed based on the bits to be transmitted (from SOF up to and
including the data field) and a generator polynomial G(x) defined by ISO 11898-
1. The CRC sequence is appended to the bits to be transmitted. The overall
polynomial is a multiple of the bits to be transmitted. The receiver of the overall
polynomial can then detect — with very high reliability — whether a transmission
error occurred (exception: CRC sequence itself was corrupted by a disturbance),
i.e. if division by the generator polynomial yields a remainder.

Acknowledgement Field (2 Bits)

The Acknowledgement Field contains of a 1 bit Acknowledgement Slot plus the

ACK Delimiter Bit (which is always recessive).

12
 Fig 14. Acknowledgement Field

Unlike other serial communications, such as RS232, the acknowledgement field

does not serve as a signal for the successful or unsuccessful reception of a message
by a receiving node (consider that there may be numerous receiving nodes in a
CAN network). The acknowledgement field serves as a confirmation of a
successful CRC (checksum) check by the receiving nodes in the network.

During the ACK slot, the message transmitting node switches to receive mode by
sending a recessive signal to the bus. At the same time all other nodes in the
network accomplish their individual CRC (checksum) check (according to the
CAN standard all nodes must determine the checksum in the same standardized
way) and output a dominant signal to the bus if the check was successful.

The message transmitting node monitors the bus and expects a dominant level
during the ACK slot. This will be the case when either one of the receiving CAN
nodes outputs a dominant level.

Fig 15. Acknowledgement Function

13
In case that all nodes in the network determine a checksum error, meaning the
sending node monitors a recessive level in the ACK slot, it is clear that the sending
node calculated a wrong checksum. The error is therefore local at the sending
node.

Any receiving node detecting a checksum error will post an error frame to the bus,
i.e. right after the completed acknowledgement field. With this scenario it is
possible to determine whether or not the actual malfunction is with that particular
receiving node.

It is possible that the ACK slot remains dominant, while at the same time an error
is reported by only one receiving node, meaning this single node will send out an
error frame. The error is therefore local at that particular receiving node.

The CAN standard allows the so-called “self-retirement” (or self-removal) of

nodes from the network due to an excessive number of transmit or receive errors .

The ACK Delimiter Bit is always recessive. This is necessary in order to

distinguish a successful acknowledgement from an occurring error frame. An error
frame starts with at least 6 successive dominant bits, meaning the first bit of an
error frame will override the ACK Delimiter Bit .

End-of-Frame Field (7 bits, recessive)

Each data or remote frame is terminated by a bit sequence of 7 recessive bits.

Each CAN message frame, regardless of the message ID length, will be terminated
by a sequence of 11 recessive bits: The ACK Delimiter bit in the
Acknowledgement Field (1 bit), the End of Frame Field (7 bits) and the
Intermission Field (3 bits).

Fig 16. End Of Frame Field

14
This last statement is actually only true, unless an Overload Frame occurs .

More specifically: With the combination of the EOF Field and the preceding
recessive ACK Delimiter Bit each message (data and remote) frame is terminated
by 8 recessive bits plus, unless an overload frame occurs, the 3 recessive bits of
the Intermission Field.

As shown in the following picture, the up to 11 recessive bits at the end of a

message frame are not subject to bit stuffing error detection, since the bit stuffing
applies only between the SOF (Start Of Frame) bit and (including) the CRC
Sequence .

Bit Stuffing

A basic prerequisite for correct data transmission is synchronized communication

partners. The dominant-to-recessive signal edge of the start bit serves to produce
synchronism (Start Of Frame — SOF) of a CAN message. Afterwards,
aresynchronization mechanism is used to maintain synchronism up to the end of
the message transmission.

Fig 17. Bit Stuffing Range

Principle of Bus Access

In case of simultaneous bus access, the CSMA/CA method based on bitwise bus
arbitration ensures that the highest priority CAN message among the CAN nodes
prevails. In principle, the higher the priority of a CAN message the sooner it can
be transmitted on the CAN bus. In case of poor system design, low priority CAN
messages even run the risk of never being transmitted.

Bitwise Bus arbitration

Arbitration logic decides whether a CAN node may continue to send, or whether
it must stop sending.

15
 Fig 18. BUS Acess in CAN Network

At the end of the arbitration phase, the CAN node transmitting the CAN message

with the lowest ID gets authorization to send. CAN nodes with lower priority
messages switch to the receiving state, later they access the CAN bus for another
sending attempt as soon as it is available again.

Prioritization

The priorities of the CAN messages are decisive in obtaining bus access in the
CAN network. They are encoded via the identifier which is transmitted bitwise
from the most significant to the least significant bit.

Wired-AND bus logic and arbitration logic ensure that the priority of the CAN
message increases with decreasing identifier value: The smaller an identifier is,
the higher the priority of the CAN message. The figure “Prioritization” explains
this relationship.

16
 Fig 19. Prioritization Of CAN Messages

Principle of Data Protection

Reliable data transmission is a prerequisite for the safety and reliability of

electronic systems in motor vehicles. Therefore, CAN not only has to satisfy strict
real time requirements, but must always provide for reliable data transmission.
Because CAN is also used in very time and safety critical applications within the
motor vehicle, requirements for data integrity are extremely high.

Logical Error Detection

The bit monitoring and ACK check error detection mechanisms are performed by
the sender. Independent of acceptance filtering, the receivers perform the form
check, stuff check and cyclic redundancy check.

Fig 20. Form Check

17
Fig 21. Bit Monitoring & Stuff Check

Fig 22. CRC

18
 Fig 23. ACK Check

Error Tracking

Depending on the specific error count, a CAN controller handles switching of the
error state. After the start, a CAN controller assumes the normal state Error Active.
In this state, the CAN controller sends six dominant bits (active error flag) after
detecting an error. When a limit is exceeded (TEC>127; REC>127), the CAN
controllers switch over to the “Error Passive” state. If a CAN controller fails or if
there are extreme accumulations of errors, a state transition is made to the Bus Off
state. The CAN controller disconnects from the CAN bus. The Bus-Off state can
only be exited by intervention of the host (with a mandatory waiting time of 128
x 11 bits) or by a hardware reset.

CAN Message Types

Now that we know what a CAN message looks like, you might be wondering what
kinds of messages are passed along the bus. CAN allows for four different
message types. They are the data frame, remote frame, overload frame, and error
frame.

A standard CAN data frame makes use of the identifier, the data, and data length
code, the cyclic redundancy check, and the acknowledgment bits. Both the RTR
and IDE bits are dominant in data frames. If the recessive acknowledge bit at the
receiving end is overwritten by a dominant bit, both the transmitter and receiver
recognize this as a successful transmission.

A CAN remote frame looks similar to a data frame except for the fact that it does
not contain any data. It is sent with the RTR bit in a recessive state; this indicates
that it is a remote frame. Remote frames are used to request data from a node.

When a node detects an error in a message on the CAN bus, it transmits an error
frame. This results in all other nodes sending an error frame. Following this, the
node where the error occurred retransmits the message. The overload frame works

19
similarly but is used when a node is receiving frames faster than it can process
them. This frame provides a time buffer so the node can catch up.

Bus Arbitration & Signaling

CAN is a CSMA/CD protocol, meaning each node on the bus can detect collisions
and back off for a certain amount of time before trying to retransmit. This collision
detection is achieved through a priority arbitration based on the message
identifiers. Before we discuss arbitration, let's take a closer look at the dominant
and recessive bits used on the CAN bus.

Inverted Logic

An interesting aspect of the CAN bus is that it uses an inverted form of logic with
two states, dominant and recessive. Figure 5, below, shows a simplified version of
a CAN transceiver's output and input. The '101' bitstream is coming from/going to
a CAN controller and/or microcontroller. Notice that when the controller sends a
stream of bits, these are complemented and placed on the CANH line. The CANL
line is always the complement of CANH. For arbitration to work, a CAN device
must monitor both what it is sending and what is currently on the bus, i.e., what
it's receiving.

Fig 24. CAN output/input

Next figure shows both the CANH and CANL signals simultaneously so that you
can see the CAN bus in action. Plotted below the bus signals is the differential
voltage that corresponds to the dominant and recessive states of the CAN signals.
The first three segments in time, t1–t3, are drawn to match up with the three bits
shown above . We will look at this from the perspective of the output driver. The
driver's input initially sees a '1' and complements this to a zero, which is placed on
CANH. CANL sees the complement of CANH and goes high. This is shown as t1
in Figure 6. Notice that the CANH and CANL voltages are offset from one
another. During time t1, CANH – CANL is very close to zero, since CANH and
CANL are almost the same voltage. This period, where the driver is sending a
logic '1' resulting in CANH and CANL being close to the same voltage, is what
we call the CAN recessive state.

The next bit sent is a '0' . CANH gets its complement and CANL again gets the
complement of CANH. Notice this time that the CANH and CANL voltages are
not close to one another. Therefore, the differential voltage (VDIFF) is larger. This

20
is the CAN dominant state. We say that the logic is inverted because a '1' takes the
bus low and a '0' brings it high. The input receiver works in a similar fashion.

Fig 25.CAN BUS arbitration with differential voltage

21
 Literature Survey
For completion, justification and solving the problem definition, a number of
research papers, magazines, journals and online links are investigated in details.
In this chapter, the details of research papers and journals are specified from where
we have analyzed the content and formulated the problem.

A number of research scholars and scientists has written a number of research

papers and found excellent results. This section underlines all those research
papers and their extracts

A Salunkhe; Pravin P Kamble ; Rohit Jadhav [1]- CAN bus is a serial

bus protocol used in most automotive industries. Recently, more attention on
the CAN bus network application and wireless transmission bus carrying
technology. CAN bus technology is adopted in modern vehicles to reduce the
wiring harness and controls the vehicle using electronics system. In this paper,
CAN bus protocol is implemented using a single board computer (SBC) and
accessed the vehicle parameters remotely. Raspberry Pi is used as SBC which
has a high-performance processor used to increase speed ability. The presented
work concentrates on the communication between three nodes using a CAN bus
and how to access modern vehicle ECU parameters using OBD II connector.
The paper is described further set up of CAN device using Linux software.

The Controller Area Network (CAN) is a serial field bus system with a message-
based protocol. The protocol is multi master based. CAN was developed by the
Robert Bosch GmbH and released in 1986. Developed to reduce wiring cost in
automobile industry. Currently, computer technology has been widely used in
vehicle monitoring and control systems, and the proportion of car electronics
represented by micro-controller continues to increase at the whole vehicle
electronic systems. The system describes communication between three nodes
using a CAN bus. The two nodes are designed for getting the information of
vehicle parameters such as speed, Engine temperature and brake status
measurement. The two nodes transmit their sensed data over a can bus. The third
node receive the data from the CAN bus and display it on GUI (Graphical User
Interface) as well as the third node act as server so that a user or owner can get
the information of such parameters remotely. The second part of this paper is
that third node is connected to OBD-II (On Board Diagnostic-II) connector
which is present in every modern vehicle below or near the steering. The third
node can access all the ECU (electronic control unit) parameters and control the
vehicle by writing the messages through the third node. The system will be used
to hack the vehicle remotely.

Jufang Hu ; Chunru Xiong[2]- This paper introduces a system that uses

ARM as the main controller and double gateway in a control computer within a
car. This system makes full use of the high-performance of ARM, high-speed

22
reduction of CAN bus communication control networks and instrument control
so as to achieve full sharing of data between nodes and enhance their
collaborative work. This system features efficient data transfer among different
nodes in the practical applications.

As the increasing of the amount of electronic controller and instruments in the

modern automotive, it is observed that the vehicle reliability is largely
influenced by the complexity of circuit deployed in the control system . In
addition, the maintenance is hard to carry out. From the layout point of view,
the traditional electric systems use a single point-topoint communication
approach, which will inevitably result in large pet cabling problem. Therefore,
the high quality vehicles use CAN (Controller Area network) bus system to link
all the controllers in a system to achieve unified management . That leads to
easy data sharing and interoperability between different control systems.
However, due to the complexity of vehicles, for example, sensors are deployed
throughout the entire vehicle with diversified standards, the data within an
automotive system are varied such as complex data format, heterogeneous data
etc . It is facing a challenge that the gap among different systems is hard to
fulfill. One solution, a gateway is a bridge to connect various CAN bus with
different speed ratio. Furthermore, the vehicle system requires the information
for the maintainer and driver. It is necessary to design an efficient, reliable
gateway as well as its data processing system. This paper introduces such
gateway with the data processing system using ARM (Advanced RISC
Machines) as the central controller. The CAN bus system in an automotive
system is introduced firstly. Secondly, the gateway system based on ARM is
proposed. Finally, the control system utilized micro-Linux is reported in terms
of software design and network architecture.

Shuking Guo[3]-It is the application of Controller Area Network (CAN) that

changed vehicle electrical system wiring and control mode, wiring harness and
controller pin count were decreased, so the cost was reduced. The comparative
method is applied in this paper base on traditional vehicle circuit and CAN-bus
circuit. The result shows CAN-bus not only can improve reliability and control
function, but reduced the costs and the car failure rate.

Each control unit on the requirements of real-time differs from data update rate
and the control cycle. It requires the data exchange network based on the priority
of competing models and has a high communication rate, CAN bus is designed
to meet these requirements. According to the specific models network can be
configured different nodes, it forms a CAN network topology. the entire
network segment is composed of three parts, namely, power system parts, body
control part and the audio entertainment section. Usually, power system uses
highspeed CAN communication and body control and audio entertainment
system uses low-speed CAN communication. The high-speed CAN
communication network usually refers to faster than 125Kbps, such as 250Kbps
and 500Kbps. The high-speed CAN communication network usually refers to
less than 125Kbps, such as 125Kbps, 64Kbps and 50Kbps etc. The above
diagrams of the three parts are connected via a gateway which can achieve the
exchange of information among different segments. With the rapid development
of computer technology, network technology has already integrated with control

23
engineering, namely, the bus which makes our imagination come true. Users
can put the electronic control unit, which was produced by different company
and been suitable for the bus standards, as a single entity. Therefore, an excellent
performance control system can be founded.

Xiaoming Li ; Mingxiong Li[4]- A CAN BUS communication module for

embedded system has been proposed in this paper, together with its hardware
and software design. The motivation to design such CAN module is try to ease
the development of CAN-BUS based embedded applications. With the CAN
module, the engineers do not have to understand all aspects of CAN protocol,
CAN controllers and CAN transceivers, therefore an industry automation
application can be built conveniently. The CAN module provides simple
hardware interface and highly abstracted software communication protocol, due
to the abstraction and integration of all CAN related communication functions
in an embedded module, and therefore can be easily embedded into any MCU
based systems. The CAN module can can send/receive data following the pipe
based communication model. With the help of the software package, the CAN-
BUS communication would be transparent to the micro-controllers of the nodes
in the system.

The CAN field BUS has now been widely used in Mechatronics systems for
distributed measurement and control, attributed a lot to its characteristics such
as real time, multicast communication ability, and its performance in heavy
network load conditions. The hardware units such as CAN Controller and CAN
Trasnsciever make the application developement job easier, and the integration
of CAN controller and MCU also propels the usage of CAN technology in
different areas. There are also many tools have been designed to ease the use of
CAN-BUS, such as PCI based CAN interface card, the USB-CAN transciever,
and the RS232/485-CAN converter.These devices enables the developer
intergrate the CAN-BUS into the system without having the knowledge of CAN
protocols. However, it is still not an easy thing for a novice to develop a CAN-
BUS involved application in an embedded system. In such system, the
developer should be familiar with the CANBUS protocols, also the interfaces
to the CAN communication ICs, which would be hard jobs for any untrained
engineers. It is necessary that the CAN-BUS, as a kind of communication
media, should be modularized as an embedded CAN module, in order to lower
the degree of difficulties in the embedded CAN application development. There
are also some other benifits for the embedded CAN module(ECM), such as
providing the common interface for distributed control system, the plug and
play ability and short development cycle.

Fang Li ; Lifang Wang ; Chenglin Liao[5]-CAN bus communication

system was established mainly using SimEvents module in the software of
Matlab/Simulink. Performance indexes of CAN bus system, which embraces
worst-case response time of messages and bus load, were separately gained by
theoretical calculation, experiments in Matlab and CANoe. The calculation and
experiment results were compared sufficiently, and it concludes that CAN bus
system established in Matlab/Simulink can efficiently represent the message
transfer sequences on the CAN bus, and achieve an exact result of the
performance analysis of the CAN bus system. With CAN bus system

24
established in Matlab/Simulink, test modules for ECU (Electric Control Unit)
testing can conveniently be created, and it is an efficient testing tool for CAN
bus system design.

Controller area network (CAN) provides high reliability and good real-time
performance with very low cost. Due to this, CAN now is widely used in a wide
range of applications, such as in-vehicle communication, automated
manufacturing and distributed process control environments. In order to
guarantee real-time performance and reliability of CAN networks, it is
necessary to analyze system performance before it is running practically on the
real vehicle. There are mainly two methods to analyze the system’s real-time
performance. One is based on mathematical model. The method applied
processor scheduling analysis to CAN bus, the worst case real-time behavior of
CAN bus (message response time, bus load, etc.) is bounded and can be
accurately predicted. This method is widely used in the automotive areas, for
example, the VNA software of Mentor Graphics Company is based on this
method. Another method to evaluate the real-time performance of CAN bus
system is testing or experiment. CAN Bus models are established using different
tools such as Sate flow and OPNET . Adriano Carvalho did experiments on the
permanent faults of CAN bus using the Markov tool. But this work is not visible,
and the paper’s results can hardly be used in the real world. In this paper, a CAN
bus communication system that built using Matlab is given. A case study is
employed to compare the results obtained by Matlab with those obtained by
theoretical calculation and CAN experiment separately. The system can offer
an efficient and visible environment for analyzing CAN bus real-time
performance.

Xiao-feng WAN,Yi-si XING, Li-xiang CAI[6]- The real-time data

communication of real-time operation system is a difficult point. This paper
analyzes the functions and characteristics of embedded real-time operation
system VxWorks and CAN field bus, and makes use of CAN field bus to realize
the data communication between embedded realtime operation system
VxWorks and work-site MCU (Micro Controller Unit）. The applications of
CAN bus can satisfy the reliability and real-time request of data communication
completely. The general steps of CAN bus applications offer reference for CAN
bus applications in real-time operation system.

Controller Area Network (CAN) is a kind of multi-host local network that leads
to be offered by Bosch Company in modern automobile technology. CAN
protocol is stipulated as international standards by 150 International Standard
Organization. CAN protocol is a high-speed serial bus which follows 150/051
model and contains three-tier protocols: physical layer, data link layer and
application layer. In the practical application system of CAN bus, various field
intelligent devices represent a node separately. By means of CAN field bus, we
can realize the information transmission and communication among all nodes,
as well as between the field nodes and process control management, meanwhile,
various complicated automatic control function also could be achieved.
VxWorks, developed by WindRiver Company, is a high qualified real-time
operation system with leading industrial position. Simultaneously, it is suitable

25
for all mainstream CPU target platform with retractility, easy-clipped and high
reliability. VxWorks real-time operation system is composed of more than 400
relatively independent and brief modules, the user may choose the appropriate
modules according to the need to tailor and dispose system, therefore, the
system’s security and reliability are guaranteed effectively. System linker may
link some object modules automatically on the basis of applications need.
Through the on-demand combination among the object modules, the user may
obtain lots of applications which could meet the functions need.

Li Ran, Wu Junfeng, Wang Haiying[7]- -According to the

communication structure of CAN BUS network on EV, this paper works out a
SAE J1939 application layer protocol meet the system functional requirements,
and designs the software and hardware for the system. First, design the CAN
BUS work nod for EV, including the master node, the light node, air
conditioning node, doors and instrument node, etc, and the draw the CAN BUS
topology diagram. Meanwhile, according to the concrete situation of EV, work
out an application layer protocol that consistent with the SAE J1939 protocol,
and the information allocation table and message structure chart of CAN BUS
network node is also presented. Secondly, design the hardware and software for
the CAN BUS communication network. Hardware interface circuit mainly
consist of CAN communication controller SJAIOOO, high-speed opt coupler
6N137 and CAN BUS driver 82C250, and design schematic circuit diagram for
CAN bus system hardware. The software designs for CAN BUS network are
mainly the design of CAN BUS data communication and exchange between
nodes, and communication processing for switchsignal, analog signal. The
design of software communication module includes CAN initialization unit,
message sending unit, message receiving unit and the interrupt service unit.
Finally, the CAN BUS network communication system the paper designed is
applied to the new energy bus produced by CENS Energy-Tech Co., Ltd. which
is dedicated in the Shanghai World Expo.

26
 Inferences Drawn
The literature reviewed basically helped us in getting acquainted with the various
techniques through which our two phases – data transmission and data reception
could be made to work efficiently. We looked at various tools that have been
developed already for message transmission through CAN Bus. Also, the use of
MCP-2515 CAN BUS controller module along with Arduino has been suggested.
Apart from this, the need and challenges in real time transmissions were also
studied.

As a part of our future work on the project, various research papers on CAN
transfer protocol were also looked upon so that the rate of communication could
be increased and the process of communication could be made more efficient.

27
 System Requirement
Components Required

Arduino UNO x 2

MCP2515 x 2

USB Cable x 2

Connecting Wires

A Brief Note on MCP2515 CAN Bus Controller Module

The MCP2515 CAN Bus Controller is a simple Module that supports CAN Protocol version 2.0B and
can be used for communication at 1Mbps. In order to setup a complete communication system, you
will need two CAN Bus Module.

Fig 26. An MCP2515 CAN BUS Module

This particular module is based on MCP2515 CAN Controller IC and TJA1050 CAN Transceiver IC.
The MCP2515 IC is a standalone CAN Controller and has integrated SPI Interface for communication
with microcontrollers. Coming to the TJA1050 IC, it acts as an interface between the MCP2515 CAN
Controller IC and the physical can bus. Thus increasing the speed of system which is our requirement.

28
 Fig 27. MCP2515 CAN Controller

Schematic of MCP2515 CAN Bus Module

Before seeing the schematic of the module, we need to understand a couple of things about both the
ICs i.e. MCP2515 and TJA1050.

MCP2515 IC is the main controller that internally consists of three main subcomponents: The CAN
Module, the Control Logic and the SPI Block.

CAN Module is responsible for transmitting and receiving messages on the CAN Bus. Control Logic
handles the setup and operation of the MCP2515 by interfacing all the blocks. The SPI Block is
responsible for the SPI Communication interface.

Coming to the TJA1050 IC, since it acts as an interface between MCP2515 CAN Controller and the
physical CAN Bus, this IC is responsible for taking the data from the controller and relaying it on to
the bus.

The following image shows the schematic of the MCP2515 CAN Module and it shows how MCP2515
IC and TJA1050 IC are connected on the Module.

29
 Fig 28. Schematic of MCP2515

Arduino Uno

The Uno is a microcontroller board based on the ATmega328P. It has 14 digital input/output pins (of
which 6 can be used as PWM outputs), 6 analog inputs, a 16 MHz quartz crystal, a USB connection,
a power jack, an ICSP header and a reset button. It contains everything needed to support the
microcontroller. "Uno" means one in Italian and was chosen to mark the release of Arduino Software
(IDE) 1.0. The Uno board and version 1.0 of Arduino Software (IDE) were the reference versions of
Arduino, now evolved to newer releases. The Uno board is the first in a series of USB Arduino boards,
and the reference model for the Arduino platform.

The R3 is the third, and latest, revision of the Arduino Uno.

The Arduino Uno is a microcontroller board based on the ATmega328. It has 20 digital input/output
pins (of which 6 can be used as PWM outputs and 6 can be used as analog inputs), a 16 MHz resonator,
a USB connection, a power jack, an in-circuit system programming (ICSP) header, and a reset button.
It contains everything needed to support the microcontroller; simply connect it to a computer with a
USB cable or power it with a AC-to- DC adapter or battery to get started.

30
 Fig 29: Arduino Uno schematic Pin Diagram

The Uno differs from all preceding boards in that it does not use the FTDI USB-to-serial driver chip.
Instead, it features an ATmega16U2 programmed as a USB-to-serial converter. This auxiliary
microcontroller has its own USB bootloader, which allows advanced users to reprogram it.

The Arduino has a large support community and an extensive set of support libraries and hardware
add-on “shields” (e.g. you can easily make your Arduino wireless with our Weixel shield), making it
a great introductory platform for embedded electronics.

This is the 3rd revision of the Uno (R3), which has a number of changes:

 The USB controller chip changed from ATmega8U2 (8K flash) to ATmega16U2 (16K flash). This
does not increase the flash or RAM available to sketches.

 Three new pins were added, all of which are duplicates of previous pins. The I2C pins (A4, A5) have
been also been brought out on the side of the board near AREF. There is a IOREF pin next to the reset
pin, which is a duplicate of the 5V pin.

 The reset button is now next to the USB connector, making it more accessible when a shield is used.

31
 Fig 30: Original Diagram

Circuit Design Of MCP2515 with Arduino

The following image shows the circuit diagram of interfacing MCP2515 CAN Module with Arduino
and possible communication between two Arduino over CAN Protocol.

Fig 31. PIN module of MCP2515

32
 Fig 32. Circuit Diagram

As mentioned earlier, the CAN Controller IC facilitates SPI Communication Protocol for interfacing
with any Microcontroller. Hence, connect the SPI Pin i.e. SCK, MOSI (SI), MISO (SO) and CS of the
MCP2515 Module to corresponding SPI Pins of Arduino Make two such connections: one pair acts as
a transmitter and the other as a receiver. Now for the communication between this transmitter and
receiver, connect CANH and CANL pins of each MCP2515 Module.

33
Software Requirement

Coding

Since the communication involves a Transmitter Module and a Receiver Module, the code is also
divided into Transmitter Code and Receiver Code.

Transmitter Code

#include <SPI.h>

#include <mcp_can.h>

const int spiCSPin = 10;

int ledHIGH = 1;

int ledLOW = 0;

MCP_CAN CAN(spiCSPin);

void setup()

Serial.begin(115200);

while (CAN_OK != CAN.begin(CAN_500KBPS))

Serial.println("CAN BUS init Failed");

delay(100);

34
 }

Serial.println("CAN BUS Shield Init OK!");

unsigned char stmp[8] = {ledHIGH, 1, 2, 3, ledLOW, 5, 6, 7};

void loop()

Serial.println("In loop");

CAN.sendMsgBuf(0x43, 0, 8, stmp);

delay(1000);

Receiver Code

#include <SPI.h>

#include "mcp_can.h"

const int spiCSPin = 10;

const int ledPin = 2;

boolean ledON = 1;

MCP_CAN CAN(spiCSPin);

void setup()

Serial.begin(115200);
35
 pinMode(ledPin,OUTPUT);

while (CAN_OK != CAN.begin(CAN_500KBPS))

Serial.println("CAN BUS Init Failed");

delay(100);

Serial.println("CAN BUS Init OK!");

void loop()

unsigned char len = 0;

unsigned char buf[8];

if(CAN_MSGAVAIL == CAN.checkReceive())

CAN.readMsgBuf(&len, buf);

unsigned long canId = CAN.getCanId();

Serial.println("-----------------------------");

Serial.print("Data from ID: 0x");

Serial.println(canId, HEX);

36
 for(int i = 0; i<len; i++)

Serial.print(buf[i]);

Serial.print("\t");

if(ledON && i==0)

digitalWrite(ledPin, buf[i]);

ledON = 0;

delay(500);

else if((!(ledON)) && i==4)

digitalWrite(ledPin, buf[i]);

ledON = 1;

Serial.println();

37
 Working And Application

Working of this project is very simple as all the work is done by the libraries (SPI and CAN). Since
CAN is message-based communication, you need to send a message anywhere between 0 and 8
bytes.

In this project, the transmitter is sending a message as 1 1 2 3 0 5 6 7. This message is transmitted

over CAN Bus and the receiver receives this message and is displayed on its serial monitor.

Additionally, the 0th and 4th bit i.e. 1 and 0 in the above sequence are extracted separately by the
receiver and turns ON and OFF the LED connected to Pin 2 of Arduino.

Application
As mentioned in the introduction, CAN is widely used in the field of automobiles. Some of the
applications include:

 Electronic Gear Shift System

 Main Interface in Automation (like industrial)
 Medical Equipment
 Robotics
 Auto Start/Stop of Car Engine

38
 Conclusion

This thesis documented a design of MCP2515-CAN module which forms a communication bridge
between the MCP2515 and CAN protocols. The module provides a protocol conversion with a plug
and play feature where modification of neither the hardware nor the software is needed. CAN is a
reliable, robust and real time serial communication protocol which reduces wiring harness, weight and
complexity. The protocol creates a master to master communication bus and every message
transmitted on the bus is received by all the nodes connected to the bus. The message filtering
technique decides whether the received data is relevant to the node or not. The error detection and
fault confinement techniques provided by the protocol are the added features which keep the bus
working without any errors and virtually detach the faulty nodes which transmit corrupt messages on
the bus.

The rate at which the base station communicates with the PC should be equal to or lesser than the sum
of rates at which the sensors communicate over MCP2515 to avoid the overflow of the data.

39
 Future Scope

As the Internet of Things continues to grow and encompass more and more
complex systems, standardizing the way each component communicates with
the next will be vital in ensuring compatibility, expandability and installation
longevity. Here at Logic Supply we’re working with clients to implement
CAN bus communication in a wide range of custom embedded systems and
we see a bright future for the technology, particularly in manufacturing
environments and in modern building automation installation. All electric cars
are currently based in this technology and dependence on this technology will
only increase with time.

40