作者：劉俊, 馬云林, 劉平, 黃正瑜

為了提高整車OTA的穩(wěn)定性、縮短升級時間，本文提出了一種基于整車電子電器架構(gòu)的OTA設(shè)計方案，實現(xiàn)整車版本管理和整車軟件升級。

1）兩類對象：即升級對象分為2類，第一類是智能控制系統(tǒng)，基于操作系統(tǒng)具備自升級能力，如座艙域的車機、儀表等，駕駛域的自動駕駛控制器等；第二類是傳統(tǒng)的控制器即ECU電控單元，沒有操作系統(tǒng)而是由刷寫上位機來完成軟件升級。兩類升級對象須遵循各自的技術(shù)要求：智能系統(tǒng)要求實現(xiàn)版本信息維護、文件存儲、自升級以及升級異常處理等功能；傳統(tǒng)的控制器要求滿足UDS（汽車通用診斷服務(wù)）的刷寫規(guī)范。升級對象分類的目的在于將車上眾多的控制器按照其軟件升級方式的不同進行分類管理，對同類的控制器提出一致的技術(shù)要求規(guī)范，以便于實現(xiàn)OTA升級對象管理的標準化。

2）兩個過程：即升級過程分為2個過程，第一個過程是下載部署過程，服務(wù)器將升級任務(wù)通知到車輛，車端從服務(wù)器端下載升級包到本地，這個過程可在車輛行駛中進行不會對用戶產(chǎn)生影響；第二個過程是安裝過程即“車端各個控制器執(zhí)行軟件升級”，這個過程需要保持車輛處于特定的狀態(tài)如車速為零、發(fā)動機熄火等，所以不能正常用車。下載部署過程和安裝過程中的執(zhí)行對象、執(zhí)行條件以及控制策略是不同的，將過程分段的目的在于實現(xiàn)OTA不同過程的差異化控制，能夠?qū)Ω鞣N過程進行集中控制，并在一個模塊中實現(xiàn)。

3）四種角色：即功能劃分為4個角色實現(xiàn)職責分離，第一個角色是OTA服務(wù)端（OTAServer）負責web管理平臺、升級數(shù)據(jù)管理和升級文件存儲[2]；第二個角色是OTA客戶端（OTAClient）完成車上所有控制器的版本收集，與服務(wù)端交互獲取升級任務(wù)和上報升級狀態(tài)，下載升級包，將升級包和升級信息分發(fā)到執(zhí)行升級的控制器，負責人機交互功能；第三個角色是OTA主控模塊（OTAMaster）檢查整車的安裝條件、保持安裝狀態(tài)、按照升級策略控制安裝過程；第四個角色是OTA子控模塊（SubMaster）保存升級包、完成所在控制器的升級功能，能夠通過車內(nèi)總線或者USB等其它的物理通道對其他控制器或者固件進行升級。 

OTAClient、OTAMaster和SubMaster這三個模塊運行在車端，基于整車電子電器架構(gòu)被部署到不同的控制器中。角色劃分的目的在于對功能進行模塊化設(shè)計，便于在不同車型上實現(xiàn)復用，從而實現(xiàn)該OTA方案的平臺化和可移植性。

基于上述的設(shè)計原則和設(shè)計思路，系統(tǒng)設(shè)計方案如圖1所示：

圖1 系統(tǒng)設(shè)計方案

在車端，下載部署過程，包括圖1中的步驟1.1和步驟1.2，由OTAClient發(fā)起，先從OTAServer下載文件，再將升級信息和升級包分發(fā)到各個執(zhí)行升級的SubMaster；安裝過程包括圖1中的步驟2.1和步驟2.2，由OTAMaster發(fā)起，進行安裝控制，判斷整車安裝條件是否滿足，維持整車安裝狀態(tài)，按照安裝順序向各個SubMaster發(fā)出安裝命令；SubMaster分別執(zhí)行具體的升級操作，完成自升級或者對其他控制器的刷寫。各個SubMaster的升級可以獨立執(zhí)行，因此需要OTAMaster總體協(xié)調(diào)。

服務(wù)器端,OTA Serve主要實現(xiàn)OTA數(shù)據(jù)的管理，為了支持整車升級，本方案設(shè)計了車型配置管理、整車版本管理、升級任務(wù)管理這三個功能。

1）每個車系需要設(shè)置車型配置組，一個組對應一個或多個車型配置，一個車型配置只能對應唯一的一個組。每個組需要配置所有控制器的軟件集合，通過軟件ID和控制器的軟件保持對應關(guān)系。

2）整車版本的管理粒度為車型配置組，每個車型配置組的軟件版本按整車大版本來進行管理，大版本是一個虛擬的版本，是車型配置組下的所有控制器軟件版本的集合標識。

3）升級任務(wù)包括升級的控制器對象、安裝策略、升級范圍。新增任務(wù)時需要設(shè)置車系、車型配置組以及對應的目標整車版本。每個升級對象可設(shè)置其軟件更新的方式、安裝的時間和異常處理的上限次數(shù)。安裝策略包括安裝條件、安裝順序和軟件版本依賴。a)安裝條件包括：行車檔位、電池電量范圍、溫度下限、電源檔位等。在OTA管理平臺設(shè)置可設(shè)置每次OTA的安裝條件，并生成信息到升級任務(wù)中。b)安裝順序包括升級對象的并行或者串行升級順序。在OTA管理平臺設(shè)置SubMaster和升級對象的包含關(guān)系以及升級對象之間的安裝依賴關(guān)系，在創(chuàng)建升級任務(wù)時根據(jù)上述關(guān)系自動生成升級任務(wù)的安裝順序。c）軟件版本依賴包括多個關(guān)聯(lián)組，關(guān)聯(lián)組內(nèi)的升級對象版本要支持同升同降。在OTA管理平臺設(shè)置控制器之間的關(guān)聯(lián)關(guān)系，創(chuàng)建升級任務(wù)時根據(jù)關(guān)聯(lián)設(shè)置自動生成升級任務(wù)的關(guān)聯(lián)組。

3.2 汽車端設(shè)計

3.2.1流程設(shè)計

在車端，包括下載部署過程和安裝過程，這兩個過程分別由不同的功能模塊來執(zhí)行，保證各個過程中有相同的控制主體和統(tǒng)一的控制流程。

OTAClient通常部署在車機或者T-BOX上，具有車聯(lián)網(wǎng)功能、人機交互功能、文件存儲和分發(fā)的功能[3]。OTAMaster通常部署在中心節(jié)點網(wǎng)關(guān)上，對升級過程進行控制和協(xié)調(diào)[4]。SubMaster會有多個，通常部署在有操作系統(tǒng)（android、qnx、linux等）的智能控制器上，如車機、儀表、智能駕駛控制器等。另外，網(wǎng)關(guān)負責傳統(tǒng)控制器的刷寫功能，也需要部署一個SubMaster模塊。車端的架構(gòu)如圖2所示：

圖2 車端的架構(gòu)設(shè)計

1）下載部署過程，OTAClient將下載過程和分發(fā)過程進行同步處理，使兩個過程可以并發(fā)執(zhí)行，以縮短升級包下載部署的時間，同時減少對儲存空間的需求。OTAClient根據(jù)硬件通道的不同，優(yōu)先下載數(shù)據(jù)傳輸速率低的SubMaster節(jié)點的升級包，最后下載OTAClient所在的SubMaster節(jié)點的升級包；單個SubMaster的升級包下載完成就可以進行文件部署。如果在下載部署過程中，車輛熄火，則停止下載和部署；下次點火后，繼續(xù)在斷點處執(zhí)行。整個過程可以在行車中執(zhí)行，不影響用戶用車。

2）安裝過程，由OTAMaster集成控制，用戶確認發(fā)起安裝后，OTAMaster根據(jù)升級信息中安裝條件，檢測整車安裝條件是否滿足，發(fā)起安裝后一直保持安裝的狀態(tài)，如電源檔位、行車檔位、整車OTA狀態(tài)等。OTA Master依次向各個的SubMaster發(fā)送安裝請求；收到安裝請求，SubMaster各自執(zhí)行升級，SubMaster之間可以進行并行升級。通常網(wǎng)關(guān)作為傳統(tǒng)控制器的SubMaster，實現(xiàn)各個網(wǎng)段之間的并行刷寫。

其中，t_n 為子任務(wù)n中的耗時最長的SubMaster的安裝時間。

3.2.2協(xié)議設(shè)計

為了滿足車端OTA過程中功能模塊之間數(shù)據(jù)交互的，本方案中設(shè)計了兩套通信協(xié)議，如圖3所示。

圖3 車端的通信協(xié)議

1）部署協(xié)議，主要在部署過程和人機交互過程中使用。協(xié)議采用的是客戶端和服務(wù)端（C/S）的模式，OTAClient作為客戶端，SubMaster和OTA Master作為服務(wù)端。物理的通道包括CANFD、以太網(wǎng)、USB等。部署協(xié)議的交互覆蓋四個子過程。a）子過程1.1版本收集：OTAClient向各個SubMaster發(fā)出版本收集請求，SubMaster收集版本的范圍包括其所部署的控制器的軟件版本、以及所負責刷寫的其他控制器或者控制升級的其他固件的軟件版本。b）子過程1.2升級信息和升級包的分發(fā)：OTAClient下載完成后，要向各個Sub Master傳輸升級包，以及升級對象的信息。OTAClient向OTAMaster發(fā)送升級任務(wù)信息。c）子過程1.3發(fā)起安裝請求：OTAClient根據(jù)人機交互的觸發(fā)，發(fā)送安裝請求到OTAMaster；如果支持升級取消，也通過該子過程發(fā)送請求。d）子過程1.4安裝狀態(tài)查詢：OTAClient查詢OTAMaster的安裝條件檢查及結(jié)果、安裝執(zhí)行的狀態(tài)、安裝進度和安裝結(jié)果，用于人機交互界面的顯示。

2）安裝控制協(xié)議，主要是在安裝過程中使用，通過診斷服務(wù)，借助診斷通道到達全車所有的控制器[5]。安裝控制協(xié)議的交互覆蓋了兩個子過程分別是，子過程2.1安裝控制：OTAMaster按照升級任務(wù)，向子任務(wù)中的各個SubMaster發(fā)出安裝命令請求，查詢安裝的進度，SubMaster返回執(zhí)行狀態(tài)。子過程2.1回滾控制：當所有的子任務(wù)安裝執(zhí)行完成后，OTAMaster讀取安裝結(jié)果，判斷是否有升級對象安裝失??；并讀取升級任務(wù)中的關(guān)聯(lián)組新，如果升級失敗的對象和其他升級對象是在一個關(guān)聯(lián)組內(nèi)，則向該組內(nèi)其他升級對象的SubMaster發(fā)出回滾命令請求，查詢回滾的進度，SubMaster返回執(zhí)行狀態(tài)。

圖4 某項目整車OTA方案

在OTA管理平臺配置車型信息和控制器的升級依賴關(guān)系，發(fā)布升級任務(wù)，選擇對18個控制器，即所有升級對象進行升級，云端自動生成升級任務(wù)信息，其中的安裝順序如圖5所示。

圖5 某項目整車OTA安裝順序 

按照圖5的安裝順序，對車端OTA的過程進行記錄，下載部署過程和安裝過程的時間分別如表1和表2所示。從下載到安裝一共需要44分鐘，影響用戶體驗的升級時間主要是安裝過程，用戶需要等待升級完成的時間是28分鐘。如果所有控制器都采用串行的升級順序，安裝過程的時間是77分鐘。本方案用戶等待升級時間明顯縮短，相比串行升級時間降低63.6%，大幅提升了OTA的用戶體驗滿意度。

表2 安裝過程的時間

如表2所示，安裝過程的耗時瓶頸主要在CANFD1網(wǎng)段，如果在其他網(wǎng)段上適當增加控制器則不會影響總的時間。如果要縮短總時間，需要對CANFD1網(wǎng)段的控制器進行優(yōu)化，優(yōu)化方向主要是減少升級包大小、將傳統(tǒng)控制器改為智能控制系統(tǒng)等。

本文提出的一種基于電子電器架構(gòu)的整車OTA設(shè)計方案，實現(xiàn)了對升級對象的統(tǒng)一管理、對升級過程的集中控制、對升級功能的模塊化設(shè)計。從試驗的效果來看，通過OTA管理平臺配置升級策略、明顯縮短了升級時間，是一個可實施、可平臺化的設(shè)計。本設(shè)計方案可應用于其他車型的整車OTA，解決了整車OTA控制器多、升級過程不可控、升級時間長和穩(wěn)定性差等問題，形成了一套從云端到車端完整的持續(xù)迭代更新能力和智能網(wǎng)聯(lián)汽車價值提升的新動力。