How Does understanding canbus Work?

06 May.,2024

 

Understanding CAN Bus: A Comprehensive Guide - Wevolver

Introduction

Developed by Bosch in the 1980s, the Controller Area Network (CAN) bus is a popular communication protocol used in industrial and automotive applications. It was developed to improve data interchange between Electronic Control Units (ECUs), hence boosting system efficiency in vehicles. In 1993 [1], CAN was incorporated as an international standard communication system,  ISO 11898, in industrial and automobile applications.

sonnepower Product Page

It is a message-based protocol [2], designed originally for multiplex electrical wiring within automobiles to save on copper, but it is also used in many other contexts. For an amateur, the CAN bus may seem confusing or complex, but its core principle is straightforward. 

It is a communication method that allows vehicle systems and devices to communicate with each other, from the car's stereo to its ABS system. The CAN bus is the medium that exchanges instructions amongst the peer ECUs and other devices.

Suggested reading: Autonomous Vehicle Technology Report

Basic Principles of CAN Bus

The Controller Area Network (CAN) bus operates on a principle of decentralized networking, where all nodes (or devices) on the network are equal in their ability to transmit data. This is a departure from traditional networking models where a central master device controls communication. 

CAN Bus Data Transmission

In a CAN network, any node can transmit data when the bus is free. This data is sent in the form of frames which contain the information being transmitted, as well as additional data for error checking and identification.

The CAN bus operates on a "broadcast" principle [3], meaning that all nodes receive all transmissions. Each node then decides whether to ignore the data or accept it based on the identifier in the CAN frame. This identifier is not a source or destination address, but rather a label indicating the content of the message. This means that the same message can be received and processed by multiple nodes, which is particularly useful in automotive applications where multiple systems may need the same data. This also means that a particular node cannot send a message to a specific node based on its address. 

Data transmission in a CAN bus system is based on a differential two-wire interface (replacing complex wiring harnesses and connectors), which enhances noise immunity in the electrically noisy environment of a vehicle. The two wires, CAN-High (CANH) and CAN-Low (CANL), carry complementary signals. When a node transmits a dominant (0) signal, CAN-High goes to a higher voltage level than CAN-Low. Conversely, when a recessive (1) signal is transmitted, both CAN-High and CAN-Low are at the same voltage level [4].

The data is transmitted in frames, which consist of several fields. The most important of these are the identifier field and the data field. The identifier field contains the identifier of the message, which is used by receiving nodes to determine whether to accept the message. The data field contains the actual data being transmitted, which can be up to 8 bytes in standard CAN and up to 64 bytes in CAN FD (Flexible Data rate).

CAN Data Rate Standard Format. Credits: ResearchGate

The significance of each field within the data frame is as follows:

Field NameSize (bits)DescriptionStart of Frame (SOF)
1The Start of Frame bit initiates the frame transmission and signals the beginning of a CAN message. It serves as a synchronization point for the receiving nodes.Identifier (ID)
11 or 29The Identifier field contains a unique message ID, which can be either 11 bits (Standard) or 29 bits (Extended). This ID differentiates between various messages on the CAN bus and helps prioritize their importance.Remote Transmission Request (RTR)
1The Remote Transmission Request bit indicates whether the frame is a data request (0) or a request for data (1). This bit informs receiving nodes whether to expect data or not.Data Length Code (DLC)
4The Data Length Code field specifies the number of data bytes included in the frame. It can range from 0 to 8, allowing for flexibility in the amount of data being transmitted.Identifier Extension (IDE)

1

The Identifier Extension bit differentiates between Standard (0) and Extended (1) frames, indicating the length of the Identifier field. Standard frames use an 11-bit ID, while Extended frames use a 29-bit ID.Data Field (Data)

0-64 bits

The Data Field carries the actual data being transmitted. It can contain between 0 and 64 bits (0 to 8 bytes) of information, making it the primary content of the CAN frame.Cyclic Redundancy Check (CRC)
15The CRC field, or Cyclic Redundancy Check, is a 15-bit value used for error-checking purposes. It helps ensure data integrity during transmission by detecting any errors or corruption in the message.Acknowledgment (ACK)
1The Acknowledgment bit indicates whether the frame was successfully received. It plays a crucial role in confirming the reliable transmission of data between sender and receiver.End of Frame (EOF)
7The End of Frame field marks the conclusion of the CAN frame transmission. It is a sequence of bits used to signal that the message is complete and that the bus is available for the next transmission.

Data transmission in a CAN bus is governed by the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) principle. This means that each node monitors the bus (Carrier Sense) and transmits when the bus is free (Multiple Access). If two nodes transmit at the same time (Collision), the node with the lower identifier value continues transmitting while the other node stops. This is because dominant bits overwrite recessive bits on the bus, and lower identifiers (lower numerical value) have more dominant bits at the start of the CAN frame. This mechanism ensures that the highest priority messages (those with lower identifiers) are transmitted first [4][5].

Error Detection and Handling

One of the key features of the CAN bus system is its efficient error detection and handling capabilities. The system incorporates five methods of error detection, each designed to ensure the integrity of data transmission, as discussed below:

  1. Bit Monitoring: Each transmitting node in the CAN network system monitors the state of the bus while it is transmitting. If the bus state does not match the expected state, the node knows that an error has occurred.
  2. Frame Check Sequence (FCS): This field contains a cyclic redundancy check (CRC) value that is calculated based on the data in the frame. Each receiving node calculates its own CRC value and compares it to the received FCS. If the two values do not match, the node knows that an error has occurred.
  3. Acknowledgment Check: Each frame contains an ACK slot where all other nodes are expected to send a dominant bit to acknowledge receipt of the frame. If the transmitting node does not detect a dominant bit in the ACK slot, it knows that an error has occurred.
  4. Frame Format Check: Each frame has a specific format, including specific locations where dominant and recessive bits are expected. If a node detects a violation of this format, it knows that an error has occurred.
  5. Error Frame: When a node detects an error using any of the above methods, it transmits a special Error Frame that alerts all other nodes to the error. This causes all nodes to discard the current frame and wait for the retransmission of the correct frame.

When an error is detected, the node that detected the error automatically retransmits the frame. This continues until the frame is transmitted without errors. If a node detects too many errors, it goes into an Error Passive state where it only listens to the bus and does not transmit. If errors continue to occur, the node goes into a bus-off state where it is disconnected from the bus. This mechanism ensures that a faulty node does not disrupt communication on the bus.

CAN Bus Architecture

The architecture [6] of a CAN bus system is designed to facilitate efficient communication between multiple nodes. At its most basic, a CAN bus system consists of two lines, CAN-High (or CANH) and CAN-Low (or CANL), connected to all nodes in the system. These lines carry the differential signal that represents the transmitted data.

Fig 2. CAN Bus Architecture. Credits: ResearchGate

Fig 2. CAN Bus Architecture. Credits: Each node in the system has a Transceiver (or CAN transceiver), which interfaces with the bus lines, and a Controller (or CAN controller), which handles the framing of data and error checking. The CAN Transceiver is responsible for converting the digital signal from the CAN Controller into the differential signal on the bus, and vice versa. The Controller, on the other hand, is responsible for creating the frames that contain the data to be transmitted, as well as checking received frames for errors.

Nodes

In a CAN bus system, a node refers to any device that is connected to the bus and is capable of sending and receiving messages. Each node has its own Controller and Transceiver, allowing it to interface with the bus. Nodes can be anything, from simple sensors or actuators to complex devices like Engine Control Units (ECUs).

Each node in a CAN bus system transmits data whenever the bus is free. This data is sent in the form of frames, which contain the data, as well as an identifier that indicates the content of the message. All other nodes on the bus receive this frame and decide whether to accept it, based on the identifier value.

Nodes in a CAN bus system are also responsible for error detection. Each node checks received frames for errors using several methods, including bit monitoring and frame check sequences. If a node detects an error, it transmits an Error Frame that alerts all other nodes to the error. 

Bus Lines

In a CAN bus system, the bus lines are the physical medium through which data is transmitted between nodes. There are two bus lines, CAN-High and CAN-Low, which carry complementary signals. These lines are typically twisted together to form a twisted pair, which helps to reduce electromagnetic interference and improve signal integrity.

The differential signaling used in CAN bus systems provides several advantages, as stated below: 

  1. Common-Mode Noise: It improves noise immunity by ensuring that any noise picked up by the bus lines affects both lines equally. Since the receiving node is only interested in the difference between the voltages on the two lines, this common-mode noise is effectively canceled out. 
  2. Reduced Magnetic Field: The use of complementary signals means that the current flowing in one line is equal and opposite to the current flowing in the other line. This reduces the net magnetic field generated by the current flow, further reducing electromagnetic interference.

The bus lines are terminated at both ends with resistors, typically 120 Ohms, which match the characteristic impedance of the lines. This termination is crucial for preventing signal reflections, which can cause errors in data transmission. In some cases, additional resistors known as biasing resistors may be used to ensure that the bus lines are in a known state when no nodes are transmitting.

The length of the bus lines and the number of nodes connected to them can impact the performance of the CAN bus system. Longer bus lines and more nodes can result in increased capacitance, which can slow down the rise and fall times of the signal. This, in turn, can limit the maximum data rate that can be achieved on the bus. To mitigate this issue, the CAN bus specification defines different data rates and maximum bus lengths, allowing system designers to choose the appropriate combination for their specific application.

Suggested Readings: Bus Topology: The Backbone of Simple Network Design

CAN Protocol

The CAN bus is recognized as an international standard for data communication. There are several protocols [7] used in CAN bus communication systems, each with its own set of features and capabilities. These protocols define the rules for data transmission, including frame formats, data rates, and error handling. Understanding the differences between these protocols is essential for selecting the appropriate one for a specific application.

The most widely used CAN bus protocols are CAN 2.0A, CAN 2.0B (also known as classical CAN), and CAN FD (Flexible Datarate). Each of these protocols builds upon the basic principles of the CAN bus system, adding new features and capabilities to meet the evolving needs of automotive and industrial applications.

CAN Protocols 2.0A and 2.0B

Classical CAN i.e. CAN 2.0A and CAN 2.0B are two closely related protocols that differ primarily in the length of their identifier fields. CAN 2.0A, also known as Standard CAN, uses an 11-bit identifier, while CAN 2.0B, or Extended CAN, uses a 29-bit identifier. This difference in identifier length (visible in Fig.1) has several implications for data transmission. Let’s touch on a few basic implications:

  1. Useful in complex systems: The longer identifier in CAN 2.0B allows for a greater number of unique message identifiers, which can be useful in complex systems with many nodes and data types. However, the longer identifier also increases the length of the frame, which can reduce the maximum data rate achievable on the bus.
  2. Finer Prioritisation: The longer identifier in CAN 2.0B provides more opportunities for the prioritization of messages. Since lower identifier values have the highest priority in the CAN bus system, the additional bits in the CAN 2.0B identifier allow for finer control over message priority.
  3. Flexibility: The use of different identifier lengths in CAN 2.0A and CAN 2.0B can impact compatibility between devices. While CAN 2.0B devices can generally communicate with CAN 2.0A devices, the reverse is not always true. This is because the longer identifier in CAN 2.0B frames can cause errors in CAN 2.0A devices that are not designed to handle them.

CAN Protocol FD

Fig 3. CAN-FD Data Frame. Credits: Research Gate

CAN FD (Flexible Data-rate) is a recent addition to the family of CAN bus protocols (2012), designed to address some of the limitations of CAN 2.0A and CAN 2.0B. The primary advantage of CAN FD is its ability to support higher data rates and larger data payloads, making it well-suited for modern automotive and industrial applications that require faster communication and more data throughput.

CAN FD achieves these improvements by introducing two key changes to the CAN bus protocol: 

  1. Variable Data Rates: It allows for variable data rates during the transmission of a single frame. This means that the arbitration phase, where nodes compete for access to the bus, can occur at a lower data rate to ensure robust communication, while the data payload is transmitted at a higher data rate to improve throughput. This is particularly useful in electrically noisy environments, where a lower data rate can provide better noise immunity.
  2. Flexible Data Field Size: CAN FD increases the maximum size of the data field in a frame from 8 bytes in CAN 2.0 to 64 bytes. This larger data payload allows for more efficient transmission of data, as fewer frames are needed to transmit the same amount of information. This can be especially beneficial in applications where large amounts of data need to be transmitted quickly, such as high-resolution sensor data or software updates.
  3. Backward Compatibility: Despite these improvements, CAN FD maintains backward compatibility with CAN 2.0A and CAN 2.0B devices. This is achieved by using the same frame format as CAN 2.0B, with the addition of a new control field that indicates whether the frame is a CAN FD frame or a standard CAN 2.0B frame. This allows CAN FD devices to coexist with CAN 2.0A and CAN 2.0B devices on the same bus, although the higher data rates and larger data payloads of CAN FD will only be available when communicating with other CAN FD devices.

Suggested Readings: Modbus RTU: A Comprehensive Guide to Understanding and Implementing the Protocol

Suggested Readings: Understanding Modbus TCP-IP: An In-depth Exploration

CAN Bus Variants

The CAN bus functions at the Physical layer and Data-Link layer, just like RS-485. It is essential to realize that there are two widely used CAN bus specifications. When one hears the term "CAN bus," practically everyone immediately thinks of the ISO 11898-2 standard, also known as high-speed CAN. There are two variations of the CAN protocol, High-Speed CAN and Low-Speed CAN, each is designed to meet particular communication requirements. 

High-speed CAN is intended for uses that need real-time and quick data interchange. The maximum data transfer rate is up to 1 Mbps. Reliable communication is ensured by High-Speed CAN's typical voltage values, which hover around 2.5V for recessive states and 3.5V for dominant states. This is especially important in noisy industrial and automotive situations.

Conversely, a fault-tolerant and low-speed variant of the CAN bus standard is ISO 11898-3 or Low-Speed CAN. It is appropriate for systems with less demanding data transfer rates, a maximum of up to 125 Kbps. Low-Speed CAN utilizes the same voltage levels as High-Speed CAN, which are roughly 2.5V for recessive states and 3.5V for dominant states. Unlike High-Speed CAN, the resistors here are dispersed over each node as opposed to being used as two termination resistors at the beginning and end of the bus.

Also, a low-speed fault-tolerant CAN can be designed in many different ways, such as a star-shaped bus, a linear bus akin to a high-speed CAN, or several star-shaped buses linked by a linear bus.

CAN Bus in Automotive Applications

The CAN bus has become an integral part of the modern automotive industry due to its efficiency and flexibility. It is used to facilitate communication between various Electronic Control Units (ECUs) and sensors within a vehicle, enabling the seamless integration of numerous subsystems. Some of the key applications of CAN bus in automotive systems include engine control, safety systems, body control, and infotainment systems. By using a common communication protocol, the CAN bus simplifies the wiring and reduces the complexity of the vehicle's electronic architecture, resulting in reduced weight, lower manufacturing costs, and easier diagnostics.

Suggested Readings: What is an Autonomous Vehicle: A Comprehensive Guide to its Engineering Principles and Applications

Engine Control

One of the primary applications of CAN bus in automotive systems is engine control. The Engine Control Module (ECM) is responsible for managing various aspects of the engine's operation such as fuel injection, ignition timing, and emissions control. To perform these tasks, the ECM needs to receive data from various sensors, such as the throttle position sensor, oxygen sensor, and crankshaft position sensor, and send commands to actuators, such as fuel injectors and ignition coils.

The CAN bus plays a crucial role in facilitating this communication between the ECM and other devices. By using a single bus to transmit data between the ECM and the various sensors and actuators, the CAN bus simplifies the wiring and reduces the number of connections required. This not only reduces the weight and complexity of the engine control system but also improves its reliability and maintainability.

Furthermore, the use of the CAN bus allows for real-time monitoring and control of the engine's operation. This enables the ECM to make rapid adjustments to the engine's parameters based on the data received from the sensors, ensuring optimal performance, fuel efficiency, and emissions control. Additionally, the CAN bus communication enables advanced diagnostic capabilities, allowing technicians to quickly identify and resolve issues with the engine control system.

Safety Systems

The CAN bus communication plays a critical role in the various operations of a vehicle's safety systems. These systems rely on the efficient exchange of data between sensors, actuators, and control modules to ensure the safety of the vehicle's occupants and other road users. Some of the key safety systems that utilize the CAN bus include Anti-lock Braking Systems (ABS), Electronic Stability Control (ESC), and Advanced Driver Assistance Systems (ADAS).

The Anti-lock Braking System (ABS) is designed to prevent wheel locking during heavy braking, which otherwise can lead to skidding and loss of control. The ABS control module receives data from wheel speed sensors and uses this information to modulate the braking force applied to each wheel. By using the CAN bus to transmit this data, the ABS control module can quickly and accurately adjust the braking force, ensuring optimal braking performance and vehicle stability.

Electronic Stability Control (ESC) is another safety system that relies on the CAN bus for communication. ESC is designed to detect and correct loss of traction or vehicle skidding by applying selective braking and adjusting engine torque. The ESC control module receives data from various sensors such as the steering angle sensor, yaw rate sensor, and wheel speed sensors, and uses this information to determine the appropriate corrective actions. The CAN bus enables rapid communication between the ESC control module and other devices, allowing the system to respond quickly to changing conditions and maintain vehicle stability.

Advanced Driver Assistance Systems (ADAS) encompass a wide range of safety features such as adaptive cruise control, lane departure warning, and collision avoidance systems. These systems rely on data from various sensors such as cameras, radar, and lidar, to monitor the vehicle's surroundings and provide assistance to the driver. The CAN bus is essential for transmitting this data between the ADAS control module and other devices, enabling real-time decision-making and control of the vehicle's safety systems. 

By facilitating efficient communication between these systems, the CAN bus helps to improve overall vehicle safety and reduce the likelihood of accidents.

CAN Bus in Industrial Applications

In addition to its widespread use in automotive systems, the CAN bus has also found applications in various industrial settings. Its robustness, reliability, and flexibility make it an ideal choice for communication between devices in industrial automation and control systems. Some of the key industrial applications of the CAN bus include machine control, sensor networks, and distributed control systems.

Machine Control

Machine control is a critical aspect of industrial automation where precise coordination between various devices, such as motors, actuators, and sensors, is required to ensure efficient and accurate operation. The CAN bus is well-suited for this purpose, as it enables real-time communication between devices and allows the implementation of complex control algorithms.

In a typical machine control application, a central control module, often referred to as a Programmable Logic Controller (PLC), is responsible for coordinating the operation of various devices. The PLC receives data from sensors, such as position sensors, temperature sensors, and pressure sensors, and uses this information to determine the appropriate actions for the actuators, such as motors, valves, and solenoids.

The CAN bus facilitates the communication between the PLC and the various devices, allowing for rapid exchange of data and real-time control. By using a single bus for communication, the CAN bus simplifies the wiring and reduces the complexity of the machine control system, resulting in lower installation and low-cost maintenance. Additionally, the precise error detection and handling capabilities of the CAN bus ensure reliable communication, even in electrically noisy industrial environments.

The use of the CAN bus in machine control applications also enables advanced features, such as distributed control and remote monitoring. Distributed control allows for the decentralization of control tasks, with each device in the system capable of making decisions based on local data. This can improve the overall performance and flexibility of the system, as well as reduce the load on the central control module. Remote monitoring, on the other hand, enables operators to monitor and control the system from a remote location, improving efficiency and reducing downtime.

Sensor Networks

Sensor networks are an essential component of many industrial applications, providing real-time data on various parameters such as temperature, pressure, flow rate, and position. These networks often consist of multiple sensors distributed throughout a facility, each responsible for monitoring a specific parameter. The data collected by these sensors is then transmitted to a central control system, which uses the information to make decisions and control various processes.

The CAN bus is an ideal communication medium for sensor networks, as it offers several advantages over traditional point-to-point wiring. 

First, the use of a single bus for communication simplifies the wiring and reduces the complexity of the network, resulting in lower installation and low cost maintenance. This is particularly important in large-scale industrial applications, where the number of sensors and the distances between them can be significant.

Second, the robust error detection and handling capabilities of the CAN bus ensure reliable communication between the sensors and the control system. This is crucial in industrial environments, where electrical noise and interference can cause errors in data transmission. The use of differential signaling and error-checking mechanisms in the CAN bus helps to minimize the impact of these issues, ensuring accurate and reliable data transmission.

Finally, the use of the CAN bus in sensor networks enables advanced features, such as distributed processing and remote monitoring. Distributed processing allows each sensor in the network to perform local data processing and decision-making, reducing the load on the central control system and improving the overall performance of the network. Remote monitoring, on the other hand, enables operators to monitor the status of the sensors and the data they are collecting from a remote location, improving efficiency and reducing downtime.

In summary, the CAN bus is a powerful and versatile communication medium that is well-suited for use in sensor networks in industrial applications. Its robustness, efficiency, and flexibility make it an ideal choice for ensuring reliable and accurate data transmission in these demanding environments.

Challenges and Limitations of CAN Bus

While the CAN bus offers numerous advantages in automotive and industrial applications, it is not without challenges and limitations. Some of the key issues that need to be considered when implementing a CAN bus system include data rate limitations, network size constraints, and electromagnetic compatibility.

  1. Data Rate: One of the primary limitations of the CAN bus is its data rate. Although CAN FD has improved data rates compared to CAN 2.0A and CAN 2.0B, it may still not be sufficient for some high-bandwidth applications such as high-resolution video streaming or large-scale data acquisition. In these cases, alternative communication protocols, such as Ethernet or FlexRay, may be more suitable.
  2. Limited Capacity: Another challenge associated with the CAN bus is the constraint on network size. The maximum length of the bus and the number of nodes that can be connected to it are limited by factors such as signal propagation delay, capacitance, and the electrical characteristics of the bus lines. As the number of nodes and the length of the bus increase, the performance of the system may degrade, resulting in reduced data rates and increased latency. To address this issue, system designers may need to consider using multiple interconnected CAN buses or alternative communication architectures.
  3. Electromagnetic compatibility (EMC): EMC is another important consideration when implementing a CAN bus system. The electrical noise generated by other devices in the environment can interfere with communication on the bus, leading to errors and reduced performance. To mitigate this issue, it is essential to follow best practices for EMC design, such as using twisted-pair cabling, proper grounding, and shielding of the bus lines. Additionally, the use of differential signaling in the CAN bus helps to improve noise immunity by canceling out common-mode noise.

Despite these challenges and limitations, the CAN bus remains a popular choice for communication in various industrial applications due to its reliability and flexibility. 

Conclusion

The CAN bus is a powerful and versatile communication protocol that has become an integral part of modern automotive and industrial systems. Its robustness, efficiency, and flexibility make it an ideal choice for facilitating communication between various devices and subsystems. By understanding the basic principles, architecture, and protocols of the CAN bus, as well as its applications in automotive and industrial settings, engineers and system designers can effectively implement and optimize CAN bus systems to meet the requirements of their specific applications.

FAQ

1. What is the CAN bus?

The CAN bus (Controller Area Network) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a host computer. It is widely used in automotive and industrial applications for communication between various electronic control units (ECUs) and sensors.

2. What are the main differences between CAN 2.0A and CAN 2.0B?

The main difference between CAN 2.0A (Standard CAN) and CAN 2.0B (Extended CAN) is the length of their identifier fields. CAN 2.0A uses an 11-bit identifier, while CAN 2.0B uses a 29-bit identifier. This difference affects the number of unique message identifiers, message prioritization, and compatibility between devices.

3. What is CAN FD?

CAN FD (Flexible Data-rate) is a more recent addition to the family of CAN bus protocols, designed to support higher data rates and larger data payloads. It achieves these improvements by introducing variable data rates during the transmission of a single frame and increasing the maximum size of the data field in a frame.

4. How does the CAN bus handle errors?

The CAN bus incorporates several error detection and handling mechanisms, including bit monitoring, frame check sequences, acknowledgment checks, frame format checks, and error frames. These mechanisms ensure the integrity of data transmission and maintain system reliability.

For more understanding canbusinformation, please contact us. We will provide professional answers.

5. What is a LIN bus?

The Controller Area Network (CAN) and Local Interconnect Network (LIN) protocols were both developed for the automotive industry. Later, LIN was added as a low-cost, simple alternative to the high-reliability, high-speed CAN protocol (up to 1 Mbit/s), which was built for the harsh environment of the automotive electrical bus. 

References

[1] https://en.wikipedia.org/wiki/CAN_bus#History 

[2] https://www.cl.cam.ac.uk/research/srg/han/Lambda/webdocs/an713.pdf

[3] https://copperhilltech.com/blog/controller-area-network-can-bus-message-broadcasting/

[4] https://www.engineersgarage.com/can-canopen-applications/

[5] https://www.eecs.umich.edu/courses/eecs461/doc/CAN_notes.pdf

[6] https://en.wikipedia.org/wiki/CAN_bus#Architecture

[7] https://dewesoft.com/blog/what-is-can-bus 

CAN Bus Explained - A Simple Intro [2023]

CAN Bus Explained - A Simple Intro [2023]




What is CAN bus?

Your car is like a human body:

The Controller Area Network (CAN bus) is the nervous system, enabling communication.

In turn, 'nodes' or 'electronic control units' (ECUs) are like parts of the body, interconnected via the CAN bus. Information sensed by one part can be shared with another.

So what is an ECU?

In an automotive CAN bus system, ECUs can e.g. be the engine control unit, airbags, audio system etc. A modern car may have up to 70 ECUs - and each of them may have information that needs to be shared with other parts of the network.




This is where the CAN standard comes in handy:

The CAN bus system enables each ECU to communicate with all other ECUs - without complex dedicated wiring.

Specifically, an ECU can prepare and broadcast information (e.g. sensor data) via the CAN bus (consisting of two wires, CAN low and CAN high). The broadcasted data is accepted by all other ECUs on the CAN network - and each ECU can then check the data and decide whether to receive or ignore it.

CAN bus physical & data link layer (OSI)

In more technical terms, the controller area network is described by a data link layer and physical layer. In the case of high speed CAN, ISO 11898-1 describes the data link layer, while ISO 11898-2 describes the physical layer. The role of CAN is often presented in the 7 layer OSI model as per the illustration.

The CAN bus physical layer defines things like cable types, electrical signal levels, node requirements, cable impedance etc. For example, ISO 11898-2 dictates a number of things, including below:

  • Baud rate: CAN nodes must be connected via a two wire bus with baud rates up to 1 Mbit/s (Classical CAN) or 5 Mbit/s (CAN FD)
  • Cable length: Maximal CAN cable lengths should be between 500 meters (125 kbit/s) and 40 meters (1 Mbit/s)
  • Termination: The CAN bus must be properly terminated using a 120 Ohms CAN bus termination resistor at each end of the bus

In the context of automotive vehicle networks, you'll often encounter a number of different types of network types. Below we provide a very brief outline:

  • High speed CAN bus: The focus of this article is on high speed CAN bus (ISO 11898). It is by far the most popular CAN standard for the physical layer, supporting bit rates from 40 kbit/s to 1 Mbit/s (Classical CAN). It provides simple cabling and is used in practically all automotive applications today. It also serves as the basis for several higher layer protocols such as OBD2, J1939, NMEA 2000, CANopen etc. The second generation of CAN is referred to as CAN FD (CAN with Flexible Data-rate)
  • Low speed CAN bus: This standard enables bit rates from 40 kbit/s to 125 kbit/s and allows the CAN bus commmunication to continue even if there is a fault on one of the two wires - hence it is also referred to as 'fault tolerant CAN'. In this system, each CAN node has it's own CAN termination
  • LIN bus: LIN bus is a lower cost supplement to CAN bus networks, with less harness and cheaper nodes. LIN bus clusters typically consist of a LIN master acting as gateway and up to 16 slave nodes. Typical use cases include e.g. non-critical vehicle functions like aircondition, door functionality etc. - for details see our LIN bus intro or LIN bus data logger article
  • Automotive ethernet: This is increasingly being rolled out in the automotive sector to support the high bandwidth requirements of ADAS (Advanced Driver Assistance Systems), infotainment systems, cameras etc. Automotive ethernet offers much higher data transfer rates vs. CAN bus, but lacks some of the safety/performance features of Classical CAN and CAN FD. Most likely, the coming years will see both automotive ethernet, CAN FD and CAN XL being used in new automotive and industrial development




Top 4 benefits of CAN bus

The CAN bus standard is used in practically all vehicles and many machines due to below key benefits:

Simple & low cost

ECUs communicate via a single CAN system instead of via direct complex analogue signal lines - reducing errors, weight, wiring and costs

Easy access

The CAN bus provides 'one point-of-entry' to communicate with all network ECUs - enabling central diagnostics, data logging and configuration

Extremely robust

The system is robust towards electric disturbances and electromagnetic interference - ideal for safety critical applications (e.g. vehicles)

Efficient

CAN frames are prioritized by ID so that top priority data gets immediate bus access, without causing interruption of other frames or CAN errors





The CAN bus history in short

  • Pre CAN: Car ECUs relied on complex point-to-point wiring
  • 1986: Bosch developed the CAN protocol as a solution
  • 1991: Bosch published CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29 bit)
  • 1993: CAN is adopted as international standard (ISO 11898)
  • 2003: ISO 11898 becomes a standard series
  • 2012: Bosch released the CAN FD 1.0 (flexible data rate)
  • 2015: The CAN FD protocol is standardized (ISO 11898-1)
  • 2016: The physical CAN layer for data-rates up to 5 Mbit/s standardized in ISO 11898-2

Today, CAN is standard in automotives (cars, trucks, buses, tractors, ...), ships, planes, EV batteries, machinery and more.






As vehicle functionality expands, so does the load on the CANbus. To support this, CAN FD (Flexible Data Rate) has been designed as the 'next generation' CAN bus.

Specifically, CAN FD offers three benefits (vs Classical CAN):

  • It enables data rates up to 8 Mbit/s (vs 1 Mbit/s)
  • It allows data payloads of up to 64 bytes (vs 8 bytes)
  • It enables improved security via authentication

In short, CAN FD boosts speed and efficiency - and it is therefore being rolled out in newer vehicles. This will also drive an increasing need for IoT CAN FD data loggers.

"The first cars using CAN FD will appear in 2019/2020 and CAN FD will replace step-by-step Classical CAN"

- CAN in Automation (CiA), "CAN 2020: The Future of CAN Technology"

Learn more



What is a CAN frame?

Communication over the CAN bus is done via CAN frames.

Below is a standard CAN frame with 11 bits identifier (CAN 2.0A), which is the type used in most cars. The extended 29-bit identifier frame (CAN 2.0B) is identical except the longer ID. It is e.g. used in the J1939 protocol for heavy-duty vehicles.

Note that the CAN ID and Data are highlighted - these are important when recording CAN bus data, as we'll see below.




  • SOF: The Start of Frame is a 'dominant 0' to tell the other nodes that a CAN node intends to talk
  • ID: The ID is the frame identifier - lower values have higher priority
  • RTR: The Remote Transmission Request indicates whether a node sends data or requests dedicated data from another node
  • Control: The Control contains the Identifier Extension Bit (IDE) which is a 'dominant 0' for 11-bit. It also contains the 4 bit Data Length Code (DLC) that specifies the length of the data bytes to be transmitted (0 to 8 bytes)
  • Data: The Data contains the data bytes aka payload, which includes CAN signals that can be extracted and decoded for information
  • CRC: The Cyclic Redundancy Check is used to ensure data integrity
  • ACK: The ACK slot indicates if the node has acknowledged and received the data correctly
  • EOF: The EOF marks the end of the CAN frame

The CAN frame has to satisfy a number of properties to be valid. If an erroneous CAN frame is transmitted, CAN nodes will automatically detect this and take action accordingly. This is referred to as CAN bus error handling, in which CAN nodes keep track of their own 'CAN error counters' and change state (active, passive, bus off) depending on their counters. The ability of problematic CAN nodes to transmit data is thus gracefully reduced to avoid further CAN errors and bus jamming. For details, see our intro to CAN bus error handling.







Logging CAN data - example use cases

There are several common use cases for recording CAN bus data frames:

Logging/streaming data from cars

OBD2 data from cars can e.g. be used to reduce fuel costs, improve driving, test prototype parts and insurance

obd2 logging

Heavy duty fleet telematics

J1939 data from trucks, buses, tractors etc. can be used in fleet management to reduce costs or improve safety

j1939 telematics

Predictive maintenance

Vehicles and machinery can be monitored via IoT CAN loggers in the cloud to predict and avoid breakdowns

predictive maintenance

Vehicle/machine blackbox

A CAN logger can serve as a 'blackbox' for vehicles or equipment, providing data for e.g. disputes or diagnostics

can bus blackbox

Do you have a CAN logging use case? Reach out for free sparring!

Contact us



How to log CAN bus data






Example: CANedge CAN logger

The CANedge1 lets you easily record data from any CAN bus to an 8-32 GB SD card. Simply connect it to e.g. a car or truck to start logging - and decode the data via free software/APIs.

Further, the CANedge2 (WiFi) and CANedge3 (3G/4G) let you push data to your own server - and update devices over-the-air.

learn about the CANedge



How to decode raw CAN data to 'physical values'

If you review the raw CAN bus data sample above, you will probably notice something:

Raw CAN bus data is not human-readable.

To interpret it, you need to decode the CAN frames into scaled engineering values aka physical values (km/h, degC, ...).

Below we show step-by-step how this works:


Each CAN frame on the bus contains a number of CAN signals (parameters) within the CAN databytes. For example, a CAN frame with a specific CAN ID may carry data for e.g. 2 CAN signals.

To extract the physical value of a CAN signal, the following information is required:

  • Bit start: Which bit the signal starts at
  • Bit length: The length of the signal in bits
  • Offset: Value to offset the signal value by
  • Scale: Value to multiply the signal value by

To extract a CAN signal, you 'carve out' the relevant bits, take the decimal value and perform a linear scaling:

physical_value = offset + scale * raw_value_decimal


Most often, the CAN bus "decoding rules" are proprietary and not easily available (except to the OEM, i.e. Original Equipment Manufacturer). There are a number of solutions to this when you're not the OEM:

  • Record J1939 data: If you're logging raw data from heavy duty vehicles (trucks, tractors, ...), you're typically recording J1939 data. This is standardized across brands - and you can use our J1939 DBC file to decode data. See also our J1939 data logger intro
  • Record OBD2/UDS data: If you need to log data from cars, you can typically request OBD2/UDS data, which is a standardized protocol across cars. For details see our OBD2 data logger intro and our free OBD2 DBC file
  • Use public DBC files: For cars, online databases exist where others have reverse engineered proprietary some of the CAN data. We keep a list of such databases in our DBC file intro
  • Reverse engineer data: You can also attempt to reverse engineer data yourself by using a CAN bus sniffer, though it can be time consuming and difficult
  • Use sensor modules: In some cases you may need sensor data that is not available on the CAN bus (or which is difficult to reverse engineer). Here, sensor-to-CAN modules like the CANmod series can be used. You can integrate such modules with your CAN bus, or use them as add-ons for your CAN logger to add data such as GNSS/IMU or temperature data
  • Partner with the OEM: In some cases the OEM will provide decoding rules as part of the CAN bus system technical specs. In other cases you may be able to get the information through e.g. a partnership

Note: If you need to load, edit or create new DBC files, check out our free online DBC file editor.


In some cases, conversion rules are standard across manufacturers - e.g. in the J1939 protocol for heavy-duty.

This means that you can use the J1939 parameter conversion rules on practically any heavy-duty vehicle to convert a large share of your data. To make this practical, you need a format for storing the conversion rules. Here, the CAN database (DBC) format is the industry standard - and is supported by most CAN bus decoder software incl. the supporting tools for our CAN loggers like asammdf and our MF4 decoders.

We also offer a low cost J1939 DBC file, which you can purchase as a digital download. With this, you can get quickly from raw J1939 data to human-readable form.

j1939 dbc

To illustrate how you can extract CAN signals from raw CAN data frames, we include below the previous J1939 sample data - but now decoded via a J1939 DBC file using the asammdf GUI tool.

As evident, the result is timeseries data with parameters like oil temperature, engine speed, GPS, fuel rate and speed:

For more on logging J1939 data, see our J1939 data logger and mining telematics articles. You can also learn how to analyze/visualize your CAN data via the free asammdf GUI tool or telematics dashboards.





What is the link between CAN, J1939, OBD2, CANopen, ...?

The Controller Area Network provides the basis for communication - but not a lot more.

For example, the CAN standard does not specify how to handle messages larger than 8 bytes - or how to decode the raw data. Therefore a set of standardized protocols exist to further specify how data is communicated between CAN nodes of a given network.

Some of the most common standards include SAE J1939, OBD2 and CANopen. Further, these higher-layer protocols will increasingly be based on the 'next generation' of CAN, CAN FD (e.g. CANopen FD and J1939-17/22).




In addition to the above, the following CAN based higher layer protocols are relevant:

  • Unified Diagnostic Services (UDS): A communication protocol used in ECUs to enable e.g. diagnostics
  • NMEA 2000: A protocol used in most modern maritime vessels with similarities to J1939
  • CCP/XCP on CAN: These protocols are commonly used in prototype development for ECU measurement/calibration


For more intros, see our guides section - or download the 'Ultimate Guide' PDF.





Need to log/stream CAN bus data?

Get your CAN logger today!

For more information, please visit sonnepowercontrol.com.






Recommended for you