Inside CAN FD: Architecture, Performance Gains, and Integration Challenges

This report was created by Copperhill Technologies, a leading provider of embedded systems solutions specializing in Controller Area Network (CAN) technologies, including both Classical CAN and CAN FD. With extensive experience in automotive, industrial, and off-highway applications, Copperhill Technologies delivers a wide range of development tools, gateways, and custom hardware that support robust and high-performance CAN-based communication systems.

Download the Full Report (PDF):
Inside CAN FD: Architecture, Performance Gains, and Integration Challenges

Introduction and Historical Background

Controller Area Network (CAN) is a fieldbus communication protocol originally developed by Bosch in the 1980s for in-vehicle networking. Classical CAN (CAN 2.0, standardized in 1991) proved highly reliable for transmitting short messages (up to 8 data bytes) at speeds up to 1 Mbps. However, as automotive and industrial systems grew more complex, the limitations of Classical CAN became apparent. By the 2000s, vehicles contained dozens of Electronic Control Units (ECUs) generating more data than a 1 Mbps bus with 8-byte frames could efficiently handle. Engineers sought a higher bandwidth solution that maintained CAN’s robustness and real-time capabilities.

Motivation for CAN FD: The main limitations of Classical CAN were the payload size and bit rate. An 8-byte data field often meant fragmenting larger datasets into multiple frames, adding latency and overhead. Similarly, the 1 Mbps speed cap became a bottleneck for applications like high-resolution sensors and advanced diagnostics. Initial ideas to improve CAN appeared as early as 1999, proposing to “overclock” parts of the CAN frame and increase payload length. Building on these ideas, Bosch began developing an enhanced CAN protocol in 2011 in close cooperation with automakers and other CAN experts. The goal was to overcome CAN’s limits by allowing higher transmission rates and larger frame sizes while preserving compatibility with existing CAN networks. The result of this effort was CAN FD (CAN with Flexible Data-Rate).

Timeline Milestones:

• 1980s: Bosch develops the original CAN protocol (11-bit identifier, 8-byte data) for automotive use. CAN 2.0 (with standard and extended frame formats) is later published in 1991.
• 1999: Concepts for a faster CAN bus with larger payloads are proposed in research, anticipating future needs.
• 2011: Bosch initiates the CAN FD development project, collaborating with car manufacturers and CAN specialists to increase CAN’s bandwidth.
• 2012: The first CAN FD specification (Version 1.0) is released by Bosch. It demonstrated up to 5 times higher data transfer rate and much larger message sizes than Classical CAN.
• 2015: CAN FD is standardized internationally as ISO 11898-1:2015, which introduced some protocol refinements for reliability. (Notably, the ISO version added safeguards like improved CRC; these changes made the ISO standard slightly incompatible with Bosch’s 1.0 spec, see Section 5.)
• Late 2010s: Semiconductor companies (e.g., NXP, Infineon, TI, STMicroelectronics) and automakers (e.g., GM, Daimler) widely embrace CAN FD. CAN FD capability begins appearing in high-performance ECUs, with industry consortia defining higher-layer protocols (e.g. CANopen FD, J1939 FD) to leverage the new features. By 2019–2020, CAN FD was predicted to be used in most new vehicles, a prediction largely realized as CAN FD became mainstream in automotive networks by the early 2020s.

In summary, CAN FD was created to address the bandwidth and data size shortcomings of Classical CAN. It retains CAN’s proven fundamentals (such as the arbitration mechanism and error handling), while dramatically boosting throughput. The next sections detail the technical improvements CAN FD brings and how they compare to Classical CAN.

Technical Features of CAN FD

CAN FD introduces several key technical enhancements to the CAN protocol. These include a higher data payload per frame, the ability to switch to a faster bit rate during data transmission, adjustments to bit stuffing and error-checking mechanisms, and changes in the frame structure and fields. Together, these features enable CAN FD to carry more data at higher speeds with improved efficiency, all while maintaining reliability. Figure 1 and Figure 2 below illustrate the frame format differences between Classical CAN and CAN FD. We will then discuss each feature in detail.

Figure 1: Classical CAN data frame format (Base frame, 11-bit ID). It consists of an arbitration field (identifier and control bits), a data field up to 8 bytes, a 15-bit CRC for error checking, an ACK field, and end-of-frame bits. Bit stuffing is applied after 5 identical bits to ensure clock synchronization.

Figure 2: CAN FD data frame format (Base frame format with 11-bit ID). It extends the control field (including new bits r1, IDE, EDL/FDF, BRS, ESI), allows a data field up to 64 bytes, and uses a longer CRC sequence (17 or 21 bits) with additional bits for error detection. The arbitration field and ACK/end-of-frame segments remain similar to Classical CAN.

Increased Payload Capacity (Up to 64 Bytes)

One of the most significant upgrades in CAN FD is the expanded data payload. A Classical CAN frame can carry at most 8 bytes of application data, whereas a CAN FD frame can carry up to 64 bytes of data. This eight-fold increase in payload capacity greatly improves bus efficiency for data-intensive applications. Larger messages that previously needed to be split into multiple CAN frames can now often be sent in a single frame. For example, sending 32 bytes of data would have required four separate classical CAN frames (4 × 8 B), each incurring protocol overhead and arbitration delays; with CAN FD, those 32 bytes can ride in one frame with a single arbitration cycle and header. The protocol introduces a redefined Data Length Code (DLC) to support these new lengths. DLC values 0–8 still represent 0–8 bytes as before, while values 9–15 are re-purposed to encode higher payload sizes (up to 64). In practice, common DLC mappings are 9→12 bytes, 10→16 bytes, 11→20 bytes, 12→24 bytes, 13→32 bytes, 14→48 bytes, and 15→64 bytes. Software and hardware interfacing with CAN FD had to accommodate this new DLC scheme. Microcontrollers require larger CAN buffers/FIFO and updated driver software to handle frames with extended length. Despite these changes, CAN FD frames remain backward-compatible in format – a CAN FD controller can transmit and receive standard 8-byte CAN frames as well (interoperability is discussed in Section 5).

Overall, the extended payload reduces protocol overhead per byte of data and increases bandwidth utilization. In combination with CAN FD’s higher bit rates (next topic), this leads to a much higher effective data throughput on the bus.

The PiCAN FD board adds advanced CAN Bus FD (Flexible Data-Rate) capabilities to the Raspberry Pi 3, making it ideal for industrial, automotive, and embedded networking applications.

It is based on the Microchip MCP2517FD, a stand-alone CAN FD controller, combined with the MCP2562FD high-speed CAN transceiver. This hardware solution ensures full compliance with the latest ISO 11898-1:2015 standard.

More information...

Flexible Data-Rate and Faster Bit Rates

The “FD” in CAN FD stands for Flexible Data-Rate. Unlike Classical CAN which operates at a single bit rate for the entire frame (up to 1 Mbit/s on a high-speed CAN bus), CAN FD allows two different bit rates within each frame:

• Arbitration Phase: This is the start of frame through the arbitration field (identifier and control) up to the point just before the data field. In CAN FD, the arbitration phase is kept at a bit rate up to 1 Mbit/s, identical to Classical CAN. Keeping arbitration at classical speeds ensures that CAN FD nodes can coexist with legacy CAN nodes during bus arbitration without timing issues. All nodes sample the identifier and arbitration bits at the same slower rate so that the priority-based bus access (CSMA/CR) works reliably and is fair for all.
• Data Phase: Once arbitration is won and the data field begins, a CAN FD frame may switch to a higher bit rate for the remainder of the frame (data field, CRC, and ACK sequence). This faster rate is configurable (often 2, 5, or even up to 8 Mbit/s depending on transceiver capabilities) and allows the lengthy data payload to be transmitted much quicker. After the data and CRC are sent at the higher speed, the transmitter switches back to the nominal (lower) bit rate for the ACK slot and end-of-frame, so that all nodes (including any slower ones) can properly process the frame completion.

This dual-bit-rate scheme is controlled by a special bit in the CAN FD frame’s control field called BRS (Bit Rate Switch). If the sender sets the BRS bit to recessive (1), it indicates that the bit rate will change to the pre-configured faster value right after the arbitration phase. If BRS is dominant (0), the frame stays at the arbitration bit rate throughout (allowing CAN FD to also be used at a uniform rate for consistency or testing if needed).

In practical terms, the data phase bit rate provides a huge boost in throughput. For example, if a CAN FD network runs at 500 kbps during arbitration and 4 Mbps during data phase (a common 1:8 ratio), the throughput increases roughly six-fold compared to classical CAN. Even with the protocol’s slightly increased overhead (additional control bits and longer CRC), the ability to send 64-byte payloads at 8× speed yields a major bandwidth improvement. In fact, data payload transfer rates of 5–8 Mbit/s are achievable in CAN FD, versus 1 Mbit/s max in Classical CAN. It should be noted that the actual achievable data rate on a real CAN FD bus depends on the network length and transceiver hardware – higher bit rates shorten the maximum bus length due to signal propagation and ringing. Therefore, system designers must balance bit rate and network size, and often a 2–5 Mbit/s data phase is chosen for robust operation in automotive environments. Still, flexible data-rate empowers designers to significantly speed up critical data transfers (such as high-frequency sensor readings or large data blocks) without sacrificing CAN’s multi-master arbitration in the lower-speed phase.

Frame Structure Changes and New Control Bits

To accommodate the above capabilities, the CAN FD frame format includes some changes in the control field and overall frame structure, while retaining most field definitions of Classical CAN:

• FD Frame Identifier (FDF) Bit: One of the reserved bits in the Classical CAN control field is reassigned as the FD Format (FDF) indicator. In CAN FD frames, this bit is sent recessive (1) to signify that the frame is in CAN FD format. If a node sees a recessive FDF bit where a Classical CAN frame would have had a dominant reserved bit, it knows to interpret the rest of the frame as CAN FD (with potential bit rate switching and larger DLC). Classical CAN controllers, on the other hand, will not recognize this pattern – they consider a recessive value in that position as a form error (see Section 5 on compatibility). In Classical frames, that bit remains dominant (0), identifying the frame as a traditional CAN 2.0 message.
• BRS (Bit Rate Switch) Bit: As mentioned, this new control bit is used to signal a speed change. BRS is part of the CAN FD control field and is only relevant if the frame is FD format (when FDF = recessive). If BRS = 1 (recessive), the transmitter and CAN transceivers switch to the pre-defined higher data-phase bitrate after the arbitration field. If BRS = 0, the frame stays at the base rate. Nodes that support CAN FD will adjust their timing accordingly when they detect the recessive BRS. The switching is timed such that it occurs exactly at the boundary between arbitration and data field, maintaining synchronization.
• ESI (Error State Indicator) Bit: CAN FD adds an ESI bit in the frame to indicate the error status of the transmitting node. In Classical CAN, a node’s error state (error active or error passive) was only implicitly indicated by error frames. In CAN FD, the transmitter sets ESI = dominant (0) if it is in error active state, or recessive (1) if in error passive state. This can be useful for network diagnostics, as other nodes can tell if the transmitter has experienced a lot of errors (entering error passive) without waiting for an actual error frame. The ESI bit is located in the extended control field of the CAN FD frame and is transmitted at the arbitration rate.
• No Remote Frames: CAN FD does not support Remote Transmission Request (RTR) frames. In Classical CAN, an RTR bit in a frame could request data from a remote node (causing that node to send back a data frame). In CAN FD, this concept was removed – all CAN FD frames are data frames (the RTR field is replaced or kept dominant as a placeholder). Practically, remote frames were seldom used in modern CAN applications, and removing support simplified the protocol. The RRS (Remote Request Substitute) bit in extended frames and a reserved bit in base frames ensure the fixed recessive/dominant value to indicate “not a remote frame” in CAN FD.
• Extended Frame Format: CAN FD supports both 11-bit standard identifiers and 29-bit extended identifiers, just like Classical CAN. It uses the existing IDE (Identifier Extension) bit to distinguish between these (IDE = 0 for 11-bit ID, IDE = 1 for 29-bit ID). For CAN FD, an 11-bit ID frame is sometimes called FBFF (FD Base Frame Format) and a 29-bit ID frame FEFF (FD Extended Frame Format). Aside from the larger DLC and new bits above, extended CAN FD frames function analogously to extended Classical CAN frames.

In summary, the frame layout of CAN FD closely mirrors Classical CAN for the arbitration and ACK segments, but the control field is extended with new bits (FDF, BRS, ESI) to signal FD features. Figures 1 and 2 showed how these bits fit into the frame. These changes are designed such that CAN FD-capable controllers can handle both old and new frame types, ensuring a degree of continuity with existing CAN infrastructure (see Section 5 for how mixing works in practice).

This high-performance embedded system is built around the Teensy 4.1 microcontroller board and offers triple CAN connectivity (two CAN 2.0B and one CAN FD) as well as Ethernet support via onboard MagJack. Designed for advanced real-time applications in automotive, industrial, and IoT environments, it comes pre-integrated with a 240x240 wide-angle IPS TFT LCD for visual interface or diagnostics display.

Power is supplied through an external +12 VDC input, and the system includes robust reverse voltage protection and an onboard voltage regulator, ensuring reliable operation in demanding environments.

More information...

Improved Bit Stuffing and Protocol Efficiency

CAN uses non-return-to-zero (NRZ) coding on the bus, which requires bit stuffing to ensure sufficient signal edges for clock recovery. In Classical CAN, the rule is that after five consecutive bits of the same polarity (five 0s or five 1s), a stuff bit of the opposite polarity is inserted automatically into the bit stream. The receivers also apply this rule to remove stuff bits and stay synchronized. Bit stuffing guarantees the transmitter cannot send a long string of identical bits without a clock edge, but it does add overhead (the number of stuff bits depends on the data pattern).

With CAN FD’s longer frames and higher speeds, the impact of stuff bits becomes more significant. To improve efficiency and reliability, CAN FD introduced a couple of changes:

• Fixed Stuff Bits in CRC Field: In the CAN FD CRC field, a scheme of fixed stuff bits is used instead of the standard “five identical bits” rule. The CRC sequence (which is longer in CAN FD) is divided in a way that a fixed stuffing pattern (a stuff bit of opposite polarity) is inserted at predetermined positions. This reduces uncertainty in frame length and makes the CRC checker design simpler for larger payloads.
• Stuff-Bit Counter: Additionally, CAN FD adds a stuff count mechanism. An 8-bit sequence (3-bit binary count with Gray coding, plus parity and some fixed bits) in the CRC field encodes the number of stuff bits that were inserted in the frame. This stuff-bit counter is sent right before the CRC remainder. Receivers use this information to verify that the correct number of stuff bits were present and detect certain forms of errors that might otherwise go unnoticed. The inclusion of a parity check on this count further improves robustness.

These measures, combined with the longer CRC, ensure that CAN FD maintains a high error-detection capability even with the larger frames. In fact, the design goal was to detect all single-bit errors and most double-bit errors in a frame, despite the increased length. The improved stuffing mechanism helps achieve that by avoiding pathological bit patterns that could defeat error checking. From a performance standpoint, reducing the unpredictability of stuff bits slightly improves worst-case timing calculations and protocol efficiency, especially at high data rates.

It’s worth noting that aside from the CRC field, the rest of the CAN FD frame still uses the standard bit stuffing rule during the arbitration and data fields. So, stuff bits will still be inserted after 5 identical bits in those portions. The net effect on efficiency depends on the data content, but with 64-byte payloads, the relative overhead of stuff bits is generally lower than in multiple smaller classical frames carrying the same total data. Designers can also choose data byte patterns (in higher-layer protocols) that minimize consecutive identical bits to reduce stuff bits if needed.

Enhanced CRC and Error Detection

Error detection has always been a strength of CAN. Classical CAN uses a 15-bit CRC (with a known polynomial) to protect up to 8 data bytes, providing a minimum Hamming distance of 6 (able to detect up to 5 random bit errors in a frame under certain conditions). For CAN FD, because frames can be much longer, the error detection scheme was upgraded:

• Longer CRC Polynomials: CAN FD employs two CRC polynomials: a 17-bit CRC for frames with payload 0–16 bytes, and a 21-bit CRC for frames with payload >16 up to 64 bytes. The generator polynomials were chosen to guarantee a strong error detection performance for the respective maximum frame lengths. The 21-bit CRC in particular is necessary to maintain a high Hamming distance for 64-byte messages (since the probability of undetected errors would be higher if the old 15-bit CRC were used over such a long message).
• Augmented CRC Field: As described above, the CRC field in CAN FD is not just the raw CRC bits. It also includes the stuff-bit count and parity, which act as additional check bits. This effectively increases error coverage. Any discrepancy in the number of stuff bits, or a parity mismatch, will cause the frame to be detected as erroneous.
• Robust Error Detection Mechanisms: Beyond CRC, CAN FD retains all the robust error checking mechanisms of Classical CAN – including frame format checks, ACK monitoring, bit monitoring, and bit stuffing checks. In total, CAN FD uses five kinds of error detection (at bit level: bit monitoring and bit stuffing; at message level: CRC, frame check, and acknowledgment check). The enhancements to CRC and stuffing primarily strengthen the CRC and frame check aspects. According to Bosch/CiA, these safeguards ensure that all single-bit errors are detected and greatly improve detection of multiple-bit errors. This was validated through analysis and has been one of the selling points of CAN FD for safety-critical systems.

In summary, CAN FD’s error detection is equal or superior to Classical CAN despite the higher speeds and longer frames. The introduction of a more powerful CRC and additional check bits was a necessary evolution to maintain reliability. Early revisions of CAN FD (the non-ISO 2012 version) did not include the stuff count in the CRC field; this was identified as a potential weakness (“the CRC issue”) and was corrected in the ISO 11898-1:2015 standard update. All modern CAN FD controllers implement the ISO version, ensuring robust error checking. 

Comparison with Classical CAN

The table below summarizes the major differences between Classical CAN (CAN 2.0) and CAN FD:

As shown, CAN FD preserves the core structure of the CAN frame (SOF, arbitration ID, control, data, CRC, ACK, EOF all exist in similar order) but extends and modifies certain fields to deliver higher performance. The arbitration mechanism (non-destructive bitwise arbitration using message IDs) remains identical; thus, priority handling and real-time behavior are comparable between Classical CAN and CAN FD. Importantly, a CAN FD controller is typically dual-mode, meaning it can communicate in classical CAN format (acting just like a CAN 2.0 node when needed) or in FD format. This was intended to allow a gradual transition to CAN FD in systems. In practice, as noted, mixing CAN FD and non-FD nodes on the same bus has limitations (addressed next).

The espBerry DevBoard combines the ESP32-DevKitC development board with any Raspberry Pi HAT by connecting to the onboard RPi-compatible 40-pin GPIO header.

The PiCAN FD board adds CAN Bus FD (Flexible Data Rate) capability to the Raspberry Pi, utilizing the Microchip MCP2517FD CAN FD controller and the MCP2562FD CAN transceiver.

The board includes onboard connection options via DB9 connector or a 4-way screw terminal, making integration into a variety of systems easy.

More information...

Applications of CAN FD

Since its standardization, CAN FD has been adopted in various industries, primarily propelled by the automotive sector. Wherever Classical CAN was used for its robustness and simplicity, CAN FD offers a path to handle more data and higher bandwidth demands. Below are some key application areas and use cases for CAN FD:

• Automotive (Advanced Driver Assistance Systems and Beyond): The automotive industry was the driving force behind CAN FD. Modern vehicles incorporate advanced driver-assistance systems (ADAS), high-resolution sensors (radar, LiDAR, cameras), and increasingly centralized computing units that generate and exchange large volumes of data. CAN FD provides the higher throughput needed for these data-intensive tasks while retaining CAN’s reliability and real-time control characteristics. For example, an autonomous driving ECU might need to receive obstacle data from multiple radar sensors quickly; by using CAN FD at 5 Mbit/s with 64-byte frames, the system can significantly reduce the bus latency compared to Classical CAN. Powertrain and drivetrain systems also benefit: engines and transmissions now include more sensors (for precision control and monitoring) and may use CAN FD to send detailed status messages or diagnostic information without splitting into many small frames. Another important automotive use case is ECU flash reprogramming and diagnostics. Updating software or calibrations in an ECU over the CAN bus (during servicing) can be much faster with CAN FD – garages can reflash firmware in a fraction of the time it used to take with Classical CAN, reducing service times. By 2019, major car OEMs like GM and Daimler had embraced CAN FD for high-performance network domains in vehicles, and today it is common in new platform architectures alongside other networks like Automotive Ethernet.
• Industrial Automation and Robotics: CAN has long been used in industrial control (for example, with the CANopen protocol in automation systems). CAN FD is increasingly being adopted in these environments to meet the needs of Industry 4.0 and beyond. CANopen FD (released in 2017 as CiA 1301) upgrades the CANopen standard to leverage CAN FD’s 64-byte frames and higher bit rates for machine control and motion control systems. This allows, for instance, more complex sensor data or multiple setpoints to be sent in a single message, or faster control loop cycles for precision robotics. Factories with distributed controllers, sensors, and actuators can transmit larger configuration blocks or diagnostic logs over CAN FD without the throughput bottleneck of 8-byte frames. In robotics, multiple motor controllers and sensors on a CAN FD network can coordinate with lower latency, which is crucial for real-time motion coordination. Additionally, industrial systems often have many nodes; CAN FD’s efficiency can help reduce overall bus load (as one CAN FD message can carry what used to require many Classical CAN messages). The robustness of CAN (error detection, fault confinement) remains intact, which is essential for industrial reliability.
• Heavy Vehicles and Transportation: Buses, trucks, and off-highway vehicles (which traditionally use SAE J1939 protocol over CAN) are also moving toward CAN FD. SAE has introduced adaptations of J1939 to CAN FD (sometimes referred to as J1939-22) to allow longer parameter groups and higher bandwidth on the vehicle network. This is used for advanced engine control, telemetry, and even semi-autonomous functions in heavy equipment. For example, a modern tractor or construction vehicle might utilize CAN FD to connect high-resolution displays, central controllers, and implements, all of which exchange more data than before (such as detailed GPS, yield monitors, or diagnostic info).
• Medical Devices and Equipment: CAN networks appear in medical electronics as well – from imaging equipment to surgical machines and hospital bedside devices – because of CAN’s reliability and error checking (patient safety is paramount). CAN FD’s advantages are being recognized here too. In a medical imaging device (MRI, CT, ultrasound), a CAN FD network could be used to connect various control modules and sensors, sending larger configuration datasets or status messages quickly. In devices like infusion pumps or ventilators that might be networked for central monitoring, CAN FD can allow more detailed data (like waveforms or logs) to be transmitted periodically without network congestion. Medical robotics (such as robotic surgery assistants or prosthetic/exoskeleton control) is another niche that can benefit from the low latency and increased data size – for instance, streaming multiple channels of sensor feedback in a single frame to synchronize movement.
• Aerospace and Defense: Some aerospace and defense systems use CAN (e.g., CANaerospace or MILCAN for military vehicles). These applications often have expanded data needs for sensors and payloads. CAN FD can provide higher bandwidth for, say, an aircraft’s sensor networks or a military ground vehicle’s control systems, while still meeting stringent reliability and real-time requirements. Additionally, unmanned vehicles (UAVs, UGVs) that currently use CAN for onboard communication could use CAN FD to handle high-rate telemetry or control signals more efficiently.
• Other Use Cases: Because Classical CAN is so ubiquitous, virtually any domain that used CAN is evaluating CAN FD. This includes marine electronics, underwater ROVs, renewable energy systems (wind turbines, solar inverters often use CAN for internal comms), and building automation. Many of these systems are seeing increases in complexity (more sensors, more data logging), which CAN FD can accommodate. As an example, a wind turbine might have a CAN FD network linking its hub, blade pitch controllers, and condition monitoring units, allowing faster communication of vibration analysis data or power measurements. In general, the pervasiveness of classical CAN in various industries means CAN FD’s improved protocol is being incorporated into a wide variety of applications beyond just cars.

It’s important to note that CAN FD is not intended to completely replace every use of CAN immediately – in cost-sensitive or low-data-rate scenarios, classic CAN at 125 kbps or 500 kbps is still perfectly adequate. However, CAN FD extends the useful life and capability of CAN technology into realms that would otherwise push the old limits. It fills the gap between Classical CAN and more complex network technologies like Ethernet, offering a middle ground of higher performance while preserving CAN’s simplicity and robustness.

Challenges and Considerations

While CAN FD offers clear advantages, transitioning from Classical CAN to CAN FD comes with challenges. Engineers and system integrators must consider compatibility issues, hardware/software upgrades, and other implications when adopting CAN FD:

• Backward Compatibility and Mixed Networks: A critical point is that CAN FD and Classical CAN are not fully interoperable on the same bus. CAN FD was designed to allow new controllers to also send/receive classical frames, but a legacy CAN controller cannot parse a CAN FD frame. In fact, if a CAN FD frame is transmitted on a bus where some nodes are classical CAN only, those legacy nodes will detect an error (due to the unexpected recessive FDF bit and the lack of expected stuffing transitions) and will flag an error, disrupting the communication. In other words, CAN FD is backward-compatible, but Classical CAN is not forward-compatible with FD. All nodes on a bus must support CAN FD in order to use FD frames successfully. This means that during transition, systems either need to upgrade all nodes on a CAN segment to FD-capable ones or segregate FD traffic onto dedicated buses. To ease this, many CAN FD controllers have a configuration to operate in a “CAN 2.0 mode” so they only send classical frames if required on a mixed network. There has also been development of CAN FD tolerant transceivers or gateways – for example, a legacy node could be outfitted with a transceiver that detects FD frames and ignores them (instead of generating an error), allowing it to coexist passively on an FD bus. However, such solutions are not widely standard; the safest approach is to assume a network must be homogeneous regarding FD capability. This challenge implies that upgrading a vehicle or machine from Classical CAN to CAN FD might require a wholesale update of all ECUs on that bus, or the introduction of a bridge that separates old and new nodes.
• Hardware and ECU Upgrades: Every CAN FD node requires a CAN FD-compatible controller (the CAN controller IP in microcontrollers or stand-alone CAN controllers must support the extended frame format and dual bit rates). Older CAN controllers (pre-2013 designs) do not support FD and typically cannot be made to do so via firmware updates because the hardware filtering and protocol state machines are fixed for the 8-byte frame format. Thus, adopting CAN FD often means using newer microcontrollers or peripheral chips that include CAN FD controller IP. Similarly, CAN transceivers – the analog drivers that interface to the bus – need to handle the faster edge rates of CAN FD. While the physical layer voltage levels and wiring remain the same (ISO 11898-2 high-speed CAN transceivers), high bit rates shorten the bus length and require transceivers with low propagation delay and fast slew rates. Many silicon vendors now offer “CAN FD transceivers” specified for 2 Mbps or 5 Mbps operation with symmetry and timing tight enough to meet FD requirements. In practice, if a design is upgrading to CAN FD, all transceiver ICs on that bus should be checked and likely replaced with CAN FD-rated versions to ensure signal integrity at the higher speeds. Failing to do so could result in increased errors (especially at temperature extremes or on longer cables). Additionally, higher bit rates can increase electromagnetic interference (EMI) if not managed – designers may need to pay attention to cable shielding, layout, and perhaps CAN choke use when using FD at several Mbit/s.
• Software and Protocol Stack Changes: On the software side, moving to CAN FD impacts the entire communication stack. Low-level drivers must handle the new frame format and possibly configure two bit timings (for arbitration and data phase) instead of one. Buffer management needs to accommodate up to 64 bytes per frame, which might involve larger buffer allocations and adjustments in interrupt service routines that handle CAN traffic. Higher-layer protocols (like CANopen, J1939, ISO-TP for transport layer, etc.) have had to release updated specifications to utilize CAN FD. For example, diagnostic protocols (UDS on CAN) now allow larger single-frame payloads, which simplifies some transfers. Developers need to update these protocol libraries and ensure backward compatibility if interacting with legacy systems. Testing and tools also required updates: CAN FD capable bus analyzers, oscilloscopes with CAN FD decode, etc., are necessary to debug and validate systems. Initially, these tools were lagging but now most CAN development tools support FD. Nonetheless, teams transitioning a mature CAN 2.0 network to CAN FD must budget effort for re-testing the network communications under the new protocol to ensure everything (from error handling to timing) still behaves as expected, especially under worst-case conditions.
• Integration with Existing Systems: During a transition period, it’s likely that some subsystems remain on Classical CAN while new ones use CAN FD, requiring integration. Gateways or bridge nodes might be used to connect a Classical CAN bus to a CAN FD bus. This introduces complexity, as the gateway must buffer and possibly split/join messages between the two domains. For instance, an existing ECU on a classical CAN bus sending multiple 8-byte frames might be replaced by a single 64-byte frame from an FD domain – the gateway would have to segment it appropriately when forwarding to the classical side. Careful consideration is needed to avoid overwhelming a slower bus or violating timing constraints when converting between protocols.
• Non-ISO vs ISO CAN FD: One historical quirk is the existence of non-ISO CAN FD vs ISO CAN FD. The initial Bosch CAN FD 1.0 specification (published in 2012) differed slightly from the final ISO 11898-1:2015 standard. The ISO version added the above-mentioned stuff-count in the CRC and some other minor adjustments to improve error detection. This means early CAN FD implementations (in some prototype silicon or early products around 2013–2014) were non-ISO and would not communicate correctly with ISO-compliant implementations (they would effectively disagree on frame format in certain cases, resulting in error frames). Today, virtually all commercial CAN FD controllers adhere to the ISO standard, but engineers should ensure that all devices in a network are configured to the same CAN FD mode. Some controllers (like those from Microchip or NI interface cards) support both modes for backward compatibility in labs, and allow switching to non-ISO mode if needed for a legacy device. In any new design, ISO CAN FD should be used exclusively. The lesson here is to double-check that all network nodes have CAN FD ISO compliance to avoid mysterious communication errors.
• System Design and Timing: CAN FD’s higher throughput can actually change system-level behavior. For example, because an FD frame can transmit 64 bytes quickly, it is possible to saturate a slower receiving node if messages arrive back-to-back at high speed and that ECU’s application loop can’t process them fast enough. In Classical CAN, the limit of 8 bytes and lower speed meant a sort of natural pacing. System designers might need to implement flow control or scheduling considerations to avoid overloading nodes with too much data at once (especially if mixing with transport protocols that send large multi-frame bursts). The CAN bus utilization (bus load) calculation also changes with CAN FD: one must account for the shorter frame times and longer payloads. Analytical models and tools exist to help compute CAN FD bus load and worst-case latencies (some extended from classical CAN analyses). Ensuring real-time deadlines are met with CAN FD requires updated timing analysis.

Despite these challenges, the transition to CAN FD is generally seen as manageable, given proper planning. The upgrade path typically occurs in new vehicle platforms or new machine designs, where all ECUs can be specified with CAN FD from the start. In retrofit scenarios, careful segmentation and gateways can allow coexistence. The benefits in throughput and efficiency often justify the effort, especially as the cost difference for CAN FD capable chips has diminished over time.

Conclusion

CAN FD represents a significant evolution of the CAN bus protocol, addressing modern communication demands while preserving the core advantages that made CAN ubiquitous. By extending the data payload to 64 bytes and allowing flexible switching to higher bit rates within a frame, CAN FD dramatically increases the data throughput of CAN networks. It achieves this with only modest modifications to the frame format and without sacrificing real-time performance or reliability. Key enhancements like the extended CRC with stuff-bit counter and new control bits (FDF, BRS, ESI) ensure that the protocol remains robust against errors even as it operates faster and carries more information.

In practical terms, CAN FD enables vehicles, machines, and devices to exchange much more data over the familiar two-wire CAN bus. This has opened up new possibilities: high-bandwidth sensor data streaming, faster ECU reprogramming, consolidation of networks (reducing the number of separate CAN buses in a system by handling more traffic on one bus), and the ability to future-proof designs for upcoming data requirements. The benefits of CAN FD include improved efficiency (fewer frames and lower protocol overhead for a given amount of data), reduced latency for high-priority transmissions, and the ability to scale CAN-based networks to meet current and near-future needs.

Looking forward, CAN FD is expected to largely supersede Classical CAN in new designs over the coming years, especially in the automotive domain where performance requirements are ever-increasing. At the same time, it will continue to coexist with legacy CAN in many applications, given the vast installed base and the fact that not all systems need the extra capacity. For even more demanding scenarios, the CAN in Automation community and Bosch have been developing CAN XL, the next-generation CAN protocol that supports data rates up to 10–20 Mbit/s and payloads up to 2048 bytes. Notably, CAN XL is designed to be compatible with CAN FD, allowing a smooth migration path where CAN XL controllers can also communicate using CAN FD and classical frames. This means the evolutionary path of CAN will continue, with CAN FD as a crucial stepping stone.

In conclusion, CAN FD extends the longevity and capability of the CAN bus in the era of increasing data exchange requirements. It retains the simplicity, distributed control, and robustness that engineers trust, while significantly boosting performance. As more ECUs and devices adopt CAN FD, industries will enjoy the higher bandwidth and efficiency in their control networks without having to completely shift to more complex networking technologies for medium-range data rates. CAN FD embodies an elegant technical solution – enhancing a tried-and-true protocol to meet new challenges, which is why it has seen rapid and growing adoption in engineering communities worldwide.

References

1. Wikipedia – CAN FD (Controller Area Network Flexible Data-Rate) en.wikipedia.orgen.wikipedia.org (development history, technical overview). https://en.wikipedia.org/wiki/CAN_FD
2. CiA (CAN in Automation) – CAN FD: The basic idea web.archive.orgweb.archive.org (article explaining CAN FD’s motivation and fundamental changes). Archived: https://web.archive.org/web/20170202024101/https://www.can-cia.org/can-knowledge/can/can-fd/
3. Bosch – CAN FD Protocol product page bosch-semiconductors.com (Bosch introduction of CAN FD, 2012, and standardization in 2015). https://www.bosch-semiconductors.com/products/ip-modules/can-protocols/can-protocol-1.html#can-fd-protocol
4. NI (National Instruments) – CAN FD: ISO Versus Non-ISO ni.com (explanation of differences between Bosch’s CAN FD 1.0 and ISO 11898-1:2015 standard). https://www.ni.com/docs/en-US/bundle/ni-xnet/page/can-fd-iso-versus-non-iso.html
5. HMS Networks – CAN vs CAN FD: Compatibility hms-networks.comhms-networks.com (blog post discussing why CAN FD frames are not backward compatible with classic CAN controllers). https://www.hms-networks.com/tech-blog/blogpost/hms-blog/2020/05/29/can-vs-can-fd-compatibility
6. Phytools – Introduction to CAN FD phytools.com (overview of CAN FD improvements: higher bitrate, larger payload, improved CRC). https://phytools.com/pages/can-fd-intro
7. CANopen FD (CiA 1301) Press Release – CANopen FD is released (Sept 2017) (industrial adoption of CAN FD in higher-layer protocols). https://www.can-cia.org/news/cia-in-action/view/cia-1301-released (accessed via emotas.de summary)
8. IEEE Access journal – De Andrade et al., “Analytical and Experimental Performance Evaluations of CAN-FD Bus” (2018) – detailed performance analysis of CAN FD vs Classical CAN in various scenariosen.wikipedia.org. https://doi.org/10.1109/ACCESS.2018.2826522