接上一篇：詳解汽車遠程升級（OTA )技術體系（二）
2.3 OTA 車載端架構及關鍵技術
2.3.1 車載端架構
OTA 車載端功能模塊主要包括 2 大部分，即 OTA 主控和 OTA 對象，如圖 2-3 所示。OTA 主控是車端 OTA 系統的核心，車端所有 OTA 業務邏輯均由主控實現，包括上報車輛信息、下載更新文件、升級包安裝、車輛狀態管理、人機交互等。
圖 2-3 車載端功能模塊(參考 AutoSAR UCM)
（1） OTA 主控功能模塊
按照車載端的工作流程，車載端的功能模塊包括：OTA 客戶端負責與云端進 行數據交互；下載模塊負責升級包下載及分發；升級管理模塊負責升級過程的控制；升級代理負責執行軟件刷寫或者軟件安裝；人機交互模塊負責升級信息提示、用戶輸入、升級過程的展示等，如表 2-7 所示。
表 2-7 OTA 主控功能模塊
（2） OTA 主控部署方案
由于車輛 E/E 架構的不同以及控制器升級方式的不同，功能模塊的部署方式 也有所不同。在傳統網關分布式架構下，按照 OTA 主控部署的位置不同，大致分為：遠程信息處理控制單元（TCU/T-BOX）方案、車載信息娛樂系統（IVI） 方案、網關（GW）方案，如圖 2-4 所示。前兩種方案，由 TCU/IVI 來進行 ECU 的軟件刷寫，GW 僅作為路由實現數據的轉發，刷寫的鏈路比較長；后一種方案直接是由 GW 進行刷寫，刷寫鏈路較短，但是 GW 并不能直接聯網，如果通過TCU/IVI 路由聯網必須增加安全機制，或者由 TCU/IVI 下載升級包后再分發至網關。
圖 2-4 傳統的 OTA 主控部署方案[1]
傳統網關分布式架構下，由于控制器分散以及層級很深，導致在實現 OTA 的過程中要進行多次的轉發和透傳，容易導致數據丟失，增加升級失敗的概率。另外，需要在 OTA 主控內部對軟件進行備份，以保證升級失敗后，控制器可以被回滾。由于傳統控制器的芯片 Flash 和 RAM 容量小，實現也比較困難。
對高算力和大帶寬數據傳輸的迫切需求和“軟件定義汽車” 的理念驅動， 各家 車企逐步開始進行整車 E/E 架構的升級和變革，引入了“ 中央計算平臺+區域控制 器”的中央集中式架構，整體 E/E 架構更加扁平化，有利于實現整車級的 OTA。中央控制器和域控制器之間采用的是以太網，數據傳輸能力增強；并且 SOA 架構使得域控制器之間的交互機制更加靈活。針對區域控制器的 OTA 主控部署方案如圖 2-5 所示。可采用中央控制單元(CCU)作為升級主控，對于 ECU的刷寫有兩種方式：1) 區域控制器作為網關路由 UDS 報文，主控通過 UDS 升級區域控制器和該區域的所有傳感器和執行器；2)區域控制器作為副主控，即升級主控先將該區域所有 ECU 的更新文件傳輸到區域控制中，由區域控器完整自身升級以及與其連接的執行器和傳感器的刷寫[1]。
圖 2-5 區域控制器方案
（3） ECU 端架構方案
車端 ECU 作為被升級對象， 在 OTA 系統中主要功能是按照一定的協議升級 主控接收目標版本數據，將目標版本數據寫入都指定的存儲區域中并引導運行新版本軟件，從而實現自身軟件的更新。按 ECU 芯片類型及運行軟件的特性可分為普通 ECU 和智能 ECU，而不同的 ECU 類型根據其內存空間結構又可以分為單分區和雙分區兩類。針對兩類 ECU 的兩種不同分區方案，ECU 端的升級可以大致歸類為 4 種方案，本小節將分別對其展開討論。
① 普通 ECU 單分區（Bootloader）升級方案
普通 ECU 由于存儲空間有限，通常會采用流式刷寫的方式進行升級，所謂流式刷寫即先將目標刷寫空間的數據擦除，然后傳輸數據的同時，ECU 將已接收的數據寫入目的存儲地址，通過這種方式可以省去存儲升級包的內存空間。傳統的 BootLoader 通過 UDS 協議刷寫的方式就是典型的流式刷寫。
如圖 2-6 所示，普通 ECU 單分區結構只有 BootLoader(啟動引導程序)和應用程序分區。該類型 ECU 需要更新時，首先將 ECU 從當前運行的應用程序分區切 換至 BootLoader 運行，在 BootLoader 中將應用分區當前版本數據擦除后，再從升級主控接收新版本數據并寫入應用程序分區，數據檢驗無誤后重啟 ECU 切換至應用分區即可運行新版本軟件。
圖 2-6 Bootloader 升級方案示意圖
這種方案缺陷非常明顯， 由于只有一個應用分區，升級前需要擦除，導致升 級過程 ECU 功能無法使用，如果更新過程異常中斷或者失敗也會導致功能無法使用。另外，這類升級通常需要在車輛非運行狀態下才能進行，在軟件數量較大所需升級時間較長的情況下，對車輛低壓電池供電，尤其對于燃油車挑戰較大。
由于這用方案具有對內存空間要求低、在 BootLoader 進行更新不受應用程 序干擾、實現簡單等優勢，目前現有升級解決方案中大部分普通 ECU 的更新仍采用這種方式。
② 普通 ECU 雙分區（AB 分區）升級方案
通過 AB 分區方案，為軟件的運行版本和升級的目標版本分配不同的存儲區，A 與 B 分區彼此為回滾，A 分區系統運作提供服務時，刷新 B 分區，待 B 分區軟件刷寫完成通過校驗后，下次重啟時載入 B 分區；若刷寫錯誤或關聯 ECU 刷新失敗，則仍以 A 分區系統啟動，從而提高升級的可靠性，最小化回滾所需的時間。
對于 AB 升級，其實有三種實現方案：第 1 類基于硬件輔助的 A/B 交換方 案。該方案要求 ECU 內存足夠，而且支持地址重映射，也就是當新版本軟件刷寫完成，通過更新映射地址來激活新版本軟件，即新版本軟件運行的入出地址不變；第 2 類與第 1 類的差別在于 ECU 硬件不支持地址重映射，激活新版本軟件的入出地址會變化；第 3 類，基于外擴內存的 A/B 交換方案，該方案是需要額外的外擴內存，備份當前版本軟件和舊版本軟件，新版本軟件會先刷寫原先的舊版本軟件空間，然后擦除 ECU 內存的當前版本軟件， 刷寫新版本軟件，完成激活。
AB 升級方案示意圖如圖2-7 所示
圖 2-7 AB 升級方案示意圖
③ 智能 ECU 單分區升級方案
智能 ECU 是指具有高性能處理器，可運行現代操作系統(如 Linux 、QNX、 Android 等)支持文件系統的控制器。這類控制器存儲介質成本相對較低， 一般存儲空間較為充足，通常不會采用流式刷寫的方式進行升級，而是先將升級包保存到 ECU 本地存儲，然后進行安裝。智能 ECU 的升級通常采用私有協議，通過升級代理(update agent)接收 OTA 主控的升級包和控制命令，根據主控的指令使用 本地安裝程序(Installer)完成升級包的安裝。圖 2-8 為智能 ECU 升級單分區方案和雙分區方案的系統框架對比。
圖 2-8 智能 ECU 升級方案示意圖
單分區方案通常包含主系統分區和更新子系統分區，以及用于存儲升級包的 緩存區域。正常系統功能相關軟件運行在主系統分區，更新子系統是一個最小功能系統僅用于實現軟件安裝功能。該方案軟件更新流程：①系統正常運行在主系統分區，同升級代理從 OTA 主控接收升級包文件，并保存在升級包緩存區， ② 升級包接收完成后由進行解密、簽名認證，③接收到 OTA 主控安裝命令后，升級代理將 ECU 切換至更新子系統，在子系統中通過安裝程序將升級包安裝到主系統分區，替換分區中的舊版本軟件， ④安裝完成后系統重啟切換到新的主分區軟件版本。
④ 智能 ECU 雙分區升級方案
智能 ECU 雙分區方案與單分區相似，雙分區方案具有兩個結構完全相同的 系統分區，兩個分區都具備升級代理和安裝程序的功能。系統默認運行在 A 系統分區，有新版本軟件需要更新時，可以通過升級代理從 OTA 主控接收升級包，并直接通過安裝程序將其安裝到 B 系統分區中，整個更新過程不影響 ECU 正常功能使用。該方案軟件更新流程：①系統正常運行在 A 系統分區，同升級代理從 OTA 主控接收升級包文件，并保存在升級包緩存區；②升級包接收完成后由進行解密、簽名認證；③接收到 OTA 主控安裝命令后，A 系統分區安裝程序將緩存中的升級包安裝到 B 系統分區；④收到 OTA 主控激活命令后將系統啟動引導標志設置為 B 系統分區，⑤重啟系統后切換運行 B 系統分區新安裝的軟件版本。
2.3.2 車載端關鍵技術
（1） OTA 主控
① 電源管理：由于整車升級時間較長，且要確保車輛處于安全狀態， 因此需要管理升級過 程中各個控制器的工作狀態。如果車輛在熄火狀態下升級，考慮到長時間的電池電量消耗，在升級之前要對車輛的現有電量進行檢查，升級過程中需要設計電源管理策略對升級與不升級的控制器、耗電的電器件進行差異化管理。如果控制器由于不可控的意外導致升級異常，也應處于低功耗模式，降低對整車電量的消耗。
② 車輛控制：對于影響車輛安全的升級，整個升級過程需要保持在一種安全狀態，因此， OTA 主控需要具備一定車輛功能控制能力，根據不同的升級類型，控制車輛的功能狀態。
③ 異常處理：在 OTA 傳輸過程中，外界干擾或者其他因素導致刷寫異常或者中斷，車載ECU 必須支持軟件回滾、斷點續傳、丟失重傳等處理機制。
（2）OTA 相關協議
① 標準協議：支持軟件刷寫和軟件升級的標準過程，方便 OTA 的開發、測試和集成，如傳統 ECU 支持 UDS 協議、AUTOSARAP 的 UCM。
UDS，即統一診斷服務，主要用于車外診斷設備通過車輛診斷口連接車內總 線，并向控制器請求控制器內部信息或向控制器傳輸數據。FBL 規范定義了控制器要實現軟件刷寫所需遵循的軟件架構，并且定義了刷寫時需要使用哪些 UDS 服務，以及這些服務之間的順序關系。使用這些 UDS 診斷服務，可以命令控制器擦除原有內存中的軟件數據，接收新的軟件數據并寫入到內存，最終執行新的軟件程序。傳統 ECU 基本采用的都是基于 UDS 協議的軟件刷寫這種升級方式。
AUTOSARAP ，即自適應平臺，是由軟件更新配置管理器（UCM）提供了處理軟件更新請求的服務。UCM 負責在 AP 上更新，安裝，刪除和保留軟件記錄，實現了軟件包管理，確保以安全可靠的方式更新或修改 AP 上的軟件。UCM Master 提供了一種標準的平臺解決方案，通過與多個 UCM 之間協調和分配車輛內的包，實現 AUTOSARAP 的軟件更新。
② 私有協議：除了升級遵從標準協議的傳統控制器，OTA 還需要支持智能 ECU 的升級。智能 ECU 通常帶有操作系統并且自身具有升級能力，作為升級對象，需要從 OTA 主控模塊或者云端獲取升級包，并與 OTA 主控進行信息交互，實現升級的觸發和升級信息的反饋。對于這部分升級所涉及到的升級包分發和升級控制，現在并沒有統一的定義和標準，各家車企和供應商的實現方案也各異。
（3） ECU 端升級技術
① 差分升級：相對于整包升級，差分升級方案不僅可以節省 MCU 內部的資源空間、還可 以節省下載和升級過程中的功耗。從另一個角度說，通過將差分部分下發到設備保證了軟件版本的安全性。差分升級的流程如表 2-8，圖 2-9 、2-10 所示。
表 2-8 差分升級基本流程
差分的實現方式主要有兩種：基于文本文件的差分和基于二進制文件的差分， 其區分在于對比文件的差異，前者是基于邏輯上的，后者是基于物理上的。在升級時，通過與制作過程對應的還原工具，將差分包還原后寫入到存儲器中，保證寫入后的內容與目標版本內容一致。
圖 2-9 差分計算過程
差分計算程序接收舊版本 v1.0 與新版本 v1.1 后生成差分升級包 v1.0-v1.1-update.patch。ECU 端從云端下載差分升級包v1.0-v1.1-update.patch 后，開始后續的差分還原操作。
圖 2-10 差分還原過程
差分還原算法輸入參數為舊版本安裝包 v1.0 與差分升級包 v1.0-v1.1- update.patch。通過差分還原算法處理后得到最新的完整升級包 v1.1 。ECU 端安裝 v1.1 完整升級包實現升級目標。
② 安全啟動：安全啟動(Secure Boot)用于保證固件啟動的代碼受信任的安全保證機制，它 通過在引導加載過程中，對加載固件進行檢驗，從而防止加載和執行惡意代碼。固件的每一步加載都經過數字簽名認證，而每一步簽名認證的根證書中的密鑰需要與固化在芯片內部不可修改的簽名密鑰匹配，從而行成一個完整信任鏈。
③ 安全校驗：ECU 端需要具備對所安裝軟件包進行完整性校驗和真實性校驗的能力，這要求 ECU 有能力對更新數據進行簽名驗證。傳統的 ECU 刷寫過程通常只通過循環冗余校驗驗證更新數據的完整性，而無法驗證其真實性，存在被刷寫非法軟件的風險。
2.4 人機交互
2.4.1 人機交互要素分析
車端的人機交互主要體現在信息娛樂系統上，覆蓋到 OTA 的整個過程，包括信息提示、用戶確認、關鍵信息顯示等。人機交互過程需要考慮的要素大致可以分為兩個方面，即法規符合性和使用便利性，如表 2-8 所示。
表 2-9 人機交互要素分類及示意
2.4.2 人機交互方式分類
基于實際業務要求，各家 OEM 的 OTA 人機交互方式各有差異，本節共總結 6 種主流升級方式，并針對營運車輛與非營運車輛使用性質不同，分別展開分析，具體如表 2-10 所示。
表 2-10 人機交互方式分類
轉自汽車電子與軟件
