CAN Bus 3
CAN Bus 3
ON
“CAN BUS PROTOCOL”
Submitted by
ABHINAW TIWARI
Regd. No. 12010330
7th Semester, B.Tech. (CSE)
For the year 2016
CERTIFICATE
This is to certify that the seminar entitled “CAN Bus Protocol” presented by ABHINAW TIWARI
bearing registration number 12010330 of 7th Semester B.Tech. (Computer Science & Engineering) in
Veer Surendra Sai University of Technology, Burla has been successfully delivered during the year
2016.
Dr. Suvasini
Panigrahi Seminar
in-charge
Acknowledgement
I deem it a great pleasure and opportunity to dedicate a few lines to some persons who enabled
me to complete this seminar.
I am really indebted to Dr. Suvasini Panigrahi of Computer Science & Engineering for her
valuable suggestions, motivations and guidance right from scratch to the completion of the
seminar. Her contributions were indeed instrumental in achieving the final result.
I would also like to thank my friends especially Gourab and Sourav for their support
throughout.
Last but not the least, I want to thank all the members of the Department of Computer Science
& Engineering for their help in various ways for the completion of this seminar.
ABHINAW TIWARI
7TH SEMESTER
B.TECH. (CSE)
Abstract
CAN (Controller Area Network) is a serial communication technology used especially for
reliable data exchange between electronic control units (ECUs) in the automobile.
Data exchange between the electronic control units was initially implemented
conventionally, i.e. a physical communication channel was allocated to every signal to be
transmitted.
However, intensive wiring effort enabled just limited data exchange. The only solution that
seemed to offer a way out of this dilemma came from serial bit exchange of data via a
single communication channel (bus). This led to the need to conceptualize a serial
communication system tailored to the requirements of the automobile.
Contents
Abstract.................................................................................................................................. 4
1. Introduction........................................................................................................................ 6
1.1 Motivation for CAN........................................................................................................6
1.2 Standardization............................................................................................................. 6
2. CAN Communication.......................................................................................................... 7
2.1 CAN Network................................................................................................................ 7
2.2CAN Node...................................................................................................................... 7
2.3 CAN Controller.............................................................................................................. 7
2.4 CAN Transceiver.......................................................................................................... 8
2.5 CAN Bus....................................................................................................................... 8
2.6 CAN Bus Logic............................................................................................................. 8
2.7 CAN Communication Principle......................................................................................8
3. CAN Framing...................................................................................................................... 9
3.1 Frame Types................................................................................................................. 9
3.2 Data Frame................................................................................................................... 9
3.3 Remote Frame............................................................................................................ 11
3.4 Addressing.................................................................................................................. 11
3.5 CRC and Acknowledgement.......................................................................................11
3.6 Bit Stuffing.................................................................................................................. 12
4. CAN Bus Access.............................................................................................................. 12
4.1 Principle of Bus Access..............................................................................................12
4.2 Bitwise Bus arbitration................................................................................................12
4.3 Prioritization................................................................................................................ 13
5. CAN Data Protection........................................................................................................14
5.1 Principle of Data Protection........................................................................................14
5.2 Logical Error Detection...............................................................................................14
5.3 Error Tracking............................................................................................................. 16
6. Disadvantages.................................................................................................................. 17
7. Conclusion....................................................................................................................... 18
8. References....................................................................................................................... 19
Introduction
Data exchange between the electronic control units was initially implemented
conventionally, i.e. a physical communication channel was allocated to every signal to be
transmitted.
However, intensive wiring effort enabled just limited data exchange. The only solution that
seemed to offer a way out of this dilemma came from serial bit exchange of data via a
single communication channel (bus). This led to the need to conceptualize a serial
communication system tailored to the requirements of the automobile.
At the beginning of the 1980s, Bosch began to develop such a serial communication system.
It was given the name CAN (Controller Area Network). Even today, CAN is still performing
useful services in motor vehicles in networking ECUs in the powertrain, chassis and
convenience areas. Above all, CAN is characterized by very reliable data
transmission that satisfies the real-time requirements of target usage areas.
Standardization
CAN technology has been standardized since 1994 and is described by four ISO
documents. ISO 11898-1 describes the CAN protocol. In relation to the reference model of
data communication, the CAN protocol just covers the Data Link Layer (MAC — Medium
Access Control, LLC — Logical Link Control) and the Physical Layer (PLS — Physical
Signalling).
CAN Communication
CAN Network
A CAN network consists of a number of CAN nodes which are linked via a physical
transmission medium (CAN bus) In practice, the CAN network is usually based on aline
topology with a linear bus to which a number of electronic control units are each connected
via a CAN interface. The passive star topology may be used as an alternative.
The maximum data rate is 1 Mbit/s. A maximum network extension of about 40 meters is
allowed. At the ends of the CAN network, bus termination resistorscontribute to preventing
transient phenomena (reflections). ISO 11898 specifies the maximum number of CAN nodes
as 32.
CAN Node
An ECU that performs its tasks in a CAN network is referred to as a CAN node.
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.
Frame Types
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.
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 andtransmit 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 (re-
synchronization).
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.
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 that each receiver filters
the received CAN messages (acceptance filtering).
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.
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.
CAN Data Protection
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.
Disadvantages
CAN communication protocol came with a lot of boons in the 1980s and changed the
scenario of the automobiles field forever. Afterwards it was implemented in other areas like
medical, security, agriculture etc as well. Although it was a great success, still it had some
limitations too.
• Unfair access: Node with high priority can hog the network
Further, as the demand for higher speed and more data to be sent arose, CAN was found to
be insufficient.
Conclusion
In the decades since the introduction of the CAN bus the fabric of embedded systems in
vehicles has changed profoundly. Arguably the most evident change is quantity: Had there
been some hundreds of signals to be communicated at the time CAN was introduced, today
the numbers are within the five digit range.
Consequently the rise in data traffic led to ever higher bus loads on the CAN buses. Aside
from the rising demand in bandwidth, an increasing need for deterministic system behavior
encouraged the development of new bus systems. So for infotainment purposes the MOST
bus was created with band widths of up to 150 Mbit/s. The deterministic FlexRay bus offers
bandwidths of 10Mbit/s suitable for driver assistance functionality.
CAN's lack of bandwidth often is circumvented by applying a higher number of CAN buses.
But this involves using gateways to transfer data between these buses.
During the part between the arbitration phase and the acknowledgement field of a CAN
frame only one transmitter is allowed. Hence in this part of the frame there is no restriction
on the minimum duration of a bit time. And what would be — so engineers at Bosch thought
— if we increased the transmission rate during this portion of a CAN frame? You only
would need to toggle between two different transmission rates: A slow one at the beginning
and end of a CAN frame and a fast one in the middle. Exactly this is the fundamental idea
of CAN FD.
A faster transmission of a CAN FD frame's payload reduces its transmission time, i.e. the
bus load decreases. On the other hand a longer data field could be transmitted in the same
time, i.e. with only a single CAN FD frame.
Introducing CAN FD would result in a number of advantages for the development process: