摘要：长城的架构演进规划主要依据以下四个重点方向进行：突破质量瓶颈；快速响应客户需求并降低功能集成的成本；响应公司走出去的全球化战略；提高产品差异化的竞争力。

2022年11月15日，由盖世汽车主办，上海虹桥国际中央商务区管委会、上海闵行区人民政府指导，上海南虹桥投资开发（集团）有限公司协办的2022第二届智能汽车域控制器创新峰会上，长城汽车电子电气架构总工程师胡斌提到，中央计算+区域控制架构作为EE架构发展的大方向毋庸置疑，但必须根据已有平台及产品；商品规划；供应链转型；公司流程；组织架构等因素分步实施。

长城汽车电子电气架构总工程师 胡斌

以下是演讲内容整理：

下面由我来跟大家分享，我负责整个长城汽车EE架构平台的规划，包括一些架构平台工具链的推广，今天分享的主题是《整车域控制器的选型及优化》。

先澄清一下，我讲的整车域控制器不是专指整车域控制器，而是包括车控域、自动驾驶和座舱域。我今天分享的主题主要分为以下五个内容：

一是关于长城汽车EE架构的迭代策略，对于整车厂，我们不会一下进入域控制器的规划，我们先规划整车域控制器，包括整车架构，然后再到域控制器，再层层向下切入微流程。

第二是域控制器开发平台，整车厂本身研发的不仅仅是控制器，还有其他的模块：包括电器件、软件、执行器、传感器……所以需要有一个开发平台控制所有不同模块。

第三是域控制器的规划（考虑要素/瓶颈），更多从客户体验、需求规划等方面分享域控所要注意的要素。

第四是关于长城域控制器的规划，虽然网上经常会流传一些长城汽车域控制器的规划分享，大家可以以我这次的演讲作为最终版本。最后是总结，因为时间比较短，我们不能对所有的点进行展开，今天更多是抛砖引玉，希望产生共鸣。

中央计算+区域控制器+通信架构是EE架构发展的大方向，这点毋庸置疑，从万物互联、OTA以及各方面的需求来讲，中央+区域控制器是一个大的未来趋势，这个不可否认。

但是在具体的实施路径方式上，我们认为根据已有的开发平台，包括产品、商品规划、供应链转型、公司流程、组织架构等因素分步实施。从一步直接跨到终点，阻力太大，瓶颈也太多。长城汽车的架构演进规划考虑以下四个重点方向：

1、解决以往的质量瓶颈问题。大家常常听到长城有3.0、4.0、5.0、6.0和7.0，对我们来讲架构不是一个技术形态，不是一个单独的硬件架构、软件架构，它承载着OEM的需求，质量问题是非常关键的需求。比如说，OTA能解决就不算问题，但是，如果这个软件BUG是在终端出现，就只能通过4S店维修，会降低客户的体验感，影响品牌口碑。因此，在架构的演变过程中，怎么样解决以前的架构、软件硬件的问题，是非常重要的。

2、快速响应客户的需求/减少功能集成的时间&成本。中央架构下，所有跟客户体验相关的软件都可以通过OTA进行刷写，区域控制器则可以通过感知刷写，怎么样通过合适的软件架构设计，快速响应客户的需求，减少功能集成代理的时间和成本，减少客户的抱怨……这些都是非常重要的。

3、响应公司走出去全球化的战略需求。长城这几年在全球各地布局了很多生产、制造基地，未来一两年在北美也要建立子基地，不光包含研发还有生产制造。那么如何让整个软件架构设计，既满足中国的需求，又可以满足其他国家的标准，包括整个制造售后，软件架构、硬件怎么设计，这些都要考虑在内。

4、提高产品差异化的竞争力。就整车层面，我们更多关注的是公有功能如何突显差异化竞争力，比如通过某个域的特殊功能，比如行泊一体，基于小算力实现差异化竞争。

这是长城统一的策略，分别从中央层、域控层、ECU层进行迭代。其中量产车主要应用的是GEEP3架构，正在开发GEEP4.0架构，下一代正在规划。主要是中央计算+区域架构；中央计算与智能驾驶融合架构，最终走向OneBrain，以上是整体规划。

GEEP 4.0采用了SOA（面向服务架构）设计理念，整个架构采用了中央计算+区域架构的形式，将此前的域控制器再度整合，并开放标准API接口，中央计算、智能驾驶和智能座舱三大计算平台分别掌管不同的域，支持持功能可生长和车云一体化，具备中央化、智能化、服务化三大特征。

OneBrain版本的目标是全面实现SOA，解耦开发功能和软硬件开发平台，这种解耦不光包括软件硬件，还包括软件之间的解耦，不同系统之间的解耦，从而具备系统级性能提升和高安全设计两大核心技术优势，支持L4的自动驾驶搭载应用。

EE架构迭代统一策略/规划思路

结合平台的需求、新技术以及未来的趋势等维度，定义智能车端控制、智能座舱、智能驾驶三大核心领域，通过打造可伸缩架构，大算力硬件平台，高质量高复用软件，以及功能可生长机制，满足平台分层化、模块化、通用化、个性化需求。

针对此，长城的规划目标有四点：可伸缩性，算力可扩展，高复用，灵活部署。比如针对可伸缩性，长城的对应策略是1、硬件可扩展、可更换 2. 硬件模块即插即用 3. 迭代延续性 4. 功能可配置。而针对算力可拓展，长城的对应策略是1、高性能，2、高存储，3、分层协同。

这里重点谈一下算力可拓展，在把软件变复杂之后，能给客户体验带来什么价值？这是我们关注的重点，到底在整车生命周期里有多少扩展需求要考虑？因为不是说所有的功能都做OTA，配置到底用不用是需要考虑的，特别是系统架构层面，这一需求需要被放在设计定性之前考虑。

还有高复用，软硬分离，标准化接口，分层设计，软件模块化，通用化，平台化，这些说起来简单，但是把需求规划清楚是不容易的，这是IT软件和通讯软件不一样的地方，通讯可以完全做到软硬分离，但是车真正做软硬分离，基本不大可能，即使最后做到软硬分离，还是有中间件在里面，中间件还是要连操作系统和应用层。最后，对于OEM而言，成本是非常关键的考量因素，如果对硬件的掌握不够深，或者对一些细节没有把控好，就存在成本失控的问题。

核心领域有车控域，座舱域和智能驾驶域，这三个域根据不同的平台，不同的需求可以做不同层级地融合，我所讲的“域”是抽象层次的域，可能未来变成一个大脑，也有可能变两个大脑，两个大脑有不同的融合方式。

长城的目标是打造可伸缩，可扩展，高算力的硬件架构平台，采用SOA软件架构，实现分层化、模块化、标准化，在不同车型硬件平台、操作系统上实现服务和软件的复用，通过标准化接口对应用功能进行快速升级迭代。

域控制器开发平台Systemweaver

为什么要打造域控制器开发平台？对OEM来讲，如果仅仅通过传统的方式，采用文本管理所有需求、需求之间的迭代互通，由于不同的模块是由不同组织、人员开发，传统线下沟通和文本储存的模式，给管理带来了非常大的难度。

Systemweaver为例可以有多种形式，从架构来讲有几个主要的活动：首先是SH需求抽取：包含关键词&结构工件、SH需求；第二阶段是系统分析：包含结构工件，系统架构，产品需求，功能定义，变种管理，产品线管理等六个步骤；后面就是零部件设计、功能开发和软件设计。

在我们看来，如果原有组织架构中并没有形成系统，采用Systemweaver可能并不能加速域控开发，反而会造成负担，长城目前推出该平台已经有两年，具备一定的经验，也切实提高了开发效率。

怎么让域控制器架构的软件硬件架构满足所有的需求，前后的SH需求抽取和系统分析是非常重要的。进行需求分析的人必须要了解系统组织和需求管理，一定要做过软件，不只是IT软件，还包括通讯软件，熟悉嵌入式软件五花八门的需求。

比如说实现L5自动驾驶，就会有“没有方向盘”这句话，将其传导至零部件设计层面，可以有以下的理解：首先，没有方向盘是谁决定的？是最前期的系统架构确定的，是系统分析层面决定的，是产品规划里就需要没有方向盘，那么就要将这个需求转化为零部件设计规范、软件设计规范，分门别类地释放给内部、外部的零部件供应商。

需求不仅是功能性需求，还包括非功能性需求，包括成本，人员管理，系统生命周期，法规等。因此我们发现，开发一个域控制器的利益关系非常广泛，提需求的人会来自不同的部门，需要把系统将其全部输入系统，分别分门别类，最终转化为软件、硬件的相关需求，放置于规范中。

长城在域控制器中的规划

接下来讲长城在域控制器的规划。怎么做规划？通常域控制器要考虑几个因素：一个是功能性和非功能性的需求，功能性主要是和软件相关的需求，比如说域控制器实现什么功能。还有非功能性的需求，着直接和域控制器相关，比如安装位置，散热等工程化需求，包括非工程性的成本，比如竞争优势、法规等。

具体而言，第一，是主要芯片（MPU/MCU）的选择/潜在供应商的横向&纵向对比。选择一种芯片后，我们还需要看整个芯片的计算架构，通讯架构到底能否满足需求，这是第二层次的细节对标，分为横纵两种维度，横向对比指的是：对比不同芯片的算力，性能优势与不足。

纵向指的是：量产情况和制成。由于最近一两年的国际形势，芯片层面的制裁，这些对OEM的影响是非常大的。所以未来芯片量产的限制因素，是对于OEM来讲非常关键的信息。

选了芯片以后，我们要对它的计算资源和架构做个Design review，深挖其满足的通信协议和其他性能，因为OEM要考虑整个产品对终端用户可能产生的影响。

从整个域控制器架构方面来讲，我们期望未来跟芯片供应、系统供应商、Tier1建立更和谐的互动关系，包括在一些深层次的方面做更多的交流，从而更好地满足计算、通信架构方面的需求。

第二，是主要传感器的技术趋势分析&选择。我们看来，毫米波雷达发展有如下三种趋势：

1. 3D毫米波雷达微带阵列天线从单输入多输出(SIMO)到多输入多输出(MIMO)发展，微波集成芯片（MMIC）从集成DSP到射频收发展，提高集成度达到降本目的。

2. 微阵天线布局从一维布局（水平）走向二维布局（水平和垂直），推动输出数据从3D走向4D空间，增加目标高度信息。

3. 4D毫米波雷达目前以芯片级联方案为主，未来向专用4D集成芯片方向发展，主流厂商采用2片级联和4片级联方案为主，级联越多分辨率越好，体积和功耗也会同步增大。

第三，行业横向&纵向对标。市场的大背景是：中低端车一般会用行泊分离的方案，高端更多会用行泊一体的方案，包括高阶自动驾驶的方案。然而，智舱智驾不光是技术的融合，更多是组织协调的融合，包括开发协调成本问题，部门之间的开发模式不同，所以要融合的话，沟通成本包括开发成本其实是蛮高的。

行泊一体化趋势下，如何选择传感器，如何提升性能，降低开发成本是大家应该关注的重点，如何落地是最关键的。对于OEM来讲，我们更多的困难是如何从内部改善不足，提升内部沟通效率，健全组织结构。

第四，域融合规划。 目前智控和智驾融合的约束是什么？理想方案是低阶自动驾驶，比如行泊一体融合成一个方案，然而在实际操作中，我们发现如果将三块MPU与一块MCU放在一起，基本上盒子就变成微波炉了。包括之前考虑双MPU+MCU，散热就无法被满足，此外延时也是一大问题。

因此在域控制规划上，电子电气的约束也是设计前期需要考虑的关键要素。

长城汽车域控制器规划——下一代车云协同的软件架构

长城要构建的下一代车云协同软硬架构有哪些规划？首先，按照SOA架构，实现软硬结构和分布式计算，支持多种SOA的通信协议，如DDC、Some/IP等，可以与自动驾驶、智能座舱进行方便灵活的对接，整个应用开发是跨不同的异构平台，跨不同的通讯协议，甚至跨不同的操作系统，这是我们规划的目标。

在SOA服务上，我们提供了车辆的设备抽象、服务接口，便于隔离底层的通讯方式影响，有利于其他服务的对接。服务方向，我们提供了SOA服务的基础业务功能，包括发布地域、请求回复、进程调度、节点管理、服务网关。

硬件架构也会支持服务方，我们现在规划了智控域、智舱域和车控域，三个域通过以太网连接，就近连接区域控制器，会根据不同的需求进行基于全平台的规划。基于DDS、SomeIP等，SOA技术可以被广泛应用于车控、智驾、智能座舱三大领域，便于快速、低成本地实现跨域融合。这是我们在自动驾驶的规划。

最后总结一下，作为OEM的一员，我们希望主要表达以下五个观点：

1、域控制器的开发不仅仅是技术的转型，整个开发流程/方法/工具链/组织架构都要跟上。

2、黑盒/白盒设计开放的原则取决于最终谁对域控制器的“灵魂”失效负责。

3、域控制器设计的核心是需求分析，包括功能性/非功能性需求，成本是非功能需求的核心要素。

4、域控制器融合方案的可行性除了技术可行性外，更多取决于工业化方案的可行性。

5、主机厂、硬件供应商、系统软件、底层软件、中间件系统集成方等域控制器利益相关方建立起“自洽”，而非“互锁、互斥”的长期利益合作命运共同体的关系。