4. CANFD网络层：网络管理机制、诊断协议与信号路由
好，咱们进入CANFD网络层这个核心话题。说实话，很多工程师做CANFD项目时，往往只关注物理层和数据链路层——波特率配好了、报文能发了，就觉得完事了。但真正让系统稳定运行的，其实是网络层这套看不见的机制。
我个人习惯把网络层比作「交通调度中心」。你想想看，车上几十个ECU同时发消息，谁先谁后？谁该睡觉谁该工作？出了问题怎么查？这些都得靠网络层来管。
4.1 网络管理机制：让ECU学会「作息规律」
网络管理，说白了就是让各个ECU知道什么时候该干活，什么时候该休息。我见过不少项目，ECU之间互相唤醒，结果整车静态电流超标，电瓶两天就亏空了。嗯，这就是网络管理没做好。
CANFD的网络管理，主流有两种模式：
- OSEK直接网络管理：基于令牌环，每个节点轮流发管理报文。优点是确定性好，缺点是复杂。
- AUTOSAR网络管理：基于分布式策略，每个节点独立决定睡眠/唤醒。现在用得最多。
我重点说说AUTOSAR这套。它的核心逻辑其实很简单——每个ECU都会周期性地发送一个「我还活着」的报文，叫NM报文。如果某个ECU发现其他节点都不发了，它就知道：嗯，大家都想睡了，那我也睡吧。
关键状态机：
- Bus-Sleep模式：ECU完全休眠，只监听唤醒信号
- Prepare Bus-Sleep模式：准备休眠，等待其他节点确认
- Network模式：正常工作，收发报文
我在项目中遇到过一个问题：某个ECU的NM报文周期设置得太短，结果网络一直处于活跃状态，根本睡不下去。后来我把周期从100ms改成了500ms，配合一个「空闲计数器」，问题就解决了。
避坑指南：我曾经在某个量产项目里，发现两个ECU的NM报文ID冲突了。结果一个ECU发「我要睡」，另一个ECU收到后以为是自己的报文，也跟着睡了。整车在高速上突然黑屏...嗯，从那以后我要求所有NM报文ID必须在设计阶段统一登记，谁都不许私自改。
4.2 诊断协议（UDS on CANFD）：给ECU做「体检」
UDS（统一诊断服务）是车载诊断的通用语言。在CANFD上跑UDS，和传统CAN相比，最大的优势就是——快。CANFD的数据场可以到64字节，一个诊断请求可能一个报文就搞定了，不用像传统CAN那样拆成好几个。
UDS on CANFD的报文结构是这样的：
CANFD帧格式：
| CAN-ID | DLC | 数据场（最多64字节） |
| 0x7DF | 0x08 | [服务ID] [子功能] [数据...] |
常见的诊断服务：
- 0x10：诊断会话控制（默认/扩展/编程）
- 0x22：读取数据标识符
- 0x2E：写入数据标识符
- 0x31：例程控制
- 0x19：读取故障码
我个人习惯把诊断会话分成三个等级：
| 会话等级 | 服务ID | 说明 | 我常用的场景 |
|---|---|---|---|
| 默认会话 | 0x10 0x01 | 基本诊断功能 | 读取VIN码、版本号 |
| 扩展会话 | 0x10 0x03 | 允许写入操作 | 刷写配置参数 |
| 编程会话 | 0x10 0x02 | 允许刷写固件 | OTA升级 |
这里有个容易踩的坑——CANFD的传输层和传统CAN不一样。传统CAN用ISO 15765-2，CANFD用ISO 15765-2的扩展版本。说白了，就是CANFD支持更大的数据包，但分段和重组逻辑要重新适配。
注意：我曾经在调试一个诊断刷写功能时，发现ECU总是回复「请求超出范围」。查了两天才发现，原来是CANFD的DLC编码方式搞错了。传统CAN的DLC是4位，CANFD的DLC也是4位，但含义不同——CANFD的DLC可以表示0-15，但实际数据长度可以到64字节。很多芯片的CANFD控制器需要你手动设置数据长度，而不是直接填DLC。
4.3 多路复用与信号路由：让信号「搭便车」
多路复用，说白了就是一个报文里塞多个信号，通过不同的「模式」来切换。你想想看，如果每个信号都单独发一个报文，CANFD的带宽再大也不够用。
我常用的多路复用方式有两种：
- 静态多路复用：信号位置固定，比如Byte0永远是车速，Byte1永远是转速。简单，但浪费带宽。
- 动态多路复用：通过一个「模式位」来切换信号布局。比如模式0时Byte0是车速，模式1时Byte0是方向盘转角。
动态多路复用的典型结构：
CANFD报文（64字节）：
| Byte0: 模式标识 | Byte1-63: 信号数据 |
模式0（常规模式）：
Byte1-2: 车速
Byte3-4: 发动机转速
Byte5-6: 冷却液温度
模式1（诊断模式）：
Byte1-4: 故障码1
Byte5-8: 故障码2
Byte9-12: 故障码3
信号路由呢，就是网关干的活了。CANFD网关收到一个报文，根据路由表决定：这个信号要不要转发到另一个CANFD网络？要不要转成以太网？
我在项目中遇到过最头疼的问题——信号路由延迟。一个信号从CANFD1进来，经过网关处理，再发到CANFD2，如果网关处理不过来，延迟就会累积。特别是做ADAS系统时，摄像头数据延迟超过10ms，整个控制逻辑就乱套了。
我的经验：做信号路由设计时，一定要先做「带宽预算」。把每个CANFD网络的负载率算清楚，一般建议不超过50%。网关的处理能力也要留余量，我通常按峰值负载的1.5倍来选型。另外，关键信号（比如刹车、转向）要走独立的路由通道，别和普通信号混在一起。
嗯，说到这，我想起一个具体的案例。有个项目，CANFD1和CANFD2之间需要转发100多个信号。一开始设计成每个信号单独路由，结果网关CPU占用率直接飙到90%。后来我改成「批量路由」——把同一周期的信号打包成一个报文转发，CPU占用率降到了30%。
说白了，多路复用和信号路由的核心思想就一句话：能用一条路走完的，别绕弯子；能一个报文搞定的，别拆成多个。
最后总结一下：CANFD网络层的这三个方面——网络管理、诊断协议、信号路由——是决定系统稳定性的关键。网络管理管的是「什么时候干活」，诊断协议管的是「出了问题怎么查」，信号路由管的是「数据怎么走」。三者缺一不可。
我个人建议，做CANFD项目时，先把网络管理策略定下来，再设计诊断方案，最后做信号路由。这个顺序能帮你少走很多弯路。