基于電子電器架構(gòu)的整車OTA設(shè)計方案

　?。∣ver-the-Air）是一種無線升級技術(shù)，為軟件提供了持續(xù)迭代更新的能力，已逐漸成為智能網(wǎng)聯(lián)汽車的標(biāo)配。整車OTA受限于電子電氣架構(gòu)、升級時間長、控制器多難以控制等限制導(dǎo)致發(fā)展進(jìn)度緩慢，為提高整車OTA的穩(wěn)定性并縮短升級時間，本文提出一種基于電子電器架構(gòu)的整車OTA設(shè)計方案，實現(xiàn)了對升級對象的統(tǒng)一管理、對升級過程的集中控制，并以此提出了整車OTA的平臺化架構(gòu)方案。本設(shè)計方案可應(yīng)用于其他車型，解決了整車OTA涉及控制器多、升級過程不可控、升級時間長和穩(wěn)定性差等問題，形成了一套從云端到車端完整的持續(xù)迭代更新能力和智能網(wǎng)聯(lián)汽車價值提升的新動力。

　　引言

　　OTA（Over-the-Air）即空中下載技術(shù)，是通過移動通信的接口實現(xiàn)對軟件進(jìn)行遠(yuǎn)程管理。OTA是汽車軟件升級的通道，其價值是將新軟件遠(yuǎn)程刷寫到汽車中。軟件定義汽車逐漸成為業(yè)內(nèi)共識，汽車軟件存在兩個趨勢：第一、整車廠交付的汽車將不再是一個功能固化的產(chǎn)品，而是一個持續(xù)更新的智能設(shè)備，在整個生命周期內(nèi)，需要持續(xù)支持軟件迭代升級；第二、隨著軟件量的增加，軟件bug將成為潛在風(fēng)險，OTA可以有效解決軟件故障，通過軟件升級降低開發(fā)周期短帶來的軟件風(fēng)險問題，完成軟件漏洞的修復(fù)，減少軟件問題導(dǎo)致的召回。OTA遠(yuǎn)程升級技術(shù)已逐漸成為智能網(wǎng)聯(lián)汽車的基礎(chǔ)功能，通過持續(xù)迭代的更新軟件，不斷提升汽車的潛在價值，從而帶動智能網(wǎng)聯(lián)汽車行業(yè)全新的商業(yè)模式。

　　需求分析

　　汽車整車OTA受限于電子電氣架構(gòu)，存在很多困難。隨著汽車電子化技術(shù)的提高，電子控制單元ECU占領(lǐng)了諸如動力、底盤、車身、座艙以及自動駕駛等領(lǐng)域，ECU的數(shù)量多達(dá)幾十甚至上百個。這些ECU是由不同的供應(yīng)商提供，運(yùn)行著各種不同的操作系統(tǒng)和應(yīng)用軟件，整車OTA意味著所有相關(guān)的控制器都要在一次升級過程中完成軟件版本的更新，因此升級的總時間和成功率是OTA的兩大難點。而且為了保持軟件升級的穩(wěn)定性和安全性，車輛部分功能將被禁用，要求車輛處于熄火的狀態(tài)，長時間的升級會影響用戶體驗。為了提高整車OTA的穩(wěn)定性、縮短升級時間，本文提出了一種基于整車電子電器架構(gòu)的OTA設(shè)計方案，實現(xiàn)整車版本管理和整車軟件升級。

　　總體方案設(shè)計

　　整車OTA的功能是控制和執(zhí)行車上各類控制器的軟件升級，因此需要對所有關(guān)聯(lián)控制器提出統(tǒng)一的升級要求和規(guī)范，并對升級過程進(jìn)行集中控制。本方案遵循“集中控制、分而治之”的原則，實現(xiàn)了“兩類對象、兩個過程、四種角色”：1）兩類對象：即升級對象分為2類。第一類是智能控制系統(tǒng)，基于操作系統(tǒng)具備自升級能力，如座艙域的車機(jī)、儀表等，駕駛域的自動駕駛控制器等；第二類是傳統(tǒng)的控制器即ECU電控單元，沒有操作系統(tǒng)而是由刷寫上位機(jī)來完成軟件升級。兩類升級對象須遵循各自的技術(shù)要求：智能系統(tǒng)要求實現(xiàn)版本信息維護(hù)、文件存儲、自升級以及升級異常處理等功能；傳統(tǒng)的控制器要求滿足UDS（汽車通用診斷服務(wù)）的刷寫規(guī)范。

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

　　3）四種角色：即功能劃分為4個角色實現(xiàn)職責(zé)分離。第一個角色是OTA服務(wù)端（OTAServer）負(fù)責(zé)web管理平臺、升級數(shù)據(jù)管理和升級文件存儲；第二個角色是OTA客戶端（OTAClient）完成車上所有控制器的版本收集，與服務(wù)端交互獲取升級任務(wù)和上報升級狀態(tài)，下載升級包，將升級包和升級信息分發(fā)到執(zhí)行升級的控制器，負(fù)責(zé)人機(jī)交互功能；第三個角色是OTA主控模塊（OTAMaster）檢查整車的安裝條件、保持安裝狀態(tài)、按照升級策略控制安裝過程；第四個角色是OTA子控模塊（SubMaster）保存升級包、完成所在控制器的升級功能，能夠通過車內(nèi)總線或者USB等其它的物理通道對其他控制器或者固件進(jìn)行升級。 OTAClient、OTAMaster和SubMaster這三個模塊運(yùn)行在車端，基于整車電子電器架構(gòu)被部署到不同的控制器中。角色劃分的目的在于對功能進(jìn)行模塊化設(shè)計，便于在不同車型上實現(xiàn)復(fù)用，從而實現(xiàn)該OTA方案的平臺化和可移植性。基于上述的設(shè)計原則和設(shè)計思路，系統(tǒng)設(shè)計方案如圖1所示：圖1 系統(tǒng)設(shè)計方案

　　詳細(xì)設(shè)計

　　5.1 服務(wù)器端設(shè)計

　　服務(wù)器端，OTA Serve主要實現(xiàn)OTA數(shù)據(jù)的管理，為了支持整車升級，本方案設(shè)計了車型配置管理、整車版本管理、升級任務(wù)管理這三個功能。1）每個車系需要設(shè)置車型配置組，一個組對應(yīng)一個或多個車型配置，一個車型配置只能對應(yīng)唯一的一個組。每個組需要配置所有控制器的軟件集合，通過軟件ID和控制器的軟件保持對應(yīng)關(guān)系。2）整車版本的管理粒度為車型配置組，每個車型配置組的軟件版本按整車大版本來進(jìn)行管理，大版本是一個虛擬的版本，是車型配置組下的所有控制器軟件版本的集合標(biāo)識。3）升級任務(wù)包括升級的控制器對象、安裝策略、升級范圍。新增任務(wù)時需要設(shè)置車系、車型配置組以及對應(yīng)的目標(biāo)整車版本。每個升級對象可設(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)組。

　　5.2 汽車端設(shè)計

　　5.2.1流程設(shè)計

　　OTAClient通常部署在車機(jī)或者T-BOX上，具有車聯(lián)網(wǎng)功能、人機(jī)交互功能、文件存儲和分發(fā)的功能。OTAMaster通常部署在中心節(jié)點網(wǎng)關(guān)上，對升級過程進(jìn)行控制和協(xié)調(diào)。SubMaster會有多個，通常部署在有操作系統(tǒng)（android、qnx、linux等）的智能控制器上，如車機(jī)、儀表、智能駕駛控制器等。另外，網(wǎng)關(guān)負(fù)責(zé)傳統(tǒng)控制器的刷寫功能，也需要部署一個SubMaster模塊。車端的架構(gòu)如圖2所示：圖2 車端的架構(gòu)設(shè)計1）下載部署過程，OTAClient將下載過程和分發(fā)過程進(jìn)行同步處理，使兩個過程可以并發(fā)執(zhí)行，以縮短升級包下載部署的時間，同時減少對儲存空間的需求。OTAClient根據(jù)硬件通道的不同，優(yōu)先下載數(shù)據(jù)傳輸速率低的SubMaster節(jié)點的升級包，最后下載OTAClient所在的SubMaster節(jié)點的升級包；單個SubMaster的升級包下載完成就可以進(jìn)行文件部署。如果在下載部署過程中，車輛熄火，則停止下載和部署；下次點火后，繼續(xù)在斷點處執(zhí)行。

　　整個過程可以在行車中執(zhí)行，不影響用戶用車。2）安裝過程，由OTAMaster集成控制，用戶確認(rèn)發(fā)起安裝后，OTAMaster根據(jù)升級信息中安裝條件，檢測整車安裝條件是否滿足，發(fā)起安裝后一直保持安裝的狀態(tài)，如電源檔位、行車檔位、整車OTA狀態(tài)等。OTA Master依次向各個的SubMaster發(fā)送安裝請求；收到安裝請求，SubMaster各自執(zhí)行升級，SubMaster之間可以進(jìn)行并行升級。通常網(wǎng)關(guān)作為傳統(tǒng)控制器的SubMaster，實現(xiàn)各個網(wǎng)段之間的并行刷寫。OTA Master按照升級任務(wù)中安裝順序執(zhí)行，安裝順序由多個子任務(wù)組成，子任務(wù)之間串行執(zhí)行，而子任務(wù)內(nèi)的升級對象則是并行執(zhí)行升級。如果控制器的安裝順序存在依賴，則需要把被依賴和依賴的控制器劃分到不同的子任務(wù)中，并分配為先后的順序。升級任務(wù)的安裝總時間如公式（1）所示：其中，t_n 為子任務(wù)n中的耗時最長的SubMaster的安裝時間。5.2.2協(xié)議設(shè)計為了滿足車端OTA過程中功能模塊之間數(shù)據(jù)交互的，本方案中設(shè)計了兩套通信協(xié)議，如圖3所示。圖3 車端的通信協(xié)議1）部署協(xié)議，主要在部署過程和人機(jī)交互過程中使用。協(xié)議采用的是客戶端和服務(wù)端（C/S）的模式，OTAClient作為客戶端，SubMaster和OTA Master作為服務(wù)端。物理的通道包括CANFD、以太網(wǎng)、USB等。部署協(xié)議的交互覆蓋四個子過程。a）子過程1.1版本收集：OTAClient向各個SubMaster發(fā)出版本收集請求，SubMaster收集版本的范圍包括其所部署的控制器的軟件版本、以及所負(fù)責(zé)刷寫的其他控制器或者控制升級的其他固件的軟件版本。b）子過程1.2升級信息和升級包的分發(fā)：OTAClient下載完成后，要向各個Sub Master傳輸升級包，以及升級對象的信息。

　　OTAClient向OTAMaster發(fā)送升級任務(wù)信息。c）子過程1.3發(fā)起安裝請求：OTAClient根據(jù)人機(jī)交互的觸發(fā)，發(fā)送安裝請求到OTAMaster；如果支持升級取消，也通過該子過程發(fā)送請求。d）子過程1.4安裝狀態(tài)查詢：OTAClient查詢OTAMaster的安裝條件檢查及結(jié)果、安裝執(zhí)行的狀態(tài)、安裝進(jìn)度和安裝結(jié)果，用于人機(jī)交互界面的顯示。2）安裝控制協(xié)議，主要是在安裝過程中使用，通過診斷服務(wù)，借助診斷通道到達(dá)全車所有的控制器。安裝控制協(xié)議的交互覆蓋了兩個子過程分別是，子過程2.1安裝控制：OTAMaster按照升級任務(wù)，向子任務(wù)中的各個SubMaster發(fā)出安裝命令請求，查詢安裝的進(jìn)度，SubMaster返回執(zhí)行狀態(tài)。子過程2.1回滾控制：當(dāng)所有的子任務(wù)安裝執(zhí)行完成后，OTAMaster讀取安裝結(jié)果，判斷是否有升級對象安裝失敗；并讀取升級任務(wù)中的關(guān)聯(lián)組新，如果升級失敗的對象和其他升級對象是在一個關(guān)聯(lián)組內(nèi)，則向該組內(nèi)其他升級對象的SubMaster發(fā)出回滾命令請求，查詢回滾的進(jìn)度，SubMaster返回執(zhí)行狀態(tài)。

　　應(yīng)用案例

　　按照以上的整車OTA設(shè)計，在某車型項目上開發(fā)整車OTA功能，如圖4所示，部署升級功能模塊和搭建升級通道。車機(jī)作為OTAClient，網(wǎng)關(guān)作為OTA Master，實現(xiàn)對座艙域、車身域、動力域、底盤域、自動駕駛域的控制器的OTA功能；覆蓋了18個控制器，其中包括4個智能控制系統(tǒng)，14個傳統(tǒng)控制器；部署了5個SubMaster節(jié)點，分別是車機(jī)、儀表、網(wǎng)關(guān)、自動駕駛控制器、駕駛輔助控制器。圖4 某項目整車OTA方案在OTA管理平臺配置車型信息和控制器的升級依賴關(guān)系，發(fā)布升級任務(wù)，選擇對18個控制器，詳即所有升級對象進(jìn)行升級，云端自動生成升級任務(wù)信息，其中的安裝順序如圖5所示。圖5 某項目整車OTA安裝順序 按照圖5的安裝順序，對車端OTA的過程進(jìn)行記錄，下載部署過程和安裝過程的時間分別如表1和表2所示。從下載到安裝一共需要44分鐘，影響用戶體驗的升級時間主要是安裝過程，用戶需要等待升級完成的時間是28分鐘。如果所有控制器都采用串行的升級順序，安裝過程的時間是77分鐘。本方案用戶等待升級時間明顯縮短，相比串行升級時間降低63.6%，大幅提升了OTA的用戶體驗滿意度。表1 下載部署過程的時間表2 安裝過程的時間如表2所示，安裝過程的耗時瓶頸主要在CANFD1網(wǎng)段，如果在其他網(wǎng)段上適當(dāng)增加控制器則不會影響總的時間。如果要縮短總時間，需要對CANFD1網(wǎng)段的控制器進(jìn)行優(yōu)化，優(yōu)化方向主要是減少升級包大小、將傳統(tǒng)控制器改為智能控制系統(tǒng)等。

　　結(jié)論

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

　　編輯：黃飛