3. 通讯链路建立：CAN/CANFD网络拓扑确认、DBC文件加载、报文监控

通讯链路，说白了就是线控转向系统的「神经系统」。

方向盘和转向执行器之间没有机械连接，全靠这根「神经」传递指令。如果链路断了，或者信号乱了，后果你懂的。我参与的第一个线控项目，就因为在CAN网络拓扑上偷了个懒，结果路试时方向盘突然「失联」——嗯，那感觉，至今难忘。

3.1 网络拓扑确认：别让节点「打架」

拿到实车后，第一件事不是上电，而是确认CAN/CANFD网络拓扑。我习惯先做三件事：

• 核对节点清单：方向盘控制器（SWC）、转向执行控制器（SAC）、整车域控（VDC）、网关（GW）——这些节点必须在同一网段，或者通过网关正确路由。
• 检查终端电阻：CAN总线两端必须有120Ω电阻。我遇到过一台车，怎么都连不上，最后发现终端电阻被前一个工程师拆了忘了装。
• 确认波特率：CAN通常500kbps，CANFD可以到2Mbps甚至更高。波特率不一致，节点之间就是「鸡同鸭讲」。

我曾经在一个项目中，发现SWC和SAC之间只有一条CAN线。问设计团队为什么不做冗余？答曰「成本考虑」。结果路试时一根线被磨破，方向盘直接锁死——嗯，后来他们改了。

3.2 DBC文件加载：把「二进制」翻译成「人话」

CAN总线上跑的都是二进制数据。0x183F4A20，你看着头大，但ECU知道这是「方向盘转角 45.2°」。DBC文件就是这本「翻译词典」。

加载DBC时，我建议按以下步骤来：

1. 确认DBC版本：和供应商对一下版本号。我见过最离谱的事，是用了上一版的DBC，结果把「转向扭矩请求」解析成了「车速信号」——车直接冲了出去。
2. 检查信号定义：重点关注起始位、长度、精度、偏移量。举个例子，方向盘转角信号，如果精度是0.1°，那原始值1000就代表100.0°。偏移量如果是-780，那原始值0代表-78.0°。
3. 验证校验和与计数器：线控转向的报文通常有CRC和Rolling Counter。如果DBC里没定义这两个信号，那这个DBC八成是半成品。

你想想看，如果DBC错了，后面所有的调试都是白费功夫。我习惯在加载后，把关键信号打印出来，和供应商提供的文档逐条核对。虽然麻烦，但值得。

3.3 报文监控：看「心跳」、抓「异常」

通讯链路建好、DBC加载完毕，接下来就是监控报文了。说白了，就是看总线上的数据「正不正常」。

我一般分三步走：

• 看心跳报文：每个节点都会周期性发送心跳（Heartbeat），比如SWC每10ms发一次。如果某个节点的心跳丢了，说明它「死」了或者被踢出总线了。
• 看应用报文：比如方向盘转角、转速、扭矩请求。这些报文必须满足时序要求——比如转向指令的周期是5ms，如果实际间隔变成10ms，那控制性能会急剧下降。
• 看错误帧：CAN总线上的错误帧（Error Frame）是「噪音」的直接体现。如果错误帧率超过1%，说明物理层有问题——可能是线束屏蔽不良、接地不好，或者节点驱动能力不足。

我记得有一次，监控发现SWC发出的报文偶尔会「丢帧」。查了半天，发现是SWC的MCU负载太高，导致CAN发送中断被延迟了。后来优化了任务调度，问题才解决。你看，有时候问题不在通讯本身，而在源头。

3.4 知识体系：一张图看懂通讯链路建立

下面这张图，是我自己总结的通讯链路建立流程。每次做新项目，我都会对着它走一遍，确保不漏项。

这张图把三个步骤串起来了。你注意看，每一步都有对应的细节检查项。我建议你在实车调试前，把这张图打印出来，每完成一项就打个勾。别嫌麻烦，这能帮你省下后面排查问题的大量时间。

嗯，关于通讯链路建立，我就讲这么多。下一节我们会聊到「转向执行器零点标定」——那又是一个容易踩坑的地方。