1 — The Bus and Why It Won
CAN is a multi-master, message-oriented serial bus designed by Bosch in 1986 and standardized as ISO 11898. There are no node addresses. A frame carries an identifier that names the message, not a destination, and every node hears every frame and decides in hardware whether to keep it. That single design choice — broadcast plus content filtering — is why one pair of wires can wire up an entire vehicle.
It won because it is cheap, differential, and deterministic. Two wires survive an electrically violent engine bay. Priority is built into the identifier, so the most urgent message always wins the bus without a scheduler. Nearly forty years later it is still the nervous system of almost every car and a vast amount of industrial, agricultural, and marine equipment.
2 — Physical Layer
- Differential pair — CAN_H and CAN_L. A transceiver drives the dominant state (logical 0) by pulling the two lines roughly 2V apart, and the recessive state (logical 1) by letting them relax to the same ~2.5V. Reading the difference rejects common-mode noise picked up equally on both wires.
- Termination — 120Ω at each physical end of the bus, matching the twisted pair's characteristic impedance. Missing or extra terminators cause reflections and bit errors. A bench bus needs exactly two 120Ω resistors, no more.
- Topology and rate — a linear bus with short stubs. High-speed CAN (ISO 11898-2) runs to 1 Mbps; low-speed fault-tolerant CAN (ISO 11898-3) trades speed for surviving a shorted or broken wire, used for slow body electronics.
- Bit timing — each bit is divided into time quanta grouped into sync, propagation, and two phase segments. The sample point (typically 75–87.5% into the bit) is where every node reads the level, and nodes resynchronize their clocks on each recessive-to-dominant edge. Get this wrong and the bus works at short range but fails as you add cable.
3 — Frame Format and Arbitration
A classic data frame is a fixed sequence of fields. The arbitration field carries the identifier and decides priority. Everything after it is payload and integrity.
Arbitration is the elegant part. Because the bus is a wired-AND (dominant always overrides recessive), nodes can transmit at the same time and sort out priority bit by bit without anyone colliding destructively.
-
Simultaneous startSeveral nodes see the bus idle and begin transmitting on the same Start-of-Frame bit. No coordination, no token.
-
Identifier, MSB firstEach node drives its identifier one bit at a time and simultaneously samples what is actually on the bus.
-
Dominant winsA node that drives recessive but reads dominant has just been overruled by a higher-priority frame. It stops transmitting instantly and switches to listening. Its frame is not corrupted; it simply lost.
-
Winner never noticesThe highest-priority node finishes its frame unaware there was contention. The loser re-arbitrates at the next idle. No retransmission penalty, no backoff timer, fully deterministic.
Two more mechanisms keep the bus honest. Bit stuffing inserts an opposite-polarity bit after five identical bits so receivers can keep their clocks locked. Fault confinement counts transmit and receive errors at each node, demoting a misbehaving node from error-active to error-passive and finally to bus-off, where it removes itself from the bus entirely.
4 — CAN FD and CAN XL
Classic CAN's 8-byte payload and 1 Mbps ceiling became the bottleneck as ECUs multiplied. The two successors keep the arbitration model and extend the data phase.
| Variant | Max payload | Max data rate | Standard | Notes |
|---|---|---|---|---|
| Classic CAN | 8 bytes | 1 Mbps | ISO 11898-1 | The 1986 original. Universal, slow, tiny frames. |
| CAN FD | 64 bytes | ~8 Mbps (data) | ISO 11898-1:2015 | Arbitrate slow for compatibility, then switch rate (BRS) for the payload. |
| CAN XL | 2048 bytes | ~10–20 Mbps | CiA 610 / ISO 11898-1 | SDU type field tunnels Ethernet and higher protocols. Needs SIC XL transceivers. |
CAN FD is the workhorse upgrade: the slow arbitration phase stays bit-compatible with classic CAN so mixed buses work, then the bit-rate switch accelerates only the data and CRC fields. Bigger payloads also cut per-byte overhead, which matters when flashing firmware. CAN XL goes further, carrying up to 2048 bytes and an SDU type that lets a CAN frame transport an Ethernet frame, positioning CAN as the edge bus under a zonal Ethernet backbone (section 9).
5 — Higher-Layer Protocols
CAN itself is only layers 1 and 2: wires and frames. Anything meaningful — diagnostics, firmware, sensor meaning — is a higher-layer protocol riding on top of the same frames.
| Protocol | Layer / role | Domain | Key idea |
|---|---|---|---|
| ISO-TP | Transport (ISO 15765-2) | Diagnostics transport | Segments up to 4095 bytes across many frames with flow control. |
| UDS | Diagnostics (ISO 14229) | Every modern ECU | Read data, run routines, flash firmware, seed/key security. |
| OBD-II | Emissions (ISO 15031 / J1979) | Legally mandated port | Standardized PIDs any scan tool can read. |
| J1939 | Application (SAE) | Trucks, buses, ag, marine | 29-bit PGN/SPN at 250–500 kbps; self-describing parameters. |
| CANopen | Application (CiA 301) | Industrial / robotics | Object dictionary with PDO (real-time) and SDO (config) messaging. |
6 — ISO-TP and UDS
A single CAN frame holds at most 8 bytes (64 in FD). To move a 17-byte VIN or a megabyte of firmware, ISO-TP segments the message and the receiver paces it with flow control. The first byte of each frame is a Protocol Control Information byte whose high nibble names the frame type.
- Single Frame (0) — the whole message fits in one frame; the low nibble is the length.
- First Frame (1) — opens a multi-frame transfer and declares the total length (up to 4095).
- Consecutive Frame (2) — carries 7 payload bytes each, tagged with a rolling 4-bit sequence number.
- Flow Control (3) — sent by the receiver: clear-to-send / wait / overflow, plus block size and STmin (the minimum gap it can tolerate between frames).
On top of ISO-TP sits UDS. A request is a one-byte service ID plus parameters; a success reply echoes the service ID plus 0x40. A failure returns 0x7F, the service, and a negative response code. The same handful of services covers reading sensors, clearing trouble codes, unlocking protected functions, and reflashing the ECU.
Key services worth memorizing: 0x10 DiagnosticSessionControl, 0x22 ReadDataByIdentifier, 0x2E WriteDataByIdentifier, 0x27 SecurityAccess, 0x31 RoutineControl, 0x34/0x36/0x37 the RequestDownload / TransferData / TransferExit firmware-flashing trio, 0x19 ReadDTCInformation, and 0x3E TesterPresent (the keep-alive that stops a session timing out).
7 — socketcan and Hands-On
On Linux, CAN is just another network interface. socketcan presents can0 like a NIC, so the same mental model as Ethernet applies: bring the link up, then capture and inject. A virtual vcan0 interface lets you build and test an entire pipeline with no hardware at all.
The raw bus is hex. A DBC database maps arbitration IDs and bit ranges to named signals with scale and offset, turning 0x0C8 1A F0 into EngineRPM = 832.5. python-can reads the bus and cantools applies the DBC.
- USB adapters — a CANable or other slcan dongle is roughly $25 and shows up as
can0. PEAK PCAN-USB is the pricier professional option with rock-solid drivers. - Raspberry Pi + MCP2515 — an SPI CAN controller HAT turns a Pi into a logger or gateway for under $15 in parts. The mainline kernel driver exposes it as socketcan directly.
- Where to tap — the OBD-II port exposes at least one CAN bus on pins 6 and 14. Beyond that, vehicles split into many isolated buses behind a gateway, so a single port rarely sees everything.
8 — Reverse Engineering and Security
The uncomfortable truth: classic CAN has no authentication and no encryption. Any node can transmit any identifier, and every node believes it. Physical access to a bus, often through the OBD-II port, is close to full control. Security was simply not a 1986 design goal.
- Sniff and identify — run
cansniffer, actuate one control (a turn signal, a window), and watch which ID and bytes change. Repeat to hand-build a DBC. This is most of practical CAN reverse engineering. - Replay and spoof — capture a frame and re-send it; the receiving ECU cannot tell the difference. Nearly every CAN attack reduces to this, because nothing on the bus proves who sent a frame.
- Bus-off attack — an adversary node deliberately induces bit errors during a victim's transmission, driving the victim's error counter to bus-off so it silently drops off the network. A denial-of-service that needs no spoofing, only timing.
- Voltage fingerprinting IDS — defenders profile each ECU's analog voltage signature, which depends on transceiver hardware and is hard to mimic, then flag frames whose claimed ID does not match the measured transmitter. Effective, but it needs extra taps on CAN_H/CAN_L and is itself attackable by voltage corruption.
- SecOC — AUTOSAR Secure Onboard Communication appends a truncated MAC and a freshness value (a counter or timestamp) to critical frames, giving authentication and replay protection where bus bandwidth allows. The cryptographic answer to a bus that never had one.
9 — Where CAN Connects
CAN is not being replaced so much as demoted to the edge. Modern vehicles are moving to a zonal architecture: a few location-based controllers gather their local CAN, CAN FD, and LIN buses and aggregate them onto an automotive Ethernet backbone.
- Automotive Ethernet — single-pair 100BASE-T1 and 1000BASE-T1 for the backbone, 10BASE-T1S multidrop for cheaper segments, with TSN adding the bounded latency that classic Ethernet lacks. This is the same determinism story as the avionics fabrics in the real-time inference reference.
- Zonal gateways — instead of one bus per function snaking across the car, zone controllers translate between local CAN and the Ethernet core, cutting wiring mass and giving a natural place to enforce security policy.
- The crossover — a car's CAN edge is the consumer-accessible analog of the F-35's IEEE 1394b vehicle bus feeding the Integrated Core Processor: a deterministic, low-bandwidth bus carrying actuators and slow sensors under a high-bandwidth fused backbone. Same shape, very different budget. See the companion document, Real-Time Sensor Fusion and Inference Architectures.
References
| [ISO 11898-1] | ISO 11898-1:2015 — Road vehicles, Controller Area Network, Part 1: Data link layer and physical signalling (Classic and FD) |
| [ISO 11898-2] | ISO 11898-2:2016 — High-speed medium access unit (physical layer) |
| [CiA 610] | CAN in Automation — CiA 610 series, CAN XL specification and test plans. can-cia.org |
| [ISO 15765-2] | ISO 15765-2 — Diagnostic communication over CAN (ISO-TP): segmentation, flow control, reassembly |
| [ISO 14229] | ISO 14229-1 — Unified Diagnostic Services (UDS) specification and requirements |
| [SAE J1939] | SAE J1939 — Serial control and communications heavy-duty vehicle network |
| [SocketCAN] | Linux kernel SocketCAN documentation. kernel.org |
| [python-can] | python-can and cantools. python-can.readthedocs.io |
| [Bus-off] | Silently Disabling ECUs and Enabling Blind Attacks on the CAN Bus — arXiv:2201.06362 |
| [SecOC] | AUTOSAR — Specification of Secure Onboard Communication (SecOC) |