AP Autosar平台设计 5 EM& 6SM

目录

5执行管理EM

5.1概述

5.2系统启动

5.3 EM职责

5.4确定性执行Deterministic Execution

5.5资源限制 Resource Limitation

5.6应用程序恢复

5.7可信平台

6状态管理State Management

---

5执行管理EM

5.1概述

执行管理负责系统执行管理的所有方面，包括平台初始化和应用程序的启动/关闭。执行管理与操作系统协同工作，以执行应用程序的运行时调度。

5.2系统启动

当机器启动时，将首先初始化操作系统，然后作为操作系统的初始进程之一启动执行管理。然后通过EM启动自适应平台基础的其他功能集群和平台级应用。在AP基础平台启动和运行之后，EM继续启动自适应应用程序。平台级应用程序和自适应应用程序的启动顺序由执行管理根据计算机清单和执行清单信息确定。

图5-1AP启动顺序

EM可选地支持经过身份验证的启动，即从信任锚点启动自适应平台，同时维护信任链。在经过身份验证的启动期间，执行管理将验证应用程序的真实性和完整性，并在检测到违规行为时阻止其执行。通过这些机制，可以建立一个可信的平台。

5.3 EM职责

EM负责自适应平台执行管理和应用程序执行管理的所有方面，包括：

1.平台生命周期管理

执行管理作为Adaptive Platform启动阶段的一部分启动，并负责Adaptive Platform和已部署应用程序的初始化。

2.应用程序生命周期管理

执行管理负责有序地启动和关闭已部署的应用程序。执行管理根据计算机清单和执行清单中的信息确定已部署的应用程序集，并根据声明的应用程序依赖关系导出启动/关闭顺序。根据机器状态和功能组状态，已部署的应用程序将在Adaptive Platform启动期间或之后启动，但是，由于许多应用程序将向其他应用程序提供服务，因此将等待并“侦听”传入的服务请求，因此不期望所有应用程序立即开始活动工作。

执行管理层不负责执行的运行时调度应用程序，因为这是操作系统的责任。但是，执行管理负责操作系统的初始化/配置，以使其能够根据执行管理从机器清单和执行清单中提取的信息执行必要的运行时调度。

5.4确定性执行Deterministic Execution

确定性执行提供了一种机制，使得使用给定输入数据集的计算总是在限定的时间内产生一致的输出。EM区分了时间确定性time determinism和数据决确定性 time determinism。前者表示输出总是在截止日期前生成，而后者表示从相同的输入数据集和内部状态生成相同的输出。

EM提供的支持侧重于数据确定性，因为它假定时间确定性通过提供足够的资源来处理。对于数据确定性，EM提供确定性客户端API，以支持对流程内部循环、确定性工作池、激活时间戳和随机数的控制。Deterministic Client与通信管理交互，以使数据处理与循环激活同步。Deterministic Client支持的API及其与应用程序的交互如“图5-2DeterministicClient”所示。

图5-2确定性客户端

5.5资源限制 Resource Limitation

自适应平台允许在同一台机器上执行多个自适应应用程序，因此确保系统不受干扰。因此，应限制行为不正确的自适应应用程序影响其他应用程序的能力，例如，应防止应用程序消耗超过规定的CPU时间，因为这可能会影响其他应用程序的正确运行。

执行管理通过配置应用程序进程分配到的一个或多个资源组Resource Groups，支持免受干扰。可以为每个资源组分配CPU时间或内存限制，以限制应用程序的可用资源。

5.6应用程序恢复

EM负责进程Process启动/停止的状态相关管理，因此它必须拥有启动和停止进程的特殊权利。

平台运行状况管理（Platform Health Management，PHM）监控流程，并可能触发恢复。

当任何进程的行为不在指定参数范围内时的操作。恢复操作由集成商根据平台健康管理的软件体系结构需求定义，并在执行清单中配置。

5.7可信平台

为了保证系统的正确功能，确保平台上执行的代码具有合法来源是至关重要的。保留此属性允许集成器构建受信任的平台（Trusted Platform）。

实现可信平台的系统的一个关键属性是信任锚Trust Anchor（也称为信任根Root of Trust）。信任锚通常被实现为存储在安全环境中的公钥，例如存储在不可修改的persistent memory或HSM中。

系统设计者负责确保系统至少从信任锚开始，并且在启动EM之前保持信任。根据系统设计者选择的建立信任链的机制，整个系统的完整性和真实性可能已在系统启动时进行了检查。但是，如果系统设计者仅确保已执行软件的完整性和真实性已得到检查，则EM将在接管系统控制时接管继续信任链的责任。在这种情况下，系统集成商负责确保正确配置EM。

将信任从信任锚点传递到操作系统和AP（即建立信任链）的一个示例如下所示：信任锚（根据定义是一个真实实体）在启动引导加载程序之前对引导加载程序进行身份验证。在引导过程的每个后续步骤中，应首先对要启动的可执行文件进行身份验证。该真实性检查应由已经认证的实体完成，即，真实性检查可以通过之前启动的可执行文件或一些外部实体（例如HSM）完成。

操作系统真正启动后，应启动EM作为其第一个进程之一。在启动执行管理之前，操作系统应确保EM的真实性已由已认证且值得信赖的实体验证。

注意：如果认证未通过信任锚本身的功能进行检查（根据定义，信任锚本身是可信的），则应用于验证可执行文件真实性的软件必须在应用之前进行认证。例如，如果Crypto API用于验证可执行文件的身份验证，则Crypto API本身在使用前应经过某个受信任实体的身份验证。

EM现在接管了在启动AP程序之前对其进行身份验证的责任。但是，验证可执行代码的完整性和真实性的可能性不止一种。在SWS_ExecutionManagement 里面，提供了完成此任务的可能机制列表。

6状态管理State Management

SM是一个独特的功能集群，主要是一个特定于ECU开发项目的集群，通常，最终实现由系统集成商执行。它负责AUTOSAR自适应平台运行状态的所有方面，包括处理传入事件、确定这些事件/请求的优先级以设置相应的内部状态。根据项目需要，状态管理可能由一个或多个状态机组成。

SM通过特定于项目的ara::com服务接口与自适应应用程序交互，该接口由“ Fields ”组成，如下所述。状态管理和其他功能集群之间的交互应通过每个功能集群定义的标准化接口完成。

图6-1状态管理交互

SM可实现以下功能：

•可以请求将功能组设置为专用状态

•（部分）网络可被请求停用/激活

•可以请求关闭或重新启动机器

•可能会影响其他自适应（平台）应用程序

•可以执行特定于项目的动作

•当平台健康管理层或执行管理层通知时，从（监督）错误中恢复

•根据诊断的请求，按照诊断地址执行项目特定重置

•准备和验证软件集群，以便根据更新和配置管理的要求进行安装、更新或删除

•影响运行程序以实现机器（部分）内的同步行为（例如电源模式）

为了实现同步行为，状态管理提供消息定义和消息回复，其中在通信管理的通信组范围内生成ara::com方法（method）和字段（field）。

状态管理通过ara::com提供一组“触发器Trigger”和“通知器Notifier”字段。SM实质上监听“触发器”，并在内部执行特定于实现的状态机处理，如果存在“通知器”字段，则向其提供effect。

由于状态管理功能至关重要，因此从其他功能访问群集或应用程序必须受到保护，例如通过IAM（身份和访问管理）进行保护。状态管理由平台健康管理监控和监督。

状态管理功能是高于特定项目的，AUTOSAR决定暂时不要为AP指定类似于CP平台BswM之类的功能。AP只指定一组基本服务接口，并将实际仲裁逻辑封装到特定于项目的代码中。

仲裁逻辑代码可以根据标准化配置参数单独开发或（部分）生成。