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】