Why CAN needed a second generation
Classical CAN was designed in the 1980s for a handful of ECUs exchanging short control values. Two of its limits became binding as vehicles grew more complex. The first is payload: with eight data bytes per frame, anything larger, from a software download to a diagnostic response, must be split into many frames that each pay 44 to 64 bits of protocol overhead. The second is speed: classical CAN cannot exceed 1 Mbit/s, and real vehicle networks rarely run above 500 kbit/s, because during arbitration every bit must make a round trip across the bus before it is sampled.
New demands made those limits painful. Driver-assistance functions exchange larger data sets; security requirements such as UN Regulation No. 155 have pushed manufacturers towards authenticated in-vehicle messages, whose authentication codes need room in every frame; and reprogramming dozens of ECUs in the workshop takes far longer over eight-byte frames. Bosch published CAN FD (flexible data rate) in 2012, and ISO standardised it in ISO 11898-1:2015.
What stays the same
CAN FD is an evolution, not a new network. All of the following carries over unchanged:
- The medium: the same twisted pair, the same 120 Ω termination and the same recessive and dominant voltage levels described in CAN physical layer.
- Arbitration: identifiers are still 11 or 29 bits, still resolved bit by bit, still non-destructive, and always at the nominal bit rate.
- Acknowledgement, error signalling and fault confinement: the same error types, error flags, counters and bus-off rules as in CAN frames and arbitration.
- Higher layers: ISO 15765-2 transport, UDS and J1939 run over CAN FD with adaptations for larger frames rather than redesigns.
The CAN FD frame, bit by bit
The visible differences sit in the control field, where classical CAN had reserved bits to spare:
FDF: announcing the new format
The FD format bit sits where classical CAN has its reserved bit r0, but it is sent recessive. A CAN FD controller reads it and switches to the FD frame layout. A classical controller accepts either level in that reserved position, keeps reading the following bits as a DLC and data, and inevitably runs into an error further on, most often because the data phase is faster than it can follow. It then transmits an error flag that destroys the FD frame for every node. That single fact is the root of every coexistence question covered below.
BRS: switching the bit rate
If BRS is recessive, every node switches from the nominal to the data bit rate at the sample point of the BRS bit and back again at the sample point of the CRC delimiter. Everything in between, the ESI bit, DLC, data and CRC field, travels at the faster rate. This data phase needs no round trip across the bus, because only one node is transmitting and the others are listening, so its speed is limited by signal quality rather than by bus length. Frames sent with BRS dominant run entirely at the nominal rate and still benefit from the larger payload.
Approximate figures for an 11-bit identifier, without stuff bits.
ESI: error state in every frame
The error state indicator lets every receiver see whether the transmitter is error active (ESI dominant) or error passive (ESI recessive). In classical CAN that information never left the node. Gateways and network monitoring can use it to spot a degrading node long before it reaches bus-off.
Payload sizes and the DLC
CAN FD keeps the four-bit DLC but uses the codes that classical CAN treated as 8 bytes to reach longer payloads in coarser steps:
In classic CAN, codes 9 to 15 still carry 8 bytes. CAN FD uses them for 12 to 64 bytes.
A payload that falls between two sizes is padded up to the next one: 30 bytes travel in a 32-byte frame with two padding bytes, and 50 bytes in a 64-byte frame with 14. Communication designers therefore lay out their messages around the available sizes, and the padding value is defined in the network specification.
Higher layers adapted accordingly. ISO 15765-2 carries up to 62 bytes of diagnostic data in a single unsegmented CAN FD frame, where classical CAN fits 7, and SAE J1939-22 packs several parameter groups into one FD frame.
Stronger error detection
A longer frame needs a stronger checksum. CAN FD selects its CRC by payload size and changes how stuffing and the CRC interact:
CRC-17: x¹⁷ + x¹⁶ + x¹⁴ + x¹³ + x¹¹ + x⁶ + x⁴ + x³ + x + 1 · CRC-21: x²¹ + x²⁰ + x¹³ + x¹¹ + x⁷ + x⁴ + x³ + 1The stuff bit count closes a known weakness of classical CAN, in which two bit errors that create or remove stuff bits can shift the frame in a way the CRC may not catch. The fixed stuff bits make the length of the CRC field independent of its content.
Data-phase bit rates: 2, 5 and 8 Mbit/s
With arbitration out of the way, the data phase is limited by how cleanly a bit survives the trip between transceivers: ringing from stubs and star points, asymmetry between rising and falling edges, and the transceivers' own delays. Typical combinations:
Two techniques make the higher rates practical. Transmitter delay compensation (TDC): at 5 Mbit/s a data bit lasts 200 ns, comparable to the delay from the controller's TXD pin through the transceiver and back to RXD. The transmitter would read back each of its own bits too late to check it, so it measures this loop delay at the start of the data phase and checks each bit at a secondary sample point shifted by that amount. CAN in Automation's CiA 601-3 recommends enabling TDC for data rates above 1 Mbit/s.
Signal improvement capability (SIC): SIC transceivers actively damp the ringing after a dominant-to-recessive transition by briefly presenting a matched impedance to the bus. That suppresses reflections in topologies with stars or long stubs which would otherwise limit the data phase to lower rates. SIC was first specified by CAN in Automation and is now part of ISO 11898-2:2024.
Bit-timing discipline also matters more than in classical CAN. CiA 601-3 recommends CAN clocks of 20, 40 or 80 MHz, the same time-quantum length in both phases, identical sample points in all nodes and, for automotive networks, a nominal sample point no later than 80 %.
Worked example: moving 64 bytes
How much faster is CAN FD in practice? Take 64 bytes of payload on a network with a 500 kbit/s nominal rate and count the bits, ignoring dynamic stuff bits, which add a few percent in every case:
- 01Classical CAN
Eight base-format frames of 8 bytes, each 111 bit times including intermission: 888 bits at 2 µs = 1,776 µs.
- 02CAN FD without bit-rate switch
One frame: about 30 bits for arbitration, acknowledgement, end of frame and intermission, plus 549 bits from ESI to the end of the CRC field (ESI 1, DLC 4, data 512, stuff count 4, CRC 21, fixed stuff bits 7). 579 bits at 2 µs = 1,158 µs.
- 03CAN FD with a 2 Mbit/s data phase
The 30 nominal bits take 60 µs; the 549 data-phase bits at 0.5 µs take 274.5 µs. Total ≈ 335 µs.
- 04CAN FD with a 5 Mbit/s data phase
60 µs + 549 × 0.2 µs ≈ 170 µs.
The larger payload alone brings a modest gain; the step change comes from the data phase. The numbers matter for latency too: a full 64-byte FD frame with a 2 Mbit/s data phase occupies the bus for about 335 µs, only slightly longer than one worst-case 8-byte classical frame at 500 kbit/s (270 µs). Larger frames do not have to mean longer blocking times for urgent traffic.
Mixing classical and FD nodes
Because a classical controller cannot follow an FD frame and destroys it with an error flag, a network that carries FD frames must not contain active classical CAN controllers. Manufacturers resolve this in four ways:
- All-FD segments: every node uses an FD-capable controller, including nodes that only ever send classical frames. FD controllers handle classical frames natively.
- Gateway separation: classical and FD networks stay on separate segments, joined by a gateway ECU that routes and repacks data between them; see Vehicle network architecture.
- FD-passive transceivers: some partial-networking transceivers ignore FD frames while their ECU sleeps, so the sleeping node neither wakes up nor signals errors.
- Staged migration: an FD-capable network carries only classical frames until every node supports FD, then switches.
- 01Controller
Confirm an ISO CAN FD controller (ISO 11898-1:2015 or later), not a classical or non-ISO FD one.
- 02Transceiver
Use a transceiver specified for the data rate in use under ISO 11898-2:2016 or later, with timing-symmetry parameters for that rate.
- 03Bit timing
Match the network's nominal and data bit rates, sample points and time-quantum settings exactly, and enable transmitter delay compensation above 1 Mbit/s.
- 04Topology
Keep the stub to the new device as short as possible. A stub that was harmless at 500 kbit/s can ring straight through a 500 ns data bit.
- 05Behaviour
Make sure the device stays silent while the network sleeps and never transmits anything outside the network design.
Beyond FD: CAN XL
The third generation, CAN XL, is specified in ISO 11898-1:2024 alongside classical CAN and CAN FD, with its transceivers in ISO 11898-2:2024. It keeps CAN's arbitration and adds a data phase sized for Ethernet-class payloads:
The SDU type field lets CAN XL carry other protocols' frames, Ethernet frames included, which positions it as a bridge between CAN-based zones and Ethernet backbones in zonal architectures; see Vehicle network architecture. The virtual network ID allows up to 256 logical networks on one physical segment, and CANsec, the security protocol from CAN in Automation, can protect data at the link layer.
ISO 11898-1:2024 also standardises CAN FD Light, a commander/responder variant for simple sensors and actuators that need CAN FD frames but not multi-master arbitration. For vehicles already on the road, classical CAN and CAN FD will remain the reality for many years; CAN XL is an architecture decision for new platforms.
What this means in the field
- Know the network generation before connecting anything. A classical-only device on a CAN FD network is not merely unable to read the new frames; if it acknowledges or signals errors, it actively destroys them.
- Look at the whole frame on the scope. An FD frame with BRS set shows a visible change in bit width after the arbitration field: bits four times narrower at 500 kbit/s and 2 Mbit/s.
- Respect the shorter data bit. Ringing that settles in 300 ns is harmless in a 2 µs nominal bit and fatal in a 200 ns data bit. Stub length and splice quality matter more on FD networks than on any classical CAN bus.
- Expect mixed vehicles. One car can carry classical CAN on body networks, CAN FD on powertrain and driver-assistance networks, and Automotive Ethernet in the backbone.
Frequently asked questions
Can a CAN FD node talk to a classical CAN node?
Yes, using classical frames: every CAN FD controller also sends and receives classical frames. The reverse is not true. A classical controller cannot receive FD frames and will disturb them.
Does CAN FD need different wiring?
No new cable type: the same twisted pair and 120 Ω termination. What changes is the tolerance for poor topology. Long stubs, star points and untwisted sections that classical CAN forgave can limit the usable data rate.
Is the OBD-II port CAN FD?
Legislated emissions diagnostics under ISO 15765-4 run on classical CAN at 250 or 500 kbit/s. Some manufacturers' own diagnostic communication on newer vehicles uses CAN FD behind the same OBD-II connector. See OBD-II and secure gateways.
What happened to the EDL bit?
EDL (extended data length) was the bit's name in the original Bosch CAN FD documents. ISO 11898-1:2015 renamed it FDF (FD format). It is the same bit.
Will CAN XL replace CAN FD?
Not on existing platforms. CAN XL targets new architectures that need payloads and bit rates between CAN FD and Automotive Ethernet. CAN FD remains the mainstream choice for control networks.
