CAN Bus Explained - A Simple Intro [2023]
Need a simple, practical intro to CAN bus?
In this tutorial we explain the Controller Area Network (CAN bus) 'for dummies' incl. message interpretation, CAN logging - and the link to OBD2, J1939 and CANopen.
Read on to learn why this has become the #1 guide on CAN bus.
You can also view our CAN protocol intro above or get the PDF.
In this article
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
- The use of AI in data analysis (see e.g. our ChatGPT + CAN bus intro)
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 moreWhat 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 loggingHeavy duty fleet telematics
J1939 data from trucks, buses, tractors etc. can be used in fleet management to reduce costs or improve safety
j1939 telematicsPredictive maintenance
Vehicles and machinery can be monitored via IoT CAN loggers in the cloud to predict and avoid breakdowns
predictive maintenanceVehicle/machine blackbox
A CAN logger can serve as a 'blackbox' for vehicles or equipment, providing data for e.g. disputes or diagnostics
can bus blackboxDo you have a CAN logging use case? Reach out for free sparring!
Contact usHow to log CAN bus data
As mentioned, two CAN fields are important for CAN logging:
The CAN ID and the
Data.
To record CAN data you need a CAN logger. This lets you log timestamped CAN data to an SD card. In some cases, you need a CAN interface to stream data to a PC - e.g. for car hacking.
This first step is to connect your CAN logger to your CAN bus. Typically this involves using an adapter cable:
- Cars: In most cars, you simply use an OBD2 adapter to connect. In most cars, this will let you log raw CAN data, as well as perform requests to log OBD2 or UDS (Unified Diagnostic Services) data
- Heavy duty vehicles: To log J1939 data from trucks, excavators, tractors etc you can typically connect to the J1939 CAN bus via a standard J1939 connector cable (deutsch 9-pin)
- Maritime: Most ships/boats use the NMEA 2000 protocol and enable connection via an M12 adapter to log marine data
- CANopen: For CANopen logging, you can often directly use the CiA 303-1 DB9 connector (i.e. the default connector for our CAN loggers), optionally with a CAN bus extension cable
- Contactless: If no connector is available, a typical solution is to use a contactless CAN reader - e.g. the CANCrocodile. This lets you log data directly from the raw CAN twisted wiring harness, without direct connection to the CAN bus (often useful for warranty purposes)
- Other: In practice, countless other connectors are used and often you'll need to create a custom CAN bus adapter - here a generic open-wire adapter is useful
When you've identified the right connector and verified the pin-out, you can connect your CAN logger to start recording data. For the CANedge/CLX000, the CAN baud rate is auto-detected and the device will start logging raw CAN data immediately.
You can optionally download raw OBD2 and J1939 samples from the CANedge2 in our intro docs. You can e.g. load this data in the free CAN bus decoder software tools.
Data from the CANedge is recorded in the popular binary format, MF4, but can be converted to any file format via our simple MF4 converters (e.g. to CSV, ASC, TRC, ...).
Below is a CSV example of raw CAN frames logged from a heavy-duty truck using the J1939 protocol. Notice that the CAN IDs and data bytes are in hexadecimal format:
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 (WiFi) and CANedge3 (3G/4G) let you push data to your own server - and update devices over-the-air.
learn about the CANedgeHow 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 like asammdf.
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 dbcTo 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).
SAE J1939
J1939 is the standard in-vehicle network for heavy-duty vehicles (e.g. trucks & buses). J1939 parameters (e.g. RPM, speed, ...) are identified by a suspect parameter number (SPN), which are grouped in parameter groups identified by a PG number (PGN).
J1939 introJ1939 telematics
OBD2
On-board diagnostics (OBD, ISO 15765) is a self-diagnostic and reporting capability that e.g. mechanics use to identify car issues. OBD2 specifies diagnostic trouble codes (DTCs) and real-time data (e.g. speed, RPM), which can be recorded via OBD2 loggers.
OBD2 introOBD2 logging
CANopen
CANopen is used widely in embedded control applications, incl. e.g. industrial automation. It is based on CAN, meaning that a CAN bus data logger is also able to log CANopen data. This is key in e.g. machine diagnostics or optimizing production.
CANopen introCANopen logger
CAN FD
CAN bus with flexible data-rate (CAN FD) is an extension of the Classical CAN data link layer. It increases the payload from 8 to 64 bytes and allows for a higher data bit rate, dependent on the CAN transceiver. This enables increasingly data-intensive use cases like EVs.
CAN FD introCAN FD logger
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!