先記錄模式不要急著歸責
設備突然停止時，先把「CPU現在是STOP」和「誰讓它STOP」分成兩個問題。第一個可由狀態觀察回答，第二個需要控制器診斷、工程站操作、通訊與現場紀錄相互支持。只看到RUN燈熄滅，不能立即判定有人按停，也不能只因網路在線就指認遠端命令。
本篇以Q06UDVCPU維護情境說明只讀取證，功能依三菱QnUCPU手冊的遠端操作章核對，工程環境以適用版本GX Works2為準。本文不執行RUN、STOP、RESET，也不提供用測試命令重現停機的步驟；先保存既有證據，復機另按現場已核准程序處理。
人為與通訊不是互斥分類。工程師在工程站按遠端STOP，是人為發起、通訊傳送；排程服務送出相同命令，是軟體發起、通訊傳送。報告分開填發起者、傳送路徑、控制器反應和信心程度，才不會把「遠端」誤寫成「沒有人操作」。
先記錄CPU型號、工程版本、觀察時間、RUN/STOP/RESET開關位置、LED、診斷內容和通訊是否可讀。保留完整錯誤碼及文字，但不要用其他系列代碼表套解。若只能看到HMI停止圖示，需標明那是應用狀態，還沒有證明CPU已進STOP。
取得資料時也記來源時鐘。PLC時間、工程站時間、HMI顯示和伺服器日誌可能有偏差；先保留原時間與時區，再另做對齊欄。修改時鐘或清除診斷可能破壞順序線索，不宜在第一步就做。
分開查四條可能路徑
第一條是CPU實體開關。保存當時能取得的照片、值班紀錄或觀察者說明，但現在開關在RUN不證明過去一直在RUN。若開關位置與程式狀態不同，先查遠端操作與診斷，不要來回扳動開關只為看看會發生什麼。
第二條是工程軟體遠端操作。查實際連線的工程站、專案與作業紀錄，確認操作目標是本台CPU。工程站登入記錄只能證明帳號登入，若沒有對應命令或作業紀錄，不能直接推定該人送出STOP。共用帳號尤其只能追到帳號或主機，不能憑空補出操作者。
第三條是外部通訊或網路操作。三菱手冊列出工程工具、MC協定外部設備、適用網路專用指令與RUN接點等遠端途徑。逐一盤點本案實際有配置哪些，不把功能清單當成所有路徑都啟用。封包與服務日誌只從已核准且可取得的記錄查閱。
第四條是控制器或模組異常。查停止前後的診斷、電源與重啟紀錄，以及是否有停止型錯誤。看到錯誤和STOP時間接近，只能列候選關係；必須核對該型號手冊對此錯誤的動作，並排除同時發生的操作。網路中斷也可能只是CPU停止後的結果。
RUN接點和應用程式的設備啟動按鈕不是同一個概念。只讀檢查PLC參數是否配置遠端RUN接點及其來源，不任意改參數或操作輸入。本篇不給通用ON/OFF口訣，避免把現場接線和控制器專用設定混為一談。
用一條時間線建立證據等級
建立離線案例：工程站紀錄10:00:02.100送出對CPU-A的遠端STOP請求，10:00:02.180記錄成功回覆；監看最後一次RUN在10:00:02.000，首次讀到STOP在10:00:02.300。假設三個時間均來自同一已校對工程站，這些資料支持遠端請求與模式變化有關，但沒有精確到控制器在哪一毫秒完成切換。
模式切換的可觀測窗口是最後RUN到首次STOP之間，也就是300毫秒範圍。請求到回覆80毫秒是本次通訊往返觀察，不能當作PLC掃描時間，也不能把首次輪詢STOP當成真正切換瞬間。保存監看週期，讀者才能判斷時間線解析度。
再查作業單：若核准維護單CR-17記載工程師E01操作，且工程站使用個別帳號、有對應操作稽核，可描述為「記錄支持E01經工程站發起遠端STOP」。若只有主機IP與共用帳號，就寫「來源主機已知，實際操作者未確認」，不可為了結案而補姓名。
第二個分支只有10:00:02.300讀到STOP，服務日誌和工程站操作記錄都缺失。這時結論是切換來源未知，列出待查開關、遠端途徑與CPU診斷。沒有找到STOP封包不等於沒有發送，因為擷取點、保留期限或加密通道可能讓你看不到。
第三個分支同時有停止型診斷與遠端請求，兩者時鐘偏差尚未確認。先各自保留時間線，結論標多個候選原因，待時鐘和錯誤動作核對後再判讀。不要以畫面排序第一筆就稱為根因；記錄先後不必然等於物理因果。
整理可搜尋的模式事件紀錄
每筆事件保存caseId、assetId、CPU型號、程式版本、原模式、新模式、來源時間、接收時間、時鐘偏差範圍、觀察方式、原始證據位置和判定。判定分Observed、Supported、Unknown等本案自訂分類；它們不是三菱原生狀態碼，應與官方診斷欄分開。
例如CASE-207-01的Observed是「監看由RUN變STOP」，Supported是「同目標遠端STOP請求有成功回覆」，Unknown是「控制器實際切換精確時間」。同一案件可以同時有這三種欄位，不需要為了畫一個綠勾而把未知細節全部改成已確認。
排查失敗時先查目標識別：工程站是否連到CPU-A，畫面是否顯示另一台控制器，專案離線版本是否匹配。再查時間基準和資料缺口，接著核對遠端路徑與診斷。若連目標都不同，往後的時間比對再精細也沒有意義。
原始日誌保持原貌，清理後的CSV另存版本。對同一事件從兩個收集器收到的記錄，保存各自接收時間並關聯，而不是把其中一份刪掉；不同觀察點可協助判斷延遲。雜湊支持檔案未改，但不能替代日誌來源與帳號責任證明。
若需要以測試驗證某條路徑會留下什麼紀錄，先在隔離環境制定測試計畫，明定設備輸出影響、恢復條件與責任人。文章中的離線時間線只能教你如何分析，不代表已證明現場特定版本一定保存完整操作者或命令歷史。
完成結果與常見問題
完成後交付一張有證據等級的時間線，而不是只寫「人為停機」。本例應能算出300毫秒模式觀察窗口及80毫秒請求回覆間隔，列出遠端路徑與操作者證據；資料不足的第二分支必須保留Unknown，不能套用第一分支的結論。
驗收時讓接手人從caseId找到原始工程站紀錄、CPU診斷與版本，再逐一核對時間和目標。若沒有原始命令記錄，就讓報告明確顯示缺項和下一步。這個結果有助維護改善記錄能力，也避免以推測指責操作人員。
問：開關在RUN，CPU就不可能被遠端停止嗎？答：不是。手冊的遠端RUN/STOP正是在實體開關RUN位置下改變執行狀態的功能，仍需核對實際配置。
問：遠端STOP一定是自動程式做的嗎？答：不一定，人可經工程工具發起，應分開記錄發起者與通訊路徑。
問：沒有操作日誌可以寫無人操作嗎？答：不能，只能寫目前未取得操作證據，並說明保留與觀測限制。
問：STOP後可以直接遠端RUN驗證嗎？答：復機需另按機台程序確認原因、輸出與現場狀態；本篇取證流程不授權試啟動。
參考：三菱QnUCPU User’s Manual SH-080807ENG-AF，第3.6節遠端操作、第3.6.1節RUN/STOP：路徑與模式定義。