软件定义汽车的时代已经到来

1、目 录 HYPERLINK l _TOC_250002 软件定义汽车助力硬件生命周期延长，并带动商业模式拓展 3 HYPERLINK l _TOC_250001 电子电器架构的集中化是软件定义汽车的基础 3分层的软件架构是软件定义汽车的重要条件 4 HYPERLINK l _TOC_250000 风险提示 9软件定义汽车助力硬件生命周期延长，并带动商业模式拓展软件定义汽车是行业重要趋势，其好处至少体现在两个方面。1)软件定义汽车的最大价值在于延长硬件的生命周期。所有 IT/ICT 渗透程度较高的产业都面临高度同质化的问题，对于主机厂而言，实现功能和客户体验的差异化是至关重要的。在软硬件耦合度较

2、高的阶段，往往通过硬件迭代来实现功能迭代。软硬件解耦之后，软件功能的发布与更新不再需要依托硬件的发布和更新，硬件的更新频率也就能随之放缓，带动成本下降。2)软件定义汽车会带动商业模式的拓展。目前特斯拉已经实现通过 FSD 选装包、OTA 升级、高级车联网服务等方式实现了软件收入，实现了商业模式的拓展。电子电器架构的集中化是软件定义汽车的基础电子电器架构的集中化软件定义汽车的基础。在汽车 E/E 架构发展的前三个阶段，E/E 架构是分布式的，各个阶段之间更多是复杂程度和 ECU间协作程度上的差异。时至今日，每辆车分布着上百个 ECU，每个 ECU控制着车辆的不同功能，也有部分功能需要不同的 EC

3、U 共同协作。随着功能越来越复杂，数量庞大的 ECU 对整车协同带来了难度，软件更新迭代也难以实现。要实现软件定义汽车，首先需要实现电子电器架构由分布式向集中式的升级。图 1：汽车 E/E 架构发展趋势分布式域集中式中央集中式1st2nd3rdToday4thCentral Gateway域控制器5th车载资讯娱乐Central Gateway独立ECU功能分离每个功能有各自的ECU- 域内ECU协作- 通过中央网关更强的- 控制域：主体/协助、协同底盘、动力、娱乐3-4个独立工作网域内有限沟通跨功能联系处理复杂功能的能力中央域控制器- 虚拟域解决更多复杂功- 有限的专用硬盘能的能力- 以太网

4、主干网功能融合- 高性能计算E/E架构Central Gateway代际架构主要特点数据来源：麦肯锡，国泰君安证券研究特斯拉在电子电器架构上的领先助力其最先实现 OTA。传统的汽车采用 的是分布式的 ECU 架构，一个功能可能是由若干个零部件的 ECU 共同 实现的，在这种情况下，如果要实现 OTA 升级，就要同时对所涉及的节 点进行统一升级，升级时间很长，用户体验不好。而特斯拉采用了一种 新的电子电器架构，把原有的车身、底盘、安全系统等拆分到了中央计 算模块(CCM)、左车身控制模块(BCM LH)和右车身控制模块(BCM RH)，使控制器尽可能地集中，仅仅保留负责外设的 ECU 维持分散布

5、置。在特 斯拉的域控制器架构中，每一个域都是由一个中央处理器来完成的，如 果需要升级某项功能，就只要升级对应的那个域控制器主板，从而使得 OTA 成为了可能。根据 Consumer Reports 的测评，OTA 帮助 Model3 解决了制动距离过长的问题，大幅提升了其刹车性能。分层的软件架构是软件定义汽车的重要条件 AUTOSAR(Automotive Open System Architecture)即汽车开放系统架构，是一种由各家主机厂、供应商以及研究机构共同参与的汽车电子合作开发框架。该框架源于 2003 年由 9 家主流主机厂、Tier1(宝马、戴姆勒、福特、通用、PSA、丰田、大

6、众、博世、大陆)成立的 AUTOSAR联盟，目前该联盟已经囊括了全球各大主机厂、Tier1、标准软件供应商、开发工具和服务提供商、半导体供应商、高校和研究机构。特斯拉目前并没有加入 AUTOSAR 联盟，而是走自研路径，前期投入较大。之所以能走自研路径，一方面得益于特斯拉把自身定位为豪华品牌，价格较高，能够支撑一些相对大一些的研发投入，另一方面也和特斯拉只造电动车，而且每个车型中的可选项相对较少有关。Semi- conductorsTools and ServicesStandard SoftwareGenericTier1General OEM图 2：AUTOSAR 联盟成员囊括了全球各大主

7、机厂、Tier1、标准软件供应商、开发工具和服务提供商、半导体供应商、高校和研究机构数据来源：AUTOSAR 官网、上汽，国泰君安证券研究目前 AUTOSAR 有 CP、AP 两套标准。最初的标准目前被成为 Classic Platform，而新开发的标准被称为Adaptive Platform。从功能特点上来看，在CP 框架中，每个信号都在配置时定义，属于静态配置；AP 框架下是动态配置，这导致 AP 框架能够实现 OTA，而 CP 框架下不能实现。在应用场景上来看，CP 框架更多地被应用于引擎控制、制动系统等领域，而 AP 框架则被用于自动驾驶中车辆和交通基础设施、云服务器的通信场景，以及

8、域控制器的车辆架构中。简而言之，CP 框架是适合“非智能机”的，而 AP 框架是适合“智能机”的。表 1：CP AUTOSAR 和AP AUTOSAR 比较CPAPUpdate意味着替换整个 ECU 代码删除/更新/增加单个 Application配置部署静态配置，每个信号都在配置时定义动态配置部署传感器融合处理、运行时动态更新自动驾驶中：与交通基础设施的通信、与云服务器的通信应用范例引擎控制、制动系统等数据来源：搞一下汽车电子，国泰君安证券研究域控制器的车辆架构(车身域、娱乐域、动力域)FOTA跨域计算平台、智能手机集成等CP AUTOSAR 的普及程度已经很高，而 AP AUTOSAR 仍

9、在推广过程中。对于 CP 框架：部分主机厂目前暂时没有采用 CP AUTOSAR 框架，但这并不是因为他们采用了另外一套标准，而是因为这些主机厂自己做电子电器架构设计的能力相对有限，更多地关心 Tier1 提供的系统模块能否满足需要实现的功能，而不在意其架构。(如下图中红线即代表了主机厂架构设计能力的强弱，红线越靠上表明其架构设计能力越弱)当这些厂商逐渐能力提升，要开始做自己的架构设计的时候，就会发现他需要用到这个标准。从这个意义上来讲，目前 CP AUTOSAR 的普及度已经很高。图 3：不同主机厂的正向开发能力不同数据来源：汽车电子与软件，国泰君安证券研究对于 AP 框架：这一框架相对还比

10、较新，目前博世、大陆等 Tier1的核心合作伙伴在使用，其中包括全球排名前列的一些主机厂。整体而言，AP AUTOSAR 正处于逐步推广的过程中。AUTOSAR 的最基本理念是分层。在分层概念被引入之前，应用层开发者往往会直接调用和修改寄存器，以实现快速使用硬件驱动的目的，软硬件是难以解耦的。在这种开发模式下，其他工程师很难对代码进行修改，甚至即便是自己写的代码，一段时间之后也不一定能理清代码中的逻辑关系。AUTOSAR 引入分层的理念，将嵌入式软件系统自下而上划分成基础软件架构层、运行环境层以及应用层，每一层封装成标准化接口再提供给上一层。图 4：经典 AUTOSAR 平台通常分为基础软件架

11、构层、AUTOSAR 运行环境层以及应用层数据来源：AUTOSAR 官网，国泰君安证券研究AUTOSAR 通过对接口实现标准化帮助上层开发者降低了对于下层软 件或硬件系统的依赖。对于基础软件层的开发者而言，标准化接口使得 在某个处理平台上开发的软件在其他平台上的复用性大大提升，在提升 了开发效率的同时也降低了出错的概率；对于应用软件的开发人员而言，则不需要关注底层的运行过程而专注于应用功能的研发。图 5：AUTOSAR 降低了上层开发者对于下层软件或硬件系统的依赖数据来源：AUTOSAR 官网，国泰君安证券研究AUTOSAR 诞生的主要推动力来自主机厂。此前汽车中的 ECU 是软硬一体的，软件

12、和硬件来自同一个供应商，完全绑定。在这种情况下，主机厂是没有办法来对功能进行重新分配的，也没有办法在硬件中嵌入自己的软件。而主机厂希望车辆的功能分配更加灵活，同时减少 ECU 的数量，从而一方面降低成本，另一方面降低复杂度，使系统出问题的概率更低。基于这两方面的考量，主机厂需要一个标准的软件架构对电子电器架构进行支撑，AUTOSAR 正是在这样的诉求下应运而生的。和主机厂不同，AUTOSAR 对于博世、大陆等传统 Tier1 而言则是有利有弊。从积极方面来看：AUTOSAR 提升了软件的复用性。Tier1 的软件开发出来之后，能够比较好地复用在不同的主机厂的项目中，而不需要针对每个主机厂都进行特殊的研发，在变换项目的过程中配置工作比此前要简单。从消极方面来看：Tier1 将面临更加激烈的竞争，议价能力被削弱。此前由于软件和硬件高度绑定，Tier1 只需要保证其提供的软硬一体化产品是最有竞争力的就可以了，而不需要软件和硬件同时达到最优；而在软硬件解耦的大趋势下，其软件和硬件将面临单独竞争，主机厂的控制权得到了加强。比如主机厂可以选择只采购某家 Tier1 的硬件和一部分软件，其他软件则自研或者从别的供应商那里购买，在这种情况下，Tier1 的议价能力在一定程度上被削弱。4.风险提示部分