笔者在智能电动汽车控制器开发领域从业近6年时间，很幸运地经历了智能电动汽车整车EE架构技术发展的三个时代：1.0时代——分布式EE架构；2.0时代——域控EE架构；3.0时代——中央-区域EE架构。

在过去三年，笔者反复思考一个问题：整车EE架构&控制器未来会向什么方向发展，现在做的工作未来会不会被淘汰掉？在跟行业内大量的技术专家、研发工程师、产品经理、营销人员、战略决策者、投资经理等各个角色的深入交流后，笔者得到了这个问题的“阶段性答案”。

在此，我将用简洁、准确的语言和示意图，为大家描绘出这张蓝图，也期待这张蓝图能成为大家讨论、议论、争论的base，让真理越辩越明。

本文首先会简短地介绍下汽车EE架构进化的历史，提炼出EE架构进化的原生驱动力；接下来会详细阐述在EE架构2.0时代OEM的主要痛点，进而明确“中央-区域是EE架构进化的必然方向”；然后，会描绘EE架构3.0时代的蓝图。

EE架构3.0时代初级阶段的蓝图在汽车行业已基本达成共识了（参考阅读《博世：未来汽车电子电气架构趋势》），也有很多前辈的优秀文章介绍。为了节省读者的时间，笔者会将重心放在对EE架构3.0时代终极阶段蓝图的描绘上；然后会阐述EE架构3.0时代的终极阶段是如何解决2.0时代的痛点问题；最后是畅想的内容——率先进入3.0时代终极阶段的OEM对尚停留在2.0/3.0时代初级阶段的OEM实施降维打击的图景。

由于信息量很大，有很多内容并不是那么容易消化，所以，平心静气或心浮气躁地阅读此文，吸收效果可能会有云泥之别。因此，建议读者拿出1~2小时可以静下心来思考的整段时间来阅读这篇文章。

在这一阶段，EE架构演化的主要驱动力是：功能增加->控制器增加->带宽不足->增加网络&增加网关。

在这一阶段，EE架构演化的主要驱动力是：功能增加–>控制器增加–>域内、跨域交互信息增加–>带宽不足–>CAN通讯与低性能控制器无法承载功能需求–>总线技术进步＆MCU性能提升＆SOC性能提升–>每个功能域自发地出现了功能的集中化，出现整车的局部中心——域控制器。

总结一下，前两代EE架构进化的原生驱动力，主要源于功能增长和性能需求。

在2.0域控时代，“质量、周期、成本不可能同时被满足”这个客观规律可能被很多人忽视掉了，尤其被很多项目组领导忽视掉了，这才有了一些“既要又要也要”的决策，当然，这些决策实际上都违背了客观规律。

笔者在做项目时，对“质量、周期、成本是不可能三角形”这个概念有很深刻的体会。

质量、周期、成本的不可能三角形

时间就是新势力的生命线。

老牌外资车企，在智能电动汽车产品落地的进展上，几年前就被国内的新势力超越，并且被拉开差距的速度仍在扩大。比如：

某新势力OEM凭借先发优势，曾在智能座舱、智能驾驶处于行业领先位置，但是智能座舱目前已经被鸿蒙OS、FlymeOS追上并超越，智驾功能的落地也已经落后了华为、小鹏一截。

有什么新功能、新功能何时上线、竞品的killer Function上线后，要多久能做出60分产品、多久能达到同等水平的用户体验？在中国汽车市场高烈度刺刀战的大环境下，时间就是生命线，当消费者的心智认定某家OEM的产品“功能少、更新慢、bug修复慢、很多新颖、实用的功能都没有”时，这家OEM就会从“新”势力变为“旧”势力，maybe未老先衰。

为了方便读者理解，笔者希望引入“分子周期”、“原子周期”这两个概念。

对于整车软件开发，从功能设计idea的提出到做出一版软件的时间，可以称其为“分子周期”。从整车级功能需求、子系统需求，控制器级系统需求、软件需求、软件架构、软件详设、单元测试、软件集成测试、系统合格性测试，整车级集成测试，到功能validation，每一个软件开发必不可少且不可分割的环节，可以称其为“原子周期”。

对于分布式控制的整车EE架构，当实现一个功能需要多个团队价值观、工作风格、团队素养甚至时差都不同的团队共同完成，且不同模块均为了技术保密or能力不足而实施软件需求、软件架构级的黑盒交付，且OEM缺乏高水平高素质的“灵魂人物”『架构师』的时候，可以想见，这个“分子周期”会有多长。

在这个“分子周期”中，时间的大头消耗在了哪里呢？

各个团队的软件开发人员都在做盲人摸象式的开发，没有人知道大象的全貌，每个人对来自上一级的需求都难免存在误读，当到了整车级集成测试时，大家会发现，发现多个团队生产的“零件”不是你多了就是我少了，根本拼凑不到一起去！

并且，由于整车项目管理人员缺乏技术功底，没能力评判问题的根因在哪个团队，在技术争论上无法做出正确的裁决，然后就开始比拼哪个项目经理、哪个部门领导更有扯皮功底和抗压能力，最后造车不是“谁错了谁改”，而是“谁‘好说话’，谁改变”，然后弱势的一方修改软件，做出一个犬牙差互的软件产品。

这个过程，是极其消耗时间的，并且会导致软件在整个生命周期内的维护成本极高，越来越难修改，到项目生命周期的中期以后，想修改/新增一个新功能的开发周期会越来越长，长到让整车项目组都无法理解的情况。

这里引用《架构简洁之道》一书里介绍乱码系统特点的一幅图片：随着软件版本的迭代，工程师并没有偷懒，但是平均生产力却在下降——疲于修改bug、疲于救火。

PS：这还没算validation时发现“大象画成了长颈鹿，鼻子长在脖子上”时，要重新走一遍“分子周期”所耗费的时间；或者功能设计的idea本身就有问题，要重新变更整车级系统需求的情况。

质量是在新势力车企里最容易被忽视的一个角度，一个全新的车型从立项到量产的时间，从合资时代的5年压缩至自主品牌时代的3年，再到新势力时代的2年甚至18个月，冬标、夏标、耐久验证的周期被极大压缩，很多车型量产时都是带着潜在bug交付的。很多功能都是尚不成熟的产品，先上线交付，再慢慢暴露bug、修改bug。

比如，某新势力在OTA推送有bug后，第二天紧急又推送一版OTA来修复bug；再比如，某传统车企孵化的新势力在OTA时，批量出现了仪表不显示车速和挡位的问题。

基于上文提到的开发周期原因和多团队协作开发原因，对于域控制器，首版软件集成出来的时间离该研发阶段首次交样的时间就很接近了，测试出来的问题，每次修改都极其匆忙；并且，当团队leader失去话语权时，由于每修改一个bug就需要紧急出一版软件，开发节奏就会完全被打乱。

可以想见，软件开发部门或者tier1 给EE测试/项目组频繁交付软件（一次OTA可能涉及五六次到十几次软件交付），带来的后果必然是，每版软件的开发流程都是“突破规则”的紧急变更，多数步骤的动作都走样了，压下葫芦翘起瓢，测试又没有覆盖到“瓢”，最后陷入“bug多-频繁交付-改出更多bug-频率更高的频繁交付”这一螺旋下降的恶性循环。

成本不必多说，看下各个新势力的财报，一目了然。让我们再回看一下前面说的“不可能三角”——当前，那些新势力车企，开发实力处于第二等级的玩家至少要保证开发周期，第一等级的玩家则会同时保证开发周期和质量， 那无论哪种情况，成本通常都是被牺牲的那个维度。

在此，我们引用《架构简洁之道》一书的另一幅图片：乱码系统的开发维护成本——

这张图，大家可以跟上一幅图放在一起对照着看，假如你是部门经理，看到团队人员越来越多、工资支出越来越多，但是产出却越来越小，你会不会很着急、想找到办法改变这个局面？

23年年底，从问界M7降价7万元上市，到智界S7、极氪007、大众ID7、银河E8相继发布封锁纯电中级轿车定价体系，再到元旦前比亚迪全系降价1~2万、春节后秦plus phev血降到7.98w、6.98w“一扫六合”，智能电动汽车的价格战已然进入“刀刀见血”的白刃战，成本控制对于OEM已经不是“活得好不好”的问题，而是“能否活下来，资本家是否还有必要继续投入”的问题了。

对于OEM来说，实现新功能的质量、周期、成本，一定是既要又要也要的状态，那么，前面提到的“不可能三角”是否有可能被打破呢？让我们一起来了解一下EE架构3.0时代。

接下来，笔者将为大家描绘一下这两张蓝图，跟大家一起看看3.0时代的EE架构长什么样。

1. EE架构3.0时代的初级阶段

随着特斯拉model3的问世，行业人士突然发现特斯拉基于第一性原理设计出的创新的左、右车身区域控制器的好处，以及将智能座舱、智能驾驶放在onebox里，全栈自研的好处。

大家初步分析的好处主要有：线束简洁节省成本、控制器与线束易于装配维修、线束节省的重量可以增加纯电续航里程或减小电池包继从而降低用户购车成本。后面，随着特斯拉OTA更新软件，不断增加新功能，行业发现这套EE架构对功能增长的便利性、对OEM掌握在“软件定义汽车”时代的自主权，有非常大的优势。

在EE架构3.0时代的初级阶段，中央计算平台分如下三种形态：

2. EE架构3.0时代终极阶段

在3.0时代的终极阶段，硬件架构和初级阶段的One Chip方案是一模一样的。终极阶段跟初级阶段真正的区别不在于硬件，而在于整车级的软件架构、灵魂——One OS，One Soul。

RTI 中央-区域EE架构

2.1 One OS

One OS可以参考windows 11。在Winwos 11中，Microsoft已经实现将CPU、SOC、GPU、NPU、MCU、ASIC的运算能力封装进一个OS，给App提供API接口，灵活高效地调用不同逻辑电路的运算能力与功耗控制。

智能汽车One OS简版软件架构图

为了方便读者理解，这张图片简化了功能安全分区、信息安全岛等概念。

智能汽车上的One OS可以参考上图：One OS所封装的硬件，不应该仅局限在单芯片或者单控制器，而是要封装区域控制器、中央计算平台的全部硬件及车辆所有的传感器、执行器、智能传感执行器；智能汽车的应用层软件，应该部署在中央计算平台或云端；One OS则应该为应用层提供具备调用整车全部硬件能力的API接口。

当然，与用户生命安全、隐私相关的API接口，一定要有功能安全、信息安全的保护与用户的授权才能授权App调用。

2.2 One Soul

One Soul，比较难描述，更难理解，这部分内容要靠读者去意会了。在此，笔者想问读者一个哲学问题——“你相信人类有灵魂吗？”

笔者写这篇文章时，在这里卡滞了很久，话语的力量太薄弱了，一维文字和二维图片，要怎么样描绘出“灵魂”呢。这是mission impossible，后来想通了，笔者能做到的，是将它的一维和二维的投影描绘出来，尽力多描绘几个投影角度和侧面，以便大家理解。

为便于大家更好地理解多个灵魂与1个灵魂的区别与联系，在描述这个很抽象的蓝图前，笔者推荐大家读三篇文章：

1、九个脑子的拥有者——章鱼https://mp.weixin.qq.com/s/-zP73YaM9mhcLr_kOhWrjw

2、章鱼9个大脑能编辑基因，智商高到无法理解，为啥没发展出文明？https://mp.weixin.qq.com/s/QuUuI7fMA81l9duKBbUVxA

3、这类动物连天灵盖都没有，却聪明得让人害怕https://mp.weixin.qq.com/s/abJef3AM1PaSI3qZO3Tg5A?poc_token=HAupyWWjt0HVHJ4JDDKTSOBBOWlhP2bADCSdvDhC

接下来，为便于大家从仿生学的层面来看一下EE架构3.0时代的终极形态是怎样的，笔者将人体器官和智能汽车的控制器做了一个功能对照表：

交感神经、副交感神经对人体器官的控制

大家可以将章鱼和人类的图片并排放在一起品悟一下，想一想3.0时代的初级阶段和终极阶段的差别与联系在哪里。建议有一个初步的答案后，再往下看。

接下来，笔者来做个解读。

章鱼有1个中央大脑和8个分布式大脑，中央大脑占了神经元的40%，分布式大脑占了神经元的60%，类似的是，在智能汽车EE架构3.0时代的初级阶段，尽管中央计算平台表面上已经形成了比较可观的集中，但是仍然存在诸多问题，这些问题，导致软件层面仍然是“分布式控制”。

具体地说，由于在不同的开发团队之间存在信息孤岛，并且在合作的过程中彼此缺乏信任，因此，会存在很多原来独立做控制器的团队不愿意将算法上移至中央计算平台、只允许黑盒交付并限制开发信息的共享、更不用说对原有软件架构做合理化的拆分与有机合并、重组。

可见，软件架构的变化往往伴随着组织架构的变化，软件的拆分重组伴随着开发人员的变动，显而易见的，原来团队的领导的权力与利益会受到冲击，因而，技术的架构会被权力的架构扭曲、变形，技术架构不得不向权力架构妥协。

所以，在EE架构3.0时代的初级阶段，软件架构，更像是一个一个黑盒子软件用胶水黏在一起，硬件虽然少了，但是软件架构层面仍然是分布式控制，只不过从不同的控制器里挪到了同一个PCB板上的差别。

EE架构3.0时代的终极形态，就像是一个真的人一样：理解、思考、决策、平衡与运动控制，都在中央计算平台里，各个计算单元都使用高速通讯的“神经元”连接打通，信息的流动畅通无阻，开放共享，各部分软件是有机高效地组合的，没有冗余、相互干涉的部分，区域控制器最重要的任务是做好传感器信息的收集与上传、执行指令的下发、硬件驱动控制、供电控制的功能；区域控制器也会像交感神经副交感神经一样，承接一部分无需告知中央计算平台就可以完成决策执行的算法，以保证快速反应、延迟最小化、减少中央计算平台的运算负荷。

一千个读者眼里有一千个哈姆雷特，读到这里，也许每个读者对于One Soul的理解都不尽相同，没关系，时间会给我们答案。现在，请准许笔者对One Soul作个“建筑师版”的诠释：

“One Soul” 其实是我在准备这篇文章时，突然从脑子里面蹦出来的一个词，我觉得挺贴切的，就使用了。

我的理解是，One Soul的对立面是多个Soul、精神分裂，像现在的分布式控制就是精神分裂的，多个团队，无中心化的开发，各有各的想法，就会做出精神分裂的产品。举个极端的、让人发笑的真实例子：

在智驾、智能座舱，这种精神分裂的现象其实也很明显，很多功能如果融合到一起做，会有更好的用户体验，但不同团队之间协作、配合不足，做出来的产品用户体验就很糟糕。

One soul，我觉得是一个“中心化团队”驱动整车软件开发，“其他团队”心甘情愿地配合中心团队，心往一处想、劲往一处使，共同下一盘棋，在高等级的协作、团队融合后，用心打磨出来的协调如一的产品。”

2.3 EE架构3.0时代终极阶段的其他典型特征

整车ECU数量会从100+降到10个左右，所有控制器的软件都会重新洗牌、重组，达到运算成本最低、效率最高、延迟最低、性能最好的状态。

现有功能的整车级功能需求不变，整车子系统级的需求，会SOA化重构，实现“控制”和“逻辑”的分离（援引《架构简洁之道》推荐序一，“所谓控制就是对程序流转的与业务逻辑无关的代码或系统的控制，所谓逻辑则是实实在在的业务逻辑，是解决用户问题的逻辑”）。

届时，车辆量产以后，绝大部分功能的新增或变更，都可通中央计算平台上的软件OTA升级来解决，只有极少部分需要涉及到区域控制器，而传感器、执行器、智能传感执行器在量产后全生命周期几乎无需做软件变更（但是部分会保留OTA能力，应对潜在bug或未知功能）。

中央计算平台上的CPU、GPU、NPU的算力，将遵循新摩尔定律，驱动新产品的迭代。芯片算力决定了软件运行的性能，因此，算力将会和硬件功能（如屏幕、沙发、音响、外置屏幕）、工业设计一起会成为用户购买新车的强驱动力。

搭载高算力的智能电动汽车还会成为AI时代的基础设施。高算力智能电动车与云端服务器的概念会模糊化，服务器为车提供云端算力，车也可以成为远端服务器，算力可以像比特币以太坊挖矿一样地出租赚钱，将停车时的闲置算力出租出去，只要赚的钱大于电费及硬件折旧成本，就会有很多用户愿意做这件事。

算力的出租对象将包含其他智能电动汽车、提供大模型AI服务的公司、AI计算的需求者，形成类似于太阳能发电-分布式电网的分布式AI算力网络。

看一下最近的AI产业新闻，“Sam Altman大胆地提出要筹集7万亿美元搭建超级AI计算平台”，周鸿祎在讨论sora中国自主开发的难度时，谈到“目前国内所有人工智能公司加在一起可能有50万块GPU，但这些GPU都分散在各个公司里；相比之下，Meta已经有50万块GPU，并计划明年购买更多，微软也有相似的规模；这说明国内大模型企业在算力资源上面临巨大的压力”。中国每年生产汽车3000w辆，如果高算力智能电动汽车与低算力的比例达到1:2，粗算一下，每年中国新增的GPU数量将达到现存的20倍，智能电动汽车将是AI时代最重要的基础设施之一。

2.4 通用人形机器人的预言

一个更有想象力的角度：让我们再回到仿生学的图片思考一下，EE架构3.0时代终极阶段的智能电动汽车像不像一个“机器人”？

只不过这个“机器人”的脚是车轮、手是几个舒服的大沙发、用户是坐在“机器人”的怀抱里使用它提供的服务；这个“机器人”除了把你从A点送到B点，还可以和你对话交流，帮你点外卖、订票、介绍热点新闻、讲段子、一起玩双人游戏；它还可以写邮件、制定日程、查资料、制作工作总结PPT，甚至还可以和你探讨如何给另一半制造惊喜，或者如何教育下一代，或者陪着你city walk、健身远足，在你走累了、达到体能极限时安全地接你回家。

如果说智能手机是人们接入“数字世界”的第1个入口，那么智能电动汽车就是第2个入口，而“通用人形机器人”将会是第3个入口。

在未来，低成本民用型“通用人形机器人”，也许会与智能电动汽车共用同一套EE架构，共用同一套芯片，共用同一套云服务器，共用同一套APP算法，共用同一套用户大数据。这将是Tesla、华为、小米、Apple、Google、Microsoft、Facebook、Amazon十年后商业竞争的主战场。谁能把握住当下，谁就拥有未来的入场券。

在理解了EE架构3.0时代终极阶段的技术形式与团队合作方式后，我们会发现，显而易见，2.0时代的痛点都可以迎刃而解——“不可能三角形”会因为颠覆性的技术进步而变得可能。

“原子周期”不变；“分子周期”将大幅度缩短——由于更先进的EE架构&SOA特性，新功能无需重复开发“控制”软件，仅需开发大小脑的“逻辑”软件。因此，汽车软件研发将实现真正意义上的“敏捷开发”，单个功能可以实现开发team轻量化，story写出后快速做出软件，产品经理validation后即可快速迭代。

区域控制器以下部分的变更极少，多项目100%复用或裁剪复用，中央计算平台里的“控制”软件也可高度复用。解耦后的软件架构，新增功能或变更功能苏产生的影响，将更容易准确全面地分析。

终极形态下，控制器成本、软件新增功能成本、软件变更成本、测试成本等均会大幅度下降。

这一部分是畅想。

很多人在讨论软件定义汽车的话题时，都会拿诺基亚和柯达类比传统汽车、拿苹果和安卓类比智能汽车，不过近几个月，有一种悲观的声音在不断放大——

关于这个话题，笔者持乐观的态度。笔者相信，EE架构3.0时代的终极形态会以技术手段实现降本增效，量变形成质变。

智能电动汽车是一个大的平台，除了上文提到的分布式算力中心，汽车拥有非常多的传感器和执行器，具有24h供电online的能力，而当前的EE架构与分布式控制功能架构限制了传感器、执行器的数据、算法、控制的打通，就好像放在同一个容器内的多种化学原料被薄膜隔开；那么，当薄膜融化时，化学反应会诞生出什么样的产物，nobody knows。

既然是畅想部分，既然很多人在失去信心，让笔者来贡献2个智能汽车killer app的idea吧，给大家一点启发与信心。

第一个killer app：调用遍布全国甚至全世界的车辆的温湿度传感器、摄像头、激光雷达、毫米波雷达、超声波雷达、电机转速实时采集的数据（数据脱敏&合法合规），上传到气象预测大模型，将实现当地是否会下雨/极端天气的秒级精确预测，回传至手机/车机通知用户，也可以传递至导航APP，提前告知用户前方路况：“长江大桥天上掉冰柱”、哪里会下冰雹、哪里会下冻雨、哪里路面会打滑、哪里会有团雾，并为用户提供安全行驶路线，减少高速多车连撞的悲剧。

第二个killer app：车辆行驶时调用摄像头，智能识别违反交通规则的或者危险驾驶行为、强行变道加塞的车，一键举报到12123，将危险并线加塞的低素质司机都逐出马路。

期待一个真正属于智能电动汽车APP开发者的生态能够建立起来。真正能解决用户痛点的killer app在哪家OEM的OS中诞生，用户就会用脚投票买入这个OEM的产品，数量的增长会增加开发者的盈利，吸引更多聪明机智的开发者下场，从而为用户提供更多解决痛点、实用、好用的APP，这将会是汽车OS的马太效应的实现过程，这才是真正的智能电动汽车的诞生过程。

OEM要做的是打造出低APP开发成本、高可复用、硬件API功能丰富、造型吸引用户眼球、拥有良好用户体验的智能汽车平台，为开发者打造一个好底子、打造一个好生态。好产品，会说话，群雄逐鹿中原，谁是真正的智能汽车，谁是IOS、Android，谁是塞班、Windows Phone、黑莓，将会由开发者和用户来决定。

本文用近万字描绘了智能汽车EE架构发展的最终形态的蓝图，描述了做成这件事的意义以及头部车企做成这件极难而正确的事的驱动力。这个未来，可能很远，也可能被一家车企在几年内时间就快速实现，倒逼其他车企快速跟进。

本文描述了“最终形态是什么”，以及“为什么这样做”，但是受限于篇幅，没有来得及讲“如何做”。这是一个很大的课题，全世界所有车企和tier1都还没有答案，大家都在起跑线或者在马拉松长跑的路上。笔者深知这场马拉松的难度，想赢得这场比赛，需要OEM、Tier1/2/3...、开发者、用户共同协作，营造出一个巨大、多元、平等、开放、良性竞争的生态系统。

笔者期待着能尽自己所能，为这张蓝图添砖加瓦，会将做域控制器开发的一些教训、坑、失败的地方与可供借鉴的地方陆续地发布在笔者的公众号“建筑师和朋友们”上，期待读者们的关注。

后续，“智能电动汽车EE架构终极形态”系列三部曲还将有两篇文章会首发在九章智驾的平台上，分别探讨OEM进化到终极阶段最难的一道坎和3.0时代tier1的危与机。笔者也期待着读者们高质量、深度的提问与交流。

期待以文会友，结交更多志同道合的同路人，一起将蓝图落地为现实，实现“汽车人的中国梦”！

文章最后，感谢清涛老师、九章沙龙、贾建龙、黄超波、宋海灵以及建筑师的前4位读者——五月、hwu、华生、守中在本篇文章构思、成文、修改阶段提供的建议、帮助、指教，没有你们的帮助，便不会有这篇文章。感谢你们，也期待着下一次合作。