↓↓关注回复“资料”，领取特斯拉专利技术解析报告↓↓

移动出行时代，汽车逐渐由机械驱动的硬件向软件驱动的电子产品过渡，软件定义汽车趋势愈发明显。这一过程中汽车软件以和硬件深度耦合的方式得到发展；现如今，汽车企业的车型硬件配置已逐渐趋同，成本和功能改善空间有限，传统汽车价值链面临重构，而新能源和智能化逐渐获得成功，汽车软件开始成为车企打造 差异化的核心要素，汽车行业逐渐迈向软件定义汽车（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 由不同供应商提供，任何功能修改涉及多个控制器重新开发、验证， 耗时耗力，且软件逻辑被供应商把控，主机厂无法对软件功能实现高效管理。
智能化与网联化共同推动了汽车EE架构的bi ang，由分布式向集中式、域融合转变
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 等。
不同类型的4类常见的汽车操作系统示意
操作系统内核又称为“底层 OS”，提供操作系统最基本的功能，负责管理系统的 进程、内存、设备驱动程序、文件和网络系统，是系统软件层的核心。由于开发难 度最大且安全性要求最高，其市场竞争格局较为稳定，主要以 QNX、Linux、Android、 WinCE 为主。
长期看，未来市场将是 QNX、Linux、Android 三足鼎立的局面。根据 IHS Automotive 数据统计，系统内核目前主要以 QNX 和开源的 Linux、Android 为主，合计市占率 已近 90%。从系统性能上，三大主流系统各具优势。
  • QNX 凭借高安全性、高 稳定性和高实时性，牢牢占据汽车嵌入式操作系统市占率第一的位置。从适用领域上看，QNX 系统更适用于仪表系统、动力系统等 对安全性能要求更高的领域
  • Linux（包括 基于 Linux 开发的 Android）与 QNX 相比最大的优势在于开源，具有很强的定制开 发灵活度、扩展性强。Linux 和 Android 在车载信息娱乐领域更具优势。
主流底层OS特点
头部主机厂和第三方企业都积极布局汽车操作系统。如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 技术支持。（报告来源：未来智库）
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 方面，仍处于起步 阶段，大陆 EB 与和大众合作将 AP AUTOSAR 和 SOA 平台应用于大众 MEB 平台 ID 系列纯电动车型上。国内厂商纷纷将 AP AUTOSAR 作为发力重点，推出相应的 中间件及其工具链产品，抢占市场先机。
Classic Platformyu与Adaotive Platform的对比
整个 AUTOSAR 的框架中真正对控制有作用的只有 Application Layer，其他 RTE 及 以下层都是起辅助作用的，不同 Application 层的功能对应的 BSW 基本相同，而且 AUTOSAR 要求软件工程师严苛的按照标准进行“写作”。这样在分布式架构下会造 成控制器数量越多，软件行数越多，软件开发成本也就越高。在域控架构下由于 ECU 和执行器还仍然遵循 AUTOSAR 这个标准的时候，无法大幅度减少代码量。因此特 斯拉不用 AUTOSAR，依托自研的操作系统和基础软件实现更高效的开发。
2020 年 7 月 22 日，一汽、上汽、广汽、蔚来、吉利、长城、长安、北汽福田、东 风、一汽解放、小鹏汽车、东软睿驰、恒润、拿森、地平线、苏州挚途、万向钱潮、 威迈斯、重塑、中汽创智这 20 家企业组成中国汽车基础软件生态委员会 （AUTOSEMO），旨在形成由本土企业主导具有自主知识产权的基础软件架构标准 和接口规范，共享知识成果，建立产业生态。
功能软件层
在汽车软件架构中，功能软件主要包含自动驾驶的核心共性功能模块。核心共性功 能模块包括自动驾驶通用框架、网联、云控等，结合系统软件，共同构成完整的自 动驾驶操作系统，支撑自动驾驶技术实现。
目前在功能软件层面，传统 Tier1、OEM、科技巨头、第三方软件供应商都有一 定布局。各方可凭借自身的优势提供解决方案，选择擅长的模块进行开发，例如 在传感器领域有优势的算法厂商可以专注于功能软件中传感器模块的开发，实现 整个行业更为有效的分工与合作。
在功能软件领域，与供应商合作的模式有助于满足车企自身对于智能汽车产品功 能研发的需求。相比于车企，各大供应商开发的软件模块经过不同情景、在不同 产品上的检验，质量更具有保障。且一些软件供应商可根据车企自身特色，提供 更适合车企的解决方案，加快研发效率。例如为研发能力比较强的车企提供功能 模块方案，开放干净的接口，让车企自己去控制整个用户体验和产品定义。而面 向软件能力还不完善的车企，可以提供软硬件集成交付方案，大大缩短车企研发 周期。
布局功能软件层业务的企业
应用软件层
应用层软件运行在广义操作系统之上，具体负责功能实现。主要包括面向自动驾驶 算法、地图导航类、车载语音、OTA 与云服务、信息娱乐等。典型的计算平台，在 装载运行系统软件和功能软件构成的操作系统后，向上支撑应用软件开发，最终实 现整体功能实现。上层的应用软件层是 OEM 重点研发打造差异化的领域，比如座 舱 HMI、自动驾驶等。因此，目前整车厂、传统 Tier1、初创企业、科技巨头以及 独立的软件企业等在上层软件领域都在积极发力。
从长期来看，上层应用与算法价值量最大。在短期内，汽车软件领域内企业若想真 正落地 SOA 软件架构，虚拟化技术、系统内核及中间件（AUTOSAR）等系统软件 至关重要。但从长期来看，在 SOA 架构以及广泛的操作系统框架构建成熟后，丰 富的上层应用生态与算法将具备更大的价值空间。
转载自AI汽车人，文中观点仅供分享交流，不代表本公众号立场，如涉及版权等问题，请您告知，我们将及时处理。
-- END --
继续阅读
阅读原文