一種多任務(wù)RTOS看門狗框架的設(shè)計①

董 昀, 李 穗

(安徽文達信息工程學(xué)院電子電氣工程學(xué)院,安徽 合肥 230039)

0 引 言

嵌入式多任務(wù)實時操作系統(tǒng)如今廣泛的應(yīng)用在各個領(lǐng)域,系統(tǒng)的穩(wěn)定性和可靠性始終是最為重要的問題之一,特別在一些條件比較惡劣,電磁干擾嚴重的場合,常會出現(xiàn)系統(tǒng)死機或程序跑飛現(xiàn)象。多年來,圍繞著提高嵌入式系統(tǒng)的抗干擾能力,以及系統(tǒng)受到干擾后如何恢復(fù),在硬件和軟件方面都提出了很多有效的方法,其中比較常用就是看門狗技術(shù)[1]?？撮T狗分為硬件看門狗和軟件看門狗:硬件看門狗通常指的是集成在處理器內(nèi)部的看門狗定時器或外置的專用看門狗芯片或電路;軟件看門狗和硬件看門狗類似,不過它采用處理器內(nèi)部的定時器,無需額外的硬件電路。典型的看門狗應(yīng)用就是將看門狗芯片的復(fù)位信號輸出引腳接到處理器的復(fù)位引腳,當處理器正常運行時系統(tǒng)會周期性地執(zhí)行“喂狗”操作,將看門狗計數(shù)器定期清零,一旦系統(tǒng)出現(xiàn)故障,程序跑飛,“喂狗”操作長時間未得到執(zhí)行,看門狗計數(shù)器將會溢出,導(dǎo)致系統(tǒng)重啟[2]。這種方法每次只能監(jiān)測到系統(tǒng)的一部分,即主進程,因此在單任務(wù)系統(tǒng)中得到了廣泛應(yīng)用[3]。然而現(xiàn)在的嵌入式系統(tǒng)功能越來越復(fù)雜,往往需要采用多任務(wù)的嵌入式操作系統(tǒng)進行開發(fā)。這種情況下,僅對主進程進行監(jiān)控對提高嵌入式產(chǎn)品的穩(wěn)定性來說收效甚微。文中提出了一種基于多任務(wù)實時操作系統(tǒng)的看門狗框架,可以根據(jù)用戶的實際情況,對系統(tǒng)中任意任務(wù)進行靈活的監(jiān)控,保障了系統(tǒng)運行的穩(wěn)定可靠。

1 相關(guān)研究

多任務(wù)環(huán)境下的看門狗監(jiān)測問題葉幫利在Windows系統(tǒng)中已經(jīng)進行了探索和嘗試[4],初步提出了多進程軟件看門狗的設(shè)計思路。戴積發(fā)、胡玉霞等人在嵌入式系統(tǒng)中也提出了類似的解決方案[5],他們設(shè)計的看門狗主要實現(xiàn)以下功能:(1)當某個任務(wù)出現(xiàn)異常時重啟該任務(wù);(2)多次重啟某一個任務(wù)失敗或者所有的任務(wù)均出現(xiàn)異常時,重啟系統(tǒng);(3)當操作系統(tǒng)本身或硬件電路出現(xiàn)異常時,由軟件看門狗或硬件看門狗重啟處理器[4-5]。Abaffy等人針對Linux操作系統(tǒng)提出了一種多硬件看門狗的框架[6]。包明磊、姚艷松在FPGA平臺上也提出了多任務(wù)硬件看門狗的容錯技術(shù)[7]。上述工作在一定程度上為多任務(wù)環(huán)境下的看門狗應(yīng)用提供了方案。但在實際應(yīng)用中,系統(tǒng)中運行的各個任務(wù)重要性未必相同,某些任務(wù)出現(xiàn)異常后可能經(jīng)過適當?shù)募m錯處理重新恢復(fù)運行,或者即使無法正常運行,對整個系統(tǒng)也不會帶來不可接受的后果;這樣的情況就無需重啟系統(tǒng)。此外,某些系統(tǒng)可能有更復(fù)雜的應(yīng)用場景,比如要求只有在任務(wù)1和任務(wù)2都發(fā)生異常時才必須重啟,或者任務(wù)喂狗過于頻繁也意味著某種異常。

文中針對上述問題提出了一種新的多任務(wù)環(huán)境下看門狗框架,即用戶可以根據(jù)需求自定義異常處理函數(shù)和關(guān)聯(lián)規(guī)則來決定系統(tǒng)在任務(wù)發(fā)生異常時如何處理異常,并決定在什么情況下需要重新啟動系統(tǒng)。

2 多任務(wù)環(huán)境看門狗框架

文中結(jié)合了軟件看門狗和硬件看門狗技術(shù)的優(yōu)勢[8],針對多任務(wù)操作系統(tǒng)環(huán)境下的看門狗應(yīng)用提出了一種靈活的框架。其中利用軟件看門狗對系統(tǒng)中運行的任務(wù)進行監(jiān)控,而硬件看門狗則用于對軟件看門狗本身進行監(jiān)控,有效的保障了系統(tǒng)的可靠性。

用戶可以為想要監(jiān)控的每一個任務(wù)(進程)創(chuàng)建一個軟件看門狗,指定超期時間和最小喂狗間隔,以及關(guān)聯(lián)規(guī)則,同時用戶可以自定義任務(wù)異常處理例程。所有的軟件看門狗通過適當?shù)姆绞竭M行管理,如鏈表或者隊列。此外,系統(tǒng)在啟動階段創(chuàng)建一個優(yōu)先級最高的任務(wù)作為軟件看門狗管理器。每個被監(jiān)測的任務(wù)在設(shè)定的超期時間和最小喂狗時間間隔范圍內(nèi)對其相應(yīng)的軟件看門狗清零,即“喂軟件狗”。

系統(tǒng)節(jié)拍定時器中斷處理函數(shù)周期性的檢查每個軟件看門狗是否超時[9],以及是否喂狗過于頻繁。如果任務(wù)由于異常導(dǎo)致未能正常喂軟件狗,系統(tǒng)節(jié)拍定時器中斷處理函數(shù)將調(diào)用對應(yīng)的異常處理例程進行處理,如果異常成功的得到處理,則跳過該軟件看門狗,如果異常沒有得到解決,中斷處理函數(shù)記錄下該軟件看門狗監(jiān)控的任務(wù)發(fā)生了不可修復(fù)的異常。在檢查完所有的軟件看門狗的狀態(tài)后,如果有不可修復(fù)的異常,中斷處理函數(shù)喚醒軟件看門狗管理器任務(wù)。

正常情況下,軟件看門狗管理器周期性的對硬件看門狗進行喂狗,即“喂硬件狗”,防止硬件看門狗超時導(dǎo)致系統(tǒng)復(fù)位。但是如果被監(jiān)控的任務(wù)發(fā)生不可修復(fù)的異常,系統(tǒng)節(jié)拍定時器中斷服務(wù)程序?qū)拘衍浖撮T狗管理器檢查異常任務(wù)的軟件看門狗關(guān)聯(lián)規(guī)則,如果滿足關(guān)聯(lián)規(guī)則,則停止喂硬件狗,重啟系統(tǒng)。另外當管理器任務(wù)本身出現(xiàn)錯誤時,也不能及時“喂硬件狗”,系統(tǒng)也將重啟。具體的監(jiān)控原理框圖如圖1所示:

3 多任務(wù)軟件看門狗管理器的實現(xiàn)

為驗證設(shè)計的框架,作者以RT-Thread操作系統(tǒng)和STM32F103開發(fā)板為平臺實現(xiàn)了一個原型系統(tǒng)。在實現(xiàn)中軟件看門狗定義如下:

struct {

int due_time; //看門狗到期時間

int last_feed, current_feed; //上次和本次喂狗時間

int (*Handle)(void *arg); //任務(wù)異常處理函數(shù)

void *data;//傳遞給異常處理函數(shù)的參數(shù)

list_head list; //用于將所有軟件看門狗連 接為一個雙向循環(huán)鏈表

int min_interval;//看門狗最小喂狗間隔

int mask;//關(guān)聯(lián)規(guī)則

int watchdog_id; //軟件看門狗編號

}soft_watchdog;

int map;//全局標志位

圖1 監(jiān)控原理框圖

其中map是一個全局變量標示所有軟件看門狗的狀態(tài),它的每一個位對應(yīng)一個軟件看門狗的狀態(tài),若該軟件看門狗監(jiān)控的任務(wù)發(fā)生不可修復(fù)的異常,則將其對應(yīng)位標識為1,否則標識為0。mask是一個由用戶自定義的關(guān)聯(lián)規(guī)則,比如mask=5,其二進制數(shù)第1位和第3位為1,其他位為0,這表示軟件看門狗1和軟件看門狗3是關(guān)聯(lián)的,即都處于觸發(fā)狀態(tài),也就是說任務(wù)1和任務(wù)3均出現(xiàn)不可修復(fù)異常時,軟件看門狗管理器將重啟系統(tǒng)。due_time與min_interval是到期時間和最小喂狗間隔,如果min_interval為0則表示對喂狗頻率沒有限制。handle即為自定義的異常處理例程,用戶可以根據(jù)實際情況進行可能的異常檢測、處理、修復(fù)等操作,如果成功處理異常,該函數(shù)返回0,否則返回-1。所有這些軟件看門狗通過類型為list_head的成員變量list連接成雙向循環(huán)鏈表,如圖2所示。list_head的定義如下:

struct list_head {

struct list_head *next, *prev;

} ;

軟件看門狗管理器由watchdog_daemon()實現(xiàn),該任務(wù)周期性的休眠指定的時間間隔timeout,該時間應(yīng)小于硬件看門狗溢出間隔。當管理器被喚醒運行時首先檢查喚醒原因:如果是因為timeout時間超時,則喂硬件狗,再次休眠等待下一次喚醒;如果喚醒的原因是系統(tǒng)節(jié)拍定時器中斷處理函數(shù)檢測到有軟件看門狗被觸發(fā),則進行異常處理。

軟件看門狗管理器檢查map標志的每一位,如果該位為1,則表示對應(yīng)的軟件看門狗被觸發(fā)。管理器獲取被觸發(fā)軟件看門狗的mask關(guān)聯(lián)規(guī)則,與map進行比較。如果規(guī)則指定的關(guān)聯(lián)軟件看門狗均被觸發(fā),那么我們稱關(guān)聯(lián)規(guī)則被觸發(fā),此時,管理器不再喂硬件狗,觸發(fā)系統(tǒng)復(fù)位。管理器的執(zhí)行流程如圖3所示。

圖2 軟件看門狗鏈表結(jié)構(gòu)

圖3 管理器執(zhí)行流程圖

每個被監(jiān)控任務(wù)需要周期性的喂軟件狗,其喂狗間隔必須小于到期時間due_time,且大于最小喂狗間隔min_interval,軟件看門狗數(shù)據(jù)結(jié)構(gòu)中的current_feed和last_feed分別記錄本次和上次喂狗的時間。系統(tǒng)節(jié)拍定時器中斷處理函數(shù)依次檢查每個軟件看門狗監(jiān)控的任務(wù)是否異常。方法是:如果當前時間與current_feed的差大于due_time,則軟件看門狗溢出;同樣,如果current_feed與last_feed的差小于min_interval則說明喂狗過于頻繁。這兩種情況下,中斷處理函數(shù)均調(diào)用對應(yīng)的異常處理例程handler。該例程是用戶自定義的,用于對發(fā)生異常的任務(wù)進行處理,包括檢查具體異常原因,生成異常日志,嘗試修復(fù)異常,或者重啟任務(wù)等。如果handler成功解決了異常,則返回0,否則返回-1。在返回-1的情況下,系統(tǒng)認為該任務(wù)發(fā)生了不可修復(fù)的錯誤,設(shè)置map標志對應(yīng)位為1,稱之為觸發(fā)軟件看門狗。中斷處理函數(shù)在檢查完所有的軟件看門狗后,如果有任何看門狗被觸發(fā),則喚醒軟件看門狗管理器任務(wù)。系統(tǒng)節(jié)拍中斷處理函數(shù)的執(zhí)行流程如圖4所示。

圖4 系統(tǒng)節(jié)拍中斷服務(wù)程序流程圖

4 結(jié) 論

提出了一種新的多任務(wù)RTOS環(huán)境下軟硬件看門狗框架,論述了工作原理,并在RT-Thread實時操作系統(tǒng)上實現(xiàn)了該框架。該框架提供了一種靈活的高度可定制的多任務(wù)管理的軟硬件看門狗結(jié)合方案,與傳統(tǒng)的硬件看門狗和多任務(wù)看門狗技術(shù)相比具有如下優(yōu)勢:

1)利用軟件看門狗可監(jiān)控系統(tǒng)任意任務(wù)(一個,多個或全部),實現(xiàn)成本低;

2)監(jiān)控方案配置靈活,可方便添加待監(jiān)控的任務(wù),理論上該任務(wù)數(shù)量沒有上限,管理器可對出現(xiàn)異常的任務(wù)調(diào)用自定義的處理例程進行處理,這樣可以對某些不嚴重問題進行修復(fù),而無需重啟任務(wù)或系統(tǒng)。

3)用戶可以自定義關(guān)聯(lián)規(guī)則,管理器分析當前異常情況,在滿足用戶設(shè)定的關(guān)聯(lián)規(guī)則時才重啟系統(tǒng)。