首页 > 其他分享> > Adaptive AUTOSAR 学习笔记 10 - 执行管理

Adaptive AUTOSAR 学习笔记 10 - 执行管理

2021-07-31 18:00:26 作者：互联网

本系列学习笔记基于 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 中列出了几种可行的机制。