AUTOSAR AP平臺核心技術(shù)解析

本文主要分享執(zhí)行管理和狀態(tài)管理以及操作系統(tǒng)接口模塊，這些功能集群是Adaptive AUTOSAR的核心部分。你們可能會問，什么是執(zhí)行管理和狀態(tài)管理？它們是不是很復(fù)雜很高深？其實不然，它們就像是你的汽車的大腦和心臟，它們控制著你的汽車軟件的啟動、運(yùn)行和停止，以及與你的汽車的操作系統(tǒng)的溝通。

AP平臺是AUTOSAR為了讓你的汽車變得更強(qiáng)大更靈活而制定的一種軟件架構(gòu)標(biāo)準(zhǔn)，它由多個功能集群組成，每個功能集群都有自己的特色和作用。在這篇文章中，將向你解釋這些功能集群的基本概念、功能、原理和實現(xiàn)方式，以及它們在汽車軟件開發(fā)中的作用和價值。希望你能通過閱讀這篇文章，對Adaptive AUTOSAR有一個更深入的了解，也能夠在你的工作中更好地應(yīng)用它。讓我們開始吧。

本文將從以下六個方面來介紹這兩個模塊：

1.執(zhí)行管理模塊：介紹執(zhí)行管理模塊的職責(zé)和功能，以及它如何根據(jù)Manifest文件來初始化和管理平臺和應(yīng)用。

2.確定性執(zhí)行：介紹執(zhí)行管理模塊如何提供DeterministicClient API來支持?jǐn)?shù)據(jù)確定性執(zhí)行，以及如何與軟件鎖步框架協(xié)作。

3.狀態(tài)管理模塊：介紹狀態(tài)管理模塊的職責(zé)和功能，以及它如何定義和管理Machine State和Function Group State。

4.執(zhí)行管理和狀態(tài)管理的交互：介紹執(zhí)行管理模塊和狀態(tài)管理模塊如何通過SetState和ReportExecutionState API來協(xié)調(diào)平臺和應(yīng)用的狀態(tài)轉(zhuǎn)換。

5.操作系統(tǒng)接口：介紹執(zhí)行管理模塊如何與操作系統(tǒng)交互，以及如何使用操作系統(tǒng)提供的資源和服務(wù)。

6.如何編寫一個自適應(yīng)應(yīng)用程序：介紹如何遵循AUTOSAR規(guī)范和編程標(biāo)準(zhǔn)來編寫一個符合AP平臺要求的自適應(yīng)應(yīng)用程序，并向執(zhí)行管理匯報狀態(tài)。

第一部分

1 執(zhí)行管理（EM）

Execution Management（EM）是Adaptive Platform的核心部分，它負(fù)責(zé)管理Machine的生命周期，包括啟動、關(guān)閉、重啟等。EM還負(fù)責(zé)管理Function Groups的狀態(tài)，F(xiàn)unction Groups是一組相互關(guān)聯(lián)，需要統(tǒng)一控制的進(jìn)程的集合。EM還負(fù)責(zé)解析Execution Manifest和Machine Manifest，這些文件描述了Machine的配置和屬性，以及進(jìn)程的依賴和優(yōu)先級等。

1.1 執(zhí)行管理模塊涉及到AP平臺的多個方面

執(zhí)行管理模塊（Execution Management，EM）是自適應(yīng)平臺和應(yīng)用程序的執(zhí)行管理的核心部分，它負(fù)責(zé)平臺和應(yīng)用程序的初始化、啟動、關(guān)閉、狀態(tài)轉(zhuǎn)換、確定性執(zhí)行等功能。

執(zhí)行管理模塊根據(jù)Machine Manifest和Execution Manifest中的信息來管理平臺和應(yīng)用程序的生命周期，這些信息包括應(yīng)用程序的屬性、依賴、資源、優(yōu)先級、狀態(tài)等。

執(zhí)行管理模塊提供DeterministicClient API來支持?jǐn)?shù)據(jù)確定性執(zhí)行，即保證在給定的輸入數(shù)據(jù)下，應(yīng)用程序能夠在有限時間內(nèi)產(chǎn)生一致的輸出結(jié)果。執(zhí)行管理模塊還可以與軟件鎖步框架協(xié)作，以確保冗余運(yùn)行的進(jìn)程的行為一致。

執(zhí)行管理模塊與狀態(tài)管理模塊（State Management，SM）密切交互，以協(xié)調(diào)平臺和應(yīng)用程序的狀態(tài)轉(zhuǎn)換。狀態(tài)管理模塊定義和管理Machine State和Function Group State，分別表示機(jī)器的運(yùn)行階段和功能組的運(yùn)行條件。執(zhí)行管理模塊根據(jù)狀態(tài)管理模塊的請求，啟動或停止相應(yīng)的進(jìn)程或功能組。

執(zhí)行管理模塊與操作系統(tǒng)接口，以使用操作系統(tǒng)提供的資源和服務(wù)，如內(nèi)存、CPU、調(diào)度、文件系統(tǒng)等。執(zhí)行管理模塊還與其他功能模塊，如診斷管理、升級管理、網(wǎng)絡(luò)管理等進(jìn)行交互，以響應(yīng)不同的事件和請求。

執(zhí)行管理模塊遵循AUTOSAR規(guī)范和編程標(biāo)準(zhǔn)，要求自適應(yīng)應(yīng)用程序（Adaptive Application，AA）也遵循相同的規(guī)范和標(biāo)準(zhǔn)，使用ARA（AUTOSAR Runtime for Adaptive applications）作為接口，向執(zhí)行管理模塊報告狀態(tài)和事件。執(zhí)行管理模塊還負(fù)責(zé)驗證應(yīng)用程序的可信度和完整性，以保證安全性和可靠性。AP平臺的執(zhí)行管理模塊:是一個負(fù)責(zé)管理平臺和應(yīng)用的生命周期和資源的功能集群。

執(zhí)行管理模塊除了與操作系統(tǒng)接口，還與其他功能模塊，如診斷管理（Diagnostic Management，DM）, 升級管理（Update configuration Management，UCM）, 網(wǎng)絡(luò)管理（Network Management，NM）等進(jìn)行交互，以響應(yīng)不同的事件和請求。這些功能模塊提供了一些特定的服務(wù)和API，用于實現(xiàn)平臺和應(yīng)用程序的診斷、升級、通信等功能。執(zhí)行管理模塊可以通過調(diào)用這些服務(wù)和API，或者注冊回調(diào)函數(shù)，來與這些功能模塊進(jìn)行協(xié)作和協(xié)調(diào)。

將從以下幾個方面來詳細(xì)展開：

1.2 Execution Management（EM）概述

執(zhí)行管理是自適應(yīng)平臺基礎(chǔ)的一個功能模塊，它負(fù)責(zé)平臺的初始化和管理模型化進(jìn)程的生命周期。模型化進(jìn)程是一種獨立的可執(zhí)行單元，它可以自主控制內(nèi)部線程的創(chuàng)建和銷毀。

執(zhí)行管理根據(jù)清單文件中的信息來執(zhí)行這些操作，例如何時以及以何種方式啟動或停止模型化進(jìn)程。執(zhí)行管理還支持狀態(tài)管理、確定性執(zhí)行和安全性等功能。

執(zhí)行管理是AUTOSAR自適應(yīng)平臺的組成部分，但它并不是AUTOSAR系統(tǒng)的唯一部分，因為車輛中還有許多基于AUTOSAR經(jīng)典平臺的ECU。因此，車輛的系統(tǒng)設(shè)計需要考慮AUTOSAR經(jīng)典平臺ECU和AUTOSAR自適應(yīng)平臺機(jī)器的協(xié)同工作。

執(zhí)行管理的基本概念:

執(zhí)行管理是指用于管理應(yīng)用程序的執(zhí)行過程的軟件模塊。

執(zhí)行管理負(fù)責(zé)管理應(yīng)用的啟動、運(yùn)行和停止等過程。

執(zhí)行管理的功能和作用:

啟動和關(guān)閉Machine，配置和加載應(yīng)用程序，處理啟動和關(guān)閉過程中的錯誤和異常。

控制應(yīng)用程序的執(zhí)行狀態(tài)，設(shè)置應(yīng)用程序的調(diào)度參數(shù)，監(jiān)控應(yīng)用程序的狀態(tài)、資源、性能，處理應(yīng)用程序之間的同步和通信。

管理功能組的狀態(tài)，實現(xiàn)功能組之間的協(xié)調(diào)和一致性，根據(jù)不同的場景和需求，動態(tài)地切換功能組的狀態(tài)。

處理平臺和應(yīng)用程序中發(fā)生的錯誤和異常，根據(jù)不同的錯誤類型和嚴(yán)重程度，采取相應(yīng)的恢復(fù)措施。

從AP的整體架構(gòu)來看：

執(zhí)行管理是AUTOSAR AP 平臺的核心功能模塊之一，如圖中的1，2，3所示，執(zhí)行管理模塊與POSIX的操作系統(tǒng)接口和狀態(tài)管理有著密不可分的關(guān)系。

執(zhí)行管理與其他應(yīng)用程序一樣，本質(zhì)上是POSIX的操作系統(tǒng)上運(yùn)行的進(jìn)程。

執(zhí)行管理是AUTOSAR AP平臺的進(jìn)程創(chuàng)建的入口點，由操作系統(tǒng)在系統(tǒng)啟動期間，啟動執(zhí)行管理這個進(jìn)程。

執(zhí)行管理負(fù)責(zé)啟動所有功能集群、自適應(yīng)AUTOSAR服務(wù)和用戶級應(yīng)用程序的進(jìn)程。

執(zhí)行管理管理進(jìn)程的能力是指在AP AUTOSAR平臺中，能夠有效地實施和執(zhí)行平臺初始化、啟動和停止所有功能集群、自適應(yīng)AUTOSAR服務(wù)和用戶級應(yīng)用程序的進(jìn)程。

換句話說，執(zhí)行管理可以根據(jù)我們配置出來的manifest文件來啟動和停止功能組中配置的進(jìn)程，即EM控制進(jìn)程怎么運(yùn)行。

執(zhí)行管理需要通過與操作系統(tǒng)交互，為應(yīng)用程序提供了靈活的運(yùn)行時調(diào)度機(jī)制，支持多進(jìn)程和多線程的能力。支持多進(jìn)程的原因之一是要實現(xiàn)不同功能集群和AA之間的“無干擾”。

執(zhí)行管理還支持狀態(tài)管理、資源限制、應(yīng)用恢復(fù)和可信平臺、確定性執(zhí)行的功能，以保證系統(tǒng)的可靠性和穩(wěn)定性。

執(zhí)行管理模塊和狀態(tài)管理模塊之間的區(qū)別主要有以下幾點：

執(zhí)行管理模塊負(fù)責(zé)平臺和應(yīng)用的初始化、啟動和停止，以及相關(guān)的配置和管理，而狀態(tài)管理模塊負(fù)責(zé)定義和控制平臺和應(yīng)用的運(yùn)行狀態(tài)和狀態(tài)轉(zhuǎn)換。

執(zhí)行管理模塊依賴于Machine Manifest和Execution Manifest來確定應(yīng)用的啟動和停止順序，以及應(yīng)用的依賴關(guān)系和優(yōu)先級，而狀態(tài)管理模塊依賴于功能組和功能組狀態(tài)來確定當(dāng)前運(yùn)行的進(jìn)程集合。

執(zhí)行管理模塊提供了一些功能來支持確定性執(zhí)行、資源限制、應(yīng)用恢復(fù)和可信平臺，而狀態(tài)管理模塊沒有這些功能。

執(zhí)行管理模塊和狀態(tài)管理模塊之間有一定的協(xié)作關(guān)系，例如執(zhí)行管理模塊需要根據(jù)狀態(tài)管理模塊的請求來啟動或停止進(jìn)程，而狀態(tài)管理模塊需要根據(jù)執(zhí)行管理模塊的反饋來更新狀態(tài)。

執(zhí)行管理模塊與操作系統(tǒng)接口的主要方式有以下幾種：

通過系統(tǒng)調(diào)用（System Call）來請求操作系統(tǒng)的服務(wù)，例如創(chuàng)建、銷毀、啟動、停止進(jìn)程，分配、釋放、映射內(nèi)存，打開、關(guān)閉、讀寫文件，發(fā)送、接收網(wǎng)絡(luò)數(shù)據(jù)等。系統(tǒng)調(diào)用是操作系統(tǒng)提供的一組標(biāo)準(zhǔn)的函數(shù)或指令，它們可以讓執(zhí)行管理模塊在用戶態(tài)切換到內(nèi)核態(tài)，從而訪問操作系統(tǒng)的內(nèi)部資源和功能。

通過信號（Signal）來接收操作系統(tǒng)的通知，例如進(jìn)程終止、內(nèi)存錯誤、中斷、異常等。信號是操作系統(tǒng)提供的一種異步的事件通知機(jī)制，它可以讓執(zhí)行管理模塊在收到信號后執(zhí)行相應(yīng)的處理函數(shù)，從而響應(yīng)操作系統(tǒng)的狀態(tài)變化。

通過共享內(nèi)存（Shared Memory）來與操作系統(tǒng)共享數(shù)據(jù)，例如進(jìn)程間通信、內(nèi)存映射文件、共享庫等。共享內(nèi)存是操作系統(tǒng)提供的一種高效的數(shù)據(jù)交換方式，它可以讓執(zhí)行管理模塊在不進(jìn)行數(shù)據(jù)復(fù)制的情況下，直接訪問操作系統(tǒng)或其他進(jìn)程的內(nèi)存空間，從而提高性能和節(jié)省資源。

1.3 與執(zhí)行管理相關(guān)的組件

執(zhí)行管理（EM）可以控制和管理自適應(yīng)應(yīng)用程序的運(yùn)行

它依賴以下幾個組件來實現(xiàn)它的功能：

1. 應(yīng)用恢復(fù)管理器：它可以通過PHM檢測應(yīng)用程序的故障，并根據(jù)Execution Manifest文件中的設(shè)置，對應(yīng)用程序進(jìn)行恢復(fù)操作，如重啟、替換或終止。

2. 操作系統(tǒng)接口：它可以通過這些接口調(diào)用操作系統(tǒng)的基本服務(wù)，如進(jìn)程管理、信號處理等。EM是一個與操作系統(tǒng)無關(guān)的抽象層，可以在不同的操作系統(tǒng)上運(yùn)行。

3. 資源管理：它可以分配和釋放系統(tǒng)資源，并監(jiān)控資源的使用情況。它可以根據(jù)Machine Manifest文件中的設(shè)置，對應(yīng)用程序進(jìn)行資源限制和隔離。

4. 狀態(tài)管理：它可以管理應(yīng)用程序的狀態(tài)和生命周期，并與其他軟件組件進(jìn)行交互。

1.4 什么是自適應(yīng)應(yīng)用程序

自適應(yīng)應(yīng)用程序（Adaptive Application，AA）是一種運(yùn)行在AUTOSAR自適應(yīng)平臺（Adaptive Platform，AP）上的軟件組件，它可以實現(xiàn)高性能的計算和通信功能，例如自動駕駛、車聯(lián)網(wǎng)等。自適應(yīng)應(yīng)用程序可以根據(jù)運(yùn)行時的需求和條件，動態(tài)地調(diào)整其行為和配置，例如支持無線更新、服務(wù)發(fā)現(xiàn)、故障管理等。自適應(yīng)應(yīng)用程序通過ARA（AUTOSAR Runtime for Adaptive applications，自適應(yīng)應(yīng)用程序的運(yùn)行平臺）與AP的功能集群（Function Clusters，F(xiàn)Cs）進(jìn)行交互，使用服務(wù)和API作為接口。

提供給自適應(yīng)應(yīng)用程序的編程接口集合稱為AUTOSAR Runtime for Adaptive (ARA)。

（圖片來自網(wǎng)絡(luò)）

自適應(yīng)應(yīng)用程序總是建立在中間件層之上，中間件層是一些提供基礎(chǔ)服務(wù)和功能的模塊。這樣做的好處是，自適應(yīng)應(yīng)用程序可以方便地移植到不同的平臺上，也可以重復(fù)使用已有的代碼。自適應(yīng)應(yīng)用程序是根據(jù)功能需求來開發(fā)的，它只使用AUTOSAR定義的API，這些API是一些通用的接口，可以讓不同的應(yīng)用程序互相協(xié)作。自適應(yīng)應(yīng)用程序也要按照編碼指南來編寫代碼，這些指南是一些規(guī)范和建議，可以讓代碼更清晰和規(guī)范。

自適應(yīng)應(yīng)用程序是實現(xiàn)應(yīng)用功能的軟件單元，它是功能開發(fā)的成果，也是針對特定機(jī)器進(jìn)行配置和集成的軟件組件。配置和集成就是根據(jù)機(jī)器的特點和需求，調(diào)整和組合不同的軟件單元。

上圖顯示了一個自適應(yīng)應(yīng)用程序與三個文件的關(guān)系，這三個文件分別是：

執(zhí)行清單，也就是Application1Startup.arxml，它定義了進(jìn)程的啟動方式和參數(shù)，以及進(jìn)程所需的資源和依賴。

服務(wù)實例清單，也就是Application1Service.arxml，它定義了進(jìn)程提供和消費(fèi)的服務(wù)，以及服務(wù)的屬性和接口。

進(jìn)程的可執(zhí)行文件，也就是Application1Executable，它是進(jìn)程的二進(jìn)制文件，包含了進(jìn)程的具體邏輯和功能。

Mapping of a Process to a Machine

上圖是一個進(jìn)程如何映射到一個機(jī)器的神奇過程，看起來像是一幅抽象畫，但其實這是由AP的工具鏈來完成來的，我們只需要在工具鏈中告訴它哪個進(jìn)程要跑在哪個機(jī)器上就可以了。工具鏈會根據(jù)我們的要求，生成一些代碼和配置文件，然后把它們打包送到目標(biāo)機(jī)器（ECU）上。

這樣，我們就可以在一個機(jī)器上運(yùn)行多個進(jìn)程，或者在多個機(jī)器上運(yùn)行同一個進(jìn)程，實現(xiàn)高效的資源利用和軟件復(fù)用。

縮略詞和縮寫

Modelled Process模型化進(jìn)程是一種在機(jī)器上運(yùn)行的可執(zhí)行文件的實例，它與ARXML/Meta-Model中的Process元素一一對應(yīng)。在AUTOSAR文檔中，為了區(qū)分操作系統(tǒng)中的進(jìn)程概念，一般用process（沒有“modelled”前綴）來表示正在運(yùn)行的進(jìn)程。

Reporting Process 報告進(jìn)程是一種與可執(zhí)行文件對應(yīng)的模型化進(jìn)程，在工具鏈中將reportingBehavior設(shè)置為reportsExecutionState。這種模型化進(jìn)程會向執(zhí)行管理反饋自己的執(zhí)行狀態(tài)。

Non-reporting Process非報告進(jìn)程是一種與可執(zhí)行文件對應(yīng)的模型化進(jìn)程，在工具鏈中將reportingBehavior設(shè)置為doesNotReportExecutionState。

Self-terminating Process這種進(jìn)程可以自行啟動和終止程序（只能用退出狀態(tài)EXIT_SUCCESS終止），或等待執(zhí)行管理發(fā)送SIGTERM信號來啟動終止程序。

Unexpected Self-termination：意外自終止是執(zhí)行管理檢測到的一種事件，當(dāng)進(jìn)程沒有被請求終止，卻自行終止時發(fā)生，

例如：

進(jìn)程沒有設(shè)置terminationBehavior為processIsNotSelfTerminating，卻自行終止。

模型化進(jìn)程在報告kRunning之前終止。請注意，意外自終止也屬于意外終止，所以意外終止的要求也適用于這里。意外終止是執(zhí)行管理檢測到的一種事件，當(dāng)進(jìn)程以非0（EXIT_SUCCESS）的退出狀態(tài)終止時發(fā)生。任何未處理的信號都會導(dǎo)致意外終止，從而導(dǎo)致非0的退出狀態(tài)。

Execution Dependency 是一種配置選項，它可以設(shè)置模型化進(jìn)程實例之間的啟動和停止順序，以滿足它們的依賴關(guān)系。

1.5 AP平臺的幾種的清單

首先了解什么是清單？

清單是一種用ARXML格式編寫的文件，它由AP工具鏈根據(jù)應(yīng)用程序的特性和服務(wù)實例生成。

清單的目的是提供應(yīng)用程序在自適應(yīng)平臺上運(yùn)行所需的信息。

清單的優(yōu)點是，可以實現(xiàn)應(yīng)用程序軟件代碼和部署方案的分離，提高應(yīng)用程序軟件在不同部署方案下的重用性。

清單在軟件集成階段，機(jī)器清單和執(zhí)行清單可以由標(biāo)準(zhǔn)ARXML文件轉(zhuǎn)換為平臺特定的格式（稱為Processed Manifest），方便執(zhí)行管理模塊在機(jī)器啟動時加載。Processed Manifest還可以包含一些集成時生成的代碼或數(shù)據(jù)，例如執(zhí)行清單中的恢復(fù)操作或服務(wù)實例清單。

清單在應(yīng)用設(shè)計階段由開發(fā)者通過AP工具鏈創(chuàng)建，并與可執(zhí)行文件一起部署到機(jī)器上。

清單有三種常見的類型：機(jī)器清單、執(zhí)行清單、服務(wù)實例清單。

Machine Manifest和Execution Manifest是AP autosar 的兩種重要的配置文件，它們用于描述硬件平臺和應(yīng)用程序的特性和需求，以及應(yīng)用程序的依賴關(guān)系和優(yōu)先級 。

執(zhí)行清單（Execution Manifest）

執(zhí)行清單由開發(fā)人員在應(yīng)用設(shè)計期間創(chuàng)建，作用是為了支持可執(zhí)行文件在機(jī)器上的部署和管理，它可以和可執(zhí)行文件一起被部署到機(jī)器上。

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

總的想法是保持應(yīng)用軟件代碼盡可能獨立于部署場景，以增加應(yīng)用軟件在不同場景中的復(fù)用性。

通過執(zhí)行清單，應(yīng)用程序的實例化受到控制，因此可以：

在同一臺機(jī)器上多次實例化同一個應(yīng)用軟件

將應(yīng)用軟件部署到幾臺機(jī)器上，并且每臺機(jī)器上實例化應(yīng)用軟件

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

啟動配置，定義如何啟動應(yīng)用程序，包括啟動參數(shù)和環(huán)境變量等。每次啟動可能取決于機(jī)器狀態(tài)/功能組狀態(tài)。

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

執(zhí)行清單可以由標(biāo)準(zhǔn)ARXML文件轉(zhuǎn)換為平臺特定格式（也稱為Processed Manifest），可以在機(jī)器啟動時被讀出。

使用RTA-VRTE工具鏈，可以在Execution Editor中按照以下步驟進(jìn)行可執(zhí)行文件的屬性設(shè)置：

添加可執(zhí)行文件，并填寫其名稱、路徑、SWC和版本等信息。

添加進(jìn)程，并為每個可執(zhí)行文件實例配置啟動參數(shù)、需要的服務(wù)接口，庫、資源組分配、調(diào)度策略、啟動和停止時間，

配置可執(zhí)行文件的狀態(tài)機(jī)，如Machine 和Function Group State

添加可執(zhí)行文件的依賴關(guān)系，并指定依賴的服務(wù)進(jìn)程或后臺守護(hù)進(jìn)程以及依賴的進(jìn)程狀態(tài)。

執(zhí)行清單和可執(zhí)行代碼一起打包，可以將可執(zhí)行代碼部署到目標(biāo)機(jī)器上。通過執(zhí)行清單，可以為每個進(jìn)程實例設(shè)置不同的配置選項，也可以根據(jù)機(jī)器狀態(tài)或功能組狀態(tài)選擇不同的配置集。

機(jī)器清單Machine Manifest

Machine Manifest是在集成期間為一個特定機(jī)器創(chuàng)建的，包含了所有無法被Execution Manifest和Service Instance Manifest覆蓋的其他配置信息。

機(jī)器清單是一個定義Machine的配置的文檔，它包含了一些與特定的可執(zhí)行文件或進(jìn)程無關(guān)的配置信息，這些信息涉及機(jī)器的屬性、特性（資源、功能安全、信息安全等），例如機(jī)器狀態(tài)Machine State、功能組狀態(tài)Function Group State、資源組、訪問權(quán)限組、調(diào)度配置、內(nèi)存分區(qū)等。

圖示是使用 RTA-VRTE 工具鏈，創(chuàng)建Machine Manifest，通常需要按照以下步驟進(jìn)行配置：

在Software層級：

創(chuàng)建Function Group (MachineFG)，并指定Machine State，如:啟動、關(guān)閉、重啟、關(guān)機(jī)等。

創(chuàng)建FunctionGroupSet，并在FunctionGroupSet中，添加已經(jīng)創(chuàng)建的Function Group

創(chuàng)建SoftwareCluster和SoftwareClusterDesign，并建立映射關(guān)系

將FunctionGroupSett添加到相應(yīng)的軟件集群SoftwareCluster中

將MachineDesign添加到相應(yīng)的軟件集群SoftwareClusterDesign中

在軟件集群的配置中，建立FunctionGroupSet、MachineDesign和進(jìn)程之間的映射關(guān)系，比如確定功能組和軟件集群的映射關(guān)系，以及進(jìn)程和軟件集群的映射關(guān)系。

在System層級：

創(chuàng)建Machine和MachineDesign并建立映射關(guān)系。

設(shè)置Machine的基本屬性，比如名字、類型、版本、ID 等。

在Machine上創(chuàng)建資源組ResourceGroup，并分配一些硬件資源，比如內(nèi)存大小、cpu使用率等。

ResourceGroup還將與進(jìn)程配置所屬關(guān)系。

通過MachineDesign，配置Machine的網(wǎng)絡(luò)連接參數(shù)，比如IP地址、端口號等。

通過MachineDesign，配置服務(wù)發(fā)現(xiàn)的參數(shù)，比如多播地址、端口號等。

Machine 和Machine Design的關(guān)系

在AP平臺中，Machine是一種虛擬的計算資源，它可以對應(yīng)一個物理的處理器，也可以對應(yīng)一個虛擬機(jī)或一個容器。

Machine上運(yùn)行著不同的功能集群和服務(wù)，它們提供了各種汽車應(yīng)用程序的功能。

Machine Design是一種描述Machine之間協(xié)作和交互方式的模型，它定義了Machine之間的通信協(xié)議和接口。

Machine和Machine Design之間的關(guān)系是：一個Machine Design可以包含多個Machine，一個Machine只能屬于一個Machine Design。

一個Machine Design可以描述一個完整的汽車系統(tǒng)，也可以描述一個子系統(tǒng)或一個功能域。

為了讓Machine能夠在網(wǎng)絡(luò)中通信，每個Machine都需要在Machine Design中配置IP地址，它包含了Machine的網(wǎng)絡(luò)地址和其他信息。

如果沒有IP配置，Machine就無法找到或被找到其他Machine或設(shè)備。

Machine Manifest和Execution Manifest可以在運(yùn)行時被修改和更新，從而實現(xiàn)應(yīng)用程序的靈活部署和動態(tài)管理 。

例如，當(dāng)平臺或應(yīng)用程序的特性或需求發(fā)生變化時，可以通過修改Machine Manifest或Execution Manifest來反映這些變化，從而使平臺或應(yīng)用程序適應(yīng)新的環(huán)境或需求 。或者，當(dāng)需要部署或更新新的應(yīng)用程序時，可以通過添加或修改Execution Manifest來實現(xiàn)應(yīng)用程序的增量部署或動態(tài)更新，從而減少軟件開發(fā)和集成的工作量，縮短迭代周期 。

服務(wù)實例清單（Service Instance Manifest）

Service Instance Manifest 服務(wù)實例清單 用于配置自適應(yīng)應(yīng)用程序使用的面向服務(wù)通信的清單文件。

服務(wù)實例清單主要包含面向服務(wù)通信的配置信息 ，描述針對特定的傳輸協(xié)議（如SOME/IP接口部署設(shè)置 Service ID，Method ID，Event ID，端口號等），進(jìn)行面向服務(wù)通信的配置可執(zhí)行代碼綁定（服務(wù)實例到機(jī)器的映射、服務(wù)實例到應(yīng)用端點的映射），還包含基于服務(wù)的通信相關(guān)信息，如應(yīng)用層及相應(yīng)的傳輸層、網(wǎng)絡(luò)層通信參數(shù)信息。

1.6 執(zhí)行管理中定義的接口

執(zhí)行管理中定義的接口分為三類，它們分別用于實現(xiàn)不同的功能和目標(biāo)：

1. 用于狀態(tài)報告的接口（見圖9.3）：這類接口主要用于讓執(zhí)行管理了解AP平臺和應(yīng)用程序的運(yùn)行狀況，以便進(jìn)行相應(yīng)的控制和管理。所有由執(zhí)行管理啟動的進(jìn)程（即AP平臺的所有進(jìn)程和AA的所有進(jìn)程）都應(yīng)該通過ExecutionClient接口向執(zhí)行管理報告其執(zhí)行狀態(tài)。

其中：ExecutionClient 自適應(yīng)應(yīng)用程序接口，用于與執(zhí)行管理進(jìn)行交互。

這個接口提供了一個功能，使得一個進(jìn)程能夠向執(zhí)行管理報告其執(zhí)行狀態(tài)，包括初始化、運(yùn)行、停止、錯誤等。執(zhí)行管理可以根據(jù)這些狀態(tài)信息來決定是否需要啟動、停止、重啟或恢復(fù)某個進(jìn)程，以保證平臺和應(yīng)用程序的正常運(yùn)行。

執(zhí)行管理把進(jìn)程分為兩類：報告進(jìn)程和非報告進(jìn)程。

報告進(jìn)程是進(jìn)程的常規(guī)形式，而非報告進(jìn)程是一種特殊情況。

非報告進(jìn)程可以用于運(yùn)行那些沒有適配AUTOSAR自適應(yīng)平臺的可執(zhí)行文件。比如，如果一個可執(zhí)行文件只有二進(jìn)制版本，如果無法修改其源碼或者如果可執(zhí)行文件僅用于開發(fā)階段。

在涉及安全的系統(tǒng)中，系統(tǒng)設(shè)計者要謹(jǐn)慎使用非報告過程功能。這類過程可能無法提供安全關(guān)鍵功能，并且不受平臺健康管理的監(jiān)控，但是它們?nèi)匀豢赡軐ζ渌踩嚓P(guān)的過程造成影響，從而帶來安全風(fēng)險。為了把非報告過程和安全關(guān)鍵部分隔離開，可以使用ResourceGroup。如果非報告過程試圖報告其執(zhí)行狀態(tài)，執(zhí)行管理會將其視為錯誤。

Users of the ExecutionClient interface

除了自適應(yīng)應(yīng)用程序，（如上圖）一些功能集群的守護(hù)進(jìn)程也需要通過ExecutionClient接口向執(zhí)行管理反饋其執(zhí)行狀態(tài)。這樣，執(zhí)行管理可以了解功能集群的運(yùn)行情況，以便進(jìn)行相應(yīng)的控制和管理。

2. 用于確定性執(zhí)行的接口（見圖9.4）：這類接口主要用于實現(xiàn)平臺和應(yīng)用程序的確定性執(zhí)行，即在給定的時間內(nèi)完成預(yù)期的任務(wù)。執(zhí)行管理可以通過這些接口來控制進(jìn)程的執(zhí)行順序、優(yōu)先級、資源限制等，以滿足實時性、安全性、性能等方面的需求。

DeterministicClient 自適應(yīng)應(yīng)用程序接口，用于支持進(jìn)程內(nèi)部周期的控制、確定性工作池、激活時間戳和隨機(jī)數(shù)。

例如，執(zhí)行管理可以通過ExecutionOrder接口來指定進(jìn)程的啟動和停止順序，通過ExecutionPriority接口來指定進(jìn)程的優(yōu)先級，通過ExecutionResourceGroup接口來指定進(jìn)程的資源組，從而避免進(jìn)程之間的干擾和沖突。

3. 用于狀態(tài)管理的接口（見圖9.5）：這類接口主要用于實現(xiàn)平臺和應(yīng)用程序的狀態(tài)管理，即根據(jù)不同的系統(tǒng)需求和場景來切換平臺和應(yīng)用程序的運(yùn)行狀態(tài)。執(zhí)行管理可以通過這些接口來與狀態(tài)管理模塊協(xié)作，實現(xiàn)平臺和應(yīng)用程序的狀態(tài)轉(zhuǎn)換。

圖中的StateClient 狀態(tài)管理接口，用于支持功能組狀態(tài)和機(jī)器狀態(tài)管理。

例如，執(zhí)行管理可以通過MachineStateRequest接口來請求狀態(tài)管理模塊改變平臺的狀態(tài)，通過FunctionGroupStateRequest接口來請求狀態(tài)管理模塊改變功能組的狀態(tài)，從而實現(xiàn)平臺和應(yīng)用程序的狀態(tài)轉(zhuǎn)換。

執(zhí)行管理模塊需要使用的不同的接口，它們的作用是：

Multi-Process System Interface：可以讓執(zhí)行管理模塊在操作系統(tǒng)層面上創(chuàng)建和管理進(jìn)程。

Adaptive Intrusion Detection System Manager::EventReporter：可以讓執(zhí)行管理模塊向自適應(yīng)入侵檢測系統(tǒng)管理器發(fā)送安全事件的通知，比如發(fā)現(xiàn)可執(zhí)行文件被篡改。

Execution Management::WorkerRunnable：可以讓執(zhí)行管理模塊利用其確定性客戶端的實現(xiàn)來執(zhí)行工作可運(yùn)行實體，這些實體是一些具有特定功能的程序。

Log and Trace::Logger：可以讓執(zhí)行管理模塊記錄一些標(biāo)準(zhǔn)化的消息，用于記錄和跟蹤其運(yùn)行情況。

Persistency::KeyValueStorage：可以讓執(zhí)行管理模塊讀取和寫入一些持久性的數(shù)據(jù)，這些數(shù)據(jù)是以鍵值對的形式存儲的。

Platform Health Management::SupervisedEntity：可以讓執(zhí)行管理模塊將其進(jìn)程注冊為被平臺健康管理監(jiān)控的實體，這樣可以檢測和處理一些故障或異常。

Registry::ManifestAccessor：可以讓執(zhí)行管理模塊從清單中讀取一些配置信息，這些信息包括其確定性客戶端的設(shè)置以及功能組和進(jìn)程的屬性。

Time Synchronization::SynchronizedTimeBaseConsumer：可以讓執(zhí)行管理模塊中的確定性客戶端實現(xiàn)與同步時間基進(jìn)行同步，這樣可以保證確定性客戶端的執(zhí)行與其他組件的執(zhí)行一致。

1.7 執(zhí)行管理的職責(zé)

執(zhí)行管理模塊是自適應(yīng)平臺和應(yīng)用程序的執(zhí)行管理的核心部分，它的職責(zé)包括：平臺的生命周期管理和應(yīng)用程序生命周期管理。

AP平臺的生命周期管理

執(zhí)行管理是 AUTOSAR 自適應(yīng)平臺的第一個進(jìn)程。準(zhǔn)備好后，執(zhí)行管理啟動機(jī)器狀態(tài)從Off狀態(tài)（EM 啟動前的默認(rèn)狀態(tài)）到Startup狀態(tài)的轉(zhuǎn)換。在轉(zhuǎn)換過程中，執(zhí)行管理請求啟動存在于Machine State為Startup中的進(jìn)程。

在滿足必要的狀態(tài)轉(zhuǎn)換條件后，執(zhí)行管理應(yīng)向狀態(tài)管理報告機(jī)器狀態(tài)以啟動轉(zhuǎn)換確認(rèn)。在這一點上，執(zhí)行管理將功能組狀態(tài)管理的責(zé)任（即發(fā)起狀態(tài)變更請求）移交給狀態(tài)管理。

在一個機(jī)器上，它可以是任何資源組，即物理環(huán)境、hypervisor 上的虛擬化環(huán)境，或者 OS 級別的虛擬化（容器），執(zhí)行管理不一定是啟動的第一個進(jìn)程；

系統(tǒng)可能需要其他進(jìn)程存在，例如操作系統(tǒng)初始化進(jìn)程，或者操作系統(tǒng)微內(nèi)核用戶級進(jìn)程，如驅(qū)動程序、文件系統(tǒng)等。所有這些進(jìn)程都可能在 AUTOSAR 自適應(yīng)平臺之外啟動和管理。

請注意，一個應(yīng)用程序由一個或多個可執(zhí)行文件組成。因此，為了啟動一個應(yīng)用程序，執(zhí)行管理將進(jìn)程作為每個可執(zhí)行文件的實例啟動。平臺級進(jìn)程的啟動順序應(yīng)由執(zhí)行管理根據(jù)機(jī)器清單和執(zhí)行清單信息確定。

執(zhí)行管理模塊在AP平臺啟動的時候被激活，它負(fù)責(zé)初始化自適應(yīng)平臺和所有部署在上面的應(yīng)用程序。

啟動ECU后，將首先初始化操作系統(tǒng)，然后啟動執(zhí)行管理作為操作系統(tǒng)的初始過程之一。

然后，執(zhí)行管理將啟動Adaptive Platform Foundation的其他功能集群和Application-Level類型的應(yīng)用程序。

Adaptive Platform Foundation啟動并運(yùn)行后，執(zhí)行管理將繼續(xù)啟動Adaptive Applications。

上述過程這執(zhí)行管理與操作系統(tǒng)接口的協(xié)作主要體現(xiàn)在以下幾個方面：

執(zhí)行管理負(fù)責(zé)配置操作系統(tǒng)，使操作系統(tǒng)能夠根據(jù)執(zhí)行管理從Machine Manifest和Execution Manifest中提取的信息執(zhí)行必要的運(yùn)行時調(diào)度，比如優(yōu)先級、時間片、親和性等。

執(zhí)行管理負(fù)責(zé)根據(jù)Machine State和Function Group State，以及聲明的執(zhí)行依賴關(guān)系，確定進(jìn)程的啟動和關(guān)閉的順序。

執(zhí)行管理負(fù)責(zé)啟動和關(guān)閉進(jìn)程，以及管理進(jìn)程的狀態(tài)，比如Running、Idle、Terminated等。

AP通過清單文件來定義應(yīng)用程序的屬性和服務(wù)實例，并且具有管理權(quán)限，可以控制其他進(jìn)程的資源和權(quán)限。為了使用自適應(yīng)平臺的基本功能，EM需要先啟動所有的AP平臺功能集群。功能集群是根據(jù)服務(wù)和自適應(yīng)AUTOSAR基本功能的分類來組織的模塊。

例如，要使用自適應(yīng)AUTOSAR的通信服務(wù)，通信管理模塊的守護(hù)進(jìn)程必須已經(jīng)運(yùn)行。執(zhí)行管理還負(fù)責(zé)啟動機(jī)器狀態(tài)（Machine State）這個功能集群。機(jī)器狀態(tài)表示機(jī)器的運(yùn)行階段，例如啟動狀態(tài)（Startup State），運(yùn)行狀態(tài)等。EM在啟動后自動觸發(fā)到啟動狀態(tài)的狀態(tài)轉(zhuǎn)換，并通知狀態(tài)管理（SM），機(jī)器狀態(tài)已經(jīng)變?yōu)閱訝顟B(tài)。SM是負(fù)責(zé)管理其他功能集群狀態(tài)的組件，它可以在機(jī)器狀態(tài)的任何狀態(tài)下運(yùn)行。

進(jìn)程的執(zhí)行依賴和啟動順序

執(zhí)行管理可以根據(jù)聲明的執(zhí)行依賴關(guān)系，在狀態(tài)管理框架內(nèi)推導(dǎo)出進(jìn)程啟動和終止的順序。這樣可以確保應(yīng)用程序在依賴的應(yīng)用程序使用它們提供的服務(wù)之前啟動，同樣，也可以確保應(yīng)用程序在它們提供的服務(wù)不再需要時才關(guān)閉。

例如，如果進(jìn)程A依賴于進(jìn)程B的輸出，那么執(zhí)行管理會先啟動進(jìn)程B，再啟動進(jìn)程A。同樣，如果進(jìn)程A需要在進(jìn)程B之前終止，那么執(zhí)行管理會先停止進(jìn)程A，再停止進(jìn)程B。

執(zhí)行管理確保在定義依賴關(guān)系的進(jìn)程啟動之前，依賴的進(jìn)程處于由執(zhí)行依賴關(guān)系定義的狀態(tài)。

圖中展示了進(jìn)程的執(zhí)行順序和執(zhí)行依賴關(guān)系：

進(jìn)程A 引用了 Function group1的:running狀態(tài)。在Machine狀態(tài)轉(zhuǎn)換時，進(jìn)程“A”應(yīng)該被啟動，因為它引用了新的Machine狀態(tài)。然而，進(jìn)程“B”沒有引用那個機(jī)器狀態(tài)，所以它沒有被啟動。

進(jìn)程 A 先啟動，進(jìn)入到運(yùn)行狀態(tài)。通過執(zhí)行客戶端接口將kRunning 狀態(tài)報告給執(zhí)行管理

進(jìn)程“B”依賴于進(jìn)程“A”的運(yùn)行狀態(tài)。執(zhí)行管理收到進(jìn)程“A”的運(yùn)行狀態(tài)，此時進(jìn)程B應(yīng)該被啟動，

進(jìn)程 C 在（且僅在）進(jìn)程 B 進(jìn)入運(yùn)行進(jìn)程狀態(tài)（即報告 kRunning）時啟動。請注意，這個執(zhí)行依賴性將獨立于進(jìn)程 C 的報告/非報告配置。

進(jìn)程 D 與進(jìn)程A配置了終止?fàn)顟B(tài)的執(zhí)行依賴性。進(jìn)程A終止后，進(jìn)程D被啟動進(jìn)入到運(yùn)行狀態(tài)。

這些進(jìn)程相關(guān)的信息會被保存在執(zhí)行清單ARXML文件中，在機(jī)器運(yùn)行時被執(zhí)行管理讀取。

應(yīng)用程序生命周期管理

執(zhí)行管理模塊負(fù)責(zé)按照一定的順序啟動和關(guān)閉部署的應(yīng)用程序。執(zhí)行管理模塊根據(jù)機(jī)器清單和執(zhí)行清單中的信息，確定哪些應(yīng)用程序需要被部署，以及它們之間的執(zhí)行依賴關(guān)系。

執(zhí)行管理模塊根據(jù)機(jī)器狀態(tài)和功能組狀態(tài)，決定何時啟動部署的應(yīng)用程序的進(jìn)程，但是并不是所有的進(jìn)程都會馬上開始工作，因為有些應(yīng)用程序是為其他應(yīng)用程序提供服務(wù)的，所以它們會等待并響應(yīng)服務(wù)請求。

執(zhí)行管理模塊不負(fù)責(zé)應(yīng)用程序的運(yùn)行時調(diào)度，這是由操作系統(tǒng)來完成的。執(zhí)行管理與操作系統(tǒng)接口的協(xié)作主要體現(xiàn)在以下幾個方面：

執(zhí)行管理負(fù)責(zé)配置操作系統(tǒng)，使操作系統(tǒng)能夠根據(jù)執(zhí)行管理從Machine Manifest和Execution Manifest中提取的信息執(zhí)行必要的運(yùn)行時調(diào)度，比如優(yōu)先級、時間片、親和性等。

執(zhí)行管理負(fù)責(zé)啟動和關(guān)閉進(jìn)程，以及管理進(jìn)程的狀態(tài)，比如Running、Idle、Terminated等。

執(zhí)行管理負(fù)責(zé)根據(jù)Machine State和Function Group State，以及聲明的執(zhí)行依賴關(guān)系，確定進(jìn)程的啟動和關(guān)閉的順序。

執(zhí)行管理提供DeterministicClient API來支持進(jìn)程內(nèi)部周期控制，確定性工作池，激活時間戳和隨機(jī)數(shù)。

1.8可執(zhí)行文件從部署到執(zhí)行的過程

應(yīng)用程序設(shè)計和執(zhí)行的過程如下：

設(shè)計應(yīng)用程序，確定應(yīng)用程序的功能和服務(wù)。

開發(fā)和集成應(yīng)用程序，生成可執(zhí)行文件?？蓤?zhí)行文件是一種二進(jìn)制文件，它包含了應(yīng)用程序的代碼和入口點，可以在機(jī)器上運(yùn)行。一個應(yīng)用程序可以由一個或多個可執(zhí)行文件組成，它們在開發(fā)和集成階段被連接、配置和校驗。

部署和移除應(yīng)用程序，將可執(zhí)行文件和相關(guān)的清單文件和配置文件安裝在目標(biāo)機(jī)器上，或者卸載舊版本的應(yīng)用程序。清單文件是一種文檔，它描述了應(yīng)用程序的屬性和服務(wù)實例，它可以有不同的格式和內(nèi)容，根據(jù)不同的階段和目的而變化。部署和移除過程可以通過UCM（更新和配置管理）模塊來進(jìn)行，也可以通過其他方式來進(jìn)行。

執(zhí)行應(yīng)用程序，進(jìn)程作為二進(jìn)制文件的實例啟動。執(zhí)行管理使用Processed Manifest的內(nèi)容來分別啟動和配置每個進(jìn)程。屬于同一自適應(yīng)應(yīng)用程序的可執(zhí)行文件可能需要部署到不同的機(jī)器上，例如部署到一個高性能機(jī)器和一個高安全機(jī)器上。

AP平臺的啟動案例

應(yīng)用程序設(shè)計與執(zhí)行管理的關(guān)系如圖所示：

執(zhí)行清單它描述了應(yīng)用程序的屬性和服務(wù)實例，以及它們之間的依賴關(guān)系。

機(jī)器清單它描述了機(jī)器的配置和資源限制。這兩種文件都是應(yīng)用程序設(shè)計的重要部分，它們決定了應(yīng)用程序如何在AP平臺上運(yùn)行。

AP平臺它提供了一些功能集群（Functional Cluster），即按照服務(wù)和自適應(yīng)AUTOSAR基礎(chǔ)進(jìn)行分組的模塊。

例如，SOME/IP通信就屬于一個功能集群，它提供了基于SOME/IP協(xié)議的服務(wù)和客戶端通信功能。

圖中展示了一個SOME/IP通信的案例，執(zhí)行管理的系統(tǒng)啟動過程如下：

啟動ECU（Machine即運(yùn)行環(huán)境的物理資源）后，將首先初始化操作系統(tǒng)。

啟動執(zhí)行管理進(jìn)程作為操作系統(tǒng)的初始過程之一。

執(zhí)行管理負(fù)責(zé)啟動、停止和配置自適應(yīng)應(yīng)用程序。然后執(zhí)行管理啟動AP平臺的其他功能集群和平臺級應(yīng)用程序。

執(zhí)行管理進(jìn)程加載機(jī)器清單和執(zhí)行清單信息轉(zhuǎn)換成processed Manifest（它包含了用戶應(yīng)用程序和平臺進(jìn)程的啟動順序和依賴關(guān)系）。

執(zhí)行管理通過操作系統(tǒng)接口調(diào)用調(diào)度器，將應(yīng)用程序和功能集群的啟動順序傳遞給調(diào)度器。操作系統(tǒng)調(diào)度器加載應(yīng)用程序和功能集群的可執(zhí)行文件，并根據(jù)啟動順序創(chuàng)建進(jìn)程。例如，調(diào)度器會創(chuàng)建SOME/IP通信的守護(hù)進(jìn)程、服務(wù)程序和客戶端程序的進(jìn)程，并將它們分配到不同的CPU核心上運(yùn)行。

1.9 可信平臺

為了防止惡意代碼或數(shù)據(jù)對計算過程的干擾或破壞，保證系統(tǒng)的正確功能提高計算平臺的安全性和可靠性，非常關(guān)鍵。

可信平臺（Trusted Platform）是一種能夠保證計算過程的安全性和正確性的執(zhí)行平臺。可信平臺通過使用安全硬件模塊和軟件機(jī)制，建立了從啟動到應(yīng)用程序的一系列信任驗證步驟，形成了一個信任鏈。信任鏈的作用是確保所有執(zhí)行的代碼都是可信的（即來源可靠，沒有被篡改或惡意修改）。

執(zhí)行管理支持經(jīng)過身份驗證的啟動，這是一種保證AP平臺的可信性的方法，它從一個信任錨開始，沿著一個信任鏈，逐步啟動AP平臺的各個部分。

信任錨（ Trust Anchor）通常是一個公鑰，它存儲在一個安全的環(huán)境中，比如一個不可修改的持久化區(qū)域或一個HSM中。信任錨是實現(xiàn)可信平臺的關(guān)鍵條件，如果機(jī)器上沒有信任錨，就無法驗證自適應(yīng)平臺的可信性。

在操作系統(tǒng)啟動的過程中，每一個要啟動的可執(zhí)行程序都要先經(jīng)過認(rèn)證，認(rèn)證檢查要由一個已經(jīng)認(rèn)證過的實體來進(jìn)行，比如一個之前啟動過的可執(zhí)行程序，或一個外部實體（HSM等），這樣才能形成一個信任鏈。信任鏈?zhǔn)且环N證書路徑，用于證明證書之間的關(guān)系。證書鏈也叫做證書路徑或信任鏈。

當(dāng)操作系統(tǒng)被認(rèn)證啟動后，它要加載執(zhí)行管理作為AP平臺的第一個進(jìn)程，在加載執(zhí)行管理之前，操作系統(tǒng)要確保執(zhí)行管理的認(rèn)證已經(jīng)完成，是一個可信的實體。

因此，在啟動時，從信任錨開始，沿著信任鏈，逐步啟動AP平臺的各個部分。執(zhí)行管理現(xiàn)在負(fù)責(zé)認(rèn)證應(yīng)用程序，有多種機(jī)制來檢查應(yīng)用程序的完整性和真實性。執(zhí)行管理支持經(jīng)過身份驗證的啟動。

執(zhí)行管理建立可信平臺的驗證機(jī)制

執(zhí)行管理EM通過這些驗證機(jī)制，可以建立可信平臺：

執(zhí)行管理應(yīng)該確保在使用之前檢查從處理過的清單中獲取的機(jī)器信息的完整性和真實性。（機(jī)器配置）

執(zhí)行管理應(yīng)該確保對于即將啟動的每個進(jìn)程，檢查可執(zhí)行文件的完整性和真實性。

執(zhí)行管理應(yīng)該確保對于即將啟動的每個進(jìn)程，檢查每個相關(guān)共享對象的完整性和真實性。

執(zhí)行管理應(yīng)該確保對于即將啟動的每個進(jìn)程，檢查可執(zhí)行文件相關(guān)數(shù)據(jù)（如清單）的完整性和真實性。

對于上述的驗證過程，可以配置兩種不同的處理方式來應(yīng)對驗證失敗的情況：

監(jiān)控模式：在監(jiān)控模式下，完整性和真實性檢查仍然會進(jìn)行，但不會阻止啟動過程，即使文件系統(tǒng)有損壞，AP平臺仍然會啟動。監(jiān)控模式適用于那些希望保持系統(tǒng)運(yùn)行，即使平臺不可信的情況。另外，監(jiān)控模式也適用于開發(fā)階段，因為代碼經(jīng)常變動，不需要每次都更新驗證標(biāo)簽（簽名）。

嚴(yán)格模式：在嚴(yán)格模式下，AP平臺要求，只有當(dāng)執(zhí)行程序，manifests，或者相關(guān)庫能夠成功通過完整性和真實性驗證時，進(jìn)程才會被執(zhí)行。如果檢測到違規(guī)，執(zhí)行管理將阻止其執(zhí)行。

舉個例子，EM在驗證了一個可執(zhí)行程序的相關(guān)元數(shù)據(jù)和Manifest，啟動了該執(zhí)行程序，這個時候EM準(zhǔn)備啟動另一個可執(zhí)行程序，但是它的驗證失敗了，那么EM就不會啟動它，但其它已經(jīng)在運(yùn)行的程序繼續(xù)保持運(yùn)行。

1.10 應(yīng)用程序恢復(fù)

如果AA進(jìn)程出現(xiàn)了問題時，PHM會檢測到并觸發(fā)恢復(fù)操作?；謴?fù)操作（Recovery Action）是由集成人員根據(jù)軟件需求和架構(gòu)定義的，它們在執(zhí)行清單（Execution Manifest）中配置。

恢復(fù)動作是一種用于處理自適應(yīng)應(yīng)用程序錯誤的操作，執(zhí)行管理能夠根據(jù)恢復(fù)策略來執(zhí)行恢復(fù)動作，比如重啟或停止有問題的進(jìn)程，以保證系統(tǒng)的可靠性和安全性。

監(jiān)控到SE發(fā)生錯誤時，PHM定義了以下恢復(fù)操作：

向SM模塊請求切換到某一功能組狀態(tài)

向EM請求強(qiáng)制切換到某一無法恢復(fù)狀態(tài)

向EM請求重新啟動進(jìn)程

請求看門狗驅(qū)動執(zhí)行重置動作

將錯誤信息報告給診斷管理

將錯誤信息轉(zhuǎn)發(fā)給安全應(yīng)用，在應(yīng)用層執(zhí)行更為復(fù)雜的錯誤響應(yīng)操作

執(zhí)行管理如何支持應(yīng)用恢復(fù)的過程如下：

執(zhí)行管理通過執(zhí)行清單文件來獲取應(yīng)用的恢復(fù)策略，該文件描述了應(yīng)用的部署和執(zhí)行相關(guān)的信息，包括進(jìn)程名、資源組、啟動參數(shù)、依賴關(guān)系、恢復(fù)策略等。

執(zhí)行管理通過ExecutionManagement ReportApplicationState等接口來與平臺健康管理（PHM）進(jìn)行交互，PHM負(fù)責(zé)監(jiān)測應(yīng)用的運(yùn)行狀態(tài)和故障信息，并將其上報給執(zhí)行管理。

執(zhí)行管理根據(jù)PHM上報的信息和執(zhí)行清單中的配置來判斷是否需要執(zhí)行恢復(fù)動作（RecoveryAction），以及執(zhí)行何種恢復(fù)動作。

Alive Supervision, Deadline Supervision, Logical Supervision是三種用于監(jiān)控應(yīng)用/服務(wù)的健康狀態(tài)的方法，它們都基于應(yīng)用/服務(wù)通過被監(jiān)控實體（Supervised Entity）和ReportCheckpoint接口來報告其運(yùn)行情況。

恢復(fù)通知到狀態(tài)管理是指Phm模塊根據(jù)監(jiān)督實體和檢查點的報告，以及健康通道狀態(tài)信息，判斷是否發(fā)生了違規(guī)情況，并將其通知給狀態(tài)管理模塊，由狀態(tài)管理模塊執(zhí)行恢復(fù)活動。

圖中的示例展示了Application 1和Application 2向監(jiān)督實體報告的情況。PHM模塊被配置為對這些報告的元素進(jìn)行監(jiān)督。如果檢測到違規(guī)情況，PHM模塊被配置為通知狀態(tài)管理應(yīng)用程序，由狀態(tài)管理應(yīng)用程序處理恢復(fù)活動。

1.11 資源限制

AP平臺可以讓多個程序同時在一臺Machine上運(yùn)行，但是要保證它們不會互相影響。當(dāng)某一程序可能會占用太多的資源，比如CPU或內(nèi)存，這樣就會讓其他程序變慢或出錯。

EM可以通過配置一個或多個資源組（ResourceGroup）來分配給應(yīng)用程序來支持這個特性，每個資源組都可以分配指定的CPU時間和內(nèi)存大小。

執(zhí)行管理負(fù)責(zé)監(jiān)督和管理資源使用，如果一個資源組用了太多的資源，執(zhí)行管理EM可以做一些處理，比如記錄、停止、重啟等，這樣就可以保持系統(tǒng)的正常運(yùn)行。

1.12 AP平臺的執(zhí)行管理模塊小結(jié)

EM可以實現(xiàn)平臺和應(yīng)用的生命周期管理，包括啟動、關(guān)閉、重啟以及解決進(jìn)程依賴等。

EM可以協(xié)同SM根據(jù)Machine State和Function Group State來控制平臺和應(yīng)用的狀態(tài)轉(zhuǎn)換，以適應(yīng)不同的系統(tǒng)需求和場景。

EM可以支持應(yīng)用的增量部署和動態(tài)管理，以減少軟件開發(fā)和集成的工作量，從而縮短迭代周期。

EM可以實現(xiàn)可信平臺的機(jī)制，包括信任根、認(rèn)證啟動、應(yīng)用驗證等，以保證平臺和應(yīng)用的安全性。

EM可以與故障處理模塊協(xié)作，實現(xiàn)應(yīng)用的故障檢測和恢復(fù)動作，包括重啟、重置、替換等。

EM可以通過資源組來保證應(yīng)用之間的資源獨立性，包括CPU時間、內(nèi)存等，以避免應(yīng)用程序之間的干擾。

EM可以與資源分配器協(xié)作，實現(xiàn)資源的申請和釋放，包括內(nèi)存、文件、設(shè)備等。

審核編輯：湯梓紅