📚 课程目录第3章车载以太网物理层基础

3. 车载以太网物理层基础

做车载以太网调试，第一件事是什么？

我个人习惯，先把协议栈的「骨架」搭起来。你想想看，车上那么多ECU，有的要刷写，有的要传音视频，有的要发控制信号。它们走的都是以太网，但用的协议完全不一样。搞不清楚这个，调试的时候连抓包都不知道该看哪一层。

3.1 OSI七层模型在车载环境下的映射

OSI七层模型，学网络的人都知道。但车载环境里，它长什么样？我直接给你画张图。

核心观点：车载以太网不是把标准以太网照搬上车。它在物理层做了适配（100BASE-T1 / 1000BASE-T1），在应用层做了裁剪（去掉大量互联网协议，加入DoIP、SOME/IP等汽车专用协议）。

这张图你看懂了吗？我重点说几个地方。

物理层：车上不用RJ45。用的是100BASE-T1或1000BASE-T1，一对双绞线搞定收发。我记得第一次拿到车载以太网示波器波形，吓了一跳——跟标准以太网完全不一样，信号幅度、编码方式都不同。

数据链路层：VLAN是标配。车上一个物理网络要跑多个功能域（动力、座舱、智驾），全靠VLAN隔离。AVB/TSN的流预留、时间感知整形，全在这一层。

传输层：UDP用得比TCP多。为什么？因为SOME/IP和AVB都追求低延迟，TCP的重传机制在实时场景下反而是累赘。

应用层：这是车载协议栈最热闹的地方。DoIP负责诊断刷写，SOME/IP负责服务发现和远程调用，AVB/TSN负责音视频和时间同步。咱们一个一个说。

3.2 DoIP — 诊断通信的「高速公路」

DoIP，全称Diagnostic over Internet Protocol。说白了，就是把UDS诊断报文封装在TCP/IP里，通过以太网传输。

为什么要搞DoIP？以前诊断走CAN，速度慢，刷一个ECU要几十分钟。DoIP走以太网，刷写速度能到100Mbps甚至1Gbps。我做过一个项目，用DoIP刷写域控制器，原来CAN要45分钟，DoIP只要3分钟。客户当场就拍板了。

调试技巧：DoIP抓包时，重点关注三个端口：

UDP 13400 — 车辆发现/声明
TCP 13400 — 诊断消息传输
TCP 动态端口 — 并行测试会话

我曾经遇到一个bug，诊断仪死活连不上ECU。抓包一看，车辆声明报文发出来了，但TCP连接建立后ECU直接RST。最后发现是ECU的TCP窗口大小配置错了。

DoIP的典型流程，我列个表给你看：

步骤	方向	报文类型	说明
1	ECU → 诊断仪	车辆声明 (VIN)	ECU上线，广播自己的VIN和IP
2	诊断仪 → ECU	路由激活请求	诊断仪请求建立诊断会话
3	ECU → 诊断仪	路由激活响应	ECU确认，分配逻辑地址
4	诊断仪 → ECU	诊断消息 (UDS)	真正的诊断请求/响应
5	ECU → 诊断仪	诊断消息 (UDS)	ECU回复诊断结果

避坑指南：我曾经在调试DoIP时，发现车辆声明报文里的VIN长度不对。标准规定VIN是17字节，但某个ECU发了18字节。诊断仪直接丢弃了这条声明，导致发现不了该ECU。这种问题，抓包一看就明白。

3.3 SOME/IP — 面向服务的通信

SOME/IP，Scalable service-Oriented MiddlewarE over IP。名字很长，核心就一句话：把ECU的功能抽象成服务，通过以太网调用。

你想想看，以前CAN通信，每个信号都有固定的ID和周期。想加一个新功能？重新分配ID，改所有节点的代码。SOME/IP不一样，它用服务发现（Service Discovery）动态管理。ECU上线时广播自己能提供什么服务，其他ECU按需订阅。

SOME/IP的报文结构，我习惯这么记：

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Message ID (Service ID + Method ID)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Length (包括自身)                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Request ID (Client ID + Session ID)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Protocol Version | Interface Version  | Message Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Return Code           |        Payload ...             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

调试SOME/IP，我最常用的工具就是Wireshark + SOME/IP解析插件。有一次客户反馈，座舱域控和智驾域控之间的SOME/IP通信时断时续。我抓包一看，发现Service Discovery的Offer报文TTL设得太短，导致订阅方频繁重新发现。把TTL从3秒改成30秒，问题解决。

关键调试点：

Service Discovery：Find Service / Offer Service / Subscribe / Subscribe Ack
序列化：Payload的字节序（大端/小端）必须对齐，否则解析出来全是乱码
超时：SOME/IP的Timeout配置，直接影响系统稳定性

3.4 AVB/TSN — 时间敏感网络

AVB（Audio Video Bridging）和TSN（Time-Sensitive Networking），是车载以太网里最「硬核」的部分。它们解决的是同一个问题：怎么保证数据在确定的时间内到达？

普通以太网，数据包到了交换机，排队。前面有大包？等着。延迟不可控。但车上不行——摄像头数据晚到1毫秒，ADAS决策就错了。音响数据晚到，声音就卡顿。

AVB/TSN的核心机制，我总结成三点：

时钟同步（gPTP）：所有节点共享同一个时间基准，精度达到纳秒级。没有这个，后面全白搭。
流预留（SRP）：音视频流在发送前先申请带宽，交换机保证不丢包、不超时。
时间感知整形（CBS/Qbv）：交换机根据时间片转发数据，关键流优先通过。

我记得第一次调试AVB，遇到一个诡异问题：摄像头画面偶尔卡顿，但网络带宽明明够用。抓包分析发现，gPTP的同步报文被背景流量阻塞了，导致时钟偏差超过100微秒。后来把gPTP报文放到最高优先级VLAN，问题消失。

调试AVB/TSN的常用命令：

ptp4l — Linux下的gPTP实现，查看时钟同步状态
tsn-tool — 配置流预留和Qbv时间槽
tcpdump -i eth0 -j adapter_unsynced — 抓包时关闭硬件时间戳，避免混淆

3.5 协议族对比：什么时候用哪个？

很多新手问我：这三个协议到底什么关系？能不能只用一个？

我的回答是：分工不同，各管一摊。

协议	主要用途	传输层	实时性	典型场景
DoIP	诊断、刷写	TCP	低（不要求实时）	OBD诊断、OTA升级
SOME/IP	服务调用、信号订阅	UDP/TCP	中	座舱功能、车身控制
AVB/TSN	音视频、时间同步	UDP	高（微秒级）	摄像头、音响、雷达

实际项目中，这三个协议经常混用。比如一个智能座舱域控：用DoIP做诊断刷写，用SOME/IP发布空调、座椅等服务，用AVB传输音频流。调试的时候，你得同时看懂三种协议的报文。

注意：不要试图用SOME/IP传音视频数据。SOME/IP的序列化开销大，延迟不可控。AVB/TSN才是干这个活的。我见过一个项目，工程师图省事用SOME/IP传摄像头数据，结果延迟超过50ms，ADAS直接报警。后来老老实实改回AVB。

好了，这一章的内容就到这里。协议栈的骨架搭起来了，后面每一章我们会深入具体协议的调试方法。你先把这张图记在脑子里，调试的时候就知道该看哪一层了。