電子發(fā)燒友App
OTA 技術(shù)最早應(yīng)用在 PC 電腦和移動手機(jī)行業(yè)，近幾年才開始在汽車行業(yè)中 廣泛應(yīng)用。然而車內(nèi)通訊網(wǎng)絡(luò)的復(fù)雜性、汽車電子系統(tǒng)的碎片化等因素限制著 OTA 技術(shù)整車范圍普及。本章從 OTA 定義與應(yīng)用場景、OTA 實(shí)現(xiàn)流程和“云-管-端”關(guān)鍵技術(shù)進(jìn)行研究，為行業(yè)從業(yè)者對 OTA 技術(shù)的設(shè)計開發(fā)、技術(shù)驗證和生產(chǎn)工作提供參考。
一、汽車 OTA 定義與應(yīng)用場景
1.1? OTA 定義及分類
OTA 是 Over the Air 的縮寫，通常指的是遠(yuǎn)程無線方式，OTA 技術(shù)可以理解為一種遠(yuǎn)程無線升級技術(shù)。在無特別說明情況下，本文所指的 OTA 是所有汽車遠(yuǎn)程升級的統(tǒng)稱。實(shí)現(xiàn) OTA 的基礎(chǔ)是車輛具備遠(yuǎn)程聯(lián)網(wǎng)功能，這意味著正是智能網(wǎng)聯(lián)汽車滲透率的快速增長，推動了 OTA 的快速普及。
OTA?的本質(zhì)是通過技術(shù)實(shí)現(xiàn)軟件更新，智能網(wǎng)聯(lián)汽車與傳統(tǒng)汽車的軟件升級不同之處在于，通過 OTA 技術(shù)，原始設(shè)備制造商（OEM）可以不用通過售后服務(wù)中心，而是直接遠(yuǎn)程連接目標(biāo)聯(lián)網(wǎng)車輛，將軟件更新推動至待升級的車輛。
隨著 OTA 的應(yīng)用越來越廣泛，針對升級對象的不同，延伸出來很多不同的 概念。人們在談及 OTA 相關(guān)業(yè)務(wù)時通常會在前面增加一個具體對象，用于表明使用 OTA 技術(shù)實(shí)現(xiàn)何種功能，比如遠(yuǎn)程軟件升級、遠(yuǎn)程固件升級、遠(yuǎn)程配置、遠(yuǎn)程數(shù)據(jù)更新等。然而在一些 OTA 解決方案中，已經(jīng)模糊了不同類型遠(yuǎn)程升級的邊界，將所有可升級的軟件對象抽象為軟件簇，而軟件簇包含了從小到配置字信息大到整個操作系統(tǒng)固件所有顆粒度的對象。并且，GB《汽車軟件升級通用 技術(shù)要求》中對軟件升級（Software Update）的定義已經(jīng)涵蓋了下述幾種 OTA 概念（遠(yuǎn)程診斷除外）。
1.1.1? 遠(yuǎn)程軟件升級(SOTA)
SOTA（Software Over-The-Air），即遠(yuǎn)程軟件升級，是指在操作系統(tǒng)的基礎(chǔ)上對應(yīng)用程序進(jìn)行遠(yuǎn)程升級。SOTA 通過遠(yuǎn)程下載并給車輛安裝“應(yīng)用程序升級包”，來實(shí)現(xiàn)控制器功能的一個“增量”更新， 一般應(yīng)用于娛樂系統(tǒng)和智駕系統(tǒng)。
SOTA 一般涉及應(yīng)用層小范圍的功能局部更新，不包括汽車核心系統(tǒng)，對整 車性能和安全影響較小，升級前置條件要求較低。SOTA 的增量更新策略， 可以大幅減小升級包文件大小、從而節(jié)約網(wǎng)絡(luò)流量和存儲空間。
1.1.2? 遠(yuǎn)程固件升級(FOTA)
FOTA（Firmware Over-The-Air），即遠(yuǎn)程固件升級，是指囊括車輛底層算法至頂層應(yīng)用的綜合升級，在不改變車輛原有配件的前提下，通過遠(yuǎn)程下載并寫入新的固件程序進(jìn)行設(shè)備升級。FOTA 包括驅(qū)動、系統(tǒng)、功能、應(yīng)用等的升級，與硬件的更換沒有關(guān)系。
FOTA 涉及車輛的核心系統(tǒng)，包括但不限于汽車動力控制系統(tǒng)、底盤電子系 統(tǒng)、自動駕駛系統(tǒng)、車身控制系統(tǒng)等核心零部件的控制系統(tǒng)，可以改變車輛的充放電、動能回收、加速性能、輔助駕駛系統(tǒng)邏輯等與深度駕控有關(guān)的體驗。理論上所有支持固件更新的電子控制單元（ECU）都可以涵蓋在 FOTA 范圍中。
1.1.3? 遠(yuǎn)程配置(COTA)
COTA（Configuration Over-The-Air），即遠(yuǎn)程配置，是指通過 OTA 的方式實(shí)現(xiàn)遠(yuǎn)程修改配置字，以達(dá)到修改軟件功能配置的目的。配置字是一組以數(shù)據(jù)標(biāo)識碼(DID)方式存儲在 ECU 上的數(shù)據(jù)，可通過診斷指令進(jìn)行讀取和修改。它根據(jù)特定的編碼規(guī)則與車輛功能特征碼一一對應(yīng)，通過配置可判斷車輛的功能配置，軟件可根據(jù)配置實(shí)現(xiàn)相應(yīng)的功能。遠(yuǎn)程配置常見的應(yīng)用場景是遠(yuǎn)程開啟和關(guān)閉某項功能，例如軟件訂閱功能。
1.1.4? 遠(yuǎn)程診斷/遠(yuǎn)程數(shù)據(jù)更新(DOTA)
DOTA 有兩種常見解釋：
DOTA(Data Over-The-Air)，即遠(yuǎn)程數(shù)據(jù)更新，是指一些獨(dú)立于軟件程序存在的數(shù)據(jù)包的更新，比如，地圖數(shù)據(jù)、語音數(shù)據(jù)和算法模型數(shù)據(jù)等。這類更新的特點(diǎn)是數(shù)據(jù)量比較大，更新流程相對獨(dú)立，比如，地圖數(shù)據(jù)通常由地圖應(yīng)用自行更新，而數(shù)據(jù)量也可能高達(dá)幾 G 到幾十G。
DOTA(Diagnostic Over-The-Air)，即遠(yuǎn)程診斷，通過云平臺實(shí)時數(shù)據(jù)采集監(jiān)控，主動性地檢查汽車系統(tǒng)異常問題，為遠(yuǎn)程問題修復(fù)與人工問題修復(fù)提供決策依據(jù)。遠(yuǎn)程診斷的觸發(fā)方式有兩種，一種是用戶在車輛上發(fā)現(xiàn)異常狀況的響應(yīng)式；另一種是周期性收集通訊網(wǎng)絡(luò)、應(yīng)用程序、硬件效能、使用操作記錄、系統(tǒng)程序等狀態(tài)信息，利用大數(shù)據(jù)后臺分析監(jiān)測故障。
1.1.5? 其他類型(XOTA)
隨著汽車智能化程度越來越高，除了車輛本身軟件的升級外，還可能會涉及 到外部智能設(shè)備交互功能的軟件更新，比如，智能鑰匙、AR 設(shè)備等。目前有些企業(yè)和組織將所有與車輛相關(guān)聯(lián)的軟件升級統(tǒng)稱為 XOTA，即 Everything Over-The-Air 的意思。
1.2 OTA 應(yīng)用場景
1.2.1?車輛生命周期維度
從開發(fā)者編譯生產(chǎn)出目標(biāo)版本軟件，到該軟件更新至目標(biāo)硬件設(shè)備上的全過 程涉及多個階段。在不同的階段，受產(chǎn)品形態(tài)和生產(chǎn)環(huán)境限制，所適用的軟件更新目的和手段也有所不同，如下表 2- 1 所示。目前，大部分車企的 OTA 主要集中在售后軟件更新，但不論是從效率上還是成本上 OTA 都體現(xiàn)出了巨大的優(yōu)勢。隨著 OTA 應(yīng)用越來越成熟，從單一的售后升級場景向更多的應(yīng)用場景發(fā)展是的必然趨勢。
表 2-1? 車輛生命周期維度的軟件更新應(yīng)用
?
| 車輛生命周期 | 軟件更新目的及手段 |
| 零部件階段 | ECU?供應(yīng)商產(chǎn)線是最早可以切換到最新軟件版本的節(jié)點(diǎn)，該節(jié)點(diǎn)進(jìn)行軟件切換可避免舊版本軟件繼續(xù)生產(chǎn)從而流向下游，稱為供應(yīng)商產(chǎn)線斷點(diǎn)。由于該階段還是零件狀態(tài)，通常只能通過芯片燒錄工具或者供應(yīng)商特定的工具進(jìn)行軟件更新，不適用OTA?方式。 |
| 總裝階段 |
由于零件需提前訂購，仍有一定量的零部件在供應(yīng)商產(chǎn)線斷點(diǎn)前流轉(zhuǎn)到?OEM?庫存，總裝線的電檢工位可以完成部分軟件的刷寫，稱之為 EOL(End of Line)軟件刷寫。然而 EOL軟件刷寫會影響產(chǎn)線節(jié)拍，導(dǎo)致 OEM 不會在產(chǎn)線進(jìn)行大量軟件刷寫。 總裝完成時車輛已經(jīng)具備 OTA 的條件，如果通過 OTA 方式進(jìn)行產(chǎn)線刷寫，可實(shí)現(xiàn)多車并線刷寫且不受產(chǎn)線工位影響，將極大提高產(chǎn)線軟件灌裝的效率。目前，已經(jīng)有個別企業(yè)實(shí)現(xiàn)總裝階段 OTA。 |
| 駁運(yùn)階段 | 車輛從總裝線下線到經(jīng)銷商庫存要經(jīng)過一定的駁運(yùn)過程。對于體量大且緊急程度不高的軟件，在總裝線灌裝會影響效率，如果利用駁運(yùn)過程進(jìn)行軟件更新，能降低對產(chǎn)線節(jié)拍的影響。OTA?使得利用駁運(yùn)過程更新軟件成為一種可能，但在駁運(yùn)過程中更新對電源供應(yīng)管理及車輛安全是否有影響需要更深一步考慮。 |
| 售前庫存 |
經(jīng)銷商通常有一定的庫存車輛，在正式銷售前庫存車輛可能需要對軟件版本進(jìn)行升級。以往是在進(jìn)行最終售前檢查時，將軟件更新到最新版本，存在更新時間長，影響用戶交付體驗等問題。 OTA 技術(shù)可將庫存車輛自動同步至最新版本，大大減少在交付過程中軟件更新的耗時，提升效率。 |
| 售后階段 |
過去的售后階段軟件更新，用戶需要將車駕駛到指定維修站完成更新。 通過OTA?技術(shù)，用戶可隨時隨地通過簡單操作完成軟件更新，使車輛“常用常新”?。目前已成為汽車企業(yè)增加用戶粘度和解決軟件售后問題及構(gòu)建生態(tài)服務(wù)體系的一個重要手段。 |
?
1.2.2? 軟件運(yùn)營管理維度
從軟件運(yùn)營管理的維度 OTA 的典型應(yīng)用場景如下表 2-2 所示。
表 2-2? 軟件運(yùn)營管理維度的軟件更新典型應(yīng)用場景
?
| 典型應(yīng)用場景 | 應(yīng)用場景描述 |
| 軟件召回 | 軟件引起重大功能缺陷時，例如存在功能安全、網(wǎng)絡(luò)安全/數(shù)據(jù)安全重大風(fēng)險、法規(guī)相關(guān)問題，通過OTA?方式召回，可以在短時間內(nèi)批量完成問題軟件的修復(fù)，盡可能降低軟件缺陷造成的影響，效率高且成本低。 |
| 問題修復(fù) | 對于一些非嚴(yán)重性問題，通過OTA?方式，可以周期性推送軟件版本，進(jìn)行問題修復(fù)。 |
| 性能優(yōu)化 | 與缺陷修復(fù)類似，OTA?方式的便捷性，使得性能優(yōu)化類的軟件更新也逐漸得以重視，目前已經(jīng)是常見的OTA?場景之一。 |
| 軟件個性化定制 | 此應(yīng)用場景通常為COTA?應(yīng)用，比如用戶可根據(jù)個人需求，完成怠速調(diào)整、車下啟動/熄火，自動啟停等參數(shù)的設(shè)置更新。 |
| 新功能交付 | OTA ?使得售后軟件功能持續(xù)迭代成為可能。通過?OTA ?可新增功能的多少，已成為用戶評價OEM?的對重要指標(biāo)之一。 |
| 付費(fèi)功能訂閱 | 功能訂閱是新功能交付應(yīng)用場景衍生出來的一種新的行業(yè)形態(tài)。車企在售賣車輛之后，針對部分新增軟件功能以付費(fèi)方式供用戶購買使用。這使得車企除了車輛銷售之外，有了新的盈利可能性，這也是目前汽車企業(yè)非常樂于探索的一種?OTA?應(yīng)用場景。 |
?
二、 汽車 OTA 技術(shù)體系? ?
2.1? OTA 實(shí)現(xiàn)流程
汽車軟件更新的本質(zhì)是將供應(yīng)商或者 OEM 內(nèi)部開發(fā)部門編譯出來的軟件或 者數(shù)據(jù)替換當(dāng)前車輛 ECU 中的版本，以實(shí)現(xiàn)預(yù)期的特定功能。因此，汽車軟件升級所需要的核心工作是建立遠(yuǎn)程傳輸鏈路并實(shí)現(xiàn) OEM 云端系統(tǒng)遠(yuǎn)程更新車輛 ECU 中的軟件數(shù)據(jù)。同時，為了準(zhǔn)確、安全、可靠地完成 ECU 軟件的更新，OTA 系統(tǒng)需要云端管理系統(tǒng)對軟件、升級對象進(jìn)行管理，以實(shí)現(xiàn)人工操作到自動化的轉(zhuǎn)變；車端系統(tǒng)需要完成軟件數(shù)據(jù)的接收和分發(fā)工作，并保證無專業(yè)技師操作情況下的安全升級。?
圖 2-1：OTA 實(shí)現(xiàn)流程(來源 AutoSAR) ? ?
圖2-1 是一個典型的 OTA 系統(tǒng)框架，包含了三個基本要素，即云端的 OTA 平臺、車端 OTA 主控、OTA 對象。其中：OTA 云平臺負(fù)責(zé) OTA 升級包管理、車輛管理及 OTA 發(fā)布等功能，車端 OTA 主控負(fù)責(zé)從 OTA 云平臺下載升級包并將其刷寫到目標(biāo) ECU ，OTA 升級對象即最終軟件刷寫的主體，從主控接收軟件并完成自身軟件更新。OTA 的基本實(shí)現(xiàn)流程（圖2-1）可歸納為下表 2-3 所示步驟。
表 2-3? OTA 的基本實(shí)現(xiàn)流程
?
| 步驟 | 內(nèi)容 |
| 1.??升級包制作 | ECU?供應(yīng)商或車企內(nèi)部開發(fā)團(tuán)隊完成軟件開發(fā)并編譯產(chǎn)生新版本的軟件， 通過約定的方式制作成升級包。 |
| 2.上傳軟件 | 供應(yīng)商或?OEM??內(nèi)部開發(fā)部門生產(chǎn)的軟件驗證合格后，經(jīng)由產(chǎn)品生命周期管理系統(tǒng)(PLM)或類似的系統(tǒng)流轉(zhuǎn)到OTA云平臺，供更新使用。 |
| 3.OTA??任務(wù)發(fā)?布 | 發(fā)布過程是選定特定軟件，通知至指定目標(biāo)車輛，通常由OTA?運(yùn)營人員完成。發(fā)布之后的軟件通常經(jīng)過一系列安全處理后傳至專門的文件服務(wù)端供車輛下載。 |
| 4.下載升級包 | OTA發(fā)布完成后，通常OTA云平臺需要通知車端OTA主控執(zhí)行軟件更新動作，OTA主控根據(jù)與云平臺命令交互獲取信息，從指定文件服務(wù)端地址下載所需要的升級包；不同的OTA系統(tǒng)可能由于升級對象升級包大小原因，OTA主控不會直接下載升級包而是通過相關(guān)命令控制目標(biāo)ECU?完成其所需升級包的下載。 |
| 5.安裝 | 安裝過程是由?OTA??主控根據(jù)約定的協(xié)議，將目標(biāo)升級軟件刷寫到對應(yīng)?ECU??指定存儲介質(zhì)。ECU?硬件不同、通信方式不同，通常安裝的過程會有所差異。 |
| 6.校驗 | 軟件安裝前后需要進(jìn)行完整性校驗及真實(shí)性校驗。完整性校驗保證安裝過程傳輸?shù)臄?shù)據(jù)沒有被篡改，真實(shí)性校驗保證所安裝軟件沒有被仿冒偽造。 |
| 7.激活 | 根據(jù)ECU結(jié)構(gòu)不同，安裝步驟可能還會包含激活操作，即雙備份分區(qū)ECU更新完成后進(jìn)行分區(qū)切換。此外，OTA主控除了處理控制安裝過程外，還需要控制車輛的狀態(tài)，保證升級過程車輛的安全。 |
| 8.回滾 | 針對升級異常的情況，將軟件版本恢復(fù)到升級前版本的過程，主要目的在于保證升級失敗ECU功能仍可用。 |
| 9.狀態(tài)上報 | OTA主控需要將升級狀態(tài)同步到OTA云平臺，保證?OTA云平臺可以根據(jù)車輛最新狀態(tài)編排升級任務(wù)。同時，可根據(jù)業(yè)務(wù)實(shí)際情況，同步更新過程中各階段狀態(tài)至OTA云平臺，以便更精準(zhǔn)地控制升級。 |
?
2.2? OTA 云平臺架構(gòu)及關(guān)鍵技術(shù) ???
OTA 云平臺是支撐 OTA 業(yè)務(wù)正常運(yùn)行的相關(guān)云端系統(tǒng)的集合，既包括實(shí)現(xiàn) OTA 核心功能的 OTA 服務(wù)端，也包括了其他關(guān)聯(lián)系統(tǒng)如企業(yè) IT 管理系統(tǒng)、安全服務(wù)端、web 控制臺以及文件服務(wù)端。OTA 云平臺業(yè)務(wù)范圍涉及軟硬件生命周期管理、業(yè)務(wù)流程整合、軟件遠(yuǎn)程分發(fā)等軟件更新所有相關(guān)業(yè)務(wù)，是一個軟件升級管理體系(SUMS)。
2.2.1? 云平臺架構(gòu)
基于 OTA 產(chǎn)品業(yè)務(wù)形態(tài)，結(jié)合系統(tǒng)組件之間松耦合高內(nèi)聚的標(biāo)準(zhǔn)，行業(yè)內(nèi) 普遍將云平臺設(shè)計為 4 層的分層架構(gòu)型式，如圖 2-2 所示，包括前端展示層、路由網(wǎng)關(guān)層、業(yè)務(wù)服務(wù)層和數(shù)據(jù)存儲層。前端展示層是系統(tǒng)與用戶交互的 web 應(yīng)用層，用戶訪問和操作云平臺系統(tǒng)的交互接口；網(wǎng)關(guān)路由層包括指令控制層和網(wǎng)關(guān)接入層，是云平臺與車端建立通信鏈接以及控制車端流程的通信中間件；業(yè)務(wù)服務(wù)層負(fù)責(zé)所有 OTA 相關(guān)業(yè)務(wù)邏輯的處理，包括車輛、軟件包管理、策略管理等諸多業(yè)務(wù)模塊，是 OTA 云平臺的核心；數(shù)據(jù)存儲層負(fù)責(zé) OTA 所有業(yè)務(wù)相關(guān)數(shù)據(jù)存儲，包括基本的數(shù)據(jù)庫集群數(shù)據(jù)緩存和大文件存儲等。
圖 2-2? OTA 云服務(wù)框架圖
（1） 前端展示層
前端展示層的劃分，是基于前后端分離開發(fā)方式設(shè)計的架構(gòu)分層模式，主要 負(fù)責(zé) Web 端用戶交互頁面的功能。核心思想是前端頁面通過調(diào)用后端的接口并進(jìn)行交互，前端專注于交互頁面的開發(fā)，業(yè)務(wù)邏輯由后端負(fù)責(zé)。對 OTA 云平臺而言，前端展示層可以理解為業(yè)務(wù)服務(wù)層的用戶交互接口，其展示功能與具體業(yè)務(wù)功能一一對應(yīng)。
? ? ? ? ?
?
（2） 指令控制層
各業(yè)務(wù)平臺與網(wǎng)關(guān)接入層的連通介質(zhì)，接收來自業(yè)務(wù)系統(tǒng)指令并將指令發(fā)送 至網(wǎng)關(guān)可訪問的緩存中，接收來自網(wǎng)關(guān)回寫的升級狀態(tài)至各業(yè)務(wù)系統(tǒng)可訪問的消息隊列中。
（3） 網(wǎng)關(guān)接入層
針對不同的數(shù)據(jù)格式及上層需求，接收封裝來自車載終端傳輸?shù)臄?shù)據(jù)，并流
向緩存、消息隊列等中間件。
（4）業(yè)務(wù)服務(wù)層
業(yè)務(wù)服務(wù)層是 OTA 服務(wù)所有業(yè)務(wù)及相關(guān)流程管理功能在云平臺端的實(shí)現(xiàn)， 除了車輛管理服務(wù)、軟件包服務(wù)、版本服務(wù)、策略管理和任務(wù)管理 5 個支撐 OTA 的核心功能外，還包括關(guān)聯(lián)系統(tǒng)審批、數(shù)據(jù)對接、信息安全服務(wù)、測試、統(tǒng)計分析、日志查詢等重要輔助功能。由于不同的企業(yè)內(nèi)部管理存在差異，云平臺所支持的輔助業(yè)務(wù)可能存在較大差異，常見服務(wù)列舉見表 2-4。
表 2-4?常見服務(wù)舉例
?
| 常見服務(wù) | 業(yè)務(wù)內(nèi)容 |
| 車輛管理服務(wù) | 維護(hù)所有可升級車輛的信息，包括品牌、車型、配置以及每個單車所包含的可升級設(shè)備信息等。 |
| 軟件包服務(wù) | 用于控制器升級包的在線管理、差分包的制作及管理，相當(dāng)于OTA?的倉庫管理，需要維護(hù)不同車型所有?ECU?不同版本的所有軟件實(shí)體，包含軟件包的簽名加密以及各版本與其關(guān)聯(lián)關(guān)系等。 |
| 版本服務(wù) | 包括基線版本管理、軟硬件版本及版本號管理，每個軟硬件版本的依賴條件管理，并維護(hù)每一個軟件版本所適用的品牌、車型、配置等。 |
| 策略管理服務(wù) | 需適配各種復(fù)雜軟件更新，提供靈活的設(shè)備群組管理、下發(fā)條件配置，支持升級任務(wù)策略配置，滿足各類升級需求。 |
| 任務(wù)管理服務(wù) | 對升級推送任務(wù)的管理，每次選擇特定版本的軟件包向指定車輛推送即可視為一個任務(wù)。任務(wù)管理包含：1）任務(wù)條件設(shè)定，如任務(wù)所適用的車型、升級模式、升級策略、任務(wù)有效時間；?2）發(fā)布車輛選擇，指定將該任務(wù)適用于哪些車輛，可加入黑白名單，批量導(dǎo)入汽車唯一識別碼(VIN?碼)、標(biāo)簽匹配等業(yè)務(wù)邏輯；3）任務(wù)的基本操作，如創(chuàng)建、暫停、取消等。 |
| 審批服務(wù) | 功能在于把傳統(tǒng)的線下軟件發(fā)布的審批流程通過?OTA?平臺實(shí)現(xiàn)在線化，達(dá)到自動流傳，提高效率的作用。 |
| 數(shù)據(jù)對接服務(wù) | 數(shù)據(jù)對接的系統(tǒng)包括?PLM、MES、EOL、DMS、ADS，數(shù)據(jù)對接涉及到軟件版本信息獲取、車輛信息初始化、用戶信息、售后信息同步等。 |
| 信息安全服務(wù) | 用于保證OTA?的安全，主要通過與PKI?系統(tǒng)對接完成升級包的簽名加密，車端設(shè)備的身份認(rèn)證，通信鏈路的認(rèn)證和加密。 |
| 安全訪問控制?服務(wù) | 通過云平臺端的安全訪問控制服務(wù)在線化管理會話控制的安全算法，防止未授權(quán)的系統(tǒng)或者設(shè)備對車輛?ECU?進(jìn)行軟件更新，更利于對每個ECU?實(shí)現(xiàn)獨(dú)立的安全訪問方案。 |
| 測試服務(wù) | 用于支持OTA?的測試，主要包括OTA?升級策略、升級配置信息和任務(wù)等，以保證升級效果符合期望目標(biāo)。 |
| 統(tǒng)計分析服務(wù) | 用于動態(tài)統(tǒng)計OTA?升級狀態(tài)，可以通過可視化展示升級狀態(tài)，快速了解升級任務(wù)進(jìn)度。同時，可以根據(jù)統(tǒng)計分析結(jié)果動態(tài)調(diào)整?OTA?任務(wù)推送的車輛數(shù)，保證系統(tǒng)資源和售后資源得到最有利的分配。 |
| 日志查詢服務(wù) | 包含云端日志、車云交互日志以及車端遠(yuǎn)程日志等查詢功能。 |
| 基礎(chǔ)信息服務(wù) | 主要針對OTA?云平臺本身的信息管理，如賬號權(quán)限管理等。 |
?
（5） PKI 系統(tǒng)
公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure，PKI）：基于公鑰密碼體制實(shí)現(xiàn)數(shù)字證書的發(fā)布、撤銷和管理等功能，并為數(shù)字證書用戶提供相應(yīng)服務(wù)的系統(tǒng)。其目的在于創(chuàng)造、管理、分配、使用、存儲以及撤銷數(shù)字證書，可以用來保證通信對象的身份真實(shí)性、軟件程序的來源真實(shí)性和完整性、通信行為的不可否認(rèn)性等。
PKI 在 OTA 系統(tǒng)中的作用主要在于為相關(guān)實(shí)體發(fā)放數(shù)字證書，通過密碼技術(shù)保證升級包和升級過程的安全。主要包括車輛證書、設(shè)備證書、供應(yīng)商證書等 的申請和校驗；云端對車端身份認(rèn)證，車端對云端身份認(rèn)證；升級包的安全認(rèn)證等。
（6）外部數(shù)據(jù)系統(tǒng)
外部數(shù)據(jù)對接的系統(tǒng)可能包括整車生命周期配置系統(tǒng)（VLCS）、遠(yuǎn)程診斷系 統(tǒng)、軟件可售系統(tǒng)及一些其他支撐系統(tǒng)組成。主機(jī)廠研發(fā)部門需要根據(jù)車型的功能規(guī)劃確定該車型所對應(yīng)的軟硬件相關(guān)配置。需要進(jìn)行軟件更新時， 從 VLCS 系統(tǒng)中確定所涉及的車型和影響的功能范圍，并依據(jù)確定好的范圍， 從物料信息管理系統(tǒng)(BOM)中申請軟件物料號作為版本控制依據(jù)， 供應(yīng)商軟件釋放后經(jīng)由產(chǎn)品生命周期管理系統(tǒng)（PLM）系統(tǒng)通過驗證審批后流轉(zhuǎn)到 OTA 服務(wù)端供升級使用使用。OTA 服務(wù)端管理設(shè)備中初始的車輛信息，可通過對接 MES 在車輛下線檢驗合格后將新生產(chǎn)車輛自動注冊到 OTA 云平臺，所有升級目標(biāo)車輛應(yīng)保證是已 注冊車輛。除此之外，根據(jù)實(shí)際需要還可能會從汽車經(jīng)銷商管理系統(tǒng)（DMS）系 統(tǒng)獲取經(jīng)銷商及售后服務(wù)站點(diǎn)信息，售后系統(tǒng)通常也需要與 OTA 系統(tǒng)關(guān)聯(lián)以同步最新版本信息以及線下配置更改信息等。
另外， OTA 系統(tǒng)在升級前可通過遠(yuǎn)程診斷系統(tǒng)獲得最新的 ECU 配置信息及 狀態(tài)信息，并且當(dāng)遠(yuǎn)程診斷系統(tǒng)發(fā)現(xiàn)問題后，可以通過 OTA 系統(tǒng)下發(fā)經(jīng)過測試驗證的補(bǔ)丁包來修復(fù)。對于一些有運(yùn)營需求的主機(jī)廠來說，通過 OTA 系統(tǒng)配合軟件可售系統(tǒng)，可以實(shí)現(xiàn)軟件付費(fèi)升級、功能付費(fèi)使用等后向運(yùn)營，真正實(shí)現(xiàn)“千車千面”、“用戶定義汽車”。
（7）數(shù)據(jù)存儲層
數(shù)據(jù)存儲層包括數(shù)據(jù)庫集群、緩存和存儲節(jié)點(diǎn)，分別用于存儲 OTA 云平臺 不同類型的數(shù)據(jù)。其中，數(shù)據(jù)庫集群，主要用于存儲車輛信息版本信息等關(guān)系型數(shù)據(jù)；緩存，為了解決數(shù)據(jù)庫性能瓶頸問題，可以通過多架設(shè)一層緩存層來減少對數(shù)據(jù)庫的直接訪問；存儲節(jié)點(diǎn)，針對較大的升級包、配置文件等需要提供車端下載的文件，通常可以存儲在分布式存儲節(jié)點(diǎn)上。
2.2.2? 關(guān)鍵技術(shù)
（1）安全技術(shù)
OTA 服務(wù)端以及企業(yè) IT 管理系統(tǒng)、安全服務(wù)端、web 控制臺、文件服務(wù)端 等關(guān)聯(lián)系統(tǒng)，會面臨傳統(tǒng)云平臺的所有安全威脅。為保證 OTA 升級的安全性，常用安全技術(shù)如表 2-5 所示。? ?
?
表 2-5? OTA 云平臺常用安全技術(shù)
?
| 名稱 | 技術(shù)要點(diǎn) |
| PKI?簽名驗簽技術(shù) | 在升級過程中，OTA?系統(tǒng)采用數(shù)字證書簽名方案，終端從?OTA?云平臺下載的升級包、升級腳本均經(jīng)過簽名處理，升級前需驗簽正確后才進(jìn)行升級。 |
| 安全訪問控制 | 通過云平臺端的安全訪問控制服務(wù)，OTA?車載系統(tǒng)采用網(wǎng)關(guān)內(nèi)置或終端內(nèi)置的安全訪問函數(shù)方式實(shí)現(xiàn)校驗方案，只有全訪問驗證通過，ECU?才會執(zhí)行后續(xù)對應(yīng)安全訪問等級要求的請求。 |
| 數(shù)字證書身份認(rèn)證及信息安全 | PKI?數(shù)字證書用于實(shí)現(xiàn)車輛身份管理，車、云身份認(rèn)證；用于?OTA?云平臺與車端上下行消息的加解密、簽名、驗簽。 |
| 數(shù)據(jù)安全 | 通過在組織中建立數(shù)據(jù)安全管理體系、建設(shè)云平臺數(shù)據(jù)全生命周期的主動安全防護(hù)和數(shù)據(jù)安全運(yùn)營能力，保護(hù)數(shù)據(jù)安全。 |
?
（2） OTA 技術(shù)
OTA 系統(tǒng)常用升級技術(shù)如表 2-6 所示。
表 2-6? OTA 云平臺常用升級技術(shù)
?
| OTA技術(shù) | 技術(shù)要點(diǎn) |
| 升級包管理 | 用于控制器升級包的在線管理、差分包的制作及管理。 |
| 腳本管理 | 用于控制器升級執(zhí)行腳本文件的在線管理。 |
| 升級策略管理 | 用于升級任務(wù)執(zhí)行條件（目標(biāo)版本對目標(biāo)車輛、整車狀態(tài)、控制器狀態(tài)、時間、信號等影響因素的依賴關(guān)系）的在線管理。 |
| 升級效率管理 | 制定相關(guān)策略提升升級效率，降低升級失敗次數(shù)。并通過日志分析其原因， 進(jìn)行技術(shù)迭代開發(fā)。 |
?
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ù)邏輯均由主控實(shí)現(xiàn)，包括上報車輛信息、下載更新文件、升級包安裝、車輛狀態(tài)管理、人機(jī)交互等。
?
?
圖 2-3? 車載端功能模塊(參考 AutoSAR UCM)
（1） OTA 主控功能模塊
按照車載端的工作流程，車載端的功能模塊包括：OTA 客戶端負(fù)責(zé)與云端進(jìn) 行數(shù)據(jù)交互；下載模塊負(fù)責(zé)升級包下載及分發(fā)；升級管理模塊負(fù)責(zé)升級過程的控制；升級代理負(fù)責(zé)執(zhí)行軟件刷寫或者軟件安裝；人機(jī)交互模塊負(fù)責(zé)升級信息提示、用戶輸入、升級過程的展示等，如表 2-7 所示。
表?2-7? OTA 主控功能模塊
?
| 功能模塊 | 功能描述 |
| 升級管理（OTA?Manager） |
作為?OTA?的核心，管理車輛所有?ECU?的更新過程，控制著將固件更新分發(fā)到?ECU，并告知?ECU?何時執(zhí)行更新，這在多個?ECUs?需要同時更新的情況下尤為重要。 OTA?任務(wù)下發(fā)到車輛后，OTA ???Manager?需要判斷車輛條件，對于不符合條件的車輛，需要中止升級任務(wù)并上報給云平臺，安全完成軟件升級后，?也要上報云端。若想實(shí)現(xiàn)單車定制化功能，OTA?Manager?還需能夠靈活定義升級的具體范圍，升級時機(jī)，升級內(nèi)容，提示事項，失敗后給用戶的失敗處理提示等。 |
| OTA?客戶端 | 負(fù)責(zé)?OTA?主控與?OTA?云平臺交互，包括下發(fā)?OTA?云平臺的?OTA?控制命令，反饋控制命令的執(zhí)行結(jié)果，發(fā)起更新檢查請求，同步升級過程狀態(tài)等。 |
| 下載管理模塊 | 負(fù)責(zé)從文件服務(wù)端下載升級所需升級包和文件，支持?jǐn)帱c(diǎn)續(xù)傳，保證升級包可以分多次下載，同時也避免部分重復(fù)下載造成流量浪費(fèi)。 |
| 安裝模塊 | 負(fù)責(zé)將升級包安裝到對應(yīng)的?ECU。不同的?ECU?類型會需要不同的安裝模塊，比如?FBL?安裝模塊用于僅支持?Bootloader?升級?ECU，AB?安裝模塊用于支持?AB swap??雙備份分區(qū)升級方式的?ECU, ?其他安裝模塊主要是指一些采用私有協(xié)議進(jìn)行升級的智能?ECU |
| 車輛狀態(tài)管理 |
負(fù)責(zé)確保車輛在安全狀態(tài)下進(jìn)行升級，其功能主要包括兩個: ① 車輛狀態(tài)判斷，通過預(yù)設(shè)條件判斷判斷車輛狀態(tài)是否滿足?OTA?的要求，比如判斷車輛的電池電量是否足以支持完成升級、車輛是否處于非行駛狀態(tài)等，這些條件通常是通過監(jiān)控車輛相關(guān)的信號實(shí)現(xiàn)； ② 車輛狀態(tài)控制, ?通過特定的控制命令或者信號值，限制車輛非升級必須的功能，保證升級過程車輛狀態(tài)不可被改變，從而維持在安全狀態(tài)。 |
| 人機(jī)交互接口 | 人機(jī)交互接口是?OTA?主控通過相關(guān)顯示設(shè)備與用戶進(jìn)行交互的操作接口，控制?OTA?相關(guān)信息在車內(nèi)的娛樂主機(jī)顯示屏或者手機(jī)?APP?等設(shè)備上的顯示。 |
?
（2） OTA 主控部署方案
由于車輛 E/E 架構(gòu)的不同以及控制器升級方式的不同，功能模塊的部署方式? 也有所不同。在傳統(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 下載升級包后再分發(fā)至網(wǎng)關(guān)。
圖 2-4? 傳統(tǒng)的 OTA?主控部署方案[1] ??
?
傳統(tǒng)網(wǎng)關(guān)分布式架構(gòu)下，由于控制器分散以及層級很深，導(dǎo)致在實(shí)現(xiàn) OTA ?的過程中要進(jìn)行多次的轉(zhuǎn)發(fā)和透傳，容易導(dǎo)致數(shù)據(jù)丟失，增加升級失敗的概率。另外，需要在 OTA 主控內(nèi)部對軟件進(jìn)行備份，以保證升級失敗后，控制器可以被回滾。由于傳統(tǒng)控制器的芯片 Flash 和 RAM 容量小，實(shí)現(xiàn)也比較困難。
對高算力和大帶寬數(shù)據(jù)傳輸?shù)钠惹行枨蠛汀败浖x汽車” 的理念驅(qū)動， 各家 車企逐步開始進(jìn)行整車 E/E 架構(gòu)的升級和變革，引入了“ 中央計算平臺+區(qū)域控制 器”的中央集中式架構(gòu)，整體 E/E 架構(gòu)更加扁平化，有利于實(shí)現(xiàn)整車級的 OTA。中央控制器和域控制器之間采用的是以太網(wǎng)，數(shù)據(jù)傳輸能力增強(qiáng)；并且?SOA 架構(gòu)使得域控制器之間的交互機(jī)制更加靈活。針對區(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é)議升級 主控接收目標(biāo)版本數(shù)據(jù)，將目標(biāo)版本數(shù)據(jù)寫入都指定的存儲區(qū)域中并引導(dǎo)運(yùn)行新版本軟件，從而實(shí)現(xiàn)自身軟件的更新。按 ECU 芯片類型及運(yùn)行軟件的特性可分為普通 ECU 和智能 ECU，而不同的 ECU 類型根據(jù)其內(nèi)存空間結(jié)構(gòu)又可以分為單分區(qū)和雙分區(qū)兩類。針對兩類 ECU 的兩種不同分區(qū)方案，ECU 端的升級可以大致歸類為 4 種方案，本小節(jié)將分別對其展開討論。
①? 普通 ECU 單分區(qū)（Bootloader）升級方案
普通 ECU 由于存儲空間有限，通常會采用流式刷寫的方式進(jìn)行升級，所謂流式刷寫即先將目標(biāo)刷寫空間的數(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ùn)行的應(yīng)用程序分區(qū)切 換至 BootLoader 運(yùn)行，在 BootLoader 中將應(yīng)用分區(qū)當(dāng)前版本數(shù)據(jù)擦除后，再從升級主控接收新版本數(shù)據(jù)并寫入應(yīng)用程序分區(qū)，數(shù)據(jù)檢驗無誤后重啟 ECU 切換至應(yīng)用分區(qū)即可運(yùn)行新版本軟件。
圖? 2-6 Bootloader 升級方案示意圖
這種方案缺陷非常明顯， 由于只有一個應(yīng)用分區(qū)，升級前需要擦除，導(dǎo)致升 級過程 ECU 功能無法使用，如果更新過程異常中斷或者失敗也會導(dǎo)致功能無法使用。另外，這類升級通常需要在車輛非運(yùn)行狀態(tài)下才能進(jìn)行，在軟件數(shù)量較大所需升級時間較長的情況下，對車輛低壓電池供電，尤其對于燃油車挑戰(zhàn)較大。
由于這用方案具有對內(nèi)存空間要求低、在 BootLoader 進(jìn)行更新不受應(yīng)用程 序干擾、實(shí)現(xiàn)簡單等優(yōu)勢，目前現(xiàn)有升級解決方案中大部分普通 ECU 的更新仍采用這種方式。
② 普通 ECU 雙分區(qū)（AB 分區(qū)）升級方案
通過 AB 分區(qū)方案，為軟件的運(yùn)行版本和升級的目標(biāo)版本分配不同的存儲區(qū)，A 與 B 分區(qū)彼此為回滾，A 分區(qū)系統(tǒng)運(yùn)作提供服務(wù)時，刷新 B 分區(qū)，待 B 分區(qū)軟件刷寫完成通過校驗后，下次重啟時載入 B 分區(qū)；若刷寫錯誤或關(guān)聯(lián) ECU 刷新失敗，則仍以 A 分區(qū)系統(tǒng)啟動，從而提高升級的可靠性，最小化回滾所需的時間。
對于 AB 升級，其實(shí)有三種實(shí)現(xiàn)方案：第 1 類基于硬件輔助的 A/B 交換方 案。該方案要求 ECU 內(nèi)存足夠，而且支持地址重映射，也就是當(dāng)新版本軟件刷寫完成，通過更新映射地址來激活新版本軟件，即新版本軟件運(yùn)行的入出地址不變；第 2 類與第 1 類的差別在于 ECU 硬件不支持地址重映射，激活新版本軟件的入出地址會變化；第 3 類，基于外擴(kuò)內(nèi)存的 A/B 交換方案，該方案是需要額外的外擴(kuò)內(nèi)存，備份當(dāng)前版本軟件和舊版本軟件，新版本軟件會先刷寫原先的舊版本軟件空間，然后擦除 ECU 內(nèi)存的當(dāng)前版本軟件， 刷寫新版本軟件，完成激活。
AB 升級方案示意圖如圖2-7 所示
圖 2-7? AB 升級方案示意圖
③ 智能 ECU 單分區(qū)升級方案
智能 ECU 是指具有高性能處理器，可運(yùn)行現(xiàn)代操作系統(tǒng)(如 Linux 、QNX、 Android 等)支持文件系統(tǒng)的控制器。這類控制器存儲介質(zhì)成本相對較低， 一般存儲空間較為充足，通常不會采用流式刷寫的方式進(jìn)行升級，而是先將升級包保存到 ECU 本地存儲，然后進(jìn)行安裝。智能 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)軟件運(yùn)行在主系統(tǒng)分區(qū)，更新子系統(tǒng)是一個最小功能系統(tǒng)僅用于實(shí)現(xiàn)軟件安裝功能。該方案軟件更新流程：①系統(tǒng)正常運(yùn)行在主系統(tǒng)分區(qū)，同升級代理從 OTA 主控接收升級包文件，并保存在升級包緩存區(qū)， ② 升級包接收完成后由進(jìn)行解密、簽名認(rèn)證，③接收到 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)默認(rèn)運(yùn)行在 A 系統(tǒng)分區(qū)，有新版本軟件需要更新時，可以通過升級代理從 OTA 主控接收升級包，并直接通過安裝程序?qū)⑵浒惭b到 B 系統(tǒng)分區(qū)中，整個更新過程不影響 ECU 正常功能使用。該方案軟件更新流程：①系統(tǒng)正常運(yùn)行在 A 系統(tǒng)分區(qū)，同升級代理從 OTA 主控接收升級包文件，并保存在升級包緩存區(qū)；②升級包接收完成后由進(jìn)行解密、簽名認(rèn)證；③接收到 OTA 主控安裝命令后，A 系統(tǒng)分區(qū)安裝程序?qū)⒕彺嬷械纳壈惭b到 B 系統(tǒng)分區(qū)；④收到 OTA 主控激活命令后將系統(tǒ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 主控
① 電源管理
由于整車升級時間較長，且要確保車輛處于安全狀態(tài)， 因此需要管理升級過 程中各個控制器的工作狀態(tài)。如果車輛在熄火狀態(tài)下升級，考慮到長時間的電池電量消耗，在升級之前要對車輛的現(xiàn)有電量進(jìn)行檢查，升級過程中需要設(shè)計電源管理策略對升級與不升級的控制器、耗電的電器件進(jìn)行差異化管理。如果控制器由于不可控的意外導(dǎo)致升級異常，也應(yīng)處于低功耗模式，降低對整車電量的消耗。
② 車輛控制
對于影響車輛安全的升級，整個升級過程需要保持在一種安全狀態(tài)，因此， OTA?主控需要具備一定車輛功能控制能力，根據(jù)不同的升級類型，控制車輛的功能狀態(tài)。
③ 異常處理
在 OTA 傳輸過程中，外界干擾或者其他因素導(dǎo)致刷寫異?；蛘咧袛?，車載
ECU 必須支持軟件回滾、斷點(diǎn)續(xù)傳、丟失重傳等處理機(jī)制。
（2）OTA 相關(guān)協(xié)議
① 標(biāo)準(zhǔn)協(xié)議
支持軟件刷寫和軟件升級的標(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)，并且定義了刷寫時需要使用哪些 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 負(fù)責(zé)在 AP 上更新，安裝，刪除和保留軟件記錄，實(shí)現(xiàn)了軟件包管理，確保以安全可靠的方式更新或修改 AP 上的軟件。UCM?Master 提供了一種標(biāo)準(zhǔn)的平臺解決方案，通過與多個 UCM 之間協(xié)調(diào)和分配車輛內(nèi)的包，實(shí)現(xiàn) AUTOSARAP 的軟件更新。
② 私有協(xié)議
除了升級遵從標(biāo)準(zhǔn)協(xié)議的傳統(tǒng)控制器，OTA 還需要支持智能 ECU 的升級。智能 ECU 通常帶有操作系統(tǒng)并且自身具有升級能力，作為升級對象，需要從 OTA 主控模塊或者云端獲取升級包，并與 OTA 主控進(jìn)行信息交互，實(shí)現(xiàn)升級的觸發(fā)和升級信息的反饋。對于這部分升級所涉及到的升級包分發(fā)和升級控制，現(xiàn)在并沒有統(tǒng)一的定義和標(biāo)準(zhǔn)，各家車企和供應(yīng)商的實(shí)現(xiàn)方案也各異。
（3）?ECU 端升級技術(shù)
① 差分升級
相對于整包升級，差分升級方案不僅可以節(jié)省 MCU 內(nèi)部的資源空間、還可 以節(jié)省下載和升級過程中的功耗。從另一個角度說，通過將差分部分下發(fā)到設(shè)備保證了軟件版本的安全性。差分升級的流程如表 2-8，圖 2-9 、2-10 所示。
表 2-8? 差分升級基本流程
?
| 步驟 | 內(nèi)容 |
| 原始版本提取 | 從目標(biāo)?ECU?中提取出當(dāng)前安裝的軟件版本，以便與新版本進(jìn)行比較。?? |
| 新版本生成差分包 | 將新版本的軟件與當(dāng)前版本進(jìn)行比較，找出兩者之間的差異。這些差異可能是代碼的新增、修改或刪除。生成差分包時，通常使用一些壓縮和差異算法，例如哈希函數(shù)、二進(jìn)制比較等，以便減少差分包的大小。?? |
| 差分包傳輸 | 將生成的差分包傳輸?shù)侥繕?biāo)?ECU。由于差分包只包含實(shí)際更改的部分，?因此傳輸時間會大大減少，尤其是在網(wǎng)絡(luò)帶寬有限的情況下。?? |
| 差分包合并 | 目標(biāo)?ECU?接收到差分包后，使用算法將差分包中的更改與當(dāng)前軟件版本進(jìn)行合并。這可能涉及將新增的代碼插入到現(xiàn)有的代碼中，可選擇修改現(xiàn)有代碼，或者刪除不再需要的代碼。?? |
| 軟件驗證和更新 | 合并差分包后，對新軟件版本進(jìn)行驗證，確保它在目標(biāo)?ECU?上正常運(yùn)行。如果一切正常，系統(tǒng)將完成升級過程，新版本的軟件將被激活并開始運(yùn)行。?? |
?
差分的實(shí)現(xiàn)方式主要有兩種：基于文本文件的差分和基于二進(jìn)制文件的差分， 其區(qū)分在于對比文件的差異，前者是基于邏輯上的，后者是基于物理上的。在升級時，通過與制作過程對應(yīng)的還原工具，將差分包還原后寫入到存儲器中，保證寫入后的內(nèi)容與目標(biāo)版本內(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 完整升級包實(shí)現(xiàn)升級目標(biāo)。
② 安全啟動
安全啟動(Secure Boot)用于保證固件啟動的代碼受信任的安全保證機(jī)制，它 通過在引導(dǎo)加載過程中，對加載固件進(jìn)行檢驗，從而防止加載和執(zhí)行惡意代碼。固件的每一步加載都經(jīng)過數(shù)字簽名認(rèn)證，而每一步簽名認(rèn)證的根證書中的密鑰需要與固化在芯片內(nèi)部不可修改的簽名密鑰匹配，從而行成一個完整信任鏈。
③ 安全校驗 ? ?
ECU 端需要具備對所安裝軟件包進(jìn)行完整性校驗和真實(shí)性校驗的能力，這要求 ECU 有能力對更新數(shù)據(jù)進(jìn)行簽名驗證。傳統(tǒng)的 ECU 刷寫過程通常只通過循環(huán)冗余校驗驗證更新數(shù)據(jù)的完整性，而無法驗證其真實(shí)性，存在被刷寫非法軟件的風(fēng)險。
2.4??人機(jī)交互
2.4.1? 人機(jī)交互要素分析
車端的人機(jī)交互主要體現(xiàn)在信息娛樂系統(tǒng)上，覆蓋到 OTA 的整個過程，包 括信息提示、用戶確認(rèn)、關(guān)鍵信息顯示等。人機(jī)交互過程需要考慮的要素大致可以分為兩個方面，即法規(guī)符合性和使用便利性，如表 2-8 所示。
表 2-9? 人機(jī)交互要素分類及示意
?
| 人機(jī)交互分類 | 要 求 |
| 法規(guī)符合性 | 符合GB《汽車軟件升級通用技術(shù)要求》 |
| 使用便利性 | 版本信息可查看 |
| 升級功能可設(shè)置 | |
| 升級信息提示 | |
| 升級前用戶可以選擇升級方式，并且支持升級包下載進(jìn)度的展示，和用戶手動取消下載。下載完成后，用戶需要再次確認(rèn)是否升級。 | |
|
升級中顯示升級條件的檢查，需要實(shí)時顯示進(jìn)度；如果條件不滿足，要給予用戶明確的提示。 如果出現(xiàn)異常情況要進(jìn)行回滾，可以明確提示回滾狀態(tài)和及其進(jìn)度。 |
|
| 升級后提示升級的結(jié)果成功或失敗。 |
?
2.4.2??人機(jī)交互方式分類
基于實(shí)際業(yè)務(wù)要求，各家 OEM 的 OTA 人機(jī)交互方式各有差異，本節(jié)共總結(jié) 6 種主流升級方式，并針對營運(yùn)車輛與非營運(yùn)車輛使用性質(zhì)不同，分別展開分析，具體如表 2-10 所示。
表 2-10? 人機(jī)交互方式分類
?
| 升級方式 | 營運(yùn)車輛 | 非營運(yùn)車輛 |
| 離車升級：升級過程會影響用戶使用車輛功能，在升級包下載完成、確認(rèn)用戶離車后進(jìn)行升級條件檢查，條件滿足開始升級。 | √運(yùn)營公司的車輛管理平臺遠(yuǎn)程管理車輛升級 | ?√ |
| 無感升級：升級過程不影響用戶使用車輛功能，升級完成后版本切換需要用戶確認(rèn)，系統(tǒng)重啟后即可實(shí)現(xiàn)版本切換，用戶無需等待升級包寫入的過程。無感升級可通過?AB?分區(qū)技術(shù)來實(shí)現(xiàn)。 | ? | √ |
| 立即升級：用戶在車機(jī)端點(diǎn)擊確認(rèn)升級后，立即發(fā)起升級條件檢查，條件滿足開始升級。 | √車輛回歸單位后，統(tǒng)一安排升級 | √ |
| 預(yù)約升級：用戶通過車機(jī)或手機(jī)端?APP?設(shè)置預(yù)約升級的時間，當(dāng)?shù)竭_(dá)設(shè)定的時間點(diǎn)，車輛自動檢查是否滿足升級條件，條件滿足開始升級。 | √ ?通過運(yùn)營公司的車輛管理平臺確認(rèn)授權(quán)并設(shè)置頂約升級時間 | √ |
| 延時升級：用戶通過車機(jī)或手機(jī)端?APP?確認(rèn)授權(quán)升級后，不會立即開始更新，而是在?OEM?設(shè)定的時間(比如凌晨)，車輛自動檢查是否滿足升級條件，條件滿足開始升級。 | √通過運(yùn)營公司的車輛管理平臺確認(rèn)授權(quán) | √ |
| 手機(jī)遠(yuǎn)程升級：用戶收到升級通知后，可通過手機(jī)端?APP??進(jìn)行版本檢查，通過手機(jī)下發(fā)下載、升級或者取消等指令的操作，并且在?APP?上實(shí)時查看下載和升級的過程、升級結(jié)果。 | √?向車主的手機(jī)端?APP?發(fā)送升級通知 | √ |
?
來源：本文節(jié)選自《智能網(wǎng)聯(lián)汽車遠(yuǎn)程升級（OTA）發(fā)展現(xiàn)狀及建議》
關(guān)于《智能網(wǎng)聯(lián)汽車遠(yuǎn)程升級（OTA）發(fā)展現(xiàn)狀及建議》 本書由國家智能網(wǎng)聯(lián)汽車創(chuàng)新中心、國家市場監(jiān)管總局缺陷產(chǎn)品管理中心、華為技術(shù)有限公司、上海蔚來汽車有限公司、中國軟件評測中心、襄陽達(dá)安汽車檢測中心、國家工業(yè)信息安全發(fā)展研究中心、中國信息通信研究院八家單位牽頭，聯(lián)合30余家單位共同編制完成。
本書從既保障安全、又鼓勵OTA技術(shù)應(yīng)用的目標(biāo)出發(fā)，開展OTA定義與技術(shù)體系、政策法規(guī)標(biāo)準(zhǔn)現(xiàn)狀、產(chǎn)業(yè)生態(tài)現(xiàn)狀、安全風(fēng)險與測試評價等相關(guān)研究，并分析提出發(fā)展建議，以支撐相關(guān)政策法規(guī)標(biāo)準(zhǔn)制修訂和企業(yè)軟硬件及OTA技術(shù)研發(fā)，力求為智能網(wǎng)聯(lián)汽車產(chǎn)業(yè)發(fā)展?fàn)I造良好環(huán)境。
審核編輯：黃飛
?
工商網(wǎng)監(jiān)
評論