Hello！大家好！
本篇是AP AUTOSAR平臺設計(2)——架構
AP和CP相關資料獲取和工具諮詢、更多精彩內容歡迎訂閱微信公衆號“搞一下汽車電子”
整理不易，如果覺得不錯，點贊分享支持一下吧~
微信：shactiontech
1.邏輯視圖
① ARA
圖1表示的是AP的體系結構。從圖中可以看出以下幾點：
1. 自適應應用程序（AA）在自適應應用程序的AUTOSAR運行時（ARA）之上運行。
2. ARA由功能羣集提供的應用程序接口組成，這些羣集屬於Adaptive Platform Foundation或Adaptive Platform Services。Adaptive Platform Foundation提供AP的基本功能，而Adaptive Platform Services提供AP的平臺標準服務。
3. 任何AA也可以向其他AA提供服務，在圖中以非平臺服務形式說明。
從AA的角度來看，功能集羣的接口（無論是Adaptive Platform Foundation的接口還是Adaptive Platform Services的接口）都無所謂——它們僅提供指定的C ++接口或AP將來可能支持的任何其他語言的接口。
另外，請注意，在ARA接口下，包括在AA上下文中調用的ARA庫，可以使用ARA以外的其他接口來實現AP規範，這取決於AP實現的設計。
② 語言綁定，C++標準庫和POSIX API
這些API是基於C ++，並且C ++標準庫也作爲ARA的一部分提供。
關於OS API，AA只可使用PSE51接口
建議不要將C ++標準庫線程接口與本機PSE51線程接口混合使用，以避免複雜化。
但是，C ++標準庫沒有涵蓋所有PSE51功能，例如設置線程調度策略。在這種情況下，可能需要同時使用兩個接口。
③ 應用程序啓動和關閉
應用程序的生命週期由執行管理（EM）管理。
應用程序的加載/啓動是通過使用EM的功能進行管理的，並且需要在系統集成時或運行時進行適當的配置才能啓動應用程序。
實際上，從EM的角度來看，所有功能集羣都是應用程序，除了EM本身以外，它們也以相同的方式啓動。圖2應用程序說明了AP內部和AP上不同類型的應用程序。
EM不會決定應用程序的啓動時間和終止時間。
應用程序的啓動時間和終止時間是狀態管理（SM）控制的，SM是一種特殊的FC，它根據系統的設計命令EM，仲裁不同的狀態，從而控制整個系統的行爲。
SM還與其他FC交互以協調整體機器行爲。SM應該僅使用標準ARA接口來維護不同AP堆棧實現之間的可移植性。
④ 應用程序交互
AA之間沒有直接進行交互的接口，不能通過IPC（進程間通）進行直接交互。
AA之間要想交互需要通過通信管理（CM）
AA可以直接調用POSIX OS的PSE51接口，但是不能調用POSIX OS的非PSE51接口
CM還爲Machine內和Machine間提供面向服務的通信
注意：其他ARA接口可能在內部觸發AA之間的交互，但是，這不是顯式的通信接口，而只是相應ARA接口提供的功能的副產品
⑤ 非標準接口
AA和功能集羣可以使用任何非標準接口，只要它們不與標準AP功能衝突，並且它們符合項目的安全性要求即可。
除非它們是純的應用程序本地運行時庫，否則應注意使此類使用最少，因爲這將影響軟件在其他AP實現上的可移植性。
2.物理視圖
在此討論AP的物理體系結構。
注意：本節中的大多數內容僅用於說明目的，並且不構成AP的正式要求規範。
① 操作系統，進程和線程
每個AA被實現爲一個獨立的進程，具有自己的邏輯內存空間和名稱空間。
請注意，單個AA可以包含多個進程，並且可以將其部署到單個AP Instance上或分佈在多個AP Instance上。
每個進程都由OS從可執行文件實例化。可以從單個可執行文件實例化多個進程。同樣，AA可以構成多個可執行文件。
功能集羣通常也被實現爲進程。功能集羣也可以用單個過程或多個（子）過程來實現。自適應平臺服務和非平臺服務也被實現爲進程。
所有這些進程可以是單線程進程或多線程進程。但是，根據進程所屬的邏輯層，它們可以使用的OS API有所不同。如果它們是運行在ARA之上的AA，則它們只能使用PSE51。
如果該進程是功能集羣之一，則可以自由使用任何可用的OS接口。
綜上所述，從操作系統的角度來看，AP和AA只是形成一組進程，每個進程包含一個或多個線程——這些進程之間沒有區別。這些進程確實通過IPC或任何其他可用的OS功能相互交互。請注意，AA進程可能不會直接使用IPC，而只能通過ARA進行通信。
② 基於庫或基於服務的功能集羣實施
如圖1 AP體系結構邏輯視圖中所示，功能集羣可以是Adaptive Platform Foundation模塊或Adaptive Platform Service。如前所述，這些通常都是進程。爲了使它們與AA（也是進程）交互，它們需要使用IPC。有兩種替代設計可以實現此目的。
一種是“基於庫”的設計，其中由功能集羣提供並鏈接到AA的接口庫直接調用IPC。
另一個是“基於服務”的設計，該進程使用通信管理功能，並且具有鏈接到AA的Server Proxy庫。Proxy庫調用通信管理接口，該接口在AA進程和服務器進程之間協調IPC。請注意，AA是僅通過通訊管理直接執行IPC，還是通過Proxy庫與Server 直接IPC混合，由實施定義。
選擇功能性集羣設計的一般指導原則是，如果僅在AP實例中本地使用它，則基於庫的設計會更合適，因爲它更簡單且效率更高。
如果以分佈式方式從其他AP實例中使用它，則建議採用基於服務的設計，因爲無論客戶端AA和服務的位置如何，通信管理都將提供透明的通信。顧名思義，屬於Adaptive Platform Foundation的功能集羣是“基於庫的”，而Adaptive Platform Services是“基於服務的”。
注意：允許FC的實現以庫的形式實現，即：AA和FC之間的交互將是常規進程調用，而不是如前所述基於IPC。
③ 功能集羣之間的交互
功能集羣之間的一種典型交互模型是使用功能集羣的受保護接口來提供實現功能集羣的特殊功能所需的特權訪問。
從AP18-03開始，引入了功能間羣集（IFC）接口的新概念。它描述了FC提供給其他FC的接口。注意，它不是ARA的一部分，也不構成AP實施的正式規範要求。這些接口在相應的FC SWS的附件中進行了描述。
④ 機器/硬件
AP將運行在其上的硬件視爲一臺Machine。其背後的原理是獲得一致的平臺視圖，而不考慮可能使用的任何虛擬化技術。該Machine可能是一臺真正的物理Machine，一臺全虛擬化的Machine，一臺半虛擬化的OS，一個OS級虛擬化的容器或任何其他虛擬化環境。
在硬件上，可以有一個或多個Machine，並且在一臺Machine上僅運行一個AP實例。通常認爲，該“硬件”包含一個芯片，可容納一臺或多臺Machine。但是，如果AP允許的話，也有可能多個芯片組成一臺Machine。
3.方法論和Manifest
對功能應用程序的分佈式，獨立和敏捷開發的支持需要一種標準化的開發方法。
AUTOSAR自適應方法論涉及工作產品的標準化，用於描述諸如服務，應用程序，Machine及其配置之類的工件。以及定義這些工作產品應如何交互以實現針對自適應平臺產品開發所需的各種活動的設計信息交換的相應任務。
圖3給出瞭如何實施自適應方法的概述草案。
4.Manifest
Manifest代表一段AUTOSAR模型描述，該描述是爲了支持AUTOSAR AP產品的配置而創建的，並且會上載到AUTOSAR AP產品中，並可能與其他包含Manifest文件的可執行代碼的工件（如二進制文件）結合使用。
Manifest的使用僅限於AUTOSAR AP。但是，並不是說在針對AUTOSAR AP的開發項目中生成的所有ARXML都會自動被視爲清單。
一輛典型的汽車很可能還配備了許多在AUTOSAR CP上開發的ECU，因此，整個汽車的系統設計必須同時涵蓋兩個方面——在AUTOSAR CP上構建的ECU和在AUTOSAR AP上創建的ECU。
在應用程序設計時，有必要將術語Manifest的定義細分爲三個不同的分區：
應用設計 這種描述指定了所有與設計相關的方面，這些方面適用於爲AUTOSAR AP創建應用程序軟件。不一定需要將其部署到自適應平臺Machine，但是應用程序設計有助於在執行Manifest和服務 Instance Manifest中定義應用程序軟件的部署。
執行Manifest 這種Manifest用於指定在AUTOSAR AP上運行的應用程序的與部署相關的信息。執行Manifest與實際的可執行代碼捆綁在一起，以支持將可執行代碼集成到計算機上。
服務Instance Manifest 此類Manifest用於根據基礎傳輸協議的要求指定如何配置面向服務的通信。服務Instance Manifes與實際的可執行代碼捆綁在一起，該可執行代碼實現了面向服務的通信的相應用法。
Machine Manifest 這種Manifest應該描述與部署相關的內容，這些內容僅適用於運行AUTOSAR AP的基礎計算機（即，該計算機上沒有運行任何應用程序）的配置。Machine Manifest與用於建立AUTOSAR AP實例的軟件捆綁在一起。
不同種類的Manifest的定義（和用法）之間的時間劃分得出這樣的結論：在大多數情況下，將使用不同的物理文件來存儲這三種Manifest的內容。
除了應用程序設計和不同種類的Manifest外，AUTOSAR方法論還支持系統設計，它有可能在一個單一模型中描述將在系統中使用的兩個AUTOSAR平臺的軟件組件。
不同的AUTOSAR平臺的軟件組件可以以面向服務的方式相互通信。但是也有可能描述信號到服務的映射，以在面向服務的通信與基於信號的通信之間建立橋樑。
5.應用設計
應用程序設計描述了所有與設計相關的建模，這些建模適用於爲AUTOSAR AP創建應用程序軟件。應用程序設計側重於以下方面：
1) 用於對軟件設計和實現的信息進行分類的數據類型
2) Service Interface是面向服務的通信的關鍵要素
3) 定義應用程序如何訪問面向服務的通信
4) Persistency接口是訪問持久性數據和文件的關鍵要素
5) 定義應用程序如何訪問持久性存儲
6) 定義應用程序如何訪問文件
7) 定義應用程序如何訪問加密軟件
8) 定義應用程序如何訪問平臺運行狀況管理
9) 定義應用程序如何訪問Time Base
10) 序列化屬性，用於定義如何序列化數據以在網絡上傳輸的特徵
11) REST Service Interface是通過REST模式與Web服務進行通信的關鍵要素
12) Client 和Server 功能的描述
13) 對應用程序進行分組，以簡化軟件的部署。
在應用程序設計中定義的工件獨立於應用程序軟件的特定部署，因此可以簡化針對不同部署場景的應用程序實現的重用。
6.執行Manifest
執行Manifest的目的是提供將應用程序實際部署到AUTOSAR AP所需的信息。
總體思路是保持應用程序軟件代碼與部署方案儘可能獨立，以增加應用程序軟件可以在不同部署方案中重用的機率。
通過執行Manifest，可以控制應用程序的實例化，因此可以：
1) 在同一臺計算機上多次實例化同一應用程序軟件，或者
2) 將應用程序軟件部署到多臺計算機上，並在每臺計算機上實例化應用程序軟件。
執行Manifest集中於以下方面：
1) 啓動配置，定義應如何啓動應用程序實例。啓動包括啓動選項和訪問角色的定義。每次啓動可能取決於Machine狀態和/或Function Groups狀態。
2) 資源管理，尤其是資源組分配。
7.服務Instance Manifest
在網絡上實現面向服務的通信需要特定於所使用的通信技術（例如SOME / IP）的配置。由於通信基礎結構在服務的提供者和請求者上的行爲相同，因此服務的實現必須在雙方上都兼容。
服務Instance Manifest集中於以下方面：
1) Service Interface部署，用於定義如何在特定的通信技術上表示服務。
2) Service Instance 部署，以爲特定的提供和所需的服務實例定義通信技術所需的憑據。
3) E2E保護的配置
4) Safety保護的配置
5) 日誌和跟蹤的配置
8.Machine Manifest
Machine Manifest允許配置運行在特定硬件（機器）上的實際自適應平臺實例。
Machine Manifest 集中於以下方面：
1) 配置網絡連接並定義網絡技術的基本憑據（例如，對於以太網，這涉及設置靜態IP地址或定義DHCP）。
2) Service Discovery技術的配置（例如，對於SOME / IP，這涉及要使用的IP端口和IP多播地址的定義）。
3) 使用的Machine狀態的定義
4) 使用的Function Group的定義
5) 自適應平臺功能集羣實現的配置（例如，操作系統提供具有特定權限的OS用戶列表）。
6) 加密平臺模塊的配置
7) 平臺健康管理的配置
8) 時間同步的配置
9) 可用硬件資源的文檔（例如，可用的RAM數量；可用的處理器核數量）