EXPLANAION ON CAN PROTOCOL

Hi, I'm Rakshith M working as a junior software engineer at luxoft India. In this article I made my best effort to provide some of the aspects in EXPLANAION ON CAN PROTOCOL and this is one of my interests

Introduction
The CAN was developed by Robert Bosch. The role of CAN protocol is to exchange data from one ECU to another ECU or send data from one ECU to another ECU. For faster communication between electronic devices and modules and to reduce wiring inside the electronic devices like cars CAN protocol is used.

Agenda
•Replacing wiring complexity in vehicles
•Improving engine performance by providing fuel and engine oil correctly
•By adding automations in vehicles
•By adding safety features in vehicles (crash detection, airbag, ABS)
•Making vehicle more reliable

What is CAN protocol?
CAN is a serial communication technology used especially for reliable data exchange between ECUs in the automobile without using any host ECU.

ECU (electronic control unit)
ECU is a microcontroller unit which consists of 3 major units.
•Microcontroller unit
•CAN controller
•CAN transceiver

•ECUs are connected to each other, and ECU creates a network among them that is called IN “VEHICLE ELECTRONICS NETWORK”.
•ECUs aren’t only used for exchanging data, it is also used for OBD (onboard diagnostics)
•Here the OBD is used to check the car if they have any errors during the service and it is the vehicle self-reporting capability.

Features of CAN protocol
It is a two wired protocol.
•CANH (CAN high)
•CANL (CAN low)
A minimum of 2 ECUs is required to communicate.
•If we connect ECUs within 40m the resistor value is 120 ohms. Here resistor value depends on the distance of the number of ECUs.
•Both wires will send 1 data bit from 1 ECU to another ECU
•CAN protocol uses differential voltage method here differential voltage method means to exchange data between ECUs because it is less sensitive (to cancel noise).
•The CAN wire is twisted inside the car to avoid noise. Line terminating resistors are used to improve the signal quality by avoiding signal reflections on the CAN bus. CAN protocol is Broadcast, Multi-master, half duplex, Asynchronous serial communication protocol where any ECUs writes data frame on the CAN bus it is broadcasted to all other ECUs.
Here is an example: when we press indicator the BCM will write it on CAN bus, and it is broadcasted to all ECUs, so Bosch has organized the receiver has a choice to access or ignore the data frame. To achieve this there is a setting inside receiver ECU we must do “message acceptance setting. “Here all ECUs can transmit and receive data.
The maximum data rate is 1MBPS. The maximum network extension of about 40m is allowed. Decreasing the speed below longer network distance According to ISO 11898 Maximum of 32 nodes we can connect (when we use more than 32 nodes it is recommended that a transceiver with a high bus input impedance)
CAN is available in 2 versions.
•Standard CAN (11-bit identifier and version 2.0A)
•Extended CAN (29-bit identifier and version 2.0B)
To achieve design transparency and implementation flexibility CAN has been subdivided into different types:
•Data link layer (ISO 11898-1)
•Physical layer (ISO 11898-2 or 3)
Here ISO 11898-2 allows data rates up to 125 KBITS (low speed CAN) and ISO 11898-3 allows data rate up to 1MBPS (high speed CAN)
Commonly used topology is line/bus topology (The passive star topology may be used as an alternative), and it is Low-cost lightweight network, Standard CAN protocol supports 8 bytes while CAN FD supports 64 bytes in a data field part, CAN supports remote data request and it supports multi master bus arbitration and it will It will transmit any corrupted messages as soon as the bus is in idle condition, The CAN supports different error detection capabilities such as bit error, ack error, form error, CRC error, stuff error, In CAN if each node becomes winner, it will generate a bit error.

Different types of messages used in CAN protocol
•Data frame: this frame is used to exchange data between the ECUs.
•Remote frame: used to request data frame from the other ECUs.
•Error frame: this frame is generated automatically when any error is detected. Here the node which detects the error will send error frame.
•Overloaded frame: This frame is generated when the node is busy.
For example, if the first two frames can be generated and transmitted by using code and next two frames can be generated and transmitted automatically.

Types of data frame
•Standard data frame
•Extended data frame

Standard data frame:

SOF: start of frame
EOF: end of frame
IFS: inter-frame space
CRC: cyclic redundancy check
Note: In the extended data frame all are same but Arbitration field is 32 bits...

SOF: Idle condition of CAN bus is represented by 1, here no nodes will exchange the data and idle condition represents bus is free. SOF is a single dominant (0) bit. When SOF is detected, all nodes will synchronize with every node. In asynchronous serial communication baud rate of every node must be same

Arbitration field: In CAN arbitration takes place during arbitration field only. In CAN arbitration dominant bit is 0, which node write first 0 that will be the winner and priority of data frame depends on identifier. If the value of identifier is smaller data frame priority is higher.

RTR: if RTR=0 that is data frame and if RTR=1 that is remote frame. When node A and B are sending same identifiers, but A is sending data frame and B is sending remote frame in this case data frame gets higher arbitration.

Data field: This field consists of data to be transmitted in a data frame. Every data byte is transmitted from MSB to LSB.
CRC field: CRC is an error detection method used in CAN protocol.

EOF: EOF field is used to finish the transmission of the data. After writing EOF on bus, bus is considered as idle and EOF is a sequence of 7 recessive bits.

IFS: it is used to provide a small delay between previous frame and next frame, and it is a sequence of three consecutive recessive bits

Bit stuffing:
To ensure enough transitions and to maintain synchronization a bit of opposite polarity is inserted after five consecutive bits of same polarity. Stuffed data frames are destuffed by the receiver.

Conclusion:
CAN is ideally suited in applications requesting many short messages with high reliability is rugged operating environments. Because CAN message based and not address-based it is especially well-suited when data is needed by more than one location and system-wide data consistency is mandatory.