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

　　引言

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

　　需求分析

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

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

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

　　升級(jí)對(duì)象分類(lèi)的目的在于將車(chē)上眾多的控制器按照其軟件升級(jí)方式的不同進(jìn)行分類(lèi)管理，對(duì)同類(lèi)的控制器提出一致的技術(shù)要求規(guī)范，以便于實(shí)現(xiàn)OTA升級(jí)對(duì)象管理的標(biāo)準(zhǔn)化。2）兩個(gè)過(guò)程：即升級(jí)過(guò)程分為2個(gè)過(guò)程。第一個(gè)過(guò)程是下載部署過(guò)程，服務(wù)器將升級(jí)任務(wù)通知到車(chē)輛，車(chē)端從服務(wù)器端下載升級(jí)包到本地，這個(gè)過(guò)程可在車(chē)輛行駛中進(jìn)行不會(huì)對(duì)用戶(hù)產(chǎn)生影響；第二個(gè)過(guò)程是安裝過(guò)程即“車(chē)端各個(gè)控制器執(zhí)行軟件升級(jí)”，這個(gè)過(guò)程需要保持車(chē)輛處于特定的狀態(tài)如車(chē)速為零、發(fā)動(dòng)機(jī)熄火等，所以不能正常用車(chē)。下載部署過(guò)程和安裝過(guò)程中的執(zhí)行對(duì)象、執(zhí)行條件以及控制策略是不同的，將過(guò)程分段的目的在于實(shí)現(xiàn)OTA不同過(guò)程的差異化控制，能夠?qū)Ω鞣N過(guò)程進(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客戶(hù)端（OTAClient）完成車(chē)上所有控制器的版本收集，與服務(wù)端交互獲取升級(jí)任務(wù)和上報(bào)升級(jí)狀態(tài)，下載升級(jí)包，將升級(jí)包和升級(jí)信息分發(fā)到執(zhí)行升級(jí)的控制器，負(fù)責(zé)人機(jī)交互功能；第三個(gè)角色是OTA主控模塊（OTAMaster）檢查整車(chē)的安裝條件、保持安裝狀態(tài)、按照升級(jí)策略控制安裝過(guò)程；第四個(gè)角色是OTA子控模塊（SubMaster）保存升級(jí)包、完成所在控制器的升級(jí)功能，能夠通過(guò)車(chē)內(nèi)總線(xiàn)或者USB等其它的物理通道對(duì)其他控制器或者固件進(jìn)行升級(jí)。 OTAClient、OTAMaster和SubMaster這三個(gè)模塊運(yùn)行在車(chē)端，基于整車(chē)電子電器架構(gòu)被部署到不同的控制器中。角色劃分的目的在于對(duì)功能進(jìn)行模塊化設(shè)計(jì)，便于在不同車(chē)型上實(shí)現(xiàn)復(fù)用，從而實(shí)現(xiàn)該OTA方案的平臺(tái)化和可移植性?；谏鲜龅脑O(shè)計(jì)原則和設(shè)計(jì)思路，系統(tǒng)設(shè)計(jì)方案如圖1所示：圖1 系統(tǒng)設(shè)計(jì)方案

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

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

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

　　安裝策略包括安裝條件、安裝順序和軟件版本依賴(lài)。a）安裝條件包括：行車(chē)檔位、電池電量范圍、溫度下限、電源檔位等。在OTA管理平臺(tái)設(shè)置可設(shè)置每次OTA的安裝條件，并生成信息到升級(jí)任務(wù)中。b）安裝順序包括升級(jí)對(duì)象的并行或者串行升級(jí)順序。在OTA管理平臺(tái)設(shè)置SubMaster和升級(jí)對(duì)象的包含關(guān)系以及升級(jí)對(duì)象之間的安裝依賴(lài)關(guān)系，在創(chuàng)建升級(jí)任務(wù)時(shí)根據(jù)上述關(guān)系自動(dòng)生成升級(jí)任務(wù)的安裝順序。c）軟件版本依賴(lài)包括多個(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 汽車(chē)端設(shè)計(jì)

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

　　OTAClient通常部署在車(chē)機(jī)或者T-BOX上，具有車(chē)聯(lián)網(wǎng)功能、人機(jī)交互功能、文件存儲(chǔ)和分發(fā)的功能。OTAMaster通常部署在中心節(jié)點(diǎn)網(wǎng)關(guān)上，對(duì)升級(jí)過(guò)程進(jìn)行控制和協(xié)調(diào)。SubMaster會(huì)有多個(gè)，通常部署在有操作系統(tǒng)（android、qnx、linux等）的智能控制器上，如車(chē)機(jī)、儀表、智能駕駛控制器等。另外，網(wǎng)關(guān)負(fù)責(zé)傳統(tǒng)控制器的刷寫(xiě)功能，也需要部署一個(gè)SubMaster模塊。車(chē)端的架構(gòu)如圖2所示：圖2 車(chē)端的架構(gòu)設(shè)計(jì)1）下載部署過(guò)程，OTAClient將下載過(guò)程和分發(fā)過(guò)程進(jìn)行同步處理，使兩個(gè)過(guò)程可以并發(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)行文件部署。如果在下載部署過(guò)程中，車(chē)輛熄火，則停止下載和部署；下次點(diǎn)火后，繼續(xù)在斷點(diǎn)處執(zhí)行。

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

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

　　應(yīng)用案例

　　按照以上的整車(chē)OTA設(shè)計(jì)，在某車(chē)型項(xiàng)目上開(kāi)發(fā)整車(chē)OTA功能，如圖4所示，部署升級(jí)功能模塊和搭建升級(jí)通道。車(chē)機(jī)作為OTAClient，網(wǎng)關(guān)作為OTA Master，實(shí)現(xiàn)對(duì)座艙域、車(chē)身域、動(dòng)力域、底盤(pán)域、自動(dòng)駕駛域的控制器的OTA功能；覆蓋了18個(gè)控制器，其中包括4個(gè)智能控制系統(tǒng)，14個(gè)傳統(tǒng)控制器；部署了5個(gè)SubMaster節(jié)點(diǎn)，分別是車(chē)機(jī)、儀表、網(wǎng)關(guān)、自動(dòng)駕駛控制器、駕駛輔助控制器。圖4 某項(xiàng)目整車(chē)OTA方案在OTA管理平臺(tái)配置車(chē)型信息和控制器的升級(jí)依賴(lài)關(guān)系，發(fā)布升級(jí)任務(wù)，選擇對(duì)18個(gè)控制器，詳即所有升級(jí)對(duì)象進(jìn)行升級(jí)，云端自動(dòng)生成升級(jí)任務(wù)信息，其中的安裝順序如圖5所示。圖5 某項(xiàng)目整車(chē)OTA安裝順序 按照?qǐng)D5的安裝順序，對(duì)車(chē)端OTA的過(guò)程進(jìn)行記錄，下載部署過(guò)程和安裝過(guò)程的時(shí)間分別如表1和表2所示。從下載到安裝一共需要44分鐘，影響用戶(hù)體驗(yàn)的升級(jí)時(shí)間主要是安裝過(guò)程，用戶(hù)需要等待升級(jí)完成的時(shí)間是28分鐘。如果所有控制器都采用串行的升級(jí)順序，安裝過(guò)程的時(shí)間是77分鐘。本方案用戶(hù)等待升級(jí)時(shí)間明顯縮短，相比串行升級(jí)時(shí)間降低63.6%，大幅提升了OTA的用戶(hù)體驗(yàn)滿(mǎn)意度。表1 下載部署過(guò)程的時(shí)間表2 安裝過(guò)程的時(shí)間如表2所示，安裝過(guò)程的耗時(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)等。

　　結(jié)論

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

　　編輯：黃飛