2.1.2 物理架構

接下來介紹和討論AP的物理架構。

1.OS、進程與線程之間的關系

AP的操作系統需要具有能夠提供多進程同時運行的能力。每個AA都是作為一個獨立的進程實現的，它們都有自己的邏輯內存空間和命名空間。請注意，單個AA可能包含多個進程，這可能部署到單個AP實例上，也可能分布在多個AP實例上。從模塊組織的角度來看，每個進程都是由操作系統從可執行文件實例化的。多個進程也可以從同一個可執行文件實例化。此外，AA可以構成多個可執行文件。功能集群通常也作為進程來實現，功能集群也可以用單個或多個進程來實現。自適應平臺服務和非平臺服務也可以作為進程實現。

所有這些進程可以是單線程進程，也可以是多線程進程。但是，根據進程所屬的邏輯層的不同，它們可以使用的操作系統API也不同。如果它們是在ARA之上運行的AA，那么它們應該只使用PSE51。如果進程是功能集群之一，則可以自由使用任何可用的操作系統接口。

總之，從操作系統的角度來看，AP和AA只是形成了一組進程，每個進程包含一個或多個線程——這些進程之間沒有區別，盡管提供任何類型的分區取決于AP的實現。這些進程通過IPC或任何其他可用的操作系統功能相互作用。

功能集群可以是自適應平臺基礎模塊或自適應平臺服務。如前所述，這些通常都是進程。它們需要使用IPC才能讓其與同樣是進程的AA進行交互。有兩種替代設計可以實現這一點：一種是“基于庫”的設計，由功能集群提供鏈接到AA的接口庫，直接調用IPC；另一種是“基于服務”的設計，其中進程使用CM的功能函數，并有一個鏈接到AA的服務器代理庫。代理庫調用CM接口，該接口協調AA進程和服務器進程之間的IPC。

為功能集群選擇設計的一般準則是，如果它僅在本地使用AP應用程序實例，那么基于庫的設計更合適，因為它更簡單，效率更高。如果以分布式方式從其他AP實例使用它，則建議采用基于服務的設計，因為CM提供透明的通信，而不管客戶端AA和服務具體的位置如何。自適應平臺基礎所屬的功能集群是“基于庫的”，自適應平臺服務是“基于服務的”。關于“基于服務”的和“基于庫”的內容還需要注意的是，FC的實現是可以不包含有進程的，可以以庫的形式實現，在AA的進程中運行時，只要它滿足FC定義的RS和SWS。在這種情況下，AA和FC之間的交互將是常規的過程調用，而不是前面描述的基于IPC的。

2.FC之間的交互

一般來說，功能集群可以以特定于應用程序實現的方式相互交互，因為它們沒有綁定限制使用IPC的ARA接口。例如PSE51，它確實可能使用其他功能集群的ARA接口，這些接口是“public”接口。功能集群之間的一個典型交互模型是使用自適應平臺設計的功能集群的“protected”接口來提供實現功能集群的特殊功能所需的訪問權限。此外，從AP18-03開始，引入了功能間集群（IFC）接口的新概念。請注意，它不是ARA的一部分，也不構成對AP實現的正式規范要求。提供這些是為了通過闡明FC之間的交互來促進AP規范的開發，并且它們還可以為AP規范的用戶提供更好的AP架構視圖。接口在各自附加的FC SWS中進行了描述。

在上文中提到了機器（Machine），接下來講解一下機器的概念。

AP將其運行的平臺視為機器，機器可以是真實的物理機器、完全虛擬化的機器、半虛擬化的操作系統、操作系統級虛擬化的容器或任何其他虛擬化的環境。在硬件上，可以有一臺或多臺機器，一臺機器上只能運行一個應用程序實例。通常假設這個“硬件”包括一個芯片，運行一臺或多臺機器。然而，如果AP允許，也有可能多個芯片組成一臺機器。

在AP的物理架構中，還有很重要的一環是清單（Manifest）。清單是AUTOSAR模型描述的一部分，它是為支持AUTOSAR AP產品的配置而創建的，并被上傳到AUTOSAR AP產品，可能與包含清單適用的可執行代碼的其他文件（如二進制文件）相結合，清單的使用僅限于自動搜索應用程序。然而，這并不意味著在以AUTOSAR AP為目標的開發項目中產生的所有ARXML都自動被視為清單。事實上，一個車輛項目一般不會僅僅使用AUTOSAR AP，很可能還會配備許多在AUTOSAR CP上開發的ECU，因此，整車的系統設計必須涵蓋這兩者——在AUTOSAR CP上構建的ECU和在AUTOSAR AP上創建的ECU。

原則上，清單可以這樣定義，即在概念上只有一個“清單”，并且每個部署都將在這個清單的內容中處理。但是這似乎不合適，因為清單相關的模型元素存在于開發項目的不同階段。在應用程序設計之后有必要將清單（Manifest）一詞的定義細分為三個不同的部分。

1）執行清單（Execution Manifest）：這種清單用于指定在AUTOSAR AP上運行的應用程序的部署相關信息。執行清單與實際的可執行代碼捆綁在一起，以支持將可執行代碼集成到機器上。

2）服務實例清單（Service Instance Manifest）：這種清單用于指定如何根據底層傳輸協議的要求配置面向服務的通信。服務實例清單與實際的可執行代碼捆綁在一起，實現面向服務的通信的各自用法。

3）機器清單（Machine Manifest）：這種清單應該描述與部署相關的內容，這些內容只適用于運行AUTOSAR應用程序的底層機器（即沒有任何應用程序在機器上運行）的配置。機器清單與用來建立AUTOSAR應用程序實例的軟件捆綁在一起。

不同種類清單的定義（和使用）之間的時間劃分導致這樣的結論：在大多數情況下，不同的文件將被用來存儲三種清單的內容。除了應用程序設計和不同種類的清單之外，AUTOSAR方法支持系統設計，可以描述將在一個單一模型的系統中使用的兩個AUTOSAR平臺的軟件組件。不同AUTOSAR平臺的軟件組件可以以面向服務的方式相互通信。但是也可以描述信號到服務的映射，從而在面向服務的通信和基于信號的通信之間建立橋梁。

應用程序設計描述了應用于AUTOSAR AP應用程序軟件創建的所有與設計相關的建模。應用程序設計側重于以下方面：

1）用于對軟件設計和實現的信息進行分類的數據類型。

2）作為面向服務通信的關鍵元素的服務接口。

3）定義應用程序如何訪問面向服務的通信存儲接口。

4）作為訪問存儲數據和文件的關鍵元素。

5）定義應用程序如何訪問存儲。

6）定義應用程序如何訪問文件。

7）定義加密軟件如何訪問應用程序。

8）定義應用程序如何訪問平臺健康管理。

9）定義應用程序如何訪問時基。

10）定義序列化屬性。

11）定義數據的特征如何序列化以在網絡上傳輸。

12）描述客戶端和服務器功能。

13）對應用程序進行分組以簡化軟件部署。

應用程序設計中定義的工件獨立于應用程序軟件的特定部署，因此便于在不同的部署場景中重用應用程序實現。

下面來詳細介紹各個清單部分。

（1）執行清單的目的是提供在AUTOSAR AP上實際部署應用程序所需的信息

總的想法是保持應用軟件代碼盡可能獨立于部署場景，以增加應用軟件在不同部署場景中的復用性。通過執行清單，應用程序的實例化受到控制，因此可以：①在同一臺機器上多次實例化同一個應用軟件；②將應用軟件部署到幾臺機器上，并在每臺機器上實例化應用軟件。

執行清單側重于以下幾個方面：

1）啟動配置，以定義如何啟動應用程序實例。啟動包括啟動選項和訪問角色的定義。每次啟動可能取決于機器狀態/功能組狀態。

2）資源管理，特別是資源組分配。

（2）服務實例清單在網絡上實現面向服務的通信需要特定于所使用的通信技術（例如SOME/IP）的配置

由于通信基礎設施在服務的提供者和請求者上的行為應該是相同的，因此服務的實現必須是雙方兼容的。

服務實例清單側重于以下方面：

1）服務接口部署，定義服務在特定通信技術上的表現方式。

2）服務實例部署，為特定提供和要求的服務實例定義通信技術所需的憑證。

3）E2E保護的配置。

4）安全保護的配置。

5）日志和跟蹤的配置。

（3）機器清單允許配置在特定硬件（機器）上運行的實際自適應平臺實例

機器清單側重于以下方面：

1）網絡連接的配置和定義網絡技術的基本憑證（例如，對于以太網，涉及靜態IP地址的設置或DHCP的定義）。

2）服務發現技術的配置（例如，對于SOME/IP，涉及要使用的IP端口和IP多播地址的定義）。

3）已用機器狀態的定義。

4）已用功能組的定義自適應平臺功能集群實現的配置（例如，操作系統提供具有特定權限的操作系統用戶列表）。

5）加密平臺模塊的配置。

6）平臺健康管理的配置。

7）時間同步的配置。

8）可用硬件資源的文檔（例如，有多少內存可用；有多少處理器內核可用）。