CAN Bus Protocol

What is CAN Bus?

CAN (Controller Area Network) is a serial communication protocol designed by Robert Bosch GmbH in 1986. It was originally developed to reduce the weight and complexity of wiring harnesses in automobiles by replacing point-to-point connections with a shared two-wire bus. Since its introduction, CAN has become one of the most widely deployed communication protocols in the world, with billions of CAN-enabled devices in operation.

CAN is a multi-master protocol, meaning any node on the bus can initiate communication without requiring permission from a central controller. Messages are broadcast to all nodes on the network, and each node decides whether to process or ignore a given message based on its identifier. There are no node addresses in CAN. Instead, each message carries an identifier that defines both its content and its priority on the bus.

The physical layer uses differential signaling across two wires: CAN_H (CAN High) and CAN_L (CAN Low). This differential pair provides excellent noise immunity, which is critical in electrically noisy environments like engine compartments and factory floors. The protocol is standardized under ISO 11898, which covers both the data link layer and the physical layer.

Today, CAN is found in passenger vehicles, commercial trucks, agricultural equipment, construction machinery, industrial automation systems (via CANopen), medical devices, elevators, marine electronics, and even spacecraft. Its combination of reliability, low cost, and deterministic behavior makes it a natural fit for any application where multiple microcontrollers need to communicate over a shared bus.

CAN Bus Network Topology

A CAN network consists of two or more nodes connected to a single linear bus. The bus itself is a twisted pair of wires: CAN_H and CAN_L. Each end of the bus must be terminated with a 120-ohm resistor to prevent signal reflections. Without proper termination, the bus will not function reliably.

Because CAN is a multi-master protocol, any node can begin transmitting at any time (subject to arbitration rules). Every message sent on the bus is visible to all connected nodes, making CAN a broadcast network by design. Nodes use acceptance filters to determine which messages they should process and which they should discard.

The maximum bus length depends on the bit rate. At the highest standard speed of 1 Mbps, the bus can extend up to approximately 40 meters. At lower speeds, significantly longer distances are possible: up to 1000 meters at 50 kbps. This trade-off exists because the arbitration mechanism requires all nodes to observe each bit simultaneously, and propagation delay increases with cable length.

Stub lines (short branches off the main bus to reach individual nodes) should be kept as short as possible, ideally under 0.3 meters at 1 Mbps, to avoid signal integrity problems. Star topologies are generally not recommended for CAN, although specialized CAN hubs and bridges can enable star or hybrid layouts in certain applications.

CAN Frame Structure

CAN defines two frame formats. The standard frame (CAN 2.0A) uses an 11-bit identifier, allowing up to 2,048 unique message types. The extended frame (CAN 2.0B) uses a 29-bit identifier, supporting over 500 million unique message types. Both formats can coexist on the same bus, and most modern CAN controllers support both.

A standard CAN data frame contains the following fields:

• SOF (Start of Frame): a single dominant bit (0) that signals the beginning of a new frame and synchronizes all nodes on the bus.
• Identifier (11 bits): defines the message type and its priority. Lower numeric values have higher priority during arbitration.
• RTR (Remote Transmission Request): a single bit that distinguishes data frames (dominant, 0) from remote frames (recessive, 1). Remote frames are used to request data from another node.
• IDE (Identifier Extension): indicates whether the frame uses the standard 11-bit identifier (dominant, 0) or the extended 29-bit identifier (recessive, 1).
• DLC (Data Length Code, 4 bits): specifies the number of data bytes in the frame, from 0 to 8.
• Data Field (0 to 8 bytes): the actual payload of the message. CAN FD extends this to up to 64 bytes.
• CRC (15 bits + delimiter): a cyclic redundancy check that allows receiving nodes to detect transmission errors.
• ACK (2 bits): the transmitting node sends a recessive bit, and any node that successfully received the frame overwrites it with a dominant bit, confirming receipt.
• EOF (End of Frame, 7 bits): seven recessive bits that mark the end of the frame.

In an extended frame, the 29-bit identifier is split into two parts: an 11-bit base ID followed by an 18-bit extension. The SRR (Substitute Remote Request) and IDE bits appear between them, ensuring backward compatibility with CAN 2.0A controllers.

CAN Bus Arbitration

Arbitration is the mechanism that determines which node gets to transmit when multiple nodes attempt to send at the same time. CAN uses non-destructive bitwise arbitration, which is one of the protocol's most important innovations.

In CAN, a dominant bit (logic 0) always overwrites a recessive bit (logic 1) on the bus. When two or more nodes begin transmitting simultaneously, each node monitors the bus while sending its identifier bits one at a time. If a node sends a recessive bit but reads back a dominant bit, it knows that another node with a higher-priority (lower numeric) identifier is also transmitting. The losing node immediately stops transmitting and switches to receive mode.

The node with the lowest identifier value always wins arbitration because its dominant bits overwrite the recessive bits of all competing nodes. This process happens bit by bit during the identifier field, so by the time the winning node finishes sending its ID, all other competing nodes have already backed off. The winning node continues transmitting its frame without any delay or data corruption.

This approach is non-destructive because no data is lost during arbitration. The losing nodes simply wait for the bus to become idle and then retry automatically. The result is a deterministic priority system: the most urgent messages always get through first. System designers assign lower identifier values to time-critical messages (such as engine management or brake commands) and higher values to less urgent data (such as interior lighting or seat position).

CAN Bus Speed and Bit Timing

CAN bus speed is directly related to the maximum bus length. Higher bit rates require shorter cable runs because the arbitration mechanism depends on all nodes observing each bit at the same time. The following table shows the standard speed and distance combinations:

Each bit on the CAN bus is divided into four timing segments:

• Sync Segment: used to synchronize all nodes. A bit edge is expected during this segment.
• Propagation Segment: compensates for the physical propagation delay across the bus and through transceiver circuits.
• Phase Segment 1: can be lengthened by resynchronization to compensate for clock drift between nodes.
• Phase Segment 2: can be shortened by resynchronization. The bus is sampled at the boundary between Phase Segment 1 and Phase Segment 2.

The sample point, expressed as a percentage of the total bit time, is a critical configuration parameter. A sample point of 75% to 87.5% is typical for most CAN applications. All nodes on a bus must be configured with the same bit rate and compatible sample point settings, or communication will fail.

CAN Bus Error Handling

CAN includes five error detection mechanisms that work together to ensure data integrity:

• Bit Monitoring: each transmitting node reads back the bus level and compares it to what it sent. If the levels do not match (outside of the arbitration field), an error is detected.
• Bit Stuffing: after five consecutive bits of the same value, the transmitter inserts a stuff bit of the opposite value. If a receiver detects six consecutive bits of the same value, it flags a stuff error.
• CRC Check: the transmitter calculates a 15-bit CRC over the frame contents. Each receiver independently calculates the CRC and compares it to the transmitted value.
• Frame Check: certain fields in the CAN frame have fixed values (such as the delimiter bits). If a receiver observes an incorrect value in a fixed-format field, it flags a form error.
• ACK Check: the transmitter expects at least one node on the bus to assert the ACK bit. If no acknowledgment is received, the transmitter knows the message was not received by any node.

When an error is detected, the detecting node transmits an error frame to alert all other nodes. CAN uses three error states to manage faulty nodes:

• Error Active: the normal operating state. The node can transmit and receive normally, and it sends active error flags (six dominant bits) when it detects an error.
• Error Passive: a node enters this state after accumulating too many errors. It can still transmit and receive, but it sends passive error flags (six recessive bits) and must wait an additional delay after each transmission before it can send again.
• Bus Off: a node enters this state after severe or persistent errors. It disconnects from the bus entirely and cannot transmit or receive. The node can automatically recover from Bus Off after detecting 128 occurrences of 11 consecutive recessive bits, which indicates that the bus has been idle and stable.

CAN 2.0 vs CAN FD

CAN FD (Flexible Data-rate) was introduced by Bosch in 2012 to address the growing need for higher bandwidth in automotive and industrial applications. CAN FD is backward compatible with CAN 2.0 at the physical layer, meaning both types of nodes can share the same bus (though CAN 2.0 nodes will flag errors on CAN FD frames unless configured to tolerate them).

CAN FD achieves higher data rates by switching to a faster bit rate during the data phase of the frame. The arbitration phase still runs at the standard CAN bit rate (up to 1 Mbps) to maintain compatibility with the arbitration mechanism. Once arbitration is complete, the transmitter shifts to a higher clock rate for the data payload, then drops back to the standard rate for the CRC and end-of-frame fields.

The larger payload (64 bytes vs 8 bytes) significantly reduces protocol overhead. Transmitting 64 bytes of data over CAN 2.0 requires at least 8 separate frames, each with its own header, CRC, and acknowledgment. CAN FD can send the same amount of data in a single frame, improving throughput and reducing bus load.

Common Use Cases

CAN bus is used in a wide range of industries and applications:

• Automotive: engine management, transmission control, ABS (anti-lock braking), airbag deployment, power steering, climate control, infotainment systems, and advanced driver assistance systems (ADAS). A modern vehicle may have multiple CAN buses operating at different speeds for different subsystems.
• OBD-II Diagnostics: the On-Board Diagnostics standard (OBD-II) mandates a diagnostic connector in all vehicles sold in North America and Europe. CAN is the required physical layer protocol for OBD-II in all vehicles manufactured after 2008. Diagnostic tools and scan tools communicate with vehicle ECUs over CAN to read fault codes, monitor sensor data, and perform tests.
• Industrial Automation (CANopen): CANopen is a higher-layer protocol built on CAN that is widely used for embedded control systems, motion controllers, sensors, actuators, and I/O modules in factory automation and robotics.
• Medical Devices: CAN connects subsystems within medical equipment such as patient monitors, X-ray machines, MRI scanners, laboratory analyzers, and surgical robots, where reliability and determinism are essential.
• Agricultural Machinery (ISOBUS / SAE J1939): the J1939 protocol, built on CAN, is the standard for communication in tractors, combines, harvesters, and their implements. ISOBUS (ISO 11783) extends J1939 for implement-tractor compatibility.
• Aerospace and Defense: CAN is used in avionics subsystems, unmanned aerial vehicles (UAVs), satellite systems, and ground support equipment where weight, cost, and reliability are critical considerations.
• Marine Electronics: the NMEA 2000 protocol, based on CAN, connects navigation instruments, engines, fuel sensors, and environmental monitors on boats and ships.
• Elevator and Building Systems: CAN networks connect elevator controllers, door operators, floor indicators, and safety systems in modern elevator installations.

Frequently Asked Questions About CAN Bus

What is the difference between CAN and CAN FD?

CAN FD (Flexible Data-rate) is an extension of the original CAN protocol that supports larger payloads (up to 64 bytes per frame instead of 8) and higher data rates (up to 8 Mbps during the data phase instead of 1 Mbps). CAN FD uses the same physical layer and arbitration mechanism as CAN 2.0, so both protocols can coexist on the same bus under certain conditions. CAN FD also uses stronger CRC values (17-bit or 21-bit) to protect the larger payloads.

How does CAN bus arbitration work?

CAN uses non-destructive bitwise arbitration. When multiple nodes start transmitting at the same time, each node sends its message identifier one bit at a time while monitoring the bus. A dominant bit (0) always overrides a recessive bit (1). If a node sends a recessive bit but sees a dominant bit on the bus, it knows another node has higher priority, so it stops transmitting and switches to receive mode. The node with the numerically lowest identifier always wins because its dominant bits override all competing recessive bits. No data is lost in this process.

What speed does CAN bus run at?

Standard CAN (CAN 2.0) supports bit rates up to 1 Mbps. CAN FD supports up to 8 Mbps during the data phase of the frame, while the arbitration phase remains at up to 1 Mbps. The actual speed used in a given application depends on the bus length and the required update rate. Common automotive speeds are 500 kbps for powertrain systems and 125 kbps or 250 kbps for body electronics.

What is OBD-II and how does it relate to CAN?

OBD-II (On-Board Diagnostics, second generation) is a regulatory standard that requires vehicles to provide a standardized diagnostic interface. Since 2008, all vehicles sold in North America and Europe must use CAN as the physical layer protocol for OBD-II communication. Diagnostic scan tools connect to the vehicle's 16-pin OBD-II connector and communicate with engine, transmission, and emission control modules over CAN using standardized diagnostic services defined in ISO 15765 (Diagnostics on CAN).

Can CAN bus be used outside of cars?

Absolutely. While CAN was originally designed for automotive use, it has been adopted across many industries. Industrial automation uses CANopen and DeviceNet. Agricultural equipment uses J1939 and ISOBUS. Marine electronics use NMEA 2000. Medical devices, elevators, aerospace systems, and even amusement park rides rely on CAN for reliable, real-time communication. The protocol's simplicity, low cost, and proven reliability make it suitable for virtually any embedded networking application.

What are CAN_H and CAN_L?

CAN_H (CAN High) and CAN_L (CAN Low) are the two wires that make up the CAN bus. CAN uses differential signaling: the data is encoded as the voltage difference between these two wires rather than the absolute voltage on either wire. In the recessive state (logic 1), both wires sit at approximately 2.5 V, so the differential voltage is near 0 V. In the dominant state (logic 0), CAN_H rises to about 3.5 V and CAN_L drops to about 1.5 V, producing a differential voltage of roughly 2 V. This differential approach provides strong immunity to electromagnetic interference because noise affects both wires equally and cancels out in the difference.

Related Protocols

• PROFINET: industrial Ethernet protocol for real-time automation and motion control in factory environments.
• EtherNet/IP: industrial Ethernet protocol based on CIP, widely used in North American manufacturing.
• Modbus RTU: serial fieldbus protocol for RS-485 industrial communication, often found alongside CAN in mixed automation systems.
• TCP: the reliable transport protocol that underpins higher-layer industrial Ethernet protocols like Modbus TCP and EtherNet/IP.