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

某厂家 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 更小、更稳定、扩展性更好，更适合用于嵌入式虚拟化场合。