薦 言：
通過以下鏈接可直接購買：
正文：
AUTOSAR AP平臺的總體性概述
今天我們節選了書中對AUTOSAR AP平臺的總體性概述，可以讓AP的用戶和AP的開發人員對AP的整體設計和關鍵概念建立宏觀認識，以下是節選正文：
AUTOSAR自適應平臺（AUTOSAR Adaptive Platform，AP）中的“Adaptive”意為“適應”，也意味著AP能適應多種操作系統，可以適應多種應用。在軟件的架構、實現以及軟件的更新迭代方式上，AP與CP有很大的區別。本章從AP產生的背景、AP的主要特點以及架構等角度給出主要知識點的介紹，但不會詳細展開每一部分，具體每個組件的功能和特性將會在后續章節中詳細展開，以便讀者由淺入深地學習后面的相關章節。
#01
AUTOSAR 自適應平臺產生的背景
1.1 高算力ECU的出現
目前市場上大部分汽車中，ECU主要用于取代或增強機電系統的功能。部署在這些ECU中的軟件主要功能是根據輸入信號和連接到車輛網絡的其他ECU的信息來控制電氣輸出信號，算法相對簡單，且大部分控制軟件是為目標車輛設計和開發的，在車輛生命周期內不會有明顯的變化。因此，控制器對算力和內存的要求較低，軟件功能也相對固定，但是要求高可靠性，需要較長的驗證周期才能進入市場銷售，因此開發周期較長。
而智能網聯汽車的開發模式則與傳統汽車不同，電氣化、智能化和互聯互通成為下一代汽車的主要技術特征。換句話說，這些新的技術特征對車輛E/E架構升級和軟件技術推陳出新提出了挑戰。例如，一些具備輔助駕駛或者自動駕駛功能的汽車，可能需要安裝雷達、攝像頭等傳感器，這些傳感器輸出的信號則需要引入復雜的計算機算法來實現信息分析并代替人控制車輛的功能，這些算法需要較強的計算處理能力且必須滿足嚴格的完整性和安全性要求，而傳統的車載ECU是無法滿足這種使用場景需求的。
此外，在車輛的生命周期中，由于外部系統的發展或功能的改進，整車生產商提供給終端客戶的服務不再是所見即所得，行業內企業都在致力于通過軟件創新持續地為客戶提供更多個性化的增值服務，以及以更便捷、低成本的方式實現車輛軟件的缺陷修復與升級，而這需要網絡的支持。因此，將汽車接入互聯網，以及引入更強算力的ECU作為車載計算機則成了新的技術趨勢，隨之也對軟件技術的更新提出了挑戰。
總體來說，CP滿足了控制ECU的需求，而上述高算力ECU的需求無法得到滿足。因此，AUTOSAR開發了第二個軟件平臺，即AP。AP主要為高性能計算提供通信機制以及構建一個安全、可靠的運行環境，并提供靈活的軟件配置，例如支持軟件隨時更新，支持大數據的存儲等。
1.2 技術驅動力
汽車軟件技術發展的背后有兩個主要的技術驅動力。一個是帶寬更高、速度更快的總線網絡，另一個是車用高算力處理器。車載網絡不斷增長的帶寬需求推動了以太網的引入，它提供了更高的帶寬和交換網絡，與傳統的車載通信技術（如CAN）相比，能夠更有效地傳輸大數據、支持點對點通信，并且寶馬以及博通等公司對總線進行了改進。以太網也采用了雙絞線，能夠滿足電磁兼容性（ElectroMagnetic Compatibility，EMC）要求。CP雖然可以支持以太網，但CP的初衷主要還是為傳統的通信技術而設計的，即使對以太網架構進行了優化，受主頻和存儲空間限制還是很難充分利用以太網的通信能力，也很難充分發揮以太網的優勢。
同樣，近年來隨著車輛變得更加智能，對處理器的性能要求也大大增加。多核MCU雖然已經在ECU中使用，但內核數量的增加使CP的設計變得更加困難。具有更多內核的多核處理器、通用圖形處理器（General- Purpose computing on Graphics Processing Units，GPGPU）、FPGA和專用加速器正在不斷得到應用，使得AP能提供比傳統MCU高幾個數量級的運算處理性能。另外，隨著計算能力的膨脹，對于這些智能ECU來說，電源能效也會成為一個需要關注的問題。從半導體和處理器技術的角度來看，受波拉克法則的限制，物理上不可能無止境地提高處理器的頻率，提高性能的唯一方法是眾核（Many- Core）并行執行。此外，眾所周知，每瓦功耗的最佳性能是由不同的計算資源混合實現的，如多核、協處理器、圖形處理器（Graphics Processing Unit，GPU）、FPGA和加速器。這種高性能計算（High Performance Computing，HPC）已經遠遠超過了CP的能力范圍。
隨著更多的處理元件被組合在一個芯片中，如多核處理器，這些處理元件之間的通信變得比傳統的ECU之間的通信快了好幾個數量級。新型的處理器互連技術，如片上網絡（Network on Chip，NoC）應運而生。芯片內更多的處理能力和更快的通信的組合也促使人們需要一個能夠滿足不斷增長的系統要求的新平臺。
#02
AUTOSAR AP 的特點
AP 的出現主要是為了解決車上某些不適用于CP場景的問題。新的車載需求促進了改變，主要體現在四個方面，一是數據量特別是通信數據量的劇增，雷達和圖像等信息的傳遞和處理必須有更強、更快的處理器；二是車內總線的帶寬需要有質的突破，需要更高帶寬、標準成熟的總線，這使得CP難以勝任；三是軟件需要頻繁地迭代更新甚至是透明式的更新；四是軟件不再要求強實時和面向過程，而更注重面向對象。這四個方面使得AP有別于CP。AP主要是為新的車載處理器芯片運行環境提供一套汽車軟件架構規范，需要更高的計算能力，與CP相比，AP具備以下特點。
2.1 采用 \(\mathrm{C + + }\) 語言
\(\mathrm{C + + }\) 是1979年由貝爾實驗室在C語言的基礎上開發而來的。 \(\mathrm{C + + }\) 是兼容C語言的，目前的編譯器都會同時支持C與 \(\mathrm{C + + }\) 語言。C語言面向過程，適用于控制類功能開發，而 \(\mathrm{C + + }\) 面向對象，比C語言要復雜，抽象程度更高，但更符合物理世界的屬性和活動。AP使用的場景大多是輔助駕駛、無人駕駛，需要大算力、大數據的處理，采用的操作系統是符合可移植操作系統接口（Portable Operating System Interface，POSIX）標準的，例如Linux、QNX等。這些操作系統支持 \(\mathrm{C + + }\) 語言的編程，可以通過靈活地使用 \(\mathrm{C + + }\) 中的封裝、繼承和多態等特性，極大地提高大規模編程中的代碼可讀性、可重用性和可移植性。
\(\mathrm{C + + }\) 成為AP的首選語言，是因為 \(\mathrm{C + + }\) 既能很好地支持面向對象，也能兼容C語言。既可以實現應用程序的高效運行，也可以向下支持更底層的操作。AP采用 \(\mathrm{C + + }\) 是ISO/IEC14882標準在汽車工業子領域的應用規范，同時也對MISRA \(\mathrm{C + + 2008}\) 的不足做了補充。
2.2 使用SOA架構
在AP中，更多的處理是高層次的、更接近于終端用戶層面的行為需求，因此架構設計有別于傳統CP的面向信號的架構。面向服務的架構（Service- Oriented Architecture，SOA）是以服務為核心的高層次架構設計理念。可通過在網絡上使用基于通用通信語言的服務接口，實現軟件組件的重復使用。AP 中的需求可以很好地利用 SOA 架構來描述。因此，AP 選擇了 SOA 來解決功能模塊不斷擴展、迭代升級的問題。
SOA 通常的定義為：一個系統由一組服務組成，其中一個服務可以使用另一個服務，而應用程序則根據其需求使用一個或多個服務。例如，一個服務可能和使用它的應用程序運行在相同的 ECU 上，也可能運行在另一個 ECU 上。在這兩種情況下，應用程序的代碼是相同的，通信基礎設施將負責屏蔽這一差異，為應用程序提供完全透明的通信。
2.3 多核并行處理
多核處理器和異構計算的不斷發展為 AP 提供了技術基礎，使 AP 具備了功能擴展和性能提升的架構能力，如硬件和平臺接口規范、操作系統和 Hypervisor（虛擬化）技術，以及開發工具（如自動并行化工具）等，這些都需要依靠 AP 供應商和行業生態體系的合作方來共同實現。
2.4 功能安全與信息安全
AP 是汽車軟件的一部分，需要運行在 ECU 上。安全性在車輛的開發和應用中具有極高的要求，而隨著車輛中增加了更多的電子控制系統，以及增加了原來沒有的屬性，對于安全性又提出了新的要求。
功能安全在 CP 上已經應用多年，有了一定的應用實踐。而 AP 系統從誕生之日起就要面對功能安全問題，因此在 AP 設計之初就把功能安全作為一個重要的指標提出來。在進行整車功能安全目標分解時，就會分解到 AP 所在 ECU 中，根據應用的領域不同，功能安全的目標要求也不同，但隨著 AP 更多地介入了車輛控制領域，AP 系統的安全等級也會朝最高等級 ASIL- D 發展。
AP 在智能駕駛、車輛網聯領域有更多的應用，這些領域都需要與外部設備和云端進行通信。涉及車輛與外界交互信息時，若沒有信息安全的保障，車輛將完全暴露在黑客面前。近十年來，信息泄露、信息被竊取、車輛被控制的案例屢見不鮮。因此信息安全是車輛的一個關鍵的屬性，保證信息可靠且有效的交互，是 AP 系統的主要特點。AP 在架構、通信、存儲、升級方面使用了不同的加解密方式，目的就是可以抵抗黑客的攻擊。
2.5 動態部署
AP 支持應用程序的動態部署，其中資源和通信是動態管理的，以減少軟件開發和集成的人力，加快軟件開發的迭代速度。
對于產品交付，AP 支持系統集成方對于某些動態行為進行限制，以減少可能產生的不利影響，從而讓系統更安全穩定。應用的動態行為將受到定義在 Execution Manifest 中的約束的限制。
在實際應用中，對軟件的動態運行不加以約束往往會增加系統風險。AP 系統在具體實現中對動態行為進行的必要約束有如下幾種情況：
預先確定服務的發現過程。
只在啟動階段進行動態內存分配。
采用除基于優先級的調度外的公平調度策略。
將進程固定分配給 CPU 核。
只能訪問文件系統中的現有文件。
對應用程序使用 AP API 的限制。
只執行經過認證的代碼。
2.6 敏捷開發過程
AP 的目的是適應不同的產品開發過程，尤其是基于敏捷的開發過程。對于基于敏捷的開發，關鍵是系統的底層架構是可增量擴展的，在系統部署后有可能對其進行更新。AP 的架構應該支持這一點。因此，AP 規范本身和 AP 的演示程序（Adaptive Demostrator）都是用敏捷方式開發的。敏捷開發在互聯網開發中流行，而 AP 的軟件開發與 IT 行業軟件開發有很大的相似度，對硬件的依賴更小。敏捷開發方式可以使軟件迭代更快，更能適應市場對軟件需求的變化。
#03
AUTOSAR CP、AUTOSAR AP 和非 AUTOSAR ECU 的兼容整合
如前幾節所述，AUTOSAR AP 不會取代現有的 AUTOSAR CP 或非 AUTOSAR 平臺。相反，它將與這些平臺和外部后端系統（如路側基礎設施）互動，形成一個綜合系統（見圖 5- 1 和圖 5- 2）。隨著以太網在智能網聯汽車中逐漸成為骨干網絡的基礎設施，AUTOSAR CP、AUTOSAR AP 以及安裝非 AUTOSAR 軟件的 ECU 之間能夠通過 SOA 架構和 SOME/IP 或 DDS 等協議的應用整合在車輛中。
圖 5-1 不同架構平臺的共存
圖 5-2 AP和CP的示范性相互作用
#04
AUTOSAR AP 標準的范圍
AP 定義了運行時系統架構、主要平臺中間件以及中間件功能和接口。同時，AP 還定義了用于開發這種系統的方法學中各種可用工具配置和讀取的模型及文件（主要是 Manifest 形式的 xml 文件）。關于方法學的具體內容，可參考第 6 章。
#05
架構
5.1 邏輯視圖
圖 5-3 所示為 AP 架構邏輯視圖。其中功能集群（Functional Cluster，FC）在圖中的層次關系并不意味著實際的邏輯上下層關系。例如，Diagnostics 位于 Log and Trace 之上并不意味著 Diagnostic 這個 FC 會調用下層 Log and Trace 的功能。AP 的 FC 在邏輯關系上完全是平等的，僅僅因架構圖排版樹圖的需要才出現了層級圖示。在未來的 AP 版本中，很可能會加入更多未在此顯示的 FC。
圖 5-3 AP 架構邏輯視圖
在圖 5- 3 中，自適應應用程序（Adaptive Application，AA）運行在 ARA（AUTOSAR Runtime for Adaptive Applications）之上。ARA 由 FC 提供的 API 組成，如 ara::com。這些 FC 可以分為 AP Foundation 和 Service 兩類。
AP Foundation 為 AA 提供基本功能，與 Machine 和車型都無關，以庫函數或者進程的形式實現。如通信管理（Communication Management，CM）、POSIX OS 接口等。
AP Service 為 AA 提供平臺標準服務，如狀態管理（State Management，SM）、更新配置管理（Update and Configuration Management，UCM）等。與 Foundation 的差異在于 Service 針對特定 Machine，其功能根據配置會有所不同，而且其都是以進程的方式運行的。
在 AP 中，任何 AA 也可以向其他 AA 提供服務，即非平臺服務（Non- PF Service）。FC 的接口，無論是 AP Foundation 還是 AP Service，從 AA 的角度來看，無非都是指定的 C++ API 或 AP 未來可能支持的任何其他語言綁定。
1. 語言綁定、C++標準庫和POSIXAPI
AP 的 API 語言綁定目前只是基于 C++ 的，而且 C++ 標準庫也是 ARA 的一部分。關于操作系統 API，AP 只支持 POSIX PSE51 接口。POSIX 是 IEEE 描述應用程序與操作系統之間接口的標準。應用程序如果按照 POSIX 標準進行編寫，就可以在不同的支持 POSIX 標準的操作系統上進行移植，如 Linux、UNIX。在嵌入式系統中，POSIX 主要應用于復雜嵌入式系統。
POSIX 接口標準根據配置高低分為 4 個等級，分別為 PSE51\~PSE54。PSE51 是 POSIX 標準的最低配置等級，定義了應用程序和操作系統之間最簡單的接口實現方式，適用于以下應用場景：
僅有一個處理器的系統。
系統沒有文件系統或大容量存儲器。
一個應用程序僅能有一個進程，但支持多線程。
不使用內存管理單元（Memory Management Unit，MMU）。
沒有輸入/輸出設備等。
C++ 標準庫（C++ Standard Library，STL）本身包含許多基于 POSIX 的接口，包括多線程接口。一般情況下，不建議把 C++ 標準庫的線程接口和本地 PSE51 的線程接口混合使用，以避免復雜化。然而 C++ 標準庫并沒有涵蓋 PSE51 的所有功能，例如設置一個線程的調度策略，在這種情況下，就有必要將兩者結合使用。
2. 應用程序的啟動和關閉
一個應用程序的加載、啟動、運行、終止等是通過執行管理（Execution Management，EM）這個 FC 的功能來管理的，這需要在系統集成時或在運行時，通過適當的配置告訴 EM 如何管理應用程序的生命周期。事實上，從 EM 的角度來看，除了 EM 本身，其他所有的 FC 都是應用程序，它們的啟動方式也是一樣的。圖 5- 4 所示為 AP 內部和 AP 上不同類型的應用。
圖 5-4 AP內部和AP上不同類型的應用
關于應用程序啟動或終止的決定并不是由EM做出的，而是一個特殊的FC，稱為狀態管理（State Management，SM）。其作用類似于Android系統的生命周期管理。它根據系統的設計指揮EM，對不同的系統狀態進行仲裁，從而控制整個系統的行為。由于這里的系統指的是Machine（即一個虛擬ECU或物理ECU），AP和它的應用程序在其之上運行，因此內部狀態的設計和切換邏輯是項目特定的。SM也與其他FC交互，以協調整個Machine的行為。
3. 應用程序的交互
關于應用程序之間的交互，PSE51不包括進程間通信（Inter- Process- Communication，IPC），所以沒有直接的接口來進行應用程序之間的交互。通信管理（CM）是唯一明確的途徑。CM還為Machine內部和Machine之間提供面向服務的通信，對應用程序屏蔽了通信的細節，類似于CP中的RTE。
CM處理服務請求/回復的路由，而不考慮服務和客戶端應用程序的部署在哪里。其他ARAAPI可以在內部觸發AA之間的交互，但是，這不是基于服務的API，而只是各ARAAPI所提供的功能。
AA和FC可以使用任何非標準API，只要它們不與標準的AP功能相沖突，并且符合項目的安全要求。除非它們是純應用的本地運行庫，否則應注意將這種使用降到最低，因為這將影響軟件在其他AP實現中的可移植性。
5.2 物理視圖
該物理視圖從操作系統、進程和線程，基于庫或基于服務的FC的實現，FC交互規則及Machine與硬件4個維度，明確了AP的物理部署與運行機制，核心內容如下。
1. 操作系統、進程和線程
AP要求基于POSIX操作系統。每個AA都被實現為一個獨立的進程，擁有自己的邏輯內存空間和命名空間。需要注意的是，一個AA可能包含多個進程，這些進程可能部署在一個AP實例上，或分布在多個AP實例上。從模塊組織的角度來看，一個可執行程序在操作系統中運行時會對應一個進程，且它可以被操作系統多次運行以產生多個進程，即一個進程代表一個可執行程序的實例。
FC通常也是作為進程來實現的。一個FC也可以由一個進程或多個進程實現。APService和非APService也被實現為進程。所有這些進程既可以是單線程進程，也可以是多線程進程。然而，它們可以使用的操作系統API是不同的，這取決于這些進程屬于哪個邏輯層。如果它們是運行在ARA之上的AA，那么應該只使用PSE51。總之，從操作系統的角度來看，一個AA對應一個或者多個進程，每個進程都包含一個或多個線程。在同一個Machine內部，AA的進程間只能通過ara::com調用IPC來實現通信。不同Machine之間的AA通過ara::com的SOME/IP或DDS協議棧來實現通信。
2. 基于庫或基于服務的FC的實現
圖5- 3所示的AP架構邏輯視圖中，一個FC可以是APFoundation模塊或APService。FC與AA之間的通信有兩種形式。
一種是“基于庫的設計”。FC為Foundation類型，即函數庫的形式，并提供API接口。在AA開發階段，直接調用FC的API接口，在鏈接時直接將調用的FC庫函數鏈接進AA的可執行文件中，在運行時FC的庫函數作為AA進程的一部分。
另一種是基于服務的設計。FC為Service類型，以進程的形式存在。由于FC和AA都是獨立的進程，因此AA對FC的調用需要采用IPC機制。在這種情況下，AA進程使用CM功能，在開發階段的鏈接過程中將ServerProxy庫鏈接到AA的可執行文件中。運行時，AA內的Proxy庫調用CM的API，由CM來協調AA進程和Server進程之間的IPC。
屬于APFoundation的FC是基于庫的，而APService是基于服務的，如其名稱所示。最后，只要滿足FC定義的需求規范（Requirement Specification，RS）和軟件規范（Software Specification，SWS），允許FC不必產生一個進程，而是以庫的形式實現，在AA進程的背景下運行。在這種情況下，AA和FC之間的交互將是常規的API調用，而不是前面所述的基于IPC的交互。
3. FC交互規則
FC可以是APFoundation或Service。如前所述，它們通常都是進程，需要使用IPC才能與同為進程的AA進行交互。要實現這一點，有兩種可供選擇的設計方案。一種是“基于庫”的設計，即由FC提供鏈接到AA的API庫，并由API直接調用IPC。另一種是“基于服務”的設計，即進程使用CM功能，并將ServerProxy庫鏈接到AA。Proxy庫調用CM的API接口，該接口協調AA進程與Server進程之間的IPC。
選擇FC設計的一般準則是，如果只在本地AP實例中使用，則基于庫的設計更合適，因為它更簡單、更高效。如果在其他Machine的AP實例中以分布式方式調用FC，建議采用基于服務的設計，因為無論客戶AA和服務位于何處，CM都能提供透明的通信。
最后要注意的是，FC并不一定是以進程的方式實現的，還可能是以庫的形式實現，在AA進程的上下文中運行，只要它符合FC定義的RS和SWS即可。在這種情況下，AA與FC之間的交互將是常規的函數調用，而不是前面所述的基于IPC的進程間通信。
4. Machine與硬件
AP將其運行的硬件視為一臺Machine。由于AP可以使用虛擬化技術，Machine可能是一個真實的物理ECU，也可能是一個虛擬ECU，也可能是一個準虛擬化的操作系統、一個操作系統級的虛擬化容器或任何其他的虛擬化環境。在某個ECU硬件上，可以有一個或多個Machine，而且一個Machine上只能運行一個AP實例。一般認為，硬件指的是ECU內的一個處理器，可搭載一個或多個Machine。
5.3 方法學
支持分布式、獨立和敏捷的功能應用開發，需要一個標準化的開發方法。AP方法學將工作產品標準化，用于描述Service、AA、Machine及其配置等，并定義這些工作產品如何實現交互的相應任務，以實現AP產品開發所需的各種活動的設計信息交互。AP啟動順序如圖5- 5所示，這些步驟的細節在第6章有更詳細的描述。
圖 5-5 AP啟動順序
5.4 Manifest
Manifest是AUTOSAR模型描述的一部分，是為了支持AP產品的配置而創建的ARXML文件。Manifest與其他文件（如二進制文件）一起包含在AP產品中。
在AUTOSAR中，除了應用程序設計過程中會創建ARXML外，還有三類與AA和Machine配置相關的Manifest：Execution Manifest、Service Instance Manifest、Machine Manifest。第6章會詳細介紹它們的功能。
#06
本章小結
本章主要對AP做了概述性的介紹，幫助讀者對AP有一個總體的認識。總的來說，AP和CP的區別非常大，CP是針對汽車實時控制系統設計的，而AP則是基于POSIX操作系統，為了適應汽車軟件開發中的配置特點，支持汽車行業的規范和標準而設計的中間件。因此，AP采用了很多計算機軟件開發的理念和方法，例如采用敏捷的開發方式，支持SOA架構，編程方法也采用面向對象的方法。此外，關于開發語言，目前AP采用了 \(\mathrm{C + + }\) ，雖然AUTOSAR標準中開始引入RUST語言，但普及尚需時日，因此在本書中沒有做介紹，感興趣的讀者可以參考相關標準和語言介紹。在本書后續章節中，會對AP的主要特性做更詳細的介紹，本章不再贅述。
