CAN Bus Protocol: The Ultimate Guide (2023)

CAN bus stands for Controller
Area Network Communication and consists of two electrical wires called CAN_Low and CAN_High. The information within
each
vehicle is being transmitted from and to ECUs. In addition, CAN bus
is built to handle robust performance within harsh environments.

We have prepared a simple introduction to CAN bus. Several topics have been covered, in order to give you the best
explanation of the CAN protocol.

While working on the article, we
combined the knowledge from our top experts within the company, as well as non-expertise team members.

Why? The idea was to write a
professional but simple guide introduction to CAN bus for everyone, no
matter how much experience you have.

In conclusion, it do not matter if you have no knowledge about the CAN bus protocol whatsoever or you are already a
pro. This simple guide intro to CAN bus will
give you all the information needed.

What is CAN bus?

CAN bus is a set of two electrical wires in the car network (CAN_Low and CAN_High), where the
information is
being sent to and from ECUs. The network that allows ECUs to communicate is called Controller Area
Network
(CAN).

The CAN bus is a serial communication bus, designed for robust performance within harsh environments,
primarily in industrial and automotive applications.

It is basically a vehicle bus standard that allows microcontrollers and devices to communicate with each
other.

CAN bus is one of the protocols used in On-Board
Diagnostics (OBD). Nowadays, the OBD-2 is mandatory in all newer cars and light trucks all
around the
globe.

CAN bus system easily explained

Let us try to look at it from a totally different point of perspective.

Imagine that the car is like the human body and the nervous system in the human body is the Controller
Area
Network (CAN bus) in the car, which also enables the communication.

Nodes or electronic
control units (ECUs) are something like body parts that are interconnected through the
CAN bus communication. Information can easily be shared between parties. That is much easier to
understand,
isn’t it?

The CAN bus system

Depending on the type of the car,
it can have up to 70 ECUs (Electronic Control Units) and each of them needs to be shared with other parts of the
network.

Some of the examples are for
instance; audio system, airbags, engine control unit, door control unit
and so on. The CAN bus enables the ECUs to communicate to each other.

Think about ECUs as specific
people. One ECU can formulate and transmit the information via CAN bus to other ECUs that accept the data. After
that, they will check the data and decide if they want to receive it or ignore it.

The CAN bus uses two wires for
communication – CAN low and CAN high (CANL and CAN H). ISO 11898-2 describes the physical layer
of the CAN bus and ISO 11898-1 describes the data link layer.

The physical layer represents types of cables, node requirements, electrical signal levels, cable impedance,
etc.

On the other side, ISO 11898-2 represents things such as baud rate, cable length and termination.

• Cable lengths should be 40 meters (1 Mbit/s) or 500 meters (125 kbit/s).

• The CAN bus has to be terminated using a 120 Ohms CAN bus resistor at the end of each bus.

• CAN nodes have to be connected through two wire bus with baud rates up to 1 Mbit/s (CAN) or 5 Mbit/s
  (CAN
  FD).

5 benefits of CAN bus protocol

CAN bus standard is commonly used in all vehicles due to its key benefits, such as:

• Robustness

  CAN bus standard is ideal for safety applications such as vehicles due to its durability and
  reliability.
  There are also 5 mechanisms to detect errors in the CAN protocol such as bit stuffing, bit monitoring,
  frame
  check, acknowledgment check and cyclic redundancy check.

• Low-cost

  When the CAN protocol was created, its purpose was to enable fast communication between electronic
  devices
  and modules, while reducing errors, weight, wiring and costs.

• Speed

  Currently defined by two physical layers – High Speed CAN (CAN h) and Low Speed CAN (CAN L), both with
  its own
  advantages
  and disadvantages.

• Flexibility

  CAN bus protocol is well-known as a message-based protocol, meaning nodes can easily be added or removed
  without performing any updates on the system. This makes it really easy for engineers to integrate new
  electronic devices without significant programming and modify it to your requirements.

• Efficiency

  High priority data will get prioritized by ID, in order to get immediate bus access – not interrupting
  other
  frames.

CAN bus wiring

One of the best advantages of
CAN bus
is the reduced amount of wiring in combination with an ingenious prevention of message collision.

In other words, no data will be lost during message transmission.

The two examples below illustrates the
CAN protocol and what it would look like with CAN bus system and without the CAN bus system.

Clearly, with CAN bus, it is much easier for nodes to communicate and navigate through.

On the other side, without a CAN bus, it is much harder for nodes to communicate with each other and the
communication is ineffective.

There are several different types of networks. You can find an easy explanation below.

High speed CAN bus (ISO 11898)

• Supports bit rates between 40 kbit/s and 1 Mbit/s.

• Simple cabling.

• Most
  commonly used these days.

• Basis for higher layer protocols such as
  OBD2, CANopen, j1939 and more.

Low speed CAN bus

• Supports bit rates between 40 kbit/s and 125 kbit/s.

• Allows communication to continue despite the fault in one of the two wires.

• Also known as a fault tolerant CAN.

• Each CAN node has own CAN termination.

LIN bus

• Low-cost supplement.

• Less harness.

• Cheaper nodes.

• Usually consists of a LIN bus
  master, which
  is acting as a gateway – up to 16 slave nodes.

• Typically includes vehicle functions such as door functionality or air condition.

Automotive
ethernet

• Ethernet
  supports high
  bandwidth requirements of Advanced Driver
  Assistance Systems (ADAS), cameras, infotainment systems and so on.

• Provides much higher data transfer rates than CAN bus.

• Lacks safety features of CAN and CAN FD.

• Most likely will be used commonly in the upcoming years within the automotive
  industry.

CAN FD

• Typically used in modern high performance vehicles.

• CAN FD is an extension to the original CAN
  bus
  protocol.

• Released in 2012 by Bosch.

• Developed to meet the need to increase the data transfer.

What is a CAN message frame?

CAN frames are used to communicate over CAN bus. CAN uses the differential signal with two logic states –
dominant
and recessive.

CAN network uses two CAN messages – standard CAN and extended CAN that are described below.

The image below shows a typical CAN frame with an 11-bit identification, which is the kind used in most cars.
Except for the larger ID, the expanded 29-bit identifier frame is identical.

Standard CAN frame

The first bit is the start of the
frame (SOF), which represents the start of the CAN message. Next one is the 11 bit identifier that
organizes the priority of the CAN message. The smaller the identifier is, the higher priority it has.

The Remote Transmission Request
(RTR) is typically dominant, but it becomes recessive when nodes are requesting data from each other.

Next one is the identifier extension (IDE) bit, which is dominant when the standard CAN frame is sent – not
extended
one. The r0 bit is reversed and not currently used.

Next one is the Data Length Code
(DLC), which indicates how many bytes of data are in the current message. Another important part is the data
itself, where it is the same number of bytes as in DLC bits.

The next one is the cyclic redundancy check (CRC), which is a 16-bit checksum that detects errors and issues
in
the
transmitted data.

In case the message is properly received, the receiving node will overwrite the recessive acknowledge bit
(ACK)
with
a dominant bit. The end of frame (EOF) indicates the end of the CAN message.

It is 7 bits wide and it detects bit stuffing errors. The last part of the CAN message is the interframe
space
(IFS), which is being used as a time delay.

Extended CAN frame

Extended CAN frame uses a 29 bit
identifier with a couple additional bits. The extended 29 bit identifier (CAN 2.0B) is identical, but has a
longer ID and is usually used in the j1939
protocol –
heave-duty vehicles. CAN uses two logic states; dominant and recessive.

• Dominant

  Pinpoints that the differential voltage is greater than the minimum threshold. In
  addition, the
  dominant
  state is also achieved by driving a logic ‘0’ onto the bus.

• Recessive

  Pinpoints that the differential voltage is less than the minimum threshold. On the other
  side,
  recessive
  state is achieved by a logic ‘1’.

It also has a substitute remote
request (SRR) bit, which comes after 11 bit identifier and acts like a placeholder, in order to keep the
same
structure as a standard CAN frame.

The identifier extension (IDE) should be recessive and the extended identifier
should follow it accordingly.

The remote transmission request (RTR) comes right after the 18 bit ID. The reverse bit r1 follows the path
and the
rest of the message stays the same.

CAN bus data logging

Logging CAN data can be done from several types of vehicles such as cars, heavy duty vehicles, predictive
maintenance and machine blackbox.

The vehicle data are
gathered through the OBD2 port and are usually used to reduce fuel costs, improve car mileage and more.

On the other side, data from the heavy duty vehicles are gathered through j1939 and are usually used to improve
safety and reduce costs.

Vehicles and machinery can be
also monitored through IoT CAN
loggers. That can be done in the cloud to avoid breakdowns. A CAN logger can
provide data for disputes or diagnostics. It is also called blackbox.

CAN bus logging is commonly used
in fleet management, due to its effectivity
and increased number of opportunities.

A CAN logger is required to
record CAN data. This allows you to save timestamped CAN data on an SD card. In some situations, a CAN interface
is required to transmit data to a PC, such as when decoding data.

Example: TMU SocketCAN

The TMU SocketCAN allows you to
record data from any CAN bus to an 8-32 GB Micro SD Card with ease. Simply attach it to a car or truck to begin
logging, and then code the data using our free management software.

Furthermore, the TMU SocketCAN has WiFi, allowing you to automatically upload
data to your own server – as well as upgrade devices over-the-air.

Decoding raw CAN data

Raw CAN data is not easily readable. Therefore we have prepared a guide for you. Check out the guide on
how to log raw CAN messages.

The CAN bus supports the
basis for communication, but not more than that. The CAN protocol doesn’t indicate how to handle
messages
greater than 8 bytes, or how to decode the RAW data.

In order to indicate how data
is communicated between CAN nodes of a network, a set of standardized protocols come in handy. There are
several higher layer protocols such as; OBD2,
CANopen, CAN FD and SAE J1939.

• OBD2

  OBD has a self-diagnostic capability that mostly mechanics use to analyze car issues and the overall
  health of the car. OBD2 determines trouble codes (DTCs) and real time data (RPM, speed, etc) that
  can be recorded through OBD2 loggers.

• CANopen

  CANopen is typically used in embedded control applications such as industrial automation and is
  based on a CAN meaning that the CAN bus data logger is also capable to log CANopen data.

• CAN FD

  CAN FD is essentially a CAN bus with flexible data rate and an extension of the classical CAN data link
  layer.
  In comparison with classical CAN protocol, CAN FD increases the payload from 8 to 64 bytes. It also
  allows a higher data bit rate, depending on the CAN transceiver.

• SAE J1939

  J1939 is commonly used in heavy duty vehicles. J1939
  parameters such as RPM and speed are analyzed by a suspect parameter number (SPN). Afterwards, they
  are grouped in parameter groups and classified by a PG number (PGN).

A high speed transfer data
rate offers DoIP
diagnostics,
more precisely approximately 100 times of CAN diagnosis.

History of CAN bus

Control Area Network (CAN bus)
have a rich history and went through several development stages. The actual development stages within years can
be seen below.

• Development of CAN bus goes all the way back to 1983 when Bosch
  originally invented Control Area Network and was later codified into ISO 11898-1
  standard.

• The CAN protocol was later released to the Society of Automotive Engineers (SAE) in 1986.

• Intel was the first one to introduce the CAN controller chips in 1987, and Phillips joined Intel shortly
  after that.

• In 1991, Bosch published CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29bit).

• CAN bus as an international standard in ISO 11898, was adopted in 1993.

• In 2003, ISO 11898 became a standard series.

• In 2012, Bosch has released the CAN FD 1.0 – flexible data rate.

• In 2015, the CAN FD protocol has become standardized in ISO 11898-1.

• Lastly, the physical CAN layer up to 5Mbit/s has become standardized in ISO 11898-2, in 2016.

In the future, CAN bus will still be commonly used, but influenced by major automotive industry trends such as;
growth of Internet of Things and connected vehicles, impact of autonomous vehicles, the rise of cloud computing,
the
need for advanced vehicle functionality and more.

The need of CAN FD increases and many experts assume it will slowly replace the classical CAN bus protocol. Stay
updated to see what happens.

Make your fleet management KEYLESS

Customized solutions for fleets that allows fleet managers to
remotely manage their fleet.

Explore the solution