近几年汽车行业关于EEA的讨论一直热度不减，各大整车企业也纷纷宣布推出域集中、区域集中乃至中央集中式的EEA。EEA是电子电气架构（Electrical/Electronic Architecture）的英文名称缩写，这个概念最早出现在汽车从完全机械化产品向电气化、电子化发展之时。然而到了电动化、网联化、智能化的今天，“架构”一词的外延更加丰富，“电子电气”又关联广泛，EEA常常与芯片、软件、网络、线束、电子电气硬件等概念一起出现，实际上出现不少问题，真的有必要对EEA进行系统清晰的梳理。或许正是因为相关话题中混杂了太多的细节，一些企业高层对于EEA的理解与认知也缺乏战略高度，导致企业对于集中式EEA的落地规划陷入了误区。为了助力行业形成共识、加快智能汽车EEA的发展演进，盖斯特咨询研究团队围绕大家最关注的以下8个EEA问题，分享我们对于EEA最新发展趋势的系统研究和深度思考。
✔ 从传统汽车到智能汽车，EEA的内涵发生了什么变化？
✔ EEA包含哪些关键要素？EEA在智能汽车技术全景图中的定位是什么？
✔ EEA对于智能汽车具有什么作用和意义？
✔ EEA的总体发展趋势是什么？
✔ EEA的评价维度有哪些？
✔ EEA的演进将分成几个阶段？
✔ 集中式EEA演进着面临哪些挑战？
✔ 整车企业如何推动集中式EEA的落地？
一、从传统汽车到智能汽车，EEA的内涵发生了什么变化？
1.EEA的概念定义
首先从基本概念上，EEA就是电子电气器件的架构，体现了整车电子电气器件之间的连接关系。广义上EEA包含器件及其连接关系。我们可以进一步把EEA分为“电子架构”和“电气架构”，它们分别承载整车信息和能量的流动。
其中，“电子器件”一般指供电电压小于/等于48伏、基于电子电路实现相关功能的低压/弱电设备，包括车载传感器、芯片、显示屏等，主要负责完成信息/数据的采集、处理与利用。“电子架构”负责整车电子器件之间的信息交互，决定了电子器件的连接关系。这种连接关系通常用“网络拓扑”来表示，即以连接各种电子器件的通信线束所构成的通信网络的物理空间布局，因此“电子架构”也可以称为“通信架构”和“网络架构”。
“电气器件”一般指供电电压高于48伏的高压/强电设备，包括电池、电驱等，主要负责完成能量的转换。“电气架构”负责整车用电设备（包括高压和低压）的供电配电，并决定了电气器件的连接关系。这种连接关系通常用“电气拓扑”来表示，即连接各种电气器件所用的电气线缆的物理空间布局。
此外还需要注意以下几点：第一，虽然电子器件的供电配电也是由电气架构负责，但是电子器件之间不涉及能量的流转，因此电气架构对其连接关系不起决定性作用；第二，电子架构和电气架构是两套完全不同的拓扑结构，即使在物理空间上存在某些重合，但实际用到的线束/线缆是不同的；第三，电气架构中的高压和低压的供配电并非完全独立，一方面，低压供配电的能量是通过高压电源变压而来；另一方面，部分电子器件与电气器件在物理空间上会集成在一起，比如电驱总成内集成一个ECU（电子控制单元），因此高压和低压会同时存在于某些零部件。
2.EEA的内涵变化
具体到EEA的内涵，从传统汽车发展到智能汽车的变化非常大。笔者将EEA的内涵划分为物理连接关系、计算通信架构和能量配给平台三个层面，其中计算通信架构包括计算节点和通信网络，能量配给平台又可以区分为低压平台和高压平台。EEA的内涵在各个层面的变化如图1所示。
图1传统汽车EEA与智能汽车EEA的差异
在物理连接关系层面，传统汽车EEA采用分布式架构，电子控制设备（通常是ECU）分布在各功能子系统/模块中。随着智能化带来的功能数量激增，如果继续沿用分布式架构将导致ECU数量越来越多、布线愈发复杂，使得架构难以持续拓展。因此，智能汽车EEA将向集中式架构发展，即将各功能子系统/模块交由集中式电子器件（比如计算平台或域控制器）统一控制，从而简化硬件的物理空间布局、连接与布线。
在计算通信架构层面，传统汽车EEA采用以MCU（微控制单元）为核心、以ECU作为计算节点、以CAN总线（控制器局域网总线）作为通信网络的主干网，实现是面向各ECU信号的通信。随着智能化带来的软件集中与复杂度提高，汽车需要更大的算力来支撑软件运行，因此以异构SoC（系统级芯片）为核心的计算平台将成为主要的计算节点。此外，智能汽车要求软件能够灵活调用硬件，这需要更大的通信带宽和更灵活的通信机制，因此车载以太网将成为新的主干网，支撑上层实现面向服务的通信。计算节点和通信网络的升级也将反过来进一步促进EEA的集中化。
在能量配给平台层面，传统汽车由于高压器件较少，主要采用基于蓄电池的低压供电以及基于电磁继电器的静态配电。而电动化作为智能化的有力支撑，动力电池、电驱等三电及其附带的高压器件均会搭载在智能汽车上，智能汽车EEA也将新增高压供电配电网络。此外，智能化也要求低压平台采取更加安全、节能和灵活的电源管理策略，这需要基于芯片实现智能动态配电。
二、EEA包含哪些关键要素？EEA在智能汽车技术全景图中的定位是什么？
对于智能汽车而言，EEA在“能量配给平台”层面的内涵并非重点，因此在大部分语境中，狭义上的EEA通常指的是电子器件的连接关系，即通信网络。而广义上的EEA则包含“计算通信架构”中的所有电子电气器件及其连接关系，为汽车软件提供基础能力支撑与可供调用的硬件资源来源。考虑到狭义EEA可谈论的内容有限，本文后续内容主要讨论广义EEA。
图2展示了EEA在智能汽车技术架构中所处的位置、构成要素，以及其与其他要素之间的关系。可以看出，EEA既是软件运行与交互的支撑，又是硬件接入与集成的平台。
EEA构成要素之一是传感器、执行器等功能硬件，它们通过硬件接口和线束接入整车通信网络。这些硬件所提供的功能性能是实现整车体验的基础能力。在软硬解耦趋势下，未来功能硬件的相关控制模型将实现知识化、抽象化，从而允许通过软件将硬件功能封装成为基础服务单元，支撑构建上层SOA（面向服务的架构）。
EEA构成要素之二是计算平台/控制器，它们是所有车载软件最终部署的地方，通过提供计算与存储资源来支撑软件的运行。计算平台/控制器的数量可以是一个或多个，这既与车载软件的集中程度有关，又与芯片技术的发展有关，具体将在后文详细介绍。
EEA构成要素之三是通信网络，主要负责硬件的连接与信号的传输。首先，通信网络需要建立不同计算平台之间的连接，从而支持跨域/跨平台的软件交互；其次，通信网络需要建立功能硬件与计算平台之间的连接，从而支持部署在计算平台上的软件能够灵活调用底层功能硬件；最后，通信网络需要提供以太网等硬件层通信协议，从而支撑上层复杂的软件层协议，比如实现SOA所必需的面向服务的通信。
图2智能汽车技术架构
三、EEA在智能汽车具有什么作用和意义？
笔者此前的微信文章《“新汽车”SOA发展趋势与实施策略研究》中曾经提到，智能汽车中软硬解耦趋势本质上就是逻辑与物理分离的过程，而软件架构决定逻辑连接关系，EEA决定物理连接，两者是灵魂和躯体的协同共生关系。
如果把整车架构设计类比为城市规划，那么以SOA为代表的软件架构对应一种特殊的城市运行机制，EEA则对应城市总体布局。下面根据“软件先行”的SOA架构设计流程，说明SOA与EEA之间的紧密联系，以及EEA对于智能汽车的重要意义：
第一，EEA决定了整车软件在硬件上的部署。设计SOA的第一步是进行服务的划分与定义，即确定服务集合、服务颗粒度、服务功能性能，类似于城市规划中明确城市的正常运转需要具备哪些功能；而设计EEA时就需要考虑为每种服务提供必要的底层硬件支撑，包括传感器、执行器、计算、存储、通信带宽等资源，类比城市规划就是明确承担城市各功能的建筑物以及配套设施。
第二，EEA不仅影响整车功能的横向打通，还影响企业内部研发组织的横向划分。设计SOA的第二步是明确服务之间的打通交互关系，类比城市规划就是使城市功能实现充分协同；理想情况下SOA的服务之间能够彼此相互打通、灵活访问，但这受限于EEA的集中程度，比如部署在同一域控制器上的软件往往比跨硬件的软件更容易打通，类比城市规划就是只有城市形成集群才能实现更充分的协同，而不同的城市集群又需要不同的管理组织。
第三，EEA为软件的灵活交互提供了通信的硬件支撑。设计SOA的第三步是定义服务之间的通信规则，不同服务之间的通信规则是不同的，就好比城市中的物流运输网络和医疗急救转运网络需要不同的运营调度机制；但软件层面不论设计规则如何，服务交互最终都要转化为EEA中通信线束上的物理信号，就好比无论是物流车还是救护车都必须跑在交通道路上。
第四，EEA的设计决定软件复杂度的上限，也影响外部功能生态的接入。设计SOA的第四步需要从可拓展性的角度对架构进行优化，类似在城市规划中经常强调城市功能的多元化与转型升级；但就像城市的土地空间资源都是有限的，EEA提供的算力、通信带宽、硬件接口等硬件资源也是有限的，只有做好相应的预留才能支持软件的灵活拓展和升级，因此EEA的设计对于外部功能生态的接入以及车载软件复杂度的上限都有决定性影响。
第五，EEA支持硬件的平台化设计、硬件的灵活替换与升级。设计SOA的第五步是对架构进行跨车型、跨平台、跨硬件适配，即强调架构的复用性，就好比北京和上海虽然是不同的城市，但在整体的城市运行机制上有很大一部分的机制相似；但这种相似是建立在城市建设中存在很多国家标准规范的基础上，对于EEA来说就是要实现硬件接口的标准化，因此可以说EEA支持着硬件的平台化设计以及可插拔式替换与升级。
综上所述，EEA为整车的设计开发提供了物理层面的“总体布局”，同时影响着硬件、软件以及企业组织，所以EEA和SOA都是智能汽车设计开发中首要考虑的关键要素。
四、EEA的总体发展趋势是什么？
汽车智能化发展驱动汽车软硬解耦，解耦后的软件和硬件分别在逻辑维度和物理维度上集中，因此需要更高性能、更低成本、更加灵活的EEA。所以在讨论EEA的发展方向之前，首先要了解智能汽车的发展趋势与需求，笔者将其归纳为三点：一是，智能化时代技术发展快，用户需求变化也快，导致汽车产品开发迭代的周期也必须加快；二是，智能化功能需求呈现多样化，导致汽车上硬件的种类与数量增多；三是，用户更加追求整体体验，要求汽车上功能之间的协同要增加，导致功能逻辑的设计越来越复杂。以上每一个趋势都对整车EEA提出全新的需求。
第一，产品开发迭代加速，意味着传统的软硬件绑定的开发模式必然走向没落，取而代之的是软硬解耦，让软件能够脱离硬件实现更快的迭代，这对应到EEA层面即前文所述的逻辑与物理分离。
第二，分布在物理空间中的硬件越多，意味着车上的线束连接越多、拓扑结构越复杂，而要避免车内空间的限制，就需要将原本由多个ECU承担的功能集中至一个或几个具备大算力的域控制器或计算平台上，并使得传感器和执行器尽可能就近接入，即所谓的物理集中。
第三，功能逻辑设计越复杂，意味着负责实现这些逻辑策略对硬件进行控制和调用的软件需要更复杂的结构、更多的组件，而要降低软件的开发难度，就要将原本针对特定硬件、采用不同软件系统的多个逻辑策略集中至一个软件系统内重新设计开发（比如SOA），即所谓的逻辑集中。
因此，汽车EEA的演进趋势可以归纳为“集中化”，并且是分别从逻辑和物理两个维度实现集中。
五、智能汽车EEA的评价维度有哪些？
优秀的智能汽车EEA应具备三个属性：高性能（支撑更复杂的软件更好更快地运行）、灵活可拓展（支持产品在更长的周期中持续进化）、合适的成本（有利于整体研发和制造的成本控制）。EEA的集中化恰好能够在这三个维度都实现优化。
从性能维度看，逻辑集中通过让软件在一个系统内充分共享数据，甚至部分软件可以进行合并融合，使得软件的运行与交互效率都更高；物理集中通过提高算力，能够处理更多的数据、支撑更复杂的功能。
从灵活性维度看，逻辑集中后通过对软件系统进行SOA设计，使得软件高内聚、低耦合、灵活访问，允许对软件组件（服务）进行灵活升级以及往架构中灵活增加新组件；物理集中则留出了更多的布置空间，支持更多传感器和执行器的灵活接入。
从成本维度看，逻辑集中后通过对软件系统进行SOA设计，使得软件组件的复用性增强，避免了重复性开发，降低了研发成本；物理集中通过减少硬件数量与算力冗余降低了控制器的物料成本，另外通过简化网络拓扑结构，使得线束的成本与重量都得到了降低。
六、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进化，智能汽车的产品形态也将迎来新一阶段的升华，让我们共同期待！
