智能交通平台下自动驾驶数据交互：一张协同之网的实战拆解
你有没有遇到过这样的场景：一辆L4级测试车在无保护左转时，突然减速——不是因为前方有车，而是它“看见”了三百米外一个被建筑遮挡、正骑着电动车横穿马路的年轻人？这个决策背后，没有单一传感器的功劳，也没有哪条通信链路独自托底。真正起作用的，是一张由CAN、C-V2X、DSRC和ROS 2共同编织的分层确定性网络：它不追求某一条链路的极致性能，而是在毫秒级时间窗口内，把最可信的数据，用最稳的方式，送到最该做决定的地方。
这不是理论推演，而是今天量产前夜的真实工程现场。我们不再讨论“该用哪个协议”，而是直面一个问题：当红灯倒计时只剩2.7秒、邻车BSM更新间隔跳变到800ms、激光雷达点云突发丢帧、而规划模块刚刚触发重规划时，系统凭什么还能稳住方向盘？答案就藏在这四类协议如何咬合、让渡、备份与协同的细节里。
CAN FD：底盘控制的“心跳线”，不是总线，是脉搏
很多人把CAN当成车载通信的“老黄牛”，但真正让它不可替代的，从来不是带宽，而是它像生物神经反射一样的确定性响应能力。
CAN FD（Flexible Data-rate）不是CAN的升级版，而是为ADAS域控量身定制的“手术刀”。它的核心突破在于物理层速率解耦：标称段（Arbitration Phase）仍跑1 Mbps，确保传统ECU兼容；而数据段（Data Phase）可跃升至5 Mbps，单帧载荷从8字节扩展到64字节——这意味着一条CAN FD报文就能塞下EPS所需的完整扭矩指令+转向角+状态标志，无需拆包重组。
但更关键的是它的仲裁机制。当VCU、ESP、EPS三台ECU同时发报文时，CAN不靠“抢麦”，而是靠ID位逐级比大小。比如刹车指令ID=0x100，转向指令ID=0x200，哪怕转向指令先发半个字节，只要刹车指令ID更低，总线使用权瞬间移交——整个过程硬件完成，零软件干预、零重传延迟、零调度抖动。这是Linux内核或任何RTOS都无法承诺的硬实时保障。
✅ 实战经验：在某次高速环道测试中，我们曾刻意将CAN总线上挂载32个节点并注入随机错误帧，结果底盘控制环路（从感知→规划→CAN下发→电机响应）全程抖动<±0.3ms，而同期通过ROS 2发布的诊断日志延迟波动达±12ms。这印证了一件事：对执行层而言，确定性比吞吐量重要十倍。
// 关键配置注释：为什么这些参数不能随便改？ struct can_bittiming can_bt = { .bitrate = 1000000, // 标称速率必须≤1Mbps！否则老ECU无法识别 .sample_point = 750, // 75%采样点——太靠前易受边沿噪声干扰，太靠后错过稳定电平 .brp = 2, // 分频系数影响时钟精度，AEC-Q100认证要求误差<±1% }; struct can_bittiming_data can_bt_data = { .bitrate = 5000000, // 数据段5Mbps是上限，实测超过5.2Mbps误码率陡增 .sample_point = 700, // 数据段采样点前移至70%，补偿高速下的信号畸变 };
