多個故障同時出現時如何保留第一個線索

先保留線索再談根因

多個故障同時出現時，第一個收到的訊息不一定是第一個發生的事件。保存第一個線索的目的，是保留可重算的原始資料與候選關係，不是替尚未證明的電源、網路或製程故障下定論。每筆事件要同時記錄source time、received time、來源識別、品質、序號與採集器時鐘。

先不要改寫raw時間。另建normalized欄位，說明使用的時區、已知偏差與估計窗口；若沒有偏差資料，就把窗口標為未知。收到時間可用來安排調查順序，不能直接代替來源時間。來源時間說「事件在來源看來何時發生」，收到時間只說「採集器何時看見它」。

同一可靠時鐘的案例可先作局部排序：A電源異常source 10:00:00.100、收到10:00:00.700；B通訊source .300、收到.400；C製程Hold source .500、收到.600。收到順序是B、C、A，但來源順序是A、B、C，因此第一個收到B不代表B是根因。共同電源只能列為候選，還要找獨立證據。

報告開頭應先寫事件邊界，例如「分析10:00:00.000至10:00:02.000，僅使用保存的來源訊息與CPU診斷；未讀取現場波形，故不判定電氣因果」。這一句界定調查能回答什麼，也避免後續讀者把候選圖當成已證實故障樹。

QnUCPU手冊的錯誤歷史與GX Works2的PLC Diagnostics可協助讀取控制器事件，但畫面顯示的歷史仍受保存容量、取樣時機、時鐘與資料來源限制。這篇只建立證據方法，不假稱某個診斷畫面必然含有所有外部設備事件。

適用限制包括：GX Works2的診斷畫面與QnUCPU錯誤歷史不會自動補齊外部設備資料；不同型號、參數、韌體與資料保存配置可能改變可見欄位。若來源時鐘、接收時鐘或序號規則未核實，所有跨來源的精確先後都只能算推測。

同一可靠時鐘的排序

先確認三個來源是否使用同一可靠時鐘。若PLC、通訊閘道與製程採集器都由同一校時來源同步，且誤差已小於10毫秒，便可在這個已知精度內比較source time。即使如此，事件同時或接近時仍應保留誤差，不把0.1毫秒的差異寫成絕對因果。

本例A、B、C來源時間為100、300、500毫秒，收到時間為700、400、600毫秒。在來源與接收共用同一已核對基準的假設下，延遲分別為600、100、100毫秒。這解釋為何B先收到而A先發生，但不能僅由時間差證明電源事件A造成通訊事件B。

下一步不是把A標成根因，而是為A、B、C各找一個獨立證據。A可查電源監視器或模組電壓記錄，B可查網路設備和站端連線，C可查順序程式步驟與回饋。若A沒有電壓證據，仍可保留A為來源自報事件，但根因欄必須寫Unknown。

同源序號可以協助判斷遺失和重複，例如同一CPU的事件序號100、101、103表示102可能遺失或被覆蓋；序號只能在同一來源內排序，不能拿CPU序號101和閘道序號55比較先後。跨來源排序仍要靠共同時鐘、收到時間與獨立參考事件。

驗收一條事件鏈時，至少要能回答四件事：第一個線索是哪一筆原始資料、它的來源時間和收到時間各是多少、哪個結論仍是候選、下一份證據由誰在何時取得。若其中一項沒有資料，結論應保留缺口，而不是以「已查明」結尾。

時鐘偏差與不確定窗口

第二個案例中，A來源時間為10:00:00.100，B為10:00:00.300，但兩台來源的時鐘偏差各可能達±200毫秒。A的實際窗口是[-0.100,0.300]相對於10:00:00，B的窗口是[0.100,0.500]；兩個窗口在0.100至0.300重疊，不能定先後。

窗口重疊時，報告應寫「A與B時間相容，順序未定」，而不是依顯示的小數位決定。可再查校時紀錄、同一外部觸發器或具有單調計數的採集器；如果沒有新增證據，這個不確定性要保留到結論。

收到時間也要帶誤差。若採集器可能排隊150毫秒，收到10:00:00.400的B只能表示它在這個採集點被看見，不能把.400當作B實際來源發生時間。將received time誤當source time，會把傳輸延遲誤寫成設備反應時間。

時間線表要同時保留raw、窗口、排序狀態與證據。不要把未知轉成零，也不要在匯入時四捨五入到整秒；精度不足可以在顯示層縮短，但原始資料檔必須原封不動保存。

若製程Hold只在C來源出現，而A、B都沒有直接控制回饋，最穩妥的說法是「C是已觀察到的製程結果，A與B為時間相容的候選先行事件」。這個寫法讓工程師知道下一個要找的是因果鏈證據，而不是重排文字。

本文案例的數字都是案例條件，沒有宣稱真機、模擬器或現場硬體驗證。引用手冊只表示章節內容已核對到診斷與錯誤歷史功能；它不保證每個專案都啟用相同記錄，也不替設備安全或製程根因做工程批准。

輪詢漏脈衝與保存覆蓋

第三個案例的輪詢點在0與500毫秒，脈衝在100毫秒開始、200毫秒結束，寬度100毫秒。兩次輪詢都讀到OFF，於是完全漏掉中間ON。這不是沒有發生，也不是把輪詢改快就一定全抓到；還要核對最短脈衝、排程延遲、來源更新及路徑限制。

要降低漏失，先明確定義資料路徑和需求：是要知道「曾經發生」還是要重建每個邊緣？前者可使用設備已提供的事件計數或鎖存證據，但功能與型號要核對；後者需要能保存邊緣的來源、時間與序號。本文不虛構Q系列通用指令，也不保證一般輪詢能取代硬體事件記錄。

第四個案例是診斷歷史環形覆蓋。09:00時記錄A、B，10:00後高頻錯誤寫入使最早資料被覆蓋，11:00才開始匯出，只看到較新的事件。報告必須寫「09:00至匯出前的歷史可能已覆蓋」，而不是把匯出檔當成完整清單。

保存策略要在事件高峰前啟動，並留下匯出完成時間、資料範圍、檔案雜湊和缺口。若已經覆蓋，補救是找外部採集器、HMI事件、網路設備或操作員紀錄，不能從剩下的檔案猜回缺失事件。

把製程影響獨立列出。若C的Hold造成批次停在加熱步驟，先記錄停留步驟、輸出命令、回饋和批次編號；不要因A或B看似較早就直接把停機損失歸因於它。製程影響可以已確定，根因仍然未知，兩欄不能混寫。

失敗排查順序是先保全raw，再確認時間基準，再查同源序號與容量，最後才建立候選因果圖。任何重新啟動、清除歷史或改變輪詢週期的動作都可能破壞原始證據，必須由現場負責人批准並留下變更記錄。

FAQ與來源

FAQ1：第一個收到的訊息是不是第一個根因線索？答：它是第一個收到的線索，不一定是第一個發生的事件。必須並列source time與received time，並查時鐘偏差與傳輸延遲。

FAQ2：已知A、B時間窗口重疊，能否用事件序號跨設備排序？答：不能。序號通常只在同一來源內有排序意義；跨來源要靠共同時鐘、共同觸發或其他獨立證據。

FAQ3：把輪詢從500毫秒改成100毫秒，是否保證抓到100毫秒脈衝？答：不保證。脈衝相位、排程延遲與資料路徑仍可能造成漏失，需求若是事件不遺漏，應核對來源是否提供事件鎖存或計數能力。

FAQ4：歷史已被環形覆蓋，能否用現存事件推回缺失內容？答：不能。保留Unknown，改查外部採集器、HMI、網路設備或操作員紀錄；任何推論都要標示為候選並說明證據缺口。

參考：GX Works2 Common 第21.1.1節 QCPU診斷及錯誤歷史CSV保存

參考：Mitsubishi QnUCPU User Manual，3.18 Error History：QnUCPU錯誤歷史功能的文件核對。

延伸閱讀

• PLC記憶體不足時如何找出陣列與暫存使用量
• PLC重啟後流程位置與恢復條件判讀