一、整体软件架构

汽车电子电气架构正在由传统的分布式架构向域集中式和中央集中式演进， 并继续演进至车路云一体化协同。智能网联汽车整体软件架构需要采用 SOA 分层思路构建， 从下往上，分为系统软件层、 功能软件层、 应用软件层， 以及云平台。其中， 系统软件与功能软件构成了广义上的操作系统（本文中， 没有特别强调说明的“操作系统”， 均指广义操作系统。如下图 智能网联汽车软件架构中红色线框内所示） ， 是汽车软件的基础。

此外， 汽车软件一般要配合专业的硬件平台来运行， 硬件平台为基于高性能芯片搭建的异构分布式硬件运行环境， 具有选型灵活、 配置可插扩、 算力可堆砌等特点。

智能网联汽车软件架构

系统软件是针对汽车场景定制的复杂大规模嵌入式系统运行环境， 不仅为上层应用以及功能的实现提供了高效、 稳定环境的支持， 也是各类应用调度底层硬件资源的“桥梁”， 在智能汽车整体软硬件架构中处于核心的位置。主要包含虚拟化管理与 BSP（板级支持包） 、 操作系统内核（如：OSEK、 RTOS、 Linux、 Android Q） 、 基础中间件三层， 进一步细化可分为异构分布系统的多内核设计及优化、 虚拟化管理（如 Hypervisor） 、 POSIX（可移植操作系统接口） 、 系统中间件及服务（如 AUTOSAR、 DDS）等。

功能软件是根据面向服务的架构设计理念， 通过提取智能网联汽车核心共性需求， 形成各共性服务功能模块， 高效实现智能网联功能开发的软件模块。主要包括数据抽象、 通用框架、 通用模型、 API， 以及安全域基础应用和管理平面。

应用软件运行在操作系统之上， 具体负责功能实现。即为实现具体自动驾驶功能、 HMI（人机界面） 交互等算法软件， 基于下层基础服务实现对整车服务、 应用、 体验等进行定义和组合增强， 构建差异化竞争力的应用。应用算法差异化涵盖了智能座舱（车载信息娱乐系统 IVI、 车联网、 人机交互、 中控系统、 ADAS、 智能座椅等） 、 智能驾驶（L1-L5 级智能驾驶等级） 等领域。同时伴随着云端软件复杂性的提高， 车载网络信息安全（检测与防卫远程攻击） 也将逐步成为未来应用算法的关注焦点。

云平台是独立与车端之外， 可以在云端部署， 并与车端互联互通， 提供计算、 互联等服务的远程服务平台。在新一代汽车的 SOA 架构下， 越来越多的应用层接入云端， 使得车载网络在以前独立的电子领域（例如信息娱乐、 ADAS 和动力总成） 之间建立连接。云服务平台包含大数据服务、 远程诊断、 应用商店、 驾驶服务等。

此外， 汽车软件整体架构在设计和开发过程中， 还需要关注安全要求， 以及配套工具链。安全体系自底向上贯穿硬件、 系统软件、 功能软件和应用软件等各个层级， 需要关注的安全要求有功能安全、 信息安全、 预期功能安全， 防护的层次主要有三个， 分别是车路云一体安全防控、 整车级安全防控、 零部件级安全防控。软件的配套工具链包括系统设计工具、 软件配置工具、 系统集成工具和开发、 调试、 测试工具等。

当前， 车端软件架构 SOA 化主要集中在智驾、 座舱、 车身功能域， 动力和底盘域受限于实际需求、 时延和可靠性要求以及其他非技术原因， 暂时还未实现 SOA 化。但未来， 随着EEA 向 HPC 中央计算平台的进一步演进， 车端各功能域软件也会逐步实现完全 SOA 化。

各大整车企业和供应商提出的新一代软件架构中， 均采用了 SOA 设计思想， 提出分层解耦开发目标。从底层的内核与基础中间件， 到框架支撑层的功能软件， 再到上层应用软件，明确了各层之间的向下依赖关系， 各层之间通过规范化的 API 进行交互， 实现了不同层次间的分离与解耦。

汽车软件整体架构中， 操作系统（OS） 是基础支撑。不同功能域对于操作系统的要求也不同。比如传统的动力和底盘域， 仍然是高实时性高确定性的嵌入式 OS（如 OSEK/VDX OS），通常和经典 AUTOSAR 平台绑定在一起。在智能座舱领域， 以车端 Android 操作系统为主，通过 SOA 网关实现自身服务和外部功能域之间的服务化交互。在智驾域， 满足高功能安全和高性能要求的实时操作系统 RTOS 被广泛应用（如 BlackBerry QNX， 中兴 ZEOS 等） ， 同时为满足机器学习和视觉 AI 算法的 OS 层接口要求， 安全 Linux 操作系统也需要引入， 比如和RTOS 一起构筑软件功能安全岛， 支撑 AI 算法丰富接口要求的同时， 满足智驾要求的功能安全等级， 如下图所示。

智驾域控制器软件架构示意图

汽车软件 SOA 新架构中均引入了自适应 AUTOSAR（Adaptive AUTOSAR） 平台， 用于满足一定的代码规范性和功能安全的目标， 同时也是借助于 Adaptive AUTOSAR 平台自身SOA 架构完成软件系统设计与开发。Adaptive AUTOSAR 经过五年左右的发展， 目前推出了R21-11 最新规范（如下图所示）， 国内外 AUTOSAR 厂商均在规划对齐最新规范进行各自 Adaptive AUTOSAR 产品的完善。总体而言， Adaptive AUTOSAR 平台面临的场景更加多样化， 相应的处理逻辑更加复杂多样， 功能范围更加宽泛， 即使是目前 Adaptive AUTOSAR 最新的规范也不能完全满足应用软件的需要， 需要在此基础上做进一步的扩展和完善。在国内， 中国智能网联汽车产业创新联盟基础软件工作组和中国汽车基础软件生态委员会（AUTOSEMO）等组织正在致力于推进相关标准化工作。

Adaptive AUTOSAR R21-11 规范框架

在汽车软件 SOA 架构中， 通过针对不同设备的抽象和适配， 对外发布原子服务， 实现设备和软件平台之间的解耦。在此基础上进一步定义组合服务、 应用服务以及动态服务， 实现服务的完全共享和重用。当前， 中国汽车工程学会、 汽车工业协会等组织在积极推进感知设备、 执行机构、 车身传感器及执行器、 热管理系统的设备抽象和原子服务定义， 具体落地实现还需要一个较长时期的过程。

此外， 软件 SOA 架构中各服务和应用模块之间的通讯， 当前应用层协议主要还是SOME/IP 及其关联的服务发现（SD） 。目前 Classic AUTOSAR 和 Adaptive AUTOSAR 都已经支持了 SOME/IP 协议栈， 同时在 Adaptive AUTOSAR 平台中还提供了 S2S 服务， 实现服务和信号的相互转换， 支持面向服务功能模块和面向信号模块之间的消息互通。当前， 以数据为中心的 DDS 协议虽然已经纳入 Adaptive AUTOSAR， 但目前对 DDS 的支持还很少。另外， 用于车云通讯的 MQTT（Message Queuing Telemetry Transport， 消息队列遥测传输， ISO标准下基于发布/订阅范式的消息协议） 、 RESTful 还没有正式应用到车端软件架构中。

汽车 SOA 架构设计当前处于起步阶段， 面临诸多挑战。其中包括车端硬件环境的限制，高实时性和高确定性要求， 系统设计与工作模式的转变， 面向服务通讯组件的整合与集成，架构服务化带来的信息安全风险， 功能安全方面的挑战， 异构环境及非 SOA 架构模块的并存增加了系统架构的复杂度等。

总体而言， 目前整车企业更多是进行少量服务化尝试， SOA 架构还未形成通用普适性规范。汽车软件架构正处于 SOA 化和传统非 SOA 化架构并存的阶段， 软件跨域分布式计算与多功能域异构软件环境是其显著特点。未来随着汽车电子电气架构向中央集中式演进， 汽车软件架构也会逐步实现全面 SOA 化， 各域功能进一步融合， 服务定义更加丰富， 服务重用与共享程度更高， 软件开发更加灵活便捷。伴随着车云一体化发展， 汽车软件平台会逐步演进为智能网联汽车边缘计算节点， 和智能网联云平台充分协同， 有效推动软件定义汽车的实现。

二、系统软件

2.1 虚拟化管理与板级支持包

系统软件层面， 主要包括 BSP（板级支持包） 、 Hypervisor（虚拟化管理） 、 操作系统内核（狭义操作系统） 、 中间件组件等。

Hypervisor 是运行在基础物理服务器和操作系统之间的中间软件层， 可允许多个操作系统和应用共享硬件， 也可称为 VMM（Virtual Machine Monitor） ， 即虚拟机监视器。硬件虚拟化技术管理并虚拟化硬件资源（如 CPU、 内存和外围设备等） ， 提供给运行在 Hypervisor之上的多个内核系统。虚拟化（Hypervisor） 解决方案提供了在同一硬件平台上承载异构操作系统的灵活性， 同时实现了良好的高可靠性和故障控制机制， 以保证关键任务、 硬实时应用程序和一般用途、 不受信任的应用程序之间的安全隔离， 实现了车载计算单元整合与算力共享， 是实现车载跨平台应用、 提高硬件利用率的重要途径。

在域集中式电子电气架构下， 各种功能模块都集中到少数几个计算能力强大的域控制器中， 不同安全等级的应用需要共用相同的计算平台， 传统的物理安全隔离被打破。虚拟化技术可以模拟出一个具有完整硬件系统功能、 运行在一个完全隔离环境中的计算机系统。此时供应商不再需要设计多个硬件来实现不同的功能需求， 而只需要在车载主芯片上进行虚拟化的软件配置， 形成多个虚拟机， 在每个虚拟机上运行相应的软件即可满足需求， 如下图所示。虚拟化技术的出现让“多系统”成为现实。

虚拟化技术示意

如下图所示， Hypervisor 通常被分成 Type1 与 Type2， Type1 类型的 Hypervisor 直接运行在硬件之上， Hypervisor 需要自己管理所有硬件资源；Type2 类型的 Hypervisor 运行在某个Host 系统之上， 利用 Host 系统对硬件资源进行访问。大家在 PC 上使用的 Virtual Box 和 VMware 虚拟机， 就属于 Type2 的类型。

Hypervisor 类型

全虚拟化时， Hypervisor 完整模拟了所有硬件资源， Guest OS 不知道正在被虚拟化， 它也不需要任何修改就能运行， Hypervisor 负责捕获并处理所有特权指令， 如果 Guest OS 使用的指令集架构与物理设备的相同（例如都是 ARM64） ， 那么用户级别的指令可以直接在物理设备上运行。在某些场景下， 要完全模拟一个真实的物理设备是非常慢的， 因为所有对模拟寄存器的访问都会产生一个软中断， 之后系统需要切换处理器特权模式， 陷入到 Hypervisor 当中进行模拟， 这样会带来很多额外的性能开销。为了解决这个问题， 部分外围设备会采用半虚拟化， 半虚拟化方式需要修改 Guest OS， 使之意识到自身运行在虚拟机当中， 通过 Guest OS 当中的前端驱动， 与 Hypervisor 中的后端驱动进行直接通信， 以此来换取更好得 I/O 性能，VMware vSphere、 华为 FusionSphere 就是比较常见的半虚拟化的方案。全虚拟化和半虚拟化方案如下图所示。

全虚拟化与半虚拟化

每个提供商都将为该特定处理器提供操作系统和应用程序,随着系统复杂程度的提高， 所需的计算能力被集中在一台集中式计算机中。这些处理器被要求放在一起， 同时又要互不干扰分开工作， 不同的安全等级往往会带来很大的难度。通过软件虚拟化的方法， 可以创建分配任务的错觉， 将每个任务分开， 如果某个特定任务由于软件故障而失败， 那么其他所有任务都将不受影响。软件虚拟化是分隔不同软件系统并降低总体硬件成本的有效方法。

在车载虚拟化领域， 主流的虚拟化技术提供商包括BlackBerry QNX Hypervisor（闭源） 及Intel与Linux基金会主导的ACRN（开源） 。目前， 只有QNX Hypervisor应用到量产车型， 也是唯一被认可功能安全等级达到ASIL D级的虚拟化操作系统。

Hypervisor 介乎于底层 DCU 硬件和上层操作系统软件之间， 与标准化服务器（x86） +标准化操作系统（Windows 和 Linux） 的云虚拟化应用场景不同， 汽车嵌入式环境中的虚拟化技术面临的挑战是 Hypervisor 往往需要定制适配底层 DCU 硬件和上层操作系统软件， 这对于 Hypervisor 的大规模商用与普及是一个非常大的技术障碍。因此 OASIS（Organization for the Advancement of Structured Information Standards， 结构化信息标准促进组织） 于 2016 年 3 月正式标准化 VirtIO 项目， 旨在提供一种通用的框架和标准接口， 减少 Hypervisor 对底层不同硬件和上层不同软件的适配开发工作量。

同样地， BSP（板级支持包） 是介于主板硬件和操作系统之间的中间软件层。BSP 用于为操作系统提供虚拟硬件平台， 使其具有硬件无关性， 可以在多平台上移植。BSP 包括 Bootloader（以基础支持代码来加载操作系统的引导程序） 、 HAL（硬件抽象层） 代码、 驱动程序、 配置文件等。不同的操作系统对应于不同定义形式的 BSP， 例如 VxWorks 的 BSP 和 Linux 的 BSP 相对于某一 CPU 来说尽管实现的功能一样， 可是写法和接口定义是完全不同的，所以写 BSP 一定要按照该系统 BSP 的定义形式来写， 这样才能与上层操作系统保持正确的接口。

对于一般的嵌入式系统， 硬件部分需要嵌入式硬件工程师设计硬件电路， 新出厂的电路板， 需要 BSP 来保证其能稳定工作， 在此基础之上， 才能进行下一步的软件开发。

BSP 涉及到的企业较多， 涵盖芯片制造商、 第三方软件服务商、 整车企业， 比如高通、华为、 德赛西威、 中科创达、 长城毫末和长城诺博等。

2.2 内核

内核（狭义操作系统） 是汽车操作系统最基本的部分， 负责管理系统的进程、 内存、 设备驱动程序、 文件和网络系统， 决定着系统的性能和稳定性， 是系统软件层的核心， 也被称为操作系统内核（OS 内核） /底层操作系统。根据域集中架构下汽车操作系统的发展情况，可将对应的内核粗略分为三大类：智能座舱操作系统内核、 智能驾驶操作系统内核和安全车控操作系统内核。

智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台， 是汽车实现座舱智能化与多源信息融合的运行环境。智能座舱操作系统应用于车机中控、 仪表、 T-Box等系统， 提供导航、 多媒体娱乐、 语音、 辅助驾驶、 AI 以及网联等功能， 对于安全性和可靠性的要求处于中等水平。随着车辆由单纯交通工具向智能移动终端转变， 智能座舱操作系统内核需要支持更多样化的应用与服务， 可以支撑一个丰富的生态。

智能驾驶操作系统主要面向智能驾驶领域， 运行于智能驾驶域控制器， 支持智能驾驶所需的高性能计算、 高带宽通信的高算力异构芯片， 对安全性和可靠性要求较高， 同时对性能和运算能力的要求也较高。智能驾驶操作系统内核应以标准的 POSIX 接口为基础， 兼容国际主流的系统软件。中间件如 Adaptive AUTOSAR 等， 满足智能驾驶不同应用所需的功能安全和信息安全等要求。根据当前异构分布硬件架构各单元所加载的内核系统安全等级有所不同，AI 单元内核系统支持 QM~ASIL-B， 计算单元内核系统支持 QM ~ ASIL-D， 控制单元内核系统需支持 ASIL-D 安全等级。

安全车控操作系统用于传统的车辆控制， 适用于动力系统、 底盘与车身控制等领域， 支持 MCU 等控制芯片。车辆底盘控制与动力系统对操作系统最基本的要求是高实时性， 系统需要在规定时间内完成资源分配、 任务同步等指定动作， 而嵌入式实时操作系统具有高可靠性、 及时性、 交互性以及多路性等优势， 系统响应度极高， 通常在毫秒或者微秒级别， 满足了高实时性的要求。目前主流的安全车控操作系统都兼容 OSEK/VDX 和 Classic AUTOSAR 标准。安全车控操作系统内核需要符合车规级实时控制功能安全应用需求， 应达到 ISO26262 ASIL-D 级安全认证。

在汽车电子电气系统中， 不同的 ECU 提供不同的服务， 同时对底层操作系统的要求也不同。为支持车载软件适应不同的汽车应用场景和硬件资源， 需要不同的底层汽车操作系统（OS内核） 来支撑。因打造全新操作系统需要花费太大的人力、 物力， 所以当前基本没有企业会开发全新的 OS 内核。比如 Waymo、 百度、 特斯拉、 Mobileye ， 无论是自动驾驶企业还是车企的“自研操作系统”， 其实都是在上述现成 OS 内核的基础之上， 将自研中间件和应用软件整合形成。目前普遍采用的汽车 OS 内核主要有：

OSEK/VDX OS， 主要用于安全车控操作系统  

OSEK/VDX 是应用在模块和静态实时操作系统上的标准， 由主要的汽车制造商、 供应商、研究机构以及软件开发商发起。OSEK， 是指德国的汽车电子类开放系统和对应的接口标准；而 VDX 则是汽车分布式执行标准， 后来加入了 OSEK 团体。OSEK/VDX 标准主要由四部分组成：操作系统规范、 通信规范、 网络管理规范和 OSEK 实现语言。OSEK/VDX OS 一般用作安全车控操作系统， 主要用于 ECU/TCU（远程信息控制单元） 等底层控制单元。这些单元通常使用处理能力简单且资源受限的 MCU 执行传统的车辆控制任务， 对实时性、 安全性要求非常苛刻。

目 前 OSEK/VDX 是国际上被广泛应用的汽车行业标准 ， AUTOSAR OS 正是在OSEK/VDX 的基础上进行了扩展， 并成为汽车应用主流。各嵌入式操作系统厂商都相继推出了符合 OSEK/ VDX 规范的产品， 比较典型的有 Vector 公司的 osCAN 及 MICROSAR OS、WINDRIVER 公司的 OSEKWorks、 ETAS 公司的 RTA-OSEK、 MOTOROLA 的 OSEKturbo、美国密西根大学的 EMERALDS-OSEK、 普华软件的 ORIENTAIS OS 等。随着该规范应用的不断深人，其结构和功能不断完善和优化， 版本也不断升级和扩展。

微内核 RTOS， 用于智能驾驶操作系统和安全车控操作系统

随着自动驾驶技术的发展， 车辆环境融合感知与智能决策需求带来了更为复杂的算法，并产生了大量的数据， 需要更高的计算能力和数据通讯能力。基于 OSEK/VDX OS 的传统嵌入式实时操作系统已经不能满足未来自动驾驶的需求， 这些需求对原有的车控操作系统提出了巨大的挑战。为应对挑战， 业界在继承 OSEK/VDX OS 高实时、 高功能安全特性的基础上，发展出可运行于异构大算力、 高带宽环境之上的微内核 RTOS 实时操作系统。

微内核 RTOS 架构设计是内核部分代码量少， 系统服务更多的运行在用户空间， 当某个服务发生问题时并不会影响内核稳定性， 天生具备功能安全优势。但微内核缺少类似 Linux的开源生态环境支持， 所以微内核更适合汽车软件中对功能安全要求更高、 稳定性更强的部分， 但同时对软件生态没有过高要求的场景使用（如需要 AI 算法模型框架的高级自动驾驶，较为封闭的微内核 RTOS 的应用生态很难满足） 。

基于 POSIX 标准的微内核 RTOS， 通常以 ASIL-D 功能安全级别为目标， 满足安全实时要求， 适用于自动驾驶所需要的高性能计算和高带宽通信， 支撑自动驾驶决策、 规划、 控制的算法需求， 可用于智能驾驶操作系统。在一些基于异构核的 SOC 硬件环境， 微内核 RTOS可以通过 Hypervisor 虚拟化平台运行在实时核上， 用作安全车控操作系统， 支撑一些对实时性、 安全性要求高的功能需求。目前应用在汽车领域的微内核 RTOS 主要包括 BlackBerry QNX、 风河 VxWorks、 华为鸿蒙 OS、 中兴 GoldenOS、 阿里 AliOS 等。

Safety Linux OS， 用于智能驾驶操作系统和智能座舱操作系统  

Linux 是一款开源、 功能强大、 应用广泛的操作系统。Linux 具有内核紧凑高效等特点，可以充分发挥硬件的性能。它与 QNX 等微内核解决方案相比最大优势在于开源以及丰富的生态应用， 具有很强的定制开发灵活度。通常基于 Linux 开发新的操作系统是指基于 Linux Kernel 进一步集成中间件、 桌面环境和部分应用软件。Linux 功能较 QNX 等微内核更强大，组件也更为复杂， 因此 Linux 常用于支持更多应用和接口的信息娱乐系统中。AGL、 GENIVI  等联盟致力于将开源 Linux 操作系统推广至汽车领域中。AGL（Automotive Grade Linux） 是一款基于开放源代码的车载操作系统。Linux 基金会推出可定制、 开源的车载系统平台 AGL，旨在成为未来车载系统开源标准平台。互联汽车系统联盟（COVESA） ， 前身为 GENIVI 联盟， 专注于实现对车载信息娱乐系统开源开发平台的广泛普及。

不论是 AGL、 GENIVI， 还是原生 Linux， 由于其对硬件外设驱动支持性高、 软件生态丰富等特性， 成为了现阶段汽车操作系统首选之一， 但其依然面临缺乏功能安全的局限。为此，Linux 基金会启动了 ELISA 开源项目， 致力于联合业界厂家研发以功能安全级别 ASIL-B 为目标的 Safety Linux 操作系统。Safety Linux 操作系统继承 Linux 丰富的应用生态， 可更好地支持汽车高级自动驾驶业务。

ELISA 项目吸引来诸多重量级汽车领域厂商和供应商参与。ELISA 的创始会员包括丰田、宝马、 Intel、 RedHat、 英伟达等， 国内厂家华为、 中兴通讯、 斑马智行、 上汽、 地平线、 国汽智控也已经加入该组织。

目前来看， 实现 Safety Linux 工作量巨大， 尽管 ELISA 发布了一些资料对 Linux 进行了诸多卓有成效的鉴定分析， 但由于系统过于庞大， 后续分析仍然道路漫长， 而基于分析构建的认证工具、 过程资产也需要 ELISA 成员贡献大量的精力， 任重而道远。以 ASIL-B 为目标的 Safety Linux 实现， 尤其对内核关键功能进行安全增强更是一个长期任务。

Android Automotive OS， 主要用于智能座舱操作系统

Google 基于移动端 Android 操作系统， 开发了 Android Automotive OS， 专门服务于汽车领域。由于 Android Automotive 继承了 Android 生态圈开放灵活的优点， 被广泛应用到了车载信息娱乐系统当中（安全性要求较低， 车规要求宽松， 个性化需求多） 。但对功能安全要求高的仪表、 ADAS/AD 相关系统，Android Automotive OS 则无法胜任。

近年来， 智能座舱的娱乐与信息服务属性越发凸显， 目前主流车型的智能座舱操作系统包括 QNX、 Linux、 Android 等。QNX 占据了绝大部分份额， 开源的 Linux 以及在手机端拥有大量成熟信息服务资源的 Android 也被众多厂商青睐。Android Automotive OS 成为后起之秀， 为了加快 Android Automotive OS 在座舱领域的应用进程， Google 建立了一个联盟 OAA，包括奥迪、 通用、 现代、 芯片厂商英伟达等。Android Automotive OS 的买家， 不仅包括绝大部分后装供应商， 同时也有新兴造车势力和传统整车企业。