EE架构|国内主流OEM的中央计算区域控制架构信息梳理

小毛HYL 2022-01-19

展开全文

智能座舱、智能驾驶和智能网联的发展将会促使新功能的不断增加。同时，对高算力和大带宽数据传输的需求也会越来越迫切，再加上“软件定义汽车”的理念驱动，共同推动着整车EE架构的升级和变革；目前各车企已经逐步开始从独立功能的分布式架构，走向功能集成的域控制架构，并将最终走向中央计算+区域控制的中央集中式架构。

一、特斯拉的“准中央集中式架构”引领了潮流

1. 分布式架构VS中央集中式架构

1）在分布式架构下，软硬件紧密耦合，OEM对于供应商比较依赖，在合作的过程中，主要只是提供一个技术标准(比如通讯信息-XX信号，通讯形式-CAN/LIN等)给到Tier1，并且每个系统由不同的供应商提供，导致OEM的整车软件成为由很多独立的、不兼容的软件系统组成的混合体。如果主机厂想进行功能变更或者增加新的功能，需要和不同供应商去谈，因此受供应商掣肘十分明显。

其次，随着ECU越来越多，车内的线束也会越来越长，不仅增加了车重和整车成本，同时也给整车布置及装配带来了很大的困扰。并且，各个ECU之间的计算能力无法协同，产生较大的算力浪费。

2）在中央计算+区域架构下，算力逐渐向中央集中，先是由多个ECU合并成一个域控制器，慢慢的多个域控制器会继续融合，最终会形成1个中央计算平台+N个区域控制器的终极布局。此时，ECU数量会大大缩减，不仅降低了整车ECU的应用成本和控制器之间的布线成本,也有利于整车的轻量化设计。

其次，传感器、执行器就近接入到附近的区域控制器中，能够更好的实现硬件的扩展。同时，区域控制器的结构形式也更易于管理，容易实现线束的自动化组装。

2. 特斯拉的“准中央集中式架构”到底是怎样的？

2019年，特斯拉已经在Model3上实现了中央计算+区域控制器的EE架构方案，引领了潮流，那么特斯拉的这种架构究竟有哪些优势呢？

特斯拉Model3的车电子电气架构分为四大部分：CCM(中央计算模块)、BCM FH（前车身控制模块）、BCM LH(左车身控制模块)、BCM RH(右车身控制模块)。其中CCM(中央计算模块)由三个模块组合而成：信息娱乐系统(IVI)，驾驶辅助系统(ADAS)和车内外通信系统。

1）前车身控制模块：负责整车电源分配，车辆前舱用电器的逻辑控制和驱动；

2）左车身控制模块：负责左侧用电器的配电，左侧用电器的逻辑控制和驱动，包括左车身便利性控制以及转向、制动等底盘控制等；

3）右车身控制模块：负责右侧用电器的配电，右侧和背部用电器的逻辑控制和驱动，包括右车身便利性控制、动力系统、空调等。

特斯拉EE架构的优势：

1）智能驾驶模块的硬件部分采用了自研的FSD芯片；对于软件部分，操作系统基于开源Linux进行定制化裁剪，同时自研中间件。实现了软硬件自主可控，这样既有利于加快车型功能的的迭代更新速度，又大大降低了整车开发成本。

2）软件架构层面，采用了SOA架构思想，便于SOTA的部署以及云端数据的收集和分析。

特斯拉电子电气架构的先进性是毋庸置疑的，它的中央计算模块-CCM将智能驾驶模块、影音娱乐模块以及车内外网联模块集成在一起，并共用一套液冷系统。基本上实现了中央集中式架构的雏形，但并不是严格意义上的中央集中式架构，业内把这种类型称之为“准中央集中式架构”。

因此，即便是特斯拉，它距离真正的中央集中式架构也是还有一段路要走。基于当时技术成熟度和成本考虑：

1）通讯架构依然较为传统，以CAN总线为主，控制仍分布在MCU上，且MCU基础软件统一采用FREE RTOS；

2）中央计算模块CCM属于分离式：只是形式上将影音娱乐的MCU、智能驾驶的FSD以及车内外外网联模块集成在了一个板子上，但是每个模块依然是独立运行各自的操作系统，并独立完成各自的任务。

即使如此，特斯拉依然是中央计算+区域控制架构最先进理念的践行者，引发了业界其他同行的学习和追赶。

二、国内特斯拉EE架构的“追赶者”

在智能化和软件定义汽车时代，谁能掌握EE架构和软件的主导权，谁就能占据智能汽车市场的制高点。因此，国内主流整车企业也都在积极进行相关布局，“准中央集中式”架构方案的量产车型集中在2022-2023年左右推出。

但是，各家OEM规划的中央集中式架构形式上并不是太统一。比如，上汽零束的整车计算平台采用两个HPC高性能计算单元；广汽或者长城的方案采用中央计算平台、智能驾驶域和智能座舱域三大计算平台。但总体上来讲，研发设计理念大同小异：硬件上采用中央计算+区域控制的架构方案，软件上采用SOA软件架构的设计理念。

1. 上汽零束 - 银河全栈3.0方案

硬件平台方面：由两个HPC高性能计算单元HPC1和HPC2以及四个区域控制器（ZONE）构成。两个高性能计算单元作为整车的计算中心，用于实现智能座舱、智能驾驶以及智能驾驶冗余备份等功能；4个区域控制器用于实现各自不同区域的相关功能。

银河全栈3.0硬件平台（图片来源:上汽零束宣讲资料）

备注：

1）2021年8月，上汽零束与芯驰科技达成战略合作，将基于零束银河全栈3.0架构，共同制定芯片及整车电子电气架构的发展路线图；同时，双方将围绕芯片级底层软件操作系统、虚拟化平台技术，共同探讨、联合开发适用全栈3.0的狭义操作系统；

2）2021年9月，上汽零束宣布与创时科技联合设计开发基于“零束银河全栈3.0”的云管端一体化舱驾融合HPC。

软件平台方面：采用云管端SOA一体化软件平台

1）软件平台与硬件芯片以及操作系统解耦，即使不同EE架构平台的芯片类型和操作系统不一样，软件平台依然可以平移过来复用。比如零束的1.0架构平台和3.0架构平台，虽然底层硬件和操作系统不一样，但依然采用的是同一个软件平台。

2）在应用层，通过中间件和SOA原子服务层，使得向上能够提供统一、标准的API接口，能够让应用层开发更轻松，复用性更高。同时，再加上软件平台SDK，可以让OEM、供应商、第三方开发者和用户都可以加入到应用开发中来，实现应用生态共创。

银河全栈3.0软件平台（图片来源:上汽零束宣讲资料）

2. 广汽埃安 - 星灵架构

1）硬件平台方面：星灵架构由数字镜像云、3个核心单元模块和4个区域控制器（左/右/前/后）构成。其中，3个核心计算机模块包括中央运算单元、智驾域控制模块和座舱域控制模块；中央运算单元涵盖了新能源控制模块和车身控制模块，负责控制车辆行驶、制动和车辆设备等功能。

中央运算单元搭载NXP S32G399网关计算芯片，由8个A核+4个M核构成，并且内置LLCE+PFE加速引擎，通信延迟≤20μs；
座舱域控制模块搭载高通8155/8295芯片，7nm制程，具备105K DMIPS算力，支持3D人物形象渲染、人脸识别、AR-HUD等功能；
智驾域控制模块搭载华为昇腾610高性能芯片，7nm制程，支持200~400TOPS的算力拓展，ISP的图像处理能力可达2.4GPix/s，能够应对高速、城市等复杂道路情况。

星灵架构硬件平台（图片来源:广汽埃安宣讲资料）

2）软件平台方面：采用了分层设计的SOA软件架构

基础中间层采用原子服务封装和标准化接口；
专用中间层采用增强型组合服务，可独立执行；
APP软件层是与底层解耦的独立组件，可直接调用服务。

该软件架构实现了组件服务化、原子化和标准化，软硬件解耦，提升OTA能力和速度，同时实现硬件的即插即用——增加新的应用模块即可实现新的场景。

星灵架构软件平台（图片来源:广汽埃安宣讲资料）

3. 长城汽车- GEEP4.0架构

1）硬件平台方面：GEEP4.0架构由中央计算平台（CCU）、智能座舱模块（HUT）、智能驾驶模块（ICU），以及3个区域控制器（VIU_L 、VIU_R以及VIU_F）组成。

中央计算单元CCU的主要职责是把辅助自动驾驶、动力、底盘、车身、空调、车身状态以及模式管理等各个域的功能做集中的处理，在高阶自动驾驶配置下，CCU可以作为L3域控制器的备份，实现最低风险条件。

3个区域控制器：是一个标准化的控制单元，按照车身域进行划分、部署和开发，分别布置在左边、右边和前边，负责将周边的一些MCU就行整合，也就是将ECU、电源、控制器、输入/输出做一个整合。目前三个VIU的大部分软件算法已经上移到CCU中，由长城软件团队开发，VIU仅仅保留了很少一部分逻辑，更多是承担驱动I/O的作用。

GEEP4.0硬件平台（图片来源:长城汽车技术分享沙龙宣讲资料）

2）软件平台方面

应用软件层面，将大数据、云诊断、信息安全等软件系统融合，实现功能集成；
在不同核部署不同域的软件 - MCU核采用CP Autosar，在多个MCU核分别部署不同域电控软件；HPC核采用Linux OS和AP Autosar中间件；
通过在不同的核部署不同域的软件，在横向打通了多域之间的融合，在纵向打通了底层硬件、操作系统(CP autosar、Linux OS)、中间件（AP autosar）、协议栈以及应用软件之间的通讯；
支持FOTA，规划部分舒适性功能将支持SOA。

GEEP4.0软件平台（图片来源:长城汽车技术分享沙龙宣讲资料）

4. 小鹏X-EEA3.0

2021年11月，小鹏汽车在广州车展上发布了小鹏G9，计划于2022年上市；该车采用小鹏全新的X-EEA 3.0架构。目前小鹏官方关尚未透露过多具体的技术细节，笔者整理了以下几点信息供大家参考：

硬件架构：中央超算 + 区域控制；
软件平台架构分为三层：系统软件平台、基础软件平台和智能应用平台；
通信架构：采用千兆以太网通信；
数据架构：实现无感OTA - 域控制器均将内存进行分区隔离控制，一个区用于升级，一个区用于车辆正常运行；因此即使当车辆正常行驶的时候，依然可以同时进行新功能的OTA升级；
电力架构：用电设备供电可控，根据用户场景进行智能化精准配电，减少不必要的电力浪费，让电力得到最优化的利用。

三、EE架构升级变革带来的影响

1. 供应链体系的重塑

在传统分布式架构下，软件与ECU高度耦合。OEM对Tier1有较强的依赖关系，Tier1占据主导地位，软硬件以打包的方式直接供给OEM。产业链相对比较简单，上游是软件产品供应商/芯片供应商（Tier2），中游是零部件集成商（Tier1），下游便是整车集成厂（OEM）。

随着电子电气架构的升级变革，硬件逐渐的标准化，软件从硬件中剥离出来，软件和硬件实现解耦，使得由软件来定义汽车成为了现实。因此，OEM对掌握软件定义汽车的能力变得更加的强烈，他们希望能够逐渐的从Tier1手中夺回期盼已久的“主导权”。

为此，有进取心的OEM开始组建软件团队提升自己的软件研发能力，但毕竟还是有很长一段的路要走。在这样的背景下，一些人看到了车企对“自研可控”合作模式的强烈需求，于是出现了新的物种 — Tier1.5，向上可以支持OEM产品的自定义，向下可集成和整合Tier2的资源，以期能够在这场“主导权”争夺战中分一杯羹。

与此同时，传统Tier1为了维护自己的主导权地位，也纷纷开始进行垂直整合，打造软硬件全栈的研发能力，由零部件供应商向系统方案解决商转型，即由Tier1提升至Tier0.5 - 不仅可以为OEM提供软硬一体化的产品，还可提供从前期技术研发到后期数据共享等环节的全流程服务，希望能够继续保持和OEM之间的“亲密”关系。

2. 行业竞争格局的改变

当前进行先进EE架构研发的企业大致可以分为三类：整车企业、Tier1和科技公司。整车企业掌握中央集中式EE架构核心技术和部件主导权的动机比较强烈，因为他们已经看到了这种主导权给特斯拉带来的好处。但短期内能够实现这些技术和部件全部自研的整车企业仍是少数。大多数整车企业仍将依赖 Tier1 、科技公司以及其他供应商共同去完成。

整车电子电气架构的开发工程复杂且技术链路长，只有产业链上的玩家在各个环节能够相互协作，发挥各自的优势，并能够形成合力，起到1+1大于2的效果。这样才能帮助整车企业更快地完成架构的升级换代。

对于OEM而言，会依据自身实际情况选择适合自己的合作方式：

1）对于研发能力较强的头部车企，比如特斯拉，在芯片、操作系统、中间件、域控制器系统集成等关键核心领域都会选择自研，而对于一些硬件的生产会选择外包。

其次，自动驾驶感知算法相对比较复杂，即使是一些头部车企，在感知算法方面也会选择与业内实力较强的软件公司进行联合开发。在这个过程中，他们多半也会偷师学艺，逐渐提升自己的感知算法能力，最终向全栈自研的目标靠拢。

2）对于软件研发能力相对较弱的车企，则需要分清楚什么是共性的，什么是个性的。考虑到自身的研发实力及成本的压力，共性部分只能选择战略性地放弃，交给合适的供应商来帮助其完成开发；对于个性的部分，则需要尽自己最大的努力去做好差异化，打造出自己的品牌力。例如域控制器或者中央计算平台，就需要通过有全栈研发能力Tier1或者软件公司来帮助其逐步分层打开，然后自己在应用层做个性化和差异化的开发。

目前，主机厂的需求是个性化和多元化的，大都倾向于根据自己的需求要求供应商进行定制化开发。同时，OEM也在竭力提升自身的软件开发能力；从长期来看，对于Tier1和打算去做Tier1的科技公司而言，域控制器或中央计算平台的部分软件功能的开发权被主机厂“收回”已是大势所趋。因此，Tier1和科技公司也在极力打造软硬件的全栈技术研发能力，以避免沦为OEM的“硬件代工厂”。

3. EE架构的向上突破带来的新机遇

在智能驾驶进入下半场竞赛的关键时期，OEM开始升级自己的电子电气架构，以应对汽车智能化和网联化的发展。在这个关键的时间窗口，谁能够帮助OEM率先实现硬件模块化的快速替换和迭代升级，以及软件模块的可移植和最大化重用，谁便能获得主机厂的青睐，便能率先在新的市场站稳脚跟。

所谓时势造英雄，那么哪些类型比较容易出现“新风口”上的“英雄”呢？笔者判断会有以下几种类型：

1）大算力AI芯片公司 - 电子电气架构向域集中和中央域控快速发展，对主机厂来说，对高性能大算力计算平台的选择是当务之急。因此大算力芯片的供应商将迎来不断增长的市场空间。尤其是国内最近成长起来的一些芯片公司 —— 开放的系统方案，对本地化场景的理解能力，以及良好的工程配套服务能力是其当前的优势所在。

2）域控制器集成商 - 随着整车电子电气架构的升级，推动了域控制器渗透率的提升，域控制器这一新兴的市场未来会有很大的增长空间。具备可靠的产品质量，同时还能够帮OEM大大节省成本和缩短开发周期的域控制器集成商，将会迎来发展的契机。

3）基础软件平台供应商 - 对于软件势力稍弱的OEM，对于基础的软件平台这种共性的部分，没有必要进行重复开发，因为它是不会被消费者感知到的东西。因此可以选择把这部分交给合适的基础软件平台供应商去做，这样既可以降低自己的开发难度和开发成本，同时还能够把自身的人力和财力用于关键的个性化开发部分；有利于缩短产品开发周期，并尽快将其推向市场。

四、实现中央计算+区域控制架构的挑战是什么？

1. 底层“芯片”基础决定上层“架构”高度

高阶自动驾驶对算力的需求越来越高，搭载制程更先进、性能更强悍的芯片已经成为架构设计时所要考虑的首要问题，因为所计划采用芯片的量产时间会影响到架构方案的落地时间。

在设计中央计算+区域架构的时候，中央计算平台需要同时满足各域的需求和特性，为此需要算力更强的芯片以及各种操作系统的组合，最大的挑战就是选取可用的芯片。但目前尚未有量产的芯片能够同时满足几大功能域的要求，因此多数主机厂的还是采用多个芯片拼凑的方案：

1）车控系统：一般采用MCU，运行成熟的Classic AUTOSAR基础软件，实时性和安全等级要求高，但是算力和存储有限。

2）智能座舱和智能驾驶域，需要高性能、大算力的SoC芯片，并且还需要运行复杂的操作系统，并辅以中间件。

其次，现在入局车载领域的大算力、高性能芯片的玩家越来越多，同时芯片的迭代速度也越来越快，如果每次更换芯片都需要对整个技术架构进行重构，将会严重影响新产品的开发速度。因此，中央计算平台需要具有较好的拓展性，既需要拥有统一的传感器及外设接口，还需要具备良好的芯片兼容性。

2. 软件能力和软件团队建设

软件能力 - 目前主流功能域架构可划分为五个域：车身域、底盘域、动力域、智能座舱域、自动驾驶域。在向中央集中式架构发展的过程中，必然要做跨域融合，比如把车身域、底盘域以及动力域整合为一个整车控制域，以后的终极目标是所有功能域全部集成到一个中央大脑上来。在这样的发展过程中，不仅需要自建大量的软件功能服务能力；与此同时，更需要强大的软件能力去应对底层的实时操作系统、AUTOSAR以及其他关键软件模块之间的系统协同。

软件能力的另外一个体现，就是OTA，尤其是FOTA，需要OEM具备强大的软件开发能力，能够开发底层执行件的控制软件，才能够真正实现软件定义汽车的功能或者性能。

2018年美国《消费者报告》杂志指出，Model3在高速行驶状态下紧急刹车方面存在严重问题。当Model3以60英里/小时行驶时，其制动距离约为46.3米，高于同级别其它车型。为解决此问题，Model 3 通过远程推送固件升级。最终的结果是通过OTA，Model3的紧急刹车距离缩短了大约6.1米。

Model 3 制动系统的硬件采用的是博世的iBooster，但底层的电控软件是特斯拉自研的，因此才能通过OTA升级，实现了对刹车踏板特性的调节，即通过调整刹车响应曲线来实现整个刹车过程中的制动力最优化的分配，从而缩短了刹车距离。

软件团队建设 - OEM若要实现真正的软件定义汽车，即车辆的绝大多数功能和性能都由自己来定义，那么对其自身的研发能力，特别是软件的研发能力，都将是一个比较大的考验。现在有实力的OEM都在大规模的组建软件研发团队，软件开发人员在人才市场上已经明显供不应求了。甚至出现了即使舍得用高薪和期权去“引诱”，也难以“套”到合适人才的尴尬局面。同时，软件团队的管理和协调也比较复杂，这也是传统OEM需要重新进行强化学习的地方。

3. 组织体系的问题

传统OEM具备多年逐步搭建和完善起来的研发团队、产品体系以及供应链体系。但是，在进行整车EE架构变革的时候需要考虑和顾忌的东西会更多，比如，原来生产线的可复用性问题，架构对庞大产品线的兼容性问题，以及全球各地的供应链问题等等。

中央集中式架构的一大特点是算力向中央集中，这样的话，肯定会砍掉很多ECU。如果车上有大量ECU被砍掉，对于依赖这些部件的员工以及与之相关供应商来说，这是生死攸关的事情。如果他们无法在内部和外部做好调整，那么新的架构就很难快速地被推进和实施。

从某种程度上讲，传统OEM凭借多年积攒起来的供应链以及产品体系优势等，现在却成了一把“双刃剑”，开始阻碍他们进行架构的创新。因此，他们在进行架构改革的时候根本不太可能“一刀切”，全盘推倒以前的方案，全部转换到新的E/E架构上来，只能利用现有资源分阶段地向前过渡和演进，并逐步提升自身的软件研发能力和改变自身的研发组织架构去适应新的研发流程。