智能汽车车用基础软件的内核和中间件

本章节分别从技术形态、技术发展趋势、关键技术解读、典型应用四个方面对基础软件开发平台的重要组成部分 AUTOSAR CP、AUTOSAR AP、操作系统内核、虚拟化进行介绍。

2.1  AUTOSAR CP

2.1.1  技术形态

AUTOSAR CP 是 Classical Platform AUTOSAR 的简称，广泛用于对实时性、安全性要求高的动力域控、底盘域控、车身域控等方面，以达到软硬件解耦、提高开发效率、提升软件复用性等目的。AUTO- SAR CP 规范不仅提出了软件分层架构，而且定义了基于该规范的标准开发流程，即开发方法论。下面从开发方法论、软件分层架构、工具链这三方面详细说明。

1. 开发方法论

AUTOSAR    CP  为基于该规范的系统开发提供了一个通用的技术方法。它定义了从系统开发到单个ECU开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果物。开发一个系统可分解为以下四个阶段。

一、开发抽象系统描述和基于 VFB( 虚拟功能总线，它描述了系统中所有 SWC 之间的交互关系，与ECU 个数和网络拓扑无关）的系统描述，如图 2.1-1 所示。该阶段首先基于功能提出对整个系统的技术要求和约束条件，并且从功能视角设计合理高效的系统架构。其次，工程师在车辆电子电气架构尚未确定之前就开始基于 VFB 进行系统架构设计，将功能视角的系统架构转为 VFB 视角的系统架构。

图 2.1-1 抽象系统描述与基于VFB的系统描述

二、开发系统和子系统，如图 2.1-2 所示。该阶段将整车的电子电气架构作为输入，结合网络拓扑和硬件资源情况将 VFB 视角的 SWC 分配到各个 ECU，并且将 VFB 的接口转换成能够在通信总线上传输的数据，最后生成 System Extract 和 ECU Extract 供 ECU 软件集成时使用。

图 2.1-2系统和子系统开发

三、开发应用软件和基础软件。在 VFB 视角的系统架构设计完毕后，即可进行原子级 SWC 开发包括实现其内部行为，无需关心具体ECU  信息。另一方面，在系统和子系统设计完成后，即可进行基础软件开发。因为基础软件独立于 VFB，所以只要在 ECU 软件集成前完成开发即可。

四、ECU 软件集成。当 ECU Extract、基础软件、原子级 SWC 都开发完成后即可进行 ECU 软件集成。在该阶段工程师定义好 Schedule Table，将 SWC Runnable 分配到 task 中、补充基础软件配置、生成 RTE 后即可编译链接生成可执行文件。

总的来说，该方法论将汽车嵌入式软件开发分为系统架构级、ECU 级和 SWC 级。系统架构级开发可进行整车级别的软件架构设计以及相关功能模块的定义。ECU   级开发则着重开发单片机底层软件。SWC 级开发则主要开发具体控制算法。各级开发可以并行，不同的开发之间通过标准化的 ARXML 文件进行交互。

2. 软件分层架构

在 AUTOSAR CP 分层架构中， 自上而下分别为应用软件层（Application Layer）、运行时环境（Runtime Environment）、基础软件层（Basic Software Layer）, 如图 2.1-3 所示。

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

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

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

图 2.1-3 AUTOSAR CP软件分层架构

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

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

3.  工具链

V 模型是目前汽车电子软件开发过程中采用的主流开发模式，V 模型左侧统称为设计阶段，主要涵盖业务需求分析（Requirement Analysis）、系统设计（System Design）、架构设计（Architectural De- sign）、模块设计（Module Design）和编码（Coding）五个阶段。V 模型右侧统称为测试阶段，涵盖单元测试（Unit Testing）、集成测试（Integration Testing）、系统测试（System Testing）和验收测试（Ac- ceptance Testing）四个阶段。在V 模型左侧，当前主流商用工具链可以全面支撑 AUTOSAR CP 开发方法论中提到的系统架构级、ECU 级和 SWC 级开发，详细请参考图 2.1-4 AUTOSAR CP 工具链。

图 2.1-4 AUTOSAR CP工具链

参照 AUTOSAR CP 方法论和开发流程，开发工具主要分为以下四类：

一、系统设计工具。一般由 OEM 使用，主要用于完成软件组件框架（端口、端口接口、数据类型、运行实体、触发事件）的设计及框架代码生成；实现软件组件间通信端口的连接；导入 DBC、LDF 等传统网络描述性文件实现软件组件向 ECU 映射等工作。

二、软件组件设计工具。一般由 Tier1 使用，主要用于软件组件框架的搭建，生成符合 AUTOSAR 规范的代码与软件组件 ARXML 文件。之后将 ARXML 文件导入 Matlab Simulink 后可继续进行控制算法模型开发，开发完成后通过自动代码生成获得的 C 代码将用于 ECU 软件集成。

三、MCAL/BSW 配置及 RTE 代码生成工具。MCAL 配置工具主要用于底层驱动的配置与配置代码生成、BSW 配置工具主要用于基础软件协议栈的配置与配置代码生成，生成后的配置代码需要与工具供应商提供的静态代码一同进行 ECU 软件集成。RTE 代码生成工具以软件组件 ARXML 或基础软件配置ARXML 为输入，生成符合 AUTOSAR CP 标准的 RTE 代码，向软件组件提供可靠的通信和调度服务。

四、编译与调试工具。用于 ECU 软件集成时的编译与调试。由于 AUTOSAR CP 工程代码量十分庞大， 所以对编译器和调试器的要求也相对较高。

此外，目前市面上的 AUTOSAR  工具链都是桌面应用程序，这使工具链的维护和升级都不方便，并且由于应用程序在各个电脑上都是独立的，所以其资源是不可共享的，使开发效率降低。而随着 5G 和千兆网络的普及，在未来，AUTOSAR 工具链由桌面应用程序发展为 Web 应用程序成为可能。具有超大带宽、超低时延、更加稳定可靠等特征的宽带网络结合超强性能的 Web 应用程序服务器，以及 Web 应用程序本身的优势，这使得工具链供应商可以更加方便的维护及更新工具，开发者们更加高效、友好的合作开发。

2.1.2  技术发展趋势

AUTOSAR CP 发展历史悠久，从诞生到现在已经有近 20 年的历史。本章节将从当前痛点分析角度来阐述 AUTOSAR CP 存在的问题和未来发展趋势。

AUTOSAR CP 带来的优势和便利前文已经叙述了很多，但是它也不是完美的，在实际应用过程中也存在一些问题，下面将从五个方面分别阐述。

一、架构充分解耦导致标准和接口规范繁多。不可否认 AUTOSAR CP 的规范文档非常详尽，但正是两百多个多达几万页的标准文档让一些传统的嵌入式工程师望而止步。同时 AUTOSAR CP 提出了很多新概念，比如标定量通过描述文件进行描述；应用接口不通过传统全局变量的方式与底层软件交互，而是对接口进行描述定义通过 RTE 统一接口进行匹配等。AUTOSAR CP 的软件开发理念和传统嵌入式工程师的认知偏差也是其普及率不高的原因之一。

二、工具链价格昂贵国产研发之路任重而道远。动辄几百上千万的软件使用授权费对 OEM、Tier1 来说都是很大的研发投入。尽管国内已经有普华基础软件、经纬恒润、东软睿驰、中汽创智等几家供应商开始布局工具链的开发，但国产工具链的研发推广之路依然任重而道远。

三、工具链之间兼容性差影响合作开发的灵活性。在实际项目中并没有体现出 AUTOSAR CP 软件模块的复用性和独立性。由于各厂商对 AUTOSAR CP 规范的理解并不完全一致，而且各厂商的工具也并不完全兼容，导致 OEM 集成各家供应商开发的软件模块需要花费大量的精力和时间。原本希望借助 AU- TOSAR CP 标准统一的优势合作开发，但是因为工具链的兼容性问题而不得不统一工具链的使用，严重限制了合作开发的灵活性。

四、自动化程度低导致开发和集成效率偏低。基础软件与应用软件的接口集成需要大量的手动配置工作，不仅操作上低效出错率高，而且在错误检查方面也不如传统软件集成方便。对于某些错误提示往往不能快速定位错误原因，对于某些需求追加或变更往往不能快速对应。针对这一痛点，国内大部分 OEM 都已经开始使用自动化脚本工具直接操作 ARXML 来代替这种重复性的工作。

五、代码可读性差导致调试困难。这是代码生成工具普遍存在的问题，和 MATLAB 的 AUTOSAR 工具箱生成的代码一样，一些 AUTOSAR 工具链的 RTE 代码生成工具生成的代码可读性也较差，这给软件调试带来了不少麻烦。例如在调试基于  SOMEIP  的服务通信时需要根据服务请求信号、提供信号的数据流向和函数调用关系，一层一层地查询才能理解整个通信过程。

2.1.3  关键技术解读

1.  基础软件多核分配

基础软件多核分配是发挥多核系统并行计算、负载均衡、快速响应优势的关键技术。没有基础软件的多核分配，就算应用软件做了多核分配，多核系统的优势将受到核间通信效率的制约，甚至系统整体性能还不如单核。实现基础软件多核分配的主要技术手段有主卫星方式（Master/Satellites）和通信协议栈分割（Com-Stack Split）两种。

一、主卫星方式。如图 2.1-5 主卫星方式的基础软件分割所示，该方式可适用于 Dem、FiM、WdgM、Com、NvM、XCP、EcuM 等基础软件组件。当这些组件提供的服务需要被多个核使用时可以考虑主卫星方式，即卫星给其所在核的其他模块提供服务接口并将收到的服务请求通过主卫星通信传递给主星，主 星协调、过滤和接收各卫星的服务请求并进行处理，最后将处理结果通过主卫星通信反馈给卫星。由于主卫星之间的工作分配 AUTOSAR CP 并未标准化，所以用户可自定义。一种极端情况是主星具备全部功能， 卫星仅为同核其他模块提供服务接口并将服务请求转发到主星上处理；另一种极端情况是卫星和主星一 样具备全部功能并不需要主星处理服务请求，它只需要与主星保持必要信息的同步。

图 2.1-5 主卫星方式的基础软件分割

由于卫星提供的接口可以被该核的其他模块直接调用并通过高效的主卫星通信与主星交互，从而避免了低效的 Client/Server 通信，大大提高了多核系统中基础软件的服务效率。另外由于主卫星可并行处理服务请求，因此 CPU 负载可以被有效平衡、基础软件的服务速度也得到提高。

二、通信协议栈分割方式。该方式通过一个增强型的 PduR 引入FIFO 队列（无需自旋锁）或 Buffe（r  需

要配合自旋锁）这样的数据结构对跨核 PDU 进行路由，可将不同类型的总线协议栈分配到不同的核，如将 CAN 协议栈和以太网协议栈分配到不同的核。通过这样的协议栈分割可达到 CPU 负载均衡及提升多核系统实时性的目的。

2.  软件集群技术

软件集群（Software Cluster）在R20-11 版本中被首次提出，是 AUTOSAR CP 在软件架构方面的一次创新，其本质是利用二进制接口技术实现更为灵活的软件集成与更新。

图 2.1-6 软件集群技术示例

如图 2.1-6 软件集群技术示例所示，通过软件集群技术 AUTOSAR CP 软件架构被分割成了两个独立的软件集群，分别为应用软件集群（Applicative Software Cluster）和主软件集群（Host Software Cluster）两部分。其中应用软件集群可以单独编译，其搭载一组关联度较高的 SWC ；主软件集群也可以单独编译，其除了可以搭载 SWC 之外还必须搭载基础软件（包含 OS 和 MCAL）。一个控制器中可以存在多个高度解耦的应用软件集群，但是只能且必须存在一个主软件集群，分别将应用软件集群和主软件集群烧写至目标板后即可形成完整的、可执行的程序。这样的软件架构创新使得软件的开发与集成变得更加灵活，尤其是当需要更新软件功能时，无需更新全部软件，只要更新特定的软件集群即可。

如图 2.1-6 软件集群技术示例中的蓝框所示，各个软件集群就像是控制器上的一块块拼图，而这些拼图之间是通过软件集群连接块（Software Cluster Connection）拼接起来的。软件集群连接块由三部分组成，分别是二进制清单（Binary Manifest），跨软件集群通信（Cross Cluster Communication）， 代理模块（Proxy Modules）。其中最关键的是二进制清单，它在编译阶段产生且 AUTOSAR CP 规定了其标准格式，它为各个软件集群编译后文件（Binary Objects）之间提供了定义良好的接口，从而能将其连接在一起形成完整的可执行文件。图 2.1-7 软件集群的连接展示了二进制清单连接两个软件簇的例子， 其中软件集群 A 运行时需要一个资源（Require Resource，指软件集群运行时所需要的一切，或是 S/R 接口，或是 NV 块），而这个资源正好可以由软件集群 B 提供（Provide Resource）。软件集群 A/B 的二进制清单中都分别存储了这个资源的基本信息包括：资源属性（Require/Provide）、资源类型（S/R、NV 块等）、资源 ID、句柄一览表（Handle，即用于访问该资源的信息如数据指针、函数指针、数据等）等。对于软件集群 A 来说，因为在其单独编译阶段没有相应的 Provide Resource，所以其二进制清单的句柄一览表被默认值填写且是可修改的，如图 2.1-7 黄色框所示。对于软件集群 B 来说，因为其具备固定的Provide Resource，所以其二进制清单的句柄一览表在编译时已确定且是不可修改的，如下图绿色框所示。如果在烧写时进行软件集群连接，那么目标板内的软件集群连接器软件（On-board Software Cluster Connector）负责在烧写的同时，将软件集群 B 中资源的句柄拷贝至软件集群 A 中资源的句柄，从而完成两个软件集群的连接。

图 2.1-7 软件集群的连接

跨软件集群通信用于支撑 VFB 通信。而代理模块分为高代理模块（High Proxy Modules）和低代理模块（Low Proxy Modules）两部分，其中高代理模块位于应用软件集群代替原先的基础软件模块提供符合  AUTOSAR  标准的接口，低代理模块位于主软件集群负责实现真正的基础软件模块功能，二者之间通过二进制清单连接。

2.1.4  典型应用案例

本章节将分享几个基于 AUTOSAR CP 基础协议栈的典型应用案例供读者参考。

1.  SOME/IP 应用案例

在某公司 L3+ 自动驾驶项目中，整车和传感器通过 CAN 总线与自动驾驶域控制器的 MCU 进行交互， MCU 再将从 CAN 总线接收到的数据组包转发给 SOC 的各应用模块，MCU 与 SOC 之间则通过基于以太网的 SOME/IP 通信协议进行交互。

常用的  SOME/IP  以太网消息类型有：REQUEST、REQUEST_NO_RETURN、NOTIFICATION、RE-SPONSE。其中  REQUEST  为期待响应的请求，客户端有需求时才会向服务端发送请求，且客户端会等待服务端反馈的结果。例如，客户端如果需要向服务端请求 VIN 码，则可发送 REQUEST 类型的消息。RESPONSE 则为响应消息，即服务端的用于响应客户端 REQUEST 类型的报文。例如：客户端向服务端请求 VIN 码，服务端则通过 RESPONSE 类型的消息给客户端回复 VIN 码。REQUEST_NO_RETURN 为 不期待响应的请求，客户端有需求时才会向服务端发送请求，但客户端不关注结果。例如，客户端如果 需要向服务端请求打开车窗，客户端可发送 REQUEST_NO_RETURN 类型的消息。NOTIFICATION 为事 件通知，客户端先向服务端订阅消息，服务端当发现被订阅的消息发生变化时则主动通知客户端。例如， 客户端向服务端订阅车速信息，服务端如果发现车速变化则可发送 NOTIFICATION 类型的消息给客户端。

在本案例中，由于 MCU 与 SOC 的通信数据具有数据量大、通信数据类型确定、数据周期性发送等特点，因此 SOME/IP 消息采用 NOTIFICATION 类型。自动驾驶域控制器的软件架构如图 2.1-8 所示。

图 2.1-8 自动驾驶域控制器软件架构

MCU 一侧基于 AUTOSAR CP 搭建应用软件， 主要包括三个应用模块：VDC（Vehicle Data Center）将整车相关 CAN 数据做预处理，此类 CAN 数据主要指 VCU、EPS、EPB 等控制器数据；XDC（X Sensor Data Center）将各传感器的 CAN 数据做预处理，此类 CAN 数据主要指毫米波雷达、组合导航、智能摄像头等传感器数据；IDC（Internal Data Center）将预处理后的 CAN 数据转换成以太网数据并通过 SOME/IP 协议发送到 SOC 一侧。SOC 一侧基于 AUTOSAR AP 搭建，其中 SDC（Service Date Center）将以太网数据转换为 SOC 应用模块所需要的数据。在 SOME/IP 通信中，SOC 侧的 SDC 作为客户端，启动后即开始订阅 MCU 侧的所有已知服务，MCU 一侧收到订阅后即开始以固定周期向 SDC 侧发送订阅的报文，为保证实时性，SOME/IP 的数据传输周期与 CAN 报文周期一致。

SOME/IP 序列化方式采用大端一字节对齐。因为一字节对齐是最简单的对齐方式，大多编译器很容易实现；并且采用一字节对齐，序列化后没有冗余数据，报文的有效负载段都是有意义的数据，所以总体传输效率得到了一定提升。另外，SOME/IP 通信报文中的 Payload 也会添加时间戳和 Rolling Counter 等信息，SOC 一侧的应用在使用 MCU 传来的数据之前，会先把时间戳取出来，并作数据校验、对齐、分析等工作。SOME/IP 报文结构如图 2.1-9 所示。

图 2.1-9 SOME/IP报文结构

本案例中的 SOME/IP 协议均基于 UDP 协议开发，它在用户有需求的时候才发送报文，这种方法有以下几点优势：

一、传输效率高。与 CAN 等周期性的网络相比，总线上不会出现过多不必要的数据，从而减少了资源消耗，点对点的全双工传输模式也让通信效率变得更高。

二、通信速率快。对于雷达这类较大的数据，需要 MCU 能在短时间内及时地将数据传输到 SOC，使用以太网是目前各类总线通信中速率最快的，它最能满足大数据量的通信需求。

三、数据长度长。CAN-FD 报文数据长度最大 64 字节，LIN 报文数据长度最大 8 字节，单帧 Flex- ray 报文数据长度最大 254 字节，而基于 UDP 的以太网单帧报文长度可达 1500 字节，能满足大数据的通信需求。

四、实现较简单。以太网已有成熟的 TCP/IP 协议栈，基于 Linux 平台还有开源的 Vsomeip 协议栈，可直接移植使用。

2.  时间同步应用案例

在智能驾驶中，时间是一个非常重要的参数，各个系统中需要保证时间一致，其中包括车云系统之 间时间一致；域控之间时间一致；域控与各个 ECU 之间时间一致；ECU 与各个传感器之间时间一致等。车云系统为保证时间一致，常在车载 ECU 中加装 GPS 模块，ECU 通过 GPS 数据与云平台时间保持一致。车内系统（域控之间、域控与 ECU 之间、ECU 与传感器之间）为保证时间一致主要采用：PTP（Precision Time Protocol 高精度时间同步协议）、PPS（同步脉冲信号）、AUTOSAR CP 同步方案等。

如图 2.1-10 多传感器融合系统中，Camera ECU 通过高精度摄像头采集车道线、障碍物、标识等信息；Radar ECU 通过毫米波雷达进行障碍物、障碍物速度等信息的采集；Camera/Radar ECU 通过CAN-FD 将处理的数据交给 ADCU 进行数据融合，ADCU 中自带 GNSS 芯片保证与云端时间一致。由于该系统对数据实时性、真实性要求比较高，所以需要保证 Camera/Radar ECU 采集的数据时间一致。为了达到该目的，如图 2.1-11 时间同步步骤所示，本案例采用了 AUTOSAR CP 时间同步解决方案，即ADCU 作为 Time Master 实体，Camera/Radar ECU 作为 Time Slave 实体，由 ADCU 对 Camera/Ra- dar ECU 进行时间同步。

图 2.1-10 多传感器融合系统

图 2.1-11 时间同步步骤

时间同步的步骤与方法如下：

一、ADCU 以 1s 为周期发送同步帧，即图中 t1 时刻发送 t0 时刻的时间戳。

二、Camera/Radar ECU 在 t2 时刻收到同步帧后，记录 t2 时刻的时间戳。

三、ADCU 间隔固定时间（100ms）后发送跟随帧，发送内容即Δt0 时间。

四、Camera/Radar ECU 在t3 时刻接收到跟随帧后，进行绝对时间计算并将绝对时间更新到 ECU 中， 公式为：t3 = t0 +Δt0 + t3–t2。

注：本章有关AUTOSAR 的内容是AUTOSEMO 会员单位的经验解读，仅供行业参考。

2.2  AUTOSAR AP

2.2.1  技术形态

新四化（电动化，网联化，智能化，共享化）的变革驱使汽车软件系统变得更加灵活。汽车软件既要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及与非车载系统之间的交互。

今天的汽车 E/E 架构可划分为信息娱乐、底盘和车身控制等不同域，信息娱乐系统通常使用 Linux 或商业化的通用操作系统，车身控制则使用标准的 AUTOSAR CP。随着未来新技术及深度嵌入式系统对计算能力需求的不断增长，急需第三种控制器—— 域控制器，用于集成特定领域的功能特性（如车辆动力域、车身域等 )，形成域集中或跨域集中式电子电气架构。

在未来，随着汽车电子及软件功能的大幅增长，E/E 架构最终可能向基于中央计算平台的整车集中式电子电气架构，以及车云协同控制发展。在这种趋势下，需要高度灵活、高性能且支持 HPC、动态通信等特性的新软件架构平台—— Adaptive Platform AUTOSAR 平台（下文简称 AUTOSAR AP）。

1.  软件分层架构

典型的域控软件架构如图 2.2-1 所示，整体可被分为四层，即操作系统层、基础平台层、原子服务层、应用组合服务层。

AUTOSAR AP 在基础平台层，这一层包含了 AUTOSAR AP、AUTOSAR CP、专用基础功能等，主要为整车提供基础运行环境。

原子服务层是实现数据融合和控制逻辑的功能模块，作为服务的最小单位与单一执行实体，通过   API 为应用提供可按需编排的基础服务，实现一次开发多次复用，最大化提升开发效率。该层的设计目标是原子服务与平台解耦，提升软件复用性。

应用层基于原子服务实现对整车服务、应用、体验等进行定义和组合增强，构建差异化竞争力的业务应用，体现千车千面。

图 2.2-1 域控软件架构图

图2.2-2 AUTOSAR AP在软件架构中的位置

AUTOSAR AP 在域控软件架构中位于中间件的位置，通过服务和API 为上层服务提供功能，如图2.2-2 所示。

在 Non-AUTOSAR 环境中，系统已经实现了部分 AUTOSAR AP 标准组件，只需要实现剩余部分组件即可满足 AUTOSAR AP 的标准。比如在 Android Automotive OS 中，软件框架提供了进程管理、执行管理、Log、加密、生命周期管理等功能，基础软件供应商实现通信管理、诊断、升级、网络管理等功能， 即可满足 AUTOSAR AP 的标准。

2.  工具链

基于自适应平台的应用程序开发一般要经历三个阶段，分别是设计建模阶段、软件开发阶段、集成部署阶段，为了更好地支撑这三个阶段的活动，AP 工具链具备以下能力：

·  设计建模阶段使用建模工具，用于生成 ARXML，完成 Adaptive Application、Service Instance、Executable、Machine 等设计开发，配置 SWC（Software Component）相关配置项，完成 SWC 端口及框架设计 , 最终导出 AP 平台的 ARXML 文件。产品工具应具备支持导入导出、解析、编辑ARXML 文件的能力。

·  软件开发阶段：使用 AP 产品生成工具，用于实现组件 API 代码及 Manifest 配置文件的生成。输入是标准的 ARXML 文件，生成源代码和 Manifest 配置文件，另外需要包含应用层的代码编辑器和代码库管理，实现源码编辑，编译链文件编写，代码库同步等功能。

·  集成部署阶段：使用集成编译调试以及部署工具，包含编译工具、可视化调试工具、部署工具、资源监控等工具，支持编译、调试、部署等功能。

3.  开发方法论

为了支持 AP 平台下应用程序独立、敏捷、分布式的开发，需要在开发方法论上有一套标准化的方法。AUTOSAR AP 开发方法论涉及工作产品的标准化，用于描述工作产品（如服务、应用程序、机器及其配置）、工作产品应如何交互、以实现自适应平台产品开发过程中不同角色之间所需的信息交换。

图 2.2-3 简要展示了 AP 平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的软件集成入车辆中。

(1) 架构设计阶段

① 服务接口设计（Define Services）：主要是定义服务接口及数据类型，包括定义服务所包含的method、event、field、trigger 等通信元素以及数据类型详细说明等；

② 机器配置设计（Configure Machine）：定义和配置机器的网络通信属性，包含网络连接配置，服务发现配置等信息；

(2) 软件开发阶段

③ 定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集；

④ 定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射；

⑤ 服务实例接口框架源码生成；软件集群源码开发及测试等；

(3) 集成与部署阶段

⑥ 软件集群集成 (Integrate Software) ：配置可执行实例和进程的映射、定义和配置应用程序配置清单、定义和配置服务实例部署信息；

⑦ ECU 集成 (ECU(Machine) Integrate)，定义应用程序执行清单 (Execution Manifest)、定义平台程序的配置清单、诊断和进程之间的映射配置；

图2.2-3 AUTOSAR AP开发方法论

2.2.2  技术发展趋势

1.  架构发展趋势

(1) Adaptive AUTOSAR 的历史

Adaptive AUTOSAR 于 2017 年应运而生，主要为了提供高算力、高网络带宽下的基础软件开发平台标准。目前最新版本为 R21-11。

(2) Adaptive AUTOSAR 的发展趋势

① 技术趋势

在汽车行业， 智能网联、自动驾驶、V2X、OTA 等功能逐渐成为标配，Adaptive AUTOSAR 面向POSIX    标准的操作系统，可以更好支持这些功能。在最新的标准中为了更好的支持开发，在可用性及稳定性上做了如下提升：

a. 可用性：提升模块特性的合理性及便利性。支持更多的 SOA 通讯协议、通信失效模式的检测、灵活支持日志内容定义等。同时，针对域控制器的异构平台，新版本在 AP 与 CP 的共用特性及方法论上进行统一，定义了自动驾驶的传感器接口、整车级健康管理的架构与接口、针对整车 OTA 升级的流程等域控制器架构的使用功能等。

b. 稳定性：增加针对系统稳定的特性。如在 EM 细节中增加了配置进程错误码、功能组增加 unde- fined 状态、增加对进程意外终止的处理，PHM 中增加确定性执行的监控，UCM 中增加容错机制等。

同时在这些功能场景下，信息安全与功能安全成为不可或缺的关键机制。Adaptive AUTOSAR 针对这两项安全需求，定义了完善的特性：

a. 面向功能安全：新增了系统健康监控，主要用于系统协调健康状况 / 错误。主要包含以下内容：

SHM Client 交流平台健康状况；

SHM Master 确定健康指标；

根据健康指标进行的机器恢复（例如降级）；

增加了确定性同步的内容，描述了同步行为和周期性激活的要求，包括时间同步和数据同步。

b. 面向信息安全：增加了入侵检测系统管理，由标准化的接口来报告安全事件。通过标准化的过滤机制来传输合格的安全事件。

增加了 Crypto API 的描述；

软件和硬件解耦；

支持分离式非耦合开发；

应用程序独立于加密解决方案。

② 基础软件技术路线

随着各种域控制器方案陆续问世，各细分赛道由分散到集中，由独立到整合。目前整车域控制器， 例如智驾域控，中央域控，智能座舱域控等均需得到高性能 MPU 芯片的支撑，因此 POSIX 标准系统的搭载显得尤为必要。基于 POSIX 系统之上的 AUTOSAR Adaptive 平台及相关工具链，为应用开发过程中的效率带来显著提高，而座舱域控一般在 Linux 基础之上搭载安卓系统，在程序启动、状态切换、存储等方面有自己独立的生态，而诸如 SOA 通信、整车诊断、健康管理的方面需要参考 AUTOSAR AP 平台标准给予补齐和增强，工具链未来需要从整车视角实施统一化配置。

③ 新的分工趋势

受域控制器行业的蓬勃发展以及各项政策利好，越来越多的参与者以各种新的身份加入进来，整体 的行业角色将不再是 E/E 时代的 OEM、Tier1 及 Tier2 三种。随着产业链结构的变化，位于下游负责整车生产和组装的主机厂（即行业所说的 OEM），将不再通过系统与设备集成来获取价值增量，而会转向基于用户需求和自身产品定位，建立有效的梳理筛选机制，向上游 Tier1 及 Tier2 提出更多定制化的需求。

2.  工具链发展方向

工具链（tool chain）是在一套流程里面用到的所有工具和相关库组成的集合，上一个工具的输出或环境状态成为下一个工具的输入或启动环境。因此，工具链的效率决定了整个系统的开发效率。所以随着行业的发展成熟，工具链的发展将由现在分散的多工具相互切换配合形态，逐步升级到成熟开放的中间服务体系，来匹配整个产业的发展态势，在平衡各自的专业分工的前提下避免产生信息数据孤岛。

现行的工具链标准基本是在 AUTOSAR AP 规范所约定的框架内按照给定的方法论实现功能，各家比拼的是对 AP 服务模块的实现及理解。在第一阶段的服务实施提供后，要比拼的就是在整个产业上下游的环节中的规范度、可移植性及整体的效率提升。

从集成角度，基于 AP 的开发工具链一般是基于 Linux 系统进行开发、编译和调试，在用户桌面端往往出现多种开发工具同时使用的问题，因此亟需一套集成开发环境来简化用户桌面，为基于 AP 的应用开发提供便捷性。

2.2.3  关键技术解读

1.  面向服务的架构（SOA）

当前整车电子电气架构，功能不集中，分散到不同 ECU，使得功能和信号交互异常复杂，代码和逻辑冗余相当严重，而互联网开发思想不断涌入汽车行业，汽车电子电气开发也必须尽快适应变革。

面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务 之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种这类系统中的服务可以以一种统一和通用的方式进行交互。通过 引入 SOA 架构，不但可以使应用软件与硬件及应用软件与应用软件之间松耦合，还可以使车端软件、通信、信息安全能和云端环境产生很好的协同，实现一整套车云生态环境，因此车端采用基于服务的通信 SOA 是有效的落地方案。

2.  软硬分离

传统汽车控制器的开发模式是等硬件确定后，再进行软件的设计、开发、测试，软件的开发依赖于硬件，无法先行或同步开发，导致软硬件两个团队人员只能顺序完成工作，浪费时间。并且一旦硬件发生改变， 软件则需要大量的修改适配，重复工作量巨大。在新型整车集中式 E/E 架构下，功能服务化，接口统一化， 增加了中间件层，软硬分离成为可能。

3.  虚拟化

当前高算力芯片层出不穷，通过虚拟化技术，将芯片上所跑的各类业务分类进行隔离已经是目前很多车企的选择。同时，在软硬分离的背景下，在 x86 架构 PC 机上或云端通过虚拟化技术运行虚拟控制器进行服务设计的验证也是目前的主流软件先行方案。

2.2.4  典型应用案例

1.  基于 AP 的基础软件产品和解析

(1) 日志与调试

日志作为行为或状态详细描述的载体，提供可用于分析系统的活动和诊断问题的跟踪记录。在安全事件分析、事件回溯和取证过程中起着相当重要的作用。

在 AP AUTOSAR 中，Log and Trace 模块负责管理和记录 AP 平台的日志，既可以应用于开发过程， 也可以适用于量产过程。在架构上，Log and Trace 模块会与 AP 的时间同步及通信管理等模块交互。基于 AP AUTOSAR 标准定义的 LT 协议，Log and Trace 模块可以让 AP 应用程序将信息记录到通信总线、控制台或文件系统上。同时 DLT 协议也提供了包括日志等级、日志 ID 等字段内容，日志客户端可以使用此信息来关联、排序或过滤接收到的日志帧，便于日志的解析查看以及日志相关功能的扩展。

平台典型的日志系统架构图如图 2.2-4 所示：

图2.2-4 Log And Trace案例

其中，App 通过使用 DLT 接口将相应的操作步骤、状态监控、故障信息等内容发送至 Daemon；

Daemon 表示 DLT 守护进程，它接收并处理来自 AP 应用程序的日志信息，并根据配置对日志进行终端显示、文件存储、网络传输等操作；

Dlt-Viewer 表示通过网络传输接收 Daemon 日志信息的客户端，对日志信息进行 UI 展示，方便用户进行日志的查看和分析。

日志记录分析

上文介绍了从日志产生到日志数据流转的整个过程，基于已有的日志信息，Dlt-Viewer 可以提取出我们所关注的数据，如图 2.2-5 所示。

Dlt-Viewer 提供相当多 DLT 日志处理功能，除了日志显示、日志导入 / 导出等功能外，还提供了强大的日志过滤、标记等功能。过滤器可以是某一字段，甚至是正则表达式。它提供了插件的开发接口，极大地提升了功能扩展的能力。

图2.2-5 日志记录分析

(3) 系统启动监控

通过解析各功能模块产生的 DLT 日志，可以分析出整个系统上电启动过程，用户可以直观地观测各功能模块的启动过程，并根据观测结果调整各功能的启动策略，达到功能模块稳定、快速启动的目的。

2.  基于 AP 的应用场景介绍

本节主要介绍基于 AP 的智能域控制器（后续简称 IDC）OTA 升级场景及其实现方案。IDC 的 OTA 功能可以进行自身应用软件及系统软件、关联器件固件的升级，并在数据管理、软件升级、可追溯性、安全验证方面满足 AP 的相关要求。

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

图2.2-6 IDC与外界数据交互图

(1) 数据传输与管理

① IDC 内部分为 OTA 进程和 UDS Server 进程，UDS Server 进程与 HUT 端交互，负责处理、转发指令和接收软件包，OTA 进程处理软件包进行升级。

② OTA 使用专用的磁盘分区保证有足够的资源来存储软件包及相关数据，从而保证数据的安全性。

③ IDC 会进行完整性校验以保证软件包的完整性。

④ OTA 结束后，IDC 会删除临时数据，最大限度节省空间。

(2) 软件升级

① OTA 采用双分区机制，通过活跃分区去升级备份分区，升级成功后重启备份分区，完成备份分区和活跃分区的互相切换，轻松实现 IDC 上的应用软件、中间件、操作系统、配置数据的安装、更新、删除。

② OTA 采用双分区机制，通过切换启动分区，可以实现 IDC 上所有软件及数据的快速回滚功能。

③ OTA 支持周边器件的升级，如 MCU、相机等。

④ OTA 内部维护状态机，状态变化实时落盘，可以支持在异常中断后恢复升级。

(3) 可追溯性

① OTA 提供获取当前软件版本号、安装进度、安装结果的接口。

② OTA 会记录升级过程中的日志，供 HUT 获取。

(4) 安全性

① OTA 在软件升级前会使用强加密算法校验证书链与软件包签名，保证软件包的真实性及完整性。

② OTA 在软件升级前会检查当前车速、IDC 的温度、供电情况，保证在安全的情况下进行 IDC 软件升级。

③ OTA 时会激活 IDC 心跳监控机制及分区损坏回滚机制，当切换到备份分区启动失败后，IDC 不会给 MCU 发送心跳报文，MCU 会认为 IDC 在 OTA 后变砖，会给 IDC 断电重启，切回原分区启动，保证车机可用。

注：本章有关AUTOSAR 的内容是AUTOSEMO 会员单位的经验解读，仅供行业参考。

2.3  操作系统内核

2.3.1  操作系统内核技术架构

1.  简要架构

在车辆动力电子，底盘电子和车身电子等实时控制功能实现当中，经常会使用到一些功能相对简单的微控制单元（MCU）芯片（如单片机），这类芯片资源配置较低，硬件上没有为操作系统内核提供复杂的内存管理和特权级别的隔离功能，因此会采用一种简要的操作系统内核结构设计。在简要结构设计当中，内核服务与应用程序会被放置在同一地址空间，应用程序无需切换地址空间和权限层级就能够直接调用内核服务，具有高效的优势，有利于实时业务的实现。但相对于后面提到的宏内核和微内核架构设计，简要架构系统缺乏内核隔离保护能力，任何一个模块（无论是应用还是内核服务）出现问题都可能导致系统崩溃。

出于硬件成本和实时性的综合考虑，汽车领域中许多基于 AUTOSAR CP 的安全车控嵌入式实时系统都采用了简要架构设计。其他领域类似的简要架构系统还有 uC/OS II，FreeRTOS。

2.  宏内核架构

宏内核（Monolithic Kernel）架构在计算机和通信领域是应用最为广泛的一类操作系统架构，其相关产品的生态也最为完善，目前常见的桌面系统（如 Windows，MacOS，Linux 桌面发行版），服务器系统（如 Unix，Linux）和主流手机操作系统（Android，iOS）均是基于宏内核架构。宏内核架构操作系统在智能驾驶和智能座舱领域也有大量应用。宏内核的特点是将所有传统的操作系统服务（例如进程调度，内存 管理，文件系统和设备驱动）全部运行在内核态，能够直接操控硬件，系统服务间的内部调用效率相对较高。在硬件能力的支撑下，宏内核可以实现用户程序和内核的安全隔离保护，采用合适的进程调度机制（优 先级抢占式）时也能够满足车用领域的硬实时性任务要求，并能支持虚拟化等新技术来满足汽车 E/E 架构向集中式架构演进的需求。

但是应该看到，由于面向通用业务而设计，随着宏内核功能的丰富，其代码量也会变得越来越庞大， 以 Linux 内核为例，2021 年底其内核已经达到了 3220 万代码行的规模，且可能会持续增长，在车用领域这不仅意味着软件复杂度和硬件成本的增加，也意味着更高的信息安全和功能安全挑战。目前，业界还未看到基于宏内核的操作系统产品通过功能安全 ASIL-B 以上的安全认证。

为了应对这些问题，宏内核架构的操作系统也采用了模块化，抽象，分层，层级等方法来控制其不断增长的复杂度。

模块化：内核通过模块化的策略来组织功能，提供可加载内核模块（LKM）机制。例如将大部分设备驱动与内核其他功能解耦。

抽象：对内核服务进行抽象以提高可维护性、降低复杂度。例如 Linux 将所有的数据，设备和内核都抽象成文件，对应用层提供统一接口。

分层：将逻辑上或功能上相近的模块分层，以便更好地组织功能。例如 Linux 文件系统的分层结构。

层级：对于内核的资源管理引入层级的概念，如进程调度优先级的分类等。

3.  微内核架构

从功能服务的角度看，微内核（Microkernel）操作系统和宏内核系统并无本质差异，只是采用了不同的内核架构设计思路。由于宏内核架构系统将所有的服务都运行在内核态，任何一个模块出现错误或者被攻击就有可能引发内核的崩溃，从而影响到整个系统的稳定性。而且随着内核代码量越来越大，这种概率还会提高。为了保证内核的稳定性，微内核架构主张将宏内核的功能进行解耦，将某些功能从内核中剥离出来作为独立服务，并挪到用户态去运行（比如文件系统、设备驱动）。内核为这些剥离到用户态的服务提供各种通信机制，以保证这些服务能够相互协作，这样即使单个服务出错或者被攻破也不会导致内核崩溃或者出现系统安全问题。

微内核的最小内核设计原则主张保留尽量少的功能在内核态运行（如进程调度、内存管理、进程间通信等）。微内核架构设计同时还主张机制与策略分离的原则，尽量将策略配置管理功能剥离到用户态，将实现机制保留在内核态运行，这样可以根据应用场景适配不同的内核服务实现机制。微内核的这两个设 计理念不仅提高了安全性，而且由于内核功能相对简单，其内核服务的时延相对比较容易控制和估算， 也有利用于硬实时系统的调度实现。

不过由于第一代微内核系统代表 Mach 采用了一种过于通用的进程间通信 IPC（Inter-Process Communication）设计方案，加上自身资源（内存、CPU 缓存）占用过大等问题，导致其性能受到很大影响， 与同期的宏内核系统相比有明显差距。但后续有文献分析表明，“高性能的 IPC 的设计与实现必然是与体系结构相关的，过度抽象将极大影响 IPC 的性能，而利用体系结构相关的状态进行优化则可将 IPC 性能提升到极致” 。经过改进和优化，第二代微内核系统代表 SeL4 在采用了最小化设计原则的情况下，也达到了与同时期宏内核系统同样的效率水平。此外，SeL4 系统还通过了形式化验证。

目前微内核架构系统在汽车、工业等高实时、高可靠和高安全领域得到了广泛应用，并有商用化产品（如 QNX）通过了汽车行业的 ASIL-D 功能安全认证。

2.3.2  技术发展趋势

前面已经提到，影响 OS 内核架构技术发展和应用的因素主要还是来自硬件约束、安全性（含功能安全和信息安全）、可靠性、运行效率这些非功能性需求，而非具体的功能性需求。

从整车电子电气架构的技术发展看，由博世公司提出的分阶段、分步骤从分布式向集中式发展的趋势及相应框架已经得到业界广泛认可。当前汽车 E/E 架构正逐步迈入跨域集中式阶段。新阶段 E/E 架构的显著特点是 “域融合、区集中” ，即车端功能逐步向几个主要功能域融合，传感器执行器等逐步通过区域控制器做区域集中化接入。未来，随着 E/E 架构向 HPC 中央计算平台的进一步演进，智能功能会越来越集中到一个或几个有限的但是更加强力的计算单元上，智能驾驶、座舱、车身功能域将明显出现计算平台融合的趋势，因此基于宏内核和微内核架构的复杂系统应用会越来越广泛。当然，受限于实际需求、时延和可靠性要求以及其他非技术原因，一些基于 MCU 的简要结构系统也还会持续存在相当长的时间。

从功能安全的角度看，不同功能域对于操作系统内核的要求也不相同。例如在功能相对简单的安全 车控领域，由于功能安全等级要求较高，仍然在大量使用基于 MCU 的高实时性高确定性的简要架构操作系统（如 OSEK/VDX OS），这些系统通常和 AUTOSAR CP 平台绑定在一起。因为 MCU 硬件能力的限制，简要架构内核系统技术本身发展空间非常有限。考虑到基于微内核的 RTOS 实时系统已经有支持 ASIL-D功能安全等级的产品出现，未来必然会在安全车控领域起到越来越重要的作用。

在智能座舱领域，除了自身要实现复杂的人机交互和多媒体娱乐等服务外，还需要支持和外部功能域之间的大量交互（如车云一体服务需求），但大部分业务属于软实时业务，且对功能安全等级要求相比安全车控和智能驾驶应用要低。从技术能力上看，宏内核系统和微内核系统都可以胜任此类应用。业界的选择主要还是看相应产品的应用服务框架支持能力和生态环境的成熟度。在中控和仪表分离的智能座舱解决方案当中，功能安全等级要求较高的虚拟仪表主要选择 QNX 系统，而中控娱乐系统则选择 Android 较多。在虚拟仪表和中控一体化的解决方案当中，QNX 系统占多数，也有少数方案选择了 Linux 宏内核。

在智能驾驶领域，能够满足高功能安全（ASIL-D）和高性能要求的微内核实时操作系统将被广泛应用。与此同时，为满足机器学习和视觉 AI 算法的操作系统层接口要求，基于宏内核的安全操作系统（如安全 Linux）也可能被引入，比如和 RTOS 一起构筑软件功能安全岛，在支撑 AI 算法丰富接口要求的同时， 满足智能驾驶要求的功能安全等级。此外，宏内核系统也在一直不断进行内核的裁剪优化，对安全关键 功能采用 ISO 26262 形式化或半形式化方法完成正向设计和验证，以满足高功能安全等级和高可靠性的智能驾驶场景要求，不排除在未来也能够独立支撑智能驾驶域的应用。

在简要架构操作系统产品领域，有国外大量的 OSEK/VDX OS 系统可供选择，国内部分厂家开发的操作系统也逐渐成熟。此外还有FreeOSEK 和OpenOSEK 等开源的OSEK/VDX 操作系统供开发者使用。

在汽车上应用的微内核操作系统产品领域，国外有黑莓 QNX、风河 VxWorks 等系统已经实现了商业化落地，国内也有不少基础软件供应商在大力投入车用领域操作系统的开发，具备相当的竞争力。在开源软件领域，有 seL4 系统通过了形式化验证，只是商业落地较少。

在汽车上应用的宏内核系统产品领域，基于 Linux 内核的 Android 系统凭借在手机和 IT 智能终端市场上建立的强大生态占据了主导地位，但是国内部分头部厂商都在积极发展自己的系统生态。与此同时， 不少国内厂家还积极参加了 Linux 基金会的 ELISA 项目，旨在构建和认证基于 Linux 的安全关键应用程序和系统。

2.3.3  关键技术解读

1.  高效 IPC 技术

无论是安全车控、智能驾驶还是智能座舱应用，都必然存在着多个任务并发执行的情况。每一个任务都可能对应着一个或多个进程，用户应用进程之间由于可靠性和信息安全的需要采用了各种严格的时空隔离手段（技术原理参见 2.3.3.2 节）进行隔离，不能直接进行通信。但是用户进程间的协作又必须要进行信息交互，因此只能依赖于操作系统内核提供的进程间通信机制来完成，业界称为 IPC 技术。IPC 机制在实现进程间的数据传递功能的同时，还需要内核通过对进程的运行状态和运行时间的控制来实现控制流从发送者进程到接收者进程的切换（返回的过程类似），从而直接影响系统运行效率。

目前宏内核架构和微内核架构的操作系统都能够提供一些常见的 IPC 通信机制，包括管道、消息队列、信号量、共享内存、套接字 Socket 等。具体应用场景和特点如下表 2.3-1 所示：

表 2.3-1 常用IPC技术对照表

出于最小内核服务设计的考虑，在微内核架构系统中，类似于驱动，文件系统等传统的内核服务被 移到了用户态，许多原本可以通过简单系统调用就可实现的内核功能也必须使用 IPC 机制来提供服务， 在系统负荷较高的情况下可能会面临着比宏内核更加严重的效率问题。因此对微内核系统的研究一般都 会将改进 IPC 效率作为优化系统性能的重要选择之一。

传统的微内核 IPC 机制设计是通过端口（port）和消息（message）来实现进程间接通信。通信的双方不需要显式指定另一方，而是通过端口进行通信，这样可以将用户进程本身和 IPC 通信隔离开，只要一个进程在内核拥有某个端口，就能通过这个端口和另一端的进程通信。进程之间通过端口流通的数据就是消息。

在微内核 IPC 通信机制优化方案当中，还有一些比较极端的手段，如迁移线程技术（thread migra- tion）。如果把其他 IPC 通信机制看作将需要处理的数据发送到其他进程（或线程）进行处理的话，那么迁移线程技术就是把其他进程的代码拉进当前进程中运行，这样就会大量减少内核进程切换的代价，同时 也能通过共享参数栈和寄存器来简化数据传输，减少序列化开销，优化并发，避免共享的全局数据结构。在一些学术文献中，迁移线程模型被用在了 LRPC（轻量级远程过程调用）技术当中。

图2.3-1 主流IPC的控制流转移

图 2.3-2 迁移线程IPC

上面两张图 ( 图 2.3-1 和图 2.3-2) 是主流 IPC 和迁移线程 IPC 设计的对比。“要做到 '将代码拉到本地’ ，迁移线程首先需要对线程结构进行解耦，明确线程中哪些部分是对通信请求处理起关键作用的。然后，这部分允许被调用者（负责处理请求的逻辑）运行在调用者的上下文中，将跨进程调用变成更接 近函数调用的形式。” ，由于篇幅原因，迁移线程模型的实现就不做详细介绍了，具体细节可参考相关文献。

在行业中，即使是一些成熟的系统也会针对特定应用场景提供改进的 IPC 机制，比如 Android 系统（宏内核）就使用了 Binder IPC 机制来改进进程通信效率。Binder IPC 机制中发起通信请求的用户态进程被称为客户端，执行某种服务的用户态进程都被称为服务端。Binder IPC 还引入了 Context Manager 进程来负责建立通信连接。当服务端在向内核及 Context Manager 注册时，内核 Binder 驱动及服务端进程会在内核中维护一个对应的 “线程池” 。线程池中的每个线程都可以代表服务端处理客户端的请求并返回结果。客户端首先从内核和 Context Manager 处获取服务端信息，然后通过内核对服务端发起通信请求， 内核会从对应的服务端线程池里找到空闲的线程来响应处理（通过内存映射方式仅用一次拷贝完成数据 传递，比共享内存两次数据拷贝要快）。每个服务端在内核中对应的线程池大小可以通过消息来动态改变， 内核 Binder 驱动也允许用户为服务端配置一个最大上限线程数，这样动态分配结合最大上限配置能够防止资源浪费和潜在的安全攻击。需要特别强调的是，用户态的客户端，服务端和 Context Manager 进程间的交互（下图2.3-3 虚线部分）都不能直接交换信息，而是通过运行在内核的Binder 驱动来间接完成（下图 2.3-3 实线部分）。

图2.3-3 Binder IPC机制框架

在车用环境中，无论是基于宏内核还是基于微内核架构搭建的操作系统，使用什么样的 IPC 通信机制并不是固定的，需要根据不同的应用和需求目标进行灵活选择，必要时甚至会要求内核改进 IPC 通信机制。

2.  时空隔离技术

众所周知，在汽车智能驾驶、智能座舱或者是安全车控应用当中，都存在不同功能安全等级、不同重要程度的任务同时在一个计算单元中运行的情况。如果不采用一定的隔离措施，就会出现低功能安全等级或者非关键任务进程有意无意地干扰高功能安全要求或者重要任务进程的运行的情况（因自身缺陷或者信息安全等原因）。

当前有多种不同层次的时空隔离技术手段来实现任务的隔离。

第一个层次是处理器级别的物理空间隔离 ( 图 2.3-4)，例如可以将 A 和 B 两个应用分别独立运行在同一计算单元的不同处理器中，每个处理器都是一个独立的运行系统。即使 A 应用所在处理器发生系统崩溃（无论是否由 A 应用触发），也不会影响 B 应用的运行，反之亦然。

图2.3-4 处理器级的物理空间隔离示意图

第二个层次是虚拟机 / 容器级别的时空隔离 ( 图 2.3-5)，例如可以在同一个计算单元（可能有 1 到多个处理器）上虚拟出多个资源独立的虚拟机空间，每个虚拟机 / 容器分配有独立的物理地址空间和处理器资源。将 A 和 B 两个应用分别运行在不同的虚拟机 / 容器空间中，即使 A 所在虚拟机空间发生了系统崩溃（无论是否由 A 应用触发），也不会影响到 B 应用所在的虚拟机空间的运行，反之亦然。

图 2.3-5 虚拟机级的时空隔离示意图

第三个层次是内核和应用间的隔离 ( 图 2.3-6)。因为所有应用都不可避免地要调用内核服务，一旦内核出现问题，很容易导致系统故障，从而影响到所有运行在该内核之上的应用，所以需要将内核空间与用户空间隔离开来。用户应用程序只能运行在被内核映射分配好的地址空间，并限制用户态进程访问内核地址空间，系统同时会禁止用户进程执行某些可能破坏内核服务的机器指令，运行这些指令只能通过调用系统内核服务、中断等方式来完成。这一层次的隔离通常也需要硬件内存管理单元（如 MMU）提供的存储保护机制和相应的特权指令支持。

图2.3-6 内核和应用的空间隔离

第四个层次是应用间的分区时空隔离机制 ( 图 2.3-7)。分区是对一个相对独立的空间、时间、设备资源的抽象，形成一个尽可能与真实独立计算机资源相接近的实体。分区被抽象为一个运行单位，具有状态、优先级、调度策略、运行上下文、运行时间等属性。分区时空隔离机制需要操作系统内核的配合，由操作系统内核对分区资源（CPU 时间、内存、IO 端口）实现配额管理，分区对核心资源的访问需通过内核的授权与验证。分区通信必须通过操作系统内核验证进行才能数据交换。

图 2.3-7用户分区隔离

分区间的空间隔离技术通常采用硬件 MMU 提供的存储保护机制，除了将操作系统内核和应用分区进行隔离外，还需在负责时空隔离的操作系统内核和分区内进行实时调度（见 2.3.3.3 章节）。在分区隔离机制中，操作系统内核实施管理和安全验证所有核心资源的配额和访问，以保证系统的可靠性。操作系 统内核为每个分区配置独立的 CPU 时间和内存空间，并在分区内提供分区操作系统服务，实现分区内资源管理、任务通信、任务调度及分区间通信。操作系统内核管理外部中断，并通过信号的机制向相应的分区发送虚拟中断，相应的分区操作系统在分配到的时间片中截获信号，完成中断处理，保证分区时间窗 口的确定性，防止中断处理过长导致分区调度时钟窗口的不确定性。操作系统内核的空间域可以定义出 一个空间保护模型，每个空间域（分区）有自己的内存地址空间，每个空间域类似于传统的操作系统的 进程，空间域内的任务类似于传统的操作系统的线程。分区内调度的是任务，应用层和分区操作系统服 务层也是隔离的，任务失败不会导致系统故障。对不同分区空间可提供不同的保护权限，保护权限有：读、写、执行、共享等。一个分区内的任务失败不会影响操作系统内核或其他分区正常运行。

第五个层次是应用任务进程或线程之间的时空隔离 ( 图 2.3-8)。即操作系统内核 / 或者分区操作系统负责为每个任务进程分配独立的地址空间和处理器服务时隙，并禁止进程之间的直接访问。进程之间的信息交换必须通过调用内核提供的 IPC（见 2.3.3.1 章节）进程通信服务来完成。这一层次的隔离可以借助硬件的特权指令和基于硬件的 MMU 机制来实现，不得已的情况下也可以通过软件来完成。

图 2.3-8 应用进程/线程间的隔离

对一些功能简单的低端 MCU，由于没有内存管理单元 MMU（Memory Management Unit）支撑， 硬件上无法直接提供地址空间的隔离机制，需要通过软件技术来实现隔离保护。基于软件的隔离保护技 术包括段保护、段匹配和地址沙箱技术。其具体的实现原理和特点见下表 2.3-2。但无论是哪种基于软件的隔离技术，对系统的实时性都会有影响。

表 2.3-2 基于软件的隔离技术

对于支持 MMU 页表技术的处理器，其硬件能够很好地支持虚拟地址到物理地址的映射翻译，并提供基于硬件的存储器访问授权，从而实现不同进程任务的空间隔离。MMU 的映射翻译机制主要有两种，一种是分段机制，一种是分页机制。分段机制只是在早期的 X86 架构处理器上引入（在 X86-64 架构之后转向了分页机制），现代操作系统目前广泛使用的（无论是 X86 还是 ARM 架构）都是分页机制，后来还引入了多级页表机制。虚拟地址的哪个页面映射到物理内存的哪个页帧是通过页表（Page Table）来描述的，页表保存在物理内存中，MMU 会通过查找页表来确定一个虚拟地址应该映射到什么物理地址。MMU 配合操作系统内核完成了诸多空间隔离功能，比如通过特权模式划分了内核空间和用户空间，

用户空间无法直接访问内核空间，必须通过某些手段（系统调用，异常，中断等）切换到特权模式才能间接访问内核。此外，每个进程都拥有自己独立的地址空间，进程切换时地址空间也会切换。不同进程都拥有自己的一套页表，因而即使两个进程虚拟地址相同，映射的物理地址也是不同的。切换地址空间相当于控制 MMU 访问不同进程拥有的页表，MMU 找到了页表就找到了物理地址。

此外，操作系统内核还可以对每个页表的访问权限进行设置，当进程要访问不可访问权限的内存地址时，会产生一个异常通知处理器，操作系统内核可以通过捕获这种异常和对这种异常的合理处理来实现对空间域的保护隔离。

随着计算单元硬件和虚拟化技术不断地进步，配合操作系统内核所能提供的软件隔离保护手段，基本上能够满足未来整车 E/E 架构智能集中化趋势下的时空隔离要求。具体使用哪种隔离机制或者几种隔离机制的组合，需要根据整车应用功能安全要求，硬件成本约束来灵活决定。

3.  实时任务调度技术

在汽车应用领域，不可避免地要应对两类实时任务。一类被称为硬实时任务，这类任务无论在什么样的情况下都必须在规定的截止时间内执行完毕，否则会造成不可接受的后果（如因碰撞传感器引发的安全气囊弹出）；另一类为软实时任务，这类任务也规定了严格的截止时间，但是偶尔超过了时间门限也不会引发严重的后果，如触摸屏交互，即使反应时间超限导致应用体验不好，也不会酿成安全事故。

实时任务又可分为周期性任务，偶发任务（通常是硬实时）和非周期任务（通常是软实时）。

无论是哪种车用操作系统，都面临着多个软硬实时任务（进程 / 线程）同时争夺有限资源的问题， 需要操作系统内核提供合适的调度机制来满足硬实时任务截止时间要求，在此基础上，还需要满足其他 系统和应用指标（周转时间，资源占用效率）。操作系统内核的任务调度机制通常可分为两大类 - 抢占式和非抢占式。

非抢占调度方式是指当一个低优先级任务获得了处理器执行资源后，即使内核知道有更高优先级的任务在等待处理器资源，仍然会让这个低优先级任务继续执行，直到当前任务完成或发生某种事件而进入阻塞态时，才会把处理器资源分配给当前最高优先级的任务。虽然这种调度方式比较简单，但它不适合于分时系统，也不适合于实时系统。

抢占式调度方式是指当一个低优先级任务正在处理器上执行时，如果有更高优先级的任务出现需 要使用处理器资源，内核会立即暂停正在执行的任务，将处理器资源分配给当前更高优先级的任务。这种方式对提高系统的实时性和响应效率有明显的好处，但也要遵循一定原则，否则可能因为频 繁切换任务而降低处理器效率，或者让低优先级任务等待时间过长影响系统整体性能。

很显然，车用领域的操作系统内核都必须支持基于任务优先级的抢占式调度方式。内核任务调度系统设计的核心是如何为每个任务定义合适的优先级，以保证包括任务截止时间在内的各项系统性能指标都能得到满足。

图 2.3-9 优先级队列调度策略示意图（队列0具有最高优先级）

为了简化系统设计，有的简要架构系统（如 uC/OS-II）甚至规定所有任务的优先级都不同，任务的优先级也同时唯一标识了该任务本身，但在复杂系统下这个方法不太适用。通常我们会将系统中所有的 任务按照一定的优先级定义划分为若干个不同优先等级的多级队列（Multi-Level Queue，MLQ( 图 2.3- 9)），优先级相同的任务放在一个队列中，高优先级任务队列优先得到服务，当高优先级队列为空或阻塞时，低优先级队列才能得到服务。此外，还需为每个任务队列采用合适的任务调度策略来决定哪个任务该优 先获得资源（一般会采用 FIFO 和 RR 机制）。MLQ 方法中，系统性能表现主要依赖于对任务优先级的合理定义。常用的任务调度策略和对应的任务优先级定义如下表 2.3-3 所示：

表 2.3-3 不同优先级调度策略特点

针对 MLQ 调度策略可能带来的低优先级任务饥饿（长时间得不到服务）和优先级反转问题（高优先级任务所需资源被低优先级任务锁住），又出现了多级反馈队列（Multi-level Feedback Queue，MLFQ） 调度机制，这一机制采取了动态调整任务优先级的策略，在 MLQ 机制的基础上采用了短任务优先级策略，

同时还会对任务的运行时间做评估，即统计每个任务已经执行了多长时间，并据此判断此任务是长任务还是短任务，然后调整对应任务的优先级，被判断为长任务的优先级会被逐次调低。为避免低优先级任务长期得不到服务，还可以定时 / 不定时将所有任务优先级提到最高，再根据任务实际运行长短动态逐渐调整优先级。

对于周期性实时任务，除了上述 MLQF 方法外，还可使用速率单调（Rate-Monotonic, RM）策略。这种策略是要预先知道任务的周期，并根据周期静态地为每个任务分配一个优先级：任务的周期越短， 意味着截止时间要求越迫切，优先级越高。RM 策略还可以支持抢占式调度，高优先级的任务可以抢占低优先级的任务。此外，RM 也可以引入动态优先级变化机制，增加调度策略的调度能力。RM 方法由于优先级固定，实现简单，带来的任务时延固定，成为解决周期性实时任务最佳策略。

在实时性任务调度中，还可以采用最早截止时间优先（Earliest Deadline First, EDF）策略。这种策略和 RM 类似，只是该策略是根据任务的截止时间来动态分配任务优先级。

另外，还有一种分区调度机制，该机制将处理器算力按一定比例分隔成几个区（比如 70%，30%）， 然后把不同线程分到这些分区里按上述调度策略进行调度。当分区里的处理器资源预算被用完以后，该 分区里所有可执行线程都会被 “停住” ，直到预算恢复。为了提高处理器利用率，降低分区资源的空置率， 同样可以采取   “自适应分区调度”   机制来改进调度性能，即定时计算各分区的算力闲置情况，在分区算力有富裕时，“自适应” 允许把多出来的算力 “借给” 需要更多算力的分区。

需要指出的是，内核硬实时调度机制只是支撑硬实时任务的一部分，整个任务的实时性还需要依赖于应用本身的设计，例如在 AUTOSAR CP 中还提出了通过将应用和 CPU 核（多核情况下）绑定，禁止动态分配内存的方法来保证应用运行的确定性。

总之，从技术发展趋势看，上述的这些基于优先级的抢占式进程调度机制通过一定程度的    “动态” 优化，都能很好地在满足硬实时任务的截止时间要求的基础上，照顾到软实时业务和其他非实时业务的性能需求，达到系统最优化，因此在现有的简要架构、宏内核以及微内核架构中都被广泛支持。

4.  健康监控

在汽车安全车控和智能驾驶应用领域，操作系统内核除了要满足应用的实时性和确定性要求外，功能安全的保证也同等重要的。由于操作系统内核是由软件代码组成，从软件工程的角度来看，缺陷几乎是不可避免的，而这些缺陷在某些特定条件下有可能会引发功能安全故障。因此，为了及时在系统运行过程中发现这些故障，并及时处理以防止故障的扩散，避免引发功能安全事故，采取健康监控是一种必要的解决方案。

健康监控系统用于监视硬件、应用程序和操作系统的状态。当发现故障时，需进行记录故障、识别故障等级、按故障等级进行不同的故障处理分派、提供防止故障蔓延的处置手段的操作。在安全可靠性要求极高的飞行器航空电子领域中，健康监控功能已经成为飞行器安全的重要保障机制。国际航空电子标准中定义的系统层次的健康监控中，将单一 CPU 内的健康监控体系分为三层故障处理级别。与之类似，汽车电子系统虽然没有统一的故障处理级别标准，但也可以参考航空电子标准中的健康监控机制，例如可将故障级别划分为分区级、管理级和核心级三个等级，并可对不同级别的故障设置不同的处理策略 ( 图2.3-10)。

图 2.3-10 故障处理流程示意图

分区级、管理级和核心级处理的异常是对应 CPU 硬件可捕获的异常。当产生 CPU 异常时，操作系统底层硬件抽象层的异常处理程序首先会根据异常产生的位置来判定异常处理级别，然后健康监控系统根据异常级别做相应处理。CPU 异常处理级别的确定方式如下所述：

如果 CPU 异常产生的位置是在操作系统内核态，则该异常属于核心级异常；

如果 CPU 异常产生的位置是用户态，则进行以下判断：

如果用户分区产生的异常不是二次异常（用户分区触发异常的处理过程中再次触发的异常被认定为二次异常），则作为分区级异常；

如果用户分区产生的异常是二次异常，且此用户分区的管理分区不是自身，则作为管理级异常；如果产生二次异常的用户分区对应的管理分区处于休眠态，那么该异常升级为核心级异常。

针对分区级、管理级和核心级的异常，其健康监控处理方式如下描述：

分区级

主要处理用户分区运行过程中用户态产生的一些异常，如：进程自身报错、被零除、内存保护、非法

系统调用等。分区级异常由用户安装的用户分区异常处理程序处理。

管理级

每个用户分区可以配置一个管理分区，用来帮助被管理用户分区处理自身无法处理的异常。被升级到管理分区处理的异常称为管理级异常，如用户分区产生的二次异常。

当用户分区产生的异常升级为管理级时，健康监控就会对产生异常的用户分区进行默认处理（如挂起） 及后续一系列预设的异常处理。

核心级

主要处理内核态程序运行过程中产生的一些异常和管理分区无法处理的被管理用户分区产生的异常， 如：内核态程序产生了非法指令；管理分区是自身的用户分区产生的二次异常。

内核态程序运行过程中产生的异常需要执行健康监控中的内核默认异常处理，如记录异常上下文信息，停止整个系统，防止故障的蔓延。

图 2.3-11 故障分派及处理示意图

整个健康监控系统的故障分派及处理的架构如图 2.3-11 所示，其核心是由操作系统内核所维护的系统健康监控表，该表由系统集成者进行静态配置，作为系统逻辑配置的一部分。当处理器或操作系统 内核检测到一个故障时，在系统健康监控表中通过系统状态和故障类型，获取事先定义的故障处理级别。系统健康监控表根据错误代码和注入时的系统状态指定故障的分派级别（分区级、管理级或核心级）。系统健康监控表是作为健康监控总体故障处理派发的一级表，当故障处理进入对应故障级别的处理流程后， 根据各自故障级别的健康监控表（分区健康监控表、管理健康监控表、核心健康监控表）中对应的故障类型调用相应的处理程序（系统默认处理或用户自定义处理）。

2.3.4  典型应用案例

1.  国产车用操作系统应用案例

从 2017 年开始，一些国内供应商本土化研发的车用操作系统已经陆续在上汽、一汽、长安等 OEM 厂商的验证交付项目和研发量产项目中得到应用。现阶段，一些有代表性的基础软件供应商正在与国内主要 OEM 主机厂联合推动基于微内核和 Safety Linux 的双内核智能驾驶操作系统的量产上车项目。

(1) 虚拟仪表量产项目

图 2.3-12 虚拟化仪表量产项目

在这个项目 ( 图 2.3-12) 中，基础软件供应商提供了 Hypervisor、微内核 RTOS 和 Safety Linux 三大产品，其中，Hypervisor 提供半虚拟化功能并提供隔离保障，微内核 RTOS 运行紧急仪表，Safety Linux 上运行虚拟仪表。主要功能如下：

·  提供快速启动方案，支持启动动画；

·  提供图形引擎，支持 KANZI，达到 1080p@60fps；

·  提供中控投屏视频与仪表画面的融合方案；

·  提供仪表画质监控功能；

·  提供业务稳定性监控功能，异常情况下及时切换到紧急仪表。

(2) 双内核智能驾驶操作系统解决方案

现阶段，不论是微内核 RTOS，还是 Safety Linux 操作系统在智能驾驶领域都有一定的应用局限性， 前者具备高功能安全等级，但缺乏完善的智能驾驶生态资源支撑，构建周期漫长；后者具备丰富的生态， 但获得所需功能安全等级认证较难。考虑到这些问题，某厂家基于自研车用操作系统产品系列，推出基 于微内核和 Safety Linux 的双内核智能驾驶操作系统解决方案 ( 图 2.3-13)，可完整兼顾智能驾驶对功能安全和丰富应用生态两方面要求，为汽车 OEM 主机厂快速落地智能驾驶项目提供强有力的支撑。

图 2.3-13 双内核智能驾驶操作系统解决方案

在 Microkernel RTOS+Safety Linux 的双内核方案中：

Hypervisor 支持的Type-1 类型虚拟化技术可允许多个操作系统和应用共享硬件，实现安全分区隔离， 支持硬件虚拟化和软件虚拟化。Hypervisor 支持全虚拟化和半虚拟化技术，通过与其 Microkernel RTOS 的一体化设计，能够同时运行原生实时任务和虚拟机中的任务，提升整体性能。

智能驾驶场景中的数据融合、环境建模、路径预测、决策、规划、控制等相关业务由微内核 RTOS 承载，最高可保证 ASIL-D 级功能安全。微内核 RTOS 内核部分仅实现实时任务调度、时钟、中断、内存管理、IPC 等基础功能，代码量小，运行速度快，安全性和稳定性高。

AI 融合感知处理及算法类业务需要使用图形图像处理以及深度学习算法模型框架，对底层算力芯片的驱动适配要求也较高，这部分服务由 Safety Linux 承载，可充分利用其既有成熟的软硬件生态快速完成开发。Saftey Linux 支持 POSIX 标准中的大部分实时信号处理机制和功能，同时通过开源实时性 RT 补丁，支持三级抢占，自旋锁主动释放，资源分区，任务可配置优先级，任务排他性绑核运行，无中断干扰， 智能迁移等特性，增强实时调度能力。

同时，依托于某厂家微内核 RTOS 的 ASIL-D 级功能安全能力，通过在 Safety  Linux 中部署健康监控代理，实时对 Safety Linux 的关键应用、内核和 BSP 进行异常监测和故障诊断，并根据故障等级和处理规则，控制其完成相应的失效处理，在一定程度上也可提升 Safety Linux 的功能安全。

2.  某厂家 QNX 微内系统应用案例

长城汽车集团旗下某厂家在其全栈自研的小魔盒3.0 智能驾驶系统中，搭载了QNX OS for Safety 2.2 操作系统，实现多种场景下的智能辅助驾驶。

众所周知，自动驾驶系统中有着大量的算法任务调度，海量的传感器数据交互，加上自动驾驶特有的应用场景，因此对操作系统有着非常严格的要求。对于操作系统而言，不但对实时性有着非常严格的要求，安全方面更是重中之重。QNX 作为嵌入式软件行业的领导者，全球汽车装载量超过 2.15 亿，它的微内核架构不仅保证了操作系统服务的硬实时性，并且在软件架构上也契合了 SOA 的软件开发思路，使得小魔盒在软件架构的设计上更简洁。QNX 功能安全更是其优势所在，OS for Safety 2.2 通过了 ISO 26262 ASIL-D 认证，得益于此，小魔盒的安全认证变得更为简单。

小魔盒 3.0 将于 2022 年下半年首发于长城摩卡 dht-phev 激光雷达版，独有的城市 NOH 功能更是解锁了城市导航辅助驾驶，整体自动驾驶能力处于行业一流水平。

2.4  虚拟化

随着 ICT 技术的发展，单 SOC 算力可以承担更多业务，网络带宽拓展及低时延、区分服务等特性使得业务部署、功能分配更加灵活，比如 : 感知、融合、规划、控制、执行可分离解耦，汽车业务功能可分可合、可软件定义。电子电气架构从分布式架构到域集中式架构，再到中央集中式架构转变，分散的 ECU 功能集成到域控制器甚至车载中央计算机，这就是多域融合。

汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算，而是需要复杂的多核 SoC 芯片提供更为复杂控制逻辑以及强大的算力支持。但是多域业务具有不同的技术需求，比如座舱域 IVI 业务强调交互体验、应用生态丰富，比较适合的操作系统是 Android；仪表盘、辅助驾驶有实时性、可靠性要求，操作系统倾向于  RTLinux、RTOS ；智驾域强调大算力融合感知、推演规划，也有实时性、可靠性要求，也会选择   RTLinux、RTOS。在域融合的同时，要保证关键业务的安全可靠，也要考虑应用生态的可持续性兼容， 这就需要有资源隔离技术来支撑在同一 SOC 上切分资源，可并发运行多种操作系统，保障互不干扰。

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

图2.4-1 虚拟化典型应用场景

2.4.1  技术形态

Hypervisor 直译即 “超级监督者” ，也称为虚拟机监控程序（VMM）。如图 2.4-2 所示，Hypervisor处于 SoC 硬件平台之上，将实体资源（如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源， 按需分配给每个虚拟机，允许它们独立地访问已授权的虚拟资源。Hypervisor 实现了硬件资源的整合和隔离，使应用程序既能共享 CPU 等物理硬件，也能依托不同的内核环境和驱动运行，从而满足汽车领域多元化应用场景需求。

图2.4-2虚拟化在系统中的位置

在汽车领域，Hypervisior 主要完成以下任务：

CPU 虚拟化：为虚拟机提供 VCPU 资源和运行环境；

内存虚拟化：负责为其自身和虚拟机分配和管理硬件内存资源；

中断虚拟化：发生中断和异常时，按需将中断和异常路由到虚拟机进行处理；

虚拟机设备模拟：根据需求创建虚拟机可以访问的虚拟硬件组件；

硬件支持 BSP：提供 Hypervisor 在 SoC 上运行的板级支持包，如串口驱动；

虚拟机资源配置：对虚拟机的 CPU，内存，IO 外设等资源进行配置和管理；

虚拟机通信：为虚拟机提供  IPC，共享内存等通信机制。

虚拟机调度：为虚拟机提供优先级和时间片等调度算法；

虚拟机生命周期管理：创建，启动和停止虚拟机；

虚拟机调测服务：提供控制台，日志等调试功能；在汽车领域，Hypervisior 还面临如下挑战：

轻量高效。Hypervisor 在带来软件定义的灵活性的同时，也导致了软件栈层次增加，不可避免会有性能损耗。汽车领域的成本敏感特性，注定了降低 CPU、存储、网络、GPU  等外设性能损耗的需求贯穿整车项目始终，因此 Hypervisor 的轻量和高效十分重要；

安全可靠。相较于互联网领域看重的资源动态分配和闲置利用，汽车领域更看重 Hypervisor 的实时性、可靠性、安全性；

便捷适配。在汽车领域，芯片类型和操作系统丰富多样，嵌入式虚拟化的一大特点就是异构，Hy- pervisor 必须具备快速适配不同的底层硬件和上层操作系统的能力。

2.4.2技术发展趋势

1.  云边端虚拟化关键技术差异化

虚拟化技术最早可以追溯到 20 世纪 60 年代，IBM 开发了虚拟机监视器软件，将计算机硬件虚拟分割

成一个或多个虚拟机，可支持多名用户对大型计算机的同时、交互的访问。随着 21 世纪通用服务器算力的提升，云计算蓬勃发展，作为底层支撑技术的云虚拟化也快速迭代演进。后来算力从云、边、端逐步下沉， 也就伴随着出现了边缘虚拟化、端侧嵌入式虚拟化。它们的典型架构、关键技术需求如图 2.4-3 所示。

图2.4-3云边端虚拟化典型架构及关键技术需求

(1) 云侧虚拟化

其特点是硬件平台基本同构，大量节点构成集群，架构设计以吞吐能力优先，要支持多业务并发， 虚拟化要满足集群负载均衡、节能降耗的资源调度策略，在进行跨节点虚拟机调配过程中，要保证业务无中断迁移。虚拟机故障时，要能保证从检查点恢复，减少业务损失，虚拟机要能支持 CPU  算力、内存、存储空间、网络、GPU、外设等能力的弹性扩展，还要能超分配，以便提升数据中心的运营收益。

(2) 边侧虚拟化

是在某些特定业务的边缘节点上，采用通用 ICT 架构，支持多种业务的动态部署，典型如 SDN、NFV。其技术特点是：基于通用硬件平台、行业定制的管理部署平台，实现软硬解耦、软件定义，多功能节点按需部署、弹性组网，一般会采用 1+1 或者 N+1 冗余方式保证业务高可用，在 5G 电信网元中需要考虑 5G 业务端到端实时性，Hypervisor、虚拟机、通信协议栈都需要设计考虑。

(3) 端侧虚拟化

端侧典型特点是异构，其芯片架构、处理能力都差异较大。一般是单芯片方案，不存在着集群、主备间的虚拟机迁移，因此比较强调高安全、单节点高可靠，比如会有功能安全 ASIL 等级要求，同时对于实时性、确定性有更强的要求。另外，端侧资源更加有限、成本更敏感，因此要求 Hypervisor 轻量化、高性能。

2.  虚拟化模型趋势

Hypervisor 可以划分为两大类，一类是 Type1 裸机型，Hypervisor 直接运行在硬件设备上的，也叫做Bare-Metal Hardware Virtualization（裸机虚拟化环境）；一类是Type2 主机托管型，也叫做Hosted Virtualization（ 主机虚拟化环境）。图 2.4-4展示了两种 Hypervisor的分层架构。

图2.4-4 Type1和Typer2型Hypervisor

Type2 型 Hypervisor 需要借助宿主操作系统来管理 CPU、内存、网络等资源，由于 Hypervisor 和硬件之间存在一个宿主操作系统，Hypervisor 及 VM 的所有操作都要经过宿主操作系统，所以就不可避免地会存在延迟、性能损耗，同时宿主操作系统的安全缺陷及稳定性问题都会影响到运行在之上的 VM（虚拟机），所以 , Type-2 型 Hypervisor 主要用于对性能和安全要求不高的场合，比如 : 个人 PC 系统。

Type1 型的 Hypervisor 不依赖主机操作系统，其自身具备操作系统的基础功能。设计上更简洁，直接运行于硬件之上，整体代码量和架构更为精简，对内存和存储资源要求更少，可满足自动驾驶车控系统功能安全等级要求，也具备进行形式化验证的条件。所以汽车操作系统更适合使用 Type 1 型 Hyper-

随着微内核操作系统技术的发展，很多基于微内核操作系统设计的 Hypervisor 依赖的 Host OS 已经非常精简，只包括基本的、不变的功能，如 : CPU 调度和内存管理，设备驱动和其他可变组件处于内核之外，这类 Hypervisor 应当归于 Type1、还是 Type2，业内存在分歧。总体来说，微内核 Hypervisor 更小、更稳定、扩展性更好，更适合用于嵌入式虚拟化场合。

3.  Hypervisor 与虚拟机协作技术路线

(1) 全虚拟化

最初的虚拟化是通过软件模拟具有完整硬件系统功能的、运行在一个隔离环境中的计算机系统，即通过软件虚拟硬件设备提供给 GuestOS 使用，优点是 GuestOS 不感知外部真实硬件环境、不用改动。由于 Guest OS 中每次访问全虚拟化硬件都要陷入到 Hypervisor 中，直接导致该方式虚拟的硬件性能较差， 一般只用来模拟如串口等比较简单的硬件。对硬件的模拟可以在 Hypervisor 中直接模拟，也可以将请求传递到其他 VM 中进行模拟，如在某一 VM 中通过 QEMU 进行模拟。

(2) 硬件辅助虚拟化

Intel 最早提出硬件辅助虚拟化技术，由硬件直接提供共享功能，支持多 GuestOS 的访问，减少软件虚拟技术带来的延时和性能损耗。Intel 提出了分别针对处理器 & 内存、IO、网络的 Intel VT-x、Intel VT-d 和 Intel VT-c 技术等。随着 ARM 算力提升，从移动端向边缘、甚至云算力中心发展，ARM 也在不断增强其硬件辅助虚拟化技术，比如 stage 2 页表转换、虚拟异常等。

(3) 半虚拟化

在硬件辅助虚拟化技术不完善、不强大的发展阶段，或者对于某些复杂外设的共享复用，为避免全虚拟化的性能问题，可以采用 GuestOS 与 Hypervisor 协作的半虚拟化技术。这种技术一般应用于 IO 设备虚拟化， 采用前后端的方式来实现 IO 设备虚拟化，在 Guest OS 中实现前端驱动，在 Hypervisor 或 Host OS 中实现 后端驱动，前后端一般按照 VirtIO 标准来实现，后端驱动作为硬件的实际访问方。Guest OS 中前端驱动通过Virt Queue 等通信机制与后端驱动进行通信，前端驱动将 Guest OS 的请求传递给后端驱动，后端驱动将请求发送给硬件驱动，处理完后将结果再传回给前端驱动。半虚拟化相对全虚拟化实现的硬件性能较好， 且可实现相对比较复杂的硬件，比如 : 块设备，网卡，显示设备等。具体如图 2.4-5 所示。

图2.4-5 半虚拟化Pass-through资源分配

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

2.4.3  关键技术解读

1.  CPU 虚拟化和节能降耗技术

车载高性能处理器一般采用多核 CPU 架构。在 SMP（Symmetric Multi-Processing 对称多处理） 架构下，Hypervisor 调度器会根据 CPU 的亲和性配置让客户机操作系统在指定的 CPU 上运行，虚拟机的操作系统可按照自己的调度方式，比如 : ：优先级方式在 CPU 上进行任务调度。为了最大化地利用系统资源，Hypervisor 也支持多个虚拟机对某个 CPU 的共享使用。在共享核上，Hypervisor 可通过优先级或时间分区方式对虚拟机进行调度，确保虚拟机运行时间和调度策略是确定的。Hypervisor 的调度算法需要确保不能够出现分区内某个虚拟机出现死循环或故障而长期占用处理器资源，导致其他虚拟机的业 务无法得到合理时间配额的问题。

虚拟机调度还需要考虑节能降耗问题，在工作负载较高的情况下系统提升主频提升用户体验，在工 作负载较低的情况下系统自动节能降频提升续航。车载高性能处理器本身为了节能降耗需求设计为大小 核架构，CPU 以及之上运行的复杂操作系统需要支持大小核调度，动态调频，低功耗设置，关闭 CPU 核， 休眠（Suspend to RAM/Suspend to Disk）等节能降耗功能。系统虚拟化后，CPU 等物理资源都需要Hypervisor 才能直接访问，Hypervisor 调度算法也需要完成对虚拟机节能降耗的支持。

2.  IO 设备虚拟化

出于性能考虑，一般嵌入式领域多使用半虚拟化技术。半虚拟化技术需要 Guest OS 中的前端驱动与Hypervisor 中的后端驱动配合实现。前端驱动将 Guest OS 的请求通过 Hypervisor 提供的通信机制发送给后端驱动，后端驱动通过调用物理驱动实现对设备的访问。这就涉及到不同厂商的 Guest OS 与不同厂商的 Hypervisor 生态对接问题。

Virtio 是目前最流行的一种 I/O 半虚拟化解决方案。Virtio 是 OASIS 标准组管理的开放协议和接口，以使得虚拟机能够标准化方式访问 IO 设备。Virtio 于 2016 年 3 月正式标准化，2020 发布 V1.1 版本。Virtio 标准采用通用和标准化的抽象模型，支持设备类型不断增加，性能高效，在云计算领域广泛应用， 开源活跃度高，Linux 等操作系统已有稳定的前端驱动代码。大部分商业和开源 Hypervisor 都已经支持Virtio 标准。

Virtio 是车载行业比较常用的半虚拟化技术的实现，如图 2.4-6 所示，在 Guest OS 内部虚拟一条设备总线 Virtio-bus，通过 Virtio Ring 双向通信机制，前端驱动与挂载在 Virtio-bus 上遵循 Virtio 标准的后端虚拟设备，进行访问与通信。Virtio 提供了全面的 Virtio 总线和设备控制接口，包括 virtio-net，vir- tio-blk，virtio-console，virtio-input 等。

图 2.4-6Virtio虚拟化实现模型

·  利用 virtio-blk 技术实现块设备共享

块设备是使用缓存机制读写的存储设备，分配给 Hypervisor 所在的操作系统进行管理。virtio-blk driver 是符合 virtio 标准的块设备驱动，vdev virtio block 是后端的虚拟块设备，virtio  blk  driver 通过该vdev 设备完成对物理块设备的读写，并获取执行结果。

·  利用 virtio-net 技术实现跨系统通信

Virtio-net 实现了多系统间点对点的通信，Guest 系统内部的 virtio-net driver 通过 virtqueue 与Hypervisor 所在系统的 virtio-net 设备进行全双工通信，实现多系统之间的控制类、配置类的指令、数据的交互。适合音视频流以外的数据传输，稳定性较好，因 virtqueue 的控制逻辑复杂，对实时性有一定影响。

·  利用 virtio 技术实现触摸共享

触摸设备是字符型设备，通过 virtio-input driver、vdev-input 实现前端驱动和后端设备。设备端通过 virtqueue 向驱动上报触摸坐标数据。

3.  实时性技术

实时性是嵌入式实时操作系统的关键性能指标。Hypervisor 的实时性是整个系统实时性的基础，如果 Hypervisor 无法及时调度到客户机操作系统运行，客户机操作系统也不能取得较好的实时性指标。衡量 Hypervisor 实时性主要指标包括中断延迟和调度延迟。中断延迟以硬件发生中断时刻为起始时间，以虚拟机收到 Hypervisor 注入的中断时刻为截止时间，在各种压力情况下最长延时时间即为中断延时。调度延迟是指以高优先级的虚拟机进程就绪为起始时刻，以该高优先的虚拟机进程得到调度运行为截止时刻，在系统各种压力情况下最长的延时时间即为调度延迟。

中断虚拟化后，当外界中断产生时，Hypervisor 收到并以最快的速度注入到虚拟机，使得 Hypervi- sor 对虚拟机中断处理时间足够少。Hypervisor 优化虚拟机的切换时间，尽量减少 Hypervisor 上关中断和关抢占的时间，尽量少使用内核锁，当高优先级的虚拟机需要切换运行时，能最快速度切换至高优先级虚拟机上运行。

4.  安全和可靠性技术

功能安全、信息安全和可靠性是车控操作系统产品可靠安全运行的必要组成部分。Hypervisor 为智能汽车域控制器提供基础运行环境，其安全性和可靠性是保证整个系统功能安全和可靠的基础和核心。Hy- pervisor 需按照汽车功能安全 ISO26262  ASIL-D 最高标准进行设计，开发和测试，其功能安全需求由域控制器产品的安全需求分解产生。

Hypervisor 上运行了多个虚拟机，一个虚拟机的异常不能传递至其他虚拟机。Hypervisor 能获取到当前系统整体健康状态，当虚拟机发生异常时，Hypervisor 应实时监控系统健康状态，有效地隔离故障， 并在最小波及范围内修复异常，保障系统持续可用。

Hypervisor 加入汽车软件栈，会导致纵向上软件栈层次增加，横向上业务软件复杂度增加，而汽车的安全可靠要求强于既有的云侧虚拟化、边缘虚拟化，因此虚拟化安全性正日益得到行业的关注。这些安全性包括：

·  虚拟机管理器和虚拟机之间的信任链问题。利用虚拟化技术在一个可信物理平台上创建出多个虚拟机，并将从硬件可信根开始构建的信任链传递到每一个虚拟机，从而在一个可信物理平台上构建多个虚拟的可信计算平台，有些解决方案缺乏虚拟机管理器到虚拟机之间的信任链验证；

·  虚拟机间的攻击：恶意入侵者可以通过利用虚拟机管理程序中的漏洞，通过同一物理主机上存在的另一个虚拟机来获得对虚拟机的控制，从而破坏目标虚拟机；

·  虚拟机逃逸：利用虚拟机软件或者虚拟机中运行的软件的漏洞进行攻击，以达到攻击或控制虚拟机宿主操作系统的目的。

为了提高 Hypervisor 的安全性，建立相应的安全性目标很重要，表 2.4-1 简要列出相关要求：

表2.4-1 安全性目标

Hypervisor 的安全性能力可以从三个维度进行提升。

(1) 需要建立安全边界

如图 2.4-7 所示，这个边界由 Hypervisor 严格定义并且实施。Hypervisor 安全边界的保密性、完整性和可用性需要得到保证。边界能防御一系列攻击，包括侧向通道信息泄漏、拒绝服务和特权提升。虚拟机监控程序安全边界还提供网络流量、虚拟设备、存储、计算资源和所有其他虚拟机资源的隔离能力。

图2.4-7 安全边界

整体虚拟化安全架构如图 2.4-8 所示。安全边界的保密性可以通过传统的密码学方法来实施。完整性通过可信度量机制来保障，可信报告机制实现不同虚拟环境的可信互通，监控机制动态度量实体的行为， 发现和排除非预期的互相干扰。虚拟技术提供的隔离机制将实体运行空间分开。

图2.4-8 整体虚拟化安全架构

安全边界的隔离通过Hypervisor 的vCPU 调度隔离安全、内存隔离、网络隔离和存储隔离技术来支持， 实现了同一物理机上 Hypervisor 和虚拟机、虚拟机之间的隔离。

(2) 需要建立深度防御漏洞的缓解机制

对于安全边界存在的潜在漏洞，Hypervisor 需要有一定的技术手段进行主动防御，这些技术手段包括地址空间布局随机化（ASLR）、数据执行保护（DEP）、任意代码保护、控制流保护和数据损坏保护等。

(3) 建立强大的安全保障流程

与 Hypervisor 相关的攻击面包括虚拟网络、虚拟设备和所有跨虚拟机表面，所有虚拟机攻击面都建议实施威胁建模、代码审核、模糊（fuzzed）测试，通过建立自动化构建及环境，触发定期安全检查。

虚拟化技术作为云计算场景的重要技术，在 10 多年的生产实践中已经积累了很多安全范式，这些经验也可被汽车场景借鉴。但是与云场景相比，汽车场景的虚拟化技术也有其特殊性，如虚拟机不需要动态迁移 / 创建，Hypervisor 有功能安全等级的要求等等，其安全性手段需要在实践中不断丰富和完善。

2.4.4  典型应用案例

在汽车智能化发展历程中，虚拟化主要应用于智能座舱、智能驾驶、智能网关等融合场景。智能驾驶受技术成熟度、政策法规所限，基本处于预研、方案原型阶段。智能网关业务功能相对同构，并且有可能进一步融合到其他场景方案中。因此，目前主要的应用案例集中在智能座舱中。

智能座舱域融合也是在近几年启动，正在不断迭代演进中。受芯片算力、虚拟化技术成熟度、生态链对于虚拟化解决方案的掌控能力等因素影响，有些厂商同时采用了硬隔离方案来实现域融合，一方面最大程度地沿用既有技术能力，有确定性保障，但是缺少了软件定义的灵活性，智能化程度有限，是域融 合的一种可选方案。在嵌入式虚拟化技术方面，国外的 QNX、OpenSynergy、PikeOS  等有先发优势，尤其在汽车领域已耕耘多年，因此在这两年涌现了较多的应用案例。在智能本土化发展的趋势带动下，国内这几年也出现了不少芯片厂商、独立软件厂商研发嵌入式虚拟化技术、产品、解决方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中兴 GoldenOS、斑马智行的 AliOS Hypervisor、中汽创智 CAIC Hypervi-sor 等。

1.  智能座舱域控制器产品

某厂家智能座舱域控制器产品，如图 2.4-9 和图 2.4-10 所示，基于高通 8155、瑞萨 R-Car H3 处理器，采用 QNX Hypervisor，搭载QNX Host、Android P/R/S Guest OS, 可配置输出最多 6 块高清大屏独立显示，集成了娱乐系统、液晶仪表、车身控制、DMS、APA   等功能，支持独立四音区、多屏互动和音视频分享，集成度高，在长城、长安、宇通客车等多款车型上适配量产。

另外，国产化方案芯驰 X9HP+ 平台，采用硬分区、Hypervisor 两种方案灵活配置实现中低端智能座舱域控制器产品。

图 2.4-9智能座舱域控制器

图2.4-10国产化方案智能座舱域控制器

2.  RHOS 智能座舱域控制器平台

(1) NXP I.MX8QM 座舱域控制器

某厂家基于自研的 Type-1 型虚拟化软件 RHOS(Raite Hypervisor OS)，适配支持了 NXP I.MX8QM， 提供一个轻量、灵活的汽车智能座舱虚拟化解决方案，已在东风车型量产上市。其系统架构如图 2.4-11 所示：

图 2.4-11 NXP I.MX8智能座舱系统架构

在 SoC 上运行 Hypervisor 后可支持同时运行多个操作系统，比如 Linux 系统可以运行实时性和安全性较高的业务，如全液晶仪表等，可以扩展运行 DMS、HUD 等业务。另外一个虚拟机运行 Android 操作系统，上面部署信息娱乐等安全性和实时性要求较低的业务。为保证系统具备良好的市场竞争力，域控制器兼容 TBOX 功能需求，系统能够支持休眠唤醒和快速启动。

Linux 和 Android 虚拟机可按需进行资源的配置，包括内存、CPU、存储空间、外设等。该架构支持系统升级，包括对虚拟机和 Hypervisor 的升级，支持异常日志记录，包括虚拟机内核和 Hypervisor 日志。

多屏交互是智能座舱重要的应用场景，Android 的 APP 应用程序可以通过 Hypervisor 推送到 Linux 仪表进行显示。

图2.4-12 虚拟机多屏交互架构

Android 和 Linux 仪表交互的方案如图 2.4-12 所示。NXP I.MX8QM 芯片有两个以上显示接口，每个显示接口可以接 2 个显示屏，当 Android 系统需要投射信息到仪表屏幕时，仪表显示屏的 Overlay 图层可以进行投屏内容的显示。系统交互零延迟、零拷贝，多系统交互不额外占用 CPU 和 GPU 资源。通过Hypervisor 虚拟化技术实现跨系统多屏交互，有效提高了行车安全性，并降低智能座舱的硬件成本。

（2） MT8675 座舱域控制器

RHOS 通过适配支持MT8675，形成一个功能丰富、性价比高的一机多屏智能座舱域控制器解决方案，已获得多个车厂量产项目。

其总体系统架构如图 2.4-13 所示：

图2.4-13 MT8675智能座舱系统架构

MT8675 只提供了一个 GPU，座舱域需要在仪表和中控上共享使用 GPU 资源。RHOS 实现了 GPU 虚拟化共享，并通过性能优化，达到业界领先的虚拟化效果（损耗 < 6%）。RHOS 支持 Suspend to RAM 功能，MT8675 A 核完全下电，满足智能座舱待机静态功耗小于 4mA 要求。

3.  KCS 3.0 智能座舱虚拟化平台

某厂家基于 Renesas H3/M3 + QNX Hypervisor2.x 开发了支持 “一芯多屏” 的 KSC3.0 智能座舱虚拟化平台 , 可实现在一颗 SOC 上同时运行 QNX 仪表、Android 中控及副驾等多个系统，并支持以下特性：

4 个屏幕同时输出

多系统实时 3D 渲染

多屏共享

仪表和 IVI 间音乐、地图应用的多屏互动，

快速启动：<2s

人脸及情绪识别等

平台展示如图 2.4-14 所示

图2.4-14 KCS 3.0智能座舱虚拟化平台

此外，该厂家还基于 X86+KVM+QEMU 开发了数字孪生平台，通过虚拟化技术来模拟硬件开发平台， 包括支持多路 Camera、多路显示输出、多系统音频混音，屏幕共享以及多路 CAN 信号等，能够很好地解决 SOA 平台开发过程中开发人员对于真实硬件平台的依赖。