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

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

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

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

圖3：系統復位邏輯圖。

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

　　為實現多任務系統的看門狗監視功能額外增加了TaskMonitor任務，這個任務占用執行時間多少也是一個重要問題。假設TaskMonitor任務一個監視周期延時1.5秒，此外需要執行保存當前計數值，判斷是否“喂狗”等語句，它的CPU占用時間是很小的。用一個具體的試驗證實，使用50M工作頻率的CPU(S3C4510)，移植vxWorks操作系統，cache不使能條件下監視10個任務，每個監視周期占用220~240微秒。可見該任務絕大多數時間都處于任務延時狀態。

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

　　semTake(semID, WAIT_FOREVER); // WAIT_FOREVER為無限時間等待

　　分解為

　　do

　　{

　　ResetWatchDog; // “喂狗”操作

　　}while(semTake(semID, sysClkRateGet( )) != OK); // 1s內的等待信號量操作

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

　　另外需要注意的是系統中是否有的任務優先級比TaskMonitor高并且長時間處于執行狀態，TaskMonitor長時間得不到調度，使得看門狗錯誤復位。良好的任務劃分，配置是不應該出現這種高優先級任務長期執行狀況的。