第四章：车载以太网基础
说实话，我刚入行那会儿，车载网络基本就是CAN的天下。那时候谁要是提以太网，大家会觉得「这玩意儿是搞IT的才用的吧？」。但时代变了，真的变了。现在你打开一辆高端车的电气架构图，以太网已经成了骨干网络。
这一章，我们就来聊聊车载以太网的那些事儿。我会结合我这些年踩过的坑，给你讲清楚协议栈、SOME/IP、DoIP，还有以太网和CAN到底怎么选。
4.1 车载以太网协议栈（AVB/TSN）
先说说协议栈。车载以太网和咱们办公室用的以太网，底层物理层是一样的，但上层协议栈完全不同。为什么？因为车里面需要确定性——说白了，就是数据必须在规定时间内到达，不能像上网看视频那样卡一下还能忍。
这里有两个关键协议族：AVB和TSN。
4.1.1 AVB（音频视频桥接）
AVB最初是为了解决音视频同步问题。我记得2016年做第一个AVB项目时，客户要求摄像头画面和雷达数据必须严格同步。当时我天真地以为，只要带宽够大就行。结果呢？数据是传过去了，但时间戳对不上，画面和雷达点云差了50毫秒——这在自动驾驶里可是要命的。
AVB的核心机制包括：
- 精确时间同步（gPTP）：IEEE 802.1AS，让所有节点的时间误差控制在微秒级
- 流预留协议（SRP）：IEEE 802.1Qat，提前为数据流预留带宽
- 信用整形器（CBS）：IEEE 802.1Qav，控制数据发送的节奏
关键点：AVB不是万能的。它适合软实时场景，比如音视频流。但如果你需要硬实时（比如制动控制信号），AVB就不够用了。这时候得请出TSN。
4.1.2 TSN（时间敏感网络）
TSN是AVB的进化版。说白了，AVB是「尽量准时」，TSN是「必须准时」。TSN引入了一个杀手锏——时间感知整形器（TAS）。
怎么理解呢？想象一下，网络时间被切成一个个小片。在每个时间片里，只有特定的数据流可以发送。这样一来，高优先级的数据（比如制动指令）就能在固定的时间窗口内完成传输，完全不受其他数据干扰。
我去年调试一个TSN项目时，遇到过一个问题：明明配置了时间窗口，但数据还是偶尔超时。查了两天才发现，是时钟同步的精度不够。嗯，这里要注意：TSN依赖gPTP，如果gPTP没调好，整个TSN就是空中楼阁。
| 特性 | AVB | TSN |
|---|---|---|
| 时间同步精度 | 微秒级 | 纳秒级 |
| 确定性 | 软实时 | 硬实时 |
| 典型应用 | 音视频、摄像头 | 控制信号、安全相关 |
| 复杂度 | 中等 | 高 |
4.2 SOME/IP协议
SOME/IP，全称是Scalable service-Oriented MiddlewarE over IP。名字很长，但核心思想很简单：把汽车里的功能封装成服务，通过以太网来调用。
你想想看，传统CAN通信是信号导向的——你定义一个CAN ID，里面塞几个信号，接收方按ID解析。但SOME/IP不一样，它是服务导向的。一个ECU可以发布一个服务（比如「获取车速」），其他ECU可以订阅这个服务。谁需要谁订阅，不需要就取消，非常灵活。
我个人习惯把SOME/IP分成两种通信模式：
- 请求/响应模式：客户端发请求，服务端回响应。适合查询类操作，比如读取故障码。
- 事件通知模式：服务端主动推送数据。适合周期性数据，比如车速、转速。
这里有个坑，我曾经踩过。SOME/IP的序列化（Serialization）方式跟CAN完全不同。CAN里你直接读寄存器就行，但SOME/IP需要按照指定的格式把数据打包成字节流。如果你序列化和反序列化的两端不一致，数据解析出来就是乱码。我曾经因为一个字节序（Endianness）配置错误，调试了整整两天。
小技巧：调试SOME/IP时，先用Wireshark抓包看看原始字节流。确认发送端和接收端的序列化参数完全一致，再往下查。
4.3 DoIP协议
DoIP，Diagnostics over IP。说白了，就是用以太网来做诊断。以前诊断都是走CAN（UDS over CAN），但CAN的带宽有限，刷写一个ECU固件可能要半小时。换成DoIP，同样的固件，几分钟搞定。
DoIP的协议栈分三层：
- 物理层和传输层：TCP/UDP over IP
- DoIP协议层：处理连接管理、路由激活、诊断消息封装
- 应用层：UDS诊断服务（比如读取DTC、写入数据）
我记得有一次，客户反馈说DoIP连接总是超时。我排查后发现，是TCP的Keep-Alive参数没配好。DoIP要求在一定时间内没有数据交互时，发送Keep-Alive报文来维持连接。如果这个时间设置得太长，中间的路由器可能会把连接断开。
警告：DoIP的端口号是13400，这是IANA分配的。不要随便改。另外，DoIP要求支持同时多个诊断连接，但实际项目中建议限制为1-2个，否则ECU资源可能不够用。
4.4 以太网与CAN的对比
很多新手会问：既然以太网这么牛，为什么还要用CAN？
这个问题，我当年也问过我的导师。他的回答让我记到现在：「工具没有好坏，只有合不合适。」
咱们来做个对比：
| 维度 | CAN | 车载以太网 |
|---|---|---|
| 带宽 | 最高8 Mbps（CAN FD可达15 Mbps） | 100 Mbps ~ 1 Gbps |
| 传输距离 | 40米@1 Mbps | 100米@100 Mbps |
| 确定性 | 天生确定性（CSMA/CR） | 需要TSN支持 |
| 成本 | 低（芯片几毛钱） | 高（PHY芯片几美金） |
| 功耗 | 低 | 较高 |
| 适用场景 | 控制信号、传感器数据 | 摄像头、大容量数据、诊断 |
你看，CAN的优势在于简单、便宜、确定性强。一个刹车信号，用CAN传，延迟是固定的，不会因为网络拥堵而变慢。但以太网的优势在于带宽大，可以传高清视频、激光雷达点云这些海量数据。
所以现在的趋势是：
- 控制域：继续用CAN/CAN FD，甚至LIN
- 骨干域：用以太网连接各个域控制器
- 传感器域：摄像头、激光雷达直接走以太网
我曾经参与过一个项目，客户非要所有信号都走以太网。结果呢？成本翻倍，功耗飙升，而且因为TSN配置复杂，开发周期延长了三个月。最后不得不改回CAN+以太网的混合架构。
我的建议：别盲目追求新技术。CAN和以太网不是替代关系，是互补关系。该用CAN的地方用CAN，该用以太网的地方用以太网，这才是成熟工程师的思路。
好了，这一章的内容就到这里。下一章我们会进入实战环节——用Python写一个简单的SOME/IP客户端和服务端。到时候我会手把手带你过一遍代码，保证你学完就能用。