Execution Management（下称EM），负责平台初始化以及AP应用的启动和关闭。它根据配置好的Manifest文件执行任务，而这些Manifest文件则包含了什么时候，如何启动应用等信息。
EM需要和操作系统一起，共同执行应用的运行调度。EM需要负责操作系统的初始化/配置，让操作系统来做运行时调度，但是如何调度的这个信息，需要由EM从Machine Manifest和Execution Manifest文件当中提取出来。
应用一般包含可执行软件单元，相关执行项（例如数据或参数文件），集成/执行用的描述性信息（例如AUTOSAR模型描述文件，测试案例等等）。应用可执行文件既可以是用户级（中间件以上）也可以是AP平台的功能（中间件），但都是由EM模块进行启动/停止管理。
Adaptive应用是一种特定类型的应用，需要遵守AUTOSAR规范，也即限定只能使用AUTOSAR的标准接口，也要遵守相应的编程标准。Adaptive应用总是位于中间件以上，为了实现更好的可移植性和重复利用性，用户及的应用应当尽可能的是Adaptive应用。
可执行文件作为一个软件单元，是应用的一部分，它有一个entry point（main函数）。应用可以由一个或多个可执行文件来实现。(部署/执行流程如下)
进程是可执行文件的实例，AP平台中，进程作为OS进程，运行时被创建。EM仅仅控制进程的启动和停止，进程运行起来后，EM仅仅在进行状态管理或者和Deterministic Execution时才会和进程有联系。
Execution Manifest在设计期间创建，和可执行文件一起被部署到机器上。Execution Manifest指定可执行文件部署相关信息，以及进程属性的配置信息（例如启动参数，resource group分配，调度优先级等等）。可以为每一个Machine State或Function Group State指定不同的配置，也就是说可执行文件对应的不同实例可以有不同的配置。
Machine Manifest在集成期间为一个特定机器创建，它包含了所有无法被Execution Manifest和Service Instance Manifest的其他配置信息，包括Machine属性，特性（资源，功能安全，信息安全等），例如Machine State，Function Group State，resource group, 访问权限组，调度配置，SOME/IP配置，内存分区等等。
Execution Manifest和Machine Manifest可以由标准ARXML文件转换为平台特定格式（也成为Processed Manifest），可以在机器启动时被读出。转换过程既可以在集成时或部署时完成，也可以在安装时（UCM升级）完成。
一般来说，EM管理两种生命周期：平台生命周期管理以及应用生命周期管理。
平台生命周期管理：作为AP平台启动阶段的一部分，EM也会被启动，并负责AP平台及部署的应用的初始化
应用生命周期管理：EM负责部署的应用能够按照顺序地启动和关闭。EM需要根据Machine Manifest和Execution Manifest决定哪些是部署地应用，并根据声明地应用依赖来得到启动和关闭地顺序。根据Machine State和Function Group State，部署的应用会在AP平台启动或启动结束时启动。当然，并不是所有的应用都会立即被启动，因为有的应用会向其他应用提供服务，需要等待并“监听”服务请求。
Execution State代表进程内部生命周期，当到达kRunning状态时，EM将进程视为初始化完毕。
Process State代表从EM的角度来看进程的生命周期，每一个进程都有自己的状态。
从资源分配的角度来说，Terminated状态的进程和Idle类似，进程没有运行，也没有资源被分配，但是从执行的角度来说，他们是不同的状态，Terminated代表进程执行过了，已经被终止，可以再次启动。
机器启动后，操作系统首先被初始化，然后EM作为操作系统初始进程的一部分，也被启动。其他功能簇以及平台级的应用将随后由EM启动，当平台启动后，EM继续启动AP应用。
当设置了信任链（chain of trust）时，认证启动过程中，EM会验证应用的可信度和完整性，如果未通过检测，将不会运行这个应用。
EM可以根据声明的执行依赖关系来得到启动和终止的顺序，我们通过这个例子来理解：
首先我们有一个DataLogger进程，依赖于另一个Storage进程，这意味着启动时，EM需要先启动Storage进程，然后再启动DataLogger，这样的流程才能让DataLogger进行日志存储。
相对应的，在终止时，需要先终止DataLogger才能终止Storage。
以上图为例，代表了不同的Machine State，Function Group，都和哪些进程有关，例如Machine为Startup状态时，需要进程A和进程B是Running状态，而到Running状态时，需要终止进程A，然后启动进程C。
SM通过SetState接口设置状态，EM根据状态，需要从FG1迁移到FG1:State2，这个时候需要启动相应的进程。而当SM再次请求设置状态为FG1:State3时，这个时候又需要EM将进程终止掉。
进程B不允许依赖于另一个FG中的进程A，否则可能会出现启动一个不再给定状态中的进程。一个FG中的状态变化不会对其他FG产生影响。
还有一种情况是，B依赖于A，但是A在FG2:Running状态下就已经运行了，但是B对A的依赖会要求A以不同的启动选项开始启动，所以A要先终止并再次以不同的选项还是启动，然后再启动B。
确定性执行提供这样一个机制，即当输入给定数据时，计算过程总能在有限时间内返回一致的输出结果。
默认地，时间确定性已经由足够的资源所达到，EM的这个特性主要集中于数据确定性。EM提供DeterministicClient API来支持进程内部周期控制，确定性工作池， 激活时间戳和随机数。当出现软件锁步的情况，DeterministicClient与一个可选软件锁步框架交互来确保冗余运行进程的行为一致。DeterministicClient和Com模块一起同步数据。
AP平台允许在设备上运行很多个AP应用，所以需要保证他们能够互不干扰。当某一AP应用出现错误行为时，要保证影响范围不会设计到其他应用，例如应用不应当能够使用比配置指定还要多的CPU资源，否则很有可能影响其他应用的正常执行。
EM通过配置一个或多个ResourceGroup分配给应用来支持这个特性，每个ResourceGroup都可以分配指定的CPU时间或者内存。
EM模块负责进程启动/停止状态相关的管理，所以EM有特定的权限去启动和停止进程。如果有进程运行发生问题，PHM会监控到并触发恢复操作。恢复操作由集成人员根据软件架构对于PHM的需求而定义，在Execution Manifest中配置。
为了保证系统的正确功能，保证平台上运行代码的合法来源是非常关键的，这样才能允许集成人员构建一个可信平台。
系统实现可信平台的关键属性是Trust Anchor (也成为Root of Trust)。Trust Anchor通常由保存在安全环境中的公钥实现，例如不可修改内存或HSM中。
系统设计者负责保证系统由Trust Anchor开始启动，直到EM运行起来。根据系统设计者选择的机制而建立的信任链， 系统的完整性和真实性在系统启动时已经被检查过了。
在此基础上，当EM接管系统控制时，也会接管信任链的职责，这个时候系统集成者需要负责EM已被正确配置。
让我们来看这样一个信任链的例子：Trust Anchor在bootloader启动之前验证bootloader，在随后自动过程中的每一步，每一个即将被启动的执行程序都需要经过验证，而这个验证应当由已经被验证过的实体来完成，可以是已经验证过且启动的执行程序，或者是HSM这样的外部实体。
可以为上述的验证过程配置两种不同的验证失败时的处理方式：
监控模式：在监控模式下，完整性和真实性检查仍会执行，但不会影响启动过程，及时文件系统有损坏，AP平台仍会启动。当希望即使平台并不可信但仍能保持系统运行时，监控模式就很有用。另外一种情况是，在开发阶段时，代码经常有改动，没有必要每次都对应更改验证标签（签名），这个时候也可以用监控模式。
严格模式：在严格模式下，AP平台需要保证，当执行程序，manifests，或者相关库不能成功完成完整性和真实性验证时，进程不会被执行。
举个例子，EM在验证了执行程序，相关共享obj和Manifest，启动了执行程序，这个时候EM准备启动另一个执行程序，但是它的验证失败了，那么EM就不会启动它，但其他已经在运行的程序继续保持运行。
阅读原文，关注作者博客
推荐阅读
特斯拉最新的12V蓄电池有什么不同？
特斯拉最新中央计算模块(CCM)解析
关于对自动驾驶传感器的理解
特斯拉的电池管理系统 (BMS) 相比其他电动车有哪些优势？
2021款特斯拉Model Y ECU接口梳理
详解CANoe之CAPL编程
关于CAN时间同步的理解
dbc文件的格式以及创建详解
大众ID.4 X网络架构详解
学习笔记——NVM数据处理机制
学习笔记——AUTOSAR NVM基础知识
基于UDS的Bootloder详解
关于整车上下电流程的理解
一文详解CAN总线错误帧|附下载
DoIP协议介绍，资料分享！
详解车载网络 OTA系统的开发|文末附下载
一文了解汽车嵌入式AUTOSAR架构|附下载
特斯拉Autopilot系统安全研究|附dbc下载
