CAN Bus Explained – A Simple Intro [2023]

What is CAN bus?

Your car is like a human body:

The Controller Area Network (CAN bus) is
the nervous system, enabling communication.

In turn, ‘nodes’ or ‘electronic control units’ (ECUs) are like parts of the body, interconnected via the CAN
bus. Information sensed by one part can be shared with another.

So what is an ECU?

In an automotive CAN bus system, ECUs can e.g. be the engine control unit, airbags, audio system etc. A modern
car may have up to 70 ECUs – and each of them may have information that needs to be shared
with other parts of the network.

This is where the CAN standard comes in handy:

The CAN bus system enables each ECU to communicate with all other ECUs – without complex dedicated wiring.

Specifically, an ECU can prepare and broadcast information (e.g. sensor data) via the CAN bus (consisting of
two wires, CAN low and CAN high). The broadcasted data is accepted by all other ECUs on the CAN network – and
each ECU can then check the data and decide whether to receive or ignore it.

CAN bus physical & data link layer (OSI)

In more technical terms, the controller area network is described by a data link layer and physical layer. In the case of
high speed CAN, ISO 11898-1 describes the data link layer, while ISO 11898-2 describes the physical
layer. The role of CAN is often
presented in the 7 layer OSI model as per the illustration.

The CAN bus physical layer defines things like cable types, electrical signal levels, node requirements, cable
impedance etc. For example, ISO 11898-2 dictates a number of things, including below:

• Baud rate: CAN nodes must be connected via a two wire bus with baud rates up to 1 Mbit/s
  (Classical CAN) or 5 Mbit/s (CAN
  FD)
• Cable length: Maximal CAN cable lengths should be between 500 meters (125 kbit/s) and 40
  meters (1 Mbit/s)
• Termination: The CAN bus must be properly terminated using a 120 Ohms CAN bus termination
  resistor at each end of the bus

In the context of automotive vehicle networks, you’ll often encounter a number of different types of network
types. Below we provide a very brief outline:

• High speed CAN bus: The focus of this article is on high speed CAN bus (ISO 11898). It is by
  far the most popular CAN standard for the physical layer, supporting bit rates from 40 kbit/s to 1 Mbit/s
  (Classical CAN). It provides simple cabling and is used in practically all automotive applications today. It
  also serves as the basis for several higher layer protocols such
  as OBD2, J1939, NMEA 2000, CANopen etc. The second
  generation
  of CAN is referred to as CAN FD
  (CAN with Flexible Data-rate)
• Low speed CAN bus: This standard enables bit rates from 40 kbit/s to 125 kbit/s and allows
  the CAN bus commmunication to continue even if there is a fault on one of the two wires – hence it is also
  referred to as ‘fault tolerant CAN’. In this system, each CAN node has it’s own CAN termination
• LIN bus: LIN bus is a lower cost supplement to CAN bus networks, with less harness and
  cheaper nodes. LIN bus clusters typically consist of a LIN master acting as gateway and up to 16 slave nodes.
  Typical use cases include e.g. non-critical vehicle functions like aircondition, door functionality etc. – for
  details see our LIN bus intro
  or LIN bus data logger article
• Automotive ethernet: This is increasingly being rolled out in the automotive sector to
  support the high bandwidth requirements of ADAS (Advanced Driver Assistance Systems), infotainment systems,
  cameras etc. Automotive ethernet offers much higher data transfer rates vs. CAN bus, but lacks some of the
  safety/performance features of Classical CAN and CAN FD. Most likely,
  the coming years will see both automotive ethernet, CAN FD and CAN
  XL being used in new automotive and industrial development

Top 4 benefits of CAN bus

The CAN bus standard is used in practically all vehicles and many machines due to below key benefits:

Simple & low cost

ECUs communicate via a single CAN system instead of via direct complex analogue signal lines – reducing errors,
weight, wiring and costs

Easy access

The CAN bus provides ‘one point-of-entry’ to communicate with all network ECUs – enabling central diagnostics,
data logging and configuration

Extremely robust

The system is robust towards electric disturbances and electromagnetic interference – ideal for safety critical
applications (e.g. vehicles)

Efficient

CAN frames are prioritized by ID so that top priority data gets immediate bus access, without causing
interruption of other frames or CAN errors

The CAN bus history in short

• Pre CAN: Car ECUs relied on complex point-to-point wiring
• 1986: Bosch developed the CAN
  protocol as a solution
• 1991: Bosch published CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29 bit)
• 1993: CAN is adopted as international standard (ISO 11898)
• 2003: ISO 11898 becomes a standard series
• 2012: Bosch released the CAN FD 1.0 (flexible data
  rate)
• 2015: The CAN FD protocol is standardized (ISO 11898-1)
• 2016: The physical CAN layer for data-rates up to 5 Mbit/s standardized in ISO 11898-2

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 protocol will stay relevant – though it will be impacted by major trends:

• A need for increasingly advanced vehicle functionality
• The rise of cloud computing
• Growth in Internet of Things (IoT) and connected vehicles
• The impact of autonomous
  vehicles

In particular, the rise in connected vehicles (V2X) and cloud will lead to a rapid growth in
vehicle
telematics and IoT
CAN loggers.

In turn, bringing the CAN bus network ‘online’ also exposes vehicles to security risks – and
may require a shift to new CAN protocols like CAN FD.

As vehicle functionality expands, so does the load on the CANbus. To support this, CAN FD (Flexible Data
Rate) has been designed as the ‘next generation’ CAN bus.

Specifically, CAN FD offers three benefits (vs Classical CAN):

• It enables data rates up to 8 Mbit/s (vs 1 Mbit/s)
• It allows data payloads of up to 64 bytes (vs 8 bytes)
• It enables improved security via authentication

In short, CAN FD boosts speed and efficiency – and it is therefore being rolled out in newer vehicles. This
will also drive an increasing need for IoT CAN FD data
loggers.

“The first cars using CAN FD will appear in 2019/2020 and CAN FD will
replace step-by-step Classical CAN”

– CAN in Automation (CiA), “CAN 2020: The Future of CAN Technology”

Learn
more

What is a CAN frame?

Communication over the CAN bus is done via CAN frames.

Below is a standard CAN frame with 11 bits identifier (CAN 2.0A), which is the type used in most cars. The extended
29-bit identifier frame (CAN 2.0B) is identical except the longer ID. It is e.g. used in the J1939 protocol for
heavy-duty vehicles.

Note that the CAN ID and Data are highlighted – these are important when recording CAN bus data, as we’ll see below.

• SOF: The Start of Frame is a ‘dominant 0’ to tell the other nodes that a CAN node intends to
  talk
• ID: The ID is the frame identifier – lower values have higher priority
• RTR: The Remote Transmission Request indicates whether a node sends data or requests
  dedicated data from another node
• Control: The Control contains the Identifier Extension Bit (IDE) which is a ‘dominant 0’ for
  11-bit. It also contains the 4 bit Data Length Code (DLC) that specifies the length of the data bytes to be
  transmitted (0 to 8 bytes)
• Data: The Data contains the data bytes aka payload, which includes CAN signals that can be
  extracted and decoded for information
• CRC: The Cyclic Redundancy Check is used to ensure data integrity
• ACK: The ACK slot indicates if the node has acknowledged and received the data correctly
• EOF: The EOF marks the end of the CAN frame

The CAN frame has to satisfy a number of properties to be valid. If an erroneous CAN frame is transmitted, CAN
nodes will automatically detect this and take action accordingly. This is referred to as CAN bus error handling,
in which CAN nodes keep track of their own ‘CAN error counters’ and change state (active, passive, bus off)
depending on their counters. The ability of problematic CAN nodes to transmit data is thus gracefully reduced to
avoid further CAN errors and bus jamming. For details, see our intro to CAN bus error handling.

Logging CAN data – example use cases

There are several common use cases for recording CAN bus data frames:

Logging/streaming data from cars

OBD2 data from cars can e.g. be used to reduce fuel costs, improve driving, test prototype parts and insurance

obd2
logging

Heavy duty fleet telematics

J1939 data from trucks, buses, tractors etc. can be used in fleet management to reduce costs or improve safety

j1939 telematics

Predictive maintenance

Vehicles and machinery can be monitored via IoT CAN loggers in the cloud to predict and avoid breakdowns

predictive
maintenance

Vehicle/machine blackbox

A CAN logger can serve as a ‘blackbox’ for vehicles or equipment, providing data for e.g. disputes or
diagnostics

can bus blackbox

Do you have a CAN logging use case? Reach out for free sparring!

Contact us

How to log CAN bus data

Example: CANedge CAN logger

The CANedge1 lets you easily
record data from any CAN bus to an 8-32 GB SD card. Simply connect it to e.g. a car or truck to start logging –
and decode the data via free
software/APIs.

Further, the CANedge2
adds WiFi, letting you auto-transfer data to your own server – and update devices over-the-air.

learn about the
CANedge

How to decode raw CAN data to ‘physical values’

If you review the raw CAN bus data sample above, you will probably notice something:

Raw CAN bus data is not human-readable.

To interpret it, you need to decode the CAN frames into scaled engineering values aka
physical values (km/h, degC, …).

Below we show step-by-step how this works:

Each CAN frame on the bus contains a number of CAN signals (parameters) within the CAN
databytes. For example, a CAN frame with a specific CAN ID may carry data for e.g. 2 CAN signals.

To extract the physical value of a CAN signal, the following information is required:

• Bit start: Which bit the signal starts at
• Bit length: The length of the signal in bits
• Offset: Value to offset the signal value by
• Scale: Value to multiply the signal value by

To extract a CAN signal, you ‘carve out’ the relevant bits, take the decimal value and perform a linear scaling:

physical_value = offset + scale * raw_value_decimal

Most often, the CAN bus “decoding rules” are proprietary and not easily available (except to the OEM, i.e.
Original Equipment Manufacturer). There are a number of solutions to this when you’re not the OEM:

• Record J1939 data: If you’re logging raw data from heavy duty vehicles (trucks, tractors,
  …), you’re typically recording J1939 data. This is standardized across brands – and you can use our J1939 DBC file to decode data. See also
  our J1939
  data logger intro
• Record OBD2/UDS data: If you need to log data from cars, you can typically request OBD2/UDS
  data, which is a standardized protocol across cars. For details see our OBD2 data logger intro
  and our free OBD2 DBC file
• Use public DBC files: For cars, online databases exist where others have reverse engineered
  proprietary some of the CAN data. We keep a list of such databases in our DBC file intro
• Reverse engineer data: You can also attempt to reverse engineer data yourself by using a CAN bus sniffer, though
  it can be time consuming and difficult
• Use sensor modules: In some cases you may need sensor data that is not available on the CAN
  bus (or which is difficult to reverse engineer). Here, sensor-to-CAN modules like the CANmod series can be
  used. You can integrate such modules with your CAN bus, or use them as add-ons for
  your CAN logger to add data such as GNSS/IMU or temperature data
• Partner with the OEM: In some cases the OEM will provide decoding rules as part of the CAN
  bus system technical specs. In other cases you may be able to get the information through e.g. a partnership

Note: If you need to load, edit or create new DBC files, check out our free online DBC file editor.

In some cases, conversion rules are standard across manufacturers – e.g. in the J1939 protocol for
heavy-duty.

This means that you can use the J1939 parameter conversion rules on practically any heavy-duty vehicle to
convert a large share of your data. To make this practical, you need a format for storing the conversion
rules. Here, the CAN database (DBC)
format is the industry standard – and is supported by most CAN
bus decoder software incl. the supporting tools for our CAN loggers, asammdf and CANvas.

We also offer a low cost J1939 DBC file, which you can purchase as a digital download. With this, you can
get quickly from raw J1939 data to human-readable form.

j1939 dbc

To illustrate how you can extract CAN signals from raw CAN data frames, we include below the previous J1939 sample
data – but now decoded via a J1939 DBC file
using the asammdf GUI tool.

As evident, the result is timeseries data with parameters like oil temperature, engine speed, GPS, fuel rate and
speed:

For more on logging J1939 data, see our J1939 data
logger and mining
telematics articles. You can also learn how to analyze/visualize your CAN data via the free asammdf GUI tool or telematics dashboards.

What is the link between CAN, J1939, OBD2, CANopen, …?

The Controller Area Network provides the basis for communication – but not a lot more.

For example, the CAN standard does not specify how to handle messages larger than 8 bytes – or how to decode the raw
data. Therefore a set of standardized protocols exist to further specify how data is communicated
between CAN nodes of a given network.

Some of the most common standards include SAE J1939, OBD2 and CANopen. Further, these higher-layer protocols will
increasingly be based on the ‘next generation’ of CAN, CAN FD (e.g. CANopen FD and J1939-17/22).

In addition to the above, the following CAN based higher layer protocols are relevant:

• Unified Diagnostic Services (UDS): A communication protocol used in ECUs to enable e.g. diagnostics
• NMEA 2000: A protocol used in most modern maritime vessels with similarities to J1939
• CCP/XCP on CAN: These protocols are commonly used in prototype development for ECU measurement/calibration

For more intros, see our guides section – or download the
‘Ultimate Guide’ PDF.

Need to log/stream CAN bus data?

Get your CAN logger today!

Recommended for you