智能机软件（下载智能app下载安装）

我们在《特斯拉系列专题报告（三）：颠覆性创新重塑汽车产业，零部件厂商破壳重 生》中提到，在特斯拉的引领之下，汽车 E/E 架构、软件架构、通信架构正全面升 级，传统汽车产业链正在被颠覆性重塑。此外，《特斯拉系列专题报告（五）：域控 制器—智能汽车的“大脑”》中重点探讨了智能汽车中核心增量零部件域控制器的相 关内容。我们认为，当 E/E 架构正由传统的分布式走向集中化时，原本孤立的 ECU 相互融合为域控制器，并将以此有效减少汽车智能化升级进程中的线束成本、研发 成本等，加速汽车智能化时代的到来。不过，集中化的 E/E 架构以及域控制器的诞 生仅仅是汽车实现快速智能化升级的硬件基础。若要完全实现软件驱动创新、软件 定义汽车，还需要松耦合、易扩展的车载软件架构予以持续赋能。同时，软件亦是 在智能汽车中可做到差异化最高、边际开发成本最低的领域，相比较硬件未来将具 备更大的价值量。因此，本篇我们将重点讨论在汽车硬件架构快速升级的基础下软 件系统的变革趋势，挖掘软件定义汽车时代，车载软件赛道的投资机遇。

(资料图片)

1.1、 软件定义汽车已为产业界共识，鲶鱼效应下车载软件需求大幅提升

“软件定义汽车”（Software Define Vehicle）的概念最早于 2007 年 4 月份的 IEEE 会 议论文中被提出，而后于 2016 年被百度自动驾驶事业部总经理再次提及，随之这一 概念开始在产业界广为流传，并已逐步成为产业界对于智能汽车演进方向的共识。 可以看到，近年来在特斯拉的引领下，众多传统整车厂正通过成立子公司（沃尔沃、 丰田、上汽、长安、一汽、吉利等）、成立软件研发部门（长城、大众、雷诺日产等）、 与软件供应商合作（广汽、宝马等）三种模式加码车载软件领域布局。

而“软件定义汽车”之所以能够在现在时点下成为众多整车厂、传统供应商及互联 网科技公司的共识，究其原因，我们认为主要源自于以下两方面：

（1）特斯拉率先落地“硬件为流量入口、软件为收费服务”的模式，鲶鱼效应显著。

特斯拉基于领先的硬件实力（高算力 AI 芯片、集中化 E/E 架构、以太网通信等）， 通过自研 AI 操作系统率先实现“数据采集-训练学习-部署”的数据闭环，迈向软件 开发 2.0 时代（也即去人力化、以机器学习为主的进化模式）。根据 MIT 学术研究员 Lex Fridman 统计，截至 2020Q1，所有特斯拉已售车型中，95%以上已实现了自动驾 驶相关硬件的预埋。截至 2020 年，预计所有特斯拉已售车型的自动驾驶里程数总和 将超过 51.3 亿英里。同时，基于这种数据闭环，特斯拉早在 2012 年便已在 Model S 上率先实现整车 OTA，从而推动整车厂在产业链的中角色由传统的汽车生产制造商 （“卖硬件”），升级为综合性的出行服务供应商（“卖服务”），并且可以为消费者提 供全生命周期的软件增值服务（“卖软件”），颠覆性改变了传统汽车行业的商业模式。 根据特斯拉官网数据统计，在 2012-2019 年间特斯拉已完成超过 142 次的 OTA 升级 （潜在问题改善 11 次、全新功能导入 67 次、交互界面逻辑等优化 64 次），涉及自 适应巡航、自动紧急刹车系统、360°全景视图、并道辅助等多项功能，系统版本从 2014 年的 V6.0 已迭代至目前的 V10.0。总体而言，特斯拉作为智能汽车的引领者， 其在产业界的示范效应已不言而喻。基于现有数据闭环及软件架构，特斯拉可实现 快速的软件迭代升级，进而建立软件付费模式，进一步打开盈利空间。由此所带来 的鲶鱼效应，促使传统整车厂加速转型布局车载软件领域，软件定义汽车时代正加 速到来。

（2）软件才能形成差异化，以软件驱动创新，边际开发成本更低

复盘智能手机发展路径来看，随着屏幕尺寸、摄像头像素、CPU 性能等硬件竞争的 愈演愈烈，智能手机的硬件体系逐渐固化，各品牌手机硬件同质化严重。由此导致 了手机平均更换周期延长（根据 Statista 数据统计，全球手机平均替换周期已由 2013 年的 25.6 个月延长至 2019 年的 33.2 个月）。而对于手机厂商而言，纯粹的硬件产品 收入增速也随着手机替换周期延长、全球手机渗透率达到瓶颈等因素逐步放缓。根 据苹果公司年报数据统计，其近年来 iphone 产品收入增速已显著下滑。但相比较而 言，以 App Store 为核心的软件收入近年来增速持续保持在 20%以上，并且亦具备更 高的毛利率水平。从长期来看，苹果软件收入的背后是强大的 iOS 生态，根据 2020 年苹果 WWDC（全球开发者大会）官方数据统计，苹果全球应用开发者数量已经超 过 2300 万人，具备持续的更新迭代能力。回看汽车行业，目前，传统整车厂及 Tier1 已纷纷开启智能化转型，主控芯片的算力军备竞赛已经开始，正如智能手机浪潮伊 始之时，各个厂商争相提升摄像头、屏幕以及处理器等配置。而当硬件配置竞赛达 到白热化阶段时，软件层面的竞争则更能体现差异化竞争力。同时，软件的边际开 发成本更低，更易满足用户千人千面的需求，且完善的软件生态亦可为整车厂树立 更加牢固的护城河、打造更为差异化的品牌特征，从而反向推动新车的销量。根据 McKinsey analysis 数据预计，2030 年全球车载软件市场规模将有望达到 500 亿美元。

1.2、 为真正落地软件定义汽车理念，智能汽车软件架构向 SOA 转型升级

集中化的 E/E 架构是实现软件定义汽车的硬件基础，SOA 架构则是实现软件定义汽 车的软件基础。传统的分布式 E/E 架构下，汽车采用的是“面向信号”的软件结构， ECU 之间通过 LIN/CAN 等总线进行点对点通信。并且，此时 ECU 的信号收发关系 和路由信息是静态的（已在 ECU 软件的编译阶段完成预设），如果要新增或升级某 项功能，除了要修改与该信号相关的所有 ECU 软件外，还需要对总线的网关配置、 节点的数量等进行修改。因此，在传统的通信及 ECU 软件架构设计中，通讯网络关 注的重点在于各类信号能否准确、高效的在车内进行收发传导。而随着汽车智能化 升级需求的快速增长，传统通讯网络及软件架构设计中扩展性差、升级和移植成本 高等问题逐渐凸显，例如若想新增某项软件应用或服务，仍需要从头建立一个新的 基础软件环境。因此，为解决以上问题，汽车行业借鉴 IT 行业发展经验，提出 SOA （面向服务）软件架构。

软件架构设计的理念，其核心思想是将每个控制器的底层功能以“服务”的形式进 行封装，一个服务即是一个独立可执行的软件组件，并对其赋予特定的 IP 地址和标 准化的接口以便随时调用，最终通过对这些底层功能的自由组合，以实现某项复杂 的智能化功能。我们以新增 Model X“跳舞”功能的方式为例，具体说明 SOA 软件 架构的优势所在：“跳舞”功能的实现包含音乐、车身、前后运动等多方面，与之对 应的是座舱、车身、底盘中的多个控制器，若在传统软件架构下实现该功能，则需 要对与该功能链路上所有相关的控制器软件进行重新编译，并通过 LIN/CAN 总线实 现信号的传递。而在 SOA 软件架构下，我们可将各个控制器所能贡献的部分抽象为 一种“服务”，如“灯光控制服务”、“语音交互服务”等，然后仅需要对“跳舞”APP 进行编写，对以上基础服务予以调用，即可实现这一功能。

SOA 软件架构下的底层软件具备接口标准化、相互独立、松耦合三大特点。在 SOA 软件架构之下，各个“服务”（底层软件）具有以下三个特点：

（1）标准化：各个“服 务”间具有界定清晰的功能范围，并且留予标准化的访问接口（由第三方代码编码 而成），以便于其他控制器在进行功能变更或升级时进行订阅。

（2）相互独立：每个 服务之间相互独立且唯一，均属于汽车软件架构中的基础软件，因此若想升级或新 增某项功能只需通过标准化的接口进行调用即可。

（3）松耦合：底层软件独立于车 型、硬件平台、操作系统以及编程语言。可以将传统中间件编程从业务逻辑分离， 允许开发人员集中精力编写上层的应用算法，而不必将大量的时间花费在更为底层 的技术实现上。

总体而言，SOA 架构的本质是将原本相互分散的 ECU 及其对应的基础软件功能模 块化、标准化，将各个应用区域相互解耦，重新部署为分层式的软件架构，汽车可 在不增加或更换硬件的条件下通过不同的软件配置为驾驶员提供不同的服务，从而 实现千人千面。以上汽零束 SOA 软件架构为例，将实现“T+0+1+7”的迭代速度， 也即在新的应用场景可于“T+0”快速上线；新的轻应用可于“T+1”快速上线；新 的 APP 则可在“T+7”时快速上线。并且基于标准化的服务接口，开发过程的参与 者将不再局限于整车厂，还将包括第三方应用厂商甚至个人开发者，最终旨在构建 类似于智能手机上 iOS/安卓的开发平台。目前，欧洲主要车厂，如宝马、大众、戴 姆勒等采用 AP AUTOSAR 统一标准来构建 SOA 基础软件平台；而国内车厂在纷纷 成立软件中心的同时亦建立 AUTOSEMO 联盟，构建国内本地化的软件开发标准。

此外，亦有华为、特斯拉基于 Linux 系统自建分层、模块化基础软件平台。

2、 短期看系统及功能软件举足轻重，长期看应用层价值更大

在 SOA 软件架构设计理念之下，汽车软件架构走向分层化、模块化，使得应用层功 能够在不同车型、硬件平台、操作系统上复用，并且可以通过标准化接口对应用功 能进行快速迭代升级。进一步来看，软件架构按层级自下而上大致可分为系统软件 （虚拟机、系统内核、中间件）、功能软件以及应用程序层三部分。短期来看，若想 真正在汽车上落地 SOA 软件架构，虚拟机技术、系统内核及中间件等系统软件将至 关重要；长期来看，在 SOA 架构构建成熟后，丰富的应用生态具备更大的价值空间。

2.1、 系统软件：操作系统的基石，支撑上层软件运行的载体

在智能汽车的嵌入式操作系统中，系统软件是最为基础的部分，通常包括系统内核、 中间件、虚拟机三大部分。同时，通过系统软件平台集成虚拟机、系统内核、中间件等组件，可为上层功能软件提供一个稳定、高效、安全的运行环境，以及与硬件 无关的应用开发接口。

2.1.1、 虚拟机：构建智能计算平台操作系统的第一步

虚拟机技术的引入是实现软件定义汽车的第一步。汽车从硬件角度来看，智能汽车 中无论是 E/E 架构还是主控芯片，都存在显著的集中化趋势，其中 E/E 架构由分布 式走向域集中，主控芯片由单一的 CPU 走向包含 AI 单元的 SOC 芯片。而在硬件资 源集中化的背景下，传统的基于总线和网关的物理保护屏障被打破，使得不同安全 等级的应用不得不共享同一个计算平台。此时，可保障各类应用系统具备一定隔离 性的虚拟机（Hypervisor）技术，将成为实现高性能智能驾驶操作系统的关键。举例 来看，在座舱域控制器中，由于产品属性的不同，需要运行不同类别的操作系统， 比如 QNX 负责安全要求等级较高的仪表、安卓则用于更强调应用生态的信息娱乐系 统。通过 Hypervisor 技术可以将以上不同的操作系统运行在同一个主控芯片之上。 如此以来，智能汽车中的硬件资源和软件资源可以根据终端产品需求的不同，灵活 的在各类操作系统中给予分配，从而更好的发挥芯片性能、降低硬件成本。

当前可提供车规级 Hypervisor 技术的厂商较少，QNX 凭借高安全等级占据市场主 导地位。从竞争格局来看，由于车载虚拟机技术要求安全等级较高（需通过 ASIL D 级安全认证），因此仅少数的头部厂商可提供该产品，市场份额高度集中。目前，产 业内主要的虚拟机技术包括黑莓的 QNX Hypervisor、瑞萨的 COQOS Hypervisor、英 特尔的ACRN、大陆集团的L4RE等。其中，QNX Hypervisor 2.0是全球首款通过 ASIL D 安全认证的商用虚拟机，能够支持在单一芯片上运行 QNX Neutrino、Linux 以及 Android 等多个操作系统，已广泛被国内外整车厂及 Tier1 采用。

2.1.2、 系统内核：汽车软件架构的核心，竞争格局高度稳定

内核是系统软件中最核心的部分，是软件架构中直接且唯一可对接硬件资源的部分。操作系统通过采用输入输出语句控制下层硬件，并将硬件控制命令集成于内核的库 函数——系统调用（System Calls），上层应用程序通过访问系统内核进而调用硬件资 源。以“驾驶员通过与车内液晶屏幕交互使得汽车自动打开天窗”为例，需要经历 下面的几个流程：

（1）通过 HMI（Human Machine Interface，人机交互）层。将驾驶 员的生理信号通过液晶屏幕进行压力触碰识别，转换为电输入信号。

（2）通过应用 程序层。由电输入信号启动与压力触碰相对应的应用程序。

（3）通过中间件层。应 用程序向下需要首先经过中间件，需要向中间件获得相应的计算资源和网络通信来 继续向下传递信号。

（4）进入系统内核。当信号传入内核中，内核会根据输入信号 的强弱（即中间层分配的计算资源和网络通信大小）为该应用程序规划并调度相应 的机械单元完成目标操作。总体来说，内核在整个流程中起到调度硬件、协调实施 的重要作用。

进一步来看，系统内核具备较高的技术壁垒，QNX 和 Linux 市场份额占据 90%以 上，竞争格局稳定。系统内核具体可分为微内核、宏内核及混合内核三种：

（1）微 内核是系统内核的一种精简形式。通常而言，系统服务层和内核集成在一起，而微 内核将系统服务层分离出来，变成可以根据需求加入的选件，由此可以提供更好的 可扩展性和更加有效的应用环境。微内核具有代码量和漏洞少、可扩展性高的优点， 但内核与服务层间的频繁通信会降低系统整体性能。根据思迈汽车信息咨询公司 2019 年的相关数据，QNX Neutrino 微内核在车控操作系统/车载操作系统中市占率分 别为 90%/50%以上，截至 2020 年 6 月已搭载于超 1.75 亿车辆，具备垄断地位。

（2） 宏内核同样管理着用户程序和硬件之间的系统资源，但是在宏内核架构中，用户服务和内核服务在同一空间中实现。具体而言，内核可以代表内核进程运行代码，即 内核进程；当用户进程经过系统调用或者中断进入到内核态时，内核也可以代表它 运行代码。因此，宏内核需要管理的资源多于微内核，其大小相对微内核更大一些。 性能高的同时也带来了维护困难的缺点。Linux 和 WinCE 为宏内核产品，同时由于 Linux 开源从而更易扩展应用生态，因此常用于车载信息娱乐系统之中。

（3）混合内 核包含了两个或两个以上的内核，是华为等研发能力较强企业由宏内核向微内核发 展的过渡方案。2019 年发布的鸿蒙 OS 1.0 采用了混合内核结构，即同时搭载了 Linux 内核、自研的鸿蒙微内核和 Lite OS 作为当前的技术过渡方案。由于系统内核开发难 度最大，且安全性要求最高，因此少有厂商涉足该领域，竞争格局亦最为稳定。根 据 IHS Automotive 数据统计，系统内核目前主要以 QNX 和开源的 Linux 为主，两者 合计市占率已近 90%（包含车机和车控两类）。

2.1.3、 中间件：实现软硬件解耦关键环节，海内外 Tier1 加码中间件研发

中间件是一类提供系统软件和应用软件之间连接、便于软件各部件之间沟通的软件， 应用软件可以借助中间件在不同的技术架构之间共享信息与资源，根据功能领域的 不同具体可分为通信中间件、数据存储中间件、安全中间件等多种。中间件位于客 户机服务器的操作系统之上，管理客户机与系统软件之间的计算资源和网络通信。

通过对底层软件模块的封装和接口标准化，可以将硬件功能抽象化并将其通过标准 化接口提供给上层软件开发者，实现软硬件分离。同时推动跨平台开发，减少设计 的复杂性，从而消除了多次重新开发相同软件的问题。目前，应用在汽车领域的中 间件主要包括 AUTOSAR、OSEK、QNX 等，满足最高等级的功能安全需求，其中 AUTOSAR 由于其应用的广泛性、方法论的成熟性，拥有最广泛的开发生态，且已 有 EB、VECTOR、ETAS、东软睿驰、华为等多家软件供应商可基于 AUTOSAR 架 构提供具有差异化的中间件解决方案。

从 CP AUTOSAR 到 AP AUTOSAR，助力整车厂构建 SOA 软件架构

AUTOSAR 是汽车行业内最著名的中间件方案，由众多整车厂与供应商联合制定， 其核心在于对各个软件接口进行标准化定义。2003 年，整车厂与供应商为降低汽车 电子系统软件的开发成本、同时更加便捷有效的对其进行管理，共同建立了汽车开 放系统架构（AUTOSAR）。AUTOSAR 架构中对各功能模块进行了封装，并对模块 与模块之间的接口进行了标准化，从而实现了汽车软件与硬件的解耦。以经典 AUTOSAR 为例，AUTOSAR 平台运行于微处理器（MCU）之上，并将汽车的软件 架构抽象为基础软件层、运行环境层以及应用软件层三部分：

（1）基础软件层（BSW） 包括微控制器抽象层、ECU 抽象层、服务层、复杂设备驱动层四部分，是将硬件“软 化”的第一步。其主要作用是将各类标准化的基础软件服务功能封装起来供应用层 调用（本身并不参加实际工作），包括系统服务、内存服务、通信服务等。

（2）运行 环境层（RTE）是 AUTOSAR 系统的核心枢纽，其通过标准化的接口（分为标准化 接口、AUTOSAR 接口、标准化的 AUTOSAR 接口三类）将上层应用软件与基础软 件层进行连接，使得应用层可以通过 RTE 的接口函数来调用基础软件服务。

（3）应 用软件层则是负责实现汽车中各类具体功能。

经典 AUTOSAR 是以“面向信号”软件架构为背景下的产物，当软件架构迈向 SOA 时，AP AUTOSAR 将开始被广泛应用。在传统“面向信号”的软件架构中，CP AUTOSAR 的引入虽然可以有效解决应用程序与底层软件强耦合的问题，降低应用 程序的开发成本，但各个 ECU 的信号收发关系和路由信息已在 ECU 软件的编译阶 段完成预设，后期难以大幅修改、批量升级。因此，在 SOA 软件架构理念下， AUTOSAR 于 2017 年提出 AP AUTOSAR 平台，平台由根据服务和 AP AUTOSAR 基 础分组的多个功能栈组成。相比较 CP AUTOSAR，AP AUTOSAR 具备可灵活在线升 级、硬件资源连接虚拟化（不局限于线束的连接关系、可通过互联网连接），支持高 性能计算等优势，更适用于功能需求快速迭代的智能驾驶时代。

龙头企业加码中间件研发，打造从硬件至基础软件的完整解决方案

中间件作为一种基础软件，其关键在于能否通过制定一套可行的架构和标准的开发 方法论，把汽车软件开发人员从大量重复的研发工作中解放出来。因此，产业链对 其的认可程度将决定其能否获存活，例如 AUTOSAR 标准之所以可以得到广泛应用， 得益于其在全球拥有超过 284 个会员（截至 2020 年 5 月），核心成员包括宝马、博 世、德国大陆、戴姆勒等全球龙头整车厂及 Tier1。历史上来看，经典 AUTOSAR 标 准下的开发工具链及基础软件几乎被海外 Tier1 所垄断，包括 EB（Continental 子公 司）、ETAS（Bosch 子公司）、VECTOR 等。而随着汽车产业的智能化转型升级，AP AUTOSAR 逐渐登上历史舞台，各个传统 Tier1 及科技公司亦相继发布新一代中间件 解决方案。例如，2020 年 7 月，博世推出针对高级自动驾驶应用的中间件 Iceoryx， 兼容 ROS2 和 AP AUTOSAR 的接口，满足不同开发阶段的需求。2020 年 12 月，采 埃孚发布中间件 ZF Middleware，提供可以集成到整车制造商软件平台的模块化解决 方案，将于 2024 年搭载在量产车辆上。国内方面，此前行业内汽车基础软件架构标 准及产业生态整体较为落后，而在产业智能化转型升级的趋势下，部分国内厂商紧 抓 AP AUTOSAR 应用趋势，相继迈向中间件及其工具链的研发。例如，华为发布的 智能驾驶域控制器MDC及支持和兼容AP AUTOSAR架构，东软睿驰基于AUTOSAR 标准所定制化开发的基础软件 NeuSAR 等。可以看到，海内外 Tier1 在中控仪表、域 控制器、摄像头等硬件领域相继进行智能化转型升级的同时，亦开始渗透底层基础 软件的开发，从而打造可提供从硬件到基础软件完整解决方案的能力，进一步助力 降低整车厂研发成本，加快新产品落地。

2.2、 功能软件：将共性需求软件化、模块化，助力应用程序快速部署

由于智能驾驶涵盖多种跨行业技术，在软件层面具备较高的复杂性，单一厂商很难在系统软件之上完成端到端的设计，因此只有实现功能软件化、模块化、标准化， 使得产业链各方力量各抒己长（例如算法公司专注于感知或规控等算法、Tier1 亦可 专注自己擅长的模块），整车厂才能根据功能软件框架进行集成、灵活配置，从而推 动智能网联产品快速落地。功能软件目前的整体集成由整车厂主导，而各个功能模 块的研发由软件供应商与整车厂合作完成，其中主要包含自动驾驶通用框架模块、 传感器抽象功能模块、感知融合功能模块、预测功能模块、定位功能模块等。我们 以感知融合功能模块为例，进一步来说明此类功能软件的作用：在日常的车辆运行 过程中，周围的交通环境会因为天气、拥堵程度等不可控因素而变得十分复杂，因 此仅靠单一的传感器难以适应全工况、全天候的环境感知，此时就需要不同特性的 传感器相互配合，从而提升感知的性能和可靠性。而感知融合功能模块便是将各类 不同特性的传感器的测量结果（包括车辆状态、车辆模型等）抽象化后，完成在数 字世界中对环境模型的构建，最终输出至自动驾驶预测和决策模块。总体而言，功 能软件对智能驾驶中的一些共性需求进行有效抽象，并将其软件化、模块化、标准 化，结合系统软件共同构建完整的操作系统，并且配合成熟的工具链使得整车厂可 以快速实现智能驾驶应用功能的部署。

2.3、 应用程序：持续更新迭代，差异化竞争的焦点

应用程序是基于操作系统之上独立开发的软件程序，亦是各汽车品牌差异化竞争的焦点。应用算法差异化不仅涵盖智能座舱（车载信息娱乐系统 IVI、车联网、人机 交互、中控系统、ADAS、智能座椅等），也包括智能驾驶（L1~L5 级智能驾驶等级） 领域。同时伴随着云端软件复杂性的提高，车载网络信息安全(检测与防卫远程攻击) 也将逐步成为未来应用算法的关注焦点。

2.3.1、 OTA 空中升级模式普及，云端更新持续创造价值

OTA（Over-The-Air Technology，空中下载技术）指通过车端与云端通信升级车内 系统，是车企从静态出售硬件到动态服务创收的战略转型所依赖的重要技术，也成 为了车企差异化竞争的重要赛道。OTA 升级创新了车企的产销模式，大大缩短了研 发和交付周期，车企可通过添加软件补丁和解锁预埋硬件功能在智能汽车全生命周期内持续创造价值。根据美国科技媒体 Electrek 统计，截至 2019 年特斯拉已通过出 售 FSD 套件实现收入超过 10 亿美元。具体来看，以特斯拉为例，OTA 升级流程包 括三步：

（1）由软件供应商生成更新包传输给云端服务器。

（2）由车辆网联模块接 收并下载更新包。

（3）由网关/OTA Manager 调用并向车载 ECU 分配更新包。据此， 可将 OTA 分类为 SOTA（Software-Over-The-Air）和 FOTA（Firmware-Over-The-Air）：

（1）FOTA 可以实现大多数核心 ECU 层面的升级，包括更改电池、电机、发动机、 变速箱等控制件以改善续航能力和加速性能，比如 Model 3 通过 OTA 将百里加速时 间由 4.6 秒提升为 4.1 秒。FOTA 过程需要压缩更新包于待升级的嵌入式设备中，同 时需要借助算法提升更新效率，因而对底层固件开放权限和差分算法要求较高，目 前仅有特斯拉、蔚来等少数车厂能够实现 FOTA。

（2）SOTA 仅实现应用软件层面的 升级，大部分车企已具备 SOTA 技术。

2.3.2、 云端安全问题初现端倪，软件信息安全领域未来市场开阔

“软件定义汽车”不仅体现在开发端代码量的指数式增长，云端软件复杂性的提高 还给联网车辆带来了许多难以追踪的新型信息安全风险。在传统汽车的 E/E 架构下， 程序员通过在 ECU 中独立嵌入预先设置好的代码来满足功能需求，而在新一代汽车 的 SOA 架构下，越来越多的应用层接入云端，使得车载网络在以前独立的电子领域 （例如信息娱乐，ADAS 和动力总成）之间建立连接。这些连接为通过汽车传播的 新型网络攻击提供了渠道，由于可以利用一个系统中的软件漏洞来提供对其他系统 的访问，跨车辆研究不同软件堆栈的开发人员很少协调修复系统安全漏洞。且由于 软件功能品类繁多，跨模块的更新很困难，并且潜在“攻击面”的数量会随着所连 接的自动驾驶系统数量增加而递增。根据 Upstream Security 发布的 2020 年《汽车网 络安全报告》显示，自2016年至2020年1月，汽车网络安全事件的数量增长了605%。

具体来看，在软件信息安全领域，以腾讯和 360 公司为代表的老牌互联网公司凭借 着强大的 IT 网络安全技术优势，对以特斯拉为代表的智能网联汽车开展了大量研究。常用的车联网攻击程序渗透路径可归纳为：

（1）接入系统。即通过车内开放式的网 络连接端口接入车载服务电子系统，进而采用传统分析方法找出应用服务中的安全 漏洞，获取多个车载系统权限。

（2）避开检测。由于各自独立的 ECU 间通过 CAN 总线相连，获得 CAN 总线的权限即代表掌握了车体控制电子系统的命脉。所以其往 往采用技术手段绕过部分 ECU 的固件完整性检测机制，刷新相应固件来获得向 CAN 总线读写数据的能力。

（3）实施控制。最终通过将伪造的数据包注入到 CAN 总线， 实现在驻车模式或行驶模式下对汽车的远程无物理接触式控制。总体来看，随着汽 车智能网联化进程的加速，软件功能的问题引发大规模的产品召回，直接导致客户 安全风险增加，对整车厂造成生产延期、预算超支等不良影响。为此，车载信息安 全行业需求渐起，软件信息安全领域的进步正为智能网联汽车的发展提供强有力的 支持。

3、 软件定义汽车时代，多方势力角逐操作系统

软件定义汽车时代，操作系统将是智能网联汽车竞争的焦点。我们从技术角度和产 品角度两个维度去定义操作系统类型。从技术角度来看，车载操作系统可分为实时 操作系统和非实时操作系统。分别来看，所谓实时操作系统，是指系统接收到输入 信号后，能够在短时间内处理完毕并予以反馈，并且其处理任务的（最迟）完成时 间是确定可知的，具备较高的安全性与可靠性。因此实时操作系统往往应用于车控 领域，包含传统的车辆动力、底盘、车身以及新兴的自动驾驶等。非实时操作系统 则广泛应用于座舱娱乐等领域，更加注重兼容性与开发生态。从产品角度来看，车 载操作系统可分为面向整车厂和面向消费者的两类。其中，面向整车厂的操作系统 多被用于二次开发或消费者无法直接交互感知的领域，因此其自身并不具备品牌效 应。面向消费者的操作系统，以市场产品化为目的和检验标准，具备一定的品牌溢 价，大多数厂商是基于 Linux 内核裁剪和配置，然后加上自己设计的 UI 而成。整体 来看，以上两种对车载操作系统的定义相互交叉，面向整车厂的实时性操作系统包 括 QNX、RT-Linux、VxWorks 等；面向整车厂的非实时性操作系统主要为 Android、 AGL 等。面向消费者的实时性操作系统包括特斯拉 Version、百度 Apollo、华为鸿蒙 OS 等；而面向消费者的非实时性操作系统则包括小鹏 Xmart.OS、阿里 Ali.OS 等。

3.1、 面向整车厂的实时性操作系统：QNX、RT-Linux 等

3.1.1、 QNX：世界首款通过车规级安全认证的操作系统，核心优势在于高安全性

QNX 是世界上第一款通过 ISO 26262 ASIL 级安全认证的车载操作系统，母公司黑莓 所拥有的 80+项安全认证和数千项安全相关专利将为其安全性持续赋能。从技术端来 看，QNX 采取微核心架构，操作系统中的多数功能均以许多小型 Task 来执行，这样 的架构使得用户和开发者可以关闭不需要的功能而不需要改变操作系统本身。得益 于这种执行模式，QNX 系统中的各项功能与应用能在不影响互相间稳定性的前提下 整合运算资源，在高安全性的同时保障其运算效率。从产品端来看，公司产品覆盖 基础系统软件（QNX Neutrino RTOS、QNX Hypervisor、QNX SDP）、安全认证产品 （QNX OS for Safety 等）、安全解决方案（BlackBerry Jarvis、BlackBerry QNX OTA 等）、中间件（声学管理、ADAS 等）四大领域。同时，为确保软件的安全性，QNX 开发生态较为封闭，黑莓是 QNX 的唯一开发者，其他厂商在使用时需支付版权费用。 根据黑莓公司官网数据统计，截至 2020 年 6 月底，全球已有超过 1.75 亿辆汽车已搭 载 QNX 系统，车用市场占有率达 75%。德尔福、大陆、电装等 Tier1 的基础软件层 都是在 QNX 系统上搭建的，而其合作伙伴既包括小鹏、威马等新势力车企，也包括 宝马、奥迪、保时捷、大众、福特、通用等传统 OEM。

3.1.2、 Linux：优化后用于 RTOS，核心优势在于灵活的开发度

Linux 操作系统诞生于 1991 年，由于其完全开源的特性，在过去的三十年中，全球 的软件工程师都在为 Linux 体系不断贡献代码，让其更加完善。而高效、灵活的特 性亦使得其被广泛使用在平板电脑、交换机、路由器、视频游戏控制台、台式计算 机、掌机游戏、大型机和超级计算机等产品上面。相比较 QNX，Linux 的特点在于 免费开源，并且给予用户更大的灵活性、更多的应用场景、更为丰富的软件库选择。 同时，可通过对内核的进程调度、中断服务程序等代码进行修改与优化，提高系统 的实时性能，具体改进方案包括直接修改内核法（如 Kurt-Linux、Ingo's RT patch 等） 和双内核法（RT-Linux）。目前，许多厂商是基于 Linux 内核进行裁剪和配置，然后 加上自己设计的 UI，作为车载操作系统。典型的包括特斯拉 Version、华为鸿蒙 OS、 阿里 AliOS 等。此外，德赛西威目前量产的车载信息娱乐系统和虚拟仪表的操作系 统大部分也是基于 Linux 平台开发的。

3.2、 面向整车厂的非实时性操作系统：AGL、Android

3.2.1、 AGL:基于 Linux 的开源车载操作系统

Linux 基金会针对汽车领域成立 AGL 联盟，该系统可提供 70%~80%的现成平台。 Linux 基金会于 2014 年针对车载信息娱乐领域发布了 AGL（Automotive Grade Linux） 操作系统。与安卓系统类似，AGL 的主要优势之一是它的统一代码库（UCB），它 基于 Tizen 和 GENIVI Alliance 另外两个汽车开源项目，从底层开始开发，一直到特 定的汽车应用软件，可提供 70%到 80%的现成平台，这使得汽车制造商和供应商能 够将他们的资源集中在定制其他的 20-30％，以满足他们独特的客户需求。目前，AGL 联盟成员已超过 150 个，其中 11 个是汽车制造商（包括丰田、本田、马自达、日产、 大众等）主要应用领域仍集中于信息娱乐系统。

3.2.2、 Android：兼容性与应用生态优势显著

Android 是基于 Linux 内核开发的操作系统，被称为“类 Linux 系统”，在兼容性与 应用生态方面具备较强竞争力。2014 年，Google 联合一些车企与科技企业组成 OAA 联盟，旨在将 Android 操作系统引入汽车领域，Android Auto 同年作为该联盟第一个 应用成果正式发布。2019年，Google为抗衡传统车载联盟推出了Android-Automotive， 目的是获得新的流量入口，将 Google 在机器学习方面的技术优势结合到汽车上来， 形成其在自动驾驶方面的主导地位，卡位未来交通。

Android Auto 是专门为驾驶环境而设计的安卓版车机互联方案，可让用户将智能手机连接到兼容的车辆上，以便直接在控制台上显示针对驾驶员进行了优化的应用版本。 目前奥迪、凯迪拉克、沃尔沃等超过 50 家汽车制造商宣布支持 Android Auto。

Android Automotive 是一个支持信息娱乐系统开发的全栈、开源、高度可定制的平台。 配备该操作系统的车辆，信息娱乐系统完全基于 Android 的专用版本构建，不需要手 机的参与，将直接集成至车辆。与 Android Auto 不同，Android Automotive 可以控制 车辆的诸多功能，如空调，暖气，加热座椅和音频功能等，此时汽车与智能手机一 样，是一个独立的设备。使用 Google 帐户登录汽车的操作系统后，可以根据用户自 定义的方式加载应用程序和屏幕，为用户量身定制驾驶体验。2020 年，通用汽车宣 布将从 2021 年开始搭载 Android Automotive OS。沃尔沃旗下 Polestar 2 是首款通过 Android Automotive 进入市场的汽车，驾驶员可以通过中央屏幕控制车辆的所有功能， 还可以访问许多可以增强驾驶体验的应用程序。未来，随着 Android 大型开发社区中 汽车信息娱乐系统的快速迭代和开发，Android Automotive 在汽车信息与系统方面的 优势有望逐步凸显。

3.3、 面向消费者的实时性操作系统：百度 Apollo、华为鸿蒙 OS 等

3.3.1、 特斯拉 Version：基于 Linux 内核深度定制化改造

特斯拉的操作系统 Version 基于 Linux 内核深度改造而成。特斯拉系统平台采用 Linux4.4 开源操作系统，支持 PyTorch 的深度学习编程框架，基于 Kafka 开源流 实时数据处理平台，可支持信息娱乐系统（IVI）和驾驶辅助系统（ADAS）等。同 时，Linux 开源自由的特点可以让特斯拉避免受制于操作系统厂商，特斯拉可通过 OTA 快速进行问题修正与软件升级，从而提升用户体验。自 2014 年首次在 Model S 上使用 Version 6 以来， 特斯拉已通过 OTA 技术对其操作系统进行了多次重大 升级，涉及自适应巡航、自动紧急刹车系统、360°全景视图、并道辅助等多项功能， 系统版本从 2014 年的 V6.0 已迭代至目前的 V10.0。

3.3.2、 华为鸿蒙 OS：自主研发鸿蒙微内核，多域覆盖提供全栈式解决方案

华为智能汽车软件解决方案包括三个操作系统+一个跨域集成软件框架。

（1）鸿蒙座 舱操作系统 HOS：华为针对汽车座舱的使用场景、上层应用软件和底层硬件对接的 需求，进行了定制化开发，打造了鸿蒙座舱操作系统 HOS。整体来看，鸿蒙座舱操 作系统 HOS 采用双内核方案，针对于安全功能等级较高的仪表领域采用鸿蒙微内核 （具备实时性）；而在对软件生态要求较高的 IVI 领域，则采用基于 Linux 改造的宏 内核。此外，在功能软件层面，华为基于语音交互、视觉、声音分区、音箱音响、 触控共五大核心功能开发了融合感知模块，并通过标准化的 API 开放给主机厂、Tier1 等，使其可以进行定制化开发，共同构建应用生态。

（2）智能驾驶操作系统 AOS： 针对智能驾驶打造的实时操作，目前已通过 ASIL-D 等安全认证，成为业界首个获得 Security & Safety 双高认证的商用 OS 内核。

（3）智能车控操作系统 VOS：该系统原 生支持异构多核，模型化工具链，兼容 AUTOSAR。可以使得原来多 ECU 的集中开 发变得简单高效。同时，该系统相比于现有的车控系统将更加开放，不仅支持华为 自己的微处理器芯片，而且会支持世界范围内包括恩智浦、英飞凌在内的众多芯片。

（4）华为 Vehicle Stack：是面向服务（SOA）的跨域集成软件框架，相当于欧洲传 统车企联盟所创造的 AUTOSAR。在此软件架构之下，可以各个操作系统之间互联 互通，使能整车特性快速开发、验证、部署，同时还支持丰富的自动化工具链，车 型开发周期可缩短 6－8 个月。

3.3.3、 百度 Apollo：基于 ROS 深度定制内核，打造开源的自动驾驶软件开发平台

2017 年，百度发布“阿波罗计划”及 Apollo 1.0，定位为自动驾驶软件的开源平台。该 平台结合多种开发工具，包括数据、API 和开源代码等，开发者可以免费使用这些 工具将自动驾驶产品推向市场。2018 年 7 月，在百度 AI 开发者大会上，百度发布 Apollo3.0 及小度车载 OS，并首次发布了车载语义开放平台。2019 年 12 月，在首届 百度 Apollo 生态大会上，百度推出了 Apollo 5.5 版本，同时支持点对点城市自动驾 驶，并将自动驾驶平台扩展为自动驾驶、车路协同、智能车联三大开源平台。2020 年，百度发布 Apollo 6.0 迈向无人驾驶领域。其中，Apollo 实时操作系统是 Ubuntu Linux 操作系统与 Apollo 内核相结合的成果。其中，ubuntu 是业内顶级 Linux 发行版 之一，也是流行的云操作系统；Apollo 内核是基于 ROS 进行改进而成。原始的 Ubuntu 系统并非实时操作系统，通过加入 Apollo 自主设计的内核，使其成为实时性操作系 统。类似于谷歌在移动领域中推出的 Android 开源项目，整个 Apollo 平台旨在车载 领域中为第三方提供更为便捷的开发环境。2021 年 1 月 11 日，百度宣布组建智能汽 车公司，以整车制造商的身份与吉利汽车战略合作，正式进军汽车行业。

3.4、 面向消费者的非实时性操作系统：腾讯 TAI、阿里 AliOS 等

3.4.1、 腾讯 TAI：丰富的应用生态，提供 300 万量级服务应用扩展空间

2017 年 11 月，腾讯在全球合作伙伴大会推出腾讯车联 AI in Car 系统，一年后，AI in Car升级为腾讯车联TAI汽车智能系统。2020年6月，腾讯车联推出全新TAI3.0TAI3.0 包含两大车载 APP——腾讯随行、腾讯爱趣听，以及一个云端轻量化的生态开放平 台“腾讯小场景”，能为车上生态带来 300 万量级服务应用扩展空间。同时，TAI3.0 刷新了行业上车速度，对于通过系统和硬件依赖性评估的车辆，最短能在 2 个月内 实现快速上车，能自适应 Android、Linux 等不同车机系统以及差异化的硬件平台， 拥有一整套自动化上车工具链和标准化上车流程。目前，腾讯车联 TAI 已与宝马、 长安、广汽、东风等 29 家主流车企展开合作，有 110 多款主流车型已经或即将落地。

3.4.2、 阿里 AliOS：一站式 IoT 解决方案，构建云端一体化生态

AliOS 是阿里巴巴集团推出的移动操作系统，可应用于智联网汽车、智能家居、手机、 Pad 等智能终端，目标为行业提供一站式 IoT 解决方案，构建 IoT 云端一体化生态， 使物联网终端更加智能。AliOS 于 2014 开始进军车载方向，基于 Linux 内核而研发， 采用阿里云虚拟机技术，目前主要应用于智能座舱领域。2016 年，AliOS 在荣威 RX5 中实现了汽车操作系统的商用，并率先提出“去 APP 化”的应用模式：AliOS 采用 “场景地图桌面+无缝连贯服务体验”的架构和生态，相比较 PC 端中 Windows“桌 面+文件”实现的“人找内容”，移动端中 Android 与 iOS 的“桌面+APP”架构实现 的“人找应用”，AliOS 则实现了“服务找人”的模式。例如，当车主的常规线路发 生拥堵时，系统会给车主发送一条信息，推荐最佳导航路线；若车主告知汽车要去 电影院看电影，系统会自动规划去电影院的路线以及看电影之前的就餐地点、停车 场。2016 年 7 月开始，与上汽合作陆续推出搭载 AliOS 系统的荣威 RX5、荣威 eRX5、 荣威 ERX5、荣威 i6、荣威 ei6、荣威 950、荣威 RX3，名爵 ZS、名爵 3、名爵 6、 名爵 GS，大通 D90 等 10 余款车型 2017 年 10 月与神龙汽车合作，2018 年东风雪铁 龙品牌推出搭载 AliOS 的智联网汽车，2019 年 3 月与斯柯达合作，明锐等多款车型 搭载斑马智行，2019 年 12 月与中国一汽战略合作。

标签： 域控制器