柳旭 周時(shí)瑩 范玲玲 李長(zhǎng)龍 周銳

【摘要】為提高現(xiàn)有遠(yuǎn)程升級(jí)系統(tǒng)的高并發(fā)連接能力、自動(dòng)化程度及下載升級(jí)效率，利用云端微服務(wù)化、基于整車基線的自動(dòng)升級(jí)路線策略、獨(dú)立下載通道、輕量化遠(yuǎn)程參數(shù)修改等技術(shù)對(duì)空中下載（OTA）系統(tǒng)方案進(jìn)行精益化設(shè)計(jì)，量產(chǎn)車型的實(shí)車功能及性能試驗(yàn)結(jié)果表明：該方案滿足百萬(wàn)輛級(jí)車輛的并發(fā)使用需求，升級(jí)穩(wěn)定性接近100%。

關(guān)鍵詞：空中下載 軟件基線 任務(wù)自動(dòng)化 獨(dú)立下載

中圖分類號(hào)：U461? ?文獻(xiàn)標(biāo)志碼：A? ?DOI： 10.20104/j.cnki.1674-6546.20220131

Lean Design of Intelligent Connected Vehicle OTA System

Liu Xu， Zhou Shiying， Fan Lingling， Li Changlong， Zhou Rui

（1. Global R&D Center， China FAW Corporation Limited， Changchun 130013; 2. National Key Laboratory of Advanced Vehicle Integration and Control， Changchun 130013）

【Abstract】In order to improve the high concurrency connectivity， degree of automation and efficiency of downloading upgrading， this article uses cloud-based microservice， automatic upgrade path strategy based on vehicle baseline， independent download channel and lightweight remote parameter correction to make lean design for Over-The-Air （OTA） system scheme. Function and performance test results of mass-produced vehicles show that this scheme satisfies the demand of concurrent use for vehicles with production capacity of one million unit， with upgrade stability nearly reaching 100%.

Key words： Over-The-Air （OTA）， Software baseline， Task automation， Independent download

【引用格式】柳旭， 周時(shí)瑩， 范玲玲， 等. 智能網(wǎng)聯(lián)車輛空中下載系統(tǒng)精益化設(shè)計(jì)[J]. 汽車工程師， 2024（6）： 1-7.

LIU X， ZHOU S Y， FAN L L， et al. Lean Design of Intelligent Connected Vehicle OTA System[J]. Automotive Engineer， 2024（6）： 1-7.

1 前言

以自動(dòng)駕駛為代表的車輛核心軟件功能愈發(fā)復(fù)雜，面對(duì)巨額的開發(fā)成本投入，軟件價(jià)值商業(yè)化勢(shì)在必行[1-2]。基于遠(yuǎn)程軟件升級(jí)、軟件個(gè)性化定制等需求的空中下載（Over-The-Air，OTA）技術(shù)應(yīng)運(yùn)而生。

國(guó)內(nèi)外車企針對(duì)企業(yè)級(jí)OTA系統(tǒng)、云端搭建、升級(jí)流程、信息安全、升級(jí)可靠性等方面已開展了大量的開發(fā)工作。文獻(xiàn)[3]對(duì)某公司初代OTA系統(tǒng)的架構(gòu)組成、升級(jí)策略、差分原理、實(shí)車測(cè)試用例及參數(shù)指標(biāo)進(jìn)行了闡述；文獻(xiàn)[4]介紹了信息安全原理及在OTA下載過(guò)程中的具體應(yīng)用流程；文獻(xiàn)[5]介紹了目前國(guó)內(nèi)外OTA相關(guān)法規(guī)制定情況及其具體要求。由此可見，汽車行業(yè)、企業(yè)及國(guó)家監(jiān)管部門均在快速開展OTA技術(shù)研發(fā)及規(guī)范工作。

本文針對(duì)目前主流的整車OTA技術(shù)提出一種精益化設(shè)計(jì)方案，主要進(jìn)行OTA平臺(tái)系統(tǒng)的高并發(fā)、自動(dòng)化任務(wù)發(fā)布、下載升級(jí)速率提升等方面研究，闡述OTA實(shí)際項(xiàng)目開發(fā)及使用過(guò)程中亟待解決的問(wèn)題，并給出合理的設(shè)計(jì)方法和解決方案，最后驗(yàn)證方案的可執(zhí)行性。

2 OTA架構(gòu)演進(jìn)

OTA技術(shù)是通過(guò)4G、5G、WIFI等網(wǎng)絡(luò)介質(zhì)從云端服務(wù)器下載車輛軟件更新包并在車端完成軟件替換更新的無(wú)線升級(jí)技術(shù)[6]，采用典型的客戶端/服務(wù)端（Client/Server）架構(gòu)，由車端、管端、云端3個(gè)部分組成。OTA云端系統(tǒng)及其外圍服務(wù)器集群為車輛提供全面的軟件升級(jí)服務(wù)，涵蓋車輛管理、軟件包管理、升級(jí)流程協(xié)調(diào)等。車云鏈路確保通信過(guò)程的安全性和可靠性，車輛作為服務(wù)請(qǐng)求的終端接入這一系統(tǒng)，可精準(zhǔn)地向特定的云端服務(wù)器發(fā)起升級(jí)服務(wù)的請(qǐng)求[7-8]。

2.1 OTA系統(tǒng)基本硬件組成

OTA系統(tǒng)的基本硬件組成如圖1所示。云端系統(tǒng)硬件主要包括OTA應(yīng)用服務(wù)器群、汽車遠(yuǎn)程服務(wù)提供商（Telematics Service Provider，TSP）車輛數(shù)據(jù)服務(wù)器、公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure，PKI）證書服務(wù)器、內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）第三方應(yīng)用服務(wù)器[9]。車端系統(tǒng)硬件主要包括網(wǎng)絡(luò)連接電子控制單元（Electronic Control Unit，ECU）、網(wǎng)關(guān)控制器、交互控制器等，各控制器之間通過(guò)車載總線，如以太網(wǎng)、CAN、CANFD等進(jìn)行數(shù)據(jù)及信號(hào)傳輸[10]。

2.2 OTA系統(tǒng)基本軟件組成

OTA云端系統(tǒng)按照云服務(wù)架構(gòu)可拆解成如圖2所示的模塊：基礎(chǔ)設(shè)施即服務(wù)（Infrastructure-as-a-Service，IaaS）平臺(tái)層提供基本的系統(tǒng)級(jí)資源，包括Kafka類調(diào)度中心、各類型數(shù)據(jù)庫(kù)、對(duì)象存儲(chǔ)（Object Storage Service，OSS）、數(shù)據(jù)緩存等；平臺(tái)即服務(wù)（Platform-as-a-Service，PaaS）層劃分為核心業(yè)務(wù)服務(wù)、通用服務(wù)、安全服務(wù)3個(gè)模塊，其中核心業(yè)務(wù)模塊為OTA的主邏輯，可按功能劃分為通信、下載、車輛管理、軟件管理、升級(jí)管理、統(tǒng)計(jì)等服務(wù)；軟件即服務(wù)（Software-as-a-Service，SaaS）應(yīng)用層為面向?qū)I(yè)人員的云端Web及向外可擴(kuò)展的信息接口[11]。

OTA車端按照模塊化設(shè)計(jì)，包含以下基本組件：下載管理器組件（DMclient），主要功能為下載、驗(yàn)簽、加密、安全認(rèn)證、版本管理、差分還原；升級(jí)代理（Update Agent，UA）組件，用于收集并保存車輛狀態(tài)信息，輔助OTA策略的實(shí)施[12]，該組件觸發(fā)刷寫腳本應(yīng)用程序接口（Application Programming Interface，API）完成ECU的刷寫腳本調(diào)用，獲取ECU的升級(jí)進(jìn)度和結(jié)果，同時(shí)收集整車各ECU的軟件版本；人機(jī)交互代理（Human Machine Interface Agent，HMI Agent）組件用于處理整個(gè)升級(jí)過(guò)程中所有OTA相關(guān)狀態(tài)的顯示及用戶操作信號(hào)的反饋；系統(tǒng)代理（System Agent）組件用于OTA升級(jí)過(guò)程中車輛電源控制、車輛狀態(tài)判斷、中央網(wǎng)關(guān)（Central Gateway，CGW）的睡眠接口調(diào)用以及車輛起動(dòng)狀態(tài)獲取[13]。

同時(shí)，OTA組件的正常運(yùn)行依賴于部署節(jié)點(diǎn)的底層能力，包括刷寫相關(guān)、條件相關(guān)、通用信息相關(guān)、交互相關(guān)的底層功能接口。車端軟件架構(gòu)如圖3所示。

3 OTA系統(tǒng)精益化設(shè)計(jì)

OTA精益化設(shè)計(jì)以現(xiàn)有硬件為基礎(chǔ)，優(yōu)化現(xiàn)有軟件架構(gòu)及功能邏輯，主要包括基于整車基線的自動(dòng)任務(wù)引擎、獨(dú)立下載技術(shù)和遠(yuǎn)程配置技術(shù)3個(gè)方面。

不同于基礎(chǔ)OTA邏輯的單ECU軟件版本管理的維度，車端整車軟件版本管理組件用于整車版本收集及整車基線判斷，云端軟件包管理以整車軟件為邏輯集合，利用獨(dú)立下載技術(shù)實(shí)現(xiàn)大數(shù)據(jù)量級(jí)ECU直接訪問(wèn)CDN的方法，縮減原有的車內(nèi)傳輸過(guò)程。同時(shí)，OTA云端下發(fā)的整車軟件包中攜帶ECU配置信息，可通過(guò)車端的配置模塊實(shí)現(xiàn)ECU功能的開啟和關(guān)閉。云端任務(wù)觸發(fā)引擎按照整車基線設(shè)置預(yù)定路線，單個(gè)車輛終端上報(bào)狀態(tài)后，自動(dòng)確定及下發(fā)任務(wù)。OTA精益化設(shè)計(jì)方案如圖4所示。

3.1 OTA云端微服務(wù)架構(gòu)

單體式架構(gòu)中多個(gè)服務(wù)通過(guò)共享同一數(shù)據(jù)庫(kù)，將應(yīng)用程序整合成一個(gè)單一的、不可分割的單元，因此所有的服務(wù)、組件和模塊都是緊密耦合的，這將導(dǎo)致車輛并發(fā)能力偏弱、云端Web管理界面卡滯、云端部署任務(wù)及軟件包上傳時(shí)間過(guò)長(zhǎng)等問(wèn)題。同時(shí)，由代碼依賴、數(shù)據(jù)共享等架構(gòu)特性帶來(lái)的強(qiáng)耦合性會(huì)導(dǎo)致系統(tǒng)功能變更困難。

微服務(wù)架構(gòu)將單一應(yīng)用程序劃分為微小的服務(wù)，各服務(wù)之間互相協(xié)調(diào)、配合，為用戶提供最終價(jià)值。各服務(wù)獨(dú)立運(yùn)行，并采用輕量級(jí)的通信機(jī)制互相協(xié)作，圍繞具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被單獨(dú)分配到生產(chǎn)環(huán)境中，同時(shí)，各微服務(wù)擁有獨(dú)立的數(shù)據(jù)庫(kù)[14]。微服務(wù)核心功能機(jī)制如圖5所示。

3.2 基線控制及云端任務(wù)路線

用戶較為關(guān)注汽車的整車級(jí)功能，但整車制造商（Original Equipment Manufacturer，OEM）更關(guān)注ECU的模塊化設(shè)計(jì)，其基線存在控制器版本不受控、新功能通知滯后、企業(yè)運(yùn)營(yíng)及宣傳通道受限等弊端。

3.2.1 整車版本定義

整車版本描述了整車ECU的軟件狀態(tài)，各ECU的軟件狀態(tài)通過(guò)軟件版本號(hào)進(jìn)行識(shí)別，將整車功能的不同狀態(tài)通過(guò)唯一的整車版本號(hào)進(jìn)行區(qū)分，如圖6所示。整車版本的格式設(shè)置為AA OS P S.X.Y<.Z><-T>，各字段定義如表1所示。

3.2.2 車端整車版本判斷模塊

ECU通過(guò)CAN報(bào)文按周期上報(bào)ECU硬件及軟件版本信息，軟件更新涉及軟件版本號(hào)的變化，刷寫流程執(zhí)行完成后重啟，新的軟件版本號(hào)在第一幀發(fā)出。

整車硬件及軟件判斷依據(jù)以xml文本格式記錄。針對(duì)不同的整車硬件版本，分別描述ECU標(biāo)識(shí)、名稱、版本號(hào)集合，基本結(jié)構(gòu)如圖7所示。整車硬件判斷依據(jù)通過(guò)下線設(shè)備灌裝入車內(nèi)，當(dāng)車輛存在硬件升級(jí)的場(chǎng)景時(shí)，售后部門重新灌裝。整車軟件判斷依據(jù)伴隨升級(jí)包一同下發(fā)到車輛。

整車軟件版本判斷模塊如圖8所示，其工作機(jī)制為：各ECU通過(guò)通信報(bào)文發(fā)出軟、硬件信息；車端版本管理組件收集該信息并存儲(chǔ)；整車軟件版本引擎按照設(shè)備樹軟件信息，判斷存儲(chǔ)的版本信息是否相同，若相同則完成整車版本匹配。匹配過(guò)程中，由于設(shè)備樹軟件信息較多，按照序號(hào)從大到小的順序依次判斷，匹配成功后則停止繼續(xù)比對(duì)。

3.2.3 基于整車版本的云端任務(wù)路線

不同于繁瑣的人工部署任務(wù)，基于整車版本的云端任務(wù)采用提前預(yù)設(shè)路線的方式，不同車輛識(shí)別碼（Vehicle Identification Number，VIN）的車輛上報(bào)整車版本后，自動(dòng)選擇后續(xù)節(jié)點(diǎn)生成恰當(dāng)?shù)娜蝿?wù)[15]。云端任務(wù)路線示例如圖9所示。

3.3 獨(dú)立下載

車內(nèi)車載遠(yuǎn)程通信終端（Telematics-BOX，T-BOX）、車載信息娛樂系統(tǒng)（In-Vehicle Infotainment，IVI）及高級(jí)駕駛輔助系統(tǒng)（Advanced Driving Assistance System，ADAS）等系統(tǒng)的升級(jí)包大小可達(dá)GB級(jí)，若OTA組件將升級(jí)包下載至主節(jié)點(diǎn)內(nèi)，升級(jí)包需要從網(wǎng)關(guān)傳輸?shù)侥繕?biāo)設(shè)備，傳輸過(guò)程耗時(shí)較長(zhǎng)。

獨(dú)立下載技術(shù)通過(guò)將下載信息經(jīng)由加密信道傳輸給目標(biāo)端，目標(biāo)端直接與云端通信的方式完成下載動(dòng)作[16]，相關(guān)流程如圖10所示。

Engine Service和Dwl Service Ext為主節(jié)點(diǎn)中OTA組件的2個(gè)服務(wù)模塊，分別負(fù)責(zé)任務(wù)管理和下載管理。獨(dú)立下載方案中，Engine Service負(fù)責(zé)同步各軟件包的下載相關(guān)信息，當(dāng)判斷升級(jí)包所屬為獨(dú)立下載ECU后，將下載信息同步給對(duì)應(yīng)ECU。

IVI/T-BOX/ADAS收到下載信息后，直接通過(guò)下載通路連接對(duì)應(yīng)服務(wù)器，完成數(shù)據(jù)下載，支持?jǐn)帱c(diǎn)續(xù)傳。在獨(dú)立下載過(guò)程中，同時(shí)響應(yīng)OTA主節(jié)點(diǎn)取消下載、獲取下載狀態(tài)和獲取刷寫腳本的控制指令。

獨(dú)立下載和正常下載全部完成后進(jìn)入安裝階段，仍然由Engine Service統(tǒng)一調(diào)用UAt模塊完成升級(jí)刷寫的控制。至此，OTA任務(wù)的流程全部完成。

3.4 遠(yuǎn)程配置

遠(yuǎn)程配置即通過(guò)遠(yuǎn)程通信的方式對(duì)整車的軟件功能進(jìn)行配置，通常是啟動(dòng)和關(guān)閉整車的某一功能，可用于開啟與關(guān)閉整車的基礎(chǔ)功能和可銷售的軟件功能?；A(chǔ)功能通?？擅赓M(fèi)獲取，通過(guò)OTA的方式升級(jí)軟件后，通過(guò)遠(yuǎn)程配置啟動(dòng)與關(guān)閉?？射N售軟件功能在用戶購(gòu)買后可進(jìn)行單獨(dú)配置，或者需要先通過(guò)OTA平臺(tái)將軟件升級(jí)至指定版本再進(jìn)行配置。

不同的整車硬件版本配置軟件的方式不同，主要分為廣播配置與診斷配置，物理層支持通過(guò)CAN網(wǎng)絡(luò)和車載以太網(wǎng)進(jìn)行配置。廣播配置的優(yōu)勢(shì)在于一次廣播播報(bào)可配置多個(gè)相關(guān)ECU報(bào)文，診斷配置則需要對(duì)各ECU進(jìn)行單獨(dú)尋址，逐步完成功能的配置[17]。

3.5 OTA安全設(shè)計(jì)

OTA安全設(shè)計(jì)主要包括服務(wù)器端、管端及車端3個(gè)部分。服務(wù)器端安全設(shè)計(jì)如圖11所示。

OTA服務(wù)器與車端采用超文本傳輸協(xié)議（Hyper Text Transfer Protocol，HTTP），基于私有PKI體系實(shí)現(xiàn)雙向身份認(rèn)證，保證通信信道的加密傳輸。

車端安全設(shè)計(jì)主要包括升級(jí)前置條件控制和升級(jí)異常處理。升級(jí)前置條件設(shè)計(jì)內(nèi)容包括車速、擋位、蓄電池電量、網(wǎng)絡(luò)通信等，此外，本文特別設(shè)計(jì)了OTA模式。OTA模式是指OTA升級(jí)過(guò)程中，各控制器為適應(yīng)OTA刷寫需求進(jìn)入的特殊狀態(tài)。OTA任務(wù)下載完成開始安裝后，主節(jié)點(diǎn)會(huì)播報(bào)“OTA模式”信號(hào)，模式信號(hào)為狀態(tài)值，各控制器監(jiān)測(cè)到信號(hào)后，進(jìn)入OTA模式，在該模式下，各控制器執(zhí)行不同動(dòng)作，如車身控制器維持電池鎖定狀態(tài)、娛樂主機(jī)降低亮度等。

升級(jí)異常策略分為重刷和回滾2種處理機(jī)制。依賴于可重復(fù)刷寫的引導(dǎo)加載程序（Bootloader）功能設(shè)計(jì)，ECU至少需要實(shí)現(xiàn)升級(jí)異常后可重復(fù)刷寫；回滾機(jī)制包含云端、車內(nèi)、ECU內(nèi)回滾等方式，其中ECU內(nèi)回滾即ECU的a、b面升級(jí)，能夠徹底解決刷寫失敗異常的問(wèn)題，但對(duì)于ECU芯片性能、存儲(chǔ)空間的高要求，會(huì)使硬件成本增加20%～30%，因此需要根據(jù)ECU的功能安全等級(jí)分級(jí)設(shè)計(jì)。

4 試驗(yàn)驗(yàn)證

4.1 試驗(yàn)環(huán)境

針對(duì)上述精益化設(shè)計(jì)內(nèi)容，進(jìn)行OTA功能及系統(tǒng)性能的試驗(yàn)驗(yàn)證，以實(shí)物臺(tái)架試驗(yàn)為主，系統(tǒng)仿真為輔。功能測(cè)試包括任務(wù)自動(dòng)化、斷點(diǎn)續(xù)傳、獨(dú)立下載流程、遠(yuǎn)程配置流程、整車版本判斷、軟件包篡改、升級(jí)前置條件等；性能測(cè)試包括云端服務(wù)器每秒查詢率（Queries Per Second，QPS）、獨(dú)立下載速度、CAN刷寫速度、軟件升級(jí)成功率、功能配置成功率等。云端測(cè)試系統(tǒng)及實(shí)物臺(tái)架如圖12、圖13所示。

4.2 功能測(cè)試

功能測(cè)試基本采用云端任務(wù)部署、車端任務(wù)執(zhí)行的方式，測(cè)試目的及方法如表2所示。以自動(dòng)化的任務(wù)下發(fā)為例，測(cè)試大致步驟為：設(shè)置一條三節(jié)點(diǎn)的升級(jí)路線進(jìn)行全網(wǎng)發(fā)布；使用實(shí)車1進(jìn)行車云通信；使用實(shí)車2首次接入OTA系統(tǒng)進(jìn)行車云通信（模擬車輛剛下線）。測(cè)試發(fā)現(xiàn)實(shí)車1和實(shí)車2皆能完成2次任務(wù)串行下發(fā)，任務(wù)升級(jí)成功，整車軟件版本判斷正確。通過(guò)本次測(cè)試，驗(yàn)證了云端升級(jí)任務(wù)自動(dòng)化下發(fā)以及車輛連續(xù)升級(jí)功能的實(shí)效性。

4.3 性能測(cè)試

4.3.1 云端并發(fā)能力測(cè)試

通過(guò)高性能服務(wù)器模擬多車連接請(qǐng)求，驗(yàn)證服務(wù)器的處理能力及錯(cuò)誤率等關(guān)鍵指標(biāo)。壓力機(jī)硬件性能指標(biāo)如表3所示。

使用Locust負(fù)載測(cè)試工具，設(shè)定HTTP請(qǐng)求超時(shí)時(shí)間為10 s，測(cè)試樣本為10萬(wàn)輛汽車，包括3萬(wàn)輛有任務(wù)車輛和7萬(wàn)輛無(wú)任務(wù)車輛。并發(fā)時(shí)根據(jù)有任務(wù)和無(wú)任務(wù)情況循環(huán)測(cè)試所有車輛，并發(fā)送對(duì)應(yīng)請(qǐng)求。

測(cè)試結(jié)果為：在5 h內(nèi)共請(qǐng)求1 399萬(wàn)次，其中失敗266萬(wàn)次，在服務(wù)端磁盤飽和前，請(qǐng)求次數(shù)為960 次/s，錯(cuò)誤率小于0.02%；磁盤飽和后，請(qǐng)求次數(shù)下降為500 次/s左右，錯(cuò)誤率迅速增大。

4.3.2 CAN刷寫速度測(cè)試

基于CANoe工具的通信訪問(wèn)編程語(yǔ)言（Communication Access Programming Language，CAPL）腳本實(shí)現(xiàn)自動(dòng)化重復(fù)測(cè)試上位機(jī)，針對(duì)車門控制器進(jìn)行重復(fù)刷寫計(jì)時(shí)。上位機(jī)設(shè)置刷寫連續(xù)幀間隔（STmin）為0，hex文件為200 KB，分別針對(duì)總線非刷寫報(bào)文無(wú)負(fù)載、5%負(fù)載、10%負(fù)載情況進(jìn)行驗(yàn)證，測(cè)試數(shù)據(jù)如表4所示。測(cè)試結(jié)果表明，隨著總線負(fù)載的增加，控制器的刷寫時(shí)間也逐步增加。

4.3.3 刷寫成功率測(cè)試

刷寫成功率驗(yàn)證分為單件多次重復(fù)刷寫驗(yàn)證和多件單次刷寫驗(yàn)證，刷寫成功率測(cè)試方法與刷寫速度測(cè)試一致。刷寫成功需具備2個(gè)充分條件：對(duì)Flash擦除指令，車門控制器給出積極響應(yīng)；刷寫完成后，通過(guò)版本號(hào)讀取服務(wù)和通信報(bào)文均能夠收到目標(biāo)版本號(hào)。單件多次重復(fù)刷寫驗(yàn)證對(duì)控制器進(jìn)行百次級(jí)的壓力測(cè)試，成功率為100%；多件單次刷寫驗(yàn)證使用10個(gè)相同版本的車門控制器進(jìn)行，成功率為100%。

5 結(jié)束語(yǔ)

本文針對(duì)進(jìn)行了方案設(shè)計(jì)，并通過(guò)實(shí)車臺(tái)架驗(yàn)證了其可行性，得到以下主要結(jié)論：

a. OTA云端采用微服務(wù)架構(gòu)設(shè)計(jì)，可支撐百萬(wàn)級(jí)車輛的業(yè)務(wù)請(qǐng)求，同時(shí)便于后續(xù)業(yè)務(wù)升級(jí)；

b.整車基線控制在管理層面可以有效保證車輛的初始狀態(tài)，在技術(shù)層面更加便于任務(wù)自動(dòng)化的實(shí)現(xiàn)；

c.獨(dú)立下載能夠有效縮減大數(shù)據(jù)量軟件包在車內(nèi)網(wǎng)絡(luò)的傳輸時(shí)間，減少ECU安裝過(guò)程的等待時(shí)間；

d.不同于大數(shù)據(jù)量的軟件更新，遠(yuǎn)程配置更適用于獨(dú)立實(shí)現(xiàn)輕量級(jí)的參數(shù)變動(dòng)。

參考文獻(xiàn)

[1]? ?陳虹， 郭露露， 邊寧. 對(duì)汽車智能化進(jìn)程及其關(guān)鍵技術(shù)的思考[J]. 科技導(dǎo)報(bào)， 2017， 35（11）： 52-59.

CHEN H， GUO L L， BIAN N. Reflections on the Process of Automotive Intelligence and its Key Technologies[J]. Science and Technology Herald， 2017， 35（11）： 52-59.

[2]? ?PHUNG P H， NILSSON D K. A Model for Safe and Secure Execution of Downloaded Vehicle Applications[C]// IET Road Transport Information and Control Conference and the ITS United Kingdom Members Conference （RTIC 2010）-Better Transport Through Technology. London： IEEE， 2010.

[3]? ?王棟梁， 湯利順， 陳博， 等. 智能網(wǎng)聯(lián)汽車整車OTA功能設(shè)計(jì)研究[J]. 汽車技術(shù)， 2018（10）： 29-33.

WANG D L， TANG L S， CHEN B， et al. Research on the Design of OTA Function for the Whole Vehicle of Smart Networked Vehicles[J]. Automotive Technology， 2018（10）： 29-33.

[4]? ?周奇才， 王奕童， 趙炯， 等. 基于互聯(lián)網(wǎng)設(shè)備的車輛安全空中下載通信協(xié)議方案[J]. 汽車技術(shù)， 2020（1）： 6-11.

ZHOU Q C， WANG Y T， ZHAO J， et al. A Communication Protocol Scheme for Safe Over-the-Air Download of Vehicles Based on Internet Devices[J]. Automotive Technology， 2020（1）： 6-11.

[5]? ?朱云堯， 吳勝男. 國(guó)內(nèi)外智能網(wǎng)聯(lián)汽車軟件在線升級(jí)法規(guī)分析[J]. 汽車文摘， 2022（10）： 6-10.

ZHU Y Y， WU S N. Analysis of Online Software Upgrade Regulations for Domestic and Foreign Intelligent Networked Vehicles[J]. Automotive Digest， 2022（10）： 6-10.

[6]? ?萬(wàn)開明， 洪雷. 車載OTA技術(shù)研究[J]. 時(shí)代汽車， 2020（11）： 10-11.

WAN K M， HONG L. Research on In-Vehicle OTA Technology[J]. Times Automotive， 2020（11）： 10-11.

[7]? ?MANSOR H， MARKANTONAKIS K， AKRAM R N， et al. Lets Get Mobile： Secure FOTA for Automotive System[C]// International Conference on Network and System Security. New York： Springer， Cham， 2015.

[8]? ?IDREES M S， SCHWEPPE H， ROUDIER Y， et al. Secure Automotive Onboard Protocols： A Case of Over-the-Air Firmware Updates[C]// International Workshop on Communication Technologies for Vehicles. Heidelberg， Berlin： Springer， 2011.

[9]? ?程達(dá)， 姬東耀. OTA業(yè)務(wù)的高速下載[J]. 計(jì)算機(jī)工程與應(yīng)用， 2005（33）： 147-148+204.

CHENG D， JI D Y. High-Speed Download for OTA Services[J]. Computer Engineering and Applications， 2005（33）： 147-148+204.

[10] NILSSON D K， SUN L， NAKAJIMA T. A Framework for Self-Verification of Firmware Updates over the Air in Vehicle ECUs[C]// 2008 IEEE Globecom Workshops. New Orleans： IEEE， 2008.

[11] NILSSON D K， LARSON U E. Secure Firmware Updates Over the Air in Intelligent Vehicles[C]// ICC Workshops-2008 IEEE International Conference on Communications Workshops. New Orleans： IEEE， 2008.

[12] 武智， 劉天宇， 賈先鋒. 智能網(wǎng)聯(lián)汽車OTA升級(jí)安全設(shè)計(jì)[J]. 汽車實(shí)用技術(shù)， 2022， 47（3）： 38-40.

WU Z， LIU T Y， JIA X F. OTA Upgrade Safety Design for Smart Networked Vehicles[J]. Automotive Practical Technology， 2022， 47（3）： 38-40.

[13] 嚴(yán)娟， 張玉川， 楊鵬翔， 等. 基于以太網(wǎng)OTA遠(yuǎn)程升級(jí)的研究[J]. 上海汽車， 2020（3）： 15-18+27.

YAN J， ZHANG Y C， YANG P X， et al. The Study on OTA Remote Updating of Ethernet[J]. Shanghai Automotive， 2020（3）： 15-18+27.

[14] VILLAMIZAR M， GARC?S O， CASTRO H， et al. Evaluating the Monolithic and the Microservice Architecture Pattern Todeploy Web Applications in the Cloud[C]// 2015 10th Computing Colombian Conference（10CCC）. Bogota， Colombia： IEEE， 2015.

[15] ZHANG J， LIAO Z， ZHU L. Research on Design and Implementation of Automotive ECUs Software Remote Update[J]. Applied Mechanics and Materials， 2015， 740： 847-851.

[16] MU C Y， SUN L N， DU Z J， et al. Research and Development of Device for Downloading and Updating Software of Product ECU Based on Extended CCP[C]// 2007 2nd IEEE Conference on Industrial Electronics and Applications. Harbin， China： IEEE， 2007： 2865-2869.

[17] SHI G Y， KE Z W， YAN F W， et al. A Vehicle Electric Control Unit Over-the-Air Reprogramming System[C]// 2015 International Conference on Connected Vehicles and Expo （ICCVE）. New York： IEEE， 2015.

（責(zé)任編輯 王 一）

修改稿收到日期為2024年5月15日。