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

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