车载E/E架构演进趋势：整车架构的未来指引

引言

ADAS功能不断升级导致对芯片计算能力需求提升，驾驶辅助功能快速提升，分布式架构向“功能域”集中式架构演进成为趋势。

一、背景信息

1、分布式ECU在汽车电气化、智能化时代，因为驾驶辅助功能快速的提升，面临着巨大的挑战：

• 各个ECU之间计算能力无法协同，相互冗余，产生极大浪费；
• 嵌入式操作系统及Application Software由不同的Tier1提供，编程语言和编程风格迥异，导致难以统一维护和OTA升级；
• 分布式架构需要大量内部通信，导致线束成本增加并加大装配难度。
• 因此，分布式架构向“功能域”集中式架构演进成为趋势。

2、SOA架构助力整车OTA

• 对比传统汽车，OTA为汽车注入新的活力。在“软件定义汽车”时代，OTA（Over The Air）能够满足智能汽车软件快速迭代的需求，避免传统汽车每次更新都需要去4S店，从而导致效率低下的问题。通过它可以不断给客户开启新的功能，不断优化产品体验，吸引客户，形成生态链。

传统分布式ECU软硬件架构，整车OTA效率低下。在传统的分布式ECU架构下，有以下几个弊端：

• ECU众多，不同供应商进行开发，软件框架不同，外部开发者难以对ECU进行编程更新；
• 通过CAN/LIN总线进行通信，信号收发关系和路由信息静态固定，各ECU周期性发出各种信号，通过网关进行转发，若更新信号配置，需要同步修改网关配置；
• 控制器之间信号嵌套，单个控制器升级需要将所有信号相关控制器全部升级，工作量极大上升

分布式原理图

• 为实现“软件定义汽车”，SOA架构成为新的趋势。SOA(Service-Oriented Architecture)面向服务架构，是一种架构设计思想，将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。简单来说，SOA要求各个控制器将自己的能力以服务的方式提供出来，不同的服务以原子化的方式存在，互相之间能够进行动态的订阅/发布关系。

在中央计算电子电气架构下，通过以太网通信方式，把各个控制器提供的功能按照服务的维度进行拆解成原子状态，再重新组合实现不同的组合服务或者流程服务。其优点如下：

• 软硬件分离，有利于开发；
• 灵活部署软件，功能重新分配；
• 服务间低耦合，互相无依赖，易于维护；
• 服务间通信接口标准化，不依赖于平台实现功能。
  

框架标准/硬件架构/通信协议配合实现SOA架构升级。SOA在互联网IT行业有较成熟的应用，因为：

• 框架标准；
• 硬件架构；
• 通信协议；

• 等方面的原因，SOA架构理念之前在汽车行业未能得到较广泛的推广。在智能电动化趋势下，逐渐成为整车架构下一代的升级方向。

• 3、框架标准增加：AUTOSAR联盟推出Adaptive AutoSAR标准
• AUTOSAR成立于2003年7月，核心成员由宝马、戴姆勒、大陆、西门子、大众、丰田、福特、PSA、博世9家公司构成。为汽车E/E（电子电气系统）架构建立了一种开放式的行业标准，以减少其设计复杂度，增加其灵活性，提高其开发效率。
  

其目标主要有三个：

• 建立分层的体系架构；
• 为应用程序的开发提供方法论；
• 制定各种应用接口规范。

Classical AUTOSAR标准面向传统ECU在最初的汽车ECU开发中

存在着几大痛点：

A.传统的汽车ECU的嵌入式系统不支持硬件抽象；

B.分布式ECU由不同的供应商提供，采用不同的软件代码，互相之前通信困难并且软件可移植性差；

C.软件复用性差，而车辆的寿命往往长于ECU的寿命，当硬件更换后，软件往往需要推倒重写。

基于以上痛点，AUTOSAR联盟推出了Classical AutoSAR标准，将ECU的开发流程、文件交换格式以及内部的代码规范和书写进行标准化。通过建立不同的软件层级，将硬件接口抽象化、驱动程序抽象化、操作系统抽象化，最终通过RTE中间件来实现上层应用之间、应用与底层软件之间以及不同ECU的上层应用之间通信。

4.AUTOSAR将软件分为四层：

1. Application（应用层）；
2. RTE层；
3. 基础软件层（BSW）；
4. 微控制器硬件层。
   
5. 其中BSW层又进一步细分成：
6. 控制器抽象层（MCAL）；
7. ECU抽象层；
8. 服务层；
9. 复杂驱动层。
   

如上图是AUTOSAR实现底层软件和应用软件分离示意图

AUTOSAR分层模型

• 运行环境RTE是CP标准的核心组成部分，它是虚拟功能总线（Virtual Function Bus，VFB）的接口具体的实现，为应用程序组件通信提供基本服务。在应用层中各个组件之间不允许直接通信，由RTE封装好下层通信基础软件之后，为上层应用层提供通信所需API接口。

RTE可以实现的功能：

1. 应用层软件组件（SW-C）之间通信；
2. 应用层SW-C与BSW之间的通信；
3. 不同ECU的SW-C之间的通信
   

应用层由多个模块化的软件组件(SW-C)组成。每个SW-C都封装了各种应用的功能集，用于实现汽车控制的功能。与非AUTOSAR架构的车载软件不同的是，由于通过RTE将SW-C与底层硬件和操作系统等完全的解耦，SW-C不依赖硬件，即使搭载于不同的ECU之上，代码依然可以被重复利用。

5.Adaptive AUTOSAR标准面向高性能

• ECU Classical AutoSAR标准解决了传统的嵌入式ECU开发的需求，但是在汽车智能化时代，高级自动驾驶功能需要在车辆上引入高度复杂和计算资源需求量大的软件，CP标准无法满足ADAS控制器相关的需求。于是，在算力大幅提升的需求拉动，和以太网技术发展&多核异构高性能处理器技术的驱动下，AUTOSAR联盟推出满足面向服务SOA架构的第二个软件标准：Adaptive AutoSAR（AP）。
  

6.AP不是原有CP的升级版本！！！

• 而是运用SOA架构设计思想，面对汽车更加复杂的功能需求推出的新标准。两者相比，首先AP可以适配64位及以上的高性能芯片，而CP只能适配32位及以下微控制器；其次CP中的RTE仅支持静态通信，在程序发布时已经确定通信源和目标，不支持通信的动态重新配置，通信协议主要是“面向信号”的LIN/CAN架构。而AP中的通信模块ara::com为Application (服务)间的通信提供接口，并且其自身包含的SOME/IP通信协议属于“面向服务”架构，支持服务发现、数据的动态发布/订阅机制，从而能够实现不同的应用像电脑上的软件一样动态升级、卸载。

AP具有如下的特点：

• 软实时性，具有毫秒级的最后期限，即使错过最后期限也不会造成灾难后果；
• 具有一定的功能安全要求，可以达到ASIL-B或更高；
• 更适用于多核动态操作系统的高资源环境。
  

因此与CP相比，虽然AP实时性有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发

7、 硬件架构/通信协议升级：CAN/LIN->以太网，面向信号->面向服务

数据传输速度需求推动车身网络向以太网进化

• 自动驾驶需要以更快速度采集并处理更多数据，传统汽车总线无法满足低延时、高吞吐量要求。随着汽车电子电气架构日益复杂化，其中传感器、控制器和接口越来越多，自动驾驶也需要海量的数据用于实时分析决策，因此要求车内外通信具有高吞吐速率

• 低延时和多通信链路。在高吞吐速率方面，LIDAR 模块产生约70 Mbps的数据流量，一个摄像头产生约40 Mbps的数据流量，RADAR模块产生约0.1Mbps的数据流量。若L2级自动驾驶需要使用8个RADAR和3个摄像头，需要最大吞吐速率超过120Mbps，而全自动驾驶对吞吐速率要求更高，传统汽车总线不能满足高速传输需求。
  

• 集带宽更宽、低延时等诸多优点的以太网有望成为未来车载数据传输骨干网络。车载以太网（Ethernet）是汽车中连接电子元器件的一种有线网络，具有带宽较宽、低延时、低电磁干扰、低成本等优点。传统以太网在1990年就已经发布，需要2-4对双绞线进行传输，且抗电磁干扰能力较弱，难以在汽车上大量推广，宝马率先应用以太网技术，在2008年的宝马7系上，装备了一条从DLC诊断端口到网关的100Base-Tx以太网，用于诊断和固化软件更新。

• 2011年，Broadcom(博通)、NXP、BMW成立OPENAlliance联盟，到目前已经有500+成员。2015年首个车载以太网规范100Base-T1发布，仅需要一对双绞线进行传输，可以减少70-80%的连接器成本，减少30%以上的重量，并且能够有效的满足车内EMC电磁干扰的要求。随着1000Base-T1以及更高带宽NGBase-T1以太网标准的不断推出，以太网有望成为未来智能汽车时代的车载主干网络

关于“面向服务”通信协议，支持SOA架构升级

• SOME/IP面向服务通信协议，支持SOA架构升级。随着以太网不断的普及，SOME/IP (Scalable service-Oriented MiddlewarEover IP)概念开始引入车载网络通信领域，它2011年由BMW集团推出，是车载以太网的通信中间件，位于OSI 7层模型的第5层，并于2013年被纳入AUTOSAR 4.1规范中。传统的CAN/LIN总线为主的车载网络中，通信过程是面向信号，其信号的发送是根据发送者的需求，不会考虑接收者是否有需求。而SOME/IP则不同，它在接收方有需求的时候才会发送，这种方法优点在于总线上不会出现过多不必要的数据，降低负载。

以太网支持下SOA架构

• 在SOME/IP协议和以太网的支持下，通信架构和协议支持面向服务的SOA架构升级，将各种控制算法、显示功能等应用程序抽象为“服务”，并通过API接口和中间件（Middleware）使得所有有需求的任务都可以对其进行访问。

8、  算力需求+SOA架构推动“功能域”集成，“Zone”区域控制成为重要组成

• 控制器“功能域”集中成为趋势。在原有的分布式电气架构下，因为汽车智能化功能不断提升导致ECU数量不断升级，线束带宽及重量难以支撑继续扩张，且分布式ECU功能相对简单，设计资源有限，无法支持SOA架构下新增功能持续升级和消耗，因此控制器“功能域”集中成为趋势。
  
• 就近接入，扩展灵活，“Zone”区域控制成为整车网络重要组成部分。在“功能域”集中的基础上，通过Zone区域控制器对全车的设备进行就近接入，能够更好的实现硬件的扩展，减少整车线束长度及成本，成为整车电子电气架构中重要的组成部分。

• 二、 全新电子电气架构下，整车的控制器发展趋势如何演变？
  

1、控制器（ECU）：功能控制核心，协助实现各项功能

• 功能控制中枢，处理输入信号实现功能控制。汽车控制器是实现整车功能控制的关键器件，一般由MCU、电源芯片、通信芯片、输入处理电路、输出处理电路等构成，通过对各类传感器信号、开关信号以及控制信号的处理，来对阀、电机、泵、开关等执行机构进行控制。

ECU架构原理图

通过整车微控制器能够实现的功能包括：接收信号并解析、逻辑判断、网络通信、故障诊断和处理、设备地址识别等等。

2、整车电子电气功能升级，ECU数量不断提升

• 微控制器在传统的车辆中为分布式架构，每增加一个功能需要增加一个ECU。随着整车电子电气功能的不断升级，ECU的数量在不断提升。根据Strategy Analytics的数据显示，目前汽车平均采用约25个ECU，但是高端型号ECU数量已经超过100个。不同的ECU之间，主要采用CAN/LIN总线对其进行连接，近年来汽车中CAN/LIN总线节点的数目在不断提升，其中LIN总线节点CAGR约为17%，CAN节点的CAGR约为13%。

• 以数据诊断接口为中心，分布式ECU架构通过不同速率的总线系统将不同的ECU进行连接，从而实现不同的功能。

大众汽车ECU分布图

3、 信号复杂度+控制难度不同，控制器价值量有所区别

• 信号处理+输出控制难度提升，控制器复杂度不断升级。
• 简单驱动控制器：以油泵控制器为例，仅需要接收非总线信号并驱动执行机构，价值量约为10-20元；
• 拥有总线诊断通信功能的控制器：以鼓风机控制器为例，需要通过LIN总线通信，并拥有诊断功能，价值量约为40-50元；
• 实现较为复杂功能控制器：以车灯控制器为例，需要通过CAN总线通信，拥有诊断功能，并需要对冷却风扇、调节电机、灯光进行控制的较复杂控制器，价值量约为80-100元；
• 实现复杂功能控制器：以车身控制器/发动机

4、全新电子电气架构向“功能域”集中，带来域控制器需求提升

• “软件定义汽车”时代，需要大算力控制单元。不同于以往的分布式电子电气架构，“软件定义汽车”时代，整车硬件架构向以太网+SOA架构升级，大算力+软件快速迭代需求推动分布式ECU向域控制器集成。在中央控制计算单元出现之前，整车控制单元被划分为自动驾驶域控制器/智能座舱域控制器/车身域控制器以及底盘域控制器等。

5、智能座舱域控制器，不涉及行车安全，集成先行

汽车座舱升级分为几个阶段：

• 60-90 年代为机械时代，座舱产品主要包括机械式仪表盘及简单的音频播放设备，功能结构单一，基本都是物理按键形式，可提供的信息仅有车速、发动机转速、水温、油耗等基本信息；
• 2000-2015 年为电子化时代，随着汽车电子技术的发展，座舱产品进入电子时代，装置仍以机械仪表为主，但少数小尺寸中控液晶显示开始使用，此外也增加了导航系统、影音等功能，为驾驶员提供较多信息。
• 2015年开始进入智能时代，以大尺寸中控液晶屏为代表率先替代传统中控，全液晶仪表开始逐步替代传统仪表，中控屏与仪表盘一体化设计的方案开始出现，少数车型新增HUD 抬头显示、流媒体后视镜等，人机交互方式多样化，智能化程度明显提升。

但现阶段大部分座舱产品仍是分布式离散控制，即操作系统互相独立，核心技术体现为模块化、集成化设计。一芯多屏、多屏互融、立体式虚拟呈现等技术开始逐步普及，核心技术体现为进一步集成智能驾驶的能力。

目前智能座舱域控制器主要目的是将分别呈现的液晶仪表、液晶中控、HUD、流媒体后视镜等显示端进行“功能域”集中统一控制，实现“一芯多屏”等功能。

6、车身域控制器，进一步集成BCM功能

车身域控制器就是BCM(Body Control Module)的进一步集成产品，传统的BCM将天窗、车窗、车门锁、车内灯光、座椅、电动尾门、车灯、雨刮、PEPS（无钥匙进入和启动）等功能的控制进行了集成。

特斯拉作为汽车电子电气架构升级的先锋，在2019年推出的Model3上率先对其电子电气架构进行了革命性的变革，不仅将驾驶辅助+影音娱乐进行了双域融合，同时也将车身域相关的控制器进行了“区域”集成，通过左（RCM_LH）、前(RCM_FH)、右(RCM_RH)三大域控制器不仅将原车身域中车窗、车门、座椅、门锁、灯光、雨刮等功能开关进行了集成，更将空调、热管理、EPB等模块进行了集成，并按照就近原则对节点进行接入，有效的降低了整车的线束长度、重量、成本以及布线的难度。

车身域控制器的主要功能包括传统BCM功能、PEPS（无钥匙进入和启动）、车窗控制、天窗控制、空调模块、座椅模块等。我们认为未来能够在车身域控制器领域能够胜出的Tier1应该具备以下几个方面的特征：

• 有较强的传统BCM开发的经验；
• 能够独立的开发车窗及空调模块；
• 较强的硬件集成能力；
• 软件架构能够符合时代，最好有AUTOSAR、SOME/IP等相关的开发经验；
• 芯片保供能力（公司营收规模）。

7、“底盘域”控制器集成需求，为自主底盘控制执行单元带来机会

• 电动智能化时代，底盘控制全面转向线控。电动智能车因为真空源缺失、能量回收需求、控制灵敏度升级等多种原因，底盘执行单元全面转向X-By-Wire(线控技术)，除电机驱动之外，主要包括线控制动及线控转向功能。
  
• 底盘执行机构向线控单元升级，多路径实现制动和转向功能。在传统底盘执行单元升级成线控单元后，制动和转向功能能够通过多路径实现，以制动功能为例，实现目标减速度可以通过驾驶员主动制动、ESC主动减压、电子手刹EPB以及动能回收等路径实现。因此将底盘执行的所有功能集中在更上层的底盘域控制器上进行统一控制，成为提升整车控制效率的发展趋势

• 电动智能车多路径实现制动和转向

8、电动智能化趋势下，域控制器和执行端控制器同步增长

• 电动智能化趋势下，一方面因为自动驾驶和智能座舱的需求以及整车电气架构向SOA的升级会带来几大域控制器以及区域控制器渗透率的不断提升。另一方面电动智能化的应用会驱使执行端微控制器数量不断上升，类似车灯控制器、电动水泵控制器、电磁阀控制器、电动压缩机控制器以及线控底盘控制器等持续提升。控制端与执行端控制器的需求将共同推动控制器市场规模增长。
  
• 

9、电气架构升级+智能功能推进，域控制器1-2年内加速渗透

• 域控制器的渗透速度首先取决于整车电气架构的更新速度，其次取决于L2.5以上高级别自动驾驶功能和智能座舱功能的需求。整车电子电气架构升级可以推动所有域控制器渗透率提升，而高级别自动驾驶功能和智能座舱功能的需求提升，可以推动主机厂对部分区域电子电气架构进行升级从而适应自动驾驶域控制器和智能座舱域控制器的需求。
  
• 智能化功能渗透率+电动智能车渗透率提升推动控制器市场不断增长
• 未来域控制器增长点：
• 自动驾驶域控制器
• 智能座舱域控制器
• 车身域控制器
• 底盘域控制器

以上是自己结合网上资料整理，让自己对整个行业前景有更好的认知。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删