~

CAN Bus: the operating principles

CAN BUS system.

What is the CAN BUS system?

In an automotive CAN BUS system, Electronic Control Units (ECUs) can be, for example, the engine control, airbags, audio system, etc. A modern car can have up to 70 ECUs - and each of them can have information that needs to be shared with other parts of the network.

Here's where the CAN standard comes into play:

The CAN BUS system allows each ECU to communicate with all the other ECUs - without complex dedicated wiring. Specifically, an ECU can prepare and transmit information (such as sensor data) via the CAN BUS (composed of two wires, CAN low and CAN high). The transmitted data is accepted by all the other ECUs on the CAN network - and each of them can then check the data and decide whether to receive or ignore it.

Physical layer and data link layer of the CAN BUS (OSI)

In more technical terms, the area control network is described by a data link layer and a 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 OSI 7-layer model as illustrated.

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

  • 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: The maximum lengths of CAN cable 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-ohm CAN bus termination resistor at each end of the bus.

High-speed CAN, Low-speed CAN, LIN BUS,...

In the context of automotive vehicle networks, you are likely to encounter various types of networks. Below we provide a brief overview:

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 transmission speeds from 40 kbit/s to 1 Mbit/s (Classical CAN). It provides simple wiring and is used virtually in all modern automotive applications. It also serves as the basis for several higher-level protocols such as OBD2, J1939, NMEA 2000, CANopen, etc. The second generation of CAN is called CAN FD (Flexible Data Rate).

Low-speed CAN BUS: This standard allows transmission speeds from 40 kbit/s to 125 kbit/s and enables communication of the CAN BUS even if there is a fault on one of the two wires - hence it is also called 'fault-tolerant CAN BUS'. In this system, each CAN node has its CAN termination.

LIN BUS: The LIN BUS is a low-cost supplement to CAN BUS networks, with less wiring and cheaper nodes. LIN BUS clusters typically consist of a LIN master acting as a gateway and up to 16 slave nodes. Typical use cases include non-critical vehicle functions such as air conditioning, door functionality, etc. - for details see our introduction to LIN BUS or the LIN BUS data logger article.

Automotive Ethernet: This is increasingly being introduced in the automotive sector to support the broadband requirements of Advanced Driver Assistance Systems (ADAS), infotainment systems, cameras, etc. Automotive Ethernet offers much higher data transfer speeds than CAN BUS, but lacks some of the security/performance features of Classical CAN and CAN FD. Most likely, in the coming years, both Automotive Ethernet and CAN FD and CAN XL will be used in automotive and industrial development.

The 4 main advantages of the CAN BUS

The CAN BUS standard is used virtually in all vehicles and many machines thanks to the following key advantages:

The history of the CAN BUS in brief

Pre-CAN: Car ECUs relied on complex point-to-point wiring.

  • 1986: Bosch developed the CAN protocol as a solution.
  • 1991: Bosch released CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29 bit).
  • 1993: CAN is adopted as an international standard (ISO 11898).
  • 2003: ISO 11898 becomes a standard series.
  • 2012: Bosch released CAN FD 1.0 (Flexible Data Rate).
  • 2015: The CAN FD protocol is standardized (ISO 11898-1).
  • 2016: The CAN physical layer for data rates up to 5 Mbit/s is standardized in ISO 11898-2.

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

The future of the CAN BUS

Looking ahead, the CAN BUS protocol will remain relevant - although it will be influenced by significant trends:

A need for increasingly advanced vehicle functionalities. The rise of cloud computing. Growth of the Internet of Things (IoT) and connected vehicles. The impact of autonomous vehicles. The use of AI in data analysis (see e.g. our introduction to ChatGPT + CAN BUS).

In particular, the increase in connected vehicles (V2X) and the cloud will lead to rapid growth in vehicle telemetry and CAN BUS IoT data loggers.

In turn, bringing the CAN BUS network 'online' also exposes vehicles to security risks - and may require a transition to new CAN BUS protocols such as CAN FD.

The growth of CAN FD

With the expansion of vehicle functionalities, the load on the CAN BUS also increases. To support this, CAN FD (Flexible Data Rate) has been designed as the 'next generation' of the CAN BUS.

In particular, CAN FD offers three advantages (compared to Classical CAN):

  • Allows data rates up to 8 Mbit/s (compared to 1 Mbit/s).
  • Allows data payloads up to 64 bytes (compared to 8 bytes).
  • Provides improved security through authentication.

In short, CAN FD increases speed and efficiency - and is therefore being implemented in newer vehicles. This will also increase the need for CAN FD IoT data loggers.

"The first vehicles using CAN FD will appear in 2019/2020 and CAN FD will gradually replace Classical CAN."

CAN in Automation (CiA), "CAN 2020: The future of CAN technology" -Learn more-

What is a CAN frame?

Communication via the CAN BUS occurs through CAN frames.

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

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

The CAN Bus protocol message field

  • SOF: The start of the frame is a 'dominant 0' to inform other nodes that a CAN node intends to speak.
  • ID: The ID is the frame identifier - lower values have higher priority.
  • RTR: The remote transmission request indicates whether a node is sending data or requesting 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 data length code as a 4-bit value (DLC) specifying the length of the data bytes to be transmitted (from 0 to 8 bytes).
  • Data: The data contains the data bytes aka payload, which includes the 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 whether the node has received and correctly acknowledged the data.
  • EOF: EOF marks the end of the CAN frame.

CAN BUS errors

The CAN frame must meet a series of properties to be valid. If an erroneous CAN frame is transmitted, CAN nodes will automatically detect this and take necessary measures. This is defined as CAN BUS error handling, where CAN nodes keep track of their own 'CAN error counters' and change states (active, passive, bus off) depending on their counters. The ability of problematic CAN nodes to transmit data is thus delicately reduced to avoid further CAN BUS errors and bus jams. For details, see our introduction to CAN BUS error handling.

CAN data logging - illustrative use cases

There are several common use cases for logging CAN BUS data:

How to log CAN BUS data

As mentioned, two CAN fields are important for CAN logging: The CAN ID and the Data.

To log CAN data, a CAN logger is required. This allows logging CAN data with timestamps on an SD card. In some cases, a CAN interface is needed to transmit the data to a PC - e.g. for car hacking.

Connecting to the CAN BUS

The first step is to connect the CAN logger to the CAN BUS. Typically, this involves using an adapter cable:

  • Auto: In most cars, simply using an OBD2 adapter is sufficient for connection. In most cars, this will allow you to log raw CAN data, as well as perform requests to log OBD2 or UDS (Unified Diagnostic Services) data.
  • Heavy vehicles: To log J1939 data from trucks, excavators, tractors, etc., you can connect to the J1939 CAN BUS via a standard J1939 connector cable (9-pin deutsch).
  • Marine: Most ships/boats use the NMEA 2000 protocol and enable connection via an M12 adapter to log marine data.
  • CANopen: For logging CANopen, it is often possible to directly use the CiA 303-1 DB9 connector (i.e. the default connector for our CAN data loggers), optionally with a CAN BUS extension.
  • Contactless: If no connector is available, a typical solution is to use a contactless CAN reader - e.g. the CANCrocodile. This allows you to log data directly from the raw CAN twisted pair wiring, without direct connection to the CAN BUS (often useful for warranty purposes).
  • Other: In practice, countless other connectors are used and often a custom CAN BUS adapter needs to be created - in this case, a generic open-wire adapter is helpful.

Once the correct connector has been identified and the pin-out verified, you can connect the CAN logger to start logging data. For the CANedge/CLX000, the CAN baud rate is automatically detected and the device will immediately start logging raw CAN data.

Example: raw CAN data sample (J1939)

You can optionally download OBD2 and J1939 data samples from the CANedge2 in our introductory documents. You can upload for example this data into free CAN BUS decoding software tools.

CANedge data is logged in popular binary format MF4 and can be converted to any file format using our simple MF4 converters (e.g. to CSV, ASC, TRC, ...).

Below is an example CSV of raw CAN frames logged from a heavy truck using the J1939 protocol. Note that the CAN IDs and data bytes are in hexadecimal format:

Example: CAN BUS logger CANedge

The CANedge1 allows you to easily log data from any CAN BUS on an 8-32 GB SD card. Simply connect it to e.g. a car or a truck to start logging - and decode the data using free software/API.

Additionally, the CANedge2 (WiFi) and CANedge3 (3G/4G) allow you to send the data to your own server - and update the devices over-the-air. -Learn more about the CANedge-

How to decode raw CAN data into 'physical values'

If you examine the raw CAN data sample above, you will likely notice something:

Raw CAN data is not readable by humans.

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

Below we show step by step how it works:

Extracting CAN signals from raw CAN frames

Each CAN frame on the bus contains a number of CAN signals (parameters) within the CAN data bytes. 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:

  • Start bit: At which bit the signal starts.
  • Length in bits: The length of the signal in bits.
  • Offset: Value to offset the signal value.
  • Scale: Value to multiply the signal value.

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

physical_value = offset + scale * raw_decimal_value

The challenge of proprietary CAN data

Very often, the 'CAN decoding rules' are proprietary and not easily available (except for the OEM, i.e., the original manufacturer). There are several solutions to this when you are not the OEM:

  • Log J1939 data: If you are logging raw data from heavy vehicles (trucks, tractors, ...), you are probably logging J1939 data. This is standardized across brands - and you can use our J1939 DBC file to decode the data. Also, see our introduction to J1939 data logger.
  • Log OBD2/UDS data: If you need to log data from cars, you can request OBD2/UDS data, which is a standardized protocol across cars. For details see our introduction to OBD2 data logger and our free OBD2 DBC file.
  • Use public DBC files: For cars, there are online databases where others have decoded some of the proprietary CAN data. We maintain a list of such databases in our introduction to DBC file.
  • Reverse engineer the data: You can also try to reverse engineer the data yourself using a CAN BUS sniffer, although it can be laborious and challenging.
  • Use sensor modules: In some cases, you may need sensor data that is not available on the CAN BUS (or is difficult to reverse engineer). Here, CAN sensor modules like the CANmod series can be used. You can integrate such modules with your CAN BUS, or use them as add-ons to your CAN logger to add data such as GNSS/IMU or temperature data.
  • Collaborate with the OEM: In some cases, you can also collaborate with the OEM to get proprietary decoding rules. This may be necessary for optimizing vehicle control parameters or for debugging/diagnostics.

Real-time CAN decoding

Our site supports decoding of CAN frames in real-time for diagnosis/troubleshooting or real-time vehicle monitoring. We specialize in decoding:

  • OBD2: Including support for OBD2 PID and the entire SAE J1979 standard PIDs.
  • J1939: Support for standard J1939 parameters including J1939 PGNs, SPNs, etc.
  • NMEA 2000: Support for standard NMEA 2000 data, including NMEA 2000 PGN messages.

Our fleet monitoring software is designed to support real-time CAN BUS data analysis across a wide range of industries and use cases, such as:

  • Remote diagnostics: Monitor real-time CAN BUS data to identify vehicle issues - e.g. in the field of a broken car.
  • Vehicle safety: Monitor real-time CAN BUS data to identify hazardous driving situations (e.g. driver behavior) or malfunctioning vehicles.
  • Autonomous deployment: Monitor real-time CAN BUS data to monitor autonomous vehicles (e.g. drones, robots) and ensure they are functioning properly.
  • Fleet: Monitor real-time CAN BUS data for predictive fleet maintenance and optimize vehicle downtime.
  • Cargo tracking: Monitor real-time CAN BUS data to track the position and condition of cargo in transit.

Additionally, we support a wide range of hardware for capturing real-time CAN BUS data, such as:

  • OBD2 interfaces: Support for standard and advanced OBD2 interfaces to capture real-time data directly from the ECU.
  • OBD2 gateways: Support for OBD2 gateways to capture and transmit real-time CAN BUS data to a remote monitoring platform.
  • J1939 interfaces: Support for J1939 interfaces to capture real-time data directly from the ECU.
  • J1939 gateways: Support for J1939 gateways to capture and transmit real-time CAN BUS data to a remote monitoring platform.
  • NMEA 2000 interfaces: Support for NMEA 2000 interfaces to capture real-time data directly from the NMEA 2000 BUS.
  • NMEA 2000 gateways: Support for NMEA 2000 gateways to capture and transmit real-time CAN BUS data.

[Top]