4. 车载以太网基础：Some/IP、DoIP、AVB/TSN 协议概述与测试方法
车载以太网，说白了就是给车装上了一条高速数据公路。传统的 CAN、LIN 总线在自动驾驶和智能座舱面前，已经有点力不从心了。带宽不够，延迟还高。以太网一来，带宽直接上 Gbps，还能支持复杂的服务架构。
但光有物理层不行，车上跑的协议才是灵魂。今天咱们重点聊三个：Some/IP、DoIP 和 AVB/TSN。这三兄弟，几乎覆盖了当前车载通信的三大核心场景——服务调用、诊断刷写、音视频同步。
4.1 Some/IP：面向服务的通信
Some/IP（Scalable service-Oriented MiddlewarE over IP）是 AUTOSAR 标准里的核心中间件。它让 ECU 之间不再只是发信号，而是提供服务。
举个例子：以前你想知道车速，得去解析 CAN 报文里的某个信号位。现在呢？你直接调用一个 GetVehicleSpeed() 服务，Some/IP 帮你搞定请求和响应。
4.1.1 核心概念
- Service Interface：服务的抽象定义，包含 Method、Event、Field。
- Method：客户端发请求，服务端回响应。典型的 RPC 模式。
- Event：服务端主动推送数据给订阅的客户端。
- Field：有点像属性，可以 get、set、notify。
- Service Discovery (SD)：动态发现服务，不用静态配置 IP 和端口。
我个人的习惯：在测试 Some/IP 时，先抓 Service Discovery 的 Offer 和 Subscribe 报文。如果服务发现没跑通，后面所有通信都是白搭。
4.1.2 测试方法
| 测试项 | 测试点 | 工具/方法 |
|---|---|---|
| 服务发现 | Offer 报文是否周期性发送？Subscribe 后是否有 Ack？ | Wireshark + vSomeIP |
| Method 调用 | 请求与响应是否匹配？超时重传机制是否生效？ | CAPL 脚本 / Python scapy |
| Event 推送 | 事件触发后，订阅方是否及时收到？丢包后如何处理？ | CANoe + SOME/IP Option |
| 序列化 | Payload 的序列化格式是否与 ARXML 一致？ | 静态代码检查 + 报文对比 |
避坑指南：我曾经遇到过一个项目，Some/IP 的 Method 调用总是超时。查了半天，发现是服务端的线程池太小，请求排队了。测试时一定要关注并发场景。
4.2 DoIP：诊断通信的以太网化
DoIP（Diagnostic over Internet Protocol）就是把传统的 UDS 诊断协议搬到以太网上。以前诊断用 CAN，一条报文 8 个字节，刷个固件得等半天。DoIP 一来，带宽大了，刷写速度直接起飞。
4.2.1 协议栈结构
DoIP 的协议栈其实不复杂，从上到下大概是：
- 应用层：UDS 诊断服务（如 0x22、0x2E、0x34）
- DoIP 层：封装 UDS 报文，加上 DoIP 头部（版本号、类型、长度等）
- 传输层：TCP（用于大块数据传输）或 UDP（用于发现和心跳）
- 网络层：IPv4/IPv6
注意：DoIP 的 TCP 连接是长连接，测试时一定要验证连接断开后的重连机制。否则刷写一半断线了，ECU 可能变砖。
4.2.2 测试重点
- 车辆发现：诊断仪发送
0x0004（车辆识别请求），ECU 回复0x0005（车辆识别响应）。 - 路由激活：发送
0x0006，ECU 回复0x0007。这里要注意逻辑地址的合法性。 - 诊断数据传输：通过
0x8001和0x8002传输 UDS 报文。 - 并发连接：多个诊断仪同时连接时，ECU 的行为是否符合规范？
// DoIP 报文示例（十六进制）
// 车辆识别请求
02 FD 00 04 00 00 00 00
// 车辆识别响应
02 FD 00 05 00 00 00 10
EID: 00 00 00 00 00 00
GID: 00 00 00 00 00 00
VIN: 4C 45 56 49 4E 47 53 2D 44 45 4D 4F 2D 30 30 31
我建议：测试 DoIP 时，最好准备一个“坏报文”库。比如故意把 DoIP 头部长度字段写错，看看 ECU 会不会崩溃。这种负面测试，往往能发现大问题。
4.3 AVB/TSN：时间敏感网络
AVB（Audio Video Bridging）和 TSN（Time-Sensitive Networking）是 IEEE 802.1 标准族。它们解决的核心问题是：确定性低延迟。
你想想看，自动驾驶的摄像头数据、雷达数据，如果传输延迟忽高忽低，那控制算法根本没法跑。AVB/TSN 就是给以太网装上了“时间表”，让关键数据准时到达。
4.3.1 关键协议
| 协议 | 作用 | 典型应用 |
|---|---|---|
| 802.1AS (gPTP) | 时钟同步，精度可达亚微秒级 | 多传感器数据融合 |
| 802.1Qav (FQTSS) | 流量整形，保证音视频带宽 | 车载娱乐系统 |
| 802.1Qbv (TAS) | 时间感知整形，按时间片发送 | ADAS 控制指令 |
| 802.1CB (FRER) | 帧复制与消除，提高可靠性 | 安全关键系统 |
4.3.2 测试方法
AVB/TSN 的测试，我个人觉得最核心的是三点：时钟同步精度、端到端延迟、抖动。
- gPTP 测试：用专业的时钟分析仪，测量主时钟与从时钟的偏差。我记得有一次，发现某个交换机的 PTP 报文处理时间不稳定，导致同步误差超过了 1μs，后来换了 PHY 芯片才解决。
- 流量整形测试：构造混合流量（高优先级音视频 + 低优先级背景流量），用网络分析仪抓包，验证高优先级流量的延迟是否在预算内。
- 时间感知整形测试：配置 802.1Qbv 的门控列表，用示波器或专用工具测量每个时间片的发送窗口是否准确。
核心指标：
- 时钟同步精度：< 1μs（典型值）
- 端到端延迟：< 100μs（Class A 流）
- 抖动：< 50μs
4.4 知识体系总览
下面这张图，是我自己总结的车载以太网协议测试知识体系。你可以把它当作一个检查清单，面试时也能用来展示你的系统性思维。
4.5 面试表达建议
面试官如果问你“车载以太网协议你熟悉哪些？”，别只背概念。你可以这样说：
“我主要接触过 Some/IP、DoIP 和 AVB/TSN。Some/IP 这块，我做过服务发现和 Method 调用的自动化测试，用 Python scapy 构造过异常报文。DoIP 的话，我参与过 OTA 刷写测试，重点验证了路由激活和并发连接场景。AVB/TSN 我测过 gPTP 的时钟同步精度，当时发现交换机晶振漂移导致同步误差超标，后来换了 TCXO 才解决。”
你看，这样一说，既有技术深度，又有实战案例，面试官会觉得你是个“干过活”的人。
最后提醒一句：车载以太网的测试，工具很重要，但更重要的是理解协议的设计意图。你只有知道它为什么这么设计，才能测到点子上。