智能座舱架构与芯片- (11) 软件篇上

本文主要是介绍智能座舱架构与芯片- (11) 软件篇上，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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

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

根据中国汽车基础软件发展白皮书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 抽象层、微控制器抽象层和复杂驱动。各层又由一系列基础软件组件构成，包括系统服务、存储服务、通信服务等，它们主要用于提供标准化的基础软件服务。

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

架构充分解耦导致标准和接口规范繁多。AUTOSAR CP 的规范文档非常详尽，但正是两百多个多达几万页的标准文档让一些传统的嵌入式工程师望而止步。同时 AUTOSAR CP 提出了很多新概念，比如标定量通过描述文件进行描述；应用接口不通过传统全局变量的方式与底层软件交互，而是对接口进行描述定义通过 RTE 统一接口进行匹配等。AUTOSAR CP 的软件开发理念和传统嵌入式工程师的认知偏差也是其普及率不高的原因之一。
工具链价格昂贵。目前AutoSAR CP的工具链都是老牌经典的AutoSAR OS公司所有，软件授权和开发费用非常高。
工具链之间兼容性差影响合作开发的灵活性。由于各厂商对 AUTOSAR CP 规范的理解并不完全一致，而且各厂商的工具也并不完全兼容，导致 OEM 集成各家供应商开发的软件模块需要花费大量的精力和时间。
自动化程度低导致开发和集成效率偏低。基础软件与应用软件的接口集成需要大量的手动配置工作，不仅操作上低效出错率高，而且在错误检查方面也不如传统软件集成方便。
代码可读性差导致调试困难。这是代码生成工具普遍存在的问题，和 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和使用区域硬隔离都有其优势和不足。实际上，二者的选择取决于智能座舱芯片供应商的所选择的技术路线，也取决于主机厂对可靠性和芯片性能的判断。