2.1.2 物理架構(gòu)

接下來介紹和討論AP的物理架構(gòu)。

1.OS、進(jìn)程與線程之間的關(guān)系

AP的操作系統(tǒng)需要具有能夠提供多進(jìn)程同時(shí)運(yùn)行的能力。每個(gè)AA都是作為一個(gè)獨(dú)立的進(jìn)程實(shí)現(xiàn)的，它們都有自己的邏輯內(nèi)存空間和命名空間。請(qǐng)注意，單個(gè)AA可能包含多個(gè)進(jìn)程，這可能部署到單個(gè)AP實(shí)例上，也可能分布在多個(gè)AP實(shí)例上。從模塊組織的角度來看，每個(gè)進(jìn)程都是由操作系統(tǒng)從可執(zhí)行文件實(shí)例化的。多個(gè)進(jìn)程也可以從同一個(gè)可執(zhí)行文件實(shí)例化。此外，AA可以構(gòu)成多個(gè)可執(zhí)行文件。功能集群通常也作為進(jìn)程來實(shí)現(xiàn)，功能集群也可以用單個(gè)或多個(gè)進(jìn)程來實(shí)現(xiàn)。自適應(yīng)平臺(tái)服務(wù)和非平臺(tái)服務(wù)也可以作為進(jìn)程實(shí)現(xiàn)。

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

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

功能集群可以是自適應(yīng)平臺(tái)基礎(chǔ)模塊或自適應(yīng)平臺(tái)服務(wù)。如前所述，這些通常都是進(jìn)程。它們需要使用IPC才能讓其與同樣是進(jìn)程的AA進(jìn)行交互。有兩種替代設(shè)計(jì)可以實(shí)現(xiàn)這一點(diǎn)：一種是“基于庫”的設(shè)計(jì)，由功能集群提供鏈接到AA的接口庫，直接調(diào)用IPC；另一種是“基于服務(wù)”的設(shè)計(jì)，其中進(jìn)程使用CM的功能函數(shù)，并有一個(gè)鏈接到AA的服務(wù)器代理庫。代理庫調(diào)用CM接口，該接口協(xié)調(diào)AA進(jìn)程和服務(wù)器進(jìn)程之間的IPC。

為功能集群選擇設(shè)計(jì)的一般準(zhǔn)則是，如果它僅在本地使用AP應(yīng)用程序?qū)嵗敲椿趲斓脑O(shè)計(jì)更合適，因?yàn)樗唵危矢摺Ｈ绻苑植际椒绞綇钠渌鸄P實(shí)例使用它，則建議采用基于服務(wù)的設(shè)計(jì)，因?yàn)镃M提供透明的通信，而不管客戶端AA和服務(wù)具體的位置如何。自適應(yīng)平臺(tái)基礎(chǔ)所屬的功能集群是“基于庫的”，自適應(yīng)平臺(tái)服務(wù)是“基于服務(wù)的”。關(guān)于“基于服務(wù)”的和“基于庫”的內(nèi)容還需要注意的是，F(xiàn)C的實(shí)現(xiàn)是可以不包含有進(jìn)程的，可以以庫的形式實(shí)現(xiàn)，在AA的進(jìn)程中運(yùn)行時(shí)，只要它滿足FC定義的RS和SWS。在這種情況下，AA和FC之間的交互將是常規(guī)的過程調(diào)用，而不是前面描述的基于IPC的。

2.FC之間的交互

一般來說，功能集群可以以特定于應(yīng)用程序?qū)崿F(xiàn)的方式相互交互，因?yàn)樗鼈儧]有綁定限制使用IPC的ARA接口。例如PSE51，它確實(shí)可能使用其他功能集群的ARA接口，這些接口是“public”接口。功能集群之間的一個(gè)典型交互模型是使用自適應(yīng)平臺(tái)設(shè)計(jì)的功能集群的“protected”接口來提供實(shí)現(xiàn)功能集群的特殊功能所需的訪問權(quán)限。此外，從AP18-03開始，引入了功能間集群（IFC）接口的新概念。請(qǐng)注意，它不是ARA的一部分，也不構(gòu)成對(duì)AP實(shí)現(xiàn)的正式規(guī)范要求。提供這些是為了通過闡明FC之間的交互來促進(jìn)AP規(guī)范的開發(fā)，并且它們還可以為AP規(guī)范的用戶提供更好的AP架構(gòu)視圖。接口在各自附加的FC SWS中進(jìn)行了描述。

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

AP將其運(yùn)行的平臺(tái)視為機(jī)器，機(jī)器可以是真實(shí)的物理機(jī)器、完全虛擬化的機(jī)器、半虛擬化的操作系統(tǒng)、操作系統(tǒng)級(jí)虛擬化的容器或任何其他虛擬化的環(huán)境。在硬件上，可以有一臺(tái)或多臺(tái)機(jī)器，一臺(tái)機(jī)器上只能運(yùn)行一個(gè)應(yīng)用程序?qū)嵗Ｍǔ＜僭O(shè)這個(gè)“硬件”包括一個(gè)芯片，運(yùn)行一臺(tái)或多臺(tái)機(jī)器。然而，如果AP允許，也有可能多個(gè)芯片組成一臺(tái)機(jī)器。

在AP的物理架構(gòu)中，還有很重要的一環(huán)是清單（Manifest）。清單是AUTOSAR模型描述的一部分，它是為支持AUTOSAR AP產(chǎn)品的配置而創(chuàng)建的，并被上傳到AUTOSAR AP產(chǎn)品，可能與包含清單適用的可執(zhí)行代碼的其他文件（如二進(jìn)制文件）相結(jié)合，清單的使用僅限于自動(dòng)搜索應(yīng)用程序。然而，這并不意味著在以AUTOSAR AP為目標(biāo)的開發(fā)項(xiàng)目中產(chǎn)生的所有ARXML都自動(dòng)被視為清單。事實(shí)上，一個(gè)車輛項(xiàng)目一般不會(huì)僅僅使用AUTOSAR AP，很可能還會(huì)配備許多在AUTOSAR CP上開發(fā)的ECU，因此，整車的系統(tǒng)設(shè)計(jì)必須涵蓋這兩者——在AUTOSAR CP上構(gòu)建的ECU和在AUTOSAR AP上創(chuàng)建的ECU。

原則上，清單可以這樣定義，即在概念上只有一個(gè)“清單”，并且每個(gè)部署都將在這個(gè)清單的內(nèi)容中處理。但是這似乎不合適，因?yàn)榍鍐蜗嚓P(guān)的模型元素存在于開發(fā)項(xiàng)目的不同階段。在應(yīng)用程序設(shè)計(jì)之后有必要將清單（Manifest）一詞的定義細(xì)分為三個(gè)不同的部分。

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

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

3）機(jī)器清單（Machine Manifest）：這種清單應(yīng)該描述與部署相關(guān)的內(nèi)容，這些內(nèi)容只適用于運(yùn)行AUTOSAR應(yīng)用程序的底層機(jī)器（即沒有任何應(yīng)用程序在機(jī)器上運(yùn)行）的配置。機(jī)器清單與用來建立AUTOSAR應(yīng)用程序?qū)嵗能浖壴谝黄稹?/p>

不同種類清單的定義（和使用）之間的時(shí)間劃分導(dǎo)致這樣的結(jié)論：在大多數(shù)情況下，不同的文件將被用來存儲(chǔ)三種清單的內(nèi)容。除了應(yīng)用程序設(shè)計(jì)和不同種類的清單之外，AUTOSAR方法支持系統(tǒng)設(shè)計(jì)，可以描述將在一個(gè)單一模型的系統(tǒng)中使用的兩個(gè)AUTOSAR平臺(tái)的軟件組件。不同AUTOSAR平臺(tái)的軟件組件可以以面向服務(wù)的方式相互通信。但是也可以描述信號(hào)到服務(wù)的映射，從而在面向服務(wù)的通信和基于信號(hào)的通信之間建立橋梁。

應(yīng)用程序設(shè)計(jì)描述了應(yīng)用于AUTOSAR AP應(yīng)用程序軟件創(chuàng)建的所有與設(shè)計(jì)相關(guān)的建模。應(yīng)用程序設(shè)計(jì)側(cè)重于以下方面：

1）用于對(duì)軟件設(shè)計(jì)和實(shí)現(xiàn)的信息進(jìn)行分類的數(shù)據(jù)類型。

2）作為面向服務(wù)通信的關(guān)鍵元素的服務(wù)接口。

3）定義應(yīng)用程序如何訪問面向服務(wù)的通信存儲(chǔ)接口。

4）作為訪問存儲(chǔ)數(shù)據(jù)和文件的關(guān)鍵元素。

5）定義應(yīng)用程序如何訪問存儲(chǔ)。

6）定義應(yīng)用程序如何訪問文件。

7）定義加密軟件如何訪問應(yīng)用程序。

8）定義應(yīng)用程序如何訪問平臺(tái)健康管理。

9）定義應(yīng)用程序如何訪問時(shí)基。

10）定義序列化屬性。

11）定義數(shù)據(jù)的特征如何序列化以在網(wǎng)絡(luò)上傳輸。

12）描述客戶端和服務(wù)器功能。

13）對(duì)應(yīng)用程序進(jìn)行分組以簡化軟件部署。

應(yīng)用程序設(shè)計(jì)中定義的工件獨(dú)立于應(yīng)用程序軟件的特定部署，因此便于在不同的部署場(chǎng)景中重用應(yīng)用程序?qū)崿F(xiàn)。

下面來詳細(xì)介紹各個(gè)清單部分。

（1）執(zhí)行清單的目的是提供在AUTOSAR AP上實(shí)際部署應(yīng)用程序所需的信息

總的想法是保持應(yīng)用軟件代碼盡可能獨(dú)立于部署場(chǎng)景，以增加應(yīng)用軟件在不同部署場(chǎng)景中的復(fù)用性。通過執(zhí)行清單，應(yīng)用程序的實(shí)例化受到控制，因此可以：①在同一臺(tái)機(jī)器上多次實(shí)例化同一個(gè)應(yīng)用軟件；②將應(yīng)用軟件部署到幾臺(tái)機(jī)器上，并在每臺(tái)機(jī)器上實(shí)例化應(yīng)用軟件。

執(zhí)行清單側(cè)重于以下幾個(gè)方面：

1）啟動(dòng)配置，以定義如何啟動(dòng)應(yīng)用程序?qū)嵗?dòng)包括啟動(dòng)選項(xiàng)和訪問角色的定義。每次啟動(dòng)可能取決于機(jī)器狀態(tài)/功能組狀態(tài)。

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

（2）服務(wù)實(shí)例清單在網(wǎng)絡(luò)上實(shí)現(xiàn)面向服務(wù)的通信需要特定于所使用的通信技術(shù)（例如SOME/IP）的配置

由于通信基礎(chǔ)設(shè)施在服務(wù)的提供者和請(qǐng)求者上的行為應(yīng)該是相同的，因此服務(wù)的實(shí)現(xiàn)必須是雙方兼容的。

服務(wù)實(shí)例清單側(cè)重于以下方面：

1）服務(wù)接口部署，定義服務(wù)在特定通信技術(shù)上的表現(xiàn)方式。

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

3）E2E保護(hù)的配置。

4）安全保護(hù)的配置。

5）日志和跟蹤的配置。

（3）機(jī)器清單允許配置在特定硬件（機(jī)器）上運(yùn)行的實(shí)際自適應(yīng)平臺(tái)實(shí)例

機(jī)器清單側(cè)重于以下方面：

1）網(wǎng)絡(luò)連接的配置和定義網(wǎng)絡(luò)技術(shù)的基本憑證（例如，對(duì)于以太網(wǎng)，涉及靜態(tài)IP地址的設(shè)置或DHCP的定義）。

2）服務(wù)發(fā)現(xiàn)技術(shù)的配置（例如，對(duì)于SOME/IP，涉及要使用的IP端口和IP多播地址的定義）。

3）已用機(jī)器狀態(tài)的定義。

4）已用功能組的定義自適應(yīng)平臺(tái)功能集群實(shí)現(xiàn)的配置（例如，操作系統(tǒng)提供具有特定權(quán)限的操作系統(tǒng)用戶列表）。

5）加密平臺(tái)模塊的配置。

6）平臺(tái)健康管理的配置。

7）時(shí)間同步的配置。

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