診斷歷史環形覆蓋與定期匯出

環形歷史的容量問題

診斷歷史或操作歷史若以環形方式保存，新事件可能覆蓋最早事件。定期匯出不是「每隔固定分鐘按一次按鈕」而已，必須先知道容量、事件速率、停機延遲、匯出時間、失敗恢復與保存期限。本文用1000筆作自訂容量假設，不把1000寫成QnUCPU的原生規格。

QnUCPU 3.18 Error History與3.38 Operation History說明不同種類的歷史；GX Works2也分別提供診斷與歷史監看。error history記錄錯誤或診斷事件，operation history記錄操作活動，兩者來源、欄位與覆蓋行為不能混成一張表。先確認要保存哪一種，再設計匯出工作。

若假設容量1000筆、持續每秒2筆，新資料寫滿時間為1000÷2=500秒，約8分20秒。這是容量推導，不是手冊保證；突發速率高於2筆每秒時，實際覆蓋更快，事件格式或多來源合併也可能改變每筆所占容量。

保存檔要保留原始事件識別、來源、來源時間、採集時間與序號。不要只匯出畫面上的摘要文字，因為後續需要判斷是否重複匯出、是否有缺口，以及某筆事件屬於error history還是operation history。

定期匯出只能降低覆蓋風險，不能替代容量計算與失敗告警。若PLC停機、連線中斷或工程站忙碌，匯出時間表就會失效；設計上要把失敗當成明確狀態，而不是默認下一輪會自動補回。

覆蓋時間與排程計算

以每300秒匯出一次為例，理想情況下兩次匯出間新增2×300=600筆，低於1000筆容量，尚有400筆裕量。但若匯出前發生250秒停機或連線延遲，從上一個成功checkpoint到下一次可讀取已經550秒，新增2×550=1100筆，超過容量100筆，最早資料可能已被覆蓋。

最大保存間隔要從上一批已涵蓋的來源位置，算到下一批確實取得並持久保存的涵蓋位置，不能只用兩次排程啟動時間。讀取、寫檔、重試與排隊都需列入最壞延遲；若一批不是一致快照，還要依來源讀取方式核對哪段可能已被覆蓋。

例如以最壞速率每秒四筆、容量一千筆，另保留二百筆突發空間，可用時間為(1000−200)除4，得到二百秒。若失敗恢復和讀取保存共預留六十秒，理想排程間隔最多一百四十秒；這是有條件的預算，超出任一假設就重新評估。

保存時間也要明確。假設希望保留7天，不能只保存最近一次匯出檔；每次成功檔案要有時間範圍與不可覆寫的名稱，並在外部儲存檢查可讀性、容量和保留政策。保存成功不表示可以刪除CPU內歷史，刪除或清除要另有批准。

checkpoint與重複匯出

checkpoint代表「哪一筆已成功持久保存」，不是「哪一筆已被讀取」。流程應先讀取來源歷史、寫入外部檔、完成關閉與完整性檢查，最後才推進checkpoint。若檔案寫到一半斷線，checkpoint不得前移，下一次應從上一個已成功識別的範圍重試。

重試可能重複匯出。原始批次照存，事件檢視只有在來源提供可核對唯一身份時才合併，例如來源身份加重啟世代與事件序號。時間戳和碼值未必唯一，不能把同秒發生的兩次事件刪成一次。若同一身份對應不同內容，保留衝突與原始檔。

error history與operation history要各自維持checkpoint。若把兩種歷史合併成同一流水號，可能在一種歷史暫停時錯誤推進另一種的保存位置。報告要能回答每個checkpoint屬於哪一個來源、最後成功檔、涵蓋起訖和未確認缺口。

QnUCPU手冊中的操作歷史保存、顯示與注意事項章節可用來核對功能邊界；它不保證你的工程站自動定期匯出，也不保證外部儲存永遠可用。GX Works2的保存功能是操作工具，實際排程、失敗重試與檔案保留仍需由專案系統設計。

若來源沒有穩定事件序號，保存完整重疊快照與讀取時間，明示無法精確去重的限制。checkpoint可以表示最後成功批次及涵蓋範圍，但不能假裝是原廠不存在的事件游標。本文序號表是自訂假設，實際介面不支持增量讀取時，不硬套續傳流程。

失敗恢復與證據缺口

匯出工作失敗時先寫入failure record：來源、開始時間、失敗位置、已寫檔大小、最後成功checkpoint與下次重試條件。若設備重新連線時歷史已被覆蓋，報告要列出可能漏掉的時間範圍與估算筆數，不可以用下一批事件補寫成連續歷史。

延續一千筆容量案例：09:00已保存至序號500，此後來源持續每秒兩筆。09:05排程失敗，延遲250秒後於09:09:10取得下一批，共新增1100筆，至序號1600；環形來源只剩601至1600，501至600共一百筆已缺失。保留此明確缺口，不能寫成只新增六百筆卻覆蓋一百筆。

永久缺口不能靠無限重試補回。先保存601至1600並驗證檔案，再依設計記錄缺口501至600已確認無法補回，可將後續收集位置推進至1600，同時保留完整性未通過。保存進度和歷史完整性是兩個欄位，推進游標不能抹掉缺失。

如果同一事件在兩個外部檔重複出現，保留兩份原始資料和一個dedup結果，並記錄去重規則。去重是資料整理，不代表第一次匯出和第二次匯出都成功；運維人員仍要看批次紀錄與完整性檢查。

排查時分開看三條線：CPU歷史是否仍可讀、工程工具是否成功取得、外部儲存是否持久保存。任何一條線失敗，都不能把整個保存任務標成Done。若只有摘要畫面而沒有原始識別，應降低證據等級並保留未知。

適用限制包括CPU型號、韌體、參數、歷史種類與GX Works2版本差異；1000筆、2筆每秒、300秒與250秒均是案例條件。真實容量和覆蓋規則要按QnUCPU 3.18、3.38及專案配置核對。

驗收保存機制時，先以可重算資料集測試：固定事件速率、故意延遲250秒、模擬寫檔中斷、重試同一批，再檢查checkpoint是否只在成功後推進、重複資料是否依原始識別去重、缺口是否被保留。這是離線資料流程測試，不是對QCPU歷史容量的硬體宣稱。

保存驗收與FAQ

保存檔命名可包含來源類型、CPU識別、起訖來源時間、首末序號與匯出批次；檔名只是索引，正文仍要保留每筆raw欄位。時鐘異常或序號跳躍時，檔案可成功保存但內容仍有缺口，完整性檢查應把它標出。

若工程人員要求「每五分鐘一定不漏」，先把這句轉成容量、最大事件速率、最大停機、最大重試與外部保存可用性的條件。沒有這些數字，就只能說降低風險，不能承諾零遺失。

FAQ1：容量1000筆、每秒2筆，能保存多久？答：理想計算為500秒；若速率突增、讀取延遲或來源分開計算，實際覆蓋可能更早。

FAQ2：每300秒匯出，停機250秒後是否仍安全？答：不一定。若從上次成功保存算起達550秒，2×550=1100筆，已超過1000筆假設，可能漏100筆。

FAQ3：checkpoint何時推進？答：外部檔完整寫入、關閉並通過完整性檢查後才推進；只讀到資料或建立暫存檔都不算成功。

FAQ4：error history與operation history可共用一個checkpoint嗎？答：不建議。兩者來源與保存進度不同，應分開識別、分開記錄缺口與成功批次。

參考：GX Works2 Common 第21.1.1節 錯誤歷史與操作歷史顯示保存；其他trace資料另依第19.4節

參考：Mitsubishi QnUCPU User Manual：3.18 Error History、3.38 Operation History及其保存注意事項的文件核對。

延伸閱讀

• 診斷位元瞬閃的事件計數概念
• 版本標籤與CPU內容比對