先把一次停機保存完整
偶爾停機最容易落入每次換一個零件的循環。先把「什麼條件下停」寫成可查的事件：設備、產品、運轉模式、速度、負載、班別、環境與當時動作步驟。這些條件讓你能比較正常與異常，不必只靠操作員記得剛才好像有聲音。
第一筆資料要回答事件何時開始、哪個來源最先觀察到異常、何時停止產出、何時恢復。警報畫面收到時間不一定是故障發生時間；保存來源時間與接收時間，另外記下時鐘同步、解析度及資料是否延遲補送。
建立事件編號，把PLC狀態、驅動器警報、供電記錄、網路事件及維護操作串在一起。來源原文保留，不先全部改成同一個「PLC異常」名稱。若設備不提供故障前資料，明確標示缺口，不能用最後正常值補成故障期間的狀態。
本文適用一般維護調查，不把某種紀錄器或特定PLC記憶體當成必備。先用既有可安全讀取的資料建立最小紀錄，再依事件速度選擇額外量測設備；不可為了收資料改動保護邏輯或讓已知不安全狀態持續運轉。
用故障前後視窗保住起因
只有停機後截圖，常會漏掉觸發原因。採集端可設循環緩衝，持續保存最近一段資料，發生事件後保留前段與後段。假設每十毫秒一筆、保留事件前五秒與後十秒，半開區間內共十五秒，也就是一千五百筆；實際邊界規則要另寫清楚。
緩衝資料至少含採樣序號、時間、命令、實際回饋、步驟號、關鍵量測與品質。若記錄的是變化事件而非固定週期資料，就不能用一千五百筆公式驗收，應確認初始狀態、每次變化與最長無變化間隔都能重建。
觸發可來自停機事件或關鍵狀態變化，但要避免同一故障連續覆蓋前一段證據。每次觸發配置事件識別與保留策略；儲存不足時發出明確診斷，不能悄悄覆寫唯一的故障片段。重啟後是否仍保存，依平台能力另測。
記錄頻率要符合待查事件。十毫秒採樣無法保證抓到兩毫秒的訊號消失；如果只有HMI每秒輪詢，時間線只能支持較粗的結論。提高趨勢圖刷新率不等於提高來源取樣率，兩者在設定與報告分開列。
完成後應看到同一事件的前、後狀態及完整性標記。若序號缺號、時鐘跳變或品質失效，先標出缺口。圖上用直線連過缺口會讓人誤以為設備連續穩定，應在顯示與匯出時保留這個差異。
比較發生率而不只數次數
假設高速模式四十個小時出現八次停機，低速模式一百六十個小時出現四次。高速每小時0.20次，低速每小時0.025次，這組資料的發生率比為八。只看八次與四次會低估運轉時間差異，但也不能憑八倍直接斷言高速造成故障。
接著分層比較產品、負載與環境。若高速全部生產較重產品，速度和產品重量就混在一起；若高速只在白天使用，溫度與人員操作也可能相關。先列出尚未分離的條件，再規劃可安全控制的比較，而不是把第一個相關變數當根因。
分母也可以是循環次數。每千次動作故障數適合按循環暴露的問題，每小時故障數適合持續運轉的問題。選定後保持一致；停機等待時間是否算入運轉小時要先定義，否則不同班別的數字無法比較。
零次故障不代表零風險。修改後只跑二十分鐘沒停，不能和原本幾十小時才一次的情況直接比較。應設定代表性的驗證期間、循環量及負載範圍，保留未覆蓋條件；若事件稀少，結論可寫尚無再現，而不是保證根治。
從候選原因到可驗證處置
把候選原因各寫成能被資料支持或反駁的句子。例如「馬達啟動期間控制電源短暫下降，接觸器先釋放」需要啟動事件、足夠頻寬的電壓證據及接點時序；只有PLC重啟時間，還不能證明哪個電源最先異常。
每次處置先寫預期變化，再動手。若懷疑接點鬆動，依隔離程序處理後，預期相同負載下的壓降與停機事件下降；若只換一條網路線，卻同時降低速度與更換產品，就無法知道哪個變更帶來改善。
將觀察、推論、已做處置與待驗證分欄。操作員描述「剛好開門」是有價值的觀察，但不能自動變成門開關故障；仍需看原始輸入、連鎖狀態及機械條件。反證也要保存，例如同樣開門卻沒有故障的正常片段。
失敗時先查紀錄是否真的涵蓋故障前段，再查時鐘、採樣與品質。若資料本身完整，再調整候選原因。不要因找不到證據就無限提高取樣率，應先確認需要哪個物理量及何種時間尺度。
交付時附事件清單、運轉暴露量、條件分組、原始資料位置、變更版本及驗證結果。本篇數字是統計算例，不能單憑一次相關性宣稱已證明某項硬體根因。
練習與常見問題
練習：改版前五十小時十次，改版後一百小時十次，是否完全沒改善？依本例定義，發生率由每小時0.20降到0.10次，但仍須確認運轉條件相近、樣本不確定性及觀察範圍，不能只比總次數或直接宣稱減半保證。
FAQ1：只保存第一個警報足夠嗎？不夠，第一個被收到的警報未必是最先發生的異常，應保留來源時間與故障前段。
FAQ2：每次都是同一產品就能判產品造成嗎？只能形成候選，還要比較速度、負載、班別及其他共同條件。
FAQ3：重啟後正常代表程式問題嗎？不代表，重啟也可能重置驅動器、通訊或暫態狀態，須保留重啟前證據。
FAQ4：多久沒再停才算修好？依原故障頻率與代表性運轉條件制定驗收，不使用固定半小時作通用門檻。