總體說明

(圖片來源主要來源于Simulink 以及 Vector)在Autosar官網(autosar.org)上,目前CLASSIC PLATFORM 更新到4.4版本,ADAPTIVE PLATFORM更新到19.03版本,期盼已久的Adaptive Autosar終于有了基本構架。Adaptive Autosar 不是針對Classic Autosar的升級替換,它的出現主要面對汽車更復雜的需求,包括自動駕駛、車聯網以及域控制等,而傳統的ECU依然采用Classic Autosar進行開發,同時他們共存在未來智能汽車中,他們可以通過以太網進行交互。本文主要針對當前Adaptive 的信息進行匯總說明。CP和AP對比
上面圖片來自Simulink,我們看到其中的RTE在Classic Autosar中,而ARA(Autosar Run-time For Adaptive)是Adaptive Autosar的實時運行環境,他們主要區別是 Classic RTE基本是靜態配置的,而Adaptive ARA則是動態的,并且Application就像我們在電腦上安裝軟件一樣可以安裝、升級、卸載。上面圖片來自Vector,我們看到其實整體的差別還是比較大的,Adaptive Autosar中保留了部分Classic的基礎服務,例如診斷、網絡管理等,而新增了很多新的服務如升級與配置、健康管理、執行管理、狀態轉移等。操作系統由之前的Autosar OS 變為POSIX(可移植操作系統)如Linux等。AP架構說明
架構分層主要分為硬件層,基礎服務層,ARA(實時運行環境),以及應用層。基礎服務層中,主要服務包括,通信服務(COM)、加密服務(crypto)、日志記錄服務(Log)、診斷服務(Diag)、存儲服務(Per)、狀態管理(SM)、執行管理(Exec)、時間同步(Tsync)、升級配置管理(UCM)等AP關鍵點
基礎服務介紹
從上節我們知道Application就是OS的一個一個進程,Autosar 采用一個Manifest用來配置管理這些進程信息,包含平臺相關的信息,恢復操作以及與服務或庫相關的依賴關系,Instance 配置文件主要包含靜態的信息,這里會配合執行管理Exec、升級與配置管理UCM以及狀態管理SM等來配合管理進程。采用Proxy/Skeleton的通信架構,同時采用中間件SOME/IP。
客戶端 -->服務端具體服務請求方式如上圖(vector圖)所示:1. 代理請求服務--2.服務傳輸--3.調用服務--4.結果響應--5.獲取結果。具體事件請求過程如下:1.服務端事件請求--2.事件傳輸--3.事件存儲--4.用戶事件處理。
執行管理負責系統初始化以及Adaptive Applications的啟動和關閉。它使用Manifest文件中包含的信息來執行這些任務,包括何時以及如何啟動可執行文件。啟動階段:進行OS的啟動,根據應用的manifest文件中的描述,進行應用程序的啟動與執行。運行階段:使應用運行在狀態機所期望的狀態,并監測狀態機狀態的改變和進程的終止。Adaptive Autosar也同樣使用UDS診斷服務,只是物理層采用以太網方式,同時也可以看到應用層通過com服務來請求診斷服務。主要通過per模塊的服務來針對關鍵數據進行存儲或實現流存儲。
版權聲明:本文為CSDN博主「AgingMoon」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明,已獲作者轉載許可。車輛診斷系統中的安全挑戰
關于 ASPICE 的理解
CAN FD網絡設計提示和建議
詳解汽車Bootloader設計
特斯拉Autopilot系統安全研究|附dbc下載
詳解功能安全概念階段
詳細揭秘大眾ID.4的高壓系統
特斯拉Model 3的BMS系統
結合AUTOSAR和DDS實現靈活的車輛架構