WORKING WITH AUTOMOTIVE CAN PROTOCOL

In the past, electronic devices in vehicles were connected via point-to-point wiring systems. As automotive manufacturers integrated more electronics into vehicles, the resulting wire harnesses grew bulky, heavy, and expensive. To address this, the industry introduced a specialized internal communication network — the vehicle bus — that interconnects electronic control units (ECUs) inside a vehicle. The automotive CAN IVN protocol (In-Vehicle Network protocol) became the dominant standard for this purpose, dramatically reducing wiring cost, weight, and complexity while enabling robust, real-time data exchange across vehicle subsystems.

At present there are several vehicle bus types and protocols used by various manufacturers. The most common automotive bus protocol options include:

1. CAN
2. LIN
3. FlexRay
4. MOST
5. DC-BUS
6. IEBUS
7. J1850
8. ISO 9141-1/-2
9. D2B – Domestic Digital Bus
10. VAN

Among all these automotive bus protocol options, CAN emerged as the dominant in-vehicle network standard, formalized as ISO 11898. Bosch originally developed the Controller Area Network (CAN), and it has since been adopted universally across the automotive industry. Higher-level protocols built on CAN — such as CANopen and DeviceNet — are widely used for industrial communications. Vehicle-class-specific profiles such as J1939 for commercial vehicles and ISO 11783 for agricultural vehicles extend the automotive CAN IVN protocol for specialized domains. Embien's Product Engineering Services cover the full spectrum of CAN bus development, from physical layer bring-up to application-layer protocol stacks.

In this blog, we describe the automotive CAN IVN protocol in detail — covering the physical bus, electrical characteristics, frame structure, and arbitration mechanism that make CAN the backbone of modern vehicle networking.

CAN bus development: Basics of the automotive CAN IVN protocol

CAN bus is an inexpensive, robust vehicle bus standard designed for multiple CAN device communications without a central host computer. CAN is a multi-master serial bus, and the devices on the network are called nodes. A minimum of two nodes is required for CAN communication. All nodes connect to one another via a two-wire bus (CAN H and CAN L) using 120-ohm nominal twisted pair cabling. Termination resistors — typically 120 ohms — are required at each end of the bus to suppress signal reflections and return the bus to its recessive (idle) state.

CAN bus development begins with understanding this physical architecture. Below is the block diagram of the CAN bus architecture:

Each node in the automotive CAN IVN protocol network requires three hardware components:

1. Transceiver – Converts data from the CAN controller into differential CAN bus voltage levels, and converts bus-level signals back into logic levels suitable for the CAN controller.
2. CAN controller – Often integrated within the microcontroller; handles framing, CRC computation, bus arbitration, and error detection.
3. Microcontroller – Determines the meaning of received messages and decides what messages to transmit.

The transceiver drives or senses dominant and recessive bits based on the differential voltage between CAN H and CAN L. The nominal dominant differential voltage is 1.5 V to 3 V; the recessive differential voltage is 0 V. The transceiver actively drives to the dominant (logic 0) voltage level, and the recessive (logic 1) state is passively restored by the termination resistors. The idle bus state is always recessive.

CAN H is driven toward supply voltage (VCC) when transmitting a dominant bit, and CAN L is driven toward 0 V. In practice, VCC and 0 V are not fully reached due to internal diode drops in the transceiver. When transmitting a recessive bit, neither line is driven, and both settle at VCC/2.

The following figure depicts the block diagram and real-time capture of CAN bus signals:

Automotive Bus Protocol Physical Layers

The automotive CAN IVN protocol supports several physical layer variants, each defining signaling characteristics, cable impedance, maximum data rates, and electrical voltage levels. Understanding these physical layers is essential for any CAN bus development project. The most commonly used variants are:

1. High Speed CAN

High Speed CAN (ISO 11898-2) uses two wires and supports data rates up to 1 Mbit/s. It is the most widely deployed automotive bus protocol variant, used in safety-critical systems including antilock brake systems (ABS), engine control modules (ECMs), and emissions management systems.

CAN FD development for Higher Bandwidth Applications

CAN FD (CAN with Flexible Data rate) is the next-generation evolution of High Speed CAN. CAN FD development addresses the bandwidth limitations of classical CAN by supporting arbitration-phase data rates above 1 Mbit/s and data-phase rates up to 8 Mbit/s or more, while also increasing the maximum payload from 8 bytes to 64 bytes per frame. CAN FD development is now mandatory for many modern automotive ECU programs, particularly in ADAS, electrification, and domain controller architectures where high-throughput in-vehicle networking is required.

3. Low Speed / Fault-Tolerant CAN

Low Speed / Fault-Tolerant CAN (ISO 11898-3) also uses two wires and supports data rates up to 125 Kbit/s with built-in fault-tolerance. This automotive bus protocol variant is used in body electronics and comfort systems — such as window regulators, mirror adjusters, and door modules — where wiring passes through door hinges and is subject to mechanical stress from repeated opening and closing.

4. Single Wire CAN

Single Wire CAN (SAE J2411) uses a single wire and supports lower data rates up to 33.3 Kbit/s. It is used in low-performance body comfort systems such as seat and mirror adjusters.

Transceivers are available for each CAN physical layer variant from semiconductor manufacturers including NXP Semiconductors, Texas Instruments, STMicroelectronics, Maxim Integrated, Infineon Technologies, and Linear Technology. Specialty transceivers include galvanically isolated variants — which provide electrical isolation between the CAN controller and the bus — and direct-interface transceivers that eliminate the need for external voltage-level buffers.

CAN bus development: Terminologies and Frame Structure

A solid understanding of CAN terminologies is foundational to any automotive CAN IVN protocol implementation. The following covers the key concepts used in CAN bus development:

1. CAN Frame and Field Descriptions

Devices in a CAN network exchange data in structured packets called frames. The figure below shows the CAN frame format:

SoF – Start of Frame bit – Indicates the beginning of a message with a dominant (logic 0) bit.

Arbitration ID – Identifies the message and indicates its priority. Standard frames use an 11-bit arbitration ID; extended frames use a 29-bit arbitration ID.

IDE – Identifier Extension bit – Differentiates between standard and extended frame formats.

RTR – Remote Transmission Request bit – Distinguishes a remote frame (logic 1 / recessive) from a data frame (logic 0 / dominant).

DLC – Data Length Code – Specifies the number of bytes in the data field.

Data Field – Contains 0 to 8 bytes of data in classical CAN, and up to 64 bytes in CAN FD.

CRC – Cyclic Redundancy Check – A 15-bit CRC field followed by a recessive delimiter bit, used for error detection across the frame.

ACK – Acknowledgement slot – Any CAN controller that correctly receives a frame asserts the ACK bit. The transmitting node checks for an ACK and retransmits if none is received.

2. Bus Arbitration

Arbitration is the process by which two or more CAN controllers resolve simultaneous transmission attempts and determine which node will use the bus. It is fundamental to the automotive CAN IVN protocol's non-destructive, priority-based access mechanism. Arbitration is performed bit-by-bit over the arbitration ID field.

3. Bit Stuffing

Bit stuffing ensures sufficient signal transitions in the NRZ (Non-Return to Zero) bit stream to maintain clock synchronization. After five consecutive identical bit levels, the transmitter automatically inserts a bit of the opposite polarity (a stuff bit). Receivers automatically remove (destuff) these inserted bits. Detection of six consecutive identical bits triggers a stuff error.

SAE J1939 Protocol Software for Commercial Vehicle Networks

SAE J1939 protocol software is a higher-layer application profile built on top of the automotive CAN IVN protocol, standardized for use in commercial vehicles including trucks, buses, and construction equipment. SAE J1939 protocol software defines parameter group numbers (PGNs) for standardized data exchange between engine, transmission, brake, and body ECUs. It also specifies network management, diagnostics, and address claiming procedures. Embien's engineers have hands-on experience developing SAE J1939 protocol software stacks and integrating them with telematics and fleet management platforms. For teams looking to accelerate development, RapidSea provides a framework for rapid embedded protocol integration across automotive and industrial applications.

How the automotive CAN IVN protocol Works: Arbitration in Detail

The automotive CAN IVN protocol is a peer-to-peer network with no centralized master controlling transmission. When any node is ready to transmit, it waits for the bus to become idle and then begins transmission. Because multiple nodes may detect bus idle simultaneously and start transmitting at the same time, CAN resolves the conflict through bit-wise arbitration:

1. Every transmitting node monitors the bus while sending its arbitration ID bits.
2. If any node transmits a recessive bit (logic 1) but detects a dominant bit (logic 0) on the bus, it has lost arbitration — it immediately stops transmitting and switches to receive mode.
3. Arbitration continues bit-by-bit through the entire arbitration ID field. At the end, only the node with the lowest arbitration ID (highest priority) remains as transmitter.
4. The winning node continues its transmission as if no collision had occurred.
5. Losing nodes act as receivers, applying hardware and software filters to determine whether the message is relevant to them.
6. Lost nodes automatically attempt retransmission when the bus next becomes idle.

This blog has covered the fundamentals of the automotive CAN IVN protocol — spanning the physical bus architecture, electrical characteristics, automotive bus protocol physical layer variants, frame structure, CAN bus development terminology, and the bit-wise arbitration mechanism. In upcoming posts, we will go deeper into the software perspective: configuring a CAN controller for operation and managing message flow in embedded CAN bus development projects.

About Embien

Embien Technologies is a leading provider of product engineering services for the Automotive, Semiconductor, Industrial, Consumer, and Healthcare segments. Embien has successfully executed many projects leveraging the automotive CAN IVN protocol — including Android-based automotive infotainment systems, GUI solutions for TFT-based instrument clusters, and vehicle tracking devices. Embien also offers a portfolio of automotive-grade solutions including the eStorm-B1 BLE module, CAN-to-BLE gateway, CAN-to-RS232/RS485 gateway, and the Sparklet GUI library, all designed to accelerate automotive bus protocol product development and reduce time-to-market for CAN bus development programs.