自动驾驶之软件定义汽车
软件定义汽车时代下，智能汽车软件架构逐步向 SOA 迈进，软件成为智能汽车差异化的核心
汽车智能化的大趋势下，“软件定义汽车”成为产业共识。简单来说，软件定义汽车（Software Defined Vehicles，SDV）。
指的是软件将深度参与到汽车定义、开发、验证、销售、服务等过程中， 并不断改变和优化各个过程，实现体验持续优化、过程持续优化、价值持续创造。
目前，不同车型在硬件配置方面逐渐趋同，各大车企在硬件领域已经经历了漫长的竞争，硬件及其成本持续改 善的空间较为有限。
相较于传统汽车，智能汽车能为车主创造丰富的、可感知的价值以及全新的驾驶体验，这也是当前不同汽车形成差异化的关键。
因此，软件和算法逐步成为了车企竞争的核心要素，造车的壁垒也由从前的上万个零部件拼合集成能力演变成将上亿行代码组合运行的能力。
软件价值不断提升，全球汽车软件市场将快速增长。据麦肯锡预测，全球汽车软件与硬件产品内 容结构正发生着重大变化，2016年软件驱动占比从 2010 年的 7%增长到 10%。
预计 2030 年软件驱动的占比将达到 30%。从规模上来看，全球汽车软件市场规模将从2020 年的 350 亿美元增 长到840 亿美元，未来将有巨大的空间。
竞逐智能化下半场，软件及计算能力成为新时代下汽车的核心。智能化、网联化、电动化、共享 化已成为汽车产业变革的必然趋势。
汽车产品逐步由传统代步机械工具向新一代具备感知和决策能力的智能终端转变。在汽车“新四化”浪潮的变革趋势下。
比亚迪董事局主席兼总裁王传福曾 在2021联想创新科技大会上表示：“电动化是上半场，智能化是下半场。智能化是更大的变革， 创造的生态超乎想象。”
在电动汽车时代，电池、电驱等三电核心技术是比亚迪的护城河，王传 福认为，在下一个汽车时代软件决定了汽车竞争力。
在2021华为智能汽车解决方案生态论坛上， 华为智能汽车解决方案 BU CEO 余承东同样表示，电动化、网联化、智能化的时代已经到来与 传统汽车相比。
智能汽车的本质已经发生了改变，计算和软件成为了汽车的核心。可以预见的是， 未来汽车智能化将成为各大车厂竞逐的焦点，而软件能力将成为定义整车功能的关键。
“硬件预埋，软件升级”成为车企主流策略，未来汽车软件、算法优化空间巨大。当前面向量产 乘用车的智能驾驶系统整体处于 L3 及以下级别，智能驾驶技术仍在持续迭代升级中。
汽车产品具 备较长的生命周期，一般为 5-10 年，车载计算平台的算力上限决定车辆生命周期内可承载的软件服务升级上限。
相较而言软件迭代更快，因此智能驾驶软件迭代周期与硬件更换周期存在错位。 为保证车辆在全生命周期内的持续软件升级能力。
主机厂在智能驾驶上采取“硬件预置，软件升 级”的策略，通过预置大算力芯片，为后续软件与算法升级优化提供足够发展空间。
以蔚来、智 己、威马、小鹏为代表的主机厂在新一代车型中均将智能驾驶算力提升至 500-1000Tops 级别。
我国智能汽车产业发展速度领先世界，L3 及以上级别自动驾驶落地有望为行业带来更大机遇。在 巨大的消费需求推动下，我国汽车产业链中的企业密切合作。
不仅构建了良性互动的生态环境， 并且推动着行业标准水平快速提升。根据 IHS Markit 数据，我国 2020年智能座舱新车渗透率达 48.8%，且到 2025 年预计可以超过 75%。
无论是渗透率还是渗透率提升速度均高于全球水平。 盖世汽车 CEO周晓莺女士也指出，目前我国自动驾驶产业发展处于世界领先水平。
从座舱域到驾 驶域，近年来高算力芯片的问世加速了智能汽车向更高级别自动驾驶的演进，例如英伟达推出的 Xavier（30TOPS）、DRIVE Orin（254TOPS）、DRIVE Atlan（1000TOPS）。
而根据地平线 数据，实现 L3 自动驾驶的算力需达 20-30TOPS，到 L4 级需要 200TOPS以上，可见当前芯片算 力方面已为 L3 及更高级别的自动驾驶“做好了准备”。
根据艾瑞咨询，随着智能驾驶相关上路法 规的不断完善，L3 级别有条件自动驾驶乘用车有望在 2023 年开始逐步落地。结合我国新势力车 企对于今年新车型的大算力预埋。
我们认为，2022-2023 年将成为 L3及更高级别自动驾驶发展的 关键节点，具有领先软件和算法能力的车企、软件供应商有望获得重要机遇。
软硬件解耦带动汽车软件架构向 SOA 演进，传统汽车分布式的 EE 架构难以适应软件定义汽车的时代需求：
在传统 EE 架构中软硬件高度嵌套，软件功能的实现更加依赖于硬件。若要新增单一功能， 需要改变所有与其相关的ECU 软件，同时也要修改车内电线、线束布线等，功能或系统升级 的复杂性极大，车企集成验证更为困难。
若要实现较为复杂的功能，则需要多个控制器同时 开发完成才能进行验证，一旦其中任意一个控制器出现问题，可能导致整个功能全部失效；
在传统分布式 EE 架构之下，ECU 由不同的供应商开发，框架无法复用，无法统一。同时， OTA 外部开发者无法对 ECU 进行编程，无法由软件定义新的功能，以进行硬件升级；
基于传统分布式 EE 架构，车企只是架构的定义者，核心功能是由各个 ECU 完成，其软件开 发工作主要是由 Tier1 完成。主机厂只做集成的工作，这也导致过去大部分主机厂自身的软 件开发能力较弱。
随着汽车不断向智能化、网联化方向发展，以单片机为核心的传统分布式电子电气架构已经很难 满足未来智能汽车产品的开发需求，同时还面临算力束缚、通讯效率缺陷、以及不受控的线束等 成本黑洞。
因此，汽车电子电气架构从传统分布式架构正在朝向域架构、中央计算架构转变，而 集中化的 EE 架构是实现软件定义汽车重要的硬件基础。
在集中化的 EE 架构下软硬件解耦，软件开发逐渐通用化、平台化。分布式软件架构是一种面向 信号的架构，控制器之间通过信号来传递信息，整个系统是封闭、静态的。
在编译阶段就被定义 完成，因此若主机厂要修改或增加某个控制器的功能定义，同时该指令还必须调用另一个控制器 上的功能时，就不得不把所有需要的控制器都升级，大大延长开发周期、增加开发成本。
此时， 软硬件高度嵌套，硬件之间难以形成较强的协同性，汽车软件的可复用性和 OTA 升级能力整体较 弱。随着汽车 EE 架构逐步趋于集中化。
域控制器或中央计算平台以分层式或面向服务的架构部 署，ECU 数量大幅减少，汽车底层硬件平台需要提供更为强大的算力支持，软件也不再是基于某 一固定硬件开发。
而是要具备可移植、可迭代和可拓展等特性。汽车原有以 ECU 为单元的研发组 织将发生转变，形成通用硬件平台、基础软件平台以及各类应用软件的新型研发组织形态。
为实现软件定义汽车，智能汽车软件架构需向 SOA 转型升级。过去汽车软件架构更多是面向信 号的架构（Signal-Oriented Architecture），ECU 的功能是固定的，软件被提前编写在控制器中。
但随着智能汽车的发展，车内搭载的 ECU 数量快速增加，这不仅使 ECU 的点对点的通讯变得十 分复杂，且不具备灵活性和扩展性，微小的功能改动都会引起整车通讯矩阵以及各 ECU 软件的变 动。
SOA（Service-Oriented Architecture，面向服务的软件架构）是一种软件架构，同时也是一 种软件设计方法和理念，其具备接口标准化、松耦合、灵活易于扩展等特点：
首先，在 SOA 架构中每一个服务都具有唯一且独立互不影响的身份标识（ID），界定了清晰 的功能范围，并通过服务中间件（Service Middleware）完成自身的发布、对其他服务的订 阅以及与其他服务的通讯工作。
因此，SOA架构解决了传统架构中因个别功能增减/变更而导 致整个通讯矩阵与路由矩阵都要变更的问题。同时，SOA 架构中每一个服务组件接口都是 “标准可访问”的。
服务组件的设计、部署不再依赖于具体特定的硬件平台、操作系统和编 程语言，同样的组件/功能可以通过标准化接口在不同的车型上实现复用，实现组件的“软硬 分离”。
在智能汽车时代，软件的迭代周期越来越短，独立于硬件的软件升级是持续为客户提供价值 的关键。由于 SOA 架构具有“松耦合”的特性。
服务组件和硬件均可以标准化地接入和访问， 若要新增某一功能只需增加相应的服务组件并使其调用不同的硬件功能即可。
因此在 SOA 架构下，开发人员可更多地专注于上层应用的开发，而无需再对底层算法甚至各个 ECU 中的软 件进行重新编译。
这也解决了相同的应用在不同车型及硬件环境下重复开发的痛点，使得汽 车软件架构十分灵活并易于拓展。
在软硬件解耦以及汽车软件架构向 SOA 转型的背景下，汽车软件产业链正逐渐被重塑：
主机厂开始重视软件能力的构建，通过建立软件自研能力、系统架构能力以及 SOA 架构能力 以强化软硬件解耦。
目前大部分车企已经完成了软件自研能力补充或升级，建立起了平台型 架构体系，车企的传统开发模型也正向面向软件定义汽车的开发模型升级。
软件供应商一跃成为 Tier1 供应商。由于汽车软件开发难度提升，传统的汽车零部件供应商 研发能力难以满足需求，此时车厂开始绕过传统一级供应商，直接与原有的二级供应商（芯 片、软件算法等厂商）合作。
在软件定义汽车时代，软件重要性不言而喻，整车厂为了掌握 主导权并降低高昂的研发成本，往往会选择直接与具备较强的独立算法研发能力的软件供应 商合作。
因此这些软件供应商一跃成为了 Tier1 厂商。未来，软件供应商的盈利模式有望发 生转变，开发基础平台收许可费、供应功能模块按 Royalty 收费及定制化的二次开发等方式 或成为主流打法。
主机厂纷纷布局 SOA软件架构的开发，未来几年内或迎来 SOA量产的高峰期。当前大部分OEM 主机厂仍处于硬件架构升级的阶段。
目前仅有特斯拉、大众完成了定制 OS 内核的开发构建和规 模化应用，汽车软硬件解耦也处于发展初期，现阶段主机厂纷纷将底层基础软件（系统软件层） 作为发展重点。
从长期来看，SOA 将重构汽车生态，汽车行业很可能复制 PC 和智能手机的软件 分工模式。车企可通过自建或与供应商合作搭建操作系统和 SOA 平台。
引入大量的算法供应商、 生态合作伙伴等形成开发者生态圈，未来车企能够向用户提供全生命周期的软件服务。这一背景 下，主机厂纷纷布局 SOA 软件架构的开发，未来几年有望成为 SOA 量产的高峰期。
智能汽车软件架构梳理
纵观智能汽车软硬件架构，最底层的是车辆平台以及外围硬件（传感器、V2X、动力及底盘控制 等），在其之上的是自动驾驶计算平台，而这也是实现汽车智能化的核心。
进一步来看，自动驾 驶计算平台可以分为硬件平台和软件两大部分，其中软件层面自下而上分别为：
系统软件：由硬件抽象层、OS 内核（狭义上的操作系统）和中间件组件构成，是广义操作 系统的核心部分；
功能软件：主要为自动驾驶的核心共性功能模块，包括自动驾驶通用框架、AI 和视觉模块、 传感器模块等库组件以及相关中间件。系统软件与功能软件构成了广义上的操作系统。
应用软件：主要包括场景算法和应用，是智能座舱（HMI、应用软件等）以及自动驾驶（感 知融合、决策规划、控制执行等）形成差异化的核心。
系统软件：提供基础功能和底层环境支持，是操作系统的 核心
系统软件是车载操作系统的基础，不仅为上层应用以及功能的实现提供了高效、稳定环境的支持， 也是各类应用调度底层硬件资源的“桥梁”。
在智能汽车整体软硬件架构中处于核心的位置。通常来说，系统软件由硬件抽象层、OS 内核（狭义上的操作系统）和中间件组件三部分构成。
硬件抽象层：Hypervisor 与 BSP 搭建软硬件间的“桥梁”
在汽车电子电气系统中，不同的 ECU 提供不同的服务，同时对底层操作系统的要求也不同。根 据 ISO 26262 标准，汽车仪表系统与娱乐信息系统属于不同的安全等级，具有不同的处理优先级。
汽车仪表系统与动力系统密切相关，要求具有高实时性、高可靠性和强安全性，以 QNX操作系统为主；而信息娱乐系统主要为车内人机交互提供控制平台，追求多样化的应用与服务，主要以 Linux 和 Android 为主。
在 EE 架构趋于集中化后，虚拟化（Hypervisor）技术的出现让“多系统”成为现实。在电子电 气系统架构从分布式向域集中式演进的大背景下，各种功能模块都集中到少数几个计算能力强大 的域控制器中。
此时，不同安全等级的应用需要共用相同的计算平台，传统的物理安全隔离被打 破。虚拟化（Hypervisor）技术可以模拟出一个具有完整硬件系统功能、运行在一个完全隔离环 境中的计算机系统。
此时供应商不再需要设计多个硬件来实现不同的功能需求，而只需要在车载 主芯片上进行虚拟化的软件配置，形成多个虚拟机，在每个虚拟机上运行相应的软件即可满足需 求。
Hypervisor 提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠 性和故障控制机制。
以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的 安全隔离，实现了车载计算单元整合与算力共享。
在车载虚拟化领域，主流的 Hypervisor 技术提供商包括 BlackBerry QNX Hypervisor（闭源） 及 Intel 与 Linux 基金会主导的 ACRN（开源）。
目前，只有 QNX Hypervisor 应用到量产车型， 它也是目前市场上唯一被认可功能安全等级达到 ASIL D 级的虚拟化操作系统。
国内厂商也纷纷加入两大主流虚拟机技术生态：2017 年，中科创达与诚迈科技入选黑莓 VAI 计划（该计划将建立一 个基于黑莓 QNX 嵌入式技术和 Certicom 安全技术的全球专家网络，旨在拓展嵌入式软件市场）。
公司可以基于黑莓的嵌入式技术开发集成服务、安全关键型解决方案；东软集团在 ACRN 项目早 期就成为了其会员；2019 年，ACRN 与润和软件建立战略合作伙伴关系。
BSP 可支持操作系统更好地运行于硬件主板。BSP（Board Support Package）指板级支持包。 对于一般的嵌入式系统，硬件部分需要嵌入式硬件工程师设计硬件电路。
而新出厂的电路板需要 BSP 来保证其能稳定工作，在此基础之上才能进行下一步的软件开发。BSP 是介于主板硬件和操 作系统之间的系统软件之一，主要目的是为了支持操作系统，使之能够更好的运行于硬件主板。
BSP 是相对于操作系统而言的，不同的操作系统对应于不同定义形式的 BSP。例如 VxWorks 的 BSP 和 Linux 的 BSP 相对于某一 CPU 来说尽管实现的功能一样。
可是写法和接口定义是完全不 同的，所以写 BSP 一定要按照该系统 BSP 的定义形式来写，这样才能与上层 OS 保持正确的接 口。
由于 BSP 处于在硬件和操作系统、上层应用程序之间，因此 BSP 程序员需要对硬件、软件 和操作系统都要有一定的了解。
OS 内核：QNX 、Linux、VxWorks 为主流
汽车操作系统可分为狭义 OS 和广义 OS，OS 内核属于狭义 OS。如前文所述，汽车的自动驾驶 计算平台分为四个层级，从下到上分别为硬件层、系统软件层、功能软件层、应用软件层。
广义 OS 指系统软件层（包括硬件抽象层、OS 内核、中间件组件）与功能软件组成的软件集合，而狭 义 OS 仅单指 OS 内核。
具体来说，OS 内核又称为“底层 OS”，提供操作系统最基本的功能， 负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性，是 系统软件层的核心。
当前，狭义 OS 的内核呈现 QNX、Linux 和 VxWorks 三足鼎立的局势。自动驾驶 OS 内核的格 局较为稳定，主要玩家为 QNX（Blackberry）、Linux（开源基金会）、VxWorks（风河）。
因打 造全新 OS 需要花费太大的人力、物力，目前基本没有企业会开发全新的 OS 内核。当前，无论是 Waymo、百度、特斯拉。
Mobileye 还是一些自动驾驶初创公司、车企，所谓的自研自动驾驶 OS，都是指在上述现成内核的基础之上自研中间件和应用软件。
QNX、Linux 和 VxWorks 三大内核有以下区别：
实时性：以是否对需要执行的任务划分优先级为标准，OS 内核可分为分时 OS（TimeSharing OS）和实时 OS（Real-time OS）两种。
前者对各个用户/作业都是完全公平的，不 区分任务的紧急性；而后者指在高优先级的紧急任务需要执行时，能够在某个严格的时间限 制内抢占式切换到该任务上。
实时 OS 还可以分为硬实时和软实时两类：硬实时系统有一个 刚性的、不可改变的时间限制，它不允许任何超出时限的错误；而软实时系统的时限是一个 柔性灵活的，它可以容忍偶然的超时错误。
QNX 和 VxWorks 均属于实时 OS，且均属于硬实 时 OS。最初 Linux 属于分时 OS，但 Linux 对实时性改进的工作从未停止过。
经过优化后， Linux内核也分为抢占式内核和非抢占式内核，其中，抢占式内核的实时性足以满足自动驾驶 的需求。因此，实时性大幅改善的 RT Linux 实际上已经成为硬实时操作系统。
开放性：QNX是一个半封闭系统，而 Linux和 VxWorks 均是开源系统。所谓“半封闭”，即 QNX 的内核，客户是不能改的，但客户可自己编写中间件和应用软件；
所谓开源，即所有内 核源代码都向客户开放，客户可根据自己的实际需求裁剪，可配置性很高。与 QNX 相比， Linux 更大的优势在于开源。
在各种 CPU 架构上都可以运行。可适配更多的应用场景，并有 更为丰富的软件库可供选择，因此具有很强的定制开发灵活度。
VxWorks 也是开源的，VxWorks RTOS 由 400 多个相对独立、短小精悍的目标模块组成，用户可获所有源代码并根 据需要对 OS 内核在源代码层面进行裁剪和配置。
内核架构：QNX 与 VxWorks 是微内核，即内核中只有最基本的调度、内存管理，驱动、文 件系统等都是用户态的守护进程去实现的。
微内核的优点是稳定、漏洞少，驱动等的错误只 会导致相应进程发生 Bug，不会导致整个系统都崩溃，同时具有灵活性高、易扩展的特点 可以便捷地在操作系统中增减功能；缺点是频繁的系统调用与信息传递使 OS 运行效率较低
Linux是宏内核，即除了最基本的进程、线程管理、内存管理外，文件系统，驱动，网络协议 等等都在内核里面，其优点是效率高，可以充分发挥硬件的性能；
缺点是内核结构复杂，稳 定性较差，开发进程中的 Bug 可能会导致整个系统崩溃，因此基于 Linux 开发的门槛很高。
是否付费：QNX 凭借其安全性、稳定性和实时性占据汽车嵌入式操作系统市占率第一的位置 但 QNX 是需要商业收费的。虽然 VxWorks 和 Linux 同为开源系统，但区别在于 Linux 是免 费的，而 VxWorks 是收费的。
QNX 与 VxWorks 均需收取高昂的授权费，开发定制成本也很 高，这也会在一定程度上阻碍其市场占有率的增长；相较而言，Linux的免费也会对车企有很 强的吸引力。
综上，车企在选择 OS 内核时，主要考虑开放性、可扩展性、易用性、安全性、可靠性及成本等 因素，再结合自己的需求及能力体系来做权衡。
中间件：AUTOSAR 标准应用最为广泛
中间件位于硬件及操作系统之上，应用软件之下，是汽车软件架构中重要的基础软件。中间件 （middleware）是基础软件的一大类，在汽车软件架构中位于硬件、操作系统之上，应用软件的 下层。
总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开 发和集成复杂的应用软件，并能在不同的技术之间实现资源共享并管理计算资源和网络通信。
软件定义汽车时代下，中间件的作用愈发重要。随着 EE 架构逐渐趋于集中化，汽车软件系统出 现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的剧增。
为了提高软件的管理 性、移植性、裁剪性和质量，需要定义一套架构（Architecture）、方法学（Methodology）和应 用接口（Application Interface），从而实现标准的接口、高质量的无缝集成、高效的开发以及通 过新的模型来管理复杂的系统。
中间件的核心思想在于“统一标准、分散实现、集中配置”：统 一标准才能给各个厂商提供一个通用的开放的平台；分散实现则要求软件系统层次化、模块化， 并且降低应用与平台之间的耦合度；
由于不同模块来自不同的厂商，它们之间存在复杂的相互联 系，要想将其整合成一个完善的系统，必须要求将所有模块的配置信息以统一的格式集中管理起 来，集中配置生成系统。
有了汽车软件中间件后，所有的软件和应用都具备了标准化接口，同时 硬件功能也被抽象成服务，可以随时被上层应用调用；软件开发可以跨配置、跨车型、跨平台、 跨硬件适应；
软件开发者可以更多地聚焦软件功能的差异化；软件认证可以有标准可依。因此， 可以说中间件在汽车软硬件解耦的趋势中发挥了关键的作用。
在所有中间件方案中，AUTOSAR 是目前应用范围最广的车载电子系统标准规范。AUTOSAR （Automotive Open System Architecture）指汽车开放架构，是由全球汽车制造商。
零部件供应 商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架，并建立了一个开 放的汽车控制器（ECU）标准软件架构，规范了车载操作系统标准与 API 接口。
2003 年 7 月，宝 马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众等 9 家汽车行业巨头发起了 AUTOSAR联盟的建立，这 9 家公司后来也成为 AUTOSAR 联盟的核心成员。
截至 2021年 7月， AUTOSAR 联盟已经拥有了 300 多家合作伙伴，包括全球各大主流整车厂、一级供应商、标准软 件供应商、开发工具与服务提供商。
半导体供应商、高校以及研究机构等，其中也包括了华为、 百度、长城、东风、一汽、上汽、吉利、蔚来、拜腾、宁德时代等国内厂商。
AUTOSAR 旨在通过提升 OEM 以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽 车电子电气架构的管理。
汽车行业中有众多的整车厂和供应商，每家 OEM 会有不同的供应商以 及车型，每个供应商也不止向一家 OEM 供货，此时若尽可能地让相同产品在不同车型可重复利 用或是让不同供应商的产品相互兼容，这样就能大幅减少开发成本。
为此，AUTOSAR 联盟建立 了独立于硬件的分层软件架构；为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将 应用软件整合至 ECU；
制定了各种车辆应用接口规范，作为应用软件整合标准，以便软件在不同汽车平台复用。有了标准化应用软件和底层软件之间的接口，开发者可以专注于功能的开发，而 无需顾虑目标硬件平台。
目前，AUTOSAR 拥有 Classic Platform 和 Adaptive Platform 两大平台，分别对应传统控制类车 辆电子系统与对应自动驾驶的高性能类车载电子系统：
Classic Platform（CP）：Classic Platform 是 AUTOSAR 针对传统车辆控制嵌入式系统的 解决方案，具有严格的实时性和安全性限制。
从架构来看，Classic Platform 自下而上可大致 分为微控制器、基础软件层、运行环境层和应用软件层。
Classic 平台软件架构实现了汽车软 件的层次化与模块化，将硬件依赖和非硬件依赖的软件进行了封装。
同时，如果使用工具链 进行开发，基础软件可以通过配置参数即可实现功能剪裁、算法逻辑，便于基础软件的开发。
此外，接口的标准化便于基础软件与硬件抽象层软件对接，缩短开发周期的同时也为OEM提 供了更多的选择空间。
Adaptive Platform（AP）：Adaptive Platform 是 AUTOSAR 面向未来自动驾驶、车联网等 复杂场景而提出的一种新型汽车电子系统软件架构标准。
Adaptive平台修改了大量Classic平 台标准的内容，采用了基于 POSIX 标准的操作系统，以面向对象的思想进行开发，并且可使 用所有标准的 POSIX API。
主要目的是为满足当前汽车自动驾驶、电气化和互联互通等趋势 的需求。Adaptive Platform 自下而上可分为三层：
硬件层：AP 可将运行的硬件视作 Machine，这也意味着硬件可以通过各种管理程序相关技术进行虚拟化，并可实现一致的平 台视图；
实时运行环境层（ARA）：由功能集群提供的一系列应用接口组成，分为 API 和 service 两种接口类型；应用层：运行在 AP 上的一系列应用。
Adaptive Platform 相较 Classic Platform 更加适应于当前汽车架构向 SOA 转型的大趋势。如 前文所述，当前汽车架构中同一硬件平台可能集成了多种系统。
例如车载信息娱乐相关的 ECU 通 常使用 Linux、QNX 或其他通用操作系统。尽管 Classic Platform 支持 AUTOSAR OS（OSEK OS），而 Adaptive Platform 支持虚拟化技术以及多系统并存的架构。
只要是 POSIX OS 都可使 用，包括那些达到 ASIL-D 的操作系统，兼容性广，可移植性高，因此 AP 相较 CP 更有优势。
此 外，CP 主要支持面向信号的架构（Signal-Oriented Architecture），以基于信号的静态配置的通 信方式（CAN、LIN）为主，开发后功能升级较为困难；
AP 主要支持面向服务的软件架构 （SOA），以基于服务的 SOA 动态通信方式（SOME/IP）为主，硬件资源间的连接关系虚拟化， 不局限于通信线束的连接关系，软件也可实现灵活的在线升级。
因此，AP 更专注于提供高性能计 算和通讯机制，提供了灵活的软件配置方式，更加适用于当前智能汽车领域高速发展的时代。
面向全新 E/E 架构的智能汽车，AUTOSAR 和中间件 OS 将是众多 Tier1 的发力重点。目前全球 知名的 AUTOSAR 解决方案厂商包括 ETAS（博世）。
EB（Continental）、Mentor Graphics （Siemens）、Wind River（TPG Capital）、Vector、KPIT（美印合资）等。
在国内，Classic AUTOSAR 标准下的开发工具链及基础软件由海外供应商占据主导地位，包括 EB、ETAS、 Vector 等，国内厂商主要包括东软睿驰、华为、经纬恒润等；
国内 Adaptive AUTOSAR 仍处于起 步阶段，大陆 EB 与大众合作将 AP AUTOSAR 和 SOA 平台应用于大众 MEB 平台 ID 系列纯电动 车型上。
此前国内汽车基础软件架构标准及产业生态整体较为落后，在汽车智能化转型升级的趋 势下，国内厂商纷纷将 AP AUTOSAR 作为发力重点，推出相应的中间件及其工具链产品，抢占 市场先机。
功能软件：提供自动驾驶的核心共性模块，支撑自动驾驶技术的实现
汽车软件架构中，功能软件层主要包含自动驾驶的核心共性功能模块以及相关中间件。根据 SOA 架构设计理念，通过提取自动驾驶核心共性需求。
形成了自动驾驶共性功能模块，主要包括自动 驾驶通用框架模块、网联模块、云控模块、AI 与视觉模块、传感器模块等。
利用这些共性功能模 块，开发者可更高效地进行自动驾驶业务层面的研发，缩短了智能驾驶系统的开发周期；主机厂 基于自身策略，在设计和开发功能软件时可以选择不同的功能模块和算法组件。
实现拼插式功能 组合，灵活构建智能驾驶系统级解决方案，这也降低了系统集成成本。功能软件层中，中间件同 样可对软硬件资源进行管理、分配和调度。
例如对传感器、计算平台等资源进行抽象，对算法、 子系统、功能采取模块化的管理，并通过提供的统一接口。功能软件与系统软件共同构成了广义 的自动驾驶操作系统，支撑着自动驾驶技术实现。
自动驾驶通用框架模块：自动驾驶通用框架模块是功能软件的核心和驱动部分
L3 及以上等 级自动驾驶系统具备通用、共性的框架模块，如感知、规划、控制等及其子模块
一方面， 自动驾驶会产生安全和产品化的共性需求，通过设计和实现通用框架模块来满足这些共性需 求，是保障自动驾驶系统实时、安全、可扩展和可定制的基础；
另一方面，重点算法（特别 是人工智能算法）仍在不断演进，如基于 CNN 框架的深度学习感知算法、基于高精度地图等 多源信息融合定位算法、基于通用 AI 和规划的决策规划算法和基于车辆动力学模型的控制算 法等。
自动驾驶通用框架模块定义了核心、共性的自动驾驶功能和数据流，并包含共性模块 的实现；提供对外接口 API 和服务，以接入非共性或演进算法、HMI 等；
通用框架模块也会 调用自动驾驶操作系统内的云控、网联、信息安全等功能软件模块，或使用这些模块提供的 服务。
通用框架模块的设计和实现，可以充分利用市场不断成熟的、不同领域的算法子模块， 促进产品高质高效的快速迭代。
网联模块：网联模块是自动驾驶操作系统功能软件中实现网联通信、处理网联数据的功能子 模块
除满足常规网联服务场景要求外，该子模块通过完善通用框架模块设计实现网联协同 感知、网联协同规划、网联协同控制等网联自动驾驶功能。
网联数据通过 V2X（车用无线通 信技术）获得，包括路测数据、摄像头、智能信号灯、道路交通提示预警等信息及其他车辆信息等。
与单车传感器系统的多种探测手段相结合和融合处理，能够有效实现单车感知范围 到数百米，车辆间防碰撞，根据预警直接控制车辆启停等重要感知、规划和控制功能。
单车 智能化与 V2X 网联功能的有机结合增强自动驾驶系统整体的感知、决策和控制能力，降低自 动驾驶成本，最终实现无人驾驶。该子模块是智能网联汽车的典型特征，也是自动驾驶操作 系统的核心功能之一。
云控模块：云控模块是与云控基础平台交互的功能子模块
云控基础平台为智能网联汽车及 其用户、管理及服务机构等提供车辆运行、基础设施、交通环境等动态基础数据。云控基础 平台具有高性能信息共享、高实时性云计算、多行业应用大数据分析等基础服务机制。
云控 模块通过自动驾驶通用框架模块的支持，提供云控基础平台所需的数据支撑，同时通过高速 通信与中心云/边缘云进行云端感知。
规划和控制等数据的实时同步，实现云-端分工协同， 如基于广泛多车感知的云端感知、云端多车感知融合和云端最终裁决等。
AI 与视觉模块：功能软件需要支持深度学习嵌入式推理框架，便于成熟算法移植和适配。自 动驾驶是深度学习算法的重要应用场景。
尤其在视觉、激光雷达及决策规划方面。算法企业、 科研机构进行了长期且富有成效的研究和产品化工作。
自动驾驶操作系统功能软件中需要支 持深度学习嵌入式推理框架（如 TensorRT），并兼容 TensorFlow 和 Caffe 等主流训练开发 框架的深度学习模型，便于已有成熟算法和开发生态的移植和适配。
传感器模块：传感器模块规范和模块化各类自动驾驶传感器，为传感数据融合提供基础
L3 及以上等级自动驾驶技术方案多依赖激光雷达、摄像头、毫米波雷达等不同类型、不同安装 位置的传感器，这些传感器硬件接口、数据格式、时空比例、标定方法不同。
针对传感器的 多样性、差异性和共性需求，自动驾驶操作系统功能软件中预置传感器模块来规范和模块化 自动驾驶各类传感器，为异构传感器信息融合处理提供基础。
功能软件开发涉及多方合作，Tier1 与软件算法厂商可为主机厂提供相应的优势解决方案。自动 驾驶功能软件平台设计规范将解耦的功能软件标准化和平台化，明确了各功能模块之间的接口定 义。
基于标准规范和开放接口，功能软件组件的生产就可变成类似于汽车传统零部件的生产方式， Tier1、软件算法厂商以及主机厂等参与方可凭借自身优势提供解决方案。
例如在AI和视觉领域有 优势的算法厂商可以专注于功能软件中 AI 和视觉模块的开发，传感器厂商（Tier1）可与主 机厂共同对功能软件中传感器模块进行开发。
因此，自动驾驶功能软件平台设计规范的制定建立 了有序、高效、敏捷的汽车软件供应链体系，实现了更有效的分工与合作。
为自动驾驶解决方案 供应商提供更多的应用需求，也为主机厂提供了更灵活的选择，极大地促进了自动驾驶的落地以 及产业化发展。
应用软件：智能汽车差异化的核心
应用软件层主要包括智能汽车场景算法、座舱功能、数据地图等内容，是智能座舱（HMI、应用 等）以及自动驾驶（感知融合、决策规划、控制执行等）形成差异化的核心，位于汽车软件架构 最上层。
过去的汽车供应链一般是由实力强劲的 Tier1 提供软硬件一体化的“黑盒”产品，软硬 件解耦难度非常高。
在软件定义汽车时代，汽车电子零部件也将像过去的传统机械、车身零部件 一样加速“白标化”，硬件差异化越来越小，利润也愈发透明，“硬件成本价”售车成为可能性。
软件则将成为汽车的灵魂和 OEM 的新的利润中心。车辆的差异化和盈利能力将向技术和相关软 件堆栈转移，其中主要包括智能座舱、自动驾驶、数据地图/车路协同等方面。
智能座舱相较自动驾驶技术实现难度更低，有助于迅速提升产品差异化竞争力。由于自动驾驶软 件及算法开发难度及测试难度较大，同时目前政策法规方向尚不完善，因此自动驾驶的整体的市 场成熟度仍然不高。
目前在整车智能化转型时代，智能座舱能集成更多的信息和功能，给用户带 来更直观、更个性化的体验，从而成为整车智能化的先行者。
根据 IHS Markit 调查，虽然座舱智 能科技配置需求的相关消费习惯尚在培育阶段，但仍有超过 60%的用户认可座舱配置的价值并有 望实现需求的转化。
反映出用户层面的座舱智能配置需求有很大的上升空间。未来，我国智能座 舱新车渗透率将快速提升，到 2025 年预计可以超过 75%，高于全球市场装配水平。
自动驾驶由低速向高速演进需要长时间的训练和算法积累，未来空间巨大。目前，L3 及以上级别 的自动驾驶有望在封闭、半封闭和低速场景下率先应用。
自主泊车作为自动驾驶的低速复杂场景， 将为自动驾驶技术演进提供低速域的数据训练和积累。尽管自动驾驶高速场景的商业化落地还有 一定距离。
但特斯拉、谷歌、百度等厂商依旧把目光放在了高级别的自动驾驶上，为的就是在行 业拐点来临之前占得先机。根据 IHS 的预测，自动驾驶汽车将在 2025 年前后开始一轮爆发式增长
到2035年，道路行驶车辆将有一半实现自动驾驶，届时自动驾驶整车及相关设备、应用的收 入规模总计将超过五千亿美元。
根据 CIC 预测，预计到 2025 年我国自动驾驶市场空间接近 4000 亿元，2020-2025 年 CAGR 接近 107%，远快于全球市场增速。
高级别的自动驾驶的实现需要高精度定位与地图的支持。车路协同是目前业界普遍认为实现智能 驾驶的关键路径之一，智能汽车将逐步从单车智能向车路协同迈进。
与智能摄像头、毫米波雷达、 激光雷达等类似，C-V2X 是通过“车、路、云”的协同以获得其他车辆、行人运动状态的另一种 信息交互手段。
由于高速自动驾驶需要对更远的行人、车辆的运动状态做出实时的判断，加之可 能存在天气、障碍物等因素的影响，仅靠单辆车的传感器难以对路况做出实时判断，此时就离不 开路端的信息来为智能车的驾驶决策来做补充。
车联网将定位技术、传感器技术、通信技术、互 联网技术等先进技术进行有机结合，而高级别的自动驾驶更是需要车联网的支持。
其中定位技术 （包括高精地图）是车联网关键之一，是车辆在高速状态下实现安全行驶的重要保障。
在 SOA 和分层解耦趋势下，OEM、传统 Tier1 和软件供应商分别采取了不同的应对策略，以融 入应用软件的开发生态：主机厂向软件转型主要有三种路径模式：
成立软件子公司：实现全栈技术自研布局，OEM 逐渐掌握软件、算法、芯片等全技术栈的自 主研发能力，一定程度上绕过传统 Tier1，与过去二级软件供应商共同开发子系统，如上汽零 束软件、长安汽车软件科技公司等；
成立软件研发部门：通过合作、投资等方案与核心技术厂商直接合作，最大程度实现自主可 控，主要在某一项或多项具备战略性差异的领域建立 in-house 的研发能力，部分共性软件外包。
例如蔚来、小鹏等初创企业，由于体量较小更加灵活，无须面面俱到，专注于智能座舱、 自动驾驶核心应用软件的开发，组建了规模庞大的自研团队。
与软件企业战略合作：OEM 一边扩充内部研发队伍，一边与软件企业建立战略联盟，主机厂 推进软件生态建设，但执行由软件 Tier1 来实现。例如广汽研究院与东软睿驰、中科创达等 组建联合创新中心。
传统 Tier1 需要打造软硬一体的能力。对于传统 Tier1 来说，部分系统功能开发权被主机厂收回是大势所趋，因此传统Tier1迫切需要转型寻求新的出路，避免沦为硬件代工商。
目前来看， 软硬件全栈能力的打造，是抢占下一个市场份额制高点的关键所在，这一点，传统 Tier1 巨头深 谙其道。
更多的 Tier1 致力于打造“硬件+底层软件+中间件+应用软件算法+系统集成”的全栈技 术能力，典型代表如博世、华为、德赛西威等，既能为客户提供硬件、也能提供软件，同时也提 供软硬一体化的解决方案。
软件供应商需要不断丰富产品矩阵，并逐步提升硬件能力。随着 OEM 主机厂自主权和软件 自研能力的不断加强，OEM 主机厂开始寻求与软件供应商的直接合作。
比如 OEM 厂商将首先寻 求将座舱 HMI 交互系统功能收回，UI/UX 设计工具、语音识别模块、音效模块、人脸识别模块等 应用软件则直接向软件供应商购买软件授权，从而绕过了传统 Tier1，实现自主开发。
对于软件供 应商来说，能提供越多的软件 IP 产品组合，就可能获取更高的单车价值。同时，软件供应商也正 寻求进入传统 Tier1把持的硬件设计、制造环节，比如域控制器、TBOX等，以提供多样化的解决 方案。
相关公司介绍
中科创达：车载操作系统头部厂商，由座舱域到驾驶域打开成长空间，基于移动终端领域积累多年的嵌入式操作系统二次开发经验，公司切入智能网联汽车领域。
自 2013 年，公司基于积累多年的操作系统优化技术、优秀的 3D 引擎、机器视觉、以及语音和音频 技术，为汽车提供从操作系统开发、核心技术授权到应用定制。
包括汽车娱乐系统、智能仪表盘、 集成驾驶舱、ADAS 和音频产品在内的整体智能驾驶舱软件解决方案和服务，为驾乘者提供丰富、 先进的智能驾驶体验。目前，全球采用公司智能驾驶舱产品和解决方案的公司超过 100 家。
基于 SOA 架构，公司智能座舱产品已经发展为跨系统融合的智能驾驶舱 4.5 解决方案，为客户提 供从底层系统软件、中间件再到上层应用的全栈式解决方案。
从公司 TurboX Auto 4.5 智能座舱 平台架构来看：系统软件方面，公司具备 BSP 开发能力解决方案支持多个主流芯片平台（高通、 瑞萨、NXP 等）。
基于 Hypervisor 技术平台可支持 QNX、Linux、Android 等 OS 内核，并可对 OS 性能进行优化；功能软件方面，平台具备提供音频及图像处理、传感器融合、车内网络等模 块的能力
上层应用方面，基于Kanzi，平台提供信息娱乐系统、智能仪表、ADAS和影音集成等 产品，提供 5G、云服务并支持 FOTA升级；
平台提供的中间件方案可实现软硬件接口的标准化，进而支持 SOA 架构汽车的持续迭代升级。总结来看，公司的智能座舱方案实现了场景和服务的解 耦，可快速完成场景服务的开发变更及升级迭代。
公司收购辅易航，以低速泊车场景切入驾驶域2020 年 12 月，公司收购辅易航。辅易航具有低 速感知系统、驻车辅助系统、智能泊车系统、全自动泊车系统、自主驾驶五大核心产品能提供 软硬一体的整体解决方案。
此次收购强化了公司在低速场景下的 ADAS、毫米波雷达、自动驾驶 等领域的技术积累，也表明公司开始以低速泊车场景切入驾驶域。
目前，公司座舱域的算法已经 具备支撑低速驾驶的能力，可以实现座舱域和低速驾驶域的融合，复用座舱芯片的算力，实现了安全且成本优秀的自动泊车方案。
自动驾驶高速场景的商业化落地还有一定距离，行业的拐点尚 未到来，而公司在低速场景的积累也有利于高速自动驾驶政策落地、技术成熟之时抓住机遇，为 车厂提供领先、成熟的产品或解决方案。
光庭信息：国内领先的汽车软件及解决方案提供商
公司具备面向智能网联汽车的全域全栈软件开发能力。公司成立于 2011 年，自成立以来一直专 注于汽车电子软件先端技术的研发与创新。
伴随着汽车电子电气架构的演变以及“软件定义汽车” 理念的兴起，公司紧密围绕汽车智能化、网联化、电动化的发展趋势。
致力于构建以车载操作系 统为核心的基础软件平台，以软件驱动汽车数字化转型，为用户提供全新的驾乘体验及服务。
目 前，公司产品和技术服务已涵盖了构成智能网联汽车核心的智能座舱、智能电控和智能驾驶三大 领域。并建立了智能网联汽车测试服务体系。
移动地图数据服务平台两大支撑体系。目前，公司 全域全栈的产品体系已具备为新一代智能网联汽车提供软件开发与技术服务的能力。
