4. 车载以太网基础：物理层与协议栈概览
好，我们正式开始聊车载以太网。说实话，很多工程师一听到「以太网」三个字，脑子里蹦出来的就是办公室里的 RJ45 网线。但车上的以太网，跟那个完全是两码事。我最早接触车载以太网是在一个 ADAS 项目上，当时被要求用一根非屏蔽双绞线跑 100Mbps，我心里直打鼓——这能行吗？后来才发现，是我多虑了。
4.1 车载以太网物理层：100BASE-T1 与 1000BASE-T1
车载以太网物理层最核心的区别，就是它只用一对双绞线。你想想看，传统以太网至少需要两对线（100BASE-TX）甚至四对线（1000BASE-T），这在车上根本行不通——线束重量和成本都受不了。
核心差异速览
| 特性 | 100BASE-T1 | 1000BASE-T1 |
|---|---|---|
| 速率 | 100 Mbps | 1 Gbps |
| 线对数量 | 1 对 | 1 对 |
| 最大传输距离 | 15 m | 15 m |
| 编码方式 | PAM3 | PAM3 |
| 典型应用 | 诊断、OTA、控制 | 摄像头、激光雷达 |
100BASE-T1 用的是 PAM3 编码，说白了就是通过三电平信号来传输数据。为什么不用传统的 NRZ？因为单对线既要传数据又要传时钟，还得对抗车上的电磁干扰，PAM3 在信噪比和带宽之间找到了一个平衡点。
我记得第一次用示波器看 100BASE-T1 的波形时，差点以为自己接错了——信号幅度只有 1V 左右，比传统以太网的 2.5V 小多了。但正是这种低摆幅设计，让它的电磁辐射大幅降低，才能通过车规级的 EMC 测试。
我的经验：100BASE-T1 的共模扼流圈（CMC）选型很关键。我曾经在一个项目中用了便宜的 CMC，结果辐射超标 6dB，最后换了 TDK 的专用型号才过。别在这上面省钱。
1000BASE-T1 呢？它把速率提到了 1Gbps，但依然只用一对线。怎么做到的？PAM3 的符号率从 66.7 MBaud 提升到了 750 MBaud，同时引入了更复杂的回声抵消和均衡算法。说实话，这玩意儿对 PCB 走线的要求极高——差分对阻抗必须控制在 100Ω ±5%，等长误差不能超过 5mm。
4.2 车载以太网协议栈概览
物理层搞定了，数据怎么往上走？这就得聊协议栈了。车载以太网的协议栈跟 IT 以太网很像，但多了几个车规级的专用协议。
4.3 TCP/IP 协议栈在车上的适配
TCP/IP 大家都熟，但车上用 TCP/IP 有几个坑。我一个个说。
- TCP 的拥塞控制：车上网络拓扑相对固定，带宽也有限，传统的慢启动和拥塞避免反而会引入不必要的延迟。我建议在车内通信中禁用 TCP 的 Nagle 算法，或者直接改用 UDP。
- IPv6 的普及：现在新车基本都要求支持 IPv6，因为地址空间够大，可以给每个 ECU 分配一个全球唯一地址，方便远程诊断和 OTA。
- VLAN 隔离：车上不同域（动力域、车身域、信息娱乐域）必须做 VLAN 隔离，否则一个广播风暴就能让全车网络瘫痪。我见过一个项目，就是因为没配 VLAN，摄像头数据流把 CAN 网关的 CPU 占满了。
注意：车载以太网的 MTU 通常设置为 1500 字节，但如果你跑 SOME/IP 的序列化数据，建议把 MTU 调到 9000 字节（巨帧），能显著降低 CPU 开销。前提是你的交换机支持。
4.4 SOME/IP：面向服务的通信
SOME/IP（Scalable service-Oriented MiddlewarE over IP）是车载以太网的核心中间件。它把传统的信号通信变成了服务调用。你想想看，以前 CAN 上你要读一个车速，得先定义好 DBC 里的信号 ID，然后周期性地发。现在 SOME/IP 里，你只需要调用一个 getVehicleSpeed() 方法，服务端就会返回结果。
SOME/IP 有两种通信模式：
| 模式 | 说明 | 适用场景 |
|---|---|---|
| Request/Response | 客户端发送请求，服务端回复 | 诊断、配置读取 |
| Fire & Forget | 客户端发送请求，不等待回复 | 事件通知、状态更新 |
| Notification | 服务端主动推送数据 | 传感器数据、报警 |
我个人习惯在 SOME/IP 的接口设计里，把频繁变化的数据（比如车速、转速）做成 Notification 模式，把偶尔读取的数据（比如 VIN 码、软件版本）做成 Request/Response。这样能大幅减少总线负载。
避坑指南：我曾经在一个项目中，把所有的服务都设计成了 Request/Response，结果网关 CPU 负载飙到 80%。后来改成 Notification 模式，负载直接降到 15%。记住，能推就别拉。
4.5 DoIP：基于 IP 的诊断
DoIP（Diagnostics over IP）是 UDS 在以太网上的实现。它把传统的 CAN 诊断（ISO 14229-1）搬到了 TCP/IP 上。好处很明显：带宽大、速度快、支持并行诊断。
DoIP 的典型流程是这样的：
- 车辆发现：诊断仪发送广播请求，车辆回复自己的 IP 地址和 VIN。
- 路由激活：诊断仪发送路由激活请求，车辆分配一个逻辑地址。
- 诊断通信：双方通过 TCP 连接传输 UDS 报文。
- 连接关闭：诊断结束，关闭 TCP 连接。
DoIP 的报文格式比 CAN 诊断复杂一些，但核心还是 UDS 那套服务。比如 0x22（读取数据）、0x2E（写入数据）、0x10（诊断会话控制）。
// DoIP 报文头部结构（简化版）
// 字节 0-1: 协议版本 (0x02)
// 字节 2-3: 报文类型 (0x8001 = 诊断请求)
// 字节 4-7: 报文长度 (N)
// 字节 8-N: UDS 诊断数据
// 示例：读取 VIN 码的 DoIP 请求
02 80 01 00 00 00 03 // 头部
22 F1 90 // UDS: 读取 VIN (0x22, DID = 0xF190)
注意：DoIP 的 TCP 端口固定为 13400，UDP 端口用于车辆发现。如果你在网关里做路由，一定要把 DoIP 的 TCP 连接超时设得长一点（至少 30 秒），否则诊断仪还没读完数据，连接就被网关掐断了。
4.6 小结
车载以太网物理层用单对双绞线解决了线束重量和 EMC 问题，100BASE-T1 和 1000BASE-T1 分别覆盖了不同的速率需求。协议栈在传统 TCP/IP 基础上，增加了 SOME/IP 做服务化通信，DoIP 做远程诊断。这些协议不是孤立的——物理层提供通道，协议栈提供语义，两者配合才能让车载网络真正跑起来。