英創(chuàng)信息技術多任務系統(tǒng)看門狗的實現(xiàn)

看門狗分硬件看門狗和軟件看門狗。硬件看門狗是利用一個定時器電路，其定時輸出連接到電路的復位端，程序在一定時間范圍內(nèi)對定時器清零（俗稱“喂狗”），因此程序正常工作時，定時器總不能溢出，也就不能產(chǎn)生復位信號。如果程序出現(xiàn)故障，不在定時周期內(nèi)復位看門狗，就使得看門狗定時器溢出產(chǎn)生復位信號并重啟系統(tǒng)。軟件看門狗原理上一樣，只是將硬件電路上的定時器用處理器的內(nèi)部定時器代替，這樣可以簡化硬件電路設計，但在可靠性方面不如硬件定時器，比如系統(tǒng)內(nèi)部定時器自身發(fā)生故障就無法檢測到。當然也有通過雙定時器相互監(jiān)視，這不僅加大系統(tǒng)開銷，也不能解決全部問題，比如中斷系統(tǒng)故障導致定時器中斷失效。

看門狗本身不是用來解決系統(tǒng)出現(xiàn)的問題，在調(diào)試過程中發(fā)現(xiàn)的故障應該要查改設計本身的錯誤。加入看門狗目的是對一些程序潛在錯誤和惡劣環(huán)境干擾等因素導致系統(tǒng)死機而在無人干預情況下自動恢復系統(tǒng)正常工作狀態(tài)。看門狗也不能完全避免故障造成的損失，畢竟從發(fā)現(xiàn)故障到系統(tǒng)復位恢復正常這段時間內(nèi)怠工。同時一些系統(tǒng)也需要復位前保護現(xiàn)場數(shù)據(jù)，重啟后恢復現(xiàn)場數(shù)據(jù)，這可能也需要一筆軟硬件的開銷。

圖1：（a） 多任務系統(tǒng)看門狗示意圖 ；（b） 相應的看門狗復位邏輯圖

在單任務系統(tǒng)中看門狗工作原理如上所述，容易實現(xiàn)。在多任務系統(tǒng)中情況稍為復雜。假如每個任務都像單任務系統(tǒng)那么做，如圖1（a）所示，只要有一個任務正常工作并定期“喂狗”，看門狗定時器就不會溢出。除非所有的任務都故障，才能使得看門狗定時器溢出而復位，如圖1（b）。

而往往我們需要的是只要有一個任務故障，系統(tǒng)就要求復位。或者選擇幾個關鍵的任務接受監(jiān)視，只要一個任務出問題系統(tǒng)就要求復位，如圖2（a）所示，相應的看門狗復位邏輯如圖2（b）所示。

在多任務系統(tǒng)中通過創(chuàng)建一個監(jiān)視任務TaskMonitor，它的優(yōu)先級高于被監(jiān)視的任務群Task1、Task2.。.Taskn。TaskMonitor在Task1~Taskn正常工作情況下，一定時間內(nèi)對硬件看門狗定時器清零。如果被監(jiān)視任務群有一個Task_x出現(xiàn)故障，TaskMonitor就不對看門狗定時器清零，也就達到被監(jiān)視任務出現(xiàn)故障時系統(tǒng)自動重啟的目的。另外任務TaskMonitor自身出故障時，也不能及時對看門狗定時器清零，看門狗也能自動復位重啟。接下來需要解決一個問題是：監(jiān)視任務如何有效監(jiān)視被監(jiān)視的任務群。

圖2：（a） 多任務系統(tǒng)看門狗示意圖；（b） 正確的看門狗復位邏輯圖

在TaskMonitor中定義一組結構體來模擬看門狗定時器組

typedef struct

{

UINT32 CurCnt， LastCnt;

BOOL RunState;

int taskID;

} STRUCT_WATCH_DOG;

該結構體包括被監(jiān)視的任務號taskID，用來模擬“喂狗”的變量CurCnt、LastCnt（具體含義見下文），看門狗狀態(tài)標志RunState用來控制當前任務是否接受監(jiān)視。

被監(jiān)視的任務Task1~Taskn調(diào)用自定義函數(shù)CreateWatchDog（int taskid）來創(chuàng)建看門狗，被監(jiān)視任務一段時間內(nèi)要求“喂狗”，調(diào)用ResetWatchDog（int taskid），這個“喂狗”動作實質(zhì)就是對看門狗定時器結構體中的變量CurCnt加1操作。TaskMonitor大部分時間處于延時狀態(tài)，假設硬件看門狗定時是2秒，監(jiān)視任務可以延時1.5秒，接著對創(chuàng)建的看門狗定時器組一一檢驗，延時前保存CurCnt的當前值到LastCnt，延時后比較CurCnt與LastCnt是否相等，都不相等系統(tǒng)才是正常的。需要注意的是CurCnt和LastCnt數(shù)據(jù)字節(jié)數(shù)太小，而“喂狗”過于頻繁，可能出現(xiàn)CurCnt加1操作達到一個循環(huán)而與LastCnt相等。

如果有任意一組的CurCnt等于LastCnt，認為對應接受監(jiān)視的任務沒有“喂狗”動作，也就檢測到該任務出現(xiàn)故障需要重啟，這時候TaskMonitor不對硬件看門狗定時器清零，或者延時很長的時間，比如10秒，足以使得系統(tǒng)重啟。反之，系統(tǒng)正常，Task1~Taskn定期對TaskMonitor“喂狗”，TaskMonitor又定期對硬件看門狗“喂狗”，系統(tǒng)就得不到復位。還有一點，被監(jiān)視任務可以通過調(diào)用PauseWatchDog（int taskid）來取消對應的看門狗，實際上就是對STRUCT_WATCH_DOG結構體中的RunState操作，該標志體現(xiàn)看門狗有效與否。

這種方式可監(jiān)視的最大任務數(shù)由STRUCT_WATCH_DOG結構數(shù)據(jù)的個數(shù)決定。程序中應該有一個變量記錄當前已創(chuàng)建的看門狗數(shù)，判斷被監(jiān)視任務Task1~Taskn是否“喂狗”只需比較CurCnt與LastCnt的值n次。

圖3：系統(tǒng)復位邏輯圖

硬件看門狗監(jiān)視TaskMonitor任務，TaskMonitor任務又監(jiān)視其他的被監(jiān)視任務Task1~Taskn，形成這樣一種鏈條。這種方式系統(tǒng)的故障圖表示如圖3所示。被監(jiān)視任務Task1~Taskn及TaskMonitor都是或的關系，因此被監(jiān)視的任一任務發(fā)生故障，硬件電路看門狗就能復位。

為實現(xiàn)多任務系統(tǒng)的看門狗監(jiān)視功能額外增加了TaskMonitor任務，這個任務占用執(zhí)行時間多少也是一個重要問題。假設TaskMonitor任務一個監(jiān)視周期延時1.5秒，此外需要執(zhí)行保存當前計數(shù)值，判斷是否“喂狗”等語句，它的CPU占用時間是很小的。用一個具體的試驗證實，使用50M工作頻率的CPU（S3C4510），移植vxWorks操作系統(tǒng)，cache不使能條件下監(jiān)視10個任務，每個監(jiān)視周期占用220~240微秒?？梢娫撊蝿战^大多數(shù)時間都處于任務延時狀態(tài)。

被監(jiān)視任務可能有獲取消息、等待一個信號量等的語句，往往這個消息、信號量的等待是無限期的等待。這就需要將這類語句作一些修改。比如在vxWorks中將一次無期限的獲取信號量操作。

semTake（semID， WAIT_FOREVER）; // WAIT_FOREVER為無限時間等待

分解為

do

{

ResetWatchDog; // “喂狗”操作

}while（semTake（semID， sysClkRateGet（ ）） ！= OK）; // 1s內(nèi)的等待信號量操作

多次的時間范圍內(nèi)的獲取信號量操作，這樣才能保證及時“喂狗”。

另外需要注意的是系統(tǒng)中是否有的任務優(yōu)先級比TaskMonitor高并且長時間處于執(zhí)行狀態(tài)，TaskMonitor長時間得不到調(diào)度，使得看門狗錯誤復位。良好的任務劃分，配置是不應該出現(xiàn)這種高優(yōu)先級任務長期執(zhí)行狀況的。