一

AUTOSAR 平臺邏輯體系結構

圖示邏輯體系結構描述了平臺是如何組成的，有哪些模塊，模塊之間的接口是如何工作的。

經典平臺具有分層的軟件體系結構。定義明確的抽象層，每個抽象層都有精確定義的角色和接口。

對于應用程序，我們需要考慮使用的軟件組件，希望它們是可重用的，因此應該盡可能小，依賴性盡可能少。組件被靜態地分配給ECU，并且通過靜態連接發送/接收的信號進行通信。

AUTOSAR實現了軟件和硬件的分離，使得軟件可以在不同的硬件平臺上運行。

AUTOSAR采用了一種統一的XML文件格式，用于描述軟件架構和配置信息。

AUTOSAR具有很高的靈活性，可以根據不同的需求進行定制和擴展。

AUTOSAR支持運行時軟件更新，可以適應不同的應用場景。

AUTOSAR提高了軟件集成的效率和擴展性，使得軟件可以更容易地進行重用和遷移

AUTOSAR為上層開發者提供了標準化的接口和協議，使得開發者可以專注于應用功能的開發。

在軟件開發過程階段，CP與AP都主要都包括以下三個階段：

1.設計階段：

設計ARXML

2.代碼生成：基于ARXML生成代碼

3.集成：集成Application，編譯調試等

二

AUTOSAR AP平臺邏輯體系結構

AP AUTOSAR的核心是自適應應用程序（Adaptive Application），它是一種可以根據運行時環境動態調整的軟件組件。那么，AP AUTOSAR是如何定義和管理自適應應用程序的呢？下面將為你介紹AP AUTOSAR的邏輯視圖和功能集群，詳解自適應應用程序的運行環境。

AP AUTOSAR的邏輯視圖是一種抽象的軟件架構，它描述了自適應應用程序的功能需求，接口，依賴關系和配置。邏輯視圖由多個功能集群（Feature Cluster）組成，每個功能集群包含一組相關的功能需求和接口。功能集群可以進一步劃分為多個功能組（Feature Group），每個功能組包含一組具體的功能需求和接口。功能需求和接口可以使用ARXML文件進行描述和生成。

AP AUTOSAR的功能集群是一種邏輯上的分組，它不代表實際的軟件組件或部署單元。在實際的軟件開發過程中，功能集群需要被映射到具體的軟件組件或部署單元上，這就涉及到AP AUTOSAR的另一個視圖：實現視圖（Implementation View）。實現視圖描述了自適應應用程序的軟件結構，包括軟件組件，部署單元，運行時對象等。實現視圖和邏輯視圖之間的映射關系可以使用ARXML文件進行描述和生成。

AP AUTOSAR的運行環境是一種軟件平臺，它提供了自適應應用程序所需的基礎服務，如通信，配置，診斷，安全等。運行環境由多個服務層（Service Layer）組成，每個服務層提供了一類特定的服務。服務層之間通過面向服務架構（Service Oriented Architecture, SOA）進行交互，即通過發布-訂閱模式（Publish-Subscribe Pattern）進行異步消息傳遞。運行環境可以在不同的硬件平臺和操作系統上運行，通過硬件BSP進行適配。

自適應平臺采用模塊化軟件體系結構。它比經典分層軟件架構更模塊化，反映了平臺的動態特性。這種動態性也是平臺的核心需求；

AP遵循面向服務的架構，SOA設計理念，充分利用各種開源軟件成熟技術，重用軟件市場成熟組件，縮短開發周期。在ECU的生命周期內有獨立更新應用程序的能力。

三

Adaptive PlatformArchitecture

AP AUTOSAR的邏輯視圖體現了其相應的體系結構，如下圖所示：

AP AUTOSAR的邏輯視圖體現了其相應的體系結構，如下圖所示：

lAA（Adaptive Application）

自適應應用程序運行在AUTOSAR Runtime for Adaptive Applications (ARA)之上，用于實現碰撞預警、車道保持、自動駕駛等復雜的汽車功能。AA可以使用C++語言編寫，也可以使用模型驅動開發（Simulink）工具生成。

lARA（AUTOSAR Runtime for Adaptive applications）

自適應應用程序的運行平臺：提供了AA所需的運行時環境，包括內存管理、進程管理、文件安全讀寫、日志記錄等。ARA由功能集群（Functional Clusters，FCs）提供的應用程序接口組成，這些群集屬于Adaptive Foundation或Adaptive Services。Adaptive Foundation提供了AP的基本功能，而Adaptive Services提供了AP的平臺標準服務。

lAdaptive Foundation

提供了AP AUTOSAR的基礎功能，如服務發現、事件發布訂閱、請求回復、持久化數據管理等。這些服務主要是為了實現AA之間以及AA與外部系統之間的面向服務的通信（Service-Oriented Communication，SOC），基于以太網和SOME/IP協議。此外，還包括操作系統接口、執行管理、平臺健康管理（看門狗）、網絡管理、診斷通信、時間同步等。這些功能主要是為了支持ARA和AA的運行。

lAdaptive Services

提供了AP AUTOSAR的標準服務，狀態管理（特定于項目實現），網絡管理，更新配置管理（UCM）即我們比較熟悉的運行時軟件更新（OTA）。

Adaptive AUTOSAR構建在POSIX操作系統之上，ARA可以提供多種功能供應用程序調用來實現軟硬件解耦、為上層應用提供服務。

四

Adaptive AUTOSAR 術語——Machine

Adaptive AUTOSAR是一種基于服務的軟件平臺，它支持高性能、靈活和可更新的汽車應用程序。

Adaptive AUTOSAR的邏輯體系結構是基于Machine的概念構建的，Machine是指運行環境所需的物理資源，如處理器、內存、網絡等。

一個Machine可以包含一個或多個ECU，但只能運行一個AUTOSAR Adaptive Instance（AUTOSAR平臺的實例即AP實例）。每個AP實例都有自己的功能集群，可以實現不同的服務和應用。

在Adaptive AUTOSAR中，Adaptive Application是用C++編寫的，它們在Machine上以進程的形式運行。進程之間通過服務進行通信和協作。

Machine可以是高性能計算機（HPC），它們提供了數據密集型應用所需的計算能力。HPC可以包含多個核心，Adaptive Application可以通過進程到Machine的映射分配到不同的核心上。

一個重要的概念是，AUTOSAR的作用域是Machine，也就是運行環境所依賴的物理資源。每個Machine都有自己獨立的功能集群和服務，它們可以實現不同的汽車應用程序。AUTOSAR也允許在同一個Machine上運行一些非AUTOSAR的進程，但是這些進程不受AUTOSAR平臺實例的管理和約束。

adaptive autosar machine的啟動過程包括哪幾個步驟？

adaptive autosar machine的啟動過程包括哪幾個步驟？

機器啟動，操作系統最先初始化，然后執行管理（EM）作為操作系統的初始進程之一啟動。

EM負責啟動其他功能簇（FC）和平臺應用。

平臺基礎（Foundation）啟動后，EM繼續啟動adaptive應用（AA）。

EM根據machine manifest和execution manifest決定啟動順序。

如果AP從可信錨點（trust anchor）啟動，并且在啟動過程中維護信任鏈（chain of trust），則EM可以支持認證啟動（authenticated startup）。認證啟動啟動過程中，EM驗證應用的真實性和完整性，如檢測出異常，則阻止應用運行。

Adaptive application（AA）：承載Service的應用實體

Executable：App的運行時實體，一個可執行程序可以包含多個服務實例

Process ：OS運行調度的實體

Machine：運行環境的物理資源

AUTOSAR使用ARXML格式文件進行建模 ：

通過正式定義的接口來使用服務

實現服務有三種方式Event Method Field

定義服務傳輸的數據類型

App之間的通信端口，需要在component 元素中定義provide/require Port

adaptive autosar machine的啟動過程涉及到以下幾個概念：

清單是一種用來描述AP AUTOSAR軟件系統的文件，它可以告訴我們怎么安裝和運行軟件。清單文件的格式是XML，它們可以通過ARXML工具進行生成和處理。

清單有三種不同的類型，分別是：

Execution Manifest

Execution Manifest在設計期間創建，提供應用部署所需的信息，定義每個可執行文件實例化幾個進程（幾次），每個進程的的啟動參數、環境變量、UID/GID、資源組、調度策略、何時啟動、停止等都可以獨立配置。

在RTA-VRTE中配置Execution Manifest

添加一個AA進程我們需要做幾方面的配置：

1.配置AA進程相關的FunctionGroupstate

2.選擇AA將要部署在哪個Machine上

3.AA進程的啟動參數和環境變量（依賴的庫和配置文件等信息）

4.AA進程的Log模塊配置

5.AA是否向EM匯報執行狀態

6.設置AA所屬于的Resource Group,來控制AA所在的功能組所占用的內存和cpu使用率。

7.選擇AA進程中的線程的調度算法（FIFO、RR、other）

Machine Manifest

Machine Manifest實際運行在特定硬件（機器）上的adaptive平臺實例的配置，它包含了 machine屬性，特性（資源，功能安全，信息安全等），例如machine state、function group state、resource group、訪問權限組、SOME/IP配置、內存分區、硬件資源，如處理器和核心等等。

每個machine都配置有關function groups、software clusters和process到machine的映射等相關信息。

在RTA-VRTE中配置MachineManifest

在ARXML文件中，我們可以配置Machine的以下屬性和特征：

狀態：Machine的運行狀態，如啟動、停止、重啟等。
進程：Machine的執行單元，如應用邏輯、中斷、函數等。
網絡：Machine的通信方式，如Ethernet等。
服務：Machine的提供或請求的功能，如診斷、校準、更新等。

每個Machine都有自己獨立的功能集群和服務，它們可以實現不同的汽車應用程序。每個Machine需要與一個Machine Design相關聯，Machine Design是用來定義不同Machine之間如何協作和交互的。

下表展示了Machine和Machine Design的關系：

每個Machine都需要至少一個IP配置，因為在網絡中，每個Machine都是一個獨立的end point。IP配置包括IP地址、子網掩碼、網關等信息，用于標識和定位Machine。沒有IP配置，Machine就無法與其他Machine或設備進行通信。

軟件集群（software cluster）一種原子的、可更新的、可擴展的軟件單元，由一個或多個進程組成，實現了一組特定的功能或應用程序。軟件集群的作用是將應用程序和服務按照功能或特性進行分組和管理，提高了開發和部署的靈活性和效率。

軟件集群通常需要配置以下幾項內容：

功能組（Function group）

用來說明軟件集群包含了什么樣的功能，比如導航、泊車、通訊等。

進程

用來執行具體的軟件代碼，比如導航進程、泊車進程、通訊進程等。一個軟件集群可以包含多個進程，但是它們要有相同的功能組。

設計（software cluster design）

用來描述軟件集群的結構和屬性，比如名稱、版本、大小、依賴關系等。

softwareclusterdesign需要和MachineDesign相關聯

softwarecluster需要和softwarecluster design相關聯

Function Group State：功能組狀態，是指一個功能集群（Function Group）的整體狀態，它反映了該功能集群內部所有進程或自適應應用程序的執行狀態的綜合情況。功能組狀態由狀態管理（State Management）模塊控制和監視。

在ARXML文件中，我們可以配置執行管理的以下功能：

·控制進程（Process）的啟動和停止，根據功能組（Function Group）的狀態（Function Group State）。

·定義功能組，需要創建一個新的模式聲明組（Mode Declaration Group），并將它和功能組集（Function Group Set）關聯。功能組集和軟件集群（Software Cluster）關聯。

·在MachineFG中添加Machine的四種狀態：Off、Startup、Restart、shutdown，并將MachineFG設置初始狀態為OFF。

下表展示了功能組和狀態的關系：

MachineFG Function Group Transitions

功能組是一種邏輯分組，用于將具有相同或相似功能的進程聚合在一起。功能組可以有多個狀態，表示該功能組所包含的進程的運行情況。執行管理根據功能組的狀態，決定是否啟動或停止該功能組所包含的進程。這樣可以提高執行效率，節省資源，實現動態調度。

Service Instance Manifest

Service Instance Manifest 主要包含面向服務通信的配置信息，描述針對特定的傳輸協議（如SOME/IP），進行面向服務通信的配置和可執行代碼綁定（服務實例到機器的映射、服務實例到應用端點的映射），還包含基于服務的通信相關信息，如應用層及相應的傳輸層、網絡層通信參數信息。

在RTA-VRTE中配置Service Instance Manifest

Processed Manifest

Execution Manifest和Machine Manifest可以從原始的標準化ARXML轉換為特定于平臺的格式（稱為Processed Manifest處理清單），在機器啟動時可以有效地讀取。

格式轉換可以在集成時在板外或部署時進行，也可以在安裝時在機器上（通過更新和配置管理）進行。

借著狀態轉換圖來介紹一下AP AUTOSAR中用來描述Machine和功能集群的狀態和行為的process state, Execution state, Function Group State, Machine State概念。

它們的含義如下：

process state：

進程狀態，是指一個功能集群（Function Group）內部的一個進程（Process）或者一個AA的生命周期狀態。進程狀態有四種可能的值：未創建（NotCreated）、創建中（Creating）、已創建（Created）和銷毀中（Destroying）。進程狀態由進程管理（Process Management）模塊控制和監視。

Execution state：

執行狀態，是指一個功能集群（Function Group）內部的一個進程（Process）或者一個AA的運行狀態。執行狀態有四種可能的值：未啟動（NotStarted）、啟動中（Starting）、運行中（Running）和停止中（Stopping）。執行狀態由執行管理（Execution Management）模塊控制和監視。

Function Group State：

功能組狀態，是指一個功能集群（Function Group）的整體狀態，它反映了該功能集群內部所有進程或自適應應用程序的執行狀態的綜合情況。功能組狀態有五種可能的值：未啟動（NotStarted）、啟動中（Starting）、運行中（Running）、停止中（Stopping）和已停止（Stopped）。功能組狀態由狀態管理（State Management）模塊控制和監視。

Machine State：

機器狀態，是指一個Machine的整體狀態，它反映了該Machine上所有功能集群的功能組狀態的綜合情況。機器狀態有幾種可能的值：未啟動（Off）、啟動（Startup）、關機（Shutdown）和重啟（Restart）。機器狀態通常會引用功能組狀態。

狀態金字塔

五

Adaptive AUTOSAR 平臺架構

在AP架構下，同一臺機器上的自適應應用程序都實現為一個獨立的進程，都有自己的邏輯內存和命名空間相互隔離，以確保相互不受干擾。這是由操作系統的MMU內存管理單元提供的。這也是AP模塊化的由來。

單個AA可能包含一個或多個進程，可以部署到單個AP實例上，也可以分布在多個AP實例上。從模塊來看，每個進程都是由操作系統從可執行文件中實例化的，一個可執行文件可實例化多次。這些進程都是運行在操作系統之上的，進程是動態運行的，何時調用、進程生存周期、資源占用及進程結束等，都是系統動態管理，好比你手機上的App何時打開、運行后其會調用的資源及何時關閉都是動態進行的。

AP平臺需要提供相關模塊的SDK和守護進程等。應用程序可以調用SDK提供的API來調用模塊的功能，比如應用程序之間的通信，我們可以調用COM模塊提供的API，可以進行片內或片間通信。

這跟CP架構有著顯著的區別，在CP架構下，所有應用都是靜態配置的，即應用的進程在OS中被寫死，軟件功能在編譯階段就確定了，其調用的周期也是確定，因此基于CP架構的軟件一旦有小的應用變更就得重新配置和編譯。

應用程序的加載/啟動是通過使用EM的功能進行管理的，并且需要在系統集成或運行時進行適當的配置才能啟動應用程序，軟件功能在運行時才可以確定。從EM的角度來看，所有功能集群都是應用程序。

Adaptive autosar是一種用于高性能計算ECU的軟件平臺，它支持自適應應用程序的開發和運行1。它由兩部分組成：基礎（Foundation）和服務（Service）。基礎包括了操作系統接口、執行管理、網絡管理、識別訪問管理、加密、更新和配置管理等功能。服務包括了通信管理、RESTful、時間同步、診斷、狀態管理、持久性、平臺健康管理、日志和跟蹤等功能。

Adaptive autosar各模塊的功能如下：

執行管理 execution management (EM)

功能描述：EM負責系統執行管理的所有方面，包括平臺初始化和應用的啟動和關閉。EM和OS一起工作執行應用運行時間的調度。

AP AUTOSAR執行管理模塊可以實現以下功能：

1.啟動和關閉Machine，配置和加載應用程序，處理啟動和關閉過程中的錯誤和異常。

2.控制應用程序的執行狀態，設置應用程序的調度參數，監控應用程序的狀態、資源、性能，處理應用程序之間的同步和通信。

3.管理功能組的狀態，實現功能組之間的協調和一致性，根據不同的場景和需求，動態地切換功能組的狀態。

4.處理平臺和應用程序中發生的錯誤和異常，根據不同的錯誤類型和嚴重程度，采取相應的恢復措施。

狀態管理（State Management）

功能描述：

SM模塊（State Management）是一種實現狀態管理和事件處理功能的軟件組件。SM模塊負責所有和AP平臺運行狀態相關的方面。

主要功能：

?處理輸入的事件，如診斷請求、喚醒事件、錯誤恢復等，并根據事件類型和優先級來設置內部狀態。

?將自適應應用程序進程分配到功能組狀態(inc. the Machine State)

?根據狀態更改啟動/停止應用程序

?AUTOSAR觸發器接口——用于提示狀態更改

?AUTOSAR ara::StateClient API

?與ara::diag, ara::exec, ara::nm & ara::ucm模塊的交互

執行管理與SM的交互

核心類型：Core TYPES：

功能描述：

定義了多個FCs的公共類接口和公共功能。包括接口定義中經常使用的常見復雜數據類型。

主要功能：

?由于AP平臺它具有功能安全的屬性，通常而言我們是不可以使用C++的異常機制的（由于ASIL認證的c++編譯器缺乏異常支撐），因此AP平臺它引入了ara::ErrorCode錯誤碼以及ara::Result的概念。允許進程在不拋出異常的情況下進行錯誤處理。

?AP還定義了一些了增強的數據類型，這些數據類型統一封裝在了ARA：：core的命名空間。包括AP自己的內存分配相關的數據類型如：Vector、Map和String，以及Manifest中一些constructs用到的類型如StringView，Span，Optional和Variant。

?全局初始化函數，ara::Initialize和ara:: Deinitialize,此調用必須在main()內部進行。

操作系統接口OSI

功能描述：

AUTOSAR Adaptive platform(AP)運行在高性能處理器上，直接基于通用的操作系統。

操作系統接口的要求如下：

1.OS提供符合PSE51標準的POSIX兼容的API接口。

2.OS支持周期性時間觸發的執行功能，進程中的算法可以是時間觸發的。

3.OS需要提供允許應用程序的時間觸發執行的機制。觸發因素需要至少但不限于包含外部計時器。

4.OSI支持C++11，AP進程是用C++編寫的，接口應該符合c++11

5.OS支持把EM拉起作為第一個執行進程。

6.OS支持為進程或進程組配置內存和CPU資源預算。

7.OS提供進程綁定到CPU Core的機制。

8.OS支持軟件實體對系統對象訪問的權限管理機制，應用進程只能通過授權的系統調用來

9.OS提供多進程，以便支持應用程序隔離。

通信管理（Communication Management）

功能描述：

通信管理模塊是一個用于實現服務導向通信的模塊，它支持多種通信協議，如SOME/IP, DDS, IPC等。

主要功能：

1.將協議無關的服務導向通信映射到配置的協議綁定，并執行相應的協議。應用程序代碼使用服務導向通信的API，而不需要關心底層的協議細節。

2.支持服務發現、服務注冊、服務請求、服務響應等功能，實現不同的通信模式和質量，如點對點、發布訂閱、可靠、實時等。

3.支持事件、方法和字段三種類型的服務，實現不同的數據交換和遠程調用功能。事件用于發布和訂閱數據，方法用于請求和響應數據，字段用于獲取和設置數據。

4.支持端到端通信保護，使用E2E機制對通信數據進行校驗和保護，防止數據被篡改或丟失。

5.支持網絡管理，使用NM機制對網絡狀態進行監控和控制，實現網絡節點的加入和退出，以及網絡喚醒和休眠等功能。

6.支持安全通信，使用加密、簽名、認證等技術保證通信的機密性、完整性和可信性。

診斷管理（Diagnostics）

功能描述：

診斷管理模塊（DM）是一種實現基于ISO 14229-1（UDS）和ISO 13400-2（DoIP）的ISO 14229-5（UDSonIP）的診斷服務的軟件組件。DM代表Foundation層上AP平臺的功能集群，支持多個診斷客戶端和多個軟件集群。

每個SWCL是一個單獨的軟件更新包， SWCL都可以創建自己的診斷服務器實例，每個診斷服務器都有自己的診斷地址和服務，可以獨立地進行診斷操作 。每個診斷服務器都需要一個數據庫和一個文本文件（ru:candela文件）來配置其功能 。

主要功能：

1.診斷通信：實現診斷服務器的功能，支持一些標準的UDS服務，如例行控制、數據標識符、故障碼讀取和清除等。DM模塊還可以將診斷請求調度到相應的自適應應用程序，以便執行特定的診斷操作。

2.事件存儲：負責故障診斷代碼（DTC）的管理，包括DTC的存儲、更新、刪除、啟用和禁用等。DM模塊還可以管理DTC相關的快照記錄和擴展數據記錄，以及提供內部轉換的通知。

3.傳輸層：支持DoIP作為傳輸協議，實現車輛發現和診斷通信。DoIP是一種基于IP網絡的車輛診斷協議，可以與診斷基礎設施（如診斷客戶端、生產/車間測試儀）進行車外通信。

網絡管理（Network Management）

Architecture overview with example applications

功能描述：

NM是一種網絡管理機制，用于控制和協調負責協調內部協調狀態機中基礎網絡（部分網絡，VLAN或物理通道）的正常運行和總線睡眠模式之間的轉換。它的目的是在滿足ECU節點正常通信需求的情況下，又能節省汽車蓄電池電量。

Overview Of Network Management

主要功能：

1.網絡請求和釋放：NM模塊為狀態管理提供了一個服務接口，用于請求和釋放網絡以及查詢其實際狀態。NM模塊協調不同實例（網絡句柄）的請求，并通過網絡提供匯總的計算機請求。

2.網絡狀態監測：NM模塊通過周期性的NM消息來監測網絡狀態，包括喚醒、準備睡眠、睡眠等。NM消息的接收指示發送節點要保持NM群集處于喚醒狀態。如果任何節點準備好進入睡眠模式，它將停止發送NM消息，但是只要接收到來自其他節點的NM消息，它將推遲過渡到睡眠模式。最后，如果由于不再接收NM消息而經過了專用計時器，則每個節點都將執行到睡眠模式的轉換。

3.部分網絡管理：如果使用了部分網絡功能，則NM消息可以包含部分網絡（PN）請求，從而使ECU可以忽略不請求與ECU相關的任何PN的NM消息。盡管在其他部分網絡中仍在進行通訊，但這可以關閉ECU（或其部分）。

身份識別訪問管理（Identify Access Management）

功能描述：

身份識別訪問管理塊（IAM）是一種實現基于策略的訪問控制功能的軟件組件。IAM模塊為應用程序提供權限隔離以及受攻擊時權限越級的保護功能，同時，IAM模塊還能方便集成人員在部署時就能驗證應用對于資源的訪問權限。

主要功能：

1.訪問控制決策：IAM模塊通過Policy Decision Point（PDP）基于訪問控制策略來決定應用是否被允許執行請求動作。訪問控制策略是一些約束條件，描述了訪問特定資源或服務需要哪些Capability。Capability是應用身份信息的一個屬性，在定義Application Manifest時，開發者為每個應用分配對應的Capability。

2.訪問控制執行：IAM模塊通過Policy Enforcement Point（PEP）在應用提出請求時中斷控制流，向PDP請求訪問控制決策并根據決策返回的布爾值進行對應操作。PEP可以實現對Service、Foundation FC以及相關模型資源的訪問控制。

3.應用身份識別：IAM模塊通過Execution Management（EM）模塊獲取應用身份信息，以便進行訪問控制決策和執行。EM模塊會根據模型信息，去創建Adaptive應用的運行實例，所以EM也需要去負責追蹤運行進程的屬性，也即正在運行的應用的PID、UID、Key或UUID。

加密（Cryptography）

High level architecture of Cryptography

功能描述：

加密模塊（Crypto）是一種實現通用加密操作和安全密鑰管理的軟件組件。Crypto模塊支持在運行時動態生成密鑰和加密作業，以及對數據流進行操作。為了減少存儲需求，可以將密鑰內部存儲在加密后端中，也可以外部存儲并按需導入。Crypto模塊旨在支持將對安全敏感的操作和決策封裝在單獨的組件中，例如硬件安全模塊（HSM）。

主要功能：

1.加密操作：Crypto模塊提供了一系列標準化的加密算法和模式，用于對數據進行加密、解密、簽名、驗證等操作。Crypto模塊支持對稱加密（例如AES、DES、3DES等）、非對稱加密（例如RSA、ECC等）、哈希函數（例如SHA-1、SHA-2、SHA-3等）、消息認證碼（例如HMAC、CMAC等）和數字簽名（例如ECDSA、RSA-PSS等）。

2.密鑰管理：Crypto模塊提供了一系列標準化的接口和服務，用于管理密鑰的生成、存儲、導入、導出、更新、刪除等操作。Crypto模塊支持本地密鑰生成和基于現有供應密鑰的端到端保護的密鑰引入。Crypto模塊還支持對密鑰進行訪問控制和使用限制，以提高密鑰的安全性。

3.證書管理：Crypto模塊提供了一系列標準化的接口和服務，用于管理證書的生成、存儲、導入、導出、驗證等操作。Crypto模塊支持X.509證書格式，以及基于PKCS#7或PKCS#10的證書請求和響應。

日志和跟蹤（Log & Trace）

功能描述：

一種實現日志記錄和追蹤功能的軟件組件。Log模塊可以在開發期間以及生產中和生產后使用日志記錄和追蹤功能，以便對自適應平臺的運行狀態進行監測和分析。

主要功能：

?本地日志 (輸出到控制臺或文件)日志記錄,Log模塊提供了一系列標準化的方法，用于向不同的日志接收器發送日志信息，例如通信總線、系統上的文件和串行控制臺等。Log模塊支持多種日志級別，例如錯誤、警告、信息、調試等，以及多種日志格式。Log模塊還可以自動在日志信息中添加時間戳和其他元數據，以便進行排序和過濾。

?遠程日志記錄（使用DLT協議）,Log模塊提供了一種基于DLT協議的追蹤功能，用于對自適應平臺的運行時行為進行分析和優化。DLT協議是一種標準化的交付和表示格式，可以將日志信息打包為標準化的幀，并添加一些額外的信息，例如ECU ID、軟件集群ID等。Log模塊可以將LT幀發送到追蹤工具或其他設備，以便進行可視化和分析。

更新配置管理UCM

功能描述：

為了支持Adaptive Platform上軟件的更改，更新和配置管理器（UCM）提供了處理軟件更新請求的Adaptive Platform服務。

主要功能：

UCM可以接收來自后端服務器或診斷測試儀的軟件更新請求，負責在自適應平臺上安裝、更新、刪除和保留軟件記錄。

UCM可以處理不同格式和類型的軟件包，包括完整包、增量包、后端包、車輛包等，根據軟件包清單中的元數據和依賴關系，執行相應的操作。

UCM可以與UCM主服務器協作，以在車輛內部分發和協調多個UCM客戶端的軟件包，實現軟件的一致性和同步。

UCM可以在軟件安裝或更新后，執行激活或回退操作，確保軟件的可靠性和安全性。

UCM可以提供軟件的版本信息、狀態信息、錯誤信息等，供客戶端查詢和監控。

PHM模塊（Platform Health Management）

功能描述：

PHM是一種實現平臺健康管理和功能安全功能的軟件組件。PHM模塊監控運行的應用程序，當受監控實體發生錯誤/故障時，PHM模塊可以觸發恢復操作。恢復操作具體由集成人員根據平臺軟件架構需求，在Manifest文件當中定義。

主要功能：

?全局和本地監督（Global and local supervision）
?邏輯監督（Logical supervision）
?恢復操作 （Recovery actions）
?存活監督（Alive supervision）
?截止日期監控（Deadline monitoring ）

持久化（Persistence）

功能描述：

Persistence模塊是一種讓自適應平臺的軟件可以保存和讀取數據的軟件組件。它可以把數據存儲在不會丟失的存儲器中，即使車輛關機或重啟也不會影響。它提供了一個統一的接口，讓軟件可以方便地訪問不同的存儲位置。

主要功能：

?鍵值存儲（Key-Value storage）
?文件代理訪問（File proxy access）
?并行訪問數據（Parallel access to data）

?持久數據的安裝、更新和回滾（Installation, Update and Rollback of Persistent Data）

時間同步(ara::tsync)

功能描述：

ara::tsync它提供了時間同步的功能，使得不同的節點可以共享一個全局的時間基準。ara::tsync的主要特點有：
?基于服務的架構，可以動態地發現和訂閱不同的時間基準資源，如全局時間主節點或從屬時間基準節點。
?支持多種網絡綁定，如SOME/IP、REST、DDS等，以適應不同的通信需求和場景。
?支持即時時間同步和延遲時間同步兩種模式，分別用于高精度和低精度的時間同步需求。
?支持用戶數據的傳輸，可以在時間同步消息中附加額外的信息，如診斷數據、配置數據等。

主要功能：

?啟動和關閉 （Startup & shutdown）
?時間校正 （Time correction）
?時基提供者和使用者模式 （Time base provider and consumer modes）

入侵檢測系統管理(ara::idsm)

IDS Overview

功能描述：

ara::idsm它提供了入侵檢測系統管理的功能，使得不同的安全傳感器可以向它報告安全事件，并對安全事件進行過濾和處理。ara::idsm的主要特點有：
?基于服務的架構，可以動態地發現和訂閱不同的安全事件資源，如入侵檢測系統主節點或從屬入侵檢測系統節點。
?支持多種網絡綁定，如SOME/IP、REST、DDS等，以適應不同的通信需求和場景。
?支持用戶定義的診斷事件內存，可以將安全事件存儲在獨立于主診斷事件內存的內存中。
?支持用戶數據的傳輸，可以在安全事件消息中附加額外的信息，如診斷數據、配置數據等。

主要功能：

?事件生成 (Event generation)
?報告模式(Reporting modes)
?過濾器鏈條 (Filter chains)
?QSevs的傳播和認證(Propagation & authentication of Qsevs)
?Rate and traffic limitation
?訪問控制（包括診斷訪問）Access control (including diagnostic access)

防火墻(ara::fw)

Architecture of the FC Firewall (圖片來自AUTOSAR官網)

功能描述：

ara::FW是AP AUTOSAR中的一個模塊，它提供了防火墻的功能，使得不同的節點可以根據防火墻規則來控制網絡訪問和通信。

ara::FW的主要特點有：

基于服務的架構，可以動態地發現和訂閱不同的防火墻資源，如防火墻主節點或從屬防火墻節點。

支持多種網絡綁定，如SOME/IP、REST、DDS等，以適應不同的通信需求和場景。

支持用戶定義的防火墻規則，可以在運行時動態地修改和應用防火墻規則，以適應不同的車輛狀態或外部系統的變化。

支持用戶數據的傳輸，可以在防火墻消息中附加額外的信息，如診斷數據、配置數據等。

審核編輯：劉清