CAN Bus Explained (2025): Frames, Arbitration & Tools

CAN bus is used in many vehicles, machines and embedded systems to let electronic modules exchange control data.

Instead of wiring every sensor, switch and actuator directly to every other module, CAN lets multiple devices share the same two-wire network.

At AutoPi, we work with CAN bus in passenger cars, trucks, EVs, industrial machines, off-highway equipment and special purpose vehicles.

In most projects, the goal is not only to understand CAN bus in theory. The goal is to connect to the bus, log the traffic, decode useful signals and move the data into a dashboard, cloud platform or customer backend.

This guide explains CAN bus from a practical point of view. It covers what CAN bus is, why it is used, how messages are sent, how frames are structured and what matters when logging or decoding CAN data with hardware such as the AutoPi CAN-FD Pro or Raspberry Pi based AutoPi devices.

The article is written for engineers, developers, technical buyers and project teams working with vehicle data, telematics, automotive data loggers or embedded systems based on Controller Area Network.

What is CAN bus?

CAN bus stands for Controller Area Network.

It is a serial communication protocol that allows ECUs, sensors, actuators and other electronic devices to communicate without a central host computer.

CAN was developed by Bosch in the 1980s and later standardized in the ISO 11898 serie.

Today, it is one of the most common communication protocols in vehicles and machinery because it is robust, predictable and well suited for real-time control.

CAN bus is message-based. A node does not send data to a specific address like in many computer networks.

Instead, it broadcast a message with an identifier. All nodes on the bus receive the message, and each node decide if the message is relevant.

Before CAN bus, vehicle electronics used more point-to-point wiring. Each function needed dedicated wires between switches, sensors, relays, actuators and control units.

As vehicles got more electronic systems, the wiring harness became heavier, more expensive and more difficult to service.

CAN bus reduced this complexity. Multiple modules could now exchange data over the same pair of wires.

This made it easier to add new functions, reduce harness weight and keep communication predictable between electronic systems.

Today, CAN bus is still used in modern vehicles even when other networks are present. A newer vehicle may use CAN, CAN FD, LIN, Automotive Ethernet and other protocols at the same time.

CAN is still commonly used where control signals need low latency, predictable timing and reliable delivery.

Why is CAN bus important?

CAN bus is important because it gives independent electronic modules a common way to work together.

A braking system, powertrain controller, battery management system, telematics unit and dashboard can all use CAN messages to share status and control data.

1. Less wiring: Many signals can share one twisted pair instead of using seperate wiring for every function. This reduces harness complexity and makes platform variants easier to manage.
2. Lower system cost: Less copper, fewer connectors and simpler harness layouts can reduce production, installation and service cost.
3. Reliable communication: CAN includes error detection, acknowledgement, retransmission and fault confinement. A faulty node can be isolated by the protocol instead of blocking the whole network permanently.
4. Prioritized traffic: CAN uses message identifiers for arbitration. Lower identifier values have higher priority, so critical messages can win access to the bus before less critical traffic.

These properties make CAN bus useful in vehicles, mobile machinery, industrial control systems, agricultural machines and other environments where electrical noise, vibration and temperature changes are normal.

Real-world CAN bus example

A common example is braking in a modern vehicle.

When the driver presses the brake pedal, a sensor measures the input and sends data to a control module. Other modules then use related CAN messages to coordinate their own functions.

• Brake lights: The body control module activates the brake lights.
• ABS and ESP: The ABS/ESP module monitors wheel speed and controls hydraulic braking if a wheel starts locking.
• Powertrain: The powertrain controller may reduce torque.
• Regenerative braking: In a hybrid or electric vehicle, regenerative braking may be adjusted by the drivetrain or battery system.

The same pattern is used across many vehicle systems.

Steering angle, throttle position, gearbox status, wheel speeds, battery data, temperatures and fault states are all exchanged as messages.

In many vehicles, these messages are split across multiple CAN networks with gateway ECUs between them.

How does CAN bus work?

CAN bus works as a broadcast network. Every node can transmit, and every node can listen.

A message contains an identifier, data bytes and protocol fields used for arbitration, acknowledgement and error checking.

The identifier is important because it defines both the meaning and the priority of the message.

A node does not need to process every frame. It can filter messages by identifier and only act on the traffic that is relevant to its function.

This identifier-based design is also why higher-layer protocols such as SAE J1939, CANopen and ISO 11783/ISOBUS can be built on top of CAN.

Core parts of a CAN network:

• Nodes: ECUs, sensors, actuators, gateways, displays, telematics units or data loggers connected to the bus. Each node has a CAN controller and CAN transceiver.
• Bus: The shared twisted pair, normally called CAN_H and CAN_L, with correct termination at both ends of the main bus.
• Messages: Frames containing an identifier, control information, payload data and error checking. The payload is decoded using a signal definition, higher-layer protocol or OEM-specific knowledge.

At a high level, communication works like this:

• A node transmits: A node places a frame on the bus when it has data to send.
• Arbitration decides priority: If two nodes transmit at the same time, the message with the highest priority continues. The other node stops and retries later.
• All nodes receive the frame: Each node reads the message and decides if it should use or ignore it.
• Errors are detected: CAN controllers check the frame. If an error is detected, an error frame is sent and the original message is retransmitted.

CAN bus explained with simple analogies

The nervous system analogy

CAN bus is often compared to the nervous system of a machine.

The comparison is not perfect, but it helps explain the basic idea: different parts of the system exchange short messages so the machine can react as one coordinated unit.

The highway analogy

CAN can also be compared to a road shared by many vehicles. The bus is the road, and CAN messages are the vehicles using it.

A simple CAN network can be imagined as one main cable with several nodes connected along it.

The bus must be wired correctly, with suitable cable, short stubs and termination at both ends. If the wiring is wrong, the protocol may still be correct, but the network can become unstable.

CAN bus protocol

The CAN protocol defines how data is transmitted on the bus.

It covers frame structure, arbitration, acknowledgement, error checking and fault handling.

It does not define what every payload byte means. That part is normally handled by a higher-layer protocol or by an OEM-specific signal database.

Classical CAN supports up to 8 data bytes per frame. CAN FD extends this to up to 64 data bytes and allows a faster data phase.

This is one reason CAN FD is used in newer vehicles where more data needs to be moved without replacing the complete CAN-based architecture.

The protocol is standardized mainly through the ISO 11898 serie:

• ISO 11898-1: Data link layer and general CAN frame handling.
• ISO 11898-2: High-speed CAN physical layer.
• ISO 11898-3: Low-speed, fault-tolerant CAN physical layer.

In practice, this means CAN devices from different suppliers can communicate as long as they follow the same bit rate, physical layer, wiring and timing rules.

CAN message frame

A CAN frame is the packet format used to transmit data.

Understanding the frame fields is useful when working with raw CAN logs, debugging bus traffic or building a signal decoder.

A standard CAN data frame contains:

A raw CAN frame from a logger may look simple, for example:

can0 123 [8] 01 0A 3F 00 00 7C 10 FF

By itself, this only tells you the interface, identifier, length and data bytes.

To turn this into useful information, you need to know how the payload is encoded. That usually requires a DBC file, protocol definition or reverse engineering work.

Common CAN frame types include:

For CAN diagnostics, reverse engineering and data logging, the frame is the starting point.

The useful information comes after decoding: RPM, state of charge, hydraulic pressure, temperature, fault status, operating mode or any other signal encoded by the system designer.

CAN bus wiring

CAN wiring affects reliability as much as the protocol itself.

A correct decoder or data logger cannot fix a poorly wired bus.

Missing termination, long stubs, bad grounding or unsuitable cable can result in intermittent errors and bus-off states.

A typical high-speed CAN bus uses:

• Linear bus topology: The main CAN bus should normally run as one main line.
• Short stubs: Connections from the main bus to each node should be kept short.
• Twisted pair: CAN_H and CAN_L are normally routed as a twisted pair.
• 120 Ω termination: The main bus should normally have termination at both ends.

Twisted pair cabling improves noise immunity because CAN uses differential signaling.

The receiver looks at the voltage difference between CAN_H and CAN_L instead of measuring each wire independently.

Termination resistors reduce signal reflections.

For most high-speed CAN networks, the expected resistance across CAN_H and CAN_L is around 60 Ω when the bus is powered down and both 120 Ω terminators are present in parallel.

In field work, wiring problems often show up as increasing error counters, intermittent communication, missing frames or controllers entering bus-off state.

On Linux-based systems, tools such as ip -details link show can0, candump and can-utils are commonly used to inspect bus behaviour.

Types of CAN bus systems

CAN exists in several variants.

The right type depends on speed, fault tolerance, network length and the kind of system being built.

High-speed CAN

High-speed CAN, defined in ISO 11898-2, is used for time-critical communication.

Classical high-speed CAN supports bit rates up to 1 Mbit/s. Typical use cases include:

• Engine control: Used for time-critical powertrain communication.
• Transmission control: Used to exchange gear, torque and state information.
• ABS, ESP and chassis systems: Used where braking and stability data needs predictable timing.
• Battery management systems: Used in EVs and hybrids for battery status and control data.
• Telematics and data logging: Used to collect CAN traffic for monitoring, debugging or backend systems.

Low-speed / fault-tolerant CAN

Low-speed or fault-tolerant CAN, defined in ISO 11898-3, is used where communication is less time-critical but the system must tolerate certain wiring faults.

It is typically used for body and comfort electronics.

• Door modules: Used for local body electronics and status signals.
• Window and mirror controls: Used for comfort functions where high speed is not needed.
• Seat modules: Used for seat adjustment, memory and local control.
• Climate and comfort functions: Used for body systems with lower timing requirements.

CAN FD

CAN FD stands for CAN Flexible Data-rate. It extends classical CAN by allowing a larger payload and a faster data phase.

• Classical CAN: Supports up to 8 data bytes per frame.
• CAN FD payload: Supports up to 64 data bytes per frame.
• CAN FD data phase: Can use a faster bit rate during the data phase.

CAN FD is useful in newer vehicles and machines where more telemetry must be moved without replacing the complete CAN architecture.

It is relevant for EV battery data, higher-resolution sensor values, advanced diagnostics and systems where classical CAN payload size becomes limiting.

What is CAN bus used for?

CAN bus is used wherever multiple electronic modules need reliable real-time communication.

Automotive is the most common example, but CAN is also used in industrial, agricultural, maritime, medical and off-highway systems.

Automotive examples

• Powertrain: Engine, transmission, hybrid modules and battery systems exchange torque requests, speed, temperature, load and operating state.
• Chassis: ABS, traction control, steering angle sensors and stability systems share data for braking and handling functions.
• Body systems: Lighting, doors, windows, seats, climate control and instrument clusters use CAN or related in-vehicle networks for control and status.
• Diagnostics and telematics: Service tools and data loggers use CAN access to read fault codes, collect live data and record operational behaviour.

Industrial and machine examples

• Industrial automation: CAN-based protocols such as CANopen are used for motion control, sensors and distributed I/O.
• Agriculture: Tractors and implements use CAN-based systems such as ISOBUS for implement control and machine data.
• Off-highway and mining: Heavy machines use CAN and J1939-style communication for engine, hydraulic, drivetrain and telematics data.
• Medical and laboratory equipment: CAN is used in internal control systems where predictable timing and robust communication are required.

Strengths and weaknesses of CAN bus

CAN bus is reliable and widely used, but it is not the right technology for every task.

It works best for control messages, status values, diagnostics and telemetry.

It is not designed for large data streams such as raw camera, lidar or radar data.

Strengths of CAN bus

Weaknesses of CAN bus

Using AutoPi for CAN bus logging

Understanding CAN bus is useful, but most projects eventually need data.

That usually means connecting a logger, recording raw CAN traffic, decoding selected signals and sending the result to a dashboard, file export, cloud platform or customer backend.

The AutoPi CAN-FD Pro is built for projects where CAN, CAN FD, LIN, OBD2 and J1939 data logging are required.

It can be used to capture raw frames, decode known signals and forward data for analysis or remote monitoring.

Typical CAN logging workflows include:

• Connect to the network: Connect to the target CAN or CAN FD network.
• Check the bus: Confirm bitrate, termination and bus activity.
• Record raw frames: Log CAN frames for a representative operating period.
• Decode known signals: Use DBC files or protocol definitions where they are available.
• Export the data: Export as CSV, JSON or another format used by the project.
• Send selected signals: Send useful data to AutoPi Cloud or an external backend.

Examples of useful decoded signals include RPM, speed, torque, state of charge, hydraulic pressure, battery temperature, fault status, operating mode, fuel rate and machine working state.

The exact signals depend on the vehicle or machine and whether the signal definitions are available.

AutoPi’s Raspberry Pi based devices are useful when the project needs a Linux environment close to the vehicle data.

This makes it possible to run scripts, process data locally, integrate with APIs or forward selected signals using protocols such as MQTT or HTTP.

• SocketCAN: Use SocketCAN interfaces such as can0 for Linux-based CAN access.
• Linux CAN tools: Use tools such as candump and cansend during testing and debugging.
• Custom scripts: Run custom Python scripts for filtering, decoding or forwarding selected data.
• System integrations: Integrate with AutoPi Cloud, REST APIs, MQTT brokers or customer systems.

A practical introduction to Raspberry Pi and CAN bus, including SocketCAN setup and basic examples, is available here: Raspberry Pi CAN bus explained.

Discover AutoPi CAN-FD Pro

The future of CAN bus

CAN bus is not disappearing.

It is becoming part of more mixed network architectures. Modern vehicles often combine CAN, CAN FD, LIN, Automotive Ethernet and secure gateways.

Each network type is used where it makes technical and economic sense.

CAN and CAN FD remain strong for control signals, diagnostics, telemetry and local communication inside vehicle zones.

Automotive Ethernet is better suited for high-bandwidth data such as cameras, lidar and large software update flows.

EVs, heavy equipment and connected vehicles are increasing the demand for CAN data logging.

Battery systems, thermal management, energy use, fault behaviour and machine utilization can all be analyzed when CAN data is collected and decoded correctly.

Security is also becoming more important. As more vehicles and machines connect to cloud services, CAN access must be handled carefully.

Telematics systems need controlled access, filtering and secure communication between the vehicle and backend systems.

Planning a CAN bus logging project

A CAN logging project should start with a clear scope.

Before choosing hardware or building dashboards, define what data is needed and how it will be used.

• Vehicle or machine: Which vehicle or machine will be logged?
• Networks: Which CAN networks need to be accessed?
• Protocol: Is the traffic classical CAN, CAN FD, J1939, OBD2, CANopen or another protocol?
• Signal definitions: Do you have a DBC file or signal description?
• Data format: Should the logger store raw frames, decoded signals or both?
• Data destination: Should the data be stored locally, uploaded to AutoPi Cloud or sent to an external backend?

Answering these questions early makes the project easier to specify and avoids collecting large amounts of CAN data without a clear way to use it.

AutoPi helps customers select hardware, define logging strategies, decode relevant signals and integrate CAN data with cloud services or existing software systems.