現代車輛中的汽車軟件變得非常復雜，并且提供了各種新功能和機遇。制造商的主要問題是要確保將新功能，錯誤修復和改進迅速應用于車輛，因為當今修理廠的軟件更新方法不切實際。可以考慮通過空中更新（OTA）來更新新軟件，而不會導致驅動程序中斷。這就要求開發一個平臺，該平臺可以動態部署和更新應用程序，這是自適應AUTOSAR。這些程序不得違反安全關鍵ECU的正常工作，并應確保系統不受外部入侵的影響。在本文中，我們提出了一種車輛更新解決方案，其中包括將IoT技術與自適應AUTOSAR平臺集成在一起，
如今，現代車輛非常依賴于軟件，這可以實現一套全新的服務以及與駕駛員和乘客的交互，而許多功能取決于車輛的連接性。與智能手機建立連接和交換數據的能力是這一新興趨勢的一大進步。由于車輛已經開始與外界進行通信，因此汽車行業需要快速做出反應，并采用依賴于連接性的功能，例如遠程更新，與軟件即服務（SaaS）范式與后端系統的通信等。
在越來越多的電子控制單元（ECU）中增加軟件復雜性的同時，許多軟件組件已連接到外界，這為可能危害安全性的漏洞和利用創造了理想的環境。軟件不可能做到防錯；因此，最先進的產品與徹底的故障之間的界限非常小。對于原始設備制造商（OEM）而言，找到一種提供快速，安全，可靠的更新機制來解決這些問題的方法非常具有挑戰性。
當前的汽車軟件堆棧大多符合AUTOSAR。AUTOSAR伙伴關系的最新功能-自適應框架[1]將提供動態升級軟件組件的機制。但是，在這種情況下，尚未提出用于可靠，安全的軟件升級例程的完整流程。在本文中，我們提出了一個完整的升級軟件體系結構，包括基于智能家居的基于物聯網（IoT）技術的云連接；適用于托管和遠程組件的自適應AUTOSAR堆棧擴展，驗證和升級過程，以及面向OEM，驅動程序和服務人員的前端擴展。我們還將在模擬環境中對提出的概念進行評估。
解決汽車中軟件更新問題的專有解決方案已經開發出來。有福特的Sync 3 [2]，Harman的OTA系統[3]，Uconnect [4]等。這些封閉的解決方案為系統強加了垂直方向的軟件體系結構。當系統中需要更改或升級時，這會給OEM廠商帶來重大問題。在這種情況下，標準化平臺仍然不存在。自適應AUTOSAR將是第一個為此提供統一的應用程序編程接口（API）并解決如圖1所示的創建水平對齊汽車軟件體系結構的問題的標準。
圖1.自適應AUTOSAR堆棧
關于學術界，也有關于車輛軟件的安全交付的研究和相關工作[5]，以及具有自定義框架[6]和[7]的完整更新流程。這些技術和程序在物聯網領域已經很成熟[8]，并且由于車輛的生命攸關性，它們可以在汽車工業中繼承并進行適當的調整。
現有許多更新管理器解決方案，例如OSTree [9]或GENIVI SOTA [10]等，但是對于汽車ECU來說可能是至關重要的，因此這些管理器不適用，因此，新的管理器應基于較高的原則進行設計。安全性，驗證性，授權性和數據正確性。在版本回滾，中間安裝失敗或取消的情況下，Automotive Update Manager也需要回滾過程。
據我們所知，汽車工業和學術界仍在尋求基于自適應AUTOSAR平臺的軟件動態升級的集成解決方案，并且許多提議的方法仍然相沖突。
III
擬議的軟件更新體系結構如圖2所示：
圖2.
更新流程的體系結構A.?OBLO系統
為了使車輛的OTA更新成為可能，名為“ OBLO”?[11]的用于智能家居的現有物聯網技術被用作系統的后端部分。OBLO系統的主要組件是圖3中的用戶和管理門戶，云服務，數據庫和網關。
圖3.
OBLO系統架構用戶和管理員使用門戶網站獲取有關家庭設備的信息或以所需方式對其進行控制。車輛作為智能設備顯示在系統中，有關車輛的信息包括已安裝應用程序及其版本的列表，如圖4所示。
重要的功能是，通過門戶網站，用戶可以在升級可用時得到通知，并可以選擇是否要更新。用戶管理的應用程序來自Infotainment領域，對車輛中的乘客無害。但是，對于至關重要的更新，OEM可以從管理門戶觸發更新。
圖4.
用戶門戶啟動更新后，云服務負責使用MQTT協議將消息延長到網關。網關是放置在站點（家庭）上的OBLO系統的一部分，與節點（智能設備）進行通信。擴展了此組件，以便可以將車輛作為新的智能設備進行支持，并可以與平臺（車輛中的ECU）進行更精確的通信-使用OTA Bridge Agent。
B.?OTA橋接代理
空中（OTA）橋接代理代表了自適應AUTOSAR平臺的擴展，該平臺支持IoT系統與平臺本身之間的雙向通信。代理使用來自自適應平臺（ARA :: COM）的通信模塊與活動的自適應應用程序和服務進行通信，以收集數據并接收由承載不同類型信息的系統組件生成的各種類型的事件。
圖5.
OTA橋架構通過代理本身的一部分Bridge Client組件與IoT云服務進行通信，如圖5所示。Bridge Client將通信的詳細信息（如協議或格式）抽象到平臺的其余部分。這使其與物聯網技術無關。
網橋運行時組件負責使用發布/訂閱模式在代理中分發事件。事件從服務傳播到客戶端，反之亦然。Bridge Services和Bridge Client都注冊到Bridge Runtime，并為其支持的各種類型的事件提供適當的處理器。當內部通信的參與者之一嘗試將其事件發送到運行系統時，此事件將放置在事件的可用隊列之一上。多個隊列用于在事件分發期間提供最小的延遲。
代理程序最重要的部分是其橋接服務形式的擴展，可以綁定到Adaptive Platform的不同部分，例如診斷或更新和配置服務。通過在Bridge Runtime上注冊來添加服務，從而應提供處理回調函數以及“預訂”事件的列表。
OTA Bridge代理通過更新程序服務進行了擴展，該更新程序服務與自適應平臺（ARA :: UCM）的更新和配置管理器綁定。在被云通知后，更新程序服務將下載軟件包，因為ARA :: UCM僅適用于軟件包的本地副本。下載完成后，更新程序將調用ARA :: UCM方法來處理下載的軟件包。
C. 更新和配置管理器（ARA :: UCM）
ARA :: UCM[12]是自適應平臺服務，不僅負責應用程序的更新，還負責底層OS和平臺本身的更新。該服務的輸入是“軟件包”。
“軟件包”是數據的組合，例如多個應用程序二進制文件，配置文件，資源等，以及為ARA :: UCM提供處理信息的軟件包元數據。軟件包的內容由OEM創建，生成和測試，然后上傳到OBLO服務器。上載后，門戶網站會顯示有關新更新的通知。
由于ARA :: UCM不負責啟動此過程，因此Updater Service會開始處理程序包。為了防止從另一個應用程序未經授權啟動該過程，在這兩個服務之間的通信中強制執行訪問策略。
ARA :: UCM服務負責進一步的安全措施，包括包裝驗證，內存要求檢查，跟蹤正確的版本等。此外，在車輛處于行駛或停車模式時，無法進行更新，因此，在將車輛置于特殊狀態之前-更新狀態。
除了有關安全性的功能外，ARA :: UCM服務的簡化任務如圖6所示。
圖6.ARA :: UCM用例圖
IV.評價
通過測試完整的更新流程來完成驗證和確認。通過創建軟件包并上載來測試服務器。如果不是關鍵更新，則通過用戶門戶通知用戶更新的可能性，如圖7所示。然后，他們應該決定是否要升級軟件。
圖7.有可用更新
啟動更新后，將在車輛級別執行上述過程。通過在圖8的用戶門戶上驗證應用程序的版本，并且在ECU級別沒有崩潰的情況下，可以確認更新成功。
圖8.更新的應用程序
這樣的系統非常復雜，其性能取決于許多因素，例如Wi-Fi信號的強度和帶寬，云服務的負載，汽車的狀態，包裹尺寸，請求的類型等等。由于諸多因素，對車輛中執行的程序進行優化是很重要的。
表I的測量結果表明執行時間以毫秒為單位。與Web和IoT技術相比，響應時間可以是幾秒鐘，這表明該解決方案滿足可以受到影響的標準。此外，可以看出，使用較大的程序包，執行時間會線性增長，這是可以預期的。
表I與軟件包大小有關的安裝請求的ARA :: UCM服務的執行時間
V.結論
本文提出的解決方案集成了現有的物聯網技術-OBLO和新的自適應AUTOSAR平臺，可幫助OEM解決昂貴且車輛更新緩慢的問題。提供快速方式將最新軟件交付給車輛將滿足非常苛刻的市場。
隨著車輛變得越來越自主，駕駛員和乘客有更多的時間和空間來娛樂。此解決方案的未來工作可以是為Infotainment域實現“ App Store”，以確保客戶滿意度。
分享不易，懇請點個【??】和【在看】
