OTA 技術最早應用在 PC 電腦和移動手機行業，近幾年才開始在汽車行業中 廣泛應用。然而車內通訊網絡的復雜性、汽車電子系統的碎片化等因素限制著 OTA 技術整車范圍普及。本章從 OTA 定義與應用場景、OTA 實現流程和“云-管-端”關鍵技術進行研究，為行業從業者對 OTA 技術的設計開發、技術驗證和生產工作提供參考。

一、汽車 OTA 定義與應用場景

1.1? OTA 定義及分類

OTA 是 Over the Air 的縮寫，通常指的是遠程無線方式，OTA 技術可以理解為一種遠程無線升級技術。在無特別說明情況下，本文所指的 OTA 是所有汽車遠程升級的統稱。實現 OTA 的基礎是車輛具備遠程聯網功能，這意味著正是智能網聯汽車滲透率的快速增長，推動了 OTA 的快速普及。

OTA?的本質是通過技術實現軟件更新，智能網聯汽車與傳統汽車的軟件升級不同之處在于，通過 OTA 技術，原始設備制造商（OEM）可以不用通過售后服務中心，而是直接遠程連接目標聯網車輛，將軟件更新推動至待升級的車輛。

隨著 OTA 的應用越來越廣泛，針對升級對象的不同，延伸出來很多不同的 概念。人們在談及 OTA 相關業務時通常會在前面增加一個具體對象，用于表明使用 OTA 技術實現何種功能，比如遠程軟件升級、遠程固件升級、遠程配置、遠程數據更新等。然而在一些 OTA 解決方案中，已經模糊了不同類型遠程升級的邊界，將所有可升級的軟件對象抽象為軟件簇，而軟件簇包含了從小到配置字信息大到整個操作系統固件所有顆粒度的對象。并且，GB《汽車軟件升級通用 技術要求》中對軟件升級（Software Update）的定義已經涵蓋了下述幾種 OTA 概念（遠程診斷除外）。

1.1.1? 遠程軟件升級(SOTA)

SOTA（Software Over-The-Air），即遠程軟件升級，是指在操作系統的基礎上對應用程序進行遠程升級。SOTA 通過遠程下載并給車輛安裝“應用程序升級包”，來實現控制器功能的一個“增量”更新， 一般應用于娛樂系統和智駕系統。

SOTA 一般涉及應用層小范圍的功能局部更新，不包括汽車核心系統，對整 車性能和安全影響較小，升級前置條件要求較低。SOTA 的增量更新策略， 可以大幅減小升級包文件大小、從而節約網絡流量和存儲空間。

1.1.2? 遠程固件升級(FOTA)

FOTA（Firmware Over-The-Air），即遠程固件升級，是指囊括車輛底層算法至頂層應用的綜合升級，在不改變車輛原有配件的前提下，通過遠程下載并寫入新的固件程序進行設備升級。FOTA 包括驅動、系統、功能、應用等的升級，與硬件的更換沒有關系。

FOTA 涉及車輛的核心系統，包括但不限于汽車動力控制系統、底盤電子系 統、自動駕駛系統、車身控制系統等核心零部件的控制系統，可以改變車輛的充放電、動能回收、加速性能、輔助駕駛系統邏輯等與深度駕控有關的體驗。理論上所有支持固件更新的電子控制單元（ECU）都可以涵蓋在 FOTA 范圍中。

1.1.3? 遠程配置(COTA)

COTA（Configuration Over-The-Air），即遠程配置，是指通過 OTA 的方式實現遠程修改配置字，以達到修改軟件功能配置的目的。配置字是一組以數據標識碼(DID)方式存儲在 ECU 上的數據，可通過診斷指令進行讀取和修改。它根據特定的編碼規則與車輛功能特征碼一一對應，通過配置可判斷車輛的功能配置，軟件可根據配置實現相應的功能。遠程配置常見的應用場景是遠程開啟和關閉某項功能，例如軟件訂閱功能。

1.1.4? 遠程診斷/遠程數據更新(DOTA)

DOTA 有兩種常見解釋：

DOTA(Data Over-The-Air)，即遠程數據更新，是指一些獨立于軟件程序存在的數據包的更新，比如，地圖數據、語音數據和算法模型數據等。這類更新的特點是數據量比較大，更新流程相對獨立，比如，地圖數據通常由地圖應用自行更新，而數據量也可能高達幾 G 到幾十G。

DOTA(Diagnostic Over-The-Air)，即遠程診斷，通過云平臺實時數據采集監控，主動性地檢查汽車系統異常問題，為遠程問題修復與人工問題修復提供決策依據。遠程診斷的觸發方式有兩種，一種是用戶在車輛上發現異常狀況的響應式；另一種是周期性收集通訊網絡、應用程序、硬件效能、使用操作記錄、系統程序等狀態信息，利用大數據后臺分析監測故障。

1.1.5? 其他類型(XOTA)

隨著汽車智能化程度越來越高，除了車輛本身軟件的升級外，還可能會涉及 到外部智能設備交互功能的軟件更新，比如，智能鑰匙、AR 設備等。目前有些企業和組織將所有與車輛相關聯的軟件升級統稱為 XOTA，即 Everything Over-The-Air 的意思。

1.2 OTA 應用場景

1.2.1?車輛生命周期維度

從開發者編譯生產出目標版本軟件，到該軟件更新至目標硬件設備上的全過 程涉及多個階段。在不同的階段，受產品形態和生產環境限制，所適用的軟件更新目的和手段也有所不同，如下表 2- 1 所示。目前，大部分車企的 OTA 主要集中在售后軟件更新，但不論是從效率上還是成本上 OTA 都體現出了巨大的優勢。隨著 OTA 應用越來越成熟，從單一的售后升級場景向更多的應用場景發展是的必然趨勢。

表 2-1? 車輛生命周期維度的軟件更新應用

?

?

1.2.2? 軟件運營管理維度

從軟件運營管理的維度 OTA 的典型應用場景如下表 2-2 所示。

表 2-2? 軟件運營管理維度的軟件更新典型應用場景

?

?

二、 汽車 OTA 技術體系? ?

2.1? OTA 實現流程

汽車軟件更新的本質是將供應商或者 OEM 內部開發部門編譯出來的軟件或 者數據替換當前車輛 ECU 中的版本，以實現預期的特定功能。因此，汽車軟件升級所需要的核心工作是建立遠程傳輸鏈路并實現 OEM 云端系統遠程更新車輛 ECU 中的軟件數據。同時，為了準確、安全、可靠地完成 ECU 軟件的更新，OTA 系統需要云端管理系統對軟件、升級對象進行管理，以實現人工操作到自動化的轉變；車端系統需要完成軟件數據的接收和分發工作，并保證無專業技師操作情況下的安全升級。?

圖 2-1：OTA 實現流程(來源 AutoSAR) ? ?

圖2-1 是一個典型的 OTA 系統框架，包含了三個基本要素，即云端的 OTA 平臺、車端 OTA 主控、OTA 對象。其中：OTA 云平臺負責 OTA 升級包管理、車輛管理及 OTA 發布等功能，車端 OTA 主控負責從 OTA 云平臺下載升級包并將其刷寫到目標 ECU ，OTA 升級對象即最終軟件刷寫的主體，從主控接收軟件并完成自身軟件更新。OTA 的基本實現流程（圖2-1）可歸納為下表 2-3 所示步驟。

表 2-3? OTA 的基本實現流程

?

?

2.2? OTA 云平臺架構及關鍵技術 ???

OTA 云平臺是支撐 OTA 業務正常運行的相關云端系統的集合，既包括實現 OTA 核心功能的 OTA 服務端，也包括了其他關聯系統如企業 IT 管理系統、安全服務端、web 控制臺以及文件服務端。OTA 云平臺業務范圍涉及軟硬件生命周期管理、業務流程整合、軟件遠程分發等軟件更新所有相關業務，是一個軟件升級管理體系(SUMS)。

2.2.1? 云平臺架構

基于 OTA 產品業務形態，結合系統組件之間松耦合高內聚的標準，行業內 普遍將云平臺設計為 4 層的分層架構型式，如圖 2-2 所示，包括前端展示層、路由網關層、業務服務層和數據存儲層。前端展示層是系統與用戶交互的 web 應用層，用戶訪問和操作云平臺系統的交互接口；網關路由層包括指令控制層和網關接入層，是云平臺與車端建立通信鏈接以及控制車端流程的通信中間件；業務服務層負責所有 OTA 相關業務邏輯的處理，包括車輛、軟件包管理、策略管理等諸多業務模塊，是 OTA 云平臺的核心；數據存儲層負責 OTA 所有業務相關數據存儲，包括基本的數據庫集群數據緩存和大文件存儲等。

圖 2-2? OTA 云服務框架圖

（1） 前端展示層

前端展示層的劃分，是基于前后端分離開發方式設計的架構分層模式，主要 負責 Web 端用戶交互頁面的功能。核心思想是前端頁面通過調用后端的接口并進行交互，前端專注于交互頁面的開發，業務邏輯由后端負責。對 OTA 云平臺而言，前端展示層可以理解為業務服務層的用戶交互接口，其展示功能與具體業務功能一一對應。

? ? ? ? ?

?

（2） 指令控制層

各業務平臺與網關接入層的連通介質，接收來自業務系統指令并將指令發送 至網關可訪問的緩存中，接收來自網關回寫的升級狀態至各業務系統可訪問的消息隊列中。

（3） 網關接入層

針對不同的數據格式及上層需求，接收封裝來自車載終端傳輸的數據，并流

向緩存、消息隊列等中間件。

（4）業務服務層

業務服務層是 OTA 服務所有業務及相關流程管理功能在云平臺端的實現， 除了車輛管理服務、軟件包服務、版本服務、策略管理和任務管理 5 個支撐 OTA 的核心功能外，還包括關聯系統審批、數據對接、信息安全服務、測試、統計分析、日志查詢等重要輔助功能。由于不同的企業內部管理存在差異，云平臺所支持的輔助業務可能存在較大差異，常見服務列舉見表 2-4。

表 2-4?常見服務舉例

?

?

（5） PKI 系統

公鑰基礎設施（Public Key Infrastructure，PKI）：基于公鑰密碼體制實現數字證書的發布、撤銷和管理等功能，并為數字證書用戶提供相應服務的系統。其目的在于創造、管理、分配、使用、存儲以及撤銷數字證書，可以用來保證通信對象的身份真實性、軟件程序的來源真實性和完整性、通信行為的不可否認性等。

PKI 在 OTA 系統中的作用主要在于為相關實體發放數字證書，通過密碼技術保證升級包和升級過程的安全。主要包括車輛證書、設備證書、供應商證書等 的申請和校驗；云端對車端身份認證，車端對云端身份認證；升級包的安全認證等。

（6）外部數據系統

外部數據對接的系統可能包括整車生命周期配置系統（VLCS）、遠程診斷系 統、軟件可售系統及一些其他支撐系統組成。主機廠研發部門需要根據車型的功能規劃確定該車型所對應的軟硬件相關配置。需要進行軟件更新時， 從 VLCS 系統中確定所涉及的車型和影響的功能范圍，并依據確定好的范圍， 從物料信息管理系統(BOM)中申請軟件物料號作為版本控制依據， 供應商軟件釋放后經由產品生命周期管理系統（PLM）系統通過驗證審批后流轉到 OTA 服務端供升級使用使用。OTA 服務端管理設備中初始的車輛信息，可通過對接 MES 在車輛下線檢驗合格后將新生產車輛自動注冊到 OTA 云平臺，所有升級目標車輛應保證是已 注冊車輛。除此之外，根據實際需要還可能會從汽車經銷商管理系統（DMS）系 統獲取經銷商及售后服務站點信息，售后系統通常也需要與 OTA 系統關聯以同步最新版本信息以及線下配置更改信息等。

另外， OTA 系統在升級前可通過遠程診斷系統獲得最新的 ECU 配置信息及 狀態信息，并且當遠程診斷系統發現問題后，可以通過 OTA 系統下發經過測試驗證的補丁包來修復。對于一些有運營需求的主機廠來說，通過 OTA 系統配合軟件可售系統，可以實現軟件付費升級、功能付費使用等后向運營，真正實現“千車千面”、“用戶定義汽車”。

（7）數據存儲層

數據存儲層包括數據庫集群、緩存和存儲節點，分別用于存儲 OTA 云平臺 不同類型的數據。其中，數據庫集群，主要用于存儲車輛信息版本信息等關系型數據；緩存，為了解決數據庫性能瓶頸問題，可以通過多架設一層緩存層來減少對數據庫的直接訪問；存儲節點，針對較大的升級包、配置文件等需要提供車端下載的文件，通常可以存儲在分布式存儲節點上。

2.2.2? 關鍵技術

（1）安全技術

OTA 服務端以及企業 IT 管理系統、安全服務端、web 控制臺、文件服務端 等關聯系統，會面臨傳統云平臺的所有安全威脅。為保證 OTA 升級的安全性，常用安全技術如表 2-5 所示。? ?

?

表 2-5? OTA 云平臺常用安全技術

?

?

（2） OTA 技術

OTA 系統常用升級技術如表 2-6 所示。

表 2-6? OTA 云平臺常用升級技術

?

?

2.3??OTA 車載端架構及關鍵技術

2.3.1??車載端架構

OTA 車載端功能模塊主要包括 2 大部分，即 OTA 主控和 OTA 對象，如圖 2-3 所示。OTA 主控是車端 OTA 系統的核心，車端所有 OTA 業務邏輯均由主控實現，包括上報車輛信息、下載更新文件、升級包安裝、車輛狀態管理、人機交互等。

?

?

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

（1） OTA 主控功能模塊

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

表?2-7? OTA 主控功能模塊

?

?

（2） OTA 主控部署方案

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

圖 2-4? 傳統的 OTA?主控部署方案[1] ??

?

傳統網關分布式架構下，由于控制器分散以及層級很深，導致在實現 OTA ?的過程中要進行多次的轉發和透傳，容易導致數據丟失，增加升級失敗的概率。另外，需要在 OTA 主控內部對軟件進行備份，以保證升級失敗后，控制器可以被回滾。由于傳統控制器的芯片 Flash 和 RAM 容量小，實現也比較困難。

對高算力和大帶寬數據傳輸的迫切需求和“軟件定義汽車” 的理念驅動， 各家 車企逐步開始進行整車 E/E 架構的升級和變革，引入了“ 中央計算平臺+區域控制 器”的中央集中式架構，整體 E/E 架構更加扁平化，有利于實現整車級的 OTA。中央控制器和域控制器之間采用的是以太網，數據傳輸能力增強；并且?SOA 架構使得域控制器之間的交互機制更加靈活。針對區域控制器的 OTA 主控部署方案如圖 2-5 所示?？刹捎弥醒肟刂茊卧?CCU)作為升級主控，對于 ECU的刷寫有兩種方式：1)? 區域控制器作為網關路由 UDS 報文，主控通過 UDS 升級區域控制器和該區域的所有傳感器和執行器；2)區域控制器作為副主控，即升級主控先將該區域所有 ECU 的更新文件傳輸到區域控制中，由區域控器完整自身升級以及與其連接的執行器和傳感器的刷寫[1]。

圖 2-5? 區域控制器方案

（3） ECU 端架構方案

車端 ECU 作為被升級對象， 在 OTA 系統中主要功能是按照一定的協議升級 主控接收目標版本數據，將目標版本數據寫入都指定的存儲區域中并引導運行新版本軟件，從而實現自身軟件的更新。按 ECU 芯片類型及運行軟件的特性可分為普通 ECU 和智能 ECU，而不同的 ECU 類型根據其內存空間結構又可以分為單分區和雙分區兩類。針對兩類 ECU 的兩種不同分區方案，ECU 端的升級可以大致歸類為 4 種方案，本小節將分別對其展開討論。

①? 普通 ECU 單分區（Bootloader）升級方案

普通 ECU 由于存儲空間有限，通常會采用流式刷寫的方式進行升級，所謂流式刷寫即先將目標刷寫空間的數據擦除，然后傳輸數據的同時，ECU 將已接收的數據寫入目的存儲地址，通過這種方式可以省去存儲升級包的內存空間。傳統的 BootLoader 通過 UDS 協議刷寫的方式就是典型的流式刷寫。

如圖 2-6 所示，普通 ECU 單分區結構只有 BootLoader(啟動引導程序)和應用程序分區。該類型 ECU 需要更新時，首先將 ECU 從當前運行的應用程序分區切 換至 BootLoader 運行，在 BootLoader 中將應用分區當前版本數據擦除后，再從升級主控接收新版本數據并寫入應用程序分區，數據檢驗無誤后重啟 ECU 切換至應用分區即可運行新版本軟件。

圖? 2-6 Bootloader 升級方案示意圖

這種方案缺陷非常明顯， 由于只有一個應用分區，升級前需要擦除，導致升 級過程 ECU 功能無法使用，如果更新過程異常中斷或者失敗也會導致功能無法使用。另外，這類升級通常需要在車輛非運行狀態下才能進行，在軟件數量較大所需升級時間較長的情況下，對車輛低壓電池供電，尤其對于燃油車挑戰較大。

由于這用方案具有對內存空間要求低、在 BootLoader 進行更新不受應用程 序干擾、實現簡單等優勢，目前現有升級解決方案中大部分普通 ECU 的更新仍采用這種方式。

② 普通 ECU 雙分區（AB 分區）升級方案

通過 AB 分區方案，為軟件的運行版本和升級的目標版本分配不同的存儲區，A 與 B 分區彼此為回滾，A 分區系統運作提供服務時，刷新 B 分區，待 B 分區軟件刷寫完成通過校驗后，下次重啟時載入 B 分區；若刷寫錯誤或關聯 ECU 刷新失敗，則仍以 A 分區系統啟動，從而提高升級的可靠性，最小化回滾所需的時間。

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

AB 升級方案示意圖如圖2-7 所示

圖 2-7? AB 升級方案示意圖

③ 智能 ECU 單分區升級方案

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

?

圖 2-8? 智能 ECU 升級方案示意圖

單分區方案通常包含主系統分區和更新子系統分區，以及用于存儲升級包的 緩存區域。正常系統功能相關軟件運行在主系統分區，更新子系統是一個最小功能系統僅用于實現軟件安裝功能。該方案軟件更新流程：①系統正常運行在主系統分區，同升級代理從 OTA 主控接收升級包文件，并保存在升級包緩存區， ② 升級包接收完成后由進行解密、簽名認證，③接收到 OTA 主控安裝命令后，升級代理將 ECU 切換至更新子系統，在子系統中通過安裝程序將升級包安裝到主系統分區，替換分區中的舊版本軟件， ④安裝完成后系統重啟切換到新的主分區軟件版本。

④ 智能 ECU 雙分區升級方案

智能 ECU 雙分區方案與單分區相似，雙分區方案具有兩個結構完全相同的 系統分區，兩個分區都具備升級代理和安裝程序的功能。系統默認運行在 A 系統分區，有新版本軟件需要更新時，可以通過升級代理從 OTA 主控接收升級包，并直接通過安裝程序將其安裝到 B 系統分區中，整個更新過程不影響 ECU 正常功能使用。該方案軟件更新流程：①系統正常運行在 A 系統分區，同升級代理從 OTA 主控接收升級包文件，并保存在升級包緩存區；②升級包接收完成后由進行解密、簽名認證；③接收到 OTA 主控安裝命令后，A 系統分區安裝程序將緩存中的升級包安裝到 B 系統分區；④收到 OTA 主控激活命令后將系統啟動引導標志設置為 B 系統分區，⑤重啟系統后切換運行 B 系統分區新安裝的軟件版本。

2.3.2??車載端關鍵技術

（1）?OTA 主控

① 電源管理

由于整車升級時間較長，且要確保車輛處于安全狀態， 因此需要管理升級過 程中各個控制器的工作狀態。如果車輛在熄火狀態下升級，考慮到長時間的電池電量消耗，在升級之前要對車輛的現有電量進行檢查，升級過程中需要設計電源管理策略對升級與不升級的控制器、耗電的電器件進行差異化管理。如果控制器由于不可控的意外導致升級異常，也應處于低功耗模式，降低對整車電量的消耗。

② 車輛控制

對于影響車輛安全的升級，整個升級過程需要保持在一種安全狀態，因此， OTA?主控需要具備一定車輛功能控制能力，根據不同的升級類型，控制車輛的功能狀態。

③ 異常處理

在 OTA 傳輸過程中，外界干擾或者其他因素導致刷寫異?；蛘咧袛?，車載

ECU 必須支持軟件回滾、斷點續傳、丟失重傳等處理機制。

（2）OTA 相關協議

① 標準協議

支持軟件刷寫和軟件升級的標準過程，方便 OTA 的開發、測試和集成，如傳統 ECU 支持 UDS 協議、AUTOSARAP 的 UCM。

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

AUTOSARAP ，即自適應平臺，是由軟件更新配置管理器（UCM）提供了處理軟件更新請求的服務。UCM 負責在 AP 上更新，安裝，刪除和保留軟件記錄，實現了軟件包管理，確保以安全可靠的方式更新或修改 AP 上的軟件。UCM?Master 提供了一種標準的平臺解決方案，通過與多個 UCM 之間協調和分配車輛內的包，實現 AUTOSARAP 的軟件更新。

② 私有協議

除了升級遵從標準協議的傳統控制器，OTA 還需要支持智能 ECU 的升級。智能 ECU 通常帶有操作系統并且自身具有升級能力，作為升級對象，需要從 OTA 主控模塊或者云端獲取升級包，并與 OTA 主控進行信息交互，實現升級的觸發和升級信息的反饋。對于這部分升級所涉及到的升級包分發和升級控制，現在并沒有統一的定義和標準，各家車企和供應商的實現方案也各異。

（3）?ECU 端升級技術

① 差分升級

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

表 2-8? 差分升級基本流程

?

?

差分的實現方式主要有兩種：基于文本文件的差分和基于二進制文件的差分， 其區分在于對比文件的差異，前者是基于邏輯上的，后者是基于物理上的。在升級時，通過與制作過程對應的還原工具，將差分包還原后寫入到存儲器中，保證寫入后的內容與目標版本內容一致。

圖?2-9?差分計算過程

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

圖 2-10? 差分還原過程

差分還原算法輸入參數為舊版本安裝包 v1.0 與差分升級包 v1.0-v1.1- update.patch。通過差分還原算法處理后得到最新的完整升級包 v1.1 。ECU 端安裝 v1.1 完整升級包實現升級目標。

② 安全啟動

安全啟動(Secure Boot)用于保證固件啟動的代碼受信任的安全保證機制，它 通過在引導加載過程中，對加載固件進行檢驗，從而防止加載和執行惡意代碼。固件的每一步加載都經過數字簽名認證，而每一步簽名認證的根證書中的密鑰需要與固化在芯片內部不可修改的簽名密鑰匹配，從而行成一個完整信任鏈。

③ 安全校驗 ? ?

ECU 端需要具備對所安裝軟件包進行完整性校驗和真實性校驗的能力，這要求 ECU 有能力對更新數據進行簽名驗證。傳統的 ECU 刷寫過程通常只通過循環冗余校驗驗證更新數據的完整性，而無法驗證其真實性，存在被刷寫非法軟件的風險。

2.4??人機交互

2.4.1? 人機交互要素分析

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

表 2-9? 人機交互要素分類及示意

?

?

2.4.2??人機交互方式分類

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

表 2-10? 人機交互方式分類

?

?

來源：本文節選自《智能網聯汽車遠程升級（OTA）發展現狀及建議》

關于《智能網聯汽車遠程升級（OTA）發展現狀及建議》 本書由國家智能網聯汽車創新中心、國家市場監管總局缺陷產品管理中心、華為技術有限公司、上海蔚來汽車有限公司、中國軟件評測中心、襄陽達安汽車檢測中心、國家工業信息安全發展研究中心、中國信息通信研究院八家單位牽頭，聯合30余家單位共同編制完成。

本書從既保障安全、又鼓勵OTA技術應用的目標出發，開展OTA定義與技術體系、政策法規標準現狀、產業生態現狀、安全風險與測試評價等相關研究，并分析提出發展建議，以支撐相關政策法規標準制修訂和企業軟硬件及OTA技術研發，力求為智能網聯汽車產業發展營造良好環境。

審核編輯：黃飛

?