Software Defined Vehicle | The Eclipse Foundation

导读：移动出行时代，汽车逐渐由机械驱动的硬件向软件驱动的电子产品过渡，软件定义汽车趋势愈发明显。这一过程中汽车软件以和硬件深度耦合的方式得到发展；

现如今，汽车企业的车型硬件配置已逐渐趋同，成本和功能改善空间有限，传统汽车价值链面临重构，而新能源和智能化逐渐获得成功，汽车软件开始成为车企打造差异化的核心要素，汽车行业逐渐迈向软件定义汽车（Software Defined Vehicles， SDV）的时代。

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

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

计算性能：汽车芯片由 MCU 转向 SoC。MCU 芯片通常只包含一个 CPU 处理器单元、存储和接口单元，算力一般仅几百 DMIPS；而 SoC 是系统级芯片，一般采用“CPU+AI 芯片（GPU\FPGA\ASIC）”架构方案，如英伟达 Orin X 算力高达 254TOPS。
通讯带宽：车载以太网成为汽车骨干通讯网络。传统的分布式架构中 ECU 之间大多通过 CAN 通讯、LIN 通讯、Flex Ray 等通讯，数据的传输速度非常有限，一般只有几兆每秒。随着车内传感器数量增加，数据传输体量和速率要求大幅提高，未来车载以太网将成为汽车骨干网，在单对非屏蔽双绞线上可实现 100Mbit/s，甚至 1Gbit/s 的传输速率。
软硬解耦实现 OTA 升级：汽车由烟囱式垂直架构转变为通用硬件平台+基础软件平台+各类应用软件的水平分层架构，实现软硬件的解耦。硬件预埋，软件 OTA ，实现软件功能迭代推动整车功能升级。
更好的成本管控：目前在高端车型与智能化程度高的车型中主要 ECU 的数量达到 100 多个，加上一些简单功能的 ECU 总数可以超过 200 个，ECU 增加对应线束增加带来成本提升，通过域控集成方式可较大幅度减少 ECU 数量；此外，ECU 由不同供应商提供，任何功能修改涉及多个控制器重新开发、验证，耗时耗力，且软件逻辑被供应商把控，主机厂无法对软件功能实现高效管理。

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

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

ECU 间信号收发关系是静态，ECU 各功能的编码在架构设计阶段被预先定义在 ECU 排序文件中。
面向信号架构仅支持接受和发送模式，不支持请求和响应模式，不能实现交互
软件硬件高度耦合，软件发生改动或升级时，需要对整车进行集成验证，时间花费较长且难度较大。
软件功能改动成本高，难度大。在传统的面向信号架构下，如果某个软件功能需要改动，整车通讯系统和 ECU 都要发生改动，而 ECU 数量的急剧增加使得这一过程的成本和复杂度显著上升。

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

SOA 将车端不同功能及硬件能力划分为服务，并按整车的原子能力将服务拆分为颗粒度更小的接口。
SOA 各服务组件的接口进行标准化封装，可通过既定协议互相访问、拓展组合；SOA 的核心要素包括松耦合、标准化定义、软件复用等。
SOA 使应用层功能可在不同车型上复用，且能够基于标准化接口快速响应用户新的功能需求，

汽车软件架构

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

底层系统软件层，包括 BSP、虚拟机、系统内核、中间件组件等；

功能软件层：包括库组件、中间件等，位于操作系统、网络和数据库之上，应用软件的下层，为应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件；

上层应用算法软件层，包括智能座舱 HMI、ADAS/AD 算法、网联算法、云平台等，用于实际实现对于车辆的控制与各种智能化功能。

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

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

基础型操作系统：如 QNX、Linux、WinCE 等，包含全新底层操作系统和所有系统组件，如系统内核、底层驱动等，有的还包括虚拟机。
定制型操作系统：指在基础型操作系统之上进行深度定制化开发（包括修改内核、硬件驱动、运行时环境、应用程序框架等），最终实现座舱系统平台或自动驾驶系统平台，如大众 VW.OS、特斯拉 Version、Google 车载 Android、华为鸿蒙 OS、AliOS 等。
ROM 型汽车操作系统：基于 Linux 或安卓等基础型操作系统进行有限的定制化开发，不涉及系统内核更改，一般只修改更新操作系统自带的应用程序等。大部分车企一般都选择开发 ROM 型操作系统。
超级 APP：又称车机互联或手机映射系统，不是完整意义上的汽车操作系统，其借助手机的丰富功能映射到汽车中控，以满足车主对娱乐的需求，代表有苹果 CarPlay、百度 CarLife、华为 Hicar 等。

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

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

QNX 凭借高安全性、高稳定性和高实时性，牢牢占据汽车嵌入式操作系统市占率第一的位置。从适用领域上看，QNX 系统更适用于仪表系统、动力系统等对安全性能要求更高的领域
Linux（包括基于 Linux 开发的 Android）与 QNX 相比最大的优势在于开源，具有很强的定制开发灵活度、扩展性强。Linux 和 Android 在车载信息娱乐领域更具优势。

头部主机厂和第三方企业都积极布局汽车操作系统。如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 保持正确的接口。

Tier1、OEM、Tier2 厂商均有参与 BSP 市场，而由于高端芯片 BSP 开发需要深度理解芯片架构，目前市场中以和芯片厂商紧密合作的第三方公司如中科创达等公司为主要力量。中科创达与高通、瑞萨、德州仪器、恩智浦等领先芯片供应商保持深度合作，对相关公司的芯片具有深刻理解，可以代表芯片厂商为车厂/Tier1 提供 BSP 技术支持。（报告来源：未来智库）

虚拟层（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 方面仍处于起步阶段，ETAS（博世）在欧洲率先实现量产。大陆 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 架构以及广泛的操作系统框架构建成熟后，丰富的上层应用生态与算法将具备更大的价值空间。

原文链接：

什么才是软件定义汽车？

什么才是软件定义汽车？相关推荐

软件定义汽车—箭在弦上的变革
1.软件定义汽车背景在过去的几年中,智能手机和计算机,其标准化硬件在现有技术水平下正逐渐接近物理极限,这推动了其行业逐步从由硬件升级发展主导产品创新,转向由软件开发和迭代去推动硬件设计的更新和升级. ...
软件定义汽车新一代技术发展
引言作为一个技术的爱好者,搞算法,玩芯片,攒系统,并不只是工作,也是自己所追求的很重要的部分.写这个系列,是为了梳理这几年的所学.所思.所想,从而形成一个完整的知识体系,也供大家参考.这是一个横向跨 ...
软件定义汽车：架构分析
前言: 汽车的智能化和软件化,就像一个巨大的漩涡,吸引着各方势力卷入其中. 就像上一篇文章提到的一样,在大家构建软件能力过程中,一些危机也正在酝酿之中,在缺乏良好设计的框架下,一旦进入正常的车型迭代 ...
汽车行业大趋势——软件定义汽车
文章目录前言一.软件定义汽车的驱动力二.SOA架构在软件定义汽车中的作用三.车载软件架构(内核.中间件.应用层)长期趋势总结前言最早在2007年4月份的IEEE会议中提出"软件 ...
虚拟局域网软件开源_软件定义汽车 (第十集)：决战架构之巅
前言: 汽车的智能化和软件化,就像一个巨大的漩涡,吸引着各方势力卷入其中.就像上一篇文章提到的一样,在大家构建软件能力过程中,一些危机也正在酝酿之中,在缺乏良好设计的框架下,一旦进入正常的车型迭代,就 ...
汽车操作系统研发：“广义”带动“狭义”——东软睿驰总经理曹斌谈“软件定义汽车”
开栏的话 "如果没有操作系统,芯片再强,汽车做得再好,都是在沙滩上起高楼.如果'缺芯少魂'这个问题不解决,汽车产业走不快,也走不远."去年下半年,行业权威人士曾提出,行业" ...
gvdp哪个工厂用_@汽车工程师，软件定义汽车合集，值得收藏阅读...
软件定义汽车(Software Defined Vehicles, SDV),软件改变着汽车的DNA,毫无疑问,软件对于汽车的重要性不言而喻,从2016年开始,自动驾驶的大潮来临之际,软件定义汽车已经 ...
【数据分发服务DDS】软件定义汽车【二】- 面向服务的架构设计
引言上一篇文章主要介绍了电子电气架构.车载操作系统.基础软件平台等之间的关系,以及软件定义汽车的基本概念,本篇将继续深入,重点阐述三个问题: 智能电动汽车软件范畴软件+硬件升级的基础面向服务的软 ...
软件定义汽车产业生态创新白皮书
1 什么是软件定义汽车 1.1 驱动因素汽车"新四化"的发展需要软件的加持据大众汽车公开披露信息,未来平均每辆普通汽车软件代码量超 1 亿行.在电动化.智能化和网联化等的发展推 ...