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

（中國第一汽車集團有限公司智能網(wǎng)聯(lián)開發(fā)院，長春 130011）

主題詞：智能網(wǎng)聯(lián)汽車 整車OTA 差分算法 回滾重刷機制

1 前言

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

2 OTA系統(tǒng)架構(gòu)

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

2.1 云服務器端

2.1.1 硬件系統(tǒng)

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

圖1 OTA系統(tǒng)架構(gòu)

圖2 云端服務器架構(gòu)

2.1.2 軟件系統(tǒng)

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

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

2.2 車輛客戶端

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

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

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

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

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

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

圖3 車輛客戶端通信協(xié)議

2.3 OTA升級流程

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

圖4 OTA升級流程

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

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

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

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

3 OTA關(guān)鍵技術(shù)

3.1 差分算法

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

圖5 差分算法原理

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

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

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

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

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

圖6 差分描述文件生成

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

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

3.2 安全方案

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

圖7 OTA安全方案

軟件包下載到車內(nèi)之前，云端和車端會先根據(jù)PKI/CA認證系統(tǒng)進行身份互驗。驗證通過后，云端和車端會建立基于TLS1.2安全協(xié)議的安全通道，該通道保證云端與車端之間信息傳輸?shù)陌踩訹6]。

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

3.3 回滾重刷策略

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

3.4 車輛條件

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

表1 車輛條件

4 試驗驗證

4.1 試驗方案設計

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

圖8 試驗測試方案

4.2 實物臺架

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

表2 部分測試用例

圖9 測試臺架

4.3 試驗結(jié)果

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

表3 試驗結(jié)果

5 結(jié)束語

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