CAN Protocol

If you have any questions, feel free to leave a comment below, and our team will provide you with high-quality answers that you might not easily find on Google. Whether you’re working on a CAN-based project or need support in your company, don’t hesitate to reach out to us anytime. Let’s get started and make the most of your time.

The figure below illustrates the application of the CAN bus protocol in a vehicle, enhancing sophistication, flexibility, and safety through automation control for humans. There are two CAN networks with high and low-speed baud rates. Another ECU connects these networks of different data rates, communicating through a Gateway ECU.

History of CAN Protocol

• In 1985, Bosch developed CAN, a high-integrity serial bus system, to network intelligent devices and replace automotive point-to-point wiring systems.
• With the widespread adoption of vehicle electronics, the automotive industry replaced heavy, expensive, and bulky complex wire harnesses with CAN.
• In 1993, CAN became the international standard known as ISO 11898.
• Since 1994, several widely used higher-level protocols, such as CANopen and DeviceNet, have been standardized on top of CAN.
• In 1996, the On-Board Diagnostics OBD-II standard which incorporates CAN became mandatory for all cars and light trucks sold in the United States.
• Today markets including surface transportation, industrial automation, maritime, and avionics systems have widely adopted CAN.
• Today CAN is incorporated into many micro-controllers (our Embedded has two CAN ports).

Introduction to CAN Protocol

Initially, electronic devices, nodes, and ECUs in vehicles were connected through point-to-point wiring systems. The Automotive Manufacturers (OEMs) started using more and more ECUs in-vehicle, which resulted in bulky wire harnesses that were heavier and more expensive too which increased the cost of the vehicle. Then ROBOT BOSCH introduced a specialized internal communication network called the vehicle bus that interconnects electronic devices inside the vehicle.

The Vehicle bus reduced the wiring cost, weight, complexity, etc. Now there are several types of network types and protocols used in vehicles by various manufacturers for the interconnection of ECUs in a network. The most common vehicle bus protocols are the CAN, LIN, VAN, IEBUS, FlexRay, MOST, DC-BUS, J1850, ISO 9141-1/-2, and D2B-Domestic Digital Bus.

Among them the various bus protocols are available in the Automotive Industry, the CAN emerged as the standard in-vehicle network due to its energetic features for safety and it became the international standard known as ISO-11898. Bosch originally developed the Controlled Area Network (CAN) communication protocol, which has gained widespread adoption in the automotive industry.

CAN has become the foundation for various higher-level protocols, like CANopen and DeviceNet, which are widely applied in industrial communications. Additionally, CAN is utilized in specific vehicle classes, such as J1939 for commercial vehicles and ISO-11783 for agricultural vehicles.

Applications of CAN Protocol

The main advantages of the CAN as a serial bus lie in the reduction of expensive wiring, as well as an increased performance by enabling a distributed processing system. CAN has been used in the following applications as still now also it is expanding in different applications:

• Passenger Cars.
• Building Automation.
• Trucks and Buses.
• Industrial Machine Control.
• Lifts and Escalators.
• Trains.
• Maritime Electronic Systems.
• Aircraft & Aerospace Electronics.
• Medical Instruments etc.

What is the CAN Protocol?

The Controller Area Network (CAN) protocol serves as a communication protocol in automotive and industrial applications. Specifically designed for microcontrollers and devices, it facilitates communication within a networked environment without requiring a host computer. The CAN protocol is based on a message-based communication model where each device on the network can send and receive messages. It uses a two-wire bus, consisting of a CAN High (CANH) and a CAN Low (CANL) wire, to transmit and receive data between devices. The CAN protocol provides a highly reliable and robust communication system, capable of transmitting data at high speeds over long distances. CAN is widely used in diverse applications, such as engine control, body control, powertrain control, and more.

In conclusion, The Controller Area Network (CAN) is a multi-master, broadcasting, multi-casting, message-based, Event-driven, Configuration Flexible, half-duplex, serial-type asynchronous networking protocol.

Features of CAN protocol

There are distinct features in CAN that set it apart from other protocols, making it widely utilized in various applications.

• Information Routing.
• System flexibility.
• Message Routing.
• Broadcasting.
• Multicasting.
• Data Consistency.
• Bit-rate.
• Priorities.
• Remote data requests.
• Multi-master.
• Arbitration.
• Data integrity.
• Error detection.
• Error Detection performance.
• Error signaling and recovery time.
• Fault confinement.
• Connection.
• Single-channel.
• Bus values.
• Acknowledgment.
• Sleep mode/wake-up.

Information Routing In CAN Protocol

In CAN network systems, a node does not make use of the system configuration means of the node address. In the Controller Area Network (CAN) protocol, information routing relies on a message-based communication model. Each device has a unique identifier to address messages on the bus. When a device sends a message, it includes its identifier and the message data in the message frame. This frame is transmitted on the bus, and all devices on the network receive it.

System Flexibility in CAN Protocol

One of the key advantages of the Controller Area Network (CAN) protocol is its system flexibility. CAN networks offer easy expansion and modification, providing flexibility in system design. Standard hardware and software interfaces enable the addition or removal of devices without impacting overall system performance.

CAN networks can be configured in different topologies, such as star, tree, or linear, depending on the specific application requirements. The use of standard connectors and cables also makes it easy to connect devices to the network and allows for easy integration with existing systems.

Another key aspect of the CAN protocol’s system flexibility is its ability to support multiple data rates. This means that devices on the network can transmit and receive data at different speeds, allowing for greater efficiency and optimization of network performance.

Message Routing In CAN Protocol

In CAN, each message is distinguished by a unique identifier that doesn’t specify the message’s destination but only defines the data’s significance within the message. All connected nodes in the network can decide, through message filtering technology using this message ID, whether to receive the data or not.

In a Controller Area Network (CAN) protocol, message routing refers to the process of transmitting messages between devices on the network. The CAN protocol uses a message-based communication model, where each device on the network has a unique identifier that is used to address messages sent and received on the bus.

When a device sends a message on the network, it includes its identifier and the message data in the message frame. The message frame is then transmitted on the bus, and all devices on the network receive it. Each device on the network then checks the identifier of the message to see if it is the intended recipient of the message. If the device is the intended recipient, it processes the message data, and if not, it ignores the message.

Broadcasting in CAN Protocol

Broadcasting in the CAN Protocol involves sending a message to all nodes on the network, rather than to a specific node or group. CAN messages, transmitted as data frames, include an identifier (ID) and data bytes. When broadcasting, the ID field uses a special value, the “broadcast address” or “global address,” signaling all nodes to receive and process the message.

Broadcasting proves beneficial in specific scenarios, like when a message requires simultaneous delivery to multiple nodes or when a node needs to notify all other nodes on the network of a particular event or status change. However, because broadcasting sends a message to all nodes on the network, it can also result in increased network traffic and potential collisions, which can impact overall network performance.

Multicasting in CAN Protocol

Multicasting in a Controller Area Network (CAN) protocol refers to the ability to transmit messages to multiple devices on the network simultaneously. In a CAN network, multicasting is accomplished using a multicast message—a single transmission sent to multiple devices with distinct node identifiers.

When a device wants to send a multicast message on the CAN network, it includes a special identifier in the message frame that indicates that the message is multicast. The message data is then transmitted on the bus, and all devices on the network receive the message. Each device on the network checks the identifier of the message to see if it matches their node identifier. If the message identifier matches their identifier, the device processes the message data, and if not, it ignores the message.

Multicasting in the CAN protocol provides several advantages in system design and implementation. For example, it allows multiple devices on the network to receive the same data without the need for individual message transmissions, which can reduce network traffic and improve system efficiency. Multicasting facilitates the implementation of intricate systems with multiple devices and sensors. It enables the transmission of data to specific groups of devices on the network.

Data Consistency in CAN Protocol

Data consistency in a CAN network ensures a message is accepted simultaneously either by all nodes or by none. This property is achieved through the concepts of multicast and error handling in the system.

In a Controller Area Network (CAN) protocol, data consistency refers to the accuracy and reliability of the data transmitted and received on the bus. Data consistency is a critical aspect of the CAN protocol, particularly in applications where real-time data transmission and control are essential, such as in the automotive and industrial industries.

Different Mechanisms for Data Consistency in CAN Protocol

The CAN protocol includes several mechanisms to ensure data consistency across the network. One of the most important mechanisms is the cyclic redundancy check (CRC), which is included in each message frame transmitted on the bus. The CRC is a mathematical function that generates a checksum value based on the data in the message frame. When a device receives a message on the bus, it calculates the CRC based on the received data and compares it to the CRC included in the message frame. If the two values match, the data is considered consistent and is processed by the receiving device. If the values do not match, the data is discarded, and an error is reported.

In addition to the CRC, the CAN protocol also includes error detection and correction mechanisms to ensure data consistency. For example, the protocol uses bit stuffing to prevent the occurrence of long sequences of identical bits, which can cause synchronization errors. The protocol also includes mechanisms for detecting and correcting errors in the transmitted data, such as by using ACK and NACK signals to confirm the successful transmission of messages.

Bit-Rate in CAN Protocol

In a Controller Area Network (CAN) protocol, bit-rate refers to the speed at which data is transmitted on the bus. The bit rate is the number of bits that can be transmitted per second and is typically expressed in bits per second (bps).

The bit rate in the CAN protocol is adjustable to meet specific application requirements. While the maximum supported bit rate is 1 Mbps, lower rates are commonly employed in applications where reduced speeds suffice for data transmission needs.

Priorities in CAN Protocol

In a Controller Area Network (CAN) protocol, priorities refer to the relative importance of messages transmitted on the bus. Priorities are used to determine which messages should be transmitted first in cases where multiple messages are waiting to be transmitted.

In the CAN protocol, every message incorporates a priority field determining its relative importance on the bus. Usually, represented as an 11-bit identifier, lower values signify higher priorities. Consequently, messages with lower priority values take precedence over those with higher priority values.

In Conclusion, the message identifier defines a static message priority during the bus access in a CAN network. Mostly each message has a unique Identifier integer value and it is represented in a hexadecimal number system for increasing the reading and programming flexibility for a developer. The OEM should select the message or his ID as to how much priority it is. The highest is the priority, the lowest is the value of that message. 

Remote Data Request in CAN Protocol

Remote Data Request (RTR) is a feature of the Controller Area Network (CAN) protocol that allows a node to request data from another node on the bus without waiting for the other node to initiate communication.

In a CAN network, nodes can transmit data frames to other nodes on the bus. However, in some cases, a node may need to request data from another node that is not currently transmitting data. Instead of waiting for the other node to send the data voluntarily, the requesting node can send a Remote Data Request frame with a specific identifier. When the other node receives the request, it responds with a Data Frame containing the requested data.

Utilizing the RTR feature in a CAN network can diminish data exchange latency and enhance efficiency. It enables nodes to request specific data on-demand, avoiding continuous broadcasting of data that might not be needed by all nodes on the bus.

Multi-Master in CAN Protocol

Multi-master in Controller Area Network (CAN) protocol refers to the ability of multiple nodes (i.e., microcontrollers or other devices) on a CAN bus to act as masters and initiate communication with other nodes. In a multi-master CAN system, any node can act as a master and initiate communication with any other node on the bus without requiring explicit permission or coordination from other nodes.

This is in contrast to a single-master CAN system where only one node, typically a central controller or host, can initiate communication with other nodes. In a single-master system, all other nodes are slaves and can only respond to requests from the master.

Multi-master CAN systems are useful in situations where multiple nodes need to share control of the bus and exchange data with each other without a central controlling node. However, multi-master systems can also be more complex and require additional coordination and arbitration mechanisms to prevent conflicts and ensure reliable communication.

Arbitration in CAN Protocol

Arbitration is a fundamental aspect of the Controller Area Network (CAN) protocol, which is used to manage access to the shared communication bus by multiple nodes on the network.

In a CAN network, each node has the potential to transmit data onto the bus at any time. When two or more nodes attempt to transmit at the same time, a collision occurs, and the data frames become corrupted. To prevent collisions and ensure reliable communication, CAN uses a form of non-destructive arbitration based on the priority of the message.

The arbitration process starts when a node wants to transmit data onto the bus. The node checks if the bus is idle or if any other node is currently transmitting. If the bus is idle, the node immediately begins transmitting its message. If the bus is busy, the node waits until the current message is finished and then begins transmitting its message.

During the arbitration, every transmitter compares the level of the bit transmitted with the level that is monitored on the bus. If these levels are equal the node may continue to the send. When a recessive level is sent, but a dominant level is monitored (discussed in the introduction part), the node has lost arbitration and must withdraw without sending any further bits.

Data Integrity in CAN Protocol

Data integrity refers to the assurance that the data transmitted over a Controller Area Network (CAN) is accurate, complete, and free from errors or corruption.

In a CAN network, data integrity is essential to ensure the correct operation of the system. CAN uses several mechanisms to ensure data integrity, including error detection, error signaling, and error handling.

CAN uses a form of cyclic redundancy check (CRC) to detect errors in the data transmitted over the bus. The transmitting node calculates a CRC value based on the data in the message and includes the CRC value in the message frame. The receiving node also calculates a CRC value based on the received data and compares it with the CRC value included in the message. If the two values align, the message is deemed error-free. In case of a mismatch, the receiving node communicates an error to the entire network.

Upon detecting an error, the node transmits an error message to all other nodes on the network. This message includes details about the detected error type, such as a CRC error or bit error, along with the identifier of the message that triggered the error.

Error Detection in CAN Protocol

To detect errors in a CAN network, the following measures have been taken:

• Monitoring involves each transmitter comparing the detected bit levels on the bus with the transmitted bit levels.
• Cyclic Redundancy Check (CRC).
• Bit-Stuffing.
• Message Frame Check.

Error Detection Performance:

In the CAN network system, the error detection mechanism has the following properties:

Error Detection or Monitoring in CAN Protocol

1. All global errors are detected.
2. All local errors at transmitters are detected.

• CRC Error in CAN Protocol

1. Up to 5 randomly transmitted errors within a sequence can be detected.
2. Burst errors of length less than 15 in a message can be detected.
3. Errors of any odd number of bits in a message can be detected.

The total residual error probability of the undetected corrupted messages is less than 4.7 x 10¹¹.

Error Signalling and Recovery Time in CAN Protocol

Error signaling and recovery time are important aspects of the Controller Area Network (CAN) protocol, which are used to detect and recover from errors in the communication network.

When a CAN network detects an error, the node identifying the error transmits an error message to all other nodes. This message includes details about the error type, like a CRC error or bit error, along with the identifier of the problematic message.

In addition to signaling errors, CAN includes mechanisms for error recovery. Upon detecting an error, the node retries the transmission. If the error persists, it might transition to a different error handling mode, like error passive or bus off, depending on the error’s severity.

The corrupted messages are flagged by any node detecting an error. Such messages are aborted and are retransmitted automatically. The recovery time from detecting an error until the start of the next message is at most 29 bit times, provided there is no further error.

Fault Confinement in CAN Protocol

The CAN nodes are able to distinguish between short disturbances and permanent failures. Defective nodes are switched off is nothing but the Bus-Off mechanism in the CAN network.

Connection in CAN Protocol

The CAN serial communication link is a bus to which a number of the nodes may be connected or disconnected. This number has no theoretical limit. Practically, the total number of nodes will be limited by delay time and/or electrical loads on the bus.

The CAN bus consists of a single bidirectional channel that carries the data bits. From this data, the re-synchronization information can be derived. The way in which this channel is implemented is not fixed in this specification, e.g. single wire (plus ground), two differential wires, optical fibers, etc.

Bus Values in CAN Protocol

The CAN bus can have one of two complementary values dominant or recessive. During the simultaneous transmission of the dominant and recessive bits, the resulting bus value will be dominant. For instance, in a wired-AND implementation on the bus, the dominant level is represented by a logical ‘0,’ and the recessive level by a logical ‘1.’

Acknowledgment in CAN Protocol

All receivers in the CAN network verify the consistency of the received message, acknowledging a consistent message and flagging an inconsistent one.

Sleep/Wake-up Mode in CAN Protocol

To minimize the system’s power consumption, a CAN device can enter sleep mode, ceasing internal activity, and disconnecting the bus drivers. Sleep mode concludes with a wake-up triggered by any bus activity or internal system conditions.

Upon waking up, internal activity restarts. The transfer layer waits for the system’s oscillator to stabilize and synchronize itself to bus activity (checking for eleven consecutive recessive bits) before setting the bus drivers to the ‘on-bus state again. To awaken other sleeping nodes on the network, a special wake-up message with the dedicated, lowest possible Identifier can be used.

Why CAN Protocol?

Whenever there was no CAN protocol available in the industry at that time also vehicles were running with ECU. These ECUs are also able to communicate with each other using some other older protocols such as PWM, VPW, J1850 serial protocol, etc. But at that time the technology was not that much improved and so many demerits were also like low speed, more noise, more accidents, etc were happening.

As technology advanced, users’ demands grew, especially with the rise of autonomous vehicles. In response, many OEMs and vehicle ECU suppliers began researching ways to meet these evolving customer needs. Recognizing this, Bosch’s dedicated R&D team conducted extensive investigations and successfully developed the first CAN controller chip equipped with a CAN transceiver, enabling efficient communication among ECUs.

This method really works fine to get the 3 Mbps speed at 40 meters of length with all the other advantage features that I have explained above. before this, there was no such protocol as CAN that could give these features which caused it to boom the industry as nowadays most of the industry trying to use the CAN protocol.

Different types of CAN Protocol

The CAN Protocol finds applications across various fields due to its unique and comprehensive features. Unlike protocols such as Ethernet, it stands out for its cost-effectiveness. Therefore, it is classified into distinct types, including:

As per ISO standards, CAN Protocol is categorized as:

1. ISO-11898 Standard: Road vehicles – CAN for high-speed communication
2. ISO-11519 Standard: Road vehicles – Low-speed serial data communication Low-Speed CAN / VAN
3. ISO-11992 Standard: Road vehicles – Electrical connections between towing and towed vehicles.
4. ISO-11783 Standard:  ISO-BUS is for “Tractors and machinery for agriculture and forestry—Serial control and communications data network”.
5. EIA RS-485 Standard: Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems (formerly used for CAN Physical Layer).

The CAN Protocol is categorized based on the number of wires used for the Physical Layer:

1. SW CAN: Single Wire CAN used for low speed and less risk data transmission CAN network. Single wire CAN interface has a lower data rate of up to 33.3 Kbits/s and is also named SAE-J2411. The devices that do not require high performance like seat and mirror adjusters use a Single wire CAN interface.
2. DW CAN: Double Wire CAN used for high-speed and fault-tolerant CAN networks.

Categorization of CAN Protocol Based on Physical Layer Speed

1. Low-Speed CAN Physical Layer:

The Low-Speed CAN bus is typically used for data rates between 40 kbps and 125 kbps. It is also known as a fault-tolerant CAN bus. Unlike other types of CAN buses, it can operate without a termination resistor. The voltage levels for the Low-Speed CAN bus are as follows:

• Dominant Voltage Level: CAN-L is 1.4 v and CAN-H is 3.6 v
• Recessive Voltage Level: CAN-L is 0 v and CAN-H is 5 v.

2. High-Speed CAN Physical Layer:

The High-Speed CAN bus is typically used for data rates ranging from 40 Kbps to 1 Mbps. This type of bus requires termination with a resistor, usually between 108 Ohms and 132 Ohms, depending on the specific requirements outlined in the bus system documentation. The voltage levels for the High-Speed CAN bus are as follows:

• Dominant Voltage Level: CAN-L is 1.5 v and CAN-H is 3.5 v.
• Recessive Voltage Level: CAN-L is 2.5 v and CAN-H is 2.5 v. 

CAN Generation Improvement in the CAN Protocol is categorized as:

1. Classical CAN: Normal CAN protocol having speed up to 1 Mbps with a maximum of 8 bytes of Payload in a single data packet.
2. CAN-FD: CAN-FD(Flexible Data Rate) has a speed of up to 2 Mbps with a maximum of 64 bytes of payload in a single data packet (CAN FD-SiC up to 5-8Mbit/s).
3. CAN-XL: CAN-XL (Extra/Extended Length) has a speed of up to 20 Mbps with a maximum of 2048 bytes of payload in a single data packet.

Categorization of CAN Protocol Based on Data Rate

1. Low-Speed CAN: Speed between 1 kbps – 125 kbps.
2. Medium-Speed CAN: Speed between 125 kbps – 500 kbps.
3. High-Speed CAN: Speed between 500 kbps – 1 Mbps.
4. Ultra High-Speed CAN (CAN-FD): Speed between 1 Mbps – 2 Mbps.
5. Extended Ultra High-Speed CAN (CAN-XL): Speed between 2 Mbps – 20 Mbps.

Categorization of CAN Based on Length

1. Class-A: 50 Kbps speed at 1 Kilo Meter (1000 meter) of CAN bus length.
2. Class-B: 125 Kbps speed at 500 Meters of CAN bus length.
3. Class-C: 1 Mbps speed at 40 Meters of CAN bus length.

As per Identifier, CAN is categorized as:

1. Basic/Standard CAN: Message Identifier is 11-bit (2¹¹ = 2048) which helps to create limited unique messages or message identifiers for the lowest number of ECUs with lowest data communications in simple CAN networks.
2. Extended CAN: Message Identifier is 29-bit (2²⁹ = 536,870,912) which helps to create millions of unique messages for data communications in complex CAN networks.

OSI Layer used in CAN Protocol

As we all know each computer system follows the 7-layers of the OSI (Open System for Interconnection) layer for communication between two or more computers. In the automotive field, each ECU is nothing but a computer system that uses the same OSI layer as shown in the below image:

Among all of the OSI layers, the CAN protocol uses only two layers since it is part of an ECU for data or information communication. So for communication purposes, it is sufficient for most of the protocol. These layers are:

1. Physical Layer.
   • Physical Signalling Characteristics(PSC).
   • Physical Medium Attachment (PMA).
   • Medium Dependent Hardware (MDH).
2. Datalink Layer.
   • Logical Link Control (LLC).
   • Medium Access Control (MAC).

CAN Protocol Physical Layer

The physical layer of the Controller Area Network (CAN) protocol defines the electrical and mechanical characteristics of the communication medium used to transmit data between nodes in the network. It defines the CAN transceiver characteristics.

The Physical Layer is divided into three types:

1. Physical Signalling Characteristics(PSC) of CAN Physical Layer

CAN uses a differential signaling scheme to transmit data over the communication medium. In differential signaling, the voltage on one wire is higher than the voltage on the other wire. The voltage difference between the two wires represents the transmitted data. The differential signaling scheme provides several advantages, including noise immunity, signal integrity, and low power consumption. Physical Signalling Characteristics define the bit encoding/decoding, bit timing, and synchronization.

2. Physical Medium Attachment (PMA) of CAN Physical Layer

CAN uses a twisted pair of wires to transmit data between nodes in the network. The twisted pair helps to reduce electromagnetic interference and improve signal integrity. Implementing CAN is possible with alternative physical media, like optical fiber or wireless communication. Physical Medium Attachment defines the CAN transceiver characteristics.

3. Medium Dependent Hardware (MDH) of CAN Physical Layer

Medium Dependent Hardware (MDH) in the Controller Area Network (CAN) protocol refers to the hardware components that are responsible for the physical transmission of data over the communication medium. The MDH is a part of the physical layer of CAN and includes components such as transceivers, connectors, and termination resistors. The main function of the MDH is to convert the digital signals from the CAN controller into the appropriate signals for transmission over the physical medium as per CAN protocol voltage levels, such as a twisted pair of wires or optical fiber. The MDH also accepts incoming signals from the communication medium and transforms them into digital signals processed by the CAN controller.

CAN Protocol Data-Link Layer

The data-link layer is the second layer of the Controller Area Network (CAN) protocol, which is responsible for framing and transmitting data between nodes in the network. The data-link layer of CAN is divided into two sub-layers.

The data-link layer is divided into two types:

1. Logical Link Control (LLC) Sub-Layer: This sub-layer is responsible for error detection and correction, flow control, and message filtering. It receives messages from the higher layers and adds a header and a trailer to each message to create a frame. The header contains information about the source and destination nodes, as well as the message identifier, while the trailer contains an error check sequence (ECS) to detect errors in the data.
2. Media Access Control (MAC) Sub-Layer: This sub-layer is responsible for arbitration and collision detection. It controls access to the communication medium and ensures that only one node transmits data on the bus at any given time. The MAC sub-layer uses a priority-based arbitration scheme to resolve conflicts between multiple nodes trying to transmit data at the same time. The node with the highest priority wins the arbitration and is allowed to transmit its message on the bus.

The data-link layer of CAN also includes several error-handling mechanisms, such as error signaling, error detection, and error recovery. These mechanisms guarantee accurate and reliable data transmission between network nodes, even in the presence of errors or interference.

What are the Types of CAN Protocol Frames

I hope you have cleared about all the types of CAN protocol available but commonly one type that I missed and going to explain here because it is common for each type of CAN which I have explained above.

As per the CAN frames, all the CAN standards are communicating among the ECU in a CAN network. There are 5 types of CAN frames such as:

1. Data Frame: Used to send the data in a CAN network.
2. Remote Frame: Used to request the data in a CAN network.
3. Error frame: Used to send the error information in a CAN network.
4. Overload Frame: Used to notify the incomplete data reception.
5. Inter-Frame Space (IFS): Used to delay the next packet data transmission. 

I hope we will not waste time, let us discuss each frame in detail below:

Data Frame Format In CAN Protocol

The data frame within the CAN protocol facilitates the transmission of data across the CAN network. It allows others in the network to receive data based on their specific requirements. The data frame consisted of 7 fields that are taking care of secure data transfer from transmitter to receiver successfully.

There are two main types of data frames in CAN communication: the standard frame, which uses an 11-bit identifier, and the extended frame, which uses a 29-bit identifier. First, we’ll discuss the standard CAN frame, followed by an explanation of the extended CAN frame.

Standard or 11-bit CAN Protocol Frame Format

The standard CAN was initially developed by BOSCH, allowing a maximum of 2^11 (2048) unique messages to be generated and utilized in a CAN network for data communication. The entire frame is segmented into seven typical fields, aiding in the identification, detection, correction, and validation of a CAN message within the CAN network. Please refer to the figure below for illustration:

CAN Protocol Frame Field Explanation

A Data frame consists of seven distinct bit fields: Start of the frame, Arbitration field, Control field, Data field, CRC field, ACK field, and End of the frame. The Data field has the flexibility to be of length zero. Each field is elaborated below:

SOF Field in CAN Protocol Data Frame

The Start of the frame marks the beginning of Data frames and remote frames. It consists of a single dominant bit. A node is only allowed to start transmission when the bus is idle. All nodes must synchronize to the leading edge initiated by the node commencing the transmission at the start of the frame.

Arbitration Field in CAN Protocol Data Frame

The Arbitration Field is vital in the Controller Area Network (CAN) protocol, resolving conflicts when multiple nodes attempt simultaneous data transmission on the shared medium. Positioned in the header of a CAN message, the Arbitration Field is integral to the Data Link Layer of the CAN protocol.

1. 11-Bit Identifier: The Identifier field is the heart of the CAN data frame. There are two main purposes of this identifier field:
   • To determine which node needs to gain the bus access whenever more than one node tries to send the messages on the same can bus.
   • To identify the type of message it is. That means in can protocol it is message-based so there is nothing like an address for any ECU. It will broadcast to whoever is interested they will receive it. Now you tell how it will get to know which data he needs to receive or not? Yes for this in CAN protocol, each identifier is unique and it will be assigned to a message. These data including some more data will create a database called a CAN database.
2. Remote Transmission Request (RTR): It is extended for the purpose of Remote Transmission Request. The main objective of this bit is to identify either a data frame or a remote frame. If the RTR bit is 1, it is a remote frame else it is a data frame.

Control Field in CAN Protocol Data Frame

The Control field consists of six bits. It includes the Data length code and two bits reserved for the future of the expansion. The reserved bits must be sent as dominant. Receivers accept dominant and recessive bits in all the combinations.

1. IDE: If the Identifier Extension bit is Dominant then it is a standard (11-bit ID) CAN and if the IDE bit is recessive then it is an Extended (29-bit ID) CAN.
2. R0: This is a reserved bit for future use. It might be used in the future CAN standard amendment. It is always recessive in the CAN data field.
3. DLC: The Data length code, which is 4 bits wide, is transmitted within the Control field. The DLC bits can code data lengths from 0 to 8 bytes. If the DLC exceeds 8, it is considered a “don’t care” condition and will be rejected by the Transmitter ECU.

Data Field in CAN Protocol

Within the Controller Area Network (CAN) protocol, the Data Field resides in the Data Link Layer, encompassing the actual data transmitted among nodes on the network. The Data Field follows the Arbitration Field and the Control Field in the CAN message frame.

In the CAN protocol, the Data Field can accommodate up to 8 bytes of data. It serves as a conduit for conveying information like sensor readings, control signals, and status updates among network nodes. The actual length of the Data Field depends on the length of the message being transmitted.

CRC Field in CAN Protocol Data Frame

The CRC field contains the 15-bit CRC Sequence followed by a 1-bit CRC Delimiter.

Cyclic Redundancy Check (CRC) in CAN Protocol Data Frame

The CRC field is nothing but an algorithm or a polynomial function you can say. This function will be implemented in all available ECUs within the CAN network. If you will give the same input, then the output will be the same for all.
When a transmitter sends a data frame, it inputs the SOF, Arbitration, Control, and data field data. Afterward, it generates 15-bit CRC data, subsequently added to the CRC field within the CAN data field. When a transmitter sends a data frame, it inputs the SOF, Arbitration, Control, and data field data, generating a 15-bit CRC data added to the CRC field within the CAN data field.

Then the Transmitter ECU will generate the total frame and it will send it over the CAN bus. Then the receiver ECU will receive it. The receiver ECU also has the same CRC algorithm. It will also give the received SOF, Arbitration, Control, and data field as input to that algorithm. Then it will generate a 15-bit CRC field and the controller will compare both the received CRC and generated CRC. If both the CRC is the same it will receive the data or else it will generate the CRC error.

CRC Delimiter in CAN Protocol Data Frame

In the Controller Area Network (CAN) protocol, the CRC Delimiter resides in the Data Link Layer, specifically the Logical Link Control (LLC) sub-layer. Positioned after the data field and preceding the ACK field in a CAN message, the CRC Delimiter is a bit sequence. It serves two key functions: marking the end of the data field and providing a checksum for error detection.

The CRC Delimiter consists of a delimiter bit, six recessive bits, and two dominant bits, forming a fixed bit sequence of “01111110“. This bit sequence is known as the CRC Delimiter or End of Frame (EOF) sequence. The delimiter bit is always recessive, while the six recessive bits and two dominant bits are fixed.

The CRC Delimiter enables error detection in the CAN protocol by providing a checksum of the data field, which can be used to detect errors introduced during transmission. The CRC Delimiter is also used to indicate the end of the data field and to synchronize the receiving nodes in the network.

ACK Field in CAN Protocol Data Frame

When a node transmits a message on the CAN bus, it waits for an acknowledgment from the receiving node. The acknowledgment signal indicates that the message has been received correctly and that the receiver is ready to receive the next message.

The acknowledgment mechanism in CAN works as follows:

1. When a node transmits a message on the bus, it monitors the bus to detect any errors or interference.
2. If the transmission is successful, the node waits for an acknowledgment signal from the receiving node.
3. The receiving node sends an acknowledgment signal by transmitting a dominant bit on the bus immediately after receiving the message.
4. If the transmitting node detects the dominant bit, it knows that the message has been received correctly and that the receiving node is ready for the next message.
5. If the transmitting node does not receive an acknowledgment signal, it assumes that the message was not received correctly, and it may retransmit the message after a short delay.

The ACK mechanism in CAN ensures that messages are reliably transmitted and received, even in the presence of errors or interference. It enhances the reliability and safety of the system, which is critical in many applications of the CAN protocol, such as automotive and industrial control systems.

ACK Delimiter Bit in CAN Protocol Data Frame

In the Controller Area Network (CAN) protocol, the ACK Delimiter bit is a single bit that follows the ACK Field in a CAN data frame. The ACK Delimiter bit serves as a delimiter between the ACK Field and the End of Frame (EOF) bit.

The ACK Delimiter bit is always recessive, meaning that it has a value of 1 and does not interfere with the dominant state of the bus. The recessive state of the ACK Delimiter bit allows for a seamless transition from the ACK Field to the EOF bit, without any interference or corruption of the data.

The ACK Delimiter is the second bit of the ACK field and has to be a recessive bit. As a consequence, the ACK Slot is surrounded by the two recessive bits (CRC Delimiter, ACK Delimiter).

End Of Frame (EOF) in CAN Protocol Data Frame

In both the Data and Remote frames, each frame’s data is separated by a flag sequence comprising seven recessive bits. The 7 recessive bits are constant, confirming the idle state of the CAN BUS. The EOF (End of Frame) bit holds significance in the CAN protocol, marking the conclusion of a CAN message frame and signaling to the receiving node the successful reception of the message. Additionally, the EOF bit provides time for the bus to transition back to the intermission period, preparing for the transmission of the next message.

Extended or 29-bit CAN Protocol Frame Format

There are two types of CAN protocol defined in ISO 11898-1 standard. Both standards are designed by Robot BOSCH. You would have thought why there are two types of CAN? Yes obviously, let me explain this. Basically, the main difference is the CAN data frame. In this data frame, the Arbitration and control field is having some change, except this, there is no more change between them.

The primary advantage of the 29-bit CAN over the 11-bit CAN is its ability to accommodate a greater number of unique CAN messages. This becomes essential when dealing with increased functionality and data requirements in a vehicle, which may not be feasible with an 11-bit CAN. In such cases, the 29-bit CAN proves valuable. The image below illustrates the 29-bit CAN frame format.

The above figure, it is showing each and every bit field with clear visibility. As I have already told you except for the arbitration and Control fields, others are the same, we will only discuss these fields.

Substitute Remote Request (SRR) in Extended CAN Frame

The SRR, or Substitute Remote Request, consistently holds a recessive position in the extended frame format. In the context of our CAN system, which supports both 11-bit and 29-bit IDs in the CAN-2.0B standard, the question arises: why utilize this bit? The significance becomes apparent when considering a scenario where both an 11-bit ID as a data frame and a 29-bit ID as a remote frame attempt to transmit messages simultaneously. In such instances, arbitration technology comes into play to efficiently manage bus access and resolve potential conflicts.

In an 11-bit Identifier, the RTR bit resides in the 12th position, while in a 29-bit ID, it occupies the 30th position. The challenge arises during arbitration, where the remote frame gains precedence in violation of CAN rules. To address this, we introduce the SRR bit, consistently setting it to a recessive state. Its purpose is to ensure that the 11-bit Identifier gains bus access, preventing any violation of the BUS access rule during arbitration.

R1 and R0 in Extended CAN Frame

The Extended frame has two reserve bits in the control field like the R0 bit in the 11-bit CAN.

CAN Protocol Remote Frame Format

In CAN, there are two types of communication. One is the sender and receiver and the second one is client-server communication.
The sender-receiver concept involves the Transmitter ECU sending updated data on the CAN bus, and any recipient in need will receive it. In the case of a Client-server, when an ECU needs any data like the vehicle speed in the Instrument cluster ECU, it will send a remote frame to the CAN bus.

Then the ECU suppose VMCU ECU who is having this data will receive by checking the RTR bit of that remote frame. After that, the VMCU ECU will read the vehicle speed from the sensor put it in the data field of the same frame, and make the RTR bit 0. Then the VMCU will send it again back and the Instrument ECU will receive it.

A node acting as a RECEIVER for certain data can stimulate the relevant source node to transmit the data by sending a Remote Frame. A Remote frame consists of six distinct bit fields: Start of the frame, Arbitration field, Control field, CRC field, ACK field, and End of the frame.

Why RTR bit is always recessive in CAN Protocol?

The RTR bit of a Remote frame is always recessive (cf. Data frames where the RTR bit is dominant). In a Remote frame, there is no Data field, regardless of the Data length code’s value. The Data length code corresponds to that of the associated Data frame and can be assigned any value within the permissible range of 0-8.

The polarity of the RTR bit indicates whether a transmitted frame is a Data frame (RTR bit dominant) or a Remote frame (RTR bit recessive).

CAN Protocol Error Frame Format

The error frame is used to notify an error that has occurred during the transmission. The error frame consists of an error flag and an error delimiter. The Error frames are transmitted by the hardware part of the CAN controller. 

This Error Frame in CAN protocol consists of an Error Flag, which has 6 bits of the same value, and an Error Delimiter, which is 8 recessive bits. The Error Delimiter provides some space so that the other nodes on the bus can send their Error Flags when they detect the first Error Flag.

The CAN protocol error frame has two fields:

1. Error Flag
2. Delimeter Flag

Error Flag in CAN Protocol Error Frame

The error flag bits are the minimum of 6 bits which are generated whenever any error occurs in the CAN network at the time of data transmission. There are two types of error flags: the active-error flag and the passive-error flag.

• Active-Error flag: 6-12 consecutive dominant bits.
• Passive-Error flag: 6-12 consecutive recessive bits.

Active Error Flag in CAN Protocol Error Frame

In the Controller Area Network (CAN) protocol, an Active Error Flag is a bit that is transmitted in the Error Frame to indicate the presence of an error on the CAN bus. The Active Error Flag consists of six consecutive dominant bits bit that are sent by a node when it detects an error on the bus.

When a node detects an error, it sends an Error Frame, which contains the Active Error Flag and other bits that provide information about the type of error that occurred. The Active Error Flag serves as a warning to all nodes on the bus that an error has occurred and that they should take appropriate action.

When a node receives an Error Frame with the Active Error Flag, it acknowledges the error by sending an Acknowledge Error Frame, which consists of six recessive bits. The Acknowledge Error Frame is sent to all nodes on the bus and signals that the node has received the Error Frame and is ready to resume normal communication.

Passive Error Flag in CAN Protocol Error Frame

In the Controller Area Network (CAN) protocol, a Passive Error Flag is a bit that is transmitted in the Error Frame to indicate the presence of an error on the CAN bus. The Passive Error Flag is a recessive bit that is sent by a node when it detects an error on the bus.

When a node detects an error, it sends an Error Frame, which contains the Passive Error Flag and other bits that provide information about the type of error that occurred. The Passive Error Flag serves as a warning to all nodes on the bus that an error has occurred and that they should take appropriate action.

If a node receives an Error Frame with a Passive Error Flag, it does not acknowledge the error by sending an Acknowledge Error Frame. Instead, the node enters an error state and stops transmitting data on the bus until the error has been resolved.

What is the need for a Passive Error Flag in CAN Protocol?

The Passive Error Flag is used in cases where a node detects an error, but it is not severe enough to warrant a dominant Active Error Flag. The Passive Error Flag allows the node to signal that an error has occurred while maintaining the integrity of the bus and minimizing the impact on other nodes.

In summary, the Passive Error Flag is a recessive bit that is transmitted in the Error Frame in the CAN protocol to indicate the presence of an error on the bus. The Passive Error Flag serves as a warning to all nodes on the bus that an error has occurred and that they should take appropriate action. The Passive Error Flag is used in cases where a node detects an error that is not severe enough to warrant a dominant Active Error Flag, allowing the node to signal that an error has occurred while maintaining the integrity of the bus and minimizing the impact on other nodes.

Depending on the timing at which an error is detected by each unit connected to the bus, error flags may overlap one on top of the other, up to 12 bits in total length. This is called an overlapping of the error flag.

Error Delimeter in CAN Protocol Error Frame

Error Delimiter is an important part of the CAN (Controller Area Network) protocol. It is used to indicate that a transmission error has occurred in the network, allowing for corrective action to be taken. The error delimiter consists of 8 recessive bits.

The purpose of Error Delimiter is to detect when errors occur during data transmission over a CAN bus system. When an error occurs, such as bit stuffing or bit-level corruption, the transmitting node sends out an “error frame” with special bits set aside as delimiters that signal all other nodes on the network about this occurrence so they can take appropriate steps toward correcting it or avoiding further damage from occurring due to corrupted data being sent across the wire.

When these delimiters are received by another node in receipt of this message, they know there was some sort of issue with its delivery and should take preventative measures like dropping any subsequent frames until things have been cleared up again or re-transmitting if needed – depending upon what type of application layer protocol you may be using at higher levels within your stack architecture.

To learn more about the CAN Protocol Error frames and their types, you can follow this Types of Error in CAN Protocol.

There is also an Error Triangle in the CAN Protocol. Please select this Link to learn about the CAN Bus Error Handling.

CAN Protocol Overload Frame Format

The overload frame is used by the receiver unit to notify that it has not been prepared to receive frames yet. It consists of the overload flag and an overload delimiter. There are three kinds of Overload condition that lead to the transmission of an Overload flag: 

• Where the internal conditions of the receiver are such that the receiver requires a delay of the next Data frame or Remote the frame.
• On detection of a dominant bit during the INTERMISSION.
• If the CAN node samples a dominant bit at the eighth bit (i.e. the last bit) of an Error Delimiter or Overload Delimiter, it will start transmitting an Overload frame (not an Error frame). The Error Counters will not be incremented.

An Overload frame resulting from Overload condition 1 is only allowed to start at the first-bit time of an expected INTERMISSION, whereas Overload frames resulting from Overload conditions 2 and 3 start one bit after detecting the dominant bit.

Overload Flag in CAN Protocol Overload Frame

It consists of 6 dominant bits. The overload of the flag is structured the same way as the active-error flag of the error frame. The Overload flag’s form destroys the fixed form of the INTERMISSION field. As a consequence, all other nodes also detect an Overload condition and each starts to transmit an Overload flag. In the event that there is a dominant bit detected during the third bit of the INTERMISSION, then it will interpret this bit as the Start of a frame.

Overload Delimiter in CAN Protocol Overload Frame

It consists of 8 recessive bits. The overload delimiter is structured in the same way as the error delimiter of the error frame. The Overload Delimiter is the same form as the Error Delimiter. After the transmission of an Overload flag, the node monitors the bus until it detects a transition from a dominant to a recessive bit.

At this point of time, every bus node has finished sending its Overload flag, and all the nodes start transmission of the seven more recessive bits in coincidence.

Inter-Frame Space In CAN Protocol

The IFS frame is used to separate the data frame and the remote frames. The data and the remote frames, whichever frame (data, remote, error, or overload frame) may have been transmitted prior to them, are separated from the preceding frame by an inserted inter-frame space. However, no inter-frame spaces are inserted preceding overload and error the frames.

CAN Protocol Working Principle

The CAN bus is an inexpensive, robust vehicle bus standard designed for multiple CAN device communications with one another without a host computer connection. The CAN is also called a multi-master serial bus and the CAN devices on the bus are referred to as nodes.

Two or more nodes are required on the CAN network to communicate. All nodes are connected to each other via a two-wire bus (CAN H and CAN L) and the wires are 120 ohms nominal twisted pairs. A termination resistor commonly 120 ohms is a must in each node in order to suppress the reflections as well as return the bus to its recessive or idle state.

Each node in the CAN bus requires the below modules to work together in a CAN network.

Different Components of CAN Protocol Communication System

1. Microcontroller (Host): It decides what the received messages mean and what messages it wants to transmit.
2. CAN controller: They are often an integral part of the microcontroller that handles framing, CRC, etc. like the Data Frame, Remote Frame, Error Frame, Overload Frame, and Inter-Frame Space generation.
3. CAN Transceiver: The CAN transceiver transforms data between the CAN controller and bus levels. It converts data from the CAN controller to CAN bus levels and vice versa. In essence, the CAN transceiver’s role is to convert Microcontroller TTL voltage levels (High/Low) into CAN Bus protocol voltage levels (Recessive/Dominant) and vice versa.

Functions of Transceiver in CAN Bus Communication

The transceiver drives or detects the dominant and recessive bits by the voltage difference between the CAN_H and CAN_L lines. The nominal dominant differential voltage is between 1.5V to 3V and the recessive differential voltage is always 0V.

The CAN transceiver actively drives to the logical 0 (dominant bits) voltage level and the logical 1 (recessive bits) are passively returned to 0V by the termination resistor.  The idle state will always be in the recessive level (logical 1).

Individually, CAN_H will always be driven towards supply voltage (VCC) and CAN_L towards 0V when transmitting to the dominant (0). But in a practical case, supply voltage (VCC) or 0V cannot be reached due to the transceiver’s internal diode drop. CAN H/L will not be driven when transmitting a recessive (1) where the voltage will be maintained at VCC/2.

The following figure depicts the block diagram and real-time capture of the CAN signals.

CAN has different physical layers that classify certain aspects of the CAN network such as signaling scheme, cable impedance, maximum data rates, electrical levels, etc. The following are the most commonly used physical layers.

How CAN Communication Works?

As mentioned earlier, CAN is a Peer-to-Peer network in which there is no master that controls the transmission between nodes. When any CAN node is ready to transmit data, it should undergo a process called message arbitration. In this process, the CAN node will check to see if the bus is idle and start the transmission once it is idle.

This will also trigger other CAN nodes in the bus and hence result in two or more nodes starting a message at the same time which results in a conflict. The conflict is resolved in the following methods,

While transmitting data, the sender monitors the bus. If it detects a conflicting signal (logical 0), it fails in arbitration, shifts to receiving mode, and relinquishes control. CAN frame arbitration occurs in the ID field, ensuring the highest-priority node (lowest arbitration ID) successfully completes transmission.

Then the node that has won the arbitration will continue message transmission as if nothing had happened. Other receiving nodes can decide if a message is relevant or if it should be filtered using a combination of hardware and software filters. This process is continuous and other nodes will transmit their messages when the bus has become available.

Operation of the CAN Network​

• Each node is then assigned a unique identification number called the Physical Address of the ECU.
• All the nodes are interested to transmit competing for the channel by transmitting a binary signal based on their identification value.
• A node will drop out of the competition if it detects a dominant state while transmitting a passive state.
• The node with the lowest identification value wins the bus network, initiating the message transmission.
• If an error is detected by either the transmitter or receiver, it halts Data Frame transmission and initiates the sending of an Error Frame. The error is having an error state to handle the error in CAN Protocol called Error Handling in CAN Protocol. There are 5 types of errors in CAN protocol that can occur.

Related Articles for CAN Protocol

• CAN Protocol Error States or Error Confinement Mechanism
• CAN Protocol Error Types
• DoIP Protocol
• CAN Network Management (CanNM) – AUTOSAR BSW
• 8086 Microprocessor
• CAN Protocol Bit Time Calculation