汽车CCA架构域控制器行业分析报告.docx

汽车CCA架构域控制器行业分析报告.docx

《汽车CCA架构域控制器行业分析报告.docx》由会员分享，可在线阅读，更多相关《汽车CCA架构域控制器行业分析报告.docx（30页珍藏版）》请在冰豆网上搜索。

汽车CCA架构域控制器行业分析报告

2021年汽车CCA架构域控制器行业分析报告

2021年7月

汽车E/E架构不断升级，华为CCA架构指引未来发展趋势。

1）ADAS功能升级导致算力需求提升。

智能汽车时代，传统分布式ECU架构无法满足日益增长的算力需求，开始向“功能域”集中。

2）“软件定义汽车”背景下，OTA升级需要软件实现SOA架构。

传统分布式软件架构难以进行软件快速迭代升级，需要通过SOA架构实现新的软件框架。

3）传统CAN/LIN总线向以太网升级，满足传输带宽及通信协议。

以太网高带宽适合智能化时代大数据传输的需求，成为下一代车载主干网络的首选。

其支持的SOME/IP通信协议也能够很好的支持SOA面向服务的软件架构。

4）算力需求+SOA软件架构升级推动“功能域”集中趋势，“Zone”区域控制成为重要组成。

5）华为推出CCA架构：

“功能域”+“区域”集中，指引E/E架构未来发展趋势。

“功能域”集中趋势下域控制器需求提升，“Zone”区域控制器导致机电一体化产品向标准化智能执行器演进。

域控制器主要需求增量来自自动驾驶域/智能座舱域/车身域/底盘域。

其中，1）自动驾驶域单车价值量最高，价值量超过万元，后续渗透率加速提升；2）智能座舱域因为不涉及行车安全，渗透率提升速度高于自动驾驶域控制器；3）车身域控制器在原有BCM的基础上进一步集成相关控制器功能；4）底盘域控制器集成驱动/转向/制动等底盘执行功能，统一的实现整车运动控制，它的出现为自主底盘执行单元供应商提供新的机会。

“Zone”区域控制器将就近接入的控制器算法上提，机电一体化产品向智能执行器转变。

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

电动智能化趋势下，主流主机厂下一代电子电气架构在未来1-2年推出，消费者对于自动驾驶/智能座舱以及功能不断迭代的需求推动四大域控制器渗透率提升。

而电动智能化带来的升级趋势，会驱使车灯控制器、电动水泵控制器、电磁阀控制器、电动压缩机控制器以及智能底盘执行单元等渗透率持续提升。

据我们测算，域控制器市场规模在2025/2030年达到1087/2307亿元，其中自动驾驶域控制器市场规模468/1240亿元，智能座舱域控制器市场规模292/620亿元，车身域控制器市场规模234/198亿元，底盘域控制器市场规模94/248亿元。

执行端控制器数量不断提升，2025/2030年市场规模为274/318亿元。

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

1、ADAS功能升级导致算力需求提升

驾驶辅助功能快速提升，分布式架构向“功能域”集中式架构演进成为趋势。

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

1）各个ECU之间算力无法协同，相互冗余，产生极大浪费；2）大量的嵌入式OS及应用代码由不同的Tier1提供，语言和编程风格迥异，导致难以统一维护和OTA升级；3）分布式架构需要大量内部通信，导致线束成本增加并加大装配难度。

因此，分布式架构向“功能域”集中式架构演进成为趋势。

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架构理念之前在汽车行业未能得到较广泛的推广。

在智能电动化趋势下，逐渐成为整车架构下一代的升级方向。

3、框架标准增加：

AUTOSAR联盟推出AdaptiveAutoSAR标准

AUTOSAR（AUTomotiveOpenSystemARchitecture）是一个由整车厂，零配件供应商，以及软件、电子、半导体公司合起来成立的组织。

其成立于2003年7月，核心成员由宝马、戴姆勒、大陆、西门子、大众、丰田、福特、PSA、博世9家公司构成。

它为汽车E/E（电子电气系统）架构建立了一种开放式的行业标准，以减少其设计复杂度，增加其灵活性，提高其开发效率。

成立至今的近18年时间里，得到了越来越多的行业认可。

其目标主要有三个：

1）建立分层的体系架构；2）为应用程序的开发提供方法论；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之上，代码依然可以被重复利用。

（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:

:

com为Application（服务）间的通信提供接口，并且其自身包含的SOME/IP通信协议属于“面向服务”架构，支持服务发现、数据的动态发布/订阅机制，从而能够实现不同的应用像电脑上的软件一样动态升级、卸载。

AP具有如下的特点：

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

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

4、硬件架构/通信协议升级：

CAN/LIN->以太网，面向信号->面向服务

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

自动驾驶需要以更快速度采集并处理更多数据，传统汽车总线无法满足低延时、高吞吐量要求。

随着汽车电子电气架构日益复杂化，其中传感器、控制器和接口越来越多，自动驾驶也需要海量的数据用于实时分析决策，因此要求车内外通信具有高吞吐速率、低延时和多通信链路。

在高吞吐速率方面，LIDAR模块产生约70Mbps的数据流量，一个摄像头产生约40Mbps的数据流量，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以太网标准的不断推出，以太网有望成为未来智能汽车时代的车载主干