前 言

汽車(chē)OTA功能已經(jīng)成為時(shí)下熱門(mén)話(huà)題，以Tesla為代表的造車(chē)新勢(shì)力突破創(chuàng)新將消費(fèi)電子領(lǐng)域“空中下載技術(shù)”成功引入到了汽車(chē)領(lǐng)域，掀起了全球眾多OEM的追隨，同時(shí)也顛覆了人們對(duì)車(chē)輛的傳統(tǒng)認(rèn)知。 OTA升級(jí)為OEM提供了比傳統(tǒng)診斷儀更快捷、低成本的更新方式，提升用戶(hù)體驗(yàn)及對(duì)品牌的忠誠(chéng)度，而這些收益的背后自然是少不了主機(jī)廠(chǎng)遠(yuǎn)程診斷技術(shù)的支撐。 本文將介紹一種汽車(chē)OTA刷新中遠(yuǎn)程診斷設(shè)計(jì)方案，主要包含OTA云端整體架構(gòu)及診斷要求、車(chē)載終端網(wǎng)絡(luò)診斷架構(gòu)設(shè)計(jì)、軟件存儲(chǔ)及刷新策略、遠(yuǎn)程故障診斷等內(nèi)容。

01 汽車(chē)OTA簡(jiǎn)介

OTA（Over-the-Air Technology）為“空中下載技術(shù)”，與我們常見(jiàn)的手機(jī)更新系統(tǒng)固件（軟件）的情況類(lèi)似，汽車(chē)也可以同樣通過(guò)無(wú)線(xiàn)網(wǎng)絡(luò)實(shí)現(xiàn)遠(yuǎn)程更新車(chē)內(nèi)的各控制器內(nèi)部固件（FOTA）及軟件數(shù)據(jù)（SOTA），這就是所謂的汽車(chē)OTA技術(shù)。

主機(jī)廠(chǎng)積極構(gòu)建的汽車(chē)OTA升級(jí)體系，到底能帶來(lái)什么好處呢？

OTA可以快速升級(jí)修復(fù)軟件代碼缺陷。 隨著市場(chǎng)車(chē)輛功能配置的快速迭代，主機(jī)廠(chǎng)整車(chē)開(kāi)發(fā)周期被迫縮短，由于軟件漏洞造成的汽車(chē)召回風(fēng)險(xiǎn)持續(xù)攀升，目前高端汽車(chē)的整車(chē)代碼量已經(jīng)突破1億行，即使按照能力成熟度集成模型的5級(jí)最高軟件標(biāo)準(zhǔn)開(kāi)發(fā)，仍有0.32%的代碼缺陷率，使用OTA升級(jí)可減少主機(jī)廠(chǎng)50%的汽車(chē)返修成本。

OTA給主機(jī)廠(chǎng)帶來(lái)新的“營(yíng)銷(xiāo)模式”。 “軟件定義”汽車(chē)（SDV）概念的出現(xiàn)，給傳統(tǒng)的汽車(chē)售賣(mài)硬件的方式帶來(lái)的巨大的變革，已經(jīng)賣(mài)出去的車(chē)輛還可以軟件付費(fèi)方式開(kāi)通一些“升級(jí)包”，如Tesla的完全自動(dòng)駕駛（FSD）升級(jí)包。 統(tǒng)計(jì)數(shù)據(jù)顯示，預(yù)計(jì)未來(lái)五年軟件定制市場(chǎng)的年均復(fù)合增長(zhǎng)率約為30%，2023年全球汽車(chē)軟件定制市場(chǎng)規(guī)模有望達(dá)到275.42億元，因此主機(jī)廠(chǎng)可OTA升級(jí)的軟件潛力及效益可觀(guān)。 如圖1所示：

圖1 全球汽車(chē)軟件定制市場(chǎng)規(guī)模及增速

主機(jī)廠(chǎng)通過(guò)OTA方式，可改善車(chē)輛的動(dòng)力、剎車(chē)、續(xù)航、人機(jī)交互系統(tǒng)以及智能輔助駕駛系統(tǒng)的更優(yōu)體驗(yàn)。 使車(chē)輛的整體性能及功能變得更優(yōu)異，增加了車(chē)主的新鮮感，也增加了車(chē)主對(duì)車(chē)輛的品牌忠誠(chéng)度。 汽車(chē)OTA帶來(lái)眾多好處的同時(shí)也對(duì)主機(jī)廠(chǎng)提出了新的挑戰(zhàn)，無(wú)論是OTA云端架構(gòu)設(shè)計(jì)、信息安全、后臺(tái)軟件版本管控等，還是車(chē)輛終端的車(chē)載網(wǎng)絡(luò)診斷架構(gòu)設(shè)計(jì)、遠(yuǎn)程故障診斷、OTA刷新流程、ECU軟件刷新策略等方面，都需要OEM全面考慮和充分測(cè)試驗(yàn)證，避免OTA推送后車(chē)輛出現(xiàn)“癱趴”現(xiàn)象，導(dǎo)致車(chē)主適得其反的體驗(yàn)。

02 汽車(chē)遠(yuǎn)程診斷

汽車(chē)遠(yuǎn)程診斷是指在車(chē)輛不需要開(kāi)回4S店的情況下，依靠車(chē)輛具備的移動(dòng)通訊能力（WIFI/4G/5G）完成主機(jī)廠(chǎng)后臺(tái)（或手機(jī)端APP）對(duì)車(chē)輛進(jìn)行遠(yuǎn)程控制及診斷操作的一種診斷技術(shù)。 遠(yuǎn)程O(píng)TA刷新就屬于遠(yuǎn)程診斷應(yīng)用的一種場(chǎng)景。 此外，遠(yuǎn)程診斷技術(shù)通過(guò)與物聯(lián)網(wǎng)、大數(shù)據(jù)、云計(jì)算等前沿技術(shù)融合后，還可為主機(jī)廠(chǎng)在研發(fā)試驗(yàn)、產(chǎn)線(xiàn)電檢、售后診斷等領(lǐng)域提供重要支撐。

首先，遠(yuǎn)程診斷可以在線(xiàn)采集數(shù)據(jù)，降低開(kāi)發(fā)周期及成本。 研發(fā)階段車(chē)輛需要進(jìn)行大量道路試驗(yàn)、耐久試驗(yàn)，而試驗(yàn)車(chē)配備的數(shù)據(jù)采集設(shè)備有限，通過(guò)遠(yuǎn)程診斷，試驗(yàn)過(guò)程中出現(xiàn)的車(chē)輛故障現(xiàn)象可以及時(shí)反饋給研發(fā)人員分析和仿真，快速協(xié)助解決故障問(wèn)題。 其次，遠(yuǎn)程診斷可以在產(chǎn)線(xiàn)電檢跨工位實(shí)現(xiàn)初始化及功能檢測(cè)、產(chǎn)線(xiàn)OTA刷新，實(shí)現(xiàn)汽車(chē)軟件定制化生產(chǎn)，滿(mǎn)足車(chē)主定制化需求。 最后，遠(yuǎn)程診斷可以周期性監(jiān)控車(chē)輛狀態(tài)，實(shí)時(shí)診斷車(chē)輛健康，結(jié)合大數(shù)據(jù)統(tǒng)計(jì)分析進(jìn)行車(chē)輛故障預(yù)警，通過(guò)后臺(tái)推送給廠(chǎng)家售后4S店進(jìn)行車(chē)輛保養(yǎng)及維修指導(dǎo)建議。

03 OTA刷新遠(yuǎn)程診斷設(shè)計(jì)

OTA刷新系統(tǒng)架構(gòu)主要由服務(wù)器（云平臺(tái)）、傳輸媒介（3G/4G/WIFI/5G）和車(chē)載終端（ECU）三部分構(gòu)成。 本文基于如圖2所示的OTA刷新系統(tǒng)架構(gòu)設(shè)計(jì)，重點(diǎn)針對(duì)服務(wù)器（云平臺(tái)）和車(chē)載終端（ECU）進(jìn)行遠(yuǎn)程診斷詳細(xì)方案介紹。

3.1 OTA服務(wù)器

圖2 OTA刷新系統(tǒng)架構(gòu)

OTA服務(wù)器又稱(chēng)為OTA云平臺(tái)，在軟件刷新過(guò)程中起連接用戶(hù)（車(chē)廠(chǎng)、車(chē)主）與車(chē)輛的作用，為實(shí)現(xiàn)車(chē)輛遠(yuǎn)程智能診斷及故障預(yù)測(cè)分析，OTA云平臺(tái)設(shè)計(jì)一般要求都部署在車(chē)廠(chǎng)的私有服務(wù)器上，能夠支持多種車(chē)型OTA升級(jí)。

3.1.1 OTA云平臺(tái)整體架構(gòu)

OTA云平臺(tái)主要包含用戶(hù)管理、固件管理、車(chē)輛管理、升級(jí)任務(wù)管理、統(tǒng)計(jì)分析管理、用戶(hù)操作日志管理模塊，如圖3所示。

圖3 OTA云平臺(tái)整體架構(gòu)

用戶(hù)管理模塊：OTA云平臺(tái)為車(chē)廠(chǎng)提供的是一套軟件系統(tǒng)，因此需要有用戶(hù)管理模塊來(lái)實(shí)現(xiàn)用戶(hù)權(quán)限分配及管理工作。 系統(tǒng)搭建環(huán)境默認(rèn)創(chuàng)建超級(jí)管理員用戶(hù)，由超級(jí)管理員用戶(hù)登錄后在用戶(hù)管理模塊實(shí)現(xiàn)用戶(hù)新增，用戶(hù)查看，用戶(hù)信息修改等功能操作。

固件管理模塊：主要為用戶(hù)提供固件上傳，固件查詢(xún)及編輯（版本管理）功能。 用戶(hù)將車(chē)廠(chǎng)測(cè)試通過(guò)的固件上傳到OTA云平臺(tái)，用以升級(jí)任務(wù)創(chuàng)建。

車(chē)輛管理模塊：主要包含車(chē)輛ECU信息同步、車(chē)輛ECU信息獲取及車(chē)輛信息查看功能。 車(chē)輛ECU信息同步子模塊對(duì)接主機(jī)廠(chǎng)MES（生產(chǎn)制造）系統(tǒng)，可導(dǎo)入不同車(chē)型配置信息用以O(shè)TA升級(jí)時(shí)對(duì)目標(biāo)車(chē)輛篩選及升級(jí)策略配置。

升級(jí)任務(wù)管理模塊：主要負(fù)責(zé)為用戶(hù)提供升級(jí)任務(wù)創(chuàng)建、升級(jí)任務(wù)審批、升級(jí)任務(wù)查詢(xún)、升級(jí)進(jìn)度查詢(xún)功能。

統(tǒng)計(jì)分析管理模塊：主要負(fù)責(zé)統(tǒng)計(jì)分析已發(fā)布的升級(jí)任務(wù)執(zhí)行結(jié)果情況。 用戶(hù)可以查看每個(gè)升級(jí)任務(wù)對(duì)應(yīng)的升級(jí)車(chē)輛的成功率、失敗原因統(tǒng)計(jì)及未執(zhí)行升級(jí)原因統(tǒng)計(jì)分析。

用戶(hù)操作日志管理模塊：主要負(fù)責(zé)為超級(jí)管理員用戶(hù)提供所有登錄OTA云平臺(tái)的用戶(hù)的所有功能操作記錄。

3.1.2 OTA云平臺(tái)診斷要求

OTA云平臺(tái)必須符合高可用、高性能、可擴(kuò)展、可監(jiān)控的診斷要求。 具體表現(xiàn)為以下幾個(gè)方面：

采用微服務(wù)的Browser/Server（瀏覽器/服務(wù)器）的服務(wù)框架，能夠支持多種負(fù)載均衡模式（服務(wù)消費(fèi)者從提供者列表中，基于軟負(fù)載均衡算法（隨機(jī)、權(quán)重、輪詢(xún)、最少并發(fā)優(yōu)先等）選一臺(tái)服務(wù)提供者進(jìn)行遠(yuǎn)程調(diào)用，如果調(diào)用失敗，需自動(dòng)診斷并切換另一臺(tái)服務(wù)提供者）；

立體化監(jiān)控，能夠?qū)ο到y(tǒng)資源（CPU、負(fù)載、內(nèi)存、網(wǎng)絡(luò)和磁盤(pán)等）基礎(chǔ)指標(biāo)進(jìn)行詳細(xì)的監(jiān)控，對(duì)于系統(tǒng)的每一次服務(wù)調(diào)用響應(yīng)時(shí)間和出錯(cuò)率進(jìn)行故障診斷和預(yù)警；

系統(tǒng)具備高可靠和高性能，確保整個(gè)系統(tǒng)上運(yùn)行的業(yè)務(wù)體系能夠?yàn)榭蛻?hù)系統(tǒng)提供99.9%可用性的高效優(yōu)質(zhì)服務(wù)；

采用服務(wù)集群的管理技術(shù)，利用多個(gè)計(jì)算機(jī)并行計(jì)算從而獲得高性能和冗余備份，即便單機(jī)故障時(shí)整個(gè)系統(tǒng)仍能正常工作；

系統(tǒng)具備故障隔離機(jī)制，在應(yīng)用軟件系統(tǒng)發(fā)生故障時(shí)，通過(guò)故障隔離可將故障危害限制在最小范圍內(nèi)，提高系統(tǒng)對(duì)外服務(wù)的整體能力。

3.2 OTA車(chē)載終端

OTA車(chē)載終端作為OTA升級(jí)的執(zhí)行方，以O(shè)TA推送方式為例，用戶(hù)可感知體驗(yàn)的部分較多，車(chē)載終端的設(shè)計(jì)重點(diǎn)需考慮人機(jī)交互、網(wǎng)絡(luò)診斷架構(gòu)設(shè)計(jì)、ECU刷新時(shí)長(zhǎng)、軟件存儲(chǔ)及刷新策略、遠(yuǎn)程故障診斷機(jī)制。車(chē)載終端網(wǎng)絡(luò)框架如圖4所示，OTA主控節(jié)點(diǎn)由TBOX和中央網(wǎng)關(guān)（GW）負(fù)責(zé)，升級(jí)界面由車(chē)機(jī)負(fù)責(zé)，被刷新的ECU要求支持車(chē)載以太網(wǎng)（DoIP）或CAN總線(xiàn)（DoCAN）通訊協(xié)議，若ECU升級(jí)包較大（如上百兆）需要支持?jǐn)?shù)據(jù)差分算法。

圖4 OTA車(chē)載終端框架

3.2.1 OTA人機(jī)交互設(shè)計(jì)

OTA升級(jí)時(shí)除了云平臺(tái)推送升級(jí)任務(wù)到車(chē)主APP提醒外，還需車(chē)端（車(chē)機(jī)或中控）配合開(kāi)發(fā)顯示一些升級(jí)界面（如升級(jí)進(jìn)度、升級(jí)條件提醒等），用于提醒車(chē)主車(chē)輛設(shè)防及離車(chē)等配合操作。

3.2.2 網(wǎng)絡(luò)診斷架構(gòu)設(shè)計(jì)

目前車(chē)載網(wǎng)絡(luò)主干網(wǎng)仍以成熟的CAN總線(xiàn)通訊為主，但對(duì)于軟件包較大的ECU由于刷新時(shí)長(zhǎng)等因素，使用了車(chē)載以太網(wǎng)技術(shù)來(lái)突破CAN總線(xiàn)的帶寬限制，如圖10所示。

主要架構(gòu)包含OTA主控節(jié)點(diǎn)（TBOX和GW）和被刷新ECU。TBOX主要負(fù)責(zé)對(duì)外與云平臺(tái)的連接通道安全可靠，其內(nèi)部集成了PKI認(rèn)證及身份鑒權(quán)等安全模塊；GW主要負(fù)責(zé)對(duì)內(nèi)部網(wǎng)絡(luò)的連接通道及集成診斷刷新機(jī)功能。刷新ECU根據(jù)軟件包大小及理論刷新時(shí)長(zhǎng)（如不超過(guò)20分鐘），在CAN總線(xiàn)拓?fù)浼軜?gòu)上增加了以太網(wǎng)接口設(shè)計(jì)，使用DoIP協(xié)議進(jìn)行ECU診斷刷新。

圖5 網(wǎng)絡(luò)診斷架構(gòu)圖

3.2.3 ECU軟件存儲(chǔ)及刷新策略

OTA刷新前ECU軟件升級(jí)包由云平臺(tái)下發(fā)到車(chē)端OTA主控節(jié)點(diǎn)內(nèi)存儲(chǔ)，由文件存儲(chǔ)模塊來(lái)負(fù)責(zé)整車(chē)軟件升級(jí)包的存儲(chǔ)及備份包的管控。

升級(jí)管理模塊主要負(fù)責(zé)刷新機(jī)刷新策略控制，OTA刷新需要設(shè)計(jì)多次冗余刷新策略，即OTA后臺(tái)發(fā)起一次升級(jí)任務(wù)后，同一輛車(chē)內(nèi)OTA主控節(jié)點(diǎn)刷新機(jī)通常會(huì)對(duì)同一個(gè)ECU執(zhí)行多次刷新嘗試請(qǐng)求，減少偶發(fā)失敗因素，提高OTA刷新成功率。被刷新ECU主要分為傳統(tǒng)嵌入式芯片ECU和復(fù)雜帶操作系統(tǒng)（如Linux、Android、AutoSAR）的ECU。

根據(jù)ECU的硬件資源情況，我們又設(shè)計(jì)了如下ECU內(nèi)部存儲(chǔ)及刷新策略：如圖11所示的帶操作系統(tǒng)ECU，硬件存儲(chǔ)資源豐富，控制器內(nèi)分配了兩個(gè)不同啟動(dòng)區(qū)分，具體刷新過(guò)程如下：

默認(rèn)出廠(chǎng)狀態(tài)啟動(dòng)分區(qū)1激活，運(yùn)行V1.0版本程序，啟動(dòng)分區(qū)2內(nèi)無(wú)備份程序；

當(dāng)OTA發(fā)起第一次V1.1版本刷新請(qǐng)求時(shí)，刷新數(shù)據(jù)會(huì)存儲(chǔ)在備份分區(qū)（分區(qū)2），刷新成功后激活啟動(dòng)分區(qū)2，并交換備份分區(qū)（分區(qū)1），下次上電后程序由啟動(dòng)分區(qū)2啟動(dòng)并正常工作；

當(dāng)OTA發(fā)起第二次V1.2版本刷新請(qǐng)求時(shí)，刷新數(shù)據(jù)會(huì)被存儲(chǔ)在備份分區(qū)1，刷新成功后激活啟動(dòng)分區(qū)1并交換備份分區(qū)（分區(qū)2），下次上電后程序由啟動(dòng)分區(qū)1啟動(dòng)并正常工作；

當(dāng)OTA發(fā)起第三次V1.3版本刷新請(qǐng)求時(shí)，刷新數(shù)據(jù)會(huì)存儲(chǔ)在備份分區(qū)（分區(qū)2），刷新成功后激活啟動(dòng)分區(qū)2，并交換備份分區(qū)（分區(qū)1），下次上電后程序由啟動(dòng)分區(qū)2啟動(dòng)并正常工作。如此循環(huán)交換分區(qū)刷新，即便遇到刷新失敗當(dāng)前啟動(dòng)分區(qū)無(wú)法正常啟動(dòng)時(shí)，ECU也還可以通過(guò)自回滾從備份分區(qū)啟動(dòng)，確保系統(tǒng)工作正常。

圖6 帶操作系統(tǒng)的ECU軟件存儲(chǔ)及刷新策略圖

對(duì)于傳統(tǒng)嵌入式ECU，通常采用BOOT+APP的軟件架構(gòu)，如圖12所示。功能越復(fù)雜的ECU，其選擇的主控芯片APP容量越大，為了實(shí)現(xiàn)ECU內(nèi)部軟件自回滾功能，需要將APP空間劃分一部分用于軟件備份存儲(chǔ)（如APP2）。當(dāng)ECU被刷新時(shí)，由BOOT代碼負(fù)責(zé)提供升級(jí)流程引導(dǎo)，將升級(jí)包存儲(chǔ)到APP區(qū)域（一般為程序啟動(dòng)入口地址空間）。由于嵌入式芯片ECU程序啟動(dòng)入口通常只有一個(gè)，因此，當(dāng)刷新失?。ˋPP激活不了）時(shí)，由BOOT引導(dǎo)程序指引復(fù)制APP2的備份程序到APP區(qū)域進(jìn)行回滾操作并啟動(dòng)，確保ECU工作正常。對(duì)于APP容量較小不支持APP2空間劃分的ECU，只能依靠OTA主控節(jié)點(diǎn)實(shí)現(xiàn)升級(jí)包的備份存儲(chǔ)。

圖7 嵌入式ECU軟件存儲(chǔ)及刷新策略圖

3.2.4 OTA遠(yuǎn)程故障診斷設(shè)計(jì)

OTA刷新目前主要是通過(guò)診斷通訊方式實(shí)現(xiàn)的ECU刷新條件檢查、刷新過(guò)程數(shù)據(jù)傳輸及刷新后復(fù)位重啟等操作，刷新過(guò)程中被刷新ECU由于進(jìn)BOOT或其它原因無(wú)法保證應(yīng)用程序正常運(yùn)行（無(wú)感刷新方式除外）時(shí)，需要提前進(jìn)行ECU故障屏蔽設(shè)計(jì)以免刷新過(guò)程造成整車(chē)出現(xiàn)一些故障碼，誤導(dǎo)后續(xù)遠(yuǎn)程故障診斷及統(tǒng)計(jì)分析。OTA刷新過(guò)程中，診斷故障屏蔽可采用UDS診斷協(xié)議中的0x85（Control DTC Setting）服務(wù)來(lái)實(shí)現(xiàn)。OTA遠(yuǎn)程故障診斷，還要解決的一個(gè)難點(diǎn)是與本地故障診斷的沖突問(wèn)題。OTA云平臺(tái)難以識(shí)別本地診斷設(shè)備，因此，必須要在車(chē)端集成遠(yuǎn)程診斷與本地診斷的仲裁判斷邏輯。由中央網(wǎng)關(guān)（GW）負(fù)責(zé)仲裁協(xié)調(diào)，當(dāng)OTA刷新過(guò)程中，網(wǎng)關(guān)屏蔽本地故障診斷路由轉(zhuǎn)發(fā)功能；同理，當(dāng)有本地診斷設(shè)備時(shí)，網(wǎng)關(guān)屏蔽遠(yuǎn)程故障診斷路由轉(zhuǎn)發(fā)功能，屏蔽只在當(dāng)前點(diǎn)火循環(huán)有效。

04 結(jié) 論

汽車(chē)OTA刷新為遠(yuǎn)程診斷技術(shù)帶來(lái)了迫切的需求和絕佳的發(fā)展機(jī)遇，主機(jī)廠(chǎng)積極部署的OTA升級(jí)體系和遠(yuǎn)程診斷平臺(tái)，不僅是為了當(dāng)下車(chē)輛的軟件漏洞修復(fù)和功能快速更新，更是為了適應(yīng)“軟件定義”汽車(chē)（SDV）的趨勢(shì)及更高階的自動(dòng)駕駛的技術(shù)發(fā)展，而主機(jī)廠(chǎng)遠(yuǎn)程診斷平臺(tái)積累的數(shù)據(jù)，正是考驗(yàn)其大數(shù)據(jù)挖掘與智能診斷應(yīng)用相結(jié)合的綜合能力。身為“領(lǐng)頭羊”的特斯拉，通過(guò)遠(yuǎn)程診斷技術(shù)已經(jīng)實(shí)現(xiàn)90%情況下的車(chē)輛部件故障診斷，每年可為車(chē)主節(jié)省一天維修工時(shí)。國(guó)內(nèi)車(chē)企要奮起直追，為車(chē)主提供更便捷、滿(mǎn)意的服務(wù)體驗(yàn)，仍需較長(zhǎng)的發(fā)展歷程。

審核編輯：湯梓紅