Car Bus Knowledge Primer: Introduction

Preface

The automotive industry is exacting, requiring products to be designed according to strict standards. First, let’s clarify the relationship between ISO and SAE.

The SAE J-series standards cover ground vehicles and encompass nearly every electronic component. While SAE standards are primarily oriented toward the U.S. market, ISO standards are international; both GB (China) and EU standards often reference ISO. ISO frequently adopts standards originally drafted by SAE, and a single ISO standard may incorporate multiple SAE standards.

A modern vehicle contains numerous Electronic Control Units (ECUs) responsible for various tasks, such as door control, lighting, and engine management. Initially, these systems used point-to-point communication, where each signal required a dedicated wire. As the number of ECUs increased, the wiring harness grew exponentially—raising costs, consuming space, adding weight, and increasing the complexity and failure risk of internal connections.

p2p

To address this, engineers adopted a bus-based architecture. All ECUs connect to a shared communication bus, eliminating the inefficiencies of point-to-point wiring.

bus

SAE classifies in-vehicle bus networks into four categories by transmission speed:

Category	Bit rate	Use cases	Protocol type
Class A	Below 10Kb/s	Doors, A/C, seats	LIN
Class B	10 to 125Kb/s	Emissions data, cluster data	CAN
Class C	125Kb/s to 1Mb/s	Traction control, braking systems	CAN
Class D	1Mb/s to 10Mb/s	Multimedia systems	Most, FlexRay, Byteflight

Today, most in-vehicle networks globally use CAN, typically alongside LIN, MOST, FlexRay, or Ethernet. CAN remains the most widely deployed standard. These notes focus on CAN and extend to related topics. Since OEM implementations can vary and may not strictly adhere to the specification (often to meet specific business requirements), these notes will primarily follow ISO specifications for consistency.

CAN

CAN (Controller Area Network), compliant with ISO 11898, is a communication protocol widely used in manufacturing and the automotive industry. It supports high speeds and reliable long-distance transmission, allowing embedded systems and ECUs to communicate efficiently.

In 1992, the CAN data link layer and high-speed physical layer were standardized in ISO 11898. The standard consists of seven parts. While Parts 4, 5, and 6 address certain limitations of the earlier parts, they are less common in the current automotive landscape. Therefore, I will focus on the core parts. The parts are titled as follows:

ISO 11898-1 Data link layer and physical signaling
ISO 11898-2 High-speed medium access unit
ISO 11898-3 Low-speed, fault-tolerant medium access unit
ISO 11898-4 Time-triggered communication
ISO 11898-5 Low-power high-speed medium access unit
ISO 11898-6 Selective wake-up high-speed medium access unit

The figure below classifies CAN from different perspectives: the relationship among CAN standards, the network model layers, and implementations. Currently, ISO 11898 mainly covers the Physical Layer (PL), Data Link Layer (DLL), and Application Layer (AL).

reference_model

According to ISO/IEC 8802-2 (IEEE 802.2), the data link layer can be split into two sublayers:

Logical Link Control (LLC)
- Receive filtering
- Overload notification
- Recovery management
Medium Access Control (MAC)
- Data encapsulation/decapsulation
- Frame encoding (stuffing/destuffing)
- Medium access management
- Error detection
- Fault confinement
- Serialization/deserialization

The physical layer can be split into three sublayers:

Physical Coding Sub-layer (PCS)
Physical Medium Attachment (PMA)
Medium Dependent Interface (MDI)

From the CAN perspective, an ECU can be viewed as consisting of:

Microcontroller Unit (MCU), AL
CAN Controller, DLL + PCS of PL
CAN Transceiver, PMA and MDI of PL

CAN Physical Layer

CAN uses a two-wire differential signal, transmitting data over CAN_H (+) and CAN_L (-). The physical medium can be coaxial cable, optical fiber, or twisted pair. Differential signaling reduces susceptibility to external interference, allowing the receiver to reliably extract the signal.

Typically, a twisted pair forms the serial bus, with termination resistors (matching the characteristic impedance) placed at the endpoints to prevent signal reflections. Newer implementations often use distributed termination (ECU load resistors), combining a “central termination resistor” in the main control unit with high-ohmic resistors in other nodes.

CAN employs a multi-master communication model. All nodes connect to the shared bus and messages are broadcast to every node. Theoretically, there is no hard limit on the node count, though electrical factors impose practical limits.

can_net

According to the MAU definition, CAN signaling can be categorized into High-speed CAN (ISO 11898-2) and Low-speed CAN (ISO 11898-3).

ISO 11519 was the original low-speed CAN standard. Initially, both the high-speed CAN data link layer and physical layer were specified in ISO 11898. Later, this was split into ISO 11898-1 (Data Link Layer) and ISO 11898-2 (Physical Layer). ISO 11519-2-1994 was replaced in 2006 by ISO 11898-3:2006; products compliant with ISO 11898-3 maintain backward compatibility with ISO 11519-2.

ISO_CAN

High-speed CAN typically runs at 500Kbps or 250Kbps and is used for real-time communications such as engine and ABS.
Low-speed CAN typically runs at 125Kbps and is used for door locks, lighting, airbags, A/C, etc.

In-vehicle networks can employ various topologies, but ISO 11898 recommends linear and star configurations.

High-speed CAN typically uses a linear topology with 120Ω termination. To ensure signal integrity, stub lines connecting nodes to the main bus should be kept as short as possible.

interconnection

Low-speed CAN can use either linear or star topology.

star_topology

A vehicle’s internal network topology can be composed of multiple networks. Ethernet (Internet Protocol) is commonly used as the backbone network.

Different networks interconnect through a gateway (Gateway, GW). A gateway provides compatibility functions such as protocol translation and data exchange.

The gateway’s main function is to allow control units connected to different data buses to exchange data. It can be installed in the instrument cluster or inside an ECU.

Low-speed CAN is often referred to as fault-tolerant CAN. It uses larger signal swings than high-speed CAN and can maintain communication even if one of the wires (CAN_H or CAN_L) is shorted or open-circuited, reverting to single-wire operation.

High-speed CAN waveform:

Low-speed CAN waveform:

ISO11898-3_Waveform

When one device drives a low level while another drives a high level, the bus level is still low. From a logic perspective, a CAN bus has two logic states: dominant and recessive. You can treat it as a binary stream: dominant is 0, recessive is 1.

Identifying CAN Buses

First, find twisted-pair wires. You can often distinguish CAN buses in the wiring harness by color, but the number and color scheme can vary by manufacturer.

CAN_H
- Powertrain CAN: orange/black
- Convenience CAN: orange/green
- Infotainment CAN: orange/purple
- Instrument CAN: orange/blue
- Diagnostic CAN: orange/red
CAN_L: orange/brown

Assuming a nominal (V_{cc}) of 5V, the CAN bus voltages are as follows. These characteristics can help identify CAN wires in a harness. Note that some buses (commonly convenience and infotainment) feature sleep modes, whereas powertrain buses typically do not. Newer implementations often include low-power states.

High-speed CAN:
- Dominant: CAN_H 3.5V, CAN_L 1.5V, differential 2V
- Recessive: CAN_H and CAN_L both 2.5V
Low-speed CAN:
- Dominant: CAN_H 3.6V, CAN_L 1.4V, differential 2.2V
- Recessive: CAN_H 4.7V, CAN_L 0.3V, differential 4.4V

Application-Layer Extension Protocols Based on CAN

CAN can be divided into higher-layer protocols and lower-layer protocols. CAN application-layer protocols are also called CAN-based higher-layer protocols (HLPs), typically considered to be at layer 7.

Below are some CAN-based higher-layer extension protocols:

1992: CiA 201 series (CAN Application Layer)
1994: IEC 62026-3 (DeviceNet)
1994: SAE J1939 series
1994: EN 50325-4 (CANopen)
1999: ISO 11992 series
1999: MilCAN
2000: IEC 61162-3 (NMEA 2000)
2002: ISO 11783 series (Isobus)
2004: ISO 15765 series (OBDII/ISO-TP)
2007: Arinc 825/826
2015: UAVCAN

Frames

The physical layer converts analog signals into digital bits for the data link layer. A frame serves as the Protocol Data Unit (PDU) for the data link layer. PDU terminology varies by layer: the physical layer transmits bits, the network layer handles packets, and the application layer processes messages.

CAN nodes’ sending and receiving are governed by four different frame types:

Data Frame (DF): carries data from the transmitting node to receiving nodes
Remote Frame (RF): requests other nodes to transmit a data frame with the same identifier
Error Frame (EF): sent when a node detects an error
Overload Frame (OF): inserts a delay between the preceding and following data frame (or remote frame)

Data frames and remote frames are separated from the previous frame (regardless of type) by an interframe space. Error frames and overload frames do not use interframe space to separate from the previous frame.

interframe_space

Interframe space includes the intermission field and bus idle. The intermission field consists of three recessive bits. When no frame is transmitted on the bus, it is idle; at that time the bus is at a static level, i.e., recessive (1), for an arbitrary length of time.

Data Frames

The CAN family includes classic CAN and the newer CAN FD (CAN with Flexible Data rate).

Classic CAN refers to the CAN 2.0 specification, introduced by Bosch in 1991, which includes Part A (standard 11-bit identifier) and Part B (extended 29-bit identifier). CAN FD (“Flexible Data-rate”), introduced in 2011, allows for higher data throughput. Consequently, there are four types of data frames:

Classic base frame (Classical Base Frame Format, CBFF)
Classic extended frame (Classical Extended Frame Format, CEFF)
FD base frame (FD Base Frame Format, FDFF)
FD extended frame (FD Extended Frame Format, FEFF)

The overall structure of a CAN data frame is as follows:

can_frame

It mainly consists of eight parts:

SOF
Arbitration field
Control field
Data field
CRC field
ACK field
EOF
Intermission

Base Frame

Classic CAN has an 8-byte payload and a 1Mb/s bit rate. CAN FD (CAN with Flexible Data-Rate) supports payloads larger than 8 bytes—up to 64 bytes—so the bit rate can reach 8Mb/s.

canfd02

CAN and CAN FD have similar frame structures, but the details differ.

frame_structure

Extended Frame

id-examples

Extended frames can be concatenated to form a longer ID. In the extended frame, Substitute Remote Request (SRR) replaces Remote Transmission Request (RTR), and the Identifier Extension (IDE) bit is also set to 1.

Arbitration

Both CAN and Ethernet function as broadcast networks. Ethernet handles collisions using Carrier Sense Multiple Access with Collision Detection (CSMA/CD), where nodes “listen” to the medium and back off if a collision occurs.

CAN uses a similar carrier-sense mechanism but resolves collisions differently, using a process called arbitration. When the bus is idle, any node is free to transmit.

Arbitration is bit-wise. Transmission begins with a Start of Frame (SOF) bit (dominant, 0) once the bus is idle. During the subsequent arbitration field, the transmitter monitors the bus level while transmitting. If the monitored level differs from the transmitted level, it knows it has lost arbitration to a higher-priority message. Dominant bits (0) overwrite recessive bits (1), meaning the message with the lower numerical ID has higher priority.

If the bus level matches the transmitted level, continue with the next bit.
If another node drives a dominant bit (0) on the bus, and this node transmits a recessive bit (1), it loses arbitration and stops transmitting any bits.
If another node drives a recessive bit (1) on the bus, and this node transmits a dominant bit (0), the transmitting node will detect an error.

In the figure below, Node3 has the lowest arbitration ID value, so it wins and transmits first.

can_arbitration

Bit-wise arbitration can resolve conflicts between different IDs or different frame types. If a data frame conflicts with a remote frame, the data frame has priority because the RTR bit in a data frame is dominant (0). If conflicting frames have the same ID and the same type, arbitration fails and an error frame is generated. A lack of response or a corrupted frame due to errors can also cause arbitration failure; in such cases the frame is automatically retransmitted.

When multiple nodes transmit simultaneously, the conflict is resolved without data loss for the highest-priority message. The winning node continues to transmit as if nothing happened, while the losing nodes immediately cease transmission and switch to receiving mode. They will attempt to retransmit once the bus becomes idle again.

This mechanism is known as non-destructive arbitration, as the winning frame is preserved intact. This stands in contrast to Ethernet’s CSMA/CD, where a collision typically results in the destruction of both packets and requires both nodes to back off.

In DeviceNet (IEC 62026-3), bit-wise arbitration and non-destructive arbitration together are referred to as Carrier Sense Multiple Access/Non-destructive Bit-wise Arbitration (CSMA/NBA).

Because standard CAN as defined in ISO 11898-1 is event-triggered and insufficient in real-time aspects, ISO 11898-4 describes a time-triggered CAN transmission mechanism (TTCAN) that avoids message conflicts by using time slots. It has not yet been widely implemented.

TTCAN

CAN has multiple error-detection measures: monitoring and comparing the transmitter’s output level with the monitored bus level, checking frame format, CRC (15-bit for classic CAN; 17-bit for CAN-FD payload length 8–16 bytes; 21-bit for payload length 20–64 bytes), checking stuff bits, and checking ACK.

On-Board Diagnostics

On-Board Diagnostics (OBD) was originally implemented for emissions monitoring. The concept originated with General Motors’ Assembly Line Diagnostic Link (ALDL). Standardized Diagnostic Trouble Codes (DTCs, defined in ISO 15031-6/SAE J2012) allow faults within the vehicle to be quickly identified.

ISO 15031 specifies communication between external equipment and vehicle emission-related diagnostic systems, and it has seven parts:

ISO 15031-1 General information and use-case definitions
ISO 15031-2/SAE J1930 Terminology, definitions, abbreviations and acronyms guidelines
ISO 15031-3/SAE J1962 Diagnostic connector and related electrical circuits specification and use
ISO 15031-4/SAE J1978 External test equipment
ISO 15031-5/SAE J1979 Emission-related diagnostic services
ISO 15031-6/SAE J2012 Standardized DTC definitions
ISO 15031-7/SAE J2186 Data link security

OBD-II

During the OBD-I era, connectors, locations, DTCs, and communication protocols varied significantly by manufacturer. OBD-II standardized these elements. The OBD-II connector, defined by SAE J1962, uses a 16-pin (2x8) D-shaped layout.

J1962_wire

femail_pinout

Using the female connector as an example, the pin definitions are shown below.

With CAN, pin 4 is chassis ground, pin 5 is signal ground, pin 6 is CAN_H, pin 14 is CAN_L, and pin 16 is +12V DC. ISO 15031-3 also defines pins for other protocols (ISO 14230, SAE J1850).

pinout_assignment

Today, the mainstream standard for vehicle diagnostics is OBD-II (ISO 15765), a CAN-based extension protocol. In 1996, the U.S. required all vehicles to implement OBD-II. In 2003, the EU required all vehicles to implement EOBD (nearly identical to OBD-II). In 2006, China’s National III standard required vehicles to include OBD for emissions testing. As a result, almost all vehicles now have an OBD interface—usually under the driver’s side dashboard—and it is commonly connected to a computer via DB9.

UK DB9 layout:

US DB9 layout:

The OBD-II specification consists of four parts:

ISO 15765-1 General information
ISO 15765-2 Network layer services specification (ISO-TP)
ISO 15765-3 Application layer specification; implementation of UDS over CAN
ISO 15765-4 Physical layer to network layer specification; session layer

Mapping OBD-II to the OSI seven-layer model, it can be divided into three categories:

Diagnostic services: see ISO 15765-3
Network layer services: see ISO 15765-2
CAN services: see ISO 11898

UDS

In the comparison table below, the right side represents the legally mandated OBD-II specifications, while the left side depicts OEM-specific Enhanced Diagnostics. Unified Diagnostic Services (UDS) implements a modular diagnostic framework at the application layer, standardized for use across all ECUs.

OSI_layers_table