{"id":446,"date":"2026-09-01T09:00:00","date_gmt":"2026-09-01T09:00:00","guid":{"rendered":"https:\/\/jellai.com\/index.php\/2026\/09\/01\/can-and-can-fd-how-ecus-share-two-wires\/"},"modified":"2026-10-15T20:43:59","modified_gmt":"2026-10-15T20:43:59","slug":"can-and-can-fd-how-ecus-share-two-wires","status":"publish","type":"post","link":"https:\/\/jellai.com\/index.php\/2026\/09\/01\/can-and-can-fd-how-ecus-share-two-wires\/","title":{"rendered":"CAN and CAN FD: how ECUs share two wires"},"content":{"rendered":"

Controller Area Network, or CAN, is the bus that powertrain, chassis and body ECUs use to exchange signals such as wheel speeds, torque requests and switch states. It has no master and no addresses, yet it never lets two transmitters collide. This post shows how, bit by bit, and what CAN FD changes.<\/p>\n

Bosch began developing CAN in 1983 and presented it at the SAE congress in Detroit in February 1986. In 1987 Intel delivered the first CAN controller chip, the 82526, with Philips following shortly after with the 82C200. ISO 11898 was published in November 1993, and Mercedes-Benz has used CAN in its upper-class passenger cars since 1991.<\/p>\n

Two wires, two states<\/h2>\n

A high-speed CAN bus is a twisted pair, CAN_H and CAN_L, terminated with 120 Ω at both ends. When no node drives it, both lines sit at about 2.5 V. That is the recessive state, a logical 1. A node that sends a 0 pulls CAN_H up to about 3.5 V and CAN_L down to about 1.5 V, a differential of about 2 V. That is the dominant state. When one node sends dominant and the others recessive, the bus is dominant: a dominant bit always overwrites a recessive one. The rest of the protocol is built on that property.<\/p>\n

Identifiers instead of addresses<\/h2>\n

A CAN frame does not name a destination. Its identifier, 11 bits in the base format or 29 bits in the extended format, says what the data is, and every node decides for itself whether it needs it. The identifier also sets the frame’s priority: the lower the number, the higher the priority.<\/p>\n

Arbitration without collisions<\/h2>\n

Any node may start a frame when the bus is idle. If several start on the same bit, each sends its identifier most significant bit first and reads back what is on the bus. A node that sends a recessive 1 but reads a dominant 0 knows that a higher-priority frame is on the wire, so it stops transmitting and becomes a receiver. The node with the lowest identifier never sees a mismatch. Its frame continues without being damaged and without losing time, and the others try again once the bus is idle.<\/p>\n

\n
<\/div>
Three ECUs start a classical base frame on the same bit. Each frame is encoded bit for bit: start of frame, 11-bit identifier, control bits, two data bytes, CRC-15, and a stuff bit after every five equal bits. A dominant 0 overrides a recessive 1, so the lowest identifier wins without a collision.<\/figcaption><\/figure>\n

What a classical frame carries<\/h2>\n

After the identifier comes the RTR bit, dominant for a data frame, and the control field with the data length code. Up to 8 data bytes follow, then a 15-bit CRC. Every receiver checks the frame, and every receiver that got it intact writes a dominant bit into the ACK slot, which the sender transmits as recessive. Seven recessive bits end the frame.<\/p>\n

Two mechanisms keep the bus honest. After five equal bits the sender inserts one bit of the opposite value, so that receivers always have edges to stay synchronized to; receivers remove these stuff bits again. And a node that detects an error normally answers with an error flag of six dominant bits, which deliberately breaks the stuffing rule so that every node discards the frame. The sender then transmits it again.<\/p>\n

CAN FD: more data, faster<\/h2>\n

Classical CAN carries at most 8 data bytes per frame and runs at up to 1 Mbit\/s. Bosch started work on CAN with flexible data rate, CAN FD, in 2011, and it was officially introduced at the 13th international CAN Conference in 2012. A CAN FD frame carries up to 64 data bytes and can switch to a second, faster bit rate for its data phase. The arbitration phase keeps the slower rate: there the bit rate depends on the network topology and is limited to 1 Mbit\/s, while the data-phase rate is limited by the transceivers.<\/p>\n

A few control bits make this work. A recessive FDF bit marks the frame as CAN FD, and a recessive BRS bit switches to the data-phase bit rate. The ESI bit tells receivers whether the sender is error active. The RRS bit, in the place where classical CAN has RTR, is always dominant, because CAN FD has no remote frames. Data length codes 9 to 15 stand for 12, 16, 20, 24, 32, 48 and 64 bytes. The longer payload gets a stronger checksum: a 17-bit CRC for up to 16 data bytes and a 21-bit CRC above that, with a stuff count in front of it and fixed stuff bits inside the CRC field.<\/p>\n

The gain is easy to put in numbers. Not counting stuff bits, a classical frame with 8 data bytes is 108 bits long, 216 µs at 500 kbit\/s. A CAN FD frame with 64 data bytes is 576 bits long including its fixed stuff bits, but 549 of them are sent in the data phase. At 500 kbit\/s with a 2 Mbit\/s data phase, the whole frame takes about 330 µs, for eight times the payload.<\/p>\n

\n
<\/div>
Classical CAN with 8 data bytes at 500 kbit\/s against CAN FD with 64 data bytes, which switches to 2 Mbit\/s after the BRS bit and back at the CRC delimiter. Field lengths and bit rates are to scale, without dynamic stuff bits; the bit values are illustrative. The magnifier follows the data-phase bits.<\/figcaption><\/figure>\n

The standard has kept growing. ISO 11898-1:2024 covers Classical CAN, CAN FD and CAN XL, a third generation with data fields of up to 2048 bytes.<\/p>\n

CAN on a test rig<\/h2>\n

On a hardware-in-the-loop rig, the ECU under test sits on a real CAN bus, and the simulator has to stand in for every node that is not on the bench. It sends their frames at the right cycle times with plausible contents, reacts to the ECU’s frames, and keeps counters and checksums consistent wherever the ECU checks them. This is restbus simulation. The bus description comes from the vehicle’s network database, typically a DBC file or AUTOSAR ARXML, so the rig follows the real network rather than a hand-written copy of it.<\/p>\n

We build restbus simulation into real-time systems alongside the vehicle models, together with fault injection: frames that arrive late or not at all, wrong counters or checksums, and signals out of range, so you can see how the ECU copes. If you are bringing up a CAN or CAN FD rig, get in touch<\/a>.<\/p>\n

Sources<\/h2>\n