本文主要分享执行管理和状态管理以及操作系统接口模块，这些功能集群是Adaptive AUTOSAR的核心部分。你们可能会问，什么是执行管理和状态管理？它们是不是很复杂很高深？其实不然，它们就像是你的汽车的大脑和心脏，它们控制着你的汽车软件的启动、运行和停止，以及与你的汽车的操作系统的沟通。
AP平台是AUTOSAR为了让你的汽车变得更强大更灵活而制定的一种软件架构标准，它由多个功能集群组成，每个功能集群都有自己的特色和作用。在这篇文章中，将向你解释这些功能集群的基本概念、功能、原理和实现方式，以及它们在汽车软件开发中的作用和价值。希望你能通过阅读这篇文章，对Adaptive AUTOSAR有一个更深入的了解，也能够在你的工作中更好地应用它。让我们开始吧。
本文将从以下六个方面来介绍这两个模块：
1.执行管理模块：介绍执行管理模块的职责和功能，以及它如何根据Manifest文件来初始化和管理平台和应用。
2.确定性执行：介绍执行管理模块如何提供DeterministicClient API来支持数据确定性执行，以及如何与软件锁步框架协作。
3.状态管理模块：介绍状态管理模块的职责和功能，以及它如何定义和管理Machine State和Function Group State。
4.执行管理和状态管理的交互：介绍执行管理模块和状态管理模块如何通过SetState和ReportExecutionState API来协调平台和应用的状态转换。
5.操作系统接口：介绍执行管理模块如何与操作系统交互，以及如何使用操作系统提供的资源和服务。
6.如何编写一个自适应应用程序：介绍如何遵循AUTOSAR规范和编程标准来编写一个符合AP平台要求的自适应应用程序，并向执行管理汇报状态。
1 执行管理（EM）
Execution Management（EM）是Adaptive Platform的核心部分，它负责管理Machine的生命周期，包括启动、关闭、重启等。EM还负责管理Function Groups的状态，Function Groups是一组相互关联，需要统一控制的进程的集合。EM还负责解析Execution Manifest和Machine Manifest，这些文件描述了Machine的配置和属性，以及进程的依赖和优先级等。
执行管理模块（Execution Management，EM）是自适应平台和应用程序的执行管理的核心部分，它负责平台和应用程序的初始化、启动、关闭、状态转换、确定性执行等功能。
执行管理模块根据Machine Manifest和Execution Manifest中的信息来管理平台和应用程序的生命周期，这些信息包括应用程序的属性、依赖、资源、优先级、状态等。
执行管理模块提供DeterministicClient API来支持数据确定性执行，即保证在给定的输入数据下，应用程序能够在有限时间内产生一致的输出结果。执行管理模块还可以与软件锁步框架协作，以确保冗余运行的进程的行为一致。
执行管理模块与状态管理模块（State Management，SM）密切交互，以协调平台和应用程序的状态转换。状态管理模块定义和管理Machine State和Function Group State，分别表示机器的运行阶段和功能组的运行条件。执行管理模块根据状态管理模块的请求，启动或停止相应的进程或功能组。
执行管理模块与操作系统接口，以使用操作系统提供的资源和服务，如内存、CPU、调度、文件系统等。执行管理模块还与其他功能模块，如诊断管理、升级管理、网络管理等进行交互，以响应不同的事件和请求。
执行管理模块遵循AUTOSAR规范和编程标准，要求自适应应用程序（Adaptive Application，AA）也遵循相同的规范和标准，使用ARA（AUTOSAR Runtime for Adaptive applications）作为接口，向执行管理模块报告状态和事件。执行管理模块还负责验证应用程序的可信度和完整性，以保证安全性和可靠性。AP平台的执行管理模块:是一个负责管理平台和应用的生命周期和资源的功能集群。
执行管理模块除了与操作系统接口，还与其他功能模块，如诊断管理（Diagnostic Management，DM）, 升级管理（Update configuration Management，UCM）, 网络管理（Network Management，NM）等进行交互，以响应不同的事件和请求。这些功能模块提供了一些特定的服务和API，用于实现平台和应用程序的诊断、升级、通信等功能。执行管理模块可以通过调用这些服务和API，或者注册回调函数，来与这些功能模块进行协作和协调。
将从以下几个方面来详细展开：
执行管理是自适应平台基础的一个功能模块，它负责平台的初始化和管理模型化进程的生命周期。模型化进程是一种独立的可执行单元，它可以自主控制内部线程的创建和销毁。
执行管理根据清单文件中的信息来执行这些操作，例如何时以及以何种方式启动或停止模型化进程。执行管理还支持状态管理、确定性执行和安全性等功能。
执行管理是AUTOSAR自适应平台的组成部分，但它并不是AUTOSAR系统的唯一部分，因为车辆中还有许多基于AUTOSAR经典平台的ECU。因此，车辆的系统设计需要考虑AUTOSAR经典平台ECU和AUTOSAR自适应平台机器的协同工作。
执行管理的基本概念:
执行管理是指用于管理应用程序的执行过程的软件模块。
执行管理负责管理应用的启动、运行和停止等过程。
执行管理的功能和作用:
启动和关闭Machine，配置和加载应用程序，处理启动和关闭过程中的错误和异常。
控制应用程序的执行状态，设置应用程序的调度参数，监控应用程序的状态、资源、性能，处理应用程序之间的同步和通信。
管理功能组的状态，实现功能组之间的协调和一致性，根据不同的场景和需求，动态地切换功能组的状态。
处理平台和应用程序中发生的错误和异常，根据不同的错误类型和严重程度，采取相应的恢复措施。
从AP的整体架构来看：
执行管理是AUTOSAR AP 平台的核心功能模块之一，如图中的1，2，3所示，执行管理模块与POSIX的操作系统接口和状态管理有着密不可分的关系。
执行管理与其他应用程序一样，本质上是POSIX的操作系统上运行的进程。
执行管理是AUTOSAR AP平台的进程创建的入口点，由操作系统在系统启动期间，启动执行管理这个进程。
执行管理负责启动所有功能集群、自适应AUTOSAR服务和用户级应用程序的进程。
执行管理管理进程的能力是指在AP AUTOSAR平台中，能够有效地实施和执行平台初始化、启动和停止所有功能集群、自适应AUTOSAR服务和用户级应用程序的进程。
换句话说，执行管理可以根据我们配置出来的manifest文件来启动和停止功能组中配置的进程，即EM控制进程怎么运行。
执行管理需要通过与操作系统交互，为应用程序提供了灵活的运行时调度机制，支持多进程和多线程的能力。支持多进程的原因之一是要实现不同功能集群和AA之间的“无干扰”。
执行管理还支持状态管理、资源限制、应用恢复和可信平台、确定性执行的功能，以保证系统的可靠性和稳定性。
执行管理模块和状态管理模块之间的区别主要有以下几点：
1. 执行管理模块负责平台和应用的初始化、启动和停止，以及相关的配置和管理，而状态管理模块负责定义和控制平台和应用的运行状态和状态转换。
2. 执行管理模块依赖于Machine Manifest和Execution Manifest来确定应用的启动和停止顺序，以及应用的依赖关系和优先级，而状态管理模块依赖于功能组和功能组状态来确定当前运行的进程集合。
3. 执行管理模块提供了一些功能来支持确定性执行、资源限制、应用恢复和可信平台，而状态管理模块没有这些功能。
4. 执行管理模块和状态管理模块之间有一定的协作关系，例如执行管理模块需要根据状态管理模块的请求来启动或停止进程，而状态管理模块需要根据执行管理模块的反馈来更新状态。
执行管理模块与操作系统接口的主要方式有以下几种：
1. 通过系统调用（System Call）来请求操作系统的服务，例如创建、销毁、启动、停止进程，分配、释放、映射内存，打开、关闭、读写文件，发送、接收网络数据等。系统调用是操作系统提供的一组标准的函数或指令，它们可以让执行管理模块在用户态切换到内核态，从而访问操作系统的内部资源和功能。
2. 通过信号（Signal）来接收操作系统的通知，例如进程终止、内存错误、中断、异常等。信号是操作系统提供的一种异步的事件通知机制，它可以让执行管理模块在收到信号后执行相应的处理函数，从而响应操作系统的状态变化。
3. 通过共享内存（Shared Memory）来与操作系统共享数据，例如进程间通信、内存映射文件、共享库等。共享内存是操作系统提供的一种高效的数据交换方式，它可以让执行管理模块在不进行数据复制的情况下，直接访问操作系统或其他进程的内存空间，从而提高性能和节省资源。
执行管理（EM）可以控制和管理自适应应用程序的运行
它依赖以下几个组件来实现它的功能：
1. 应用恢复管理器：它可以通过PHM检测应用程序的故障，并根据Execution Manifest文件中的设置，对应用程序进行恢复操作，如重启、替换或终止。
2. 操作系统接口：它可以通过这些接口调用操作系统的基本服务，如进程管理、信号处理等。EM是一个与操作系统无关的抽象层，可以在不同的操作系统上运行。
3. 资源管理：它可以分配和释放系统资源，并监控资源的使用情况。它可以根据Machine Manifest文件中的设置，对应用程序进行资源限制和隔离。
4. 状态管理：它可以管理应用程序的状态和生命周期，并与其他软件组件进行交互。
自适应应用程序（Adaptive Application，AA）是一种运行在AUTOSAR自适应平台（Adaptive Platform，AP）上的软件组件，它可以实现高性能的计算和通信功能，例如自动驾驶、车联网等。自适应应用程序可以根据运行时的需求和条件，动态地调整其行为和配置，例如支持无线更新、服务发现、故障管理等。自适应应用程序通过ARA（AUTOSAR Runtime for Adaptive applications，自适应应用程序的运行平台）与AP的功能集群（Function Clusters，FCs）进行交互，使用服务和API作为接口。
提供给自适应应用程序的编程接口集合称为AUTOSAR Runtime for Adaptive (ARA)。
（图片来自网络）
自适应应用程序总是建立在中间件层之上，中间件层是一些提供基础服务和功能的模块。这样做的好处是，自适应应用程序可以方便地移植到不同的平台上，也可以重复使用已有的代码。自适应应用程序是根据功能需求来开发的，它只使用AUTOSAR定义的API，这些API是一些通用的接口，可以让不同的应用程序互相协作。自适应应用程序也要按照编码指南来编写代码，这些指南是一些规范和建议，可以让代码更清晰和规范。
自适应应用程序是实现应用功能的软件单元，它是功能开发的成果，也是针对特定机器进行配置和集成的软件组件。配置和集成就是根据机器的特点和需求，调整和组合不同的软件单元。
上图显示了一个自适应应用程序与三个文件的关系，这三个文件分别是：
执行清单，也就是Application1Startup.arxml，它定义了进程的启动方式和参数，以及进程所需的资源和依赖。
服务实例清单，也就是Application1Service.arxml，它定义了进程提供和消费的服务，以及服务的属性和接口。
进程的可执行文件，也就是Application1Executable，它是进程的二进制文件，包含了进程的具体逻辑和功能。
Mapping of a Process to a Machine
上图是一个进程如何映射到一个机器的神奇过程，看起来像是一幅抽象画，但其实这是由AP的工具链来完成来的，我们只需要在工具链中告诉它哪个进程要跑在哪个机器上就可以了。工具链会根据我们的要求，生成一些代码和配置文件，然后把它们打包送到目标机器（ECU）上。
这样，我们就可以在一个机器上运行多个进程，或者在多个机器上运行同一个进程，实现高效的资源利用和软件复用。
缩略词和缩写
Modelled Process模型化进程是一种在机器上运行的可执行文件的实例，它与ARXML/Meta-Model中的Process元素一一对应。在AUTOSAR文档中，为了区分操作系统中的进程概念，一般用process（没有“modelled”前缀）来表示正在运行的进程。
Reporting Process 报告进程是一种与可执行文件对应的模型化进程，在工具链中将reportingBehavior设置为reportsExecutionState。这种模型化进程会向执行管理反馈自己的执行状态。
Non-reporting Process非报告进程是一种与可执行文件对应的模型化进程，在工具链中将reportingBehavior设置为doesNotReportExecutionState。
Self-terminating Process这种进程可以自行启动和终止程序（只能用退出状态EXIT_SUCCESS终止），或等待执行管理发送SIGTERM信号来启动终止程序。
Unexpected Self-termination：意外自终止是执行管理检测到的一种事件，当进程没有被请求终止，却自行终止时发生，
例如：
进程没有设置terminationBehavior为processIsNotSelfTerminating，却自行终止。
模型化进程在报告kRunning之前终止。请注意，意外自终止也属于意外终止，所以意外终止的要求也适用于这里。意外终止是执行管理检测到的一种事件，当进程以非0（EXIT_SUCCESS）的退出状态终止时发生。任何未处理的信号都会导致意外终止，从而导致非0的退出状态。
Execution Dependency 是一种配置选项，它可以设置模型化进程实例之间的启动和停止顺序，以满足它们的依赖关系。
首先了解什么是清单？
清单是一种用ARXML格式编写的文件，它由AP工具链根据应用程序的特性和服务实例生成。
清单的目的是提供应用程序在自适应平台上运行所需的信息。
清单的优点是，可以实现应用程序软件代码和部署方案的分离，提高应用程序软件在不同部署方案下的重用性。
清单在软件集成阶段，机器清单和执行清单可以由标准ARXML文件转换为平台特定的格式（称为Processed Manifest），方便执行管理模块在机器启动时加载。Processed Manifest还可以包含一些集成时生成的代码或数据，例如执行清单中的恢复操作或服务实例清单。
清单在应用设计阶段由开发者通过AP工具链创建，并与可执行文件一起部署到机器上。
清单有三种常见的类型：机器清单、执行清单、服务实例清单。
Machine Manifest和Execution Manifest是AP autosar 的两种重要的配置文件，它们用于描述硬件平台和应用程序的特性和需求，以及应用程序的依赖关系和优先级 。
执行清单（Execution Manifest）
执行清单由开发人员在应用设计期间创建，作用是为了支持可执行文件在机器上的部署和管理，它可以和可执行文件一起被部署到机器上。
执行清单的目的是提供在AUTOSAR AP上实际部署应用程序所需的信息。
总的想法是保持应用软件代码尽可能独立于部署场景，以增加应用软件在不同场景中的复用性。
通过执行清单，应用程序的实例化受到控制，因此可以：
在同一台机器上多次实例化同一个应用软件
将应用软件部署到几台机器上，并且每台机器上实例化应用软件
执行清单侧重于以下几方面：
启动配置，定义如何启动应用程序，包括启动参数和环境变量等。每次启动可能取决于机器状态/功能组状态。
资源管理，特别是资源组分配。
执行清单可以由标准ARXML文件转换为平台特定格式（也称为Processed Manifest），可以在机器启动时被读出。
使用RTA-VRTE工具链，可以在Execution Editor中按照以下步骤进行可执行文件的属性设置：
1. 添加可执行文件，并填写其名称、路径、SWC和版本等信息。
2. 添加进程，并为每个可执行文件实例配置启动参数、需要的服务接口，库、资源组分配、调度策略、启动和停止时间，
3. 配置可执行文件的状态机，如Machine 和Function Group State
4. 添加可执行文件的依赖关系，并指定依赖的服务进程或后台守护进程以及依赖的进程状态。
5. 执行清单和可执行代码一起打包，可以将可执行代码部署到目标机器上。通过执行清单，可以为每个进程实例设置不同的配置选项，也可以根据机器状态或功能组状态选择不同的配置集。
Machine Manifest是在集成期间为一个特定机器创建的，包含了所有无法被Execution Manifest和Service Instance Manifest覆盖的其他配置信息。
机器清单是一个定义Machine的配置的文档，它包含了一些与特定的可执行文件或进程无关的配置信息，这些信息涉及机器的属性、特性（资源、功能安全、信息安全等），例如机器状态Machine State、功能组状态Function Group State、资源组、访问权限组、调度配置、内存分区等。
图示是使用 RTA-VRTE 工具链，创建Machine Manifest，通常需要按照以下步骤进行配置：
在Software层级：
创建Function Group (MachineFG)，并指定Machine State，如:启动、关闭、重启、关机等。
创建FunctionGroupSet，并在FunctionGroupSet中，添加已经创建的Function Group
创建SoftwareCluster和SoftwareClusterDesign，并建立映射关系
将FunctionGroupSett添加到相应的软件集群SoftwareCluster中
将MachineDesign添加到相应的软件集群SoftwareClusterDesign中
在软件集群的配置中，建立FunctionGroupSet、MachineDesign和进程之间的映射关系，比如确定功能组和软件集群的映射关系，以及进程和软件集群的映射关系。
在System层级：
创建Machine和MachineDesign并建立映射关系。
设置Machine的基本属性，比如名字、类型、版本、ID 等。
在Machine上创建资源组ResourceGroup，并分配一些硬件资源，比如内存大小、cpu使用率等。
ResourceGroup还将与进程配置所属关系。
通过MachineDesign，配置Machine的网络连接参数，比如IP地址、端口号等。
通过MachineDesign，配置服务发现的参数，比如多播地址、端口号等。
Machine 和Machine Design的关系
在AP平台中，Machine是一种虚拟的计算资源，它可以对应一个物理的处理器，也可以对应一个虚拟机或一个容器。
Machine上运行着不同的功能集群和服务，它们提供了各种汽车应用程序的功能。
Machine Design是一种描述Machine之间协作和交互方式的模型，它定义了Machine之间的通信协议和接口。
Machine和Machine Design之间的关系是：一个Machine Design可以包含多个Machine，一个Machine只能属于一个Machine Design。
一个Machine Design可以描述一个完整的汽车系统，也可以描述一个子系统或一个功能域。
为了让Machine能够在网络中通信，每个Machine都需要在Machine Design中配置IP地址，它包含了Machine的网络地址和其他信息。
如果没有IP配置，Machine就无法找到或被找到其他Machine或设备。
Machine Manifest和Execution Manifest可以在运行时被修改和更新，从而实现应用程序的灵活部署和动态管理 。
例如，当平台或应用程序的特性或需求发生变化时，可以通过修改Machine Manifest或Execution Manifest来反映这些变化，从而使平台或应用程序适应新的环境或需求 。或者，当需要部署或更新新的应用程序时，可以通过添加或修改Execution Manifest来实现应用程序的增量部署或动态更新，从而减少软件开发和集成的工作量，缩短迭代周期 。
Service Instance Manifest 服务实例清单 用于配置自适应应用程序使用的面向服务通信的清单文件。
服务实例清单主要包含面向服务通信的配置信息 ，描述针对特定的传输协议（如SOME/IP接口部署设置 Service ID，Method ID，Event ID，端口号等），进行面向服务通信的配置可执行代码绑定（服务实例到机器的映射、服务实例到应用端点的映射），还包含基于服务的通信相关信息，如应用层及相应的传输层、网络层通信参数信息。
执行管理中定义的接口分为三类，它们分别用于实现不同的功能和目标：
1. 用于状态报告的接口（见图9.3）：这类接口主要用于让执行管理了解AP平台和应用程序的运行状况，以便进行相应的控制和管理。所有由执行管理启动的进程（即AP平台的所有进程和AA的所有进程）都应该通过ExecutionClient接口向执行管理报告其执行状态。
其中：ExecutionClient 自适应应用程序接口，用于与执行管理进行交互。
这个接口提供了一个功能，使得一个进程能够向执行管理报告其执行状态，包括初始化、运行、停止、错误等。执行管理可以根据这些状态信息来决定是否需要启动、停止、重启或恢复某个进程，以保证平台和应用程序的正常运行。
执行管理把进程分为两类：报告进程和非报告进程。
1. 报告进程是进程的常规形式，而非报告进程是一种特殊情况。
2. 非报告进程可以用于运行那些没有适配AUTOSAR自适应平台的可执行文件。比如，如果一个可执行文件只有二进制版本，如果无法修改其源码或者如果可执行文件仅用于开发阶段。
在涉及安全的系统中，系统设计者要谨慎使用非报告过程功能。这类过程可能无法提供安全关键功能，并且不受平台健康管理的监控，但是它们仍然可能对其他安全相关的过程造成影响，从而带来安全风险。为了把非报告过程和安全关键部分隔离开，可以使用ResourceGroup。如果非报告过程试图报告其执行状态，执行管理会将其视为错误。
Users of the ExecutionClient interface
除了自适应应用程序，（如上图）一些功能集群的守护进程也需要通过ExecutionClient接口向执行管理反馈其执行状态。这样，执行管理可以了解功能集群的运行情况，以便进行相应的控制和管理。
2. 用于确定性执行的接口（见图9.4）：这类接口主要用于实现平台和应用程序的确定性执行，即在给定的时间内完成预期的任务。执行管理可以通过这些接口来控制进程的执行顺序、优先级、资源限制等，以满足实时性、安全性、性能等方面的需求。
DeterministicClient 自适应应用程序接口，用于支持进程内部周期的控制、确定性工作池、激活时间戳和随机数。
例如，执行管理可以通过ExecutionOrder接口来指定进程的启动和停止顺序，通过ExecutionPriority接口来指定进程的优先级，通过ExecutionResourceGroup接口来指定进程的资源组，从而避免进程之间的干扰和冲突。
3. 用于状态管理的接口（见图9.5）：这类接口主要用于实现平台和应用程序的状态管理，即根据不同的系统需求和场景来切换平台和应用程序的运行状态。执行管理可以通过这些接口来与状态管理模块协作，实现平台和应用程序的状态转换。
图中的StateClient 状态管理接口，用于支持功能组状态和机器状态管理。
例如，执行管理可以通过MachineStateRequest接口来请求状态管理模块改变平台的状态，通过FunctionGroupStateRequest接口来请求状态管理模块改变功能组的状态，从而实现平台和应用程序的状态转换。
执行管理模块需要使用的不同的接口，它们的作用是：
Multi-Process System Interface：可以让执行管理模块在操作系统层面上创建和管理进程。
Adaptive Intrusion Detection System Manager::EventReporter：可以让执行管理模块向自适应入侵检测系统管理器发送安全事件的通知，比如发现可执行文件被篡改。
Execution Management::WorkerRunnable：可以让执行管理模块利用其确定性客户端的实现来执行工作可运行实体，这些实体是一些具有特定功能的程序。
Log and Trace::Logger：可以让执行管理模块记录一些标准化的消息，用于记录和跟踪其运行情况。
Persistency::KeyValueStorage：可以让执行管理模块读取和写入一些持久性的数据，这些数据是以键值对的形式存储的。
Platform Health Management::SupervisedEntity：可以让执行管理模块将其进程注册为被平台健康管理监控的实体，这样可以检测和处理一些故障或异常。
Registry::ManifestAccessor：可以让执行管理模块从清单中读取一些配置信息，这些信息包括其确定性客户端的设置以及功能组和进程的属性。
Time Synchronization::SynchronizedTimeBaseConsumer：可以让执行管理模块中的确定性客户端实现与同步时间基进行同步，这样可以保证确定性客户端的执行与其他组件的执行一致。
执行管理模块是自适应平台和应用程序的执行管理的核心部分，它的职责包括：平台的生命周期管理和应用程序生命周期管理。
AP平台的生命周期管理
执行管理是 AUTOSAR 自适应平台的第一个进程。准备好后，执行管理启动机器状态从Off状态（EM 启动前的默认状态）到Startup状态的转换。在转换过程中，执行管理请求启动存在于Machine State为Startup中的进程。
在满足必要的状态转换条件后，执行管理应向状态管理报告机器状态以启动转换确认。在这一点上，执行管理将功能组状态管理的责任（即发起状态变更请求）移交给状态管理。
在一个机器上，它可以是任何资源组，即物理环境、hypervisor 上的虚拟化环境，或者 OS 级别的虚拟化（容器），执行管理不一定是启动的第一个进程；
系统可能需要其他进程存在，例如操作系统初始化进程，或者操作系统微内核用户级进程，如驱动程序、文件系统等。所有这些进程都可能在 AUTOSAR 自适应平台之外启动和管理。
请注意，一个应用程序由一个或多个可执行文件组成。因此，为了启动一个应用程序，执行管理将进程作为每个可执行文件的实例启动。平台级进程的启动顺序应由执行管理根据机器清单和执行清单信息确定。
执行管理模块在AP平台启动的时候被激活，它负责初始化自适应平台和所有部署在上面的应用程序。
启动ECU后，将首先初始化操作系统，然后启动执行管理作为操作系统的初始过程之一。
然后，执行管理将启动Adaptive Platform Foundation的其他功能集群和Application-Level类型的应用程序。
Adaptive Platform Foundation启动并运行后，执行管理将继续启动Adaptive Applications。
上述过程这执行管理与操作系统接口的协作主要体现在以下几个方面：
执行管理负责配置操作系统，使操作系统能够根据执行管理从Machine Manifest和Execution Manifest中提取的信息执行必要的运行时调度，比如优先级、时间片、亲和性等。
执行管理负责根据Machine State和Function Group State，以及声明的执行依赖关系，确定进程的启动和关闭的顺序。
执行管理负责启动和关闭进程，以及管理进程的状态，比如Running、Idle、Terminated等。
AP通过清单文件来定义应用程序的属性和服务实例，并且具有管理权限，可以控制其他进程的资源和权限。为了使用自适应平台的基本功能，EM需要先启动所有的AP平台功能集群。功能集群是根据服务和自适应AUTOSAR基本功能的分类来组织的模块。
例如，要使用自适应AUTOSAR的通信服务，通信管理模块的守护进程必须已经运行。执行管理还负责启动机器状态（Machine State）这个功能集群。机器状态表示机器的运行阶段，例如启动状态（Startup State），运行状态等。EM在启动后自动触发到启动状态的状态转换，并通知状态管理（SM），机器状态已经变为启动状态。SM是负责管理其他功能集群状态的组件，它可以在机器状态的任何状态下运行。
执行管理可以根据声明的执行依赖关系，在状态管理框架内推导出进程启动和终止的顺序。这样可以确保应用程序在依赖的应用程序使用它们提供的服务之前启动，同样，也可以确保应用程序在它们提供的服务不再需要时才关闭。
例如，如果进程A依赖于进程B的输出，那么执行管理会先启动进程B，再启动进程A。同样，如果进程A需要在进程B之前终止，那么执行管理会先停止进程A，再停止进程B。
执行管理确保在定义依赖关系的进程启动之前，依赖的进程处于由执行依赖关系定义的状态。
图中展示了进程的执行顺序和执行依赖关系：
进程A 引用了 Function group1的:running状态。在Machine状态转换时，进程“A”应该被启动，因为它引用了新的Machine状态。然而，进程“B”没有引用那个机器状态，所以它没有被启动。
进程 A 先启动，进入到运行状态。通过执行客户端接口将kRunning 状态报告给执行管理
进程“B”依赖于进程“A”的运行状态。执行管理收到进程“A”的运行状态，此时进程B应该被启动，
进程 C 在（且仅在）进程 B 进入运行进程状态（即报告 kRunning）时启动。请注意，这个执行依赖性将独立于进程 C 的报告/非报告配置。
进程 D 与进程A配置了终止状态的执行依赖性。进程A终止后，进程D被启动进入到运行状态。
这些进程相关的信息会被保存在执行清单ARXML文件中，在机器运行时被执行管理读取。
执行管理模块负责按照一定的顺序启动和关闭部署的应用程序。执行管理模块根据机器清单和执行清单中的信息，确定哪些应用程序需要被部署，以及它们之间的执行依赖关系。
执行管理模块根据机器状态和功能组状态，决定何时启动部署的应用程序的进程，但是并不是所有的进程都会马上开始工作，因为有些应用程序是为其他应用程序提供服务的，所以它们会等待并响应服务请求。
执行管理模块不负责应用程序的运行时调度，这是由操作系统来完成的。执行管理与操作系统接口的协作主要体现在以下几个方面：
执行管理负责配置操作系统，使操作系统能够根据执行管理从Machine Manifest和Execution Manifest中提取的信息执行必要的运行时调度，比如优先级、时间片、亲和性等。
执行管理负责启动和关闭进程，以及管理进程的状态，比如Running、Idle、Terminated等。
执行管理负责根据Machine State和Function Group State，以及声明的执行依赖关系，确定进程的启动和关闭的顺序。
执行管理提供DeterministicClient API来支持进程内部周期控制，确定性工作池，激活时间戳和随机数。
1.8可执行文件从部署到执行的过程
应用程序设计和执行的过程如下：
1. 设计应用程序，确定应用程序的功能和服务。
2. 开发和集成应用程序，生成可执行文件。可执行文件是一种二进制文件，它包含了应用程序的代码和入口点，可以在机器上运行。一个应用程序可以由一个或多个可执行文件组成，它们在开发和集成阶段被连接、配置和校验。
3. 部署和移除应用程序，将可执行文件和相关的清单文件和配置文件安装在目标机器上，或者卸载旧版本的应用程序。清单文件是一种文档，它描述了应用程序的属性和服务实例，它可以有不同的格式和内容，根据不同的阶段和目的而变化。部署和移除过程可以通过UCM（更新和配置管理）模块来进行，也可以通过其他方式来进行。
4. 执行应用程序，进程作为二进制文件的实例启动。执行管理使用Processed Manifest的内容来分别启动和配置每个进程。属于同一自适应应用程序的可执行文件可能需要部署到不同的机器上，例如部署到一个高性能机器和一个高安全机器上。
应用程序设计与执行管理的关系如图所示：
执行清单它描述了应用程序的属性和服务实例，以及它们之间的依赖关系。
机器清单它描述了机器的配置和资源限制。这两种文件都是应用程序设计的重要部分，它们决定了应用程序如何在AP平台上运行。
AP平台它提供了一些功能集群（Functional Cluster），即按照服务和自适应AUTOSAR基础进行分组的模块。
例如，SOME/IP通信就属于一个功能集群，它提供了基于SOME/IP协议的服务和客户端通信功能。
图中展示了一个SOME/IP通信的案例，执行管理的系统启动过程如下：
1. 启动ECU（Machine即运行环境的物理资源）后，将首先初始化操作系统。
2. 启动执行管理进程作为操作系统的初始过程之一。
3. 执行管理负责启动、停止和配置自适应应用程序。然后执行管理启动AP平台的其他功能集群和平台级应用程序。
4. 执行管理进程加载机器清单和执行清单信息转换成processed Manifest（它包含了用户应用程序和平台进程的启动顺序和依赖关系）。
5. 执行管理通过操作系统接口调用调度器，将应用程序和功能集群的启动顺序传递给调度器。操作系统调度器加载应用程序和功能集群的可执行文件，并根据启动顺序创建进程。例如，调度器会创建SOME/IP通信的守护进程、服务程序和客户端程序的进程，并将它们分配到不同的CPU核心上运行。
为了防止恶意代码或数据对计算过程的干扰或破坏，保证系统的正确功能提高计算平台的安全性和可靠性，非常关键。
可信平台（Trusted Platform）是一种能够保证计算过程的安全性和正确性的执行平台。可信平台通过使用安全硬件模块和软件机制，建立了从启动到应用程序的一系列信任验证步骤，形成了一个信任链。信任链的作用是确保所有执行的代码都是可信的（即来源可靠，没有被篡改或恶意修改）。
执行管理支持经过身份验证的启动，这是一种保证AP平台的可信性的方法，它从一个信任锚开始，沿着一个信任链，逐步启动AP平台的各个部分。
信任锚（ Trust Anchor）通常是一个公钥，它存储在一个安全的环境中，比如一个不可修改的持久化区域或一个HSM中。信任锚是实现可信平台的关键条件，如果机器上没有信任锚，就无法验证自适应平台的可信性。
在操作系统启动的过程中，每一个要启动的可执行程序都要先经过认证，认证检查要由一个已经认证过的实体来进行，比如一个之前启动过的可执行程序，或一个外部实体（HSM等），这样才能形成一个信任链。信任链是一种证书路径，用于证明证书之间的关系。证书链也叫做证书路径或信任链。
当操作系统被认证启动后，它要加载执行管理作为AP平台的第一个进程，在加载执行管理之前，操作系统要确保执行管理的认证已经完成，是一个可信的实体。
因此，在启动时，从信任锚开始，沿着信任链，逐步启动AP平台的各个部分。执行管理现在负责认证应用程序，有多种机制来检查应用程序的完整性和真实性。执行管理支持经过身份验证的启动。
执行管理建立可信平台的验证机制
执行管理EM通过这些验证机制，可以建立可信平台：
1. 执行管理应该确保在使用之前检查从处理过的清单中获取的机器信息的完整性和真实性。（机器配置）
2. 执行管理应该确保对于即将启动的每个进程，检查可执行文件的完整性和真实性。
3. 执行管理应该确保对于即将启动的每个进程，检查每个相关共享对象的完整性和真实性。
4. 执行管理应该确保对于即将启动的每个进程，检查可执行文件相关数据（如清单）的完整性和真实性。
对于上述的验证过程，可以配置两种不同的处理方式来应对验证失败的情况：
监控模式：在监控模式下，完整性和真实性检查仍然会进行，但不会阻止启动过程，即使文件系统有损坏，AP平台仍然会启动。监控模式适用于那些希望保持系统运行，即使平台不可信的情况。另外，监控模式也适用于开发阶段，因为代码经常变动，不需要每次都更新验证标签（签名）。
严格模式：在严格模式下，AP平台要求，只有当执行程序，manifests，或者相关库能够成功通过完整性和真实性验证时，进程才会被执行。如果检测到违规，执行管理将阻止其执行。
举个例子，EM在验证了一个可执行程序的相关元数据和Manifest，启动了该执行程序，这个时候EM准备启动另一个可执行程序，但是它的验证失败了，那么EM就不会启动它，但其它已经在运行的程序继续保持运行。
如果AA进程出现了问题时，PHM会检测到并触发恢复操作。恢复操作（Recovery Action）是由集成人员根据软件需求和架构定义的，它们在执行清单（Execution Manifest）中配置。
恢复动作是一种用于处理自适应应用程序错误的操作，执行管理能够根据恢复策略来执行恢复动作，比如重启或停止有问题的进程，以保证系统的可靠性和安全性。
监控到SE发生错误时，PHM定义了以下恢复操作：
向SM模块请求切换到某一功能组状态
向EM请求强制切换到某一无法恢复状态
向EM请求重新启动进程
请求看门狗驱动执行重置动作
将错误信息报告给诊断管理
将错误信息转发给安全应用，在应用层执行更为复杂的错误响应操作
执行管理如何支持应用恢复的过程如下：
1. 执行管理通过执行清单文件来获取应用的恢复策略，该文件描述了应用的部署和执行相关的信息，包括进程名、资源组、启动参数、依赖关系、恢复策略等。
2. 执行管理通过ExecutionManagement ReportApplicationState等接口来与平台健康管理（PHM）进行交互，PHM负责监测应用的运行状态和故障信息，并将其上报给执行管理。
3. 执行管理根据PHM上报的信息和执行清单中的配置来判断是否需要执行恢复动作（RecoveryAction），以及执行何种恢复动作。
Alive Supervision, Deadline Supervision, Logical Supervision是三种用于监控应用/服务的健康状态的方法，它们都基于应用/服务通过被监控实体（Supervised Entity）和ReportCheckpoint接口来报告其运行情况。
恢复通知到状态管理是指Phm模块根据监督实体和检查点的报告，以及健康通道状态信息，判断是否发生了违规情况，并将其通知给状态管理模块，由状态管理模块执行恢复活动。
图中的示例展示了Application 1和Application 2向监督实体报告的情况。PHM模块被配置为对这些报告的元素进行监督。如果检测到违规情况，PHM模块被配置为通知状态管理应用程序，由状态管理应用程序处理恢复活动。
1.11 资源限制
AP平台可以让多个程序同时在一台Machine上运行，但是要保证它们不会互相影响。当某一程序可能会占用太多的资源，比如CPU或内存，这样就会让其他程序变慢或出错。
EM可以通过配置一个或多个资源组（ResourceGroup）来分配给应用程序来支持这个特性，每个资源组都可以分配指定的CPU时间和内存大小。
执行管理负责监督和管理资源使用，如果一个资源组用了太多的资源，执行管理EM可以做一些处理，比如记录、停止、重启等，这样就可以保持系统的正常运行。
1. EM可以实现平台和应用的生命周期管理，包括启动、关闭、重启以及解决进程依赖等。
2. EM可以协同SM根据Machine State和Function Group State来控制平台和应用的状态转换，以适应不同的系统需求和场景。
3. EM可以支持应用的增量部署和动态管理，以减少软件开发和集成的工作量，从而缩短迭代周期。
4. EM可以实现可信平台的机制，包括信任根、认证启动、应用验证等，以保证平台和应用的安全性。
5. EM可以与故障处理模块协作，实现应用的故障检测和恢复动作，包括重启、重置、替换等。
6. EM可以通过资源组来保证应用之间的资源独立性，包括CPU时间、内存等，以避免应用程序之间的干扰。
7. EM可以与资源分配器协作，实现资源的申请和释放，包括内存、文件、设备等。
本文作者：刘向，汽车嵌入式工程师
-end-
本专栏是由汽车电子与软件打造的中立性技术科普专栏，将系统地阐述软件定义汽车下的关键挑战和工程实践。欢迎订阅本专栏！
