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