在讨论智能驾驶系统时，我们往往把注意力集中在算法模型、算力平台和传感器配置上。但在真实的量产工程中，还有一个同样关键、却经常被低估的基础系统：车载通信网络。
从摄像头采集的原始图像，到智能驾驶域控制器中的感知与决策，再到底盘执行器的实时响应，这一整条链路本质上都是数据在不同控制节点之间流动的过程。通信能力不足，往往不是性能"略差一些"，而是直接限制了系统架构本身能否成立。
一、车载通信为何会成为系统能力的"隐形上限"
在早期汽车电子系统中，一个 ECU 往往只负责一个相对独立的功能模块，传感器与执行器之间通过点对点线束连接即可完成控制任务。这种方式在功能简单、ECU 数量有限时尚可接受。
但随着车辆逐步引入：
- ABS / ESP 等主动安全系统
- 多摄像头、多雷达的 ADAS 功能
- 更复杂的人机交互与联网能力
整车 ECU 数量和信号交互复杂度迅速上升。此时，单纯增加线束已经不再可行，系统开始真正依赖网络化通信来完成跨模块协同。
二、分域架构下的通信组织方式
现代汽车普遍采用分域式 E/E 架构，即按照功能将 ECU 进行逻辑整合，由域控制器统一管理域内通信，并通过网关与其他功能域进行交互。如下图，这里给出一个高level的示意图。说明：中央网关并不一定是真实存在的，或者只是部分网关功能，例如以太网网关，但是对于其他的总线型的也可以是直接相连到总线上。
环境/车辆传感器
智能驾驶域
底盘域
动力域
车身域
座舱域
中央网关
在这种架构下，通信的角色发生了明显变化：
- 域内通信强调实时性与确定性
- 域间通信强调带宽管理与安全隔离
- 网关成为通信调度与策略控制的核心节点
智能驾驶域，正是在这种体系中逐渐演变为整车中数据密度最高、通信要求最复杂的功能域。
三、主流车载通信协议的工程级解析
1️⃣ LIN ------ 最底层的"廉价通信"
-
速率：~20 kbps
-
架构：单主多从
-
使用场景：
- 车窗
- 座椅
- 后视镜
BCM
车窗
座椅
雨刮
2️⃣ CAN / CAN FD ------ 控制系统的"基石"
CAN 的核心价值不是带宽，而是：
- 仲裁机制（优先级）
- 实时性可控
- 极高鲁棒性
| 类型 | 带宽 | 典型用途 |
|---|---|---|
| CAN | 1 Mbps | 传统控制 |
| CAN FD | 2~5 Mbps | 较复杂控制 |
📌 在智驾中常用于：
- ADAS → 底盘控制指令
- 车辆状态信息汇总
3️⃣ FlexRay ------ 强实时系统的"硬核方案"
- 时间触发 + 事件触发
- 支持双通道冗余
- 强确定性
📌 典型应用：
- 线控转向（SBW）
- 线控制动（BBW）
0ms 节点A发送 2ms 节点B发送 4ms 节点C发送 FlexRay 时间触发示意
4️⃣ 车载以太网 ------ 智驾系统的"主干网"
这是智能驾驶真正离不开的通信方式。
| 特性 | 说明 |
|---|---|
| 带宽 | 100M / 1G / 10G |
| 拓扑 | 星型 / 交换式 |
| 协议 | SOME/IP、DDS、TSN |
📌 以太网解决的是：
- "数据是否能送得到"
- 而 CAN / FlexRay 解决的是：
- "控制是否准时发生"
四、智能驾驶系统中的三类典型通信场景
从通信需求的角度拆解智能驾驶系统，其内部的数据流大致可以分为三类，而每一类对通信方式的要求都截然不同。
1. 感知数据通信：带宽驱动型场景
智能驾驶系统需要持续接收来自多种环境感知传感器的数据，包括摄像头、毫米波雷达和激光雷达。这类数据的共同特点是：
- 数据持续输出
- 单位时间内数据量大
- 对吞吐能力高度敏感
摄像头和激光雷达几乎天然依赖车载以太网，但毫米波雷达在工程实现上则更为多样。
在当前量产系统中，毫米波雷达主要存在两种对外通信方式：CAN FD 和 Automotive Ethernet。
- 对于输出目标级信息（Object List）的传统毫米波雷达，单帧数据量相对可控，CAN FD 在带宽、实时性和成本之间取得了较好的平衡，因此成为目前最主流的方案。
- 随着高分辨率毫米波雷达逐步引入点云级或更高维度的数据输出，CAN FD 的带宽开始接近上限，以太网方案在部分高阶智能驾驶系统中开始出现，用于承载更大的数据吞吐需求。
Ethernet
CAN FD
Ethernet
Ethernet
摄像头
毫米波雷达
CAN FD
毫米波雷达
Ethernet
激光雷达
智驾域控制器
在一些架构中，还可以看到毫米波雷达同时保留 CAN FD 用于配置与控制，以太网用于高带宽数据通道的混合设计，这在工程上并不罕见。
2. 决策与控制通信：确定性优先
当智能驾驶域完成感知、预测和决策后，需要向底盘和动力系统下发控制指令，例如：
- 制动减速度请求
- 转向角或转向力矩请求
- 纵向与横向控制目标
这类数据的数据量并不大，但对实时性、抖动和可预测性极为敏感。因此在实际工程中，即使整车已经大量引入以太网，关键控制链路仍然普遍采用 CAN、CAN FD 或 FlexRay。
CAN / FlexRay
智驾域
底盘域 ECU
EPS
制动 ECU
这种设计并不是"保守"，而是源于控制系统对确定性的根本需求。
3. 状态反馈通信：闭环控制的基础
执行器在完成控制动作的同时，需要持续向智能驾驶域反馈实际状态信息，如轮速、转向角、纵向加速度等。这些反馈数据构成了闭环控制的基础，其可靠性直接关系到系统稳定性和安全性。
在工程实践中，这部分通信通常与控制指令共用同一类总线，以减少系统复杂度和时序不确定性。
五、多种通信协议长期共存的工程逻辑
一个在工程上非常现实的结论是：
不存在一种通信协议，可以同时满足成本、带宽、实时性和安全性的全部要求。
因此，现代汽车的通信系统天然是一个多协议协同的体系：
- LIN 用于低成本、低速的车身控制
- CAN / CAN FD 用于可靠、确定的控制通信
- FlexRay 用于高安全等级的实时系统
- Automotive Ethernet 用于高带宽数据主干
这些协议并不是相互替代，而是各自在合适的位置发挥作用。
六、从通信视角重新理解智能驾驶系统
当我们从通信角度重新审视智能驾驶系统，会发现它本质上是一个建立在复杂车载网络之上的分布式实时系统。算法能力、算力平台和传感器配置，最终都必须运行在通信系统所允许的边界之内。
这也是为什么在真实工程中，通信架构设计往往需要与算法和控制策略同步推进，而不是事后补救。
结语
智能驾驶系统的复杂性，并不仅来自模型和算力，更来自隐藏在车身内部、看不见却无处不在的通信网络。理解这些通信方式的角色与边界，是理解现代汽车 E/E 架构和智能驾驶系统的必经之路。