實時操作系統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]。