This comprehensive guide on the CAN protocol provides a detailed overview of its features, applications, and implementation. The CAN protocol is a serial communication protocol that allows microcontrollers to communicate with each other. CAN functions as a multi-master message broadcast system. It is a peer-to-peer network, meaning all ECUs have equal rights to send messages over the CAN bus.
Table of Contents
First things first: What is an ECU?
An electronic control unit (ECU) is an embedded device inside a vehicle that controls a specific feature. Common examples of ECUs include the Engine Control Module (ECM), Transmission Control Module (TCM), Powertrain Control Module (PCM), Anti-lock Braking System (ABS), and Body Control Module (BCM), among others. These electronic devices control the vehicle’s mechanical movable parts through software code running inside them. Modern cars can contain more than 100 ECUs.
These ECUs communicate with each other continuously over in-vehicle networks like CAN, CAN-FD, LIN, Ethernet, FlexRay, and MOST. The automotive industry most commonly uses CAN as the in-vehicle network in modern vehicles.
Introduction to CAN TP
The CAN TP (transport protocol) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other without needing a host computer. Developed by Bosch in the 1980s, CAN is primarily used in automotive applications but has expanded into various other sectors due to its reliability and efficiency.
What is CAN protocol?
CAN is short for ‘controller area network’. CAN is an in-vehicle bus network that allows microcontrollers and ECUs to communicate with each other. The ISO 11898 standards define how CAN communication works, how to configure the wiring, and how to construct CAN messages. CAN is designed to handle high levels of electromagnetic interference and can provide reliable communication even in challenging environments.
CAN is a peer-to-peer network, i.e. all the ECUs have equal rights to send messages on the bus. The CAN Identifier sets the priority of the messages. The message with the lowest identifier has the highest priority and will be sent first. If 2 ECUs start transmitting simultaneously, the priority of the CAN-ID decides which ECU is permitted to send its message. This process, called bit-by-bit Arbitration, follows the CSMA/CA protocol. The maximum speed of a CAN bus is 1 Mbit/sec according to the standard; however, this varies based on the CAN configuration used.
The CAN protocol has different configurations according to the wiring and voltage levels: high-speed CAN, Low-Speed CAN, and Single-Wire CAN (SWC). However, high-speed CAN is generally used and is called just CAN.
Implementing CAN TP
Hardware Requirements
To implement the CAN protocol, you need the following hardware components:
- Microcontroller with CAN Controller: Many modern microcontrollers have built-in CAN controllers.
- CAN Transceiver: Converts the digital signals from the CAN controller to differential signals required for the CAN bus.
- CAN Bus: A two-wire bus (CAN_H and CAN_L) that connects all nodes in the network.
Software Implementation
Implementing CAN communication involves configuring the CAN controller, setting up message filters, and handling the transmission and reception of messages. Many microcontroller manufacturers provide libraries and APIs to simplify the implementation process.
Here is a block diagram of ECU with CAN controller:
Acceptance Filter: Decides whether a message is relevant for an ECU.
CAN core Block: Implements the CAN protocol.
Interface Management Logic: Creates an interface with the microcontroller.
Transmit Block: Stores complete CAN messages (standard or extended).
Receive FIFO: Can store up to 32 CAN messages. Depending on the filter setting, the system either transfers the received messages to the Receive FIFO or not.
Key Features of CAN Protocol
- Multi-Master Architecture: CAN supports multi-master nodes architecture. This allows any node to initiate the communication.
- Message-Oriented: Communication is based on messages rather than addresses, which enhances the flexibility of the network.
- Error Detection and Fault Confinement: CAN includes sophisticated error detection mechanisms and can isolate faulty nodes to maintain network integrity.
- High-Speed Communication: CAN can support communication speeds of up to 1 Mbits/s (Classical CAN) and even higher in newer versions like CAN FD (upto 8 Mbits/sec).
CAN TP physical layers
The CAN TP physical layer defines the hardware and electrical characteristics of the CAN protocol, specifying how data is transmitted over the CAN physical medium, typically a twisted pair of copper wiring. It includes specifications for voltage levels, signalling rates, wiring topology, and termination, ensuring reliable communication between different nodes in a CAN network.
There are several different physical layers:
High-Speed CAN
The most common type of CAN physical medium is High-Speed CAN, defined by the CAN standard ISO 11898-2.
High-speed CAN is a parallel, twisted, shielded, or un-shielded pair of wires with differential voltage. It has a baud rate of up to 500 bits/sec. The two CAN wires are CAN_H (CAN_High) and CAN_L (CAN_Low). The maximum length of the stub must not exceed 30 cm for 500 bits/sec speed. For more extended wiring, a ground is included.
A high-speed CAN has to be terminated using 120 Ohm terminating resistors on both ends of the bus. This is to supply characteristic line impedance. CAN_H and CAN_L have differential voltage levels. The recessive level is 2.5 V on both CAN_H and CAN_L. Meanwhile, the dominant level is 3.5V for CAN_H and 1.5V for CAN_L. The differential Signal is Vdiff = CAN_H – CAN_L.
Gateways can connect ECUs in a system with both High-Speed CAN and Low-Speed CAN networks.
Low-Speed CAN
The ISO standard ISO 11898-3 defines another two-wire CAN physical medium for lower bus speeds: low-speed CAN.
Low-speed CAN has a maximum baud rate of 125 Kbits/sec. The standard ISO 11898-3:2006 (low-speed, fault-tolerant (LSFT) medium-dependent interface) specifies a data rate between 40 kbit/sec and 125 bits/sec.
Unlike High-speed CAN, there is no termination on both ends of the bus in low-speed CAN. The low-speed CAN has to be terminated separately at every node. Different voltage levels on low-speed CAN are:
0.2V and 3.6V for CAN_H
1.8V and 4.8V for CAN_L
The main difference between High-Speed CAN and Low-Speed CAN is not the data rate but the voltage levels. Because of the low data rate in combination with high voltage range, low speed CAN can operate despite the following malfunctions:
- Interruption of CAN_H and CAN_L.
- Shortcut between CAN_H or CAN_L and battery voltage.
- Shortcut between CAN_H or CAN_L and ground.
- Shortcut between CAN_H and CAN_L.
Single Wire CAN
Single-wire CAN (SWC), defined by SAE J2411, consists of an unshielded single wire as a physical connection between CAN nodes, with a voltage level related to the ground between 0V and 4.1V.
General Motors developed Single Wire CAN (SWC) as an alternative to SAE J1850, also called GMLAN. GMLAN is primarily used in comfort electronics, such as central locking systems and power windows. The SWC transceiver connects directly to the battery voltage, with termination on every transceiver.
In SWC, the data rate in normal mode for onboard communication is 33.33 bits/sec. The data rate in high-speed mode for diagnostic communication is 83.33 bits/sec. The maximum number of nodes in a network is 32. SWC has a selective sleep mode.
History of CAN protocol development
The CAN protocol was developed by Bosch in the early 1980s to address the growing complexity of in-vehicle communication systems. Its development started in 1983 and was released in 1986 at the Society of Automotive Engineers (S.A.E.) conference in Detroit, Michigan.
After its introduction in 1986 CAN quickly gained traction for its robustness and efficiency. By 1991, the first production vehicles using CAN were released, setting a new standard for automotive communication.
CAN was developed because of the rising need for serial bus communication in vehicles to add new functionalities and to reduce the wiring harnesses. Over the years, CAN has evolved with enhancements like CAN FD and CAN-XL to meet increasing data throughput demands.
CAN protocol ISO Standard
The CAN communication ISO standard is ISO-11898: 2003. Several standards define the CAN protocol and its implementation:
- ISO 11898-1: Specifies the data link layer and physical signaling of the CAN protocol.
- ISO 11898-2: Defines the high-speed physical layer for CAN.
- ISO 11898-3: Specifies the low-speed, fault-tolerant physical layer.
- ISO 11898-4: Defines the time-triggered communication in CAN.
How CAN protocol works?
CAN is a message-based protocol that digitally transmits data via twisted pairs of copper wires with differential voltage. The CAN protocol operates on a message-based principle, where each message is assigned a unique identifier. This identifier determines the priority of the message, with lower values indicating higher priority. Information is sent via these fixed-format messages.
The CAN bus allows multiple nodes to communicate on the same network without any centralized control. Any ECU or node can send messages when the CAN bus is free. Each ECU can have many messages depending on the amount of information it has. A single CAN message can send a maximum of 8 bytes (8*8=64 bits) of data.
CAN message
Each ECU sends information to each other in the form of CAN messages. These messages contain the data. Since the CAN bus is broadcast, all nodes can hear all transmissions. Each CAN message has a unique CAN identifier (CAN-ID), redirecting a CAN message to a specific ECU. A CAN message can carry upto 8 bytes of data.
CAN identifier / CAN Arbitration ID
Each message has a unique Identifier (hexadecimal) called CAN-ID or CAN Arbitration ID. A CAN-ID uniquely identifies a CAN message. There are two types of CAN-IDs, i.e. Standard CAN and Extended CAN frames. A CAN message is structured like this:
Types of CAN messages
There are four types of CAN frames. They are:
1. Data Frame
A data frame is the most common frame in the CAN protocol. It contains data. All regular frames containing data are known as Data frames. A data frame consists of 7 fields.
2. Remote frame
If a node requires data from another node on the network, this can be achieved by sending a Remote Frame. For example – A comfort electronics ECU sends a remote frame to the powertrain ECU to know the state of the transmission gear (i.e. is the car in parking mode?). A remote frame is the same as a data frame, with two significant differences:
- It is explicitly marked as a Remote Frame by setting the RTR bit as recessive (1).
- There is no Data Field in the remote frame.
3. Error frame
If a transmitting or receiving node detects an error, it will send an error frame and cancel the transmission. Error frame consists of an error flag made up of six dominant bits (000000) and an error flag delimiter made up of eight recessive bits (11111111).
Since this bit string violates the bit stuffing rule, all the other nodes also respond by transmitting error flags. After detecting sufficient errors, the node will eventually turn itself off.
There are two types of error flags – Active and Passive. Active error flags consist of 6 dominant bits (000000), and Passive error flags have six recessive bits (111111). The errors are calculated in a counter:
REC stands for Receive Error Counter and TEC is Transmit Error Counter.
When TEC/REC is greater than 255, the Bus is off
Passive error flags are set, when TEC or REC is greater than 127.
And, when TEC/REC < 128, then Active error flags are set
4. Overload frame
A CAN node uses an Overload frame to report an overload. It sends this frame when it receives messages faster than it can process, providing extra time between successive Data or Remote frames. Similar to an Error frame, the Overload frame has two fields as well: an overload flag consisting of six dominant bits (000000) and an Overload Delimiter consisting of eight recessive bits (11111111). Unlike error frames, overload frames do not increment error counters.
Bus Arbitration
Can the CAN Identifier set the priority of the message? The lower the CAN-ID (meaning lower hexadecimal number), the higher the message priority. Therefore, high-priority messages are reserved for safety-critical features like braking, steering, and Airbags. Example: A message with CAN-ID 0x001 has higher priority than one with 0x004 CAN-ID. Now, what is the benefit of high priority? If 2 ECUs start a transmission simultaneously, the message’s priority decides which ECU sends the message first. This process, known as bit-by-bit arbitration, follows the CSMA/CA (Carrier-sense multiple access with collision avoidance) protocol.
Bit-rate or Baud rate of CAN
The CAN bit rate specifies how many bits can be transmitted over a CAN bus in a second. It defines the data rate or speed of the CAN network. CAN max speed is 1 MBits/sec (i.e. 1*1000*1000 bits = 1,000,000 bit = 125,000 Bytes = 125 KByte per sec). This is the max a CAN message can transmit in 1 second.
Error Detection techniques in CAN
CAN uses many ways to detect errors on the bus. There are majorly five techniques to detect a mistake in a CAN frame:
1. Checksum Error (CRC error)
The transmitting ECU’s CAN controller calculates a checksum over all bits of the message and sends a checksum in the CRC field. Each receiving ECU also calculates the checksum and compares it to the transmitter’s checksum. The system detects a CRC error if there is a mismatch.
2. Frame check (Format error)
Transmitting (Tx) and receiving (Rx) ECUs check if the frame format is correct. For example, the system detects a dominant (0) bit in the EOF field, which should contain all recessive bits.
3. Acknowledge (ACK) check
Every receiver ECU that has performed a CRC check successfully overwrites the ACK bit (1) with a dominant bit (0).
4. Bit Monitoring
Every ECU transmitting CAN messages also monitors the CAN bus. Therefore the transmitting ECU also receives its own message. The system detects a bit error if a transmitted bit differs from a received bit.
5. Bit Stuffing and Resynchronization
CAN uses NRZ (No Return to Zero) for bit coding. When the level does not change for more than 5 bits, the transmitter adds a complementary bit to the bit stream. These bits are called stuff bits. They must be extracted from the receiver’s data flow. This process is called bit stuffing.
Further Developments
The CAN protocol continues to evolve, with ongoing developments aimed at enhancing its capabilities and expanding its applications. CAN FD (Controller Area Network with Flexible data rate) was introduced as an extension to the original CAN protocol. The standardization of CAN FD took place with the release of ISO 11898-1:2015, published in 2015. CAN FD is a significant step forward, offering higher data rates and larger data payloads.
Further, CAN in Automation (CiA) developed CAN XL (Controller Area Network extended data-field length). It is an addition to the existing CAN protocol to increase its bandwidth capabilities to over 10 Mbit/s.
Additionally, the integration of CAN with other communication protocols, such as Ethernet, is being explored to meet the increasing demands of modern applications.
The CAN protocol is a versatile and reliable communication standard that has become a cornerstone of automotive and industrial communication systems. Its robustness, flexibility, and real-time capabilities make it an ideal choice for various applications. As technology advances, the CAN protocol will remain a vital communication tool, adapting to new challenges and requirements.