CAN Bus Protocol: The Ultimate Guide (2022)
CAN Bus stands for Controller Area Network and consists of two electrical wires called CAN_Low and CAN_High. The information within each vehicle is being transmitted from and to ECUs. In addition, CAN Bus is built to handle robust performance within harsh environments.
We have prepared a simple introduction to CAN Bus. Several topics have been covered, in order to give you the best explanation of the (CAN Bus) protocol.
While working on the article, we combined the knowledge from our top experts within the company, as well as other team members, who do not have the expertise.
Why? The idea was to write a professional but simple introduction to CAN Bus for everyone, no matter how much experience you have.
In conclusion, no matter if you don’t have any knowledge about CAN bus whatsoever or you are already a pro. The simple intro to CAN bus will give you all the information needed.
What is CAN Bus?
CAN Bus is a set of two electrical wires in the car network (CAN_Low and CAN_High), where the information is being sent to and from ECUs. The network that allows ECUs to communicate is called Controller Area Network (CAN).
The CAN bus is a serial communication bus, designed for robust performance within harsh environments, primarily in industrial and automotive applications.
It is basically a vehicle bus standard that allows microcontrollers and devices to communicate with each other.
CAN bus is one of the protocols used in the On-Board Diagnostics (OBD). OBD-2 is nowadays mandatory in all cars and light trucks all around the globe.
CAN bus easily explained
Now, let’s try to look at it from a totally different point of perspective.
Imagine that your car is like a human body and the nervous system
in the human body is the Controller Area Network (CAN bus) in the car, which also enables the
Nodes or electronic control units (ECUs) are something like body parts that are interconnected through the CAN bus. Information can be easily shared between parties. That is much easier to understand, isn’t it?
CAN Bus system
Depending on the type of the car, it can have up to 70 ECUs (electronic control units) and each of them needs to be shared with other parts of the network.
Think about ECUs as specific people. One ECU can formulate and transmit the information via CAN bus to other ECUs that accept the data. After that, they will check the data and decide if they want to receive it or ignore it.
The CAN bus uses two wires for communication - CAN low and CAN high (CAN L and CAN H). ISO 11898-2 describes the physical layer of the CAN bus and ISO 11898-1 describes the data link layer.
The physical layer represents types of cables, node requirements, electrical signal levels, cable impedance and so on.
On the other side, ISO 11898-2 represents things such as baud rate, cable length and termination.
Cable lengths should be 40 meters (1 Mbit/s) or 500 meters (125 kbit/s).
The CAN bus has to be terminated using a 120 Ohms CAN bus resistor at the end of each bus.
CAN nodes have to be connected through two wire bus with baud rates upto 1 Mbit/s (CAN) or 5 Mbit/s (CAN FD).
5 Benefits of CAN Bus
CAN bus standard is commonly used in all vehicles due to its key benefits, such as
Speed - Currently defined by two physical layers - High Speed CAN and Low Speed CAN, both with its own advantages and disadvantages.
Efficiency - High priority data will get prioritized by ID, in order to get immediate bus access - not interrupting other frames
Low-cost - When the CAN protocol was created, its purpose was to enable fast communication between electronic devices and modules, while reducing errors, weight, wiring and costs.
Robustness - CAN bus standard is ideal for safety applications such as vehicles due to its durability and reliability. There are also 5 mechanisms to detect errors in the CAN protocol such as bit stuffing, bit monitoring, frame check, acknowledgment check and cyclic redundancy check.
Flexibility - CAN bus protocol is well-known as a message-based protocol, meaning nodes can easily be added or removed without performing any updates on the system. This makes it really easy for engineers to integrate new electronic devices without significant programming and modify it to your requirements.
CAN Bus Wiring
One of the best advantages of CAN bus is the reduced amount of wiring in combination with an ingenious prevention of message collision.
In other words, no data will be lost during message transmission.
Two examples below show how the CAN bus protocol seems like with CAN bus and how it would look like without the CAN system.
There are several different types of networks. You can find an easy explanation below.
High speed CAN bus (ISO 11898)
Supports bit rates between 40 kbit/s and 1 Mbit/s
Most commonly used these days
Basis for higher layer protocols such as OBD2, CANopen, j1939 and more.
Low speed CAN bus
Supports bit rates between 40 kbit/s and 125 kbit/s
Allows communication to continue despite the fault in one of the two wires
Also known as a fault tolerant CAN
Each CAN node has own CAN termination
Usually consists of a LIN master, which is acting as a gateway - up to 16 slave nodes
Typically includes vehicle functions such as door functionality or aircondition
Ethernet supports high bandwidth requirements of Advanced Driver Assistance Systems (ADAS), cameras, infotainment systems and so on
Provides much higher data transfer rates than CAN bus
Lacks safety features of CAN and CAN FD
Most likely will be used commonly in the upcoming years within the automotive industry
Typically used in modern high performance vehicles
CAN FD is an extension to the original CAN bus protocol
Released in 2012 by Bosch
Developed to meet the need to increase the data transfer
What is a CAN message frame?
CAN frames are used to communicate over CAN bus. CAN uses the differential signal with two logic states - dominant and recessive.
CAN network uses two CAN messages - standard CAN and extended CAN that are described below.
The image below shows a typical CAN frame with an 11-bit identification, which is the kind used in most automobiles. Except for the larger ID, the expanded 29-bit identifier frame is identical.
The first bit is the start of the frame (SOF), which represents the start of the CAN message. Next one is the 11 bit identifier that organizes the priority of the CAN message. The smaller the identifier is, the higher priority it has.
The Remote Transmission Request (RTR) is typically dominant, but it becomes recessive when nodes are requesting data from each other.
Next one is the identifier extension (IDE) bit, which is dominant when the standard CAN frame is sent - not extended one. The r0 bit is reversed and not currently used.
Next one is the Data Length Code (DLC), which indicates how many bytes of data are in the current message. Another important part is the data itself, where it is the same number of bytes as in DLC bits.
The next one is the cyclic redundancy check (CRC), which is a 16-bit checksum that detects errors and issues in the transmitted data.
In case the message is properly received, the receiving node will overwrite the recessive acknowledge bit (ACK) with a dominant bit. The end of frame (EOF) indicates the end of the CAN message.
It is 7 bits wide and it detects bit stuffing errors. The last part of the CAN message is the interframe space (IFS), which is being used as a time delay.
Extended CAN uses a 29 bit identifier with a couple additional bits. The extended 29 bit identifier (CAN 2.0B) is identical, but has a longer ID and is usually used in the j1939 protocol - heave-duty vehicles. CAN uses two logic states; dominant and recessive.
Dominant - pinpoints that the differential voltage is greater than the minimum threshold. In addition, the dominant state is also achieved by driving a logic ‘0’ onto the bus.
Recessive - pinpoints that the differential voltage is less than the minimum threshold. On the other side, recessive state is achieved by a logic ‘1’.
It also has a substitute remote request (SRR) bit, which comes after 11 bit identifier and acts like a placeholder, in order to keep the same structure as a standard CAN.
The identifier extension (IDE) should be recessive and the extended identifier should follow it accordingly.
The remote transmission request (RTR) comes right after the 18 bit ID. The reverse bit r1 follows the path and the rest of the message stays the same.
CAN Bus data logging
Logging CAN data can be done from several types of vehicles such as cars, heavy duty vehicles, predictive maintenance and machine blackbox.
The data from the car are gathered through the OBD2 port and are usually used to reduce fuel costs, improve car mileage and more.
On the other side, data from the heavy duty vehicles are gathered through j1939 and are usually used to improve safety and reduce costs.
Vehicles and machinery can be also monitored through IoT CAN loggers. That can be done in the cloud to avoid breakdowns. A CAN logger can provide data for disputes or diagnostics. It is also called blackbox.
CAN Bus logging is commonly used in fleet management, due to its effectivity and increased number of opportunities.
A CAN logger is required to record CAN data. This allows you to save timestamped CAN data on an SD card. In some situations, a CAN interface is required to transmit data to a PC, such as when decoding data.
Example: TMU CAN-FD
The TMU CAN-FD allows you to record data from any CAN bus to an 8-32 GB Micro SD Card with ease. Simply attach it to a car or truck to begin loggin, and then code the data using our free managemnet software.
Furthermore, the TMU CAN-FD has WiFi, allowing you to automatically upload data to your own server - as well as upgrade devices over-the-air.
Decoding raw CAN dataRaw CAN data is not easily readable. Therefore we have prepared a guide for you. Check out the guide on how to log raw CAN messages.
The CAN bus supports the basis for communication, but not more than that. The CAN standard protocol doesn’t indicate how to handle message messages greater than 8 bytes, or how to decode the RAW data.
In order to indicate how data is communicated between CAN nodes of a network, a set of standardized protocols come in handy. There are several higher layer protocols such as; OBD2, CANopen, CAN FD and SAE J1939.
OBD2 - OBD has a self-diagnostic capability that mostly mechanics use to analyze car issues and the overall health of the car. OBD2 determines trouble codes (DTCs) and real time data (RPM, speed, etc) that can be recorded through OBD2 loggers.
CANopen - CANopen is typically used in embedded control applications such as industrial automation and is based on a CAN meaning that the CAN bus data logger is also capable to log CANopen data.
CAN FD - CAN FD is a CAN bus with flexible data rate and an extension of the classical CAN data link layer. In comparison with classical CAN protocol, CAN FD increases the payload from 8 to 64 bytes. It also allows a higher data bit rate, depending on the CAN transceiver.
SAE J1939 - J1939 is commonly used in heavy duty vehicles. J1939 parameters such as RPM and speed are analyzed by a suspect parameter number (SPN). Afterwards, they are grouped in parameter groups and classified by a PG number (PGN).
A high speed transfer data rate offers DoIP diagnostics, more precisely approximately 100 times of CAN diagnosis. Read more about what DoIP is here.
History of CAN Bus
Control Area Network (CAN Bus) has a rich history and went through several development stages. The actual development stages within years can be seen below.
Development of CAN Bus goes all the way back to 1983 when Bosch originally invented Control Area Network and it was later codified into ISO 11898-1 standard.
The protocol was later released to the Society of Automotive Engineers (SAE) in 1986.
Intel was the first one to introduce the CAN controller chips in 1987, and Phillips joined Intel shortly after that.
In 1991, Bosch published CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29bit).
CAN Bus as an international standard in ISO 11898, was adopted in 1993.
In 2003, ISO 11898 became a standard series
In 2012, Bosch has released the CAN FD 1.0 - flexible data rate
In 2015, the CAN FD protocol has become standardized in ISO 11898-1
Lastly, the physical CAN layer up to 5Mbit/s has become standardized in ISO 11898-2, in 2016
In the future, CAN bus will still be commonly used, but influenced by major automotive industry trends such as; growth of Internet of Things and connected vehicles, impact of autonomous vehicles, the rise of cloud computing, the need for advanced vehicle functionality and more.
The need of CAN FD increases and many experts assume it will slowly replace the classical CAN bus protocol. Stay updated to see what happens.