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 simple CAN intro articles - 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 video above with a great voice over by Sam F (40k+ views on YouTube)!



1

What Is CAN Bus?

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

  • CAN is robust, low-cost message based protocol
  • 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

  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-Transmit-Receive-Datamin



The CAN bus history in short ...

  • Pre CAN: Car ECUs relied on increasingly complex point-to-point wiring
  • 1986: Bosch developed the CAN bus protocol as a solution, releasing it at a SAE congress
  • 1991: Bosch published CAN 2.0, incl. CAN 2.0A (11 bit) and CAN 2.0B (29 bit)
  • 1993: CAN is adopted as international standard (ISO 11898)
  • 2012: Bosch released the CAN FD 1.0, aka CAN with flexible data rate

Today, almost every new European car comes with a CAN bus system - and it is used broadly in trucks, buses, industry vehicles, ships, planes and industrial automation. 

CAN Bus History Automotive

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




... And The Future of CAN Bus

Looking ahead, the CAN bus protocol will stay relevant - and most likely even more so with the rise of e.g. cloud computing, Internet of Things (IoT) and autonomous vehicles. These trends will also boost the need for CAN bus decoders with WiFi / celluar connectivity - allowing wireless transfer of CAN bus data to e.g. cloud servers.

With 1.8 billion CAN bus interfaces sold in 2016, CAN is already a critical and fast-growing technology worldwide. But the increasing need for efficient, robust and low-cost intra-communication systems will undoubtedly give rise to massive growth going forward.

To enable this future CAN FD (Flexible Data Rate) will be a critical component.

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

With increasing complexity and requirements for data speed (more ECUs, data), this is a growing challenge.

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

"The first cars using CAN FD will appear in 2019/2020.
CAN FD will replace step-by-step classical CAN."

- CAN in Automation (CiA), "CAN 2020: The Future of CAN Technology"




2

What is a 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.

The 8 Components of a CAN Bus Message

  • 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


CANbus-Message-Frame-Structure-29-bit-Extended-Datamin



How to Log CAN Bus Data

In short, the CAN bus message contains a lot of components!

However, only 3 are practically relevant in most data logging scenarios:

The CAN ID, the Control and the Data field.

To log this data, you'll need a CAN bus data logger or interface.

Such a device will act as a "node" on the CAN bus and will be able to read all broadcasted CAN messages e.g. onto an SD card.

Note: Applications require different ways of connecting the CAN logger.

For example, in a car you'll find an OBD2 connector under the steering wheel - connecting your logger to this will allow you to record the raw CAN bus data.

Indeed, below is an example log file from a car using the CLX000:

.txt file not loaded correctly?

 

 






How to Convert Raw CAN Bus Data to Human-Readable Form

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 convert 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.

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

CAN Bus Message Frame Breakdown Bit Start Length

Again, for each of these CAN signals, you need to know how to decode the CAN data.

This typically involves a linear combination of the decimal value of the data, i.e.:

[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 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.

In some cases, most parameters are standardized across manufacturers - e.g. in SAE J1939 for heavy-duty vehicles

J1939 DBC File Digital Annex PGNs SPNs

The SAE J1939 Digital Annex e.g. contains conversion rules for PGNs & SPNs in an Excel format

Finally, you'll also need a simple way to store the rules and convert the data.

One popular CAN database file format is *.DBC - which can be used by most CAN bus software, incl. CANvas.



3

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

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

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


CAN 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:

SAE J1939

SAE J1939 is the standard in-vehicle network for buses, trucks and other heavy-duty vehicles. J1939 messages use the extended 29 bits CAN identifier. Further, J1939 data parameters (e.g. RPM, speed, ...) are identified by a suspect parameter number (SPN), which are in turn grouped in parameter group numbers (PGN) of SPNs. 

With this standardization, CAN messages from e.g. trucks can be decoded using parameter tables from the J1939 standard. For more on J1939, see our below articles:




OBD2

On-board diagnostics (OBD) is a self-diagnostic and reporting capability that e.g. mechanics use to identify what is wrong with your car. 

The OBD2 standard specifies a number of standardized diagnostic trouble codes (DTCs), which can be retrieved by a CAN logger or diagnostic tool from any vehicle.

Further, OBD2 supports data on many basic real-time parameters (e.g. vehicle speed, RPM, fuel consumption, ...). This means that OBD2 is also used for e.g. real-time vehicle telematics. Applications include vehicle fleet management, fuel optimization, proactive vehicle diagnostics and more. 

To log OBD-II data, the CAN logger must “requests” the data by submitting pre-specified CAN frames with specific 'Parameter IDs' (PID) to the CAN bus. When using the CLX000, this can easily be configured in CANvas.

For more info, see our below articles related to OBD2:




CANopen

CANopen is used widely in e.g. industrial automation applications. It builds on CAN in terms of the physical layer (i.e. lines used, voltages, ...) and the data link layer (i.e. utilizing a CAN frame message based protocol). 

In practice this means that a data logger like the CLX000 is able to log data from CANopen applications, though the method for ex post data conversion will vary depending on the specific application.




 

Cool! Where can I learn more?

Our GUIDES page contains several intro articles, use cases and guides - let us know if you have more suggestions for the series!

Interested in our products?

Read more about our CLX000 series of powerful, simple & affordable CAN bus data loggers here.


 

 Liked this article? Please share!




RECOMMENDED FOR YOU



This site uses cookies to enhance your experience

OK!