01 摘要

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

02 引言

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

03 需求分析

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

【資料圖】

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

04 總體方案設(shè)計(jì)

整車OTA的功能是控制和執(zhí)行車上各類控制器的軟件升級(jí)，因此需要對(duì)所有關(guān)聯(lián)控制器提出統(tǒng)一的升級(jí)要求和規(guī)范，并對(duì)升級(jí)過程進(jìn)行集中控制。本方案遵循“集中控制、分而治之”的原則，實(shí)現(xiàn)了“兩類對(duì)象、兩個(gè)過程、四種角色”：

1）兩類對(duì)象：即升級(jí)對(duì)象分為2類。

第一類是智能控制系統(tǒng)，基于操作系統(tǒng)具備自升級(jí)能力，如座艙域的車機(jī)、儀表等，駕駛域的自動(dòng)駕駛控制器等；

第二類是傳統(tǒng)的控制器即ECU電控單元，沒有操作系統(tǒng)而是由刷寫上位機(jī)來完成軟件升級(jí)。

兩類升級(jí)對(duì)象須遵循各自的技術(shù)要求：智能系統(tǒng)要求實(shí)現(xiàn)版本信息維護(hù)、文件存儲(chǔ)、自升級(jí)以及升級(jí)異常處理等功能；傳統(tǒng)的控制器要求滿足UDS（汽車通用診斷服務(wù)）的刷寫規(guī)范。升級(jí)對(duì)象分類的目的在于將車上眾多的控制器按照其軟件升級(jí)方式的不同進(jìn)行分類管理，對(duì)同類的控制器提出一致的技術(shù)要求規(guī)范，以便于實(shí)現(xiàn)OTA升級(jí)對(duì)象管理的標(biāo)準(zhǔn)化。

2）兩個(gè)過程：即升級(jí)過程分為2個(gè)過程。

第一個(gè)過程是下載部署過程，服務(wù)器將升級(jí)任務(wù)通知到車輛，車端從服務(wù)器端下載升級(jí)包到本地，這個(gè)過程可在車輛行駛中進(jìn)行不會(huì)對(duì)用戶產(chǎn)生影響；

第二個(gè)過程是安裝過程即“車端各個(gè)控制器執(zhí)行軟件升級(jí)”，這個(gè)過程需要保持車輛處于特定的狀態(tài)如車速為零、發(fā)動(dòng)機(jī)熄火等，所以不能正常用車。下載部署過程和安裝過程中的執(zhí)行對(duì)象、執(zhí)行條件以及控制策略是不同的，將過程分段的目的在于實(shí)現(xiàn)OTA不同過程的差異化控制，能夠?qū)Ω鞣N過程進(jìn)行集中控制，并在一個(gè)模塊中實(shí)現(xiàn)。

3）四種角色：即功能劃分為4個(gè)角色實(shí)現(xiàn)職責(zé)分離。

第一個(gè)角色是OTA服務(wù)端（OTAServer）負(fù)責(zé)web管理平臺(tái)、升級(jí)數(shù)據(jù)管理和升級(jí)文件存儲(chǔ)；

第二個(gè)角色是OTA客戶端（OTAClient）完成車上所有控制器的版本收集，與服務(wù)端交互獲取升級(jí)任務(wù)和上報(bào)升級(jí)狀態(tài)，下載升級(jí)包，將升級(jí)包和升級(jí)信息分發(fā)到執(zhí)行升級(jí)的控制器，負(fù)責(zé)人機(jī)交互功能；

第三個(gè)角色是OTA主控模塊（OTAMaster）檢查整車的安裝條件、保持安裝狀態(tài)、按照升級(jí)策略控制安裝過程；

第四個(gè)角色是OTA子控模塊（SubMaster）保存升級(jí)包、完成所在控制器的升級(jí)功能，能夠通過車內(nèi)總線或者USB等其它的物理通道對(duì)其他控制器或者固件進(jìn)行升級(jí)。

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

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

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

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

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

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

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

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

2）整車版本的管理粒度為車型配置組，每個(gè)車型配置組的軟件版本按整車大版本來進(jìn)行管理，大版本是一個(gè)虛擬的版本，是車型配置組下的所有控制器軟件版本的集合標(biāo)識(shí)。

3）升級(jí)任務(wù)包括升級(jí)的控制器對(duì)象、安裝策略、升級(jí)范圍。新增任務(wù)時(shí)需要設(shè)置車系、車型配置組以及對(duì)應(yīng)的目標(biāo)整車版本。每個(gè)升級(jí)對(duì)象可設(shè)置其軟件更新的方式、安裝的時(shí)間和異常處理的上限次數(shù)。安裝策略包括安裝條件、安裝順序和軟件版本依賴。

a)安裝條件包括：行車檔位、電池電量范圍、溫度下限、電源檔位等。在OTA管理平臺(tái)設(shè)置可設(shè)置每次OTA的安裝條件，并生成信息到升級(jí)任務(wù)中。

b)安裝順序包括升級(jí)對(duì)象的并行或者串行升級(jí)順序。在OTA管理平臺(tái)設(shè)置SubMaster和升級(jí)對(duì)象的包含關(guān)系以及升級(jí)對(duì)象之間的安裝依賴關(guān)系，在創(chuàng)建升級(jí)任務(wù)時(shí)根據(jù)上述關(guān)系自動(dòng)生成升級(jí)任務(wù)的安裝順序。

c）軟件版本依賴包括多個(gè)關(guān)聯(lián)組，關(guān)聯(lián)組內(nèi)的升級(jí)對(duì)象版本要支持同升同降。在OTA管理平臺(tái)設(shè)置控制器之間的關(guān)聯(lián)關(guān)系，創(chuàng)建升級(jí)任務(wù)時(shí)根據(jù)關(guān)聯(lián)設(shè)置自動(dòng)生成升級(jí)任務(wù)的關(guān)聯(lián)組。

5.2 汽車端設(shè)計(jì)

5.2.1流程設(shè)計(jì)

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

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

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

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

2）安裝過程，由OTAMaster集成控制，用戶確認(rèn)發(fā)起安裝后，OTAMaster根據(jù)升級(jí)信息中安裝條件，檢測整車安裝條件是否滿足，發(fā)起安裝后一直保持安裝的狀態(tài)，如電源檔位、行車檔位、整車OTA狀態(tài)等。OTA Master依次向各個(gè)的SubMaster發(fā)送安裝請(qǐng)求；收到安裝請(qǐng)求，SubMaster各自執(zhí)行升級(jí)，SubMaster之間可以進(jìn)行并行升級(jí)。通常網(wǎng)關(guān)作為傳統(tǒng)控制器的SubMaster，實(shí)現(xiàn)各個(gè)網(wǎng)段之間的并行刷寫。OTA Master按照升級(jí)任務(wù)中安裝順序執(zhí)行，安裝順序由多個(gè)子任務(wù)組成，子任務(wù)之間串行執(zhí)行，而子任務(wù)內(nèi)的升級(jí)對(duì)象則是并行執(zhí)行升級(jí)。如果控制器的安裝順序存在依賴，則需要把被依賴和依賴的控制器劃分到不同的子任務(wù)中，并分配為先后的順序。升級(jí)任務(wù)的安裝總時(shí)間如公式（1）所示：

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

5.2.2協(xié)議設(shè)計(jì)

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

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

1）部署協(xié)議，主要在部署過程和人機(jī)交互過程中使用。協(xié)議采用的是客戶端和服務(wù)端（C/S）的模式，OTAClient作為客戶端，SubMaster和OTA Master作為服務(wù)端。物理的通道包括CANFD、以太網(wǎng)、USB等。部署協(xié)議的交互覆蓋四個(gè)子過程。

a）子過程1.1版本收集：OTAClient向各個(gè)SubMaster發(fā)出版本收集請(qǐng)求，SubMaster收集版本的范圍包括其所部署的控制器的軟件版本、以及所負(fù)責(zé)刷寫的其他控制器或者控制升級(jí)的其他固件的軟件版本。

b）子過程1.2升級(jí)信息和升級(jí)包的分發(fā)：OTAClient下載完成后，要向各個(gè)Sub Master傳輸升級(jí)包，以及升級(jí)對(duì)象的信息。OTAClient向OTAMaster發(fā)送升級(jí)任務(wù)信息。

c）子過程1.3發(fā)起安裝請(qǐng)求：OTAClient根據(jù)人機(jī)交互的觸發(fā)，發(fā)送安裝請(qǐng)求到OTAMaster；如果支持升級(jí)取消，也通過該子過程發(fā)送請(qǐng)求。

d）子過程1.4安裝狀態(tài)查詢：OTAClient查詢OTAMaster的安裝條件檢查及結(jié)果、安裝執(zhí)行的狀態(tài)、安裝進(jìn)度和安裝結(jié)果，用于人機(jī)交互界面的顯示。

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

06 應(yīng)用案例

按照以上的整車OTA設(shè)計(jì)，在某車型項(xiàng)目上開發(fā)整車OTA功能，如圖4所示，部署升級(jí)功能模塊和搭建升級(jí)通道。車機(jī)作為OTAClient，網(wǎng)關(guān)作為OTA Master，實(shí)現(xiàn)對(duì)座艙域、車身域、動(dòng)力域、底盤域、自動(dòng)駕駛域的控制器的OTA功能；覆蓋了18個(gè)控制器，其中包括4個(gè)智能控制系統(tǒng)，14個(gè)傳統(tǒng)控制器；部署了5個(gè)SubMaster節(jié)點(diǎn)，分別是車機(jī)、儀表、網(wǎng)關(guān)、自動(dòng)駕駛控制器、駕駛輔助控制器。

圖4 某項(xiàng)目整車OTA方案

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

圖5 某項(xiàng)目整車OTA安裝順序

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

表1 下載部署過程的時(shí)間

表2 安裝過程的時(shí)間

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

07結(jié)論

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

關(guān)鍵詞：