智能汽车车用基础软件的内核和中间件 关键技术解读

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 平台开发过程中开发人员对于真实硬件平台的依赖。

识别二维码或点击阅读原文下载：
《中国汽车基础软件发展白皮书》