事件調查的邊界
本篇把I/O插拔、既有斷線事件與製程狀態放在同一條時間線中查讀，目的在回答「當時發生了什麼」以及「哪些結論仍不能下定論」。Q06UDVCPU與GX Works2的監看畫面可以提供控制器、模組或通訊狀態，但不代表所有遠端I/O都具備可追溯的插拔感測器。先寫清楚觀測來源、時間基準與缺口，才能避免把畫面上的最後狀態誤寫成實際動作。
調查第一步是建立事件ID，例如IO-2026-09-17-01，並收集工程檔版本、CPU運轉模式、模組站號、網路診斷紀錄、HMI趨勢與製程批號。每一筆證據都要記錄來源時間、採集時間、時鐘偏差是否已知，以及它描述的是訊號、通訊還是流程結果。這樣可以把「remote斷線」與「CPU停止」分開，也能辨認只是輸入值凍結而沒有新的掃描資料。
不要把這篇教學當成帶電拔插程序。Q系列是否支援某種模組更換、需要何種停機或專用程序，必須由該CPU、基板、模組及現場安全文件共同決定；題目只要求調查既有事件。若事件涉及真設備，先依現場隔離與變更流程處置，僅在安全允許的唯讀資料副本中分析。
一條可靠時間線至少要有事件前、疑似事件、事件後三段。事件前要記下最後一筆可信輸入和製程步驟；疑似事件段列出斷線、CPU模式、輸出命令與回饋；事件後則檢查重新連線、值是否恢復、批次是否中止。每段都標示「直接證據」「間接證據」或「未知」，避免用一個紅色警告涵蓋所有原因。
例如離線記錄顯示站號十一在09:00:00曾回報連線正常，HMI於09:00:08顯示資料未更新，PLC日誌09:00:11出現通訊錯誤，流程日誌09:00:14記錄保護停止。未對齊各來源時鐘前，這只是四筆觀察，不能直接宣布誰先誰後，更不能寫成09:00:08有人拔站。
時間線與時鐘偏差
時間排序先核對時鐘。假設HMI比PLC快二十秒，偏差估計的不確定性為正負五秒，HMI的09:00:08換到PLC時間基準約為08:59:48，區間是08:59:43至08:59:53。保留原時間與換算欄，不覆寫原始記錄。事件序號只能在已知同一序號來源的範圍輔助排序。
先固定共同參考：查工程站、CPU、HMI與網路設備的校時記錄，再找同一個可見事件，例如操作員確認按鍵、批次步驟切換或電源監視器邊沿。若參考事件只在一台裝置留下，就把它當作局部錨點。當兩筆證據的誤差區間重疊時，結論必須寫成「順序不確定」，不能因秒數看似接近而強行排序。
離線案例A為上述HMI觀察，B為PLC日誌09:00:11才寫出的通訊錯誤，已知B寫檔延遲零至三秒，所以發生窗口09:00:08至09:00:11；C是同一PLC時間基準下09:00:14的流程Hold。依這些假設，A窗口完全早於B，C晚於B；順序可分開，但還不能證明A造成B。
| 事件 | 原始時間 | 時鐘資訊 | 可下的結論 |
|---|---|---|---|
| A：HMI值凍結 | 09:00:08 HMI | HMI快PLC約20秒 | 換算區間08:59:43–08:59:53 |
| B：remote錯誤 | 09:00:11 PLC | 寫檔延遲0–3秒 | 實際事件約09:00:08–09:00:11 |
| C：流程Hold | 09:00:14 PLC | 同一控制器時間 | 晚於B記錄，但原因待查 |
若要判斷斷線是否先於CPU停止，至少找兩個獨立指標。例如CPU模式記錄仍持續增加而remote值凍結，較支持「CPU仍掃描、資料路徑中斷」；若CPU模式先變為STOP且所有輸出狀態停止更新，才有理由把CPU停止列為候選主因。這仍是證據強度的差異，不是自動診斷。
再做敏感度檢查：若HMI偏差的不確定性擴大成正負三十秒，A窗口成為08:59:18至09:00:18，與B交疊，此時順序才是不確定。報告要呈現區間及其來源，而不是不論數字為何都寫不能判斷。
三種狀態的對照
Remote斷線代表資料通道或遠端站的連線狀態出現異常，不能直接等同模組被拔出。可能原因包含電纜、交換器、站端電源、參數不一致或設備重啟。調查時應同時看站端可見電源、網路連通紀錄與最後一筆輸入，而不是只截取一個錯誤圖示。
CPU STOP是控制器運轉模式的事件。它的時間與remote斷線可能相同，也可能完全不同；CPU仍RUN時，某一站斷線可能只影響特定I/O映像，CPU STOP則通常改變整體掃描與輸出處理。文章不替產品猜測輸出保持或清除細節，這些行為要核對實際CPU、參數與安全設計。
信號凍結是觀察結果：畫面或記錄中的數值在一段時間內不變。凍結可能由來源沒有更新、通訊緩衝保留最後值、HMI沒有重新取樣或資料品質標記失真造成。若沒有有效的更新計數、timestamp或quality欄位，不能用「數值沒變」推論現場感測器真的保持同一物理值。
| 觀察狀態 | 必要交叉證據 | 錯誤推論 | 較穩妥寫法 |
|---|---|---|---|
| remote斷線 | 站端、網路、最後更新時間 | 等於拔模組 | 列為連線異常，插拔待證 |
| CPU STOP | CPU模式與掃描記錄 | 等於遠端站先斷 | 分開建立兩個事件 |
| 值凍結 | 更新計數、品質、來源時間 | 等於現場值不變 | 寫成資料未更新 |
另一組獨立示例以同一採集服務時鐘為基準：09:00:08至09:00:16，Raw=640不變，來源時間停在09:00:07，服務品質於09:00:09變Bad。這支持資料更新異常，不支持液位穩定。品質是該服務提供的欄位，並非每個GX Works2原生X裝置都具有。
再把製程命令、回饋與推導狀態分開。假設另一段同步日誌記錄09:00:12運轉命令仍為1，09:00:13回饋為0，09:00:14流程進Hold，這形成命令與回饋不一致的線索；仍需追出回饋來源及資料是否有效，不能僅憑命令推定馬達實際旋轉。
調查步驟與失敗排查
執行調查時先複製唯讀資料，不要在原工程檔中改寫註解或清除診斷。建立欄位：event_id、source、raw_time、normalized_range、clock_note、state、quality、evidence_file與confidence。每筆資料只填能證明的欄位，缺少的欄位留Unknown並說明下一個可取得的證據。
若事件記錄只有一筆09:00:11錯誤，第一個排查方向不是立即更換模組，而是確認CPU、HMI與站端是否使用同一時區與夏令時間規則，再檢查記錄是否循環覆寫。若記錄時間跳回、序號不連續或檔案有截斷，先把時間線標成不完整，避免把缺口當成沒有事件。
若remote斷線後數值短暫恢復，應記錄恢復前後的更新間隔和品質變化。例如09:00:20恢復Online，09:00:21 timestamp前進但quality仍Bad，代表連線狀態恢復不等於應用資料已可信。只有來源更新、品質回到允許值且製程互鎖重新評估，才可由負責人決定是否恢復流程。
若沒有保存原始趨勢，不能用後來截圖補造整段歷史。可做的補救是從HMI事件、控制器診斷、批次記錄、網路設備紀錄及操作員紀錄分別取證，並把每個來源的時間誤差列入結論。調查報告應保留「未能證明」的項目，這比給出錯誤的確定原因更能支援後續改善。
適用限制包括：不同Q系列CPU、遠端I/O網路和GX Works2版本的診斷欄位可能不同；本文不承諾某個畫面必然存在某個欄位，也不替現場判定可否帶電操作。引用的QnUCPU與GX Works2手冊只支援文件核對，實際事件仍要以設備型號、參數和保留紀錄為準。
FAQ與來源
FAQ1：看到遠端站Offline，可以直接寫成模組被拔出嗎？答：不可以。Offline只證明連線狀態在該來源上異常；需再查站端電源、網路記錄、模組診斷與現場紀錄，否則只能寫成候選原因。
FAQ2：CPU仍在RUN，是否表示所有I/O都正常？答：不表示。CPU可能持續掃描而特定遠端站或資料通道已中斷，必須分別檢查更新時間、品質與站端狀態。
FAQ3：時鐘偏差造成事件順序不確定時怎麼寫？答：保留各來源原始時間，列出偏差與誤差區間；若區間交疊，明確寫「順序不確定」，再用事件序號或共同參考事件縮小範圍。
FAQ4：調查是否要先重啟設備重現？答：不要把重啟當成第一步。重啟可能覆寫診斷或改變現場狀態；先保存唯讀證據，並由現場負責人依安全與變更程序決定是否進一步試驗。
參考：Mitsubishi QnUCPU User Manual：CPU、I/O與運轉狀態的文件核對。
參考：GX Works2 Version 1 Operating Manual Common：工程軟體監看與診斷操作的文件核對。