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

Zijian/TENG發表於2021-07-31

APT筆記

本系列學習筆記基於 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 或外部實體如 HSM。

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

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

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