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