（报告出品方/作者：东吴证券，黄细里）

1.汽车E/E架构不断升级，华为CCA架构指引未来演变趋势

1.1.ADAS功能升级导致算力需求提升

驾驶辅助功能快速提升，分布式架构向“功能域”集中式架构演进成为趋势。传统分布式ECU在汽车电气化、智能化时代因为驾驶辅助功能快速的提升，面临着巨大的挑战。

1）各个ECU之间算力无法协同，相互冗余，产生极大浪费；

2）大量的嵌入式OS及应用代码由不同的Tier1提供，语言和编程风格迥异，导致难以统一维护和OTA升级；

3）分布式架构需要大量内部通信，导致线束成本增加并加大装配难度。因此，分布式架构向“功能域”集中式架构演进成为趋势。

1.2.“软件定义汽车”背景下，整车OTA需要SOA架构升级

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

传统分布式ECU软硬件架构，整车OTA效率低下。在传统的分布式ECU架构下，有以下几个问题：1）ECU众多，且由不同的供应商进行开发，软件框架不同，外部开发者难以对ECU进行编程更新。2）通过CAN/LIN总线进行通信，信号收发关系和路由信息静态固定，各ECU周期性发出各种信号，通过网关进行转发，若更新信号配置，需要同步修改网关配置。3）控制器之间信号嵌套，单个控制器升级需要将所有信号相关控制器全部升级，工作量指数上升。

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

在中央计算电子电气架构下，通过以太网通信方式，把各个控制器提供的功能按照服务的维度进行拆解成原子状态，再重新组合实现不同的组合服务或者流程服务。其优点包括：1）软硬件分离，降低开发难度；2）灵活部署软件，功能重新分配；3）服务间低耦合，互相无依赖，易于维护；4）服务间通信接口标准化，不依赖于平台实现功能。并且能够在硬件可升级的前提下，通过硬件升级来拓展原子服务的功能范围，比如增加流媒体后视镜硬件，增加了流媒体后视镜服务，就可以将流媒体后视镜服务与倒车影像服务结合，将倒车影像在流媒体后视镜上呈现出来。

框架标准/硬件架构/通信协议配合实现SOA架构升级。SOA在互联网IT行业有较成熟的应用，但因为框架标准、硬件架构以及通信协议等方面的原因，SOA架构理念之前在汽车行业未能得到较广泛的推广。在智能电动化趋势下，逐渐成为整车架构下一代的升级方向。

1.3.框架标准增加：AUTOSAR联盟推出AdaptiveAutoSAR标准

AUTOSAR(AUTomotiveOpenSystemARchitecture)是一个由整车厂，零配件供应商，以及软件、电子、半导体公司合起来成立的组织。其成立于年7月，核心成员由宝马、戴姆勒、大陆、西门子、大众、丰田、福特、PSA、博世9家公司构成。它为汽车E/E（电子电气系统）架构建立了一种开放式的行业标准，以减少其设计复杂度，增加其灵活性，提高其开发效率。成立至今的近18年时间里，得到了越来越多的行业认可。其目标主要有三个：1）建立分层的体系架构；2）为应用程序的开发提供方法论；3）制定各种应用接口规范。

1.3.1.ClassicalAUTOSAR标准面向传统ECU

在最初的汽车ECU开发中，存在着几大痛点：

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

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

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

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

AUTOSAR将软件分为四层，最上层是Application（应用层），接下来是RTE层、基础软件层（BSW）和微控制器硬件层，其中BSW层又进一步细分成：1）控制器抽象层（MCAL）；2）ECU抽象层；3）服务层；4）复杂驱动层。

MCAL的功能是设置硬件驱动，将控制器、内存、通信、I/O口等硬件功能的驱动进行设置，屏蔽不同的芯片资源；其上的ECU抽象层，给控制器抽象层提供抽象接口，屏蔽具体的控制器的型号；服务层是BSW的最高层，主要运行标准化的操作系统，提供计时器、状态管理等服务；复杂驱动层为某些高要求的应用提供直接与硬件交互的通道，如发动机爆震控制、曲轴转角控制、节气门控制等等。

运行环境RTE是CP标准的核心组成部分，它是虚拟功能总线（VirtualFunctionBus，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之上，代码依然可以被重复利用。

1.3.2.AdaptiveAUTOSAR标准面向高性能ECU

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

AP不是原有CP的升级版本，而是运用SOA架构设计思想，面对汽车更加复杂的功能需求推出的新标准。两者相比，首先AP可以适配64位及以上的高性能芯片，而CP只能适配32位及以下微控制器；其次CP中的RTE仅支持静态通信，在程序发布时已经确定通信源和目标，不支持通信的动态重新配置，通信协议主要是“面向信号”的LIN/CAN架构。而AP中的通信模块ara::

转载请注明:http://www.aideyishus.com/lkyy/2253.html