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