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 ideally 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 the vehicle, which makes connection and diagnostics easy.

CAN bus data can provide valuable insight 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 variable 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 the ECUs in the vehicle, which makes connections and diagnostics easy."

A brief history of the CAN bus

The main purpose of the CAN bus is to create 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 automakers 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 automakers to implement CAN bus in its W140 S-Class.

• 2004 : CAN FD (Flexible Data Rate) is introduced, offering higher data rates and larger payloads than conventional CAN networks.

• 2015 : Adoption of ISO-16845:2015 as conformance test plan for devices implementing Classic 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 reliable operation even under harsh conditions while maintaining low-cost implementation requirements.

How does the CAN bus work?

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 by 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 : In order to prevent collisions when multiple nodes try 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 : The built-in error detection mechanism ensures data integrity in the CAN network. These include Cyclic Redundancy Check (CRC), Frame Check Sequence (FCS), and acknowledgment bits from the receiving node.

3. Failure Limitation : If any node detects an error or failure during transmission, it will enter an "error passive" state until normal operation is resumed. 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 structure of messages in a CAN bus system is crucial for efficient communication between devices. The protocol uses a data frame format consisting of several 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. An extended 29-bit identifier (CAN 2.0B) provides even 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 transferred 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 retransmissions if necessary.

• Ack Slot : A single bit used by a receiving node to acknowledge successful receipt of a message or to indicate an error requiring retransmission.

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

CAN type

Here 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 critical. 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 achieve speeds up to 1 Mbps. This type of network has faster data transfer rates than lower-speed networks and is therefore suitable for more time-sensitive applications, such as engine management systems and electronic braking systems. However, it lacks fault tolerance in low-speed networks.

#3: CAN FD (Flexible Data Rate)

CAN

Introduced by Bosch in 2012, FD is an extension of high-speed networks with higher data rates (up to 5 Mbps) while maintaining backward compatibility with existing high-speed devices. The technology's main advantage is that it can transmit larger payloads more efficiently than conventional 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 a vehicle's performance, health and behavior. Collecting CAN bus data to the cloud is an effective way to unleash 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 the CAN bus data, any abnormal or erroneous signals from devices and sensors can be identified. This can help diagnose the root cause of the problem and fix it before it causes more damage or security issues. Manufacturers can also train machine learning models to predict failures by feeding collected data into the models.

• Visualizing 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 : Calculate the collected data together with 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 any type of application.

Challenges

Collecting CAN bus data locally in 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 variable network conditions. Therefore, it is not practical to transmit all CAN bus data to the cloud for processing.  Instead, CAN bus data can be collected and processed locally at the edge to reduce data volume 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 only collect the required CAN bus signals, flexibly process and trigger MQTT transmission actions in real time.

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