工業HMI變更申請的驗收與回退流程

變更單先描述可驗證問題

一張好的變更申請要讓未參與設計的人看懂：為何改、改哪個配置項、預期行為、風險、窗口、負責人與回退條件。標題不能只寫「更新HMI」，應寫成「SCR-005趨勢查詢將時間窗由24小時改為7天，保留查詢逾時時的回退」。

before欄保存現行版本、路由、資料鍵、權限與外部端點；after欄逐項寫新值或新行為。若變更影響Gateway、歷史資料庫、認證服務或通知服務，列出依賴owner與可用性，不要只列HMI檔名。

變更申請應把量化門檻寫在送審前。例如查詢7天資料的95百分位延遲不得超過2秒，權限拒絕測試必須為零次未授權成功，DB查詢錯誤率不得高於基準。門檻是本組織自訂驗收條件，不是NIST或HMI產品自動保證的數字。

影響評估與批准

影響評估要把功能、資料、權限、網路、操作與復原分開。畫面改名可能影響route書籤；資料鍵改名可能讓歷史趨勢空白；權限改動可能讓操作員看得到命令卻無法執行；DB schema改動可能需要先升級查詢。每個影響都要有owner與檢查方式。

批准不是在變更完成後補簽。申請人提供測試結果與風險，審查者確認安全與外部依賴，變更負責人安排窗口，值班人員知道停止條件。緊急變更也要在事後補齊before/after、原因、影響與回顧，不以口頭通知取代紀錄。

通知應有唯一changeId與狀態Draft、Approved、Scheduled、Blocked、Implemented、ValidationFailed、RolledBack或Closed。同一變更的進度附在原changeId下，另有狀態版本；通知按changeId加狀態版本去重，不能只用changeId把後續失敗或回退通知也擋掉。這能避免操作團隊收到兩個互相矛盾的完成訊息。

外部依賴要有前置確認與回退負責人。若DB schema升級不能逆轉，回退方案可能是保留新schema並恢復舊HMI相容查詢，而不是把資料庫硬降版；若認證服務改版，則要先保留舊角色映射與測試帳號。把這些差異寫進表格，避免執行時才發現回退不完整。

驗收要對照before/after

驗收案例至少包含正常、邊界、拒絕與外部失敗。正常案例確認7天趨勢有資料；邊界案例確認起訖時間與時區；拒絕案例確認Operator不能修改參數；外部失敗案例讓資料庫逾時，確認畫面顯示品質或錯誤，而不是顯示0或假裝完成。

驗收結果附於changeId，包含測試資料、時間、角色、畫面版本、查詢結果與缺陷。未實施而測試不通過時標Blocked；若已實施後驗收失敗，保留真實實施時間並標ValidationFailed，不能偽裝仍Scheduled。只有達到申請單寫明的通過條件，才可關閉變更。

回退不是把HMI檔案覆蓋回去就結束。若新版本已改DB schema、權限角色或外部API，回退矩陣要說明依賴是否可逆、資料是否需要轉換、通知服務是否要撤回，以及誰批准回退。不可逆資料遷移應先有向前修復方案。

發布紀錄應把實施、驗收、例外與回退寫在同一changeId下，並在關閉前附上before/after差異。若值班人員需要即時告知，只引用該changeId與當前狀態，不另建第二張變更單，必要狀態通知仍保留版本。這樣查詢通知歷史時不會把一次變更誤算成兩次部署。

若尚未實施而外部依賴owner未確認，標Blocked並重新排程；若已實施才發現問題，記錄驗收失敗及處置；不能以HMI端測試通過代替資料庫、認證或通知端的驗收。

執行 回退與排錯

執行前建立現行快照與回退點，確認備份可讀、外部owner在線、測試端點與停機窗口有效。執行後先做低風險讀取驗證，再開放寫入或操作功能；監控錯誤率、延遲、權限拒絕與資料新鮮度。若任一停止條件成立，按申請單順序回退並記錄每個依賴的結果。

常見失敗是before欄只寫「舊版」、after欄只寫「新版」、沒有可量化驗收；另一種是HMI回退成功但DB已升版，導致查詢錯誤。排查時先核對changeId與版本，再看外部依賴狀態、資料遷移與權限，最後才重新整理畫面快取。

本篇不提供任何廠牌指令或機械設備強制操作。變更流程與驗收表是治理模板，實際平台的匯出、部署、回退與安全停機方式必須依指定版本文件及現場程序確認。

變更完成後安排觀察窗口，確認資料新鮮度、警報、登入與外部查詢在實際負載下穩定。窗口內若只發現文件缺漏，可建立補件任務；若發現功能或安全門檻失敗，按事先寫好的停止條件回退，不能以「稍後修正」繼續擴大影響。

若變更只改畫面文字，也要確認翻譯鍵、字型與截斷不影響警報或操作；若改資料綁定，則必須加入品質與空值案例。把小變更分類可以降低審查負擔，但不能因名稱看似小就略過外部依賴檢查。

回退觸發條件可包括未授權寫入、查詢錯誤率超門檻、資料延遲超門檻或安全互鎖顯示異常。每條條件都要寫觀測來源、判斷時間與決策人，避免現場爭論是否已達回退標準。

關閉變更前由另一名審查者檢查before/after、測試證據、實施時間、例外與通知狀態。審查者不能只看「成功」欄位，還要確認外部依賴與回退點真的可用。

若回退後資料已產生新格式，驗收要確認舊版能安全讀取或明確進入唯讀狀態；不能只看畫面恢復，就忽略新資料可能無法被舊版本解碼。

變更關閉時附上監控窗口的開始與結束時間、告警數量、查詢錯誤與使用者回報，讓後續問題能區分本次變更與既有缺陷。

例如相容性測試須在schema13上同時執行舊版24小時查詢與新版7天查詢，核對欄位、單位及缺值。若舊查詢不能讀新結構，回退方案尚未成立。已寫入的新資料與外部通知不會因HMI回復舊版而自動撤銷，必須另列處置。

FAQ與來源

FAQ1：有backup就一定能rollback嗎？不一定，外部資料庫、權限、API與不可逆遷移都要在回退矩陣中驗證。

FAQ2：before/after只寫檔名可以嗎？不夠，應包含版本、行為、端點、資料鍵與可驗收結果。

FAQ3：同一變更需要重發完成通知嗎？同一完成版本不要重複發布；後續修正或回退可用同changeId的新狀態版本通知，保留歷史。

FAQ4：一個邊界測試失敗能先上線嗎？只有申請單明確允許並由負責人接受風險，否則保持未通過。

參考：NIST Manufacturing Profile：保留基準組態、變更控制與製造系統回退規劃。

參考：CISA StopRansomware Guide：備份、復原計畫與定期測試，供回退準備參考。

延伸閱讀

• HMI備份與隔離還原驗收
• PLC與HMI標籤對照與命名實作