（报告出品方：中信建投证券）

一、概况：计算平台是自动驾驶系统“大脑”，供应生态多样

核心结论：自动驾驶汽车围绕感知、决策和执行三大环节构建软硬件系统。车载智能计算平台是自动驾驶 汽车的“大脑”，主要负责完成感知环节的识别融合任务以及整个决策环节，需要处理海量数据和进行复杂的 逻辑运算。为满足高算力需求，目前车载智能计算平台集成多个 SoC，每个 SoC 集成多类计算单元（如 CPU、 GPU、FPGA、ASIC 等）。同时，车载智能计算平台还需要高效的软件架构支持应用开发。其软件架构高度分 层化和模块化，主要分为系统软件（虚拟机、操作系统和中间件）、功能软件和应用程序三层。相较于传统零 部件，车载智能计算平台涉及各类芯片和软件，供应商来自不同领域，供应生态多样。主要有三类参与者：OEM 主要负责应用软件和部分功能软件，传统 Tier1 在中间层布局较深，芯片商提供硬件以及部分系统软件。另外 还有算法方案解决商、Robotaxi 厂商、专业系统软件商等。

1.1 自动驾驶系统架构：传感器 车载智能计算平台 执行系统

自动驾驶系统是一个复杂的系统。为实现从 A 地到 B 地的驾驶过程，需要自动驾驶系统完成感知、决策、 执行 3 大任务。

感知：感知环节是实现自动驾驶的前提和基础，其主要功能是解决 2 个问题：环境识别（周边环境如何） 和自身定位（在哪里）。环境识别（周边环境如何）：感知系统利用摄像头、激光雷达、毫米波雷达、超声波 雷达等传感器获取道路环境的信息，并对传感器数据进行处理、融合、理解，实现对车辆、行人等障碍物的识 别，以及对车道线、红绿灯等交通标识的检测。自身定位（在哪里）：利用全球导航卫星系统（GNSS）、惯性测量单元（IMU）、高清地图、车速传感器等获取车辆自身空间状态信息。环境状态信息以及自身状态信息为 后续车辆预测、规划等决策环节提供依据。

决策：决策环节是自动驾驶的核心，其主要功能是回答几个问题：预测（接下来会发生什么）、决策（该 做什么）、规划（怎么做）。在感知环节完成对自身精确定位和对周围环境准确理解的基础上，决策环节主要 是对接下来可能发生的情况进行准确预测，对下一步行动完成准确判断和规划，并选择合理的路径达到目标， 指导执行系统对车辆进行控制。 执行：自动驾驶系统最终要借助对车辆的控制达到自动驾驶的目的。执行环节负责将决策和规划落实为切 实的行为。执行系统控制器（如底盘控制器、动力系统控制等）接收决策系统输出的目标路径轨迹，通过一系 列结合自身属性和外界物理因素的动力学计算，转换成对油门、刹车、转向的控制，尽可能控制车辆按目标速 度和方向行驶。 完成上述 3 大任务需要车端系统、云端系统的支持，以及各类技术（如先进的整车电子电气架构、OTA、 V2X 等）的保障。完备的车端系统是自动驾驶功能实现的主要装备保障，仅靠车端系统即可实现初级和部分中 级自动驾驶功能。车端系统主要包括：感知定位传感器系统、车载智能计算平台（简称计算平台）和底盘/动力 系统。

车载智能计算平台：如同人类大脑，完成感知环节的识别融合任务以及整个决策环节。自动驾驶几乎所有 的计算都集中在计算平台。各类专用、通用芯片组成的硬件资源为计算平台提供算力保障。基于虚拟机、各类 操作系统、中间件的系统软件架构为自动驾驶算法和功能实现提供软件平台。AI 算法、滤波算法、规划算法等 基础算法库以及保障工程实现的安全、备份、通信等基础功能库组成的功能软件为差异化的应用实现提供基础 模块支持。计算平台的软硬件的差异是各厂商自动驾驶功能差异的核心所在，计算平台性能优良体现厂商自动 驾驶技术实力的高低。 底盘/动力系统：如同人类手脚，负责执行环节。底盘/动力系统包括对应的控制器和机械执行机构。底盘系 统负责实现车辆转向和制动，动力系统负责车辆驱动。对于自动驾驶汽车，执行机构电子化，以及更进一步的 线控技术是执行系统的基本技术要求。比如电子油门、电子助力转向、电子助力制动等。执行机构电子化实现 人机解耦和自动控制。比如传统的真空助力制动系统只有当驾驶员踩动制动踏板，刹车助力系统才会工作。采 用电动助力系统后，驾驶员不踩制动踏板，只要启动助力电机也能推动制动主缸，最终产生制动。

1.2 什么是车载智能计算平台？

车载智能计算平台是实现高阶自动驾驶的必选方案。自动驾驶过程中需要一个强劲的“大脑”来统一实时 分析、处理海量的数据与进行复杂的逻辑运算，对计算能力的要求非常高。计算平台本质也是嵌入式系统，相 比于汽车传统控制器 ECU（比如：发动机 ECU、变速器 TCU、车身 BCM、电池 BMS、电机 MCU、整车 VCU）， 其硬件和软件的复杂度更高，算力更高，功能更强。 硬件方面，汽车传统 ECU 主要采用 MCU（微控制单元，Microcontroller Unit）实现简单的计算和逻辑判断。 智能计算平台通常使用单个甚至多个集成 CPU、GPU、FPGA 或 AISC 的 SoC，可实现大量数据的并行计算和 复杂的逻辑功能。 软件方面，传统 ECU 软件架构较为简单，底层操作系统 OSEK，中间件采用 CP AUTOSAR 框架，顶层为 应用程序。部分功能简单的控制器甚至不需要使用操作系统和中间件。智能计算平台软件架构更复杂，层次更 多，自下而上包括虚拟机、操作系统（支持多类实时与非实时操作系统）、中间件、功能软件和应用软件。

1.2.1 车载智能计算平台架构

计算平台的功能实现需要丰富的硬件资源和复杂的软件支持。不同硬件资源的集成形成计算平台的硬件架 构，将复杂的软件分层化处理构成了计算平台的软件架构。

硬件架构：片内引入专用计算单元、板上集成多 SoC 自动驾驶中央计算平台的结构通常包括电路 PCB 板、散热部件和外壳。电路 PCB 板是计算平台是功能实 现的核心，即是通常所称的计算平台“硬件”。中央计算平台硬件架构可分为三层： 板级：即 PCB 板，其上集成了 SoC、I/O 接口、内存、电源模块以及其他电子器件。更高阶的自动驾驶功 能对计算平台的算力要求越来越高，考虑冗余的功能安全要求，单 SoC 设计已经无法满足要求，计算平台需要 集成多个主 SoC。 片级：即系统级芯片（SoC），主控芯片上集成了多个和多类计算单元。在传统 PC 时代，各个核心芯片都 是以独立的方式存在，比如英特尔和 AMD 的 CPU、NVIDIA 的 GPU 等。到了移动互联网时代，由于体积功耗 方面的要求，主芯片集成度大幅提升，除了 CPU 和 GPU，通常还包含了音频、多媒体、显示、安全、通信、 AI 计算等子单元。高度集成的 SoC 自然成为自动驾驶计算平台的首选。 核级：即芯片的计算单元，如 CPU、GPU、FPGA、ASIC 等。不同种类的计算单元有各自的优势，分别负 责不同任务。CPU 通用性最强，主要负责复杂逻辑运算；GPU 通用性不如 CPU，但计算能力高，适合同时处理 大量的简单计算任务，如运行深度学习算法；FPGA 和 ASIC 是专用型计算单元，针对某类运算定制，以达到最 优的性能和功耗比。这类计算单元主要用来运行如神经网络等 AI 算法。

系统软件：承上启下，实现应用软件与物理硬件分离。系统软件自下向上分为三层。 1） 虚拟机（Hypervisor）：通过将虚拟化将物理硬件隐藏，实现多个操作系统共享一个芯片； 2） 操作系统内核：即狭义操作系统（如 OSEK OS、QNX、Linux）。内核提供操作系统最基本的功能， 负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的稳定性和性能； 3） 中间件：处于功能应用和操作系统之间，提供标准接口、协议，保证上层软件具有较高的移植性。 功能软件：为自动驾驶功能提供共性功能模块。其可进一步分成两层，下层为实现自动驾驶的基础模块（如 基础算法、功能安全、通信存储等），上层为自动驾驶子功能模块（如感知、定位、预测等）。 应用程序：实现具体的自动驾驶功能。开发者根据自身产品功能定义，利用功能软件层提供的基础库，设 计出具体的应用功能，比如低等级的 ADAS 辅助驾驶功能（AEB、ACC 等）、较高等级的自动驾驶功能（APA、 TJP、HWP 等）、甚至 L4 以上的自动驾驶功能。

1.2.2 车载智能计算平台怎样实现功能

车载智能计算平台开发流程

计算平台软件开发依赖大量数据验证，实现高级别的自动驾驶功能需要长期的开发周期。厂商通常为计算 平台预埋充足的硬件资源，逐步完善和解锁性能更优的功能。OTA（尤其是 FOTA）使计算平台软件迭代更新 成为可能。车载计算平台算法开发和升级通常包含以下几个步骤： 1） 数据采集。利用具有自动驾驶能力或者数据采集能力的车（要求包含 GPS、惯导、摄像头、毫米波雷 达、激光雷达等所有传感器，底盘动力为线控系统，车上有数据采集控制器），实时采集车辆看到的 各种场景，以及对应场景下车辆运行的状态。 2） 构建场景样例。将采集的数据上传到云端数据中心，数据中心端依靠人力或全自动化清洗和标注数据， 形成大量的场景。 3） 算法训练。将大量场景样例输入初始算法模型，不断调整模型参数使模型输出与目标一致。 4） 仿真验证。将训练好的模型和其他的软件算法集成，在云端的仿真器平台做模拟的仿真，验证软件算 法的准确性和可靠性。 5） 实车路测。将软件算法刷写进车载计算平台，进行实际路测。在实测中发现问题，针对性的采集特定 区域的数据，再完成算法训练优化，在进行仿真和实测。 6） OTA 更新计算平台。车辆销售后，厂商根据实际道路的数据和用户反馈，对软件算法进行升级，通过 OTA 更新用户车载计算平台软件。

车载智能计算平台工作过程 车载智能计算平台的职责是完成感知环节的识别融合任务以及整个决策环节。 1） 识别融合：摄像头、激光雷达等传感器实时采集路况信息，通过以太网传输至车载中央计算平台，感 知模块根据输入图像信息调用一系列基础算法模块对信号进行滤波、识别。这类算法程序利用中间层 提供的统一接口访问操作系统。操作系统在经过虚拟机调用 SOC 中的 GPU 或 FPGA 或 ASIC 相关资源 完成的数据处理。 2） 决策：感知模块完成处理将结果数据通过中间层传递给决策模块。同样，决策模块调用基础算法模块， 层层经过中间层、操作系统和虚拟机调用 CPU 等硬件资源完成复杂计算。决策结果即目标路径、车速 等信息再经过以太网从中央计算平台传递至底盘、动力域控制器。

1.3 车载智能计算平台供应生态

车载智能计算平台主要有三大类参与者：整车厂商、传统汽车零部件商、硬件厂商。另外还有算法方案解 决商、Robotaxi 厂商、专业系统软件商等。

1） 整车厂商：定义和开发自动驾驶功能应用。整车厂商根据市场需求和产品定位，设计自动驾驶功能。 大部分整车厂商主要关注车载智能计算平台应用软件的开发。各家整车厂商自动驾驶技术水平差异显 著。特斯拉是自动驾驶汽车的领导者，研发能力覆盖应用软件、功能软件甚至底层系统软件，同时能 够根据自身算法需求自研专用 AI 芯片。为打造差异竞争，造车新势力较传统厂商在汽车智能化领域布 局节奏更快。小鹏汽车软件自研能力强，包括视觉感知、激光雷达感知、高精度定位规划等算法已经 实现全栈自研。蔚来汽车和理想汽车也搭建了强大的自动驾驶研发团队。传统整车厂商部件节奏较慢， 主要依赖供应商提供解决方案。比如吉利汽车极氪 001 采用 Mobileye 的软硬件方案，北汽蓝谷采用华 为的软硬件方案，上汽知己算法开发由 Momenta 提供支持。未来，整车厂商首先立足应用层软件开发， 进而向下延申提升功能算法、系统软件架构的自研能力，甚至设计部分专用芯片，达到软硬一体化设 计能力。

2） 传统零部件 Tier1：布局中间件为主。在传统汽车控制器中，如大陆、博世等零部件商为整车厂商提供 硬件（向芯片商采购）和软件平台（基于 CP AUTOSAR 的操作系统和中间件），支持整车厂商应用开 发。对于车载智能计算平台，汽车零部件厂商继续发挥车规级开发能力的优势，为计算平台提供满足 车规要求的中间件。未来，汽车零部件商将向上层功能软件和应用解决方案布局，同时向下部件操作 系统甚至硬件层。

3） 硬件厂商：为计算平台提供各类芯片。传统汽车控制器采用 MCU，主要芯片供应商是英飞凌、IT 和 NXP。他们在汽车芯片领域深耕，为博世、大陆提供芯片用于开发 ECU。自动驾驶对硬件算力要求更 高，GPU 以及 FPGA、ASIC 等高性能专用芯片开始应用到汽车。如英伟达、高通、英特尔等消费产品 芯片供应商进入汽车供应链。基于高壁垒的芯片及配套系统软件，实力强的芯片商将能力圈向应用层 拓展。如 Mobileye、华为可提供软硬件的全套解决方案。

二、硬件结构：集成化是趋势，开放性是核心

2.1 核级：硬件最底层，自动驾驶促进专用性提升

2.1.1 是什么：硬件层面底层架构

L2 以上自动驾驶需要处理雷达及相机等传感器输入的数据，数据量指数级增长，因此需要基于深度学习的 AI 算法实现数据处理能力的飞跃。传统 ADAS 层面处理器计算单元 CPU 已无法满足 AI 算法需求，目前已开发 多种架构计算单元，主要分为通用型（CPU、GPU）和专用型（FPGA、ASIC）两大类。

通用芯片：CPU、GPU

CPU（Central Processing Unit，中央处理器）：计算机系统的运算和控制核心，是信息处理、程序运行的 最终执行单元。优点：CPU 有大量的缓存和复杂的逻辑控制单元，非常擅长逻辑控制、串行的运算。缺点：不 擅长复杂算法运算和处理并行重复的操作。类比来看，CPU 就像是教授，复杂问题都可以解决，但是让他做 100 道小学算术题也需要一定时间。 GPU（Graphics Processing Unit，图像处理器）：也称显示核心，是一种做图像和图形相关运算工作的微 处理器。优点：核心数非常多，可以支撑大量数据的多核并行计算。缺点：管理控制能力弱，功耗高。类比来 看，GPU 就像 100 个小学生，虽然复杂问题无法解决，但是同时做 100 道小学算术题却可以很快完成。

专用芯片：FPGA、ASIC

FPGA（Field Programmable Gate Array，现场可编程逻辑门阵列）：是一个可编程芯片，用户可以自定 义芯片内部的电路连接来实现特定功能，常用于算法训练优化。优点：可以无限次编程，延时性比较低，实时 性最强，灵活性最高。缺点：开发难度大、价格比较昂贵。 ASIC（Application Specific Integrated Circuit，特殊应用集成电路）：ASIC 已经制作完成并且只搭载一种 算法和形成一种用途，一旦设定制造完成，内部电路以及算法就无法改变。优点：体积小，功耗低，性能以及 效率高，量产成本非常低。缺点：首次“开模”成本高，灵活性不足。代表性神经网络处理器包括谷歌公司研 发的张量处理器（Tensor Processing Unit, TPU），以及特斯拉自研的神经网络处理器（Neural Network Processing Unit，NPU）等。

从计算能力、通信延迟、成本三个核心维度对四种架构进行比较： 计算能力：ASIC> FPGA >GPU > CPU。CPU 和 GPU 作为通用芯片，适用范围较广，由于 GPU 集成大量 内核，因此并行计算能力高 CPU 近百倍。但是通用芯片势必会造成过程冗余，导致 AI 算力浪费，因此算力显 著低于专用芯片。专用芯片包含 ASIC 和 FPGA，其中 ASIC 专用性更强，针对单一算法和功能优化最佳，因此 算力强于 FPGA。 通信延迟：ASIC≈ FPGA FPGA >GPU ≈ CPU。专用芯片开发语言难度 大，适用性较差，因此开发成本高于通用芯片。其中 ASIC 由于无法编程，对算法以及硬件的封装程度更高， 因此开发成本高于 FPGA。量产成本：FPGA >ASIC> GPU ≈ CPU。由于 ASIC 是一次封装完成的芯片，后续量 产标准化程度高，量产成本很容易下降，而 FPGA 每一片都要进行调试，因此量产成本 ASIC 占优。

2.1.2 趋势：由通用走向专用

自动驾驶芯片架构的技术发展趋势主要考虑以下四个维度： 第一点，算力要求高。由于处理的传感器信息需要大量冗余，对终端算力要求极高，并且车速越快，对计 算能力要求越高； 第二点，终端计算的实时性要求极高。任何超出一定范围的延迟，都有可能造成事故，因此终端会负责自动驾驶的核心计算和决策功能； 第三点，能效要求高。否则降低车辆续航，影响驾驶体验。高能耗同时带来的热量也会降低系统稳定性。 例如支持 L4 的 NVIDIA Drive Pegasus 功耗为 460W，只能应用于小规模的测试车； 第四点，可靠性要求高。真正满足车规的自动驾驶芯片需要在严寒酷暑、刮风下雨或长时间运行等恶劣条 件下，都有稳定的计算表现。

目前自动驾驶硬件架构方案主要为 GPU FPGA 异构。GPU 适用于单一指令的并行计算，主要负责并行处 理数据；FPGA 与之相反，适用于多指令、单数据流，主要负责训练优化算法。当前阶段还处于算法快速迭代 时期，需要依托 FPGA 可编程性，进行开发过程不断试错。因此结合两者优势，形成当下主流 GPU FPGA 的异 构解决方案。 未来自动驾驶芯片的核心架构是 ASIC。当前阶段 FPGA 的优势是算法快速迭代背景下开发的便利性，当 自动驾驶汽车量产，形成了较为稳定的算法后，ASIC 的量产低成本、性能高、功耗低等优势就可以体现。类比 来看，FPGA 就是乐高搭建模型，可以低成本快速测试性能，而 ASIC 是开模具，虽然首次开模成本高，但是后 续量产成本低且性能更好。因此，我们认为短期内还是会以 GPU FPGA 异构为主，量产后会逐渐向 ASIC 迁移。

2.1.3 格局：GPU、FPGA 寡头垄断，ASIC 仍是蓝海

总体来看，传统 CPU 行业龙头是英特尔和高通，GPU 行业龙头是英伟达，FPGA 行业龙头赛灵思，只有 ASIC 领域暂未形成明显的龙头。

2.1.3.1 GPU

全球 GPU 市场已经进入了寡头垄断的格局。在传统 GPU 市场中，排名前三的英伟达、AMD、英特尔的营 收几乎可以代表整个 GPU 行业收入。其中，2019 年英伟达的收入占 56%、AMD 占 26%、英特尔占 18%，英伟 达占据绝对的行业垄断地位。

2.1.3.2 FPGA

目前的 FPGA 市场由海外巨头赛灵思和 Altera 主导，两者共同占有 80%的市场份额。2015 年 Intel 决定以 167 亿美元收购 FPGA 生产商 Altera，IBM 也和赛灵思联合宣布开展一项多年战略协作，打造更高性能的数据 中心应用，IT 大厂的介入也说明了 FPGA 在 AI 领域的重要地位。 国产 FPGA 起步较晚，技术水平落后 2-3 代。FPGA 细分领域具有技术壁垒高、资金投入大的特点，国外 头部企业历经多年发展形成了技术和专利方面的高壁垒，造成国内企业发展受限，目前只能从低端产品切入， 通过技术升级不断向高端产品演化。因此，部分厂商弱化芯片制造业务，主攻深度学习算法解决方案，为 FPGA 提供更优化的算法结构，提升芯片性能，代表公司深鉴科技 2018 年以 3 亿美金的价格被赛灵思收购。

2.1.3.3 ASIC

目前国外主要以谷歌为主导，国内主要是寒武纪。人工智能领域的 ASIC 专用芯片仍是一片蓝海，尚未出 现足以垄断市场的巨头公司。 在 ASIC 芯片领域，国内厂商已经取得了一定成绩。以比特大陆、嘉楠耘智为代表的矿机厂商采用的 ASIC 芯片已经达到了 7nm 制程，在国际中处于较先进地位。寒武纪科技推出的寒武纪 1A 处理器（Cambricon-1A） 是世界首款商用深度学习专用处理器，面向智能手机、安防监控、可穿戴设备、无人机和智能驾驶等各类终端 设备，在运行主流智能算法时性能功耗比全面超越 CPU 和 GPU。

2.2 片级：系统级芯片，集成化趋势显著

2.2.1 是什么：片上芯片，多个计算单元的集合

定义：系统级芯片（System on Chip, SoC）是指多个计算单元集成到一块芯片上，从而实现功能集成的设 计方案。传统汽车芯片为微控制器（Micro Control Unit, MCU），又称单片机，简单来说是就是将简化版 CPU 与功能部件集成在一个芯片上，形成“芯片级芯片”，通常只能完成单一信号控制，实现单一功能。随着自动 驾驶级别提升，需要实现的功能增多，计算能力要求更高，MCU 已不满足需求，因此将多个计算单元集成到一 块芯片上形成“系统级芯片”。

结构：SoC=n1*CPU n2*GPU n3*FPGA n4*ASIC 其他功能单元（ISP、VP 等）。以英伟达 Xavier 为例 对 SoC 架构进行说明。通常 SoC 会集成计算单元和功能单元两部分，计算单元包含通用芯片 CPU 和 GPU，总 计占据约 1/2 的面积，部分计算单元包含专用芯片 FPGA 和 ASIC，面积占比约为 1/20。功能单元主要包含数据 存储和数据预处理两部分，其中数据存储和调用主要通过内存实现，内存就像局部地区建立的一个仓库；数据 预处理包含用于图像信号预处理的 ISP 芯片、视频解码器 VP 等器件。

2.2.2 趋势：集成化、高算力、先进制程、开放化

自动驾驶芯片是硬件部分核心，也是自动驾驶方案竞争的制高点，目前技术快速迭代背景下存在三点趋势： 第一点，集成化，MCU 加速走向 SoC。伴随整车电子 E/E 架构集中度提升（分布式→域集中式→中央集 中式），起决策作用的单元由 ECU→DCU→中央计算平台，ECU 数量大幅精简，因此其内含 MCU 芯片数量下 降，加速 MCU 向集成度更高的 SoC 升级。

第二点，高算力，同时兼顾算力功耗比。硬件层面，提升单车智能化程度、实现高级别自动驾驶的核心是 提升系统级芯片算力，因此提升芯片算力仍然是厂商研发考虑的第一要素。目前阶段，芯片算力可类比智能手 机发展过程的相机像素，虽然拍照效果受算法、相机像素、传感器等多方面因素影响，但是像素提升带给消费 者的感知最强烈，消费者也更愿意支付高像素带来的溢价。同理，自动驾驶芯片算力也具有类似的消费属性， 因此短期来看，厂商势必会通过提高芯片算力来抢占市场高点。

第三点，先进制程，5nm/7nm 是未来趋势。晶体管是芯片的最小组成单元，可以把晶体管比作水池，水流 从源极流入漏极，栅极就相当于两个水池之间的水管，栅极的最小宽度（栅长）就是制程。水管越短，水流越 快完成水池间运输，水流在水管内的摩擦损耗越小。制程类比水管长度，越宽电流通过时的损耗越大，外部表 现就是器件发热和功耗增大。因此制程减小是技术发展趋势。

第四点，开放化，OEM 对功能拓展性的需求促进了芯片开放化趋势。主机厂需要在硬件基础上进行功能 开发，因此底层芯片开放性越高，越有利于主机厂进行功能拓展。在这背景下，自研能力较强的主机厂（如特 斯拉）选择了自研芯片，实现了底层完全开放；而像英伟达等厂商推出的芯片开放性也不断增强，供主机厂修 改部分不断扩充，因此得到更多主机厂青睐；相反的，开放性较差的厂商（Mobileye、地平线）则逐渐被主机 厂抛弃，只能在完全没有自研意愿的主机厂中寻求剩余机会。

2.2.3 格局：L2 以上自动驾驶消费电子领域巨头弯道超车

四类核心玩家：传统汽车芯片厂商（瑞萨、Mobileye 等）、消费电子芯片厂商（英伟达、高通等）、研发 能力较强的主机厂（特斯拉）及科技公司（华为、地平线、黑芝麻）。传统汽车芯片厂商具备汽车产业链优势， 但是芯片功能相对单一，采取基于 ADAS 不断补充功能实现更高级别自动驾驶的“自下而上”的策略；随着 L2 高级别自动驾驶逐渐落地，传统单一功能汽车芯片已无法满足要求，具备较强 AI 计算优势的消费电子芯片厂商 快速切入，凭借“自上而下”的策略实现弯道超车。此外，具备较强研发能力的主机厂（特斯拉）及部分科技 公司（华为、地平线、黑芝麻）也是主要玩家。

各厂商能力：第一梯队是芯片巨头英伟达和高通，一流芯片算力基本在 100TOPS 以上，算力功耗比 3.0 以 上。英伟达新一代 Orin 单芯片算力 254TOPS，相比其他厂商普遍高 4-10 倍。具体来看，英伟达相对高通功耗 控制较差，算力功耗比相对偏低。第二梯队是特斯拉和黑芝麻，与第一梯队芯片工艺能力还有较大差距，单芯 片算力 70TOPS 左右。第三梯队是 Mobileye 和地平线，单芯片算力普遍比较低（25TOPS 以下），仅能实现 L2 及以下功能。华为相对特殊，昇腾 910 芯片算力高达 640TOPS，功耗 310W，虽然单纯算力达到世界顶尖水平， 但是整体能效控制较差，算力功耗比仅为 2.1。总体来看，芯片目前处于技术快速迭代期，算力不断提升，厂商 纷纷加入算力游戏，开展高算力芯片军备竞赛。

2.2.3.1 英伟达：起步早、势头猛、布局快

起步早：入局已有六年之久，保持两年更新频率。智能驾驶领域英伟达前后已推出 4 代芯片（其他厂商普 遍 1-2 代），2015 年最早推出 Parker 芯片，面向 ADAS 应用，不具备深度学习功能。2017 年推出首款自动驾驶 AI 芯片 Xavier，可以满足 L2/3 级应用，2019 年推出高算力芯片 Orin，满足 L4/5 级应用。计划 2021 年推出下 一代超高算力芯片 Atlan。

具体历代 AI 芯片来看，英伟达均采用 CPU GPU ASIC 的技术路线。Xavier 芯片除集成 GPU、CPU、ISP 等标准组件外，创新集成 DLA。DLA 是 ASIC 架构专用引擎，可以高效处理深度学习算法，使单芯片算力由 20TOPS提升至30TOPS。DLA面积仅为GPU的1/8，然而贡献算力是GPU的1/2（DLA=10TOPS，GPU=20TOPS）， 因此 DLA 可以大幅提升芯片算力功耗比，也印证了 ASIC 架构的优越性。Xavier 芯片参数：三星 12nm 工艺， 算力 30TOPS，功耗 30W，算力功耗比 1.0。Orin 架构与 Xavier 基本相同，采用三星 8nm 工艺，算力 254TOPS， 功耗 65W，算力功耗比 3.9。

Atlan 是 L5 终极解决方案：2021 年 4 月 GTC 上英伟达发布下一代数据中心级别 SoC，命名为 Atlan，首次 实现单芯片算力超过 1000TOPS，面向 2025 年 L5 自动驾驶应用。创新点在于英伟达自研新一代 CPU（Grace）， 用于大规模人工智能和高性能计算应用，计划 2023 年投产。首次集成 DPU（Bluefield-3），实现了 10 倍的性 能飞跃，能够替代 300 个 CPU 核，以 400Gbps 的速率，对网络流量进行保护、卸载和加速。我们认为，英伟达 宣传高算力 Atlan 更多目的是为拉对手军备竞赛，压迫对手跟进算力游戏，以此凸显自身芯片研发能力优势， Orin 还是其未来五年内主要产品。

2.2.3.2 高通：起步晚，实力强，扩展性

起步晚：由于收购恩智浦失败，高通在智能驾驶领域入局较晚。与英特尔收购 Mobileye 类似，高通也想通 过收购恩智浦切入 ADAS，从而往更高级别自动驾驶延伸。2016 年 10 月，高通宣布收购恩智浦，收购价为 470 亿美元。2018 年 7 月，由于政策原因，高通宣布放弃收购恩智浦。本次收购失败严重拖累了高通在自动驾驶领 域的布局，直接导致高通入局相对英伟达晚了三年，目前也仅发布了一代芯片。

扩展性：依托智能座舱同源性向自动驾驶扩展。高通在智能座舱领域一骑绝尘，市场份额高达 70%，国外 最紧密合作者是美国通用，国内是长城 WEY。智能座舱芯片是前哨战，自动驾驶芯片才是制高点，由于智能座 舱和自动驾驶同源性较强，厂商为降低开发费用和周期，会选用适配性较好的同一架构芯片，因此高通可以凭 借智能座舱领域优势快速向自动驾驶扩展。代表案例：长城 WEY“咖啡智能”平台已采用高通自动驾驶芯片。 优劣势分析：高通优势在于强大的生产制造能力，凭借多年智能手机芯片霸主地位以及智能座舱领域垄断 优势，对于量产落地的功耗控制能力较强，维持高算力的同时算力功耗比通常在 4 以上；同时，高通已布置了 非常多的芯片产线，可以通过多产线去摊薄研发成本，进一步取得自动驾驶芯片成本优势。劣势主要还是入场 太晚，在近两年各厂商“跑马圈地”的情况下，没有形成大规模的客户群体。

2.2.3.3 特斯拉：逐步自研，软带动硬

逐步自研：自研新一代 FSD3.0 自动驾驶 SoC。特斯拉一直以来都是自动驾驶领域的领路人，软件部分视 觉算法能力全球领先。硬件部分，早期特斯拉基于 Mobileye EyeQ4 芯片实现 ADAS 级别应用，2015 年后转用 英伟达 Xavier 芯片开发 L2 级别自动驾驶，然而外采方案下芯片核心架构在芯片厂商手中，特斯拉自主开发受 限，难以实现软硬件充分适配，因此特斯拉决定自研芯片 SoC，并计划于 2021 年推出最新一代 FSD3.0。 FSD3.0 采用了 CPU GPU ASIC 架构。FSD3.0 中特斯拉核心自研部分是 NPU，NPU 是 ASIC 架构的处理 器，适用于进行深度学习计算。NPU 中间的核心组件是乘加累计器（Multiply Accumulate Cell, MAC），可以提 供 9216（96*96）个计算单元，每个单元可以完成 8 位的乘积运算和 32 位的加法运算，所以一个时钟周期可以 完成 9216*2=18432 次的 int8 的操作， NPU 的频率是 2GHz，其运算能力 2GHz*18432/1000=36.86TOPs(int8)。 自研芯片采用三星 14nm 工艺，总体表现为算力 72TOPS，功耗 36W，算力功耗比 2.0。

2.2.3.4 Mobileye：起点高，进步慢，被替换

起点高：Mobileye 是 ADAS 芯片绝对龙头。Mobileye 的 EyeQ 系列芯片在 2004 年就开始研发，2007 年 发布的第一代 EyeQ1 芯片是较早应用于自动驾驶的 AI 芯片之一（仅实现辅助驾驶功能）。目前 ADAS 领域 年出货量近 2000 万颗芯片，市占率高达 60%。

进步慢：Mobileye 业务模式是向 OEM 提供定制化 ADAS 和自动驾驶方案，然而 2015 年，Mobileye 发布了 一款新的芯片 EyeQ4，该芯片建立在多核架构的基础上，用于在 ADAS 中进行计算机视觉处理。区别于主流 CPU 架构（ARM、X86），EyeQ4 采用了小众的多 MIPS 处理器，导致其通用性和可开发性较差。EyeQ4 算力 2.5 TOPS， 功耗仅 3W，相比 EyeQ3 算力提升近 10 倍，功耗仅增加 0.5W，说明 Mobileye 优势在于功耗控制，但是整体算 力还是偏低。

优劣势分析：优势在于成本低，全栈黑盒子方案降低 OEM 研发开销；此外，算法与芯片都是自主研发， 适配性好，芯片开发度高。总体来看和特斯拉特点很像，Mobileye 就像不造车的特斯拉，但是硬件能力比特斯 拉强。劣势在于全栈黑盒可开发性较差，无法满足有自研需求的 OEM；同时，MIPS 架构 CPU 通用性较差，难 以形成良好的软件生态。

2.2.3.5 华为：起步晚、布局广、受制裁

起步晚：华为 2018 年才发布第一款 AI 处理器昇腾 310，算力 16 TOPS，功耗 8W，算力功耗比达 2.0。 昇腾 910 是目前单芯片算力最强的一款芯片，它是一款面向服务器的 AI 芯片，对标英伟达、谷歌同类产品， 算力高达 640 TOPS，功耗为 310W，能效比达 2.1。

昇腾 310 与 910 都采用了达芬奇架构。不同于传统的支持通用计算的 CPU 和 GPU，也不同于专用于某种 特定算法的专用芯片 ASIC，达芬奇架构本质上是为了适应某个特定领域中的常见的应用和算法，通常称之为“特 定域架构”。具体来说，达芬奇架构采用 3D Cube 针对矩阵运算做加速，每个 AI Core 可以在一个时钟周期内 实现 4096 个 MAC 操作，相比传统的 CPU 和 GPU 实现数量级的提升，从而大幅提升单位功耗下的 AI 算力。 同时，达芬奇架构还集成了向量、标量、硬件加速器等多种计算单元，同时支持多种精度计算，能够实现云、 到边缘、到端、到物联网端的全场景覆盖。最后，达芬奇架构具有统一性，在面对云端、边缘侧、端侧等全场 景应用开发时，只需要进行一次算子开发和调试，就可以应用于包括麒麟芯片在内的不同平台，大幅降低了迁 移成本。

基于昇腾 910，华为开发了：1）Atlas 800 训练服务器，具有最强算力密度、超高能效与高速网络带宽等特 点，可以广泛应用于深度学习模型开发和训练，适用于智慧城市、智慧医疗、天文探索、石油勘探等需要大算 力的行业领域。2）Atlas 900 AI 集群，由数千颗昇腾 910 组成，总算力达到 256P～1024P FLOPS @FP16，相当 于 50 万台 PC 的计算能力，可以让人类更高效的探索宇宙奥秘、预测天气、勘探石油，加速自动驾驶的商用进 程。 昇腾芯片因其独特的达芬奇架构，可以在云、到边缘、到端、到物联网端等实现全场景覆盖，不仅仅是在 车端，在智慧城市、交通、金融、能源、园区管理等领域昇腾芯片都可以提供服务，这意味着华为可以凭借其 庞大的客户群体摊薄研发费用。

受制裁：由于受到美国制裁，华为最大的问题就是供应链安全，短期内可以依靠他们已经囤积的一些芯片 去支撑，等消耗完库存后，会被迫切换到 28 nm 工艺，这种在能效比上会很差。所以长期来看，如果国内先进 芯片生产、先进材料，EDA 软件上不来，美国短期内又不会解除对他的制裁，那么华为发展高阶高算力的自动 驾驶就存在很大的困难。 优劣势分析。优势：1）成本低，降低 OEM 研发开销；2）除了 ARM CPU 可能要买 ARM 公司的授权之外， 其它几种硬件引擎都可以自研，研发能力很强；3）在云、边缘、端、物联网端都有布局，业界布局最广。劣势： 1）芯片能效相比高通英伟达还有一定差距；2）受制裁，芯片生产可能受限。

2.2.3.6 黑芝麻：能效高、潜力强

能效高：黑芝麻目前主要有三款芯片，A500、A1000L、A1000，在芯片能效比上黑芝麻达到了世界顶级水 准。华山一号 A500 在 2019 年 8 月发布，算力 5-10 TOPS，功耗 2W，使用台积电 28nm 工艺。A500 内部的 ISP、 视觉处理加速引擎、Ultra DL AI 加速引擎等内核均为黑芝麻自主设计，而像 CPU、部分 DSP 等内核则使用了供 应商的 IP。华山二号 A1000 在 2020 年 6 月发布，算力 40–70 TOPS，相应功耗为 8 W，能效比超过 6 TOPS/W。 A1000 内置了 8 颗 CPU 核心，包含 DSP 数字信号处理和硬件加速器，使用台积电 16nm 工艺。

目前黑芝麻在与中国一汽合作落地 A1000，与上汽合作落地 A500。 优劣势：专注于 SoC 芯片研发，芯片能力较强，但与高通、英伟达、华为没法比，在国内自动驾驶芯片上 仅次于华为，但是与 Tier1、OEM 的合作不足。2021 年开始与国汽智控合作，进行计算平台与软件算法的开发， 在软件上布局很晚，能力较弱。

2.2.3.7 地平线：循序渐进、开放性

循序渐进：地平线一步一个脚印，采取循序渐进的自动驾驶产业化路线，芯片算力逐年提高的同时，能效 比也在稳步提升，这主要得益于地平线提供一整套芯片及配套软件工具链 算法方案。在 SoC 芯片方面，地平 线目前量产的主要有征程 1.0、征程 2.0 和征程 3.0。

开放性：自研视觉算法 AI 开源工具链，赋能车厂 ADAS 能力。地平线一直面向深度学习这种新一代 AI 技术，相对没什么包袱，能更加开放。征程二代芯片可以支持车企开发 ADAS，前向视觉感知计算可以支持很 多差异化功能，如车辆、行人、车道线检测、测距测速等，车企也可以把芯片用于汽车座舱的智能交互，如语 音识别、眼球追踪。此外，地平线提供工具链和算法参考模型，从而车企可以自由定义产品。 地平线在自动驾驶领域的布局相当广泛。地平线 J2 已经搭载在长安汽车 UNI-T、上汽智己、奇瑞新能源蚂 蚁上，J3 搭载在赢彻科技自动驾驶卡车上，同时与广汽合作开发广汽版 J3。与大陆集团在 ADAS 和高等级自动 驾驶领域深度合作，与豪威、斑马智行等合作布局智能座舱领域，与易图通合作布局众包高精度地图领域，与 大唐移动在 5G AI 面向车路协同智能网联展开合作。 总地来看，劣势：SoC 芯片算力较差；优势：开放的商业模式，软件能力很强，AI 算法能力一流，自动驾 驶领域布局广泛，与 Tier1、OEM 的合作广泛。

2.3 板级：域控制器，当前域融合，未来中央化

2.3.1 是什么：硬件层面总体单元

定义：域控制器是自动驾驶计算平台硬件层面的总体单元。域控制器（Domain Control Unit, DCU）的概念 最早是由以博世、大陆、德尔福为首的 Tier1 提出，为解决信息安全以及 ECU 瓶颈问题。根据汽车电子部件功 能将整车划分为动力总成，车辆安全，车身电子，智能座舱和智能驾驶等不同域，利用处理能力更强的多核 CPU/GPU 芯片相对集中的去控制每个域，以取代目前的分布式汽车电子电气架构（EEA），形成域集中式架构。 结构：DCU=n*SoC 接口 内存。从现有控制器硬件架构看多颗/多核芯片以及冗余架构是域控制器设计主 流设计，核心包括 SoC、I/O 接口以及内存。其中 SoC 主要负责提供决策，数量根据功能而定；I/O 接口主要负 责输入多传感器感知信息，比如摄像头、毫米波雷达、激光雷达等，通过后融合模式将感知信息直接输入域控 制器，以及将控制信号输出给相应执行器件；内存主要负责提供数据暂时存储、传输等功能。

2.3.2 趋势：域集中向域融合转化

汽车电子电气架构由分布式向域集中式转化： 目前，主机厂正在应用第一类分布式 E/E 架构，分为模块化和集成化两个阶段。模块化阶段：每个功能具 备独立 ECU；集成化阶段：架构设计趋向功能集成，多个 ECU 之间进行融合。 之后，主机厂将采用第二类域集中式 E/E 架构，分为集中化和域融合两个阶段。集中化阶段：开始出现域 控制器 DCU，实现部分功能集成，融合部分 ECU；域融合阶段：开始出现跨域中心控制器 MDC，特斯拉 Model 3 是代表车型。 未来，主机厂将采用第三类中央集中式 E/E 架构，分为车载计算平台和车-云计算两个阶段。车载计算平台 阶段：采用的是车载平台和区域导向架构；车-云阶段：车辆的决策阶段在云端完成。

MDC 优势：1）能够将感知与决策分开，传感器与 ECU 不再是一一对应的关系。对于 OEM，有 MDC 之 后，可以随意更换传感器的供货商。2）MDC 平台本身的可扩展性，MDC 所能够对接的传感器类型与数目并不 固定，可以根据 OEM 的需求对应开发。

2.3.3 格局：芯片厂向上拓展，主机厂向下挤压

三类主要玩家：芯片厂、传统 Tier1、主机厂。 第一类，芯片厂。由于域控制器的核心部件是 SoC，因此主要芯片厂商依靠芯片制造能力向域控制器拓展，通过收购、合作等方式快速切入 DCU 赛道，通常是同期推出新一代 SoC 与相应域控制器。代表公司包括英伟 达、高通、Mobileye、华为、地平线等。 第二类，传统 Tier1。传统汽车半导体行业中，芯片厂商扮演的是 Tier2 的角色，通常需要 Tier1 对芯片进 行进一步开发，以实现主机厂具体车型的适配。自动驾驶阶段，该模式依然在延续，代表公司包括：德赛西威、 德尔福、采埃孚等。 第三类，主机厂。主机厂外采域控制器存在算力开发不足、功能实现有限的问题，因此，主机厂希望通过 自研硬件，打通软硬件壁垒，实现数据闭环和全栈开发。代表公司包括特斯拉等。

格局变动驱动力：域控制器架构。早期 ADAS 功能相对单一，因此厂家会选择一个传感器（雷达或摄像头） 作为主控制器，接收另一个传感器的数据进行统一计算。2015 年英伟达为特斯拉推出了 Drive PX 系列自动驾驶 DCU，结合深度学习技术打造 L2 自动驾驶。为了适配深度学习算法，特斯拉进行了硬件架构革新，从雷达、 摄像头分别计算并融合（前融合），跨入到自动驾驶域控制器（后融合）。特斯拉基于英伟达的 Drive PX 芯片 研发了自动驾驶域控制器，早期仍然选用 Mobileye 感知系统，但同时额外安装了自己的摄像头来收集道路数据。 工作时，感知系统会将感知结果输出到特斯拉的域控制器中，域控制器对感知结果进行融合计算，给出决策。 这一步里，特斯拉相当于将感知部分交给供应商来做，自己完成最后的决策算法。目前宝马、通用、福特等大 型车企也都采用该方案。

各厂商能力：高通、英伟达都采取高中低配去打 L2-L5 市场，策略很相近。以英伟达 Orin 平台为例：L2 及以下通过单个 Orin 实现，L3 通过 2 个 Orin，L4-L5 通过 2Orin 2GPU。华为、特斯拉、黑芝麻目前都是双芯 片平台，通常瞄准 L3 级别应用场景。蔚来 ADAM 平台采用 4Orin 芯片堆料的策略，表观算力很高，但是算法 优化技术上难以跟进，芯片性能很难完全发挥，造成算力和功耗的浪费。总体来看，高级别自动驾驶域控制器 方案尚不明确，技术上以兼具高算力和低功耗的芯片和 GPU 的搭配使用为主。

2.3.3.1 英伟达

凭借 GPU 垄断优势，英伟达布局智能驾驶领域较早。2017 年推出的 Drive PX Xavier 和 Drive PX Pegasus平台，分别采用 1 个 Xavier 芯片和 2Xavier 2GPU 配置，算力分别达到 30TOPS 和 320TOPS，适用于 L2-L4； 2019 年推出的 Drive AGX Orin 平台算力高达 2000TOPS，主要面向 L5 级别自动驾驶。

Drive PX Pegasus 可用于 L5 级自动驾驶：2017 年 10 月公布的 Drive PX Pegasus 平台可用于无方向盘、无刹 车踏板、无司机的 robo-bus 或 robo-taxi 之上。性能：2Xavier 2GPU，320TOPS，500W。劣势：功耗过高，算 力功耗比仅为 0.6。 Drive AGX Orin 是下一代域控制器：DRIVE AGX Orin 是一个软件定义的平台，旨在实现从 l2-l5 全自动驾 驶汽车的架构兼容平台，使 OEM 能够开发大规模和复杂的软件产品系列。由于 Orin 和 Xavier 都可以通过开放 的 CUDA 和 TensorRT 进行编程，开发者可以在多代产品中利用他们的投资。性能参数：2Orin 2GPU，2000TOPs， 700W。计划进度：2019 年 12 月发布，2021 主机厂适配，2022 量产车搭载。

2.3.3.2 高通

高通与英伟达类似采用两种芯片搭配实现三种方案： L1-L2：1 个骁龙 8540，面向主动安全功能（AEB、TSR、LKA 等），算力 30 TOPS，功耗 15 W； L2-L4：2 个骁龙 8540，面向辅助驾驶（HWA、自动泊车、TJA 等），算力 120TOPS，功耗 30W； L5：2 个骁龙 8540 2 个骁龙 9000，面向完全自动驾驶，算力 700TOPS，功耗 150W。

2.3.3.3 特斯拉

特斯拉初期集中软件层面，硬件依托芯片厂商提供，后期凭借强大研发能力开发出自研计算 FSD 平台，可 以更好适配自身车型，最大程度发挥芯片性能。特斯拉是用低成本策略，通过软件把硬件发挥到极致，不堆料。

HW1.0 版本(2015.10)：芯片 SoC 由 Mobileye（eyeQ3）提供，由于 Mobileye 黑盒子属性，可开发性较差， 因此第一代后被特斯拉弃用； HW2.0 版本(2016.10)：由英伟达（Parker）提供，配置采用 1 个 Parker 1 个 GPU，相当于是英伟达给特斯 拉的特供版，属于特斯拉采取的过渡策略； HW2.5 版本(2017.8)：由英伟达提供，采用 2 个 Parker 1 个 GPU，性能配置与英伟达 Drive PX2 一致；

2.2.3.4 蔚来

全新 NIO Adam 域控制器是目前功能最强大的平台。凭借四个 NVIDIA Orin SoC，Adam 实现了超 1000 TOPS 的性能。其中两颗主控芯片实现全栈计算，包括多方案相互校验的感知、多源组合定位、多模态预测和决策； 一颗独立的冗余备份芯片确保安全；一颗训练专用芯片满足用户个性化驾驶体验。

三、软件架构：高度分层化和模块化

3.1 虚拟机：软件最底层，使不同操作系统共用同一硬件资源

3.1.1 是什么：模拟硬件系统的计算机系统仿真器

3.1.1.1 虚拟机介绍

汽车电子电气系统中不同的 ECU 提供不同的服务，具有不同的优先级，对底层 OS 的要求也不一样。例如 汽车仪表系统与汽车的动力密切相关，它要求其具有高实时性、高可靠性和高安全性，因此主要以 QNX 操作系 统为主，而信息娱乐系统主要提供人机交互控制平台，追求多样化的应用服务，所以 Linux 和 Android 等 OS 也 能够胜任。那么如何使不同类型的 OS（操作系统）运行在同一套硬件上呢，最直接的路径就是虚拟化 （Virtualization）。 所谓的“虚拟”即使用某种方式隐藏底层物理硬件的过程，从而使多个 OS 可以共享这些硬件。而这些 Guest OS（访客操作系统）和其实现的应用功能就可以被视作一个虚拟机。虚拟机（Virtual Machine, VM）是计算机系统的仿真器，通过软件模拟具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计 算机系统，能提供物理计算机的功能。通过虚拟机 VM，多个相互隔离的、不同的系统便可以在同一硬件机器 上运行。

在传统模式下，实现某一特定功能就需要一套单独且完整的 OS 和与之对应的独立的硬件，具体到汽 车领域，就需要大量的 ECU、线束、接插件的实体成本以及多次生产、多次研发、多次测试的成本。而 Hypervisor 的工作原理是通过允许或者限制访问 CPU、内存等外部物理硬件上的资源，来定义每个 VM 可 用的功能。当一个特定的 Guest OS 开始消耗更多的资源时，Hypervisor 会把它转移到另一个需求较少的虚 拟机上。除此外，Hypervisor 可以为每个虚拟机分配不同的资源，从而将各种计算单元进行整合、算力共享， 以期达到降低成本的目的。例如，CPU 上的处理时间可以划分为多个时片，并根据需要分配给不同的虚拟机， 一个虚拟机可以访问多个 CPU 内核。类似地，存储器和其他外设硬件可以共享或分配给单个虚拟机。虚拟机 VM 无需知道或根本不知道彼此的存在，并且无法访问未提供给它们的资源。因此，Hypervisor 也被称为虚拟机 管理程序 (Virtual Machine Manager , VMM)。

在汽车领域，虚拟机技术率先在智能座舱中得到应用。座舱的智能化，就是对传统座舱所进行的数字化、 液晶化与集成化。智能座舱是由不同的座舱电子元器件组合而成的完整体系，它包括数字化全液晶仪表盘、车 载信息娱乐系统、抬头显示系统 HUD 及车联网模块等。如果是在传统模式下，如此多功能的应用势必会造成大 量硬件的堆砌和杂糅，增加造车成本。另外由于智能座舱中各个部分的安全要求不同，需要运行不同的操作系 统（比如 QNX 负责仪表、安卓负责信息娱乐系统），传统的软硬件搭配方案无法有效地将不同 OS 整合起来。

通过引入 Hypervisor 虚拟机技术，就相当于给了智能座舱一个操作系统，灵活地按照产品需求在不同的 Guest OS（VM）中分配硬件和软件资源，比如协调不同的芯片、不同芯片底层软件、不同应用层软件，让整个 架构和系统高效地工作起来，由于各个虚拟机之间的严格隔离，所以系统的冗余度较高，当一个虚拟机中的应 用程序出现故障时，只会影响分配给它的内存，而不会影响其它虚拟机。另外，对 OS 的简单修改就能使之在 多个 VM 间共享内存，新旧 VM 软件可因此共存，整个计算平台的系统灵活性和扩展性比起传统模式要好。例 如，在 Visteon 的 SmartCore 域控制器，在 Visteon 自身以及 QNX 或者 Integrity 等 Hypervisor 助力下，使得 Visteon 自家的软件堆栈与 Phoenix™和 Android 等其他类型的车载娱乐信息 OS 能够集成在一起，从而在人机交互终端能 够发挥出不同的应用功能。

3.1.2 趋势：域融合趋势下，虚拟机技术将成为必须项

Hypervisor 提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制 机制，以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算 单元整合与算力共享。 当前 Hypervisor 已经成为智能座舱所采用的技术方案，未来随着自动驾驶域控制器与智能座舱域控制器融 合，在高算力芯片上同时实现自动驾驶与智能座舱功能，Hypervisor 将成为必选方案。

3.1.3 格局：黑莓绝对龙头

目前全球虚拟化系统供应商几乎全部来自海外，由于车载虚拟机（Automotive Hypervisor）技术有着较高的 安全等级要求，因此能提供此类产品的供应商较少。该领域主要玩家有黑莓 Blackberry（QNX）、英特尔 Intel （ACRN）、OpenSynergy（COQOS）、Green Hills（Integrity）、大陆 Continental（L4Re）、Wind River Systems、 NXP、Siemens、Luxoft 等等。

1. QNX Hypervisor： 其中黑莓旗下的 QNX Hypervisor 是目前公认最安全最成熟的智能座舱 Hypervisor 操作系统，QNX 由于同 时获得了工业级（IEC 61508 SIL-3 级）和车规级（ISO 26262 ASIL-D 级）认证，占据了 60%的市场份额，可谓 一家独大。 从产品上讲，黑莓 QNX Hypervisor 属于 Type 1 型虚拟机管理系统，上面可以适配不同类型的 Guest OS 组 合帮助 OEM 和 Tier 1 为传统 ECU 以及下一代 ECU 和域控制器设计和开发高性能、安全、可靠的车载应用程 序。 BlackBerry QNX 软件以标准为基础，提供通用的开发工具，以满足并兼容车辆中安全关键型和非安全型 ECU 的需求，并为安全通信、安全图形、安全系统库和中间件提供解决方案。

2. ACRN Hypervisor： 2018 年 Linux 嵌入式大会上发布的 ACRN Hypervisor，是一款灵活、轻量级的参考 hypervisor，兼顾实 时性和关键安全性，并通过开源平台为精简嵌入式开发进行优化。ACRN 定义了设备 Hypervisor 的参考堆栈和 体系结构，用于在统一系统上运行安全管理的多个 Guest OS 软件子系统。ACRN Hypervisor 属于 Type 1 Hypervisor，直接在裸机硬件上运行，适用于各种 IoT（物联网）和嵌入式设备（Embedded Device）解决方案。 ACRN Hypervisor 解决了数据中心管理程序和硬分区管理程序之间当前存在的空白。ACRN Hypervisor 架构将系 统划分为不同的功能域，并精心选择了针对物联网和嵌入式设备的用户虚拟机共享优化。

3. OpenSynergy – COQOS Hypervisor COQOS Hypervisor 软件开发包（SDK）由 OpenSynergy 和瑞萨 Renesas 开发，可在 SoC 硬件上实现多种功 能的融合，同时使不同关键性的系统（分配给不同的 ASIL 级别，例如 QM 级，A 级，B 级等）之间不受干扰。 Hypervisor 技术是 COQOS Hypervisor SDK 的核心。通过 Hypervisor 虚拟化管理技术，可以在单独的虚拟机中运 行多个 Guest OS（包括 Linux，Android，AUTOSAR 或其他 OS）。COQOS Hypervisor 的一个典型的使用案例 是座舱控制器，它可以在单个处理器上同时运行仪表板和车载信息娱乐系统。

4. Greenhill- INTEGRITY Multivisor INTEGRITY Multivisor 是业界唯一经过安全认证的架构，可在各种多核 SoC 硬件上同时运行一个或多个 Guest OS 以及关键任务功能。INTEGRITY Multivisor 是专门为了解决嵌入式设备遇到的困难而设计的，它能够 在不影响安全、或性能的情况下实现快速、和成本效益最高的复杂系统设计。

3.2 操作系统：软硬件隔离的基础

3.2.1 是什么：操作系统承上启下，引领智能汽车升级

从 20 世纪 90 年代开始，随着车载电子装置功能的日益丰富以及外部交互/接口标准的种类增加，这类基于 微控制芯片的嵌入式电子产品逐渐需要采用类似个人电脑的软件架构以实现分层化，平台化和模块化，提高开 发效率的同时降低开发成本。因此，汽车电子产品才逐步开始采用操作系统。 操作系统（Operating System，OS）是指控制和管理整个计算系统的硬件和软件资源，并合理地组织调度计 算机的工作和资源，以提供给用户和其他软件方便的接口和环境的程序集合。智能设备发展到一定程度后一般 都需要专门的 OS，例如 PC 机对应的微软 Windows 系统，智能手机对应的 GoogleAndroid 系统和苹果 iOS 系统。 到了域控制器时代，许多项功能都被集成到一颗性能强大的 SoC 芯片上，尤其是，在自动驾驶功能从 L2 向 L4 演进的过程中，传感器的种类和数量大幅增加、需要处理的数据量更是呈指数级增加，如此复杂的任务， 对操作系统的实时性、功能安全、信息安全的要求都在提高，需要一个强大的实时操作系统。在软件定义汽车 的大趋势下，汽车 OS 是传统汽车实现智能汽车升级的关键。

系统内核（kernel）是操作系统最核心的部分，可以理解为操作系统的心脏，具体可分为微内核和宏内核。 微内核是系统内核的一种精简形式。通常而言，系统服务层和内核集成在一起，而微内核将系统服务层分离出 来，变成可以根据需求加入的选件，由此可以提供更好的可扩展性和更加有效的应用环境。微内核具有代码量 和漏洞少、可扩展性高的优点。宏内核同样管理着用户程序和硬件之间的系统资源，但是在宏内核架构中，用 户服务和内核服务在同一空间中实现。宏内核需要管理的资源多于微内核，其大小相对微内核更大一些。

从技术角度来看，操作系统可分为实时操作系统和非实时操作系统。所谓实时操作系统，是指系统接收到 输入信号后，能够在短时间内处理完毕并予以反馈，并且其处理任务的（最迟）完成时间是确定可知的，具备 较高的安全性与可靠性。因此实时操作系统往往应用于车控领域，包含传统的车辆动力、底盘、车身以及新兴 的自动驾驶等。非实时操作系统则广泛应用于座舱娱乐等领域，更加注重兼容性与开发生态。 车载操作系统可分为车控操作系统和智能座舱操作系统两类。

车控操作系统是实现车辆行驶功能、动力性的运行基础，对实时性和稳定性要求高，通常为实时操作系统 （RTOS），通常为芯片商提供配套的操作系统。传统的 MCU 是基于 CP Autosar 的 OSEK 系统，执行的功能 较为单一， 硬件资源有限；随着智能汽车快速发展，车控操作系统不断升级，主流的车控操作系统有：Linux、 Yocto、华为 AOS、QNX、Vxworks 等。 智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多 源信息融合的运行环境。对实时性和稳定性要求不严，重在应用生态丰富，操作系统通常来自 OEM 或第三方。 操作系统在车上主要应用领域为：信息娱乐、自动驾驶、复杂网关、TBOX。目前主流的智能座舱车载操作系 统有：仪表——QNX、Integrity；中控——Andorid、鸿蒙 OS、基于 Linux 或 Android 开发的 OS（AliOS、VW.OS、 特斯拉 Version 等）。

目前，主流的操作系统内核主要有为 QNX、Linux、Vxworks 和 OSEK。随着汽车智能化水平的不断提升， 车载操作系统的配备将必不可少。由于有实时性、可靠性和安全性的要求，目前市面上能完全满足要求的车载 操作系统产品并不多，各 OS 内核的特点总结如下:

（1）QNX 非开源&安全实时

QNX 是世界首款通过车规级安全认证的操作系统，核心优势在于高安全性。QNX 是一款微内核、嵌入式、 非开源、安全实时的操作系统。从技术端来看，QNX 采取微内核架构，内核一般只有几十 KB，操作系统中的 多数功能均以许多小型 Task 来执行，这样的架构使得用户和开发者可以关闭不需要的功能而不需要改变操作系 统本身。驱动程序、协议栈、文件系统、应用程序等都在微内核之外的受内存保护的空间内运行，可实现组件 之间相互独立，避免因程序指针错误造成内核故障。得益于这种执行模式，QNX 系统中的各项功能与应用能在 不影响互相间稳定性的前提下整合运算资源，在高安全性的同时保障其运算效率。其核心提供 4 种服务，分别 为：进程调度、进程间通信、底层网络通信和中断处理。从产品端来看，公司产品覆盖基础系统软件（QNXNeutrino RTOS、QNXHypervisor、QNXSDP）、安全认证产品（QNX OS for Safety 等）、安全解决方案（BlackBerry Jarvis、 BlackBerry QNX OTA 等）、中间件（声学管理、ADAS 等）四大领域。同时，为确保软件的安全性，QNX 开 发生态较为封闭，黑莓是 QNX 的唯一开发者，其他厂商在使用时需支付版权费用。

（2）Linux 开源&功能强大

Linux 优化后用于实时 OS，核心优势在于灵活的开发度。Linux 具有内核紧凑、高效等特点，可以充分发 挥硬件的性能。与 QNX 相比最大优势在于开源，具有很强的定制开发灵活度。Linux 功能较 QNX 更强大，组 件也更为复杂，因此 Linux 常用于支持更多应用和接口的信息娱乐系统中。协会或联盟致力于将开源 Linux 操 作系统推广至汽车领域中，典型代表如 AGL、GENIVI。 AGL 开源项目致力于建立一个基于 Linux 的联网汽车内部使用的开源平台。2014 年，Linux 基金会发布了 开源 AGL（AutomotiveGradeLinux）规范 1.0 版本，它是首个开放式车载信息娱乐（IV1）软件规范。其中 70% 的代码（包括操作系统、中间件和应用程序框架）已编写完成，车企可以专注于剩下的 30%个性化定制开发， 以保证不同品牌的差异化，而且 AGL 不收取任何许可费。随着自动驾驶的发展，AGL 已经不只局限于 IVI （In-Vehicle Infotainment，车载信息系统）领域，未来将向仪表盘、座舱域、自动驾驶等领域延伸，现阶段它仍 未通过 ISO26262 标准。从其整车企业成员来看，AGL 早期主要为丰田、本田、日产等日系厂商，随着 2019 年 大众、现代汽车的加入，AGL 势力规模逐渐壮大。截至 2020 年 3 月，国内已有中国移动、上汽集团、德赛西 威、中科创达等公司加入 AGL，成员总数超过 150 个。

（3）Vxworks 开源&实时性好

VxWorks 是开源的实时操作系统，由 400 多个相对独立、短小精悍的目标模块组成，但用户可获所有源代 码并根据需要对 OS 内核在源代码层面进行裁剪和配置。VxWorks 的优势在于：具有实时性、可裁减的操作系 统内核；友好的开发调试环境；较好的兼容性；支持多种开发和运行环境。

（4）OSEK 可移植&可扩展

OSEK 主要由四部分组成:操作系统规范、通信规范、网络管理规范和 OSEK 实现语言。OSEK 规范为实现 其制定的初衷并满足汽车控制领域对系统安全性和节省有限资源的特殊要求，制定了系统而全面的操作系统规 范，具有以下特点：（1）实时性，OSEK 操作系统通过静态的系统配置、占先式调度策略、提供警报机制和优 化系统运行机制以提高中断响应速度等手段来满足用户的实时需求。（2）可移植性，OSEK 规范详细规定了操 作系统运行的各种机制，并在这些机制基础上制定了标准的应用程序编程接口，使那些独立编写的代码能够很 容易地整合起来，增强了应用程序的可移植性。（3）可扩展性，OSEK 操作系统具备高度模块化和可灵活配置 的特性。它定义了不同的符合级别( Conformance Classes)，并采用对不同应用程序有可靠接收能力的体系结构， 从而增强了系统的可扩展性。

3.2.2 趋势：生态化、差异化、车企定制甚至主导

对于车载操作系统未来的发展趋势，可以总结为以下几点：

第一， 生态化

汽车软件与硬件体系发生分化。近几十年随汽车构架升级、性能与用户操作感需求逐年提升，汽车软硬件 数量爆发，并愈发复杂化。在硬件方面，电控单元数量迅速增长，于 2010 年面临增速放缓的拐点（主要受整车 成本与控制器数量平衡的影响），2025 年随行业集中式电子电气架构趋势持续推进，电控单元迈向集成化从而 控制器数量将较为平稳。在软件方面，各大主机厂软件功能体系越做越大，其中“功能函数”作为软件体系中 的最小单元，其单车数量持续增大，控制器内部的功能函数复杂度提升，叠加智能座舱新增的应用型软件需求， 软件重要性愈发凸显。

第二， 差异化。

回顾手机操作系统的发展经验，Symbian 系统未能跟随智能手机时代变革，导致开发者生态大幅减少 摩托 罗拉和 Psion 先后退出联盟等因素，Symbian 不能适应时代变革，仅 5 年时间，市占率便从 2007 年的近 60%迅 速下降到 2012 年的不足 2%；IOS 采用闭环开发模式（芯片-操作系统-手机），随着 2007 年第一代 iphone 发布 后，市占率快速提升并达到稳定；Android 凭借开源第三方模式，于 2008 年发布 Android 1.0 后市占率迅速提升 并反超 IOS。 Android 成功的主要原因可以概括为以下四点：（1）开源、自由的策略形成了丰富的软件生态；（2）软件 研发能力强 部分软件捆绑策略增强用户粘性；（3）中立的第三方，ARM Android 巨头联盟引领行业发展；（4） 形成了统一标准接口，使软硬件移植性较强。 苹果 iOS 采用芯片-操作系统-手机一体式的模式，其中操作系统采用非开源路线，成功的主要原因可以概 括为以下

3.2.3 格局：QNX 具有先发优势，Linux 快速崛起

2020 年全球汽车广义操作系统市场规模达 200 亿美元，未来五年 CGAR 13.1%。我们重点参照了 Mckinsey 分析数据，2020 年全球汽车广义操作系统（功能软件、狭义操作系统、中间件）市场规模达 200 亿美元，到 2025 年达 370 亿美元，CGAR 13.1%；到 2030 年达 500 亿美元，十年 CAGR 9%。

3.2.3.1 狭义操作系统格局：QNX 占主导，竞争格局高度稳定

系统内核具备较高的技术壁垒，又由于有实时性、可靠性和安全性的要求，市面上载操作系统内核产品并 不多。目前 QNX 具有一定先发优势，全球市场占有率超过 60%，长期来看很有可能会形成 QNX 和类 Linux 两 家独大的局面，且两者会是长期共存关系，QNX 和 Linux 市场份额占据 90%以上，竞争格局高度稳定。

3.2.3.2 广义操作系统格局：车企&互联网公司齐发力

目前，汽车行业充斥着各类榜车载 OS 的方案，主要来自于传统主机厂、BAT 等科技巨头、造车新势力以 及初创公司。QNX 和 Linux 可谓车载 OS 的鼻祖，多数所谓的 OS 都是在 QNX、Linux 的基础上进行开发，也 多局限在上层应用，均没有深入到系统底层。国内阿里、华为、大众等基于 QNX 或 Linux 开发操作系统，凭借 各自原有业务基础优势的支撑，深耕布局。

（1）特斯拉：Version 率先打造 OS，树立行业标杆

特斯拉的操作系统 Version 基于 Linux 内核深度改造而成。特斯拉系统平台采用 Linux4.4 开源操作系统， 支持 PyTorch 的深度学习编程框架，基于 Kafka 开源流实时数据处理平台，可支持信息娱乐系统（IVI）和驾驶 辅助系统（ADAS）等。特斯拉选择 Linux 一方面由于 Linux 开源自由的优点，避免受制于操作系统厂商；另 一方面则发挥其内核紧凑高效、可以充分发挥硬件性能的优点，满足了特斯拉对汽车性能的要求。另外，使用 Linux 系统中的安全增强型 Linux（SELinux）内核模块，通过“访问权限控制”增强操作系统信息安全性，避 免操作系统核心区域免受攻击。自 2014 年首次在 Model S 上使用 Version 5 以来，特斯拉已通过 OTA（Over-the-Air Technology，空中下载技术）对 Version 进行了多次重大升级。

（2）大众打造 VW.OS 平台，加快数字化转型

大众更加注重功能安全、框架标准化，采用 Linux、QNX、VxWorks 等多个底层操作系统打造一体式平台， 简化智能座舱、自动驾驶、车身控制等之间的交互。优点：可充分利用各家供应商的已有技术优势实现快速转 型。缺点：各家供应商标准接口、协议并不统一，组建的系统过于复杂，仍高度依赖供应商。 大众通过打造一个可运行多个底层系统（如 Linux、QNX、VxWorks）的 VW.OS 平台，简化座舱和自动驾 驶的交互技术。由于各家供应商标准接口和协议各不相同，高度依赖 AutoSAR 实现中间件标准化，因此产生大 量庞大繁杂的模块、组件以支持来自不同供应商的软件。此外，大众将建立 Volkswagen Automotive Cloud 全球 专属云服务后台，以实现传统大众汽车向全新智能软件产品的转变。 大众 VW.OS 的目标是实现车辆、客户和服务统一的数字化平台。VW.OS 为大众数字化转型战略而生，其 存在也有助于大众数字化品牌生态系统的建立。搭载大众 VW.OS 的新车型将使用系统平台实现底层硬件的资 源分配，软硬件之间的通信交互，共享底层函数库组件资源，大幅减少代码量的同时，实现 ECU 功能的集成。 该生态系统依托于一个基于云技术，将车辆、客户和服务三者紧密连接的统一数字化平台（ODP，One Digital Platform）。ODP 平台有效确保了大众汽车的外部合作伙伴以及大众汽车服务，与大众汽车 IT 架构紧密连接， 打通全线合作。

（3）Google 以 Android Automotive OS 入局汽车OS 领域

Google 于 2019 年发布 Android Automotive OS，是一款可直接运行在汽车 IVI 系统上的开源操作系统， Android Automotive 是专门考虑汽车环境使用特性而开发的，具备更快的系统响应时间，并且重新设计了界面， 并为 OEM 提供了谷歌官方的应用程序接入。用户可以通过 Google Play 下载 Google 助手、Google Map 等应用在汽车上运行，而无需使用 Android 手机。Android Automotive 与手机 Android 类似，其源代码库免费和开源， 提供基本的信息娱乐功能，主机厂可通过 Android 的通用框架和 API 来实现自己所需的功能。 Android Automative 是在原手机 Android 的系统架构基础商替换为与车相关的模块。主要包括包括：1）Car App：包括 OEM 和第三方开发的 App；2）Car API 提供给 汽车 App 特有的接口；3）Car Service：系统中与车 相关的服务；4）Vehicle Network Service：汽车的网络服务；5）Vehicle HAL：汽车的硬件抽象层描述。区别于 之前的开源安卓系统，车载安卓系统的灵活可定制性和可修改编辑性大大降低，其应用或许受限。沃尔沃旗下 电动车品牌 Polestar 将成为首辆搭载车载 Android 系统的车型。 当然此系统也还有不足之处，比如：（1）界面 layout 过于追求“大”，浪费空间；（2）整体体验很基础， 智慧功能目前主要靠语音助手体现，在智能化方面还不够完善；（3）未呈现从移动设备到车机的体验连续性， 还未完成多设备的及时联通。

（4）阿里：AliOS 以座舱切入，抢夺应用生态入口

阿里 AliOS 以座舱切入，抢夺应用生态入口。AliOS 布局广泛且定位清晰。将 AliOS 定位为面向多端的物 联网操作系统，并不局限于汽车市场，支持多任务处理，具备强大的图形、音视频及语音处理能力，适用于汽 车等 CPU 性能及内存要求较高的 IoT 设备。在智能网联汽车领域，AliOS 以智能座舱切入，抢夺应用生态入口。 AliOS 的前身 YunOS 以 Linux Kernel 为内核，直接使用 Android 的运行时库、软件框架及开发工具，可以 被视为 Android 的一个分支，但不完全与 Android 兼容。系统搭载了自主设计、架构、研发的核心虚拟机，并增 加了云服务相关模块，提供与 Android Dalvik 虚拟机兼容的运行环境。升级后的 AliOS 秉持开源自由的技术路 线，在战略重组斑马后，阿里将 YunOS 整体知识产权及业务放入斑马。后者拥有 YunOS 底层架构代码完整的 所有权和使用权，并可授权汽车品牌或其指定合作伙伴使用。同时，斑马网络将进一步向汽车全行业开放，结 合 YunOS 操作系统的核心基础技术，让斑马系统走进更多汽车品牌。

（5）华为鸿蒙 OS：面向全领域，打造独立第三方平台

鸿蒙 OS 是全球第一个面向全场景微内核的分布式 OS，包括支持全场景、跨多设备和平台以及应对低时延 和高安全性挑战的能力。鸿蒙系统具有四大特点：分布架构、天生流畅、内核安全和生态共享。从架构来看， 鸿蒙 OS 从下到上可分为内核、基础服务、程序框架及应用四层，并通过分布式软总线技术进行分布式数据管 理、能力调度及虚拟外设。中长期来看，基于分布式架构的鸿蒙 OS 将打破不同智能终端之间的壁垒，为消费 者提供“1 8 N”全场景的智能出行体验。

综合来看，当前车载 OS 领域竞争急剧升温，特斯拉继续深耕 Version 以求掌握数据资源；VW.OS 为大众数 字化转型战略而生，有助于大众数字化品牌生态系统的建立；Android 掌握着庞大的移动设备端用户基础和开发 者，占据了绝大部分市场份额，应用生态能够向车载 OS 端迁移；阿里 AliOS 定位为面向多端的物联网操作系 统，以智能座舱切入，抢夺应用生态入口；华为鸿蒙面向全领域，打造独立第三方平台，各方企业开始上演新 一轮智能网联汽车入口争夺战。

3.3 中间件：底层与应用的“中介”

3.3.1 是什么：介于操作系统与应用程序

中间件（Middleware）是链接操作系统和应用软件的一种基础软件，负责各类应用软件模块之间的通信以 及对底层系统资源的调度。中间件主要解决异构网络环境下分布式应用软件的通信、互操作和协同问题， 它可屏蔽并发控制、事务管理和网络通信等各种实现细节，提高应用系统的易移植性、适应性和可靠性。 中间件具有一定标准的协议和程序接口。当面对不同的平台（操作系统和硬件）时，中间件提供符合协议 和程序接口规范的多种实现。中间件的存在有效的屏蔽了底层操作系统的复杂性，让程序开发人员只需面 对相对简单统一的开发环境，成功降低了程序设计的复杂性。程序开发人员也就不需要考虑程序移植到不 同系统环境时的重复开发，中间件降低了重复开发的技术负担。 简而言之，中间件起到的是“中介”的作用。举一个形象的比喻：炸鸡店（应用程序）综合成本、质量挑 选屠鸡场（底层资源），最终选定某家屠鸡场作为鸡肉供应商（完成底层适配）。由于市场变化，因成本、质 量等因素需要重新挑选屠鸡场，进货方式、交易方式等全都要重来一套（重新适配）。然而炸鸡店只想好好做 炸鸡，只要有性价比高的肉送来就行。于是引入一个专门整合屠鸡场资源的第三方代理（中间件），跟他谈好 价格和质量后（统一接口），炸鸡店只负责给钱拿肉，代理负责保证肉的质量。

目前应用在自动驾驶汽车领域的中间件主要有 CP AUTOSAR、AP AUTOSAR 和 ROS。CP AUTOSAR 是 传统汽车 ECU（如发动机控制器、整车控制器等）广泛使用的中间件，已成为传统汽车控制器软件架构的规范。 AP AUTOSAR 是为适应高性能计算平台软件开发而推出的中间件，主要应用于自动驾驶控制器和智能座舱控制 器。ROS 是针对机器人项目的开源中间件，提供丰富的功能函数和生态环境。自动驾驶汽车本质上也是机器人， 因此 ROS 也被应用到构建自动驾驶控制器软件架构中。

3.1.1.1 CP AUTOSAR

AUTOSAR（automotive Open System Architecture）是汽车行业内最著名的中间件方案，是主流汽车 OEM 和 主流供应商、芯片企业等制定的一套软硬件可以分离复用、应用算法与底层驱动分离、下层的芯片企业与上层 OEM 或者 ECU 供应商基于同样的规范独立并行开发的软件开发体系，目的是为了降低汽车控制软件的开发风 险，提高软件复用度。AUTOSAR 联盟自 2003 年成立以来，成员队伍不断壮大，基本上涵盖了世界各大著名整 车厂、零部件供应商、半导体公司及软件工具开发商。 AUTOSAR 为开发者提供统一标准的软件框架和开发流程，解决传统汽车控制器开发周期长、重用性差的 缺陷。传统汽车软件存在如下的缺陷：1）软件重用性极差；2）硬件平台各式各样，难以统一、重用；3）软件 模块化程度不高；4）系统不支持硬件抽象。因为上述缺陷，成熟的软件很难移植到新平台新项目。每个项目基 本都需要从头开发，即根据硬件平台重新编写底层驱动，根据底层接口重新修改应用程序。随着汽车更新频繁、 汽车平台化发展，AUTOSAR 联盟成立并推出 AUTOSAR 软件架构和开发流程。

CP AUTOSAR（AUTOSAR Classic Platform）是 AUTOSAR 联盟最先推出的针对传统汽车控制器的软件 框架。其基本理念是将软件根据功能分为不同层级，并将各个功能模块化、标准化。在 AUTOSAR 架构中，控 制器从上到下分层依次为：应用程序层（Application Software Layer），运行环境层（Runtime Environment，RTE）、 基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。每层之间为保持独立性，每一层只 能调用下一层的接口，并为其上一层提供接口。

3.1.1.2 AP AUTOSAR

自动驾驶软件架构需要满足三个要求：1）实时性和安全性；2）支持复杂应用功能的实现；3）可扩展性。 CPAUTOSAR 架构满足实时性和安全性的要求，但不支持复杂计算和功能动态部署。而 Android 系统以及 ROS 满足 2、3 属性，但缺少车规级的实时性和安全性。为此，AUTOSAR 联盟在 2017 年推出了第二个软件平台 AP AUTOSAR（AUTOSAR Adaptive platform）。AP AUTOSAR 基于 POSIX 标准的操作系统（如 Linux、QNX 等）， 以面向对象的思想进行开发，是面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架 构标准。

APAUTOSAR 并非取代 CPAUTOSAR，两者应用场景不同，共同存在与自动驾驶汽车中。对安全性、实 时性、确定性执行有高要求，但对带宽要求不高的使用微控制器的嵌入式 ECU 首选 CP AUTOSAR，如传统汽 车的 ECU。AP AUTOSAR 用于高算力、高带宽、应用功能可动态部署的控制器，如自动驾驶控制器。因此，自 动驾驶汽车上既需要 AP AUTOSAR 也需要 CP AUTOSAR。

3.1.1.3 ROS

ROS (Robot Operating System)是一个强大而灵活的机器人编程框架，是一种基于消息传递通信的分布式多 进程框架。ROS 很早就被机器人行业使用，很多知名的机器人开源库，比如基于 quaternion 的坐标转换、3D 点 云处理驱动、定位算法 SLAM 等都是开源贡献者基于 ROS 开发的。因为 ROS 本身是基于消息机制的，开发者 可以根据功能把软件拆分成为各个模块，每个模块只是负责读取和分发消息，模块间通过消息关联。 ROS 系统是起源于 2007 年斯坦福大学人工智能实验室的 STAIR 项目与机器人技术公司 Willow Garage 的一 个人机器人项目（Personal Robots Program），2008 年之后就由 Willow Garage 来进行推动。ROS 开源免费、生 态丰富，提供庞大丰富的基础库，支持多语言，大幅提升上层应用程序开发效率。同时 ROS 基于消息驱动的 运行模式使模块灵活配置，便于功能扩展。ROS 还提供了丰富的调试工具。因此，ROS 也被应用于自动驾驶 软件。但对于自动驾驶汽车量产，ROS 仍存在一些缺陷：大数据量传输性能瓶颈、中心化网络存在单点风险、 数据格式缺乏后向兼容、安全问题。部分厂商将 ROS 更多用于前期自动驾驶功能开发和算法训练，部分厂商通 过对 ROS 进行定制化开发，弥补缺陷，使其尽可能满足车规要求。如初创公司 Apex.ai 致力于研发车规级 ROS， 推出了 Apex.OS。

3.3.2 趋势：面向服务架构（SOA）

CP AUTOSAR 架构是一种面向信号的架构，即一个模块会不停的在总线上，周期性的发送信号给另一个控 制器。整车内各个控制器的信号线交织在一起，功能交互非常复杂和冗余，导致：1）不同 ECU 或供应商之间 的变更需要花费大量的时间和成本，不同的功能逻辑交织在一起，系统异常复杂、不灵活和难以扩展；2）大量 的功能需要控制器间的协调工作，微小的功能改动都会引起整车通信矩阵的变更。为解决以上问题，汽车行业 引入了 IT 行业的面向服务的软件架构设计理念。 SOA（Service-Oriented Architecture）即面向服务的架构，是一种软件架构设计的模型和方法论。其核心 思想是将每个控制器的底层功能以“服务”的形式进行封装，一个服务即是一个独立可执行的软件组件，并对 其赋予特定的 IP 地址和标准化的接口以便随时调用，最终通过对这些底层功能的自由组合，以实现某项复的 智能化功能。在架构设计工作中，重点关注汽车上的功能（“服务”）如何实现，功能与外界的交互（“服务 接口”），功能与外界交互的基本流程（“服务序列”）。基于服务的 SOA 架构要求各个控制器，把自己的能 力，以服务的方式提供出来，以此来构建一个与车型、芯片、操作系统无关的灵活可变的平台系统。在这个框 架下，服务节点可以动态加入，即可以便捷实现功能扩展.

SOA 是一种设计模式和思想，符合 SOA 设计理念的软件架构主要有三个特点：接口标准化、相互独立、 松耦合。1）标准化：各个“服务”间具有界定清晰的功能范围，并且留予标准化的访问接口（由第三方代码编码而 成），以便于其他控制器在进行功能变更或升级时进行订阅。 2）相互独立：每个服务之间相互独立且唯一，均属于汽车软件架构中的基础软件，因此若想升级或新增某 项功能只需通过标准化的接口进行调用即可。 3）松耦合：底层软件独立于车型、硬件平台、操作系统以及编程语言。可以将传统中间件编程从业务逻辑 分离，允许开发人员集中精力编写上层的应用算法，而不必将大量的时间花费在更为底层的技术实现上。

基于 SOA 设计的架构面对同样的场景。功能模块在 ECU 上面叫做服务组件。在设计阶段，包括设计和编 译，集成部署，整体过程中都是独立自主的软件。它可以独立的进行编译以及独立的动态的进行部署。当新增 一个功能时，只需在 ECU2 上面快速 OTA 这个单独可编译模块，整体是即插即用的。在第二个场景下面，当想 把 AA 功能新的功能移植到 ECU3 的时候，无须重新开发和编译，只需在部署阶段通过动态配置文件实现模块 的移植，也是即插即用。

SOA 带来什么： 1） 软件开发模式：开发工具统一，系统软件定制化程度降低，OEM 专注应用软件开发；开发环境更加开 发，上层应用生态更加丰富。 2） 软件迭代周期：更新软件成本降低，开发周期缩短。产品 SOP 后支持软件快速独立更新，新功能即插 即用。 3） 实现“软件定义汽车”：充分释放汽车硬件资源，扩展汽车应用生态。

3.3.3 格局：传统 Tier1 为主，其他厂商差异化竞争

经典 AUTOSAR 标准下的开发工具链及基础软件几乎被海外 Tier1 所垄断，包括 EB（Continental 子公 司）、ETAS（Bosch 子公司）、VECTOR 等。随着汽车产业的智能化转型升级，AP AUTOSAR 逐步被采用。 传统 Tier1 凭借传统控制器领域的优势，迅速推出了各自的基于 AP AUTOSAR 的中间件解决方案。其他厂商 如英伟达和华为在提供硬件 系统软件解决方案的时候也提供支持 AP AUTOSAR 的方案。ROS 在自动驾驶早 期应用广泛，如百度 Apollo3.5 版本前均采用 ROS。随着自动驾驶开发越来越面向量产，ROS 的缺陷使厂商在 量产项目中逐步放弃使用 ROS，而转向 AP AUTOSA 或自研中间件。比如百度放弃使用 ROS，转而采用自研 的 CyberRT。不过仍有厂商如 Apex.AI 通过深度定制继续采用 ROS。

3.1.1.1 传统汽车软件供应商：AUTOSAR 核心成员，加速布局 AP AUTOSAR 软件框架

汽车传统 Tier1 如大陆、博世、ZF 等在底盘、发动机、车身等 ECU 领域具有显著的竞争优势。Tier1 向英 飞凌、瑞萨、TI、NXP 等芯片商采购芯片，集成 ECU 硬件。同时，基于 OSEK 实时操作系统标准和 CP AUTOSAR 架构开发各自的 ECU 系统软件，OEM 在 Ter1 的软硬件平台上开发应用程序。传统汽车 ECU 中间件基本被博 世、大陆等 Tier1 垄断，原因主要： 1） 汽车底盘和动力的机电一体化技术来自 Tier1，比如底盘的 ESP、发动机电喷等。Tier1 推动了汽车电子 化，他们具有先发优势；2） ECU 软件通常针对汽车行业，专用性强，非汽车厂商难以有进入供应体系的切入点； 3） Tier1 是 AUTOSAR 联盟的核心成员，也 AUTOSAR 软件规范主要指定者； 4） ECU 软件相对成熟，OEM 无须投入和自研。 基于 ECU 软件的优势，Tier1 在车载智能计算平台上的布局以中间件为核心。由于行业缺乏适用于高算力 计算平台的车规级中间件，AUTOSAR 联盟 2017 年推出了 AP AUTOSAR。作为联盟的核心成员，Tier1 迅速推 出相关产品。

3.1.1.2 硬件厂商：高度适配自己硬件，支持 AUTOSAR

为向 OEM 提供更高效的支持，部分硬件厂商可提供适配自己硬件的系统软件。这类系统软件在中间件集成 硬件商自研的计算模块，用于高效调用 GPU 或 AI 芯片。同时为满足量产车规级要求，硬件厂商开发的中间件 通常都支持 AP AUTOSAR 架构。 英伟达提供开源的 NVIDIA DRIVE 软件堆栈支持用户在 NVIDIA DRIVE AGX 计算平台完成应用程序开发。 NVIDIA DRIVE 软件包含 DRIVE OS、Drive Works、DRIVE AV 和 DRIVE IX。其中，DRIVE OS 包含虚拟机、 操作系统和中间件，提供自研的并行编程库 CUDA 和深度学习 SDK TensorRT。DRIVE OS 集成黑莓 QNX 实时 操作系统，采用 TTTech 的 MotionWise 安全应用框架，全面支持 Adaptive AUTOSAR。

3.1.1.3 其他：高度自研，推出针对自动驾驶的中间件

百度 Apollo 最初用的中间件是开源的 ROS，不过 ROS 的一些缺陷使为自动驾驶开发带来了挑战。2019 年 百度发布 Apollo 3.5 版本，其采用了自研的开源中间件 Cyber RT。Cyber RT 高度集成的并行计算模型，能够实 现任务执行的高并发、低延迟以及高吞吐量。针对自动驾驶业务场景的定制开发，使其能够满足自动驾驶解决 方案的高性能要求，并且使研发效率的显著提升。Cyber RT 易于部署的自适应设计，其灵活的集成方案以及最 小的环境依赖使得应用程序的部署更加简单。 一家由博世资深员工和自动化系统工程师于 2017 年创办的初创公司 Apex.ai 深度重新编写 ROS，致力于研 发车规级 ROS。目前公司推出的 Apex.OS 已经获得功能安全标准 ISO 26262 认证，这意味着该技术已被验证可 用于量产车。Apex.AI 的产品已经被丰田自动驾驶研发部门 Woven Planet、日本自动驾驶初创公司 Tier IV 所使 用。Apex.AI 也获得了沃尔沃风投、丰田风投、海拉风投、空客风投等机构的投资。

3.4 功能软件：提供算法与基础功能共性模块

3.4.1 是什么：自动驾驶相关算法的模块化封装

自动驾驶算法有很多通用性的算法模块，比如传感器的感知融合、车辆的定位、车辆路径规划、车辆运动 控制等等，同时还需要通信网联等其他软件模块形成完成的自动驾驶功能。在这类算法模块基础上，针对不同的应用场景，可进一步开发形成如 ADAS 功能、自动泊车功能、高速辅助驾驶功能、城区辅助驾驶功能等等具 体的应用软件。 功能软件可进一步分成两层，下层为实现自动驾驶的基础模块，上层为自动驾驶子功能模块。子功能模块 包含针对各类传感器的感知与融合功能、定位功能、行为规划功能、运动控制功能。而子功能模块的具体实现 还基于一些底层的基础算法或软件库，比如用于感知融合的深度学习算法（Tensorflow、Pytoch 等等）、传感器 需要用到一些滤波算法（卡尔曼滤波、贝叶斯估计等）、定位的一些基础算法（SLAM 等）、路径规划类算法 （搜索类算法 DFS、BFS、IDS 等）、自动控制算法（PID、MPC、LQR 等）以及基础的通讯、存储模块。 在 所有功能软件中，传感器的感知融合是技术难度最高的部分，其次是定位，他们直接影响自动驾驶功能的优劣。

3.4.2 趋势：复杂度提升、算法迭代

随着自动驾驶级别提升，功能软件模块不断增加（比如需要识别场景越来越多），形成超级复杂的异构计 算网络。为应对几何增长的数据处理量以及复杂度不断提升的计算网络，提升算法效率与可靠性，一些底层算 法框架不断迭代升级。比如多传感器感知融合算法框架从后融合变为前融合。

3.4.1 格局：整车企业逐步形成自研

功能软件的参与者包含整车企业、第三方软件算法供应商（Momenta、中科创达等）、系统解决方案供应 商（华为、百度、mobieye 等）和传统 Tier1（博时、大陆等）。传统 Tier1 主要结合自己传感器硬件提供一些 基础功能模块（感知融合、定位等）；因感知融合算法技术难度大，第三方软件算法供应商大多布局于此；如 华为、mobieye 等系统方案商可为整车企业提供从硬件到应用软件的全套解决方案，功能软件也是这类企业的 核心竞争力之一；整车企业为实现产品功能的领先性，以及建立核心竞争力，也纷纷自研功能软件。布局领先的整车企业有特斯拉、小鹏、蔚来、长城等。目前看，高阶辅助驾驶系统以及未来的自动驾驶系统的功能软件 将趋于由整车企业自研。

3.5 应用软件：产品智能体验差异化的核心

3.5.1 是什么：功能实现

应用层软件负责实现各类功能，包括自动驾驶相关应用功能、智能座舱相关应用功能、OTA 与云服务等。 自动驾驶相关应用功能又可以具体分为 ADAS 功能（包括 AEB、ACC、LKA 等）、高速辅助驾驶功能、城区 辅助驾驶功能、自动泊车等等。智能座舱相关应用功能又具体包含 HMI、语音交互、DMS、信息娱乐等等。 通常应用层软件的定义与开发是由整车厂完成，是打造产品差异化的核心。一方面，整车厂商不断丰富拓 展应用功能，比如增加各类场景下的自动驾驶功能；另一方面，整车厂不断完善、优化功能，比如同样为 AEB 功能，不同厂商的使用体验是有差异和优劣之分的。

3.5.2 趋势：提升功能、丰富场景

应用软件从实现低阶 ADAS 功能逐步向高阶辅助驾驶功能、自动驾驶功能推进。蔚来在 ES8、ES6 安装的 是 NIO Pilot（包含 ADAS 功能与领航辅助 NOP）。在全新产品 ET7、ET5 上，蔚来自动驾驶功能升级为 NAD （包含 NIO Pilot 功能，且增加城区/高速自动驾驶功能、泊车自动驾驶功能）。蔚来、理想、小鹏在 2022 年几 乎同时完成高阶自动驾驶的硬件方案升级，未来将通过 OTA 逐步实现 L3 甚至 L4 级别的应用功能落地。

3.5.3 格局：核心功能整车厂把控，应用生态众人参与

应用软件主要包括自动驾驶类功能与智能座舱类功能，两类软件未来格局演进的趋势有所差异： 自动驾驶技术壁垒高，是构建产品核心差异的所在，除成熟的 ADAS 功能可由供应商完成外，中高阶自动 驾驶功能将由整车企业自研。应用软件是整车企业实现软件全栈自研的主阵地。 智能座舱应用软件核心在于应用生态的扩展，这意味着整车厂不可能完成所以应用软件的开发，比如地图 导航有高德等、语音交互有科大讯飞等、车载 KTV 有雷石等。如同手机电脑，整车企业为智能座舱搭建平台， 导入各类应用丰富生态。随着 SOA 软件架构成熟后，智能座舱的应用生态将快速扩张，吸引各类供应商参与 构建智能汽车生态系统。

（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）

精选报告来源：【未来智库】。未来智库 – 官方网站