1. 车载网络演进：从CAN/LIN到车载以太网的必然趋势

做车载通信这些年，我经常被问到同一个问题：“CAN总线用了这么多年，为什么非要换成以太网？”

说实话，十年前我也觉得CAN够用。那时候一辆车也就几十个ECU，动力域、车身域各管各的，CAN 2.0的500kbps带宽勉强能撑住。但你看现在的车——智能座舱、自动驾驶、OTA升级，数据量早就不是当年那个量级了。

1.1 传统车载网络的瓶颈

我们先看看传统网络到底卡在哪。

网络类型	带宽	典型应用	痛点
LIN	20 kbps	车窗、座椅、门锁	带宽极低，只能做低速控制
CAN/CAN FD	500 kbps ~ 8 Mbps	动力总成、车身控制	带宽不足，无法承载视频/大数据
FlexRay	10 Mbps	线控底盘、安全系统	成本高，生态封闭
MOST	150 Mbps	信息娱乐	专利壁垒，逐渐被淘汰

你看这个表就明白了。CAN FD虽然把带宽提到了8Mbps，但传一路未压缩的1080p视频需要1.5Gbps左右——差了将近200倍。这不是优化协议能解决的，物理层就决定了天花板。

1.2 车载以太网为什么能胜出

我个人习惯把车载以太网的优势总结为三个字：快、省、通。

• 快：100BASE-T1提供100Mbps，1000BASE-T1直接上1Gbps，未来还有2.5G/5G/10G。这个量级，CAN FD追不上。
• 省：单对非屏蔽双绞线，重量比传统CAN线束轻30%~50%。我在一个项目中算过，全车换装以太网后线束减重了2.3公斤——对续航的影响是实打实的。
• 通：TCP/IP协议栈是现成的，诊断（DoIP）、OTA、V2X都能直接跑。不用像CAN那样每层协议都得自己造轮子。

但这里有个坑——以太网天生是“尽力而为”的传输。你想想看，办公室上网卡了可以刷新，但刹车信号能等吗？

1.3 TSN与SOME/IP的定位与价值

说到TSN和SOME/IP，很多人容易搞混。我简单理一下：TSN管“怎么准时到”，SOME/IP管“到了怎么理解”。

先看TSN。它不是一个协议，而是一套IEEE 802.1标准簇。核心能力包括：

• 时钟同步（802.1AS）：全车节点纳秒级同步，这是所有实时调度的基础。
• 流量整形（802.1Qbv）：给关键数据开“绿色通道”，确保刹车、转向信号不排队。
• 帧抢占（802.1Qbu/br）：低优先级帧传一半，高优先级帧可以打断插入。

我在一个ADAS项目中遇到过这样的问题：摄像头数据流和雷达数据流抢带宽，导致融合算法偶尔丢帧。后来用802.1Qbv给雷达开了保护时间窗，问题就解决了。这种问题，不用TSN你很难定位。

再看SOME/IP。它的全称是Scalable service-Oriented MiddlewarE over IP。说白了，就是让ECU之间像微服务一样“发布-订阅”地通信。

• 服务发现：ECU启动后自动广播“我能提供什么服务”，不用手动配置路由表。
• 序列化：把结构体数据打包成字节流，支持复杂嵌套类型。
• 事件通知：数据变化时才发送，不像CAN那样周期广播，节省带宽。

1.4 知识体系总览

下面这张图是我梳理的本章知识脉络。你可以把它当作整个课程的导航图。

从这张图你可以看到整个逻辑链条：传统网络带宽不足 → 车载以太网解决带宽问题 → TSN解决实时性问题 → SOME/IP解决服务化问题。每一层都是上一层的增强和补充。

1.5 避坑指南

最后分享几个我在项目中踩过的坑：

• 别把TSN当万能药。我曾经在一个项目中，以为开了TSN所有实时问题就都解决了。结果发现802.1Qbv的时钟同步配置错了，导致两个域控的时间基准差了200微秒——ADAS融合直接崩了。TSN配置比你想的复杂，一定要做全链路验证。
• SOME/IP的服务发现不是免费的。每台ECU启动时都会发Find Service消息，如果整车有50+ECU同时启动，网络瞬间会被广播风暴塞满。我建议你设计时把服务发现窗口错开，或者用Ethernet Switch做IGMP Snooping过滤。
• 不要混用CAN和以太网的思维。CAN是信号导向的，每个信号固定ID、固定周期。以太网是服务导向的，动态发现、事件触发。我见过团队把CAN那套“周期发送”直接搬到SOME/IP上，结果带宽浪费了30%。