[Adaptive Autosar]深入理解--Execution Management

目录

1. EM简介

2.执行程序在AP部署

3. 执行清单

4. 机器清单

5 EM生命周期管理

6 状态管理

7. 确定性执行

---

Execution Management，以下简称EM

1. EM简介

EM是包含在自适应平台基础中的一个功能集群。

负责系统执行管理的各个方面，包括平台初始化和启动/关闭应用程序。

执行管理与操作系统一起工作。

特别是，执行管理负责将操作系统配置为执行应用程序的运行时调度和资源监控。

EM 有点类似于 CP 中的EcuM 和BswM，用于管理进程的启动和停止。

• 启动和终止进程
• 限制进程的权限
• 确保应用程序的完整性

2.执行程序在AP部署

如上图所示

设计开发集成后，得到执行程序；

执行程序升级或安装到机器上；

通过EM模块读取进程清单，进而管理执行程序的启停。

3. 执行清单

即 execution manifest，主要用于说明部署信息，如：

• 启动参数
• 资源使用
• 调度优先级
• 执行依赖信息
• 绑定的执行程序

4. 机器清单

即machine manifest，用于指定需要部署的机器信息，如：

• 环境变量
• 模块实例
• 处理器等

5 EM生命周期管理

启动与停止管理：

EM启动；

EM将机器状态 off--> Startup;

EM 读取清单，根据执行的依赖，确定好启动进程顺序；

EM根据应用报告的状态，启动或停止应用。

6 状态管理

 执行程序的状态

主要包括initializing-running-terminating，如下图

进程状态

主要包含如下图状态

 机器状态

主要包含：startup -- shutdown -- restart

Startup 

• EM应该确保Startup状态已经配置到名为MachineState的功能组里。
• EM应在启动后自己触发到Startup的状态转换。
• 当完成Startup的状态转换后，EM应通知SM，MachineState已经是Startup状态了。
• 除了Machine State的Startup状态，其它的功能组状态（包括MachineState的其他状态），都不能自己来触发转换，外部必须始终有一个程序实体能够控制其他功能组状态的转换，所以SM应在Machine State的所有状态下运行。

Shutdown 

• EM本身不执行OS的停止，它需要至少一个进程提供机制来关闭OS，这个进程被期望配置在Machine State的Shutdown状态下。
• EM应确保在名为MachineState的功能组下有一个Shutdown状态。
• 请求EM切换到Shutdown和其他功能组状态一致，对于EM来说，各个状态都是独立的，外部请求状态切换，EM都会执行，但对于SM来说，不同功能组之间的状态是耦合的，所以AUTOSAR假定SM只会在合适的时候请求Shutdown。
• SM在Shutdown模式下也应保持运行，状态切换对于系统来说只是很小的工作，有很多原因会导致失败，所以SM必须在Shutdown模式下保持存活，以便处理错误等。

Restart 

• EM不执行OS的重启，为了重启系统，它要求至少有一个进程提供重启OS的机制，这个进程运行在Machine State的Restart状态下。

 功能组状态

如果在机器上安装了一组功能一致的应用，那么有一起控制它们的能力是很重要的，因此AP提出了功能组的概念。

每个功能组有着它自己的功能组状态，每个功能组状态定义了当SM请求激活哪个状态时，哪些进程将会被EM启动，每个功能组至少有一个进程，最多由实现限制。

功能组机制非常灵活，它倾向于作为一个控制应用的进程启动和停止的工具，系统集成者可以将进程分配到功能组状态，然后用SM来请求它。

总得来说，机器状态用来控制机器和平台级别的应用的生命周期（启动/停止/重启），其他的功能组状态单独控制属于同一功能的用户级别应用，当然这并不意味着所有的平台级应用都必须要被机器状态控制。

下图是一个autosar标准示例，描述了状态转换的序列。

 说明如下：

• 一个进程必须分配到一个，且只能分配到一个功能组
• 进程A，引用了机器状态Startup。它是一个自终止的进程，运行一次之后就停止了
• 进程B，引用了机器状态Startup和Running，它依赖于进程A的终止，这是靠配置执行依赖来达成的
• 进程C，只引用了机器状态Running，它在SM请求机器状态Diagnostics时终止
• 进程D，只引用了功能组状态FG1::Running，并且没有执行依赖，EM将会以冲裁的方式来启动和停止它
• 进程E，只引用了功能组状态FG1::Running，并且没有执行依赖，EM将会以冲裁的方式来启动和停止它
• 进程F，引用了FG2::Running和FG2::Fallback，它在两个状态中有不同的启动配置，所以在状态切换时会先停止，然后再使用不同的启动配置启动

状态交互

如上图所示

•  SM模块用于设置获取功能组的状态；
• EM根据功能组的状态进而处理进程状态；
• 进程的状态调度，进而管理执行状态。

状态切换

• 如上图，首先AP中禁止不同功能组之间的进程相互依赖，这会导致进程在没有配置的状态下被启动。
• 其次每个功能组是相互独立的实体，一个功能组的状态转换对其他功能组没有副作用。
•  终止所有当前正在运行，但请求的状态下不需要的进程
• 状态转换是一个复杂的过程，但有三个基础逻辑步骤：
  • 终止当前正在运行且在请求状态中不需要的所有进程
  • 重新启动当前正在运行的所有进程，并且 StartupConfig 在当前状态和请求状态之间有所不同
  • 启动当前未运行且处于请求状态所需的所有进程

进程停止超时

•  EM会监控每个进程停止的时间，默认超时时间在Machine Manifest中配置，但每个进程可以在Exectuion Manifest中重写这个超时时间。
• 当停止超时之后，EM会请求OS直接杀死进程（对于POSIX来说，使用SIGKILL信号）。
• 同时，EM会向SM报告错误，指明不能满足状态转换。

进程启动超时

• EM会监控进程从创建到报告Running的时间，如果超时，则认为发生错误。
• 超时时间由每个进程的Exectuion Manifest配置，但特殊的不报告状态的进程这个时间为0。
• 发生超时后，EM会要求进程停止，如果进程不按要求停止，EM会请求OS直接杀死进程，当进程停止后，EM会根据配置重启数次，直到成功或最终失败。
• 同样，EM也会向SM报告不能满足状态转换。

7. 确定性执行

在实时系统中，确定性执行通常意味着，给定计算一组输入数据总是在规定时间内产生一致的输出，即行为是可重现的。这在汽车 实时安全系统中，是非常重要的。

可确定性主要包含如下几类：

• 时间确定性：计算的输出总是在一个给定期限（一个时间点）。
• 数据确定性：给定相同的输入和内部状态，计算总是产生相同的输出。
• 完全确定性：如上定义的时间和数据确定性的组合。

AP中应包含的可确定性包括：

1. 软件锁步：为了执行具有高计算性能要求的 ASIL C/D 应用程序，由于高性能微处理器的高瞬态硬件错误率，需要特定的措施，例如软件锁步。 软件锁步是一种通过冗余方式进行计算的技术两个不同的执行路径并比较结果。 为了使冗余计算具有可比性，软件锁步需要完全确定性计算。
2. 已验证软件重用性：确定性子系统在满足子系统性能和资源需求的不同平台上表现出相同的行为，而不管每个环境中的其他差异，例如不相关的应用程序的存在。 示例包括不同的开发和仿真平台。 由于可重现的功能行为，子系统的许多测试、配置和校准结果在部署子系统的每个环境中都是有效的，不需要重复。

EM 提供了 DeterministicClient API 来支持对流程内部循环、确定性工作池、激活时间戳和随机数的控制。
在软件锁步的情况下，DeterministicClient 与可选的软件锁步框架交互，以确保冗余执行进程的行为相同。
DeterministicClient 与通信管理交互以使数据处理与循环激活同步。