执行管理是AP的一个功能组件，负责平台初始化和应用的启动/停止，它基于一个或多个manifest文件来执行上述动作，比如可执行程序何时启动，在哪启动。
当机器启动之后，OS会初始化EM作为初始进程，EM再加载其他的功能组，当平台基础组件运行起来之后，EM再根据Machine Manifest和Execution Manifest来按顺序启动平台应用和普通应用。
AP的应用以进程为单位，启动指的就是启动一个进程。
1. 平台生命周期管理。
EM作为AP平台启动的一部分被启动，负责AP平台和部署的应用初始化。
2. 应用生命周期的管理。
EM负责按顺序启动和停止部署的应用，基于Machine Manifest和Execution Manifest，从配置的应用依赖关系得出启动/停止的顺序。
基于机器状态和功能组状态，应用可能在机器启动阶段被执行，也可能是之后的某些阶段，可预见的是许多应用都不会立即执行。
EM不负责应用的运行时调度，这是OS的工作，然而，EM负责初始化/配置OS来使它能执行必要的运行时调度（信息从Manifest中来）。
确定性执行提供了一种机制：使用一个给定的输入数据集，在规定时间内总是给出相同的输出。
个人理解：要理解确定性执行，首先要知道程序运行中哪些是不确定的，时间上的不确定（有时执行快，有时执行慢），资源上的不确定（动态内存分配，线程分配等）和其他随机的不确定性。
EM提供了时间确定性和数据确定性，前者指的是在截止时间前总是能产生输出，后者说的是输出和内部状态总是相同。
EM提供的支持集中在数据确定性上，因为时间确定性可以由提供充足的资源来处理。
EM提供了一组确定性客户端API来支持控制进程内循环，一个确定的线程池，激活时间戳和随机数。
进一步地，确定性执行可选支持软件锁步，冗余地执行应用，并对结果进行比较。
AP平台允许在同一个机器上执行多个应用，因此确保要确保它们之间不受干扰。
行为不正当的程序在影响其他程序方面应该被限制，例如，一个程序应避免消耗多于配置的CPU资源，这会影响其他应用。
EM支持通过配置进程资源组来避免干扰，每个资源组可能对CPU时间或内存进行限制。
EM负责基于状态的进程启动/停止的管理，所以它有 特殊的权限来启动和停止进程。
PHM监测进程，当不符合预期时，可以触发一个恢复动作，这个恢复动作在Execution Manifest中进行配置。
为了保证系统功能的正常，确保可执行文件的合法来源是很重要的。
实现可信平台的关键属性是信任根，信任根通常是存储在安全环境中的一个公钥，比如存在不可修改的持久化区域内或在HSM（硬件安全模块）内。
系统设计者负责确保系统开始于信任根，直到EM模块被加载。
基于系统设计者选择的机制，整个系统的完整性和可信度可能在启动时都被检查过，但如果系统设计者只确保了已经执行过的程序的完整性和可信度，那么EM在控制整个系统时就要担负起相应的职责，继续信任链的建立，这需要集成者正确配置EM。
一个例子：从信任根传递信任到OS和AP，可能看起来是这样的：
状态管理功能集（SM）定义了AP平台的操作状态，EM负责执行不同状态的切换。
Execution Manifest允许定义进程必须在哪些状态下运行，状态管理机制确保了只有在需要时，进程才会执行。
和EM有关的状态有四种：
执行状态-每个启动的进程的内部状态，是一个枚举（Initializing->Running->Terminating)
进程状态-进程的状态，被EM内部状态机管理
机器状态
功能组状态
EM要求至少每个机器至少配置有一个功能组，这个功能组叫做“机器状态”功能组，它的功能组状态叫做机器状态，代表了机器的全局状态。
“机器状态”功能组有一些标准强制的状态:
除此以外，也可以根据需求定义其他的状态。
功能组状态（包括机器状态），定义了当前运行的进程集合。每个APP可以在Execution Manifests里声明它应该在哪个功能组状态里运行。
机器状态（包括其他功能组状态）由SM来请求，活动的状态集受车辆范围内的事件和模式显著的影响。
EM应该确保Startup状态已经配置到名为MachineState的功能组里。
EM应在启动后自己触发到Startup的状态转换。
当完成Startup的状态转换后，EM应通知SM，MachineState已经是Startup状态了。
除了Machine State的Startup状态，其它的功能组状态（包括MachineState的其他状态），都不能自己来触发转换，这其实有个隐含的规则，外部必须始终有一个程序实体能够控制其他功能组状态的转换，这通常是SM，所以SM应当能在Machine State的所有状态下运行。
EM本身不执行OS的停止（因为和OS强耦合了），它需要至少一个进程提供机制来关闭OS，这个进程被期望配置在Machine State的Shutdown状态下。
EM应确保在名为MachineState的功能组下有一个Shutdown状态。
请求EM切换到Shutdown和其他功能组状态一致，对于EM来说，各个状态都是独立的，外部请求状态切换，EM都会执行，但对于SM来说，不同功能组之间的状态是耦合的，所以AUTOSAR假定SM只会在合适的时候请求Shutdown。
如上所述，SM在Shutdown模式下也应该保持运行，状态切换对于系统来说只是很小的工作，有很多原因会导致失败，所以SM必须在Shutdown模式下保持存活，以便处理错误等。
这个模式的目的是以干净的方式关闭机器（包括SM)，这也意味着某些时候，SM将不再存活，接下来的错误都要用特定方式来处理。
EM不执行OS的重启，为了重启系统，它要求至少有一个进程提供重启OS的机制，这个进程运行在Machine State的Restart状态下。
如果在机器上安装了一组功能一致的应用，那么有一起控制它们的能力是很重要的，因此AP提出了功能组的概念。
每个功能组有着它自己的进程集和状态集（功能组状态），每个功能组状态定义了当SM请求激活哪个状态时，哪些进程将会被EM启动，每个功能组至少有一个进程，最多由实现限制。
功能组机制非常灵活，它倾向于作为一个控制应用的进程启动和停止的工具，系统集成者可以将进程分配到功能组状态，然后用SM来请求它。
总得来说，机器状态用来控制机器和平台级别的应用的生命周期（启动/停止/重启），其他的功能组状态单独控制属于同一功能的用户级别应用，当然这并不意味着所有的平台级应用都必须要被机器状态控制。
下图是一个示例，描述了状态转换的序列，有机器状态和额外的两个功能组FG1和FG2的功能组状态，为了简化，进程状态只有静态的三种Idle,Running和Terminated。
系统的设计和集成应当确保任何时刻机器的资源都是足够的，比如，需要考虑当所有进程启动时最大的资源总和。
一个进程必须分配到一个，且只能分配到一个功能组
Off States
每个功能组（包括MachineState)，有一个Off状态作为EM的默认功能组状态。
对于MachineState，EM启动会以最快的速度启动状态转换，从Off状态切换到Startup状态。
进程在它们的Exectuion Manifest中引用它们想要执行的状态，这些状态可以是任何状态，包括机器状态。
在收到状态改变请求时，EM会终止不需要的进程集，在向SM确认状态修改前会启动新的进程集。
状态转换
首先AUTOSAR禁止不同功能组之间的进程相互依赖，因为这会导致进程在没有配置的状态下被启动。
从上图可知，每个功能组是相互独立的实体，一个功能组的状态转换对其他功能组没有副作用，当然这是从EM的角度来看的，从SM来说则不同（SM需要处理状态机）。
EM判断进程是否在运行，是检查进程状态是否在Idle或Terminated，如果是，则说明进程是停止状态。
进程停止超时
EM会监控每个进程停止的时间，默认超时时间在Machine Manifest中配置，但每个进程可以在Exectuion Manifest中重写这个超时时间。
当停止超时之后，EM会请求OS直接杀死进程（对于POSIX来说，使用SIGKILL信号）。
同时，EM会向SM报告错误，指明不能满足状态转换。
进程启动超时
EM会监控进程从创建到报告Running的时间，如果超时，则认为发生错误。
超时时间由每个进程的Exectuion Manifest配置，但特殊的不报告状态的进程这个时间为0。
发生超时后，EM会要求进程停止，如果进程不按要求停止，EM会请求OS直接杀死进程，当进程停止后，EM会重启数次（根据配置），直到成功或最终失败。
同样，EM也会向SM报告不能满足状态转换。
最前沿的电子设计资讯
