3. 车载以太网基础：物理层、TCP/IP协议栈、SOME/IP与DoIP
各位同学，今天我们聊聊车载以太网的基础。说实话，我刚从CAN转到以太网时，心里是有点发怵的。CAN多简单啊，一根线，几个节点，报文发出去就完事了。以太网呢？七层模型、IP地址、端口号、还有一堆我看不懂的协议缩写。但干久了你会发现，其实核心逻辑没变——还是那套“谁跟谁说话，说什么，怎么说”的老规矩。
3.1 以太网物理层：线缆与信号
车载以太网和咱们办公室用的以太网不太一样。办公室用的是RJ45接口，四对差分线。车上呢？空间有限，线束越少越好。所以车载以太网物理层，主流是BroadR-Reach技术，后来标准化成了100BASE-T1和1000BASE-T1。
说白了，就是一对双绞线搞定收发。你想想看，一对线既要发又要收，怎么做到的？靠的是回声消除技术。嗯，这里要注意，这个技术对线缆质量要求很高。我在项目中遇到过，某次台架测试，以太网老是丢包，查了半天，结果是线束供应商用了劣质双绞线，绞距不对。换线后，问题立刻消失。
| 特性 | 100BASE-T1 | 1000BASE-T1 |
|---|---|---|
| 速率 | 100 Mbps | 1 Gbps |
| 线对 | 1对 | 1对 |
| 最大距离 | 15米 | 15米 |
| 典型应用 | 诊断、OTA | 摄像头、ADAS |
我个人习惯，在项目初期就会跟硬件团队确认：MDI（Medium Dependent Interface）的共模扼流圈选型对不对。这个细节很多人忽略，但直接影响EMC性能。你想想看，车上那么多电机、继电器，干扰大得很，物理层扛不住，上层协议再牛也白搭。
3.2 TCP/IP协议栈：车载的“普通话”
以太网物理层铺好了，接下来就是怎么组织数据。TCP/IP协议栈，说白了就是一套分层的通信规则。车载领域，我们最关心的是IPv4、UDP、TCP这三层。
为什么不是IPv6？嗯，目前量产车还是IPv4为主。虽然IPv6地址多，但车载网络规模小，IPv4够用。我建议你先把IPv4搞透，IPv6等需要时再补。
这里有个坑，我必须要说。车载以太网的DoIP和SOME/IP，底层走的是UDP还是TCP？很多人搞混。我的经验是：
- SOME/IP：主要走UDP。因为要快，要实时。控制信号、传感器数据，丢一两个包没关系，但延迟必须低。
- DoIP：诊断数据走TCP。因为诊断要求可靠，不能丢包。你想想看，刷写ECU时丢一个包，ECU就变砖了，谁敢用UDP？
3.3 SOME/IP协议：面向服务的通信
SOME/IP，全称Scalable service-Oriented MiddlewarE over IP。名字很长，但核心思想很简单：把ECU的功能封装成“服务”。
以前CAN通信，我们定义ID、信号、周期。现在SOME/IP呢？定义的是Service、Method、Event、Field。举个例子：
- Service：车窗控制服务
- Method：调用“打开车窗”方法（请求-响应模式）
- Event：车窗状态变化时，主动通知（发布-订阅模式）
- Field：获取或设置车窗位置（类似属性）
我个人觉得，SOME/IP最妙的是服务发现（Service Discovery）。ECU启动后，会发一个广播：“我提供车窗控制服务，谁需要？” 其他ECU收到后，就可以订阅。这比CAN的静态配置灵活多了。
来看一个典型的SOME/IP报文结构：
// SOME/IP Header (8 bytes)
0x00 0x01 // Service ID (车窗控制 = 0x0001)
0x00 0x01 // Method ID (打开车窗 = 0x0001)
0x12 0x34 // Length (后续数据长度)
0x56 0x78 // Request ID (客户端标识)
0x01 // Protocol Version (当前为1)
0x01 // Interface Version (当前为1)
0x00 // Message Type (0x00 = Request)
0x00 // Return Code (0x00 = OK)
// Payload
0x01 // 车窗ID (左前 = 0x01)
0x64 // 目标位置 (100%)3.4 DoIP协议：诊断 over IP
DoIP，Diagnostic over Internet Protocol。说白了，就是把UDS诊断协议搬到以太网上。为什么要这么做？因为CAN诊断太慢了。刷写一个ADAS控制器，几百兆的固件，CAN要刷几个小时。DoIP呢？几分钟搞定。
DoIP的物理连接，用的是TCP端口13400。诊断仪先发一个车辆识别请求，ECU回复VIN码、EID等信息。然后诊断仪就可以像CAN诊断一样，发UDS请求了。
这里有个关键点：DoIP的激活线。车载以太网诊断，通常需要一根额外的激活线（或通过CAN唤醒）。为什么？因为ECU平时要休眠省电，不能一直监听TCP端口。诊断仪必须先拉高激活线，ECU才启动DoIP服务。
我曾经在实车测试时，发现诊断仪连不上ECU。查了半天，原来是激活线没接。嗯，这个低级错误，犯过一次就不会再犯了。
DoIP的典型报文流程：
- 车辆发现：诊断仪发UDP广播（端口13400），询问“谁在线？”
- 车辆声明：ECU回复“我在，这是我的VIN和IP地址”
- 建立TCP连接：诊断仪连ECU的TCP 13400端口
- 路由激活：诊断仪发路由激活请求，ECU回复确认
- 诊断通信：发送UDS请求（如0x22读取数据、0x2E写入数据）
3.5 融合分析：CAN与以太网如何协同
最后，聊聊CAN和以太网怎么一起工作。现在的车，不可能全是以太网，也不可能全是CAN。通常是网关ECU负责桥接两个网络。
举个例子：ADAS摄像头通过以太网把图像数据传给域控制器，域控制器算完，通过CAN把控制指令发给转向ECU。这时候，你抓CAN报文，看到的是转向角度；抓以太网报文，看到的是图像流。两者时间戳要对齐，才能分析“图像延迟是否导致转向响应慢”。
我建议你在CANalyzer里，同时打开CAN窗口和Ethernet窗口，用时间同步功能。这样，你可以看到CAN报文和以太网报文在同一个时间轴上。我曾经用这个功能，定位到一个“摄像头数据延迟导致自动泊车撞墙”的bug。嗯，那又是另一个故事了。
好了，这一章的内容就到这里。下一章，我们开始动手，用CANalyzer抓第一个以太网报文。