CAN与CANFD通信的区别与联系：从帧格式、位速率切换到工程迁移

hyowinner

CAN与CANFD通信的区别与联系：从帧格式、位速率切换到工程迁移

在汽车电子、储能、工业控制和 HIL 台架项目里，CAN 与 CAN FD 常常同时出现。有人把 CAN FD 简单理解为“CAN 的高速版”，也有人认为“把 DLC 从 8 改成 64 就能升级”。这两种说法都不够准确。

CAN FD 保留了 CAN 最有价值的机制：多主仲裁、广播通信、按标识符决定优先级、逐位监测、错误帧和 ACK 确认；但它以新的帧格式扩展了数据字段，允许在帧内切换到更快的数据位速率，并加强了 CRC 保护。真正的工程难点不只在于能不能发 64 Byte，而在于全网节点兼容性、物理层时序、网关行为、总线负载与软件配置是否一起闭合。

先给出结论：

1. 传统 CAN 单帧数据字段最多 8 Byte，整帧使用同一套标称位时序。
2. CAN FD 单帧数据字段最多 64 Byte；在 BRS（Bit Rate Switch）置位时，仲裁阶段保持标称位速率，数据字段和 CRC 可使用更高的数据位速率。
3. CAN FD 控制器通常可以处理传统 CAN 帧；但传统 CAN 节点不一定能容忍 CAN FD 帧。只要网络中有一个旧节点把 FD 帧当成格式错误并发送错误帧，FD 帧就无法正常通信。
4. CAN FD 没有自动解决所有性能问题。带宽、线束、支线、终端、收发器、网关缓存、软件调度和诊断工具仍然需要按系统重新设计和验证。

图1：CAN FD 不是简单增加数据长度，而是引入 FDF/BRS、扩展 DLC 和更强的 CRC 保护

一、共同基础：两者仍然是同一类 CAN 网络

CAN 与 CAN FD 都是面向广播的多主串行总线。每个节点都可以在总线空闲时发起发送；多个节点同时发送时，按照标识符逐位进行非破坏性仲裁，数值更小的 ID 优先继续发送。接收节点会对正确收到的帧给出 ACK；检测到位错误、填充错误、CRC 错误、格式错误等情况时，节点会通过错误处理机制通知网络。

因此，CAN FD 没有改变“报文优先级由 ID 决定”的基本原则，也没有把 CAN 变成点对点协议。对于软件架构而言，信号打包成 PDU、PDU 映射到 CAN ID、接收端解包和有效性检查的基本思路仍然存在。

物理层上，二者通常都使用 CAN_H 和 CAN_L 两根差分线，并在主干两端进行终端匹配。CAN FD 不是另一种电压制式，也不能只因线束上写着 CAN 就假定它一定适合高速数据相位。随着数据位速率提高，传播时延、支线反射、收发器环路延迟、共模干扰和 EMC 余量都会更敏感。

二、帧格式：8 Byte 与 64 Byte 只是最直观的差异

传统 CAN 的数据字段为 0 到 8 Byte，DLC 为 0 到 8 时分别表示对应的字节数。CAN FD 的 DLC 仍有 4 bit，但编码扩展为：0 到 8 仍表示 0 到 8 Byte；9 到 15 分别表示 12、16、20、24、32、48、64 Byte。也就是说，DLC=15 代表的是 64 Byte，不是十进制 15 Byte。

CAN FD 帧中，FDF 位表明该帧采用 FD 格式；BRS 位决定是否使用位速率切换。CAN FD 的 CRC 序列长度也随数据长度扩展为 17 bit 或 21 bit，并在 ISO CAN FD 格式中引入与填充相关的附加保护。这样做的目的，是为更长数据字段和更高数据位速率保留足够的错误检测能力。

这意味着接收端不能只按“CAN ID + 8 Byte”的旧假设解析。DBC、AUTOSAR COM/PduR/CanIf 配置、驱动层 Tx/Rx buffer、网关缓存和记录工具都要能正确处理 FD 的 DLC 映射、帧格式和数据长度。

三、BRS 的原理：仲裁慢一点，数据快一点

CAN FD 最容易被误解的地方是“速率更高”。更准确地说，CAN FD 可以在同一帧内使用两套位时序：

1. 从 SOF 到仲裁以及相关控制位置，使用标称位速率。所有节点需要在这个阶段以同一节奏采样，才能可靠完成仲裁。
2. BRS=1 时，帧在数据相位和 CRC 相位切换到数据位速率。例如标称 500 kbit/s，数据相位可配置为更高的速率。
3. 到 ACK、EOF 等后续部分，帧再回到标称位速率，便于全部节点按统一时序确认帧结果。

BRS=0 的 CAN FD 帧不进行速率切换，它仍可携带大于 8 Byte 的数据。因而“是否 CAN FD”与“是否 BRS 加速”是两个不同的问题：前者由帧格式决定，后者由 BRS 位和双方时序配置决定。

图2：BRS=1 时，仲裁仍用标称位速率；数据字段和 CRC 使用单独的数据位时序

四、性能提升来自两个维度，不能只看标称速率

CAN FD 的效率提升主要来自两个方面。

第一是更大的 payload。传统 CAN 若要发送 32 Byte 业务数据，往往需要拆成多帧，每帧都有 SOF、仲裁、控制、CRC、ACK、EOF 和帧间隔等开销；CAN FD 可以在一帧内承载这组数据，减少重复协议开销和仲裁次数。

第二是 BRS。把数据字段和 CRC 放到更高数据位速率后，长数据帧在总线上的占用时间会显著缩短。但这个收益只发生在数据相位，仲裁阶段仍由标称位速率决定。对于 1 到 2 Byte 的高优先级短报文，CAN FD 的收益可能很有限；对于周期性状态量、诊断数据、标定测量或需要聚合发送的传感器数据，收益通常更明显。

做总线预算时，不能仅用“64 Byte x 8 bit”估算。实际帧长还包含仲裁、控制、CRC、ACK、帧间隔及位填充开销；总线利用率还会受到高优先级报文抢占、网关转发、驱动发送队列和任务抖动影响。需要基于目标帧格式、标称/数据位速率、报文周期、最坏位填充和端到端时延要求做仿真或实测。

五、兼容性：CAN FD 控制器兼容传统帧，不等于旧网络可以直接发 FD

这是升级项目最常见的风险点。CAN FD 控制器能够收发传统 CAN 帧，因此新 ECU 可以先工作在传统 CAN 模式，与旧 ECU 互联。但是，当网络中开始出现 CAN FD 帧时，旧的传统 CAN 控制器可能把 FDF 位识别为格式错误并主动发送错误帧，导致发送节点不断重发，甚至引发错误计数增长。

工程上要把网络节点分成三类审查：

1. 传统 CAN 节点：只能收发传统 CAN 帧，且不一定能容忍 FD 帧。
2. CAN FD tolerant 节点：可与 FD 节点共网，但本身只使用传统 CAN 帧，并且不会破坏其他节点的 FD 通信。
3. CAN FD active 节点：控制器和收发器支持 CAN FD，可收发 FD 帧，并具备正确的标称/数据位时序配置。

除了 ECU，本次审查还应覆盖网关、USB-CAN 适配器、记录仪、诊断仪、Bootloader、产线设备和售后工具。很多问题并非出在主控 ECU，而是某个维护工具接入后触发格式错误，或网关未正确转发 CAN FD PDU。

当旧节点无法容忍 FD 帧时，常见的策略是保持该网络只发送传统 CAN 帧，或将 CAN FD 网络与传统 CAN 网络分开，通过网关按应用层规则转换。不要依赖“先试着发一帧看看”来判断兼容性，应以器件数据手册、网络清单和实测错误帧结果为依据。

六、硬件与物理层：CAN FD 不是只改控制器寄存器

要启用 CAN FD，至少要确认以下硬件条件：

1. MCU 或独立控制器支持 CAN FD，并能分别配置 nominal bit timing 与 data bit timing。
2. 收发器的数据手册明确支持目标 CAN FD 数据位速率和网络工作模式。
3. 总线保持线型主干拓扑，两端终端电阻位置正确；支线长度和连接器质量满足目标速率的反射与传播时延预算。
4. 控制器的发送延迟补偿、采样点、SJW、时钟精度和收发器环路延迟按器件和网络约束配置。
5. 对长线束、复杂支线、强电磁环境和高数据位速率场景，进行示波器、错误帧统计和 EMC 联合验证。

工程上常见的错误是：传统 CAN 在 500 kbit/s 下长期稳定，就认为把数据相位设成更高即可。实际上，原本被低速时序掩盖的支线反射、终端偏差和收发器延迟，可能在 CAN FD 下迅速变成 CRC 错误、错误帧和偶发掉线。

七、MBD 项目怎样把 CAN FD 做成可验证的接口

在 MBD 项目中，CAN FD 不能只在模型外部“接一个总线模块”。建议建立从模型信号到网络验证的完整链路：

1. 模型层：定义信号量纲、更新周期、超时策略、有效性和故障降级，不把接收值直接当成永久可信输入。
2. PDU 层：按 DBC 或 AUTOSAR 配置明确 CAN ID、字节序、缩放、DLC、rolling counter、CRC/E2E 和发送周期。
3. 驱动层：明确该 PDU 是否使用 CAN FD、是否 BRS、标称与数据位时序、发送 FIFO 优先级和队列长度。
4. 验证层：在 SIL、台架和 HIL 中注入延迟、丢帧、错误计数、总线拥塞和网关转发异常，检查控制算法是否安全降级。

特别是 64 Byte PDU，不建议因为“空间很大”就把大量不同周期、不同安全等级的信号混在一帧里。这样会让低优先级字段绑住高优先级字段的发送周期，也会让 CRC/E2E 覆盖范围、故障定位和版本兼容变复杂。PDU 的划分仍要以时序、原子性、功能边界和安全需求为依据。

图3：从选型到 HIL 验证，需要把 CAN FD 的帧参数、网络参数和软件接口纳入同一条配置链

八、CAN 与 CAN FD 的选型建议

优先继续使用传统 CAN 的场景包括：网络内已有不支持 FD 的节点；数据量小且周期要求不高；线束与工具链已经稳定；改造成本高于带宽收益。传统 CAN 在车身状态、慢速诊断和大量成熟网络里仍然是合适的工程选择。

优先考虑 CAN FD 的场景包括：单帧数据超过 8 Byte 且拆帧成本高；周期性数据导致传统 CAN 总线负载接近上限；需要缩短长 PDU 的传输时间；诊断、标定、传感器融合或控制状态需要更高吞吐；且全网节点和物理层能够完成 FD 升级。

无论选择哪一种，CAN FD 也不应被误解为时间确定性保证。仲裁、报文周期、发送队列、网关调度、操作系统任务和错误重发仍会影响端到端延迟。对安全关键控制，应继续进行最坏时延分析和故障注入验证。

常见误区

1. 误区：CAN FD 的 64 Byte 一定比 8 个传统 CAN 帧更快。实际收益取决于 BRS、标称速率、数据速率、仲裁竞争、数据长度和总线负载。
2. 误区：CAN FD 控制器兼容 CAN，所以老网络可直接发 FD。发送 FD 前必须确认所有节点能够支持或容忍 FD 帧。
3. 误区：换了 FD 控制器就够了。收发器、拓扑、终端、线束、网关和工具链同样是系统约束。
4. 误区：64 Byte 更大，就应把所有信号装进一个 PDU。PDU 划分要服务于时序、故障隔离、版本管理和安全需求。
5. 误区：总线利用率低于 100% 就没有实时性风险。高优先级抢占、突发报文、错误重发和排队延迟仍可能让低优先级报文错过截止时间。

结论

CAN FD 与传统 CAN 是继承与扩展的关系：它继承了 CAN 的仲裁、广播、ACK 和错误处理基础，在此之上以更大的数据字段、可选的位速率切换和更强的 CRC 机制提升传输能力。

判断是否使用 CAN FD，不能只问“能不能发 64 Byte”，而要同时回答四个问题：业务数据是否需要它？全网节点是否兼容？物理网络是否能承受目标数据位速率？模型、DBC/AUTOSAR、驱动与 HIL 是否能够一起验证？四个问题都闭合，CAN FD 才会成为可控的工程升级，而不是后期排查错误帧的起点。

参考资料

1. ISO 11898-1:2024 - Controller area network (CAN), data link layer and physical coding sublayer
2. CAN in Automation (CiA)：CAN FD - The basic idea
3. Bosch：CAN FD Protocol