第3章：车载以太网协议栈
各位同学，今天我们来聊聊车载以太网协议栈。说实话，这个主题我讲了不下二十次，但每次都有新感悟。车载环境下的TCP/IP协议栈，跟咱们电脑上用的那套，表面看一样，骨子里差别大了去了。
3.1 TCP/IP协议栈在车载环境的应用
先说说TCP/IP。很多人觉得这玩意儿太成熟了，直接拿来用不就行了？我刚开始也这么想，直到在项目里栽了跟头。
车载环境有几个特点：
- 带宽有限——虽然以太网比CAN快得多，但跟数据中心比还是差远了
- 延迟敏感——刹车信号晚1毫秒，可能就是事故
- 资源受限——ECU的CPU和内存都很金贵
所以，标准TCP/IP协议栈在车上必须做裁剪。我个人习惯的做法是：
- 精简TCP实现——去掉重传缓冲区里那些花哨的优化算法
- UDP优先——能不用TCP就不用，减少握手开销
- IP分片禁用——我遇到过因为分片重组导致的内存溢出，那叫一个惨
核心要点：车载TCP/IP协议栈不是功能越多越好，而是越精简越可靠。
举个例子，自适应巡航的传感器数据流。用UDP发，丢了就丢了，下一帧马上补上。如果用TCP，重传机制反而引入不确定延迟。你想想看，这合理吗？
3.2 AVB/TSN协议族概述
AVB和TSN，这两个词我当年刚接触时也晕。说白了，它们就是给以太网装上「交通管制」系统。
AVB（Audio Video Bridging）最早是为了音视频同步设计的。后来演变成TSN（Time-Sensitive Networking），应用范围更广了。
我在项目中用过的主要协议：
| 协议 | 作用 | 我的经验 |
|---|---|---|
| 802.1Qav | 流量整形 | 控制数据发送节奏，防止突发 |
| 802.1Qbv | 时间感知调度 | 给关键数据开绿色通道 |
| 802.1AS | 时钟同步 | 精度能到微秒级，够用了 |
| 802.1Qci | 入口过滤 | 防止异常流量冲击 |
嗯，这里要注意。TSN不是万能的。我曾经在一个项目中，把所有数据都塞进TSN调度队列，结果发现非实时数据反而被饿死了。后来才明白，TSN要跟传统以太网配合使用，不能一刀切。
避坑指南：配置TSN时，记得给非实时流量留个「最低保障带宽」。我吃过这个亏，调试了整整两周才发现问题。
3.3 SOME/IP与DDS中间件
终于说到中间件了。SOME/IP和DDS，这两个是车载通信的「翻译官」。
SOME/IP（Scalable service-Oriented MiddlewarE over IP）是AUTOSAR的标配。它的设计思路很务实：
- 服务发现——谁提供什么服务，谁需要什么服务，自动匹配
- 远程过程调用——就像调用本地函数一样调用远程服务
- 事件通知——数据变了主动推送给订阅者
我举个例子。你车上的摄像头检测到行人，通过SOME/IP发布一个「行人事件」。控制单元订阅了这个事件，收到后立刻触发刹车。整个过程，开发者不用关心底层网络细节。
DDS（Data Distribution Service）则是另一种思路。它更强调数据的分发质量：
- QoS策略——可靠性、时效性、持久性都能配置
- 去中心化——没有中央服务器，节点间直接通信
- 动态发现——节点上线下线自动感知
说实话，DDS在自动驾驶领域越来越流行。为什么？因为它能保证「数据在正确的时间到达正确的地方」。这在传感器融合场景下太重要了。
注意：SOME/IP和DDS不是二选一的关系。我见过不少项目，控制面用SOME/IP，数据面用DDS，各取所长。
最后分享一个经验。选型时别只看技术指标。SOME/IP的生态更成熟，工具链完善。DDS的灵活性更高，但学习曲线陡。你想想看，团队的技术储备和项目周期，往往比技术本身更能决定成败。
好了，这一章就到这里。下一章我们聊聊实际部署中的那些坑，保证让你少走弯路。