CAN bus explained - a simple intro
In this tutorial we explain the Controller Area Network (CAN bus)
in simple terms, including the basics, the key benefits of CAN and a breakdown of the CAN frame.
To get a practical understanding, we’ll also explain how to record and decode CAN bus data.
Let’s start with the basics of CAN bus.
To understand what CAN bus is, imagine that your car is like a human body:
In this context, the CAN bus is the nervous system, enabling communication between
different parts of the body. Communication happens between different CAN bus 'nodes', which are also
called 'electronic control units' (or ECUs). These CAN nodes are like parts of the body,
interconnected via the CAN bus. Information from one node can be shared with other nodes.
In an automotive CAN bus system, ECUs can be things like 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 information (for example sensor data) and broadcast this
via the CAN bus. The physical communication happens via the CAN bus wiring harness,
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.
In more technical terms, the controller area network is described by a data link layer
and physical layer. Specifically, ISO 11898-1 describes the data link layer,
while ISO 11898-2 describes the physical layer. For details, see our CAN bus intro article.
Today, CAN bus is standard in practically all automotives like cars, trucks, buses,
tractors, bikes as well as ships, planes, EV batteries, machinery and more.
There are 4 key benefits to CAN bus that help explain the popularity:
First, CAN bus is simple and low cost. ECUs communicate via a single CAN system instead
of via direct complex analogue signal lines - reducing errors, weight, wiring and costs.
Second, it is fully centralized. The CAN bus provides 'one point-of-entry' to communicate
with all network ECUs - enabling central diagnostics, data logging and configuration.
Third, CAN is extremely robust. In particular, the system is robust towards electric disturbances
and electromagnetic interference - making it ideal for safety critical applications.
Finally, it is efficient. CAN frames are prioritized by ID so that top priority
data gets immediate bus access, without causing interruption of other frames.
In terms of the history of CAN bus, it was initially developed by Bosch in 1986 as a solution
to the prior challenge of complex point-to-point wiring in cars. In 1991, Bosch published CAN 2.0,
with 2.0A referring to 11-bit CAN IDs and 2.0B referring to 29-bit CAN IDs.
In 1993, CAN was adopted as an international standard, ISO 11898.
In 2003, the standard was separated for the data link and physical layers. In 2012,
Bosch released the next generation of CAN called CAN FD or CAN with flexible data-rate
CAN FD was standardized in 2015 and is gradually being rolled out in vehicles
and machinery today. More recently, work has also begun on the next generation CAN XL protocol.
To further understand how CAN bus works, let’s look at the CAN frame.
Communication over the CAN bus is done via CAN frames.
Here is a standard CAN frame with an 11 bit identifier, which is the type used in most cars.
Let’s briefly go through each of the 8 message fields:
Number 1 is the Start of Frame, which is a 'dominant 0',
informing the other nodes that the CAN node intends to broadcast information.
Number 2 is the 11-bit or 29-bit CAN ID,
which serves to identify the frame. Lower value IDs have higher priority on the bus.
Number 3 is the Remote Transmission Request field,
which indicates whether a node sends data or requests dedicated data from another node.
Number 4 is the 6-bit Control, which contains the Identifier Extension Bit which informs whether
the CAN ID is 11-bit or 29-bit. The Control field also contains the 4 bit Data Length Code
(DLC), specifying the length of the data bytes to be transmitted, which can be 0 to 8 bytes.
Number 5 is the Data payload, which contains the actual information to be communicated - for
example the front right wheel speed. We will go into more detail on ‘CAN signals’ shortly.
Number 6 is the Cyclic Redundancy Check, which is used to ensure the data integrity.
Number 7 is the Acknowledgement slot,
which indicates if the node has acknowledged and received the data correctly.
And finally, number 8 is the End Of Frame field that marks the end of the CAN frame.
We’ve highlighted the CAN ID and payload because
these are the most relevant fields in regards to CAN bus data logging, which we’ll look at next.
To truly understand the CAN bus protocol, we find it useful to explain how to record and decode
CAN bus data. CAN data acquisition is done across many use cases today.
For example, CAN data from cars can be used to reduce fuel costs, improve driving, test prototype
parts - and for insurance optimization. For more details, see also our OBD2 data logging intro.
Similarly, CAN data from trucks, buses, tractors etc. can be used in fleet management to reduce
costs or improve safety. For details on this, see our J1939 intro and J1939 telematics intro.
Another increasingly popular use case for CAN data is predictive maintenance. Vehicles and
machinery can be monitored via IoT CAN loggers that communicate data to remote servers.
This data can in turn be used to predict and avoid breakdowns.
Finally, CAN loggers are increasingly being used as blackboxes in vehicles and machinery,
providing data for diagnostics and for example warranty dispute handling.
But how do you actually record CAN bus data?
As mentioned, two CAN fields are important for CAN logging: The CAN ID and the Data.
A common way to record CAN bus data in practice is to use a CAN bus data logger like the CANedge.
With this, you can record timestamped raw CAN frames into a log file on an SD card.
To connect a CAN logger to your application typically requires a suitable adapter
cable - for example an OBD2 adapter in cars or a J1939 deutsch connector in trucks.
In some cases, you may need to use a customized adapter, or a contactless adapter cable.
Once you’ve connected your CAN logger, it’ll start recording raw CAN frames.
To understand what this looks like, let’s load a log file from a heavy duty truck.
This specific log file contains J1939 data. Using a CAN bus software tool called asammdf,
we can view the raw data in a tabular structure and you’ll see the link back to the CAN frame
fields discussed earlier - including in particular the CAN ID and data payload.
If we look at this raw CAN bus data sample, you will probably notice something:
Raw CAN bus data is not human-readable.
To make sense of the data, we need to decode the CAN frames into scaled
engineering values aka physical values. For example speed as measured in km/h.
Let’s look at how this works step-by-step:
The firs thing to understand is that each CAN frame contains a number of
CAN signals (or parameters) within the CAN databytes. For example, a CAN
frame with a specific CAN ID may carry data for 2 CAN signals as illustrated.
To extract the physical value of a CAN signal, a specific set of information is required.
In this example, the start bit is 24 and the bit length is 16.
The EngineSpeed signal is little-endian and we therefore need to reorder the byte sequence from
6813 to 1368. Next, we convert the hex string to decimal and apply the standard linear conversion
used in most CAN decoding. As evident, the engine speed physical value is 621 rpm.
In practice, the information required for extracting CAN bus
signals is contained in a standardized file format. The most common format is
called ‘CAN databases’ - see also our intro to DBC files.
In summary, if you have a tool for recording raw CAN bus data and the relevant DBC file,
then you can extract human-readable data, which you can use for practically any use case.
However, one challenge is of course: How do you get the relevant DBC file?
Most CAN based assets today use a proprietary CAN
bus signal encoding. This is the case in practically all cars, motorcycles,
factory machinery etc. Here, the decoding rules are proprietary
and only known to the manufacturer - and they differ across different models and brands.
However, some exceptions exist:
In most cars today, you can record OBD2 data by requesting specific parameters from the car
like speed, throttle position etc. OBD2 is standardized across car brands and we
provide a free OBD2 DBC file for decoding the raw OBD2 responses.
In most heavy duty vehicles like trucks, buses, tractors etc. the J1939 standard is used.
This means that a J1939 DBC file can be used to decode most of the relevant parameters.
If we load this with the J1939 log file from before, we’re able to convert 70%
of the CAN IDs resulting in 200+ parameters. See also our J1939 DBC intro.
Similarly, maritime vessels like ships typically use the NMEA 2000 protocol. Here, we offer an
NMEA 2000 DBC file that can be used to decode the majority of data from such applications.
Beyond these scenarios, you may be able to get a DBC file from the manufacturer or via
technical documents. This is typically the case for CAN modules that are intended for
integration with other systems - for example sensor-to-CAN modules like our GPS-to-CAN
and temperature-to-CAN devices, where DBC files are part of the product package.
In case the CAN data is proprietary, you can attempt to reverse engineer the data using
CAN bus sniffer tools. You can also attempt to leverage public DBC files created through the
reverse engineering efforts of others. Our DBC intro has links for the most popular databases.
As part of this walkthrough we’ve mentioned a couple of protocols related to CAN bus. In
simple terms, CAN bus provides the basic means of communicating data - but not a lot more. Therefore
a number of ‘higher layer protocols’ have been developed to enable more advanced functionality.
Let’s briefly outline the most common ones:
First we have J1939, which is the standard in-vehicle network for heavy-duty vehicles.
J1939 parameters are identified by a suspect parameter number
(or SPN) and these are bundled in parameter groups identified as a PG number (or PGN). The maritime
NMEA 2000 protocol and the agricultural ISOBUS protocol are derived from J1939.
Second, we have OBD2. In short, ‘on-board diagnostics’ is a self-diagnostic and
reporting capability that can for example be used by mechanics to troubleshoot
issues in cars. OBD2 specifies diagnostic trouble codes (aka DTCs)
and real-time data (like speed and RPM), which can be recorded via OBD2 loggers.
Next, we have CANopen which is used widely
in embedded control applications, including in industrial automation.
It is based on CAN, meaning that a CAN bus data logger is also able to log raw CANopen data.
These higher layer protocols will increasingly be based on CAN FD, which is the next generation of
Classical CAN. The CAN FD standard increases the data payload from 8 to 64 bytes and allows for a
higher data bit rate. This enables increasingly data-intensive use cases like electric vehicles.
We provide simple intro articles and videos for J1939, OBD2, CANopen, CAN FD,
LIN bus and more on our website and YouTube channel - definitely go check them out.
If you liked this video, please share and subscribe - and if you have questions, contact us.