一、车载网络概述：从CAN总线到以太网的演进之路
大家好，我是老张，在车载网络这行摸爬滚打了十几年。今天咱们聊聊车载网络的基础——发展史、分类和拓扑结构。这些东西看着基础，但说实话，很多干了三五年的工程师都未必能讲清楚。
为什么我要先讲这个？因为QoS（服务质量）不是凭空来的。你得先知道网络长什么样，才能谈怎么保障它。就像修路，你得先知道路有多宽、车流量多大，才能设计红绿灯和收费站，对吧？
1.1 车载网络发展史：从一根线到一张网
早期的汽车，说白了就是机械装置。电子系统？几乎没有。我记得90年代那会儿，一辆车上能有几个传感器就不错了，信号全靠一根根铜线直连。那时候的“网络”，其实就是一堆电线捆在一起。
转折点出现在90年代中期。随着排放法规越来越严，发动机电控系统（ECU）开始普及。一个ECU要跟传感器、执行器通信，线束越来越重，成本越来越高。这时候，博世公司搞出了CAN总线——这玩意儿彻底改变了汽车电子架构。
CAN总线时代（1990s-2000s）
CAN总线的核心思想就一句话：多节点共享一根总线。所有ECU都挂在这根线上，谁想发数据就发，靠优先级仲裁。我当年第一次接触CAN时，觉得这设计太聪明了——简单、可靠、成本低。但后来发现，它也有硬伤：带宽只有1Mbps，而且没有QoS保障。什么意思？就是高优先级的报文永远插队，低优先级的可能永远发不出去。
FlexRay与MOST时代（2000s-2010s）
到了2000年代，汽车功能越来越复杂。线控转向、线控制动这些安全关键系统，对实时性要求极高。CAN总线扛不住了。于是FlexRay出现了——双通道、10Mbps、时间触发。说白了，就是给每个报文分配一个固定时间槽，谁也别抢。我在做宝马X5项目时，底盘控制就用的FlexRay，那叫一个稳。
同时期，车载娱乐系统也在爆发。导航、DVD、音响……这些需要大带宽。MOST总线应运而生，最高150Mbps，用光纤传输。但说实话，MOST这玩意儿太封闭了，只有几家大厂在用，后来被以太网干掉了。
以太网时代（2010s至今）
现在？车载以太网是主流。100BASE-T1、1000BASE-T1，带宽从100Mbps到1Gbps。为什么以太网能胜出？说白了，生态好。TCP/IP协议栈、AVB/TSN（音视频桥接/时间敏感网络）这些现成的技术，直接拿过来用。我最近做的自动驾驶项目，激光雷达数据、摄像头数据，全走以太网。没有QoS？根本跑不动。
核心观点：车载网络的发展，本质上是带宽和实时性的博弈。CAN解决“有没有”的问题，FlexRay解决“准不准”的问题，以太网解决“够不够”的问题。而QoS，就是在这三者之间找到平衡。
1.2 车载网络分类：各司其职的“五虎将”
现在的汽车，不可能只用一种总线。你想想看，车窗升降和自动驾驶对网络的要求能一样吗？所以，一辆车上通常同时存在多种网络，各干各的。
| 网络类型 | 带宽 | 典型应用 | QoS能力 |
|---|---|---|---|
| CAN/CAN FD | 1Mbps / 8Mbps | 动力总成、车身控制 | 优先级仲裁（无严格QoS） |
| LIN | 20kbps | 车窗、座椅、门锁 | 无（主从架构） |
| FlexRay | 10Mbps | 线控底盘、安全气囊 | 时间触发（强QoS） |
| MOST | 150Mbps | 娱乐系统、导航 | 流式传输（弱QoS） |
| 车载以太网 | 100Mbps-1Gbps | ADAS、域控、OTA | AVB/TSN（强QoS） |
CAN/CAN FD： 这是最“皮实”的总线。我做过一个项目，ECU之间的通信全用CAN，跑了五年没出过问题。但注意，CAN的仲裁机制是“非破坏性逐位仲裁”——优先级高的报文永远赢。这意味着，如果你有10个节点同时发数据，优先级最低的那个可能永远发不出去。嗯，这就是QoS的雏形，但很粗糙。
LIN： 说白了就是CAN的廉价替代品。20kbps的带宽，只能控制个车窗、座椅啥的。主从架构，主机问，从机答。没有QoS，因为根本不需要——数据量太小了。
FlexRay： 这个我要多说两句。FlexRay的设计思路跟CAN完全相反：它不靠优先级，而是靠时间。每个节点在固定的时间槽里发数据，谁也别抢。我曾经调试过一个线控转向系统，要求转向指令的延迟不超过1ms。用FlexRay，轻松搞定。但代价是配置复杂——你得精确计算每个时间槽的长度和偏移量。
MOST： 这玩意儿现在基本淘汰了。当年做车载娱乐系统时，MOST是唯一的选择——150Mbps带宽，光纤传输，抗干扰能力强。但问题是，它太封闭了，只有几家供应商能做。后来以太网一出来，MOST就凉了。
车载以太网： 这是未来的方向。100BASE-T1只用一对双绞线，就能跑100Mbps。1000BASE-T1更是能到1Gbps。更重要的是，它支持AVB和TSN——这两个协议就是专门为QoS设计的。我最近在做的自动驾驶项目，激光雷达数据、摄像头数据、毫米波雷达数据，全走以太网。没有TSN？根本没法保证数据同步。
避坑指南： 我曾经犯过一个错误——在CAN网络上跑高频率的传感器数据。结果呢？低优先级的报文被活活饿死，导致系统误判。后来我学乖了：高带宽、高实时性的数据，必须走以太网+TSN；控制类的数据，走CAN FD就够了。
1.3 车载网络拓扑结构：从“一线牵”到“星罗棋布”
拓扑结构，说白了就是ECU之间怎么连。不同的拓扑，对QoS的影响天差地别。
总线型拓扑（CAN/LIN的典型结构）
所有节点挂在一根总线上。优点是简单、成本低。缺点是——一旦总线断了，整个网络瘫痪。而且，所有节点共享带宽，数据多了就堵车。我在做车身控制项目时，遇到过一个问题：车窗升降和门锁控制共用一根LIN总线，结果车窗升降时，门锁指令延迟了200ms。用户投诉说“锁车不灵敏”。后来怎么解决的？把门锁单独拉了一根LIN线。
星型拓扑（以太网的典型结构）
所有节点通过交换机连接。交换机就是交通警察，负责调度数据。这种拓扑的好处是：每个节点独享带宽，互不干扰。而且，交换机可以做QoS——给高优先级的数据开绿灯。我现在的项目，域控制器就是星型拓扑的中心，所有传感器数据都汇聚到它那里。
环型拓扑（MOST的典型结构）
节点首尾相连，形成一个环。数据沿着环一圈圈传。优点是光纤传输，抗干扰强。缺点是——环上任何一个节点坏了，整个环就断了。MOST当年用这种拓扑，主要是为了简化布线。但说实话，维护起来太麻烦。
混合拓扑（现代汽车的常见结构）
现在的汽车，通常是多种拓扑混用。比如：动力域用CAN FD总线型，底盘域用FlexRay星型，娱乐域用以太网星型，然后通过一个中央网关把它们连起来。我做过一个项目，网关要同时处理CAN、FlexRay和以太网的数据，QoS策略写得我头秃——不同网络的优先级、延迟要求都不一样，你得在网关里做“翻译”和“调度”。
警告： 混合拓扑最大的坑是“跨网络延迟”。比如，一个以太网上的传感器数据，要通过网关转发到CAN网络上的执行器。这个过程中，网关的处理延迟、不同网络的时钟同步问题，都会影响QoS。我曾经遇到过一个案例：摄像头数据从以太网到CAN网关，延迟了50ms，导致自动紧急制动（AEB）系统误触发。后来加了TSN时钟同步，才把延迟降到5ms以内。
小结
好了，这一章的内容就这些。总结一下：
- 发展史： 从CAN到FlexRay再到以太网，带宽越来越大，QoS越来越强。
- 分类： 不同网络干不同的事，别指望一种总线包打天下。
- 拓扑： 总线型、星型、环型、混合型，各有优劣。QoS设计必须考虑拓扑结构。
下一章，我会深入讲QoS的核心概念——优先级、延迟、抖动、带宽。这些东西搞懂了，你才能理解后面的流量整形和调度算法。咱们下章见。