csselectronics.

com

CAN Bus Explained - A Simple Intro (2019)

CSS Electronics

10-12 menit

CAN Bus Explained - A Simple Intro (2019)

What Is CAN Bus?

The Controller Area Network (CAN) is used in e.g.
automotives to allow communication between ECUs and
sensors
1
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.

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

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.

... 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 of cloud computing

The growth in Internet of Things (IoT) and connected vehicles
The impact of autonomous vehicles
The growing push for increasingly advanced vehicle
functionality

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 Message - And How Do You Log &

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

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.

Check this ~1 min explainer to see how a CAN logger works

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:

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

LEARN MORE USE CASES

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.

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:

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

3 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, OBD2 and CANopen - while CAN FD is increasingly
relevant as it'll act as the new basis for all of them:

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

J1939 intro
J1939 vehicle telematics
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. OBD2 specifies diagnostic trouble codes (DTCs) and
real-time data (e.g. speed, RPM), which can be logged by e.g. an
OBD2 data logger.

OBD2 intro
OBD2 data logging
CAN FD
CAN bus with flexible data-rate (CAN FD) is an extension of the
classic CAN protocol. It increases the payload from 8 to 64 bytes
and allows for a higher data bit rate. This makes it a key enabler
for increasingly data-intensive use cases like electric vehicles.

CAN FD intro

For more intros & guides, go to our GUIDES section.

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!

RECOMMENDED FOR YOU