解读 AP AUTOSAR R22-11 ExecutionManagement.pdf 中文版——第二部分

7 Functional specification

执行管理是Adaptive Platform Foundation中包含的一个功能集群。执行管理负责系统执行管理的各个方面，包括平台初始化和应用程序的启动/关闭。

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

本章描述了执行管理的功能行为。

• 第7.2节介绍了执行管理中的关键术语，重点介绍了应用程序、可执行文件和建模过程之间的关系。对于后者，我们指的是描述流程的元模型实例，它最终将由操作系统流程实现。
• 第7.3节涵盖了核心执行管理运行时职责，包括启动应用程序。
• 第7.4节描述了应用程序的生命周期，包括建模过程状态转换和启动/关闭序列。
• 第7.5节涵盖了与执行管理中的状态管理相关的几个主题，包括功能组状态管理和状态转换行为。
• 第7.6节记录了执行管理确定性执行所提供的支持，使得给定相同的输入和内部状态，计算将始终产生相同的输出。
• 第7.7节描述了执行管理如何支持资源管理，包括限制应用程序使用CPU和内存。
• 第7.8节概述了容错策略。本节将在未来的版本中进行扩展，以描述如何在执行管理中实现这些策略。
• 第7.9节涵盖了可信平台的主题，即确保应用程序的完整性和真实性。

7.2.1 Application

应用程序是为了解决一组相干的功能需求而开发的。 一个应用程序由可执行的软件单元、额外的执行相关的项目（例如数据或参数文件）和用于集成和执行的描述性信息（例如基于AUTOSAR元模型的正式模型描述、测试用例等）组成。

应用程序可执行文件可以位于中间件之上，或者可以实现AUTOSAR自适应平台的功能集群（位于中间件的层次），见[3]中的[constr_1605]。

一般来说，无论是用户级还是平台级，应用程序都被执行管理以相同的方式处理，并且可以使用操作系统和AUTOSAR自适应平台的其他功能集群提供的所有机制和API。但是，在这样做的过程中，它可能会限制其在AUTOSAR自适应平台的其他实现之间的可移植性。

7.2.2 Adaptive Application

自适应应用程序是一种特定类型的应用程序。自适应应用程序的实现完全符合AUTOSAR规范，即它只能使用AUTOSAR标准化的API，并且需要遵循特定的编码指南，以允许在不同实现的AUTOSAR自适应平台之间重新分配。 自适应应用程序总是位于中间件之上。为了实现可移植性和重用性，用户级应用程序在技术上可能的情况下，应该是自适应应用程序。

图7.1显示了不同类型的应用程序。

图7.1：应用程序类型

自适应应用程序是功能开发的结果，也是机器特定配置和集成的交付单元。

一些合同（例如关于使用的库）和与其他自适应应用程序交互的服务接口需要事先达成一致。详情请参见[9]。

7.2.3 Executable

一个可执行文件是应用程序的一部分，它有一个入口点（主函数）[SWS_OSI_01001]。

一个应用程序可以由一个或多个可执行文件实现[TPS_MANI_01010]。

可执行文件的生命周期通常包括：

• Development and Integration开发和集成：

为部署到目标机器而链接、配置和校准的二进制文件。该二进制文件可能包含在集成时生成的代码。 执行清单，见7.2.5节和[3]，以及服务实例清单（不被执行管理使用）。

• Deployment and Removal部署和移除：

 二进制文件安装在目标机器上。删除之前的版本（如果有）。 处理过的清单，以一种在机器启动时可以高效读取的平台特定格式存储。

• Execution执行：

进程作为二进制文件的实例启动。 执行管理使用处理过的清单的内容来分别启动和配置每个进程。

属于同一自适应应用程序的可执行文件可能需要部署到不同的机器上，例如部署到一个高性能机器和一个高安全机器上。

图7.2显示了可执行文件从部署到执行的生命周期。

7.2.4 Modelled Process

7.2.4 模型化进程

模型化进程是可执行文件的一个实例。在AUTOSAR自适应平台上，模型化进程在运行时被实现为一个操作系统进程。 有关执行管理如何启动和停止进程的详细信息，请参见7.4节。 执行管理以相同的方式处理所有可执行文件和派生的模型化进程，不受应用程序边界的影响。

备注：在本文档的本次发布中，通常假定进程是自包含的，即它们通过从代码中调用操作系统接口的API来控制线程创建和调度。执行管理只启动和终止进程，而当进程运行时，执行管理只通过提供状态管理机制（见7.5节）或支持确定性执行的API（见7.6.3节）与进程交互。

7.2.5 执行清单

执行清单是在设计时与服务实例清单（不被执行管理使用）一起创建的，并与其附属的可执行文件一起部署到机器上。

执行清单指定了可执行文件的部署相关信息，并以标准化的方式描述了模型化进程属性（启动参数、资源组分配、调度优先级等）的机器特定配置。

执行清单与实际的可执行代码捆绑在一起，以支持将可执行代码部署到机器上。

每个可执行文件二进制文件的实例，即每个启动的进程，都可以单独配置，可以根据机器状态或功能组状态（见第7.5节和[TPS_MANI_01012]、[TPS_MANI_01013]、[TPS_MANI_01017]和[TPS_MANI_01041]）使用不同的配置集。

为了执行其必要的操作，执行管理对机器清单和执行清单的内容提出了一些要求。 配置的验证预期由供应商工具完成。 有关执行清单规范的更多信息，请参见[3]。

7.2.6 机器清单

机器清单也是在集成时为特定机器创建的，并且在其内容发生变化时像执行清单一样部署。

机器清单包含了所有不能分配给特定可执行文件或其实例（模型化进程）的配置信息，即不是已经由执行清单或服务实例清单覆盖的信息。 机器清单的内容包括机器属性和特性（资源、安全性、安全性等）的配置。详情请参见[3]。

7.2.7 清单格式

执行清单和机器清单可以从原始标准化的ARXML转换为平台特定格式（称为处理过的清单），该格式在机器启动时可以高效地读取。格式转换可以在集成时间或部署时间离线完成，也可以在安装时间由更新和配置管理在机器上完成。

建模过程是可执行文件的一个实例。在AUTOSAR自适应平台上，建模过程在运行时作为操作系统过程实现。

有关执行管理如何启动和停止流程的详细信息，请参见7.4。执行管理以相同的方式处理所有可执行文件和派生的建模流程，与应用程序边界无关。

备注：在本文档的这个版本中，主要假设进程是自包含的，即它们通过从代码中调用操作系统接口的API来控制线程的创建和调度。执行管理仅启动和终止进程，在进程运行时，执行管理仅通过提供状态管理机制（见7.5）或API来与进程交互，以支持确定性执行（见7.6.3）。

7.2.5 Execution Manifest

执行清单在设计时与服务实例清单（不由执行管理使用）一起创建，并与附加的可执行文件一起部署到计算机上。

执行清单指定了可执行文件的部署相关信息，并以标准化的方式描述了建模过程属性的机器特定配置（启动参数、资源组分配、调度优先级等）。

执行清单与实际的可执行代码捆绑在一起，以支持将可执行代码部署到计算机上。

可执行二进制文件的每个实例，即每个启动的进程，都是可单独配置的，每个机器状态或每个功能组状态都可以选择使用不同的配置集（请参阅第7.5节和[TPS_MANI_01012]、[TPS_-MANI_01013]、[TPS_MMANI_01017]和[TPSMANI_01041]）。

为了执行必要的操作，执行管理对机器清单和执行清单的内容提出了一些要求。

配置的验证预计将由供应商工具完成。

有关执行清单规范的更多信息，请参阅[3]。

7.2.6 Machine Manifest

机器清单也是在集成时为特定机器创建的，每当其内容发生变化时，都会像执行清单一样进行部署。机器清单包含无法分配给特定可执行文件或其实例（建模进程）的所有配置信息，即执行清单或服务实例清单尚未涵盖的配置信息。

机器清单的内容包括机器属性和功能（资源、安全、安保等）的配置。有关详细信息，请参阅[3]。

7.2.7 Manifest Format

执行清单和机器清单可以从原始的标准化ARXML转换为特定于平台的格式（称为处理清单），在机器启动时可以有效地读取。格式转换可以在集成时在板外或部署时进行，也可以在安装时在机器上（通过更新和配置管理）进行。

7.3 执行管理的职责

执行管理负责所有方面的进程执行管理。一个进程是一个应用程序的一部分，它是一个可执行文件的加载实例。

执行管理作为AUTOSAR自适应平台启动阶段的一部分启动，并负责启动和终止进程。

执行管理根据机器清单和执行清单中的信息确定何时以及可能以什么顺序启动或停止进程，即部署的可执行文件的实例，以确保AUTOSAR自适应平台的正确启动。

执行管理确保检查所有可执行文件和与可执行文件相关的数据（例如清单）的完整性和真实性。如果完整性或真实性检查失败，执行管理将执行第7.9节定义的措施。

[SWS_EM_01030] 限制进程创建权利 Execution Management应该限制进程的权利，使它们不能启动其他进程。](RS_EM_00009)

 [SWS_EM_01030]的限制机制是实现特定的，但可以通过在进程创建时配置进程能力属性掩码来实现。 根据机器状态或任何其他功能组状态，部署的可执行文件在AUTOSAR自适应平台启动时或稍后启动，但不期望所有的可执行文件都立即开始活动工作，因为许多进程将为其他进程提供服务，因此等待并“监听”传入的服务请求。

执行管理根据声明的执行依赖关系[SWS_EM_01050]在机器和/或功能组状态变化的上下文中派生出部署可执行文件的启动/关闭顺序。依赖关系在执行清单中描述，见[TPS_MANI_01041]。

执行管理不负责运行时调度进程，因为这是操作系统[SWS_OSI_01003]的职责。然而，执行管理负责根据从机器清单和执行清单中提取的信息初始化/配置操作系统，以使其能够执行必要的运行时调度和资源管理。

执行管理不进行标准化的终止处理 - 执行管理对接收到信号（例如SIGTERM）的响应是实现定义的。

7.3.1 错误处理

所有的API操作都有可能引发错误。

[SWS_EM_02547]{DRAFT} 获取错误信息 [执行管理应提供一种方法来获取API调用期间发生的错误信息。

类型ara::exec::ExecException，见[SWS_EM_02282]定义了一个通用的 异常和[SWS_EM_02281]相关的错误代码。一个ara::exec::ExecutionErrorEvent表示一个函数组中发生了这样的错误。该属性executionError标识了相关的错误。

一个错误也与一个域相关联，由类型ara::exec::ExecErrorDomain标识，见[SWS_EM_02284]。该域可以从一个 异常通过函数ara::exec::GetExecErrorDomain获取。

该域提供了方法ara::exec::ExecErrorDomain::Name，它返回一个字符串常量，更具体地说，是以NULL结尾的字符串"Exec"，见[SWS_EM_02292]。

它还提供了一种通过方法ara::exec::ExecErrorDomain::Message获取与错误代码相关联的消息的方法.(RS_EM_00150)

[SWS_EM_02548]{DRAFT} 创建错误信息 [执行管理 应提供一种方法来创建错误信息。

函数ara::exec::ExecErrorDomain::ThrowAsException接受一个error代码作为参数。它从错误代码创建一个新的ara::exec::ExecException 实例，并将其作为一个C++异常抛出。这个错误代码可以通过函数ara::exec::MakeErrorCode创建.](RS_EM_00150）

7.4 Process Lifecycle Management

7.4.1 Execution State

执行状态是进程内部生命周期的特征。换句话说，他们从被执行的过程的角度来描述它。进程可见的状态由ara:：exec:：ExecutionState枚举定义

进程的执行状态是由执行管理用来构建和维护进程状态的，如第7.4.2节所述。

进程的执行状态变化通知会导致执行管理管理的进程状态变化。执行状态和进程状态是分别维护的，这样就没有显式的依赖关系 在进程的执行状态和执行管理的进程状态之间。这允许未来进程状态的演化而不影响进程的内部执行状态。

7.4.1.1 Initialization

[SWS_EM_01401] ExecutionClient使用限制 [AUTOSAR自适应平台实现只允许一个进程报告其自己的执行状态。](RS_EM_00103)

当进程状态达到kRunning运行时，无论是通过隐式方式（由非报告进程）还是通过进程报告其执行状态的显式方式，执行管理都认为进程初始化完成。

一个进程需要（见[SWS_EM_01004]）使用ara::exec::ExecutionClient::ReportExecutionState [SWS_EM_02003]方法报告kRunning状态，该方法属于ara::exec::ExecutionClient类，见[SWS_EM_02001]。

它通常在其初始化完成后，但在服务发现完成前报告。如果进程只在服务发现完成后报告kRunning，那么非确定性的延迟可能会影响其他进程，因为执行依赖关系的解决会延迟。

7.4.1.2 Termination

 [SWS_EM_01055] 启动进程终止 [执行管理 应通过向进程发送SIGTERM信号来启动进程终止.] (RS_EM_00103)

请注意，从执行管理的角度来看，需求 [SWS_EM_01055]只要求启动在进程控制下优雅终止所需的步骤。

可能的情况是，根据[SWS_EM_01055]应该终止的进程， 例如，在处理执行依赖关系期间，已经不再存活。然而， 由于执行管理可以确定子进程的状态，因此它不会 尝试终止一个不存在的进程。

执行管理可以在任何时候发送SIGTERM，即使在进程 还没有报告kRunning状态，因此进程仍然处于初始化 进程状态。 收到SIGTERM后，进程简单地开始实际的终止。

在终止状态期间，进程应该保存持久性数据和 释放所有内部使用的资源。进程通过退出状态0 (EXIT_SUCCESS)来指示终止状态的完成。

执行管理作为父进程可以检测到子进程的终止 并采取适当的平台特定的操作，如处理依赖于终止状态的执行依赖关系，从而确保这些进程在同时运行时没有重叠。

[SWS_EM_01314] terminationBehavior的默认值 [执行管理 应将没有指定terminationBehavior的建模过程视为只有在执行管理请求时才终止的过程.] (RS_EM_00103)

7.4.1.3 意外终止

[SWS_EM_01309] 进程意外终止 [如果在之前由ara::exec::StateClient::SetState请求导致的状态转换之外发生意外终止，则执行管理应执行以下操作：

1. 记录事件，如果启用了日志记录
2. 将函数组状态（映射到相关建模过程的函数组）设置为未定义函数组状态。
3. 调用ara::exec::StateClient定义的undefinedStateCallback。
4. 通过ara::exec::StateClient::GetExecutionError接口报告配置的executionError。 (RS_EM_00103) 。请注意，[SWS_EM_01309]也适用于意外自我终止。 由进程执行正确的执行状态报告是一致性的一部分执行管理的行为。
5. 通过ara::exec::StateClient::GetExecutionError接口报告配置的executionError。 c(RS_EM_00103) 请注意，[SWS_EM_01309]也适用于意外自我终止。 由进程执行的正确执行状态报告是一致性的一部分 执行管理的行为。 

7.4.1.4 Application Reporting应用程序报告

 [SWS_EM_02243] 处理执行状态运行 [执行管理应在进程报告执行状态kRunning（使用方法ara::exec::ExecutionClient::ReportExecutionState）时返回kInvalidTransition，且进程不在进程状态启动中。(RS_EM_00103)

为了防止对执行管理的拒绝服务攻击，实现可以限制接受执行状态报告的速率，或者可以请求操作 系统终止底层进程。然而，这样的反应是不标准化的。

执行管理区分两种类型的进程：报告进程和非报告进程。

1. 报告进程被 认为是进程的正常形式，而非报告进程被认为是一种例外。
2. 非报告进程可以用来支持运行没有考虑到AUTOSAR自适应平台的可执行文件。

例如，如果 一个可执行文件只有二进制形式，如果修改其源代码不可行 或者如果可执行文件只在开发时使用。

隐式转换到运行进程状态由[SWS_EM_01402]描述。

在安全相关的系统中，系统设计者必须小心使用非报告过程功能。这样的过程可能不会提供安全关键功能，并且不会被平台健康管理监控，但是它们仍然可能影响其他安全相关的过程，因此可能引入安全 风险。为了将非报告过程与安全关键部分隔离，可以使用ResourceGroup（见第7.7节）。 非报告过程尝试报告执行状态被执行管理视为错误。 [SWS_EM_01403] 报告非报告过程 [ara::exec::ExecutionClient::ReportExecutionState应将其视为违规，当由一个 非报告过程调用时。](RS_EM_00103)

7.4.2 Process States

进程状态从执行管理的角度描述进程的生命周期。换句话说，进程状态代表执行管理对执行状态的内部跟踪（见第7.4.1节）

因此不需要标准化类型。请注意，每个进程都是独立的，因此有自己的进程状态。

执行管理使用进程状态来解决执行依赖关系、管理超时等。

除了进程状态的现有值（Idle, Starting, Running,Terminating, Terminated）之外，实现还可以定义自己的进程状态，这些状态不冲突/不替换现有状态。

• 空闲进程状态 [空闲进程状态应该是在创建进程和分配资源之前的进程状态。](RS_EM_00103)
• 启动进程状态 [启动进程状态应该是在创建进程和分配资源之后的进程状态。](RS_EM_00103)
• 报告进程的运行进程状态 [运行进程状态应该是在报告进程向执行管理报告了kRunning执行状态之后的进程状态。](RS_EM_00103)
• 隐式运行进程状态 [对于非报告进程，从启动到运行进程状态的转换应该在执行管理分配了所需的资源并创建了运行时进程之后隐式地应用。](RS_EM_00103)
• 终止请求后的终止进程状态 [终止进程状态应该是在执行管理向进程发送 SIGTERM信号之后的进程状态。](RS_EM_00103, RS_EM_00011)
• 终止进程状态 [终止进程状态应该是在进程终止并释放了进程资源之后的进程状态。](RS_EM_00103, RS_EM_00011) 。对于终止进程状态，执行管理观察所有进程的退出状态。这种机制是实现相关的，但可以使用 POSIX waitpid() API作为一个例子。

从资源分配的角度来看，终止进程状态与空闲进程状态相似,没有正在运行的进程，也没有分配任何资源。

然而从执行的角度来看，终止进程状态与空闲不同，因为它告诉执行管理，这个进程已经被执行过，终止了，并且现在可以根据[SWS_EM_01066]中的规定重新启动（如果需要）。

空闲和终止之间的区别对于解决自我终止过程的执行依赖关系（见第7.4.3.1节）是相关的。

7.4.2.1 Synchronization with Platform Health Management

平台运行状况管理需要进程状态信息来启动和停止监督。有关详细信息，请参见[8]。

平台运行状况管理需要被监督进程报告执行状态kRunning（[SWS_EM_01004]）的信息来启动活动监督。

向平台健康管理报告“kRunning收到的事件”（如果受监督进程报告了执行状态kRunning，执行管理应通知平台健康管理）

平台运行状况管理需要启动监督流程终止的信息（[SWS_EM_01055]），以停止流程内监督。

[SWS_EM_01211]向平台健康管理层报告“启动过程终止”事件（执行管理层应在即将启动监督过程终止时通知平台健康管理部（RS_-EM_00103）

平台运行状况管理需要终止监督进程的信息（[SWS_EM_01006]），以监督自终止进程。

向平台健康管理报告“流程终止”事件（执行管理层应在监督流程终止时通知平台健康管理层）

提示：哪些流程由平台健康管理监管，可以参考平台健康管理的配置来确定。

上述通知是通过执行管理和平台运行状况管理之间的功能间集群接口提供的。由于此类接口是特定于供应商的，因此其定义（签名）没有标准化。

7.4.3 Startup and Termination启动和终止

7.4.3.1 Execution Dependency执行依赖

执行管理可以根据声明的执行依赖关系，在状态管理框架内推导出进程启动和终止的顺序。这样可以确保应用程序在依赖的应用程序使用它们提供的服务之前启动，同样，也可以确保应用程序在它们提供的服务不再需要时才关闭。

执行依赖关系，是在集成时根据应用程序开发者提供的信息创建的执行清单中配置的。见[TPS_MANI_01041]和[constr_1606]

一个执行依赖关系定义了一个进程所需的功能的提供者，这对于该进程提供自己的功能是必要的。执行管理确保在 定义依赖关系的进程启动之前，依赖的进程处于由执行依赖关系定义的状态。

用户级应用程序应该使用通信管理的服务发现机制作为执行顺序的主要机制 因为这既支持在机器内部，也支持跨机器边界。

因此 用户级应用程序不应该依赖于执行依赖关系，除非必要。哪些进程正在运行取决于当前functionGroup state，包括机器状态，见第7.5节。

集成者应该确保所有服务依赖关系都映射到状态管理配置中， 即当需要时，所有依赖的进程都在运行。

在现实生活中，指定一个简单的依赖关系到一个进程可能不足以 确保依赖的服务实际上是提供的。由于一些进程必须达到某个执行状态（见第7.4.1节）才能向其他进程提供其服务， 因此依赖信息也应该指向 指定为依赖关系的进程的进程状态。考虑到这一点，依赖信息 可以表示为一对类似于：<process>.<processState>。有关更多细节 关于进程状态，请参阅第7.4.2节。

已经识别出以下依赖用例：

对运行进程状态的依赖 如果进程B有一个简单的依赖关系到进程A，那么进程A的运行进程状态被指定，在进程B的执行清单中的依赖部分。

当进程B有一个对进程A的运行执行依赖时， 那么只有当进程A达到运行 进程状态时，才会启动进程B。 对终止进程状态的依赖 如果进程D依赖于 自终止过程C，则终止过程状态process C被指定在过程D的执行清单中的依赖部分。

如果过程D有终止执行依赖于过程C，则 只有当过程C达到终止状态时，才会启动过程D。 在非自终止过程上指定终止执行依赖被认为是配置错误，因为这将表明一个只能在下一个组转换时满足的依赖关系 [SWS_EM_CONSTR_00001]

注意：没有识别出对其他进程状态（即空闲或终止）的执行依赖关系的用例，因此这些不支持 用于执行依赖配置。另请参阅[SWS_EM_CONSTR_01744]。

[SWS_EM_CONSTR_01744]{DRAFT} 在执行依赖关系上下文中定义过程状态 d目标模式声明在角色中引用的 ExecutionDependency.processState应满足以下条件：

• 它应该由一个模式声明组拥有，该模式声明组被引用由一个模式声明组原型（在角色类型中），该模式声明组原型反过来应该被一个进程聚合。

• 封装的模式声明的shortNames只能是以下值之一：

• 运行
• 终止

[SWS_EM_CONSTR_00001]{DRAFT} 对于 Terminated 状态 【A Terminated ModeDeclaration 在 Pro[1]cess.stateDependentStartupConfig.executionDependency 中的引用只有在 stateDependentStartupConfig.executionDependency 中引用的进程的 StartupConfig.terminationBehavior 设置为 processIsSelfTerminating 时才允许.】(RS_EM_00100)

例 7.1

考虑一个进程，DataLogger，它对另一个进程，Storage，有一个执行依赖性。对于启动，这意味着 DataLogger 对 Storage 有一个执行依赖性，因此后者需要在 DataLogger 之前由执行管理启动，以便 DataLogger 可以存储其数据。

进程只有在引用请求的机器状态或功能组状态时才由执行管理启动，而不是因为配置的执行依赖性。执行依赖性只用于在状态转换时控制启动或终止序列。注意，执行依赖性解析的范围仅限于一个功能组状态 (参见 [constr_1689] 和 [SWS_EM_02245])。

[SWS_EM_01050] 启动依赖进程[在启动一个进程时，执行管理应该遵守执行依赖性，确保在启动进程之前，该进程所依赖的任何进程都已经达到了请求的进程状态。](RS_EM_00100)

用于定义启动顺序的相同的执行依赖性也用于定义终止顺序。但是情况相反，因为执行管理需要确保在进程之后终止依赖进程，以确保所需的服务在不再需要之前一直可用。

[SWS_EM_01051] 终止进程d在终止一个进程时，执行管理应该遵守执行依赖性，确保在终止进程之前，该进程所依赖的任何进程都不会被终止。c(RS_EM_00100)

例 7.2

考虑与上面相同的进程，DataLogger，它有一个对另一个进程，Storage，的执行依赖性。对于终止，执行依赖性表明执行管理只需要在DataLogger之后终止Storage，以便后者可以在终止期间刷新其数据。

注意[SWS_EM_01051]仅要求执行管理不在终止一个进程之前终止依赖进程。如果该进程已经自行终止，因此无法被终止，则不是错误。

如果两个进程之间没有指定执行依赖性，则没有顺序被强制执行，它们可以以任意顺序启动或终止。

例 7.3 考虑三个进程：

• Storage，一个没有任何依赖性的服务进程；

• StorageConsistencyChecker，一个自终止的进程，它要求 Storage 处于运行状态；

• ConfigReader，一个服务进程，它要求 StorageConsistencyChecker 已经达到终止状态；

对于启动，这意味着执行管理应该启动 Storage 并 等待它报告 kRunning，然后执行管理应该启动 StorageConsistencyChecker 并等待它终止，然后才启动 Conf igReader。对于终止，执行依赖性表明执行管理可以同时终止 Storage 和 Conf igReader，因为 StorageConsistencyChecker 已经终止，而 Conf igReader 没有 对 Storage 的直接依赖性。如果 Conf igReader 必须在 Storage 之前终止，那么可以通过在 Conf igReader 和 Storage 之间添加一个直接的执行依赖性来实现。

所需的依赖性信息由应用程序开发者提供。它 在集成时根据特定的机器环境进行调整，并在执行清单中提供。 执行管理解析信息并使用它来构建启动序列，以确保在启动依赖进程之前，所需的先行进程已经达到了某个 进程状态 [SWS_EM_01050]。

[SWS_EM_01001] 执行依赖性错误 d如果执行管理 需要启动一个依赖于另一个进程 B 的进程 A，并且进程 B 不是与进程 A 相同的功能组状态的一部分，则执行管理应将此视为错误，并无法启动进程 A.c(RS_EM_00100)

例 7.4

假设进程“A”依赖于进程“B”的运行进程状态。在机器状态转换时，进程“A”应该被启动，因为它引用了新的机器状态。然而，进程“B”没有引用那个机器状态，所以它没有被启动。由于两个进程之间的执行依赖性，进程“A”将永远不会在新的机器状态下运行，因为它永远等待进程“B”。这被认为是一个配置错误，并且也会导致运行时错误。

请注意，需求[SWS_EM_01001]实际上禁止了任何跨越单个功能组状态（或机器状态）定义的执行依赖性，参见[constr_1689]。这样做是有意为之的，因为这种依赖性会在功能组之间引入隐藏的依赖性，而且它们对状态管理不可见。

如果需要表达功能组之间的依赖性（例如，映射软件可能依赖于GPS软件），那么应该在状态管理内部完成。更多信息请参见[10]。

与报告进程不同，非报告进程在启动后直接处于运行进程状态。无论该进程是否完成了初始化阶段并准备提供其服务。这意味着运行执行依赖性立即得到满足，因此如果不采取进一步的行动，当指定为非报告进程时，就不会实现原始语义。

这个限制可以通过引入一个伴随进程来克服，它作为非报告进程的代表。伴随进程等待非报告进程提供的服务的可用性，并向执行管理报告kRunning。实际上需要非报告进程服务的进程可以配置为依赖于伴随进程。

请注意，终止执行依赖性不受影响，因为当非报告进程终止时，操作系统会通知执行管理。请参见图7.5了解更多细节。

• 非报告进程（和自终止进程）A 引用 FG1:Running。这个进程首先启动（因为它没有配置任何执行依赖性），并根据 [SWS_EM_01402] 自动进入运行进程状态。

• 伴随进程 B 在非报告进程 A（请注意，A 和 B 也是标准的 AUTOSAR 进程）进入运行状态后启动。进程 B 可以使用项目特定的方法来评估进程 A 是否 完全功能正常，并通过报告（或不报告）kRunning 状态来向执行管理发出信号。

• 进程 C 在（且仅在）进程 B 进入运行进程状态（即报告 kRunning）时启动。请注意，这个执行依赖性将独立于进程 C 的报告/非报告配置工作。进程 D 在自终止进程（和非报告进程）A 上配置了终止执行依赖性。正如前面提到的，这是开箱即用的（这里不需要特殊操作）。

7.4.3.2 Arguments

执行管理为包含一个或多个 StateDependentStartupConfig 的进程提供参数传递，该进程在 Process.stateDepen[1]dentStartupConfig 的角色中。这允许以不同的 参数启动不同的进程。

[SWS_EM_01012] 进程参数传递 d在启动一个进程的开始，由 StateDependentStartupConfig 引用的 StartupConfig 的聚合 ProcessArgument 应该由执行 管理根据 [SWS_EM_01072] 和 [SWS_EM_01078] 传递给进程。 (RS_EM_00010)

注意 [SWS_EM_01012] 故意没有指定用于 启动进程的 OS 机制，例如基于 exec 系列的 POSIX 接口，因为这最终是一个 实现特定的属性。 执行管理传递的第一个参数是可执行文件的名称。 [SWS_EM_01072] 进程参数零 d参数 0 应该设置为可执行文件的 名称。c(RS_EM_00010)

执行管理支持以与 shell 将命令行参数传递给 POSIX 进程相同的方式将参数传递给进程。执行管理将每个 ProcessArgument.argument 分配给 argv[] 数组中的一个元素，从元素索引 1 开始，并将其传递给进程 main() 函数。ProcessArgument 排序用于保留 (op[1]tion, argument) 对的语义，例如 “-b value”，其中 “-b” 参数必须在 “value” 参数之前。这种方法支持在 POSIX 环境中通常使用的短形式和长形式参数 传递约定。

[SWS_EM_01078] 进程参数字符串 dProcessArgument.argument 应该 按顺序传递给进程，第一个 ProcessArgument.argument 从进程参数 1 开始。] (RS_EM_00010)

传递定义的 ProcessArgument 的顺序由有序的 StartupConfig.processArgument 聚合定义。

7.4.3.3 Environment Variables

执行管理为进程初始化环境变量。进程特定的环境变量在其执行清单中配置。机器特定的环境变量在机器清单中配置。在运行时，可以通过POSIX getenv()命令访问环境变量。

[SWS_EM_02246] 进程特定的环境变量[执行管理应根据Process.stateDependentStartupConfig.startupConfig.environmentVariable的配置准备环境变量，并在进程启动时传递它们。](RS_EM_00010, RS_AP_00130)

[SWS_EM_02247] 机器特定的环境变量[执行管理应根据Machine.environmentVariable的配置准备环境变量，并在进程启动时传递它们。](RS_EM_00010, RS_AP_00130)

请注意，AUTOSAR元模型（参见3）使用TagWithOptionalValue来定义环境变量（[TPS_MANI_01208]和[TPS_MANI_01209]）。如那里所解释的，值（TagWithOptionalValue.value）可以省略，作为指定空值的环境变量的一种方式。

[SWS_EM_02249] 缺少环境变量定义的值[当执行管理发现环境变量定义，该定义缺少TagWithOptionalValue.value时，它应该使用空字符串作为该环境变量的值。](RS_EM_00010, RS_AP_00130)

[SWS_EM_02248] 环境变量优先级[当同一个环境变量在执行清单和机器清单中都有配置时，执行管理应使用执行清单中的环境变量值。](RS_EM_00010, RS_AP_00130)

7.4.4 Machine Startup Sequence机器启动序列 

执行管理是 AUTOSAR 自适应平台的第一个进程。 准备好后，执行管理启动机器状态从关机状态（EM 启动前的默认状态）到启动状态 ([SWS_EM_01023], [SWS_EM_02250]) 的转换。在转换过程中，执行管理请求启动存在于启动机器状态中的进程。

在满足必要的状态转换条件后（参见第 7.5.5 节 和 7.5.2.1 节），执行管理向状态管理报告机器状态启动转换 确认 ([SWS_EM_02241])。在这一点上，执行 管理将功能组状态管理的责任（即 发起状态变更请求）移交给状态管理。

在一个机器上，它可以是任何资源组，即物理环境、hypervisor 上的虚拟化环境，或者 OS 级别的虚拟化（容器），执行管理不一定是启动的第一个进程；

系统可能需要其他进程存在，例如操作系统初始化进程，或者操作系统微内核用户级进程，如驱动程序、文件系统等。所有这些进程都可能在 AUTOSAR 自适应平台的上下文之外启动和管理。

请注意，一个应用程序由一个或多个可执行文件组成。因此，为了启动一个应用程序，执行管理将进程作为每个可执行文件的实例启动。

启动顺序 [平台级进程的启动顺序应由执行管理根据机器清单和执行清单信息确定。](RS_EM_00100) 请参见第 7.2.5 节。

图 7.6 整个启动序列

7.5 State Management

7.5.1 Overview

状态管理功能集定义了 AUTOSAR 自适应平台的运行状态，而执行管理执行不同状态之间的转换。

执行清单允许定义模型化进程必须运行的状态（参见 [3]）。正如前面提到的，一个模型化进程是一个可执行文件的实例，它是应用程序的一部分。

状态管理机制对要执行的应用程序集合有完全的控制权,并确保只有在实际需要时才执行进程（因此分配资源）。 对于执行管理，有四种不同的状态：

1. 执行状态 - 执行状态表征每个启动进程的内部生命周期，参见第 7.4.1 节 进程状态 –
2. 进程状态由执行管理 内部状态机管理。详情请参见第 7.4.2 节。
3. 机器状态 - 参见第 7.5.2 节
4. 功能组状态 - 参见第 7.5.3 节

这些状态之间的交互示例将在第 7.5.4 节中显示。

7.5.2 Machine State

执行管理要求每个机器至少配置一个名为“MachineFG”的功能组。这个功能组有几个强制性的状态（见[SWS_EM_02250]）。可以根据机器的具体情况定义额外的机器状态，因此这些状态不是标准化的。

执行清单定义了进程和功能组状态之间的关系。因此，可以确定每个功能组状态下执行的进程集合。功能组状态是通过ModeDeclaration来建模的，参见[TPS_MANI_01330] [TPS_MANI_03145]和[TPS_MANI_03194]。

在API中，功能组由类ara::exec::FunctionGroup表示，见[SWS_EM_02263]，功能组状态由类ara::exec::FunctionGroupState表示，见[SWS_EM_02269]。

类ara::exec::StateClient在机器的生命周期中执行状态管理，见[SWS_EM_02275]。

机器状态（以及其他功能组状态）由状态管理请求。

活动状态集合受到车辆范围内的事件和模式的显著影响。关于状态变更管理的细节，请参见第7.5.5节。

机器状态配置[执行管理应从具有PLATFORM_CORE类别的SoftwareCluster中的功能组“MachineFG”获取机器状态的配置。](RS_EM_00101)

请注意，根据[constr_1788]，每台机器上必须有且只有一个具有PLATFORM_CORE类别的SoftwareCluster。

从初始状态Startup到状态管理SM请求初始运行机器状态StateXYZ的启动顺序如图7.8所示。

图 7.8: 启动序列 - 从启动到初始运行状态 StateXYZ

图 7.9 中示出了一个任意的状态变化序列，以机器状态 StateXYZ 为例。在这里，收到状态变更请求后，执行管理终止运行中的进程，然后启动在新状态中活动的进程，然后向状态管理确认状态变更。

7.5.2.1 Startup启动 

 [SWS_EM_02250]{DRAFT} 机器状态启动 [如果功能组 “MachineFG” 没有配置启动状态，执行管理应停止 AUTOSAR 自适应平台的启动。](RS_EM_00101)

停止后有多种可能的策略；停止（例如在一个无限循环中）， 中止（例如通过看门狗重置 ECU）等。选择是实现特定的。

[SWS_EM_01023] 自发地启动机器状态启动转换 [执行 管理应自发地启动到启动机器状态的状态转换。] (RS_EM_00101)

请注意，对于机器状态转换，第 7.5.5 节的要求适用。

[SWS_EM_02555]{DRAFT} 机器状态启动转换失败 [在转换到 启动机器状态失败的情况下，执行管理应进入不可恢复状态。](RS_EM_00101)

转换到启动机器状态的失败被认为是一个严重的问题。在这种情况下，执行管理不能确定有多少功能是可用的，以及是否可以由状态管理处理失败的状态转换。值得 注意的是，状态管理本身可能不可用或者其功能在那个时刻可能非常有限。

[SWS_EM_02241] 机器状态启动完成 [在初始的（自发的）机器状态转换到启动状态完成后，执行管理应通过 ara::exec::StateClient::GetInitialMachineStateTransition[1]Result API 将该转换的结果提供给状态管理 。](RS_EM_00101)

请注意，[SWS_EM_02241] 中的通知不是通过广播消息完成的，而是由状态管理通过 ara::exec::StateClient::GetInitialMachineStateTransitionResult API 请求。

 函数 ara::exec::StateClient::GetInitialMachineStateTransitionResult 检索机器状态初始转换到启动 状态的结果。

在达到启动状态后（如 [SWS_EM_02241] 所述），执行管理不会发起任何进一步的功能组状态变化 （包括机器状态）。相反，这些变化由状态 管理请求，然后由执行管理执行。

执行管理将受其他软件实体的控制，并且不应该 自己执行任何功能组状态变化（有一个例外： [SWS_EM_01023]）。这对系统配置产生了一些期望。 该规范期望在每个机器状态中都配置好状态管理（包括启动、关闭和重启）[SWS_SM_- CONSTR_00001]。需要上述期望，以确保总是有 一个软件实体可以引入机器当前状态的变化。

如果 （例如）系统集成者没有配置状态管理在启动机器状态中启动，那么机器将永远无法过渡到任何其他状态，并将永远卡在其中。这也适用于任何其他没有配置状态管理的机器状态 。 必须考虑到从未达到机器状态转换到启动状态的可能性。

在这种情况下，状态管理可以中断启动状态转换并请求例如恢复状态，使用 ara::exec::StateClient::SetState 接口,ara::exec::StateClient::GetInitialMachineStateTransitionResult 将返回值 kCancelled。

7.5.2.2 Shutdown/Restart关闭/重启

执行管理不执行机器的关闭/重启，以避免在执行管理中嵌入项目特定的行为。相反，期望一个项目特定的参与者提供一种关闭/重启机器的机制，

例如，一个独立的进程，它被配置为在转换到关闭/重启机器状态期间由执行管理启动，或者一个在启动机器状态中启动的进程，在关闭机器之前等待一个信号。这种方法使得控制关闭/重启发生的时间和方式可以以项目特定的方式管理。参见3 [constr_- 1618]和[constr_1619]。

需求[SWS_EM_02241]和[SWS_EM_01023]规定了执行管理对启动机器状态存在的依赖性，[TPS_MANI_01330]强制配置启动和关闭/重启机器状态。然而，对于关闭或重启机器状态，没有类似的需求，因为它们的缺失不会阻止执行管理的启动。因此，执行管理对这种错误配置的响应是实现特定的。

对执行管理的请求，将当前机器状态更改为关闭或重启，与任何其他功能组状态更改请求一样处理。从执行管理的角度来看，所有功能组都是独立的，因此对它们的更改可以在没有任何副作用的情况下应用。

然而，从状态管理的角度来看，在不同功能组之间存在依赖性的知识可能并非如此。AUTOSAR假设状态管理将在有效时请求“MachineFG”关闭或重启；关于如何协调机器关闭的建议，请参见[10]。

请注意，什么时候应该请求系统关闭/重启是系统集成者的责任，因为所有仍在运行的进程都不会被执行管理终止，这意味着它们将无法持久化它们的数据。

如第7.5.2.1节所述，AUTOSAR假设状态管理将在关闭和重启中运行。状态转换不是一个简单的系统变化，它可能因为很多原因而失败，在这种情况下，状态管理应该保持活跃以报告错误并等待进一步的指令。请注意，进入关闭或重启状态的目的是以干净的方式关闭或重启机器（包括状态管理）。

[SWS_EM_02549]{DRAFT} MachineFG.Off处理 [执行管理应拒绝将“MachineFG”功能组状态更改为Off 的请求，并返回错误kInvalidTransition.](RS_EM_00101)

7.5.3 Function Group State

如果机器上安装了一组应用程序，那么有能力协调地控制它们将是很有用的。正因为如此，功能组的概念被引入到AUTOSAR自适应平台中。 每个功能组都有自己的一组进程和一组称为功能组状态的状态。

每个功能组状态定义了当状态管理从执行管理请求功能组状态激活时，应该启动哪些进程。 功能组机制非常灵活，它是用来启动和停止应用程序进程的工具。系统集成者可以将进程分配给一个功能组状态，然后由状态管理请求它。 关于状态变更管理的细节，请参见第7.5.5节。

 一个建模进程不能被分配给多于一个功能组[constr_1688]。要想知道为什么需要这个约束，可以考虑相反的情况：一个建模进程映射到两个功能组中的两个状态。该建模进程现在在两个状态中运行，而在任何一个状态中的功能组状态转换都需要终止该进程。这种终止会违反第二个功能组状态的完整性，因此存在这个约束来防止这种情况。

一般来说，机器状态（见第7.5.2节）用于控制机器生命周期（启动/关闭/重启）和平台级应用程序的进程，而其他功能组状态分别控制属于功能上相干的用户级应用程序的进程。请注意，这并不意味着所有平台级应用程序的进程都必须由机器状态控制。

图7.10显示了一个状态变更序列的例子，其中几个进程引用了机器状态和两个额外功能组FG1和FG2的功能组状态。为了简单起见，每个进程只显示了三个静态进程状态：空闲、运行和终止。

图 7.10: 状态依赖的进程控制

• 进程 A 引用机器状态启动。它是一个自终止的进程，即它在执行一次后终止。

• 进程 B 引用机器状态启动和运行。它依赖于 进程 A 的终止，即配置了执行依赖性，如第 7.4.3.1 节所述

• 进程 C 只引用机器状态运行。它在 状态管理请求机器状态诊断时终止。

• 进程 D 和 E 只引用功能组状态 FG1:Running 并且它们之间没有配置执行依赖性。执行管理将以任意顺序（例如如果可能的话并行）启动和终止它们。

• 进程 F 引用 FG2:Running 和 FG2:Fallback。它在两个状态下有不同的 启动配置，因此它在状态转换时终止并重新启动，使用不同的启动配置。

系统设计和集成应确保在任何时候机器上都有足够的资源，即应考虑所有同时引用活动状态的进程的增加的资源消耗。

功能组配置 [执行管理应从处理过的清单中获取功能组的配置，以设置功能组特定的状态管理。][SWS_EM_01107]{OBSOLETE} (RS_EM_- 00101)

一个正确的系统配置要求每个进程在其执行清单中引用一个或多个功能组状态（可以是机器状态）。如果一个进程没有引用任何功能组状态，它将永远不会被启动，更多细节请参考 [SWS_EM_01066] 和第 7.5.5 章状态转换。

[SWS_EM_01013]{OBSOLETE} 功能组状态 [执行管理 应支持根据当前功能组状态和执行清单中提供的信息执行特定的模型化进程。](RS_EM_00101)

每个模型化进程都分配给一个或多个启动配置（StartupConfig），每个配置都可以定义一个或多个功能组状态（包括机器状态）中的启动行为。详情请参见 3。通过解析执行清单中的这些信息，执行管理可以确定如果进入特定的功能组状态，需要启动哪些模型化进程，以及哪些启动参数是有效的。

[SWS_EM_01033] 进程启动配置[为了使一个建模进程能够在多个功能组状态中启动，执行管理应该能够根据执行清单中提供的信息配置每个功能组状态变更时启动的进程。](RS_- EM_00009, RS_EM_00101)

[SWS_EM_02254]{OBSOLETE} 错误配置的进程 - 分配给多个功能组d在功能组状态转换期间，任何涉及的进程，如果引用了多个功能组的状态，应该导致EM执行以下操作：

1. 停止功能组状态转换，以便状态管理可以决定如何继续。
2. 如果需要，记录事件
3. 将当前功能组状态设置为未定义的功能组状态。
4. 在ara::exec::StateClient::SetState接口中报告kFailed，以指示无法满足状态更改请求。
5. 通过ara::exec::StateClient::GetExecutionError接口报告请求的功能组状态的executionError。](RS_EM_00101)

请注意，AUTOSAR不支持将单个进程分配给多个功能组的可能性，请参见3（[constr_1688]）。 [SWS_EM_01110] 关闭状态[每个功能组（包括功能组“MachineFG”）都有一个关闭状态，执行管理应该将其用作初始功能组状态。](RS_EM_00101)

在任何FunctionGroup中，包括“MachineFG”，“Off”状态是强制性的初始状态[TPS_MANI_03195]，并且不能根据[constr_3424]映射建模进程。[SWS_EM_01110]和[SWS_EM_01023]一起定义了上电后的第一个功能组状态转换。

进程在其执行清单中引用了它们想要执行的状态。一个状态可以是任何功能组状态，包括机器状态。详情请参见3，特别是“状态相关启动配置”章节和“功能组”章节。

图7.9所示的任意状态变更序列适用于任何功能组的状态变更 - 只需用功能组的名称替换“MachineFG”。在收到状态变更请求后，执行管理终止不再需要的进程，然后在向状态管理确认状态变更之前启动新功能组状态下活动的进程。详情请参见第7.5.5节。

7.5.4 State Interaction状态交互

图7.11显示了一个简化的例子，说明了在状态管理功能集合请求了不同的功能组状态后，不同类型的状态之间的交互。可以看到功能组的状态转换以及一个引用该功能组一个状态的进程的进程和执行状态，忽略了如果涉及多个进程时可能存在的延迟和依赖性。

7.5.5 State Transition

状态管理可以使用第8.2.7节描述的API请求改变一个或多个功能组状态（包括机器状态）。ara:- :exec::StateClient::SetState允许状态管理并行地请求多个功能组状态的变化。如果需要机器状态的变化，传递的功能组名称应为：“MachineFG”。

[SWS_EM_02298] 取消正在进行的状态转换 d在成功验证ara::exec::StateClient::SetState调用后，如果功能组已经处于状态转换中，执行管理应在开始新的功能组状态转换（并返回新请求的ara::core::Future）之前取消正在进行的功能组状态转换（并将该请求的ara::core::Future设置为kCancelled）。c(RS_EM_00101) 在执行管理根据[SWS_EM_02298]取消正在进行的请求之前，新请求应被评估为有效，这包括但不限于[SWS_EM_02553]和[SWS_EM_02554]。

请注意，[SWS_EM_02298]仅确保执行管理在通知新请求者新请求已被接受之前，先通知正在进行转换的请求者（ara::exec::StateClient实例）转换已被取消。两个请求者可能是同一个ara::exec::StateClient实例。 没有其他要求或假设关于ara:- :exec::StateClient::SetState的请求处理顺序。 请求与之前相同的功能组状态（无论之前的状态请求是否已经完成或仍在进行中）应被阻止，因为它可能导致不希望的执行依赖性。当需要再次请求相同的功能组状态时，必须先请求另一个状态。

请注意，如果之前的转换以错误结束，状态管理可以重复状态转换请求（到相同的状态）。这是允许的，因为失败的状态转换被认为是无效的功能组状态。

由于执行管理允许一个新的ara::exec::StateClient::Set- State调用中断正在进行的转换，并因此改变转换的目标功能组状态，可能会发生（尤其是在配置错误的系统或开发阶段）一些ara::exec::StateClient:- :SetState请求会被错误地发出。尽快通知正在进行转换的请求者（ara::exec::StateClient实例）它已被新请求取消是执行管理最大的利益。

 [SWS_EM_02553]{DRAFT} 拒绝到FG已经处于的状态的状态转换 dara::exec::StateClient::SetState应拒绝请求并返回kAlreadyInState错误代码，如果给定的功能组状态已经建立。c(RS_EM_00101) [SWS_EM_02554]{DRAFT} 拒绝到FG已经转换到的状态的状态转换 dara::exec::StateClient::SetState应拒绝请求并返回kInTransitionToSameState错误代码，如果到给定功能组状态的状态转换已经在进行中。c(RS_EM_00101)

图7.12：状态转换的示例配置

在我们指定状态转换的内部工作方式之前，让我们考虑图7.12所示的一个示例配置。如我们所见，跨越函数组甚至单个函数组状态的执行依赖关系是禁止的。来自函数组FG_B中的进程B到函数组FG_A中的进程A的依赖关系是禁止的，因为它会在函数组之间引入对状态管理不可见的隐藏依赖关系。如果系统配置需要这种类型的依赖关系，请参阅[10]以获取有关如何配置它们的建议。跨越单个函数组状态定义之外的依赖关系是禁止的，因为它们会导致启动一个未配置为在给定状态下运行的进程。有关执行依赖关系的更多信息，请参阅第7.4.3.1节（[SWS_EM_01001]和[constr_1689]）。

请注意，进程B在函数组状态ABC和函数组状态XYZ中具有不同的执行依赖关系。此配置要求存在两个不同的启动配置（StateDependentStartupConfig），这反过来又要求进程B重新启动，如果状态管理请求从ABC到XYZ的函数组状态更改。这是由[SWS_EM_02251]强制执行的。

从上面我们可以得出结论，每个函数组都是一个单独的实体，一个函数组的状态转换不会对另一个函数组产生副作用。请注意，这是从执行管理的角度来看是正确的，但可能与状态管理的角度不同（如果您需要更多信息，请参阅[10]）。 在以下要求中，建模进程的执行清单是进程启动行为的正式建模，并通过聚合元类StateDependentStartupConfig在角色Process（[TPS_MANI_01012]）中实现。

术语“the process references a State进程引用状态”表示引用了一个StateDependentStartupConfig实例的functionGroupState，在适用于与特定功能组状态相关联的进程相关联的StartupConfig中。

CurrentState是请求状态转换的功能组的当前（当前活动）状态；或者如果功能组具有“MachineFg”名称，则为当前机器状态。简而言之，这是一个功能组状态或机器状态。 RequestedState是一旦状态转换成功完成将成为CurrentState的状态。

换句话说，CurrentState是转换的起点，应该在功能组内当前运行的进程列表（请注意自终止进程的存在）。RequestedState是状态转换 目标点，将在功能组内运行的进程列表（请注意自终止进程的存在）。 StartupConfig是聚合在角色Process.stateDependentStartupConfig中给定进程使用的StateDependentStartupConfig。

状态转换是一个复杂的过程，但它由三个简单的逻辑步骤组成：

• 终止所有当前运行且在RequestedState中不需要的进程

• 重新启动所有当前运行且在CurrentState和RequestedState之间具有不同StartupConfig

• 启动所有当前未运行且在RequestedState中需要运行

请参阅第7.4.1节和第7.4.2节，了解执行管理如何处理进程终止和启动（重新启动是终止和启动 序列）。

[SWS_EM_01060] 状态转换 - 终止行为 d在状态转换时，执行管理应请求终止（[SWS_EM_01055]）每个在其执行清单中引用当前状态，但不引用请求状态并且具有与[空闲或终止]不同的进程状态的进程。c(RS_EM_00101)

[SWS_EM_02251] 状态转换 - 重启行为 d在状态转换时，执行管理应终止所有在其执行清单中引用当前状态，但以不同的启动配置引用请求状态并且具有与[空闲或终止]不同的进程状态的进程。c (RS_EM_00101)

请注意，[SWS_EM_02251]只请求终止进程，启动部分将属于[SWS_EM_01066]需求，从而使重启完成。 执行管理监控每个进程终止所需的时间。进程终止超时的默认值由系统集成商在机器清单中定义，见[TPS_MANI_03151]。该值可以通过在执行清单中定义终止超时参数来覆盖个别进程的启动配置，见[TPS_MANI_01278]。

[SWS_EM_01065] 状态转换 - 进程终止超时监控 d 执行管理应监控进程终止所需的时间（进程达到终止进程状态所需的时间）。c (RS_EM_00101)

[SWS_EM_02255] 状态转换 - 进程终止超时反应 d 在发生进程终止超时（由配置StartupCon[1]fig.timeout定义）的情况下，执行管理应请求操作系统强制终止底层进程。c(RS_EM_00101) 在多进程POSIX平台上，这可以使用SIGKILL信号实现。

[SWS_EM_02258] 状态转换 - 进程终止超时报告 d 当进程的终止导致超时时，如果启用了日志记录，执行管理应记录该事件。c(RS_EM_00101)

执行管理即使在存在非[1]终止进程的情况下也继续状态转换，因为这些进程将被杀死（见[SWS_EM_02255]和[SWS_EM_01060]），目标功能组状态将被达到。在终止超时的情况下继续进行，特别是确保功能组状态"Off"总是可以达到（前提是操作系统级别的进程终止总是成功的）。

这与在启动过程中超时的进程（见 [SWS_EM_02259]）不同：这些进程不能被强制启动，功能组状态将不会被达到。

 [SWS_EM_01066] 状态转换 - 启动行为 d 在状态转换时，执行管理应启动所有在其执行清单中引用请求状态并且具有[空闲或终止]的进程状态的进程。c (RS_EM_00101)

执行管理监控每个进程启动所需的时间。启动超时由系统集成商在执行清单中为每个进程启动配置定义，见[TPS_MANI_01277]。

[SWS_EM_02253] 状态转换 - 进程启动超时监控[ 执行管理应监控进程启动所需的时间（从执行管理请求操作系统创建进程到进程成功报告运行进程状态的时间）。](RS_EM_00101)

执行管理监控每个进程启动所需的时间。进程启动超时的值由系统集成商在Exe[1]cution Manifest中定义，见[TPS_MANI_01277]。请注意，非- 报告进程的启动时间为零，因为非报告进程立即从进程状态空闲切换到运行，跳过启动状态。

[SWS_EM_02260] 状态转换 - 进程启动超时反应 d如果发生进程启动超时（由配置StartupConfig.timeout定义），执行管理应尝试重新启动进程，直到num[1]berOfRestartAttempts次。c(RS_EM_00101)

进程启动超时是由故障引起的，因此执行管理请求操作系统终止进程（例如使用 SIGKILL），而不是通过SIGTERM请求终止，因为假定进程处于错误状态。

[SWS_EM_02280] 执行依赖关系的影响 [根据 [SWS_EM_02260] 的重新启动尝试不应满足任何已终止的依赖关系。](RS_EM_00101)

[SWS_EM_02310] 状态转换 - 进程终止后启动超时反应 [如果在执行管理 尝试重新启动进程numberOfRestartAttempts次后发生进程启动超时，执行 管理应请求操作系统终止底层进程。](RS_EM_00101)

[SWS_EM_02259] 状态转换 - 进程启动超时报告 [当 进程的启动导致超时时，执行管理应执行以下操作：

1. 停止功能组状态转换，以便状态管理可以决定如何继续。
2. 记录事件，如果日志记录已激活
3. 将CurrentState设置为未定义的功能组状态。
4. 在ara::exec::StateClient::SetState接口中报告kFailed，以 表示无法满足状态更改请求。
5. 通过ara::exec::State[1]Client::GetExecutionError接口报告配置的executionError。 c(RS_EM_00101)

[SWS_EM_02552]{DRAFT} 状态转换 - 完整性或真实性检查失败 d当进程的启动导致完整性或真实性检查失败，并且严格模式处于活动状态（[SWS_EM_02305]），执行管理应执行以下操作：

1. 停止功能组状态转换，以便状态管理可以决定如何继续。
2. 记录事件，如果日志记录已激活
3. 将CurrentState设置为未定义的功能组状态。
4. 在ara::exec::- StateClient::SetState接口中报告kIntegrityOrAuthenticityCheckFailed，以表示无法满足状态更改请求。
5. 通过ara::exec::State[1]Client::GetExecutionError接口报告配置的executionError。 c(RS_EM_00101)

[SWS_EM_02312] 进程启动超时反应的顺序 d执行管理应在向 状态管理报告之前执行终止反应[SWS_EM_02310] [SWS_EM_02259]。c(RS_EM_00101)

当启动新进程时，执行管理有义务执行 依赖性解析。在这样做时，它可能会遇到一个配置，其中进程B依赖于进程A，但是进程A需要在 状态改变期间重新启动。另一个例子是一个配置，其中进程D依赖于一个 自终止进程C处于已终止的进程状态。过程 C必须在请求的功能组状态中启动和终止才能满足 D的执行依赖关系。请参阅图7.13了解更多详细信息。

图7.13：状态变化期间的依赖性解析

[SWS_EM_02245] 状态变化期间的依赖性解析 d执行管理应对配置为请求状态的进程执行执行依赖性解析。c(RS_EM_00101)

请注意，[SWS_EM_02245]并没有给状态转换带来新的功能。它只是确保在对进程B执行[SWS_EM_01066]之前，对进程A执行[SWS_EM_02251]和[SWS_EM_01066]。如果不确保这个顺序，那么[SWS_EM_02245]就不能被满足，因为进程A将是一个配置为当前状态而不是请求状态的进程。

本章对功能组状态转换的描述可能会给人一种印象，即在启动任何需要的进程之前，需要先停止所有在请求状态中不需要的进程。请注意，情况并非如此。本章采用逐步的方法是为了在描述功能组状态转换时尽可能地引入清晰性。实现者可以根据特定的实现，尽可能地并行化尽可能多的步骤（用于状态转换）。 执行管理认为当发生以下情况时，状态转换已成功完成：

• 依赖性解析（[SWS_EM_02245]）已确定要启动/停止的进程

• 所有预期终止的进程已终止（[SWS_EM_01060]）

• 所有启动（[SWS_EM_01066]）或重启（[SWS_EM_02251]）的报告进程已报告kRunning。

[SWS_EM_01067] 状态转换完成后的动作 d在状态转换成功完成后，执行管理应将当前状态设置为请求状态，并向状态管理报告成功。c(RS_EM_- 00101)

[SWS_EM_02313] 功能组状态转换期间启动进程意外终止 d在进程启动期间发生意外终止（[SWS_EM_01066]），执行管理应执行以下动作：

1. 停止功能组状态转换，以便状态管理可以决定如何继续。
2. 记录事件，如果日志记录已激活
3. 将CurrentState设置为未定义的功能组状态。
4. 在ara::exec::- StateClient::SetState接口中报告kFailedUnexpectedTerminationOnEnter，以表示无法满足状态更改请求。
5. 通过ara::exec::State[1]Client::GetExecutionError接口报告配置的executionError。 ](RS_EM_00101)

请注意，[SWS_EM_02313]也适用于意外自终止。

[SWS_EM_02314] 功能组状态转换期间终止进程的意外终止 [如果在进程终止期间发生意外终止（[SWS_EM_01060]，[SWS_EM_02251]），执行管理应记录事件，如果日志记录已激活。](RS_EM_00101)

如果进程B在功能组状态转换的启动阶段依赖于进程A的终止，[SWS_EM_01309]（意外终止） 适用：如果一个进程在完成其任务之前死亡，功能组状态转换将被停止，并向状态管理报告错误。

[SWS_EM_02297] StateClient使用限制 [当由一个进程调用时，StateClient API应将其视为 违规，该进程的Process.functionClusterAffiliation配置为除STATE_MANAGEMENT之外的任何其他内容。](RS_EM_00101)

如果不受保护，StateClient可用于破坏机器，请参阅第8.2.7节 了解更多详细信息。