导读:
9月18日，《中国汽车基础软件发展白皮书3.0》在 “2022世界智能网联汽车大会” 【ICT企业专场：智能芯片与汽车软件】主题分会 正式发布
白皮书3.0以“汽车基础软件平台”为主题，围绕其技术形态和关键技术进行深入探讨，共享知识成果。白皮书对基础软件平台做了定义，是介于应用软件和异构硬件之间，用于支撑应用软件的快速高效开发，它由基础软件开发平台和基础软件验证平台两部分组成。
本文节选自其中关于操作系统内核的解读。
01
操作系统内核技术架构
1.1. 简要架构
在车辆动力电子，底盘电子和车身电子等实时控制功能实现当中，经常会使用到一些功能相对简单的微控制单元（MCU）芯片（如单片机），这类芯片资源配置较低，硬件上没有为操作系统内核提供复杂的内存管理和特权级别的隔离功能，因此会采用一种简要的操作系统内核结构设计。在简要结构设计当中，内核服务与应用程序会被放置在同一地址空间，应用程序无需切换地址空间和权限层级就能够直接调用内核服务，具有高效的优势，有利于实时业务的实现。但相对于后面提到的宏内核和微内核架构设计，简要架构系统缺乏内核隔离保护能力，任何一个模块（无论是应用还是内核服务）出现问题都可能导致系统崩溃。
出于硬件成本和实时性的综合考虑，汽车领域中许多基于 AUTOSAR CP 的安全车控嵌入式实时系统都采用了简要架构设计。其他领域类似的简要架构系统还有 uC/OS II，FreeRTOS。
1.2. 宏内核架构
宏内核（Monolithic Kernel）架构在计算机和通信领域是应用最为广泛的一类操作系统架构，其相关产品的生态也最为完善，目前常见的桌面系统（如 Windows，MacOS，Linux 桌面发行版），服务器系统（如Unix，Linux）和主流手机操作系统（Android，iOS）均是基于宏内核架构。宏内核架构操作系统在智能驾驶和智能座舱领域也有大量应用。宏内核的特点是将所有传统的操作系统服务（例如进程调度，内存管理，文件系统和设备驱动）全部运行在内核态，能够直接操控硬件，系统服务间的内部调用效率相对较高。
在硬件能力的支撑下，宏内核可以实现用户程序和内核的安全隔离保护，采用合适的进程调度机制（优先级抢占式）时也能够满足车用领域的硬实时性任务要求，并能支持虚拟化等新技术来满足汽车 E/E 架构向集中式架构演进的需求。
但是应该看到，由于面向通用业务而设计，随着宏内核功能的丰富，其代码量也会变得越来越庞大，以 Linux 内核为例，2021 年底其内核已经达到了 3220 万代码行的规模，且可能会持续增长，在车用领域这不仅意味着软件复杂度和硬件成本的增加，也意味着更高的信息安全和功能安全挑战。目前，业界
还未看到基于宏内核的操作系统产品通过功能安全 ASIL-B 以上的安全认证。
为了应对这些问题，宏内核架构的操作系统也采用了模块化，抽象，分层，层级等方法来控制其不断增长的复杂度。
- 模块化：内核通过模块化的策略来组织功能，提供可加载内核模块（LKM）机制。例如将大部分设备驱动与内核其他功能解耦。
- 抽象：对内核服务进行抽象以提高可维护性、降低复杂度。例如 Linux 将所有的数据，设备和内核都抽象成文件，对应用层提供统一接口。
- 分层：将逻辑上或功能上相近的模块分层，以便更好地组织功能。例如 Linux 文件系统的分层结构。
- 层级：对于内核的资源管理引入层级的概念，如进程调度优先级的分类等。
1.3. 微内核架构
从功能服务的角度看，微内核（Microkernel）操作系统和宏内核系统并无本质差异，只是采用了不同的内核架构设计思路。由于宏内核架构系统将所有的服务都运行在内核态，任何一个模块出现错误或者被攻击就有可能引发内核的崩溃，从而影响到整个系统的稳定性。而且随着内核代码量越来越大，这种概率还会提高。为了保证内核的稳定性，微内核架构主张将宏内核的功能进行解耦，将某些功能从内核中剥离出来作为独立服务，并挪到用户态去运行（比如文件系统、设备驱动）。内核为这些剥离到用户态的服务提供各种通信机制，以保证这些服务能够相互协作，这样即使单个服务出错或者被攻破也不会导致内核崩溃或者出现系统安全问题。
微内核的最小内核设计原则主张保留尽量少的功能在内核态运行（如进程调度、内存管理、进程间通信等）。微内核架构设计同时还主张机制与策略分离的原则，尽量将策略配置管理功能剥离到用户态，将实现机制保留在内核态运行，这样可以根据应用场景适配不同的内核服务实现机制。微内核的这两个设计理念不仅提高了安全性，而且由于内核功能相对简单，其内核服务的时延相对比较容易控制和估算，也有利用于硬实时系统的调度实现。
不过由于第一代微内核系统代表 Mach 采用了一种过于通用的进程间通信 IPC（Inter-Process Communication）设计方案，加上自身资源（内存、CPU 缓存）占用过大等问题，导致其性能受到很大影响，与同期的宏内核系统相比有明显差距。但后续有文献分析表明，“高性能的 IPC 的设计与实现必然是与体系结构相关的，过度抽象将极大影响 IPC 的性能，而利用体系结构相关的状态进行优化则可将 IPC 性能提升到极致” 。经过改进和优化，第二代微内核系统代表 SeL4 在采用了最小化设计原则的情况下，也达到了与同时期宏内核系统同样的效率水平。此外，SeL4 系统还通过了形式化验证。
目前微内核架构系统在汽车、工业等高实时、高可靠和高安全领域得到了广泛应用，并有商用化产品（如 QNX）通过了汽车行业的 ASIL-D 功能安全认证。
02
技术发展趋势
前面已经提到，影响 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 的安全关键应用程序和系统。
03
关键技术解读
3.1. 高效IPC技术
无论是安全车控、智能驾驶还是智能座舱应用，都必然存在着多个任务并发执行的情况。每一个任务都可能对应着一个或多个进程，用户应用进程之间由于可靠性和信息安全的需要采用了各种严格的时空隔离手段（技术原理参见 2.3.3.2 节）进行隔离，不能直接进行通信。但是用户进程间的协作又必须要进行信息交互，因此只能依赖于操作系统内核提供的进程间通信机制来完成，业界称为 IPC 技术。IPC 机制在实现进程间的数据传递功能的同时，还需要内核通过对进程的运行状态和运行时间的控制来实现控制流从发送者进程到接收者进程的切换（返回的过程类似），从而直接影响系统运行效率。
目前宏内核架构和微内核架构的操作系统都能够提供一些常见的 IPC 通信机制，包括管道、消息队列、信号量、共享内存、套接字 Socket 等。具体应用场景和特点如下表 2.3-1 所示：
出于最小内核服务设计的考虑，在微内核架构系统中，类似于驱动，文件系统等传统的内核服务被移到了用户态，许多原本可以通过简单系统调用就可实现的内核功能也必须使用 IPC 机制来提供服务，在系统负荷较高的情况下可能会面临着比宏内核更加严重的效率问题。因此对微内核系统的研究一般都会将改进 IPC 效率作为优化系统性能的重要选择之一。
传统的微内核 IPC 机制设计是通过端口（port）和消息（message）来实现进程间接通信。通信的双方不需要显式指定另一方，而是通过端口进行通信，这样可以将用户进程本身和 IPC 通信隔离开，只要一个进程在内核拥有某个端口，就能通过这个端口和另一端的进程通信。进程之间通过端口流通的数据就是消息。
在微内核 IPC 通信机制优化方案当中，还有一些比较极端的手段，如迁移线程技术（thread migration）。如果把其他 IPC 通信机制看作将需要处理的数据发送到其他进程（或线程）进行处理的话，那么迁移线程技术就是把其他进程的代码拉进当前进程中运行，这样就会大量减少内核进程切换的代价，同时也能通过共享参数栈和寄存器来简化数据传输，减少序列化开销，优化并发，避免共享的全局数据结构。在一些学术文献中，迁移线程模型被用在了 LRPC（轻量级远程过程调用）技术当中。
上面两张图 ( 图 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 通信机制。
3.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.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 核（多核情况下）绑定，禁止动态分配内存的方法来保证应用运行的确定性。
总之，从技术发展趋势看，上述的这些基于优先级的抢占式进程调度机制通过一定程度的 “动态”优化，都能很好地在满足硬实时任务的截止时间要求的基础上，照顾到软实时业务和其他非实时业务的性能需求，达到系统最优化，因此在现有的简要架构、宏内核以及微内核架构中都被广泛支持。
3.4. 健康监控
在汽车安全车控和智能驾驶应用领域，操作系统内核除了要满足应用的实时性和确定性要求外，功能安全的保证也同等重要的。由于操作系统内核是由软件代码组成，从软件工程的角度来看，缺陷几乎是不可避免的，而这些缺陷在某些特定条件下有可能会引发功能安全故障。因此，为了及时在系统运行过程中发现这些故障，并及时处理以防止故障的扩散，避免引发功能安全事故，采取健康监控是一种必要的解决方案。
健康监控系统用于监视硬件、应用程序和操作系统的状态。当发现故障时，需进行记录故障、识别故障等级、按故障等级进行不同的故障处理分派、提供防止故障蔓延的处置手段的操作。在安全可靠性要求极高的飞行器航空电子领域中，健康监控功能已经成为飞行器安全的重要保障机制。国际航空电子标准中定义的系统层次的健康监控中，将单一 CPU 内的健康监控体系分为三层故障处理级别。与之类似，汽车电子系统虽然没有统一的故障处理级别标准，但也可以参考航空电子标准中的健康监控机制，例如可将故障级别划分为分区级、管理级和核心级三个等级，并可对不同级别的故障设置不同的处理策略 ( 图2.3-10)。
图 2.3-10 故障处理流程示意图
分区级、管理级和核心级处理的异常是对应 CPU 硬件可捕获的异常。当产生 CPU 异常时，操作系统底层硬件抽象层的异常处理程序首先会根据异常产生的位置来判定异常处理级别，然后健康监控系统根据异常级别做相应处理。CPU 异常处理级别的确定方式如下所述：
- 如果 CPU 异常产生的位置是在操作系统内核态，则该异常属于核心级异常；
- 如果 CPU 异常产生的位置是用户态，则进行以下判断：
- 如果用户分区产生的异常不是二次异常（用户分区触发异常的处理过程中再次触发的异常被认定为二次异常），则作为分区级异常；
- 如果用户分区产生的异常是二次异常，且此用户分区的管理分区不是自身，则作为管理级异常；
- 如果产生二次异常的用户分区对应的管理分区处于休眠态，那么该异常升级为核心级异常。
针对分区级、管理级和核心级的异常，其健康监控处理方式如下描述：
- 分区级
主要处理用户分区运行过程中用户态产生的一些异常，如：进程自身报错、被零除、内存保护、非法系统调用等。分区级异常由用户安装的用户分区异常处理程序处理。
- 管理级
每个用户分区可以配置一个管理分区，用来帮助被管理用户分区处理自身无法处理的异常。被升级到管理分区处理的异常称为管理级异常，如用户分区产生的二次异常。当用户分区产生的异常升级为管理级时，健康监控就会对产生异常的用户分区进行默认处理（如挂起）及后续一系列预设的异常处理。
- 核心级
主要处理内核态程序运行过程中产生的一些异常和管理分区无法处理的被管理用户分区产生的异常，如：内核态程序产生了非法指令；管理分区是自身的用户分区产生的二次异常。
内核态程序运行过程中产生的异常需要执行健康监控中的内核默认异常处理，如记录异常上下文信息，停止整个系统，防止故障的蔓延。
图 2.3-11 故障分派及处理示意图
整个健康监控系统的故障分派及处理的架构如图 2.3-11 所示，其核心是由操作系统内核所维护的系统健康监控表，该表由系统集成者进行静态配置，作为系统逻辑配置的一部分。当处理器或操作系统内核检测到一个故障时，在系统健康监控表中通过系统状态和故障类型，获取事先定义的故障处理级别。系统健康监控表根据错误代码和注入时的系统状态指定故障的分派级别（分区级、管理级或核心级）。系统健康监控表是作为健康监控总体故障处理派发的一级表，当故障处理进入对应故障级别的处理流程后，根据各自故障级别的健康监控表（分区健康监控表、管理健康监控表、核心健康监控表）中对应的故障类型调用相应的处理程序（系统默认处理或用户自定义处理）。
04
典型应用案例
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 的功能安全。
4.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 功能更是解锁了城市导航辅助驾驶，整体自动驾驶能力处于行业一流水平。
AUTOSEMO背景
鉴于中国汽车基础软件发展的重要性，应国内主要汽车企业的要求，并经主管部门认可，中国汽车工业协会（以下简称：中汽协），于2019年12月决定组建中国汽车基础软件生态委员会（英文China Automotive Basic Software Ecosystem Committee，简称AUTOSEMO）。旨在联合汽车及软件产业内的成员，形成由本土企业主导的共同规划和创建适应新需求的软件架构和接口规范，做强本土基础软件，推动行业开放和协作，促进产业向更智能化的方向发展。在当前复杂多变的国际产业竞争趋势下，设立AUTOSEMO具有十分重要的战略意义和现实意义。
作者： AUTOSEMO
来源：智能汽车开发者平台
微信公众号：
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
