智能網聯汽車整車OTA功能設計研究

王棟梁 湯利順 陳博 柳旭 劉闖

（中國第一汽車集團有限公司智能網聯開發院，長春 130011）

主題詞：智能網聯汽車 整車OTA 差分算法 回滾重刷機制

1 前言

隨著汽車智能化、網聯化水平的不斷提升，汽車內部電子控制單元的數量和復雜度不斷增加。據統計，目前高級轎車上電子電氣元件的成本已經占到整車開發成本的60%～70%，若要對電控單元軟件進行開發調試、數據標定、文件更新、故障修復就需要遠程應用程序更新（Over the Air Technology，OTA）技術。2014年特斯拉首次面向中國推出V5.9版車載系統，目前已經更新到V8.1版本，實現了對駕駛輔助系統、自動泊車功能、空氣懸架系統、導航和地圖、影音娛樂系統等內容的更新[1-2]。整車OTA技術在車輛量產后可降低車輛的召回成本，實現對車輛軟件和車輛數據的統一管理，提高售后服務的效率和質量；為用戶提供車載娛樂系統的增值服務，有效提升用戶體驗和用戶黏貼度；通過車輛軟件的快速更新迭代，特別是優化和加強駕駛輔助功能，實現整車系統的不斷升級，讓用戶獲得更優質的行車體驗。本文提出一種基于整車Ethernet/CAN/LIN混合電子電氣架構，建立云服務器端-車輛客戶端之間安全、穩定、可靠連接通路的控制器軟件升級方案，以實現整車上信息娛樂系統、動力傳動系統、車身舒適系統等所有控制器不同類型節點的在線更新。

2 OTA系統架構

整車OTA系統包括云服務器端和車輛客戶端[3]，它們之間通過4G或Wifi進行數據通信。云服務器端和車輛客戶端采用一對多的方式，云服務器端為部署在數據中心的私有云服務平臺，僅借助于公有云的CDN（內容分發技術）來實現位于不同區域的不同車輛同時更新，圖1為OTA系統架構。

2.1 云服務器端

2.1.1 硬件系統

云服務器端集群是建設在數據中心防火墻內的私有云平臺，由1臺負載均衡服務器、6臺Swarm服務器、12臺Worker服務器、1臺帶主備功能的數據庫服務器和CDN分發服務器組成。負載均衡服務器負責大規模升級任務的分發，提高任務處理效率；18臺業務處理服務器對各升級任務進行具體處理并直接進行云端和車端的信息交互；數據庫服務器存儲所有升級文件以及車輛軟件信息，實時存儲車輛升級狀態；CDN服務器利用公有云輻射全國的資源，實現全國各地車輛的任務升級。云端服務器架構如圖2所示。

圖1 OTA系統架構

圖2 云端服務器架構

2.1.2 軟件系統

云服務器端部署有一套完整的信息存儲系統用來存儲所有量產車輛的信息，包括車型、車系、車輛配置、VIN碼、車輛EOL日期、T-Box序列號等。在這些信息的基礎上，增加對車輛控制器更新狀態的描述，這樣實現對每輛車更新歷史足跡的記錄，根據每輛車的更新狀態還可以對每次升級任務的過程和成功率進行統計。

OTA云端系統具備文件管理和升級任務部署的功能。文件管理系統實現了不同車型車系的車輛上所有控制器軟件的版本管理?？刂破鬈浖贠TA系統中需進行功能驗證、簽名、加密等操作，然后與信息存儲系統中量產車輛的信息實現唯一對應，保證升級軟件精準的下發。升級任務部署系統主要是對需升級的軟件進行配置，選擇需升級的車輛，設置升級任務的時間，升級任務的策略等。任務部署完成后，利用餅圖和直方圖來實時記錄和顯示任務進行的過程和任務完成的百分比，每次任務結束后還會自動生成任務報告，對此次任務進行分析并對升級中的問題進行解決。

2.2 車輛客戶端

車輛客戶端架構如圖3所示，采用目前主流的多種總線Ethernet/CAN/LIN融合并存、網關路由通信中樞的方式，不同總線完成不同的場景應用。在實際應用中，網關和車載通信單元集成在一起，作為一個中央網關控制單元。升級所必須的模塊主要包括遠程通信模塊、文件下載模塊、差分還原模塊和更新策略模塊。

a.遠程通信模塊。該模塊實現與云服務器端的通信，完成升級任務數據和差分文件的下載，支持蜂窩通信、WLAN通信及斷點續傳功能。

b.文件下載模塊。該模塊在云端和云端安全認證的基礎上，根據文件下載鏈接，接收軟件并解密和驗證其完整性。

c.差分還原模塊。該模塊依據遠程接收的差分文件和目前車內的舊版軟件，以及云端所使用的差分算法完成新版軟件的還原。

d.更新策略模塊。該模塊完成下載過程中車輛狀態的判斷與核查，只有在所有的限制條件均不滿足時，才可以啟動升級流程。

車輛客戶端通信協議架構如圖3所示，上層標準協議接口層采用UDS診斷協議，協議包含數據上傳和下載的標準服務，不需要開發專用數據交互協議[3]；下層依據協議的不同采用不同的國際標準。

圖3 車輛客戶端通信協議

2.3 OTA升級流程

整個OTA升級過程如圖4所示。

圖4 OTA升級流程

a.文件上傳和部署。升級軟件先線下進行刷寫測試，刷寫成功后上傳到云端系統。云端系統對升級軟件進行加密，通過集成的差分算法對文件進行差分生成二進制差分文件。在此文件基礎上添加升級策略、升級標識等信息到配置文件，組成一個完整的ZIP格式壓縮包，并選擇升級車輛范圍、升級時間，完成升級軟件在云端的部署。

b.遠程下載。在升級任務有效的時間段內，每次車輛上電會與云端建立連接，云端對車輛內部所有控制器軟件版本進行收集，與云端任務的控制器軟件版本比較，若存在新版本，云端會將升級軟件下發到車端，文件傳輸使用HTTPS協議保證文件的安全性。整個下載過程支持斷點續傳。

c.用戶通知和確認。云端和車端建立連接之后，云端會實時監控車輛狀態，確認用戶在使用車輛后，將更新信息推送到IVI的HMI（帶有免責聲明、安裝條件、注意事項）。如果用戶沒有點擊更新，下次車輛上電后會繼續通知升級信息。

d.本地刷寫。升級文件下載到本地后，車輛會判斷車輛條件是否滿足升級要求，若滿足，車輛就會對升級文件對應的控制器進行升級。網關和IVI使用自升級方式進行升級，網關下各路ECU由網關作為診斷儀進行刷寫。

3 OTA關鍵技術

3.1 差分算法

差分算法是指在云服務器端比較新、舊版本之間的差異生成差分delta文件，然后將該文件傳輸到車輛客戶端，車輛客戶端根據接收到的差分delta文件和舊版文件還原成新版文件[4]，如圖5所示。圖5中，O代表舊版文件，N代表新版文件，D代表差分文件。因差分del?ta文件的大小遠小于源文件，所以有利于無線傳輸，同時節省流量，提升整個傳輸過程的可靠性和經濟性。

圖5 差分算法原理

車輛控制器大部分文件程序很小，不需要使用差分算法進行更新。差分算法主要應用在娛樂信息系統的應用程序升級和車載地圖的更新。結合娛樂信息系統的軟件特點、文件格式以及車內端的更新方式，定義了3種指令來實現對新、舊版本軟件差異的描述[5]。

a.Data命令。當新、舊版本軟件數據內容完全不同時需要采用此指令，該指令說明將有新的數據生成。指令后面跟隨的數據包括地址信息、數據長度和更新的數據內容，如Data 0x1000 0x02 0x0102表示在舊版本軟件中起始地址為0x1000的后面進行數據更新，更新數據長度為2個字節，更新的數據內容為0102。

b.Copy命令。當新、舊模塊之間的數據內容相同而只是地址發生偏移時需要采用此命令，這種現象在標定變量及可變參數軟件中是經常發生的。指令后面跟隨的數據包括舊版本的首地址、新版本更新地址和復制的數據長度，如Copy 0x1000 0x2000 0x02表示將舊版本軟件中起始地址為0x1000、數據長度為2個字節的數據復制到新版本軟件中起始地址為0x2000、數據長度為2個字節的位置。

c.End命令。該指令用來描述文件的結束。

圖6為一個標準的差分文件的生成過程，需要完成電控單元中應用程序軟件的更新。由圖6可看出，舊版本軟件中包含5部分，新版本軟件同樣包含5部分，且地址空間大小相同。數據塊#1和#4在新、舊版本中數據內容和存儲地址沒有變化，所以不需要在差分文件中描述；數據內容發生變化的數據塊包括#2和#5，所以這兩塊在描述文件中需要使用Data命令，數據塊#2數據內容沒有變化，但是地址發生了偏移，所以使用Copy命令進行描述。生成的差分描述文件包括兩個Data命令與一個Copy命令以及一個文件結束指令。因源文件數據長度為0x80,差分文件長度大致為0x35，所以大大縮小了傳輸文件尺寸。

圖6 差分描述文件生成

由上述可知，差分文件的大小由Data命令、Copy命令的多少決定，假定命令的數據長度是1字節，地址數據長度由add表示，Data后面的數據內容長度由L表示，Data和Copy命令的數量分別為c1和c2，則一個描述文件的數據長度為：

由式（1）可知，實際上新、舊版本軟件中數據內容不一致的長度為L×c1,差分文件的大小主要由Data命令的多少以及其后的數據長度L決定。所以在生成差分文件過程中，盡量使用Copy命令尋找軟件中的數據內容相同處，即使用Copy命令替換Data命令。

3.2 安全方案

整個OTA系統的安全是從云端到車端的多階段多層級全方位的防護，即軟件上傳到OTA服務器、OTA服務器到車輛客戶端以及車輛客戶端內部都采用不同類型的加密機制來提升整個升級過程的安全等級。對于OTA服務器首先是對登陸用戶需要進行安全訪問限制和認證，其次是對上傳到OTA服務器的軟件需要先經過證書驗證、簽名驗證和權限驗證。OTA安全方案如圖7所示。

圖7 OTA安全方案

軟件包下載到車內之前，云端和車端會先根據PKI/CA認證系統進行身份互驗。驗證通過后，云端和車端會建立基于TLS1.2安全協議的安全通道，該通道保證云端與車端之間信息傳輸的安全性[6]。

在車內部分，T-Box、IVI和網關之間的交互信息采用私有協議密文傳輸，軟件包的加解密通過在T-Box、IVI和網關內部集成的HSM（硬件安全模塊）來管理、處理和保存加密秘鑰，防止軟件包被篡改。

3.3 回滾重刷策略

在車輛升級過程中，由于出現車輛電池電壓極低、CAN線不穩定的意外情況，升級的控制器要支持回滾，使控制器軟件能夠回滾到上一版本或者初始版本，保證車輛正常運行。對于帶有Linux、QNX和Andriod等智能操作系統的控制器，其系統設計為A/B系統，雙系統交替升級。當A系統處于升級過程中時，B系統正常工作，如果A系統升級成功后，控制器重啟進入A系統，則下次升級時A系統正常工作，B系統進行升級；而當A系統升級失敗后，控制器重啟仍然進入B系統，并嘗試再次對A系統進行升級更新。帶有RTOS傳統實時操作系統的控制器為網關下屬CAN節點ECU，網關作為診斷儀對其進行刷寫升級。升級失敗后網關會調用網關FLASH中存儲的控制器軟件的上一版本再次進行刷寫，若再次刷寫失敗，且控制器程序區已被擦除，控制器功能喪失使用，則控制器內部存儲的初始版本應用程序將會啟動，保證控制器基本功能的使用。

3.4 車輛條件

在升級文件下載完立即進入升級的場景中，車輛升級之前會對車輛條件進行判斷，升級過程中車輛需滿足的條件如表1所列，網關采集表1中信號并進行判斷，若某一條件不滿足，則HMI會彈出界面提示用戶手動操作以滿足升級條件。在預約升級的場景中，T-Box支持定時喚醒功能，在指定的預約時間T-Box喚醒自己并判斷車輛條件滿足后，啟動升級流程對需要升級的控制器進行升級。對于動力系統不具備在IG OFF時被喚醒刷寫升級的能力，需要T-Box喚醒BCM給整車上電，在IG ON狀態下完成刷寫升級。升級過程中BCM還需禁止車內大功率用電負荷（空調、前照燈等）工作，避免蓄電池電量消耗過多。

表1 車輛條件

4 試驗驗證

4.1 試驗方案設計

基于上述方案，在云端組建以OTA服務器集群為主體并集成安全證書平臺、車輛數據信息平臺、負載均衡、數據庫等功能的私有云平臺，以該平臺的硬件為基礎開發并部署云端應用程序，利用公有云CDN服務實現軟件在全國范圍內的高速分發下載。在車端將下載管理、差分還原、升級管理、安全傳輸等組件嵌入到TBox、Gateway和IVI中實現車內所有Ethernet/CAN/LIN節點的刷寫升級。試驗測試方案如圖8所示。

圖8 試驗測試方案

4.2 實物臺架

通過在試驗室搭建基于試驗方案的云端服務器集群和車輛控制器實物臺架，并對OTA整個升級過程建立測試用例，進行正向、逆向的完整測試，部分測試用例如表2所列，測試臺架如圖9所示。

表2 部分測試用例

圖9 測試臺架

4.3 試驗結果

通過臺架試驗對整個OTA系統進行測試，包括HMI的可視化、云服務器端WEB界面的可視化以及云服務器端對關鍵數據的統計，以T-Box測試為例，試驗結果如表3所列。

表3 試驗結果

5 結束語

整車OTA功能是實現智能網聯汽車快速更新迭代的基本條件，也是未來汽車發展中一種必然趨勢。本文提出一種安全、方便、可靠的整車OTA解決方案，并對OTA關鍵技術進行了分析。通過在試驗室搭建基于試驗方案的云端服務器集群和車輛控制器實物臺架，并對OTA整個升級過程建立測試用例，進行了正向、逆向的完整測試，通過測試驗證了整個升級過程的可行性、安全性和可靠性。