集中化已成为掌控现代汽车中计算密集型功能的核心驱动力。在下一代汽车的开发进程中，架构变革正受到高级驾驶辅助系统（ADAS）、车辆互联性、信息娱乐系统以及由此引发的网络安全需求的深刻影响。当前，已有众多研究聚焦于未来集中式电气/电子（E/E）架构的构建，以及实现集中化的各类技术途径。然而，一个亟待解决的问题是，目前尚缺乏一套系统化的方法，用于深入剖析现有系统，并精准挖掘其在功能层面的集中化潜力。
鉴于此，本文提出了一种创新方法。该方法以常见的 E/E 架构设计理念以及当前研究领域所提及的相关工具为基础，助力系统设计师或工程师对功能进行抽象化提炼。通过这种抽象化处理，设计师能够设计出更为集中化的系统架构，以更好地适应现代汽车的发展需求。
基于该方法，设计师可以进一步提出全新的系统架构方案，并对这些方案展开全面讨论与细致权衡，深入剖析其各自的优缺点。为验证该方法的有效性，本文通过逐步将其应用于现代电动汽车的进气降额功能进行了实践检验。
后续的讨论表明，影响集中化潜力的因素纷繁复杂，多种多样。并且从整体来看，集中化未必是所有功能和系统的未来演进方向，不同功能和系统应根据自身特性与需求，审慎选择适合的发展路径。
一、背景信息
在戴姆勒（Daimler）、福特（Ford）、雷诺（Renault）等资深汽车制造商中，面向领域的电气/电子（E/E）架构已然成为行业实践的标杆。这类垂直架构的显著特征在于，每个领域大致划分为五个区域，每个区域都集成了大量专用电子控制单元（ECU），使得功能高度分散于各个部件[1]。然而，这种垂直架构的弊端也日益凸显，其缺乏必要的灵活性与可扩展性，难以契合汽车行业当下的发展趋势。如今，新入局者正试图从零起步，打破传统束缚，在市场中谋求一席之地并获取设计自由。
高级驾驶辅助系统（ADAS）对强大计算能力的迫切需求，促使传统E/E架构面临重新设计的挑战。与此同时，现代汽车的互联性变革，如与万维网服务的深度融合、TCP/IP协议的广泛应用，以及对高带宽信息娱乐系统的追求，都在有力地推动着E/E架构向集中化方向发展。此外，车辆的互联性还带来了严峻的网络安全挑战，这对E/E架构的设计提出了更高要求。
在汽车行业成本压力持续攀升的背景下，那些分散且已趋于成熟的传统平台，在可扩展性方面遭遇瓶颈，难以应对日益复杂的行业环境。通过对比特斯拉Model Y、大众ID.4和福特Mach E的电子控制单元（ECU）数量及通信网络情况，这一观点得以进一步印证。其中，大众和福特仍受传统平台的桎梏，发展步伐相对迟缓。实际上，成熟的汽车原始设备制造商（OEM）并未采取激进的变革策略，而是选择稳步推进、渐进演进。
众多一级供应商敏锐捕捉到行业变革的契机，纷纷推出面向区域E/E架构的集中式高性能计算（HPC）ECU。这些ECU作为核心组件，周围环绕着智能执行器和传感器，形成了一套高效协同的系统。这一设计理念将计算能力与输入/输出（I/O）功能有效分离，将复杂功能集中整合至单一ECU中，从而实现对系统复杂性的精准把控。此外，一级供应商在解决方案中普遍采用了面向服务的设计和通信方法，这一技术手段能够高效处理未来将急剧增长的海量数据。
当前，公司内部垂直整合的趋势愈发明显，这为E/E架构的集中化提供了有力支撑。随着员工专业知识的不断积累与深化，集中化架构的推广与应用变得更加可行。在本研究中，我们基于前人的研究成果，深入剖析了集中化E/E架构的技术实现路径与结构设计方法。随后，我们将这些方法进行系统整合，形成了一套全面且具有可操作性的方法体系。同时，我们也对集中化的局限性进行了客观、深入的批判性讨论。在深入探讨集中化方法之前，我们首先对面向领域和面向区域的E/E架构的特点进行了详细阐述，以便为后续方法的分类与探讨奠定坚实基础。
二、 主导的E/E架构及趋势
1、面向领域的E/E架构
在面向领域的电气/电子（E/E）架构体系里，顶层核心组件为领域控制器，它犹如架构的“智慧大脑”，是一个性能强劲的主CPU，肩负着控制和监测特定领域（如动力系统领域）的重任。领域控制器具备强大的功能整合能力，能够巧妙地对各类功能进行捆绑与集成，以此从容应对日益攀升的复杂性和计算能力需求。
在领域控制器之下，分布着一系列计算能力相对较弱的专用电子控制单元（ECU）。这些专用ECU各司其职，专注于处理特定的功能任务。由于这些任务可能对硬件有特殊要求，或者需要部署在特定的位置，因此这些ECU的存在十分必要。它们通过典型的通信网络与领域控制器紧密相连，形成了一个有机的整体。例如，对于简单的输入/输出（I/O）执行器控制和传感器监控任务，通常采用LIN网络进行通信；而对于高度交互式的ECU之间的数据交互，则多选用CAN网络。为进一步提升数据传输速率，速率高达5 Mbit/s的CAN-FD网络被广泛应用，在当前以集中化为主导的发展潮流下，它基本能够满足面向领域的E/E架构的数据传输需求。尽管汽车以太网能够实现更高的数据速率，但目前它更多地被用作两个或多个领域之间的骨干通信路径，承担着数据传输的“高速公路”角色。如图清晰展示了这种面向领域的E/E架构的一个典型示例。
通常情况下，一辆车中会划分出四到五个领域。以梅赛德斯 - 奔驰（Mercedes-Benz）为例，其划分的领域涵盖信息娱乐和远程信息处理、车身与舒适性、高级驾驶辅助系统（ADAS）以及动力系统等。这些领域在相关文献中也代表了汽车领域架构中的主要划分方向。
2、局限性与挑战
高级驾驶辅助系统（ADAS）与动力系统这两个关键领域，充分暴露了面向领域的电气/电子（E/E）架构可能存在的固有局限。在自动驾驶这一前沿目标的实现进程中，这两个领域需要开展深度且紧密的协同合作。然而，现实情况是，大量信息需要在不同领域之间频繁且高效地交换，这一过程不可避免地导致功能在一定程度上呈现出分散和去中心化的态势。
随着自动驾驶实现复杂性的不断提升，以及所需接口数量的急剧增加，面向领域的E/E架构在可管理性和可扩展性方面逐渐力不从心，性能表现大打折扣。在此背景下，对现有的E/E架构进行全面评估与重新设计，推动其朝着跨领域或面向区域的E/E架构方向演进，已成为提升汽车系统整体性能与竞争力的必然选择。接下来，我们将深入介绍这两种新型架构及其独特特点。
3、 跨领域和面向区域的E/E架构
跨领域E/E架构在架构演进历程中，扮演着向面向区域的E/E架构过渡的关键中间角色。跨领域控制器通过巧妙整合不同领域的核心功能，实现了自身能力的质的飞跃。这些被整合的功能往往具有许多共同接口，或者对专用软件和硬件有着共同的要求。通过深度挖掘并充分利用这些协同效应，跨领域控制器显著提高了系统实现效率、性能表现以及通信能力，进一步强化了车辆功能的可管理性和可扩展性，为汽车系统的智能化升级奠定了坚实基础。
在跨领域E/E架构的基础上进一步深化集中化，便迎来了面向区域的E/E架构。正如引言中所提及的，众多一级供应商已敏锐捕捉到这一发展趋势，并积极投身于面向区域的E/E架构的研发与推广之中。面向区域的E/E架构的显著特点在于，它拥有一个功能强大的中央主控单元，该单元犹如车辆的“智慧中枢”，承担着车载计算机的核心角色。通过虚拟化、容器化等前沿技术解决方案，中央主控单元成功整合了以往分散在各个领域控制器的功能，实现了资源的高效利用与功能的深度融合。关于这些技术解决方案的详细探讨，将在后续内容中展开。
在车辆的其他部分，物理上被合理划分为多个区域，每个区域都配备了一个区域控制器，作为输入/输出（I/O）硬件（例如无法集中化的执行器或传感器）的网关。这些网关区域控制器承担着信号转换的重要任务，确保中央计算机与各个区域之间的信号能够准确、高效地传输。在选择直接信号线和通信通道类型时，必须充分考虑硬件特性以及所需的带宽，以确保系统通信的稳定性和可靠性。下图直观展示了一个典型的面向区域的E/E架构，为我们深入理解这一架构提供了清晰的参考。
4、局限性与挑战
在相关文献中探讨集中化架构的利弊时，多数观点倾向于肯定集中化的积极意义，尤其聚焦于车辆技术在当下与未来的发展需求。然而，集中化并非完美无缺，存在两个亟待重视的缺点，需通过技术革新、方法论优化以及设计针对性的解决方案来加以克服。
集中式电气/电子（E/E）架构显著特征之一是线缆长度和截断导线数量大幅攀升。这不仅增加了布线的复杂度和成本，还可能对车辆的电磁兼容性和可靠性产生不利影响。不过，通过智能化的线缆设计以及合理的区域布局规划，这一难题有望得到有效解决。
集中化系统面临着一个更为关键且棘手的挑战——单点故障问题。一旦中央计算机出现故障，整个车辆将陷入瘫痪，无法正常运行。在车辆的设计与开发阶段，无论是软件层面还是硬件层面，都必须将这一风险因素纳入考量，严格遵循汽车行业的汽车安全完整性等级（ASIL）要求，确保车辆在各种工况下都能安全可靠地运行。
实现向面向区域的E/E架构转型的技术路径丰富多样，但每一种路径都伴随着相应的挑战。这些技术方法将在后续章节中详细介绍，并作为设计功能抽象和功能集中化系统化方法的重要依据。
5、集中化的技术方法
在本章中，我们将依据AUTOSAR这一开放且标准化的软件架构，从电子控制单元（ECU）的底层硬件到顶层软件，对实现集中化的技术方法进行全面分类。通过这种方式，我们能够确保与当前车辆架构保持紧密联系，避免技术转型过程中的脱节现象。
代表成熟ECU架构的AUTOSAR经典平台（Classic Platform）将ECU从硬件到应用划分为多个层次分明的组件，这一架构模式在中有着详细阐述。与之形成对比的是，AUTOSAR自适应平台（Adaptive Platform）已经涵盖了基于例如POSIX等先进标准的未来车辆ECU架构，其架构示意图如图所示。
在本章的最后部分，我们将介绍一种文化方法和一种结构方法。这些方法旨在助力汽车行业更好地落地实施技术方法，推动汽车行业更紧密地与信息技术（IT）开发及其工具链相融合，从而满足软件驱动型车辆架构日益增长的需求。
集中式高性能计算（HPC）电子控制单元（ECU）在设计过程中，必须充分考虑处理大量偶然数据所需的高计算能力。此外，鉴于车辆在其生命周期内可能会通过空中下载（FOTA）方式持续更新功能，软件驱动型车辆对计算能力的需求也将不断攀升。为了在集中式ECU中高效地处理CPU密集型任务，硬件加速器成为不可或缺的关键组件。硬件加速器是专为特定任务量身定制的专用硬件，例如在计算机的图形显示领域就已得到广泛应用。这些加速器能够根据实际需求灵活开启或关闭，从而显著提高整体计算效率，减轻CPU的负载压力。
随着车辆开发中功能数量的持续增加以及新的CPU密集型技术的不断引入，单核处理器已难以满足日益增长的计算需求。由于功率耗散限制，CPU频率的持续提高遭遇瓶颈[15]。因此，多核和众核处理器被视为推动E/E架构集中化的关键力量。这类处理器能够实现任务分配的并行化处理，从而大幅增加可用的计算能力。多核处理器还支持时间上的干扰自由度，这在虚拟化以及在同一CPU上使用不同操作系统（如实时系统与服务器客户端系统）方面具有重要意义，是保障系统安全性的关键因素。然而，与此同时，系统复杂性也会随之增加，并且需要考虑与旧平台的向后兼容性问题。为此，业界已研发出各种软件机制和不同方法，旨在在遵循计算序列的同时实现核心的均衡负载分配，避免任务分配不当。尽管这些内容在此不再深入展开，但值得进一步深入研究与探讨。
-> 深入ECU层面：基础软件与虚拟化、中间件的作用
当我们将目光聚焦于ECU层面，并进一步向应用层靠近时，基础软件（BSW）的最低层——微控制器抽象层（MCAL），成为了备受瞩目的关键环节。MCAL犹如一座桥梁，巧妙地使上层软件层与主处理器及其片上外设（如通信模块、存储器、输入/输出（I/O）等）实现了分离。操作系统通过MCAL这一抽象层面与硬件进行交互，这一创新设计为程序员带来了极大的便利，使他们能够编写与具体设备无关的软件（SW）。正因如此，MCAL显著提升了软件在不同ECU（包括那些更靠近潜在中央主ECU的ECU）之间的可移植性，为汽车软件的高效开发与灵活部署奠定了坚实基础[4]。
高级驾驶辅助系统（ADAS）和信息娱乐系统在运行过程中，需要处理和传输海量的数据。在嵌入式ECU开发领域，传统的基于时间驱动的操作系统（如AUTOSAR Classic）已逐渐触及性能极限，难以满足日益增长的复杂需求。而较新的、基于POSIX的AUTOSAR Adaptive标准则犹如一股清新的风，为汽车开发者带来了全新的开发模式。它允许开发者以事件驱动、客户端 - 服务器为导向的方式进行开发，因为自适应平台支持在运行时动态链接服务和客户端。这些独特的特性使得ECU能够轻松应对当前和未来车辆功能的复杂性与计算负载，为汽车智能化发展提供了强大的技术支持。然而，AUTOSAR Adaptive并不会取代AUTOSAR Classic，后者凭借其硬实时、时间关键且计算负载较低的优势，仍将在特定应用场景中发挥重要作用。
为了在同一个CPU中实现相关功能和应用的和谐共存，我们引入了集中化的又一关键推动因素——虚拟化。虚拟化技术如同一位神奇的魔法师，使得在同一硬件上运行多个操作系统成为可能，从而极大地增加了将两个具有不同要求的ECU（例如，一个需要确定性行为，另一个需要非确定性行为）集中到同一硬件上的潜力，为汽车硬件资源的优化利用开辟了新途径。
在同一个CPU上并行执行多个操作系统，这一宏伟目标的实现离不开虚拟机监控器（Hypervisor）的助力。Hypervisor，也称为虚拟机监视器（VMM），它就像一位严谨的管家，将硬件与虚拟机（VM）及其操作系统隔离开来。Hypervisor时刻监控着相关VM的硬件需求，并根据实际需求精准管理硬件分配。Hypervisor主要分为两种类型：类型1和类型2。类型1 Hypervisor，也称为裸机Hypervisor，它直接与硬件交互，充当主机操作系统的角色，负责管理在其上运行的客户操作系统的资源检索。类型2 Hypervisor则作为应用程序在已有的主机操作系统上运行，通过主机为客户操作系统请求资源，执行纯软件虚拟化。同样，虚拟化也需要借鉴多核处理的方法和模式，以确保干扰自由、内存保护、符合ISO 26262标准的安全要求[20]，以及规范虚拟机边界之间的通信。
-> 虚拟化与操作系统：对E/E架构集中化的深远影响
在总结虚拟化和操作系统对E/E架构集中化的影响时，我们来到了从ECU硬件到应用层的中间件层面。中间件犹如一位默默的幕后英雄，将应用层与基础软件、操作系统和硬件抽象开来。它极大地提高了软件组件（SWC）的灵活性，使软件开发者能够全身心地专注于功能实现，而无需为底层细节所困扰。智能中间件解决方案将成为现代车辆访问信息技术（IT）领域服务乃至全球互联网服务的关键推动因素。通过集成中间件，服务能够在双方之间得到正确翻译和解释，确保信息传递的准确无误。虽然AUTOSAR Classic的时间驱动中间件称为运行时环境（Runtime Environment），但AUTOSAR Adaptive则使用称为ARA的中间件来处理服务器和客户端之间的通信，展现了不同架构下中间件的独特魅力。
-> 微服务与容器化：构建灵活、可扩展的汽车软件架构
在此背景下，我们愈发清晰地认识到，为了实现ECU的集中化和虚拟化，并确保软件驱动型车辆的互联互通，智能中间件解决方案是必不可少的。这种抽象化还需要软件组件（SWCs）以灵活设计且具有明确定义接口的形式在应用层得到有力支持。为了降低复杂性并提高灵活性，我们可以采用“分而治之”的范式，通过设计解耦的微服务来构建应用。每个微服务都专注于处理较小的任务，犹如一颗颗精密的齿轮，相互协作，共同推动整个系统的运转。微服务增强了功能和软件架构的可扩展性和可交换性，为汽车软件的持续进化提供了强大动力。通过编排，微服务可以在不同的应用中实现复用，进一步提高开发效率和软件质量。
将微服务与其运行所需的一切（如系统库、配置、工具和运行时环境）组合在一起，就创建了一个容器。容器代表了一个独立的部署单元，它总体上支持DevOps实践中的持续集成/持续部署（CI/CD）。容器可以视为一种统一的技术方法，从一开始就设计出独立于未来硬件或宿主机的应用。它使应用在中央主ECU上具有更好的可迁移性，并在保持微服务原则的同时管理日益增长的复杂性，为汽车软件的快速迭代和部署提供了有力保障。
-> 汽车行业与IT领域：工作方法与组织结构的碰撞与融合
尽管所介绍的技术方法在IT领域已经确立并得到广泛应用，但汽车行业才刚刚开始在汽车日益数字化的背景下引入这些方法。文化和结构方法可以增强将所有介绍的技术方法付诸实践的潜力。在比较汽车行业公司与IT领域公司的工作方法和组织结构时，可以发现两者存在显著差异。在汽车行业，目前主要遵循V模型和垂直结构进行开发，这种模式注重流程的严谨性和系统的完整性，但在应对快速变化的市场需求时可能显得较为僵化。而在IT领域，DevOps和水平结构占主导地位，强调快速迭代、灵活开发和高效协作，能够迅速适应市场变化。
顾名思义，DevOps通过一系列技术、方法和文化方法将开发与运维紧密结合。其目标是加快开发、测试和发布过程，以提高软件质量。通过将开发与运维融合，运营商和/或客户的反馈可以直接反馈到开发中，形成一个无限循环，从而实现持续集成/持续部署（CI/CD）的原则。由于未来的车辆将越来越依赖软件，并有可能按需更新单个功能，因此汽车行业的工作方法将向DevOps演进，以适应汽车智能化发展的新趋势。目前尚不清楚DevOps是否会取代V模型，或者两者是否会共存，亦或是未来汽车开发中会采用两者的结合，这需要汽车行业在实践中不断探索和验证。
此外，根据康威定律，组织结构（尤其是沟通结构）会影响所开发系统的架构[3]。将这一原理应用于车辆的E/E架构，意味着E/E架构反映了公司的沟通结构。由于当前车辆的E/E架构仍以垂直方向为特征，根据康威定律，垂直的组织结构可能是其中一个根本原因。换句话说，为了推动E/E架构的集中化，必须集中沟通和组织结构，打破部门之间的壁垒，促进信息的自由流通和高效协作，为汽车E/E架构的创新发展创造有利条件。
-> 功能分离与系统方法：为汽车E/E架构集中化提供决策支持
考虑到之前讨论的技术方法，在建立功能集中化的系统方法之前，必须首先将系统及其功能分解为单个组件。下一章将定义一个功能分离的概念，为后续的系统开发提供清晰的指导。在此基础上，将开发一个系统方法，该方法将技术解决方案应用于抽象的功能，旨在评估集中化的潜力。这种系统方法将帮助系统设计师和功能工程师在决定如何在系统内分配功能时做出明智的决策，重点关注当前汽车开发中呈现的趋势和挑战，为汽车E/E架构的集中化发展提供坚实的理论支撑和实践指导。
ECU 基础与 I/O 连接方式剖析
每个电子控制单元（ECU）或控制器项目均以硬件（HW）为基石。中央处理器（CPU）和微控制器单元（MCU）作为硬件的核心组成部分，必须具备相应的计算能力和控制逻辑，以支撑整个系统的运行。这些硬件设备将作为操作系统的运行载体，操作系统则肩负着将来自软件组件（SWCs）的任务合理分配到硬件内核和核心上的重任，同时还要对输入/输出（I/O）电路进行监控与操作。这些 I/O 电路作为硬件的基本构成元素，充当着执行器或传感器等 I/O 设备与处理单元（负责评估和控制逻辑）之间的桥梁。
在后续的步骤中，I/O 可以采用集中式或分布式的方式连接到处理 ECU 上。因此，在抽象方法的考量中，需要兼顾直接的模拟 I/O 信号线（集中式）以及各类数字通信协议，如 LIN、CAN、以太网，甚至基于 IEEE 802.11 标准的无线通信（分布式）。集中式 I/O 的显著优势在于能够有效减少 ECU 的数量。由于无需网关进行数据转发，信息将直接由一个功能更为强大、规模更大的集中式主 ECU 进行处理。然而，集中式 I/O 也并非十全十美，它存在一些潜在的劣势，这些劣势将在后续的讨论部分详细阐述。
基于上述分析，我们所选择的四个基本组件——硬件（HW）、软件（SW）、I/O 信号线和 I/O 通信（COM），已经足以对功能进行全面抽象，从而为评估功能集中化的潜力提供有力支持。图 展示了这些基本组件的通用示意图，这些组件将基于现代混合动力和电动汽车中广泛应用的温度电流降额功能进行验证，以检验其在实际应用中的有效性和可行性。
功能集中化的方法学阐述
该方法学方法以面向领域的 E/E 架构为起点，该架构代表了当前的技术发展状态。通过尽可能多地将逻辑集中到域控制器中，域控制器将逐步向中央主计算机演变。在理想情况下，最终仅保留智能执行器和传感器，实现系统的高度集成。在进一步的阐述中，我们可以开发一套系统方法，将各个域的逻辑集中到跨域或一个中央计算机中，从而使域控制器仅承担简单的翻译区域网关控制器的功能，简化系统架构，提高系统的整体效率和可靠性。
该活动图旨在有效管理当前汽车行业面临的趋势和挑战，推动系统从分散且分布式的面向领域功能架构向功能集中化迈进。在实施过程中，必须对每个域的功能进行细致评估，以便在域 ECU 本身内部容纳尽可能多的功能，最终实现向中央主计算机的演进。
方法学方法的验证过程
为了验证 UML 活动图中所示的方法学方法，我们选取了混合动力和电动汽车中典型的温度电流降额功能作为案例。该功能基于充电口内传感器的温度数据，对充电电流进行调节，以防止因过热而导致的损坏和伤害。根据 ISO 26262 标准，该功能具有 ASIL B 评级，其安全性和可靠性对于车辆的正常运行至关重要。这些信息对于深入讨论集中化潜力具有重要的参考价值。
主要逻辑可分为两部分。第一部分通过电路对温度传感器进行评估，并提供交流（AC）和直流（DC）引脚的温度值。根据 IEC 62196 标准，必须确保可触摸的非金属部件的最大温度不超过 85°C，因此这一评估环节至关重要。第二部分负责处理温度值并计算可抽取的潜在电流。降额功能可视为一种质量性能功能，旨在优化充电过程。充电也可以以连续的最大电流进行，但这样可能会导致温度迅速达到 85°C 的阈值，即使车辆的目标充电状态尚未达到，也需要停止充电。因此，降额功能应智能地调节电流，使充电过程不会直接运行在阈值并导致停止，而是以较低的电流继续充电，以达到最佳的时间跨度，实现高效、安全的充电。
由于与传感器和相应电路存在紧密的连接和依赖关系，主要逻辑的第一部分无法自由移动。然而，根据内容，主要逻辑的第二部分可以设计为一种微服务。它具有明确的输入（如温度值）和明确的输出（即基于其计算的实际最大电流），这一特性使得 SWC 或微服务温度电流降额功能具有高度的灵活性和位置无关性，便于在不同的系统架构中进行部署和调整。
温度电流降额功能原本分配给了三个不同的 ECU。按照 UML 活动图的指引，上述主要逻辑的第二部分可以移动到更接近域控制器的 ECU 中。在第一步中，这将是 ECU EVCC。传感器的 I/O（包括其电路）通过从传感器到 EVCC 的直接模拟信号线进行集中化，从而减少了不必要的硬件组件和通信线路。这样，功能本身就不再需要 ECU Inlet，实现了功能的优化整合。然而，这仅适用于该特定功能，因此一般不能直接移除 ECU Inlet。这也是为什么必须对域中的每个功能 x 执行 UML 活动图的原因，因为集中化潜力最小的功能会限制组件的移除。功能的新架构如图 中从上数第二个所示，实现了初步的功能集中化。
在面向区域的 E/E 架构方面更进一步，通过将主要逻辑的第二部分移动到应演变为中央计算机的域 ECU 中，ECU EVCC 将转换为一个简单的区域网关 ECU。区域网关 ECU 现在作为一个简单的智能传感器，为域控制器进行监控和翻译，实现了数据的高效传输和处理。在区域网关 ECU 下方，可以放置进一步的传感器和执行器，这些传感器和执行器将由域控制器进行统一监控和处理，进一步优化了系统架构。新的功能架构如图的第三行所示，实现了更高程度的功能集中化。在 UML 图的最后一步中，甚至区域网关 ECU 也将被移除，通过再次将 I/O 直接集中到其域控制器中，实现了功能的全面集中化。这导致电路被移入域控制器，同时也减少了通信线路的数量，进一步简化了系统结构。这种最集中的功能架构如图 的最后一行所示，达到了功能集中化的理想状态。由于温度电流降额功能的进一步集中化已不可能，接下来将对不同变体的优势、劣势和挑战进行深入讨论。
结论
在本文中，我们提出了一种方法学方法，旨在支持系统和功能工程师对E/E架构进行集中化。我们收集、研究了当前研究中的技术解决方案，并将其整合到一个UML活动图中，通过该图可以制定和集中化不同的功能设计。然而，集中化并不能被视为E/E架构中每个功能的通用解决方案。一般来说，集中化将提高未来技术（如高级驾驶辅助系统（ADAS）或信息娱乐系统）的可管理性，并降低其复杂性，这些技术以大量的代码行和数据为特征。否则，这些技术在不久的将来可能难以管理。
然而，在集中化功能时也存在劣势，特别是在涉及传统功能以及不需要高计算能力或大量数据的功能时，必须对这些劣势进行详细阐述。
来源：车载诊断技术
