2. 车云通信基础
做车联网，第一关就是搞懂车上的网络。很多人觉得这是硬件工程师的事，其实不然。你设计的通信协议最终要跑在CAN总线上，或者通过车载以太网传到T-Box。不懂底层网络，协议调优就是空中楼阁。
我个人习惯，先看物理层再看协议层。车上的网络环境跟IT机房完全不同——温度高、震动大、电磁干扰强。嗯，咱们先从最经典的CAN总线说起。
2.1 CAN总线基础
CAN（Controller Area Network）是博世在80年代开发的。到现在快40年了，依然是车载网络的中流砥柱。为什么？因为它可靠、实时、成本低。
核心要点：CAN总线是差分信号传输，两条线（CAN_H和CAN_L）绞在一起。这种设计抗干扰能力极强。我在项目中遇到过，某次EMC测试不过，最后发现是CAN线双绞节距不对，调整后直接通过。
2.1.1 CAN的帧结构
CAN有四种帧：数据帧、远程帧、错误帧、过载帧。我们最常用的是数据帧。标准CAN（2.0A）是11位ID，扩展CAN（2.0B）是29位ID。
| 字段 | 长度 | 说明 |
|---|---|---|
| SOF | 1 bit | 帧起始，同步信号 |
| ID | 11/29 bit | 标识符，决定优先级 |
| RTR | 1 bit | 远程帧标志 |
| DLC | 4 bit | 数据长度，0-8字节 |
| Data | 0-64 bit | 实际数据 |
| CRC | 15 bit | 循环冗余校验 |
| ACK | 2 bit | 应答槽 |
| EOF | 7 bit | 帧结束 |
你想想看，一帧最多8字节数据。这就是为什么车云通信要做数据压缩和聚合。我曾经见过一个项目，把10个传感器信号塞进一帧CAN报文里，位域用得那叫一个精细。
2.1.2 CAN的仲裁机制
CAN总线是多主架构。多个节点同时发送时，ID小的优先。这是通过“线与”逻辑实现的——显性位（0）覆盖隐性位（1）。
避坑指南：我曾经在项目里把两个ECU的CAN ID设反了。结果高优先级的报文一直抢不到总线，导致某个关键信号延迟超过50ms。整车厂直接打回。记住：ID越小优先级越高，0是最高优先级。
2.1.3 CAN的速率与距离
CAN的速率跟总线长度成反比。标准CAN最高1Mbps，但长度限制在40米以内。车上一般用250kbps或500kbps。
- 125kbps：车身控制（门窗、灯光），总线长度可达500米
- 250kbps：舒适系统（空调、座椅），常用速率
- 500kbps：动力系统（发动机、变速箱），长度约100米
- 1Mbps：高速控制，长度不超过40米
为什么速率上不去？因为CAN是事件触发型，所有节点共享总线。速率高了，信号反射和衰减就严重。说白了，这是物理层的硬约束。
2.2 车载以太网入门
CAN总线虽然可靠，但带宽太低了。8字节一帧，1Mbps封顶。现在车上摄像头、雷达、激光雷达的数据量动辄几百Mbps。怎么办？上以太网。
车载以太网跟IT以太网不太一样。它用的是单对非屏蔽双绞线（UTP），而不是标准的四对线。这样能减重、降成本。标准是IEEE 802.3bw（100BASE-T1）和802.3bp（1000BASE-T1）。
关键区别：车载以太网是点对点连接，不像CAN那样挂总线。每个节点通过交换机互联。这带来了更高的带宽和更低的延迟，但也意味着拓扑更复杂。
2.2.1 车载以太网的分层架构
车载以太网遵循OSI模型，但做了不少裁剪。我重点说几个跟车云通信相关的层：
| OSI层 | 车载以太网实现 | 说明 |
|---|---|---|
| 应用层 | SOME/IP, DDS, HTTP | 服务发现、远程过程调用 |
| 传输层 | TCP, UDP | 可靠/不可靠传输 |
| 网络层 | IPv4/IPv6 | 地址分配、路由 |
| 数据链路层 | 802.1Q (VLAN), 802.1AS (时间同步) | 优先级、时钟同步 |
| 物理层 | 100BASE-T1, 1000BASE-T1 | 单对线、PHY芯片 |
我个人最关注的是SOME/IP。它是Scalable service-Oriented MiddlewarE over IP的缩写。说白了，就是让ECU之间能像微服务一样互相调用。这在车云通信里特别有用——云端可以直接调用车上的服务接口。
2.2.2 时间敏感网络（TSN）
车载以太网要解决一个核心问题：实时性。普通以太网是“尽力而为”的，但车上有些信号必须准时到达。比如刹车信号，延迟超过10ms就可能出事故。
TSN是一组IEEE 802.1标准，包括：
- 802.1AS：时钟同步，精度可达微秒级
- 802.1Qbv：时间感知整形，给关键流量预留时间槽
- 802.1Qci：流过滤和监管，防止异常流量冲击
注意：TSN不是开箱即用的。你需要配置时钟域、门控列表、流过滤规则。我曾经在一个ADAS项目里，因为TSN配置错误，导致摄像头数据流和雷达数据流在交换机里冲突，整个感知系统卡死。排查了三天才找到原因。
2.3 车载网络拓扑结构
了解了CAN和以太网，咱们看看它们怎么连在一起。车载网络拓扑经历了三代演变。
2.3.1 传统拓扑：CAN总线为主
早期车辆以CAN总线为核心，所有ECU挂在一两条总线上。典型结构：
- 动力CAN：发动机、变速箱、ABS，速率500kbps
- 车身CAN：门窗、灯光、座椅，速率125kbps
- 诊断CAN：OBD接口，速率250kbps
这种拓扑简单，但问题也很明显：所有节点共享带宽，一个节点出问题可能拖垮整条总线。
2.3.2 域控制器架构
现在主流是域控制器架构。把车辆功能分成几个域：
| 域 | 包含ECU | 网络类型 |
|---|---|---|
| 动力域 | 发动机、变速箱、电池管理 | CAN FD / 以太网 |
| 底盘域 | ABS、ESP、转向 | CAN FD |
| 车身域 | 门窗、灯光、空调 | CAN / LIN |
| 信息娱乐域 | 导航、音响、仪表 | 以太网 |
| ADAS域 | 摄像头、雷达、激光雷达 | 以太网 |
每个域有一个域控制器（DCU），负责域内ECU的管理和跨域通信。域控制器之间通过车载以太网互联。
2.3.3 中央计算平台架构
这是未来的趋势。一个或两个中央计算平台（如NVIDIA Orin、高通Snapdragon Ride）接管所有计算任务。传感器只负责采集数据，通过以太网传给中央平台。
这种架构的好处是算力集中、软件升级方便。但挑战也大：中央平台一旦挂了，全车瘫痪。所以必须有冗余设计。
经验之谈：我在设计中央计算平台网络时，用了双冗余以太网。主链路和备份链路同时运行，故障切换时间控制在5ms以内。这个指标是通过802.1AS时间同步和802.1Qbv门控调度实现的。
2.4 本章知识体系
下面这张图总结了车载网络的整体结构。你可以看到CAN总线和以太网如何共存，以及它们各自的位置。
从这张图你能看到，车载网络是一个分层结构。底层是CAN/LIN总线，负责实时控制；中层是域控制器，做协议转换和数据聚合；上层是中央计算平台和T-Box，负责跨域协同和车云通信。
搞懂了这些，你才能设计出合理的车云通信协议。比如，哪些信号走CAN，哪些走以太网？数据在域控制器里怎么聚合？T-Box怎么跟云端同步？这些问题的答案，都藏在车载网络的基础里。