本系列學習筆記基于 AUTOSAR Adaptive Platform 官方檔案 R20-11 版本 AUTOSAR_EXP_PlatformDesign.pdf

縮寫

EM：Execution Management
AP：AUTOSAR Adaptive Platform
FC：Functional Cluster
AA：Adaptive Application
ARA：AUTOSAR Runtime for Adaptive Applications
SM：State Management
CM：Communication Management
PHM：Platform Health Management

5 執行管理

5.1 概述

EM 負責系統執行管理的方方面面，包括平臺初始化、啟動/關閉應用，EM 和作業系統一起，負責應用的運行時調度（準確說，應用的運行時調度是由作業系統負責，而非由執行管理負責），

5.2 系統啟動

機器啟動，作業系統最先初始化，然后 EM 作為作業系統的初始行程之一啟動，EM 負責啟動其他 FC 和平臺應用，平臺 Foundation 啟動后，EM 繼續啟動 AA，EM 根據 Machine Manifest 和 Execution Manifest 決定啟動順序，

如果 AP 從可信 Anchor 啟動，并且在啟動程序中維護信任鏈（chain of trust），則 EM 可以支持 Authenticated Startup，Authenticated Startup 啟動程序中，EM 驗證應用的真實性和完整性，如檢測出例外，則阻止應用運行，通過這些機制，可以建立可信平臺，

5.3 EM 職責

EM 負責 AP 和應用執行管理的方方面面，包括：

平臺生命周期管理：EM 在 AP 初始化階段啟動，負責初始化 AP 和其上部署的應用，
應用生命周期管理：EM 負責應用的有序啟動/關閉，EM 根據 Machine Manifest 和 Execution Manifests 中的資訊決定部署的應用集合，并且根據依賴關系決定啟動/關閉順序，根據機器狀態（Machine State）和功能組狀態（Function Group States），部署的應用在平臺啟動時或之后啟動，但并不是所有應用都立即作業，因為很多應用向其他應用提供服務，等待請求到來，

EM 不負責應用的運行時調度，這是作業系統的職責，但是 EM 從 Machine Manifest 和 Execution Manifests 提取資訊，并據此初始化、配置作業系統，以執行必要的運行時調度，

5.4 確定性執行

確定性執行提供了一個機制：同樣的輸入總能在一定的時間內計算出相同的輸出，EM 區分時間、資料的確定性，時間確定性指總能在限定時間內得出結果；資料確定性指給定相同的輸入，總能得出相同的輸出，并且具有相同的內部狀態，

EM 側重于對資料確定性的支持，因為時間確定性通過提供足夠的資源來保證，對于資料確定性，EM 提供 DeterministicClient APIs，以支持：

控制 process-internal cycle
確定性作業者池
激活時間戳
亂數

DeterministicClient 和 CM 互動，和 cycle activation 同步資料處理，DeterministicClient 支持的 API 以及和應用的互動如圖所示，

5.5 資源限制

AA 允許一個 Machine 上運行多個 AA，保證 AA 之間不互相干擾是系統的本職，因此應該對 AA 的一些錯誤行為做一些限制，以保證其他 AA 不受影響，例如應用不能使用超過設定的 CPU 時間，以免對其他應用的正常功能產生影響，

EM 可以通過配置一個或多個 ResourceGroups 實作干擾隔離，每個行程指定一個 ResourceGroup，每個 ResourceGroup 可以指定 CPU 時間和記憶體限制，

5.6 應用恢復

EM 負責行程啟停的狀態依賴管理，所以 EM 需要啟動/停止行程的特權，PHM（Platform Health Management）監控行程，如果行程超出限制，可以觸發恢復動作，集成根據 PHM 的軟體架構需求配置 Execution Manifest，以此來決定恢復動作，

5.7 可信平臺

確保平臺上執行的代碼有合法來源，對保證系統功能正確至關重要，保持該屬性可以允許集成者構建一個可信平臺，

實作可信平臺的系統的一個關鍵是 Trust Anchor（也叫 Root of Trust），Trust Anchor 通常實作為存盤在安全環境（如不可修改的永久存盤或 HSM）的公鑰，

系統設計者負責保證系統從 Trust Anchor 啟動，并且直到 EM 啟動完成，一直保持可信，系統設計者選擇一個建立信任鏈的機制，基于該機制，可以在系統啟動時檢查整個系統的完整性和真實性，然而，如果系統設計者只保證已經執行的軟體的完整性和真實性，EM 從接管系統控制權開始，負責維護信任鏈，這種情況下，系統集成負責保證 EM 被正確配置，

舉個 Trust Anchor 將 Trust 傳遞給系統和 AP 的例子：Trust Anchor（由定義保證的可信物體）在啟動 bootloader 之前認證 bootloader，之后啟動程序的每個步驟，都要先認證，再啟動 Executable，認證需要由一個已認證的物體進行，如先前啟動的 Executable 或外部物體如 HSM，

OS 經認證啟動后，應當將 EM 作為最先啟動的行程之一，啟動 EM 之前，要先經由一個已驗證過的可信物體驗證 EM 的真實性，

注意：如果不是由 Trust Anchor 驗證，驗證其他 Executable 的軟體自身應該先被驗證，舉個例子：如果加密 API 要用于認證其他 Executable，加密 API 在使用前要先被其他可信物體驗證，

EM 接管了啟動 AA 前驗證 AA 的職責，然而，有多種可能性去驗證可執行代碼的完整性和真實性，在 SWS_ExecutionManagement 中列出了幾種可行的機制，

Adaptive AUTOSAR 學習筆記 10 - 執行管理

縮寫