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


本系列學習筆記基於 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 決定啟動順序。

image

如果 AP 從可信 Anchor 啟動,並且在啟動過程中維護信任鏈(chain of trust),則 EM 可以支持 Authenticated Startup。Authenticated Startup 啟動過程中,EM 驗證應用的真實性和完整性,如檢測出異常,則阻止應用運行。通過這些機制,可以建立可信平台。

5.3 EM 職責

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

  1. 平台生命周期管理:EM 在 AP 初始化階段啟動, 負責初始化 AP 和其上部署的應用。
  2. 應用生命周期管理: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 以及和應用的交互如圖所示。

image

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 文章

https://www.cnblogs.com/tengzijian/category/1995263.html

原文地址(獲取最新更新):https://www.cnblogs.com/tengzijian/p/15084635.html


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM