第2章车载网络架构演进

车载网络架构演进：从CAN/LIN到以太网，域控制器与中央计算架构

大家好，我是你们的老朋友。今天咱们聊聊车载网络架构的演进。说实话，我刚入行那会儿，车上能有个CAN总线就觉得挺高级了。现在呢？以太网、域控制器、中央计算平台，变化快得让人眼花缭乱。但别急，咱们一步步拆解。

先说说CAN总线。这东西在汽车里服役了三十多年，可靠性没得说。我当年调试第一个CAN项目时，拿着示波器看差分信号，心里还挺得意。CAN的特点就是实时性好、抗干扰强，特别适合动力系统和底盘控制这类对安全要求极高的场景。

但CAN也有短板。它的带宽最高也就1Mbps，而且报文长度有限。你想想看，现在一个智能座舱系统，光摄像头数据流就几百Mbps，CAN根本扛不住。LIN总线就更别提了，20kbps的速率，也就控制个车窗、后视镜啥的。

核心痛点：传统总线在带宽、灵活性和可扩展性上已经严重制约了汽车智能化的发展。

为什么会选择以太网？说白了，它成熟、便宜、带宽高。100BASE-T1就能跑100Mbps，1000BASE-T1更是能到1Gbps。而且以太网的生态太强大了，从物理层到应用层，各种协议栈随便选。

我记得有个项目，客户要求实现摄像头数据实时传输。用CAN？想都别想。最后我们上了100BASE-T1，配合AVB协议，延迟控制在2ms以内。嗯，这里要注意，车载以太网和普通以太网不太一样，它用的是单对差分线，不是标准的四对线。这是为了减重和降低成本。

避坑指南：我曾经在选型时忽略了车载以太网的PHY芯片对温度范围的要求。普通工业级芯片只能到85°C，而车规级要求-40°C到125°C。结果样机在高温测试时直接挂了。从那以后，我选芯片第一件事就是看温度等级。

传统架构是每个ECU管一个功能，比如一个ECU管车窗，一个管空调。这种分布式架构的缺点很明显：线束多、重量大、升级困难。你想想看，一辆豪华车可能有上百个ECU，光线束就几十公斤。

域控制器架构把功能按域划分，比如动力域、底盘域、座舱域、自动驾驶域。每个域有一个高性能控制器，负责该域内的所有功能。这样做的好处是：

我在做域控制器项目时，最头疼的是域间通信。不同域之间需要交换大量数据，比如自动驾驶域需要座舱域提供显示信息。这时候以太网的优势就体现出来了，用SOME/IP或者DDS协议，数据交换又快又灵活。

域控制器还不够，现在大家都在搞中央计算架构。说白了，就是把所有域控制器合并成一个超级大脑。这个超级大脑负责所有计算任务，包括自动驾驶、座舱娱乐、车身控制等等。

为什么这么做？因为域控制器之间还是有数据交换延迟。你想想看，自动驾驶系统需要融合摄像头、雷达、激光雷达的数据，如果这些数据在不同域控制器之间传来传去，延迟肯定受不了。中央计算架构把所有数据集中处理，延迟最低。

注意：中央计算架构对芯片算力要求极高。我见过一个方案，用了三颗英伟达Orin芯片，功耗接近200W。散热问题怎么解决？液冷？风冷？这都是实际工程中要面对的难题。

咱们用一张图来总结一下架构演进的脉络：

我参与过一个L3级自动驾驶项目，架构选型时争论了很久。最后我们选择了域控制器方案，因为中央计算架构当时还不够成熟。具体来说：

域间通信用的是千兆以太网，协议栈选了SOME/IP。说实话，调试SOME/IP的服务发现机制时，我踩了不少坑。比如服务发布和订阅的时序问题，如果顺序不对，客户端就收不到数据。后来我们加了一个心跳机制，才彻底解决。

小技巧：如果你也在做域控制器项目，建议先做通信矩阵设计。把所有需要交换的信号列出来，包括数据类型、周期、延迟要求。这样后面做协议栈配置时，心里就有底了。

我个人觉得，中央计算架构会是未来五到十年的主流。但不会一蹴而就，而是逐步演进。比如先做部分融合，把自动驾驶和座舱域合并，再慢慢把车身域也收进来。

另外，车载以太网也会继续升级。10BASE-T1S已经在路上了，专门针对传感器这类低带宽设备。还有TSN（时间敏感网络），能提供确定性的低延迟通信，这对自动驾驶来说太重要了。

嗯，今天就聊到这儿。架构演进这个话题，其实没有标准答案。关键是根据项目需求，选择最合适的方案。下次咱们聊聊具体的以太网协议栈实现，到时候见。