a seminar report on can bus protocol

19
A SEMINAR REPORT ON “CAN BUS PROTOCOL” Submitted by ABHINAW TIWARI Regd. No. 12010330 7 th Semester, B.Tech. (CSE) For the year 2016 Under the esteemed guidance of Dr. Suvasini Panigrahi DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING VEER SURENDRA SAI UNIVERSITY OF TECHNOLOGY BURLA, ODISHA - 768018

Upload: abhinaw-tiwari

Post on 05-Apr-2017

818 views

Category:

Engineering


7 download

TRANSCRIPT

Page 1: A SEMINAR REPORT ON CAN BUS PROTOCOL

A SEMINAR REPORT

ON

“CAN BUS PROTOCOL”

Submitted by

ABHINAW TIWARI

Regd. No. 12010330

7th

Semester, B.Tech. (CSE)

For the year 2016

Under the esteemed guidance of

Dr. Suvasini Panigrahi

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

VEER SURENDRA SAI UNIVERSITY OF TECHNOLOGY

BURLA, ODISHA - 768018

Page 2: A SEMINAR REPORT ON CAN BUS PROTOCOL

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

VEER SURENDRA SAI UNIVERSITY OF TECHNOLOGY

BURLA, ODISHA

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.

This is in partial fulfilment of requirement of Bachelor degree in Computer Science &

Engineering in Veer Surendra Sai University of Technology, Burla.

I wish him success in all his future endeavours.

Dr. Suvasini Panigrahi

Seminar in-charge

Page 3: A SEMINAR REPORT ON CAN BUS PROTOCOL

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

REGD NO. 12010330

7TH

SEMESTER

B.TECH. (CSE)

Page 4: A SEMINAR REPORT ON CAN BUS PROTOCOL

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.

Page 5: A SEMINAR REPORT ON CAN BUS PROTOCOL

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

Page 6: A SEMINAR REPORT ON CAN BUS PROTOCOL

Introduction

Motivation for CAN The more recent history of the automobile is characterized by intensive electronification.

The driving force for this can be traced primarily to continual growth of customer wishes for a

modern automobile. Another factor is globalization, which increases competitive and cost

pressures that result in continual innovative pressure.

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

Page 7: A SEMINAR REPORT ON CAN BUS PROTOCOL

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.

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.

Page 8: A SEMINAR REPORT ON CAN BUS PROTOCOL

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

CAN Communication Principle

CAN network is based on a combination of multi-master architectureand 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.

Page 9: A SEMINAR REPORT ON CAN BUS PROTOCOL

CAN Framing

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

Page 10: A SEMINAR REPORT ON CAN BUS PROTOCOL

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

Page 11: A SEMINAR REPORT ON CAN BUS PROTOCOL

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

CRC and Acknowledgement

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.

Page 12: A SEMINAR REPORT ON CAN BUS PROTOCOL

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.

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.

CAN Bus Access

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.

Page 13: A SEMINAR REPORT ON CAN BUS PROTOCOL

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.

Page 14: A SEMINAR REPORT ON CAN BUS PROTOCOL

CAN Data Protection

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 timerequirements, 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.

Page 15: A SEMINAR REPORT ON CAN BUS PROTOCOL
Page 16: A SEMINAR REPORT ON CAN BUS PROTOCOL

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.

Page 17: A SEMINAR REPORT ON CAN BUS PROTOCOL

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.

Limitations like the following were some of them.

• Unfair access: Node with high priority can hog the network

• Starvation for some particular nodes,

Further, as the demand for higher speed and more data to be sent arose, CAN was found to

be insufficient.

Page 18: A SEMINAR REPORT ON CAN BUS PROTOCOL

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.

Advantages and Consequences 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:

Bus load problems would be reduced dramatically

Using several CAN buses would no longer be necessary

The need for gateways would be reduced if not abolished

Less segmentation of data thanks to larger payloads per frame

A better ratio of payload and overhead data by fewer frames

Page 19: A SEMINAR REPORT ON CAN BUS PROTOCOL

References

1. Virtual Vector Academy: https://elearning.vector.com/vl_index_en.html

2. Slideshare: https://slideshare.net