AUTOSAR_EXP_PlatformDesign[R19.03] - 03.Architecture
【version:R19.03，translated by sky8336, 2019.06.04, Shanghai】
3 Architecture
3.1 Logical view
ARA
---------
Note1：
AA: Adaptive Applications
ARA: AUTOSAR Runtime for Adaptive applications
自適應平臺基礎：Adaptive Platform Foundation
自適應平臺服務：Adaptive Platform Services
功能集羣：Functional Clusters
非平臺服務: Non-platform service（Non-PF Service）
----------
AA 運行在 ARA 的上層。
ARA 由功能集羣提供的應用接口組成。這些功能集羣接口屬於自適應平臺基礎或自適應平臺服務。
自適應平臺基礎提供AP的基本功能，自適應平臺服務提供AP的平臺標準服務。
任何AA也可以向其他AA提供服務，如圖所示非平臺服務。
從AA的角度來看，功能集羣的接口，無論是屬於自適應平臺基礎，還是自適應平臺服務，都是無關緊要的，它們只是提供了特定的c++接口，或者AP將來可能支持的任何其他語言綁定。
語言綁定、c++標準庫和POSIX API
這些API的語言綁定基於c++， c++標準庫也是ARA的一部分。
對於 OS API，只有PSE51接口，POSIX標準的單進程概要文件 是可以作爲ARA的一部分。
PSE51 已經被用於爲現有的POSIX應用程序提供可移植性，並實現應用程序之間的干擾自由。
c++標準庫包含許多基於POSIX的接口，包括多線程api。建議不要將c++標準庫線程接口與本地PSE51線程接口混合使用，以避免出現複雜的情況。不幸的是，c++標準庫沒有涵蓋PSE51的所有功能，比如設置線程調度策略。在這種情況下，可能需要同時使用這兩種接口。
Application launch and shutdown
-------
note:
Execution Management (EM): 執行管理
--------
應用程序的生命週期由執行管理(EM)管理。
應用程序的加載/啓動是通過使用EM的功能來管理的，它需要在系統集成時或運行時進行適當的配置才能啓動應用程序。
事實上，從EM的角度來看，所有的功能集羣都是應用程序，它們也是以相同的方式啓動的，除了EM本身。
圖3-2應用程序演示了AP內部和AP上的不同類型的應用程序。
EM不會決定應用程序何時啓動或何時終止。
一種稱爲狀態管理(SM)的特殊FC是控制器，它根據系統的設計來指揮EM，仲裁不同的狀態，從而控制整個系統
的行爲。由於這裏的系統是指整個機器AP及其應用程序，因此內部行爲是特定於項目的實現。SM還與其他FCs
交互以協調整個機器行爲。SM應該只使用標準的ARA接口來維護不同AP棧實現之間的可移植性。
Application interactions
在AAs之間的交互方面，PSE51不包含IPC(進程間通信)，所以AAs之間沒有直接的交互接口。
通信管理(CM)是唯一的顯式接口。CM還提供了面向服務的機器內部和機器之間的通信，對應用程序是透明的。
不考慮服務和客戶機應用程序的拓撲部署。注意，其他ARA接口可能會在內部觸發AAs之間的交互，但是，這不是一個顯式的通信接口，而是各個ARA接口提供的功能的副產品。
Non-standard interfaces
AA和功能集羣可以使用任何非標準接口，前提是它們不與標準AP功能衝突，並且它們符合項目的safety/security
需求。
3.2 Physical view
這裏討論AP的物理體系結構[1]。請注意，本節中的大部分內容僅用於演示，並不構成AP的正式需求規範，因爲
AP的內部是由實現定義的。對AP實現的任何正式需求都被顯式地聲明。
--------
note:
[1] 這裏的“物理體系結構”主要指流程視圖、物理視圖以及其他一些開發視圖，如[6]中所述
-------
OS, processes, and threads
AP操作系統需要提供多進程POSIX OS功能。每個AA都實現爲一個獨立的進程，具有自己的邏輯內存空間和名
稱空間。請注意，單個AA可能包含多個進程，並且可以將其部署到單個AP實例或分佈在多個AP實例上。從模塊
組織的角度來看，每個進程都由來自可執行文件的OS實例化。多個進程可以從一個可執行文件實例化。此外，
AA可以構成多個可執行程序。
功能集羣通常也作爲進程實現。一個功能集羣也可以通過單個進程或多個(子)進程來實現。自適應平臺服務和非
平臺服務也作爲進程實現。
所有這些進程都可以是單線程進程或多線程進程。但是，它們可以使用的OS API不同，這取決於進程屬於哪個
邏輯層。如果他們是運行在ARA之上的AAs，那麼他們應該只使用PSE51。如果進程是功能集羣之一，則可以自
由使用任何可用的OS接口。
總之，從操作系統的角度來看，AP和AA只是形成了一組進程，每個進程都包含一個或多個線程——這些進程之
間沒有區別，儘管AP的實現可以提供任何類型的分區。這些進程通過IPC或任何其他可用的操作系統功能相互交
互。注意，AA進程不能直接使用IPC，只能通過ARA進行通信。
Library-based or Service based Functional Cluster implementation
如圖3-1 AP體系結構邏輯視圖所示，一個功能集羣可以是自適應平臺基礎模塊或自適應平臺服務。如前所述，他
們一般都是進程。爲了讓它們與AAs(也是進程)交互，它們需要使用IPC。有兩種可選的設計來實現這一點。一種
是“基於庫”的設計，這種設計中，由功能集羣提供並鏈接到AA的接口庫直接調用IPC。另一種是“基於服務”的設
計，進程使用通信管理功能，並有一個連接到AA的服務器代理庫。
代理庫調用通信管理接口，用於協調AA進程和服務器進程之間的IPC。注意，它是實現定義的，AA是否只通過
通信管理直接執行IPC，還是通過代理庫與服務器混合使用直接IPC。
爲Functional Cluster選擇設計的一般原則是，如果只在本地的AP實例中使用它，那麼基於庫的設計更合適，因
爲它更簡單，也更高效。如果以分佈式方式從其他AP實例使用它，建議使用基於服務的設計作爲通信，無論客
戶端AA和服務位於何處，管理都提供透明的通信。正如名稱所正確指出的那樣，屬於自適應平臺基礎的功能集
羣是“基於庫的”，屬於自適應平臺服務的集羣是“基於服務的”。
最後，請注意，FC的實現允許沒有進程，而是以庫的形式實現，在AA進程上下文中運行，只要它滿足FC定義的
RS和SWS。在這種情況下，一個 AA和FC的交互將是常規的程序調用，而不是前面描述的基於IPC的調用。
The interaction between Functional Clusters
通常，功能集羣可以以AP特定於實現的方式相互交互，因爲它們不綁定到ARA接口，例如PSE51，這限制了IPC
的使用。它確實可以使用其他功能集羣的ARA接口，即公共接口。功能集羣之間的一個典型交互模型是使用功能
集羣的受保護接口，提供所需的特權訪問，以實現功能集羣的特殊功能。
同時，從AP18-03開始，引入了一個新的功能間集羣(IFC)接口的概念。它描述了FC提供給其他FC的接口。注
意，它不是ARA的一部分，也不構成AP實現的正式規範需求。提供這些功能是爲了通過澄清FCs之間的交互來
促進AP規範的開發，它們還可能爲AP規範的用戶提供更好的AP體系結構視圖。這些接口在各自的FC SWS的附
件中進行了描述。
Machine/hardware
AP將其運行的硬件視爲一臺機器。其背後的原理是實現一致的平臺視圖，而不管可能使用的虛擬化技術。這臺
機器可能是一臺真正的物理機器、一臺完全虛擬化的機器、一個準虛擬化的OS、一個OS級虛擬化的容器或任何
其他虛擬化的環境。
在硬件上，可以有一臺或多臺機器，並且一臺機器上只能運行一個AP實例。一般認爲，這種“硬件”包括一個芯
片，承載一臺或多臺機器。但是，如果AP實現允許，也有可能由多個芯片組成一臺機器。
3.3 Methodology and Manifest
對功能應用程序的分佈式、獨立和敏捷開發的支持需要一種標準化的開發方法。AUTOSAR自適應方法涉及工作
產品的標準化，用於描述服務、應用程序、機器及其配置等構件;對功能應用程序的分佈式、獨立和敏捷開發的
支持需要一種標準化的開發方法。AUTOSAR自適應方法涉及工作產品的標準化，用於描述服務、應用程序、機
器及其配置等構件;以及定義這些工作產品應如何交互以實現爲自適應平臺開發產品所需的各種活動交換設計信
息的各自任務。
圖3-3說明了如何實現自適應方法的概述草案。有關這些步驟的詳細信息，請參見[3]。
3.4 Manifest
清單表示爲支持AUTOSAR AP產品的配置而創建的AUTOSAR模型描述的一部分，並將其上載到AUTOSAR AP
產品，可能與清單應用於的包含可執行代碼的其他構件(如二進制文件)結合使用。
清單的使用僅限於AUTOSAR AP。但是，這並不意味着所有針對AUTOSAR AP 的開發項目產生的ARXML 被自
動認爲是一個清單。
事實上，AUTOSAR AP通常並不只用於車輛項目中。
一個典型的車輛很可能還配備了一些基於AUTOSAR CP開發的的ecu，因此整個車輛的系統設計必須涵蓋兩者
——在AUTOSAR CP上夠條件的ECU和 在AUTOSAR 上創建的ECU。
原則上，術語“清單”可以定義爲在概念上只有一個“清單”，並且每個部署方面都將在此上下文中處理。這似乎並不
合適，因爲很明顯，與清單相關的模型元素存在於一個典型開發項目的完全不同的階段中。
這方面是主要的動機，在應用程序設計之後，有必要將術語Manifest的定義細分爲三個不同的分區:
應用程序設計(Application Design)： 這類描述指定設計相關的所有方面,它們適用於AUTOSAR AP 應用軟件的
創建。它
並不一定需要部署到自適應平臺機器,但是應用程序設計幫助在執行清單和服務實例清單中進行應用軟件的部署
定義。
執行清單(Execution manifest): 這種清單用於指定運行在AUTOSAR AP上的應用程序的部署相關信息。
執行清單與實際的可執行代碼捆綁在一起，以支持將可執行代碼集成到機器上。
服務實例清單(Service Instance Manifest): 這種清單用於指定如何根據底層傳輸協議的需求配置面向服務的通
信。
服務實例清單與實際的可執行代碼綁定在一起，這些代碼實現了各自的面向服務通信用法。
機器清單(Machine Manifest): 這種清單應該描述與部署相關的內容，這些內容只應用於運行AUTOSAR AP的底
層機器的配置(即沒有任何應用程序在機器上運行)。機器清單與用於建立AUTOSAR AP實例的軟件捆綁在一起
不同類型清單的定義(和使用)之間的暫時劃分導致這樣的結論，在大多數情況下，將使用不同的物理文件存儲這
三種清單的內容。
除了應用程序的設計和不同種類的清單，AUTOSAR方法支持一種系統設計(System Design)，他能描述兩個
AUTOSAR平臺的軟件組件，它們將在一個單一模型的單個系統中使用。不同AUTOSAR平臺的軟件組件可以以
面向服務的方式彼此通信。但是也可以描述信號到服務的映射，從而在面向服務的通信和基於信號的通信之間建
立橋樑。
3.5 Application Design
應用程序設計描述了所有與設計相關的建模，這些建模應用於AUTOSAR AP應用程序軟件的創建。
應用程序設計主要關注以下幾個方面:
- 用於對軟件設計和實現的信息進行分類的數據類型(data types)
- 作爲面向服務通信的關鍵元素的服務接口(Service interfaces)
- 應用程序如何訪問面向服務通信的定義(definition)
- 作爲訪問persistent 數據 和文件的關鍵元素的persistency 接口(persistency interfaces)
- 應用程序如何訪問persistent 存儲的定義(definition)
- 應用程序如何訪問文件的定義(definition)
- 應用程序如何訪問加密軟件的定義(definition)
- 應用程序如何訪問平臺健康管理的定義(definiton)
- 應用程序如何訪問時間基準的定義(definition)
- 序列化屬性(serialization properties)，用於定義如何序列化網絡上傳輸的數據的特徵
- 作爲通過REST模式與web服務通信的關鍵元素的REST 服務接口(REST service interfaces)
- 客戶端和服務器功能的描述（description）
- 對應用程序進行分組，以簡化軟件的部署。
應用程序設計中定義的構件獨立於應用程序軟件的特定部署，因此可以簡化在不同的部署場景中重用應用程序的
實現。
3.6 Execution manifest
執行清單的目的是提供將應用程序實際部署到AUTOSAR AP所需的信息。
通常的想法是，使應用程序軟件代碼儘可能獨立於部署場景，以增加應用程序軟件在不同部署場景中重用的可能
性。
通過執行清單，可以控制應用程序的實例化，因此有可能這樣做
- 在同一臺計算機上多次實例化相同的應用程序軟件
- 將應用程序軟件部署到多臺機器上，併爲每臺機器實例化應用程序軟件。
執行清單主要關注以下幾個方面:
- 啓動配置，以定義如何啓動應用程序實例。啓動包括啓動選項和訪問角色的定義。
每個啓動可能依賴於機器狀態和/或函數組狀態。
- 資源管理，特別是資源組分配。
3.7 Service Instance Manifest
在網絡上實現面向服務的通信需要特定於所使用的通信技術的配置(例如，SOME/ IP)。由於通信基礎設施在服務
的提供者和請求者上的行爲應該相同，因此服務的實現必須在雙方都兼容。
服務實例清單主要關注以下方面:
- 服務接口部署(service interface deployment)，定義如何在特定的通信技術上表示服務。
- 服務實例部署，爲特定的已提供和所需的服務實例定義通信技術所需的憑據。
- 配置E2E保護
- 配置安全保護
- 日誌和跟蹤的配置
3.8 Machine Manifest
- 機器清單允許配置運行在特定硬件(機器)上的實際自適應平臺實例。
- 機器清單主要關注以下幾個方面:
- 配置網絡連接併爲網絡技術定義基本憑證(例如，對於以太網，這涉及設置靜態IP地址或定義DHCP)。
- 服務發現技術(service discovery technology)的配置(例如，對於SOME/IP，這涉及到要使用的IP端口和IP組播地址的定義)。
- 使用的機器狀態的定義
- 使用的功能組的定義
- 自適應平臺功能集羣實現的配置(例如，操作系統提供具有特定權限的OS用戶列表)。
- 密碼平臺模塊的配置
- 平臺健康管理配置
- 時間同步的配置
- 可用硬件資源的文檔(例如可用內存大小;有多少處理器內核可用)
--------------------------
【end-2019.06.07】