智能座舱架构与芯片- 软件篇

转载：https://www.zhihu.com/people/du-jiao-jian-mo-91

一、智能汽车基础软件平台分类

汽车软件主要分为应用软件和基础软件。应用软件和业务形态高度关联，不同控制器的应用软件之间差异较大。基础软件介于应用软件和硬件之间，用于屏蔽硬件特性、支撑应用软件。可有效地实现应用软件与硬件之间解耦，非常适合平台化最终形成基础软件平台。

根据中国汽车基础软件发展白皮书3.0所描述，车用基础软件平台分为车用基础软件开发平台和车用基础软件验证平台。其中，基础软件开发平台包含内核、虚拟化模块，中间件，功能软件以及与之相配套的开发工具链，用于支撑应用软件的快速迭代开发。基础软件验证平台通过调试、分析、仿真、测试等手段验证设计和实现的一致性。

1.1 安全车控基础软件平台

安全车控基础软件开发平台主要面向车辆经典控制领域，如动力系统、底盘系统和车身系统等，该类基础软件开发平台对实时性和安全性的要求极高。目前，主流的安全车控基础软件开发平台兼容 OSEK/ VDX 或 Classic AUTOSAR 标准，其功能安全等级需要达到 ASIL-D。

1.2 自动驾驶基础软件平台

自动驾驶基础软件开发平台主要面向智能驾驶领域，用于智能驾驶辅助，以及全自动驾驶功能的控制器上。目前智能驾驶控制器主要使用的底层操作系统有 QNX 以及 Linux。
与安全车控基础软件开发平台相比，对智能驾驶基础软件开发平台的要求主要体现在：

• 强大的计算能力，以满足图像识别和决策计算的要求；
• 强大的数据吞吐能力，以满足多传感器数据的实时接入和处理要求；
• 高度的灵活性、扩展性、可编程性，以满足多种算法模型的需要；
• 易用性，以满足 ADAS 和自动驾驶算法所需调试、调优、调测的需要

当前异构分布硬件各单元所要求的功能安全等级有所不同，AI 单元需要达到 QM 至 ASIL-B，计算单元需要达到 QM 至 ASIL-D。

1.3 信息娱乐基础软件平台

车载信息娱乐基础软件开发平台主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多源信息交互的必要运行环境。

车载信息娱乐基础软件开发平台对于实时性、安全性、可靠性的要求处于中等水平，既可以使用 Android、Linux 等非实时操作系统，也可以使用 QNX、VxWorks 等实时操作系统。为便于应用程序移植，当 前越来越多的车载信息娱乐基础软件开发平台采用 Android Automotive OS 或其他类 Linux 系统。

随着车辆由单纯的交通工具向智能移动终端转变，车载信息娱乐基础软件开发平台需要满足如下要求：

• 支持多样化应用，满足支付、娱乐、导航、信息服务等多样化功能需求
• 支持多生态资源，将手机端庞大的信息娱乐服务生态资源，通过采用相同或类似的操作系统，快速移植到车辆智能终端，避免重复开发
• 安全，通过深度定制达到车辆信息安全和功能安全的标准

1.4 智能座舱软件全景

随着新能源汽车的快速普及，智能座舱成为了一个重要的研发方向。智能座舱是汽车内部的控制中心，可以提供多种信息和服务，包括车辆状态、导航、娱乐等功能。为了实现这些功能，智能座舱需要一个可靠、高效的软件平台来支持。

对于智能座舱软件来说，主要的功能定义就是上述信息娱乐基础软件平台。

在智能座舱的软件平台中，操作系统内核、中间件和虚拟化技术都是非常重要的组成部分。其中，操作系统内核是整个软件平台的基础，它负责管理硬件资源、提供系统调用和进程管理等功能。常见的操作系统内核有Linux、QNX、RTOS等。

在智能座舱的软件平台中，中间件是连接不同组件的重要工具。中间件可以提供消息传递、进程通信、远程调用等服务，从而方便系统的开发和维护。优化中间件可以提高系统的可靠性和性能。

虚拟化技术是将物理资源虚拟化为多个逻辑实例的技术。在智能座舱中，虚拟化技术可以用于隔离不同的系统组件，提高整个系统的可靠性和安全性。常见的虚拟化技术包括Hypervisor和容器技术。Hypervisor是一种虚拟化技术，它可以将物理服务器虚拟化为多个虚拟机，从而提高整个系统的可扩展性和灵活性。而容器技术则是将操作系统层面进行虚拟化，从而提高系统的性能和资源利用率。

二、车用操作系统

2.1 AutoSAR CP

AUTOSAR CP 是 Classical Platform AUTOSAR 的简称，广泛用于对实时性、安全性要求高的动力域控、底盘域控、车身域控等方面，以达到软硬件解耦、提高开发效率、提升软件复用性等目的。
在智能汽车软件平台领域方面，AUTOSAR CP一般不用于信息娱乐域。本文只简要介绍AutoSAR CP的基本概念，不做详细解读。

• AutoSAR CP的软件分层架构

在 AUTOSAR CP 分层架构中，自上而下分别为应用软件层（Application Layer）、运行时环境 （Runtime Environment）、基础软件层（Basic Software Layer）

AutoSAR CP Arch

应用软件层：

包含若干个软件组件，软件组件间通过端口进行交互。每个软件组件可以包含一个或者多个运行实体，运行实体中封装了相关控制算法，其运行可由 RTE 事件触发。

运行时环境：

作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能，是 VFB 的具体实现。 RTE 可以实现软件组件间、基础软件间以及应用软件组件与基础软件之间的通信。RTE 封装了基础软件层的服务、提供了标准化接口，使得应用软件层可以通过 RTE 接口调用基础软件服务。此外 RTE 抽象了 ECU 之间的通信，即 RTE 使用标准化接口将 ECU 之间的通信抽象为软件组件之间的通信。

基础软件层：

又可分为四层，包括服务层、ECU 抽象层、微控制器抽象层和复杂驱动。各层又由一系列基础软件组件构成，包括系统服务、存储服务、通信服务等，它们主要用于提供标准化的基础软件服务。

1. 服务层提供了汽车嵌入式系统软件常用的一些服务，包括系统服务、存储服务以及通信服务三大部分。 还提供包括网络管理、存储管理、模式管理和实时操作系统等服务。
2. ECU 抽象层与 ECU 平台相关，但与 微控制器无关，包括板级硬件抽象、存储硬件抽象、通信硬件抽象和 I/O 硬件抽象。该层将 ECU 结构进 行了抽象，负责提供统一的访问接口，实现对通信、存储器或者 I/O 的访问，从而不需要考虑这些资源是由微控制器片内还是片外提供的。
3. 微控制器抽象层是实现不同硬件接口统一化的特殊层，包括微控制器驱动、存储驱动、通信驱动以及 I/O 驱动。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。
4. 最后，由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题， 难以抽象，所以在 AUTOSAR CP 规范中没有被标准化，统称为复杂驱动。

如上所述，AUTOSAR CP 良好的分层架构为软硬件之间解耦、软件模块之间解耦提供了坚实的保障。

• AutoSAR CP的发展历程

对于传统汽车电子开发领域，早期使用的OS是OSEK OS, 其中OSEK是德文“Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug”的缩写，译为汽车电子开放系统及接口。OSEK OS是一个为满足汽车电子可靠性、实时性、成本敏感性等需求而打造的实时单核操作系统(RTAOS)。

AUTOSAR CP 与 OSEK OS联系 ：

首先，AUTOSAR CP是基于OSEK OS继承发展而来，所以上述的OSEK OS的基本特点在AUTOSAR CP都能够得到满足，所以AUTOSAR CP是向后兼容的，也就意味着在OSEK OS上能够运行的应用程序同样也可以在AUTOSAR CP上运行。

除此之外，AUTOSAR CP也存在自身的一些独特的基本特点，下面将从基本属性与系统基本服务两个方面对比OSEKOS 与AutoSAR CP：

• AutoSAR CP 的优缺点

1. 架构充分解耦导致标准和接口规范繁多。AUTOSAR CP 的规范文档非常详尽，但正是两百多个多达几万页的标准文档让一些传统的嵌入式工程师望而止步。同时 AUTOSAR CP 提出了很多新概念，比如标定量通过描述文件进行描述；应用接口不通过传统全局变量的方式与底层软件交互，而是 对接口进行描述定义通过 RTE 统一接口进行匹配等。AUTOSAR CP 的软件开发理念和传统嵌入式工程师的认知偏差也是其普及率不高的原因之一。
2. 工具链价格昂贵。目前AutoSAR CP的工具链都是老牌经典的AutoSAR OS公司所有，软件授权和开发费用非常高。
3. 工具链之间兼容性差影响合作开发的灵活性。由于各厂商对 AUTOSAR CP 规范的理解并不完全一致，而且各厂商的工具也并不完全兼容，导致 OEM 集成各家供应商开发的软件模块需要花费大量的精力和时间。
4. 自动化程度低导致开发和集成效率偏低。基础软件与应用软件的接口集成需要大量的手动配置工 作，不仅操作上低效出错率高，而且在错误检查方面也不如传统软件集成方便。
5. 代码可读性差导致调试困难。这是代码生成工具普遍存在的问题，和 MATLAB 的 AUTOSAR 工 具箱生成的代码一样，一些 AUTOSAR 工具链的 RTE 代码生成工具生成的代码可读性也较差，这给软件 调试带来了不少麻烦。

2.2 AutoSAR AP

在基于域的EEA架构体系中，智能座舱域通常使用Linux 或者Android作为操作系统；车身控制域一般使用AutoSAR CP；自动驾驶域通常使用Linux或者QNX。

新能源汽车在由分布式EE架构向中央计算-区域控制EE架构发展的过程中，一些厂商认为，需要在中央计算平台中提供一个高灵活，高性能且支持SOA的新软件平台-- Adaptive Platform AutoSAR，简称AutoSAR AP。

• 什么是AutoSAR AP

AUTOSAR 组织在 2017 年推出了新的 AUTOSAR 平台—— AUTOSAR AP。AUTOSAR AP 的出现是为了填补高性能计算平台上缺乏好用中间件的空白，采用面向对象的 SOA 架构，旨在为上层应用提供灵活的软件开发平台；同时利用汽车行业经验和优势，让所有汽车软件能持续迭代，更快更好地量产上车。

不同于传统的AutoSAR CP，它们的主要区别在于：

AUTOSAR经典平台（CP）标准满足了深度嵌入式ECU的需求，而智能ECU的需求却无法满足。传统ECU的设计目的是专为目标车辆而设计，在车辆使用寿命期间不会有特别大的改动。智能ECU则适应新型EE架构的发展，引入了以太网，高性能计算平台，以及OTA软件升级等。因此，AUTOSAR主持修订了第二个软件平台规范，AUTOSAR自适应平台（AP）。AP主要提供高性能的计算和通信机制，并提供灵活的软件配置，例如支持空中软件更新。专门为CP定义的功能，如访问电信号和汽车专用总线系统，可以集成到AP中，但不在标准化的重点中。

• AutoSAR AP的分层架构

AutoSAR AP的基本构成包括应用程序层、运行时层、操作系统和硬件抽象层。这些组件通过标准化的接口进行通信和协作，以实现整个AUTOSAR Adaptive Platform的功能。

1.应用程序层（Application Layer）：

应用程序层是AUTOSAR Adaptive Platform中的最高层，它包括了所有的应用程序组件。应用程序层通过服务层和运行时层与其他组件进行通信和协作，以实现整个应用程序的功能。User Application 通过原子服务接口(Atomic Service)获取服务：Atomic Service 原子服务提供了一系列的标准化服务，例如通信服务、诊断服务、存储服务等。这些服务为应用程序组件提供了一些基本的功能和接口，以便它们能够相互通信和协作。

2.运行时层（Runtime Layer）：

运行时层提供了一些基本的软件组件和操作系统服务，例如操作系统抽象层、内存管理、进程管理等。这些组件和服务为应用程序组件提供了一个运行环境，以便它们能够在AUTOSAR AP中运行。

3.操作系统和硬件抽象层（Operating System Layer）：

AUTOSAR Adaptive Platform使用基于POSIX标准的操作系统，例如Linux。操作系统层提供了一些基本的操作系统服务和驱动程序，例如文件系统、网络协议栈、设备驱动程序等。这些服务和驱动程序为运行时层和应用程序层提供了底层的支持。硬件抽象层则提供了一个通用的硬件接口，以便AUTOSAR Adaptive Platform可以在不同的硬件平台上运行。硬件抽象层将硬件平台与操作系统层和运行时层分开，以便AUTOSAR Adaptive Platform可以在不同的硬件平台上进行移植和扩展。

• AutoSAR AP的应用场景

根据上述软件架构图可见，AutoSAR AP主要作为中间件而存在，它支持POSIX操作系统，通过服务和API为上层服务提供功能。

在向中央集中式的计算平台发展过程中，目前还按自动驾驶域，车身和底盘域，智能座舱域等进行功能划分。这些域控制器均需得到高性能 MPU 芯片的支撑。基于 POSIX 系统之上的 AUTOSAR AP 平台及相关工具链，为应用开发过程中的效率带来显著提高，而智能座舱域控制器从生态的角度考虑，一般在 Linux 基础之上搭载安卓系统。而诸如 SOA 通信、整车诊断、健康管理的方面则可以参考 AUTOSAR AP 平台标准进行实现。如果考虑到多域融合的发展，在舱驾一体化的道路上，AutoSAR AP和Android将有很大的可能在Hypervisor的基础上实现统一。

• AutoSAR AP的案例

基于AutoSAR AP的应用场景，可以以一个OTA升级的案例来进行讲述。

本节主要介绍基于 AP 的智能域控制器（后续简称 IDC）OTA 升级场景及其实现方案。

IDC 的 OTA 功能可以进行自身应用软件及系统软件、关联器件固件的升级，并在数据管理、软件升级、可追溯性、安全验证方面满足 AP 的相关要求。

在OTA的功能实现过程中，IDC与外界的数据交互如图所示。

云端OTA云服务器向车端HUT（终端信息展现单元 Head Unit & Telematics）推送升级任务，用户确认升级后，HUT 会通过网关向 IDC 及 其他 ECU 以 UDS 的形式发送升级指令及升级数据，IDC 接收升级指令与数据后，在确保安全的情况下 完成软件升级并向 HUT 反馈安装进度及安装结果。

1. 数据传输与管理

a. IDC 内部分为 OTA 进程和 UDS Server 进程，UDS Server 进程与 HUT 端交互，负责处理、转发 指令和接收软件包，OTA 进程处理软件包进行升级。
b. OTA 使用专用的磁盘分区保证有足够的资源来存储软件包及相关数据，从而保证数据的安全性。
c. IDC 会进行完整性校验以保证软件包的完整性。
d. OTA 结束后，IDC 会删除临时数据，最大限度节省空间。

2. 软件升级

a. OTA 采用双分区机制，通过活跃分区去升级备份分区，升级成功后重启备份分区，完成备份分区 和活跃分区的互相切换，轻松实现 IDC 上的应用软件、中间件、操作系统、配置数据的安装、更新、删除。
b. OTA 采用双分区机制，通过切换启动分区，可以实现 IDC 上所有软件及数据的快速回滚功能。
c. OTA 支持周边器件的升级，如 MCU、相机等。
d. OTA 内部维护状态机，状态变化实时落盘，可以支持在异常中断后恢复升级。

3. 可追溯性

a. OTA 提供获取当前软件版本号、安装进度、安装结果的接口。
b. OTA 会记录升级过程中的日志，供 HUT 获取。

4. 安全性

a. OTA 在软件升级前会使用强加密算法校验证书链与软件包签名，保证软件包的真实性及完整性。
b. OTA 在软件升级前会检查当前车速、IDC 的温度、供电情况，保证在安全的情况下进行 IDC 软件 升级。
c. OTA 时会激活 IDC 心跳监控机制及分区损坏回滚机制，当切换到备份分区启动失败后，IDC 不会 给 MCU 发送心跳报文，MCU 会认为 IDC 在 OTA 后变砖，会给 IDC 断电重启，切回原分区启动，保证车机可用。

2.3 虚拟化Hypervisor

• 为什么需要虚拟化

随着汽车电子电气架构从分布式架构到Domain域架构，再到中央计算-区域控制架构的演变，分散的ECU 功能集成到车载中央计算机，这就是多域融合的趋势。 汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算，而是需要复杂的多核 SoC 芯片提供更为复杂控制逻辑以及强大的算力支持。但是多域业务具有不同的技术需求，比如座舱域业务强调交互体验、应用生态丰富，比较适合的操作系统是 Android；车控域有实时性、可靠性要求，操作系统倾向于 RTLinux、RTOS；智驾域强调大算力融合感知、推演规划，也有实时性、可靠性要求，也会选择RTLinux、RTOS。

在未来，多域融合技术集成到一颗SOC之上时，需要考虑关键业务的安全可靠和实时性技术要求，又要考虑到丰富的生态应用，这些需要不同的操作系统才能支持。如何在一颗SOC上划分资源，并发运行多种操作系统，保证多域融合的可靠性，需要有资源隔离技术的支持。

资源隔离技术有多种，从硬件底层逐层向上包括硬件隔离、虚拟化隔离、容器隔离、进程隔离等。硬件隔离的隔离性最好，性能、安全、可靠性都有保证；但灵活性、可配置性差，不能实现硬件共享， 导致整个系统的资源利用率差，不能充分达到软件定义汽车的目标。容器隔离、进程隔离可以更轻量级地实现业务隔离，但还是在同一个操作系统内，存在着资源干扰、相互安全攻击的隐患，并且无法支持异构操作系统业务域融合，影响传统业务继承，不利于生态发展。

目前，在智能座舱域的实际应用中，硬件隔离和虚拟化隔离都有实际的使用范例。

• Hypervisor

在新能源汽车智能座舱中，虚拟化技术也被广泛应用，以提高系统的资源利用率、可靠性和安全性。虚拟化技术可以将一台物理服务器划分成多个虚拟机，每个虚拟机都可以独立运行不同的应用程序和操作系统。

虚拟化技术可以分为两种类型，一种是基于Type1类型的Hypervisor的虚拟化技术，另一种是基于Type2类型的虚拟化技术。

Type1类型的Hypervisor是一种直接运行在物理服务器硬件上的虚拟化软件，也被称为裸机Hypervisor。Type1类型的Hypervisor能够直接访问服务器的硬件资源，包括处理器、内存、网络和存储等，能够提供更高的性能和稳定性。在智能座舱中，Type1类型的Hypervisor可以被用来运行多个虚拟机，每个虚拟机可以运行不同的操作系统和应用程序。同时，Type1类型的Hypervisor还可以提供强大的安全隔离功能，确保不同的虚拟机之间互不干扰，从而提高整个系统的可靠性和安全性。

相比之下，基于Type2的虚拟化技术则是运行在操作系统之上的虚拟化技术。虚拟机OS可以与主机OS共享同一个操作系统内核，这样可以减少虚拟化层的开销和系统资源的占用。虚拟机OS位于主操作系统之上，可以将应用程序及其依赖项封装成一个完整的软件单元，从而实现应用程序的快速部署和扩展。在智能座舱中，基于Type2的虚拟化技术可以用于隔离不同的应用程序和服务。

Type 1类型的Hypervisor直接运行在物理硬件之上，直接访问物理硬件并管理所有硬件资源，在延时、安全性和效率上更胜一筹。但此类型Hypervisor需要硬件支持，移植难度大，开发成本也较高，在互联网领域常用于数据计算中心。

Type 2类型的Hypervisor运行在某个操作系统之上，利用操作系统访问物理硬件，因此在延时方面具有不可避免的劣势。且底层操作系统的任何Bug都将危及其上的虚拟机，因此安全性方面相对较弱。但是移植难度小，开发成本低。在互联网领域常用于客户端系统。

Hypervisor可以将一台物理服务器划分成多个虚拟机，每个虚拟机可以独立运行不同的操作系统和应用程序。Hypervisor能够提供强大的安全隔离功能，确保不同的虚拟机之间互不干扰，从而提高整个系统的可靠性和安全性。同时，Hypervisor还能够动态调整虚拟机的资源分配，以满足系统运行的需求。在智能座舱中，使用Hypervisor可以实现多个应用程序之间的隔离，从而提高系统的可靠性和安全性。

Hypervisor具有如下功能：

（1）设备模拟。Hypervisor可以创建客户操作系统可以访问的一些虚拟硬件组件，是否需要取决于客户操作系统上运行的应用程序；

（2）内存管理。Hypervisor负责为自身和客户操作系统管理和分配硬件内存资源；

（3）设备分配和访问。Hypervisor通常可以将硬件组件分配给客户操作系统，并控制客户操作系统实际可以访问哪些硬件组件；

（4）上下文切换。当Hypervisor需要在内核上安排新的客户操作系统时，Hypervisor必须通过将在该处理器内核上运行的现有客户操作系统的“上下文”（即操作条件）保存到内存中来“切换上下文”。然后进行加载新的客户操作系统时，可以从内存中访问新的客户操作系统，而不会中断执行环境；

（5）捕获指令。客户操作系统可能会根据其访问权限级别执行技术上不应执行的指令。Hypervisor可以分析客户操作系统尝试发送到硬件的指令，并模拟硬件对客户操作系统指令的响应；

（6）异常处理。发生异常（即异常行为）时，可以将某些异常路由到Hypervisor进行处理；

（7）虚拟机管理。如前所述，Hypervisor最终负责启动和停止客户操作系统在其上运行的虚拟机。

• 区域硬隔离

与Hypervisor虚拟化相对应的一种多操作系统应用方式，是区域硬隔离。

它是通过物理隔离来保障不同系统组件之间的安全。比如说，在智能座舱SOC规划与设计的时候，根据功能划分的不同，在同一颗SOC内部划分出不同的CPU内核，以及其他物理硬件资源，并分配给不同的功能来使用。比如，仪表盘就可以使用独立的CPU核和独立的显示模块，并运行独立的RTOS操作系统。

区域硬隔离能够提供更高的安全性和隔离性，避免不同的系统组件之间的相互干扰。在智能座舱中，区域硬隔离可以被用于对关键系统组件的保护，从而提高整个系统的可靠性和安全性。

在智能座舱中，使用Hypervisor和使用区域硬隔离都有其优势和不足。实际上，二者的选择取决于智能座舱芯片供应商的所选择的技术路线，也取决于主机厂对可靠性和芯片性能的判断。

 

• Hypervisor与区域硬隔离的优缺点

以仪表盘的实现为例，现代智能座舱的发展，要求支持“一芯多屏”的功能。顾名思义，就是要求在一颗智能座舱SOC芯片上，同时支持实现液晶仪表盘功能和娱乐中控大屏功能，甚至还有其他的屏幕。

由于液晶仪表盘属于高安全性和高可靠性领域，一般需要使用RTOS操作系统。娱乐中控大屏需要有丰富的生态应用，一般需要使用Android系统来支持。

区域硬隔离和Hypervisor都可以用于实现仪表盘功能，但它们有各自的优缺点。

综上所述，使用区域硬隔离和Hypervisor都可以实现仪表盘功能，需要根据具体的场景和需求进行选择。如果对可靠性和安全性要求较高，可以选择区域硬隔离；如果需要灵活性和可扩展性，可以选择Hypervisor。

三、智能座舱操作系统

3.1 概述

车载智能计算平台自下而上可大致划分为硬件平台、系统软件（硬件抽象层+OS内核+中间件）、功能软件（库组件+中间件）和应用算法软件等四个部分。狭义上的OS特指可直接搭载在硬件上的OS内核；而广义OS从下至上包括从BSP、操作系统内核、中间件及库组件等硬件和上层应用之间的所有程序。

 

• 硬件抽象层

硬件抽象层里包含BSP和Hypervisor。

Hypervisor 是一种运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件,也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。Hypervisors是一种在虚拟环境中的“元”操作系统。他们可以访问服务器上包括磁盘和内存在内的所有物理设备。

BSP(board support package)即板级支持包，也是介于主板硬件和操作系统之间的一层，主要目的是支持操作系统，使之能够更好的运行于硬件主板。

• 操作系统内核

OS内核又称为“底层OS”，提供操作系统最基本的功能，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。

智能座舱作为新能源汽车的核心部分，通常需要运行多个不同的软件应用和服务，例如车辆信息娱乐系统、导航系统、车辆诊断系统、驾驶辅助系统等。这些应用和服务需要在智能座舱中使用不同的操作系统内核来管理系统资源、控制硬件设备和提供系统服务。以下是一些常见的操作系统内核的例子：

1. Linux内核：Linux是一种开源的操作系统内核，广泛应用于各种嵌入式系统和移动设备中，包括新能源汽车智能座舱。Linux内核具有高度的可定制性和灵活性，可以根据座舱系统的需求进行定制和优化。例如，很多智能座舱系统使用基于Linux内核的Android Automotive操作系统，提供丰富的应用和服务支持。
2. QNX内核：QNX是一种实时操作系统内核，被广泛应用于汽车领域。QNX内核具有高度的实时性和可靠性，适用于对系统响应时间和稳定性要求较高的智能座舱应用，例如车辆的安全和驾驶辅助系统。
3. AUTOSAR（Automotive Open System Architecture）内核：AUTOSAR是一种开放的汽车电子系统架构，包括了一系列的软件规范和标准。AUTOSAR内核是一种用于汽车电子系统的标准化操作系统内核，可以提供统一的软件接口和服务，实现不同硬件和软件模块之间的互操作性和可替换性。许多新能源汽车厂商使用AUTOSAR内核来构建其智能座舱系统。
4. Windows内核：作为一种常见的桌面操作系统，Windows内核在某些新能源汽车智能座舱中也有应用。例如，一些电动汽车厂商采用基于Windows内核的操作系统来构建其车辆信息娱乐系统，提供丰富的图形界面和多媒体功能。

• 中间件

中间件，作为底层操作系统和这些应用程序之间的桥梁，是对软硬件资源进行管理、分配和调度的平台，充当着软件和硬件解耦的关键角色。 具体来说，中间件通常对传感器、计算平台等资源进行抽象，对算法、子系统、功能采取模块化的管理，通过提供的统一接口，让开发人员能够专注于各自业务层面的开发，而无需了解无关的细节。这为开发者快速、高效、灵活地开发和集成自动驾驶软件提供了极大的便利。

因此，从系统软件的角度来说，车载操作系统主要考虑的就是BSP，Hypervisor，OS内核，以及中间件等因素。目前座舱新应用层出不穷，和手机关联度也比较高， Android是最佳选择，但考虑到安卓背后的谷歌一家独大，车厂无力掌控，日本和欧洲车厂更倾向于 Linux。中美厂家都拥抱安卓， 中国厂家尤其注重生态系统，因此几乎全部选择手机版的安卓做一些微小修改。美国厂家则多选择车机版安卓。因为谷歌的某些应用在国内无法使用，国内一般不使用完整的车机版安卓。

QNX几乎不会作为独立的智能座舱操作系统而被选用，一般可以与Android共同作为Hypervisor之上的虚拟机VM而协同工作。

3.2 Android

Android是发行版本的Linux， 系统复杂， 功能强大。Android是由Google公司和开放手机联盟基于Linux开发的操作系统。Android被称为基于Linux开发的最成功的产品之一， 应用生态最为丰富， 主要应用于移动设备，在国内智能座舱操作系统常基于Android开发。

Android的主要优点有：

1) 开源， 对中低端OS开发商具有很强吸引力；

2) 灵活， 可以根据自身需要对原生Android进行定制化改造；

3) 可移植性强， Android手机上的APP不需要经过大的修改就可以应用在车机上， 有利于国内互联网厂商切入汽车领域， 快速建立起车载软件生态。

Android的缺点主要有：

1) 安全性、稳定性差，系统漏洞带来较高风险，技术维护成本高；

2) 过度依赖于Google。

在智能座舱操作系统的选择中，虽然还没有哪一个系统的市场份额占据绝对优势，但从软件定义汽车的角度出发，以及新能源汽车的发展历程来看，智能座舱域主要考虑的是应用的生态和智能化的发展。在实践中可以看到，Android系统体现出越来越大的优势。这里面最重要的原因就是智能座舱的生态环境可以与手机等消费类电子产品的生态打通，在手机上流行的应用APP，同样可以移植到汽车的智能座舱环境中来。比如说，导航类APP，音乐类APP，视频类APP，内容类APP，可以方便地实现车机手机统一账户，统一资源等。

Android凭借国内丰富的应用生态切入汽车智能座舱系统。虽然安全性、稳定性不足，但由于车载信息娱乐系统对安全性要求相对较低， Android仍然凭借其上述优点在国内车载信息娱乐系统领域占据主流地位。尤其是各大互联网巨头、自主品牌、造车新势力纷纷基于Android进行定制化改造， 推出了自己的汽车操作系统， 如阿里Al iOS、百度小度车载OS、比亚迪Di Link、蔚来NIO OS、小鹏X martOS等。

• Android AUTO vs AAOS vs 传统Android

谷歌也分别推出了 Android Auto 和 Android Automotive OS，安卓 Auto 是一个超级 App，不是一个操作系统，但 Android Automotive OS 就是一个操作系统，简称 AAOS。Android 官网上， Android Auto 这个分类， 是和 Android TV、Web OS by Google 并列。而在 Android 官网开发者页面处，我们能发现更多谷歌意图独立车载系统的想法。 在 Google 官方的「Android developer guide」（安卓开发者引导） 中 ， Android Automotive OS 和 Chrome OS 也 是 以 「 OS （operation system，操作系统）」命名的。AAOS 确实是为了解 决 Android 本身在车机方面的一些问题。Automotive OS 采用了 与传统安卓差异较大的显示和交互逻辑 ，「区块」成为 Automotive OS 最基本的设计语言。在操作准确度要求非常高的 车内环境里面，触屏相对孱弱的反馈被谷歌以硕大的图标设计和菜单划分得以补偿。

1. Android Auto

首先，Android Auto 不是 OS。它是集成在 Android OS 里的 feature。当通过 USB、Wi-Fi 将 Android Phone 连接到支持 Android Auto 的车机上后，Android OS 将自动加载支持 Auto 模式下的 App 并将图像投屏到车机屏幕上。

跟 CarPlay 一样，其本质上是投屏。Phone 提供计算、渲染，车机只是 Display，Display 和按键回传 Input 的事件，Phone 处理好之后将新的帧数据回传进行 Display。

2. Android automotive OS

Android automotive 是在原手机Android 的系统架构基础上替换为与车相关的模块。主要包括:

• Car App :包括OEM和第三方开发的App;
• Car 提供给汽车App特有的接口;
• Car Service :系统中与车相关的服务;
• Vehicle Network Service :汽车的网络服务;
• Vehicle HaL :汽车的硬件抽象层描述。

Android Automotive OS主界面是平均分配的四张功能卡片（Google Map地图、语音助手Google Assistant、电话和应用），随着地图的优先级降低，整体高频车载功能的优先级提高，快捷图标可以最大限度减少驾驶员会分心的情况。车辆重要的功能，如摄像头和车辆控制等放置在靠近驾驶座的左上角，方便司机触达。

3. 传统Android

国内新能源车企，一般采用自研座舱OS的模式，在传统Android版本的基础上修改出具有自身风格的智能座舱操作系统。这样做的好处毋庸讳言，类似手机OS一样，可以带来更大的用户便利性，以及更强的用户黏性。这一点与外资车企具有相当大的不同。我们从国内车企来看，蔚来，小鹏，理想均采用自研OS，基于传统Android版本进行修改。AITO问界采用华为鸿蒙车机，也类似于Android的操作界面。

• 蔚来

• 小鹏

• 理想

• 问界

那么，厂商根据标准Android版本进行定制化开发，与Android Automotive OS的区别在哪里呢？

---

咨询ChatGPT的回答如下：

1. 界面设计：Android Automotive OS的用户界面与传统的Android系统有很大的不同。它的界面更加简洁、易于操作，更适合在驾驶过程中使用。

2. 应用程序：Android Automotive OS的应用程序与传统的Android系统也有所不同。它的应用程序更加专注于驾驶和车辆信息，如导航、音乐等，而不是传统Android系统中的社交媒体、游戏等应用。

3. 安全性：Android Automotive OS在安全性方面比传统的Android系统更为重视。它采用了更加严格的安全措施，以确保驾驶过程中的数据和信息安全。

4. 系统架构：Android Automotive OS的系统架构与传统的Android系统也有所不同。它采用了更加模块化的设计，以便于车载设备的集成和维护。

总之，Android Automotive OS是专门为汽车设计的操作系统，相比传统的Android系统，更加注重驾驶和车辆信息的应用，同时也更加注重安全性和系统架构的优化。

---

目前，还很难说Android automotive OS与厂家基于Android自研修改的OS哪个能脱颖而出。但或许基于不同的市场环境和用户生态，这些智能座舱OS都还在埋头发展，零和游戏的时刻尚未到来。

3.3 Linux

这里的Linux特指非Android的Linux发行版软件，或者基于开源Linux内核所修改而来的厂商自研OS。虽然说Android也是架构在Linux 内核之上的，但由于它早已具有独立而强大的生态，因此一般单独介绍。我们通常提的基于Linux开发新的操作系统是指基于Linux Kernel进一步集成中间件、桌面环境和部分应用软件。

Linux 领域再分为三类：一类是完全独立的开发版本，如特斯拉；二是松散联盟性质的 Genivi；最后是车规级 Linux 的 AGL。

• 独立开发的Linux

这里的代表之作为Tesla。Tesla的座舱采用x86 CPU+Linux版本。对于不同的车型来说，Telsa交替采用英特尔或AMD的SOC芯片作为座舱SOC，采用自研FSD芯片作为ADAS SOC。它的软件平台基于Linux 内核所打造。

特斯拉的座舱软件平台使用的是基于Linux的自主开发操作系统，称为Tesla OS。这个操作系统是特斯拉自己开发的，基于Debian Linux，但是经过了大量的修改和自定义，以适应特斯拉车辆的特殊需求和功能。Tesla OS不仅包括车辆的座舱软件平台，还包括车辆的控制系统和网络系统等。特斯拉的座舱软件平台是由一组定制的应用程序组成的，包括导航、娱乐、通信、驾驶辅助和车辆设置等。这些应用程序都是基于Tesla OS开发的，可以通过车载屏幕、语音控制和手机应用程序等方式进行访问和操作。

Tesla OS采用Linux 4.4开源操作系统， 支持PyTorch的深度学习编程框架， 基于Kafka开源流实时数据处理平台， 可支持信息娱乐系统(IVI) 和驾驶辅助系统(ADAS) 等。特斯拉选择Linux一方面由于Linux开源自由的优点， 避免受制于操作系统厂商；另一方面则发挥其内核紧凑高效、可以充分发挥硬件性能的优点，满足了特斯拉对汽车性能的要求。

• Genivi

GENIVI是一个开源的汽车软件联盟，致力于开发和推广开放标准和技术，以支持汽车电子系统的开发和集成。该联盟成立于2009年，由一些主要的汽车制造商、供应商和软件开发公司组成，包括宝马、戴姆勒、通用汽车、飞利浦、英特尔、纳芙特、Wind River、Harman和Bosch等。GENIVI的目标是创建一个基于开放标准的汽车软件平台，以促进汽车电子系统的发展和创新。

GENIVI的软件平台基于开放标准的Linux操作系统，包括许多开源软件组件和工具，如QT、GStreamer、DBus、WebKit、BlueZ、Systemd等。GENIVI的软件平台提供了许多功能，如车载娱乐、导航、通信、驾驶辅助、车辆诊断和远程服务等。该平台还提供了一个开发框架，使开发人员可以快速开发和部署汽车应用程序和服务。

许多汽车制造商和供应商正在使用GENIVI的软件平台，以开发其汽车电子系统。一些使用GENIVI的汽车制造商包括宝马、戴姆勒、通用汽车、PSA、雷诺等。同时，一些汽车供应商和软件开发公司也在使用GENIVI的软件平台，如飞利浦、英特尔、纳芙特、Wind River、Harman、Bosch等。

• AGL

AGL 即 Automotive Grade Linux，车规级 Linux。成立于 2016 年 1 月，但是第一版 AGL 发布是在 2014 年的 6 月 30 日，实际 上就是 Tizen 的修改版，Tizen 源自三星，Tizen 是三星电子开发 的一款基于 Linux 核心的开放源代码移动操作系统，可适用设备 包括智能手机、平板电脑、智能手表、上网本、车载消息娱乐 设备（IVI）和智能电视。该项目最初由 Linux 基金会以及 LiMo 基金会合力推出，目的在于取代 MeeGo 与 LiMo 平台。在 Linux 基金会中，由技术指导小组（TSG）管理。

AGL 的顶级白金会员有亚马逊、马自达、电装、瑞萨、铃木、丰田、松下。白银会员则有爱信精机、奔驰、福特、高通、 上汽、大众。其他重要会员还有阿尔派、ARM、博世、BOSE、 中国移动、大陆、德赛西威、富士通、本田、现代、三星哈曼、 HERE、日立、GreenHills、英特尔、JVC 建伍、李尔、LG、马瑞 利、Mentor、Microchip、三菱、NEC、东软、日本精机、NXP、 英伟达、三星、先锋、索尼、东芝、Telechips、德州仪器。 目前采用 AGL 的车型主要有新一代奥迪 MIB3TOP、丰田凯美瑞、马自达 3 和斯巴鲁傲虎及力狮。还有一款奔驰的 MPV。 大众在 2019 年 4 月加入 AGL。

AGL 的主要优势之一是它的统一代码库（UCB），这是一个 新的 Linux 发行版，它基于 AGL 和另外两个汽车开源项目：Tizen 和 GENIVI Alliance。UCB 是第二代 Linux 汽车系统。它从底层开 始开发，一直到特定的汽车应用软件。完成了操作系统大约 70% 的工作。

目前 AGL 应用都在 IVI（In-Vehilcs Infotainment）上，AGL 正 努力开拓在仪表和 ADAS 领域，不过这两个领域对实时性要求较高，阻力很大。

• YOCTO

Yocto是一个开源的嵌入式Linux发行版，它提供了一个开发框架，可以帮助开发人员快速构建定制的Linux系统。Yocto的目标是使嵌入式Linux开发更加简单、快速和可靠，使开发人员能够轻松地创建定制的Linux发行版，以满足特定的嵌入式设备需求。

Yocto项目包括一个工具集，可以用于构建和管理嵌入式Linux系统，包括构建工具链、交叉编译器、调试器、库、应用程序和文件系统等。Yocto还提供了一个强大的软件包管理系统，可以让开发人员轻松地添加、删除和更新软件包。

许多汽车厂商目前仍在使用Yocto，特别是在车载娱乐系统和智能座舱软件的开发中。Yocto提供了一个灵活的开发框架，使开发人员能够快速构建和定制Linux系统，以满足特定的汽车应用需求。同时，Yocto还提供了丰富的软件包和工具，使开发人员能够快速开发和部署嵌入式应用程序。

使用Yocto的汽车厂商有：通用，丰田，福特，雷克萨斯，捷豹路虎等。

根据以上信息可以看到，很多汽车厂商都曾经使用了不止一个Linux发行版本来作为自己旗下车型的智能座舱软件平台。这说明在Linux系统在传统汽车企业中的地位。

3.3 QNX

QNX是目前车载软件中使用得最多的操作系统。

Gordon Bell和Dan Dodge在1980年成立了Quantum Software Systems公司，他们根据大学时代的一些设想写出了一个能在IBM PC上运行的名叫QUNIX（Quick UNIX）的系统，直到AT&T发律师函过来才把名字改成QNX。从QNX的最初命名可以看出，QNX是一种类UNIX的操作系统，其遵守POSIX规范，也就是说在Linux(也遵守POSIX规范)上编写的应用程序可以不作修改重新编译后可以直接在QNX上运行。

2004年，音响设备制造商 Harman 国际工业公司收购了QNX。2010年，黑莓手机（BlackBerry）制造商RIM宣布收购哈曼国际工业集团旗下的QNX软件公司。

在汽车领域，QNX早已是最大的操作系统供应商。据不完全资料显示，QNX在车用市场占有率达到75%，目前全球有超过230种车型使用QNX系统，包括哈曼贝克、德尔福、大陆、通用电装、爱信等知名汽车电子平台都是在QNX系统上搭建的。几乎全球所有的主要汽车品牌包括讴歌、阿尔法-罗密欧、奥迪、宝马、别克、凯迪拉克、雪弗兰、克莱斯勒、戴姆勒、道奇、菲亚特、福特、通用汽车、本田、悍马、现代、英菲尼迪、捷豹、吉普、蓝旗亚、马自达、马赛地、迷你宝马、三菱、尼桑、欧宝、庞迪克、保时捷、萨博、土星、双龙、丰田和大众汽车等目前都采用了基于QNX技术的系统。

QNX的特点：

QNX是一个微内核，嵌入式，非开源，安全实时的操作系统。它的软件架构分层如图所示：

从上图可以看到，在硬件层之上，QNX提供了板级支持包BSP，RTOS微内核，软件中间件，以及支撑应用的增强服务层等。

• 微内核

QNX是典型的微内核结构操作系统， 有一个非常小的微内核Neutrino 约为12K。内核提供了中断处理，定时器处理，线程的建立与调度等任务。另外有一个进程process manager来负责进程的建立和地址空间管理的功能， 与内核运行在内核空间。其他功能模块运行在用户空间。QNX对所有的进程均提供了内存保护， 包括文件系统， 资源管理器， 应用程序等。

QNX是一个典型的RTOS系统，其内核支持实时抢占式调度。

QNX 使用基于优先级的虚拟 CPU 共享模式，每个虚拟 CPU 拥有自己的优先级和时间任务安排序列（scheduling），确保高安全优先级 OS 能够从低优先级 OS 那里抢占更多的物理 CPU 资源。虚拟 CPU 拥有估计资源预算能力，进而在物理 CPU 上实现自适应分区。能够最大化利用硬件资源。

• 半虚拟化

QNX Hypervisor采用半虚拟化的方式来支持硬件设备的虚拟化操作。在一个双内核虚拟机架构体系中，VM2为Android 虚拟机，VM1 为QNX Host 虚拟机， Hypervisor为 QNX提供的Hypervisor。对于硬件资源的虚拟化，Android VM访问硬件资源可以有2种方式：

1. Front-Back End 服务方式

为避免全虚拟化的性能问题，可以采用 GuestOS 与 Hypervisor 协作的半虚拟化技术。这种技术一般应用于 IO 设备虚拟化， 采用前后端的方式来实现 。在 Guest OS (如 Android VM2） 中实现前端驱动，在 Hypervisor 或 Host OS (如QNX Host VM1) 中实现后端驱动，前后端一般按照 VirtIO 标准来实现，后端驱动作为硬件的实际访问方。

2. Pass-through 直接访问方式

Hypervisor 支持将硬件资源直接分配给其上虚拟机中 VM2 使用，无需通过 Hypervisor 进行地址和指令翻译。例如 : 串口资源、USB 资源等接口比较丰富的资源可以通过 Pass-through 直接分配给某虚拟机使用。设备控制器一般都是以 MMIO 方式来访问的，所以只需要将控制器地址区域映射到 VM 就 可实现设备控制器的分配，同时还需要分配一个设备硬件中断对应的虚拟中断到该 VM，直接透传的方式 就是 VM 独占访问该硬件，所以在性能上是最好的。

• 功能安全

QNX已经获得了ASIL-D的认证。QNX的安全性和可靠性使其成为满足汽车电子系统安全标准的理想选择。QNX的ASIL-D认证证明了其满足最高级别的汽车安全标准，可以在高度安全性和可靠性的环境中运行。QNX的ASIL-D认证包括QNX Neutrino实时操作系统、QNX Momentics开发工具和QNX Hypervisor虚拟化平台等产品。QNX的ASIL-D认证是基于国际标准ISO 26262开展的，该标准是用于开发汽车电子系统的安全标准。

• 智能座舱的应用案例

在国内新能源车企的智能座舱软件平台中，由于普遍采用了高通的SOC作为座舱芯片，因此基本会采用QNX+Android双虚拟机的方式。其中一个典型的应用就是QNX实现仪表盘，Android实现中控娱乐屏应用。

底层是采用QNX的hypervisor技术，实现硬件资源的虚拟化。

上层分为2个虚拟机VM。其一是QNX Host，它主要实现仪表盘的图形生成，渲染等任务。根据上述半虚拟化的实现，由QNX实际控制SOC芯片中的GPU和DPU等硬件资源。

由于QNX具有实时性和安全性的特点，它适合为仪表盘功能提供应用服务。

第二个虚拟机是Android VM。由于Android具有良好的生态环境和丰富的应用资源，在中控娱乐屏的使用上具有较大的优势，因此非常适合用于多元化的娱乐域应用场景需求。

四、面向服务的智能座舱软件架构

4.1 面向信号的软件架构

随着汽车电子电气架构向中央计算-域控制器的方向演进，甚至向车云一体化的方向迈进，适用于汽车的软件平台也需要进行相应的进化。

在传统的观念中，座舱域即娱乐域，座舱软件架构即运行在座舱域控制器上，主要处理各种娱乐系统的信息，为汽车用户提供丰富多彩且方便可用的娱乐信息系统。

与之相对应的，是基于信号架构的座舱软件体系。

4.2 软件架构演进

面向信号的软件架构，匹配的是分布式ECU的电子电气架构。但随着EE架构的演进，自动驾驶域，车身控制域，智能座舱域逐步融合成统一的中央计算平台。此时的智能座舱软件系统已经不仅仅承载娱乐域功能，还将融合车身控制HMI，车内外通信，ADAS信息显示等一系列的功能。与之所匹配的软件架构，需要演进到面向服务的软件体系架构。座舱软件不是一个独立的域控制器软件体系，而是面向服务的整车软件架构中的一环。

参考一个以用户为中心的融合式智能服务场景，如下：

图片来源：<汽车软件全景图(2022)>

针对上述汽车软件的演进趋势，面向服务的基础软件架构逐渐成为业界共识。相比面向信号的软件架构，面向服务的软件架构主要增加了信息分发和基础服务框架等中间件内容。

其中一个正在进行的范例是ASF软件架构。

ASF是AUTOSEMO Service Framework的缩写，AUTOSEMO (中国汽车基础软件生态委员会)联盟携手行业内主流车企和零部件企业， 针对整车通用基础服务研制的整车服务框架规范。通过该规范统一服务和接口，实现高效的整车控制器 设计、开发，让跨厂商集成更便捷、可靠。

图片来源：中国汽车基础软件发展白皮书3.0

ASF 是一组为功能服务开发、使用和集成而设计的通用化中间件服务集群，服务集群可以被所有的功能服务调用，用于对功能服务在整车平台的能力进行扩展，并实现整车各系统之间的协同，保证整车软件平台的整体性并进行统一管控。

ASF 主要可分为原子服务、SOA 增强型服务、系统级基础服务、整车级基础服务。软件架构设计师需基于各服务类型进行服务定义、设计，使 ASF 分层和功能定义更加清晰。在服务设计过程中遵循以下原则：

• SOA 增强型服务具有通用性：即可为所有的应用服务提供通用功能，应用服务基于服务自身需求可使用该类服务，如数据存储、服务信号转换、服务调试等诸如此类的通用化功能。
• 系统级基础服务，具有一定范围的（如某操作系统或控制器之上）通用性，且具有抽象性：即对基础软件开发平台（如 AUTOSAR Adaptive/Classic、Android 等）提供的通用化功能进行抽象，并提供给应用服务使用，如健康管理服务、网络管理服务、时钟服务、电源管理服务等。
• 整车级系统服务具有全局性：即该类服务的设计更多关注的是整车层面对车内所有系统的通用化功能进行协同和管控，该层服务是对系统基础服务在整车层面的抽象和管控，即通过该层服务可以配置和控制系统基础服务，如整车健康管理服务、整车网络管理服务、整车时钟服务、整车电源 管理服务等。
• 动态服务具有动态配置性：即应用服务在运行过程中可对服务进行配置，并基于配置输入执行动态服务的功能。
• 原子服务具有独立性：即其设计应与硬件配置和实现无关，与上层功能服务层和下层的硬件驱动层解耦，完全独立。
• 原子服务具有原子性：即设计的服务不可再拆分，作为服务的最小单位和执行实体，为功能服务提供最基础的执行或采集等功能

1. SOA 增强型服务

SOA 增强服务是在国际共同讨论的基础平台进行服务框架扩展，封装通用化的基础功能。应用服务调用此类服务的接口更加方便完善其功能软件逻辑、便于系统集成和敏捷测试。 该类服务为一组服务集群，以 Lib 库的形式集成在应用服务中，并提供满足国际共同讨论的自适应 性标准的服务接口，使接口标准完整统一。主要包含模块：服务调试、服务转换、服务权限、服务同步、 SOA For Android、日志管理、动态数据收集、诊断管理。

2. 系统级基础服务

系统级基础服务描述车端各类域控及网关节点，基于通用基础软件提供的底层支持，进行相应的封 装和扩展，实现各类通用化服务功能和框架及在此基础上形成的面向上层应用的各类服务接口（SDK接口、 API 接口、IPC 接口、RPC 接口等）。

系统基础服务包括通用支撑类服务和公共框架类服务。通用支撑类服务包括服务治理（服务发布及发现）及服务容器、服务访问及限流降级、数据订阅及发布、集群管理、消息总线等。公共框架类服务包 括升级管理服务、健康管理服务、网络配置服务、资源管理服务、时钟同步服务、安全管理服务、测试服 务、电源管理服务、日志服务、诊断服务、数据收集等。

3. 整车级系统基础服务

整车级系统基础服务是将各控制器节点的能力，通过跨域、跨核组合成整车级别的业务功能，以对应用层提供整车级统一的调用。整车级系统基础服务包含整车电源管理服务、整车健康管理服务、整车时钟 服务、整车诊断 Master、整车版本管理服务、整车数据采集服务、整车日志管理服务。

4. 动态服务

动态服务工作流通常由车云一体的云端平台（ 比如：开发者平台）提供工具链支持，对接技术生态 及运营，从而在运行态具备灵活更新的能力。动态服务开发流程以逻辑组合建模为主，因此工具链需要 支持可视化 UML 建模，输出模型脚本，并与车端建立同步机制。 动态服务开发面对的角色，不再局限于传统的 OEM/ 供应商角色，而是拓展面向第三方开发者，甚 至是车主。

5. 原子服务

原子服务是执行单一操作功能的服务，具有硬件功能上的不可拆分性。例如获取一个数值或者执行 一个I/O操作。通过将域控制器的硬件功能，拆分为最小功能的原子服务，并统一定义原子服务的访问接口， 从而实现软硬件的完全隔离。软硬件隔离后，车载硬件不再绑定特定的功能，应用软件得以自由使用车 载硬件，实现更加灵活多样化的功能。例如方向盘在正常行驶过程中，用于控制车辆的转向，当车辆处 于非驾驶模式时，又可以成为中控大屏游戏应用的控制手柄。

4.3 面向服务的软件架构

根据上述的描述，我们可以抽象得出面向服务的座舱软件架构，如下：

红色部分主要是从SOA的角度，在座舱软件的中间件部分增加相关服务框架和信息分发机制。一个较详细的分解可以参考汽车软件全景图文档。

图片来源：<汽车软件全景图(2022)>

SOA Framework目前已经是行业内各厂家正在主攻的方向，随着中央计算-区域控制架构的逐步实现，SOA 中间件将发挥出重要的作用。

参考文献

1. 2021中国汽车座舱智能化发展市场需求研究报告.pdf -- 亿欧智库
2. 汽车软件全景图(2022).pdf -- 国科础石
3. 中国汽车基础软件发展白皮书3.0 -- 中国汽车工业协会软件分会