第三代E/E架构：从域控制器到中央计算，智能汽车的硬件革命

1. 从“分布式”到“集中式”为什么我们需要第三代E/E架构聊到智能汽车大家现在张口闭口都是“算力”、“芯片”、“软件定义”。但如果你问一个干了十几年的汽车电子工程师这两年最让他“脱发”的底层变革是什么十有八九他会告诉你是E/E架构的换代。这玩意儿才是决定一辆车智能上限的“骨架”和“神经系统”。今天我就以一个过来人的视角掰开揉碎了讲讲这被炒得火热的“第三代E/E架构”到底是怎么回事它凭什么能成为智能汽车的“必答题”。简单说E/E架构就是整辆车的电子电气系统的总布置方案。它定义了各个电子控制单元ECU怎么放、怎么连、怎么协同工作。你可以把它想象成一家公司的组织架构图。第一代架构就像一个小作坊老板ECU管所有事但规模小效率低。第二代架构像是一个初具规模的公司设立了市场部、技术部、销售部等各个部门功能域部门内部沟通顺畅但跨部门协作就得层层审批效率不高还容易扯皮。而第三代架构的目标是打造一个高度扁平化、反应敏捷的“超级大脑”型组织。为什么非得这么折腾因为老架构扛不住了。一辆传统的豪华燃油车里面的ECU可能超过100个线束长度好几公里总重几十公斤。每个ECU由不同的供应商开发软件和硬件深度耦合。你想增加一个“开门迎宾灯联动空调自动调温”的小功能对不起可能涉及车身域、空调域等多个ECU需要协调多家供应商开发测试周期以“年”计成本高到吓人。这完全无法适应现在汽车软件快速迭代、功能持续进化的需求。所以架构升级不是“锦上添花”而是“迫在眉睫”。2. 核心设计思路从“功能域”到“区域”的范式转移2.1 域控制器的得与失第二代架构的过渡使命在深入第三代之前必须得先理解它的前身——基于域控制器的第二代E/E架构。这大概是2015-2020年间的主流方案也是目前很多在售智能电动车的“大脑”。它的核心思想是“功能整合”。按照汽车的功能划分设立了几个大的“域”动力域管电机、电池、整车控制。底盘域管刹车、转向、悬挂。车身域管车门、车窗、灯光、空调。智驾域管自动驾驶相关的传感器融合和决策。座舱域管中控大屏、仪表盘、语音交互。每个域有一个或几个性能较强的“域控制器”DCU它负责接管这个域内原来那些分散的、功能单一的ECU的任务。比如一个车身域控制器可能就替代了十几个分别控制车窗、门锁、雨刮的独立ECU。这么干的好处很明显硬件资源复用算力集中了不用每个小功能都配一个芯片降低了BOM成本。软件开始解耦在域控制器层面可以尝试将基础软件如AutoSAR与应用软件分离为OTA升级创造了条件。功能集成度高域内功能联动变得容易比如解锁车门时自动点亮内饰灯、调节座椅位置。但它的“天花板”也很低跨域协同依然是瓶颈智驾域想调用车身域的一个摄像头数据或者座舱域想和底盘域共享导航信息依然需要跨域通信延迟和带宽问题没有根本解决。线束复杂度未减反增虽然域内简化了但各个强大的域控制器之间需要高速互联如以太网同时为了可靠性大量的传感器、执行器依然需要直接拉到各自的域控制器线束拓扑并没有变得简单。算力孤岛智驾域芯片算力300TOPS闲的时候也不能帮座舱域干点活资源无法动态调配浪费严重。供应链依然复杂博世、大陆、安波福等Tier1巨头各自把持着不同域的控制器主机厂想要实现深度的、跨域的创新功能协调成本依然巨大。所以域控制器架构是一个伟大的过渡但它只是把“诸侯割据”变成了“几大藩王”并没有实现真正的“中央集权”。而第三代架构就是要解决这个问题。2.2 区域控制器的登场硬件拓扑的物理革命第三代E/E架构最标志性的特征就是引入了“区域控制器”Zonal Controller 简称ZCU。这是一个根本性的硬件拓扑变革。它的思路不再是按“功能”划分而是按“物理位置”划分。一辆车通常被划分为几个物理区域左前、右前、左后、右后可能再加一个中央区域。每个区域部署一个区域控制器。这个区域控制器是干嘛的它主要干三件事接线盒Gateway它是这个区域内所有电子部件的“总接线员”。原来分散在各个域控制器的线束现在都就近接入本区域的ZCU。大灯、车门模块、雷达、座椅传感器……只要是这个地盘上的“设备”线都先接到ZCU。这带来了革命性的变化线束长度和复杂度大幅降低。线束从复杂的树状、网状结构变成了清晰的星型结构从ZCU出发辐射到区域内各个设备。业内数据显示这能让线束总长度减少20%以上重量减轻成本降低装配也更简单。数据路由器RouterZCU负责本区域所有数据的汇总和转发。传感器数据、执行器指令都通过ZCU统一上传到中央计算单元或者转发给其他区域的ZCU。它实现了车内通信网络的“区域化”和“标准化”为整车高速通信 backbone如千兆/万兆以太网提供了理想的接入点。轻量级执行者Executor一些对算力和实时性要求不高的简单逻辑控制比如根据信号控制某个继电器的通断可以直接在ZCU上完成无需上报中央降低了中央的负载和通信延迟。 注意区域控制器不是简单地取代了原来的车身控制器BCM。BCM是一个功能域控制器而ZCU是一个地理区域的“网关”和“集线器”它的首要任务是简化线束和通信其次才是承载部分控制功能。很多方案里传统BCM的功能会被拆分一部分融入ZCU另一部分更复杂的逻辑则上移到中央计算单元。2.3 中央计算的终极大脑软件定义汽车的基石如果说区域控制器是“四肢”和“神经末梢”的整合者那么中央计算单元Central Computing Unit 简称CCU或VCU就是整个架构的“大脑”和“心脏”。这是第三代架构在计算层面的核心。在理想状态下整车只会有一个或少数几个如2-3个高性能的中央计算平台。它可能由多个不同算力的SoC系统级芯片组成通过芯片间高速互联形成一个算力池。这个中央大脑要干什么承载所有高阶功能智能驾驶、智能座舱、整车控制、通信网关等所有需要高算力的软件全部运行在这个统一的硬件平台上。智驾的感知算法和座舱的3D渲染游戏可能跑在同一块芯片的不同核上。实现真正的软硬解耦硬件是标准的、通用的计算平台比如基于英伟达Orin、高通骁龙Ride Flex等。所有功能都变成了运行在这个平台上的“软件App”。主机厂和软件供应商可以专注于开发软件而不用再为每一个功能去定制一块硬件。这才是“软件定义汽车”的终极形态。动态分配算力资源通过虚拟化技术如Hypervisor中央计算平台可以动态地为不同功能分配计算、存储和网络资源。白天行车时算力向智驾倾斜晚上停车时算力可以用于车辆自检、深度学习模型训练。资源利用率达到最大化。全局数据融合与决策所有区域的数据摄像头、雷达、车身状态、用户交互都汇聚于此使得基于全车数据的融合感知和协同决策成为可能。例如基于导航、车身姿态和智驾感知的综合信息做出更平滑、更舒适的驾驶规划。第三代架构的完整画像就是一个或几个强大的中央计算大脑CCU通过高速骨干网以太网连接着数个负责物理接线和基础控制的区域控制器ZCU再由ZCU去连接最终的执行器和传感器。从“功能域”到“区域中央”这是从设计哲学到工程实现的全面革新。3. 实现路径与关键技术拆解理想很丰满现实怎么干知道了目标长什么样下一步就是怎么实现。这里面每一步都是坑都需要关键技术的突破。3.1 通信网络的升级从CAN到以太网的“血管”革命老旧的CAN/LIN总线就像乡间小道而第三代架构需要的是“信息高速公路”。车载以太网是唯一的选择尤其是时间敏感网络TSN技术。为什么必须是以太网高带宽千兆1Gbps甚至万兆10Gbps的带宽才能满足摄像头、激光雷达海量数据以及中央与区域间高速交互的需求。传统CAN最高才1Mbps差了三个数量级。统一协议以太网是IT行业的基石协议栈统一生态成熟有利于实现车内网络与车外云端的无缝连接。成本趋势随着规模应用车载以太网芯片和线束单对非屏蔽双绞线的成本正在快速下降。TSN为什么是关键传统以太网是“尽力而为”的数据包可能延迟、可能丢失。但汽车控制指令如刹车、转向必须准时、可靠。TSN就是一套为以太网增加“确定性”的协议族。它能保证高优先级的数据流如刹车信号拥有固定的带宽和极低的延迟就像在高速公路上开辟了不允许变道的“应急车道”。没有TSN中央集中控制就无从谈起。实操心得网络拓扑设计是难点。通常采用“骨干-接入”两层结构。中央计算单元之间、中央与区域控制器之间用高速以太网带TSN组成环形或星型骨干网保证冗余和可靠性。区域控制器到本地执行器/传感器可以保留部分CAN/LIN或使用更低速的以太网。这里最容易踩的坑是网络负载估算不足一定要在架构设计初期就用工具模拟最极端的数据流场景比如所有摄像头全开激光雷达点云多屏4K视频流确保骨干网带宽有足够余量通常建议峰值利用率不超过70%。3.2 软件架构的重构SOA与虚拟化硬件集中了软件也必须跟着“搬家”和“重组”。这里两大核心技术是服务导向架构SOA和虚拟化Hypervisor。SOA把功能变成可调用的“服务”以前的功能是写在固定ECU里的死代码。SOA的思想是把每个功能如“获取车速”、“开启空调”、“播放音乐”都封装成一个独立的、标准化的“服务”。这些服务发布到整车软件平台上其他任何有权限的软件组件都可以像点外卖一样“订阅”和“调用”这些服务。好处极大提升了软件的可复用性和灵活性。开发一个新功能不再需要知道硬件在哪只需要调用已有的“车速服务”、“导航服务”、“空调服务”进行组合。这为个性化功能、第三方应用生态打开了大门。实现通常基于 SOME/IP 或 DDS 这类车载中间件协议来实现服务的发现、订阅和通信。虚拟化让一个硬件同时跑多个“系统”中央计算单元硬件只有一套但上面要同时运行实时性要求极高的自动驾驶系统QNX或AUTOSAR CP、对生态要求丰富的座舱系统Android/Linux、以及负责整车控制的系统。它们对安全性、实时性的要求截然不同绝不能互相干扰。Hypervisor的作用它就像一个“超级管家”在物理硬件之上创建出多个相互隔离的“虚拟机”。每个虚拟机可以独立运行不同的操作系统和应用程序。智驾系统崩溃了不会影响座舱大屏的正常显示。这是实现功能安全ASIL隔离和资源灵活调配的基础。选型考量目前主流的车载Hypervisor有QNX Hypervisor、ACRN、PikeOS等。选择时不仅要看性能开销通常5%更要看其对功能安全等级如ASIL-D认证的支持以及芯片厂商如英伟达、高通的适配和优化程度。3.3 开发模式与供应链的颠覆架构的变革最终会传导到人和组织。主机厂角色巨变从“集成商”转向“主导者”和“软件开发商”。主机厂必须建立强大的软件中心掌握中央计算平台的系统软件OS、中间件、Hypervisor集成能力甚至自研核心应用算法。否则就会把“大脑”的控制权拱手让人。供应商格局重塑传统的分布式ECU供应商面临转型压力他们的硬件制造优势仍在但价值会向区域控制器ZCU这种“机电软”高度集成的部件转移。而芯片厂商如英伟达、高通、英飞凌、软件公司如黑莓、风河、以及新兴的Tier0.5提供全栈软硬件方案如华为、大疆话语权将大大增强。开发流程变革传统的V模型开发流程受到挑战需要引入更多敏捷开发、持续集成/持续部署CI/CD的理念。基于SOA不同团队可以并行开发服务最后在中央平台上集成测试。仿真测试如车辆模型、传感器模型在环的比重会越来越大以应对软件复杂度指数级增长。4. 挑战、误区与未来展望这条路好走吗第三代架构是方向但通往终点的路上布满荆棘。4.1 当前面临的主要挑战成本与规模的悖论初期中央计算平台和区域控制器的研发成本极高只有高端车型才用得起。而只有达到大规模量产芯片、软件的成本才能摊薄。如何度过这个“死亡谷”是对主机厂战略定力和资金实力的考验。功能安全的复杂性所有功能集中在一个或几个盒子里一旦中央计算单元失效后果可能是灾难性的。如何设计冗余如双中央计算单元互为备份、如何通过虚拟化和硬件隔离确保不同安全等级的功能互不干扰是工程上最严峻的挑战。这涉及到芯片级、系统级、软件级的全方位安全设计。软件复杂度的管理整车代码量将从现在的数千万行激增至数亿行成为一个移动的超级复杂信息系统。软件架构设计、代码质量、测试验证、OTA升级管理的难度都是空前的。没有强大的软件工程能力和体系根本无法驾驭。产业链协同的难度这需要芯片、软件、网络、主机厂、甚至操作系统厂商前所未有的深度协作。标准如何统一接口如何定义责任如何划分都是需要行业共同解决的难题。4.2 常见的认知误区误区一第三代架构就是完全取消所有ECU。不对。执行器层面如电机驱动器、阀门控制器依然会有很多专用的、低成本的ECU常被称为“智能执行器”。第三代架构是减少“决策型”ECU而不是“执行型”ECU。误区二马上就能实现“一个大脑”控制一切。这是一个渐进的过程。行业普遍认同会经历“域融合”如智驾域和座舱域融合、“跨域融合”最后才是“中央计算”。目前大多数宣称第三代架构的车型实际上处于“多域控制器区域控制器”的混合过渡阶段。误区三用了区域控制器就一定能大幅降本。短期内未必。ZCU本身的成本、新的高速网络成本、软件开发成本可能高于节省的线束和传统ECU成本。降本效应要在全生命周期、尤其是后续软件迭代和功能扩展中才能体现出来。4.3 未来演进方向从我个人的观察来看第三代架构之后演进不会停止“中央计算区域控制”的形态固化这将成为未来10年智能汽车的主流架构范式。竞争焦点将从“有没有”转向“好不好”即中央算力的效率、软件平台的易用性、开发工具的成熟度。车云一体协同计算车载中央计算负责实时性要求高的任务而大量的数据训练、复杂场景仿真、高精地图生成等非实时任务将转移到云端。车端与云端算力协同调度形成“分布式异构计算网络”。硬件标准化与软件生态化中央计算平台的硬件可能逐渐趋同像今天的PC一样基于少数几个主流芯片平台。核心竞争力将完全落在软件和生态上。谁能构建更繁荣的车上应用生态谁就能赢得用户。跨车协同与车路协同当单车智能的架构稳定后车辆与车辆V2V、车辆与基础设施V2I之间的通信与协同将成为新的架构扩展点。E/E架构可能需要考虑如何高效、安全地接入更广域的协同网络。说到底第三代E/E架构不仅仅是一次技术升级它是一场关于汽车产品定义、研发体系、供应链关系和商业模式的深刻革命。它把汽车从一台“功能机”变成了“智能终端”而这场变革才刚刚拉开序幕。对于我们这些从业者而言理解它、适应它、参与构建它是未来十年最重要的课题。