一、产业发展现状

1.1 国外整体产业发展现状

什么是电子电气架构？在2007年由德尔福(DELPHI)首先提出E/E架构的概念，具体就是在功能需求、法规和设计要求等特定约束下，把里的传感器、中央处理器、电子电气分配系统、软件硬件通过技术手段整合在一起；通过这种结构，将动力总成、传动系统、信息娱乐系统等信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、电源管理等电子电气解决方案。

关于电子电气架构演进， 行业内讨论最多的是博世提出的电子电气架构发展六阶段，如下图所示。博世将整车 EEA 划分为六个阶段：模块化（Modular） 、 集成化（Integration）、域集中（Domain Centralization） 、 域融合（Domain Fusion） 、 整车中央计算平台（VehicleComputer） 、 车-云计算（Vehicle Cloud Computing）阶段。该演进概念清晰指明了未来电子电气架构算力会逐渐集中化， 最终会发展到云端计算。当前主流架构处于功能域控制器集中阶段， 正在朝多域控制器融合架构方向发展。

博世 EEA 发展六阶段

为了适应市场对电动化的需求， 实现从分布式向集中式电子电气架构转变。国内外整车企业已开始建立适合未来的车辆电子电气架构和汽车软件架构， 使其可以在不同的车辆计划、开发单位和组织之间进行协调， 从而提高开发的灵活性和创新性， 减少开发时间与风险。国外整车企业如特斯拉和大众已实现整车集成至 4 个主控 ECU， 实现整车域控制器软件开发，实现软硬件解耦设计， 并多次通过 OTA 升级整车功能。

特斯拉 Model S、 Model X 再到 Model 3 /Y 的电子电气架构演变， 推动力是商业模式及技术路径的变革， 充分体现了软件定义车辆的技术创新。

目前最有名的是特斯拉 Model 3 采用的架构， 如上图。Model 3 车载中央电脑和区域控制器架构， 采用 Autopilot（自动驾驶） +IVI（信息娱乐系统） +T-BOX（远程信息处理器）三合一计算平台， 将三块控制板集成到同一壳体中， 新引入 BCM-F/L/R 三个区域控制器， 实现 ECU 整合并对执行器供电。彻底抛弃了功能域的概念， 实现集中式电子电气架构和区域控制器方案， 通过中央计算模块（CCM） 对不同的区域 ECU 及其部件进行统一管理，并通过CAN（（控制器局域网） ） 进行通信， 并实现了高度集成， 高度模块化， 对传统汽车电子架构进行了全方位的创新， 实现了“软件定义汽车”， 加快了汽车产品迭代速度。实现了算力集中化、 服务附加值提升、 内部拓扑结构简化。特斯拉的准中央计算 EEA 已带来了线束革命，Model S/Model X 整车线束的长度是 3 公里， Model 3 整车线束的长度缩短到了1.5 公里， ModelY 进一步缩短到 1 公里左右。

特斯拉的集中控制功能集成在三个域控制器中， 中央计算模块直接整合了智能驾驶与信息娱乐域控制模块， 以及外部连接和车内通信系统域功能， 架构方案较之前车型简化， 即：AICM（智能驾驶与信息娱乐域控制模块）：连接各类自动驾驶传感器， 综合执行逻辑计算功能， 以及完成人机交互；FBCM（前车身控制模块） /智能配电模块：负责 12V 的电池、 电源分配和热管理的功能；LBCM（左车身控制模块） 和 RBCM（右车身控制模块）：分别负责剩下的车身与便利系统、 底盘与安全系统和部分动力系统的功能。

大众为了适应市场对电动化的需求， 推出了 MEB 平台， 实现从分布式向域融合电子电气架构转变。MEB 电子电气架构分为整车控制器（ICAS1） 、 智能驾驶（ICAS2） 和智能座舱（ICAS3） 三大域控制器。ICAS1 实现整车所有控制类功能集成， 如高压能量管理、 低压电源管理、 扭矩控制、 车身电子控制、 网关、 存储等功能；另外 ICAS1 连接诊断接口和 T-BOX，实现信息安全设计， 并作为 OTA 主控 ECU 实现整车并行刷写。ICAS2 作为智能驾驶运算中心， 通过以太网接收 ICAS1 的雷达和摄像头信息， 实现运算处理， 并实现对于制动和转向系统的请求。ICAS3 采用一机多屏控制方式， 通过以太网接收 ICAS1 和 ICAS2 的需求。另外大众推出自身 VW.OS， 并采用 Adaptive AUTOSAR（又称 AUTOSAR AP， AUTOSAR 自适应平台） 和 SOA 实现不同应用的集成。

沃尔沃的区域电子电气架构包括 Core System（核心系统） 和 Mechatronic Rim（机电区域） ， 如下图 所示。沃尔沃的 VIU（Vehicle Integration Unit， 整车集成单元） 对应不同整车区域的感知、 控制与执行。沃尔沃的 VCU（Vehicle Computation Unit， 整车计算单元/整车控制器） 对应车载中央计算机， 提供整车智能化所需的算力与数据存储。

沃尔沃 EEA 架构示意图

奥迪将采取中央集群计算方案（Central Computing Cluster ） 。 如下图所示， 整车划分为： 驱动域、 能源域、 横纵向控制域、 驾驶辅助域、 座舱域、 车身舒适域、 信息安全域；不同的域之间通过高速以太网来进行信息交互， 域内采用 CANLIN 等进行实时低速通信；新架构分为传感器与执行器层和承载不同功能的域层； 车辆的中央计算单元会与企业的后台相连接， 奥迪的后台会与 HERE 后台相连， 接进行数据共享。

奥迪 EEA 架构示意图

1.2 国内整体产业发展现状

目前， 国内主流汽车企业三化融合车型的电子电气架构方案已从完全分布式控制， 进入域集中式控制。 国内造车新势力普遍直接采用功能域控到域融合的过渡方案， 域融合方案普遍集中在智能驾驶和智能座舱。

1.2.1 小鹏汽车G9电子电气架构具领先性

势力三强中小鹏汽车在电子电气架构方面走得比较领先，随着车型从 G3、P7和P5，迭代到 G9 的这套X-EEA3.0电子电气架构，已经进入到中央集中式电子电气架构。凭借领先一代的架构，搭载更高算力SOC芯片及更高算力利用率，小鹏G9或成首款支持 XPILOT 4.0 智能辅助驾驶系统的量产车。

小鹏P7搭载小鹏第二代电子电气架构，具备混合式的特点：

• 分层域控——功能域控制器（ 智驾域控制器、车身域控制器、动力域控制器等模块）与中央域控制器并存；

• 跨域整合——域控制器覆盖多重功能，保留局部的传统 ECU；

• 混合设计——传统的信号交互和服务交互成为并存设计。

因此 CAN 总线和以太网总线并存，大数据/实时性交互均得以保证；以太网节点少，对网关要求低。

因此CAN总线和以太网总线并存，大数据/实时性交互均得以保证；以太网节点少，对网关要求低。小鹏第二代电子电气架构实现传统ECU数量减少约60%，硬件资源实现高度集成，大部分的车身功能迁移至域控制器，中央处理器可实现支持仪表、信息娱乐系统以及智能车身相关控制的大部分功能，同时集成中央网关，兼容 V2X 的协议，支持车与车的局域网的通信，支持车与云端的互联，车与远程数字终端的连接功能。小鹏汽车的智能驾驶域控制器，集成了高速NGP、城市GNP及泊车功能。小鹏辅助驾驶采用激光雷达视觉融合方案，与特斯拉的纯视觉方案不同，这就导致两者硬件架构不同，对于通讯带宽、计算能力的要求也不一样。

小鹏汽车电子电气架构演进历史

小鹏汽车将其X-EEA3.0电子电气架构称为“让智能汽车在未来永不落伍的秘密”。根据公司披露的首搭于 G9的电子电气架构的信息，未来 G9可以升级和优化的潜力较大。

X-EEA 3.0硬件架构方面，采用中央超算（C-DCU）+区域控制（Z-DCU）的硬件架构，中央超算包含车控、智驾、座舱3个域控制器，区域控制器为左右域控制器，将更多控制件分区，根据就近配置的原则，分区接管相应功能，大幅缩减线束。

得益于小鹏汽车的全栈自研能力，新架构做到了硬件和软件的深度集成，不仅实现软硬件解耦，也实现软件分层解耦，可使得系统软件平台、基础软件平台、智能应用平台分层迭代，把车辆的底层软件和基础软件与智能、科技、性能相关的应用软件脱离开，在开发新功能时，只需要对最上层的应用软件进行研究和迭代就可以，缩短了研发周期和技术壁垒， 用户也能够享受到车的快速迭代。

• 系统软件平台：基于外购代码做部分定制开发，随整车基础软件平台冻结而冻结， 可复用于不同车型；

• 基础软件平台：多个整车基础功能软件均形成标准服务接口且在车辆量产前冻结， 可复用于不同车型；

• 智能应用平台：如自动驾驶、智能语音控制、智能场景等功能，可实现快速开发和迭代。

X-EEA 3.0 数据架构方面，域控制器设置内存分区，升级运行互不干涉，便用车边升级，30分钟可升级完成。

通信架构方面， X-EEA3.0 在国内首次实现了以千兆以太网为主干的通信架构，同时支持多通讯协议，让车辆在数据传输方面更快速。从G9 搭载的新一代电子电气架构可以看出，小鹏在骨干网络的建设和面向 SOA 的方向起步较早。

X-EEA 3.0 电力架构方面， 可实现场景式精准配电，可根据驾驶、第三空间等不同用车场景按需配电，比如在路边等人时，可以只对空调、座椅调节、音乐等功能供电，其他部分断电，这样就能实现节能耗节省，提高续航里程。车辆定期自诊断，主动发现问题，引导维修，以科技手段赋能售后。

小鹏汽车第三代电子电气架构实现千兆以太网+中央计算+区域控制

1.2.2 极氪001汽车电子电气架构

极氪汽车已量产（车型：极氪 001） 的电子电气架构是功能域集中式架构 ，由四大功能域主控承担整车级别的各域功能逻辑软件部署中心的角色， 将绝大多数传感器和执行器的控制逻辑与整车功能应用进行分离， 大部分普通 ECU 作为纯粹的传感和执行控制单元， 功能域内跨子系统和子系统内部的逻辑接口交互在域控内部即可完成， 跨域信息交互通过 Flexray（高速容错网络协议） 和以太网为主干网的双网实现。ECU 实现功能业务应用和执行器控制逻辑的解耦， 功能接口模块化、 标准化、 开放化。在电子硬件集成度上， 域控集成了大量的简单 I/O 驱动 ，复杂的执行器和传感器作为独立的电子单元通过CAN/LIN/A2B/LVDS 等网络连接在各自的域控上， 一定程度上缩减了 ECU 数量、 降低了整车成本。

极氪汽车 EEA 架构示意图

1.2.3 华为CCA架构

华为基于自身的 ICT 技术为积累， 推出华为 CCA 架构为基础的全栈式解决方案 。其中底层的基础是“计算+通信”为核心的 CCA 架构， 用以太环网作为车载通信主干网络， 实现了“功能域”+“区域”的集成。以太环网+VIU 区域控制器构建车内通信架构。整车网络架构设置 3-5 个 VIU， 相应的传感器、 执行器甚至部分 ECU 就近接入， 实现电源供给、 电子保险丝、 I/O 口隔离等功能。VIU 之间通过高速以太网的环形网络进行连接， 确保整车网络高效率和高可靠。在整车通信架构之上， 设置智能座舱域控制器 CDC、 智能驾驶域控制器 MDC 和整车控制VDC， 共同完成信息娱乐、 自动驾驶、 整车及底盘域的控制。

1.3 国内外架构整体方案对比

总体而言， 国内整车企业电子电气架构整体方案与国外传统整车企业方案相当， 都处在功能域控或功能域控到域融合的过渡阶段。 不过， 国内方案相对比在行业内处于领先地位的特斯拉架构方案， 大概有 3~5 年的的差距，这些差距主要体现在：

a. 功能软件设计模型方面， 国内整车企业自主设计车载核心功能较少， 缺少开发和验证能力积累。

b. 架构设计的模型库方面， 尤其是在智能驾驶功能方面， 国外主流整车企业在开发智能驾驶功能时均基于较为完善的功能模型库进行设计和验证， 以确保智能驾驶的可靠性和安全性。而国内各整车企业在智能驾驶功能模型的开发领域还处于空白阶段， 大部分需要依靠国外供应商或者第三方技术支持才能开展智能驾驶设计工作。另外， 智能驾驶的场景数据库也是目前国内整车企业的储备软肋。

c. 控制器底层软件方面， 市场底层软件多为国外产品， 我国产品的应用范围少、 用量少， 很难发展完善；

d. 主流车载总线技术方面， 技术被国外垄断， 难以满足国内汽车在通信方面需求；

e. 汽车电子基础软件方面， 国外汽车行业已较成熟（日本汽车软件标准化组织 JASPAR和欧洲 AUTOSAR 体系） ， 而国内属于发展初期。另外， 汽车电子底层软件主要依赖国外零部件供应商。

f. 网络架构设计方面， 汽车的通信网络需要满足大带宽、 高实时性的要求，车载以太网作为车载网络中的主干网是新型网络架构的必然趋势。国际上基于车载以太网的新型网络拓扑结构以及通信协议已经基本成型，而国内车载以太网的研究和应用较少， 无法在车载以太网标准发布后快速进入应用阶段。

g. 冗余技术方面， 冗余技术在保证未来智能汽车安全性和可靠性方面具有十分重要的作用， 国际上领先的电子电气架构研发团队提出多种冗余方式， 将冗余技术应用在整个电子电气架构的开发过程中。国内目前更多将冗余技术应用于高级别自动驾驶系统的开发中。

二、产业技术发展趋势

2.1 电子电气架构演进

传统汽车采用的分布式 EEA 因计算能力不足、 通讯带宽不足、 不便于软件升级等瓶颈，无法满足现阶段汽车发展的需求， EEA 升级将助力智能汽车实现跨越式革新。博世提出了众所周知的电子电气架构技术路线图， 并描绘了未来电子架构的主要特征及可能的实现时间点。其中的两个重要标志性节点依然值得强调， 即 DCU（域控制器） 或 HPC（高性能计算机）平台的出现， 以及统一的基础软件平台的出现， 标志着 EEA 的本质进化。

a.在基于域控的集中式架构之下， 各个功能部件均成为独立的域， 在每个域之下有相应的控制功能集合。域与域之间可以做到安全隔离， 也可以根据需求进行通信和互操作， 形成类似以太网总线上的计算机局域网， 变成了松散耦合的架构。各域控制器完成各自的的数据处理， 并在域本地完成决策， 只通过中央网关与其它域控制器交换所需数据。其中， 与自动驾驶相关的传感数据由自动驾驶域控制器处理后进行决策。

b.跨域融合架构：为进一步提升性能， 满足协同执行又减少成本， 跨域融合集中化方案应运而生， 即将两个或者多个集成型域控制器合并为一个域控制器。比如动力域和底盘域的合并、 车身域与智能座舱域的合并， 座舱域和自动驾驶域再集成至同一控制器硬件， 达到部分程度的中央域控。该架构示意图如下图所示：

c.在未来， 随着高级别自动驾驶的规模化应用， 汽车电子及软件功能大幅增长， 架构形式将向基于中央计算平台的整车集中式电子电气架构演进：各采集、 执行节点将原始数据通过网关传输到中央控制器处理， 所有数据的处理与决策制定都在这里完成。其中， 与自动驾驶相关的传感数据也将由中央控制器处理后进行决策。

d.最终电子电气架构将向车路云协同架构发展。车路云协同架构是利用新一代信息与通信技术， 将车、 路、 云的物理层、 信息层、 应用层连为一体， 进行融合感知、 决策与控制，可实现车辆行驶和交通运行安全、 效率等性能综合提升的一种信息物理系统。

而整车中央集中化阶段和跨域融合阶段的本质不同是：一， 软硬件完全分离， 且所有的ECU/DCU 共享同一套基础软件平台。二， 相互独立的功能应用搭载在一套高算力的车载计算机（HPC） 上， 且它的算力远超阶段二的 DCU。三， 基础软件平台+功能独立+HPC 将带来规模化， 即一套架构可以承载任何形式、 数量的功能及服务。

2.2 整车计算平台形态演进

整车计算平台主要分为三个部分， 自动驾驶集成平台（ADIP， Automated Driving Integration Platform） 、 车控集成平台（VIP， Vehicle Integration Platform） 以及座舱集成平台（CIP， Cockpit Integration Platform）。VIP 的主要功能范围是集成动力控制、 车身控制、 网关功能以及区域控制器控制和管理；

ADIP 的主要功能范围是高阶自动驾驶、 驾驶辅助以及车辆运动控制；

CIP 的主要功能范围是娱乐以及网联的功能集。同时它们之间都有功能交集，正是因为这些功能交集的存在， 整车计算平台的形态也会存在多种， 如下图

整车计算平台功能交集（博世）

• 针对 ≤ SAE Level 2+ 应用场景， 如下图所示有三种模式：

整车计算平台三种模式（≤ SAE Level 2+）

Pattern A: 三个集成平台之间相对独立， 适合于 L2+应用；

Pattern B1: CIP 集成了 L2+的驾驶辅助功能；

Pattern B2: VIP 集成了 L2+的驾驶辅助功能；

Pattern C: xIP（Cross-domain Integration Platform， 跨域集成平台） 集成了所有， 通常 ADIP 和 CIP 整合在一起也属于这个范畴；

Pattern B2 方案， 目前的解决方案主要还是外扩一个单独的算力芯片进行驾驶辅助的感知等处理。

Pattern B1 方案， 目前以及下一代的座舱芯片已有足够的算力去直接集成驾驶辅助的功能， 无需单独的硬件芯片， 一些整车企业已经把集成泊车功能作为第一步， 进一步集成 L2+的行车功能。

VIP 功能主要用来实现动力控制、 网关以及车身等基础功能， 对于实时性有很高的要求。驾驶辅助功能是以数据驱动的开发方式， 持续频繁地进行软件迭代。把 VIP 和辅助驾驶功能糅合在一起， 复杂程度会很大， 并且在成本效率上也没有明显优势。因此 Pattern B1 方案会优于 Pattern B2 方案。

总体而言， Pattern A 目前仍然会是实现 L2+的主要架构形式， 单独的 ADIP 允许接入更多的传感器， 可以实现更多的功能场景；针对 L2+的应用， Pattern B1 会优于 Pattern B2；长期发展方向会向着 Pattern C 去演变。

• 针对 ≥ SAE Level 3 应用场景， 如下图所示有三种模式：

整车计算平台三种模式（≥ SAE Level 3）

针对≥L3 应用， 自动驾驶的冗余是必要的：

Pattern A：ADIP 内部或外部冗余

Pattern B1: ADIP 和 CIP 组成冗余

Pattern B2: ADIP 和 VIP 组成冗余

Pattern C: xIP 内部实现冗余

总体而言， 针对 L3 或以上的应用， Pattern A 优于 Pattern B1， Pattern B1 优于 Pattern B2；长期发展方向会向着 Pattern C 去演变。

2.3 构建 SOA（面向服务架构）

2.3.1 SOA

面向服务的架构 SOA（Service-Oriented Architecture） 是一种软件架构设计的理念和方法论， 也是 IT 行业企业软件的一种主流架构风格， 是一个架构组件模型， 将软件组件（称为服务） 通过定义良好的标准接口和服务契约联系起来。SOA 架构需从传统电子电气架构的“面向信号”转变为“面向服务”， 将功能独立出来。

其核心内涵即从本质上通过复用、 松耦合、 互操作等机制来提高软件质量、 加快软件研发效率、 使研发出来的产品能够交互并灵活适应业务变化。

目标是如何最大限度地减少应用（或业务） 变化对已部署或正在运行的软件系统带来最小的冲击， 以满足长期治理的需求， 实现服务架构随应用变化可持续性演化。

2.3.2 软件的工业化生产

面对车载软件庞大且仍在增加的软件代码量， 汽车行业开始借鉴 ICT（信息通信技术）行业的“软件工厂”理念。比如戴姆勒旗下的全资软件开发公司 MBition 正在打造软件工厂，根据开发项目需求， 通过对软件组件的标准化、 结构化运用， 实现快速开发。正如传统制造业在上世纪初引入福特式流水线生产那样， 软件开发也正在从“定制化手工制作”向“自动化产线制造”转变。

软件工厂需为开发者提供可行的软件框架、 配套的开发指令、 预设的程序模板、 可复用的代码以及伴随开发进程可以连续测试的环境。在此基础上， 当软件工厂收到一项开发需求时， 开发者能够根据工厂现有能力拆解需求模块， 并将其分配至各个“产品线”， 每个产品线再根据新需求识别可以复用和需要新开发的部分， 判断开发工作所需资源， 最后部署开发、测试工具并完成任务。相比于传统的“手工”开发模式， 软件工厂可以提升软件产品的一致性、品质和开发效率， 提前识别开发工作量， 前置风险， 使整个开发和部署流程更可预测，大大提升了车企对软件工作的资源配置和进程管控能力。

2.3.3 软件与服务成为差异化的关键

汽车电子电气架构的变革使得汽车硬件体系趋于集中化， 软件体系的差异化成为汽车价值差异化的关键。科技公司进入汽车行业推动了供应链生态体系的变化， 汽车产业链逐渐从整车企业、 一级、 二级供应商的线性关系演变为更加复杂的整车企业、 供应商和科技公司均参与的汽车新生态体系， 以及整个产业覆盖汽车全生命周期的网状关系。商业模式上也从出售汽车硬件发展为出售硬件与后续服务的转变。研发流程也从软硬件集成开发转变为软硬件解耦的独立开发。新的整车电子电气架构构成了未来汽车的核心， 软件和服务能力将成为未来汽车产业里最为重要的竞争力。

2.3.4 标准化的软件架构将逐步建立

汽车软件架构走向分层化、 模块化， 使得应用层功能够在不同车型、 硬件平台、 操作系统上复用， 并且可以通过标准化接口对应用功能进行快速迭代升级。未来随着智能网联汽车的应用场景越来越丰富和逐渐固化， 在面向服务设计思想下， 在容器化和虚拟化技术的支持下， 汽车硬件设备趋向于具备通用性、 算例化和标准化特性。系统软件和功能软件将是汽车行业技术研发和应用的重点。整车企业将更多聚焦在产品定义、 应用算法开发及系统集成匹配等方面， 而底层共性的基础软件架构等可由专业的供应商提供。

2.3.5 汽车产业格局将被重塑

在软件定义汽车时代， 整车企业为了掌握主导权并降低高昂的研发成本， 往往会选择直接与具备较强的独立算法研发能力的软件供应商合作， 因此这些软件供应商一跃成为了 Tier1厂商。未来， 软件供应商的盈利模式有望发生转变， 基础平台开发以许可费的形式收费， 功能模块以版权费的形式收费及定制化的二次开发费用等。“硬件预埋， 软件升级”成为当下车企的主流策略， 至 2025 年将成为 L3 及更高级别自动驾驶发展的关键节点， 具有领先软件和算法能力的车企、 软件供应商有望获得重要发展机遇。

从长期来看， SOA 将重构汽车生态， 汽车行业或将复制 PC 和智能手机的软件分工模式。车企可通过自建或与供应商合作搭建操作系统和 SOA 平台， 引入大量算法供应商和合作伙伴等形成开发者生态圈， 汽车行业上下游参与者各自的角色与定位将发生根本

2.4 通信架构升级

随着新一代架构的发展和自动驾驶的应用， 车载网络技术的发展趋势为高带宽、 低延时、高可靠、 车云协同。汽车网络通信系统朝向多网络、 高带宽、 低延时、 多冗余、 高可靠等方向发展， 同时打破核心技术垄断， 提升自主化率， 逐步实现引领超越。

车载网络技术趋势

预计至 2025 年， CANFD-XL、 10Base-T1S、 2.5G+Base-T1 等车载总线技术将趋于成熟，逐渐量产应用。

预计至 2025 年， 随着中央计算+区域控制器的架构逐渐实施， 将逐渐发展为以 1G+车载以太网为骨干网的网络架构， 结合 AVB/TSN、 SOME/IP、 DDS 等传输协议， 解决低时延、 高带宽、 高同步、 高冗余应用场景传输需求。

通信技术正在快速演进中， 从 CAN 到 CANFD 到 CAN XL, 从 100M 以太网到 1G 以太网到 2.5G 以太网， 甚至 10G 以太网的技术。

自动驾驶需要以更快速度采集并处理更多数据， 传统汽车总线无法满足低延时、 高吞吐量要求。因此， 集带宽更宽、 低延时等诸多优点的以太网有望成为未来车载网络骨干。2015 年首个车载以太网规范 100Base-T1 发布，仅需要一对双绞线进行传输， 可以减少 70-80%的连接器成本， 减少 30%以上的重量， 并且能够有效的满足车内 EMC（电磁兼容性） 电磁干扰的要求。随着 1000BASE-T1 以及更高带宽 NGBase-T1 以太网标准的不断推出， 以太网有望成为未来智能汽车时代的车载主干网络。不过为了不使零部件成本和线缆重量急剧增加， 并且尽可能降低技术升级带来的安全风险， 各域内依然保持 CAN/CAN FD 的连接架构。

2.5 功能安全、 网络安全升级

随着汽车智能化程度的不断提高， 面对车内外通信的复杂环境和未知情况， 必须提高安全策略级别以应对复杂多变的外部环境。汽车架构的初期设计中需充分考虑安全保障， 并在在整个产品使用生命周期内确保安全性。根据新一代电子电气架构的正向开发方式， 利用用户思维、 软件思维和硬件思维从整车、 系统和部件的角度开展从上到下的架构设计， 将安全体系融入其中， 并在汽车的整个生命周期内对安全保障进行维护。汽车的智能化使得监管和法规将《机器人安全总则》 三法则延伸到汽车产业上。所以最近这十年来， 汽车安全的监管和法规呈现三个趋势：

• 从结果安全逐步向架构、 设计、 开发、 构建、 集成与测试、 生产制造等全过程安全 可控扩展；

• 从功能安全向网络、 数据、 隐私等安全与合规扩展；汽车数字体验需要不断地获取数据和服务， 而且功能要始终保持更新， 因此必须从一开始就在系统开发中考虑数据安全；

• 从整车安全向每个部件安全扩展。

2.6 计算芯片短期分化与长期融合

2.6.1 自动驾驶高性能芯片的定制化

由于自动驾驶算法仍具有高度不确定性， 芯片方案需兼顾目前 AI 算法的算力要求和灵活性， GPU（图形处理器） +FPGA（现场可编程逻辑门阵列） 的组合受到大多数玩家的青睐。当自动驾驶技术路线相对成熟且进入大规模商用的阶段后， GPU 也难以胜任对更多空间信息的整合处理， 需要定制的专用集成电路 ASIC（特定用途集成电路） 。ASIC 芯片可在相对低水平的能耗下， 提升车载信息的数据处理速度， 虽然研发和首次“开模”成本高， 但量产成本低， 是算法成熟后理想的规模化解决方案。然而， 鱼和熊掌不可兼得， 低功耗、 大算力、 可编程灵活性（以应对算法的快速升级） 在短期内是无法完美兼顾的。

多核 SoC 将成为未来智能座舱主控芯片的主流。丰富生态的中控大屏系统、 “一芯多屏”系统、 AR-HUD 等多屏场景需求需要多核 SoC 进行支持。多核 SoC 芯片技术解决方案发展呈现多样化， 如车机主控芯片+MCU 兼顾安全的方案以及集成式的座舱域控制器方案。

2.6.2 芯片的长期兼容与融合

远期来看， 负责不同域的芯片架构将呈现兼容与融合趋势。如前文所述， 短期内自动驾驶高性能芯片和座舱主控芯片分别演进。究其原因， 座舱应用场景和芯片性能要求已相对明晰， 并且消费电子级芯片可满足座舱现有场景需求， 消费电子芯片可以利用规模优势实现低成本商业化开发；相反， 自动驾驶技术路线尚不成熟， 其人工智能算法所要求的芯片性能远高于目前消费电子芯片的能力， 因而在自身技术路线选择下进行高成本、 小规模开发应用。据罗兰贝格预测， 2030 年以后， 随着自动驾驶技术路线的逐渐成熟， 高性能芯片进入标准化、规模化生产阶段， 其与座舱主控芯片进一步向中央计算芯片融合， 从而通过集成进一步提升运算效率并降低成本， 但由于自动驾驶和座舱安全要求不同， 满足安全要求将成为融合的前提。

三、问题和挑战

3.1 基础软件平台规范、 接口不统一， 服务化架构刚起步

3.1.1 平台规范层面

对于车载基础软件来说， 如何满足整车电子电气架构变化的需求， 是值得深入探讨的关键问题。一方面， 基础软件平台需要统一标准并兼容不同整车企业的应用， 另一方面， 基础软件平台安全性需要重点加以考虑， 并给出系统性解决方案。

无论是域集中式架构还是基于中央计算平台的架构， 整车功能设计， 控制逻辑都离不开高性能计算单元。高性能计算单元的引入增加了基础软件平台的复杂度， 整车功能设计如何把握和驾驭这种复杂度成为首要问题。同时， 基于 SOA 的整车设计和功能服务化理念也对基础软件平台产生了重要影响， 如何满足新的设计和功能， 实现未来需求也是亟待解决的问题。

电子电气架构基础软件平台技术和测试要求的标准化和规范参考有助于形成软件定义汽车的行业共识， 降低整车企业、 零部件供应商等之间的沟通成本， 实现应用软件复用， 提高开发效率。不过国内汽车基础软件平台产业及标准化及产业发展刚起步， 各行业组织或企业切入方式和领域不同， 有待形成进一步的共识。于此同时， 基础软件平台的安全性也应从整车电子电气架构视角考虑信息安全、 功能安全、 通信安全等。

3.1.2 接口层面

接口标准化主要是为智能驾驶、 智能交互等应用提供标准化的运行环境和服务， 满足不同硬件外设可扩展、 即插即用以及功能/应用软件包可升级、 可复用， 高效实现和互操作， 实现软硬件分层解耦， 满足跨平台、 跨车型、 可扩展等要求。

当前汽车传感器、 执行器等设备的物理接口、 电气接口和通信接口还未实现标准化。以执行器为例， 执行器的物理接口受限于供应商及整车企业的布置以及产品延续性等因素， 其标准化进程较为艰难， 目前只局限于单个供应商内部的标准化或是单个整车企业内部的标准化。执行器的电气接口当前多数为硬线驱动， 由于执行器的驱动方式不同， 导致其硬线的电气接口也不尽相同；但这些年已慢慢向 CAN 或 LIN 接口的智能执行器方向发展， 节省大量的硬线线束与 ECU 硬线接口， 省去了接口电路的匹配工作， 诊断与刷写程序更加便捷， 状态监测以及故障诊断信息更加丰富， 为 ECU 电气接口的通用化、 标准化提供了保障；而执行器的通信接口标准化目前还局限于单个供应商内部或是单个整车企业内部， 待电气接口标准化后逐步完备。

此外， 在远程服务和车云通信方面， 除了 GB/T 32960《电动汽车远程服务与管理系统技术规范》 规定了电动汽车远程服务与管理系统中协议结构、 通信连接、 数据包结构与定义、数据单元格式与定义， 其他智能驾驶车辆功能的车云交互数据种类、 格式、 协议以及信号各类属性的标准化工作暂未有统一性的成果发布。

智能网联和智能驾驶技术正在日新月异的进化中， 各汽车企业开发和应用电子电气架构的技术路线各异， 架构服务化程度各异， 设备抽象和原子服务数据结构标准化对实现软件定义汽车有着显著价值， 同时接口标准化工作刚刚起步也面临着极大的挑战。

3.2 自主开发操作系统内核和虚拟化软件的挑战。

随着汽车电子电气架构的发展， 分布式架构向集中式架构过渡， 这需要域控制器在软件层面利用虚拟化技术在一个处理器上集成多个操作系统与应用系统。虚拟化软件层作为支持多个操作系统内核和应用系统同时运行的基础模块， 其安全性、 隔离性和时延小成为系统的关键要素。操作系统内核和虚拟化软件是底层操作系统最为核心的基础模块， 同时也是保护系统安全的核心组件。智能网联汽车的特殊属性， 要求操作系统内核和虚拟化软件应该满足高实时、 高安全、 高性能和高可靠性。在功能安全和信息安全方面面临着极其严苛的考验。

3.3 工具链层面缺乏从电子电气架构概念设计到产品系列开发的全过程的协同开发平台。

针对汽车电子电气系统复杂的开发过程， 比如急剧增加的车型功能特性及复杂度、 不同技术职能部门相关人员参与与设计交互、 不同车型的特性配置管理与方案评估等， 电子电气系统设计工具需提供给用户一个完整的协同开发平台， 支持从电子电气架构概念设计到产品系列开发的全过程。

当前工具链多为国外企业提供， 车规级芯片工具链平台， 包括操作系统、 集成开发环境（IDE） 、 编译器、 调试与烧录工具、 开发评估套件、 底层驱动库、 USB 协议栈、 TK 产品应用开发包、 无线产品应用开发包， 以及和实时操作系统供应商合作开发的嵌入式操作系统板级支持包。

但在面向新一代 EEA 的服务化设计方面， 缺少成熟工具链支撑， 特别是需要支持团队协作甚至是跨地域的协作模式的服务设计平台， 目前国内外较为缺乏。

3.4 智能网联化对汽车通信技术提出了大带宽和高实时性的要求。

通信协议栈是汽车电子电气架构的重要组成部分， 基于 CAN 总线的信号传输已经无法满足全部需求， 而新型总线的各类传输协议标准（如：TSN） 还在不断完善， 上层应用协议的应用生态还没有构建完成， 各整车企业在 SOME/IP、 DDS、 PCIE 的协议应用仍处于论证阶段。TSN 国际、 国内标准中与车载相关的技术标准尚不全面， 并且支持 TSN 技术的芯片没有达到车规级应用。SOME/IP 通信设计开发需实现基于服务的信号设计开发， 即在功能信号中提取 “服务”， 然后进行打包传输， 开发难度高。

3.5 中央计算硬件平台芯片和设计方案尚不成熟

中央集中式电子电气架构下的中央计算硬件平台目前尚无成熟的芯片和硬件设计方案，需要整车与芯片供应商和硬件平台供应商进行同步验证开发。同时， 中央计算平台对软件开发能力要求也很高， 需协同基础软件、 应用软件、 软件集成等资源共同实现软件设计工作。