我是穿拖鞋的漢子,，魔都中堅持長期主義的汽車電子工程師（Wechat：gongkenan2013）,。

老規(guī)矩，分享一段喜歡的文字,，避免自己成為高知識低文化的工程師：

“

本就是小人物,，輸了就是輸了，不要在意別人怎么看自己,。江湖一碗茶,，喝完再掙扎，出門靠自己,，四海皆為家,。人生的面吃一碗少一碗，人生的面見一面少一面,。人生就是一次次減法,，來日并不方長,。自己的狀態(tài)就是自己最好的風(fēng)水，自己的人品就是自己最好的運(yùn)氣,。簡單點,，善良點，努力點,，努力使每一天都開心,，不為別人，只為自己,。

本文大體如下：

1,、AP架構(gòu)

2、應(yīng)用程序的啟動和關(guān)閉

3,、OS,、Process和線程

4、基于庫或基于服務(wù)的功能集群實施

5,、方法和Manifest

一,、AP架構(gòu)

如圖顯示了AP的架構(gòu)。自適應(yīng)應(yīng)用程序(AA)運(yùn)行在 ARA(AUTOSAR自適應(yīng)應(yīng)用程序運(yùn)行時)之上,。ARA由功能集群提供的應(yīng)用接口組成,，功能集群屬于自適應(yīng)平臺基礎(chǔ)或自適應(yīng)平臺服務(wù)。自適應(yīng)平臺基礎(chǔ)提供 AP 的基本功能,，自適應(yīng)平臺服務(wù)提供AP 的平臺標(biāo)準(zhǔn)服務(wù),。任何 AA 也可以向其他 AA 提供服務(wù)，如圖中的非平臺服務(wù),。

從AA的角度來看,，功能集群的接口，無論是自適應(yīng)平臺基礎(chǔ)還是自適應(yīng)平臺服務(wù)的接口,，都無關(guān)緊要--它們只是提供指定的C++接口或AP未來可能支持的任何其他語言綁定,。在引擎蓋下確實存在差異。此外,，請注意,，在ARA（AUTOSAR Runtime for Adaptive applications）接口之下，包括在AA上下文中調(diào)用的 ARA（AUTOSAR Runtime for Adaptive applications） 庫,，可以使用 ARA 之外的其他接口來實現(xiàn) AP 的規(guī)范,，這取決于AP實現(xiàn)的設(shè)計。

POSIX API的語言綁定基于C++,，C++標(biāo)準(zhǔn)庫也是ARA（AUTOSAR Runtime for Adaptive applications）的一部分,。關(guān)于OS API，只有PSE51接口(POSIX 標(biāo)準(zhǔn)的單Process 配置文件)作為ARA（AUTOSAR Runtime for Adaptive applications）的一部分可用。選擇PSE51 的目的是為現(xiàn)有的 POSIX 應(yīng)用程序提供可移植性,，并實現(xiàn)應(yīng)用程序之間的無千擾,。

請注意，C++標(biāo)準(zhǔn)庫包含許多基于POSIX的接口,，包括多線程APIS,。建議不要將C++標(biāo)準(zhǔn)庫的線程接口與本地PSE51線程接口混用，以避免復(fù)雜化,。遺憾的是,，C++標(biāo)準(zhǔn)庫并未涵蓋 PSE51 的所有功能，如設(shè)置線程調(diào)度策略,。在這種情況下,，可能需要同時使用這兩個接口。

支持的協(xié)議,、安全和安保功能

自適應(yīng)平臺支持一系列眾所周知的協(xié)議,、安全和安保功能。下圖和表格提供了概述,。

二,、應(yīng)用程序的啟動和關(guān)閉

應(yīng)用程序的生命周期由執(zhí)行管理(EM)管理。應(yīng)用程序的加載/啟動通過使用EM的功能進(jìn)行管理,，需要在系統(tǒng)集成時或運(yùn)行時進(jìn)行適當(dāng)配置才能啟動應(yīng)用程序,。事實上，從EM的角度來看,，所有功能集群都是應(yīng)用程序,，除了EM本身外，它們也以同樣的方式啟動,。圖 4.2 展示了 AP 內(nèi)和 AP 上不同類型的應(yīng)用程序,。

請注意，應(yīng)用程序何時啟動或終止不是由EM決定的,。名為狀態(tài)管理(SM)的特殊FC是控制器,，它根據(jù)系統(tǒng)設(shè)計對EM發(fā)出指令，對不同狀態(tài)進(jìn)行仲裁,，從而控制整個系統(tǒng)的行為。由于這里的系統(tǒng)指的是AP及其應(yīng)用程序運(yùn)行的整臺Machine,，因此內(nèi)部行為的實現(xiàn)是針對具體項目的,。SM還與其他 FCs交互，以協(xié)調(diào)整個Machine的行為,。SM 只應(yīng)使用標(biāo)準(zhǔn) ARA 接口,，以保持不同 AP 棧實現(xiàn)之間的可移植性。

應(yīng)用程序交互

關(guān)于AAs之間的交互,，PSE51不包括IPC(Inter-ProcessCommunication),，因此AAs之間沒有直接的交互接口,。通信管理(CM)是唯一明確的接口。CM 還為 Machine 內(nèi)和Machine 間提供面向服務(wù)的通信,，這對應(yīng)用程序是透明的,。無論服務(wù)和客戶端應(yīng)用程序的拓?fù)洳渴鹑绾危珻M 都會處理服務(wù)請求/回復(fù)的路由選擇,。請注意,，其他 ARA 接口可能會在內(nèi)部觸發(fā) AAs 之間的交互，但這并不是一個明確的通信接口,，而只是各 ARA 接口所提供功能的副產(chǎn)品,。

非標(biāo)準(zhǔn)接口

AA 和功能集群可使用任何非標(biāo)準(zhǔn)接口，但這些接口不得與標(biāo)準(zhǔn) AP 功能相沖突,，并且必須符合項目的 Safety/Security要求,。除非它們是純應(yīng)用本地運(yùn)行庫，否則應(yīng)注意盡量減少使用,，因為這將影響軟件在其他 AP 實現(xiàn)中的可移植性,。

這里討論的是AP的物理架構(gòu)。請注意,，本節(jié)中的大部分內(nèi)容僅供參考,，并不構(gòu)成 AP的正式要求規(guī)范，因為AP的內(nèi)部結(jié)構(gòu)是由實現(xiàn)定義的,。明確說明了對AP實施的任何正式要求,。作為額外的信息來源，請參閱其中更詳細(xì)地描述了AP的內(nèi)部結(jié)構(gòu),。

三,、OS、Process和線程

需要 AP 操作系統(tǒng)才能提供多進(jìn)程 POSIX 操作系統(tǒng)功能,。每個 AA 都是作為一個獨立的進(jìn)程實現(xiàn)的,，具有自己的邏輯存儲器space和 namespace。請注意,，單個AA可能包含多個進(jìn)程,，這可以部署在單個AP實例上，也可以分布在多個AP實例上,。從模塊組織的角度來看,，每個進(jìn)程都由操作系統(tǒng)從可執(zhí)行文件實例化?？梢詮膯蝹€可執(zhí)行文件實例化多個進(jìn)程,。此外，AA 可能構(gòu)成多個可執(zhí)行文件。

功能集群通常也是以Process（進(jìn)程）的形式實現(xiàn)的,。一個功能集群也可以用一個 Process（進(jìn)程） 或多個(子)Process（進(jìn)程）來實現(xiàn),。自適應(yīng)平臺服務(wù)和非平臺服務(wù)也以 Process（進(jìn)程）的形式實現(xiàn),

所有這些 Process（進(jìn)程）都可以是單線程 Process（進(jìn)程） 或多線程 Process（進(jìn)程）。不過,，根據(jù) Process（進(jìn)程）所屬邏輯層的不同,，它們可以使用的OS API也不同。如果 Process（進(jìn)程）是運(yùn)行在 ARA 上的 AAs,則只能使用PSE51,。如果 Process（進(jìn)程）屬于功能集群,，則可以自由使用任何可用的 OS 接口?？傊?，從 OS 的角度來看，AP 和 AA 只是一組Process（進(jìn)程）,，每個 Process（進(jìn)程）都包含一個或多個線程--這些 Process（進(jìn)程）之間沒有任何區(qū)別,，但是否提供任何分區(qū)取決于 AP 的實現(xiàn)。這些Process（進(jìn)程）通過 IPC 或任何其他可用的 OS 功能進(jìn)行交互,。請注意,，AA Process（進(jìn)程）不能直接使用IPC，只能通過ARA進(jìn)行通信,。

四,、基于庫或基于服務(wù)的功能集群實施

如下圖所示，功能集群可以是自適應(yīng)平臺基礎(chǔ)模塊或自適應(yīng)平臺服務(wù),。如前所述,，它們通常都是Process。要與同為Process 的 AAs 交互,，它們需要使用 IPC,。為此，有兩種可供選擇的設(shè)計方案,。一種是"基于庫"的設(shè)計,，即由功能集群提供并鏈接到 AA 的接口庫直接調(diào)用 IPC。另一種是"基于服務(wù)"的設(shè)計,，即 Process 使用通信管理功能,，并將服務(wù)端代理庫鏈接到 AA。代理庫調(diào)用通信管理接口,，在 AA Process 和服務(wù)端 Process之間協(xié)調(diào) IPC,。請注意，AA 是直接使用通信管理功能執(zhí)行IPC,，還是通過代理庫與服務(wù)端直接混合執(zhí)行 IPC，這取決于實施情況。

選擇功能集群設(shè)計的一般準(zhǔn)則是,，如果只在本地 AP 實例中使用,，則基于庫的設(shè)計更合適，因為它更簡單,、更高效,。如果從其他 AP 實例以分布式方式使用，建議采用基于服務(wù)的設(shè)計,，因為無論客戶 AA 和服務(wù)位于何處,，通信管理都能提供透明的通信。屬于自適應(yīng)平臺基礎(chǔ)的功能集群是"基于庫"的,，而自適應(yīng)平臺服務(wù)則是"基于服務(wù)"的,，正如其名稱所示。

最后要注意的是,，只要FC符合定義的RS和SWS,，就允許FC的實現(xiàn)不包含Process,而是以庫的形式實現(xiàn)，并在 AA Process 的上下文中運(yùn)行,。在這種情況下,，AA 與 FC之間的交互將是常規(guī)的過程調(diào)用，而不是如前所述的基于IPC的交互,。

功能集群之間的交互

一般來說,，功能集群之間可以通過 AP 的特定實現(xiàn)方式進(jìn)行交互，因為它們不受限于ARA 接口,，例如 PSE51 就限制了 IPC 的使用,。事實上，它可以使用其他功能集群的ARA 接口,，這些接口都是公共接口,。功能集群之間的一種典型交互模式是使用功能集群的受保護(hù)接口，提供實現(xiàn)功能集群特殊功能所需的特權(quán)訪問,。

此外,，AP18-03 引入了 Inter-Functional-Cluster(IFC)接口的新概念。它描述了 FC 向其他 FCs 提供的接口,。請注意,，它不是 ARA 的一部分，也不構(gòu)成對 AP 實施的正式規(guī)范要求,。提供這些接口的目的是通過明確 FCs 之間的交互來促進(jìn) AP 規(guī)范的制定,，同時也可為 AP 規(guī)范的用戶提供更好的 AP 架構(gòu)視圖。FC SWS 的附件中描述了這些接口,。

Machine/硬件

AP將其運(yùn)行的硬件視為 Machine ,。這樣做的理由是為了實現(xiàn)一致的平臺視圖,，而不考慮可能使用的任何虛擬化技術(shù)。Machine 可以是真正的物理 Machine ,、完全虛擬化的Machine,、準(zhǔn)虛擬化的 OS、OS 級虛擬化容器或任何其他虛擬化環(huán)境,。在硬件上,，可以有一臺或多臺 Machine ，一臺 Machine 上只能運(yùn)行一個 AP 實例,。一般認(rèn)為,，這種"硬件"包括一個芯片，承載一個或多個 Machine ,。不過,，如果 AP 實現(xiàn)允許，也可以由多個芯片組成一臺Machine ,。

五,、方法和Manifest

要支持功能應(yīng)用程序的分布式、獨立和敏捷開發(fā),，就必須采用標(biāo)準(zhǔn)化的開發(fā)方法,。AUTOSAR 自適應(yīng)方法論涉及到服務(wù)、應(yīng)用程序,、Machine 及其配置等工件描述工作產(chǎn)品的標(biāo)準(zhǔn)化,，以及定義這些工作產(chǎn)品如何交互的相應(yīng)任務(wù)，以實現(xiàn)自適應(yīng)平臺產(chǎn)品開發(fā)所需的各種活動的設(shè)計信息交換,。

如圖展示了如何實施自適應(yīng)方法的概覽草案,。有關(guān)這些步驟的詳細(xì)信息，請參見

應(yīng)用的分布式,、獨立,、敏捷開發(fā)要求開發(fā)方法論的標(biāo)準(zhǔn)化。AUTOSAR Adaptive 方法論包括兩部分：

用于描述 Service,、Application,、Machine 的 Work Product 的標(biāo)準(zhǔn)化以及他們的配置

定義 Work Product 如何交互，以交換設(shè)計信息的任務(wù)

Manifest

Manifest 代表了一個 AUTOSAR 的模型描述,，上傳到 AP 產(chǎn)品,，用以支持 AP 產(chǎn)品的配置。上傳到 AP 時,，可能結(jié)合其他該 Manifest 適用的文件,，如含有可執(zhí)行代碼的二進(jìn)制文件。

Manifest 只限于 AP,，但這不意味著 AP 項目中所有產(chǎn)生的 ARXML 都是 Manifest,。事實上,，AUTOSAR AP is usually not exclusively used in a vehicle project 不只是應(yīng)用于汽車領(lǐng)域。

典型的車輛還會有很多基于 AUTOSAR CP 開發(fā)的 ECU,，因此整車系統(tǒng)設(shè)計要同時考慮基于 AUTOSAR CP 和 AP 的 ECU,。

原則上，術(shù)語 Manifest 在概念上可以定義為單一的 Manifest,，部署的各個方面都會在這個 Manifest 的上下文中處理。但是這樣現(xiàn)實中并不可行,，因為項目中和 Manifest 相關(guān)的模型存在于整個項目的各個不同階段,。出于這個原因，除了 Application Design 之外,，Manifest 又可以細(xì)分為三類：

Application Design

描述所有應(yīng)用設(shè)計相關(guān)的方面,，不需要部署到 AP 機(jī)器上，但 Application Design 會輔助在 Execution Manifest 和 Service Instance Manifest 中定義應(yīng)用軟件的部署,。

Execution Manifest

描述應(yīng)用部署相關(guān)的信息,。和可執(zhí)行代碼綁定，以支持將可執(zhí)行代碼集成到機(jī)器,。

Service Instance Manifest

描述針對特定的傳輸協(xié)議（如 SOME/IP）,，進(jìn)行面向服務(wù)通信的配置。和可執(zhí)行代碼綁定,。

Machine Manifest

描述運(yùn)行 AUTOSAR AP 的機(jī)器,。和共同組成 AP 實例的軟件綁定。

按照定義（和用法）劃分 Manifest 導(dǎo)致使用了不同的物理文件來存儲三類 Manifest 的內(nèi)容,。除了 Application Design 和不同的 Manifest,，AUTOSAR 方法論支持系統(tǒng)設(shè)計，可以在單一模型中描述系統(tǒng)中 CP,、AP 兩個平臺的軟件模塊,。不同平臺中軟件模塊可以通過面向服務(wù)的方式通信。但是也可以描述一個信號到服務(wù)的映射,，在面向服務(wù)的通信和基于信號的通信之間搭建一個橋梁,。

清單

一個 Manifest 代表一段 AUTOSAR 模型描述，它是為支持 AUTOSAR AP 產(chǎn)品的配置而創(chuàng)建的,，并被上傳到 AU-TOSAR AP 產(chǎn)品,，可能與其他包含 Manifest 適用的可執(zhí)行代碼的工件(如二進(jìn)制文件)結(jié)合在一起。

清單的使用僅限于 AUTOSAR AP,。但這并不意味著在以 AUTOSAR AP 為目標(biāo)的開發(fā)項目中產(chǎn)生的所有 ARXML 都會自動被視為清單,。事實上，AUTOSAR AP 通常不會專門用于車輛項目,。

一輛典型的車輛很可能還配備了許多在 AUTOSAR CP 基礎(chǔ)上開發(fā)的 ECUs,，因此整輛車的系統(tǒng)設(shè)計必須同時涵蓋在 AUTOSAR CP 基礎(chǔ)上開發(fā)的 ECUs 和在 AUTOSAR AF基礎(chǔ)上開發(fā)的 ECUS,。

原則上，"Manifest"一詞可以這樣定義,，即概念上只有一個"Manifest",，每個部署方面都將在此背景下處理。但這似乎并不合適,，因為在典型的開發(fā)項目中,，與清單相關(guān)的模型元素顯然存在于完全不同的階段。

因此,，在應(yīng)用程序設(shè)計之外,，有必要將清單一詞的定義細(xì)分為三個不同的部分:

-> 應(yīng)用設(shè)計這種描述規(guī)定了適用于為 AUTOSAR AP 創(chuàng)建應(yīng)用軟件的所有設(shè)計相關(guān)方面。它不一定需要部署到自適應(yīng)平臺 Machine 上,，但應(yīng)用設(shè)計有助于在執(zhí)行清單和服務(wù)實例清單中定義應(yīng)用軟件的部署;

-> 執(zhí)行清單這種清單用于指定在 AUTOSAR AP 上運(yùn)行的應(yīng)用程序的部署相關(guān)信息,。執(zhí)行清單與實際可執(zhí)行代碼捆綁在一起，以支持將可執(zhí)行代碼集成到 Machine 上;

-> 服務(wù)實例清單這種清單用于指定如何根據(jù)底層傳輸協(xié)議的要求配置面向服務(wù)的通信,。服務(wù)實例清單與實際的可執(zhí)行代碼捆綁在一起,，以實現(xiàn)面向服務(wù)通信的各種用途;

-> Machine 清單這種清單用于描述與部署相關(guān)的內(nèi)容，這些內(nèi)容只適用于運(yùn)行AUTOSAR AP 的底層 Machine (即 Machine 上不運(yùn)行任何應(yīng)用程序)的配置,。Machine 清單與用于建立 AUTOSAR AP 實例的軟件捆綁在一起,。不同類型的清單在定義(和使用)上的時間劃分導(dǎo)致在大多數(shù)情況下使用不同的物理文件來存儲三種清單的內(nèi)容。

除了應(yīng)用程序設(shè)計和不同類型的清單之外,，AUTOSAR方法論還支持系統(tǒng)設(shè)計,，可以在一個模型中描述系統(tǒng)中使用的兩個 AUTOSAR 平臺的軟件組件。不同 AUTOSAR 平臺的軟件組件可以面向服務(wù)的方式相互通信,。但也可以描述信號到服務(wù)的映射,，從而在面向服務(wù)的通信和基于信號的通信之間架起一座橋梁。

應(yīng)用設(shè)計

應(yīng)用設(shè)計描述了所有與設(shè)計相關(guān)的建模,，這些建模適用于為 AUTOSAR AP 創(chuàng)建應(yīng)用軟件,。

應(yīng)用設(shè)計側(cè)重于以下方面:

-> 用于軟件設(shè)計和實施信息分類的數(shù)據(jù)類型

-> 服務(wù)接口是面向服務(wù)通信的關(guān)鍵要素

-> 定義應(yīng)用程序如何訪問面向服務(wù)的通信

-> 持久性接口是訪問持久數(shù)據(jù)和文件的關(guān)鍵要素

-> 定義應(yīng)用程序如何訪問持久存儲

-> 定義應(yīng)用程序如何訪問文件

-> 定義應(yīng)用程序如何訪問加密軟件

-> 定義應(yīng)用程序如何訪問平臺健康管理

-> 定義應(yīng)用程序如何訪問時間庫

-> 序列化屬性，用于定義數(shù)據(jù)在網(wǎng)絡(luò)傳輸中的序列化特性

-> 描述客戶端和服務(wù)端功能

-> 對應(yīng)用程序進(jìn)行分組,，以方便軟件的部署,。

應(yīng)用程序設(shè)計中定義的工件與應(yīng)用軟件的具體部署無關(guān)，因此便于在不同部署情況下重復(fù)使用應(yīng)用程序?qū)崿F(xiàn),。

執(zhí)行清單

執(zhí)行清單的目的是提供在 AUTOSAR AP 上實際部署應(yīng)用程序所需的信息,。總體思路是使應(yīng)用軟件代碼盡可能獨立于部署方案,，以增加應(yīng)用軟件在不同部署方案中重復(fù)使用的幾率,。

執(zhí)行清單可控制應(yīng)用軟件的實例化，因此可以在同一臺Machine 上多次實例化同一應(yīng)用軟件,，或?qū)?yīng)用軟件部署到多臺 Machine上,，并在每臺 Machine 上實例化應(yīng)用軟件,。

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

1、啟動配置:定義應(yīng)用程序?qū)嵗膯臃绞?。啟動包括啟動選項和訪問角色的定義,。每次啟動都可能取決于 Machimne 狀態(tài)和/或功能組狀態(tài)。

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

服務(wù)實例清單

在網(wǎng)絡(luò)上實施面向服務(wù)的通信需要針對所使用的通信技術(shù)(如 SOME/P)進(jìn)行配置,。由于通信基礎(chǔ)設(shè)施對服務(wù)提供者和請求者的作用相同,，因此服務(wù)的實現(xiàn)必須在雙方都兼容。

服務(wù)實例清單側(cè)重于以下幾個方面:

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

-> 服務(wù)實例部署:為特定提供的和所需的服務(wù)實例定義通信技術(shù)所需的憑證,。

-> E2E 保護(hù)配置

-> 安全保護(hù)配置

-> 日志和跟蹤配置

Machine 清單

Machine 清單允許配置在特定硬件(Machine )上運(yùn)行的實際自適應(yīng)平臺實例,。Machine 清單側(cè)重于以下方面:

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

2,、配置服務(wù)發(fā)現(xiàn)技術(shù)(例如,，對于 SOME/IP，這涉及到IP端口和IP多播地址的定義,；

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

4、配置服務(wù)發(fā)現(xiàn)技術(shù)(例如,，對于 SOME/P,，這涉及到 正 端口和 IP 多播地址的定義)

5、定義使用的 Machine 狀態(tài)

6,、定義使用的功能組

7,、配置自適應(yīng)平臺功能組實施(例如，操作系統(tǒng)提供具有特定權(quán)限的 OS用戶列表),。

8,、加密平臺模塊的配置

9、平臺健康管理的配置

10,、時間同步的配置

11,、可用硬件資源文檔(例如,，有多少RAM 可用;有多少處理器內(nèi)核可用)

擱筆分享完畢！

愿你我相信時間的力量

做一個長期主義者,！

車載軟件架構(gòu)——基礎(chǔ)軟件供應(yīng)商&開發(fā)工具鏈（二）

車載診斷協(xié)議DoIP系列 —— 協(xié)議中的簡易網(wǎng)絡(luò)拓?fù)涓攀?br>

車載診斷協(xié)議DoIP系列 —— 協(xié)議中術(shù)語解釋和定義

車載診斷協(xié)議DoIP系列 —— DoIP會話模式（安全與非安全）

車載診斷協(xié)議DoIP系列 —— DoIP應(yīng)用（Application）需求

車載診斷協(xié)議DoIP系列 —— DoIP APP車輛識別和聲明請求報文

車載測試Vector工具——基于DoIP的ECU/車輛的連接故障排除

電子電器架構(gòu)——基于Adaptive AUTOSAR的電子電器架構(gòu)簡析

車載電子電器架構(gòu) —— 基于AP定義車載HPC

車載電子電器架構(gòu) —— 國產(chǎn)基礎(chǔ)軟件生態(tài)簡介

電子電氣架構(gòu)——無感刷寫（Vector）協(xié)議棧方案介紹

車載軟件架構(gòu)——基礎(chǔ)軟件供應(yīng)商&開發(fā)工具鏈（一）

車載軟件架構(gòu) —— 閑聊幾句AUTOSAR OS（十一）