4、车载以太网协议栈：TCP/IP、SOME/IP、DoIP、AVB/TSN概览
好，咱们进入正题。这一章我打算聊聊车载以太网的协议栈。说实话，很多刚入行的朋友一听到「协议栈」三个字就头大，觉得这是搞IT的人该操心的事。其实不然，在车上跑以太网，跟你在办公室里连Wi-Fi完全是两码事。
我个人的习惯是，先看这张图——车载以太网协议栈的分层结构。你想想看，从最底层的物理层，到最上层的应用层，每一层都有它存在的理由。咱们今天重点聊四个：TCP/IP、SOME/IP、DoIP、AVB/TSN。嗯，这四个是车载以太网的核心。
4.1 TCP/IP：老将出马，一个顶俩
TCP/IP协议族，说白了就是互联网的基石。在车上，它主要负责两个事：一是把数据包从A点送到B点（IP层干的），二是保证送过去的数据是完整的、有序的（TCP层干的）。
我在项目中遇到过一个问题：某次测试，摄像头的数据流突然卡顿。排查了半天，发现是UDP包丢得太厉害。后来我们改用了TCP，虽然延迟稍微大了点，但数据完整性保住了。这就是TCP/IP在车载场景下的典型取舍。
关键点：车载以太网通常使用100BASE-T1或1000BASE-T1物理层，但上层的TCP/IP协议栈跟标准以太网完全兼容。这意味着你可以用标准的socket编程接口，只是底层的物理介质变了。
这里有个避坑指南：我曾经在项目里看到有人直接把PC上的TCP/IP配置搬到车上，结果发现ECU之间的连接时断时续。为什么？因为车载网络的环境更恶劣——电磁干扰、温度变化、振动，这些都会影响物理层的稳定性。所以，TCP的重传机制在车上不是锦上添花，而是保命用的。
4.2 SOME/IP：面向服务的通信
SOME/IP，全称是Scalable service-Oriented MiddlewarE over IP。名字很长，但核心思想很简单：把ECU的功能抽象成服务，然后通过IP网络来调用这些服务。
我刚开始接触SOME/IP时，觉得它跟传统的CAN信号完全不是一个路子。CAN是面向信号的——你定义好ID、长度、周期，然后发就完了。SOME/IP是面向服务的——你发布一个服务，别的ECU来订阅，有需求时才通信。
举个例子：车门控制模块提供「锁门」服务。传统CAN的做法是，网关每隔10ms发一条锁门信号。SOME/IP的做法是，当用户按下锁车键时，才调用一次「锁门」服务。你想想看，这能省多少带宽？
| 特性 | CAN信号 | SOME/IP服务 |
|---|---|---|
| 通信模式 | 周期性广播 | 事件触发/请求-响应 |
| 带宽利用率 | 低（不管有没有变化都发） | 高（有变化才发） |
| 灵活性 | 差（改信号需要重新标定） | 好（服务接口可动态发现） |
我的经验：SOME/IP的Service Discovery（服务发现）机制很关键。ECU上电后，通过SD报文广播自己能提供什么服务，同时监听别人提供的服务。这个过程我建议你在设计阶段就做好时序分析，否则会出现「服务还没注册好，客户端就开始调用了」的尴尬局面。
4.3 DoIP：诊断也能走以太网
DoIP，Diagnostics over IP。说白了，就是把传统的UDS诊断协议搬到以太网上来跑。
为什么需要DoIP？原因很简单——CAN的带宽不够用了。传统诊断用CAN，一条报文最多8个字节。你要刷写一个几十兆的固件，得发几百万条报文，慢得让人抓狂。DoIP就不一样了，一条TCP报文可以发1460字节，速度提升了几百倍。
我记得有一次做OTA升级测试，用CAN刷写一个ECU的固件，花了40分钟。换成DoIP后，同样的固件只用了3分钟。嗯，这就是差距。
DoIP的协议栈其实不复杂：底层是TCP/IP，上层是UDS。中间加了一个DoIP层，负责处理诊断连接的建立、维持和断开。这里有个细节要注意——DoIP支持同时多个诊断连接，但每个ECU能支持的连接数是有限的。我曾经见过一个设计，ECU只支持2个DoIP连接，结果测试时3台设备同时连上来，直接报错。
警告：DoIP的激活线（Activation Line）一定要处理好。在车载网络中，DoIP通信需要先通过物理唤醒信号激活ECU，然后才能建立TCP连接。如果激活线设计不当，ECU可能无法被正确唤醒，导致诊断失败。
4.4 AVB/TSN：时间敏感网络
AVB（Audio Video Bridging）和TSN（Time-Sensitive Networking）是车载以太网里最「硬核」的部分。它们解决的核心问题是：如何保证数据在确定的时间内到达。
你想想看，自动驾驶的摄像头数据，如果延迟了10毫秒，车可能已经撞上了。传统的以太网是「尽力而为」的——数据包什么时候到，谁也说不好。AVB/TSN通过时间同步、流量整形、预留带宽等机制，把延迟控制在微秒级。
我个人觉得，TSN是未来车载网络的核心。为什么？因为随着自动驾驶等级的提高，对实时性的要求只会越来越严。CAN FD虽然也能做到实时，但带宽上限摆在那里。TSN可以在千兆以太网上实现确定性通信，这是质的飞跃。
AVB和TSN的关系，说白了就是「前辈」和「后辈」。AVB是IEEE 802.1标准的一部分，主要针对音视频流。TSN是AVB的演进版，覆盖了更广泛的工业和控制场景。在车上，我们通常用TSN的802.1Qbv（时间感知整形）和802.1AS（时间同步）这两个子协议。
实践建议：如果你在项目中用到TSN，一定要先搞定时钟同步。802.1AS的精度决定了整个TSN网络的性能。我见过一个项目，因为晶振的漂移太大，导致时间同步误差超过100微秒，结果流量整形完全失效。后来换了高精度的温补晶振，问题才解决。
4.5 协议栈的协同工作
好了，四个协议都聊完了。你可能会问：它们之间怎么配合？
我画个简单的场景：一辆智能网联汽车，通过DoIP进行远程诊断，同时车内摄像头通过AVB/TSN传输视频流，而SOME/IP负责控制信号的交互。底层都是TCP/IP在跑。
你看，每个协议都有自己的定位：
- TCP/IP：基础通信管道，负责数据包的路由和可靠传输。
- SOME/IP：应用层的服务框架，让ECU之间能灵活地调用功能。
- DoIP：诊断专用通道，满足刷写和故障排查的需求。
- AVB/TSN：实时性保障，确保关键数据按时到达。
它们不是互相替代的关系，而是各司其职。我建议你在设计车载网络架构时，先搞清楚每个协议适用的场景，然后再做取舍。别想着一个协议包打天下，那是不现实的。
最后说一句：协议栈的选择，最终取决于你的应用需求。如果你只是做简单的车身控制，SOME/IP+TCP/IP就够了。如果你要做自动驾驶，那AVB/TSN是绕不开的。诊断功能嘛，DoIP迟早要上，因为OTA是大趋势。