Are you looking for a straightforward and practical introduction to CAN bus? This Can Bus Guide explains the Controller Area Network (CAN bus) in simple terms, covering everything from the CAN frame structure to higher-layer protocols and techniques for logging and decoding CAN bus data.
Discover why this has become a leading resource for understanding CAN bus technology.
You can also watch our video intro to CAN bus above or download the PDF version.
In this article
Author: Martin Falch (updated January 2025)
Download as PDF
Understanding CAN Bus: What Is It?
CAN bus (Controller Area Network) is a robust communication network widely used in vehicles and machines. Its primary purpose is to enable Electronic Control Units (ECUs) to exchange data without relying on a central host computer. For instance, the CAN bus allows your car’s braking system and engine to share vital information quickly and reliably.
Think of your car as a human body:
- The CAN bus is like the nervous system, facilitating communication between different parts.
- ECUs (also known as ‘CAN nodes’) are akin to individual organs or body parts, all interconnected via the CAN bus. Information gathered by one part can be easily shared with others.
Physically, ECUs connect through a two-wire bus comprising a twisted pair: CAN high and CAN low. These wires often have distinct color codes: CAN high is typically yellow, and CAN low is green.
Delving Deeper: What is an ECU?
Electronic Control Units (ECUs) are the control centers for specific functions within a vehicle or machine, such as engine management, transmission, braking, steering, and temperature regulation. A modern vehicle can contain over 70 ECUs, each communicating with others on the CAN bus.
Any ECU can prepare and broadcast information, like sensor readings. This broadcast data is received by all other ECUs, each of which can then decide whether to accept or ignore it based on its needs.
ECUs typically consist of three main components:
- Microcontroller (MCU): This is the ECU’s “brain,” responsible for interpreting incoming CAN messages and determining which messages to send. For example, a sensor might be programmed to measure and transmit oil temperature data at a specific frequency.
- CAN Controller: Usually integrated into the MCU, the CAN controller ensures that all communication adheres to the CAN protocol, handling message encoding, error detection, and arbitration. This simplifies the tasks for the MCU.
- CAN Transceiver: This component connects the CAN controller to the physical CAN wires, converting data into differential signals suitable for transmission over the CAN bus and vice versa. It also provides electrical protection.
Understanding the CAN bus DB9 connector
How do you connect to a can bus guide system? There isn’t a universal connector for all CAN bus applications. This means different vehicles and machines might use different connectors.
However, the CAN DB9 (D-sub9) connector (CANopen CiA 303-1) is a strong contender and has become a common standard, especially for CAN bus data loggers and interfaces.
Exploring CAN bus Variants
It’s helpful to understand that several CAN variants exist:
- Low-speed CAN: Also known as fault-tolerant CAN, this is a cost-effective option when fault tolerance is crucial. However, it’s increasingly being replaced by LIN bus.
- High-speed CAN: This is the most common type of CAN used today in automotive and machinery applications, and the primary focus of this can bus guide.
- CAN FD (Flexible Data-Rate): CAN FD offers longer payloads and faster speeds, though its adoption is still growing. Learn more in our CAN FD intro.
- CAN XL: This variant offers even longer payloads and faster speeds, bridging the gap between CAN and Automotive Ethernet (100BASE-T1).
In automotive applications, you’ll also encounter other non-CAN networks:
- LIN bus: The LIN bus is a lower-cost alternative to CAN bus, requiring less wiring and cheaper nodes. LIN bus clusters typically consist of a LIN master acting as a gateway and up to 16 slave nodes. It’s often used for non-critical vehicle functions like air conditioning and door functionality. For more, see our LIN bus intro or LIN bus data logger article.
- FlexRay: FlexRay offers higher speeds than CAN (up to 10 Mbit/s), fault tolerance through dual-channel redundancy, and high flexibility, but it’s also more expensive. It’s standardized as per ISO 17458-1 and ISO 17458-5.
- Automotive Ethernet: This is increasingly used in the automotive sector to handle the high bandwidth requirements of ADAS (Advanced Driver Assistance Systems), infotainment systems, and cameras. Automotive Ethernet provides much higher data transfer rates than CAN bus but lacks some of CAN’s safety and performance features. In the coming years, Automotive Ethernet, CAN FD, and CAN XL will likely be used together in new automotive and industrial development.
Key Benefits of CAN Bus
The CAN bus standard is used in nearly all vehicles and many machines due to its key advantages:
Simple & Low Cost
ECUs communicate through a single CAN system instead of complex direct analog signal lines, which reduces errors, weight, wiring, and overall costs.
- Reduced wire complexity: Traditional point-to-point wiring systems require dedicated wires between each related node, which can be costly and inflexible. A good example is NMEA 0183 vs. NMEA 2000.
- Weight reduction: Switching to CAN bus can reduce the weight of a vehicle’s wiring harness by up to 20 kg, which can improve fuel efficiency.
- Scale: The widespread use of CAN reduces the cost of controllers, transceivers, harnesses, and related costs like data acquisition hardware and training.
Easy Access
The CAN bus provides a single point of entry for communicating with all network ECUs, enabling central diagnostics, data logging, and configuration.
- Centralized diagnostics: CAN bus allows you to connect an interface anywhere on the bus to access 100% of the traffic, simplifying diagnostics by eliminating the need to collect data individually for each node.
- Silent CAN logging: CAN bus data logging can be done in “silent mode” without affecting the CAN bus, which is crucial for diagnostics.
- ECU flashing: You can update any ECU on the network via the CAN bus by transmitting firmware or configuration updates as CAN frames using higher-layer protocols like UDS or CCP/XCP.
- Standardization: Most CAN applications share higher-layer protocols that are standardized across manufacturers, enhancing the interoperability of hardware and software tools.
Extremely Robust
The system is resistant to electrical disturbances and electromagnetic interference, making it ideal for safety-critical applications like vehicles.
- Differential signaling: Electromagnetic interference (EMI) affects both lines in the CAN bus two-wire system equally, making the differential signal robust against this type of environmental noise.
- Error handling: CAN ensures data integrity through extensive error detection, including bit errors, stuff errors, CRC errors, form errors, and ACK errors. Nodes can also be set up to automatically retransmit faulty messages.
- Confinement: CAN nodes track their own errors and can temporarily or permanently disconnect from the bus if error thresholds are exceeded (referred to as “bus off”).
Efficient
CAN frames are prioritized by ID, ensuring that high-priority data gets immediate bus access without interrupting other frames or causing CAN errors.
- Arbitration: When multiple CAN nodes try to transmit data simultaneously, the frame with the lowest CAN ID (highest priority) wins, while the others back off and retry. This prevents collisions and ensures that safety-critical messages are prioritized.
- Utilization: Arbitration also helps ensure efficient use of CAN bus bandwidth, effectively filling gaps between critical messages with lower-priority messages.
- Speed: While Classical CAN is relatively slow compared to Automotive Ethernet, it still provides sufficient speed for most automotive and industrial applications. A single 1 Mbit/s CAN bus can handle thousands of CAN frames per second.
A Brief History of CAN Bus
- Pre-CAN: Car ECUs relied on complex point-to-point wiring.
- 1986: Bosch developed the CAN protocol.
- 1991: Bosch published CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29 bit).
- 1993: CAN was adopted as an international standard (ISO 11898).
- 2003: ISO 11898 became a standard series.
- 2012: Bosch released CAN FD 1.0 (flexible data rate).
- 2015: The CAN FD protocol was standardized (ISO 11898-1).
- 2016: The physical CAN layer for data rates up to 5 Mbit/s was standardized in ISO 11898-2 (in practice up to 8 Mbit/s).
- 2018: CiA started developing CAN XL.
- 2024: CAN XL was standardized (ISO 11898-1:2024, 11898-2:2024).
Today, CAN is standard in automotives (cars, trucks, buses, tractors), ships, planes, EV batteries, machinery and more.
The Future of CAN Bus
Looking ahead, the can bus guide protocol will remain important, influenced by these key trends:
- Need for speed: Demand for higher data rates may drive a transition to CAN FD, CAN XL, or Automotive Ethernet.
- Connected vehicles: The rise of cloud computing and vehicle telematics may enable predictive maintenance and remote troubleshooting, but also cybersecurity risks.
- Open vs. closed: A push towards Open Source and Right to Repair may clash with OEM demands to keep data proprietary for subscription-based microservices.
The transition from Classical CAN to CAN FD, CAN XL, or Automotive Ethernet is expected to be slow. As of 2024, less than 0.1% of use cases involve CAN FD, and CAN XL is not yet deployed in the field.
Despite being touted as the successor to Classical CAN back in 2016, CAN FD has not replaced it. While Automotive Ethernet is playing a significant role, Classical CAN remains dominant in vehicles on the road.
Get Our ‘Ultimate CAN Guide’
Want to become a CAN bus expert?
Get our 12 ‘simple intros’ in one 160+ page PDF:
Download now
CAN Physical & Data Link Layer
The Controller Area Network is defined by a data link layer and physical layer. For high-speed CAN, ISO 11898-1 describes the data link layer, while ISO 11898-2 describes the physical layer.
In the context of a 7-layer OSI model, CAN represents the two lowest layers.
Physical Layer (ISO 11898-2)
The CAN bus physical layer defines cable types, electrical signal levels, node requirements, and cable impedance. This layer specifies:
- Baud rate: Nodes connect via a two-wire bus with baud rates up to 1 Mbit/s (Classical CAN) or 8 Mbit/s (CAN FD).
- Cable length: Maximum CAN cable lengths should be between 500 meters (125 kbit/s) and 40 meters (1 Mbit/s).
- Termination: The CAN bus must be terminated using a 120 Ohm termination resistor at each end.
Data Link Layer (ISO 11898-1)
The CAN bus data link layer defines CAN frame formats, error handling, and data transmission to ensure data integrity. This layer specifies:
- Frame formats: Four types (data frames, remote frames, error frames, overload frames) and 11-bit/29-bit identifiers.
- Error handling: Methods for detecting and handling CAN errors, including CRC, acknowledgement slots, and error counters.
- Arbitration: Non-destructive bitwise arbitration helps manage CAN bus access and avoid collisions via ID-based priority.
Anatomy of a CAN Frame
Communication over the CAN bus occurs via CAN frames, as defined by the data link layer.
Below is a standard CAN data frame with an 11-bit identifier (CAN 2.0A), commonly used in most cars. The extended 29-bit identifier frame (CAN 2.0B) is similar but uses a longer ID and is used in protocols like J1939.
The CAN ID and Data fields are crucial when recording CAN bus data.
- SOF (Start of Frame): A ‘dominant 0’ signal indicating that a CAN node intends to transmit.
- ID (Identifier): The frame identifier, with lower values indicating higher priority.
- RTR (Remote Transmission Request): Indicates whether a node is sending data or requesting data from another node.
- Control: Contains the Identifier Extension Bit (IDE), which is a ‘dominant 0’ for 11-bit identifiers, and the 4-bit Data Length Code (DLC) specifying the length of the data bytes (0 to 8 bytes).
- Data: Contains the data bytes or payload, which includes CAN signals to be decoded.
- CRC (Cyclic Redundancy Check): Used to ensure data integrity.
- ACK (Acknowledge Slot): Indicates if the node has acknowledged and received the data correctly.
- EOF (End of Frame): Marks the end of the CAN frame.
Four CAN frame variants exist:
- Data frame: Carries data from a sender CAN node to one or more receiver nodes. 99%+ of use cases focus on CAN data frames.
- Error frame: Used by a CAN node to indicate a communication error, containing an error flag and error delimiter. Some users focus on recording CAN error frames to diagnose ECU communication problems. See our intro to CAN errors.
- Remote frame: Requests data from a CAN node and is similar to the data frame, but lacks a Data field and has an RTR field of 1 (recessive). Remote frames are used rarely.
- Overload frame: Provides additional delay between CAN frames if some nodes need more processing time. Overload frames are almost never used.
The CAN frame must meet certain properties to be valid. Erroneous CAN frames are automatically detected by CAN nodes, which take action accordingly. This is known as CAN bus error handling, where CAN nodes track their ‘CAN error counters’ and change state (active, passive, bus off) depending on these counters. This reduces the ability of problematic CAN nodes to transmit data to avoid further errors and bus jamming. See our intro to CAN bus error handling for more information.
Diving into Higher-Layer CAN Protocols
CAN, as a lower-layer protocol, provides a foundation for communication but lacks specifications for handling messages larger than 8 bytes or decoding raw data.
Therefore, higher-layer protocols detail how data is communicated between CAN nodes within a specific network.
Here’s an overview of common automotive and industrial CAN protocols:
OBD2
On-board diagnostics are used in cars and trucks for diagnostics, maintenance, and emissions tests. It specifies diagnostic trouble codes (DTCs) and real-time data (speed, RPM).
UDS
Unified Diagnostic Services (UDS) is used in automotive ECUs to enable diagnostics, firmware updates, and routine testing.
CCP/XCP
The CAN Calibration Protocol (CCP) and Universal Measurement and Calibration Protocol (XCP) enable read/write ECU access for calibration, measurement, and flashing.
CANopen
CANopen is used widely in embedded control applications, including industrial automation, to enable interoperability between CAN nodes (devices).
SAE J1939
J1939 is used in heavy-duty vehicles. Parameters like ‘speed’ are identified by a suspect parameter number (SPN), grouped by parameter group numbers (PGN).
NMEA 2000
NMEA 2000 is used in the maritime industry for connecting engines, instruments, and sensors on boats. It’s based on CAN and closely linked to J1939.
ISOBUS
ISO 11783 is used in agriculture and forestry machinery, enabling plug-and-play integration between vehicles and implements across brands. It’s closely linked to J1939.
The distinction between CAN bus and higher-layer protocols can be confusing.
Think of people communicating:
In this context, CAN bus defines the physical requirements (like vocal chords and the ability to make sounds) and basic building blocks like letters in the alphabet and grammar. Higher-layer protocols reflect different languages like German or English, using these basics to build meaningful words and sentences.
- Always a higher-layer protocol: In practical applications, there is always a higher-layer protocol in use.
- Thousands of protocols exist: Like languages, thousands of higher-layer protocols exist. We’ve listed some of the most common, but many more exist – including protocols that are manufacturer/application specific aka ‘custom protocols’.
- Recording vs. understanding data: A sound recorder can record any human conversation, just like how a CAN bus data logger can record any CAN-based communication. But to interpret the information, you need to understand the language (i.e., the higher-layer protocol).
- Multiple protocols: Your car uses a CAN-based higher-layer protocol for communicating most of its data between ECUs. But in addition to this car-specific CAN protocol, the car may also communicate on the same CAN bus via OBD2 or UDS for standardized diagnostics or emissions testing.
- Interoperability: Standardized higher-layer protocols provide interoperability across applications and devices.
Other commonly encountered higher-layer CAN protocols include:
- ARINC: Used in the aerospace industry.
- UAVCAN: Open-source protocol often used in drones, aerospace, and robotics.
- DeviceNet: Used in industrial automation (sensors, actuators), particularly in North America.
- SafetyBUS p: Used in safety-critical industrial automation, such as car production and cable cars.
- MilCAN: Designed for military vehicles and harsh environments, offering deterministic data transmission.
- HVAC CAN: Designed for Heating, Ventilation, and Air Conditioning (HVAC) systems in buildings and vehicles.
Logging CAN Bus Data: A Step-by-Step Guide
Here are 4 critical steps to logging raw CAN bus data.
#1: Selecting the Right Hardware
First, determine how you want to collect the CAN data:
Learn more in above 5 min CANedge intro – or our webinar on CAN logging
#2: Identifying the Adapter Cable
Next, determine the appropriate adapter cable. This depends on the application, but here are 4 common options:
OBD2 Adapter
For most cars (and some vans/trucks), this allows you to request OBD2/UDS data and potentially access the car’s proprietary CAN data.
J1939 Adapter
In most heavy-duty vehicles (trucks, buses, excavators, tractors), this provides access to raw CAN data (J1939 protocol).
M12 Adapter
In most maritime vessels (ships, boats) and some industrial machinery, this lets you record raw CAN data (NMEA 2000 or CANopen).
Contactless Reader
A universal option is to skip the connector entirely and use induction to read data from the CAN high/low wiring directly.
Choosing the right adapter can be simple or complex, depending on your use case. Here are some additional tips:
Cars
If you want to log data from your car, you’ll likely need the OBD2 adapter. This lets you request OBD2 data from most non-EV cars after 2008, such as RPM, speed, and fuel level. If your car is an EV, you might be able to perform UDS requests using the OBD2 adapter. Similarly, if you’re looking to reverse engineer proprietary CAN data, you can use the OBD2 adapter if your car provides access to the proprietary CAN data through the OBD2 connector. However, this is not always the case. You may need to use a contactless CAN reader.
Heavy-Duty Vehicles
In heavy-duty vehicles, the J1939 adapter is most commonly used. If you find a black/green 9-pin deutsch J1939 connector in your vehicle, you can use this adapter. However, many vehicle brands use other connectors, like the Caterpillar 9-pin connector. We generally recommend getting both a J1939 adapter and a contactless CAN reader to provide multiple connection options. In some heavy-duty vehicles, a single J1939 9-pin connector may provide access to two CAN buses; in this case, you can consider the J1939-DB9/DB9 adapter. In some trucks (e.g., from Volvo), you can access J1939 data via the OBD2 connector. Here, our OBD2-DB9/DB9 adapter can be useful.
Maritime Vessels
In marine vessels, you will most often encounter the M12 connector, which provides access to the NMEA 2000 data of the boat/ship. In some cases, you may want to collect data directly from the vessel engines. In this scenario, you can use the J1939 adapter or DT06 adapter.
Industrial Machinery
In non-automotive industrial machinery, you can often use the M12 adapter. You may also encounter the standard DB9 connector, but ensure that it’s for CAN access and not an RS232 interface.
Agriculture
In tractors, you can typically use the J1939 adapter to record J1939 data from the vehicle. However, you may also want to collect ISOBUS data in parallel. Here, a J1939-DB9/DB9 adapter (H+J) can be used as it provides access to both the tractor’s J1939 network and the ISOBUS network related to the tractor implement. Alternatively, you may use the in-cab adapter to access the ISOBUS network.
