Watchdog 是時間保護不是延遲開關
Watchdog 觸發表示任務的時間行為超出平台允許範圍，但原因可能不同：任務已開始卻執行太久，或任務根本沒有在期限內開始。兩者的排查方向不同。CODESYS Task 文件把一般 watchdog 描述為任務執行時間超過設定值，也另外說明 Omitted Cycle watchdog 用來處理任務沒有開始執行的情況。不要只看到超時就把時間放寬。
本文用一個合成任務案例：週期 10 ms，正常執行約 2 ms。案例A在隔離測試中加入昂貴排序，執行時間升到14毫秒；案例B是另一條獨立時間線，描述高優先任務長時間占用CPU時低優先任務沒有開始的情況。不可把A故障後的下一個掃描當成B仍會自然運行。兩者都可能在畫面上被簡化成『Watchdog error』，但需要用任務監看、優先級、週期與程式段證據分類。
| 類型 | 關鍵問題 | 第一份證據 |
|---|---|---|
| 執行超時 | 任務是否已開始並跑太久 | 執行時間與程式段 |
| 遺漏週期 | 期限內是否根本沒開始 | 排程、優先級與啟動紀錄 |
| 連續超時 | 是否多周期累積 | 敏感度與連續次數 |
| 外部原因 | 是否由系統或 I/O 等待造成 | 平台診斷與資源負載 |
CODESYS 文件指出 watchdog 可有 Time 與 Sensitivity，某些設定以週期百分比表示；預設範圍依裝置而異。這些數字不是 Q 系列或其他平台的通用值。先取得目標 CPU 的設定與例外行為，再決定驗收條件。
先保存超時前後的時間線
記錄 CPU、工程軟體、任務名稱、週期、優先級、watchdog time 與 sensitivity。
確認錯誤發生時是單次、連續多次，或任務完全沒有執行。
保存程式版本、最近變更、輸入條件與同時運行的其他任務。
以合成負載在測試環境重現，不在正式設備上盲目增加負載。
將修正前後的最大、平均與抖動分開比較。
不要把系統時間戳當成任務執行時間。任務啟動與完成最好有同一時基的計數或平台監看值；若只拿 HMI 顯示時間，畫面刷新會掩蓋短暫超時。案例紀錄也應包括錯誤前最後一次成功週期，因為它能提示負載是逐步增加還是突然出現。
| 獨立案例與紀錄 | 執行時間 | 高優先任務 | 結果 |
|---|---|---|---|
| A101 | 2.1 ms | 未占用 | 正常 |
| A102 | 2.3 ms | 未占用 | 正常 |
| A103 | 14.0 ms | 未占用 | 執行超時候選 |
| B1 | 無資料 | 持續占用 | 遺漏週期候選 |
如果錯誤後輸出被重置，這可能是平台設定的結果，不是程式主動把輸出關掉。CODESYS 文件提到啟用 PLC Settings 的 Update I/Os 時，錯誤後可能將輸出重設為定義的預設值；目標系統是否如此要查自己的文件。報告必須把平台行為和應用邏輯分開。
案例A與B分別由相同正常基線開始。A的最後一筆完成耗時可能因watchdog提前中止而無法取得，表列14毫秒代表離線假設負載，不是故障後一定能讀到的完成紀錄。B應另記未開始的持續時間，不能只憑單筆無資料判定遺漏週期。
辨別執行太久與根本沒開始
第一個判斷是找任務開始標記。若開始標記有更新但完成標記很晚或沒有更新，偏向執行超時或程式卡在某段。若開始標記長時間不變，而其他高優先任務仍在跑，偏向遺漏週期、優先級競爭或排程資源問題。標記本身也要放在安全且可觀察的位置，不能在初始化失敗時就被誤解。
CODESYS 任務文件說明優先級 0 為最高，單核心上高優先任務可能中斷低優先任務；同優先任務可用 round-robin。多核心還涉及核心綁定與作業系統。這表示『把週期改小』可能讓情況更糟，『把優先級調高』也可能壓住其他必要工作。任何改動都要有負載和功能回歸測試。
在測試版加入開始、完成與錯誤序號，並限制記錄量。
分別注入單次長計算和高優先任務占用，形成兩組基準。
比較任務開始序號、完成序號、執行時間與 watchdog 計數。
檢查同核心任務、程式呼叫順序和 I/O 更新時機。
恢復原始設定，確認診斷程式不改變正式控制行為。
| 觀察組合 | 較合理分類 | 仍需確認 |
|---|---|---|
| 開始+，完成延遲 | 執行超時 | 卡住的程式段 |
| 開始不變，其他任務忙 | 遺漏週期候選 | 優先級與核心 |
| 單次錯誤後恢復 | 單次超時 | 敏感度設定 |
| 每次都未開始 | 排程或啟動問題 | 任務使能與系統狀態 |
找出真正的負載來源
執行超時的常見候選包括大型迴圈、排序、字串處理、檔案或通訊等待、一次複製大量陣列，以及多個程式在同一任務內連續呼叫。不要一看到某個函式就宣稱它是根因；先以分段計時或平台分析工具確認。量測工具本身也可能增加負載，應用少量標記和短測試窗。
把單次尖峰和長期平均分開。平均 2 ms 不代表不會偶爾出現 20 ms；watchdog 可能正是被尖峰觸發。以固定輸入重播最壞路徑，例如最大陣列長度、最長字串和所有設備同時回覆。若無法取得真實最壞資料，報告要標記假設，不用正常資料推導保證。
| 程式段 | 正常 | 最壞測試 | 處置方向 |
|---|---|---|---|
| 輸入整理 | 0.2 ms | 0.4 ms | 保留 |
| 排序 | 0.8 ms | 9.5 ms | 分批或改演算法 |
| 通訊解析 | 0.6 ms | 3.1 ms | 限制長度與等待 |
| 報表統計 | 0.4 ms | 6.0 ms | 移至低頻任務 |
將工作拆到不同任務不是自動安全解法。資料交換會引入一致性、優先級與更新時序問題；還要確認總負載沒有只是從一個任務移到另一個任務。若平台支援週期任務、事件任務或狀態任務，依官方語意選擇，並檢查短事件是否可能漏掉。
為什麼不應單純放寬 watchdog
把 watchdog time 調大會降低誤觸發，但同時延後發現任務卡住或排程失效的時間。若原本 10 ms 任務偶爾跑到 40 ms，直接改成 100 ms 只是掩蓋負載問題，也可能讓資料更新和現場反應變慢。正確順序是先保存證據、降低或分散負載、確認週期需求，再依平台允許的範圍設定監控。
若初始化確實需要較長時間，先拆解為可觀察的階段，記錄進度、等待上限及完成前禁止接受的工作。任何例外監控策略都需要目標平台明確支援，並驗證恢復監控的生命週期；本文不提供停用watchdog的操作步驟。
先重現並取得最壞執行時間，不先調高門檻。
找出造成尖峰的程式段，限制資料量或改為分段處理。
若必須重排任務，檢查共享資料與 I/O 更新的一致性。
依設備文件設定合理 watchdog 與 sensitivity，記錄理由。
以正常、最壞與故障注入三組測試驗證仍能被偵測。
驗收應同時包含『不該觸發時不誤觸發』與『真的卡住時要觸發』。只跑正常流程只能證明沒有立刻報錯，不能證明保護還有效。案例中的長計算只有在超過實際Time與Sensitivity規則時才應觸發；優先任務占用也需滿足目標平台的遺漏週期門檻才會診斷，並留下平台對輸出的處理結果。
驗收 交接與常見問題
| 驗收項 | 通過條件 | 證據 |
|---|---|---|
| 分類 | 執行超時與遺漏週期分開 | 開始/完成序號 |
| 負載 | 最壞路徑低於合理門檻 | 分段時間表 |
| 監控 | 真正卡住仍被偵測 | 故障注入紀錄 |
| 恢復 | 錯誤後狀態符合平台規格 | CPU/輸出診斷 |
| 交接 | 設定與版本可回查 | 專案與報告 |
問：Watchdog 一直觸發，先把值加大可以嗎？不應作為第一步，先判別任務超時或遺漏週期並找負載。問：錯誤後輸出一定會關閉嗎？不一定，要查目標系統與 I/O 設定。問：高優先級就能解決遺漏週期嗎？可能壓住其他任務，必須量測整體影響。問：初始化能不能永久停用 watchdog？這會失去重要診斷，只有平台明確支援且有邊界的特定情境才討論。
適用型號與限制：本文引用 CODESYS Task 的任務、優先級、週期、sensitivity 與 Omitted Cycle 概念作為診斷框架；沒有把它們宣稱為 Q 系列 CPU 或 GX Works 的同名設定。正式工程須核對目標 CPU 的 watchdog 類型、例外處理、輸出狀態與任務排程；所有程式片段僅為教學邏輯。