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

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

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

本文將從以下六個(gè)方面來(lái)介紹這兩個(gè)模塊：

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

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

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

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

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

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

第一部分

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

Execution Management（EM）是Adaptive Platform的核心部分，它負(fù)責(zé)管理Machine的生命周期，包括啟動(dòng)、關(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)先級(jí)等。

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

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

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

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

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

執(zhí)行管理模塊與操作系統(tǒng)接口，以使用操作系統(tǒng)提供的資源和服務(wù)，如內(nèi)存、CPU、調(diào)度、文件系統(tǒng)等。執(zhí)行管理模塊還與其他功能模塊，如診斷管理、升級(jí)管理、網(wǎng)絡(luò)管理等進(jìn)行交互，以響應(yīng)不同的事件和請(qǐ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í)行管理模塊報(bào)告狀態(tài)和事件。執(zhí)行管理模塊還負(fù)責(zé)驗(yàn)證應(yīng)用程序的可信度和完整性，以保證安全性和可靠性。AP平臺(tái)的執(zhí)行管理模塊:是一個(gè)負(fù)責(zé)管理平臺(tái)和應(yīng)用的生命周期和資源的功能集群。

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

將從以下幾個(gè)方面來(lái)詳細(xì)展開：

1.2 Execution Management（EM）概述

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

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

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

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

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

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

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

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

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

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

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

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

執(zhí)行管理是AUTOSAR AP 平臺(tái)的核心功能模塊之一，如圖中的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平臺(tái)的進(jìn)程創(chuàng)建的入口點(diǎn)，由操作系統(tǒng)在系統(tǒng)啟動(dòng)期間，啟動(dòng)執(zhí)行管理這個(gè)進(jìn)程。

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

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

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

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

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

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

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

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

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

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

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

通過(guò)系統(tǒng)調(diào)用（System Call）來(lái)請(qǐng)求操作系統(tǒng)的服務(wù)，例如創(chuàng)建、銷毀、啟動(dò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)，從而訪問(wèn)操作系統(tǒng)的內(nèi)部資源和功能。

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

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

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

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

它依賴以下幾個(gè)組件來(lái)實(shí)現(xiàn)它的功能：

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

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

3. 資源管理：它可以分配和釋放系統(tǒng)資源，并監(jiān)控資源的使用情況。它可以根據(jù)Machine Manifest文件中的設(shè)置，對(duì)應(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)平臺(tái)（Adaptive Platform，AP）上的軟件組件，它可以實(shí)現(xiàn)高性能的計(jì)算和通信功能，例如自動(dòng)駕駛、車聯(lián)網(wǎng)等。自適應(yīng)應(yīng)用程序可以根據(jù)運(yùn)行時(shí)的需求和條件，動(dòng)態(tài)地調(diào)整其行為和配置，例如支持無(wú)線更新、服務(wù)發(fā)現(xiàn)、故障管理等。自適應(yīng)應(yīng)用程序通過(guò)ARA（AUTOSAR Runtime for Adaptive applications，自適應(yīng)應(yīng)用程序的運(yùn)行平臺(tái)）與AP的功能集群（Function Clusters，F(xiàn)Cs）進(jìn)行交互，使用服務(wù)和API作為接口。

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

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

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

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

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

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

服務(wù)實(shí)例清單，也就是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

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

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

縮略詞和縮寫

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

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

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

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

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

例如：

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

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

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

1.5 AP平臺(tái)的幾種的清單

首先了解什么是清單？

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

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

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

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

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

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

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

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

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

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

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

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

在同一臺(tái)機(jī)器上多次實(shí)例化同一個(gè)應(yīng)用軟件

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

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

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

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

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

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

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

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

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

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

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

機(jī)器清單Machine Manifest

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

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

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

在Software層級(jí)：

創(chuàng)建Function Group (MachineFG)，并指定Machine State，如:啟動(dòng)、關(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層級(jí)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Users of the ExecutionClient interface

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

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

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

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

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

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

例如，執(zhí)行管理可以通過(guò)MachineStateRequest接口來(lái)請(qǐng)求狀態(tài)管理模塊改變平臺(tái)的狀態(tài)，通過(guò)FunctionGroupStateRequest接口來(lái)請(qǐng)求狀態(tài)管理模塊改變功能組的狀態(tài)，從而實(shí)現(xiàn)平臺(tái)和應(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)入侵檢測(cè)系統(tǒng)管理器發(fā)送安全事件的通知，比如發(fā)現(xiàn)可執(zhí)行文件被篡改。

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

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

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

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

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

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

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

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

AP平臺(tái)的生命周期管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

執(zhí)行管理確保在定義依賴關(guān)系的進(jìn)程啟動(dòng)之前，依賴的進(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)換時(shí)，進(jìn)程“A”應(yīng)該被啟動(dòng)，因?yàn)樗昧诵碌腗achine狀態(tài)。然而，進(jìn)程“B”沒(méi)有引用那個(gè)機(jī)器狀態(tài)，所以它沒(méi)有被啟動(dòng)。

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

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

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

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

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

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

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

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

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

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

執(zhí)行管理負(fù)責(zé)啟動(dòng)和關(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)程的啟動(dòng)和關(guān)閉的順序。

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

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

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

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

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

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

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

AP平臺(tái)的啟動(dòng)案例

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

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

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

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

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

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

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

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

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

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

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

1.9 可信平臺(tái)

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

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

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

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

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

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

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

執(zhí)行管理建立可信平臺(tái)的驗(yàn)證機(jī)制

執(zhí)行管理EM通過(guò)這些驗(yàn)證機(jī)制，可以建立可信平臺(tái)：

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

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

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

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

對(duì)于上述的驗(yàn)證過(guò)程，可以配置兩種不同的處理方式來(lái)應(yīng)對(duì)驗(yàn)證失敗的情況：

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

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

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

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

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

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

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

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

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

向EM請(qǐng)求重新啟動(dòng)進(jìn)程

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

將錯(cuò)誤信息報(bào)告給診斷管理

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

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

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

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

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

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

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

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

1.11 資源限制

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

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

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

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

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

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

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

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

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

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

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

審核編輯：湯梓紅