摘要

現(xiàn)代車輛中的汽車軟件變得非常復(fù)雜，并且提供了各種新功能和機(jī)遇。制造商的主要問(wèn)題是要確保將新功能，錯(cuò)誤修復(fù)和改進(jìn)迅速應(yīng)用于車輛，因?yàn)楫?dāng)今修理廠的軟件更新方法不切實(shí)際。可以考慮通過(guò)空中更新（OTA）來(lái)更新新軟件，而不會(huì)導(dǎo)致驅(qū)動(dòng)程序中斷。這就要求開發(fā)一個(gè)平臺(tái)，該平臺(tái)可以動(dòng)態(tài)部署和更新應(yīng)用程序，這是自適應(yīng)。這些程序不得違反安全關(guān)鍵ECU的正常工作，并應(yīng)確保系統(tǒng)不受外部入侵的影響。在本文中，我們提出了一種車輛更新解決方案，其中包括將IoT技術(shù)與自適應(yīng)平臺(tái)集成在一起，

I.介紹

如今，現(xiàn)代車輛非常依賴于軟件，這可以實(shí)現(xiàn)一套全新的服務(wù)以及與駕駛員和乘客的交互，而許多功能取決于車輛的連接性。與智能手機(jī)建立連接和交換數(shù)據(jù)的能力是這一新興趨勢(shì)的一大進(jìn)步。由于車輛已經(jīng)開始與外界進(jìn)行通信，因此汽車行業(yè)需要快速做出反應(yīng)二手車評(píng)估軟件，并采用依賴于連接性的功能，例如遠(yuǎn)程更新，與軟件即服務(wù)（SaaS）范式與后端系統(tǒng)的通信等。

在越來(lái)越多的電子控制單元（ECU）中增加軟件復(fù)雜性的同時(shí)，許多軟件組件已連接到外界，這為可能危害安全性的漏洞和利用創(chuàng)造了理想的環(huán)境。軟件不可能做到防錯(cuò)；因此，最先進(jìn)的產(chǎn)品與徹底的故障之間的界限非常小。對(duì)于原始設(shè)備制造商（OEM）而言，找到一種提供快速，安全，可靠的更新機(jī)制來(lái)解決這些問(wèn)題的方法非常具有挑戰(zhàn)性。

當(dāng)前的汽車軟件堆棧大多符合。伙伴關(guān)系的最新功能-自適應(yīng)框架[1]將提供動(dòng)態(tài)升級(jí)軟件組件的機(jī)制。但是，在這種情況下，尚未提出用于可靠，安全的軟件升級(jí)例程的完整流程。在本文中，我們提出了一個(gè)完整的升級(jí)軟件體系結(jié)構(gòu)，包括基于智能家居的基于物聯(lián)網(wǎng)（IoT）技術(shù)的云連接；適用于托管和遠(yuǎn)程組件的自適應(yīng)堆棧擴(kuò)展，驗(yàn)證和升級(jí)過(guò)程，以及面向OEM，驅(qū)動(dòng)程序和服務(wù)人員的前端擴(kuò)展。我們還將在模擬環(huán)境中對(duì)提出的概念進(jìn)行評(píng)估。

II.相關(guān)工作

解決汽車中軟件更新問(wèn)題的專有解決方案已經(jīng)開發(fā)出來(lái)。有福特的Sync 3 [2]，的OTA系統(tǒng)[3]， [4]等。這些封閉的解決方案為系統(tǒng)強(qiáng)加了垂直方向的軟件體系結(jié)構(gòu)。當(dāng)系統(tǒng)中需要更改或升級(jí)時(shí)，這會(huì)給OEM廠商帶來(lái)重大問(wèn)題。在這種情況下，標(biāo)準(zhǔn)化平臺(tái)仍然不存在。自適應(yīng)將是第一個(gè)為此提供統(tǒng)一的應(yīng)用程序編程接口（API）并解決如圖1所示的創(chuàng)建水平對(duì)齊汽車軟件體系結(jié)構(gòu)的問(wèn)題的標(biāo)準(zhǔn)。

圖1.自適應(yīng)堆棧

關(guān)于學(xué)術(shù)界，也有關(guān)于車輛軟件的安全交付的研究和相關(guān)工作[5]，以及具有自定義框架[6]和[7]的完整更新流程。這些技術(shù)和程序在物聯(lián)網(wǎng)領(lǐng)域已經(jīng)很成熟[8]，并且由于車輛的生命攸關(guān)性，它們可以在汽車工業(yè)中繼承并進(jìn)行適當(dāng)?shù)恼{(diào)整。

現(xiàn)有許多更新管理器解決方案，例如 [9]或 SOTA [10]等，但是對(duì)于汽車ECU來(lái)說(shuō)可能是至關(guān)重要的，因此這些管理器不適用，因此，新的管理器應(yīng)基于較高的原則進(jìn)行設(shè)計(jì)。安全性，驗(yàn)證性，授權(quán)性和數(shù)據(jù)正確性。在版本回滾，中間安裝失敗或取消的情況下， 也需要回滾過(guò)程。

據(jù)我們所知，汽車工業(yè)和學(xué)術(shù)界仍在尋求基于自適應(yīng)平臺(tái)的軟件動(dòng)態(tài)升級(jí)的集成解決方案，并且許多提議的方法仍然相沖突。

III

.解

擬議的軟件更新體系結(jié)構(gòu)如圖2所示：

圖2.更新流程的體系結(jié)構(gòu)

A.OBLO系統(tǒng)

為了使車輛的OTA更新成為可能，名為“OBLO”[11]的用于智能家居的現(xiàn)有物聯(lián)網(wǎng)技術(shù)被用作系統(tǒng)的后端部分。OBLO系統(tǒng)的主要組件是圖3中的用戶和管理門戶，云服務(wù)，數(shù)據(jù)庫(kù)和網(wǎng)關(guān)。

圖3.OBLO系統(tǒng)架構(gòu)

用戶和管理員使用門戶網(wǎng)站獲取有關(guān)家庭設(shè)備的信息或以所需方式對(duì)其進(jìn)行控制。車輛作為智能設(shè)備顯示在系統(tǒng)中，有關(guān)車輛的信息包括已安裝應(yīng)用程序及其版本的列表，如圖4所示。

重要的功能是，通過(guò)門戶網(wǎng)站，用戶可以在升級(jí)可用時(shí)得到通知，并可以選擇是否要更新。用戶管理的應(yīng)用程序來(lái)自領(lǐng)域，對(duì)車輛中的乘客無(wú)害。但是二手車評(píng)估軟件，對(duì)于至關(guān)重要的更新，OEM可以從管理門戶觸發(fā)更新。

圖4.用戶門戶

啟動(dòng)更新后，云服務(wù)負(fù)責(zé)使用MQTT協(xié)議將消息延長(zhǎng)到網(wǎng)關(guān)。網(wǎng)關(guān)是放置在站點(diǎn)（家庭）上的OBLO系統(tǒng)的一部分，與節(jié)點(diǎn)（智能設(shè)備）進(jìn)行通信。擴(kuò)展了此組件，以便可以將車輛作為新的智能設(shè)備進(jìn)行支持，并可以與平臺(tái)（車輛中的ECU）進(jìn)行更精確的通信-使用OTA 。

B.OTA橋接代理

空中（OTA）橋接代理代表了自適應(yīng)平臺(tái)的擴(kuò)展，該平臺(tái)支持IoT系統(tǒng)與平臺(tái)本身之間的雙向通信。代理使用來(lái)自自適應(yīng)平臺(tái)（ARA :: COM）的通信模塊與活動(dòng)的自適應(yīng)應(yīng)用程序和服務(wù)進(jìn)行通信，以收集數(shù)據(jù)并接收由承載不同類型信息的系統(tǒng)組件生成的各種類型的事件。

圖5.OTA橋架構(gòu)

通過(guò)代理本身的一部分組件與IoT云服務(wù)進(jìn)行通信，如圖5所示。 將通信的詳細(xì)信息（如協(xié)議或格式）抽象到平臺(tái)的其余部分。這使其與物聯(lián)網(wǎng)技術(shù)無(wú)關(guān)。

網(wǎng)橋運(yùn)行時(shí)組件負(fù)責(zé)使用發(fā)布/訂閱模式在代理中分發(fā)事件。事件從服務(wù)傳播到客戶端，反之亦然。 和 都注冊(cè)到，并為其支持的各種類型的事件提供適當(dāng)?shù)奶幚砥鳌．?dāng)內(nèi)部通信的參與者之一嘗試將其事件發(fā)送到運(yùn)行系統(tǒng)時(shí)，此事件將放置在事件的可用隊(duì)列之一上。多個(gè)隊(duì)列用于在事件分發(fā)期間提供最小的延遲。

代理程序最重要的部分是其橋接服務(wù)形式的擴(kuò)展，可以綁定到 的不同部分，例如診斷或更新和配置服務(wù)。通過(guò)在 上注冊(cè)來(lái)添加服務(wù)，從而應(yīng)提供處理回調(diào)函數(shù)以及“預(yù)訂”事件的列表。

OTA 代理通過(guò)更新程序服務(wù)進(jìn)行了擴(kuò)展，該更新程序服務(wù)與自適應(yīng)平臺(tái)（ARA :: UCM）的更新和配置管理器綁定。在被云通知后，更新程序服務(wù)將下載軟件包，因?yàn)锳RA :: UCM僅適用于軟件包的本地副本。下載完成后，更新程序?qū)⒄{(diào)用ARA :: UCM方法來(lái)處理下載的軟件包。

C. 更新和配置管理器（ARA:: UCM）

ARA :: UCM[12]是自適應(yīng)平臺(tái)服務(wù)，不僅負(fù)責(zé)應(yīng)用程序的更新，還負(fù)責(zé)底層OS和平臺(tái)本身的更新。該服務(wù)的輸入是“軟件包”。

“軟件包”是數(shù)據(jù)的組合，例如多個(gè)應(yīng)用程序二進(jìn)制文件，配置文件，資源等，以及為ARA :: UCM提供處理信息的軟件包元數(shù)據(jù)。軟件包的內(nèi)容由OEM創(chuàng)建，生成和測(cè)試，然后上傳到OBLO服務(wù)器。上載后，門戶網(wǎng)站會(huì)顯示有關(guān)新更新的通知。

由于ARA:: UCM不負(fù)責(zé)啟動(dòng)此過(guò)程，因此 會(huì)開始處理程序包。為了防止從另一個(gè)應(yīng)用程序未經(jīng)授權(quán)啟動(dòng)該過(guò)程，在這兩個(gè)服務(wù)之間的通信中強(qiáng)制執(zhí)行訪問(wèn)策略。

ARA :: UCM服務(wù)負(fù)責(zé)進(jìn)一步的安全措施，包括包裝驗(yàn)證，內(nèi)存要求檢查，跟蹤正確的版本等。此外，在車輛處于行駛或停車模式時(shí)二手車評(píng)估軟件，無(wú)法進(jìn)行更新，因此，在將車輛置于特殊狀態(tài)之前-更新狀態(tài)。

除了有關(guān)安全性的功能外，ARA:: UCM服務(wù)的簡(jiǎn)化任務(wù)如圖6所示。

圖6.ARA :: UCM用例圖

IV.評(píng)價(jià)

通過(guò)測(cè)試完整的更新流程來(lái)完成驗(yàn)證和確認(rèn)。通過(guò)創(chuàng)建軟件包并上載來(lái)測(cè)試服務(wù)器。如果不是關(guān)鍵更新，則通過(guò)用戶門戶通知用戶更新的可能性，如圖7所示。然后，他們應(yīng)該決定是否要升級(jí)軟件。

圖7.有可用更新

啟動(dòng)更新后，將在車輛級(jí)別執(zhí)行上述過(guò)程。通過(guò)在圖8的用戶門戶上驗(yàn)證應(yīng)用程序的版本，并且在ECU級(jí)別沒(méi)有崩潰的情況下，可以確認(rèn)更新成功。

圖8.更新的應(yīng)用程序

這樣的系統(tǒng)非常復(fù)雜，其性能取決于許多因素，例如Wi-Fi信號(hào)的強(qiáng)度和帶寬，云服務(wù)的負(fù)載，汽車的狀態(tài)，包裹尺寸，請(qǐng)求的類型等等。由于諸多因素，對(duì)車輛中執(zhí)行的程序進(jìn)行優(yōu)化是很重要的。

表I的測(cè)量結(jié)果表明執(zhí)行時(shí)間以毫秒為單位。與Web和IoT技術(shù)相比，響應(yīng)時(shí)間可以是幾秒鐘，這表明該解決方案滿足可以受到影響的標(biāo)準(zhǔn)。此外，可以看出，使用較大的程序包，執(zhí)行時(shí)間會(huì)線性增長(zhǎng)，這是可以預(yù)期的。

表I與軟件包大小有關(guān)的安裝請(qǐng)求的ARA :: UCM服務(wù)的執(zhí)行時(shí)間

V.結(jié)論

本文提出的解決方案集成了現(xiàn)有的物聯(lián)網(wǎng)技術(shù)-OBLO和新的自適應(yīng)平臺(tái)，可幫助OEM解決昂貴且車輛更新緩慢的問(wèn)題。提供快速方式將最新軟件交付給車輛將滿足非常苛刻的市場(chǎng)。

隨著車輛變得越來(lái)越自主，駕駛員和乘客有更多的時(shí)間和空間來(lái)娛樂(lè)。此解決方案的未來(lái)工作可以是為域?qū)崿F(xiàn)“ ”，以確保客戶滿意度。

END