手機更新失敗，重開機再來一次；車輛更新失敗，可能是路邊救援。車用 OTA 的工程難度不在「把檔案傳上車」，在於整套機制必須假設：傳輸會斷、電源會掉、韌體會有 bug、攻擊者會嘗試插手——然後在這些前提下仍然保證車輛可用。
防磚的核心：永遠留一條活路
A/B 分區（雙儲存區） 是最常見的策略：記憶體切成兩個完整的系統分區，更新永遠寫到「非執行中」的那一區。寫入與驗證全部完成之前，執行中的分區一個位元都不動——斷電、傳輸中斷、驗證失敗，下次開機還是從舊分區起來，車輛照常可用。
代價是儲存空間翻倍，所以資源受限的 ECU 會用就地更新＋備援開機路徑的折衷：至少保證 Bootloader 與最小恢復環境永遠可用，更新失敗時能退回「可刷寫狀態」等待重試（機制細節見 Flash Bootloader 怎麼運作）。
回滾（Rollback） 是防磚的另一半：新版本啟動後要通過自檢關卡（開機成功、關鍵服務就緒、通訊正常），連續失敗達到門檻就自動切回舊分區。這裡有個容易漏的細節——**回滾防護（Anti-Rollback）**與回滾是兩件事：前者防的是攻擊者刻意刷回有漏洞的舊版（用單調遞增的安全版本號擋），後者是故障時的自救。兩個機制要同時成立，版本號策略就要設計好：正常回滾用的舊版必須仍在允許的安全版本範圍內。
信任鏈：每一段都要驗
一包更新從雲端到 ECU，至少過四道驗證：
- 來源驗證：更新包由誰簽？車端只信任持有正確金鑰簽出的包
- 傳輸完整性：TLS 保護傳輸，但不能只靠 TLS——包本身的簽章讓「落地後」仍可驗
- 安裝前驗證：寫入目標分區後、切換之前，重新計算並比對簽章與雜湊
- 開機驗證：Secure Boot 逐段驗簽，簽章不符直接擋下（見 Secure Boot 技術）
金鑰管理是這條鏈的地基：簽章金鑰的保管、輪替、撤銷，以及車端信任錨（Root of Trust）的保護——這部分做壞，上面四道驗證都是紙糊的。
車這一端之外：UN R156 管的是「系統」
UN R156 要求的不是單次更新成功，而是軟體更新管理系統（SUMS）：
- 組態追蹤：每一台車上每一顆 ECU 現在跑什麼版本，要能回答——這正是 RXSWIN（軟體識別號）存在的理由
- 相容性評估：這包更新對哪些車型、哪些硬體版本、哪些既有軟體組合有效？推送前要有依據
- 型式認證影響判斷：更新有沒有改變已認證的功能？有的話走什麼程序
- 對車主的告知：更新內容、需要的條件（停車、電量）、失敗的後果
工程上這代表 OTA 不只是車端功能，而是雲端車隊管理＋車端更新代理＋流程與紀錄的整體——稽核看的是這一整套。
測試清單：往壞處測
OTA 的測試價值幾乎都在異常路徑：
- 傳輸中斷在各個階段（下載中、寫入中、驗證中、切換中）×斷點恢復
- 更新中斷電——特別是分區切換的臨界窗口
- 簽章錯誤、版本號回退、包內容與描述不符
- 新版本自檢失敗 → 回滾 → 回滾後的版本回報是否正確
- 車況前置條件（電量、駐車狀態）不滿足時的拒絕行為
這些情境在實車上又危險又難重現，HIL 環境（可控電源、可注入故障）是主戰場。
下一步
從更新代理、Secure Boot 到車隊組態管理，歐特莫夫（Vector Informatik 合作夥伴）協助建立可回滾、可稽核的 OTA 機制。
- 📄 解決方案：軟體定義車輛（SDV）解決方案
- 📬 預約一次現況盤點