什么才是软件定义汽车？

推荐：智车科技

/ 导读/

移动出行时代，汽车逐渐由机械驱动的硬件向软件驱动的电子产品过渡，软件定义汽车趋势愈发明显。这一过程中汽车软件以和硬件深度耦合的方式得到发展；现如今，汽车企业的车型硬件配置已逐渐趋同，成本和功能改善空间有限，传统汽车价值链面临重构，而新能源和智能化逐渐获得成功，汽车软件开始成为车企打造 差异化的核心要素，汽车行业逐渐迈向软件定义汽车（Software Defined Vehicles， SDV）的时代。

EE 架构升级是软件定义汽车的硬件基础

智能化与 联化建立在合适的电子电气架构核心的计算能力上，硬件基础是软件定义汽车的前提，EE架构主要看四方面：

SOA 是软件定义汽车的软件趋势

传统分布式 EE 架构主要基于面向信 架构（Signal-Oriented Architecture），这种软件架构无法满足智能化汽车的需求；

SOA 极大地减少了软件升级的复杂度和成本，提高了效率。

汽车软件架构

智能汽车软件分为三层架构，包括：

系统软件层——狭义操作系统

汽车操作系统是管理和控制智能汽车硬件和软件资源的底层，提供运行环境、通信 机制和安全机制等。按照对底层操作系统改造程度以及能力深度的不同，主要可以 分为以下几种∶

操作系统内核又称为“底层 OS”，提供操作系统最基本的功能，负责管理系统的 进程、内存、设备驱动程序、文件和 络系统，是系统软件层的核心。由于开发难 度最大且安全性要求最高，其市场竞争格局较为稳定，主要以 QNX、Linux、Android、 WinCE 为主。

长期看，未来市场将是 QNX、Linux、Android 三足鼎立的局面。根据 IHS Automotive 数据统计，系统内核目前主要以 QNX 和开源的 Linux、Android 为主，合计市占率 已近 90%。从系统性能上，三大主流系统各具优势。

头部主机厂和第三方企业都积极布局汽车操作系统。如Tesla.OS、大众集团的 VW.OS、戴姆勒 MB.OS、 BMW-OS、吉 利 GKUI 等，都是基于 Linux、QNX 和其他 RTOS 等内核实现硬件抽象化，形成 支持应用开发的中间层操作系统，定义开发者交互逻辑，搭建应用层。

自研操作系统有助于简化车辆软件开发流程及增加 OTA 频率。

特斯拉采用开源 Linux 自研操作系统，不再依赖于软件供应商，而是自己完 全掌握堆栈，一旦发现问题即可通过 OTA 进行快速修正与升级，提升用户体验。自 2014 年首次在 Model S 上使用自研操作系统以来，特斯拉已通过 OTA 技术对其操 作系统进行了多次重大升级。

自研操作系统而可以掌握开发者生态资源，形成一 定垄断优势。如德国大众自研 VW.OS，依托自身近千万辆汽车年销量，迫使 Tier1 以及软件供应商甚至其他 OEM 在 VW.OS 的基础上进行开发，使之成为智能手机 领域的 IOS，最终形成“OS 授权许可费+车联 服务+APP 对接许可费+APP 增值服 务分成”的商业模式，获得超额利润。

第三方汽车操作系统玩家包括：TINNOVE 梧桐车（腾讯系）、斑马智行（阿里系）、 国汽智控、百度和华为等，这些企业主要是在主流底层 OS 基础上进行独立操作系 统的研发。从技术上看，互联 及科技企业凭借自身软件研发的优势，对系统改造 程度高、产品生态丰富。因此，第三方企业产品本身具备较强竞争力，可与生态较 单一、研发能力欠缺的车企进行合作，形成良性互补。

从与车企合作情况上看，第三方企业与车企积极合作，伙伴众多。2016 年斑马智行 与上汽合作推出搭载 Alios 系统的荣威、名爵等十多款车型，2017 年与神龙汽车合 作。华为超级 APP 系统 HiCar 目前合作的车企超过 20 家，包括沃尔沃、长安、吉 利、东风、广汽传祺、比亚迪等品牌，合作的车型超过 150 款。

系统软件层——BSP 层

BSP（板级支持包）是内核与硬件之间的接口层，一般认为它属于操作系统一部分。BSP 中主要包括 Bootloader（以基础支持代码来加载操作系统的引导程序）、HAL （硬件抽象层）代码、驱动程序、配置文档等。对于具体的硬件平台，与硬件相关 的代码都被封装在 BSP 中，由 BSP 向上提供虚拟的硬件平台，与操作系统通过定 义好的接口进行交互，使之能够更好的运行于硬件主板。其目的在于为操作系统提 供虚拟硬件平台，使其具有硬件无关性，可以在多平台上移植。

BSP 是相对于操作系统而言的，不同的操作系统对应于不同定义形式的 BSP。例 如 VxWorks 的 BSP 和 Linux 的 BSP 相对于某一 CPU 来说尽管实现的功能一 样，可是写法和接口定义是完全不同的，所以写 BSP 一定要按照该系统 BSP 的定 义形式来写，这样才能与上层 OS 保持正确的接口。

虚拟层（Hypervisor）

为了让不同类型的操作系统运行在一个计算平台上，最直接的技术路径就是虚拟化 （Hypervisor），虚拟化技术可以模拟出一个具有完整硬件系统功能、运行在一个完 全隔离环境中的计算机系统，此时供应商不再需要设计多个硬件来实现不同的功能 需求，而只需要在车载主芯片上进行虚拟化的软件配置，形成多个虚拟机，在每个 虚拟机上运行相应的软件即可满足需求。因此，车载虚拟化操作系统要求具备以下 三点技术要求：（1）使用资源分区技术严格隔离和分配资源；（2）具备灵活高效 的实时和非实时任务调度机制；（3）进程间通信，实现消息在虚拟机之间通信。

目前主流的虚拟化技术提供商为 QNX 和 ACRN。常见的 Hypervisor 包括黑莓的 QNX、英特尔与 Linux 主导的 ACRN、Mobica 为代表的 XEN、松下收购的 Open Synergy 的 COQOS、德国大陆汽车的 L4RE、法国 VOSyS 的 VOSySmonitor 等， 其中最主流的是黑莓的 QNX 及英特尔与 Linux 主导的 ACRN，而 QNX 作为唯 一被认可达到 ASIL D 等级的虚拟化操作系统，已经量产应用到实际车型中。整个 操作系统是由微内核调度管理的一组进程集合，安全性与实时性有保障。目前，黑 莓 VAI 项目的中国区系统集成商类的合作伙伴主要包括中科创达、武汉光庭信息、 南京诚迈科技等。

中间件：软件开发的关键“纽带”

在中间件出现之前，系统软件是直接基于操作系统开发，导致软硬件高度耦合。随 着车内代码量的增长导致系统的复杂性和成本剧增，为了提高软件的管理性、移植 性、裁剪性和质量，需要定义一套标准的接口、高质量的无缝集成、高效的开发以 及通过新的模型来管理复杂的系统。中间件将软件、硬件进行分离，对下层硬件资 源进行抽象、利用，对芯片进行驱动并优化操作系统，对上层软件提供服务接口， 为不同算法提供不同类型的插件。中间件解决数据传输、应用调度、系统集成和流 程管理等问题，可大幅提升应用层软件的开发效率。

经典中间件设计标准：AUTOSAR。汽车电子软件标准主要包括 AUTOSAR、 OSEK/VDX 等，其中 AUTOSAR 标准发展了十多年，已经形成复杂的技术体系和广泛的开发生态，是汽车中间件主流设计标准。AUTOSAR 规定了分层架构、方法论 和应用接口规范，使得汽车嵌入式系统控制软件开发者，得以在 ECU 软件开发与 验证过程中，摆脱对硬件系统的依赖，实现了软硬件的分离。

AUTOSAR 整个架构从上到下分层依次为：应用层（Application Software Layer），运 行时环境（Runtime Environment，RTE），基础软件层（Basic Software Layer，BSW）， 微控制器（Microcontroller）。每层之间为保持独立性，每一层只能调用下一层的接 口，并为其上一层提供接口。

AUTOSAR 的优势主要有：1.有利于提高软件的复用度，使软件可以跨平台复用；2. 便于软件的交换与更新；3. 软件功能可以进行先期架构级别的定义和验证，从而 减少开发错误；4. 减少手工代码量，减轻测试验证负担，提高软件质量；5. 使用一 种标准化的数据交换格式（ARXML），方便各个公司之间的交流合作。

AUTOSAR 分为 Classic Platform 和 Adaptive Platform 两大平台，其中 Classic Platform 主要面向分布式 ECU，Adaptive AUTOSAR 主要面向更复杂的域控制器和 中央计算平台的电子电气架构。相比于 Classic AUTOSAR ，Adaptive AUTOSAR 的 优势在于：实时性强、操作系统移植性高以及软件升级更灵活。

AUTOSAR 是传统汽车行业巨头们制定的游戏规则，目前已有超 300 家生态伙伴企业。目前全世界范围内能开发完整的基于 AUTOSAR 架构底层协议栈的公司寥寥无 几，目前全球知名的 AUTOSAR 解决方案厂商包括 ETAS（博世）、EB（Continental）、 Mentor Graphics（Siemens）、Wind River（TPG Capital），以及 Vector、KPIT（美印 合资）等，大部分 Tier 1 和主机厂都需要向上述几家供应商购买底层软件。在中国， Classic AUTOSAR 标准下的开发工具链及基础软件上述海外供应商占据主导地位， 国内主要是东软睿驰、华为、经纬恒润等；Adaptive AUTOSAR 方面，仍处于起步 阶段，大陆 EB 与和大众合作将 AP AUTOSAR 和 SOA 平台应用于大众 MEB 平台 ID 系列纯电动车型上。国内厂商纷纷将 AP AUTOSAR 作为发力重点，推出相应的 中间件及其工具链产品，抢占市场先机。

整个 AUTOSAR 的框架中真正对控制有作用的只有 Application Layer，其他 RTE 及 以下层都是起辅助作用的，不同 Application 层的功能对应的 BSW 基本相同，而且 AUTOSAR 要求软件工程师严苛的按照标准进行“写作”。这样在分布式架构下会造 成控制器数量越多，软件行数越多，软件开发成本也就越高。在域控架构下由于 ECU 和执行器还仍然遵循 AUTOSAR 这个标准的时候，无法大幅度减少代码量。因此特 斯拉不用 AUTOSAR，依托自研的操作系统和基础软件实现更高效的开发。

2020 年 7 月 22 日，一汽、上汽、广汽、蔚来、吉利、长城、长安、北汽福田、东 风、一汽解放、小鹏汽车、东软睿驰、恒润、拿森、地平线、苏州挚途、万向钱潮、 威迈斯、重塑、中汽创智这 20 家企业组成中国汽车基础软件生态委员会 （AUTOSEMO），旨在形成由本土企业主导具有自主知识产权的基础软件架构标准 和接口规范，共享知识成果，建立产业生态。

功能软件层

在汽车软件架构中，功能软件主要包含自动驾驶的核心共性功能模块。核心共性功 能模块包括自动驾驶通用框架、 联、云控等，结合系统软件，共同构成完整的自 动驾驶操作系统，支撑自动驾驶技术实现。

目前在功能软件层面，传统 Tier1、OEM、科技巨头、第三方软件供应商都有一 定布局。各方可凭借自身的优势提供解决方案，选择擅长的模块进行开发，例如 在传感器领域有优势的算法厂商可以专注于功能软件中传感器模块的开发，实现 整个行业更为有效的分工与合作。

在功能软件领域，与供应商合作的模式有助于满足车企自身对于智能汽车产品功 能研发的需求。相比于车企，各大供应商开发的软件模块经过不同情景、在不同 产品上的检验，质量更具有保障。且一些软件供应商可根据车企自身特色，提供 更适合车企的解决方案，加快研发效率。例如为研发能力比较强的车企提供功能 模块方案，开放干净的接口，让车企自己去控制整个用户体验和产品定义。而面 向软件能力还不完善的车企，可以提供软硬件集成交付方案，大大缩短车企研发 周期。

应用软件层

应用层软件运行在广义操作系统之上，具体负责功能实现。主要包括面向自动驾驶 算法、地图导航类、车载语音、OTA 与云服务、信息娱乐等。典型的计算平台，在 装载运行系统软件和功能软件构成的操作系统后，向上支撑应用软件开发，最终实 现整体功能实现。上层的应用软件层是 OEM 重点研发打造差异化的领域，比如座 舱 HMI、自动驾驶等。因此，目前整车厂、传统 Tier1、初创企业、科技巨头以及 独立的软件企业等在上层软件领域都在积极发力。

从长期来看，上层应用与算法价值量最大。在短期内，汽车软件领域内企业若想真 正落地 SOA 软件架构，虚拟化技术、系统内核及中间件（AUTOSAR）等系统软件 至关重要。但从长期来看，在 SOA 架构以及广泛的操作系统框架构建成熟后，丰 富的上层应用生态与算法将具备更大的价值空间。

欢迎加入智能交通技术群！