先建立升級前基準與資產清單
韌體升級的第一個成果不是按下更新，而是一份可重建的基準。對虛構Modbus到MQTT gateway，先記錄gateway版本、序號、授權、網路介面、來源站號、功能碼、暫存器範圍、資料型別、byte order、MQTT topic、QoS、retain與資料品質規則。這些欄位要從測試設定副本匯出並加上時間、操作者和檔案雜湊，避免只保留螢幕截圖。
| 項目 | 升級前基準 | 比對方式 |
|---|---|---|
| 版本 | 虛構GW-2.4.1／檔案雜湊 | 保存release notes與sha256 |
| Modbus來源 | 站號7、FC03、40001起4筆 | 離線讀取樣本與映射表 |
| MQTT輸出 | factory/line1/temp、QoS1 | topic與欄位逐項比對 |
| 安全資料 | CA、client憑證指紋、ACL | 只保存指紋與到期資訊 |
| 網路規則 | 管理介面、來源允許清單 | 匯出規則與版本 |
設定匯出不等於完整備份。外部DNS、交換器ACL、憑證私鑰保管、資料庫、MQTT broker的帳號與授權，可能不在gateway檔案內。清單要另列外部依賴與擁有者，並標記哪些可還原、哪些只能由管理流程重新建立。不要把秘密值寫入文章或測試報告，測試副本使用替代憑證和假資料。
完成本頁後，升級前應能回答三件事：目前哪個輸入產生哪個輸出、哪些設定不在匯出檔、失敗時誰有權回退。若版本沒有官方匯出功能，不能自行猜測檔案路徑；改以產品手冊列出的備份、版本控制或人工盤點方式形成證據。
把映射差異拆成可檢查的欄位
在離線副本建立映射比較表，不要用「通訊正常」概括所有結果。虛構gateway收到Modbus FC03回應中的四個16位word，從40001標籤對應PDU位址0、數量4；word0是INT16乘0.1的溫度，word1保留，word2的bit0為Good，word3是診斷碼，再轉成MQTT JSON。升級後即使值仍像合理數字，也要檢查站號、起點、數量、signed、縮放、topic、欄位名稱和品質來源。
| 欄位 | 升級前 | 升級後比較 |
|---|---|---|
| 輸入 | Unit7 FC03，40001標籤→PDU0，數量4 | 站號、功能碼、起點與數量不變 |
| word0溫度 | INT16 253×0.1=25.3 | 型別、符號與縮放相同 |
| word1保留 | raw word1不轉換 | 不得被誤當溫度或品質 |
| word2品質 | bit0=1為Good | bit位置與缺值處理相同 |
| word3診斷 | raw 7保留為診斷碼 | 欄位與錯誤對應相同 |
| 輸出topic | factory/line1/temp | 名稱與大小寫保留 |
| 緩衝 | 斷線保留最後值並標Stale | 重連是否補送或丟棄 |
一個離線樣本可用raw=[253,0,1,7]，依固定映射得到temp=25.3、word1=0、quality=Good、diag=7。升級後應同時檢查MQTT payload是否仍為25.3、保留字是否仍可追溯、word2 bit0是否仍為1、診斷碼是否仍為7。若結果變成0x00FD、把word1當品質或把word3當狀態，不要以為只是顯示差異，應回到映射版本欄位。
測試應包含正常、邊界、無效碼、封包短少、站號錯誤、broker暫停和重新連線。所有案例在測試副本執行，使用唯讀Modbus樣本與隔離MQTT broker；不把這些步驟描述成已在真實控制器執行。每個差異附上原始輸入、轉換結果、預期值與判定人。
韌體相容 憑證與管理介面回歸
官方release notes是判斷已知變更的第一來源，但它不能代替現場映射表。逐項讀取版本支援的協定、最大連線數、buffer限制、TLS版本、憑證格式、MQTT功能與授權需求。若升級跨主要版本，先在與現場相近的測試環境匯入副本，並把不相容項目列為阻擋條件，不要直接用成功開機作為通過。
| 檢查層 | 測試輸入 | 通過條件 |
|---|---|---|
| 管理登入 | 測試帳號與最小權限 | 能登入且角色不被放大 |
| Modbus唯讀 | 固定回應樣本 | 站號、功能碼、長度與解碼一致 |
| MQTT | 隔離broker與測試topic | topic、payload、品質一致 |
| 憑證 | 測試CA與有效client | 信任、用途及有效期符合產品規則 |
| 網路規則 | 允許與拒絕來源各一筆 | 結果與ACL預期一致 |
憑證不能只看檔名。比對CA指紋、broker伺服器名稱、client用途及有效期；伺服器名稱驗證核對SAN與實際連線名稱，client憑證則依產品的身分映射及授權規則，不可一律要求client帶同樣的DNS名稱。以測試憑證確認不受信任、過期及錯誤伺服器名稱會被拒絕，私鑰仍由受控機制保管。
管理介面回歸也要分開記錄。能登入不代表資料流通，資料流通也不代表角色權限正確。每項結果寫版本、時間、帳號角色、輸入和原始錯誤。若測試需重啟gateway，只在副本執行，並確認重啟後映射、憑證和網路規則是否仍載入。
回退依據與失敗先查
回退計畫要寫成條件，而不是一句「必要時還原」。可回退的依據包括升級檔案雜湊、完整設定副本、版本相容性、外部資料清單、憑證狀態、測試結果與變更窗口。若新版本只改了管理介面，仍要確認資料流和外部依賴；若映射差異會讓品質或數值失真，應以資料風險門檻觸發停止。
回退還要查設定格式及資料庫遷移是否可逆。新韌體匯出的設定不一定能被舊版讀取，資料庫升級也可能不支援降版；保留與舊版相容的升級前備份，並依原廠支援路徑還原。指紋只能辨認憑證，不能還原私鑰；報告的脫敏清單與受保護的正式備份要分開管理。
先依症狀分流。完全連不上broker時，查網路、TLS與身分授權；已收到payload但數值錯，查站號、功能碼、起點、長度、型別與縮放；數值對而品質錯，再比品質來源及逾時策略。每次只改一項並保留原始錯誤，避免邊改位址邊換憑證後無法解釋原因。
案例：升級後payload仍有溫度，但品質從Good變Stale。先比對word2 bit0位置和斷線策略，再查broker；若輸入樣本本身沒有品質位，應標記測試限制，不能用看起來合理的溫度證明通過。另一案例是管理登入成功但Modbus唯讀失敗，應檢查服務授權與來源ACL，不要因為帳號可登入就宣稱通訊正常。
本文不寫實機升級步驟，也不宣稱任何型號能自動回退。真實系統的備份格式、升級順序、服務重啟、授權檔與憑證保留都依產品手冊和變更程序；測試副本的結果不能直接推導生產環境已安全。
FAQ 離線驗收與官方依據
FAQ1：有設定匯出就等於完整備份嗎？答：不等於，外部憑證、DNS、ACL、broker授權與資料庫可能不在檔案中。
FAQ2：升級後數值相同就算映射沒變嗎？答：不算，仍要比對站號、範圍、型別、縮放、品質、topic與緩衝。
FAQ3：管理介面能登入就代表通訊通過嗎？答：不代表，登入、Modbus、MQTT和憑證是不同測試層。
FAQ4：失敗能直接回退嗎？答：只能在版本、備份、外部依賴與變更程序都具備時按官方流程回退。
離線驗收表應包含升級前後版本、設定雜湊、四筆固定Modbus樣本、正常與錯誤品質、MQTT輸出比較、斷線緩衝、憑證拒絕、管理角色與回退判定。每筆結果附原始資料和預期，不執行實際服務變更。驗收完成是差異可解釋、風險有責任人、回退條件可稽核。
參考：Ignition 8.1 to 8.3 Upgrade Guide（產品特定例）
參考：Installing and Upgrading Ignition（產品特定例）
Ignition官方升級指南提醒先做Gateway Backup、先在開發或測試環境升級，並指出主要版本可能影響Gateway Network、序列化、資料同步與儲存。這些是Ignition的產品文件例，不能直接宣稱所有Modbus到MQTT gateway都有相同備份或相容行為。本文虛構映射只用於離線比較。