CAN FD
CAN FD, or Controller Area Network Flexible Data-rate, is an enhanced communication protocol that extends the classical CAN bus standard by supporting higher bit rates up to 8 Mbit/s during the data phase and payloads of up to 64 bytes per frame, while maintaining compatibility with existing CAN networks for arbitration and control phases.[1][2] Developed to address the growing bandwidth requirements in automotive and industrial applications, CAN FD enables more efficient data transmission without requiring a complete overhaul of legacy CAN infrastructure, making it suitable for modern electronic control units (ECUs), diagnostics, and gateway functions.[3][1] Introduced by Robert Bosch GmbH in 2012 in collaboration with automotive manufacturers and CAN experts, CAN FD builds on the original CAN protocol—standardized in the 1980s—to overcome limitations such as the 1 Mbit/s speed cap and 8-byte data restriction, thereby increasing effective throughput by up to six times in optimized configurations.[2][3] The protocol was formalized through international standardization, first as part of ISO 11898-1:2015 and later updated in ISO 11898-1:2024, ensuring interoperability across devices from multiple vendors.[1][2] Key technical advancements in CAN FD include bit rate switching (BRS), which allows a lower arbitration bit rate (typically 500 kbit/s or 1 Mbit/s) for multi-node bus access and a higher data bit rate for the payload transmission when a single node is dominant; an extended data length (EDL) indicator to denote FD frames; and an enhanced CRC polynomial for error detection in longer payloads.[2][3] These features position CAN FD as a cost-effective bridge between classical CAN and higher-speed protocols like Ethernet or FlexRay, widely adopted in vehicles for applications such as advanced driver-assistance systems (ADAS), infotainment, and powertrain control.[1][3]Background and History
Origins and Development
The development of CAN FD (Controller Area Network with Flexible Data-rate) originated from the need to extend the capabilities of the classical CAN protocol, which had reached its limits in supporting the increasing data demands of modern automotive systems. In 2011, Robert Bosch GmbH and General Motors initiated the project to address the classical CAN's restrictions, including a maximum payload of 8 bytes and a bit rate capped at 1 Mbps, which were insufficient for emerging applications requiring higher bandwidth.[2][1][4] This effort was primarily driven by the automotive industry's shift toward more data-intensive features, such as advanced driver-assistance systems (ADAS) that process sensor data for safety functions and infotainment systems handling multimedia and connectivity. Bosch, as the primary inventor of the original CAN protocol, led the development in close collaboration with automotive original equipment manufacturers (OEMs) including General Motors and Daimler and other CAN experts to ensure compatibility and practical implementation. The motivations centered on enabling efficient communication in vehicle networks where data volumes were growing rapidly due to electrification, automation, and entertainment demands.[5][6] Key milestones included the predevelopment phase in 2011, culminating in prototype demonstrations and the official release of the CAN FD specification version 1.0 in 2012 at the 13th International CAN Conference. Bosch worked with semiconductor vendors, including NXP and Microchip, to integrate CAN FD into hardware prototypes, facilitating early testing and validation in real-world automotive environments. These collaborations accelerated the transition from concept to viable technology, paving the way for broader adoption without disrupting existing CAN infrastructure.[6][7][8]Standardization Process
The standardization of CAN FD was initiated following Bosch's release of the initial specification in 2012, which proposed enhancements to the classical CAN protocol to support higher data rates and larger payloads.[6] The International Organization for Standardization (ISO) Technical Committee 22, Subcommittee 31 (ISO/TC 22/SC 31) on road vehicle data communication then undertook the formal development process, culminating in the publication of ISO 11898-1:2015 as the core international standard.[9] This document specifies the data link layer and physical signaling for both classical CAN and CAN FD, effectively updating and integrating CAN FD into the existing framework while introducing protocol modifications, such as an updated cyclic redundancy check (CRC) polynomial for improved error detection in frames up to 64 bytes.[10] The standard was approved as a Draft International Standard in June 2015 with unanimous support and officially published in December 2015.[11] Subsequent extensions addressed specific industry needs. In 2018, the Society of Automotive Engineers (SAE) finalized updates to the J1939 protocol suite for heavy-duty vehicles, with SAE J1939-22 defining the CAN FD data link layer to enable higher bandwidth transport protocol messages while maintaining compatibility with classical CAN infrastructure.[12] In 2017, the CAN in Automation (CiA) association released CiA 1301, which outlines the CANopen FD communication profile and includes procedures for device conformance testing to ensure interoperability in industrial and automation applications. Regional adoption accelerated following these milestones, with some automotive manufacturers in the US, Europe, and Asia incorporating CAN FD into production vehicles starting in model year 2018 to meet demands for advanced driver assistance systems and increased network throughput.[13] The ISO 11898-1 standard has since evolved, with the 2024 edition incorporating additional protocols like CAN FD light for further optimization in resource-constrained environments.[2]Protocol Fundamentals
Key Features and Enhancements
CAN FD introduces several key enhancements over classical CAN to address limitations in data throughput and efficiency, primarily by increasing payload capacity and enabling higher transmission speeds in specific frame phases. The protocol supports a flexible data rate (FDR) mechanism, allowing the bit rate to switch from a nominal rate (typically up to 1 Mbps) used during the arbitration phase to a higher data rate (up to 8 Mbps) in the data phase, significantly boosting overall bus utilization when only one node is transmitting.[14] This bit rate switching is triggered by the Bit Rate Switch (BRS) flag in the frame control field, ensuring that the arbitration phase remains at the nominal rate to preserve collision avoidance and multi-node compatibility, as multiple nodes compete for bus access using the same timing as in classical CAN.[2] A major improvement is the expansion of the data payload to up to 64 bytes per frame, compared to the 8-byte limit in classical CAN, which reduces protocol overhead and allows more efficient transmission of larger messages without fragmentation.[2] This is facilitated by an extended Data Length Code (DLC) field that encodes payload sizes beyond 8 bytes in a non-linear manner. To maintain data integrity with these longer payloads, CAN FD employs enhanced cyclic redundancy check (CRC) polynomials: a 17-bit CRC for payloads up to 16 bytes and a 21-bit CRC for payloads exceeding 16 bytes, providing superior error detection capabilities over the 15-bit CRC of classical CAN.[15] These polynomials are calculated to include stuff bits, further improving reliability.[14] Additionally, CAN FD optimizes bit stuffing and related mechanisms to minimize latency and enhance predictability. Unlike classical CAN, where bit stuffing is applied dynamically after five consecutive identical bits, the CRC field in CAN FD incorporates fixed stuff bits (FSB)—one opposite-polarity bit inserted after every four bits—eliminating variability in CRC length and reducing the potential for transmission delays.[2] Stuff bits are also integrated into the CRC computation, along with a 3-bit stuff count transmitted before the CRC sequence, which allows receivers to verify stuffing integrity and detect errors more robustly. These refinements, standardized in ISO 11898-1:2015 (and updated in ISO 11898-1:2024), collectively enable CAN FD to achieve up to six times the effective data rate of classical CAN under typical conditions.[2][16]Frame Structure Overview
The Controller Area Network with Flexible Data-rate (CAN FD) frame structure extends the classical CAN format to support larger payloads and higher data rates while maintaining backward compatibility. The primary frame type is the data frame, which carries the actual information payload, while remote frames, error frames, and overload frames serve specific protocol functions. Unlike classical CAN, CAN FD data frames do not support remote transmission requests for FD-formatted messages; instead, compatibility is achieved by transmitting classical CAN remote frames to solicit data responses in the classical format.[2][14] A CAN FD data frame begins with the Start of Frame (SOF) field, consisting of a single dominant (0) bit that synchronizes all nodes on the bus and marks the frame's commencement, identical to classical CAN. This is followed by the Identifier field, which is either 11 bits long in the base frame format (FBFF) for standard identifiers or 29 bits in the extended frame format (FEFF). The identifier determines message priority during arbitration, with lower values winning bus access. The Control Field follows the identifier and includes bits to indicate frame format and features. For the base frame format (FBFF), after the 11-bit identifier, it consists of the Substitute Remote Request (SRR) bit (recessive for data frames), the Identifier Extension (IDE) bit (dominant for base format), the Extended Data Length (EDL) bit (recessive to indicate CAN FD format, dominant for classical CAN compatibility), the Bit Rate Switch (BRS) bit (recessive to signal a switch to a higher data phase bit rate after arbitration, dominant to maintain the nominal rate), and the Error State Indicator (ESI) bit (dominant for error-active nodes, recessive for error-passive), followed by the 4-bit Data Length Code (DLC). For the extended frame format (FEFF), the 29-bit identifier incorporates the SRR and IDE bits (IDE recessive), after which follow the EDL bit, BRS bit, ESI bit, and 4-bit DLC.[14][17][2] The Data Field follows, supporting 0 to 64 bytes of payload—far exceeding the 0-8 bytes of classical CAN—with the DLC (4 bits) encoding the length in a non-linear manner (e.g., values 9–15 map to 12, 16, 20, 24, 32, 48, or 64 bytes) to optimize bandwidth. This is succeeded by the Cyclic Redundancy Check (CRC) field, which uses a 17-bit polynomial for data lengths up to 16 bytes or a 21-bit polynomial for longer payloads, providing enhanced error detection over the 15-bit CRC of classical CAN by incorporating stuff-bit count and parity for robustness against burst errors. The CRC Delimiter is a single recessive (1) bit, after which the ACK Slot (recessive from transmitter, overwritten dominant by at least one receiver to acknowledge receipt) and ACK Delimiter (recessive) ensure confirmation, followed by the End of Frame (EOF) of seven recessive bits to signal frame termination and allow bus idle detection. Error frames and overload frames retain classical CAN structures for compatibility, consisting of six dominant error bits or three dominant overload flags plus delimiters, respectively, to handle faults or bus overload without FD-specific modifications.[14][2][17]Comparison with Classical CAN
Structural Differences
The frame structure of CAN FD introduces several modifications to the classical CAN format to support larger payloads and flexible data rates while maintaining backward compatibility during the arbitration phase. The identifier field and arbitration process remain unchanged from classical CAN, allowing CAN FD frames to coexist on the same bus with classical CAN frames. In both formats, the arbitration field uses either an 11-bit identifier (base frame format) for standard frames or a 29-bit identifier (extended frame format) for extended frames, with the same non-destructive bitwise arbitration mechanism based on identifier priority.[18] In classical CAN, the control field is 6 bits: for base format after RTR in arbitration, IDE (dominant), r0 (dominant), DLC (4 bits); for extended format after RTR, r1 (dominant), r0 (dominant), DLC (4 bits) indicating 0 to 8 bytes of data. In CAN FD base format, after r1 (dominant, replacing RTR) in arbitration, the control field consists of IDE (dominant), EDL (recessive), r0 (dominant), BRS (recessive if switching), ESI (dominant if error-active), DLC (4 bits encoding 0-64 bytes). For extended CAN FD, after r1 in arbitration, control is EDL, r0, BRS, ESI, DLC (8 bits total for both formats). The DLC in CAN FD uses values 0-8 for 0-8 bytes and 9-15 for 12, 16, 20, 24, 32, 48, 64 bytes respectively. This expansion enables the new features without altering the arbitration phase, ensuring classical CAN nodes can detect but ignore CAN FD frames via the recessive EDL bit.[18] The data field itself is significantly enlarged in CAN FD, supporting up to 64 bytes compared to the maximum 8 bytes in classical CAN, which reduces protocol overhead for larger messages. To maintain data integrity with these extended payloads, CAN FD employs a variable-length CRC field consisting of a 4-bit stuff bit count (SBC: 3-bit modulo-8 counter in gray code + 1 parity bit), the CRC sequence (17 bits using CRC-17 polynomial for 0-16 bytes or 21 bits using CRC-21 for 20-64 bytes), and a 1-bit CRC delimiter; the SBC provides a modulo-8 count of stuff bits with parity for additional error detection. The ESI bit specifically indicates the error state of the transmitting node during the control field, allowing receivers to assess reliability—dominant for error-active nodes (fully operational) and recessive for error-passive nodes (restricted due to error counts)—which has no direct equivalent in classical CAN. These changes collectively allow CAN FD to handle more data per frame while preserving compatibility in mixed networks.[18][2]Performance Improvements
CAN FD significantly enhances throughput compared to classical CAN by allowing payloads up to 64 bytes per frame, an eightfold increase over the 8-byte limit of the original protocol, which reduces the need for message segmentation and improves overall data transmission efficiency.[2] With bit rate switching, where the arbitration phase operates at the classical rate (typically 1 Mbps) and the data phase accelerates to 5-8 Mbps, the effective throughput can reach approximately six times that of classical CAN under a 1:8 bit rate ratio.[2] This combination enables up to 64 times more data per frame in optimal configurations, addressing the growing data demands in modern automotive and industrial systems without requiring a complete protocol overhaul.[19] The protocol's bandwidth utilization improves markedly, permitting classical CAN's full bus capacity at 1 Mbps during arbitration while boosting the data phase to higher speeds, resulting in an effective bandwidth of up to 5 Mbps in practical implementations with data rates of 5 Mbit/s.[19] This efficiency allows for higher bus loads than classical CAN's recommended maximum of 50%, while maintaining real-time performance in optimized networks.[19] Consequently, latency is reduced, particularly for ECU-to-ECU communications in real-time applications, where the accelerated data phase prevents bottlenecks from high-priority messages dominating the bus.[19] Reliability is bolstered through an enhanced cyclic redundancy check (CRC) mechanism, employing 17-bit polynomials for payloads up to 16 bytes and 21-bit for larger ones, supplemented by a 4-bit stuff bit count field (3-bit counter with parity bit), which helps detect errors related to bit stuffing.[2] This results in an undetected error probability of less than 4.7 × 10^{-11} per frame, a substantial improvement over classical CAN's 15-bit CRC, ensuring robust operation in noisy environments.[20] However, the higher data rates introduce limitations, such as increased susceptibility to electromagnetic interference (EMI), necessitating improved cabling and shielding to maintain signal integrity.[19]Bit Timing and Physical Layer
Data Rate Switching Mechanism
The data rate switching mechanism in CAN FD enables dual-speed operation within a single frame, utilizing a nominal bit rate for arbitration and control fields, and a higher data bit rate for the payload to optimize bandwidth efficiency. The nominal bit time (NBT) governs the arbitration phase, including the start-of-frame (SOF), identifier, and remote transmission request fields, supporting rates from 1 to 1000 kbps while adhering to classical CAN timing parameters. This phase employs the standard segment structure: a Synchronization Segment (Sync_Seg) for edge detection, a Propagation Segment (Prop_Seg) to compensate for signal delays, and two Phase Buffer Segments (Phase_Seg1 and Phase_Seg2) for phase adjustment and synchronization jump width (SJW).[21] In contrast, the data bit time (DBT) applies to the data phase, starting after the control field and extending through the data field and CRC sequence, achieving rates 2 to 8 times faster than the nominal rate to accommodate up to 64 bytes of payload. The DBT maintains the four-segment structure but reduces the Prop_Seg—often to zero time quanta—to minimize the impact of propagation delays at higher speeds, ensuring reliable sampling despite shorter bit durations. The Bit Rate Switch (BRS) bit, positioned immediately after the Data Length Code (DLC) in the control field, triggers the transition: at the BRS sample point, all participating nodes switch to the DBT configuration, with the transmitter initiating the higher rate and receivers aligning accordingly.[21][22] Synchronization during the data phase relies on hard synchronization at the SOF edge and subsequent recessive-to-dominant transitions, with no transmitter-induced resynchronization allowed to preserve timing integrity; nodes maintain sample points using edges within the Sync_Seg, limited to a maximum of 10 bits between synchronizing edges. Oscillator tolerance is more stringent in the FD data phase compared to classical CAN (typically up to ±1.58%), with tolerance calculated per ISO 11898-1 based on bit timing to limit phase drift, often requiring 50-500 ppm depending on data rate and configuration. The bit time for both phases is calculated as: \text{Bit Time} = (\text{Sync\_Seg} + \text{Prop\_Seg} + \text{Phase\_Seg1} + \text{Phase\_Seg2}) \times \text{tq} where Sync_Seg is fixed at 1 time quantum (tq), and tq typically ranges from 10 to 50 ns depending on the clock frequency and prescaler.[21][23][24]Transceiver Specifications
The physical layer for CAN FD is defined by the ISO 11898-2:2024 standard, which specifies high-speed transceivers capable of supporting data rates up to 8 Mbps in the flexible data-rate phase while maintaining compatibility with classical CAN signaling at 5 V levels. This update includes support for signal improvement capability (SIC) transceivers, enabling robust operation at high speeds over longer bus lengths with reduced electromagnetic emissions, and partial networking for selective node wake-up to save power.[25][26] These transceivers interface between the CAN controller and the differential twisted-pair bus, ensuring reliable transmission of dominant (logical 0) and recessive (logical 1) states. Electrically, CAN FD transceivers operate with a common-mode voltage range of -12 V to +12 V on the bus lines to tolerate common-mode disturbances, exceeding the standard's minimum receiver input range of -2 V to +7 V for robustness in automotive environments.[27] The differential output voltage in the dominant state typically ranges from 2 V to 3 V across a 50 Ω to 65 Ω bus load, providing sufficient signal amplitude for noise immunity while keeping recessive-state differential voltage near 0 V (±50 mV).[28][27] Prominent integrated circuit examples include the NXP TJA1044 and Texas Instruments TCAN1044 families, both designed for high-speed CAN FD applications with support for standby and sleep modes to enable low-power operation.[28][27] The TJA1044 supports CAN FD data rates up to 5 Mbps and features a standby mode activated via a dedicated pin, reducing current consumption to 10-15 μA, while the TCAN1044 extends to 8 Mbps with integrated fault protection and similar low-power modes including remote wake-up capability.[28][27] Transceivers incorporate electrostatic discharge (ESD) protection up to ±8 kV per IEC 61000-4-2 on the CAN_H and CAN_L pins, alongside human body model (HBM) ratings of ±8 kV or higher to safeguard against transients.[28][27] Loop delay, critical for high-speed operation, is specified below 220 ns from transmitter input to receiver output, with typical values around 110 ns to 200 ns depending on the variant, ensuring synchronization during data-rate switching.[28][27] Medium access occurs over a twisted-pair cable using CAN_H and CAN_L lines, where the dominant state is driven by a positive differential voltage on CAN_H relative to CAN_L, overriding recessive states from other nodes via wired-AND arbitration.[28] To minimize reflections at high speeds, the maximum unterminated stub length is typically limited to 0.1-0.3 m depending on the transceiver type and cable characteristics, shorter without signal improvement at 8 Mbps.[28]Higher-Layer Integration
Transport Protocol Headers
The ISO 15765-2 Transport Protocol (ISO-TP) provides the higher-layer integration for CAN FD by enabling the segmentation and reassembly of messages larger than a single frame's payload capacity, supporting total payloads up to 4095 bytes through multi-frame transfers.[29] This protocol operates at the transport and network layers of the OSI model, allowing efficient data exchange over CAN FD's enhanced frame sizes while maintaining compatibility with classical CAN systems.[30] The Transport Protocol (TP) header, known as the Protocol Control Information (PCI), consists of 1 to 2 bytes embedded in the initial data bytes of the CAN FD frame.[29] For Single Frame (SF) messages, the PCI is a single byte. In classical CAN format, it is0000 LLLL where the lower 4 bits (LLLL) indicate the data length (0-7 bytes). For CAN FD extended format (length >7), the PCI is 0000 0000 followed by a byte indicating the data length up to 62 bytes.[30] First Frame (FF) uses a 2-byte PCI in the format 1xxx xxxx followed by the total message length (0-4095 bytes), signaling the start of a segmented transfer.[29] Consecutive Frame (CF) employs a 1-byte PCI 2xxx xxxx, where the lower 4 bits denote the sequence number (0-15, wrapping as needed), followed by the segment data.[30] These PCI elements ensure precise identification of frame types and payload positioning without altering the underlying CAN FD frame structure.
Flow control in ISO-TP is managed by the receiver via a 3-byte Flow Control (FC) frame, which includes a PCI byte 3xxx xxxx (indicating flow status: Continue-to-Send, Wait, or Overflow), a block size byte (0-255, where 0 means unlimited consecutive frames), and a separation time byte (0-255, enforcing minimum delays between frames in milliseconds to prevent receiver overload).[29] This mechanism allows the receiver to acknowledge segments, regulate transmission pacing, and specify the number of consecutive frames (up to 16 per block) before requiring further confirmation, optimizing throughput on CAN FD's higher data rates.[30]
ISO-TP for CAN FD extends the classical CAN version by leveraging the larger payload (up to 64 bytes per frame), which reduces the number of required segments for the same message size by up to 8 times compared to classical CAN's 8-byte limit.[30] This compatibility ensures seamless operation in mixed networks, as CAN FD frames can carry classical CAN payloads and vice versa, with the protocol adapting dynamically to the frame's data length code.[29]
A representative application involves Unified Diagnostic Services (UDS) or On-Board Diagnostics (OBD) messages, where a diagnostic tool sends requests to vehicle ECUs using the functional address CAN ID 0x7DF for broadcast inquiries, segmented via ISO-TP if exceeding single-frame limits.[31]