1. 车载电子电气架构演进：从分布式到域集中再到中央计算平台

大家好，我是你们这门课的老朋友。今天咱们聊聊车载电子电气架构的演进史。说实话，我入行那会儿，车上有个 CAN 总线就觉得挺先进了。十几年下来，架构的变化比我想象的快得多。

你想想看，一辆车从单纯的机械产品，变成现在四个轮子上的超级计算机，背后就是电子电气架构在撑腰。我个人习惯把这段历史分成三个阶段：分布式、域集中、中央计算平台。每个阶段都有它的时代背景，也有它绕不开的坑。

1.1 分布式架构：每个功能一个“大脑”

早期的车，功能很简单。车窗、门锁、雨刮、大灯，各干各的。每个功能配一个独立的 ECU（电子控制单元）。这就是分布式架构。

我记得 2010 年左右做的一个项目，一辆中端轿车，全车 ECU 数量轻松超过 30 个。每个 ECU 只管自己那一亩三分地，通过 CAN 总线或者 LIN 总线互相打个招呼。

架构特点

• 硬件独立：每个 ECU 有自己的 MCU、电源、外壳。说白了就是一个个小黑盒子。
• 软件固化：代码写死在芯片里，OTA？不存在的。升级得去 4S 店刷机。
• 信号直连：传感器信号直接进 ECU，ECU 输出直接驱动执行器。路径短，延迟低。

优势分析

• 故障隔离好：一个 ECU 挂了，不影响其他。我在项目里见过车窗控制器烧了，车照样能开。
• 开发简单：每个 ECU 的软件规模小，一个工程师就能搞定。团队管理成本低。
• 供应链成熟：供应商多，价格透明。采购部门最喜欢这种方案。

劣势分析

• 线束噩梦：这是最大的痛点。每个 ECU 都要供电、接地、走信号线。一辆豪华车的线束总长能超过 3 公里，重量 40 公斤以上。装配工人看到线束图都想哭。
• 算力浪费：每个 ECU 的 MCU 算力都不高，但加起来总算力不低。问题是它们不能共享。这边 CPU 闲着，那边 CPU 跑满了。
• 升级困难：想加个新功能？得加新 ECU。硬件改版、线束重走、软件重写。周期至少半年。
• 数据孤岛：ECU 之间只交换必要信号。想做整车级别的智能决策？门都没有。

1.2 域集中架构：把“大脑”合并成几个“部门”

随着功能越来越多，分布式架构撑不住了。尤其是智能座舱和辅助驾驶的出现，算力需求暴涨。这时候，行业开始思考：能不能把功能相似的 ECU 合并一下？

于是，域集中架构来了。整车被划分为几个域：动力域、底盘域、车身域、座舱域、智驾域。每个域有一个高性能的域控制器，负责该域内所有功能的计算和协调。

架构特点

• 算力集中：域控制器用高性能 SoC 或多核 MCU，算力是普通 ECU 的 10 倍以上。
• 区域划分：按功能域划分，不是按物理位置。动力域管发动机变速箱，座舱域管仪表中控。
• 以太网骨干：域之间用车载以太网连接，带宽从 CAN 的 1Mbps 提升到 100Mbps 甚至 1Gbps。

优势分析

• 线束大幅减少：传感器和执行器通过区域网关接入域控制器，不再需要每个 ECU 单独走线。
• 算力共享：域内算力可以动态分配。比如智驾域在高速巡航时，可以把多余算力给座舱域做渲染。
• 软件升级方便：域控制器支持 OTA。一个域升级不影响其他域。用户体验好多了。
• 功能协同：域内功能可以深度整合。比如自动泊车时，智驾域可以直接调用底盘域的转向和制动，延迟低很多。

劣势分析

• 域间通信瓶颈：跨域功能需要经过网关转发，延迟增加。比如自动紧急制动需要智驾域和底盘域协同，中间多了一跳。
• 单点故障风险：域控制器挂了，整个域的功能都瘫痪。我在项目里遇到过座舱域控死机，仪表黑屏、空调失控、音响无声。用户体验极差。
• 开发复杂度高：域控制器的软件规模大，需要 Hypervisor 做虚拟机隔离。团队需要懂 Linux、QNX、RTOS 多种系统。
• 成本不低：高性能 SoC 贵，DDR 内存贵，高速 PCB 板贵。一个域控的成本顶过去 5 个 ECU。

1.3 中央计算平台：一辆车一台“超级计算机”

到了 2020 年以后，行业开始卷中央计算平台。说白了，就是把所有域控制器再合并，变成一个或两个中央计算机。整车只有一个“大脑”。

为什么会这样？因为域集中架构虽然解决了线束问题，但域间通信的延迟和带宽还是不够。尤其是 L3 级以上自动驾驶，需要毫秒级的跨域协同。中央计算平台才是终极方案。

架构特点

• 超强算力：中央计算机用多颗高性能 SoC，总算力轻松超过 1000 TOPS。相当于几十台服务器。
• 区域网关：车辆按物理位置分成几个区域（左前、右前、左后、右后），每个区域有一个区域网关，负责采集传感器信号和驱动执行器。
• 软件定义：所有功能都是软件实现的。硬件平台统一，功能通过软件升级增减。
• 高速网络：中央计算机和区域网关之间用 10Gbps 以太网连接。内部用 PCIe 交换。

优势分析

• 线束最少：区域网关就近连接传感器和执行器，中央计算机只需要几根光纤。整车线束重量可以控制在 20 公斤以内。
• 算力极致利用：所有算力统一调度。智驾、座舱、车身、底盘的功能可以按需分配算力。不浪费一丁点。
• OTA 全车升级：一次升级可以更新所有功能。用户体验像手机一样。
• 数据闭环：所有传感器数据都汇聚到中央计算机。可以做整车级别的数据挖掘和模型训练。

劣势分析

• 单点故障致命：中央计算机挂了，整车瘫痪。必须做冗余设计。双机热备、三模冗余都是标配。成本翻倍。
• 散热挑战：1000 TOPS 的算力，功耗轻松超过 500W。液冷散热是必须的。我在项目里见过风冷方案，夏天跑半小时就降频。
• 软件开发地狱：所有功能跑在一个平台上，安全等级不同。ASIL-D 的制动和 ASIL-A 的娱乐系统要隔离。Hypervisor、容器、微服务全得上。
• 供应链重构：传统 Tier 1 供应商做不了中央计算机。需要芯片公司、软件公司、云服务商一起合作。生态复杂。

1.4 三阶段对比总结

说了这么多，咱们用一张表把三个阶段的差异理清楚。这样你面试或者做方案时，心里有数。

对比维度	分布式架构	域集中架构	中央计算平台
ECU 数量	30-100+	5-15	1-2
线束重量	40-60 kg	25-35 kg	15-20 kg
总算力	< 10 TOPS	50-200 TOPS	500-2000+ TOPS
网络骨干	CAN / LIN	CAN + 以太网	10G 以太网 + PCIe
OTA 能力	无	域级 OTA	整车 OTA
故障影响	单功能失效	单域失效	整车失效（需冗余）
开发复杂度	低	中	高
典型代表	传统燃油车	2018-2022 智能车	2023+ 新旗舰

1.5 架构演进的核心驱动力

你可能会问：为什么非要这么演进？说白了，三个字：降本增效。

• 降本：线束是整车成本的大头。分布式架构下线束成本占整车 BOM 的 5%-8%。中央计算平台能降到 2% 以下。
• 增效：算力集中后，软件迭代速度从半年一次变成一个月一次。功能上线快，用户体验好。
• 数据：只有中央计算平台才能把整车数据汇聚起来。没有数据，自动驾驶和智能座舱就是空中楼阁。

1.6 架构演进路线图（SVG）

下面这张图是我自己画的，把三个阶段的演进关系、关键变化和核心挑战都标出来了。你可以保存下来，面试或者做方案时直接参考。

1.7 我的建议

如果你现在要选架构方案，我给三个建议：

1. 别盲目追新：中央计算平台虽好，但成本高、风险大。如果你的产品定位是 15 万以下的经济型车，域集中架构更务实。
2. 预留升级空间：不管选哪种架构，网络带宽和算力一定要留余量。我见过太多项目，因为当初省了几块钱的以太网芯片，后来想加功能发现带宽不够，只能重新改版。
3. 重视软件架构：硬件架构变了，软件架构必须跟上。别用分布式时代的思路做中央计算平台的软件。微服务、容器、SOA 这些概念，早点引入早点受益。