接上一篇：詳解汽車遠(yuǎn)程升級(jí)（OTA )技術(shù)體系（二）

2.3  OTA 車載端架構(gòu)及關(guān)鍵技術(shù)

       2.3.1  車載端架構(gòu)

       OTA 車載端功能模塊主要包括 2 大部分，即 OTA 主控和 OTA 對(duì)象，如圖 2-3 所示。OTA 主控是車端 OTA 系統(tǒng)的核心，車端所有 OTA 業(yè)務(wù)邏輯均由主控實(shí)現(xiàn)，包括上報(bào)車輛信息、下載更新文件、升級(jí)包安裝、車輛狀態(tài)管理、人機(jī)交互等。

  圖 2-3  車載端功能模塊(參考 AutoSAR UCM)

         

（1） OTA 主控功能模塊

      按照車載端的工作流程，車載端的功能模塊包括：OTA 客戶端負(fù)責(zé)與云端進(jìn) 行數(shù)據(jù)交互；下載模塊負(fù)責(zé)升級(jí)包下載及分發(fā)；升級(jí)管理模塊負(fù)責(zé)升級(jí)過程的控制；升級(jí)代理負(fù)責(zé)執(zhí)行軟件刷寫或者軟件安裝；人機(jī)交互模塊負(fù)責(zé)升級(jí)信息提示、用戶輸入、升級(jí)過程的展示等，如表 2-7 所示。

表 2-7  OTA 主控功能模塊

（2） OTA 主控部署方案

      由于車輛 E/E 架構(gòu)的不同以及控制器升級(jí)方式的不同，功能模塊的部署方式  也有所不同。在傳統(tǒng)網(wǎng)關(guān)分布式架構(gòu)下，按照 OTA 主控部署的位置不同，大致分為：遠(yuǎn)程信息處理控制單元（TCU/T-BOX）方案、車載信息娛樂系統(tǒng)（IVI） 方案、網(wǎng)關(guān)（GW）方案，如圖 2-4 所示。前兩種方案，由 TCU/IVI 來進(jìn)行 ECU 的軟件刷寫，GW 僅作為路由實(shí)現(xiàn)數(shù)據(jù)的轉(zhuǎn)發(fā)，刷寫的鏈路比較長；后一種方案直接是由 GW 進(jìn)行刷寫，刷寫鏈路較短，但是 GW 并不能直接聯(lián)網(wǎng)，如果通過TCU/IVI 路由聯(lián)網(wǎng)必須增加安全機(jī)制，或者由 TCU/IVI 下載升級(jí)包后再分發(fā)至網(wǎng)關(guān)。

圖 2-4  傳統(tǒng)的 OTA 主控部署方案[1]   

 

      傳統(tǒng)網(wǎng)關(guān)分布式架構(gòu)下，由于控制器分散以及層級(jí)很深，導(dǎo)致在實(shí)現(xiàn) OTA  的過程中要進(jìn)行多次的轉(zhuǎn)發(fā)和透傳，容易導(dǎo)致數(shù)據(jù)丟失，增加升級(jí)失敗的概率。另外，需要在 OTA 主控內(nèi)部對(duì)軟件進(jìn)行備份，以保證升級(jí)失敗后，控制器可以被回滾。由于傳統(tǒng)控制器的芯片 Flash 和 RAM 容量小，實(shí)現(xiàn)也比較困難。

      對(duì)高算力和大帶寬數(shù)據(jù)傳輸?shù)钠惹行枨蠛汀败浖x汽車” 的理念驅(qū)動(dòng)， 各家 車企逐步開始進(jìn)行整車 E/E 架構(gòu)的升級(jí)和變革，引入了“ 中央計(jì)算平臺(tái)+區(qū)域控制 器”的中央集中式架構(gòu)，整體 E/E 架構(gòu)更加扁平化，有利于實(shí)現(xiàn)整車級(jí)的 OTA。中央控制器和域控制器之間采用的是以太網(wǎng)，數(shù)據(jù)傳輸能力增強(qiáng)；并且 SOA 架構(gòu)使得域控制器之間的交互機(jī)制更加靈活。針對(duì)區(qū)域控制器的 OTA 主控部署方案如圖 2-5 所示?？刹捎弥醒肟刂茊卧?CCU)作為升級(jí)主控，對(duì)于 ECU的刷寫有兩種方式：1)  區(qū)域控制器作為網(wǎng)關(guān)路由 UDS 報(bào)文，主控通過 UDS 升級(jí)區(qū)域控制器和該區(qū)域的所有傳感器和執(zhí)行器；2)區(qū)域控制器作為副主控，即升級(jí)主控先將該區(qū)域所有 ECU 的更新文件傳輸?shù)絽^(qū)域控制中，由區(qū)域控器完整自身升級(jí)以及與其連接的執(zhí)行器和傳感器的刷寫[1]。

圖 2-5  區(qū)域控制器方案

          

（3） ECU 端架構(gòu)方案

      車端 ECU 作為被升級(jí)對(duì)象， 在 OTA 系統(tǒng)中主要功能是按照一定的協(xié)議升級(jí) 主控接收目標(biāo)版本數(shù)據(jù)，將目標(biāo)版本數(shù)據(jù)寫入都指定的存儲(chǔ)區(qū)域中并引導(dǎo)運(yùn)行新版本軟件，從而實(shí)現(xiàn)自身軟件的更新。按 ECU 芯片類型及運(yùn)行軟件的特性可分為普通 ECU 和智能 ECU，而不同的 ECU 類型根據(jù)其內(nèi)存空間結(jié)構(gòu)又可以分為單分區(qū)和雙分區(qū)兩類。針對(duì)兩類 ECU 的兩種不同分區(qū)方案，ECU 端的升級(jí)可以大致歸類為 4 種方案，本小節(jié)將分別對(duì)其展開討論。

          

      ①  普通 ECU 單分區(qū)（Bootloader）升級(jí)方案

      普通 ECU 由于存儲(chǔ)空間有限，通常會(huì)采用流式刷寫的方式進(jìn)行升級(jí)，所謂流式刷寫即先將目標(biāo)刷寫空間的數(shù)據(jù)擦除，然后傳輸數(shù)據(jù)的同時(shí)，ECU 將已接收的數(shù)據(jù)寫入目的存儲(chǔ)地址，通過這種方式可以省去存儲(chǔ)升級(jí)包的內(nèi)存空間。傳統(tǒng)的 BootLoader 通過 UDS 協(xié)議刷寫的方式就是典型的流式刷寫。

      如圖 2-6 所示，普通 ECU 單分區(qū)結(jié)構(gòu)只有 BootLoader(啟動(dòng)引導(dǎo)程序)和應(yīng)用程序分區(qū)。該類型 ECU 需要更新時(shí)，首先將 ECU 從當(dāng)前運(yùn)行的應(yīng)用程序分區(qū)切 換至 BootLoader 運(yùn)行，在 BootLoader 中將應(yīng)用分區(qū)當(dāng)前版本數(shù)據(jù)擦除后，再從升級(jí)主控接收新版本數(shù)據(jù)并寫入應(yīng)用程序分區(qū)，數(shù)據(jù)檢驗(yàn)無誤后重啟 ECU 切換至應(yīng)用分區(qū)即可運(yùn)行新版本軟件。

圖  2-6 Bootloader 升級(jí)方案示意圖

      這種方案缺陷非常明顯， 由于只有一個(gè)應(yīng)用分區(qū)，升級(jí)前需要擦除，導(dǎo)致升 級(jí)過程 ECU 功能無法使用，如果更新過程異常中斷或者失敗也會(huì)導(dǎo)致功能無法使用。另外，這類升級(jí)通常需要在車輛非運(yùn)行狀態(tài)下才能進(jìn)行，在軟件數(shù)量較大所需升級(jí)時(shí)間較長的情況下，對(duì)車輛低壓電池供電，尤其對(duì)于燃油車挑戰(zhàn)較大。

      由于這用方案具有對(duì)內(nèi)存空間要求低、在 BootLoader 進(jìn)行更新不受應(yīng)用程 序干擾、實(shí)現(xiàn)簡單等優(yōu)勢，目前現(xiàn)有升級(jí)解決方案中大部分普通 ECU 的更新仍采用這種方式。

          

      ② 普通 ECU 雙分區(qū)（AB 分區(qū)）升級(jí)方案

      通過 AB 分區(qū)方案，為軟件的運(yùn)行版本和升級(jí)的目標(biāo)版本分配不同的存儲(chǔ)區(qū)，A 與 B 分區(qū)彼此為回滾，A 分區(qū)系統(tǒng)運(yùn)作提供服務(wù)時(shí)，刷新 B 分區(qū)，待 B 分區(qū)軟件刷寫完成通過校驗(yàn)后，下次重啟時(shí)載入 B 分區(qū)；若刷寫錯(cuò)誤或關(guān)聯(lián) ECU 刷新失敗，則仍以 A 分區(qū)系統(tǒng)啟動(dòng)，從而提高升級(jí)的可靠性，最小化回滾所需的時(shí)間。

      對(duì)于 AB 升級(jí)，其實(shí)有三種實(shí)現(xiàn)方案：第 1 類基于硬件輔助的 A/B 交換方 案。該方案要求 ECU 內(nèi)存足夠，而且支持地址重映射，也就是當(dāng)新版本軟件刷寫完成，通過更新映射地址來激活新版本軟件，即新版本軟件運(yùn)行的入出地址不變；第 2 類與第 1 類的差別在于 ECU 硬件不支持地址重映射，激活新版本軟件的入出地址會(huì)變化；第 3 類，基于外擴(kuò)內(nèi)存的 A/B 交換方案，該方案是需要額外的外擴(kuò)內(nèi)存，備份當(dāng)前版本軟件和舊版本軟件，新版本軟件會(huì)先刷寫原先的舊版本軟件空間，然后擦除 ECU 內(nèi)存的當(dāng)前版本軟件， 刷寫新版本軟件，完成激活。

AB 升級(jí)方案示意圖如圖2-7 所示

圖 2-7  AB 升級(jí)方案示意圖

          

      ③ 智能 ECU 單分區(qū)升級(jí)方案

      智能 ECU 是指具有高性能處理器，可運(yùn)行現(xiàn)代操作系統(tǒng)(如 Linux 、QNX、 Android 等)支持文件系統(tǒng)的控制器。這類控制器存儲(chǔ)介質(zhì)成本相對(duì)較低， 一般存儲(chǔ)空間較為充足，通常不會(huì)采用流式刷寫的方式進(jìn)行升級(jí)，而是先將升級(jí)包保存到 ECU 本地存儲(chǔ)，然后進(jìn)行安裝。智能 ECU 的升級(jí)通常采用私有協(xié)議，通過升級(jí)代理(update agent)接收 OTA 主控的升級(jí)包和控制命令，根據(jù)主控的指令使用 本地安裝程序(Installer)完成升級(jí)包的安裝。圖 2-8 為智能 ECU 升級(jí)單分區(qū)方案和雙分區(qū)方案的系統(tǒng)框架對(duì)比。

圖 2-8  智能 ECU 升級(jí)方案示意圖

      單分區(qū)方案通常包含主系統(tǒng)分區(qū)和更新子系統(tǒng)分區(qū)，以及用于存儲(chǔ)升級(jí)包的 緩存區(qū)域。正常系統(tǒng)功能相關(guān)軟件運(yùn)行在主系統(tǒng)分區(qū)，更新子系統(tǒng)是一個(gè)最小功能系統(tǒng)僅用于實(shí)現(xiàn)軟件安裝功能。該方案軟件更新流程：①系統(tǒng)正常運(yùn)行在主系統(tǒng)分區(qū)，同升級(jí)代理從 OTA 主控接收升級(jí)包文件，并保存在升級(jí)包緩存區(qū)， ② 升級(jí)包接收完成后由進(jìn)行解密、簽名認(rèn)證，③接收到 OTA 主控安裝命令后，升級(jí)代理將 ECU 切換至更新子系統(tǒng)，在子系統(tǒng)中通過安裝程序?qū)⑸?jí)包安裝到主系統(tǒng)分區(qū)，替換分區(qū)中的舊版本軟件， ④安裝完成后系統(tǒng)重啟切換到新的主分區(qū)軟件版本。

     ④ 智能 ECU 雙分區(qū)升級(jí)方案

      智能 ECU 雙分區(qū)方案與單分區(qū)相似，雙分區(qū)方案具有兩個(gè)結(jié)構(gòu)完全相同的 系統(tǒng)分區(qū)，兩個(gè)分區(qū)都具備升級(jí)代理和安裝程序的功能。系統(tǒng)默認(rèn)運(yùn)行在 A 系統(tǒng)分區(qū)，有新版本軟件需要更新時(shí)，可以通過升級(jí)代理從 OTA 主控接收升級(jí)包，并直接通過安裝程序?qū)⑵浒惭b到 B 系統(tǒng)分區(qū)中，整個(gè)更新過程不影響 ECU 正常功能使用。該方案軟件更新流程：①系統(tǒng)正常運(yùn)行在 A 系統(tǒng)分區(qū)，同升級(jí)代理從 OTA 主控接收升級(jí)包文件，并保存在升級(jí)包緩存區(qū)；②升級(jí)包接收完成后由進(jìn)行解密、簽名認(rèn)證；③接收到 OTA 主控安裝命令后，A 系統(tǒng)分區(qū)安裝程序?qū)⒕彺嬷械纳?jí)包安裝到 B 系統(tǒng)分區(qū)；④收到 OTA 主控激活命令后將系統(tǒng)啟動(dòng)引導(dǎo)標(biāo)志設(shè)置為 B 系統(tǒng)分區(qū)，⑤重啟系統(tǒng)后切換運(yùn)行 B 系統(tǒng)分區(qū)新安裝的軟件版本。

2.3.2  車載端關(guān)鍵技術(shù)       

（1） OTA 主控

      ① 電源管理：由于整車升級(jí)時(shí)間較長，且要確保車輛處于安全狀態(tài)， 因此需要管理升級(jí)過 程中各個(gè)控制器的工作狀態(tài)。如果車輛在熄火狀態(tài)下升級(jí)，考慮到長時(shí)間的電池電量消耗，在升級(jí)之前要對(duì)車輛的現(xiàn)有電量進(jìn)行檢查，升級(jí)過程中需要設(shè)計(jì)電源管理策略對(duì)升級(jí)與不升級(jí)的控制器、耗電的電器件進(jìn)行差異化管理。如果控制器由于不可控的意外導(dǎo)致升級(jí)異常，也應(yīng)處于低功耗模式，降低對(duì)整車電量的消耗。

      ② 車輛控制：對(duì)于影響車輛安全的升級(jí)，整個(gè)升級(jí)過程需要保持在一種安全狀態(tài)，因此， OTA 主控需要具備一定車輛功能控制能力，根據(jù)不同的升級(jí)類型，控制車輛的功能狀態(tài)。

      ③ 異常處理：在 OTA 傳輸過程中，外界干擾或者其他因素導(dǎo)致刷寫異?；蛘咧袛?，車載ECU 必須支持軟件回滾、斷點(diǎn)續(xù)傳、丟失重傳等處理機(jī)制。

          

（2）OTA 相關(guān)協(xié)議

      ① 標(biāo)準(zhǔn)協(xié)議：支持軟件刷寫和軟件升級(jí)的標(biāo)準(zhǔn)過程，方便 OTA 的開發(fā)、測試和集成，如傳統(tǒng) ECU 支持 UDS 協(xié)議、AUTOSARAP 的 UCM。

      UDS，即統(tǒng)一診斷服務(wù)，主要用于車外診斷設(shè)備通過車輛診斷口連接車內(nèi)總 線，并向控制器請求控制器內(nèi)部信息或向控制器傳輸數(shù)據(jù)。FBL 規(guī)范定義了控制器要實(shí)現(xiàn)軟件刷寫所需遵循的軟件架構(gòu)，并且定義了刷寫時(shí)需要使用哪些 UDS 服務(wù)，以及這些服務(wù)之間的順序關(guān)系。使用這些 UDS 診斷服務(wù)，可以命令控制器擦除原有內(nèi)存中的軟件數(shù)據(jù)，接收新的軟件數(shù)據(jù)并寫入到內(nèi)存，最終執(zhí)行新的軟件程序。傳統(tǒng) ECU 基本采用的都是基于 UDS 協(xié)議的軟件刷寫這種升級(jí)方式。

      AUTOSARAP ，即自適應(yīng)平臺(tái)，是由軟件更新配置管理器（UCM）提供了處理軟件更新請求的服務(wù)。UCM 負(fù)責(zé)在 AP 上更新，安裝，刪除和保留軟件記錄，實(shí)現(xiàn)了軟件包管理，確保以安全可靠的方式更新或修改 AP 上的軟件。UCM Master 提供了一種標(biāo)準(zhǔn)的平臺(tái)解決方案，通過與多個(gè) UCM 之間協(xié)調(diào)和分配車輛內(nèi)的包，實(shí)現(xiàn) AUTOSARAP 的軟件更新。

      ② 私有協(xié)議：除了升級(jí)遵從標(biāo)準(zhǔn)協(xié)議的傳統(tǒng)控制器，OTA 還需要支持智能 ECU 的升級(jí)。智能 ECU 通常帶有操作系統(tǒng)并且自身具有升級(jí)能力，作為升級(jí)對(duì)象，需要從 OTA 主控模塊或者云端獲取升級(jí)包，并與 OTA 主控進(jìn)行信息交互，實(shí)現(xiàn)升級(jí)的觸發(fā)和升級(jí)信息的反饋。對(duì)于這部分升級(jí)所涉及到的升級(jí)包分發(fā)和升級(jí)控制，現(xiàn)在并沒有統(tǒng)一的定義和標(biāo)準(zhǔn)，各家車企和供應(yīng)商的實(shí)現(xiàn)方案也各異。

          

（3） ECU 端升級(jí)技術(shù)

      ① 差分升級(jí)：相對(duì)于整包升級(jí)，差分升級(jí)方案不僅可以節(jié)省 MCU 內(nèi)部的資源空間、還可 以節(jié)省下載和升級(jí)過程中的功耗。從另一個(gè)角度說，通過將差分部分下發(fā)到設(shè)備保證了軟件版本的安全性。差分升級(jí)的流程如表 2-8，圖 2-9 、2-10 所示。

表 2-8  差分升級(jí)基本流程

      差分的實(shí)現(xiàn)方式主要有兩種：基于文本文件的差分和基于二進(jìn)制文件的差分， 其區(qū)分在于對(duì)比文件的差異，前者是基于邏輯上的，后者是基于物理上的。在升級(jí)時(shí)，通過與制作過程對(duì)應(yīng)的還原工具，將差分包還原后寫入到存儲(chǔ)器中，保證寫入后的內(nèi)容與目標(biāo)版本內(nèi)容一致。

圖 2-9 差分計(jì)算過程

      差分計(jì)算程序接收舊版本 v1.0 與新版本 v1.1 后生成差分升級(jí)包 v1.0-v1.1-update.patch。ECU 端從云端下載差分升級(jí)包v1.0-v1.1-update.patch 后，開始后續(xù)的差分還原操作。

圖 2-10  差分還原過程

      差分還原算法輸入?yún)?shù)為舊版本安裝包 v1.0 與差分升級(jí)包 v1.0-v1.1- update.patch。通過差分還原算法處理后得到最新的完整升級(jí)包 v1.1 。ECU 端安裝 v1.1 完整升級(jí)包實(shí)現(xiàn)升級(jí)目標(biāo)。

      ② 安全啟動(dòng)：安全啟動(dòng)(Secure Boot)用于保證固件啟動(dòng)的代碼受信任的安全保證機(jī)制，它 通過在引導(dǎo)加載過程中，對(duì)加載固件進(jìn)行檢驗(yàn)，從而防止加載和執(zhí)行惡意代碼。固件的每一步加載都經(jīng)過數(shù)字簽名認(rèn)證，而每一步簽名認(rèn)證的根證書中的密鑰需要與固化在芯片內(nèi)部不可修改的簽名密鑰匹配，從而行成一個(gè)完整信任鏈。

      ③ 安全校驗(yàn)：ECU 端需要具備對(duì)所安裝軟件包進(jìn)行完整性校驗(yàn)和真實(shí)性校驗(yàn)的能力，這要求 ECU 有能力對(duì)更新數(shù)據(jù)進(jìn)行簽名驗(yàn)證。傳統(tǒng)的 ECU 刷寫過程通常只通過循環(huán)冗余校驗(yàn)驗(yàn)證更新數(shù)據(jù)的完整性，而無法驗(yàn)證其真實(shí)性，存在被刷寫非法軟件的風(fēng)險(xiǎn)。

          

2.4  人機(jī)交互        

2.4.1  人機(jī)交互要素分析

      車端的人機(jī)交互主要體現(xiàn)在信息娛樂系統(tǒng)上，覆蓋到 OTA 的整個(gè)過程，包括信息提示、用戶確認(rèn)、關(guān)鍵信息顯示等。人機(jī)交互過程需要考慮的要素大致可以分為兩個(gè)方面，即法規(guī)符合性和使用便利性，如表 2-8 所示。

表 2-9  人機(jī)交互要素分類及示意

2.4.2  人機(jī)交互方式分類

     基于實(shí)際業(yè)務(wù)要求，各家 OEM 的 OTA 人機(jī)交互方式各有差異，本節(jié)共總結(jié) 6 種主流升級(jí)方式，并針對(duì)營運(yùn)車輛與非營運(yùn)車輛使用性質(zhì)不同，分別展開分析，具體如表 2-10 所示。

表 2-10  人機(jī)交互方式分類

 

   

轉(zhuǎn)自汽車電子與軟件