汽车EE架构不断升级，华为CCA架构指引未来演变趋势
⼀、ADAS 功能升级导致算⼒需求提升
驾驶辅助功能快速提升，分布式架构向“功能域”集中式架构演进成为趋势。传统分布式 ECU 在汽车电⽓化、智能化时代因为驾驶辅助功能快速的提升，⾯临着巨⼤的挑战。1）各个 ECU 之间算⼒⽆法协同，相互冗余，产⽣极⼤浪费；2）⼤量的嵌⼊式OS 及应⽤代码由不同的 Tier 1 提供，语⾔和编程风格迥异，导致难以统⼀维护和 OTA升级；3）分布式架构需要⼤量内部通信，导致线束成本增加并加⼤装配难度。因此，分布式架构向“功能域”集中式架构演进成为趋势。
汽车&不同⾏业软件代码量/⾏
未来汽车软件代码量变化趋势/⾏
⼆、 “软件定义汽车”背景下，整车 OTA 需要 SOA 架构升级
相较于传统汽车，整车 OTA 为汽车注⼊新的活⼒。在“软件定义汽车”时代，OTA（Over The Air）空中下载能够满⾜智能汽车软件快速迭代的需求，避免传统汽车每次更新都需要去 4S 店，从⽽导致效率低
下的问题。通过它可以不断给客户开启新的功能，不断优化产品体验，吸引客户。
传统分布式 ECU 软硬件架构，整车 OTA 效率低下。在传统的分布式 ECU 架构下，有以下⼏个问题：1）ECU 众多，且由不同的供应商进⾏开发，软件框架不同，外部开发者难以对 ECU 进⾏编程更新。2）通过 CAN/LIN 总线进⾏通信，信号收发关系和路由信息静态固定，各 ECU 周期性发出各种信号，通过⽹关进⾏转发，若更新信号配置，需要同步修改⽹关配置。3）控制器之间信号嵌套，单个控制器升级需要将所有信号相关控制器全部升级，⼯作量指数上升。
分布式 E/E 架构⾯临 OTA 困难
为实现“软件定义汽车”，SOA 架构成为新的趋势。SOA(Service-Oriented Architecture)⾯向服务架构，是⼀种架构设计思想，将应⽤程序的不同功能单元（称为服务）通过这些服务之间定义良好的接⼝和契约联系起来。简单来说，SOA 要求各个控制器将⾃⼰的能⼒以服务的⽅式提供出来，不同的服务以原⼦宝马网
化的⽅式存在，互相之间能够进⾏动态的订阅/发布关系。
如下图所⽰，在中央计算电⼦电⽓架构下，通过以太⽹通信⽅式，把各个控制器提供的功能按照服务的维度进⾏拆解成原⼦状态，再重新组合实现不同的组合服务或者流程服务。其优点包括：1）软硬件分离，降低开发难度；2）灵活部署软件，功能重新分配；3）服务间低耦合，互相⽆依赖，易于维护；4）服务间通信接⼝标准化，不依赖于平台实现功能。并且能够在硬件可升级的前提下，通过硬件升级来拓展原⼦服务的功能范围，⽐如增加流媒体后视镜硬件，增加了流媒体后视镜服务，就可以将流媒体后视镜服务与倒车影像服务结合，将倒车影像在流媒体后视镜上呈现出来。
⾯向服务的架构⽰例
框架标准/硬件架构/通信协议配合实现 SOA 架构升级。SOA 在互联⽹ IT ⾏业有较成熟的应⽤，但因为框架标准、硬件架构以及通信协议等⽅⾯的原
框架标准/硬件架构/通信协议配合实现 SOA 架构升级。SOA 在互联⽹ IT ⾏业有较成熟的应⽤，但因为框架标准、硬件架构以及通信协议等⽅⾯的原
因，SOA 架构理念之前在汽车⾏业未能得到较⼴泛的推⼴。在智能电动化趋势下，逐渐成为整车架构下⼀代的升级⽅向。
三、框架标准增加：AUTOSAR 联盟推出 Adaptive AutoSAR 标准
AUTOSAR(AUTomotive Open System ARchitecture)是⼀个由整车⼚，零配件供应商，以及软件、电⼦、半导体公司合起来成⽴的组织。其成⽴于 2003年 7 ⽉，核⼼成员由宝马、戴姆勒、⼤陆、西门⼦、⼤众、丰⽥、福特、PSA、博世 9 家公司构成。它为汽车 E/E（电⼦电⽓系统）架构建⽴了⼀种开放式的⾏业标准，以减少其设计复杂度，增加其灵活性，提⾼其开发效率。成⽴⾄今的近 18 年时间⾥，得到了越来越多的⾏业认可。其⽬标主要有三个：1）建⽴分层的体系架构；2）为应⽤程序的开发提供⽅法论；3）制定各种应⽤接⼝规范。
3.1 Classical AUTOSAR 标准⾯向传统 ECU
在最初的汽车 ECU 开发中，存在着⼏⼤痛点：1）传统的汽车 ECU 的嵌⼊式系统不⽀持硬件抽象；2）分布式 ECU 由不同的供应商提供，采⽤不同的软件代码，互相之前通信困难并且软件可移植性差；3）软件复⽤性差，⽽车辆的寿命往往长于 ECU 的寿命，当硬件更换后，软件往往需要推倒重写。基于以上痛点，AUTOSAR 联盟推出了 Classical AutoSAR 标准，将 ECU 的开发流程、⽂件交换格式以及内部的代码规范和书写进⾏标准化。通过建⽴不同的软件层级，将硬件接⼝抽象化、驱动程序抽象化、操作系统抽象化，最终通过 RTE 中间件来实现上层应⽤之间、应⽤与底层软件之间以及不同 ECU 的上层应⽤之间通信。
AUTOSAR 实现底层软件和应⽤软件解耦
AUTOSAR 将软件分为四层，最上层是 Application（应⽤层），接下来是 RTE 层、基础软件层（BSW）和微控制器硬件层，其中 BSW 层⼜进⼀步细分成：1）控制器抽象层（MCAL）；2）ECU 抽象层；3）服务层；4）复杂驱动层。
MCAL 的功能是设置硬件驱动，将控制器、内存、通信、I/O ⼝等硬件功能的驱动进⾏设置，屏蔽不同的芯⽚资源；其上的 ECU 抽象层，给控制器抽象层提供抽象接⼝，屏蔽具体的控制器的型号；服务层是 BSW 的最⾼层，主要运⾏标准化的操作系统，提供计时器、状态管理等服务；复杂驱动层为某些⾼要求的应⽤提供直接与硬件交互的通道，如发动机爆震控制、曲轴转⾓控制、节⽓门控制等等。
AUTOSAR 实现底层软件和应⽤软件分离
AUTOSAR 分层模型
运⾏环境 RTE 是 CP 标准的核⼼组成部分，它是虚拟功能总线（Virtual Function Bus，VFB）的接⼝具体的实现，为应⽤程序组件通信提供基本服务。在应⽤层中各个组件之间不允许直接通信，由 RTE 封装好下层通信基础软件之后，为上层应⽤层提供通信所需API 接⼝。RTE 可以实现的功能：1）应⽤层软件组件（SW-C）之间通信；2）应⽤层SW-C 与 BSW 之间的通信；3）不同 ECU 的 SW-C 之间的通信。
应⽤程序与 BSW 通过 RTE 通信
应⽤层由多个模块化的软件组件(SW-C)组成。每个 SW-C 都封装了各种应⽤的功能集，⽤于实现汽车控制的功能。与⾮ AUTOSAR 架构的车载软件不同的是，由于通过RTE 将 SW-C 与底层硬件和操作系统等完全的解耦，SW-C 不依赖硬件，即使搭载于不同的 ECU 之上，代码依然可以被重复利⽤。
3.2 Adaptive AUTOSAR 标准⾯向⾼性能 ECU
Classical AutoSAR 标准(CP)解决了传统的嵌⼊式 ECU 开发的需求，但是在汽车智能化时代，⾼级⾃动驾驶功能需要在车辆上引⼊⾼度复杂和计算资源需求量⼤的软件，CP 标准⽆法满⾜ ADAS 控制器相关的需求。于是，在算⼒⼤幅提升的需求拉动，和以太⽹技术发展&多核异构⾼性能处理器技术的驱动下，AUTOSAR 联盟推出满⾜⾯向服务 SOA 架构的第⼆个软件标准：Adaptive AutoSAR（AP）。
动下，AUTOSAR 联盟推出满⾜⾯向服务 SOA 架构的第⼆个软件标准：Adaptive AutoSAR（AP）。
Classical AutoSAR 框架 VS Adaptive AutoSAR 框架
AP 不是原有 CP 的升级版本，⽽是运⽤ SOA 架构设计思想，⾯对汽车更加复杂的功能需求推出的新标准。两者相⽐，⾸先 AP 可以适配 64 位及以上的⾼性能芯⽚，⽽CP 只能适配 32 位及以下微控制器；其次 CP 中的 RTE 仅⽀持静态通信，在程序发布时已经确定通信源和⽬标，不⽀持通信的动态重新配置，通信协议主要是“⾯向信号”的 LIN/CAN 架构。⽽ AP 中的通信模块 ara::com 为 Application (服务)间的通信提供接⼝，并且其⾃⾝包含的 SOME/IP 通信协议属于“⾯向服务”架构，⽀持服务发现、数据的动态发布/订阅机制，从⽽能够实现不同的应⽤像电脑上的软件⼀样动态升级、卸载。
Adaptive AutoSAR 架构
AP 具有如下的特点：1）软实时性，具有毫秒级的最后期限，即使错过最后期限也不会造成灾难后果；2）具有⼀定的功能安全要求，可以达到 ASIL-B 或更⾼；3）更适⽤于多核动态操作系统的⾼资源环境。因此与 CP 相⽐，虽然 AP 实时性有所降低，但在保证⼀定功能安全等级的基础上，⼤⼤提⾼了对⾼性能处理能⼒的⽀持，以⽀持智能互联应⽤功能的开发。
表 1：CP 与 AP 特性对⽐