CAN bus: operating principle, advantages and disadvantages

The CAN bus was originally designed by Bosch in the 1980s for automotive applications. It is a multi-master, multi-slave, half-duplex and fault-tolerant protocol that is well suited to the requirements of automotive applications. It is simple, low-cost, reliable and can be used in harsh environments. The CAN bus provides a single entry point for all ECUs in a vehicle, which makes connection and diagnostics easy.

CAN bus data can provide valuable insights into the performance and status of connected devices. However, collecting and processing CAN bus data can be challenging due to high data rates, low bandwidth, and changing network conditions. One possible solution to overcome these challenges is to use MQTT to transmit data from the car to the cloud in a timely manner even under poor network conditions.

“The CAN bus provides a single entry point for all ECUs in the vehicle, which makes connectivity and diagnostics easy.”

A brief history of the CAN bus

The main purpose of the CAN bus is to establish an efficient communication system for automotive applications, especially to reduce the complexity of the vehicle wiring harness.

In 1986, Bosch introduced their original CAN protocol, which quickly gained momentum among car manufacturers due to its reliability and robustness. By 1993, it became an international standard under ISO-11898. To summarize the evolution of the protocol:

• 1991 : Mercedes-Benz becomes one of the first car manufacturers to implement the CAN bus in its W140 S-Class.

• 2004 : Introduction of CAN FD (Flexible Data-rate), offering higher data rates and larger payloads than classic CAN networks.

• 2015 : Adoption of ISO-16845:2015 as the conformance test program for devices implementing the Classical CAN and CAN FD protocols.

Over time, other industries besides automotive applications began to adopt this versatile network protocol. Today, it is used in industrial automation systems (CANopen) and marine electronics (NMEA 2000). Its widespread adoption is mainly due to its ability to operate reliably even in harsh conditions while maintaining low-cost implementation requirements.

How does the CAN bus work?

The CAN bus is a decentralized communication protocol. Its decentralized approach makes it ideal for automotive and industrial system applications where reliability and real-time performance are critical.

In a CAN network, all nodes are connected via twisted pair or fiber optic cables. Each node has its microcontroller responsible for processing incoming messages and sending outgoing messages. Data is broadcast by one node on the shared bus, allowing all other nodes to receive it. The main stages of the communication process are:

1. Arbitration : To prevent conflicts when multiple nodes attempt to transmit at the same time, CAN uses an arbitration process based on message priority. The lower the identifier value of a message, the higher its priority.

2. Error detection : Built-in error detection mechanisms ensure data integrity in the CAN network. These include cyclic redundancy check (CRC), frame check sequence (FCS), and acknowledgement bits from the receiving node.

3. Fault Limitation : If any node detects an error or failure during transmission, it will enter an "error passive" state until normal operation is restored. This prevents erroneous transmissions from affecting the functionality of the entire system.

This combination of features enables the CAN bus to maintain a high level of efficiency while ensuring reliable communication between different components in complex systems such as vehicles or factory automation equipment.

Message structure in the CAN protocol

The message structure in the CAN bus system is critical for efficient communication between devices. The protocol uses a data frame format consisting of multiple fields, including an identifier, a control field, a data field, and an error detection mechanism.

• Identifier: This unique value determines the priority of each message on the network. In the standard 11-bit identifier (CAN 2.0A), up to 2048 different priority levels are available. The extended 29-bit identifier (CAN 2.0B) offers more options, with over a billion different values.

• Data Length Code (DLC) : Located within the control field, this code specifies the number of bytes present in the data field—ranging from zero to eight bytes.

• Data field : Contains the actual information that is transmitted across nodes in byte-sized segments.

• Cyclic Redundancy Check (CRC) : A built-in error detection mechanism that ensures reliable communications by detecting transmission errors and requesting retransmission when necessary.

• Acknowledgement slot : A single bit used by a receiving node to acknowledge successful receipt of a message or to indicate an error that requires retransmission.

• Error Frame : An optional part of CAN messaging that allows a node to signal when it detects a problem with its own transmissions or messages received from other devices on the network.

Types of CAN

The following are the three main types of CAN:

#1: Low-Speed ​​CAN

Low-speed CAN, also known as fault-tolerant or ISO 11898-3, operates at speeds up to 125 kbps. It is designed for less critical systems such as body control modules, door locks, window controls, etc., where data transfer speed is not important. Its main feature is that it continues to operate even if one wire in the bus fails.

#2: High-Speed ​​CAN

High-speed CAN or ISO 11898-2 can reach speeds up to 1 Mbps. This type of network has a faster data transfer rate than low-speed networks, making it suitable for more time-sensitive applications such as engine management systems and electronic braking systems. However, it lacks the fault tolerance found in low-speed networks.

#3: CAN FD (Flexible Data-rate)

CAN

Introduced by Bosch in 2012, FD is an extension of the high-speed network, with higher data rates (up to 5 Mbps) while maintaining backward compatibility with existing high-speed devices. The main advantage of this technology is that it can transmit larger payloads more efficiently than traditional CAN, making it ideal for modern vehicles with increasingly complex electronic systems.

CAN bus: advantages and challenges

advantage

CAN bus data can provide valuable insights into the performance, health, and behavior of a vehicle. Collecting CAN bus data to the cloud is an effective way to unlock the potential of vehicle data through big data analytics.

By applying machine learning, artificial intelligence or other analytical tools to data collected from large numbers of vehicles, automakers can gain valuable insights and use them to optimize vehicle performance.

• Fault detection, troubleshooting, and prediction : By analyzing CAN bus data, any anomalies or erroneous signals from devices and sensors can be identified. This can help diagnose the root cause of the problem and resolve it before it causes more damage or safety issues. Manufacturers can also train machine learning models to predict failures by feeding the collected data into the model.

• Visualize vehicle data : Using the collected data, users can develop a system to display aggregated data on a dashboard, allowing users to filter, sort, and compare different vehicles and metrics. The dashboard also provides alerts and recommendations based on data analysis. The system enables users to gain insight into their performance.

• Vehicle-road coordination : The collected data is calculated together with the road infrastructure data to build a vehicle-road coordination system.

In the era of artificial intelligence, data is the most valuable asset. By collecting data from cars to the cloud and then distributing it to various data infrastructures such as databases and data lakes, users can use the data for almost all types of applications.

challenge

Collecting CAN bus data locally on the vehicle is well established. However, collecting and processing CAN bus data and transmitting insights to the cloud in real time can be challenging due to high data rates, low bandwidth, and changing network conditions. Therefore, it is impractical to transmit all CAN bus data to the cloud for processing. Instead, CAN bus data can be collected and processed locally on the edge side to reduce the amount of data and transmit insights to the cloud in real time.

You need at least two components to build such a solution:

1. Edge computing engine : The edge computing engine can collect only the required CAN bus signals, flexibly process and trigger MQTT transmission actions in real time.

2. Cloud MQTT agent : MQTT agent can help transmit the processed CAN bus data to the cloud in real time.