原文：https://www.canfd.net/canfd.html

1 引入与背景

  • 传统CAN每帧仅能传输0–8 字节，最高1 Mb/s，随着ECU数量和总线报文量增长，带宽不足。

  • CAN FD（Flexible Data‑rate）在保留1 Mb/s仲裁段的同时，数据段最高可达8 Mb/s，数据域扩展至0–64 字节；硬件改动仅需控制器与收发器支持FD功能，无需更改线束或拓扑。

2 消息帧结构

  1. 帧类型

    1. 标准帧（11 位ID）与扩展帧（29 位ID）；取消远程帧，RRS位仅作保留。

  2. 关键字段

    1. FDF（1 bit）：0=传统CAN，1=CAN FD。

    2. BRS（1 bit）：位速率切换；1时切换至高速数据段。

    3. ESI（1 bit）：错误状态指示；0=主动错误，1=被动错误。

    4. DLC（4 bit）：0–8对应0–8 字节；9–15分别对应12、16、20、24、32、48、64 字节。

  3. 字段顺序 SOF → 仲裁域 → 控制域 → 数据域 → CRC域（含Stuff Count与CRC序列）→ ACK域 → EOF。

报文（Message）与帧（Frame）的对应

在 CAN 网络中，每一次帧（Frame）的发送即是一条报文（Message）的广播。

  • 帧结构：每帧包含起始位、仲裁域（ID）、控制域（DLC）、数据域、CRC、ACK、结束位等字段，用于完整地封装一次传输请求与其载荷。

  • 一一对应：节点发出一帧就等同于在总线上广播一条报文，周边所有节点都能“监听”到并根据 ID 决定是否接收处理。

报文如静帧 将每条报文（帧）比作一张画——它在时间点𝑡ₙ完整地“定格”了车辆总线上一次通信的状态（ID、数据、时间戳等）。

CAN 回放如视频 当我们把若干报文按时间顺序记录到 BLF、MF4、CSV 等文件中，再以原始时间间隔（或等比例速率）重放这些记录，就如同把一张张静帧组成连续动画。

  • 时序还原：回放工具会严格重现各帧的时间戳间隔及总线速率，保证下游 ECU 或仿真环境感知到的通信节奏与真实现场一致。

  • 顺序一致：保持记录中帧的先后顺序，确保通信逻辑和应答流程无偏差。

小结：

  • 报文＝一帧＝一张静态“画面”

  • 回放＝重放帧序与时间＝把一帧帧“画”接成连续“动画”

  • 严格还原时间戳与总线速率，是确保回放有效性的关键。

3 位填充与CRC

  • 位填充

    • SOF至Data Field：任5位同极性插入1位反向填充；

    • CRC域：固定位置填充，每4位后插入1位。

  • CRC

    • 数据≤16 字节用17 位CRC（多项式x¹⁷+x¹⁶+x¹⁴+…+1），>16 字节用21 位CRC（多项式x²¹+x²⁰+…+1），均包含填充位信息。

  • Stuff Count

    • 4 bit，SOF至Data Field填充位数（mod 8），Gray编码＋奇偶校验。

4 与传统CAN的区别

项目

传统CAN

CAN FD

最高速率

1 Mb/s

仲裁段1 Mb/s，数据段最高8 Mb/s

数据长度

0–8 字节

0–64 字节

远程帧支持

支持

取消

速率切换

不支持

通过BRS位分离仲裁与数据阶段速率

5 控制器收发流程

  1. 初始化

    1. 开启FD模式，设置仲裁域波特率（如500 kbps）、数据域波特率（如2 Mbps），配置最大Payload（8/16/32/64 字节）。

  2. 发送

    1. 建立周期调度（示例100 ms），选择对应Payload子库（如Max16Bytes）发送模块，设置ID、帧类型、DLC、数据域。

  3. 接收

    1. 周期或轮询方式，通过ID过滤从指定缓存区获取FD帧；FD节点亦可收发传统CAN帧。

  4. 通信演示

    1. 使用ZCANPRO等工具与控制器互发（如ID0x41⇄0x42），正常收发。

6 兼容性

  • ISO vs non‑ISO CAN FD

    • 2012年前后出现的non‑ISO产品与2015年ISO 11898‑1:2015标准产品在填充计数与CRC算法上不兼容，需软件模式切换。

  • 与传统CAN共存

    • FD节点可双向收发传统CAN帧；传统节点无法解析FD帧，可能产生错误帧，推荐分网通过网关互联。

7 报文与信号

在 CAN 网络中，通信的基本单位是“报文（Message / Frame）”，每个报文通过唯一的 ID 被识别和过滤。而“信号（Signal）”则是嵌套在报文中的实际数据字段，表示速度、转向角、状态量等具体含义。

7.1 信号依赖报文而存在

  • 所有信号必须依附于某个报文中存在，DBC 文件中对每个信号都规定了其所属报文、起始位、长度、缩放因子等属性；

  • 一个信号在整个网络中只能归属于一个报文，不能跨报文复用；

  • 这保证了数据结构的唯一性和一致性，防止信号源头混乱导致的解析歧义。

7.2 CAN 是报文级广播机制

CAN 总线采用 广播通信模型，即所有报文都会被发送到总线上，所有 ECU 都可以接收这些报文，但会根据报文 ID 决定是否处理。

  • ECU 不是“点对点”请求某个信号，而是监听特定报文 ID；

  • 模块之间共享数据，是通过监听相同的报文，而非复制相同的信号实现的。

✅ 一句话总结： “需要同一个数据的模块，应该接收同一个报文，而不是企图复制同一个信号。”

7.3 报文与信号的类比：公交与乘客

你可以将报文理解为一辆公交车，信号是车上的乘客：

  • 🚌 报文 = 公交车

  • 🧍♂️ 信号 = 车上的人（具体信息）

如果你想获取轮速、加速度这些数据（乘客），你就得上那辆专门承载这些乘客的车（报文）。不是每个 ECU 都能为所欲为叫一辆专属的“滴滴”，那样会导致网络冗余、带宽浪费甚至信息冲突。

7.4 为什么 DBC 不允许“信号复用”

从设计原则上讲，DBC 强制每个信号只能属于一个报文，主要基于以下原因：

  • ✅ 唯一性：每个信号有唯一位置、唯一含义，避免解析冲突；

  • ✅ 节省带宽：避免重复发送相同内容的冗余报文；

  • ✅ 统一数据源：数据一致性高，不会出现“同一信号多个版本”的扯皮现象；

  • ✅ 解析高效：上层工具（如 CANoe、CANape、TSMaster）能够准确、高效解析数据流。

🧠 打个比方： 报文就是广播电台的频道，信号就是广播内容。谁想听哪条内容，就去调到那个频道收听，而不是每人开个电台重复播放。

7.5 实际工程处理方式

当多个 ECU 需要同一信号时，通常有以下处理策略：

方式

说明

✅ 统一监听

所有接收方监听同一个报文，从中解析出目标信号

✅ 中间件转发

某个 ECU 接收到报文后，将关键信号提取并打包转发

✅ CAN 网关桥接

跨总线的信号由 CAN 网关统一管理转发

❌ 信号复制定义

同一信号出现在多个报文中，会破坏一致性，不推荐

✅ 小结

CAN 网络的本质是广播报文，而不是按需投喂信号。设计良好的 DBC 文件应确保每个信号归属明确、报文划分合理、数据分发统一。只有这样，各 ECU 才能各取所需、运行稳定，避免“各自为政、满网撒鸡”。