3. 车载以太网协议栈概览：OSI七层模型在车载环境下的映射、DoIP、SOME/IP、AVB/TSN协议族简介
做车载以太网调试，第一件事是什么？
我个人习惯，先把协议栈的「骨架」搭起来。你想想看，车上那么多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。
好了，这一章的内容就到这里。协议栈的骨架搭起来了，后面每一章我们会深入具体协议的调试方法。你先把这张图记在脑子里，调试的时候就知道该看哪一层了。