实时操作系统CPU使用率监测的软件容错研究

王余伟，曹 东,施书成

(1.南京航空航天大学自动化学院，江苏 南京 211106;2.南京航空航天大学飞行控制研究所，江苏 南京 211106)

1 引言

系统的CPU使用率是实时系统运行正常与否的重要指标，可以表征系统的时间特性和任务状态。在嵌入式系统中，CPU使用异常是经常出现的情况，CPU使用率的异常会使某个任务或者多个任务运行异常，导致系统瘫痪[1]。所以，在设计软件时要把CPU使用率监测任务的等级放在最高，在监测到异常时，必须及时进行处置，消除系统故障或抵消故障带来的影响，提高系统对于时间相关的故障容错能力，保证系统正常运行[2]。

2 CPU使用率的监测

系统在一段时间内，一个任务的CPU使用率是指系统运行该任务所花费时间长度与该段时间长度的比值，计算方法如式(1)所示。

Pcpu=(ttask/ttotal)×100%

(1)

其中，ttotal是统计CPU使用率时间段的时间长度，ttask是在该段时间内，该任务运行所耗费的CPU时间。

2.1 CPU使用率监测周期

在设计嵌入式实时软件中，CPU使用率监测周期选取得是否合理是监测系统的关键，如果CPU使用率监测周期选取过短，则会对系统资源造成浪费；如果CPU使用率监测周期选取过长，则可能无法获取准确的数据。如图1所示,CPU空闲状态以白色的部分表示，CPU正在使用状态以黑色的部分表示。假设CPU的监测周期为0.5 s，在前一个0.5 s内，CPU空闲状态仅为10%，而CPU的使用率则达到了90%；在后一个0.5 s内，CPU空闲状态达到70%，而CPU的使用率仅为30%。两个同等的时间段内CPU的使用情况相差比较大。若以1 s为系统CPU的监测周期，那么CPU的使用率为60%，这样就无法监测出CPU使用异常的情况。所以，为了得到可靠的CPU利用率，系统中正在被监测任务的频率应大于或等于系统中其它任务运行频率的最大值[2]，如式(2)所示。

fmonitor≥max(f1,f2,…,fi,…,fn),i∈[1,n]

(2)

其中，n为系统中任务的个数，fi为系统中各个任务的运行频率。

Figure 1 Impact of CPU utilization ratio monitoring cycles图1 CPU使用率监测周期的影响

2.2 嵌入式操作系统CPU使用率监测方法

μC/OS-II和VxWorks操作系统是比较常用的嵌入式实时操作系统，用户可根据两种操作系统提供的计算CPU使用率的步骤和方法来实现系统CPU使用率的监测。本文重点介绍在μC/OS-II操作系统中CPU使用率的计算原理和步骤。μC/OS-II操作系统被广泛应用于工业器械、医疗设备和网络设备等领域。μC/OS-II操作系统有一个统计时间的任务，叫做OSTaskStat()。如果将系统配置常数OS_TASK_STAT_EN设为1，这个任务就会被建立。一旦得到允许，OSTaskStat()运行1次/秒，计算当前的CPU使用率。具体流程如下：首先，系统中TaskStart()调用统计初始化函数OSStatInit()。统计初始化函数OSStatInit()测定在没有其他应用任务运行时，空闲计数器osidlectr的计算速率。其次，系统统计初始化函数OSStatInit()调用时间延时函数OSTimeDly()，将自身延时2个时钟节拍，以停止自身的运行。然后，系统执行优先级最高的统计任务OSTaskStat()。此时CPU处于空闲任务OSTaskIdle中而osidlectr不停地加1，1 s后，空闲计数器将1 s内计数的值存入空闲计数器最大值osidlectrMax中。而2个时钟节拍后，空闲计数器osidlectr被清0，同时OSTaskStat()开始计算CPU的使用率。这个任务运行的周期是1 s，精确度是1%。计算如式(3)所示：

Pcpu(%)=100-osidlectr/(osidlectrMax/100)

(3)

其中，osidlectr为系统2个时钟节拍内空闲计数器计数的值，osidlectrMax为系统保存的空闲计数器最大值[3]。

3 CPU使用率异常故障诊断算法设计

本文采用的CPU使用率异常故障诊断算法是基于残差的阈值——改进序贯概率比测试SPRT(Sequential Probability Ratio Test)联合算法，该算法能够有效地改进阈值分析法中对小值缓变性故障诊断不够灵敏的缺点，也能有效地改进序贯概率比测试算法(SPRT)中不能实时判决阶跃性故障和对故障诊断时间不能准确判断的缺点[4]。

3.1 阈值分析法

阈值分析法是一种在规定的范围内设定残差阈值的方法。阈值分析法能够快速诊断出超出其阈值范围的大值阶跃性故障，对于超出其阈值范围的小值阶跃性故障则响应缓慢。同时，阈值分析法中合理地设定残差阈值是检测出故障的重要因素，通过系统给出的残差值与设定的残差阈值进行比较，若残差阈值设定过大，系统故障发生时，若阈系统给出的残差值小于设定残差阈值，会造成系统故障诊断不够实时或发生漏检；若残差阈值设定过小，系统故障发生时，若阈系统给出的残差值大于设定残差阈值，会让系统发生错误的判断，造成虚警。

3.2 改进SPRT算法

改进SPRT算法是一种基于概率比假设检验，在给定虚警率和漏检率的情况下，以最短的时间检测出CPU使用率异常故障的方法。

假设由H0和H1分别表示系统运行时的正常状态和发生故障的状态，根据最大后验概率准则可知：

1

(4)

式(4)可以转换为：

1

(5)

其中，P(H0)和P(H1)分别为状态H0和状态H1的先验概率。系统运行时，采集残差的N次值，得到采样序列XN=[x1x2…xN],计算似然比LN(X)：

(6)

从而计算可得对数似然比lnLN(X)：

lnLN-1(X)+lnL(xN)

(7)

从公式中知，当对数似然比lnLN(X)小于T(H1)时，系统处于正常状态。而当系统处于故障状态时对数似然比的值一直变大并且达到或者大于T(H1)。

假设给定虚警率α和漏检率β，由Wald公式可得：

(8)

由式(8)可得：当系统状态正常时，对数似然比逐渐在变小并变成负值，如果此时系统出现故障，对数似然比将逐渐变大，但对数似然比需要经过几步才能增加到判决门限。这种情况严重影响了故障检测的实时性。在此基础上引入补偿环节，在其起作用时可以消除系统运行时带来的延时，同时在系统发生故障的情况下，系统能够更加快速地检测到故障[4]。

3.3 阈值-改进SPRT联合算法

本文通过对比和分析阈值分析法和改进SPRT算法的优缺点，设计出一种阈值-改进SPRT联合算法。该算法不仅结合了上述两种算法各自的优点，而且通过决策手段克服了两种算法各自的缺点。阈值-改进SPRT联合算法示意图如图2所示。

Figure 2 Schematic diagram for threshold-improved SPRT united algorithm图2 阈值-改进SPRT联合算法示意图

该算法将所得残差的值分别输入到阈值分析法和改进SPRT算法，由两种算法分别对输入的残差值进行计算和比较，将阈值分析法和改进SPRT算法分析的结果同时交给故障诊断机进行分析和判决。当对数似然比为负值时，系统中传感器给的残差的值正在变小，可能出现大值阶跃性故障，采用阈值分析法的结果更能够检测出故障结果。当对数似然比为正增量时，系统输出的残差可能出现小值缓变故障，则采用改进SPRT算法检测出结果[5]。

本文将任务运行时占用的CPU使用率曲线的峰值点作为诊断算法中的残差，通过设计的阈值-改进SPRT联合算法给出故障诊断结果。根据故障诊断结果判断出任务的CPU使用率是否异常。

4 CPU使用率异常处置

对于任何一个系统，CPU使用率正常是系统正常运行的重要因素。在嵌入式实时操作系统中，有很多种原因能够造成系统的CPU使用率异常。从硬件层面来说，硬件运行的性能和环境不同，可能造成CPU使用率不同。如果外部电源给硬件供电不足可能直接造成CPU停止工作。从软件层面来说，系统中任务的异常调度或者任务进入无限循环可能直接完全占用CPU，造成很严重的后果[5]。

本文给出两种处置CPU使用率异常的方式：单机CPU自检测和双机CPU互检测。单机CPU自检测处置CPU使用率异常主要是处理关于某个任务CPU使用率的异常，其处置方式有运行备份任务和任务降低运行频率等。这两种方式的处置类型都是被动容错。当系统监测到CPU使用率出现异常时，系统只定位故障的具体位置，不分析故障的具体原因。对故障发生的部分进行异常处置，为了保证系统正常运行，尽量减少或者将故障控制在可控范围之内。

双机CPU互检测的处置方式是利用余度的思想以主从备份的方式实现两个CPU之间的切换。主要思想是：两个相同的硬件平台，假设双机分别标为CPU_A和CPU_B，并且假设CPU_A的优先级高于CPU_B，系统运行时，CPU_A占据主控位置，同时CPU_B也在备份运行，双机之间利用Flexray总线进行数据交叉传输。当CPU_A的CPU使用率异常且根据判决条件需要系统重启才能重新恢复时，系统通过Flexray总线将CPU_A的CPU异常信息传给CPU_B，同时系统将主控权交给CPU_B。这种CPU异常处置方法是主动纠错。当系统监测到CPU使用率出现异常时，系统能够主动分析故障的严重程度，从而进行判决。针对这一方式有两种CPU使用率异常处置方式：异常任务重启和系统重启。当系统中任务或者系统需要重新启动时，为了避免给系统运行带来严重的后果，将CPU使用率异常的硬件作为备份，进行故障恢复，而CPU使用率正常的系统将继续工作运行。

上述四种处置方式能够达到系统所需要的容错目的[6]，如表1所示。

Table 1 CPU utilization ratio exception handling

4.1 运行备份任务

运行备份任务是单机处置CPU使用率异常的一种常用方法。由于每个任务运行时占用系统不同的运行资源，采用运行备份的处置方式可以合理地分配CPU资源。系统中适合创建的备份任务有以下几类：

(1)计算类任务。计算类任务是指需要进行高精度运算和计算量很大的任务。运算精度越高，计算得到的结果越精确，此类任务可用备份任务来代替原有的任务进行计算。如飞行控制系统中计算传感器信息的任务、计算导航信息的任务以及控制律解算的任务等。

(2)功能可精简类任务。嵌入式系统中有很多任务是用来传输大量数据的，在时间一定的前提下，数据量越少，对系统的CPU使用率就越低。此类任务可以对原有的数据或计算等信息进行简化，并且在CPU使用率较高的情况下能够切换到备用任务，使CPU的峰值出现率减少，保证系统运行正常[7]。如在飞行控制系统中传感器的数据传输任务、遥控遥测数据接收和发送任务、执行机构的数据接收和发送任务，以及故障注入的数据接收和发送任务等。

4.2 任务降频运行

在嵌入式系统中，不仅任务的调度周期和任务的调度方式与CPU的使用率有关，任务运行的频率也是占用CPU资源的一个重要因素。某些任务运行的频率越高，其运行效果越好。若系统的CPU资源被这些任务占用得过多，适当地降低频率,降低CPU资源使用率，有助于系统运行。如以下几类任务：

(1)监测类任务。在设计软件时，监测类任务的运行频率一般都很高，若系统出现故障，监测得越快，越能及时发现故障，说明系统运行的效果越好。此类任务对于系统的要求较高，占用CPU资源较多。如在飞行控制系统中，传感器故障监测任务、遥控遥测监测任务以及执行机构监测任务等。

(2)通信类任务。通信类任务一般是与外界的系统进行数据传输，数据量大，通信速度越快，系统运行的效果越好。这类任务更容易加大系统的负担，在设计软件时，在满足系统正常功能的情况下，尽量降低频率，从而降低CPU资源使用率[8]。如飞行控制系统中的遥控遥测通信、传感器数据通信以及Flexray总线数据通信等。

4.3 异常任务重启

异常任务重启是指系统检测到一个或者多个任务运行异常，并且CPU的使用率严重超过了系统能够承受的最大值。这时系统重新将任务初始化，直到所有任务恢复正常。其过程是：系统在任务重启之前首先将系统的状态保存到系统的内存中，然后屏蔽非系统任务，最后将系统的任务重新初始化，重新分配每个任务的堆栈情况，从而使系统任务恢复正常[9]。

上述计算类任务、功能可精简类任务、监测类任务以及通信类任务都可以进行任务异常重启，进而恢复CPU的使用率。

4.4 系统重启

看门狗是实现系统重启的手段之一，其作用也是防止程序“跑飞”。利用看门狗实现系统的重启是比较便捷和有效的。当系统的CPU使用率过高时，在一定时间段内若系统的CPU使用还未恢复正常情况，系统通过软件设定不对看门狗定时进行“喂狗”，系统将自动重新启动，系统重新给任务划分堆栈，程序将重新运行。系统重启后，首先会调用系统重启前保存状态的任务，将之前保存的关键状态从系统的内存中读取出来，保证系统能够接着系统重启前的状态继续运行[10]。

Figure 3 Flow chart of CPU utilization radio exception handling 图3 CPU使用率异常处理流程图

CPU使用率异常处理流程如图3所示。程序运行开始时，主控为CPU_A，从控为CPU_B。根据造成单机CPU使用率异常的情况选取两种不同的CPU处置方式。单机用运行备份模式和任务降频模式进行处置，如若无法有效地降低CPU的使用率，系统将主控变为CPU_B，同时将CPU_A进行任务重启或者系统重启。当CPU_A系统重启后任务运行恢复正常时，主控将重新变为CPU_A，从控变为CPU_B。若系统重启失败，则主控CPU_B继续运行。

在实际工程运用中，系统重启或者任务重启比其它降低系统CPU使用率方法的风险要大得多，一旦系统重启失败，可能会造成严重的后果。本文设计的CPU使用率处置方法加入了余度的思想，使系统运行更加安全、可靠。

5 CPU使用率异常处置的仿真验证

本文在某飞行控制系统环境中进行仿真验证。飞行控制软件是典型的嵌入式软件，实时操作系统是μC/OS-II系统。仿真验证环境包含四个部分：飞行控制系统、仿真系统、遥控遥测系统和故障注入系统。飞行控制系统是由飞行控制计算机和机载飞行控制软件组成；仿真控制系统是由仿真机和仿真软件组成；遥控遥测系统是由遥控遥测计算机和相应的遥控遥测软件组成；故障注入系统是由故障注入界面和相应的故障注入软件组成。其中飞行控制计算机是基于MPC5674开发的嵌入式计算机；飞行控制软件是基于μC/OS-II操作系统开发的软件[2]。飞行控制软件是主要的验证对象，周期调度的任务有20个(最大可建立63个任务)，最小调用的周期任务是10 ms。CPU监测任务作为最高级优先级，选取监测周期为20 ms。由于本文的篇幅有限，仿真仅给出部分验证曲线。仿真系统、遥控遥测系统和故障注入系统作为辅助手段，为验证的信息提供相应的数据，对应的软件均为VC6.0环境下开发的WinForm软件。

5.1 单机CPU使用率异常运行仿真验证

减少CPU使用率曲线中的峰值和繁忙点是单机CPU任务备份和任务降频运行的关键。以传感器数据发送任务为样例任务，通过对数据发送频率的降低和减少数据帧中不需要的数据作为备份模块功能进行仿真验证。同时，为了更具一般性，软件测试中仅有基本任务和传感器发送数据任务。得到的CPU使用率曲线如图4所示。图4中，纵轴为CPU使用率百分比，横轴为时间，单位为ms。

Figure 4 Exception handling of CPU utilization ratio—backup tasks and task frequency down图4 CPU使用率异常处置—备份任务和任务降频

图4所示，实线表示传感器发送的数据帧是每帧39 B，虚线表示将传感器的数据帧降为每帧20 B。通过阈值分析法可知,数据帧长的CPU使用率的峰值超过给定的阈值。根据图2中的故障诊断机制诊断出系统故障的严重程度进行故障处置[8]。

纵向进行比较，在运行备份任务时，CPU使用率的峰值由约2.82%降低到约1.78%，由于系统调度任务时是将任务从睡眠态转至运行状态，会消耗系统的CPU资源，其消耗约为0.6%。在调用了备份任务后CPU的使用率峰值降低了1.04%，最多减少了约49%。从横向比较，在降低任务运行频率后，系统峰值出现的次数减少了一倍。由仿真结果可知，系统的备份任务和降低任务运行频率能够有效降低任务对CPU资源的占用率。备份模块保留的功能越少，对降低CPU使用率的峰值效果越好。任务的频率下降得越多，对降低CPU使用率的峰值效果越好。

5.2 异常任务重启仿真验证

以飞行控制软件为例，飞行控制软件需要多任务协调运行。并且μC/OS-II实时操作系统是基于任务抢占优先级的方式运行的,任务进入死循环是常见的错误，该错误明显的标志是CPU使用率较高。异常任务的重启是有效处理这一问题的方法之一。仿真过程中，通过故障注入软件向飞行控制软件中注入任务无限循环指令，当飞行控制软件响应这一指令时，CPU的使用率在t=400 ms时发生突变,此时飞行控制系统响应故障处置逻辑将任务重新启动，此时主CPU的主控权切换给从CPU。

从图5中可知，针对系统的某一个任务进行仿真验证，在时间t=400 ms时注入任务异常的故障指令，在时间t从400 ms 到1 200 ms，CPU使用率峰值超过20%的监测点有15个，根据CPU使用率的判决条件得出该任务运行异常，严重占用了CPU资源，系统响应故障处置，进行任务重新启动，从而使任务运行恢复正常，这种方法能够使系统恢复正常[11]。

Figure 5 Exception handling of CPU utilization ratio-exception task restart图5 CPU使用率异常处置-异常任务重启

5.3 系统重启仿真验证

系统重启是指多个任务出现异常运行情况，系统进行重新启动。其故障注入的方法与单个任务异常重启相同。仿真过程中，通过故障注入软件向飞行控制软件中注入任务无限循环指令，当飞行控制软件响应这一指令时，CPU的使用率在t=400 ms时发生突变,此时飞行控制系统响应故障处置逻辑，将任务重新启动,双机主控CPU将会切换为从控CPU。

从图6可知，针对系统的多个任务进行仿真验证，在时间t=400 ms时注入任务异常的故障指令，在时间t从400 ms 到1 200 ms，CPU使用率峰值超过20%的监测点有15个，根据CPU使用率的判决条件得出系统运行异常，严重占用了CPU资源，系统响应故障处置，进行系统重新启动，从而使任务运行恢复正常，这种方法能够使系统恢复正常。

Figure 6 Exception handling of CPU utilization ratio-system restart图6 CPU使用率异常处置-系统重启

6 结束语

本文结合嵌入式系统CPU使用率的特点，在能够合理监测系统运行状态的情况下，提出双机切换处置系统CPU使用率异常的方法。这种方法在保证系统正常运行的情况下，根据引发CPU异常的原因不同，能够有效地降低CPU的使用率，提高系统的容错能力，对于保证嵌入式系统的正常运行有着重要的作用[12]。