離線不是只有一個紅色標籤
通訊中斷時，畫面可能仍有上一筆溫度、歷史趨勢與待送命令。若只在角落顯示離線，操作員容易把舊值當現在值，或以為按下寫入已經到達設備。先把資料、讀取、查詢與寫入分開標示，讓每個元件都說清楚它的時間與可用性。
每個顯示資料至少附 quality、source timestamp、receive timestamp 與 age；無法可信計算 age 時顯示未知，不用零代替。last good 可以供比較，但要標示「舊值」及最後有效時間。離線期間的新數值不是零，也不是自動保持為正常值。
本文把本地檢視定義為顯示已取得的資料，線上查詢則是要求後端提供歷史或狀態，寫入則會改變設備或工作流程。三者不能共用一個 enabled 旗標。離線時可允許查看已快取歷史，查詢與寫入則依服務契約分別禁用或排入待確認，不讓按鈕外觀傳達錯誤承諾。
本文是通用 HMI 與服務設計，不假設任何 Q 系列 PLC、HMI 或通訊模組原生支援特定離線模式。真正的授權、命令佇列、狀態碼與安全互鎖仍需查目標平台文件與現場規範。
把不可操作與可查看分開
離線畫面可保留趨勢與最後快照，但寫入、啟動、停止、配方提交等控制元件應呈現 disabled、原因文字與重新連線條件。不要只降低透明度或改灰色，因為色盲、投影與低亮度環境可能看不出差異；元件旁要有「離線不可操作」等明確文字。
後端仍必須驗證授權與連線狀態，不能因前端按鈕被禁用就相信請求不會到達。可接受的請求要帶 session、資料版本與 request_id；後端發現服務離線、授權失效或資料過期時應拒絕並回報原因。前端狀態是提示，不是安全邊界。
查詢按鈕可在離線時改成「查看本地快照」，但必須顯示快照時間、來源與不完整限制。若使用者要求最新資料，應回報無法取得，而不是把 last good 重新命名成現在值。歷史報表也要標示查詢當時的連線狀態，方便交班與事故回放。
正常結果是操作員仍能查看有時間標籤的資料，卻不會誤以為寫入成功；失敗結果是只把連線圖示變紅，所有數字和按鈕看起來仍正常。排查時先逐項確認元件能力、資料品質、授權結果與後端日誌，不要先改顏色或重啟畫面。
離線狀態也要標示最後成功同步的 session 或 epoch。若設備重啟、服務切換或資料來源改變，舊快照即使數字看似合理也不能直接當作同一設備的目前狀態。畫面應提供來源識別、同步時間與資料版本，讓交班人員知道快取的邊界。
命令區的禁用原因要能被讀取器與鍵盤操作取得，不能只靠滑鼠 hover。對已按下但結果未知的命令，顯示「待查詢」或「不可確認」，並提供查詢或取消草稿的明確動作；不要把按鈕文字改成模糊的忙碌狀態。
若後端允許離線草稿，草稿必須與已送出命令分開保存，並在重連時逐筆要求確認。批次草稿中任一筆資料版本不符時，應指出衝突欄位，不可整批默默套用上一版。
未知命令不可盲目重送
斷線前送出的寫入命令可能已到設備，也可能只在網路途中。重連後若沒有結果或唯一識別，不能把它當成一定未執行而自動重送；對停止、配方寫入或動作命令尤其危險。應標示 UnknownOutcome，保存 request_id、時間、目標與 payload 摘要，等待查詢或人工核實結果。
若協定和設備提供可查詢的命令狀態，可在新 session 先查詢並以 request_id 或設備交易識別配對。若沒有可靠查詢，重連後只恢復顯示，暫停自動命令佇列。原未知命令未釐清前，禁止建立同效果的新命令。只有查明結果並重新核對設備狀態、確認是新的意圖時，才建立新request_id；契約允許的原命令冪等重試則保留原識別。
重連流程可分 Connecting、Authenticated、Syncing、Ready。尚在 Syncing 時顯示不可操作；取得新鮮且品質合格的資料、完成權限與版本檢查後，才解除寫入。恢復後第一筆資料也要核對來源、epoch 或 session 與時間，不能因 TCP 已建立就宣稱設備狀態新鮮。
離線期間使用者填寫的新表單應保存草稿與建立時間，重新連線後顯示「需重新確認」；不要直接套用舊表單值送出。對可安全重試的查詢與不可安全重試的實體命令，介面要有不同提示和流程，讓操作員知道按下確認的後果。
離線提示還應說明資料是否可供控制使用，而不是只說網路斷線。相同的 last good 可以在趨勢檢視保留，卻在自動寫入或安全相關流程中拒絕；兩個畫面都要顯示相同 quality 與時間，避免交班時產生矛盾。
恢復連線後若新資料仍是 Uncertain，應維持同步中或待確認，不可因狀態從斷線變成已連線就改成 Good。只有符合資料品質、版本與來源條件的新資料到達，才可解除不可操作標記。
驗收與適用限制
恢復條件也應顯示完成時間，方便交班核對。
離線狀態的每個限制都應可由操作員在畫面上解釋，不能只留在工程師日誌。
任何自動恢復策略都要把命令與資料分開驗證，讀取恢復不等於寫入權限恢復；日誌應記下每次解除禁用的明確條件。
驗收案例包括：正常線上、斷線後查看 last good、斷線時點擊寫入、命令已送但回覆遺失、重連同步中、取得新鮮資料後恢復、授權失效、以及離線草稿。逐項檢查 age、quality、命令狀態、request_id、按鈕文字與後端拒絕紀錄是否一致。
限制是不同產品對快取、離線佇列、session、命令查詢與權限的語意不同；不能由文章推定某個 API 或 PLC 裝置行為。實際上線前需在非生產環境驗證每個命令的重試與恢復政策。
常見問題與官方參考
FAQ1：離線時顯示 last good 可以當目前值嗎？答：不可以，必須同時顯示品質、來源時間與 age，控制流程也不能把它當新資料。
FAQ2：按鈕變灰就代表後端不會執行嗎？答：不代表；後端仍要驗證授權、連線、版本與命令狀態。
FAQ3：回覆遺失的命令可以重連後自動再送嗎？答：若無可靠查詢與冪等契約，應標 UnknownOutcome，等待查詢或人工核實，不以新識別繞過未知結果。
FAQ4：重連成功就能立即解除禁用嗎？答：不能，還要完成身份、同步、新鮮資料與版本檢查。
參考：OPC Foundation OPC UA Part 4 Services：DataValue 的品質、時間戳與服務語意參考；不代表特定 HMI 離線 API。
參考：W3C WCAG 2.2：狀態、文字提示與非色彩辨識的可及性參考。