CAN Bus Explained - A Simple Intro (2018)

Struggling to find an intro to CAN bus written in layman's terms? So were we!

Therefore we've launched a series of basic CAN intro tutorials - written by one of our non-engineers to make sure it stays simple!

In this article we'll explain the Controller Area Network (CAN bus) for dummies:

  1. What is CAN Bus? Basics, history and outlook
  2. CAN message interpretation & data logging
  3. Link betwen CAN and OBD2, J1939 & CANopen
CAN Bus Explained - A Simple Intro for Dummies Youtube Button

You can also check out our QUALITY CAN bus intro video above with a great voice over by Sam F (200k+ views on YouTube)!


What Is CAN Bus?

The Controller Area Network (CAN) is used in e.g. automotives to allow communication between ECUs and sensors

  • The CAN protocol is robust, low-cost and message based
  • Originally developed by Robert Bosch in 1986
  • Essential to many applications - e.g. cars, trucks, tractors, industrial robots, ...

Imagine that your car is like a human body:

The Controller Area Network (CAN bus) is the nervous system, enabling communication between all parts of the body.

Similarly, ‘nodes’ - or electronic control units (ECU) - are connected via the CAN bus, which acts as a central networking system.

So what's an ECU?

In an automotive CAN bus system, ECUs can e.g. be the engine control unit, airbags - or the audio system.
A modern car can have up to 70 ECUs.

This is where the CAN standard comes in handy:

The CAN bus protocol allows ECUs to communicate with each other without complex dedicated wiring in between. In turn this allows for several features to be added via software alone, e.g. electronic gearbox control.

Autonomous CAN Bus System Explained Network Human Nervous

Indeed, that is the primary purpose of the Controller Area Network:

To allow any ECU to communicate with the entire system without causing an overload to the controller computer.

But that's not all: Below are 5 core reasons why CAN bus is so popular:

5 Critical Advantages of CAN Bus Communication

  1. Low cost: ECUs communicate via a single CAN interface, i.e. not direct analogue signal lines, reducing errors, weight, costs
  2. Centralized: The CAN bus system allows for central error diagnosis and configuration across all ECUs
  3. Robust: The system is robust towards failure of subsystems and electromagnetic interference, making it ideal for e.g. vehicles
  4. Efficient: CAN messages are prioritized via IDs so that the highest priority IDs are non-interrupted (key in e.g. vehicles)
  5. Flexible: Each ECU contains a chip for receiving all transmitted messages, decide relevance and act accordingly - this allows easy modification and inclusion of additional nodes (e.g. CAN bus data loggers) - cf. below figure

CAN Bus Intro Message Overview Breakdown CANbus

The CAN bus history in short ...

  • Pre CAN: Car ECUs relied on complex point-to-point wiring
  • 1986: Bosch developed the CAN bus 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)
  • 2012: Bosch released the CAN FD 1.0 (flexible data rate)

Today, the CAN protocol is standard in practically all vehicles (cars, trucks, buses, tractors, ...) - as well as ships, planes, EV batteries, industrial machinery and more.

Further, more exotic cases include drones, radar systems, submarines or even prosthetic limbs.

CAN Bus History Explained Automotive Wiring Cable CANbus Car Truck Volvo Audi

... And The Future of CAN Bus

Looking ahead, the CAN bus protocol will stay relevant - though it will be impacted by major trends:

The rise in connected vehicles & cloud computing will lead to a rapid growth in telematics and WiFi CAN bus analyzers.

But perhaps more fundamentally, the push for increased vehicle functionality may require changes to the core CAN technology.

The Rise of CAN FD

Increased vehicle functionality means a rapid increase in the data load of the vehicle CAN bus.

To support this demand, CAN FD (Flexible Data Rate) will be a critical enabler.

Basically, today's CAN bus systems face a major roadblock: The speed limit of 1 Mbit/s.

This level of speed is simply proving insufficient for handling the future CAN bus data loads.

CAN FD provides two key solutions:

  • It enables data transmission up to 8 Mbit/s - far beyond the 1 Mbit/s of regular CAN
  • Further, it allows data packets of 64 bytes (instead of 8 bytes), reducing packet complexity

There is no doubt that CAN FD will play a major role going forward:

CAN FD CAN Bus Future Outlook 2020 Automotive Tesla EV

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"


CAN Message - And How Do You Log & Convert It?

A CAN message is comprised of 8 components - and can easily be logged with a CAN data logger or interface

To understand how the CAN bus system works, let's break down the messages sent over the network.

The figure below shows a simplified picture of a CAN message with extended 29 bits identifier (i.e. CAN 2.0B), which is the format used in e.g. the J1939 protocol for trucks and buses. The 11-bit identifier (CAN 2.0A) messages look similar, but with shorter CAN IDs.

CANbus Message Breakdown Simple CRC ACK EOF

SOF: The Start of Frame is a 'dominant 0' to tell the other ECUs that a message is coming
CAN-ID: Contains the message identifier - lower values have higher priority (e.g. RPM, wheel speed, ...)
RTR: The Remote Transmission Request allows ECUs to "request" messages from other ECUs
Control: Informs the length of the Data in bytes (0 to 8 bytes)
Data: Contains the actual data values, which need to be "scaled" or converted to be readable and ready for analysis
CRC: The Cyclic Redundancy Check is used to ensure data integrity
ACK: The ACK slot indicates if the CRC process is OK
EOF: Marks the end of the CAN message

How to Log CAN Bus Data

Of the 8 CAN elements, only 3 are relevant in most CAN logging scenarios:

The CAN ID, the Control and the Data field.

To log this CAN data, you'll need a CAN bus data logger. This lets you "listen" to broadcasted raw CAN messages and record these to an SD card for further analysis.

In your car, for example, you'll find an OBD2 connector under the steering wheel - connecting your logger to this lets you record raw CAN data incl. OBD2 data.

Below is an example raw OBD2 log file from a car (Audi A4), logged using the CL2000.

Note that the car data sample contains vehicle speed data (OBD2 PID 0D) - as well as proprietary raw CAN protocol messages:

.txt file not loaded correctly?

Get started with CAN logging now

To truly learn about CAN bus, the only way is to record real CAN data yourself.

The CLX000 CAN logger lets you record raw CAN data from any vehicle. Simply connect it to e.g. your car or truck and record weeks of data to the 8GB SD card.

Further, with CANvas, you can easily decode the data using our built-in OBD2 database or *.DBC files (more on this below).


How to Decode CAN Bus Data

If you check out the raw CAN bus data sample above, you'll probably notice something:

Raw CAN bus data makes no sense!

That's because you need to decode the data into scaled engineering values - AKA human-readable form

To do this, you'll need to know a couple of things:

For each ID (e.g. "34d" in HEX in the above sample), you'll need to know what parameters (or CAN signals) are included.

CAN Bus Message Frame Breakdown Bit Start Length

For example, in the 64 bits of data in 34d there may be CAN data from 3 parameters, each with a specific bit start and bit length.

For each CAN signal, you then take the decimal value of the data bits and "scale" this (typically as below):

[Scaled Data Value] = [Offset] + [Scale] x [Raw Decimal Data Value]

In other words, you'll need for each parameter the offset and scale values.

How do you find this CAN decoding information?

Most often, these "conversion rules" are proprietary and not easily available. So, if you e.g. want to convert raw CAN protocol data from your car, you'd need to reverse engineer the CAN bus data - which is not always easy.

However, in some cases standardized decoding databases exist:

Example: J1939 DBC Files (Heavy Duty)

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'll need a format for storing the conversion rules. Here, the *.DBC format is the industry standard - and is supported by most CAN bus software incl. 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 File Digital Annex PGNs SPNs


What is the Link Between CAN bus and J1939, OBD-II & CANopen?

Many "higher layer protocols" are based on the CAN bus protocol - e.g. J1939, OBD2 and CANopen

These allow more complex communication in e.g. trucks, car diagnostics and industrial automation

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 define how data is communicated between ECUs of a given network.
Some of the most commonly encountered standards include SAE J1939, OBD-II and CANopen:

Where can I learn more?

You can go to our GUIDES section for more intros, guides & use cases.

Want to log data from your car, truck or other CAN application?
Then learn more about our CLX000 CAN logger below!

Liked this article? Please share!


We use cookies to improve our site (see our privacy policy)