六、EEA的演进将分成几个阶段？
前面谈到集中化是EEA的总体演进趋势，具体来看，实现智能汽车EEA的整体进化，不仅需要逻辑集中和物理集中双管齐下，还需要实现逻辑集中与物理集中的协同。实际上涉及到的内容很多，所以不可能一蹴而就，需要分步实现。
1.逻辑集中
逻辑集中意味着软件系统规模更大、更复杂，因此需要更先进的软件资源管理和交互技术。在传统的嵌入式软件系统中，“I/O控制软件”与“逻辑处理软件”被混杂封装在一起，没有明确的边界，这个阶段也称为“软软耦合”。
在谈论逻辑集中之前，我们首先要区分“逻辑处理类软件”和“I/O控制类软件”。“逻辑处理类软件”主要指融合决策、人机交互、功能组合等包含复杂逻辑策略的应用和算法，“I/O控制类软件”主要指信号路由、数据预处理、执行驱动等与硬件高度相关的驱动类软件。强调二类软件区别，是因为“逻辑集中”中的“逻辑”其实指的就是“逻辑处理类软件”，此类软件直接面向用户需求进行开发，具有更多的数据横向打通和组件复用的需求，天然就倾向于实现集中，而“I/O控制类软件”与硬件高度相关，其集中与否由硬件决定而非用户需求。
逻辑集中的第一步就是要实现“软软解耦”，需要把“逻辑处理软件”与“I/O控制软件”通过分类分层的封装方式来解除绑定，进而允许不同“逻辑处理类软件”之间能够实现打通和融合。
第二步是“功能集聚整合”，即把原本负责不同功能的多套软件系统集聚整合为一个系统。软软解耦后，理论上“逻辑处理类软件”与“I/O控制类软件”已经可以部署在不同的硬件上，但在实际工程开发中，考虑到对既有软件的继承，一般不会直接彻底打散重构整个软件体系。此阶段一般先继续保持“逻辑处理类软件”与“I/O控制类软件”在一个系统内，只对“逻辑处理”部分进行继承、融合与再开发，比如将AEB（紧急制动系统）、ACC（自适应巡航系统）、LKA（车道保持系统）等多个驾驶辅助功能整合升级为NOA(自动导航辅助驾驶)功能。
第三步是逻辑集中的理想阶段——“逻辑-控制分离”，即“逻辑处理类软件”与“I/O控制类软件”分别集中成两个软件系统并分别部署。“逻辑处理”这类需要大算力的软件可以部署至中央计算平台，而“I/O控制类软件”则可以部署至更靠近相关硬件的位置，这样可以最大程度实现同类型算力需求的集中，减少硬件异构集成带来的额外成本。
例如，如果需要在一颗智能驾驶SoC上同时运行“环境感知”和“底盘控制”两类软件，前者更需要AI算力，而后者只需要CPU算力，那么SoC的设计必须兼顾两者；如果将“底盘控制”软件部署在一颗单独的MCU上，那么SoC的研发和资源冗余就能得以简化。
2.物理集中
相较“逻辑集中”的三个阶段，“物理集中”整体可以分为“分布式”、“域融合”、“跨域融合”、“中央计算+区域控制”以及“车云一体”五个阶段。“物理集中”的演进过程对计算和通信等硬件性能的要求不断提升，具体参见图3。
从“分布式”到“域融合”再到“跨域融合”，目标是先用5-7个DCU（功能域控制器）取代掉各自域内的ECU，再进行跨域的计算整合将控制器数量缩减至3-4个。对于跨域的计算整合有不同的方式，有的车企按照功能域与功能域进行整合开发MDCU（多域控制器），有的车企则按照功能硬件的物理空间距离进行整合开发ZCU（区域控制器）。
“中央计算+区域控制”阶段是一个分水岭。在此之前控制器使用SoC芯片或MCU芯片，主要考虑物理集中的继承关系，假如原控制器就使用了MCU芯片，那么集中后的新控制器往往继续使用MCU芯片。但到了“中央计算+区域控制”阶段，车载计算架构已经重构，让SoC芯片居中用于中央计算集群/平台，负责大算力任务；MCU芯片则用于VIU（区域信息单元），负责与硬件控制相关的任务，这样的计算明确分工能有效简化硬件设计并提高计算效率。同时，VIU由于运算任务相对简单可以实现标准化，这样允许车企针对不同车型来灵活配置所需的数量，大大提高了架构的灵活性和通用性。
“中央计算+区域控制”阶段还可以根据“中央计算”的集中程度进一步细分为“多盒（Multi-Box）”、“单盒多板（One-Box）”、“单板多芯（One-Board）”和“单芯（One-SoC）”四个小阶段，这一集中过程除了依赖芯片硬件层面集成设计技术的突破之外，板间互连、片间互连、片上互连等通信技术的进步也是关键。
最终，根据半导体行业“摩尔定律”的发展情况，可以预见在“单芯”阶段将出现的瓶颈，因为车端算力不可能无限增长来满足所有应用场景需求，智能汽车终将迎来“车云一体”式架构。到了“车云一体”式架构阶段，部分车端算力将转移至路端或云端，车路云多端算力通过V2X（车联网）打通并实现协同计算，由此将EEA的物理空间范畴从车内拓展至车外。
3.逻辑集中与物理集中协同
综合上述逻辑集中与物理集中的演进路径不难发现，物理集中实际是逻辑集中的支撑，逻辑集中是发挥物理集中价值的关键，两者相互协同才能实现最优的EEA。虽然其中涉及到很多的软件和硬件，但是软件最终要部署在硬件上，部署的过程就是成本和效率的优化过程。
笔者认为，逻辑集中与物理集中存在一个最优匹配关系，如图4所示。笔者还标注了各大车企在EEA方面的相关进展信息。可以看到，传统燃油汽车采用的EEA是分布式物理布局，逻辑层面也是很典型的软软耦合的嵌入式软件。当到了物理集中的“域融合”和“跨域融合”阶段，实际上车企都是使用相应的集中式控制器来支撑相应“功能集聚整合”后的软件运行。特斯拉早在2021年实现了区域集中EEA量产，即使今天其比较先进的EEA仍被视为行业标杆。随着物理维度的进一步集中，“中央计算+区域控制”正好与逻辑维度的“逻辑-控制分离”相匹配，由“中央计算”承担复杂的“逻辑处理类软件”，“区域控制”承担与硬件高度相关的“I/O控制类软件”。
然而，理想与现实之间总有差距，实现逻辑集中和物理集中的最优匹配并不容易，常常处于不匹配的状态。这种不匹配现象在“域/跨域集中式架构”阶段，常见于某域/跨域控制器硬件已经完成了开发，而软件层面无法将部分功能整合进来，导致车内ECU数量并未减少甚至还有所增多。但是，后果更为严重的不匹配则体现在“中央集中式架构”阶段，这往往反映出企业的研发目标与现有实力的不匹配。
图4中列举了两个例子。第一个是某科技巨头的概念架构，该企业早在2020年就提出了“逻辑-控制分离”的目标，当时控制器的硬件水平不足以支撑实现这一目标。也就是说，物理集中落后于逻辑集中，这导致部分传感器、执行器仍然需要直接接入中央计算集群，使“中央计算”的硬件设计成本明显增加，最终该企业的相关量产产品并未按照其概念架构来设计；第二个例子是某企业于2023年宣布实现了“中央计算+区域控制”的EEA 3.0量产，从其公开的技术资料了解到，其尚未实现I/O控制与逻辑处理的完全分离，仍然有很多“逻辑处理类软件”部署在VIU上，这就是逻辑集中落后于物理集中的典型案例。
图5展示了不同EEA集中化阶段的软件在不同硬件上的部署方式。笔者将“分布式EEA”定义为1.0阶段，“域集中式EEA”定义为2.0阶段，“中央集中式EEA”定义为3.0阶段。从图5中可以看出，从“域集中”到“多域/区域集中”，软件的部署方式没有本质性变化，企业要做的是开发更强大的控制器以及整合更多的功能，因此即使物理和逻辑暂时不匹配也是走在正确的方向上。
需要注意的是，“部分区域化”（所谓2.9阶段）的两个软件部署例子，可以说是既不承上、也不启下。“物理落后于逻辑”导致“中央计算”的软件架构设计必须额外为硬件控制考虑很多安全性要求，不利于软件的灵活迭代；“逻辑落后于物理”导致“区域控制”的硬件设计无法标准化复用，面向不同车型需要费时耗力重新适配，成本投入产生极大浪费。这种“总有一方拖累另一方”不仅体现在技术层面，还体现在技术背后的组织团队，而团队之间的冲突与拉扯有可能让企业在很长一段时间都处于“3.0阶段就在眼前，但一直在2.9阶段打转”的状态。
七、集中式EEA演进面临着哪些挑战？
如前所述，推动EEA向集中化演进必须做三件事：逻辑集中、物理集中、软硬协同。这三件事分别对应了企业的三项能力：软件整合与打通能力、集中化硬件开发能力和软硬件垂直集成能力。但是其中每一项能力都面临着技术和整供企业分工合作模式的双重挑战。
1.软件整合与打通能力
逻辑集中必然使软件系统更加复杂，这需要管理调度能力更强的OS内核，负责管理软件资源，以及更灵活高效的中间件来帮助软件打通。目前OS内核在技术上主要有两方面挑战，一方面是汽车上硬件种类多样，现有的OS尚无法兼容全部的驱动；另一方面是不同软件对OS内核的性能需求不同，现有的OS产品难以同时兼顾。目前阿里、华为等科技公司以及极少数整车企业正在尝试研发或改造车载OS内核，但这种研发投入巨大，资源分散反而容易拖累整体技术进展。
对于中间件，虽然目前尚未打造出足够安全、高效、灵活的量产产品，但不存在明显的技术瓶颈。正是因此，软件供应商和车企都在相关研发上大量投入，且各有优劣。软件供应商虽然专业性更强，在中间件方面的技术积累更多更快，但短时间内很难将产品平台化、通用化，难以同时服务好多家车企；相反，车企自研的中间件能够更好地满足自身需求。因此，围绕中间件的整供博弈仍将持续。
2.集中化硬件开发能力
物理集中的核心能力是开发高集中度的域控制器或计算平台，而这又可进一步分为核心SoC芯片层面的开发和计算平台层面的开发。对于SoC，芯片企业无疑具有明显的技术优势，但也有极少数车企能够自研SoC，并与自研算法更好地协同。相较而言，车企更擅长在计算平台层面的开发，而应将供应商具有更成熟的量产开发经验。
综合来看，车企自研集中化硬件是期待能够实现更好地软硬协同，从而降低对硬件资源的需求，从这个角度看，车企自研芯片是具有合理性的，但是研发周期长，不确定性较大；即使最终研发成功，量产规模能否摊平高昂的研发成本仍然是一个问题。因此，车企很可能仍需要借助专业芯片企业的能力，并探索新的整供合作模式。
3.软硬件垂直集成能力
想要将高度复杂的软件集成在高度集中的硬件上，是一个难度极大的工程问题。从任务内容上看，车企是最适合负责软硬件垂直集成的主体，但是其在传统燃油车时代缺少经验积累而高度依赖供应商，导致车企的实际能力与需求存在较大的差距。
从供应商的能力现状上看，目前主流一级供应商一般只能提供单个功能域的软硬集成方案，少数零部件巨头具备跨域的软硬件集成能力，而对于未来的中央集中式架构下的整车级集成，几乎不可能由供应商实现。
从车企的能力现状上看，大部分车企停留在单功能域垂直集成的水平，极少数车企能够实现跨域的软硬件集成，因此整车企业在这方面还有很多功课需要补上。如果继续依赖供应商，那么路将越走越窄。
八、整车企业如何推动集中式EEA的落地？
车企在研发和量产集中式EEA时，需要综合行业整体水平与自身能力制定适合自身的EEA演进路径。笔者建议车企注意以下三方面问题：
1.根据实际情况选择EEA集中化程度
在制定EEA集中化战略时，过于落后于行业就容易被市场竞争淘汰；而过于先进，容易超出自身能力可以控制的范畴。车企需要牢记：没有最好的架构，只有最适合自己的架构。所以车企需要根据实际情况来选定适合的EEA架构发展策略。
首先，对于域集中式EEA，目前各类软硬件技术已能够满足行业需求的平均水平，部分供应商甚至能够提供完整的域级解决方案，大部分车企或多或少都已具备域级软硬件的开发和集成能力。笔者建议所有车企都应将EEA至少升级到此阶段，并逐步摆脱对域级供应商的依赖，自主实现软硬件垂直集成。
其次，对于跨域集中式EEA，目前在硬件层面，已有多家芯片企业推出了舱驾一体的芯片，虽然在成本和性能上可以进一步优化，但也算满足了基本需求；在软件层面，舱驾融合所需的OS和中间件技术，预计还需1-2年才能成熟。对于不同企业来说，传统车企在车控功能域上有较多积累，而在智驾和座舱上更依赖供应商；造车新势力则在智驾、座舱领域投入较多，相关能力掌握较强；还有少数巨头车企具备全栈自研能力。
因此，笔者建议传统车企应优先实现车控域的跨域集中，舱驾融合可以考虑与供应商合作；造车新势力则应优先自主开发舱驾融合的核心方案；而具有全栈自研能力的车企可以选择走更为灵活的区域集中路线。
最后，对于中央集中式EEA，目前硬件层面仅有Muti-Box和One-Box的方案趋向成熟，软件层面要实现真正的“逻辑-控制分离”还需要很长的发展期，并且尚无车企能真正将整车软件整合至一个大的系统内，并将其部署至中央计算集群上。因此，笔者建议车企不应该急于推出“形似神不似”的“中央计算+区域控制”架构，而是先在跨域融合阶段积累软硬件能力与经验，并推进下一代架构的预研，等待各方面条件都成熟时再考虑量产。
2.基于平衡思维设计EEA
EEA的设计需要做出各种平衡，可以说是追求平衡的艺术，主要体现在“体验”和“成本”、“现在”和“未来”、“共性”和“个性”三方面的权衡上。
对于“体验”来说，EEA提供了计算和通信的硬件支撑，其技术的先进性决定了用户体验的上限，但这种先进性将造成更高的“成本”。因此，EEA的设计切勿盲目堆料，而要根据品牌定位与目标用户来选择最优性价比。
“硬件预留”是平衡“现在”和“未来”的关键。如果预留多了容易让消费者产生“白花钱”的感觉，而预留少了将使得汽车后期难以持续升级迭代。想要合理预留就要求架构师既能对未来技术变化有比较精准的预测，又能对用户的接受程度有比较好的把握。
前文已有提及，EEA设计应能做到跨车型、跨品牌、跨平台复用，从而分摊成本，这其实指的是基础共性功能，当然不可能一套配置就满足所有用户对功能配置的个性化需求，所谓千人千面、千车千面。因此，EEA设计实际要做的是努力实现硬件标准化、平台化，同时打造算力、主干网带宽、区域控制器、功能硬件等配置可灵活调节的架构。
要做好上述平衡，对于架构师的要求非常高，既需要了解具体的软硬件技术，又要了解用户需求与业务，还要具备强大的抽象化系统思考。这类人才资源极为稀缺。因此，笔者建议各车企下一步要着重招揽或培养这类稀缺的人才。
3.面向中央集中式架构推动企业能力与产业分工变革
目前行业已经处在从EEA 2.5向3.0迈进的发展阶段，而面对高度整合、空前复杂的中央集中式EEA架构，只有车企才能主导架构的设计和资源的协同，因此车企必须尽快储备相应能力，并及时调整分工合作模式，从而实现整车软硬件的横向整合与打通。笔者预测的理想情况下中央集中式架构的产业分工详见图6。
对于“电子电气器件”，车企应主导定义底层功能硬件的标准化接口，至少也要做到与供应商联合定义，这样才能实现软硬解耦；而供电配电、通信等组件，由于功能相对基础且单一，车企依赖供应商即可；而域控制器、计算平台等核心计算节点，考虑到车企很难具备强大的芯片设计能力，建议车企与芯片企业深度绑定或者联合研发，将自己的重心放在集成电路板或机盒的开发上。
对于“电子电气器件的连接关系”，EEA的拓扑结构必须由车企自研或主导设计，且必须与软件架构深度协同，而线束等具体载体只需要借助成熟的供应链即可。
笔者相信，在符合实际情况规划、平衡设计以及合理分工下，企业将快速推动EEA架构发展，进而行业将加速向中央集中式的EEA 3.0进化，智能汽车的产品形态也将迎来新一阶段的升华，让我们共同期待！
