Welcome to our deep dive into the CAN bus protocol. With over 70% of modern vehicles relying on this system for communication, understanding its characteristics is more crucial than ever. Join us as we unravel its complexities.
It does not matter if you have no knowledge about the CAN bus protocol or if you are already a pro. This simple CAN bus guide intro, will give you all the information needed. Several topics have been covered, to give you the best explanation of the CAN protocol.
With competitive price and timely delivery, sonnepower sincerely hope to be your supplier and partner.
While working on the article, we combined the knowledge from our top experts within the company, as well as non-expertise team members.
Why? The idea was to write a professional but simple guide introduction to the CAN bus for everyone, no matter how much experience you have.
CAN bus is a set of two electrical wires in the car network (CAN_Low and CAN_High), where the information is sent to and from ECUs. The network that allows Electronics Control Units (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 a vehicle bus standard that allows microcontrollers and devices to communicate with each other.
CAN bus is one of the protocols used in On-Board Diagnostics (OBD). Nowadays, the OBD-II is mandatory in all newer cars and light trucks all around the globe.
Let's try to look at the CAN bus system from a different point of perspective.
Picture a car as the human body; just as our nervous system facilitates communication within us, the Controller Area Network (CAN Bus) does the same for the car.
Nodes or ECUs acts similarly like body parts, interconnected via the CAN bus. Just as body parts communicate easily, these components share information effortlessly. Simplifies things, doesn't it?
CAN Bus is an amazing and complicated technology, here's a overview of the whole system and how you can log and decode CAN data with the AutoPi Device.
Check out the Infographics here.
In various cars, there can be as many as 80 ECUs, each requiring communication with other network segments.
Imagine ECUs as specific characters in a play. One ECU can craft a message and convey it via the CAN bus to its fellow actors (other ECUs). Much like a receiver deciding to respond to a letter or discard it, these ECUs evaluate the information and choose either to act on it or disregard it.
The CAN bus uses two communication wires known as CAN low (CANL) and CAN high (CANH). These standards governing the CAN bus are outlined in ISO 11898. While ISO 11898-1 covers the data link layer, ISO 11898-2 defines the physical layer.
ISO 11898-1 (Data Link Layer):
Addresses the communication protocol and its mechanisms.
Defines message framing, arbitration, error handling, and more.
Focuses on how data is transmitted and received within the network.
ISO 11898-2 (Physical Layer):
Describes cable types, node requirements, and electrical signal levels.
Specifies cable lengths: 40 meters for 1 Mbit/s and 500 meters for 125 kbit/s.
Outlines factors like cable impedance, baud rate, and necessary terminations.
Termination: Every CAN bus must be properly concluded with a 120 Ohms resistor at each bus end.
CAN Nodes Connection: Linked via a two-wire bus system with baud rates of up to 1 Mbit/s for standard CAN and 5 Mbit/s for CAN FD.
In our previous discussions, we've touched upon various aspects of the CAN Bus system, a critical technology in modern automotive and industrial communications. Let's delve deeper into the key components that form the core of a CAN Bus system, ensuring its efficient and reliable operation.
Electronic Control Units (ECUs): ECUs are the 'brains' of the CAN Bus, controlling specific functions like engine management or airbag deployment in vehicles. They process and act on the information received via the CAN Bus.
CAN Controller: This component acts as a bridge between the ECUs and the CAN network. It manages the sending and receiving of data packets, ensuring messages are correctly formatted and transmitted.
CAN Transceiver: Working alongside the CAN Controller, the CAN Transceiver converts digital data into signals for transmission over the network and vice versa. This is essential for the communication across the network's nodes.
Bus Lines (CAN_H and CAN_L Wires): The physical wires of the network, CAN_H and CAN_L, are the backbone of the CAN Bus system. They transmit signals between nodes, even in environments with significant electrical noise.
Together, these components ensure the efficient and reliable operation of the CAN Bus system in various settings, from automotive to industrial applications.
The CAN bus protocol is a key communication system used in cars and industry. It helps parts of a vehicle talk to each other smoothly. When CAN bus was created, its goal was to make wiring simpler and electronics less complicated.
Many vehicles now use the CAN bus system because of its clear benefits, such as:
Durability:
The CAN bus standard is designed for important uses, especially in vehicles, thanks to its strength and trustworthiness. It also has five methods to detect and correct errors; bit stuffing, bit monitoring, frame check, acknowledgment check, and cyclic redundancy check.
Cost-Effective:
CAN bus protocol was developed to support quick communication between devices, all while reducing errors and cutting down on unnecessary wires and costs.
Speed Varieties:
It offers two types: High-Speed CAN and Low-Speed CAN, each tailored for specific needs.
Adaptable Design:
The CAN bus protocol setup is message-based, allowing parts to be added or taken away without a total system overhaul. This design lets engineers introduce new gadgets with minimal adjustments.
Efficient Data Handling:
Urgent information is identified and processed immediately, ensuring smooth operations without interruptions.
One key benefit of the CAN bus is its ability to minimize wiring while smartly avoiding message clashes.
Simply put, it ensures no data goes missing when sent.
In the example below, we are comparing two scenarios - one with the CAN bus and one without - which highlights the difference.
With the CAN bus, communication between nodes is streamlined and straightforward. Without it, nodes struggle to effectively communicate.
There are various network types, especially in areas like CAN bus wiring. For a clearer understanding of these nuances, keep reading below.
High-speed CAN bus (ISO 11898)
Supports bit rates between 40 kbit/s and 1 Mbit/s.
Simple cabling.
Most commonly used these days.
The 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 its own CAN termination.
LIN bus
Low-cost supplement.
Less harness.
Cheaper nodes.
Usually consists of a LIN bus master, which is acting as a gateway - up to 16 slave nodes.
Typically includes vehicle functions such as door functionality or air conditioning.
Automotive Ethernet
Ethernet supports high bandwidth requirements of Advanced Driver Assistance Systems (ADAS), cameras, infotainment systems, and so on.
Provides much higher data transfer rates than the CAN bus.
Lacks safety features of CAN and CAN FD.
Most likely will be used commonly in the upcoming years within the automotive industry.
CAN FD
Typically used in modern high-performance vehicles.
CAN FD is an extension of the original CAN bus protocol.
Released in 2012 by Bosch.
Developed to meet the need to increase data transfer.
Are You Maximizing Your CAN Bus Communication's Potential?
Discover Unmatched Efficiency with Our Telematics Device - Try It Now and Elevate Your Performance!
Review Our Prices Learn MoreCAN frames plays an important role in CAN communication across the CAN bus. This communication method uses a differential signal, defined by two logic states: dominant and recessive.
Within CAN communication, there are two distinct message types: standard CAN and extended CAN, which we will delve into below.
The following illustration depicts a prevalent CAN frame with an 11-bit identifier, the kind predominantly found in vehicles. Expect for its extended ID, the 29-bit identifier frame remains consistent with standard CAN communication practices.
Here is a breakdown of the different fields in the Standard CAN Frame:
SOF (Start of Frame):
Length: 1 bit
Purpose: Indicates the beginning of a CAN frame. It is always dominant bit (0 in CAN).
Are you interested in learning more about what is can bus systems in vehicles? Contact us today to secure an expert consultation!
ID (Identifier):
Length: 11 bits
Purpose: Represents the priority and the address of the transmitting node. In CAN, the lower the identifier value, the higher the priority.
RTR (Remote Transmission Request):
Length: 1 bit
Purpose: Used to differentiate a data frame from a remote request frame (RTR = 0 for data frames and RTR = 1 for remote request frames).
Control
Length: 6 bits
Purpose: Contains control information like the data length code (DLC) which indicates the number of bytes in the data field.
Data:
Length: 0 to 64 bits (0 to 8 bytes)
Purpose: Contains the actual data being transmitted. Its length is determined by the DLC in the control field.
CRC (Cyclic Redundancy Check):
Length: 16 bits
Purpose: A polynomial code used to detect errors during data transmission. The transmitting node computers a CRC value based on the frame content and sends it along with the frame. The receiving node then calculates its own CRC from the received frame and compares it to the received CRC. If they match, it's assumed that the frame was received correctly.
ACK (Acknowledgement):
Length: 2 bits (one for the slot and one for the delimiter)
Purpose: The ACK slot is overwritten with a dominant bit by nodes that correctly receive the frame. If the transmitting node sees a dominant bit in the ACK slot, it knows that at least one other node on the network received its frame correctly. Following, there is an ACK delimiter bit, which is always recessive (1 in CAN).
EOF (End of Frame):
Length: 7 bits
Purpose: Marks the end of a CAN frame. It consist of 7 consecutive recessive bits, ensuring that there's enough separation between consecutive frames.
In addition to the fields described above, actual CAN communication also involves some other fields and error handling mechanisms not depicted in this standard CAN frame. These include:
Interframe Space: A time interval between two consecutive frames.
Error Frames: If a node detects an error in a frame, it will transmit an error frame to notify other nodes of the error.
Overload Frames: Used to introduce a delay between consecutive data or remote transmit frames.
The extended CAN frame uses a 29-bit identifier with a couple of 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 - heavy-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, the recessive state is achieved by a logic ‘1’.
It also has a substitute remote request (SRR) bit, which comes after an 11-bit identifier and acts like a placeholder, to keep the same structure as a standard CAN frame.
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.
Are You Ready for the Adventure of Real-Time CAN Bus Access?
Explore New Frontiers in Vehicle Data and Optimize Diagnostics with Our Cutting-Edge Tool Today.
Explore AutoPi CM4 Shop DeviceLogging CAN data can be done from several types of vehicles such as cars, heavy-duty vehicles, predictive maintenance, and machine black box.
The vehicle data 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 heavy-duty vehicles are gathered through j1939 and are usually used to improve safety and reduce costs.
Vehicles and machinery can also be 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 a black box.
CAN bus logging is commonly used in fleet management, due to its effectiveness 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 CM4
The TMU CM4 allows you to record data from any CAN bus to an 8-32 GB Micro SD Card with ease. Simply plug it to the OBD-II port within a car or truck to begin logging, and then interpret the data using AutoPi Cloud.
Furthermore, the TMU CM4 has Wi-Fi, allowing you to automatically upload data to your own server - as well as upgrade devices over the air.
Raw 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 protocol doesn’t indicate how to handle messages greater than 8 bytes, or how to decode the RAW data.
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.
A high-speed transfer data rate offers DoIP diagnostics, more precisely approximately 100 times of CAN diagnosis.
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 the CAN bus goes back to 1983 when Bosch originally invented Control Area Network which was later codified into ISO 11898-1 standard.
The CAN 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; the growth of the Internet of Things and connected vehicles, the impact of autonomous vehicles, the rise of cloud computing, the need for advanced vehicle functionality, and more.
The need for CAN FD increases and many experts assume it will slowly replace the classical CAN bus protocol. Stay updated to see what happens.
Embark on a Journey of Discovery and Unveil Secrets Admired by Thousands.
Why Not Uncover the Secrets of Vehicle Data Today?
Are You Ready to Explore?