CAN Bus Explained - A Simple Intro [2023]

Goto sonnepower to know more.

What is CAN bus?

Your car is like a human body:

The Controller Area Network (CAN bus) is the nervous system, enabling communication.

In turn, 'nodes' or 'electronic control units' (ECUs) are like parts of the body, interconnected via the CAN bus. Information sensed by one part can be shared with another.

So what is an ECU?

In an automotive CAN bus system, ECUs can e.g. be 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 and broadcast information (e.g. sensor data) via the CAN bus (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.

CAN bus physical & data link layer (OSI)

In more technical terms, the controller area network is described by a data link layer and physical layer. In the case of high speed CAN, ISO 11898-1 describes the data link layer, while ISO 11898-2 describes the physical layer. The role of CAN is often presented in the 7 layer OSI model as per the illustration.

The CAN bus physical layer defines things like cable types, electrical signal levels, node requirements, cable impedance etc. For example, ISO 11898-2 dictates a number of things, including below:

• Baud rate: CAN nodes must be connected via a two wire bus with baud rates up to 1 Mbit/s (Classical CAN) or 5 Mbit/s (CAN FD)
• Cable length: Maximal CAN cable lengths should be between 500 meters (125 kbit/s) and 40 meters (1 Mbit/s)
• Termination: The CAN bus must be properly terminated using a 120 Ohms CAN bus termination resistor at each end of the bus

In the context of automotive vehicle networks, you'll often encounter a number of different types of network types. Below we provide a very brief outline:

• High speed CAN bus: The focus of this article is on high speed CAN bus (ISO 11898). It is by far the most popular CAN standard for the physical layer, supporting bit rates from 40 kbit/s to 1 Mbit/s (Classical CAN). It provides simple cabling and is used in practically all automotive applications today. It also serves as the basis for several higher layer protocols such as OBD2, J1939, NMEA 2000, CANopen etc. The second generation of CAN is referred to as CAN FD (CAN with Flexible Data-rate)
• Low speed CAN bus: This standard enables bit rates from 40 kbit/s to 125 kbit/s and allows the CAN bus commmunication to continue even if there is a fault on one of the two wires - hence it is also referred to as 'fault tolerant CAN'. In this system, each CAN node has it's own CAN termination
• LIN bus: LIN bus is a lower cost supplement to CAN bus networks, with less harness and cheaper nodes. LIN bus clusters typically consist of a LIN master acting as gateway and up to 16 slave nodes. Typical use cases include e.g. non-critical vehicle functions like aircondition, door functionality etc. - for details see our LIN bus intro or LIN bus data logger article
• Automotive ethernet: This is increasingly being rolled out in the automotive sector to support the high bandwidth requirements of ADAS (Advanced Driver Assistance Systems), infotainment systems, cameras etc. Automotive ethernet offers much higher data transfer rates vs. CAN bus, but lacks some of the safety/performance features of Classical CAN and CAN FD. Most likely, the coming years will see both automotive ethernet, CAN FD and CAN XL being used in new automotive and industrial development

Top 4 benefits of CAN bus

The CAN bus standard is used in practically all vehicles and many machines due to below key benefits:

Simple & low cost

ECUs communicate via a single CAN system instead of via direct complex analogue signal lines - reducing errors, weight, wiring and costs

Easy access

The CAN bus provides 'one point-of-entry' to communicate with all network ECUs - enabling central diagnostics, data logging and configuration

Extremely robust

The system is robust towards electric disturbances and electromagnetic interference - ideal for safety critical applications (e.g. vehicles)

Efficient

CAN frames are prioritized by ID so that top priority data gets immediate bus access, without causing interruption of other frames or CAN errors

The CAN bus history in short

• Pre CAN: Car ECUs relied on complex point-to-point wiring
• 1986: Bosch developed the CAN 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)
• 2003: ISO 11898 becomes a standard series
• 2012: Bosch released the CAN FD 1.0 (flexible data rate)
• 2015: The CAN FD protocol is standardized (ISO 11898-1)
• 2016: The physical CAN layer for data-rates up to 5 Mbit/s standardized in ISO 11898-2

Today, CAN is standard in automotives (cars, trucks, buses, tractors, ...), ships, planes, EV batteries, machinery and more.

As vehicle functionality expands, so does the load on the CANbus. To support this, CAN FD (Flexible Data Rate) has been designed as the 'next generation' CAN bus.

Specifically, CAN FD offers three benefits (vs Classical CAN):

• It enables data rates up to 8 Mbit/s (vs 1 Mbit/s)
• It allows data payloads of up to 64 bytes (vs 8 bytes)
• It enables improved security via authentication

In short, CAN FD boosts speed and efficiency - and it is therefore being rolled out in newer vehicles. This will also drive an increasing need for IoT CAN FD data loggers.

"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"

Learn more

What is a CAN frame?

Communication over the CAN bus is done via CAN frames.

Below is a standard CAN frame with 11 bits identifier (CAN 2.0A), which is the type used in most cars. The extended 29-bit identifier frame (CAN 2.0B) is identical except the longer ID. It is e.g. used in the J1939 protocol for heavy-duty vehicles.

Note that the CAN ID and Data are highlighted - these are important when recording CAN bus data, as we'll see below.

• SOF: The Start of Frame is a 'dominant 0' to tell the other nodes that a CAN node intends to talk
• ID: The ID is the frame identifier - lower values have higher priority
• RTR: The Remote Transmission Request indicates whether a node sends data or requests dedicated data from another node
• Control: The Control contains the Identifier Extension Bit (IDE) which is a 'dominant 0' for 11-bit. It also contains the 4 bit Data Length Code (DLC) that specifies the length of the data bytes to be transmitted (0 to 8 bytes)
• Data: The Data contains the data bytes aka payload, which includes CAN signals that can be extracted and decoded for information
• CRC: The Cyclic Redundancy Check is used to ensure data integrity
• ACK: The ACK slot indicates if the node has acknowledged and received the data correctly
• EOF: The EOF marks the end of the CAN frame

The CAN frame has to satisfy a number of properties to be valid. If an erroneous CAN frame is transmitted, CAN nodes will automatically detect this and take action accordingly. This is referred to as CAN bus error handling, in which CAN nodes keep track of their own 'CAN error counters' and change state (active, passive, bus off) depending on their counters. The ability of problematic CAN nodes to transmit data is thus gracefully reduced to avoid further CAN errors and bus jamming. For details, see our intro to CAN bus error handling.

Logging CAN data - example use cases

There are several common use cases for recording CAN bus data frames:

Logging/streaming data from cars

OBD2 data from cars can e.g. be used to reduce fuel costs, improve driving, test prototype parts and insurance

obd2 logging

Heavy duty fleet telematics

J1939 data from trucks, buses, tractors etc. can be used in fleet management to reduce costs or improve safety

j1939 telematics

Predictive maintenance

Vehicles and machinery can be monitored via IoT CAN loggers in the cloud to predict and avoid breakdowns

predictive maintenance

Vehicle/machine blackbox

A CAN logger can serve as a 'blackbox' for vehicles or equipment, providing data for e.g. disputes or diagnostics

can bus blackbox

Do you have a CAN logging use case? Reach out for free sparring!

Contact us

How to log CAN bus data

Example: CANedge CAN logger

The CANedge1 lets you easily record data from any CAN bus to an 8-32 GB SD card. Simply connect it to e.g. a car or truck to start logging - and decode the data via free software/APIs.

Further, the CANedge2 (WiFi) and CANedge3 (3G/4G) let you push data to your own server - and update devices over-the-air.

learn about the CANedge

How to decode raw CAN data to 'physical values'

If you review the raw CAN bus data sample above, you will probably notice something:

Raw CAN bus data is not human-readable.

To interpret it, you need to decode the CAN frames into scaled engineering values aka physical values (km/h, degC, ...).

Below we show step-by-step how this works:

Each CAN frame on the bus contains a number of CAN signals (parameters) within the CAN databytes. For example, a CAN frame with a specific CAN ID may carry data for e.g. 2 CAN signals.

To extract the physical value of a CAN signal, the following information is required:

• Bit start: Which bit the signal starts at
• Bit length: The length of the signal in bits
• Offset: Value to offset the signal value by
• Scale: Value to multiply the signal value by

To extract a CAN signal, you 'carve out' the relevant bits, take the decimal value and perform a linear scaling:

physical_value = offset + scale * raw_value_decimal

Most often, the CAN bus "decoding rules" are proprietary and not easily available (except to the OEM, i.e. Original Equipment Manufacturer). There are a number of solutions to this when you're not the OEM:

• Record J1939 data: If you're logging raw data from heavy duty vehicles (trucks, tractors, ...), you're typically recording J1939 data. This is standardized across brands - and you can use our J1939 DBC file to decode data. See also our J1939 data logger intro
• Record OBD2/UDS data: If you need to log data from cars, you can typically request OBD2/UDS data, which is a standardized protocol across cars. For details see our OBD2 data logger intro and our free OBD2 DBC file
• Use public DBC files: For cars, online databases exist where others have reverse engineered proprietary some of the CAN data. We keep a list of such databases in our DBC file intro
• Reverse engineer data: You can also attempt to reverse engineer data yourself by using a CAN bus sniffer, though it can be time consuming and difficult
• Use sensor modules: In some cases you may need sensor data that is not available on the CAN bus (or which is difficult to reverse engineer). Here, sensor-to-CAN modules like the CANmod series can be used. You can integrate such modules with your CAN bus, or use them as add-ons for your CAN logger to add data such as GNSS/IMU or temperature data
• Partner with the OEM: In some cases the OEM will provide decoding rules as part of the CAN bus system technical specs. In other cases you may be able to get the information through e.g. a partnership

Note: If you need to load, edit or create new DBC files, check out our free online DBC file editor.

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 need a format for storing the conversion rules. Here, the CAN database (DBC) format is the industry standard - and is supported by most CAN bus decoder software incl. the supporting tools for our CAN loggers like asammdf and our MF4 decoders.

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

To illustrate how you can extract CAN signals from raw CAN data frames, we include below the previous J1939 sample data - but now decoded via a J1939 DBC file using the asammdf GUI tool.

As evident, the result is timeseries data with parameters like oil temperature, engine speed, GPS, fuel rate and speed:

For more on logging J1939 data, see our J1939 data logger and mining telematics articles. You can also learn how to analyze/visualize your CAN data via the free asammdf GUI tool or telematics dashboards.

What is the link between CAN, J1939, OBD2, CANopen, ...?

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 specify how data is communicated between CAN nodes of a given network.

Some of the most common standards include SAE J1939, OBD2 and CANopen. Further, these higher-layer protocols will increasingly be based on the 'next generation' of CAN, CAN FD (e.g. CANopen FD and J1939-17/22).

In addition to the above, the following CAN based higher layer protocols are relevant:

• Unified Diagnostic Services (UDS): A communication protocol used in ECUs to enable e.g. diagnostics
• NMEA 2000: A protocol used in most modern maritime vessels with similarities to J1939
• CCP/XCP on CAN: These protocols are commonly used in prototype development for ECU measurement/calibration

For more intros, see our guides section - or download the 'Ultimate Guide' PDF.

Need to log/stream CAN bus data?

Get your CAN logger today!

Recommended for you

5 Advantages of CAN Bus Protocol

Staff Writer

What is CAN Bus Protocol?

The Controller Area Network (CAN) bus protocol is rapidly growing in popularity among engineers who work with high-level industrial embedded systems. The protocol was developed by Robert Bosch GmbH in 1986 to help further the development of electronic communications in the automobile industry. 

In the early 1980s, vehicle manufacturers were beginning to incorporate an increasing number of electronic devices, such as active suspension, gear and lighting control, central locking, and ABS into cars and trucks for the first time. For these electronic devices to function in unison, time tasks correctly, and share data, they would need to be wired together.

Under the existing wiring standards, the electronic modules would communicate with each other using direct, point-to-point analog signal lines. Each module had a direct line connecting it to each other module that is needed to communicate with, an architecture that was time-consuming and used an excessive amount of wiring.

The CAN protocol eliminates the need for excessive wiring by allowing electronic devices to communicate with each other along a single multiplex wire that connects each node in the network to the main dashboard. The multiplex architecture allows signals to be combined and transmitted over the entire network along a single wire, such that each electronic module in the vehicle receives data from sensors and actuators in a timely fashion.

The CAN protocol was standardized by the International Standards Organization (ISO) in 1993 and has since been divided into two standards: ISO 11898-1, which describes the data link layer of the protocol, and ISO 11898-2 which describes the physical layer. The unique properties of the CAN bus protocol have led to its increased popularity and adoption across industry verticals that leverage embedded networks, such as healthcare, manufacturing, and entertainment.

For more information, please visit canbus monitor.

The 5 Advantages of CAN Protocol

1. Low Cost

When the CAN protocol was first created, its primary goal was to enable faster communication between electronic devices and modules in vehicles while reducing the amount of wiring (and the amount of copper) necessary. This is accomplished through the use of multiplex wiring, which enables the combination of analog and digital signals and their transmission over a shared medium.

To understand how multiplexing drives down the cost of wiring vehicles, we need to know a bit more about how wiring architecture worked before the CAN bus protocol was created. Along with the electronic devices or modules that control vehicle subsystems, cars and trucks also have sensors and actuators that capture data from the vehicle's operation and communicate it to modules where it is needed.

A vehicle would have sensors for capturing data about its speed and acceleration, but feeding that data would require dedicated wires to each individual data recipient - that's one wire to communicate with the airbag system, one wire to communicate with the ABS braking system, another dedicated wire to engine control, etc. With the CAN protocol, a single wire connects all of the electronic systems, actuators, and sensors in the vehicle into one circuit that facilitates high-speed data transmission between all components.

The first vehicle to use CAN bus wiring was the BMW 850 coupe released in 1986. Implementation of CAN bus architecture reduced the length of wiring in the BMW 850 by 1.25 miles, which in turn reduced its weight by well over 100 pounds. Based on the current cost of copper wiring, the total cost savings from the saved materials would amount to nearly $600. Not only that, but the speed of communication was increased, with signal rates ranging from 125 kbps to 1 Mbps.

Low cost of implementation is one of the main reasons that we're seeing widespread adoption of the CAN bus protocol. Less wiring means less labor and lower material costs for embedded engineers.

2. Built-in Error Detection

One of the key features of the CAN bus protocol is that it supports centralized control over electronic devices that are connected to the network. In the CAN bus physical layer, each electronic device is called a node. Nodes can communicate with other nodes on the network, and each node requires a microcontroller, CAN controller, and CAN transmitter.

While each node is capable of sending and receiving messages, not all nodes can be communicating at once. The CAN bus protocol uses a technique called lossless bitwise arbitration to resolve these situations and determine which node should be given "priority" to communicate its message first.

Error handling is built into the CAN protocol, with each node checking for errors in transmission and maintaining its own error counter. Nodes transmit a special Error Flag message when errors are detected and will destroy the offending bus traffic to prevent it from spreading through the system. Even the node that is generating the fault will detect its own error in transmission, raising its error counter and eventually leading the device to "bus off" and cease participating in network traffic. In this way, CAN nodes can both detect errors and prevent faulty devices from creating useless bus traffic.

3. Robustness

Durability and reliability are key areas of concern when choosing a communication protocol for deployment in your embedded engineering projects. As you deploy your products into the live environment, you'll want to choose a communication protocol that is self-sustaining, with the ability to carry on operating for long periods of time without outside maintenance or intervention.

This need makes the protocol's error detection capabilities particularly advantageous, as they enable systems to identify and recover from errors on their own without intervention from an outside actor. There are five mechanisms for detecting errors in the CAN protocol:

1. Bit monitoring

2. Bit stuffing

3. Frame check

4. Acknowledgment check

5. Cyclic redundancy check

CAN high-speed bus lines are highly resistant to electrical disturbances, and the CAN controllers and transceivers that communicate with electronic devices are available in industrial or extended temperature ranges.

A CAN bus cable is typically vulnerable to the failure modes listed in the ISO 11898 standard, such as:

1. CAN_H interrupted

2. CAN_L interrupted

3. CAN_H shorted to battery voltage

4. CAN_L shorted to ground

5. CAN_H shorted to ground

6. CAN_L shorted to battery voltage

7. CAN_L shorted to CAN_H wire

8. CAN_H and CAN_L interrupted at the same location

9. Loss of connection to the termination network

While most CAN transceivers will not survive these types of failures, some electronics manufacturers have constructed fault-resistant CAN transceivers that can handle all of them, though they may have a restricted maximum speed as a trade-off. Together, these features expand the suitability of CAN bus networks for applications in the most rugged and demanding environments.

4. Speed

When the CAN protocol was first defined, it was described in three layers: the object layer, the physical layer, and the transfer layer. Later, when the CAN specification was created, specific definitions for the physical layer were excluded. This gave engineers the flexibility to design systems with transmission mediums and voltages that suited their intended applications. Later, to help drive adoption of CAN devices and networks, standards were finally released for the CAN physical later in the form of ISO 11898-2.

There are currently two defined physical layer standards, two types of CAN protocol, each with its own advantages and disadvantages.

High Speed CAN offers signal transfer rates of between 40 kbps and 1 Mbps, depending on the length of the cable. CAN-based bus protocols like DeviceNet and CANopen use this physical standard to support simple cable connections with high-speed data transfer. Low Speed CAN network offers lower signal transfer rates that may start at 40kbps but are often capped at or near 125 kbps. The lower signaling rates allow communication to continue on the bus, even when a wiring failure takes place. While high-speed CAN networks terminate at either end of the bus line with a 120-ohm resistor, each device in a low-speed CAN network has its own termination. Low Speed CAN network exhibits greater fault tolerance and are vulnerable to fewer failure modes, but slower transfer speeds make them poorly suited to networks that require rapid and frequent communication.

5. Flexibility

offers signal transfer rates of between 40 kbps and 1 Mbps, depending on the length of the cable. CAN-based bus protocols like DeviceNet and CANopen use this physical standard to support simple cable connections with high-speed data transfer.network offers lower signal transfer rates that may start at 40kbps but are often capped at or near 125 kbps. The lower signaling rates allow communication to continue on the bus, even when a wiring failure takes place. While high-speed CAN networks terminate at either end of the bus line with a 120-ohm resistor, each device in a low-speed CAN network has its own termination. Low Speed CAN network exhibits greater fault tolerance and are vulnerable to fewer failure modes, but slower transfer speeds make them poorly suited to networks that require rapid and frequent communication.

To appreciate the flexibility of the CAN bus protocol in communications, we need to differentiate between address-based and message-based protocols. In an address-based communication protocol, nodes communicate directly with each other by configuring themselves onto the same protocol address.

The CAN bus protocol is known as a message-based communication protocol. In this type of protocol, nodes on the bus have no identifying information associated with them. As a result, nodes can easily be added or removed (a process called hot-plugging) without performing any software or hardware updates on the system.

This feature makes it easy for engineers to integrate new electronic devices into the CAN bus network without significant programming overhead and supports a modular system that is easily modified to suit your specs or requirements.

The Future of CAN Bus Protocol

CAN bus technology has been widely adopted across industry verticals. Thanks to its robustness, flexibility and the associated cost savings, we have seen CAN bus networks implemented in:

• Trucks, buses and other passenger vehicles

• Gasoline-powered and electric cars

• Movie-set cameras and lighting systems

• Gaming machines

• Building automation equipment

• Industrial automation and manufacturing equipment

• Medical devices and instrumentation

In the future, the CAN bus protocol will remain the networking technology of choice for connecting electronic devices that require frequent, simple communications. Ethernet TCP/IP, a leading alternative to the CAN bus, still cannot deliver the same low resource requirements, low-cost implementations, reliability and error recovery capabilities of CAN bus networks. We will continue to see CAN networks deployed in IoT devices, industrial automation applications, connected medical devices and even more demanding and high-tech applications like satellites and spacecraft.

How Total Phase Deals with CAN Protocol 

Are you planning to use the CAN bus protocol in an embedded engineering project? Whether you're building a product for the automotive, military, industrial, or aerospace sector, you'll need to invest in the right tools to help you program, monitor and debug your product.

Total Phase delivers tools with the functionality you need to send test transmissions on your CAN bus network or conduct non-intrusive monitoring to investigate network traffic, detect errors, and correct them as quickly as possible. With the Komodo CAN Solo Interface, embedded engineers can transmit data or monitor the bus. The Komodo CAN Duo Interface features two CAN channels, allowing engineers to emulate and monitor data from two CAN bus networks at the same time.

Want more insight into how our tools work for your specific application? Complete our Request a Demo Form Submission and we'll show you how easy it is to debug your next embedded CAN bus network project with the right tools from Total Phase.

 

If you are looking for more details, kindly visit distributed io vs remote io.