In this tutorial we explain the Controller Area Network (CAN bus) for beginners, incl. the CAN frame, higher-layer protocols and how to log/decode CAN bus data.
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.
(updated July 2024)
CAN bus (Controller Area Network) is a communication system used in vehicles/machines to enable ECUs (Electronic Control Units) to communicate with each other - without a host computer. For example, the CAN bus enables quick and reliable sharing of information between your car's brakes and engine.
Let's imagine your car is like the human body:
The CAN bus is the nervous system, enabling communication.
In turn, ECUs (aka 'CAN nodes') are like parts of the body, interconnected via the CAN bus. Information sensed by one part can be shared with another.
In physical terms, all ECUs are connected on a two-wire bus consisting of a twisted pair: CAN high and CAN low. The wires are often color coded: CAN high is yellow (like the sun), CAN low is green (like the grass).
Electronic Control Units (ECUs) are components that control certain functionality - e.g. the engine control unit, transmission, brakes, steering, temperatures etc. A modern car can easily have 70+ ECUs - each sharing information with other ECUs on the bus.
Any ECU on the CAN bus can prepare and broadcast information (e.g. sensor data). The broadcast data is accepted by all other ECUs on the network - and each ECU can then check the data and decide whether to receive or ignore it.
If we zoom in, an ECU consists of three primary elements:
How do you connect to a CAN bus?
There is no standard connector across CAN bus aplications. As we show later, this implies that different vehicles/machines may use different connectors.
However, a close candidate is the CAN DB9 (D-sub9) connector (CANopen CiA 303-1), which has become the de facto standard for many applications including CAN bus data loggers/interfaces.
Before we proceed, it is useful to know that multiple variants of CAN exist:
Other automotive network protocols
In automotives you'll often encounter other non-CAN networks - below are the most relevant:
The CAN bus standard is used in practically all vehicles and many machines due to below key benefits:
ECUs communicate via a single CAN system instead of via direct complex analogue signal lines - reducing errors, weight, wiring and costs
The CAN bus provides 'one point-of-entry' to communicate with all network ECUs - enabling central diagnostics, data logging and configuration
The system is robust towards electric disturbances and electromagnetic interference - ideal for safety critical applications (e.g. vehicles)
CAN frames are prioritized by ID so that top priority data gets immediate bus access, without causing interruption of other frames or CAN errors
Today, CAN is standard in automotives (cars, trucks, buses, tractors, . ), ships, planes, EV batteries, machinery and more.
Looking ahead, the CAN bus protocol will stay relevant - though it will be impacted by major trends:
It should be noted that the transition from Classical CAN towards e.g. CAN FD, CAN XL or Automotive Ethernet is in practice going to be slow. In our own experience across 5,000+ customers, less than 0.1% of use cases involve CAN FD as of 2024 and 0% involve CAN XL (which is not yet deployed in the field as of 2024).
CAN FD was touted as a clear successor to Classical CAN back in 2016 by e.g. CAN in Automation: "The first cars using CAN FD will appear in 2019/2020 and CAN FD will replace step-by-step Classical CAN". While CAN FD certainly exists in the field today, we are skeptical as to whether it will replace Classical CAN at all.
Automotive Ethernet clearly already plays a major role in various applications (in particular in frontier OEM R&D), but we have yet to see a significant impact of this on the dominance of Classical CAN in vehicles on-the-road.
Want to become a CAN bus expert?
Then get our 12 popular 'simple intros' in one 160+ page PDF:
In more technical terms, the controller area network is described 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 thus represents the two lowest layers as illustrated.
The CAN bus physical layer defines cable types, electrical signal levels, node requirements, cable impedance etc. For example, the physical layer specifies below:
The CAN bus data link layer defines e.g. CAN frame formats, error handling, data transmission and helps ensure data integrity. For example, the data link layer specifies:
As per the data link layer, communication over the CAN bus is done via CAN frames.
Below is a standard CAN data 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 will see below.
The 8 CAN data frame fields
Four CAN frame variants exist:
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.
As a lower-layer protocol, CAN provides a basis for communication - but not much 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 higher-layer protocols exist to further detail how data is communicated between CAN nodes of a given network.
Below we provide an overview of the most common automotive/industrial CAN protocols (click each to read our full intro):
On-board diagnostics is used in cars/trucks for diagnostics, maintenance and emissions tests. It specifies e.g. diagnostic trouble codes (DTCs) and real-time data (speed, RPM).
Unified Diagnostic Services (UDS) is a communication protocol used in automotive ECUs to enable diagnostics, firmware updates, routine testing and more.
The CAN Calibration Protocol and Universal Measurement and Calibration Protocol enable read / write ECU access for calibration, measurement and flashing.
CANopen is used widely in embedded control applications incl. industrial automation to enable off-the-shelf interoperability between CAN nodes aka devices
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 is used in the maritime industry for connecting e.g. engines, instruments and sensors on boats. It is based on CAN and closely linked to J1939.
ISO 11783 is used in agriculture and forestry machinery. It enables plug & play integration between vehicles and implements, across brands. It is closely linked to J1939.
Lower-layer vs. higher-layer protocols explainedThe distinction between CAN bus and higher-layer protocols can be confusing - let's try to demystify it.
A useful analogy is to 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. In comparison, higher-layer protocols reflect different languages like German or English, using these basics to build meaningful words and sentences.
Within this analogy, let's highlight some important observations:
Other higher-layer CAN protocols are also commonly encountered today, including below:
Below we outline 4 critical steps to logging raw CAN bus data.
First, decide how you wish to collect the CAN data:
Next, determine what adapter should be used. This is application specific, but below are 4 common options:
In most cars (and some vans/trucks), this lets you request OBD2/UDS data. May also provide access to the car's proprietary CAN data
In most heavy-duty vehicles (trucks, buses, excavators, tractors, …), this provides access to the raw CAN data (J1939 protocol)
In most maritime vessels (ships, boats) and some industrial machinery, this lets you record the raw CAN data (NMEA 2000 or CANopen)
A universal option is to skip the connector entirely - and instead use induction to read data from the CAN high/low wiring harness directly
How to determine the right adapterDepending on your use case, it may be simple or complex to determine the right adapter. Here we provide some additional tips based on the type of use case:
If your goal is to log data from your car, you will most likely need the OBD2 adapter. This lets you request OBD2 data from most non-EV cars after 2008 and usually get some responses such as RPM, speed, fuel level etc. If your car is an EV, you may be able to perform UDS requests using the OBD2 adapter. Similarly, if you are looking to reverse engineer proprietary CAN data, you can use the OBD2 adapter if your car provides access through the OBD2 connector to the proprietary CAN data. Note, however, that this is not always the case - in which case you would instead need to use a contactless CAN reader.
In heavy-duty vehicles, the J1939 adapter is the most commonly used. If you can identify a black/green 9-pin deutsch J1939 connector in your vehicle, then you can use this adapter. However, many vehicle brands use other connectors, like the Caterpillar 9-pin connector. Therefore, we generally recommend to get both a J1939 adapter and contactless CAN reader to provide multiple options for connecting to the J1939 data. In some heavy-duty veihcles a single J1939 9-pin connector may provide access to two CAN buses, in which 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.
In marine vessels, you will most often encounter the M12 connector that provides access to the NMEA 2000 data of the boat/ship. In some cases, you may be looking to collect data directly from the vessel engines, in which case you may use e.g. the J1939 adapter or DT06 adapter.
In non-automotive industrial machinery, you will often be able to use the M12 adapter. You may also encounter the standard DB9 connector, though you should then ensure that this reflects a connector for CAN access and not e.g. an RS232 interface.
In tractors, you can typically use the J1939 adapter to record J1939 data from the vehicle. However, you may also be interested in collecting ISOBUS data in parallel to the J1939 data. 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.
If you are working in a non-field environment, you may prefer instead to use a generic adapter that provides open-wire connections for quickly connecting to power and an active CAN bus. Similarly, an open wire adapter can be useful as a starting point for creating your own custom adapter cables if no off-the-shelf adapter matches your application.
Regardless of your application, you can in principle always use a contactless CAN reader. As long as you are able to get access to the physical CAN bus wiring harness (CAN high/low), then you can connect a contactless CAN reader to start recording CAN data. This is non-invasive and therefore often used in e.g. large-scale deployments to avoid issues with vehicle warranty. However, contactless CAN readers can be more cumbersome to install as you need to e.g. remove panels or similar to expose the wires - which may be less ideal for quick test deployments. Further, other adapter cables typically provide power/ground from within the same connector (through separate pins from the CAN bus) for easy plug & play installation. With a contactless CAN reader, you need to e.g. use a cigarette-to-DC adapter or similar to provide external power. Finally, contactless CAN readers are 'read-only' - no messages can be transmitted onto the CAN bus. This is often a 'feature' - but it also means that you cannot use such an adapter to e.g. perform requests over the CAN bus. Hence this solution does not allow you to e.g. perform OBD2/UDS requests.
Multiple CAN busesMost modern vehicles do not simply have one CAN bus. There can be other automotive protocols in play like LIN bus, FlexRay and Automotive Ethernet. Further, many vehicles (in particular heavy-duty) will have multiple CAN buses. For example, most commercial trucks have 2 or 3 separate CAN buses, while some mining vehicles may have more than 8 separate CAN buses. This is important to keep in mind when you are trying to collect data: You may need to connect to multiple CAN buses in parallel to collect all the data you need - and the first CAN bus you identify does not necessarily contain the data you need.
Many CAN loggers enable you to log multiple CAN buses in parallel. This is important as you generally need to ensure a high degree of time synchronization in order to be able to perform meaningful analysis across the different networks. As an example, the CANedge by default lets you record 2 x CAN networks in perfect time synchronization. Further, by adding a CANmod.router, a single CANedge can effectively record 5 x CAN channels.
Before you connect your device, consider two things:
You can now connect your device and verify that it logs data. If not, see our top 10 troubleshooting tips (illustration).
Once you are done recording e.g. a vehicle trip, you can review the resulting log file. In the picture, we show a log file with raw CAN data (J1939) recorded using a CANedge in a heavy-duty truck. Specifically, the data is displayed in a tabular structure in a software tool called asammdf. Notice how every line reflects a timestamped CAN frame incl. a CAN ID and data payload.
Tip: Download asammdf and our sample data to try it yourself.
The log file picture above illustrates an important point:
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, degrees, . ). This requires a DBC file and software tool.
Below we explain how this works in 3 steps:
Each CAN frame contains CAN signals in the data payload.
For example, a CAN message from our CANmod.temp contains 9 CAN signals, incl. CJTemp (Cold Junction Temperature).
To extract the physical value of a CAN signal, the following information is required:
To extract a CAN signal, you 'carve out' the relevant bits, take the decimal value and perform a linear scaling as illustrated.
As shown, interpreting raw CAN data requires information about how CAN signals are encoded. This is where a DBC is key.
A CAN DBC file (CAN database) is a text file that contains information for decoding raw CAN data.
But how do you get a DBC file?
Generally, DBC files are application-specific and proprietary and available only to the Original Equipment Manufacturer (OEM).
If you work as an OEM engineer you will typically have the DBC already (or the information to create one).
Examples of standardized DBC filesIf you are not the OEM, consider instead below routes:
Finally, you will need a software/API tool that supports your log file format and DBC files.
The relevant software depends on your use case - below are examples for the CANedge:
GUI desktop tools are useful for ad hoc analysis, diagnostics and export
Customized dashboards enable data visualization, reporting and insight sharing
Script tools like MATLAB/Python enable statistical analysis and big data processing
There are several common use cases for recording CAN bus data:
OBD2 data from cars can e.g. be used to reduce fuel costs, improve driving, test prototype parts and insurance
J1939 data from trucks, buses, tractors etc. can be used in fleet management to reduce costs or improve safety
Vehicles and machinery can be monitored via IoT CAN loggers in the cloud to predict and avoid breakdowns
A CAN logger can serve as a 'blackbox' for vehicles or equipment, providing data for e.g. disputes or diagnostics
Do you have a CAN logging use case? Reach out for free sparring!
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!
