3. 车载以太网基础
好，咱们进入第三章。这一章我打算把车载以太网的协议栈整个摊开来看。很多刚入行的朋友，上来就盯着 SOME/IP 或者 DoIP 猛学，结果发现跟底层怎么配合、跟其他协议怎么共存，完全没概念。说白了，车载以太网不是单一协议，而是一整套协议栈的协同工作。
我个人习惯，先看一张总图，再拆开讲。这样你心里有个谱，后面学细节才不会迷路。
核心观点：车载以太网协议栈是 OSI 七层模型在汽车场景下的裁剪与增强。物理层、数据链路层、网络层、传输层、应用层，每一层都有对应的车载专用协议。理解它们的位置和关系，比死记硬背协议细节更重要。
3.1 OSI 模型在车载环境下的映射
标准的 OSI 七层模型，在车载以太网里被压缩和重新定义了。你想想看，汽车内部网络对实时性、确定性、安全性有特殊要求，不能照搬 IT 互联网那一套。
下面这张表，是我自己整理的车载以太网协议栈与 OSI 模型的对应关系。每次带新人，我都先让他们背这张表。
| OSI 层 | 车载以太网协议/标准 | 我的备注 |
|---|---|---|
| 应用层 (Layer 7) | SOME/IP、DoIP、AVB/TSN 应用、网络管理 | 这里最热闹，各种应用协议百花齐放 |
| 表示层 (Layer 6) | SOME/IP 序列化 (SOME/IP-SD) | 其实 SOME/IP 把表示层和会话层的事都干了 |
| 会话层 (Layer 5) | SOME/IP-SD (服务发现) | 服务发现机制，相当于设备间的自我介绍 |
| 传输层 (Layer 4) | TCP、UDP | DoIP 用 TCP，SOME/IP 通常用 UDP |
| 网络层 (Layer 3) | IPv6、IPv4 | 车载现在强推 IPv6，地址够用 |
| 数据链路层 (Layer 2) | IEEE 802.1Q (VLAN)、802.1AS (时间同步)、802.1Qbv (TSN) | AVB/TSN 的核心战场 |
| 物理层 (Layer 1) | 100BASE-T1、1000BASE-T1 | 单对非屏蔽双绞线，减重降本 |
嗯，这里要注意：车载以太网没有独立的会话层和表示层。这些功能被 SOME/IP 和 DoIP 等应用层协议直接吸收了。我刚开始做项目时，总想按标准 OSI 去套，结果发现根本对不上。后来才明白，汽车行业讲究实用，能干活就行，不纠结理论分层。
3.2 DoIP：诊断协议的位置
DoIP（Diagnostic over Internet Protocol），说白了就是把传统的 UDS 诊断搬到了以太网上。以前诊断用 CAN，一条报文 8 个字节，刷个固件得等半天。现在用 DoIP，带宽直接拉到 100Mbps，刷写时间从小时级降到分钟级。
DoIP 在协议栈里的位置很清晰：
- 传输层：TCP（可靠连接，用于诊断请求/响应）和 UDP（用于发现和通告）
- 应用层：封装 UDS 诊断消息，加上 DoIP 头部
我记得有一次，客户反馈 DoIP 连接总是超时。排查了半天，发现是 TCP 的 Keep-Alive 参数没配好。车载环境里，电磁干扰大，连接容易断，TCP 参数必须针对性地调优。这个坑，后面我会专门讲。
小提示：DoIP 的物理层必须用 100BASE-T1 或 1000BASE-T1，不能用普通的 100BASE-TX。因为车载以太网用的是单对线，而且有 EMC 要求。别拿实验室的普通网线去试车，会出问题的。
3.3 SOME/IP：面向服务的中间件
SOME/IP（Scalable service-Oriented MiddlewarE over IP）是车载以太网里最核心的应用层协议。它定义了服务如何发布、发现、调用。你可以把它理解成车载版的 RESTful API，但更轻量、更实时。
SOME/IP 在协议栈里横跨了应用层、表示层和会话层：
- 服务发现（SOME/IP-SD）：通过 UDP 多播，ECU 之间互相发现对方提供的服务。相当于设备在喊：“我这里有摄像头数据服务，谁要？”
- 远程过程调用（RPC）：通过 UDP 或 TCP，调用远程 ECU 上的方法。比如，座舱域控制器调用智驾域控制器的摄像头数据。
- 事件通知：订阅/发布模式。ECU 订阅某个事件，当事件发生时，服务端主动推送数据。
我曾经在一个项目中，SOME/IP 的序列化格式没对齐，导致两个域控制器之间数据解析全乱套。排查了三天，最后发现是结构体对齐方式不一致。所以，SOME/IP 的接口定义文件（ARXML）必须严格评审，一个字都不能错。
3.4 AVB/TSN：时间敏感网络
AVB（Audio Video Bridging）和 TSN（Time Sensitive Networking）是数据链路层的增强标准。它们解决的是车载网络里最头疼的问题：确定性延迟。
普通以太网是“尽力而为”的，数据包什么时候到，谁也说不好。但车载里，刹车信号、转向信号、摄像头数据，都有严格的延迟要求。比如，摄像头数据从采集到显示，延迟不能超过 10 毫秒。
AVB/TSN 的核心机制包括：
- 802.1AS：精确时间同步，所有 ECU 共享同一个时钟，精度达到微秒级。
- 802.1Qbv：时间感知整形器，给高优先级数据预留专用时间槽。
- 802.1Qav：流预留协议，保证带宽不被抢占。
我建议你记住一句话：TSN 不是单一协议，而是一整套工具集。实际项目中，你不需要全部实现，只需要根据业务需求选配。比如，做音响系统，重点用 802.1AS 和 802.1Qav；做智驾系统，重点用 802.1Qbv。
避坑指南：我曾经在一个项目里，TSN 的时钟同步一直不稳。后来发现是交换机的晶振精度不够，导致 802.1AS 的同步误差累积。记住，TSN 对硬件有要求，不是随便买个交换机就能用的。必须选支持 802.1AS 的 gPTP 交换机。
3.5 网络管理协议的位置
车载网络管理（NM，Network Management）负责协调 ECU 的休眠和唤醒。传统 CAN 网络有专门的 NM 报文，到了以太网，NM 协议被重新定义了。
在 AUTOSAR 架构下，以太网网络管理通常基于 SOME/IP 实现。它的位置在：
- 应用层：NM 作为 SOME/IP 的一个服务，通过 UDP 多播发送 NM 报文。
- 传输层：UDP，因为 NM 报文不需要可靠传输，丢了就丢了，下个周期再发。
- 网络层：IPv6 或 IPv4，通常用 IPv6 的多播地址。
NM 的核心逻辑是：
- ECU 启动后，发送 NM 报文，告诉网络“我醒了”。
- 如果 ECU 没有业务需要处理，进入“预备休眠”状态。
- 所有 ECU 都同意休眠后，网络进入低功耗模式。
嗯，这里有个关键点：以太网 NM 和 CAN NM 的休眠策略完全不同。CAN NM 是“总线同步休眠”，所有节点一起睡。以太网 NM 是“分布式决策”，每个 ECU 自己决定是否休眠，但需要协调。我见过不少从 CAN 转以太网的工程师，在这里栽了跟头。
3.6 一张图看懂协议栈全貌
下面这张 SVG 图，是我手绘的协议栈分层结构。你把它存下来，后面学每一章时，回来对照一下，就知道当前学的协议在栈里哪个位置。
3.7 协议栈的协同工作
光知道每层有什么协议还不够，你得理解它们怎么配合。我举个例子：
假设座舱域控制器需要从智驾域控制器获取摄像头数据：
- 物理层：1000BASE-T1 连接，1Gbps 带宽。
- 数据链路层：802.1Qbv 为摄像头数据预留了时间槽，保证延迟不超过 5ms。
- 网络层：IPv6 地址，座舱域和智驾域在同一个 VLAN 内。
- 传输层：UDP 传输，因为摄像头数据可以容忍少量丢包，但延迟必须低。
- 应用层：SOME/IP 事件通知，智驾域主动推送摄像头数据，座舱域订阅即可。
你看，每一层都在为同一个目标服务：低延迟、高带宽、确定性传输。如果某一层出了问题，整个链路都会受影响。我遇到过物理层线束阻抗不匹配，导致整个 TSN 时间槽错位的案例。所以，协议栈的每一层都要认真对待，不能有短板。
总结：车载以太网协议栈不是简单的 OSI 复制，而是针对汽车场景的深度定制。DoIP 负责诊断，SOME/IP 负责服务通信，AVB/TSN 负责实时性，网络管理负责休眠唤醒。它们各司其职，又紧密配合。后面每一章，我都会深入一个协议，但请记住，它们永远是在这个协议栈框架下工作的。