概述

本文主要內容分為兩章節。第一章節簡要介紹了AUTOSAR的軟件架構，設計理念以及方法論，對Classic Platform和Adaptive Platform做了簡單的比較。第二章主要介紹了Adaptive Platform的特性。

第一章 AUTOSAR架構介紹

AUTOSAR(AUTomotive Open System ARchitecture)是汽車和軟件行業領先公司的全球合作聯盟，為智能移動開發和建立標準化的軟件框架以及開放的E/E系統架構。考慮到目前和未來市場中不同的汽車E/E架構，AUTOSAR聯盟為汽車軟件架構建立了開放的行業標準。因此AUTOSAR有兩種含義，一是代表AUTOSAR聯盟，二是代表AUTOSAR軟件架構。

AUTOSAR基本原理

相比傳統軟件架構，AUTOSAR在上層軟件和底層硬件平臺之間嵌入標準的中間層，實現了軟硬件的解耦。AUTOSAR的口號是標準上協作，實現上競爭。 通過軟硬件解耦，縮短研發周期和降低研發成本，同時通過軟件的復用提供研發質量和效率。由于有統一的標準（軟件接口，文件交換格式，方法論），因此OEM、供應商、工具提供商等可以協同開發，簡化軟件系統的集成，軟件模塊可以復用和高效率的衍生，提高了研發效率，降低整體軟件的研發成本。

基本的AUTOSAR方法

下圖是簡化版的AUTOSAR開發工作流。AUTOSAR將應用軟件和硬件平臺進行解耦，在應用軟件和基礎軟件與硬件之間嵌入虛擬功能總線，應用之間的通信或者訪問硬件資源等都是通過虛擬功能總線進行資源交換。在Classic Platform中虛擬功能總線為RTE層，在Adaptive Platform中虛擬功能總線為ARA層。由于AUTOSAR采用自上而下的方法論，從架構設計、接口描述，軟件開發，功能組件集成都是采用模型開發。因此可以使用代碼生成工具，將SWC描述文件、ECU描述文件、系統約束文件等導入工具后可以生成可執行代碼。

未來的汽車產業挑戰

2003年，汽車行業的高端玩家們發起了汽車嵌入式系統軟件架構標準化項目——AUTOSAR(汽車開放系統架構)。2017年，為適應汽車的發展趨勢（智能化，網聯化等），應對汽車E/E系統開發面臨的新的挑戰（高性能處理器的應用，自動駕駛軟件的實現，高帶寬通信的需求，車與外界的互聯互通，汽車E/E架構的演變等），AUTOSAR組織推出了AUTOSAR Adaptive Platform。

AUTOSAR的愿景和目標

AUTOSAR架構的特點

AUTOSAR 軟件架構

Foundation

Foundation是Classic Platform和Adaptive Platform公共的部分，比如總線協議，方法論等

Classic Platform

CP平臺是為硬實時和安全要求嚴格的嵌入式系統的提出的AUTOSAR解決方案。

Adaptive Platform

AP平臺是為高性能計算的ECU提出的解決辦法，用于自動駕駛等。

Acceptance Tests

AUTOSAR驗收測試是總線級和應用程序級的系統測試，用于驗證與應用軟件組件和通信總線相關的AUTOSAR堆棧的行為

Acceptance Interface

AUTOSAR根據語法和語義為以下五個汽車領域標準化了大量的應用接口:車身和舒適性、動力總成發動機、動力總成傳動系統、底盤控制以及乘員和行人安全。

AUTOSAR Classic Platform架構

Classic AUTOSAR將微控制器上的軟件抽象為三個軟件層：應用程序、運行時環境(RTE)和基本軟件(BSW)。其中BSW分為三個主要層：服務層、ECU抽象層和微控制器抽象層。應用與應用之間，以及應用于BSW之間的通信都是經過RTE完成數據交換，因此做到了應用與硬件的完全獨立。 Classic AUTOSAR是分層軟件體系結構，軟件需求在設計時通過每一層的靜態配置來實現。因此，對于運行時的更改，它的靈活性較低，但是這點還是可以接受的，因為這個平臺通常在車輛的生命周期內保持穩定，因為被控制的傳感器和執行器的應用邏輯不會改變，傳感器和執行器仍然履行它們本身的功能。關注公號-車端

VECTOR Classic AUTOSAR架構

AUTOSAR Adaptive Platform架構

Adaptive AUTOSAR平臺為AUTOSAR應用實現了運行環境ARA。使用兩種接口完成數據交換：服務和API。平臺由功能集群組成，這些集群按服務和自適應AUTOSAR基礎進行分組如下。 Adaptive AUTOSAR解決了新一代汽車高性能需求、連接性和持續軟件無線(OTA)更新帶來的新市場需求，它作為多個供應商的軟件集成平臺，解決了Classic AUTOSAR經典架構的局限性，其為靈活性而設計的，以便在運行時支持軟件更改。Adaptive AUTOSAR構建在POSIX操作系統之上，由不同的功能模塊組成，這些模塊被劃分在服務模塊和基礎模塊上,它的的通信是面向服務類型的，會將網絡綁定到DDS或者SOME/IP使用以太網與其它ECU通信。

Adaptive Platform邏輯視圖

VECTOR Adaptive AUTOSAR架構

AP與CP架構比較

AUTOSAR CP平臺與AP平臺特性比較

綜上，AUTOSAR包含了Classic Platform和Adaptive Platfrom。Adaptive Platform并不是用來取代Classic Platform或者非AUTOSAR平臺，而是為了相互兼容，協作并滿足未來的需求。

第二章 Adaptive AUTOSAR特性介紹

技術范圍和方法

智能ECU

現在的ECU的主要功能實現都是為了增強或者取代電子機械系統，所以現在的電子電器架構很多都采用線控系統。ECU內部的嵌入式軟件根據輸入的信號或者來自于車載網絡的其他ECU的信息控制輸出信號。許多軟件是根據目標車輛設計和實現，在車輛的生命周期中不會發生根本性的變化。 未來的車輛功能，比如高級自動駕駛，會使得軟件變得非常復雜且需要很高的算力，并且要滿足嚴格的集成性和安全需要。這些軟件實現了環境感知、行為規劃等功能，并將車輛集成到外部后端和基礎設施系統中。由于外部系統的發展或功能的改進，在車輛的生命周期中，車輛中的軟件需要更改。正是由于這些需要，現在越來越多的車輛支持OTA功能，OTA功能就像我們使用手機一樣，可以借助空中升級功能不斷更新軟件功能。功能的更新可能是修復一個BUG，或是增加一個功能，又或是增強一個性能等等，這種變化使能車輛具有不斷升級的能力，也賦予了用戶與車輛更多的粘性。 由于AUTOSAR Classic Platform(CP)標準不能完全解決以上需求，因此，AUTOSAR組織提出了AP平臺的標準，AP平臺主要提供了高性能的計算和通信機制以及靈活的軟件配置，例如支持OTA軟件升級。

技術驅動

技術驅動主要有兩個方面，一個是以太網，另一個是處理器。 日益增長的車輛網絡帶寬需求幫助以太網應用在汽車網絡通信中，其提供了更高的帶寬和交換網絡，相比傳統的車載通信總線，例如CAN總線，其帶來了長消息的有效傳遞和點對點的通信。雖然CP也支持以太網通信，但主要是為傳統通信技術設計和優化的，因此也是很難充分利于以太網的通信能力。關注公號-車端 類似的，隨著汽車功能越來越復雜，對于處理器的處理能力的需要也是逐年劇增。雖然多核處理器已經能夠應用在CP平臺，但是有些應用需要成百上千的多核處理器，比如GPU，專用加速器等應用相比傳統MCU來說能夠提供更高的性能。CP平臺曾經是為了單核處理器設計，雖然現在也支持多核，但計算的最佳性能往往需要結合不同的計算資源，比如多核，協處理器，GPU，FPGA和加速器等。這種混合方式被稱為異構計算，其能力遠遠超過了CP。

AP特性

AP包含的特性來自于未來的智能ECU和技術驅動兩個方面。高性能的計算滿足了安全的需要同時也需要很高的能耗，因此帶來了許多新的挑戰。為了應對這些挑戰，AP采用了很多傳統ECU未充分利用的技術。有如下幾個方面 C++ Adaptive AUTOSAR平臺的應用都將采用C++編程。雖然C語言是嵌入式系統的主要編程語言，具有執行速度快、效率高的特點；但是在性能要求非常高的復雜應用和算法開發上（如機器學習、圖像特征識別等）具有面向對象特性的C++顯然比C更具有優勢。C++能夠提供算法開發和性能均衡的軟件。并且方便很快地適配和量產開發。 SOA 為了支持復雜的應用程序，同時在處理分布和計算資源分配方面允許最大的靈活性和可伸縮性，AP遵循SOA(service-oriented-architecture)的架構。SOA主要基于以下概念：系統由一組服務構成，其中 一個可使用另外一個的服務，應用程序可根據自己的需要使用一個或者多個服務；此外服務可以在應用程序運行的本地ECU上，也可以運行在另一個AP實例的遠程ECU上。關于什么是SOA，目前還沒有明確的結論。

官網：Scalable service-Oriented MiddlewarE over IP (SOME/IP) (some-ip.com)

? 并行處理能力 分布式計算本質是并行的。先進的多核異構處理器既具有強大的計算能力也能為并行計算提供技術支持，隨著多核異構計算技術的發展，AP具有擴展其功能和性能架構的能力。事實上，硬件和接口規范僅是實現AP的一部分，在OS等技術和開發工具的發展上對實現AP的應用也至關重要。 利用現有標準 重新發明輪子是沒有意義的，尤其在規范方面。正如已經在c++中描述的那樣，AP采取了重用和適應現有開放標準的策略，以促進AP自身的更快發展，并從現有標準的生態系統中受益。因此，開發AP規范的一個關鍵重點是不要隨意引入現有標準已經提供的新替代功能。例如，這意味著不會僅僅因為現有標準提供了所需的功能，但接口表面上不容易理解，就隨意引入新的接口。 安全性 AP所針對的系統通常需要某種級別的安全性，可能是最高級別的安全性。新概念和技術的引入不應破壞這些需求，盡管實現這些需求并非易事。為了應對這一挑戰，AP結合了體系結構、功能和過程方法。該架構基于基于SOA的分布式計算，這使得每個組件更加獨立，避免了意想不到的干擾，具有專門的功能來幫助實現安全和保障，以及諸如c++編碼指南之類的指導方針，它促進了像c++這樣的復雜語言的安全使用。 動態計劃 AP支持應用程序的動態部署，動態地管理資源和通信，以減少軟件開發和集成的工作量，從而縮短迭代周期。在AP架構下，不同的應用可能由不同的供應商提供，因此在產品交付階段，AP允許系統集成商合理限制這種動態部署的特性以降低不必要的風險和影響。 敏捷 敏捷盡管沒有直接反映在平臺功能中，AP的目標是適應不同的產品開發過程，特別是基于敏捷的過程。對于基于敏捷的開發，至關重要的是系統的底層架構是可增量擴展的，在部署后可以更新系統。AP的體系結構應該允許這樣做。作為概念的證明，AP規范本身和演示者(AP的演示實現)都是用Scrum[^1]開發的。 [^1]: Scrum是迭代式增量軟件開發過程，通常用于敏捷軟件開發。Scrum包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。雖然Scrum是為管理軟件開發項目而開發的，它同樣可以用于運行軟件維護團隊，或者作為計劃管理方法：Scrum of Scrums. [1]

CP、AP和非AUTOSAR ECU的集成

綜合以上的介紹，AP不會替代CP或者非AUTOSAR的平臺。而是與這些平臺以及外部后端系統(如路邊基礎設施)交互，形成一個完整的系統(圖2-1不同平臺部署示例、圖2-2 AP與CP交互示例)。例如，CP已經包含了一些SOME/IP協議，AP也支持這些協議。

架構

我們將從邏輯視圖，物理視圖以及方法論三個方面了解自適應平臺的架構。

邏輯視圖

ARA 下圖表示AP的架構，其中Adaptive Application(自適應應用)運行在ARA(AUTOSAR自適應應用的運行環境)之上。ARA是應用程序（AP中稱為Adaptive Application）運行時的基礎環境，可以提供多種本地功能供應用程序調用，這些本地功能在AP中統稱為Function Clusters，其分為兩個部分：Foundation Function Clusters和Service Function Clusters。 ? 語言綁定，C++標準庫，以及POSIX接口 這些API的語言基于C++綁定的，C++標準庫也可以作為ARA的一部分使用。關于OS接口，只有POSIX標準的單進程概要文件(PSE51接口)作為ARA的一部分可用。選擇PSE51是為了為現有的POSIX應用程序提供可移植性，并實現應用程序之間的自由干擾。 C++標準庫包含許多基于POSIX的接口，也包括多線程接口。 應用啟動和關閉 由Execution Management(EM)管理應用的生命周期。應用程序的加載/啟動是通過使用EM的功能來管理的，它需要在系統集成時或運行時進行適當的配置才能啟動應用程序。下圖說明了不同類型的AP應用。 ? 應用交互 對于AAs之間的交互，PSE51沒有包含IPC (Inter-Process- Communication)，所以在AAs之間沒有直接的交互接口。通信管理(CM)是唯一的顯式接口。CM還為ECU內外部提供面向服務的通信。CM處理服務請求/響應的路由，而不管服務和客戶端應用程序的拓撲部署。 ? 非標準接口 AA和功能集群可以使用任何非標準接口，只要它們不與標準AP功能沖突，并且符合項目的安全性/安全性要求。除非它們是純粹的應用程序本地運行時庫，否則應該注意盡量減少這種使用，因為這將影響軟件對其他AP實現的可移植性。

物理視圖

OS，處理器，和線程 AP操作系統要提供多進程 POSIX OS的兼容性。每一個AA實現為一個獨立的進程。自適應平臺服務和非平臺服務也實現為進程。 進程可以是一個單線程或多線程進程。可以使用OS API根據進程所屬的邏輯層而有所不同。如果它們是運行在ARA之上的AAs，那么它們應該只使用PSE51。如果一個進程是功能集群之一，它可以自由使用任何可用的操作系統接口。 AA進程不能直接使用IPC，只能通過ARA進行通信。其他進程可以通過IPC或任何其他可用的OS功能相互交互。 基于庫或基于服務的功能集群的實現 在圖3-1 AP架構邏輯視圖中，功能集群可以是自適應平臺基礎模塊，也可以是自適應平臺服務。如前所述，這兩個過程通常都有。為了與同樣是進程的AAs進行交互，它們需要使用IPC。有兩種替代設計可以實現這一點。一種是基于庫的設計，由功能集群提供的接口庫鏈接到AA，直接調用IPC。另一種是基于服務的設計，流程使用通信管理功能，并有一個服務器代理庫鏈接到AA。代理庫調用通信管理接口，協調AA進程和Server進程之間的IPC。注意，它是由實現定義的，AA是否只直接執行IPC與通信管理或混合直接IPC與服務器通過代理庫。為功能集群選擇設計的一般原則是，如果它只在AP實例中本地使用，那么基于庫的設計更合適，因為它更簡單，也更高效。如果它以分布式方式從其他AP實例中使用，建議采用基于服務的設計，因為通信管理提供透明的通信，而不考慮客戶端AA和服務的位置。自適應平臺基礎的功能集群是基于庫的，自適應平臺服務的功能集群是基于服務的。最后，需要注意的是，一個功能集群的實現可以沒有進程，而是以庫的形式實現，在AA進程的上下文中運行，只要它滿足功能集群定義的需求規范和軟件規范。在這種情況下，AA和功能集群之間的交互將是常規的過程調用，而不是像前面描述的那樣基于IPC。 功能集群間的交互 通常，功能集群可以以AP實現的特定方式相互交互，因為它們沒有綁定到ARA接口，比如限制IPC使用的PSE51。它可能確實使用了其他功能集群的ARA接口，這些接口是公共接口。功能集群之間的一個典型交互模型是使用功能集群的受保護接口來提供實現功能集群的特殊功能所需的特權訪問。 機器/硬件 AP將其運行的硬件視為機器。背后的基本原理是，硬件可以使用各種與hypervisor相關的技術進行虛擬化，并實現一致的平臺視圖。在硬件上，可以有一個或多個機器，并且在一臺機器上只能運行一個AP實例。通常假定該硬件包括一個芯片，托管一個或多個機器。但是，如果AP實現允許的話，多個芯片也可以組成一個機器。

方法論和清單

為了支持功能應用程序的分布式、獨立和敏捷開發，需要在開發方法上采用標準化的方法。AUTOSAR自適應方法涉及到工作產品的標準化，用于描述工件(如服務、應用程序、機器及其配置);并在各自的任務中定義了這些工作產品應如何交互，以實現設計信息的交換，為自適應平臺的產品開發所需的各種活動。圖4.1說明了自適應AUTOSAR的開發工作流草案，其中涉及的步驟主要包含以下7步，最終將開發的軟件集成入車輛中。

E/E Architect Define Services

ECU(Machine) Architect/Platform Software Cluster Architect

Software Cluster Architect

Application Developer

Software Cluster Integrator

ECU(Machine) Integrator

Vehicle Integrator

相關概念介紹： Machine：在AP的概念體系中，Machine代表一種計算資源，它可以是真實存在的處理器，也可以是一個虛擬機，AP軟件則運行在某一個特定的Machine上。 Manifest：Manifest是一種AUTOSAR模型的描述文件，主要包含AP軟件部署涉及到的一些配置信息（比如Service Instance Manifest會包括服務接口的版本信息，SD參數信息等內容）

操作系統

概述

操作系統負責運行時的資源和時間管理。EM負責平臺初始化和應用的啟動和停止，與操作系統協同工作。 AP沒有為高性能的處理器指定操作系統。而是，其定義執行上下文和操作系統接口供AP應用使用。 OSI(操作系統接口)規范包含了ARA中部分應用接口以及AP應用的標準接口。OS本身可以很好地提供其他接口，例如創建進程，這是執行管理啟動應用程序所需要的。然而，提供此類功能的接口，以及其他接口，不能作為ARA的一部分使用，它被定義為依賴于平臺實現。 OSI同時提供C和c++接口。對于C程序，應用程序的主要源代碼業務邏輯包括在POSIX標準中定義的C函數調用，即在IEEE1003.13[1]中定義的PSE51。在編譯過程中，編譯器決定來自平臺操作系統的哪個C庫提供了這些C函數，應用程序的可執行文件應該在運行時被鏈接。對于c++程序，應用軟件組件的源代碼包括在c++標準及其標準c++庫中定義的函數調用。

POSIX

市場上有幾種操作系統，例如Linux，提供了POSIX兼容的接口。但是，與平臺服務和基礎相比，應用程序需要對操作系統使用更受限制的API。 一般的假設是，用戶應用程序應該使用PSE51作為操作系統接口，而平臺應用程序可以使用完整的POSIX。如果在應用程序級別需要更多的特性，它們將從POSIX標準中獲取，而不是在任何可能的地方新指定。 自適應平臺基礎和自適應平臺服務功能的實現可能會進一步使用POSIX調用。特定調用的使用將留給實現者，而不是標準化的。

調度

操作系統提供多線程和多進程的支持。標準的調度策略是SCHED_FIFO和SCHED_RR，由POSIX標準定義。其他如SCHED_DEADLINE或者任何其他操作系統規定的策略也被允許，但有一些限制，即這些策略可能不能跨不同的AP實現移植。

內存管理

支持多進程的原因之一是實現了不同功能集群和AA之間的自由干擾。操作系統對多進程的支持迫使每個進程處于一個獨立的地址空間中，與其他進程隔離和保護。同一個可執行文件的兩個實例在不同的地址空間中運行，這樣它們在啟動時可能共享相同的入口點地址和代碼以及數據值，但是數據將在內存中的不同物理頁中。

設備管理

設備管理將在POSIX的PSE51接口下提供。

執行管理

概述

EM負責系統執行管理的各個方面，包括系統初始化和應用的啟停。EM與操作系統協同工作執行應用的調度。

系統啟動

當機器啟動時，操作系統會被首先初始化然后EM作為操作系統一個初始進程被啟動。然后EM啟動自適應平臺基礎的其他功能集群和平臺級應用程序。自適應平臺基礎啟動并運行后，EM將繼續啟動自適應應用程序。平臺級應用程序和自適應應用程序的啟動順序由執行管理基于機器清單和應用程序清單信息決定。

EM的職責

EM負責AP平臺和應用執行管理的各個方面，包括 1、平臺生命周期管理 EM是自適應平臺啟動階段的一部分，負責自適應平臺和部署的應用程序的初始化 2、應用生命周期管理 EM負責已部署的應用程序的有序啟動和關閉。EM根據機器清單和應用程序清單中的信息確定已部署的應用程序集，并根據聲明的應用程序依賴項派生啟動/關閉順序。根據機器狀態和功能組狀態，部署的應用程序在自適應平臺啟動時或之后啟動，然而，并不期望所有的應用程序都立即開始活動工作，因為許多應用程序將向其他應用程序提供服務，從而等待和偵聽傳入的服務請求。 執行管理不負責應用程序的運行時調度，因為這是操作系統的責任。但是，執行管理負責操作系統的初始化/配置，使其能夠根據執行管理從機器清單和應用程序清單中提取的信息執行必要的運行時調度。

狀態管理

狀態管理提供了一種機制來定義自適應平臺的操作狀態。狀態管理定義了AUTOSAR自適應平臺的操作狀態，由EM執行不同狀態之間的轉移。 EM有四種不同的狀態：

Machine State 該狀態主要用控制機器生命周期(Startup/shutdown/restart)，平臺級的進程，和其他基礎設施。在每臺機器上都必須存在幾個強制性的機器狀態。其他特定于機器的機器狀態可以在機器清單中定義。

Function Group State 該狀態主要用于單獨啟動和停止功能一致的用戶級應用進程組。它們可以在機器清單中配置。

Process State 該狀態用于應用程序生命周期管理，并由執行管理內部狀態機實現。

Application State 該狀態描述了應用程序可執行程序的任何實例的內部生命周期，即進程。每個進程必須向執行管理報告應用程序狀態更改。

如下圖，顯示了在狀態管理請求了不同功能組狀態之后，不同類型狀態之間的交互的簡化示例。可以看到功能組的狀態轉移，以及引用此功能組的一個狀態的流程和執行狀態。

通訊管理

概述

通信管理實現了自適應AUTOSAR應用程序之間面向服務的通信，適用于所有級別的通信，如進程內、進程內、機器間。它由潛在生成的服務提供者骨架和服務請求者代理以及可選的用于中央代理和配置的通用通信管理器軟件組成。 通信管理提供了內置的安全機制，即E2E保護，其可以用于所有級別的對于事件和方法的通信。

面向通信的服務SOC

服務的概念意味著提供給應用程序的功能超出了基本操作軟件已經提供的功能。通信管理軟件提供了一些機制來提供或使用這些服務，用于機器內部通信和機器間通信。 一個服務包括：

Events

Methods

Fields

通信伙伴之間的通信路徑可以在設計時、啟動時或運行時建立。該機制的一個重要組件是充當代理實例的Service Registry，它也是Communication Management軟件的一部分。

? 每個提供服務的應用程序都在服務注冊中心注冊這些服務。要使用服務，消費應用程序需要通過查詢服務注冊表來查找所請求的服務，這個過程稱為服務發現。服務發現可以發現所有本地和遠程的服務實例。服務消費由Proxy（P1...P3）表示，應用可以選擇使用哪一個服務實例。 ?

語言綁定和網絡綁定

通信管理提供了標準化的方法，即如何將已定義的服務呈現給應用程序實現者(上層，語言綁定)，以及服務數據在網絡上的各自表示(下層，網絡綁定)。這確保了源代碼的可移植性和編譯服務在不同平臺實現之間的兼容性。 語言綁定定義了如何通過使用目標編程語言的方便特性將服務的方法、事件和字段轉換為直接可訪問的標識符。性能和類型安全(只要目標語言支持)是主要目標。因此，語言綁定通常是由由服務接口定義提供的源代碼生成器實現的。 ? 網絡綁定定義了如何將已配置服務的實際數據序列化并綁定到特定的網絡。它可以根據Communication Management配置(AUTOSAR元模型的接口定義)來實現，既可以解釋生成的特定于服務的配方，也可以直接生成序列化代碼本身。 ? 網絡綁定的三種方式： ?

SOME/IP網絡綁定

基于Signal的網絡綁定

DDS網絡綁定

本地服務注冊也是網絡綁定的一部分。 請注意:語言綁定和網絡綁定之間的接口被認為是通信管理軟件內部的私有接口。因此，定義該接口的規范目前已超出范圍。盡管如此，平臺供應商還是被鼓勵獨立地為他們的軟件定義這樣的接口，以方便實現其他語言綁定(而不是c++)以及平臺實現中的其他網絡綁定。

生成c++語言綁定的代理和框架

c++語言綁定的上層接口提供了在AUTOSAR元模型的接口描述中定義的服務的面向對象的映射。 作為Communication Management軟件開發工具的一部分，生成器生成c++類，這些類包含各個服務的字段、事件和方法的類型安全表示。 在服務實現端，這些生成的類被命名為服務提供者骨架。在客戶端，它們被稱為服務請求者代理。對于服務方法，服務請求者代理提供了同步(阻塞調用者直到服務器返回結果)和異步調用(被調用的函數立即返回)的機制。調用者可以同時啟動其他活動，當服務器的返回值通過c++標準模板庫(std::future)的特殊特性可用時，調用者可以接收結果。 可以對平臺實現進行配置，使生成器創建模擬類，以便在相應的服務器還不可用時輕松開發客戶端功能。同樣的機制也可以用于對客戶機進行單元測試。雖然代理類可以被客戶端直接使用，但c++綁定的服務提供者骨架只是抽象基類。 服務實現應該從生成的基類派生并實現相應的功能。ara::com的接口還可以為端到端安全通信提供代理和框架。 這些接口的設計保證了應用程序的兼容性，無論端到端加密保護是打開還是關閉。

靜態和動態的配置

通信路徑的配置可以在設計時、啟動時或運行時進行，因此被認為是靜態或動態的。 完全靜態配置:根本不需要服務發現，因為服務器知道所有的客戶端，而客戶端也知道服務器。 應用程序代碼沒有發現:客戶機知道服務器，但服務器不知道客戶機。事件訂閱是應用程序中唯一的動態通信模式。 應用程序中的完整服務發現:在配置時不知道任何通信路徑。服務發現的API允許應用程序代碼在運行時選擇服務實例。

RESTful通信

概述

通信棧ara::com和ara::rest都可以在AP應用之間建立通信路徑。ara::rest是一個構建RESTful API的框架，以及在RESTful API之上構建特定服務的框架。它沒有定義特定的開箱即用的API來直接構造RESTful服務。這個框架是模塊化的，它允許開發人員直接訪問RESTful消息事務中涉及的不同層。相反，ara::com的重點是提供一個傳統的函數調用接口，并隱藏超出這一點的事務的所有細節。另一個重要的區別是ara::rest確保了與非AUTOSAR對等點的互操作性。例如，一個ara::rest服務可以與一個移動HTTP/JSON客戶端通信，反之亦然。

What's the RESTful？ REST：Represetational State Transfer（表象層狀態轉移） 1.每一個URI代表一種資源；2.客戶端和服務器之間，傳遞這種資源的某種表現層；3.客戶端通過四個HTTP動詞（get、post、put、delete），對服務器端資源進行操作，實現”表現層狀態轉化”

架構

ara::rest的架構是基于模塊化設計的，它支持API級別以及服務級別的設計。下圖說明了它的總體設計。它描述了一個服務應用程序是如何在ara::rest中組成的。 ? ara::rest的通用REST層只提供了三個基本抽象:一個樹狀結構的消息有效負載(對象圖)、一個URI和一個請求方法(比如HTTP中的GET或POST)。從這些基本的原語，特定于領域的RESTful api可以被組合起來，通過對象圖、URI和方法定義一個具體的高層交互協議。它的目的是定義訪問特定領域數據模型的規則，并為應用程序提供一個抽象(c++) API。當不需要進一步的抽象時，自適應應用也可以直接使用ara::rest，而不是使用這個域API。 ?

組件

ara::reset包含以下組件的集合 ? Object Graph是一個獨立的協議綁定的樹形數據結構，其是所有ara::reset通信的基礎。它的目的是映射到協議格式，如JSON和C結構體。這最大限度地提高了與非ARA通信節點和經典AUTOSAR的兼容性。對象圖是以消息的形式傳輸的，這些消息完全從一個具體的底層協議綁定中抽象出來。如果需要，它們仍然允許用戶訪問特定于協議的詳細信息。 ? 在ara::reset的異步編程模式中，消息封裝了request/replay通信周期的整個上下文。 ? 路由概念提供了一種將請求(包括請求方法和URI)映射到用戶定義的處理程序函數的方法。路由是將抽象從通用REST提升到特定類型的RESTful API的基礎。 ? Uri是一種符合RFC的通用Uri表示，但它是一種高效的Uri表示。 ? ara::rest為服務器和客戶端通信提供了所謂的(網絡)端點，兩者都提供了相當程度的資源控制。兩者的設計都是為了在單核和多核系統上提供快速和高效的通信能力。 ? 整個框架設計嚴格地面向最大限度的資源控制。可以嚴格控制和定制所有計算和分配，以滿足應用程序(部署)的精確需求。 ?

診斷

診斷管理實現了ISO 14229-5(UDSonIP)，其主要基于ISO 14229-1(UDS)和ISO 13400-2(DoIP)。 診斷管理是使用ara::com的自適應平臺服務。因此，其是語言獨立的，所以可以使用其他語言，比如在以后可以使用JAVA。配置基于Class Platform的AUTOSAR Diagnostic Extract Template(DEXT)。DEXT目前已經得到很多OEMs和Vendor使用。 診斷管理使用的傳輸層是DoIP。未來的自適應平臺會支持其他的傳輸層比如CAN。也許還計劃支持定制的傳輸層，因為DoIP通常不用作車載協議。 此部分的范圍是去從自適應應用中抽象診斷協議。這些接口與經典平臺(例如SetEventStatus)協調一致，允許經典平臺開發者進行簡單的更改。

診斷功能子集

診斷功能的子集類似于CP平臺的DCM，實現了診斷的服務器。當前支持的服務是有限的，但是 UDS的服務會在以后進行擴展。 除了ISO 14229-1的偽并行客戶端處理之外，還擴展了診斷管理器(Diagnostic Manager, DM)，以支持對不同診斷客戶端的完全并行處理。這滿足了現代汽車架構的需求，包括多個診斷客戶端(測試器)用于數據采集、后端訪問、SOTA(軟件空中傳輸)，最后是經典的車間和生產用例。

事件記憶子集

事件記憶子集類似于CP平臺的DEM，負責DTC管理。 支持的功能和接口和CP平臺類似。監測的事件和一個DTC綁定。DTC可以分配為PrimaryMemory(通過19 02/04/06訪問)或者配置UserMemories(經過19 17/18/19訪問)。DTC可以存儲快照和擴展數據。 對老化和就緒計算有重要影響的操作周期變化需要轉發給DM。 同樣，存儲和啟用條件的變化需要轉發給DM，通過啟用條件可以控制dtc的一般更新。例如禁止在電壓低時禁止所有網絡的監控。根據存儲條件，DTC不能存儲在DTC Memory。

持久化管理

概述

持久化管理提供應用在NVM中存儲信息的機制。該數據可在啟動和點火循環使用。持久化通常被實現為一個庫，它運行在自適應應用程序的進程中，具有該進程的權限。 持久化管理庫將存儲位置標識符作為來自應用程序的參數，以尋址不同的存儲位置。 可用的存儲位置分為兩類：

Key-Value Storage

File-Proxy Storage

每個應用可以使用多個存儲類型的組合。 對于一個應用，存儲的數據總是私有的。使用存儲庫不能在不同應用間共享數據。這一決定是為了防止在communication Management提供的功能之下出現第二個通信路徑。 持久化管理對于存儲的數據提供加密方法，確保敏感數據在寫入物理設備之前進行加密。

Key-Value存儲

鍵值存儲提供了從一個存儲位置存儲和恢復數據的機制。支持的value類型是基礎類型，C++ Plain Code數據結構和從這些類型派生的數組/容器。 每個Key-Value數據庫的鍵必須是唯一的字符串，并且由應用程序使用存儲庫提供的方法定義。

File存儲

并不是所有持久存儲的數據類型都適合Key-Value機制，因此AP平臺還支持File存儲機制。 File存儲提供對一組文件的訪問，類似于文件系統的目錄。

健康管理

概述

健康管理為AP應用在車輛內外提供保護信息交互的機制。包括ECU內外的通信機制。出于此目的，提供的機制允許在發生任何損壞時進行錯誤檢測，沒有保護數據完整性的機制。健康監控是ISO26262(控制流程監控、外部監控設施、看門狗、邏輯監控、時間監控、程序順序監控)所要求的。 健康提供監控應用正確執行的機制。允許對檢測偏差定義處理。 另外，安全對編碼指引提供指導，有利于安全可靠的使用復雜的語言，比如C++。

信息交換的保護

最新的AUTOSAR E2E配置支持所有AUTOSAR AP和CP實例組合之間的安全通信，無論它們是在相同或不同的ecu中。在有用的情況下，將提供使用自適應平臺中面向服務的更多功能的機制，以允許安全通信。所提供的功能提供了驗證從發布者發送和由訂閱者接收的信息在傳輸期間沒有更改的可能性。根據AUTOSAR CP中的E2E機制，在E2E上下文中不提供傳輸確認和傳輸安全。 當在發布者和訂閱者之間的通信中使用端到端保護時，在發布者的進程中同步調用端到端保護。在訂閱者端，在接收訂閱者流程中的數據時調用被選中的端到端。

平臺健康管理

提供健康管理機制以支持fail-safe應用。包含如下方面

Alive supervision

Deadline supervision

Logical supervision

Error handing of supervision errors

Health Monitoring

C++編程指引

AUTOSAR C++ 14編碼指南文檔適用的主要應用領域是汽車，但它也可以用于其他在安全相關和關鍵環境中工作的嵌入式應用。AUTOSAR C++ 14編碼準則適用于在32位和64位微控制器上，使用POSIX或類似操作系統，提供高效和完整的c++ 14語言支持的高端嵌入式微控制器。 現有的標準是不完整的，包括舊的c++版本，或者不適用于關鍵/安全相關的。特別是，MISRA c++:2008不包括c++ 11/14。多個新的語言特性需要分析它們在提供有效實現方面的作用，以及使用每個特性會帶來多大的風險。

安全措施(Security)

概述

Security服務提供AP平臺增強系統的方法，比如安全通信和訪問管理系統。

身份和訪問管理

我們建議AUTOSAR自適應平臺采用身份和訪問管理框架，以支持對各個AUTOSAR組件(自適應AUTOSAR應用程序、服務和功能集群)進行身份驗證，并引入角色和權限管理功能的概念。使用IAM框架，這些應用程序可以查詢基于現有策略的訪問控制決策。查詢將通過功能集群處理，因為應用程序沒有與IAM框架的直接接口。在使用請求時，服務將能夠利用指定的框架來評估請求者的權限和權利，并相應地實施相應的策略。 這個框架背后的思想是由日益增長的安全需求驅動的，因為AUTOSAR自適應平臺需要與它的應用程序建立一個健壯的、定義良好的信任關系。如果攻擊者破壞了應用程序，它不應該對自適應平臺本身有任何影響，攻擊者的能力應該被限制在被破壞的應用程序的能力。這就是為什么應用程序應該只能訪問系統資源或觸發它們應該執行的操作。IAM框架管理身份和訪問權限，可以被視為一種可理解的機制，將應用程序的訪問限制在必要的最低限度。

Crypto和Key管理

AUTOSAR自適應平臺支持用于通用密碼操作和安全密鑰管理的API。該API支持在運行時動態生成密鑰和加密作業，以及對數據流進行操作。為了減少存儲需求，密鑰可以存儲在加密后端內部，也可以存儲在外部，并根據需要導入。 該API旨在支持在單獨的組件(如硬件安全模塊(HSM))中封裝安全敏感的操作和決策。通過將密鑰限制到特定的使用(例如，僅解密)，或根據IAM的報告，將密鑰的可用性限制到單個應用程序，可以提供對密鑰和密鑰使用的額外保護。 根據應用程序支持的不同，API還可以用于在處理TLS和SecOC等加密協議時保護會話密鑰和中間秘密。

安全架構

Key管理

更新和配置管理

概述

AP平臺提供一個很重要的能力是通過OTA(over-the-air)升級軟件和配置。為此，AP平臺提供Update and Configuration Manager(UCM)服務處理軟件升級請求。 UCM負責升級，安裝，卸載和記錄AP平臺的軟件。它的角色類似于已知的包管理系統，如Linux中的dpkg或YUM，具有額外的功能，以確保以一種安全的方式更新或修改Adaptive Platform上的軟件。

軟件包處理

除了應用程序和配置數據，每個軟件包都包含一個清單，提供元數據，如包名、版本和處理包所需的其他元信息。 軟件包的數據內容可以包含一個或多個自適應應用程序，內核或固件更新，或更新的配置和校準數據。 UCM基于提供的元數據和Adaptive Platform軟件信息處理軟件包。

軟件信息報告

UCM提供了服務接口，該接口公開了檢索Adaptive Platform軟件信息的功能，例如已安裝軟件的名稱和版本。

軟件更新的一致性

UCM確保只安裝具有所有描述的依賴項的驗證包。這樣就不會安裝不需要的或不合適的軟件。UCM提供了一個讀取安裝結果的界面。如果在更新過程中出現故障，UCM將平臺恢復到一個已知的功能狀態。可恢復故障的一個例子是由于功率損失而中斷的更新過程。

時間同步

概述

當需要跨分布式系統的不同事件的相關性時，不同應用程序和/或ECU之間的時間同步(Time Synchronization)是至關重要的，無論是為了能夠及時跟蹤這些事件，還是為了在準確的時間點觸發它們。 ? 由于這個原因，一個時間同步API被提供給應用程序，所以它可以檢索與其他實體/ECU同步的時間信息。 ? 時間同步功能是通過系統中不同的“時間基礎資源”來提供的。 ?

設計

對于AP平臺，下面3種不同的技術應用滿足時間同步的需要

CP平臺的StbM模塊

chrono庫 - std::chrono (c++ 11)或boost::chrono

POSIX Time 接口

時間同步模塊提供類似于CP平臺StbM的功能，但帶有一個std::chrono啟發的API設計。 時間同步模塊會考慮以下幾個方面

Startup Behavior

Constructor Behavior(初始化)

Normal Operation

Error Handing

未來會考慮以下幾個方面

Shutdown Behavior

Error Classification

Version Check

架構

應用程序將能夠訪問每個時間基礎資源(Time Base Resource)的不同專門化類實現。TBR以資源的形式提供，就像在ara::com設計中提供服務一樣，因此它采用了以下ara::com的架構設計模式 代理:類似于ara::com服務代理骨架模式，TS提供了一個資源代理模式，省略了骨架部分。 查找:類似于ara::com服務代理查找模式，TS提供了一個資源代理查找模式來提供對tbr的訪問。 代理方法:類似于ara::com代理方法模式，TS使用的方法模式也遵循異步的Future模式。 當談到避免延遲時，這種架構設計顯然將時間同步設計置于正面沖突之中，因為后者是由ara::com API的設計模式的異步行為固有地添加進來的。

AUTOSAR利弊

隨著AUTOSAR組織的日益擴大和越來越多的汽車行業開始使用AUTOSAR架構，我們有必要思考相比以往的軟件開發，使用AUTOSAR架構有哪些利弊。 利弊在某種條件下是相互轉換的，有利就有弊。目前AUTOSAR還是由外國幾個公司主導，占據市場主要的幾家AUTOSAR服務（軟件以及工具）提供商有VECTOR、EB、ETAS、MENTOL,國內有普華基礎軟件，經緯恒潤，東軟睿馳，和華為等幾家，但是市場占有率還是非常低。

AUTOSAR優勢

標準化，大家在同一個起點開始競爭

縮短開發以及測試周期，快速適配不同車型和項目

縮減開發人員，降低測試要求

開發人員熟悉工具和簡單理論即可開發，門檻低

AUTOSAR弊端

軟件架構費用昂貴

代碼邏輯復雜，選項眾多，對于存儲資源占用大

軟件開發容易成為工具人，成就不高

總結

AUTOSAR Adaptive還在逐步完善豐富，除了以上介紹的功能，最新的AP還擴展了Automated Driving Sensor Interfaces(自動駕駛傳感器接口)、Intrusion Detection System Manager(入侵檢測系統管理)等功能。隨著AUTOSAR Adaptive的完善，其帶給汽車系統諸多好處，比如提高所有制造商的開發效率，提高開發速度，縮短車輛子系統間接口的開發時間以及通過標準化提升功能安全，全球所有制造商都使用用一個平臺，這樣可以縮短系統與其他車輛的集成時間，提高系統之間的兼容性以及提升信息安全。

審核編輯：彭靜